You have now walked the path from bits to applications twice: with OSI's seven-layer map (module 3) and with TCP/IP's four-layer one (this module). Time to put them face to face and answer the questions every professional ends up asking: how exactly do the layers correspond? why are there two models and not one? which one "is the right one"? (spoiler: the question is badly posed), and where do the awkward cases fall that fit cleanly into neither — ARP, TLS, VLANs, the famous "layer 2.5"? This lesson closes module 4 with a practical thesis: OSI is the language for talking and diagnosing; TCP/IP is the blueprint of what you actually build and configure. Mastering both — and knowing how to translate between them without stumbling at the borders — is what separates those who recite layers from those who use them. We will put it to the test with real Meridiano mini-cases solved by naming the layer in both models.

1. The correspondence table, layer by layer
2. Two origins, two philosophies: committee vs running code
3. What to use for what: talk with OSI, build with TCP/IP
4. The borderline cases: where the maps wrinkle
5. Meridiano mini-cases: bilingual diagnosis
6. Module wrap-up: the map and the territory

The canonical mapping, with the protocols you already know as witnesses at each border:

Three readings of the table:

• The middle layers match one to one. Transport↔Transport and Network↔Internet are the mapping's stable zone: nobody argues about where TCP or IP goes. That is no accident — these are the layers where the real protocols defined the model (TCP/IP) and where OSI was describing what already existed.
• The extremes get compressed. At the top, TCP/IP merges 5-6-7 into Application (reasons in 04-05); at the bottom, it merges 1-2 into Network access because IP doesn't care what technology sits beneath it (04-02). OSI details the extremes; TCP/IP delegates them — upward to each application, downward to each network technology.
• The PDUs survive the change of model. Frame, packet, segment (03-01) mean the same on both maps: they are vocabulary of the territory, not of the maps. That is why "the packet isn't arriving" is an unambiguous sentence whichever model you speak.

Reminder from 04-01: there is also the 5-layer hybrid variant (Physical, Data link, Network, Transport, Application) used by almost all modern textbooks — it is exactly this table with "Network access" split in two. If you see it, you already know how to translate it.

The two models don't compete: they were born for different things, and their biographies explain everything (part of which you met in 03-01 and 04-01):

Internet culture summed it up in a celebrated motto attributed to the IETF (the body that standardizes Internet protocols): "we reject kings, presidents and voting; we believe in rough consensus and running code." Against OSI's theoretical edifice, designed by committee to be complete, TCP/IP was standardized one implementation at a time: if two programs interoperated, it was a de facto standard.

From there flow the two personalities:

• OSI is exhaustive and symmetrical: seven layers, every function in its drawer, even if the drawer sits nearly empty in practice (session and presentation, 03-06/03-07). Perfect for analyzing.
• TCP/IP is pragmatic and asymmetrical: four layers of unequal sizes reflecting where there is real standardization (the middle) and where deliberate diversity (the extremes). Perfect for building.

The coexistence of the two models is not a historical anomaly: it is a division of labor worth exploiting consciously.

OSI is the language. The entire industry numbers with OSI, even those who never implemented a single OSI protocol:

• "layer 2 switch", "layer 3 switch", "layer 7 load balancer", "layer 4 firewall" — the whole commercial catalog speaks OSI.
• "The problem is at layer 1" (a cable), "that's layer 8" (the user — trade joke included).
• Module 3's layer-by-layer diagnosis (03-05): ruling out from the bottom up demands the fine vocabulary — distinguishing session from presentation lets you say "the TLS certificate expired" (≈6) versus "the server drops connections" (≈5) with surgical precision.

TCP/IP is the blueprint. When you touch real systems, what is in front of you is the TCP/IP stack:

• Any OS's network configuration has exactly TCP/IP's pieces: interface (network access), IP/mask/gateway/routes (Internet), ports and sockets (transport), and services (application). There is no place to "configure the presentation layer".
• Module 6's traffic captures will show frame → IP → TCP → HTTP: four floors, not seven.
• Code speaks TCP/IP: the sockets API (04-04) gives you transport; the libraries (04-05) give you application. Nobody programs "against the session layer".

The final mnemonic rule: think in 4, communicate in 7. You diagnose and configure against the four-layer reality, but when you open a ticket, read a datasheet or talk to another technician, the layer number expected is OSI's.

This is where exams and interviews go wrong: protocols that don't fall cleanly into one layer. The table of usual suspects, with their practical verdict:

The underlying lesson of all these cases: layers are drawers in a conceptual filing cabinet, not laws of physics. Real protocols are designed to solve problems, and some problems live at the seams. When something doesn't fit, the useful question is not "which layer IS it in?" but "what function does it perform and which layers does it depend on?" — that one always has an answer.

Let's practice the translation with four incidents, naming the layer in both models:

Case 1 — "The printer has vanished". Marta can't print; nobody in Valencia can. Ana discovers the printer's RJ45 connector half unplugged after a desk move. Diagnosis: OSI layer 1 (physical) · TCP/IP network access layer. Telltale clue: the interface with no link (ip link would show NO-CARRIER on a PC; on the printer, the port's LED off). No upper-layer command could possibly work.

Case 2 — "The guests can see the intranet". A laptop on the guest Wi-Fi shows up on the corporate network: the AP's port on the switch was assigned to VLAN 10 instead of 20. Diagnosis: OSI layer 2 (data link) · TCP/IP network access. 802.1Q segmentation (03-03) is a matter of frames and switch ports; the IPs the guests obtained were the symptom (DHCP from the wrong VLAN), not the cause.

Case 3 — "Bilbao can't reach the intranet, but their Internet works". Jon can't open intranet.grupomeridiano.example; the name resolves fine, the ping to 192.168.10.10 dies. On the Bilbao router, the route to 192.168.10.0/24 through the VPN tunnel has vanished after a reboot. Diagnosis: OSI layer 3 (network) · TCP/IP Internet layer. The quintessential 04-03 case: no route, no delivery; the default route (Internet) remained intact, hence "everything else works".

Case 4 — "The API works, but file sync doesn't". From Bilbao the intranet works (TCP:443) but the SMB connection fails (TCP:445): immediate rejection. Same destination machine, same path, one port answers and the other doesn't: a new firewall rule on the Valencia router blocks 445 from the VPN. Diagnosis: OSI layer 4 (transport) · TCP/IP transport layer. The 03-05/04-04 signature: live host + unreachable port = look at services and firewalls, not cables or routes.

And a bonus one you already solved in 04-05: "not yet valid" certificate due to a skewed clock — OSI ≈ layer 6 (presentation: TLS validation) · TCP/IP application layer. Notice the pattern across the five cases: the OSI layer provides precision in describing; the TCP/IP layer tells you which piece of the system to touch (interface, switch, routing table, firewall, service).

This funnel — which in module 6 we will turn into a full methodology with its tools — is the OSI/TCP-IP comparison turned into muscle.

Module 4 balance sheet. You started with the history and the philosophy (04-01: ARPANET, the hourglass waist, the stack inside the OS); you went down to real interfaces (04-02), read routing tables line by line (04-03), opened sockets and connection states from the keyboard (04-04) and walked a complete intranet request, from the line of code to the DNS datagram (04-05). Today you have laid the two maps over each other and learned to translate without stumbling over ARP, TLS or layer 2.5.

The conclusion of the double journey through modules 3 and 4: OSI is the detailed map; TCP/IP is the territory with its own construction blueprint. Neither is redundant. With both mastered, no architecture remains pending — what remains is the detail postponed twice (in 02-03 and in 04-03): the fine anatomy of IP addresses. What exactly do those /24s mean? How is a network carved into subnets, and why did Meridiano choose 192.168.10.0/24 and 192.168.20.0/24? What makes it possible for those private addresses to get out to the Internet? That is module 5.

• Asking "which model is the correct one?" It is like asking whether the metro map or the street map is more correct: they describe the same thing for different purposes. OSI to communicate and analyze; TCP/IP to build and configure.
• Mapping by rote "OSI 5-6-7 = some concrete TCP/IP piece". There are no three separate pieces on the other side: it is a single application layer where each protocol organizes itself as it pleases. Forcing the split produces absurd answers ("which port does the session layer listen on?").
• Being fooled by names. TLS is not in the transport (despite its name), ICMP is not layer 4 (despite traveling inside IP), and TCP/IP's "Internet" layer works just the same on a LAN that never touches the Internet.
• Treating layers as physical law. ARP, MPLS, QUIC and company exist precisely at the seams. If a protocol doesn't fit cleanly, describe its function and its dependencies instead of forcing a number onto it.
• Numbering TCP/IP layers in an OSI context (or vice versa) without saying so. If you say "layer 3" everyone will understand network/Internet, but "layer 4" is already ambiguous if the person you're talking to counts in the 4-layer model. When in doubt, name the layer ("transport") instead of numbering it: the names are unambiguous.
• Tip: in tickets and documentation, get used to the formula symptom + named layer + suspected piece ("no connection to 445 from the VPN; transport; probable firewall rule"). It forces layered thinking and spares your reader a ping-pong of questions.

1. Translate each item to its layer in BOTH models (layer name, not just number): (a) the 802.1Q VLAN tag on the frame that separates corporate and guests on the Valencia switch; (b) the sequence number the intranet server uses to reorder the segments of a file upload; (c) the TTL decremented while crossing the VPN tunnel; (d) the Content-Type: application/json header of the /api/proyectos response; (e) the key negotiation of the TLS handshake with the intranet.

2. A vendor advertises: "next-generation firewall with layer 7 inspection". The Valencia router's current firewall filters by IP and port. Explain: (a) which OSI layers the current firewall works at; (b) what the "layer 7" one can do that the current one can't, with a concrete example involving Meridiano's intranet HTTPS traffic; (c) why that inspection collides with TLS and what it implies.

3. Three incidents at Meridiano; for each one, name the layer in both models and the first check you would perform: (a) after moving the AP, phones see the Wi-Fi network with a weak signal and stutter along, but everything over cable is perfect; (b) the .10.10 server answers ping from Bilbao, but ssh 192.168.10.10 returns "connection refused" instantly; (c) the intranet loads, but the projects page shows corrupted characters (á where it should say á).

1. (a) OSI: data link (2) · TCP/IP: network access — the tag lives in the Ethernet frame. (b) OSI: transport (4) · TCP/IP: transport — sequence numbers are TCP mechanics (02-04). (c) OSI: network (3) · TCP/IP: Internet — the TTL is an IP header field (02-03). (d) OSI: presentation (6), with application nuances · TCP/IP: application — declaring the data's format is classic presentation work, carried in an HTTP header. (e) OSI: ≈ session/presentation (5-6) · TCP/IP: application — the TLS borderline case: establishing the secure session and agreeing on the encryption.

2. (a) IP filtering works at OSI 3 (network) and port filtering at OSI 4 (transport) — in TCP/IP, the Internet and transport layers. It is the classic "layer 3/4" firewall. (b) A layer 7 one inspects the application content: it could, for example, allow GET /api/proyectos but block requests to /admin from the guest VLAN, or distinguish legitimate web traffic from another protocol disguised on port 443 — decisions impossible when looking only at IPs and ports (remember: the port is convention, not guarantee). (c) With TLS, the HTTP content travels encrypted: the firewall cannot read it unless it acts as a TLS intermediary (decrypting and re-encrypting with its own certificates installed on the machines), which adds complexity, cost and privacy considerations. It is the permanent tension between inspection and encryption.

3. (a) OSI: physical (1) · TCP/IP: network access — weak radio signal is the physical medium in its purest form. First check: signal strength/coverage at the AP's new location (and obstacles). (b) OSI: transport (4) · TCP/IP: transport — ping OK (layer 3 healthy) + immediate rejection = nobody listening on 22 or a firewall rejecting (03-05). First check: ss -tlnp | grep :22 on the server — is sshd's LISTEN there? (c) OSI: presentation (6) · TCP/IP: application — á is the signature of UTF-8 text interpreted as Latin-1 (03-07): the bytes arrive perfectly; they are decoded wrongly. First check: the declared encoding (Content-Type: ...; charset=) against the actual encoding of the data the API serves.

You now hold both maps and the dictionary between them: the layer-by-layer correspondence (with the stable center — transport and network/Internet — and the compressed extremes), the two philosophies explaining why OSI remained the language and TCP/IP the reality (rough consensus and running code), the operational rule "think in 4, communicate in 7", and the handling of the borderline cases — ARP at the 2/3 seam, TLS as a false resident of the transport, layer 2.5 and company — which is where understanding is told apart from memorization. Meridiano's mini-cases have taught you the joint use: OSI gives the diagnosis its precision; TCP/IP points at the piece you must touch. And with that, module 4 closes: you master the map and the territory. The next step is the detail we have deliberately postponed since module 2: the anatomy of IP addresses — what exactly a /24 hides, how subnets like Valencia's and Bilbao's are designed, and how private addresses get out to the Internet. Welcome to module 5: IP addressing and subnets.