Command selection begins with a question the current evidence has not answered
The source page has the right foundation: use ipconfig for host configuration, ping for a selected IP-layer checkpoint, tracert/traceroute for visible routed path evidence, nslookup for DNS answers, arp for local IPv4-to-MAC mappings, netstat for local sockets, and route-table tools for forwarding selection. The deeper skill is deciding when each output would actually reduce uncertainty.
Put tool selection into a scored diagnostic with the AP Networking CLI Command Output Troubleshooting Practice Test. Its levels progress from choosing an address or route command to interpreting multi-interface paths, mismatched capture points, and failures after successful name resolution.
A fixed script such as “ipconfig, then ping, then traceroute” can waste time when the prompt has already supplied some of those facts. If the scenario explicitly shows a valid address, correct gateway, successful gateway reachability, and successful remote numeric-IP reachability, repeating those checks adds little. If hostname access alone fails, a DNS query has much greater information value.
Match the command to the evidence boundary—not to the symptom label
| Unanswered question | Strong first artifact | What it can establish | What it cannot establish alone |
|---|---|---|---|
| What configuration does this Windows host have? | ipconfig /all | Address, mask, gateway, DNS, DHCP/lease state | That the configured gateway or DNS server is reachable |
| Does this selected IP return ICMP Echo Replies? | ping | Reachability/RTT evidence for that ICMP test | That TCP/UDP services or DNS work |
| Which routed points visibly respond toward a destination? | tracert / traceroute | Visible path progression and changes | That every silent hop is broken |
| What answer does a DNS resolver return? | nslookup | Resolver response, address answer, timeout/NXDOMAIN clues | That the returned service is reachable |
| Which MAC is associated with a local IPv4 neighbor? | arp -a | Local neighbor mapping evidence | Remote server MAC across a router or switch-port location |
| Is this local host listening or holding a TCP state? | netstat | Local socket/listener/connection-state evidence | End-to-end firewall or routing health |
| Which forwarding entry matches a destination? | Route table / route command | Selected matching route and next-hop/interface logic | Next-hop reachability or return-path success |
Swipe horizontally to see the full table.
Use ipconfig when the endpoint's own Layer 3 state is still unknown
ipconfig /all is high-value when the symptom could be explained by the client's assigned address, subnet mask, gateway, DNS server, DHCP state, or lease information. It is especially useful before testing remote dependencies when the endpoint configuration itself has not been established.
This output supports a bounded conclusion: a DHCP-dependent endpoint does not have its expected normal IPv4 configuration. It does not tell you whether the root cause is a DHCP server, exhausted scope, VLAN placement, relay path, link transition, or some other DHCP-path problem. The next test should distinguish those possibilities.
Compare with DHCP scope exhaustion when the evidence suggests configuration delivery rather than general Internet failure.
Use ping as a deliberately placed checkpoint, not as a universal health test
A ping target should answer a specific question. Pinging the gateway tests a local Layer 3 checkpoint. Pinging a remote numeric IP tests farther upstream without depending on hostname resolution. Pinging a hostname can add a name-resolution dependency before the ICMP exchange even begins.
Failure is also bounded. ICMP can be filtered, so “no echo reply” is not synonymous with “host down.” If the real requirement is HTTPS, targeted TCP/service evidence may be more meaningful than insisting that ICMP succeed.
Use tracert or traceroute after local forwarding is plausible and the path itself is the question
Path discovery is useful when you need to observe which routed points return responses toward a remote destination. It can expose a changed visible path, a consistent stopping region, or a divergence between a working and failing destination. But it should not replace basic local configuration analysis.
Hop 3's asterisks do not prove that router is dead because later hops respond. A device may forward traffic while not returning the expected probe response. This is a classic evidence-boundary trap: path visibility and packet forwarding are related but not identical.
Use nslookup when the resolver's answer is the unresolved dependency
A browser combines too many dependencies to be precise DNS evidence. nslookup lets you ask the resolver directly and distinguish an answer from timeout, NXDOMAIN, or an unexpected record.
If 10.80.5.10 is the expected address, the tested resolution step succeeded. If TCP 443 still fails, do not keep editing DNS. Move toward route/policy/listener/service evidence. Conversely, if a numeric IP works but the DNS query times out, the name-resolution branch becomes much stronger.
This distinction is central to DNS troubleshooting: a correct DNS answer is evidence about naming, not proof of the application behind the returned address.
Use arp for local IPv4 neighbor ownership—not for remote switch-port discovery
arp -a shows local IPv4-to-MAC neighbor mappings known to the host. For a remote IP destination, the client normally frames the packet toward its local next hop, so the ARP entry of interest is the gateway rather than the remote server's MAC address.
To find where a MAC was recently learned in the switched network, combine neighbor information with a switch MAC table. ARP answers “which local IPv4 neighbor maps to which MAC?” while the switch table answers “where was this source MAC recently learned in this VLAN?”
Use netstat when the unresolved question is local listener or connection state
If a server is supposed to accept TCP/443, checking whether it is actually listening can prevent an unnecessary firewall change. A missing listener is a local service-state problem until evidence shows otherwise. If the listener exists, the investigation can move outward to binding scope, host policy, transit policy, routing, and client-side evidence.
A listener on 0.0.0.0:443 is useful local evidence that the service is bound broadly on IPv4. It does not prove every remote client can reach it. An ESTABLISHED entry proves more about that particular connection, but still should not be generalized to every source or policy path.
See the netstat command guide for deeper state and endpoint interpretation.
Use route-table evidence when the forwarding decision is the unknown
Route-table analysis starts by matching the destination against candidate prefixes and choosing the longest matching prefix. Then inspect the selected next hop or interface. This answers the forwarding-choice question; it does not complete the end-to-end diagnosis.
If 172.16.3.1 cannot be reached on the expected local segment, the route's presence does not rescue forwarding. Likewise, a reachable next hop does not prove downstream return routing or service policy.
Let each successful result move the failure boundary forward
| Evidence already supplied | Lower-value repetition | Higher-information next question |
|---|---|---|
| Valid configuration is shown | Run ipconfig again | Can the required local/remote checkpoint be reached? |
| Gateway responds | Ping gateway repeatedly | Does remote numeric-IP forwarding work? |
| Remote numeric IP works | Reset adapter | Does DNS return the expected answer? |
| DNS answer is correct | Change DNS servers | Is required TCP/UDP service reachable/listening? |
| Server listener exists | Restart service blindly | Does host/transit policy permit the exact flow? |
| Matching route exists | Declare routing healthy | Is selected next hop reachable and return path viable? |
Swipe horizontally to see the full table.
The same symptom can demand a different command when the prior evidence changes
Case A: “Website fails”
No IP configuration is supplied. Start by establishing endpoint state; ipconfig /all may have more value than remote path discovery.
Case B: “Website fails”
Valid configuration, gateway success, and remote numeric-IP success are supplied, but hostname access fails. nslookup now has much higher information gain.
Case C: “Website fails”
DNS resolves correctly and the server route is reachable, but TCP/443 times out. Listener/socket and policy evidence become more valuable.
Case D: “Website fails”
One client has an established TCP/443 connection while another source subnet times out. Source-specific policy/path evidence becomes more interesting than server restart.
The symptom label did not change. The evidence state did. This is why memorizing “which command goes with which symptom” is weaker than learning which command answers which technical question.
Seven common command-selection mistakes and the evidence boundary behind each
| Mistake | Why it is weak | Better reasoning |
|---|---|---|
| Ping everything first | May ignore unknown local configuration | Establish the earliest unresolved dependency |
| Traceroute one hop before gateway | Local forwarding may already be broken | Resolve endpoint/gateway state first |
| Use browser failure as DNS proof | Browser depends on many layers | Query DNS directly |
| Use ARP to find remote server MAC | Router is the local Layer 2 next hop | Inspect local gateway mapping |
| Use netstat as end-to-end proof | It is local socket evidence | Combine with path/policy evidence |
| Treat route entry as delivery proof | Selection is not successful forwarding | Test next-hop/path/return evidence |
| Repeat a successful checkpoint | Adds little information | Move to the next unresolved boundary |
Swipe horizontally to see the full table.
Choose commands as a sequence of shrinking uncertainty
Each artifact removes a branch. Configuration is plausible. The gateway responds. The remote server IP responds. DNS returns the expected address. The server is listening. The firewall then supplies direct evidence that the required source-to-destination TCP/443 flow is denied. Running traceroute at this point may be interesting, but it is not the highest-information next step because the policy artifact already explains the required service failure.
After a narrowly scoped policy correction, verify HTTPS from the authorized source and confirm prohibited source scopes remain blocked.
Command spelling can change; the networking question should not
Windows commonly uses ipconfig and tracert; other operating systems may expose configuration and path information with different utilities. The durable exam skill is the evidence category: host configuration, selected reachability checkpoint, visible routed path, resolver answer, neighbor mapping, local socket state, or route selection.
This prevents command-name memorization from replacing understanding. If a prompt gives you output from an unfamiliar utility but the fields clearly show address, prefix, gateway, and DNS state, interpret the artifact by what it contains. Likewise, a routing artifact should be analyzed by prefix matching and next-hop logic even if the exact display syntax differs.
The command that finds the problem is not automatically the command that proves the repair
Verification must match the original requirement. If nslookup helped identify a DNS problem but the original requirement was opening a secure web application, a corrected DNS answer is only an intermediate checkpoint. Finish by verifying the application. If netstat exposed a missing listener, restore it and then test the intended remote client path. If a route-table correction was made, verify the actual remote communication and relevant return behavior.
Explain why the command is appropriate before interpreting its output
A concise response can follow: Question → Command → Decisive field/result → Bounded inference → Next evidence. Example: “The unresolved question is whether the hostname resolves correctly, so use nslookup. If it returns the expected server address, the tested DNS lookup succeeded; that does not prove TCP/443 works. Next inspect the required service connection or listener/policy evidence.”
This structure turns a command-name answer into technical reasoning and makes it much harder to overclaim from one output.
Some questions are answered best by combining two artifacts rather than demanding too much from one
A single command often establishes only one boundary. Pairing artifacts can connect layers without overclaiming. For example, arp -a can identify the MAC associated with a local gateway IP, while the switch MAC table can show where that MAC was recently learned. nslookup can establish the resolver's answer, while netstat or a targeted service test can address whether the expected transport endpoint exists. A route table can identify the selected next hop, while a neighbor or reachability artifact can test whether that next hop is usable.
| First artifact | What it establishes | Useful second artifact | Why the pair is stronger |
|---|---|---|---|
arp -a | Local IP-to-MAC association | Switch MAC table | Connects neighbor identity to recent Layer 2 location |
nslookup | Resolver answer | Socket/service evidence | Separates naming success from service availability |
| Route table | Selected forwarding entry | Next-hop reachability/neighbor evidence | Separates route selection from route usability |
netstat | Local listener/connection state | Firewall log | Separates service state from transit policy |
ping | Selected ICMP checkpoint | traceroute | Adds visible routed-path evidence when path is still unresolved |
Swipe horizontally to see the full table.
A good troubleshooter often runs fewer commands because each command has a reason
Command count is not a measure of diagnostic quality. Running seven utilities and collecting seven screens of output can produce less useful information than two well-chosen commands. Before pressing Enter, finish this sentence: “I am running this because I still do not know whether _____.” If the blank cannot be filled with a precise technical question, the command may be premature.
After the output arrives, finish two more sentences: “This result supports _____” and “This result does not yet prove _____.” That simple discipline turns command-line practice into evidence interpretation. It also makes it easier to choose the next test because the remaining unknown is explicit rather than hidden inside a pile of output.
nslookup because I do not know whether the configured resolver returns the expected IP for the application name. The expected answer supports successful tested name resolution. It does not prove TCP/443 is permitted or listening. The next evidence should address the required service path.”Snapshot commands become stronger when you know when the symptom occurred
Many command outputs are snapshots. An ARP entry may be stale. A TCP state can change in seconds. A route may have changed after a failure. A successful ping now may not describe the outage five minutes earlier. When the problem is intermittent, record timestamps and compare the command output with the actual failure window.
This is especially important when interpreting connection states and neighbor mappings. Repeated observations can reveal a pattern that one snapshot hides: an IP alternating between MAC addresses, a TCP connection repeatedly stalling in the same state, or a path changing during a specific event. The command is the same, but time correlation increases the information value of its output.
24 command-selection flashcards built around evidence, not memorization
Filter the deck by command or reasoning category. The questions deliberately ask what an output proves, what it does not prove, and which command has the greatest information gain next.