Network CLI Output Clues Database: ipconfig, ping, nslookup, ARP, netstat, and Traceroute

Fast symptom-to-evidence table

Use the table to choose the next artifact, not to skip diagnosis. Scroll horizontally on smaller screens.

Command-selection rule

Choose a command because of the unanswered question: ipconfig for local addressing, ping for a specific IP reachability control, nslookup for DNS resolution, ARP for local IPv4-to-MAC mapping, netstat for local sockets/listeners, and traceroute for hop-oriented path observations. Then state what the output cannot prove before selecting the next command.

ipconfig shows 169.254.x.x

Primary interpretation: Expected DHCP configuration missing. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Check DHCP/VLAN/path. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Does not prove DHCP server is powered off. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

ipconfig gateway outside configured subnet

Primary interpretation: Addressing inconsistency. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Recalculate subnet and compare peer. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Gateway normally must be locally reachable. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

ping gateway succeeds

Primary interpretation: Local IP path to gateway responds. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Test remote IP next. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Does not prove DNS or web service. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

ping hostname fails, numeric IP works

Primary interpretation: Name resolution candidate. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: nslookup configured resolver. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Ping may also be filtered, so preserve numeric control. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

nslookup returns NXDOMAIN

Primary interpretation: Resolver responded that name does not exist. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Verify name/zone/record. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Different from timeout. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

nslookup returns expected IP

Primary interpretation: DNS resolution succeeded for that query. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Test transport/application. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Does not prove server listens. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

ARP shows one IP changing MACs

Primary interpretation: Duplicate IP candidate. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Trace both MACs. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Cache snapshots need timeline. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

netstat shows no expected listener

Primary interpretation: Local service not listening/bound as expected. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Check service/config. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Remote firewall may be irrelevant if nothing listens. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

traceroute one hop asterisk, later hops answer

Primary interpretation: Intermediate probe response suppressed. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Do not blame silent hop. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Transit forwarding clearly continues. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

traceroute stops and destination fails

Primary interpretation: Path boundary candidate. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.

Evidence to collect: Compare controls/logs/routes. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.

Important limit: Return path/filtering can complicate interpretation. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.

Turn three database records into a troubleshooting sequence

Step 1: Observe ipconfig shows 169.254.x.x. Before naming a cause, write the supported boundary: Expected DHCP configuration missing. Collect Check DHCP/VLAN/path. Then explicitly respect this constraint: Does not prove DHCP server is powered off.

Step 2: Observe ipconfig gateway outside configured subnet. Before naming a cause, write the supported boundary: Addressing inconsistency. Collect Recalculate subnet and compare peer. Then explicitly respect this constraint: Gateway normally must be locally reachable.

Step 3: Observe ping gateway succeeds. Before naming a cause, write the supported boundary: Local IP path to gateway responds. Collect Test remote IP next. Then explicitly respect this constraint: Does not prove DNS or web service.

In the Network CLI Output Clues Database context, treat this observation as evidence that must be tested against the page's specific failure boundary. Record the observed value and expected value, compare a known-good control, and choose the next artifact that can disprove the leading hypothesis. After any correction, repeat the original failed operation and confirm the related network requirement still behaves as designed.

How to study this database for AP Networking

In the Network CLI Output Clues Database context, treat this observation as evidence that must be tested against the page's specific failure boundary. Record the observed value and expected value, compare a known-good control, and choose the next artifact that can disprove the leading hypothesis. After any correction, repeat the original failed operation and confirm the related network requirement still behaves as designed.

In the Network CLI Output Clues Database context, treat this observation as evidence that must be tested against the page's specific failure boundary. Record the observed value and expected value, compare a known-good control, and choose the next artifact that can disprove the leading hypothesis. After any correction, repeat the original failed operation and confirm the related network requirement still behaves as designed.

Advanced interpretation notes

Practice command chains rather than isolated commands. If ipconfig shows a valid expected address and gateway, ping the gateway to test that checkpoint. If it succeeds, ping a stable remote IP. If remote IP succeeds but a hostname fails, use nslookup. If nslookup returns the correct server address but the service fails, inspect the transport/listener with appropriate tools such as netstat on the server and firewall logs. If an IP appears to reach the wrong device, inspect ARP and then trace the MAC through switch tables. Each command should be selected because the previous output created a specific unanswered question.

Evidence drill: observe “nslookup returns NXDOMAIN.” The first boundary to evaluate is Resolver responded that name does not exist. Inspect Verify name/zone/record. The critical reasoning constraint is: Different from timeout. Write one alternative explanation and identify a control test that would distinguish it before making a configuration change.

Verification drill: begin from “netstat shows no expected listener.” After correcting the supported mechanism (Local service not listening/bound as expected), repeat the original failed operation, capture Check service/config, and confirm the result no longer matches the failure signature. Also preserve this caution during validation: Remote firewall may be irrelevant if nothing listens.

Reason through: traceroute stops and destination fails

Start with the observed clue “traceroute stops and destination fails.” Its strongest initial boundary is Path boundary candidate. Collect Compare controls/logs/routes before changing configuration. The interpretation must preserve this limitation: Return path/filtering can complicate interpretation. Now compare a known-good control that shares the same upstream dependencies. Record the exact values, timestamps, and expected state. If the control succeeds, narrow toward the components unique to the failed path. If it fails in the same way, widen scope to the shared dependency. After a supported correction, repeat the original test and the control, then verify that required access works and intended security or segmentation remains intact.

For the Network CLI Output Clues Database reference, the goal is not to memorize a cause beside a symptom. The goal is to select evidence that can falsify the current hypothesis. Explain what result would make Path boundary candidate less likely, and where you would move next in the packet or service dependency chain. That explicit alternative is what separates evidence-based troubleshooting from confirmation bias.

Related evidence resources

Artifact Analysis · Troubleshooting Guide · CLI Tools · Troubleshooting Steps · Evidence Decision Lab