Path and Client Configuration Commands

Read the Local Configuration First

After ping, two questions remain: how is this endpoint configured, and where does its traffic try to go? Client-configuration commands expose local settings; path commands trace the route outward. Together they separate a bad endpoint config from an upstream routing or filtering fault.

On Windows, ipconfig is the start. ipconfig alone shows each adapter's IPv4/IPv6 address, mask, and gateway. ipconfig /all is the support workhorse: it adds the adapter description, physical (MAC) address, DHCP enabled/disabled, DHCP server, DNS servers, lease obtained/expires, and a "Media disconnected" flag for unplugged adapters. ipconfig /release and /renew request a fresh DHCP lease (use carefully, it drops the user's connection briefly), and ipconfig /flushdns clears the local resolver cache after a record changes but will not repair a wrong DNS server entry.

On Linux, legacy guides cite ifconfig, but modern distributions use the ip command from iproute2: ip addr lists interface names, MACs, IPv4/IPv6 addresses and state; ip route shows the routing table including the default route; ip link shows link-layer state. resolvectl status or /etc/resolv.conf reveal DNS; NetworkManager hosts add nmcli device show. On macOS, ifconfig still shows addresses, route -n get default names the gateway path, and scutil --dns shows resolvers.

The exam expects you to recognize the equivalent command across platforms, do not assume ipconfig exists on Linux or that ifconfig is the modern Linux default. A frequent trap question shows a Linux prompt and asks for the address command; ip addr is correct, while ipconfig /all is a Windows-only distractor.

Interpret Against the Expected Design

A host on a typical IPv4 LAN needs an address in the correct subnet, a matching mask/prefix, a default gateway inside that subnet, and reachable DNS servers. Spot these red flags:

• 169.254.x.x (APIPA) or no address: DHCP failed; check the DHCP scope, the link, the VLAN, or the SSID.
• A Duplicate IP address warning: two devices share the address, usually a static/DHCP collision that must be resolved before anything else works.
• Gateway missing: the host reaches local devices but nothing off-subnet.
• DNS missing/unreachable: IP-based tests work while names fail.
• Address in the wrong subnet: likely wrong VLAN, wrong SSID, or a stale static config.

Trace the Path Without Overreading It

Traceroute-style tools send probes with increasing time-to-live (TTL) values; each router that decrements TTL to zero returns an ICMP Time Exceeded, revealing one hop. Windows uses tracert; Linux/macOS use traceroute (Linux also has tracepath). Output shows per-hop latency and where responses stop.

The classic trap: asterisks (* * *) on a hop do not prove the path is broken. Routers and firewalls routinely block, rate-limit, or deprioritize traceroute replies while still forwarding real traffic, the destination may drop probes, and Internet paths change between runs. Read traceroute for broad clues: does traffic die before the gateway (local problem), leave the site but stop at the provider edge (WAN/ISP), or take a wildly different route than expected? Always combine it with ping, DNS, and application tests.

One nuance worth knowing: Windows tracert sends ICMP Echo Requests with increasing TTL, while traditional Unix traceroute sends UDP probes to high port numbers by default. That difference explains why the same destination can produce different results from a Windows box versus a Linux box, some firewalls permit ICMP but block the UDP probes, or vice versa. When a path looks broken from one OS, retesting from another can confirm whether the failure is real or just a filtering artifact of the probe type.

Putting Config and Path Together

The two command families complement each other. Suppose ipconfig /all shows a valid address, mask, gateway, and DNS, but tracert 8.8.8.8 dies after the first hop. The endpoint config is fine, so the fault is upstream: the gateway accepted the packet but could not forward it, pointing at a routing, WAN, or ISP problem to escalate. Now suppose ipconfig /all shows a 169.254 APIPA address, in that case you would not bother with traceroute at all, because the host never got a lease and has no usable gateway. Reading the local configuration first tells you whether a path test is even meaningful.

Documenting for Escalation

Record the command, source device, connection, destination, and exact output, because routing and DHCP faults are location-specific and an engineer cannot reproduce them from your desk. tracert app.company.example from Accounting desktop on switch port B14 stops after the default gateway is far more actionable than route broken, it names the source, the port, the destination, and exactly where in the path the trace failed, letting the engineer focus immediately on the gateway and the segment beyond it.