Network Troubleshooting: The Complete Guide

1. The one method that solves everything: isolate the layer
2. Layer 1–2: is the physical path real?
3. Layer 3: the ping ladder
4. Tracing the path: where does it die?
5. Layer 4–7: ports, ACLs, and "it's up but I can't reach it"
6. Protocol-specific playbooks
7. The show commands every engineer runs first
8. Mindset: the rules that separate seniors from juniors

The one method that solves everything: isolate the layer

Every network problem lives at one OSI layer. The fastest engineers don't guess — they bisect: test a layer, and its result tells them whether the fault is above or below. Two schools work; pick one and be consistent:

• Bottom-up (start at Layer 1) — best when the symptom is total loss of connectivity.
• Top-down (start at the application) — best when one app fails but the network is otherwise fine.
• Divide-and-conquer — start at Layer 3 (ping) because it instantly splits the problem in half.

Whichever layer first fails is your fault domain. Everything below is fine; everything above is untested. Stop guessing and go there.

Layer 1–2: is the physical path real?

Most "network" outages are cables and ports. Confirm link lights, then on the switch run show interfaces and read the counters like a doctor reads vitals:

• Interface down/down → cable, SFP, or the far end is off. Physical.
• Rising CRC/input errors → bad cable, connector, or interference. Replace and re-test.
• Late collisions → a duplex mismatch — one side full, one side half. Set both to auto or both to the same fixed values.
• Interface err-disabled → often port security triggered. Find the violation before you bounce the port.

Layer 3: the ping ladder

Layer 3 is where you split the problem fastest. Ping outward in order — the first failure names the fault:

ping 127.0.0.1      # your own TCP/IP stack alive?
ping <own IP>       # your NIC configured?
ping <gateway>      # local network / switch path OK?
ping 8.8.8.8        # internet reachable by IP?
ping google.com     # DNS working?

A request timed out (silence) points to a firewall or dead host; destination host unreachable (an actual reply) points to a routing or ARP failure. A 169.254.x.x address means DHCP failed. When 8.8.8.8 works but the name doesn't, it's DNS, not connectivity.

Tracing the path: where does it die?

When the ping ladder fails past the gateway, traceroute shows exactly how far traffic gets. The last responding hop borders the fault. On routers, verify the packet even has a way forward:

tracert google.com          # last live hop = edge of the problem
show ip route               # is there a route (or default) to the destination?
show ip route 8.8.8.8       # what will actually be used for this destination?

No matching route and no default = gateway of last resort not set — the router is dropping traffic it doesn't know how to forward.

Layer 4–7: ports, ACLs, and "it's up but I can't reach it"

If ping works but the service doesn't, you're above Layer 3. Test the actual port and hunt the filter:

telnet 10.0.0.5 443    # does the TCP port answer? (or Test-NetConnection)
show access-lists      # is an ACL silently denying it?
show ip nat translations  # is NAT translating as expected?

The classic trap: a working ping (ICMP allowed) while an ACL blocks the app port. Always test the protocol that actually matters, not just ICMP.

Protocol-specific playbooks

Some faults have signature checklists — jump straight to the specialist guides:

• OSPF neighbours won't form → the mismatch checklist (timers, area, MTU, auth, subnet).
• Everything is slow, nothing is down → the slow-network guide (duplex, Wi-Fi, congestion, DNS).
• No internet at all → the layered no-internet method.
• Duplicate IP warnings → IP conflict fix.

The show commands every engineer runs first

On any Cisco device, this sequence builds the whole picture in under a minute:

show ip interface brief   # which interfaces are up and addressed
show interfaces status    # speed/duplex/VLAN/errdisable at a glance
show ip route             # the forwarding logic
show cdp neighbors        # what's actually connected where
show logging              # what the device has been complaining about

Reference pages for each: show ip route, show interfaces, and the full command library.

Mindset: the rules that separate seniors from juniors

• Change one thing at a time. Two changes at once means you never learn which fixed it.
• What changed? Most incidents follow a change — a config push, a new device, a cable move. Ask first.
• Trust layers, not hunches. A signal that pattern-matches to a known failure may have a different cause — verify the layer before you act.
• Document as you go. Your notes are the next engineer's playbook and your own memory next quarter.
• Back out cleanly. If a change doesn't fix it, undo it before trying the next — don't stack experiments.

These habits are exactly what troubleshooting interviews probe for.

Frequently asked questions

Related articles