Choose commands by question, not by habit
Command-line tools are useful because each exposes a different slice of network state. The skill is not memorizing a long command list. It is choosing the smallest useful test for the current hypothesis, reading the output in context, and allowing that evidence to determine the next step.
Match the command family to the dependency you are testing
Local configuration
ipconfig /all, ip addr, interface tools.
Reachability
ping for a deliberate target and defined checkpoint.
Path
tracert/traceroute for responding routed hops.
DNS
nslookup or equivalent resolver-query tools.
Socket state
netstat/ss for listeners and transport state.
Neighbors & routes
arp/ip neigh and route-table tools.
Verify the active interface before trusting a correct-looking address
A laptop can have Ethernet, Wi-Fi, VPN, cellular, and virtual adapters at the same time. The presence of one valid address does not prove traffic uses that interface. Record the active adapter, IP address, prefix, default gateway, DNS servers, and DHCP state.
If the documented design expects 10.20.30.0/24 and the client instead shows 169.254.44.9, the address itself becomes a high-value clue.
169.254.x.x usually means the normal DHCP path did not complete
On many IPv4 client networks, a 169.254.0.0/16 address indicates link-local/APIPA behavior instead of the expected DHCP lease. Do not immediately insert a random static address. Investigate link state, VLAN placement, DHCP scope/service, relay behavior, and endpoint configuration.
The target you choose determines the question ping answers
ping can test loopback/local stack behavior, a local gateway, a remote numeric IP, or a named destination. These are not interchangeable tests.
| Target | Useful question | Does not prove |
|---|---|---|
| 127.0.0.1 / ::1 | Local IP stack responds | NIC or network path |
| Default gateway | Local client-to-gateway path | Internet/DNS/application |
| Remote IP | Some routed IP path works | Name resolution |
| Hostname | Resolution + ICMP path if it succeeds | TCP/UDP app service |
Swipe horizontally to see the ping checkpoint table.
A successful gateway ping lets you move the boundary upstream
If the client can ping its gateway, the tested local IP path works well enough for that exchange. If a remote IP then fails, investigate routing, firewall/NAT, provider, or remote path. If the gateway itself fails, remote DNS is not the highest-information first branch.
Use traceroute to observe responding routed hops—not to blame the first asterisk
Traceroute-style tools manipulate TTL or hop limit so intermediate routers may return time-exceeded responses. Some devices rate-limit or filter those responses while forwarding transit traffic normally.
Hop 3 is not proven broken because later hops and the destination respond. Treat the trace as path evidence, not a standalone fault detector.
Different traceroutes can be normal when Internet routing changes
Paths can be asymmetric, load-balanced, or altered by provider routing. Compare the destination result, repeated patterns, and timing with baselines. A different path is not automatically a fault.
A sustained latency increase that begins at one point and persists through later hops is stronger evidence than one isolated slow response.
Ask the configured resolver directly and record the exact answer
With nslookup or an equivalent query tool, record which resolver answered, whether the query timed out, whether the name was reported nonexistent, or whether an unexpected address was returned.
A timeout is different from NXDOMAIN, and both are different from a wrong A/AAAA record. The output already gives you evidence about the failure class.
This pattern should move DNS much higher than routing
Local and routed IP behavior are already demonstrated. Investigate configured resolver accuracy, DNS transport reachability, resolver service state, filtering, VPN DNS behavior, and split-DNS rules.
A client cannot prove whether the server is actually listening
netstat or ss can show listeners and established connections on the server. If users cannot reach HTTPS and there is no TCP/443 listener, the first demonstrated failure is application-side.
Opening a network firewall cannot create a process that is not listening.
A running service can still be unreachable because it is bound to the wrong interface
A listener on 127.0.0.1:443 may work locally on the server but fail for remote clients. A listener on 0.0.0.0:443 or the intended server interface is a different state.
Socket output therefore helps distinguish “service stopped” from “service running but bound incorrectly.”
Use neighbor state to test the local next hop, not the remote Internet host
arp and ip neigh expose local IPv4-to-MAC or neighbor state. If a client cannot resolve the default gateway's MAC, investigate Layer 2, VLAN placement, switch forwarding, gateway state, or duplicate addressing.
A remote server across routers will not normally appear as a local ARP entry because the Ethernet frame is addressed to the next hop.
Find the winning route for the exact destination instead of assuming the default is used
Endpoint route tables can show connected routes, defaults, VPN-created prefixes, metrics, and interface choices.
The ordinary default gateway can remain present while selected traffic leaves through a more-specific VPN route.
CLI differences are powerful when two clients should share the same policy
If one client fails while another client on the same intended VLAN works, compare address, prefix, gateway, DNS, routes, active adapter, VPN state, and neighbor table.
| Artifact | Working client | Failing client |
|---|---|---|
| IPv4 | 10.20.30.40/24 | 10.20.30.25/24 |
| Gateway | 10.20.30.1 | 10.20.30.1 |
| DNS | 10.20.1.53 | 192.0.2.53 |
| VPN route | None | Present |
Swipe horizontally to see the peer comparison.
New client has no expected IPv4 configuration
Best first tool: local IP/DHCP configuration output. Next branches: VLAN placement, DHCP service/scope, relay, or client configuration. Remote application tests are premature.
Server responds to ping but SSH fails
Best next artifacts: server-side socket state and firewall logs/policy for TCP/22. Ping success proves one ICMP path, not SSH availability.
Only one remote prefix fails while general Internet access works
Best next artifact: the route table and path for that exact destination. A more-specific stale route can override the healthy default route and break only one prefix.
Gateway ping fails and no neighbor entry forms
Best branch: local VLAN, switch port, trunk carriage, gateway state, duplicate addressing, or local Layer 2 conditions. DNS is downstream of a checkpoint that has not yet been reached.
Request reaches the server but no response returns
Best next artifacts: server route table, return path, stateful firewall logs, and NAT state if relevant. The forward path is already heavily proven.
Different operating systems expose the same networking mechanisms with different commands
| Question | Windows-style | Linux-style |
|---|---|---|
| Local addressing | ipconfig /all | ip addr / ip link |
| Reachability | ping | ping |
| Path | tracert | traceroute / tracepath |
| DNS query | nslookup | nslookup / dig where available |
| Sockets | netstat | ss / netstat |
| Neighbor table | arp -a | ip neigh |
| Routes | route print | ip route |
Swipe horizontally to see the command crosswalk.
Collect state before flushing, renewing, rebooting, or resetting
Resetting adapters, flushing caches, rebooting devices, or renewing configuration can restore service while destroying the evidence that explained the symptom. When practical, capture addresses, routes, DNS settings, socket state, neighbor entries, timestamps, and the exact failing test first.
Record enough context that another technician could repeat the test
Useful CLI evidence includes the command, target, timestamp, source host/interface, expected result, relevant output, and the current symptom.
This is far stronger than simply writing “ping failed.”
Every CLI result should be followed by “what this still does not prove”
| Result | Supports | Still unproven |
|---|---|---|
| Gateway ping works | Local gateway path | Remote route/DNS/app |
| nslookup succeeds | Resolver answered query | Application service works |
| Traceroute reaches subnet | Responding routed path | Target port is open |
| ss shows listener | Service is listening locally | Firewall allows remote client |
| Route exists | Forwarding decision exists | Next hop and return path work |
Swipe horizontally to see the evidence-boundary table.
Let one command result select the next command
Timeout, refusal, unreachable, and wrong answer are different kinds of evidence
CLI output becomes much more useful when you classify the result instead of reducing every failure to “did not work.” A timeout means no usable response arrived before the tool gave up. A connection refusal means the destination stack or an intermediary actively rejected the connection. A route or host-unreachable message indicates a routing or forwarding problem was reported. A DNS query that returns the wrong address proves the resolver answered, but the returned data or DNS view may be wrong.
| Observed result | Stronger interpretation | Good next artifact |
|---|---|---|
| Timeout | No usable response returned | Path, firewall, service-state evidence |
| Connection refused | Destination/path actively rejected the connection | Listener/bind/host firewall |
| Host/network unreachable | Forwarding problem reported | Route table and next-hop state |
| DNS wrong IP | Resolver answered with unexpected data | Direct query, cache, zone/view |
Swipe horizontally to see the result taxonomy.
Query two resolvers from the same client to isolate resolver selection from DNS data
If a client uses a suspicious resolver, test the same hostname against the currently configured resolver and the intended resolver without changing anything else. This is a controlled one-variable comparison.
This evidence is stronger than simply replacing DNS settings and seeing whether the problem disappears, because it directly demonstrates which resolver path can answer the same query.
Use the destination address to explain why the route table matters
The correct interpretation is not “there is a default route, so the packet uses it.” The more-specific /24 wins. If that next hop is stale or unreachable, one destination range can fail while general Internet access remains normal. This is why route-table output should always be interpreted against the exact destination being tested.
Escalate to deeper evidence only when command output leaves a specific ambiguity
Suppose the client has correct addressing, reaches the gateway, resolves the server name, and the route table selects the expected path. TCP/443 still times out. At that point, repeating ipconfig and ping adds little new information. A firewall log, server-side socket check, or packet capture is more useful because the unresolved boundary is now transport or policy.
The purpose of CLI tools is therefore not to solve every incident by themselves. Their value is that they move the evidence boundary far enough that the next artifact can be chosen intelligently.
Turn raw command output into a defensible diagnostic sentence
A weak answer says, “Run ping.” A stronger answer says, “Ping the configured gateway because this tests the client-to-gateway IP path. If the gateway responds, the local path is proven enough to move upstream; if it fails and the gateway neighbor entry never resolves, investigate the local VLAN, switching path, or gateway state.”
The difference is not more jargon. It is explicit linkage between the command, the dependency, the possible outputs, and the next action. That is the level of reasoning that makes command-line evidence useful on unfamiliar networks.
24 AP Networking CLI Tools digital flashcards
Practice ipconfig/ip, ping, traceroute, nslookup, netstat/ss, arp/ip neigh, route tools, APIPA, evidence boundaries, known-good comparisons, and command selection.