Use the OSI model to localize evidence—not to recite seven names
The OSI model becomes useful when each layer is treated as a troubleshooting checkpoint. A no-carrier condition, wrong VLAN, wrong subnet mask, refused TCP connection, failed DNS query, and HTTP 500 response are not interchangeable failures. Each artifact tests a different function, and a successful lower-layer checkpoint should stay proven unless new evidence contradicts it.
Match common network artifacts to the function they actually test
Layer 1
Carrier, cable, optics, radio, NIC, port state.
Layer 2
MAC learning, VLAN placement, trunks, switching.
Layer 3
IP address, mask, gateway, routes, ICMP reachability.
Layer 4
TCP/UDP behavior, ports, connection establishment.
Application
DNS, HTTP, TLS-driven application behavior, authentication.
Evidence rule
Stop the conclusion where the artifact stops.
Ethernet interface shows no carrier
The first unresolved dependency is physical attachment. Inspect cable, transceiver, endpoint NIC, switch port, power, and port administrative state before changing IP configuration.
What would move Scenario 1 above Layer 1?
If the link becomes stable, MAC learning appears on the expected port, and the endpoint receives frames, the no-carrier hypothesis is no longer the best explanation. That is the moment to move upward rather than continuing to replace cables.
The switch learns the endpoint MAC in the wrong VLAN
Layer 1 is healthy enough for frames to reach the switch. The evidence now points to Layer 2 logical placement: access VLAN, dynamic assignment, SSID mapping, voice/data role, or trunk tagging.
Use a working neighboring VLAN to isolate trunk failures
The shared physical uplink is alive. Inspect VLAN 30 existence, allowed lists, tagging, or native/untagged behavior instead of blaming the cable.
The host has the wrong prefix or default gateway
The host belongs to 192.168.14.64/26, while 192.168.14.1 belongs to a different /26. That is a Layer 3 addressing contradiction.
A subnet mask changes the host's local-versus-remote decision
An overly broad mask can make a remote destination look local, causing the host to ARP instead of using the gateway. An overly narrow mask can make a local peer look remote, sending traffic toward the gateway unnecessarily.
IP reachability succeeds, but TCP/443 is refused
Basic IP reachability is substantially proven for this test. A refusal moves the investigation toward the destination listener or an active rejection mechanism rather than back to the cable.
Two Layer 4 symptoms imply different evidence paths
| Symptom | Stronger interpretation | Still possible |
|---|---|---|
| TCP refused | Destination reachable enough to reject; listener/policy becomes stronger | Local service or active policy rejection |
| TCP timeout | No timely response returned | Filtering, loss, route, listener, return path |
| TCP connects | Transport establishment works | TLS/application/authentication can still fail |
Swipe horizontally to compare transport clues.
DNS returns the expected address, but the browser receives HTTP 500
The application produced an HTTP response. That is powerful evidence that name resolution, substantial IP routing, TCP establishment, and TLS negotiation succeeded far enough to reach application behavior.
Each successful test moves the uncertainty boundary upward
DNS fails, but remote numeric IP works
Layer 3 routed connectivity exists. DNS is the nearest unresolved application dependency. Replacing the switch uplink contradicts the successful numeric-IP path.
Same-VLAN traffic works, but the default gateway fails
Local switching is healthy enough for peers in the VLAN to communicate. The next boundary is the Layer 3 gateway path: SVI/router interface, trunk carriage to the gateway, gateway address, or policy affecting the gateway.
The route exists, but the next hop is unreachable
The routing table proves a forwarding choice exists. It does not prove the next hop is usable. The next-hop path is now the stronger Layer 3 boundary.
Firewall ALLOW appears, but the application still fails
The firewall is not the demonstrated blocker for this flow. The missing listener is the first explicit application/transport-side failure.
Strong Wi-Fi signal, high retries, and high channel utilization
The radio link exists and signal strength is good. High retries and airtime use support contention/interference rather than a simple coverage hole. The OSI model helps organize this as a lower-layer wireless problem even though the user experiences an application symptom.
Every leading hypothesis should have a test that could disprove it
If you suspect a bad cable, a known-good cable that produces the same no-carrier condition weakens the cable hypothesis. If you suspect VLAN misplacement, a MAC table showing the endpoint in the correct VLAN weakens that explanation. This prevents troubleshooting from becoming confirmation bias.
Choose controls that share most of the same path
A useful control changes as little as possible. A neighboring endpoint on the same switch, a working VLAN on the same trunk, a wired client behind the same gateway, or a second application on the same server can isolate the dependency unique to the failed case.
Reject answers that require already-proven layers to be broken
| Known-good checkpoint | Weak distractor |
|---|---|
| MAC learned on expected switch port | “Cable is completely disconnected” |
| Gateway responds | “Local VLAN path is totally down” |
| Remote numeric IP works | “All routing is broken” |
| DNS returns expected IP | “Name resolution is the first failure” |
| HTTP 500 returned | “Server cannot be reached at all” |
Swipe horizontally to see the distractor matrix.
Change one fact and force the troubleshooting layer to move
No carrier → carrier up
Move from Layer 1 if the next artifact now fails.
Wrong VLAN → correct VLAN
Move to addressing/gateway if Layer 2 placement is fixed.
Wrong prefix → correct prefix
Move to route/policy if the gateway remains reachable.
TCP refused → TCP connects
Move to TLS/application if transport succeeds.
DNS fails → resolves
Move beyond name resolution.
HTTP 500 → 200
The application path is now substantially healthy.
Trace one failure through all major checkpoints
A 403 response is an application-layer authorization outcome. Going back to cable replacement ignores eight successful checkpoints.
Create a scenario with exactly one fault and two successful controls
Use one client, one access switch, one gateway, one remote service, and one security boundary. Write the intended state first. Then create one faulty artifact, two controls that still work, one highest-information next test, and one final verification. Hand the scenario to another student without revealing the fault.
Strong answers connect the observed artifact to the correct network function
Instead of saying “Layer 4 issue,” say: “The server responds to IP reachability tests, but TCP/443 is actively refused. Basic Layer 3 reachability is substantially proven; inspect the destination listener or active policy before revisiting physical connectivity.”
24 OSI Layer Troubleshooting digital flashcards
Practice Layer 1 through application-layer evidence, VLAN placement, subnet logic, route boundaries, TCP refusal vs. timeout, DNS, HTTP errors, controls, falsifiers, checkpoints, and verification.