Choose the troubleshooting tool from the unresolved question
The best troubleshooting tool changes as evidence moves the failure boundary. If a port has no carrier, physical evidence is highest value. If the switch learns the endpoint in the wrong VLAN, Layer 2 artifacts matter more. If the gateway and a remote numeric IP work but the hostname fails, DNS tools become the best next step. The goal is not to memorize one command per OSI layer. The goal is to select the artifact that most directly answers the next unresolved question.
Connect each tool result to its real scope with AP Networking OSI and Encapsulation Practice Test. A link indicator, ARP reply, ping, TCP response and application result establish different observations; packet and capture questions also show why a warning or device layer label is not a complete diagnosis.
Match the question to the highest-information artifact
| Question | Best tool/artifact | What it can prove |
|---|---|---|
| Is the link physically alive? | Interface state, cable test, transceiver/NIC status | Carrier/media evidence |
| Where is this MAC learned? | Switch MAC table | Port/VLAN learning location |
| Which MAC owns this local IP? | ARP/neighbor table | Local IP-to-MAC mapping |
| What IP/prefix/gateway is configured? | ipconfig / ifconfig / ip addr | Local Layer 3 configuration |
| Which route wins? | Route table | Forwarding selection |
| Does the tested IP answer ICMP? | ping | That IP/ICMP exchange |
| What hops respond? | traceroute / tracert | Hop-oriented path observations |
| Is the service listening? | netstat / ss | Local socket/listener state |
| Does the name resolve? | nslookup / dig | DNS response behavior |
| Which firewall rule matched? | Logs and counters | Policy decision for that flow |
Swipe horizontally to see the tool selector.
Link status and physical tests answer a physical question
Use interface state, link LEDs, cable testing, optics/transceiver status, NIC state, power, signal quality, and physical error counters when the unresolved question is whether frames can traverse the medium at all.
MAC tables, VLAN state, trunks, and STP answer local-forwarding questions
A switch MAC table tells you where source traffic from a MAC was observed. Combine it with VLAN membership, trunk status, spanning-tree state, and tagging evidence.
The switch is receiving frames, so physical attachment is already substantially proven. The failure boundary is logical Layer 2 placement.
ARP answers a different question from the MAC table
ARP maps a local IPv4 neighbor to a MAC address. The MAC table maps that MAC to a switch port and VLAN. Used together, those two artifacts can turn a vague duplicate-IP symptom into a physical location.
ARP first, switch MAC table second
ARP identifies competing identities. The switch table locates them. Repeating ping would be lower information than following those two artifacts.
IP configuration, route tables, ping, and traceroute answer different questions
ipconfig / ip addr
What address, prefix, gateway, and interface state does the host have?
Route table
Which prefix and next hop will be selected?
Ping
Does the tested IP/ICMP exchange succeed?
Traceroute
Which hops respond along the path?
ARP/neighbor
Can the local next hop be resolved?
Known-good peer
Does a similar endpoint sharing the path behave differently?
Ping is a checkpoint, not a universal truth detector
A successful ping proves the tested IP/ICMP exchange worked. It does not prove DNS, TCP/443, SSH, TLS, or the application. A failed ping is also ambiguous because ICMP can be filtered while the application path still works.
A silent hop is not automatically the failed hop
Traceroute depends on devices returning TTL or hop-limit related responses. An intermediate device can forward traffic without replying. If later hops respond, the silent hop did not stop the entire path.
Use transport tests when IP reachability is already proven
Move from Layer 3 tools to a direct transport test, firewall logs/counters, and server listener state. A service cannot accept a connection on a port where nothing is listening.
netstat and ss can end the firewall debate quickly
If the firewall allows TCP/443 but the server shows no listener, opening more firewall ports cannot create the application. If the listener exists, then policy, route, return path, or application state remain plausible.
Use nslookup/dig for DNS and application-aware clients for applications
Use DNS tools for a DNS question. Use an HTTP-aware client for HTTP and an SSH client for SSH. Once DNS returns the expected address, repeating name-resolution tests has little value if the application still fails.
No link light: stay at the physical boundary
Best tools: interface state, cable/physical testing, endpoint NIC, switch port, and transceiver status. A route table contributes little until the link exists.
Link works, but the client has APIPA
Physical attachment is no longer the first problem. Inspect local IP configuration plus DHCP, VLAN, relay, and scope evidence.
Gateway and remote numeric IP work, hostname fails
DNS is now the specific unresolved dependency.
DNS resolves, but TCP/443 fails
Move beyond DNS. Use a transport test, firewall logs/counters, and server-side listener evidence.
Firewall allows 443, but ss shows no listener
The server-side tool directly reveals the missing endpoint. Opening another firewall rule is not supported by the evidence.
The best tool changes as the failure boundary moves
Use a comparison that shares almost the same path
A strong control changes one meaningful factor. Compare a second endpoint on the same VLAN, another VLAN across the same trunk, a wired client behind the same gateway, or another service on the same server. The closer the control is to the failed path, the more it isolates the suspected dependency.
Pick a test that could prove your first idea wrong
If you suspect a cable, a known-good cable should change the result. If you suspect DNS, an expected resolver answer should weaken that hypothesis. If you suspect the firewall, an ALLOW log plus a server request log should move the boundary elsewhere.
What each tool proves—and what it cannot prove
| Tool | What it proves | What it does not prove |
|---|---|---|
| Link state | Carrier/interface state | VLAN/IP/application health |
| MAC table | MAC learning location | Remote route or service health |
| ARP | Local IP-to-MAC mapping | Remote routing |
| ipconfig/ip addr | Local configuration | Gateway/service reachability |
| ping | Tested IP/ICMP exchange | TCP/UDP application health |
| traceroute | Hop responses | Guaranteed failure at a silent hop |
| nslookup/dig | DNS response behavior | Application availability |
| netstat/ss | Local listener state | Remote firewall path |
| Firewall log | Policy action for a flow | End-to-end application success |
Swipe horizontally to see the evidence matrix.
Choose the next tool instead of running everything
The firewall log is now the highest-value artifact because earlier tests already established physical attachment, local addressing, gateway reachability, and name resolution.
Strong answers explain why this tool is better than the alternatives
Instead of writing “use ping,” write: “Use `nslookup` because the client already reaches the gateway and a remote numeric IP, so basic routed IP connectivity is substantially proven while name resolution is the unresolved dependency.”
24 OSI Troubleshooting Tool digital flashcards
Practice physical checks, MAC tables, ARP, IP configuration, routing, ping, traceroute, listeners, DNS tools, firewall logs, controls, falsifiers, and evidence boundaries.