Path and Client Configuration Commands

Read the Path and the Local Configuration

After basic ping testing, technicians often need to know two things: how the endpoint is configured and where traffic appears to travel. Client configuration commands expose local settings. Path commands show a hop-by-hop view toward a destination. Together, they help separate a bad endpoint configuration from an upstream routing or filtering issue.

On Windows, ipconfig is the standard starting point. ipconfig shows each adapter's basic IPv4 and IPv6 settings. ipconfig /all is more useful for support because it includes adapter description, physical address, DHCP status, DHCP server, DNS servers, lease information, default gateway, and whether media is disconnected. ipconfig /release and ipconfig /renew can request a new DHCP lease, but use them carefully because they can interrupt a user's connection.

ipconfig /flushdns clears the local DNS resolver cache, which may help after a DNS record changes, but it does not repair a wrong DNS server setting.

On Linux, older guides often mention ifconfig, but many modern distributions use the ip command from the iproute2 toolset. ip addr shows interface names, MAC addresses, IPv4 and IPv6 addresses, and interface state. ip route shows the routing table, including the default route. ip link shows link-layer interface state. resolvectl status may show DNS details on systems using systemd-resolved, while /etc/resolv.conf may show resolver configuration on other systems. NetworkManager systems may also use nmcli device show or nmcli connection show.

On macOS, ifconfig still commonly shows interface addresses and link information. route -n get default identifies the default gateway path, and netstat -rn can show the routing table. scutil --dns gives DNS resolver details. In graphical System Settings, Wi-Fi and Ethernet details can show IP address, router, DNS, proxy, and hardware address. The command-line and graphical views should agree; if they do not, document both rather than guessing.

Interpret configuration output against the expected design. A host on a typical small IPv4 LAN might need an IP address in the correct subnet, a subnet mask or prefix, a default gateway in that subnet, and DNS servers. If the address is self-assigned, missing, duplicated, or outside the expected range, investigate DHCP, static settings, wrong SSID, wrong VLAN, or cable placement. If the gateway is missing, the host may reach local devices but fail outside the subnet. If DNS servers are missing or unreachable, IP-based tests may work while names fail.

Traceroute-style tools show the path toward a destination by sending probes with increasing time-to-live values. On Windows the command is tracert. On Linux and macOS it is commonly traceroute, though Linux may also have tracepath. Each hop shown is a router or Layer 3 device that responded to a probe. Output can show latency per hop and where responses stop.

Do not overread traceroute. Routers and firewalls may block, rate-limit, or deprioritize traceroute responses while still forwarding user traffic. Asterisks can mean no response from that hop, not necessarily total failure. The final destination may block probes. A path across the Internet can change between tests. Use traceroute to identify broad clues, such as traffic failing before the gateway, leaving the site but stopping at a provider edge, or taking a very different route than expected. Combine it with ping, DNS checks, application tests, and scope information.

Good triage records the command, source device, network connection, destination, and exact output. That matters when escalating because routing and DHCP issues are often location-specific. tracert app.company.example from Accounting desktop on switch port B14 stops after default gateway is more useful than route broken.

Study Checkpoint

• Topic: Path and Client Configuration Commands.
• Verify the official Cisco concept before memorizing a shortcut.
• Practice the technician action: observe, document, test, fix when supported, or escalate.