OSI model (7 layers)

Say a network connection is "broken" and you've said almost nothing useful. Broken how — no cable, no IP address, DNS not resolving, or the web server itself returned an error? An experienced engineer doesn't guess; they ask "which layer is this failing at?" and that question only makes sense because of a shared vocabulary for talking about the different jobs a network performs. That vocabulary is the OSI model.

Where the model came from

In the late 1970s, computer vendors — IBM, DEC, and others — each built proprietary networking stacks that didn't talk to each other. A DEC minicomputer couldn't cleanly network with an IBM mainframe because there was no agreed structure for how the pieces of a network stack should be divided up, let alone a shared protocol. The International Organization for Standardization (ISO) responded by publishing the Open Systems Interconnection model in 1984 — not a protocol itself, but a reference framework describing seven distinct responsibilities a network needs to fulfill, in a fixed order, so that vendors building any piece of that stack would know exactly what job it was supposed to do and what it could assume about the layers above and below it.

ISO went on to standardize actual protocols to sit in those layers — X.400 for messaging, X.500 for directories, CLNP and TP4 as the network and transport protocols. Almost none of them won out in practice. The internet grew up around a competing, simpler design covered in the next article, TCP/IP model. But the seven-layer breakdown itself survived as the standard way engineers describe and reason about any networking stack, OSI-based or not, which is why it's still the first thing taught in networking courses forty years later.

The seven layers

Layers are numbered from the bottom (closest to the physical wire) to the top (closest to the human using an application). Each layer only needs to know how to talk to the layer directly above and below it — it doesn't need to understand what the other five are doing. That isolation is the entire point: change how Wi-Fi encodes bits at Layer 1, and nothing above Layer 2 needs to change at all.

A common mnemonic for remembering the order bottom to top is "Please Do Not Throw Sausage Pizza Away" (Physical, Data Link, Network, Transport, Session, Presentation, Application).

Layer 1 — Physical

This layer is the actual, physical transmission of bits: voltages on a copper wire, pulses of light in fiber, radio waves over Wi-Fi. It defines connector shapes, voltage levels, and signal timing. It has no idea what a "packet" or an "address" is — it just moves raw bits from one point to another.

Layer 2 — Data Link

The Data Link layer moves data between two devices on the same local network, using hardware addresses rather than the logical addresses used further up the stack. Ethernet and Wi-Fi live here, and so do switches, which forward traffic based on the hardware address covered later in this module — see MAC address. A unit of data at this layer is called a frame.

Layer 3 — Network

Once data needs to leave the local network and cross into a different one, something needs a way to identify which network a destination lives on and how to get there. That's the Network layer's job, and IP is the protocol that does it — see IP addressing (IPv4, IPv6). Routers operate primarily at this layer, deciding, packet by packet, which direction to forward traffic. A unit of data here is called a packet.

Layer 4 — Transport

A host can run dozens of network applications at once — a browser, a mail client, a game — all sharing one IP address. The Transport layer's job is delivering data to the right process on that host, using port numbers, and it also decides whether delivery needs to be reliable. TCP guarantees delivery and ordering at the cost of overhead; UDP doesn't bother, trading reliability for speed. Choosing between them is a real design decision, and the next module treats it at length. A unit of data here is often called a segment (TCP) or datagram (UDP).

Layer 5 — Session

The Session layer manages the lifecycle of a conversation between two hosts — establishing it, keeping it synchronized, and tearing it down. In practice, this layer's responsibilities are often absorbed into the application or transport layer in real implementations rather than existing as a distinct piece of code, which is part of why the boundary between layers 5, 6, and 7 feels blurrier in real systems than layers 1 through 4.

Layer 6 — Presentation

This layer is responsible for making sure data is represented in a form both ends agree on — character encoding, data serialization, and importantly, encryption and compression. TLS, the encryption behind HTTPS, is frequently cited as a Presentation-layer concern, though in practice it's implemented as a layer sitting directly on top of TCP rather than as a distinct OS-level layer.

Layer 7 — Application

This is the layer closest to the user: the actual protocol an application speaks to get its job done. HTTP for web pages, SMTP for sending mail, DNS for name resolution. Note the specific meaning here — "Application layer" doesn't mean the software you clicked on (your browser), it means the protocol that software uses to talk over the network.

A frame carrying a packet carrying a segment

Data moving down through the layers on the sending side gets wrapped, one layer at a time, in that layer's own header — a process called encapsulation. An HTTP request becomes a TCP segment (Transport header added), which becomes an IP packet (Network header added), which becomes an Ethernet frame (Data Link header and trailer added), which finally goes out as raw bits (Physical layer). The receiving host reverses the process exactly, one header removed per layer, until the original HTTP request is handed to the receiving application. Each layer only reads its own header — a switch inspecting a frame at Layer 2 doesn't parse the IP header inside it, and a router at Layer 3 doesn't parse the TCP header inside that.

[ Ethernet header | [ IP header | [ TCP header | HTTP request ] ] | Ethernet trailer ]
       L2                L3            L4              L7

The same process, drawn as each layer handing its output down to the one below:

flowchart TD
    A["Application data<br/>e.g. HTTP GET /index.html"] --> B["+ TCP header (ports, sequence number)<br/>= Segment"]
    B --> C["+ IP header (source/destination IP)<br/>= Packet"]
    C --> D["+ Ethernet header/trailer (source/destination MAC)<br/>= Frame"]
    D --> E["Bits on the wire or over the air"]

This nesting is exactly what a packet capture tool shows you when you expand a captured frame — each layer's header sitting neatly inside the one below it, which is why "which layer is this at" is such a practical troubleshooting question: it tells you which header to go look at.

Why the model matters for troubleshooting

"Which layer" is a genuinely useful diagnostic filter, because each layer fails in characteristic ways:

• No link light on the network card, cable unplugged → Layer 1.
• Cable connected but the device can't reach anything, even on the local network → likely Layer 2 (switch port disabled, or the switch has the port assigned to the wrong VLAN — a way of splitting one physical switch into several separate logical networks, so two devices can be plugged into the same box and still be unable to reach each other).
• Local network works, but nothing outside it is reachable → likely Layer 3 (missing or wrong default gateway, routing issue).
• You can ping a server's IP but a specific application won't connect → likely Layer 4 (wrong port, service not listening, firewall blocking that port).
• Connection succeeds but the application returns an error page or garbled data → Layer 7 (application-level bug, wrong request format, expired credentials).

Working through layers from bottom to top when troubleshooting — physical connectivity, then local reachability, then routing, then the port, then the application — avoids wasted effort chasing an application bug when the actual problem is a loose cable.

Practical scenario: same symptom, different layers

Your service reports that it cannot reach api.internal.example. Three incidents can produce a similar user-facing complaint while failing at different layers:

Observation                         Likely layer
----------------------------------  ----------------------------------------
`ip link` shows the interface DOWN   Layer 1/2: physical or data-link problem
`ping 10.0.2.20` has no reply        Layer 3: addressing or routing problem
`curl` connects but gets HTTP 503     Layer 7: application or upstream problem

The model is useful because it prevents random debugging. Start low enough to prove the lower layer works, then move upward. If the interface is down, HTTP logs are noise. If the TCP connection succeeds and the server returns an HTTP error, replacing cables is theatre. Real incidents become shorter when engineers agree which layer they are testing.

Practical scenario: ping succeeds, the connection still times out

A deploy script reports it can't reach a database at 10.0.3.15:5432. First check, out of habit:

ping -c 3 10.0.3.15

64 bytes from 10.0.3.15: icmp_seq=1 ttl=63 time=0.412 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=63 time=0.398 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=63 time=0.405 ms

Reply, reply, reply. It's tempting to conclude the host is fine and look somewhere else entirely. That conclusion is wrong, and it's wrong in a specific, nameable way: ping uses ICMP, which lives at the Network layer (Layer 3) alongside IP. It proves routing and basic reachability between the two hosts. It says nothing about Layer 4 at all — no port number is even part of an ICMP echo request, because ICMP doesn't have ports.

The actual question — "is anything listening on TCP port 5432?" — needs a Layer 4 tool:

nc -zv -w 3 10.0.3.15 5432

nc: connect to 10.0.3.15 port 5432 (tcp) failed: Connection timed out

-z tells nc to just test the connection and send no data; -v is verbose; -w 3 caps the wait at 3 seconds. A timeout here — as opposed to an instant Connection refused — has a specific meaning: the SYN packet that opens a TCP handshake either never arrived, or arrived and got silently dropped, most often by a firewall rule with no explicit reject (just a drop). A refusal would mean the packet got there and the destination has no process listening on that port; a timeout means you can't even tell that much yet.

ping 10.0.3.15                 -> Layer 3 reachable (ICMP got a reply)
nc -zv 10.0.3.15 5432 (timeout) -> Layer 4 port unreachable, likely filtered
nc -zv 10.0.3.15 5432 (refused) -> Layer 4 port reachable, nothing listening

Same host, two different verdicts, because the two tools test two different layers. This is the concrete version of the abstract point earlier in this article: naming the layer isn't academic, it's what tells you whether the next step is "check the firewall rule between these two hosts" (Layer 3/4, likely) or "check whether PostgreSQL crashed" (Layer 7, which ping and nc can't rule in or out either way — a closed or filtered port and a crashed-but-still-listening process both need their own separate check).

Common mistakes

• Trying to force every real protocol into exactly one OSI layer. TLS straddles Presentation and Session in the strict model but is implemented right above Transport in practice. The model is a reference for reasoning, not a strict engineering blueprint every protocol must obey.
• Confusing the OSI model with a protocol suite you actually run. OSI is a conceptual reference; the protocols you actually use day to day (IP, TCP, HTTP) belong to the TCP/IP suite, covered next in TCP/IP model.
• Skipping straight to "the network is down" without identifying a layer. That phrase covers dozens of unrelated failure modes; naming a layer is what turns a vague complaint into a diagnosable problem.

Interview questions

• Basic: Name the seven OSI layers in order and give one protocol or device that belongs at each.
• Mechanism: Explain encapsulation — what gets added at each layer on the way down, and what happens to those headers on the way up at the receiving host.
• Troubleshooting: A ping to a host succeeds but an application can't connect to it. Which layer does ping prove is working, which layer is still unverified, and what single command would you run next?

Practice exercises

1. For each of the following, name the OSI layer most directly responsible: a switch forwarding a frame using a hardware address; a router choosing the next hop for a packet; a browser sending an HTTP GET request; a Wi-Fi adapter converting bits into radio waves.
2. You can reach every device on your home network but nothing on the internet. Using the "bottom to top" troubleshooting order from this article, list the layers you'd check, in order, and what you'd look for at each.
3. Open a packet capture (or read about one) and identify the encapsulation for a single HTTP request — which headers are nested inside which, from Ethernet inward to HTTP.
4. A colleague reports that two laptops plugged into the same switch, both with valid addresses in the same range, cannot reach each other. Which layer would you investigate first, and why is Layer 3 the wrong place to start?
5. Take any everyday complaint you've actually heard — "the wifi is down," "the site won't load," "the app is stuck loading" — and write down which layer you'd test first and the single command you'd run to test it. If a symptom maps to more than one layer, say which one you'd rule out first and why.

That last exercise is the whole point of the model, and it's worth doing honestly: if you can't name a layer and a command for a symptom, you don't yet have a diagnostic plan, you have a guess. Which raises a practical problem — the seven layers you just learned are not the layers the software on your machine is actually built around. The stack that runs the internet has four, and the mapping between the two is something you'll need in both directions. TCP/IP model sorts that out.

Sources

• ISO/IEC 7498-1:1994, Information technology — Open Systems Interconnection — Basic Reference Model
• Cloudflare Learning Center, What is the OSI Model?
• IETF, RFC 1122 – Requirements for Internet Hosts — the layered model the internet was actually built on, for comparison against OSI's seven.
• IETF, RFC 792 – Internet Control Message Protocol — defines ICMP, the protocol ping uses, and why it operates independently of any port number.