CLI skill is not remembering commands—it is knowing which uncertainty each command can reduce
A command becomes useful when you can explain why its output changes the diagnosis. The strongest workflow is: identify the unresolved question, predict what evidence would separate the leading causes, run the narrowest useful command, then state both what the result supports and what remains unproven.
A command output and a packet trace can disagree because they describe different times or interfaces. The AP Networking Packet Capture Analysis Practice Test tests that context explicitly: identify collection limits, correlate rewritten or proxied flows, and state what an analyzer label actually supports before choosing a repair.
After working through the guided artifacts here, use the AP Networking CLI Command Output Troubleshooting Practice Test to test whether you can select the next observation without the lesson heading as a cue. All 75 items include a bounded interpretation and an explanation of the relevant missing dependency.
This page deliberately includes outputs that look reassuring but do not prove the application works. That is where command interpretation becomes troubleshooting rather than memorization.
APIPA is not “the Internet is down”—it moves the failure boundary toward address configuration
Ethernet adapter Ethernet: IPv4 Address. . . . . . . . . . : 169.254.72.19 Subnet Mask . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . :
The decisive evidence is the 169.254/16 link-local address plus the missing gateway. In a scenario where the client is expected to receive a normal routed lease, this strongly supports a DHCP/configuration branch. It does not identify the exact cause. The DHCP server could be unreachable, the client could be in the wrong VLAN, a relay could be missing, a scope could be exhausted, or client state could be wrong.
Low-value next move: querying a public hostname. The client does not yet show the expected Layer 3 prerequisites. Higher-value evidence: compare a working peer's subnet/VLAN, inspect DHCP state, or trace the DHCP path. Continue with Cannot Get a DHCP Address.
A valid private address can still contain an impossible gateway relationship
IPv4 Address : 10.20.8.70 Subnet Mask : 255.255.255.192 Gateway : 10.20.8.1
A /26 creates blocks of 64 addresses. 10.20.8.70 belongs to 10.20.8.64/26, with ordinary host addresses .65 through .126. The listed gateway, 10.20.8.1, is outside that local subnet. The important skill is not merely recognizing “private IP.” It is checking whether the fields agree with each other.
This output does not tell you whether the address, mask, or gateway is the incorrect field. Compare the intended subnet plan or a known-good host before changing anything. That distinction prevents a technically possible calculation from becoming an unsupported configuration guess.
Reading command output accurately requires more than recognizing fields and values. Students must also resist conclusions the command never established. A ping reply, ARP entry, route, DNS response, interface counter, or listening port each has a different evidence ceiling. Use Network Evidence That Looks Like a Problem but Isn't alongside these CLI exercises to practice distinguishing the literal observation from the larger diagnosis.
Gateway success plus remote numeric-IP success moves the boundary beyond basic local routing
> ping 10.30.4.1 Reply from 10.30.4.1: time=1ms TTL=64 > ping 203.0.113.20 Reply from 203.0.113.20: time=24ms TTL=51 > nslookup portal.example DNS request timed out. Server: 10.30.2.53
The first ping supports local next-hop reachability for ICMP. The second supports routed numeric-IP reachability to that tested remote target. The DNS query then fails to receive a response from the configured resolver. Together, these results make a DNS-specific branch far more informative than restarting the network adapter.
Do not overstate the result as “the DNS server is down.” A timeout can reflect resolver service, reachability, filtering, or another DNS-path issue. A strong next comparison is querying the intended resolver directly and comparing the same query from a working client.
Correct name resolution does not test the service that uses the returned address
> nslookup app.campus.example Name: app.campus.example Address: 10.60.20.15 > ping 10.60.20.15 Reply from 10.60.20.15: time=2ms TTL=62
The lookup returned an address and ICMP received a reply from that address. Neither command tests TCP/443. If the complaint is “HTTPS does not open,” repeating DNS or ping adds little. Test the transport/service boundary, inspect firewall evidence, or verify the server's listener.
This case demonstrates why a successful command is not automatically a successful application. Each protocol has an evidence boundary.
netstat can move an HTTPS failure from the network path to the server itself
C:\> netstat -ano | findstr :443 C:\> netstat -ano | findstr :80 TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4180
No matching TCP/443 listener appears, while TCP/80 is listening. If the requirement is HTTPS on 443, verify the local web service, TLS binding, and expected listening address before modifying a transit firewall.
The absence is still contextual evidence: command filters, permissions, platform behavior, or a service bound differently can matter. But this output gives a much stronger local hypothesis than “maybe the router blocks HTTPS.”
A changing IP-to-MAC mapping is a clue, not an automatic duplicate-IP verdict
Interface: 10.44.8.25 Internet Address Physical Address 10.44.8.1 00-11-22-33-44-55 [several minutes later] 10.44.8.1 aa-bb-cc-dd-ee-ff
The same gateway IPv4 address is associated with two different MAC addresses at different times. That is worth investigating, especially if failures correlate with the change. But redundant gateway designs can legitimately present changing or virtual MAC behavior.
Before declaring a duplicate IP, determine the intended gateway architecture and use switch MAC-location evidence to identify where each address is learned. Time correlation matters: an ARP cache snapshot without timestamps can mislead.
Asterisks in the middle of a completed path are evidence about replies, not proof of failed forwarding
1 1 ms 1 ms 1 ms 10.10.0.1 2 4 ms 4 ms 5 ms 198.51.100.1 3 * * * Request timed out. 4 18 ms 17 ms 18 ms 203.0.113.9 5 21 ms 20 ms 21 ms 203.0.113.25
Later hops and the destination answered, so probes progressed beyond hop 3. Hop 3 may suppress, filter, or rate-limit the diagnostic response while continuing to forward traffic. “Hop 3 is broken” contradicts the later evidence.
Use Traceroute Explained to connect TTL/Hop Limit behavior to what the output can and cannot prove.
A timeout is weaker evidence than many students think
> ping 10.70.5.20 Request timed out. Request timed out. Request timed out. Request timed out.
This proves the client did not receive the expected ICMP echo replies during the test. It does not distinguish target-down, ICMP filtering, forward-path failure, return-path failure, or a local configuration problem.
Make the next test comparative. Can the client ping its gateway? Can a working peer ping 10.70.5.20? Does the target's local state show it is online? Does a route lookup predict a valid path? One timeout creates branches; a discriminating comparison removes them.
Timeout, NXDOMAIN, and wrong-answer responses lead to different investigations
| Observed result | What happened | Useful next question |
|---|---|---|
| Timeout | No timely DNS response was received | Can this resolver/path answer queries? |
| NXDOMAIN | A DNS response says the queried name does not exist in that context | Is the name correct and should this resolver know it? |
| Unexpected address | Resolution worked but produced a different value than expected | Which record/source/cache supplied the answer? |
| Expected address | Name-to-address resolution succeeded for the query | Does the required transport/application work? |
Swipe horizontally to see the full table.
These outputs should not all trigger “flush DNS.” The result type itself tells you which uncertainty remains.
Not seeing a remote server's MAC address can be exactly what routed networking predicts
A client normally uses ARP to resolve IPv4 neighbors on its local link. When sending to a remote subnet, it needs the MAC address of its local next hop—not the MAC address of a server several routers away.
Therefore, “the Internet server is missing from arp -a” is not evidence that ARP failed. The more relevant question is whether the expected local gateway mapping exists and whether that mapping is stable and plausible.
A working default route can coexist with a broken destination-specific route
0.0.0.0/0 via 192.0.2.1 10.90.30.0/24 via 192.0.2.99 203.0.113.8 reachable 10.90.30.25 unreachable
The Internet control can use the default. The failed 10.90.30.25 destination matches the /24 and is therefore captured by the more-specific route. Testing only the default misses the route that actually controls the failed destination.
This is where CLI practice crosses into artifact analysis: the command output must be interpreted according to routing logic, not just read line by line. Practice that skill in Routing Table Analysis Practice.
When two commands disagree with your first hypothesis, trust the evidence chain over the story
ipconfig: IPv4 Address : 10.40.8.25 Gateway : 10.40.8.1 DNS Servers : 10.40.2.53 ping 10.40.8.1: Reply ... time=1ms nslookup intranet.example: Server: 10.40.2.53 Address: 10.40.2.53 Name: intranet.example Address: 10.80.4.20
If the complaint is “the intranet page does not load,” these outputs weaken two early hypotheses: local gateway failure and basic name-resolution failure. The next test should move toward 10.80.4.20 reachability, TCP service state, or policy. Continuing to renew DHCP ignores evidence already collected.
Cross-artifact reasoning is powerful because one command can establish a control while another isolates the next boundary.
Choose the command that directly exposes the unresolved variable
| Unresolved question | High-value command/artifact | Strong evidence | Do not overclaim |
|---|---|---|---|
| What IP/mask/gateway/DNS is configured? | ipconfig /all or platform equivalent | Host configuration state | That configured services are reachable |
| Can this target return ICMP? | ping | Reply/latency for tested probes | That all ports/apps work |
| What does this resolver answer? | nslookup | Resolver/query response | That HTTPS works |
| Which hops return path diagnostics? | tracert/traceroute | Responding-hop sequence | That every silent hop is broken |
| What local IPv4 neighbor mappings exist? | arp -a | Neighbor cache state | Remote routed host MACs |
| Is the local service listening? | netstat or platform socket tool | Local socket/listener state | Remote end-to-end reachability |
Swipe horizontally to see the full matrix.
Capture before reset: repair commands can erase the state that explains the failure
Renewing DHCP, flushing DNS, clearing ARP, restarting an interface, or rebooting can change multiple variables at once. Those actions may restore service, but they can also destroy the original lease, resolver, neighbor, socket, or timing evidence.
When practical, record the failing state first. Then make the smallest justified change and capture the after-state. The delta can show mechanism: for example, an APIPA address becomes a valid lease after a VLAN/relay correction, or a missing 443 listener appears after the service binding is fixed.
24 CLI evidence flashcards: command output, boundaries, and next-test reasoning
These cards are built around decisions rather than command definitions. Say what the output proves before revealing the answer, then name one competing explanation that remains possible.
The same command can tell a different story when timestamps and change order are preserved
Imagine a user reports intermittent access. An ARP mapping changes at 10:02, gateway ping loss begins at 10:02, and a switch event records a port move at the same time. That correlation is much more useful than three screenshots collected hours apart.
For intermittent failures, preserve timestamps, repeated samples, and known changes. A single successful ping after recovery cannot erase evidence of a prior failure; it describes a different moment.
Compare failing output with a working peer when the environment should be equivalent
A working peer can reveal whether the failing host's subnet mask, gateway, DNS resolver, DHCP server, VLAN-derived lease, or route behavior differs. The comparison is strongest when the two systems are expected to share those settings.
Do not copy a peer's values blindly. First decide which fields should match and which should be unique. Two clients should not normally share the same host IP, while they may legitimately share gateway and DNS addresses.
End the CLI chain by retesting the original requirement, not merely the last command
If the original problem was HTTPS access, a successful ping after repair is incomplete verification. Retest HTTPS. If the problem was DHCP, confirm a valid lease, gateway/DNS values, renewal behavior, and the required network access. If the problem was a missing listener, confirm the service listens and a permitted remote client can connect.
Also preserve a negative or control test when security is involved. A firewall repair should restore authorized traffic without unintentionally allowing traffic that is supposed to remain blocked.
Write conclusions in three layers: observation, bounded inference, discriminating next test
Observation: “nslookup to 10.30.2.53 timed out while a remote numeric IP replied.” Bounded inference: “Basic routed numeric-IP reachability works for the tested target, while DNS resolution through the configured resolver remains unresolved.” Next test: “Query that resolver directly from a known-good peer or compare another intended resolver.”
This structure is stronger than “DNS is broken” because it shows exactly how the evidence changed the hypothesis set.