The First Rule: Define the Problem Precisely
"The network is slow" is not a problem definition. "User A in VLAN 30 cannot reach the file server at 10.0.20.50 — ping times out, but they can reach 10.0.20.51 on the same subnet" is a problem definition. The specificity of your problem statement determines the speed of your resolution.
Before touching anything, answer: Who is affected (one user, one VLAN, everyone)? What exactly fails (no connectivity, slow, intermittent)? When did it start? What changed recently? The answer to "what changed recently" resolves 60–70% of network issues before you run a single command.
OSI Layer Methodology — Bottom Up
Work through the layers from physical (Layer 1) upward. Don't jump to Layer 7 application troubleshooting when the cable is unplugged. Each layer depends on the one below it — if Layer 2 is broken, Layer 3 analysis is meaningless.
Layer 1 — Physical
Check the obvious first: is the cable connected? Is the port showing link? show interface GigabitEthernet0/1 — look for "line protocol is up." A down/down interface is a physical problem. An up/down interface is typically a protocol issue. Check for interface errors: CRC errors suggest a bad cable or duplex mismatch; input errors suggest noise or collisions.
Layer 2 — Data Link / Switching
Verify the device is in the correct VLAN: show vlan brief or show interfaces trunk. Check the MAC address table: show mac address-table | include [mac-address] — is the device's MAC appearing on the expected port? STP issues (port stuck in blocking) account for a disproportionate number of intermittent Layer 2 problems: show spanning-tree vlan [id].
Layer 3 — Network / Routing
Can the device get an IP address? Is the default gateway correct? From the device: ping [default-gateway] — if this fails, the problem is local (Layer 1/2, no IP, wrong gateway). If the gateway responds but the destination doesn't, the problem is routing. On the router: show ip route [destination] — is there a route? Is it the expected route? traceroute shows exactly where the path breaks.
Layer 4–7 — Transport and Application
If ping works but the application doesn't, the problem is above Layer 3. Common causes: a firewall blocking the specific port, a service not listening, a DNS resolution failure, an SSL certificate issue. Use telnet [ip] [port] or nc -zv [ip] [port] to test specific TCP port connectivity. Test DNS separately: nslookup hostname or dig hostname.
Essential Commands Reference
Connectivity: ping, traceroute / tracert (Windows), pathping (Windows, combines ping and traceroute)
DNS: nslookup hostname, dig hostname @dns-server, dig +trace hostname (full recursive trace)
Port testing: telnet ip port, nc -zv ip port, Test-NetConnection ip -Port port (PowerShell)
Routing: show ip route, ip route get [destination] (Linux), route print (Windows)
Interface health: show interfaces, show interface counters errors, show ip interface brief
ARP: show arp, arp -a (Windows/Linux) — verifies Layer 2/3 resolution
Packet capture: tcpdump -i eth0 host 10.0.0.1, Wireshark — when you need to see exactly what's on the wire
Common Failure Patterns
One user can't reach one destination. Start at the user's machine — correct IP, correct gateway, correct DNS? If local config is right, check the path: does the routing table show the expected route? Is there a firewall ACL blocking this specific combination of source/destination/port?
Entire subnet can't reach a destination. The problem is likely at the gateway or in the routing infrastructure. Check the SVI/interface for the VLAN — is it up? Is there a route to the destination? Has an ACL been applied to the interface recently?
Intermittent connectivity. The hardest class. Could be a flapping interface (check interface error counters over time), a routing loop, duplicate IP addresses (causes intermittent ARP resolution failures), STP topology changes, or overloaded equipment. Enable logging to capture events with timestamps: logging buffered and show log.
Slow but not down. Check interface utilisation (show interface — look at input/output rate vs bandwidth), check for duplex mismatches (one end auto-negotiates full duplex, the other is hard-coded half), check for packet loss with extended pings, look for QoS queue drops.
The Change Hypothesis
For every problem, form a specific hypothesis before making any change: "I believe the issue is X because I observed Y. If I change Z, I expect the symptom to resolve." Write this down. This discipline prevents the "I'll just try changing things" approach that wastes time and often introduces new problems.
Only change one variable at a time. Change two things simultaneously and you won't know which one fixed (or broke) the problem. This seems obvious and is routinely ignored under pressure.
Document As You Go
Notes during troubleshooting aren't optional extra work — they're the mechanism by which you avoid repeating work and by which your colleagues can continue if you're called away. Note: what you checked, what the output showed, what you changed, and what the result was. A troubleshooting log that took 10 minutes to write has saved many hours of work when the same issue recurred six months later.
Knowing When to Escalate
Escalation isn't failure. If you've worked through the layers systematically, documented your findings, and the problem is beyond the scope of your access or expertise, escalating with clear documentation (what you checked, what you found, what you ruled out) is significantly more valuable than continuing to guess. The worst outcome is spending hours changing things without a hypothesis and handing off a problem you've made harder to diagnose.