The OSI Model
The 7-layer reference model — a mental framework for networking
Why This Model Exists
The OSI (Open Systems Interconnection) model was developed by the ISO in 1984 as a conceptual framework for understanding how network communication works. It decomposes networking into 7 discrete layers, each with a well-defined responsibility.
The Core Idea
Each layer provides services to the layer above it and consumes services from the layer below. Layers communicate with their peer layer on the remote host via protocols, but the actual data flows down the stack on the sender, across the physical medium, and up the stack on the receiver.
Note
Note: The OSI model never "won" as an implementation. TCP/IP did. But OSI remains the dominant mental model for reasoning about networking. When someone says "that's a Layer 2 problem" or "this operates at Layer 7," they're referencing OSI.
The 7 Layers at a Glance
Tip
Mnemonic (top-down): All People Seem To Need Data Processing — Application, Presentation, Session, Transport, Network, Data Link, Physical.
Layer-by-Layer Deep Dive
Layer 1 — Physical
What It Does
Defines the electrical, optical, or radio specifications for transmitting raw bits over a physical medium. This layer is concerned with voltages, pin layouts, cable specs, modulation schemes, and bit timing.
- Converts bits into signals (electrical pulses, light pulses, or radio waves)
- Defines the physical connectors (RJ-45, SFP+, LC fiber connector)
- Specifies data rates (1 Gbps, 10 Gbps, 25 Gbps)
- Manages bit synchronization and encoding (e.g., Manchester encoding, 8b/10b)
Note
PDU: Bits. At this layer, there's no concept of addresses, packets, or meaning — just a stream of 1s and 0s transmitted over a medium.
| Protocol / Standard | Medium | Typical Use |
|---|---|---|
1000BASE-T | Cat5e/6 copper | 1 Gbps Ethernet over twisted pair |
10GBASE-SR | Multimode fiber | 10 Gbps short-reach datacenter links |
802.11ax (Wi-Fi 6) | Radio (2.4/5/6 GHz) | Wireless LAN |
DSL | Telephone copper | Last-mile broadband |
Tip
DevOps context: When you troubleshoot "no link" on a server NIC, check cable seating, SFP modules, and link lights — that's all Layer 1.
Layer 2 — Data Link
What It Does
Provides node-to-node (hop-by-hop) data transfer between directly connected devices on the same network segment. This layer frames raw bits into structured frames, handles MAC addressing, error detection, and media access control.
- Framing: Encapsulates packets into frames with headers and trailers
- MAC Addressing: Uses 48-bit hardware addresses (e.g.,
aa:bb:cc:dd:ee:ff) to identify NICs on the local segment - Error Detection: Appends a CRC (FCS field) to detect corrupted frames
- Media Access Control: Manages access to the shared medium (CSMA/CD for wired Ethernet, CSMA/CA for Wi-Fi)
- Flow Control: Prevents a fast sender from overwhelming a slow receiver (e.g., Ethernet PAUSE frames)
Layer 2 is subdivided in the IEEE model into two sublayers:
| Sublayer | Full Name | Responsibility |
|---|---|---|
LLC | Logical Link Control (802.2) | Multiplexing protocols over the link, optional flow/error control |
MAC | Media Access Control | Framing, addressing, media arbitration |
Note
PDU: Frame. An Ethernet frame includes a destination MAC, source MAC, EtherType, payload, and a 4-byte FCS (Frame Check Sequence).
| Protocol / Standard | Description |
|---|---|
Ethernet (802.3) | Dominant wired LAN technology; switched, full-duplex |
Wi-Fi (802.11) | Wireless LAN; uses CSMA/CA for media access |
ARP | Resolves IPv4 addresses to MAC addresses (lives between L2 and L3) |
802.1Q (VLAN tagging) | Inserts a 4-byte VLAN tag into Ethernet frames for logical segmentation |
STP (802.1D) | Spanning Tree Protocol — prevents L2 loops in switched networks |
LLDP | Link Layer Discovery Protocol — neighbor discovery for switches |
Tip
DevOps context: VLANs, bonding/LACP, bridge interfaces in Linux, and "no ARP entry" errors are all Layer 2 territory. In Kubernetes, CNI plugins like Calico (L3 mode) vs. Flannel (VXLAN/L2 overlay) make very different L2 choices.
Layer 3 — Network
What It Does
Provides end-to-end logical addressing and routing across multiple networks. This is the layer that enables internetworking — connecting different LANs into a single routed network.
- Logical Addressing: IP addresses (IPv4: 32-bit, IPv6: 128-bit) that are hierarchical and routable
- Routing: Determines the best path for packets across multiple hops (routers)
- Fragmentation/Reassembly: Splits packets that exceed the MTU of a link (though modern practice avoids this via Path MTU Discovery)
- TTL/Hop Limit: Prevents packets from looping forever
Note
PDU: Packet. An IP packet includes source IP, destination IP, TTL, protocol field, and the payload (typically a transport segment).
| Protocol | Description |
|---|---|
IPv4 | 32-bit addressing, ~4.3 billion addresses, still dominant |
IPv6 | 128-bit addressing, built-in IPsec support, no broadcast |
ICMP | Control messages: echo (ping), destination unreachable, TTL exceeded (traceroute) |
IGMP | Manages multicast group membership |
IPsec | Encryption and authentication at the network layer (used in VPNs) |
OSPF | Interior gateway routing protocol (link-state) |
BGP | Exterior gateway routing protocol — the routing protocol of the internet |
Warning
Key distinction: MAC addresses are flat (no hierarchy) and only relevant on a local segment. IP addresses are hierarchical (network + host portion) and routable across the internet. Routers operate at Layer 3; switches operate at Layer 2.
Tip
DevOps context: Subnet design, CIDR notation, route tables, VPC peering, BGP in cloud networking, and ip route / ip addr commands are all Layer 3. In Kubernetes, pod CIDR allocation, Service ClusterIP routing, and kube-proxy's iptables/IPVS rules are L3 constructs.
Layer 4 — Transport
What It Does
Provides end-to-end communication between processes on different hosts. This layer introduces port numbers to multiplex multiple applications over a single IP address, and optionally provides reliability, ordering, and flow control.
- Segmentation: Breaks application data into segments/datagrams
- Port Multiplexing: 16-bit port numbers (0-65535) identify specific processes
- Reliability (TCP): Acknowledgments, retransmission, in-order delivery
- Flow Control (TCP): Sliding window mechanism to prevent receiver overload
- Congestion Control (TCP): Algorithms (Reno, CUBIC, BBR) to avoid overwhelming the network
Note
PDU: Segment (TCP) or Datagram (UDP). Includes source port, destination port, and protocol-specific fields (sequence numbers for TCP, length for UDP).
- Connection-oriented (3-way handshake)
- Reliable, ordered delivery
- Flow control (sliding window)
- Congestion control
- Higher overhead, higher latency
- Use: HTTP, SSH, databases, file transfer
- Connectionless (fire-and-forget)
- No reliability, no ordering guarantees
- No flow control
- No congestion control (by default)
- Minimal overhead, low latency
- Use: DNS, DHCP, video streaming, gaming, QUIC
Tip
DevOps context: When you configure targetPort in a Kubernetes Service, set up health check probes, debug connection timeouts, or tune TCP keepalive settings — you're working at Layer 4. Load balancers can operate at L4 (TCP/UDP forwarding) or L7 (HTTP-aware routing).
Layer 5 — Session
What It Does
Manages sessions (dialogs) between applications. Responsible for establishing, maintaining, synchronizing, and tearing down communication sessions. This includes checkpointing, so a long transfer can resume after interruption.
- Session establishment, maintenance, and termination
- Synchronization and recovery (checkpoints in data streams)
- Full-duplex, half-duplex, or simplex mode management
Note
In practice: Layer 5 is one of the "blurriest" layers. In the TCP/IP world, session management is typically handled by application protocols or by TLS session resumption. Distinct L5 protocols are rare in modern networking.
| Protocol / Mechanism | Description |
|---|---|
NetBIOS | Legacy session service for Windows networking |
RPC | Remote Procedure Call — session management for distributed calls |
SOCKS | Proxy protocol with session negotiation |
TLS session resumption | Reuses previously established TLS sessions to avoid full handshake |
Layer 6 — Presentation
What It Does
Handles data translation, encryption, and compression between the application and the network. Ensures that data from the application layer of one system can be read by the application layer of another, regardless of internal representation.
- Data Translation: Character encoding (ASCII, UTF-8, EBCDIC), byte order
- Encryption/Decryption: TLS/SSL encryption technically operates here
- Compression: gzip, data serialization formats (ASN.1, Protocol Buffers, JSON)
- Serialization: Converting data structures to wire format and back
Note
In practice: Like Layer 5, this layer is largely absorbed into the application layer in real-world TCP/IP. TLS, data serialization (JSON, protobuf), and compression (gzip) are all handled at the application level or by libraries.
Layer 7 — Application
What It Does
The layer closest to the end user. Provides network services directly to applications. This is where protocols define the semantics of the communication — what the data means and how it's structured.
- Defines application-specific protocols and data formats
- Provides interfaces for user applications to access network services
- Handles authentication, authorization at the application level
| Protocol | Port(s) | Description |
|---|---|---|
HTTP/HTTPS | 80 / 443 | Web traffic — the foundation of REST APIs, web apps |
DNS | 53 | Domain name resolution (name to IP mapping) |
SSH | 22 | Secure shell — remote administration, tunneling |
SMTP/IMAP | 25, 587 / 993 | Email send / receive |
FTP/SFTP | 21 / 22 | File transfer |
SNMP | 161/162 | Network device monitoring and management |
DHCP | 67/68 | Dynamic IP address assignment |
gRPC | varies | HTTP/2-based RPC framework (uses protobuf at L6 conceptually) |
Tip
DevOps context: Ingress controllers, API gateways, WAFs, service meshes (Envoy/Istio), and HTTP-aware load balancers all operate at Layer 7. When you write an Ingress rule routing /api/* to one service and /web/* to another, that's L7 routing based on HTTP path.
PDUs Across the Stack
Each layer wraps the data from the layer above with its own Protocol Data Unit (PDU) headers (and sometimes trailers). This is the essence of encapsulation.
Data
Application payload
Segment
+ TCP/UDP header
Packet
+ IP header
Frame
+ Ethernet header + FCS
Bits
Electrical/optical signals
Note
Note: Layers 5-7 all share the same PDU name ("Data") in the OSI model because there's no standard framing between them — they all operate on the application data before it reaches the transport layer.
Complete Protocol Mapping
| Layer | Name | PDU | Addressing | Key Protocols | Devices |
|---|---|---|---|---|---|
| 7 | Application | Data | Hostnames, URIs | HTTP, DNS, SSH, SMTP, SNMP, DHCP | Application gateways, proxies |
| 6 | Presentation | Data | — | TLS/SSL, JPEG, MPEG, ASN.1, gzip | — |
| 5 | Session | Data | Session IDs | NetBIOS, RPC, SOCKS | — |
| 4 | Transport | Segment / Datagram | Port numbers (0-65535) | TCP, UDP, SCTP, QUIC | L4 load balancers, firewalls |
| 3 | Network | Packet | IP addresses | IPv4, IPv6, ICMP, OSPF, BGP, IPsec | Routers, L3 switches |
| 2 | Data Link | Frame | MAC addresses | Ethernet, Wi-Fi, ARP, 802.1Q, STP | Switches, bridges, NICs |
| 1 | Physical | Bits | — | Ethernet PHY, fiber, radio, DSL | Hubs, repeaters, cables, NICs |
OSI vs. Reality
Why OSI Matters Even Though TCP/IP Won
- Shared vocabulary: "L4 load balancer" vs "L7 load balancer" is universally understood because of OSI numbering
- Troubleshooting framework: Work bottom-up — "Is the cable plugged in? (L1) → Can I see the MAC? (L2) → Can I ping the IP? (L3) → Is the port open? (L4) → Is the app responding? (L7)"
- Vendor-neutral: Every networking vendor, cloud provider, and certification uses OSI layer numbering
- Separation of concerns: Forces you to think about which layer a problem or technology belongs to
Warning
Common misconception: People sometimes treat OSI layers as rigid boundaries. In reality, many protocols span multiple layers. TLS operates at L5-L6, ARP sits between L2 and L3, and QUIC is a transport protocol (L4) built on top of UDP (also L4). The model is a guide, not a straightjacket.
OSI-Based Troubleshooting Flow
When debugging a connectivity issue, walk up the stack:
- Layer 1 — Physical: Is the link up? Check cable, SFP, link lights.
bash ethtool eth0 # Check link state, speed, duplex ip link show eth0 # Is the interface UP? - Layer 2 — Data Link: Can you see the neighbor's MAC? Is ARP resolving?
bash ip neigh show # ARP table — are there entries? bridge fdb show # MAC address table on Linux bridge - Layer 3 — Network: Can you reach the remote IP? Is routing correct?
bash ping 10.0.1.5 # ICMP echo — basic L3 reachability traceroute 10.0.1.5 # Path analysis — where does it break? ip route get 10.0.1.5 # Which route table entry matches? - Layer 4 — Transport: Can you establish a TCP connection? Is the port open?
bash ss -tlnp # What's listening? (TCP) nc -zv 10.0.1.5 443 # Can we TCP connect to port 443? tcpdump -i eth0 port 443 # Capture traffic to see SYN/SYN-ACK - Layer 7 — Application: Does the application respond correctly?
bash curl -v https://10.0.1.5/health # Full HTTP request with headers dig example.com # DNS resolution test openssl s_client -connect 10.0.1.5:443 # TLS handshake test
Tip
Pro tip: If ping works but curl doesn't, the problem is above Layer 3. If nc -zv connects but curl gets no response, the problem is at Layer 7 (the application). This systematic approach eliminates guesswork.