How do you use the OSI model when you troubleshoot?
Show the answer
Say this first
I use it to prove each layer in order and to pick a starting point. Bottom up when the symptom smells physical (link down, errors, one user). Top down when the user reports an application error and the network looks healthy. Divide and conquer from layer 3 with a ping: if ping works, look up; if it fails, look down. Each layer has a quick proof: link up and clean counters, a MAC and ARP entry, a route and ping, a TCP connect to the port, then the application response.
Go deeper
Proof per layer
| Layer | What proves it | Commands |
|---|---|---|
| 1 | Link up, right speed and duplex, no CRC errors, optic light levels | show interfaces status, show interfaces, show interfaces transceiver |
| 2 | Right VLAN, MAC learned, STP forwarding, ARP resolves | show mac address-table, show spanning-tree, show arp |
| 3 | Correct IP and mask, route exists both ways, ping and traceroute | show ip route, ping, traceroute |
| 4 | Port reachable, no ACL or firewall drop, no MTU black hole | telnet host 443, nc -vz, curl -v, firewall logs |
| 7 | Application answers correctly | curl, dig, application logs |
Picking the approach
- Bottom up is thorough but slow. Good after cabling work or for a single port.
- Top down starts where the user is. Good when many users are fine and one app fails.
- Divide and conquer starts in the middle. A successful ping clears layers 1 to 3 at once.
- Follow the path hop by hop, using the routing table and ARP at each device.
They will ask next
Ping works, but the website does not load. Which layers are cleared?
Layers 1 to 3 between those two endpoints, for ICMP. Look at layer 4 and up: a firewall or ACL dropping TCP 443, DNS returning the wrong address, an MTU problem that only hits large packets, or the application itself.
Traps
- Saying "ping works so the network is fine". ICMP can take a different policy path from TCP 443.