We arrive at layer 3 of the OSI model, the network layer: the one that breaks the local barrier. Everything seen so far — signals, frames, MACs, switches, VLANs — works inside one network; the network layer is what lets Marta's packet leave Valencia, cross the VPN and reach the Bilbao printer, or lets any machine reach a server on the other side of the world. In module 2 (lesson 02-03) you already met its main characters: the IP packet, the TTL, the default gateway, the Valencia router's routing table and ICMP with ping. We won't repeat that material here: we will study layer 3 as a layer of the model — its services, its emblematic device, the types of routing and its role in diagnosis — leaning on those examples as ground already conquered.

1. The network layer's role within the model
2. Service 1: logical addressing
3. Service 2: routing
4. Service 3: fragmentation
5. The router as a layer 3 device
6. Static and dynamic routing
7. Quality of Service (QoS), a quick brushstroke
8. Layer 3 diagnosis: the gateway on Jon's PC

Layer 3's OSI contract:

• What it receives from above (layer 4): a segment that must reach a process on another machine, wherever it may be — same desk or same planet.
• What service it offers layer 4: end-to-end packet delivery across different networks, choosing the path. Careful: in IP, this delivery is "best effort": layer 3 guarantees neither that the packet arrives, nor that it arrives in order; if reliability is needed, layer 4 provides it (as TCP does).
• What it uses from below (layer 2): local delivery, hop by hop, inside each network the packet crosses.
• Its PDU: the packet. Its addresses: the IPs (logical addressing).

The right mental image is a chain of local stretches stitched together by routers: the packet (layer 3) travels intact end to end, while on each stretch it is carried by a brand-new frame (layer 2). You already saw it with the ping's journey to Bilbao in 02-03 — the TTL arriving at 62 after subtracting the two routers was the visible signature of those hops.

Why do we need IP addresses if we already have MACs? Because they are addressing schemes of opposite natures, and comparing them is the best way to understand the word logical:

Structure is the key. A MAC says nothing about where the machine is; an IP does: 192.168.20.7 declares "network 192.168.20.0/24 (Bilbao), host 7". Thanks to that hierarchy, the Valencia router doesn't need to know every machine in Bilbao: one entry in its table covers the entire 192.168.20.0/24 network, just as the postal service routes by postcode without knowing every resident. You worked through the network/host split with /24 in 02-03, and subnet masks in depth arrive in module 5; here it is enough to hold on to the principle: logical addressing is hierarchical, and that hierarchy is what makes routing scalable.

The second service is deciding the path: given a packet for network X, which way do I send it? Each router answers by consulting its routing table (remember the Valencia router's in 02-03: destination network → outgoing interface / next hop). The process, seen through OSI:

1. A frame arrives; the router decapsulates it (climbing from layers 1-2 to layer 3) and reads the packet's destination IP.
2. It looks up the most specific route in its table matching that destination network (if there is none, it uses the default route, if one exists; if not that either, it discards the packet and reports back with an ICMP message).
3. It decrements the TTL (and discards the packet if it hits 0 — the anti-loop safeguard you already know).
4. It re-encapsulates the packet in a new frame for the outgoing medium and transmits it toward the next hop.

And so on, hop by hop, until the destination network, where the last router delivers the packet directly to the final machine. Each router decides only the next hop: nobody plans the complete route in advance. It is a decentralized system, and that is why it withstands failures: if one path goes down and the router knows another, traffic diverts.

At Meridiano the routing is tiny but complete: the Valencia router knows its local network, the route toward 192.168.20.0/24 over the VPN tunnel, and the default route to the Internet. Three possible decisions; an Internet carrier's routers handle hundreds of thousands, but the mechanism is identical.

Each layer 2 technology imposes a maximum frame size (the MTU, maximum transmission unit: in Ethernet, 1500 bytes of payload). What happens if a layer 3 packet doesn't fit in the next stretch's frame? The network layer offers fragmentation: splitting the packet into fragments that do fit, each traveling as an independent packet, which the final destination (not the intermediate routers) reassembles.

The conceptual idea is enough, with two practical notes:

• Fragmentation is a last resort, not a virtue: it multiplies work and, if one fragment is lost, the entire packet is lost. Modern systems prefer to avoid it by discovering in advance the maximum size that fits along the whole path and adjusting their sends.
• You will run into it in real life precisely where there are tunnels: Meridiano's VPN adds its own headers to each packet, so a packet that filled the frame no longer fits when entering the tunnel. The typical symptoms ("ping works between sites but large transfers hang") are a support classic; remember that they exist and that their cause lives at layer 3.

The router is to layer 3 what the switch is to layer 2, and comparing them pins down the model's boundaries:

It is also worth recalling the role of the default gateway seen in 02-03, now in OSI vocabulary: it is the local router's address that every machine has configured, and it embodies the most basic layer 3 decision a host makes: "is the destination on my network? → deliver directly via layer 2; is it outside? → hand it to my gateway". Every machine with an IP makes this decision for every packet it sends. Hold on to it: it is the centerpiece of this lesson's diagnostic case.

Home and small-business routers (like Meridiano's) do many other things besides (NAT, DHCP, firewall, VPN termination point...), but their OSI essence is this: deciding each packet's next hop between networks.

Where do the routes in the table come from? There are two philosophies:

• Static routing: the administrator writes the routes by hand. It is simple, predictable and free of extra traffic, but it doesn't react to changes (if a link goes down, the route keeps pointing into the void until someone fixes it) and it doesn't scale: maintaining hundreds of routers' tables by hand would be unworkable.
• Dynamic routing: routers tell each other which networks they know via routing protocols, and compute the best routes automatically, recalculating them when something changes (a link goes down, a new network appears).

Routing protocols exist such as OSPF (common inside organizations) and BGP (the one stitching together the networks of the entire Internet). We won't develop them in this course — they belong to a more advanced level —; it is enough to know they exist, what they are for, and this decision rule:

At Meridiano, indeed, everything is static: the Valencia router has a fixed route toward 192.168.20.0/24 over the VPN, and Bilbao's has its mirror image toward 192.168.10.0/24. Simple and sufficient.

One last conceptual layer 3 service: not all traffic suffers congestion equally. If the Valencia Internet link saturates, a download doesn't mind waiting half a second longer; a video call does — choppy voice is unusable. Quality of Service (QoS) is the set of mechanisms by which the network prioritizes some traffic over other traffic: packets can carry a priority marking in their header, and routers, when managing their outbound queues, dispatch what is marked as sensitive (voice, video) first and make the tolerant stuff wait (downloads, backups).

Meridiano example: the weekly video calls between Valencia and Bilbao share the VPN link with the nightly backups and file transfers. If they ever coincide, without QoS Jon's video call stutters; with QoS, each site's router gives right of way to the video call's packets and the backup simply takes a little longer. We stay at the concept: QoS = prioritizing in router queues according to markings on packets; configuring it is material for advanced courses.

A complete practical case, in the style of the previous lesson but one floor up.

Symptom: Jon, in Bilbao, calls support: "I can print on the printer here and I can see my colleague's computer, but neither the Valencia intranet nor any Internet page opens for me. Everything works for everyone else in Bilbao."

First layer-based analysis: he prints and sees machines on his network → layers 1 and 2 work, and so does his local IP. Everything outside 192.168.20.0/24 fails, and only for him. A "local yes, remote no" pattern points straight at layer 3, and specifically at the decision that separates local from remote: the default gateway.

Diagnosis, with the commands you already know from 02-03:

Interpretation: Jon's PC, faced with a remote destination, hands the packet to its configured gateway... which is 192.168.20.254, an address where there is no router (or there is a machine that doesn't route). The packets leave the PC, layer 2 delivers them (or ARP doesn't even resolve that address) and everything dies right there. Local traffic works because for destinations on his own network the gateway plays no part: delivery is direct via layer 2. The symptom fits to the millimeter.

Cause and solution: Jon's PC had its IP configured by hand from an old test (everyone else gets theirs via DHCP, with the correct gateway 192.168.20.1). The machine is returned to automatic configuration, receives the correct gateway, and everything works.

OSI takeaway: the failure pattern delimits the layer. "Nothing works" → start at layer 1. "Local yes, remote no" → layer 3, and the first suspect is the gateway. "Everything connects but one specific service fails" → layers 4-7, as we will see in the coming lessons.

• Confusing the scope of MAC and IP. MACs never cross a router; source and destination IPs do (they travel intact end to end, except for NAT, which we will see in module 5). If you catch yourself saying "the Valencia server's MAC reaches Bilbao", re-read the packet's journey in 02-03.
• Believing layer 3 guarantees delivery. IP is best effort: packets can be lost, duplicated or arrive out of order. Reliability, for whoever needs it, is contracted with layer 4 (TCP). Many diagnostic misunderstandings are born of expecting promises from layer 3 it never made.
• Forgetting to check the gateway (and the mask) when reviewing an IP. A correct IP with a wrong gateway or mask produces the treacherous "local works, remote doesn't". ipconfig / ip addr + ip route must be read in full, not just the IP line.
• Thinking ping "tests the application". A successful ping only certifies layers 1-3 between two points. The intranet can still fail because of DNS, a stopped web service or a certificate: upper layers. Ping delimits; it doesn't conclude.
• Tip: memorize the host's decision — destination on my network: direct delivery; destination outside: to the gateway. Half the layer 3 problems in a small business are that decision running on misconfigured data.
• Tip: in small networks, prefer static routes and document each one (destination, next hop, why it exists). Dynamic routing shines where there is scale and redundancy, not in two sites with one tunnel.

Exercise 1. A video call packet leaves Jon's PC (192.168.20.7) toward the Valencia server (192.168.10.10), crossing: Bilbao switch → Bilbao router → [VPN] → Valencia router → Valencia switch → server. (a) How many distinct frames are created along the way (not counting the inside of the tunnel)? (b) How many distinct IP packets, from the endpoints' perspective? (c) Which two packet fields do you know change along the way, and who changes them?

Exercise 2. Meridiano opens a third site in Seville (network 192.168.30.0/24) connected by VPN to Valencia (not directly to Bilbao; Bilbao↔Seville traffic will pass through Valencia). (a) Which new static routes does the Valencia router need? (b) And Bilbao's? (c) Would you recommend moving to dynamic routing because of this? Justify.

Exercise 3. Ana, in Valencia, can browse the Internet normally but can't reach anything in Bilbao (neither the printer nor the router 192.168.20.1); for the rest of Valencia everything works, Bilbao included. Apply layer-based reasoning: (a) which layers can you consider good on Ana's machine, and why? (b) Does the pattern point to Ana's gateway, as in Jon's case? (c) What would you check?

Solution 1. (a) Four frames across the sites' networks: Jon's PC→switch→Bilbao router (1, the switch creates no new frames, it only switches them), Bilbao router→tunnel (the frame is rebuilt as the VPN comes into play; we count the Bilbao stretch as 1 already sent), Valencia router→switch→server (1)... being strict about "each router destroys and creates a frame": frame 1 on the Bilbao network (Jon→Bilbao router), the frame(s) of the router-to-router stretch through the tunnel, and the final frame on the Valencia network (router→server); the essential point: one new frame per layer 2 stretch, three visible stretches here. (b) A single IP packet end to end (source 192.168.20.7, destination 192.168.10.10), traveling encapsulated inside the tunnel between routers. (c) The TTL (each router decrements it: two hops, as the TTL=62 in 02-03 gave away) and, in consequence, the header checksum field that each router recalculates when modifying the TTL. The source/destination IPs do not change.

Solution 2. (a) Valencia adds one route: 192.168.30.0/24 → VPN tunnel to Seville. (b) Bilbao also adds one route: 192.168.30.0/24 → VPN tunnel to Valencia (its only path to Seville runs through there; in fact, if Bilbao already used Valencia as its default exit for everything non-local, it might not even need an explicit entry). The Seville router will need routes toward 192.168.10.0/24 and 192.168.20.0/24 via Valencia. (c) Not yet: three sites in a star around Valencia are still a handful of stable routes; static remains simpler to operate and audit. Dynamic would start to pay off with more sites, redundant links between them, or frequent changes.

Solution 3. (a) Layers 1-2 are fine (she reaches her network and browses), and her layer 3 is partially verified: she reaches the Internet, so her IP, mask and gateway work. (b) No: if Ana's gateway were wrong, everything remote would fail, Internet included. Here only one specific remote destination fails (the Bilbao network) and only for Ana. (c) I would check what makes Ana different from everyone else: does her PC have some old static route capturing 192.168.20.0/24 and sending it astray (route print / ip route)? Some local firewall or VPN client software on her machine interfering with that range? The pattern "one specific destination fails on only one machine" points to that machine's local configuration, not to the shared network — which is ruled out because it works for everyone else.

The network layer is what turns many local networks into a single network of networks: it contributes logical, hierarchical addressing (the IPs, with the network part that makes the whole system scalable), routing hop by hop through routing tables — populated by hand (static) or by protocols like OSPF and BGP (dynamic) —, fragmentation when a packet doesn't fit in the next stretch, and priority mechanisms (QoS) so the video call beats the backup. Its device is the router, boundary of broadcast domains and executor of the key decision every host also makes: local goes direct, remote goes to the gateway — the decision that was broken on Jon's PC. But notice what layer 3 delivers: packets to a machine, without guarantees and without knowing which of its programs they are meant for. Turning that best-effort delivery between machines into reliable conversations between processes — with ports, reassembly and flow control — is the trade of layer 4: the transport layer, next lesson.