CCNA 200-301 v1.1 reference — Network Fundamentals

Client IP verification

Verify address, mask, gateway, DNS and reachability on Windows, macOS and Linux with the commands each platform actually provides.

Objective 1.10v1.1 exam target

What to check and where

Task	Windows	macOS	Linux
Show addressing	`ipconfig` / `ipconfig /all`	`ifconfig` or System Settings → Network	`ip addr` / `ip -br a`
Show gateway/routes	`route print`	`netstat -nr`	`ip route`
DNS servers	`ipconfig /all`	`scutil --dns`	`resolvectl` or `/etc/resolv.conf`
Test DNS	`nslookup name`	`nslookup` / `dig`	`nslookup` / `dig`
Reachability	`ping`, `tracert`	`ping`, `traceroute`	`ping`, `traceroute` / `mtr`
Renew DHCP	`ipconfig /release` + `/renew`	Network settings / `ipconfig set <iface> DHCP`	`dhclient -r && dhclient`

Address: does the client hold an address in the expected subnet? (169.254.x.x = DHCP failed.)
Mask/prefix: does the client think the gateway is on-link? A wrong mask strands it.
Gateway: is the default gateway reachable (ping it) and correct?
DNS: does the client list a resolver and does nslookup succeed?
Beyond the gateway: tracert/traceroute localizes where forwarding stops.

$ ipconfig /all (interpreted)

IPv4 Address. . . . . . . . . . . : 192.168.10.55Expected subnet? Compare with the VLAN's scope.

Subnet Mask . . . . . . . . . . . : 255.255.255.0Wrong mask → wrong on-link decision.

Default Gateway . . . . . . . . . : 192.168.10.1Must be inside the same subnet.

DHCP Enabled. . . . . . . . . . . : YesIf No, static misconfig is a suspect.

DNS Servers . . . . . . . . . . . : 192.168.10.10Missing/wrong resolver breaks name-based access.

Isolate the failing layer

Check the configured DNS server and reachability to it; the 'internet is down' report was actually a resolver failure.

Client verification sequence (Windows example)

Baseline a client's IP parameters — Command prompt / PowerShell

Windows 10/11

Verify

ipconfig /all
route print
nslookup example.com
ping <gateway>
tracert <destination>

Read-only verification commands.

Restarting the router before checking the client — an APIPA address points at DHCP, but a failed ping alone does not prove the link is down; ICMP may be filtered or the service itself down.
Pinging a name and concluding 'no network' when it fails — test IP reachability and DNS separately.
Checking the gateway against the wrong subnet — the gateway must be inside the client's own mask.
Using ipconfig instead of ipconfig /all — DNS and DHCP details only appear with /all.

Intermittent 'no internet' on one PC

Observation: One workstation loses connectivity periodically; neighbors on the same VLAN are fine.

Hypotheses

Check	Indicates
`ipconfig /all` during an outage	APIPA or a stale lease confirms a DHCP-layer cause.
Event viewer / `ipconfig /release` + `/renew`	Renewal failure vs instant recovery splits DHCP service from cabling.
Switch interface counters for the port	Physical errors point at the drop, not at IP.

Correction: Fix the DHCP reachability/scope conflict or replace the failing drop component.

Lease renews cleanly and connectivity stays stable across several lease cycles.

On this page

Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.