Overview
Curated: · Written: · Reviewed:
Use layers to localize evidence, not to replace protocol reality
The mental model: layers are contracts, not boxes
When an interviewer asks about the OSI model, they are usually not testing whether you can recite seven nouns. They are testing whether you can look at a broken system and say which layer's contract was violated, and what evidence would prove it. That is the mental model worth having: each layer is a service contract between the layer above and the layer below, and each contract has a narrow scope. The link layer promises delivery across one physical medium. IP promises nothing except best-effort delivery of a datagram to a destination address. TCP promises a reliable ordered byte stream between two endpoints — and nothing about message boundaries or latency.
The failure mode interviewers probe for is treating the model as a law that protocols obey. It is not. TLS spans what OSI calls presentation and session concerns while running over a transport. QUIC implements reliable, secure, multiplexed transport semantics over UDP. ARP sits between layers 2 and 3 and is often drawn on either side. If your answer requires a protocol to live in exactly one box, the model has stopped helping you.
A strong answer names the two models, maps real protocols onto them honestly, and then uses layering as a troubleshooting frame. A weak answer recites the seven layers and stops.
The two models side by side
OSI has seven layers: physical, data link, network, transport, session, presentation, application. The TCP/IP model that matches what is actually deployed has four (or five, depending on the textbook): link, internet, transport, application.
The collapse happens at the top. OSI's session layer (dialog control, who talks when), presentation layer (encoding, serialization, encryption), and application layer (the actual protocol semantics) have no separate deployed counterparts — HTTP handles all three, TLS covers what presentation was supposed to mean, and session state lives in the application or in protocols like QUIC's connection concept. Nobody deploys a "session layer device."
| OSI layer | TCP/IP layer | What it owns | Example protocols |
|---|---|---|---|
| 7 Application | Application | Protocol semantics | HTTP, DNS, SMTP |
| 6 Presentation | (collapsed into Application) | Encoding, encryption | TLS, MIME, protobuf |
| 5 Session | (collapsed into Application) | Dialog, sessions | QUIC connections, RPC sessions |
| 4 Transport | Transport | End-to-end delivery, ports | TCP, UDP, QUIC, SCTP |
| 3 Network | Internet | Global addressing, routing | IPv4, IPv6, ICMP, routing protocols |
| 2 Data link | Link | Local-medium delivery | Ethernet, Wi-Fi (802.11), ARP, NDP |
| 1 Physical | Link (or split out) | Bits on the wire | Copper, fiber, radio |
Encapsulation: how the mechanism actually works
Data moving down a sender's stack gets wrapped, and each wrapper carries metadata for its own scope only. An HTTP request becomes a TCP segment (sequence numbers, ports, window), which becomes an IP packet (source/destination addresses, TTL), which becomes an Ethernet frame (MAC addresses, EtherType, FCS). The names for these units matter in interviews: a frame is the link-layer PDU, a packet is the network-layer PDU, a segment (TCP) or datagram (UDP) is the transport-layer PDU. The receiver decapsulates in reverse order.
The key asymmetry: routers rewrite the link layer at every hop, but the IP header mostly survives. A router strips the incoming frame, decrements TTL (Hop Limit in IPv6), recomputes the IP checksum (IPv4 only — IPv6 has no header checksum), and builds a fresh frame for the outgoing link with new MAC addresses. The source and destination IP addresses persist hop to hop. Transport headers and ports persist end to end — unless a middlebox intervenes.
That "unless" is where senior-level answers earn their keep:
- NAT rewrites IP addresses and ports, and holds per-flow state with a timeout. This is why a NAT mapping expires and kills an idle UDP flow while the application still believes it is connected.
- A TLS-terminating proxy ends the transport connection at the proxy. The client's TCP peer is the proxy, not the origin server. Retransmission domains, RTT measurements, and the TLS boundary all change at that point.
- A stateful firewall tracks the five-tuple and direction; it is not a pure packet filter and it can silently drop anything it cannot classify.
Protocol placement and devices per layer
Where the protocols you actually meet sit, and what hardware operates at each level:
- Physical / link: Ethernet and Wi-Fi frames, MAC addresses (48-bit, locally significant), hubs and repeaters (physical — obsolete but still named in interviews), switches (link — forward by MAC, maintain a MAC table per port, and forward broadcasts to all ports).
- Between link and network: ARP resolves IPv4 addresses to MAC addresses on the local link via broadcast. IPv6 Neighbor Discovery does the same job plus router discovery over ICMPv6. Both are local-link control planes with cache lifetimes, and both are security-sensitive (ARP spoofing, rogue NDP).
- Network: IP, ICMP, and routing. Routers forward by destination prefix from the routing table. IPv4 routers may fragment; IPv6 routers never fragment, so endpoints own Path MTU Discovery.
- Transport: TCP and UDP, identified by ports. A TCP connection is the four-tuple (source IP, source port, destination IP, destination port) plus protocol — the listening port alone is not the connection.
- Application and above: DNS (names to records — it says nothing about reachability), HTTP, TLS.
Firewalls and load balancers are deliberately awkward: a packet filter is L3/L4, a stateful firewall tracks L4 flows, an L7 proxy or load balancer reads the application protocol. "What layer does a load balancer operate at" is a common follow-up precisely because the honest answer is "which one?"
Using layers as a troubleshooting frame
This is the part interviewers actually want. Three standard approaches:
- Bottom-up: start at layer 1 (link light, interface counters) and work up. Slow but reliable; best when you have console access.
- Top-down: start at the application (is the process listening? does the request reach it?) and work down. Best when the symptom is application-specific.
- Divide and conquer: test the middle first — can you ping the host? Does TCP connect? — and branch based on which half works. Fastest in experienced hands.
Mapping symptoms to layers:
| Symptom | Likely layer | Evidence to collect |
|---|---|---|
| No link | L1/L2 | Interface state, cable, switch port, Wi-Fi association |
| ARP failures / partial reachability | L2/L3 | ARP cache (ip neigh), neighbor entries, wrong subnet mask, gateway unreachable |
| Wrong gateway | L3 | Routing table, default route, traceroute first hop |
| DNS failure | Application (name resolution) | dig/nslookup answers, resolver config, record TTLs — note DNS success says nothing about reachability |
| Port blocked / filtered | L3/L4 | Connection refused (RST — nothing listening) vs. timeout (filtered or dropped), firewall logs |
| Small requests work, large transfers stall | L2/L3 (MTU) | Path MTU, DF bit, ICMP Packet Too Big being filtered, tunnel overhead |
The MTU row deserves its own paragraph because it is the classic senior-level trap. When Path MTU Discovery's ICMP "fragmentation needed" or "Packet Too Big" messages are black-holed by an overzealous firewall, the symptom is bizarre: handshakes succeed, small requests succeed, and any payload above the path MTU stalls forever while the sender retransmits into a void. Diagnose packet sizes and DF behavior, not generic "packet loss."
Trade-offs, misconceptions, and when the model fails you
Common misconceptions that lose points:
- "UDP is faster." UDP is less, not faster. It removes reliability, ordering, congestion control, and connection state — and hands those responsibilities to the application. For a workload that needs any of them, UDP plus hand-rolled versions of them is usually slower than TCP.
- "TLS is layer 6." In the deployed stack, TLS runs over TCP (or inside QUIC) and under HTTP. The OSI label is a vocabulary convenience, not a deployment fact.
- "TTL is seconds." TTL/Hop Limit is a hop count bounding forwarding loops, not a wall-clock duration.
- "Blocking ICMP is safer." Blocking all ICMP breaks PMTUD, diagnostics, and (on IPv6) neighbor discovery itself.
- "TCP preserves messages." TCP preserves byte order only. Applications must frame records and handle partial reads, half-close, resets, and uncertain outcomes (a retransmitted request that already committed is a real production bug class).
When the model fails: any protocol that tunnels another (QUIC over UDP, IPsec, VXLAN) makes single-layer placement meaningless. Say so, then talk about the actual contracts instead.
What changes at scale
- Middlebox density. At scale, the path between client and server crosses NATs, stateful firewalls, and TLS-terminating proxies. Each one changes the true peer, the retransmission domain, and what a capture at any single point shows.
- Offload and observability. NICs offload checksums, TSO, and LRO; a packet capture at the host may show checksums that look wrong or segments that never existed on the wire. Capture at multiple boundaries.
- Asymmetric routing and anycast. The return path may not mirror the forward path; DNS-based load balancing means the "server" is a set of machines.
- IPv6 differences. No router fragmentation, no broadcast, NDP over ICMPv6 — filtering ICMPv6 breaks the protocol, not just diagnostics.
Likely interview follow-ups
- "Where does QUIC fit?" — Secure multiplexed transport over UDP; its streams remove transport-level head-of-line blocking between streams, but packet loss still stalls all streams sharing the connection's congestion control.
- "What's actually different between a switch and a router?" — MAC-table forwarding within a broadcast domain vs. prefix-based routing between networks, with TTL decrement and frame rewrite at the router.
- "A connection works from one subnet but not another — walk me through it." — Expect subnet mask, gateway, ARP, firewall, and MTU to all appear in your answer.
- "Why can a TCP connection succeed but the application still fail?" — The transport contract is only bytes between sockets; TLS handshake, authentication, and application semantics live above it.