Seven Floors.
The OSI model is not a diagram on a flashcard. It is a diagnostic methodology. You start at the bottom and you work up. Each layer either works or it doesn't. You don't skip floors.
The ticket lands in Tomasz Wysocki's queue at 09:40 on a Tuesday. Escalated from L1, flagged urgent. The client is Hargreaves Solicitors, a fifty-person law firm with a single Bristol office. Symptom: Outlook Online is degraded. Users report fifteen-second stalls on email load and roughly one in eight sessions throwing a 401 re-authentication prompt. The L1 analyst who escalated has written one line: "Possibly a TLS issue — users getting re-auth'd." Tomasz reads it and sets it aside. He knows the note is probably wrong. He does not yet know what is right. He opens his laptop and starts at Layer 1.
The OSI model describes network communication as seven discrete layers, each responsible for exactly one class of problem. The reason engineers walk it bottom-to-top is encapsulation: each layer wraps the data from the layer above in its own header, adding its own addressing and control information. At the receiving end, each layer unwraps its own contribution in reverse — decapsulation. If a lower layer is broken, every layer above it is symptomatic. You cannot fix Layer 7 if Layer 3 is dropping packets. You eliminate from the foundation upwards.
Layer 1 — Physical. The Physical layer's job is to move raw bits across a medium: electrical signals on copper, light pulses in fibre, radio waves over air. It does not know about addresses or protocols. It knows about signal and noise. Tomasz pulls up the Openreach portal. The circuit serving Hargreaves's Bristol office shows a leased line — a 100 Mbps synchronous EFM circuit. Sync status: up. No alarms, no CRC errors on the BT side. He then SSHes into the Cisco switch at the client's on-premises edge — Kestrel manages the CPE — and runs show interfaces GigabitEthernet0/1 counters errors. Input errors: zero. Output errors: zero. SFP optical power on the uplink: −3.2 dBm receive, well within tolerance. Physical layer is clean.
Layer 2 — Data Link. The Data Link layer handles frames — the packaged units that travel between devices on the same local segment. It uses MAC addresses to identify interfaces, manages access to the shared medium, and provides error detection within a segment. Switches operate here. VLANs are a Layer 2 construct: logical segmentation of the physical network. Spanning Tree Protocol lives here too, preventing broadcast storms by blocking redundant paths. Tomasz checks the VLAN configuration on the edge switch. The client has a single user VLAN (VLAN 10), correctly tagged on the uplink trunk. He runs show mac address-table — entries look normal, no flapping. show spanning-tree vlan 10 confirms root bridge is stable, no topology change events in the past hour. Broadcast counters are unremarkable. Layer 2 is clean.
Layer 3 — Network. The Network layer handles IP addressing, subnets, and routing — the decisions about how packets travel between networks. Routers operate here. ICMP — the protocol behind ping and traceroute — lives here. BGP, the protocol that connects autonomous systems across the internet, lives here. This layer's job is path selection: getting a packet from source IP to destination IP, potentially across dozens of intermediate networks. Tomasz opens a terminal and runs mtr --report --report-cycles 60 outlook.office365.com from the client's edge router. The first six hops are clean — Kestrel's own backbone, then BT's transit. At hop seven, on a BT peering link between their Bristol PoP and the London interconnect, packet loss appears. Not total loss. Not random noise. A consistent 8.3% over sixty cycles, with latency jumping from 12ms to 340ms on affected packets. He runs it again. Same result.
Tomasz opens ServiceNow and creates an internal incident. He cross-references the PRTG sensors on the BT circuit — green, because PRTG is pinging the circuit endpoint, not the transit hop. The monitoring missed it because the fault is one hop beyond Kestrel's circuit, inside BT's transit network.
Eight percent packet loss at Layer 3 explains the symptom completely. TCP detects lost packets via sequence numbers and retransmits them, but retransmission takes time. On a latency-sensitive application like Outlook Online, that cumulative delay produces exactly the fifteen-second stalls users described. The 401 re-authentication prompts follow: Outlook times out waiting for data, drops the connection, and forces a re-auth on reconnect. The L1 analyst's TLS hypothesis was a reasonable read of the surface symptom. It was wrong.
Layer 4 — Transport. The Transport layer provides end-to-end delivery between processes. TCP offers reliable, ordered delivery via sequence numbers and retransmission; UDP is connectionless and best-effort. Port numbers live here. A firewall inspecting TCP state tables operates at Layer 4. Tomasz runs tcpdump -i eth0 -nn 'tcp and host outlook.office365.com' on the edge router. TCP retransmissions are clearly visible — segments sent, no ACK received, retransmit after the RTO timer expires. This is exactly what Layer 3 packet loss looks like one floor up. TCP window sizes are normal; no flow control issue. Layer 4 is doing its job, coping with what Layer 3 is handing it.
Layer 5 — Session. The Session layer manages the lifecycle of a communication session: establishing, maintaining, and tearing down. In modern practice much of this is absorbed into application protocols, but VPN tunnel state and RPC session management have Session layer characteristics. Tomasz checks the VPN tunnel from the client site — up, stable, no renegotiations in the past two hours. Not the fault.
Layer 6 — Presentation. The Presentation layer handles translation, encoding, and encryption. It is responsible for ensuring that data produced by one system can be understood by another. This is where character encoding lives (ASCII to UTF-8), where data compression happens (JPEG, gzip), and where TLS encryption is negotiated. This last point is the most common exam trap in the OSI topic: TLS is a Layer 6 function. The client application that calls HTTPS is a Layer 7 concern. The encryption and decryption of the bytes in transit happens at Layer 6. The protocol that happens to travel inside TLS — HTTP, SMTP, whatever — is an Application layer protocol. They are on different floors.
Tomasz spends four minutes at Layer 6, because the L1 analyst's note about 401 re-authentications pointed here. He runs a Wireshark capture on a laptop connected to the client's network and filters for TLS handshake traffic to the Microsoft IP range. The ClientHello and ServerHello complete cleanly. The server certificate is valid, not expired, chain intact. Cipher suite negotiation succeeds — TLS 1.3, AES-256-GCM. No handshake failures, no certificate errors, no version downgrades. The Presentation layer is healthy. The 401 prompts are not a TLS failure; they are Outlook timing out on a TCP session that is stalling because of the Layer 3 packet loss, then triggering a re-authentication on session re-establishment. The symptom looked like Layer 6. The cause is two floors below.
He notes it in the ServiceNow ticket: "L6 (TLS) verified clean via Wireshark. 401 re-auth is a session timeout consequence of Layer 3 packet loss." The L1 analyst will read this. The explanation is deliberate.
Layer 7 — Application. The Application layer is where user-facing protocols live: HTTP, DNS, FTP, SMTP, LDAP. It is what applications implement and what users touch. Tomasz reviews the Outlook client logs from the Hargreaves admin tenant. HTTP responses are 200 where they resolve. DNS resolution times are sub-10ms. No Application layer errors. The application is correctly formed. It is simply waiting too long for packets to arrive.
At 11:14, Tomasz opens a BT Wholesale fault ticket with the full MTR report — sixty-cycle packet loss data, hop-by-hop. BT's NOC acknowledges within twenty minutes. By 13:30 they have found a misconfigured ECMP entry on a transit router at their Bristol PoP, directing a subset of flows down a degraded peering path. They push a routing fix. Tomasz re-runs the MTR. Packet loss at hop seven: 0.0%.
He updates the ServiceNow ticket, closes the incident, and sends a brief to the Hargreaves account manager. Root cause: Layer 3 routing fault on BT transit infrastructure, peering path between Bristol and London. Resolution: BT corrected ECMP routing configuration. Total duration: three hours thirty-four minutes.
At 14:00, a junior engineer, Daria, stops by Tomasz's desk. She has a topology diagram open on her screen and a slightly lost look. "I keep mixing up the layers," she says. "Is there a trick?" Tomasz writes seven words on a sticky note and hands it to her. Please Do Not Throw Sausage Pizza Away. Physical. Data Link. Network. Transport. Session. Presentation. Application. "The order matters," he says. "You always start at the bottom. If Layer 1 is broken, Layer 7 is broken too, and you'll waste an hour looking at TLS when it's just a cable."
The L1 analyst wrote "possibly a TLS issue" based on the 401 re-authentications. TLS was clean. The fault was at Layer 3. The symptom lived at Layer 7. The cause lived two layers below where the symptom pointed. You don't skip floors. — Story 03 · OSI Model
Tomasz found the fault in under two hours not because he is smarter than the L1 analyst. It is because he applied a methodology. The OSI model is a diagnostic framework. Each layer eliminates a class of problem. When you reach a layer that is broken, you stop. The fix belongs at the layer where the fault lives.
One footnote: in real-world practice engineers think in terms of the TCP/IP (DoD) model, which collapses OSI into four layers — Link (OSI 1+2), Internet (L3), Transport (L4), Application (L5+6+7). The two models describe the same reality. OSI is more precise for diagnosis and for exam questions. Know both. When the exam asks "at which layer does TLS operate," the answer is OSI Layer 6, Presentation — not Layer 7, regardless of what the TCP/IP model calls the combined upper layers.