Random poking wastes hours. A structured method — work the OSI layers, isolate the fault, change one thing at a time — finds the cause fast and reliably.
Why: networking problems live at a specific OSI layer, and checking layers in order (rather than guessing) turns a vague "it’s down" into a located fault — is it the cable, the IP, the DNS, or the app? When: start at the bottom (physical/link) and work up, or split the stack in half. Where: most outages are lower than people assume — cable, interface, VLAN, or IP before you ever blame the application.
LAYER CHECK TOOL
7 Application is the service up? curl, telnet host port
4 Transport is the port open/reachable? ss, telnet, nc
3 Network can I reach the IP? the path? ping, traceroute
3 Naming does the name resolve? dig, nslookup
2 Link interface up? right VLAN? ip link, arp
1 Physical cable, light, port up? show interface, cabling
Bottom-up finds the "nothing works" faults fastest.Why: the fastest way to locate a fault is to cut the problem space in half repeatedly — test the midpoint of the path, and each test eliminates half the possibilities. When: use it on long paths (host → gateway → WAN → server). Where: ping the gateway first; if that works the problem is beyond it, if not it is local.
PC --- switch --- gateway --- WAN --- server
1. ping gateway works? problem is BEYOND the gateway
fails? problem is LOCAL (cable, VLAN, IP)
2. ping across WAN narrows to your edge vs. the far side
3. ping the server works? it's the app, not the network
Each test halves the search. Note results as you go.Why: changing several things at once means you never learn what actually fixed (or broke) it — one change, one test keeps cause and effect clear and lets you undo cleanly. When: always, especially on production gear. Where: record a baseline and every change so you can roll back and write an accurate postmortem.
DO DON'T
- form a hypothesis, then test it - change 5 things and reboot
- one change -> re-test - trust "it looks fine" without a test
- keep a change log + baseline - skip verifying the actual fix
- roll back if it didn't help - leave experimental config behind