SubnetLayerProtocols

How a Packet Crosses a Router

What changes at every hop, and what must never change

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
There are billions of machines on the internet. No router could possibly hold a list of them. What makes routing possible is that IP addresses are organised. Addresses are handed out in blocks, so a router does not need to know about individual machines — it can know 'everything starting 10.0.3 goes that way' and be right about 256 machines at once. That is the whole trick. Group the addresses, and the table stays small enough to hold.
A postal sorting office does not hold a list of everyone in the country. It holds a list of *postcode areas* and which van each one goes on. A letter for SW1A 1AA is not looked up by name — the sorter reads the front of the postcode, throws it on the London van, and stops thinking about it. Somebody further down the chain reads more of the postcode than they did.
the postcode area
→ the network prefix — 10.0.3.0/24
the van it goes on
→ the next hop
the sorter's list of areas
→ the routing table
reading more of the postcode further down
→ each hop matching a longer prefix than the last

Where it breaks down: Postcodes are geographic and permanent; IP prefixes are administrative and move. A block can be sold and start appearing on the other side of the world next week, which is exactly why routing protocols exist and why a printed sorting list would be useless.

✗ Common misunderstanding: A router works out the whole route to the destination.

Why that's wrong: It knows only the next hop. No device on the path has a view of the whole route, and nothing reserves one.

Correct model: The route is an emergent consequence of many independent local decisions, each made by one router looking only at the destination address.

The packets prove it: Each forwarding decision in the two-hop trace lists only that router's own candidate routes — nothing about the hops beyond it.

✗ Common misunderstanding: IP delivers packets; if something is wrong it will report an error.

Why that's wrong: IP is best-effort. Packets may be dropped, duplicated or reordered, and in the common case nothing is reported to anyone.

Correct model: IP tries. Reliability, if you need it, is built on top — by TCP, or by your own application over UDP.

The packets prove it: In the UDP loss scenario a datagram is discarded and the trace that follows contains no error, no timer and no retransmission.

Watch these fields in the lab: ipv4.destIp

Prefixglossary
A block of addresses written as network/length, e.g. 10.0.3.0/24. The length says how many leading bits are fixed; the rest identify machines inside the block.
Next hopglossary
The neighbouring router to hand the packet to. Not the destination — just the next step towards it.
Longest-prefix matchglossary
When several routes contain the destination, the most specific one wins. A /24 beats a /16 beats a /0, no matter what order they were configured in.
TTLglossary
A counter decremented once per router. At zero the packet is discarded and reported. Despite the name it measures hops, not time.
Connected route
A route a device has simply because it has an interface in that subnet. It needs no configuration and is always the most trusted.

Watch these fields in the lab: ipv4.ttl

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why can a router hold a route to the whole internet in a manageable table?

A packet's source address says 10.0.1.5, your own subnet, but its TTL is 57. What does that suggest?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.