The previous lesson ended at a border: when Marta's PC sends data to Bilbao, her Ethernet frame dies at the Valencia router, because MAC addresses and link protocols never leave the local segment. From there, the family we study today takes over: the network protocols, whose mission is to carry packets between different networks, choose the path, and raise the alarm when something goes wrong. The undisputed star is IP (Internet Protocol), the protocol that gives the Internet its name and without which it would not exist; alongside it comes ICMP, its error-and-diagnostics messaging service (the one behind the ping we already used in module 1). In this lesson we will open up the IP packet to see its syntax, finally understand with rigor what an IP address is (its network part and its host part), discover how a router chooses the path with its routing table, and follow a Meridiano packet on its full journey from Valencia to Bilbao over the VPN.

1. The mission of network protocols: joining networks
2. IP: the protocol that moves the Internet
3. Inside the IP packet
4. IP addresses with rigor: network part and host part
5. Routing: how a router chooses the path
6. The default gateway
7. ICMP: the network's service messages
8. Guided case: a packet from Valencia to Bilbao over the VPN

The Internet is not "a network": it is a network of networks — millions of local networks like Valencia's and Bilbao's, interconnected. Network protocols exist so a packet can be born on any one of them and die on any other, crossing intermediate networks along the way that know neither the sender nor the receiver.

To do that, they solve three problems the data link cannot:

• Universal addressing: you need a logical, hierarchical address (the IP address) that says which network a machine is on, not just who it is. The MAC identifies the network card, but says nothing about where it is: it's like a person's national ID number versus their postal address.
• Routing: at every junction along the way, someone (a router) must decide where to forward the packet to bring it closer to its destination.
• Problem notification: if a packet cannot be delivered, the network must be able to tell the sender (ICMP's job).

Picking up the postal analogy: the data link was delivery within the neighborhood; the network protocols are the postal system between cities: they sort by postal code (the network part of the IP), route from office to office (from router to router), and return the letter stamped "addressee unknown" when appropriate (ICMP).

IP (Internet Protocol) is the universal network protocol: everything that travels across the Internet — and across Meridiano's LANs — travels inside IP packets. Its dominant version is still IPv4 (32-bit addresses, the 192.168.x.x ones we've been using); its successor, IPv6, will be introduced in lesson 05-04. Here we will work with IPv4.

Two design decisions define IP's character, and they are worth understanding because they explain the rest of the stack:

• IP is connectionless: each packet travels on its own, carrying its full addresses, with no prior "established call". Two packets from the same file may even take different paths and arrive out of order.
• IP is "best effort": it does everything it can to deliver each packet, but guarantees nothing: not delivery, not ordering, not the absence of duplicates. If a router gets congested, it drops packets without apology.

A protocol that can lose data, at the foundation of the entire Internet? Yes — and it is a stroke of genius: maintaining guarantees at every junction of the network would be hugely expensive and slow. IP stays simple and fast, and the guarantees are added only where they are needed and only at the endpoints, which is exactly TCP's job (lesson 02-04). Each family sticks to its own business.

As we did with the Ethernet frame, let's dissect the syntax of the IP packet (simplified to its essential fields):

Three fields deserve detailed comment:

• Source IP and destination IP travel end to end without changing (setting aside NAT, which we cover in lesson 05-03). Compare that with the frame's MACs, which change on every hop: it is the key difference between the two families.
• Protocol is the equivalent of Ethernet's "Type" field, one level up: it tells the receiver whom to hand the data to after decapsulating (TCP, UDP, ICMP...). The encapsulation from lesson 02-01 keeps clicking into place, piece by piece.
• TTL (Time To Live) is insurance against zombie packets: it leaves the sender with a value (typically 64 or 128) and every router that forwards it decreases it by 1. If it reaches 0, whichever router is holding it drops it and notifies the sender with an ICMP message. Without TTL, a configuration error that created a loop between routers would fill the network with packets spinning forever.

In module 1 we introduced the IP address as "the number that identifies a machine on the network". Time to sharpen that up: an IPv4 address is 32 bits, written as four numbers from 0 to 255 separated by dots (192.168.10.21), and internally it splits into two parts:

• The network part: the leftmost bits, shared by every machine on the same network. It is the "postal code".
• The host part: the rightmost bits, which distinguish each machine within that network. It is the "street number".

Where does one part end and the other begin? That is what the subnet mask accompanying every IP tells you. For now, its most common form in small businesses is all we need: 255.255.255.0 (also written /24), meaning the first three numbers are the network and the fourth is the host. The in-depth study of masks and subnetting comes in lesson 05-02; the /24 is more than enough for this whole module.

Here is Grupo Meridiano's addressing plan:

The operational consequence is immediate, and it is the decision every host makes before sending any packet:

This simple comparison is the hinge between lessons 02-02 and 02-03: inside the network, the data link rules; outside, routing begins.

A router is a machine with at least two network interfaces, each on a different network, whose job is to forward packets from one to the other, bringing them closer to their destination. To decide which way, it consults its routing table: a list of rules of the form "to reach such-and-such network, go out this way".

This is the (simplified) routing table of the Valencia router, which has three interfaces: the office LAN, the Internet connection and the VPN tunnel to Bilbao:

How to read it, row by row:

• 192.168.10.0/24 → connected: "the Valencia network is plugged directly into me; I deliver the frame to those machines myself" (using ARP, like any host).
• 192.168.20.0/24 → VPN tunnel: "anything bound for Bilbao goes through the tunnel". This route is the embodiment of the logical point-to-point link we drew in module 1's topology: as far as the routing table is concerned, the VPN is simply one more interface through which network 192.168.20 can be reached.
• 0.0.0.0/0.0.0.0 → ISP router: the default route, which means "any other network": everything that doesn't match the rows above heads out to the Internet. Without it, the router would only know its own two networks and would drop everything else.

The router's algorithm for every packet it receives is always the same:

1. Read the packet's destination IP.
2. Look up the most specific matching row in the table (the default route only wins if nothing else matches).
3. Forward the packet out the indicated interface, subtracting 1 from the TTL.
4. If no row matches and there is no default route, drop the packet and report it via ICMP.

In a small business like Meridiano the routes are written by hand (static routing): they are three rows and they never change. On large networks and on the Internet, routers exchange routes automatically using dynamic routing protocols (OSPF, BGP...), which are beyond the scope of this introductory course; it is enough to know they exist and that they do at planetary scale what we do here with three lines.

Hosts have their own miniature routing table too, almost always reduced to a single decision: the default gateway is the IP of the router to which the machine hands all traffic bound outside its local network. It is the piece of data that, together with the IP and the mask, completes any machine's minimum network configuration:

The three values tell the whole story: "I am host .21 on network 192.168.10.0/24, and anything not meant for my network goes to 192.168.10.1". A machine with a correct IP and mask but no gateway works perfectly on its LAN... and is blind to everything else: no Bilbao, no Internet. It is one of the most frequent "mystery" faults in support work.

IP needs a companion to report problems: ICMP (Internet Control Message Protocol). It does not carry application data; it carries control and error messages between machines and routers. It is the protocol at work whenever the network tells you something about itself. Its most important messages:

The ping we met in module 1 is, under the hood, pure ICMP messaging: it sends echo requests and times the echo replies. From Marta's PC to the Bilbao printer:

Now we can read this output with fresh eyes:

• time=38ms: the round-trip latency to Bilbao (compare it with the typical <1 ms inside the LAN: the VPN tunnel over the Internet makes itself felt).
• TTL=62: the printer replied with an initial TTL of 64, and the return packet crossed 2 routers (64 − 62): Bilbao's and Valencia's. A ping's TTL is a free clue to how many hops lie between you and the destination.
• If instead of replies we saw Request timed out (nothing answered) or Destination host unreachable (an ICMP destination unreachable), we would already know how to tell apart "the packet vanishes in silence" from "someone is actively telling me there is no path": two different faults. The full troubleshooting methodology arrives in module 6.

Let's put together every piece of the module so far. Marta (192.168.10.21) sends a document to the Bilbao printer (192.168.20.40). A packet's complete journey:

1. Decision at Marta's PC: it compares 192.168.20.40 with its own network 192.168.10.0/24 → different network part → remote destination → the packet must be handed to the gateway, 192.168.10.1.
2. Local link in Valencia: the PC resolves the router's MAC via ARP (not the printer's: ARP doesn't cross networks) and builds the frame: destination MAC = Valencia router, containing the packet source IP 192.168.10.21 → destination IP 192.168.20.40. The Valencia switch delivers it to the router out its port 1.
3. Decision at the Valencia router: it decapsulates the frame, reads the destination IP, checks its table: 192.168.20.0/24 → VPN tunnel. It subtracts 1 from the TTL and forwards the packet through the tunnel. (Internally, the VPN encrypts the packet and sends it over the Internet to Bilbao, but as far as our packet is concerned the tunnel is a simple point-to-point link, just as we drew it in module 1's logical topology.)
4. Decision at the Bilbao router: it receives the packet through the tunnel, reads the destination IP, checks its table: 192.168.20.0/24 → connected. It subtracts 1 from the TTL, resolves the printer's MAC via ARP and builds a new frame for the Bilbao segment.
5. Final delivery: the Bilbao switch delivers the frame to the printer, which decapsulates and passes the data up to the upper protocol (the Protocol field of the IP header).

The observation that sums it all up: the IP addresses (source and destination) never changed during the whole journey; the frames and the MACs were created and destroyed on every leg. IP is the whole journey; the data link, each stage.

• Saying "the switch routes" or "the router is on my network... and that's that". Precise vocabulary: the switch switches frames within one network using MACs; the router routes packets between networks using IPs. They are different operations on different data units.
• Forgetting (or mistyping) the gateway. The unmistakable symptom: the machine sees its LAN neighbors but can't get out to other networks. Before suspecting the VPN or the ISP, an ipconfig/ip addr confirms the three basic settings in seconds.
• Expecting IP to guarantee delivery. IP is best effort by design: it may drop, duplicate and reorder. If your application needs reliability, TCP will provide it (next lesson), not IP. It is not a defect: it is the stack's division of labor.
• Misreading a failed ping. A machine not answering ping does not always mean it is down: many firewalls deliberately drop ICMP. A ping that does answer is reliable information; one that doesn't is only a hint.
• Tip: get in the habit of looking at the TTL in ping replies. Values close to 64 or 128 minus a few hops say "nearby"; heavily reduced values say "far away". It is free diagnostics with every ping you fire.

Exercise 1. Classify these sends from Jon's laptop in Bilbao (192.168.20.12/24, gateway 192.168.20.1) as local (direct delivery via ARP) or remote (handed to the router), justifying each with the network part: a) 192.168.20.40 (Bilbao printer); b) 192.168.10.10 (Valencia file server); c) 203.0.113.80 (web server on the Internet); d) 192.168.20.1 (the router itself).

Exercise 2. Write the routing table of the Bilbao router (interfaces: Bilbao LAN, VPN tunnel to Valencia, Internet uplink), following the format of this lesson's Valencia router table. Which row would it use for a packet addressed to 192.168.10.10? And for one addressed to 198.51.100.7?

Exercise 3. From Marta's PC, ping 192.168.20.40 returns replies with TTL=62, and ping 192.168.10.10 (the file server) returns TTL=64. Both destinations start with an initial TTL of 64. How many routers does each reply cross, and why does that fit Meridiano's topology?

Solution 1:

• a) Local: 192.168.20.40 shares its network part (192.168.20) with Jon → ARP and direct delivery through the Bilbao switch.
• b) Remote: network part 192.168.10 ≠ 192.168.20 → handed to the Bilbao router, which will send it over the VPN.
• c) Remote: 203.0.113.80 does not belong to 192.168.20.0/24 → to the router, which will push it out the default route toward the Internet.
• d) Local: the router is just another neighbor on the LAN (192.168.20.1 is in 192.168.20) → ARP and direct delivery. The fact that it also happens to be the gateway doesn't change how you talk to it when it is itself the destination.

Solution 2:

• Packet to 192.168.10.10: matches the 192.168.10.0/24 row → goes out through the VPN tunnel to Valencia.
• Packet to 198.51.100.7: matches no known network → default route, out toward the Internet via the ISP router.

Solution 3: The Bilbao printer's reply arrives with TTL 62 = 64 − 2: it crossed 2 routers (Bilbao and Valencia), exactly the two ends of the VPN tunnel in the topology. The file server's reply arrives with TTL 64 = 64 − 0: no router in between, because the server is on the same local network as Marta and delivery is direct through the switch (data link only, as we saw in 02-02). The TTLs confirm module 1's network blueprint.

With this lesson, Meridiano's packets now cross borders. We have seen that network protocols turn many networks into one: IP provides universal addressing — 32-bit addresses with their network part and host part, which let every machine decide whether a destination is local or remote — and a deliberately simple packet service, connectionless and best-effort, with fields as eloquent as the TTL. Routers chain the journey together by consulting their routing table (connected networks, the route to Bilbao over the VPN, the default route to the Internet), hosts delegate to their default gateway, and ICMP gives the network its voice: ping's echoes, the destination-unreachable and TTL-expired notices. And we have confirmed the great division of labor: IPs travel end to end, frames live and die on each leg. But notice that everything said today delivers packets to a machine, not to a program: on the Valencia server, the shared files coexist with perhaps an internal website and other services, and someone has to carry each piece of data to the right application, also guaranteeing — when it matters — that nothing is missing and nothing is duplicated. That is the territory of ports, TCP and UDP: the Transport Protocols of the next lesson.