1.11 Verifying IP Parameters on Client Operating Systems

The five parameters that must be right

Whenever a client cannot reach the network, verify these five values, a wrong one explains most outages:

Windows commands

• ipconfig shows IP, mask, and gateway per interface.
• ipconfig /all adds DHCP server, DNS servers, MAC (physical) address, and lease times.
• ipconfig /release and ipconfig /renew drop and request a DHCP lease.
• ipconfig /flushdns clears the DNS resolver cache.

Linux and macOS commands

• ip addr (modern Linux) or ifconfig shows interface addresses; macOS uses ifconfig and the GUI.
• ip route (or netstat -rn) shows the default gateway/routing table.
• cat /etc/resolv.conf reveals configured DNS servers on Linux.

The APIPA clue

If a host shows an address in 169.254.0.0/16 (an APIPA, automatic private IP addressing, address), it means the client is set for DHCP but never received a lease, the DHCP server is down, unreachable, or the cable/VLAN is wrong. APIPA only allows same-link communication; the host cannot reach the gateway or Internet.

Diagnostic tools

• ping sends ICMP echo requests to test Layer 3 reachability. ping 127.0.0.1 tests the local TCP/IP stack; ping the gateway, then a remote host, to localize the break.
• tracert (Windows) / traceroute (Linux/macOS) shows each hop along the path, exposing where packets stop.
• nslookup queries DNS to confirm name resolution; if ping 8.8.8.8 works but ping example.com fails, it is a DNS problem.
• arp -a displays the local ARP cache mapping IPs to MACs on the segment.

Structured troubleshooting (worked example)

A user reports "the Internet is down." Work the layers:

1. ipconfig /all, the address is 169.254.12.7, so DHCP failed. Run ipconfig /renew.
2. After renew the host gets 192.168.1.50/24, gateway 192.168.1.1. ping 192.168.1.1 succeeds, local link is fine.
3. ping 8.8.8.8 succeeds but ping example.com fails, so connectivity is fine but DNS is broken.
4. nslookup example.com times out, confirm/correct the DNS server in ipconfig /all; once a reachable DNS server is set, names resolve.

This bottom-up method (link, then gateway, then remote IP, then DNS) isolates the fault quickly and is exactly the reasoning the CCNA expects.

Cross-platform command reference

The exam expects you to map a task to the right command on each OS:

The biggest portability trap is tracert vs traceroute: Windows truncates it to eight letters (tracert), while Unix-like systems spell it out.

What each tool actually proves

• A successful ping to 127.0.0.1 proves the local TCP/IP stack is installed and running, before blaming the network, confirm the stack.
• A ping to the default gateway proves Layer 1-3 to the first hop is healthy.
• A ping to a remote public IP (e.g., 8.8.8.8) proves routing and Internet reachability.
• A failed name ping after a successful IP ping isolates the fault to DNS.
• traceroute/tracert shows where in the path packets stop, the last responding hop is near the break.

DHCP vs static configuration

Most clients use DHCP to lease an IP, mask, gateway, and DNS automatically; servers and infrastructure often use static addresses so they never change. When ipconfig /all shows "DHCP Enabled: Yes" but an APIPA address, the lease attempt failed; when it shows "DHCP Enabled: No", an administrator set the values by hand and a wrong static gateway or DNS is the likely culprit. Reading the DHCP-enabled flag alongside the address tells you which path to troubleshoot.

Common traps

• A 169.254.x.x address is never a working DHCP lease, it signals DHCP failure (APIPA).
• If IP pings work but names do not, suspect DNS, not routing.
• ipconfig (no flag) does not show the DNS server or MAC, you need ipconfig /all.
• Windows uses tracert; Linux/macOS use traceroute, mixing them up is a common slip.
• A successful loopback ping does not prove network connectivity, only that the local stack works.