OSI Model Simplified

Why "layers" make troubleshooting tractable

The full OSI model has 7 layers, but in real-world ops you only need 4, which map cleanly to the TCP/IP model the internet actually uses. Knowing which layer a problem lives at is the difference between an hour of guessing and a five-minute fix.

Layer	Job	Protocols	Where it lives
Application	What the app actually wants	HTTP, SSH, DNS, SMTP	Your software
Transport	Reliable or fast delivery between processes	TCP, UDP	OS kernel
Network	Routing packets between networks	IP, ICMP	Routers, OS kernel
Physical/Link	Bits on the wire / airwaves	Ethernet, Wi-Fi, ARP	NICs, switches, cables

Encapsulation — what every packet really is

When you load a webpage, the request gets wrapped in headers, layer by layer, before it leaves your machine:

Browser builds an HTTP request: GET / HTTP/1.1\nHost: github.com — Application.
The OS wraps it in a TCP segment with source/dest ports — Transport.
The OS wraps that in an IP packet with source/dest IPs — Network.
The NIC wraps that in an Ethernet frame with source/dest MACs and puts it on the wire — Link.

The receiving end strips headers in reverse — de-encapsulation. Each layer only cares about its own header.

Layered troubleshooting

Can't ping? → Network layer (IP, routing, gateway).
Pings work, can't connect to port 22? → Transport layer (firewall blocking TCP, port closed).
Connects but the app shows errors? → Application layer (config, auth).
Even local devices unreachable? → Physical/Link (cable unplugged, Wi-Fi down).

Code

Check each layer in turn·bash

# Physical/Link: is the interface even up?
ifconfig en0 | grep status

# Network: can we reach the gateway?
ping -c 3 $(route -n get default | awk '/gateway/ {print $2}')

# Network: can we reach the public internet?
ping -c 3 1.1.1.1

# Transport: is a specific port open?
nc -zv 192.168.1.100 22

# Application: does HTTP actually return something sane?
curl -I https://github.com

Exercise

Pick something on your network you can't reach (maybe a printer that's been acting up, or just intentionally point at a fake IP like 192.168.99.99). Walk the layers: ifconfig (link), ping gateway (network), ping target (network), nc -zv target port (transport), application-level test (application). Note which layer breaks first — that's your bug.