Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 1.10 — Verify client IP parameters

Client troubleshooting begins with four facts: interface state, address and prefix, default gateway, and DNS resolver. Windows, macOS, and Linux expose them through different commands, but the packet-path reasoning is identical.

Windows evidence

ipconfig /all displays adapter state, IPv4 and IPv6 addresses, masks or prefixes, gateways, DHCP status, lease information, and DNS servers. route print shows the route table, while arp -a or neighbor-oriented tools show local resolution state. Select the active adapter; virtual, disconnected, and tunnel interfaces can add misleading output.

macOS and Linux evidence

On modern Linux, ip address shows interface addresses and state, ip route shows IPv4 routes, and ip -6 route shows IPv6 routes. Resolver configuration may be managed through a service rather than one static file. macOS commonly uses ifconfig for interface details and route or netstat-style views for routing; system configuration tools expose DNS. The exam goal is interpreting parameters, not insisting every operating-system release uses one command.

Local-versus-remote decisions

The host applies its prefix to decide whether a destination is on-link. For an on-link destination, it resolves the neighbor's Layer 2 address. For a remote destination, it resolves the default gateway and sends the frame there. A missing or off-subnet gateway can allow local communication while remote traffic fails.

DNS is a separate dependency. If a connection to an IP address works but the name fails, inspect the configured resolver, search suffix, query result, and reachability to the DNS server before changing the gateway.

Worked scenario

A laptop has 192.0.2.70/26, gateway 192.0.2.1, and correct DNS. The /26 subnet is 192.0.2.64/26; gateway .1 is outside it. Local hosts in .65–126 may work, but normal gateway resolution fails. Correct the gateway to an approved usable address inside the subnet rather than blaming DNS.

Verification sequence

Confirm link and adapter state. Validate the address against the prefix. Confirm the gateway is reachable on-link. Inspect the default route. Test the gateway, then a remote IP, then a DNS query and named application. At each step, record which layer the result supports.

Common traps

• Reading a disconnected or virtual adapter.
• Treating a self-assigned address as a valid enterprise lease.
• Blaming DNS when remote IP traffic also fails.
• Looking only at the address and ignoring prefix.
• Assuming a listed gateway is inside the local subnet.

Readiness checklist

• I can find equivalent host parameters on all three OS families.
• I can verify whether the gateway is on-link.
• I separate name resolution from IP reachability.
• I can build a test sequence from local to remote dependencies.