We climb one rung up the stack: below us sit the interfaces and their links (04-02); now we enter the layer that gives the whole invention its name — the Internet layer, whose job is to get a packet from one network to another until it reaches its destination, wherever that may be. Its protagonists are old acquaintances by now: IP (02-03) and ICMP, together with the routing function (03-04). What this lesson adds is the part you haven't touched yet: the layer seen from inside a real system — reading routing tables line by line with ip route and route print, understanding the default route and metrics, and seeing what happens in practice when a packet collides with the MTU of Meridiano's VPN tunnel. It matters because the routing table is the first stop in almost any connectivity diagnosis: if the route is wrong, nothing else matters.

1. What lives in the Internet layer
2. Routing as a function of the layer
3. The routing table in practice: ip route on Linux
4. The same table on Windows: route print
5. Default route and metric
6. Fragmentation and MTU in practice: the VPN case
7. What we leave for module 5: addressing in depth

TCP/IP's Internet layer corresponds to OSI's network layer, and its central tenant is the Internet Protocol (IP), which you already dissected in 02-03: packets with logical source and destination addresses, TTL, connectionless best effort delivery. We won't repeat it; let's just recall its contract: "give me a packet and a destination address, and I will try to get it there, network by network, with no guarantees".

But IP does not live alone in this layer. It is accompanied by:

• ICMP (Internet Control Message Protocol): IP's service messenger (02-03). Since IP guarantees nothing, someone must be able to report when something goes wrong: "destination unreachable", "TTL exceeded", "fragmentation needed". ICMP travels inside IP packets, but conceptually it is part of the Internet layer, not a user of it: it exists so the layer itself can work and be diagnosed (ping and traceroute live off it; we will exploit them in module 6).
• The routing function: deciding, packet by packet, which way the journey continues. It is not a protocol but a process executed by every IP-speaking device — not just routers — using its routing table.
• Auxiliary protocols we only mention: the dynamic routing protocols (OSPF, BGP — introduced conceptually in 03-04) that fill in routing tables automatically, and IPv6 with its own ICMPv6, whose existence you already know and whose details belong to module 5.

In 03-04 you learned the idea: hop-by-hop routing, each device decides only the next step. Now the practical key: that decision is made by the kernel consulting its routing table for every packet it sends. And this holds for the Valencia router just as much as for Marta's PC: when Marta opens the intranet, her own PC runs the algorithm:

1. Look at the packet's destination IP.
2. Search my table for the most specific route that contains it (longest prefix match: the longest prefix wins).
3. That route tells me which interface the packet leaves through and, if the destination is not on my own network, which next hop (gateway) to hand it to.
4. If no route matches and there is no default route: "network unreachable" error (and, on a router, an ICMP back to the source).

Note the link with the previous lesson: every route ends by naming an interface. The routing table is the bridge between the Internet layer ("toward where?") and the network access layer ("through which door?").

Let's look at the real table of the intranet server (192.168.10.10, Linux):

Only two lines — it's a server, not a router — but every word matters. Line by line:

Line 2 (we read it first because it is the more specific one):

• 192.168.10.0/24 — the destination: any IP on Valencia's local network (the /24 you planned in 02-03).
• dev enp3s0 — outgoing interface: the server's Ethernet card (04-02).
• proto kernel — who created the route: the kernel itself, automatically, when the IP 192.168.10.10/24 was configured on the interface. That is why you never "configure" this route: it is born with the address.
• scope link — the conceptual piece: the destination is directly reachable on the link, with no gateway. To reach the printer or Marta's PC, the server doesn't go through the router: it resolves the MAC via ARP and delivers the frame directly (02-02).
• src 192.168.10.10 — which source IP to use for packets leaving through this route (relevant when a machine has several addresses).

Line 1:

• default — synonym for 0.0.0.0/0: any destination not covered by another route. It is the shortest possible prefix, so it only wins when nothing else matches.
• via 192.168.10.1 — the next hop: the Valencia router. It is, literally, the "default gateway" you saw in 02-03, now in its native form: just another entry in the table.
• proto static — it was put there by explicit configuration (or by the DHCP client), not by the kernel.

And a third precious diagnostic tool — asking the kernel what it would decide, without sending anything:

The presence or absence of via is the difference between "it's on my network" and "I need the router" — the fundamental decision this layer makes millions of times a day.

By contrast, the Valencia router's table has one extra line, and that line is the VPN:

That third route is the entire secret of site-to-site communication: "for the Bilbao network, go out through the tunnel's virtual interface". The encrypted encapsulation you already know does the rest.

On Marta's PC (192.168.10.21, Windows), the information is the same in a different outfit:

Translation keys relative to Linux:

Windows additionally shows "plumbing" routes that Linux keeps elsewhere: the loopback (127.0.0.0/8), the network's broadcast address (192.168.10.255) and the general broadcast (255.255.255.255). They are normal; don't touch them and don't be alarmed to see them.

Two concepts in the table deserve a zoom of their own.

The default route (default / 0.0.0.0 0.0.0.0) is the table's safety net: "anything I don't know where to send, I hand to this gateway, which will know more than I do". It is what turns an isolated LAN into a network connected to the world:

• On Meridiano's PCs it points to their site's router (.10.1 or .20.1).
• On Meridiano's routers it points to the carrier's router.
• On the carrier's routers it points toward the core of the Internet... where the backbone routers no longer have a default route: they hold the full Internet table (learned via BGP, as mentioned in 03-04). At some point, somebody has to know everything.

Classic symptom of its absence or misconfiguration: "I can reach the machines in my office but not the Internet or Bilbao". Local network intact (scope link route present), outside world lost — that points straight at the default route.

The metric breaks ties: if two equally specific routes lead to the same destination, the one with the lowest metric wins (lowest cost). The everyday case is a laptop with cable and Wi-Fi connected at the same time: two default routes, one per interface. Windows automatically assigns a lower metric to the cable (faster and more stable), which is why traffic prefers the cable even while Wi-Fi stays active. The layer's full decision order:

1. Specificity first: the longest prefix wins (a /24 route to 192.168.20.0 always beats default for traffic toward Bilbao, whatever the metric).
2. Metric second: it only breaks ties between equally specific routes.

In 04-02 we set up the limit: each interface declares its MTU. Now the reaction, which is this layer's responsibility. Recall from 03-04 the two options when a packet doesn't fit in the outgoing link:

• Fragment it (split it into pieces the final destination reassembles), if the packet allows it; or
• Drop it and report back with an ICMP "fragmentation needed" if the packet carries the DF (Don't Fragment) flag — which is the norm today: modern senders prefer to find out and adjust (a technique called Path MTU Discovery) rather than pay the cost and fragility of fragmentation.

Meridiano's tunnel is the perfect stage to watch this bite. tun0's MTU is 1436, smaller than the LANs' 1500. Imagine the .10 server sends Jon 1500-byte packets with DF set:

That is the healthy behavior: the ICMP arrives, the sender adjusts, nobody notices. The classic failure appears when an overzealous firewall blocks those ICMP messages: the server never receives the notice, keeps sending at 1500, and the symptom is baffling — ping works (small packets) while large transfers hang (large packets silently discarded). This is the famous "MTU black hole", one of the most common real-world VPN failures.

To avoid depending solely on ICMP there is a preventive tweak worth knowing by name: MSS clamping. The MSS (Maximum Segment Size) is the maximum segment size TCP announces to its peer during the handshake (02-04); the tunnel router can rewrite that announcement downward as the connection-establishment segments pass through, so both endpoints agree from the start on segments that, once packed into IP, fit within the tunnel's MTU. It is a pragmatic patch — the Internet layer tampering with a transport negotiation — and precisely because it is pragmatic, it is ubiquitous on VPN routers like Meridiano's.

You will have noticed that throughout this lesson we have handled prefixes (/24), masks (255.255.255.0) and "private" networks (192.168.x.x) with the intuitive understanding from module 2. That is enough to read routing tables, but behind it lies a world with rules of its own: how exactly an IPv4 address is structured, how subnets are calculated and carved to measure (what if Meridiano opens a third site and wants to slice its address space precisely?), why those private addresses need NAT to get out to the Internet, and how IPv6 reshuffles the entire game. All of that is exactly module 5, and we won't get ahead of ourselves: just remember that addressing is the other half of this layer, big enough to deserve its own module.

• Believing only routers have a routing table. Every IP device has one and consults it on every send. Many "network" problems are actually an incorrect routing table on the machine itself.
• Forgetting the longest prefix match. The table is not read top to bottom: the most specific route wins. A wrong /24 route "hijacks" traffic even if the default route is correct — a classic after installing a VPN client that injects routes.
• Mistaking "On-link"/absence of via for an error. It means direct delivery on the local network, without a gateway. It is exactly right for your own /24.
• Diagnosing "no Internet" without looking at the default route. "I can see the printer but not the web" is almost always a missing/wrong default route or its gateway being down. ip route / route print before rebooting anything.
• Blocking all ICMP "for security". ICMP is not just ping: it carries the notices Path MTU Discovery needs. Filtering it wholesale creates MTU black holes — the "the VPN works, but big files don't" failure.
• Tip: learn to use ip route get <destination>: it asks the kernel for its exact decision for a specific destination, without generating traffic. It is the fastest way to verify "which way would this packet go out?".

Using the Valencia router's table shown in the lesson (three routes: default via carrier dev wan0; 192.168.10.0/24 dev lan0; 192.168.20.0/24 dev tun0), state the outgoing interface and next hop (if any) for packets destined to: (a) 192.168.10.21 (Marta's PC), (b) 192.168.20.5 (Jon's PC), (c) 93.184.216.34 (a web server on the Internet), (d) 192.168.30.7 (a network that doesn't exist at Meridiano).

Ana's laptop shows two default routes in route print: one via Ethernet (gateway 192.168.10.1, metric 25) and another via Wi-Fi (gateway 192.168.10.1, metric 50). (a) Which interface does her Internet traffic leave through, and why? (b) Ana unplugs the cable: what happens to her browsing? (c) Why is the metric of these two routes irrelevant as the first criterion for reaching the .10 server?

From Bilbao, Jon can ping the .10 server and open lightweight intranet pages, but downloading an 8 MB PDF always hangs. The administrator discovers that Valencia's perimeter firewall drops all inbound and outbound ICMP traffic. Explain the complete failure chain (which packets die, which notice never arrives, why ping still works) and propose two different solutions.

Exercise 1: (a) Route 192.168.10.0/24 dev lan0: leaves through lan0, with no next hop (direct delivery via ARP). (b) Route 192.168.20.0/24 dev tun0: leaves through the VPN tunnel toward the Bilbao router. (c) No specific route matches → default: leaves through wan0 toward the carrier's router. (d) Also falls into default and leaves through wan0: the Valencia router doesn't know that network "doesn't exist"; it will hand it to the carrier and some router along the path will eventually return an ICMP destination unreachable. Moral: the default route catches everything unknown, whether it exists or not.

Exercise 2: (a) Via Ethernet: both routes are equally specific (0.0.0.0/0), so the metric breaks the tie and 25 < 50. (b) The Ethernet route disappears (the interface loses its carrier signal, 04-02) and traffic falls back to the Wi-Fi default route; browsing continues, perhaps a bit slower — established connections may drop when the path changes, but new ones flow. (c) Because for 192.168.10.10 there is a more specific route (192.168.10.0/24, "On-link") that wins by longest prefix match before the metric comes into play; the metric only breaks ties between equally specific routes (here, between the two local routes if both interfaces are on the same /24).

Exercise 3: Failure chain: (1) the .10 server responds to the download with large packets (1500 bytes, DF set); (2) the Valencia router cannot fit them into tun0 (MTU 1436) and drops them, generating the ICMP "fragmentation needed"; (3) the firewall kills that ICMP, so the server never finds out and retransmits equally large packets over and over → hung connection (MTU black hole). ping works because its packets are small (tens of bytes) and fit in the tunnel with room to spare; lightweight pages, similarly. Solutions: (1) fine-tune the firewall to allow at least the "fragmentation needed" ICMP messages (no need to open up all of ICMP), restoring Path MTU Discovery; (2) enable MSS clamping on the tunnel routers, so both endpoints negotiate segments that fit tun0's MTU right from the handshake. (A third, less elegant path: lower the MTU on the end machines.)

The Internet layer is the heart of TCP/IP: IP delivers with no guarantees, ICMP speaks up when something goes wrong, and the routing function — executed by all devices, not just routers — decides every hop by consulting the routing table by most-specific prefix and metric. You can now read that table in both of its dialects (ip route, route print), recognize the default route as the border between "my network" and "the world", and anticipate the collision between large packets and the VPN tunnel's MTU, with ICMP and the MSS as shock absorbers. You also know what we have deliberately postponed: the fine anatomy of addresses and subnets, which will fill module 5. Before that, we keep climbing the stack: the next stop is the transport layer, where we stop moving packets between machines and start connecting processes to each other — with sockets, connection states and the TCP/UDP decisions seen from a developer's keyboard.