Routers, the post offices of the internet

Field note. Every game packet hops through twelve to twenty routers between your server and a player in Europe. Each hop adds milliseconds. Knowing the path explains why traceroute matters when ping is bad.

There's no map of the internet. No central computer that knows where every IP address lives. And yet, a packet from your laptop in New York can reach a server in Tokyo within a few hundred milliseconds, every time, automatically.

This works because of routers, which collectively do something elegant: each one only needs to know which neighbor to forward to, not the full destination. The internet's routing is local knowledge, repeated until the packet arrives.

This article explains how that actually works.

A router's job

A router is a computer with multiple network interfaces, each connected to a different network. Its job: receive packets on one interface, decide which interface to send them out on, and forward.

To decide, it consults a routing table. The table is a list of rules like:

Destination network    Next hop          Interface
10.0.0.0/8             192.168.1.1       eth0
198.51.100.0/24        203.0.113.5       eth1
0.0.0.0/0              198.51.100.1      eth2

For each packet, the router looks at the destination IP, finds the most-specific matching rule, and forwards out the corresponding interface.

The first rule says "for any address in 10.0.0.0/8, send to neighbor 192.168.1.1 via eth0."

The last rule is the default route: "for anything else, send to 198.51.100.1 via eth2."

That's the entire algorithm. Every router on the internet, from your home router to the multi-million-dollar core routers running Tier 1 networks, does this same thing: lookup destination, forward.

Where the routing table comes from

The interesting question: how does the router know what to put in its routing table?

For small networks: a human configures it. "Send 10.0.0.0/8 to my upstream provider; send everything else to my ISP."

For the internet at scale, this is automatic. Routers talk to their neighbors using a protocol called BGP (Border Gateway Protocol). Each router announces "I can reach networks X, Y, Z." Its neighbors update their tables: "to reach X, Y, Z, send to this router."

Through BGP, every router on the internet learns roughly where every reachable network is. Not the full path; just the next hop. Routes propagate hop-by-hop until every router knows the next hop for every destination.

We'll cover BGP in detail in a later series article. For now, the takeaway: routing tables are built dynamically, and they update as the network changes.

Longest-prefix match

When multiple rules match the same destination IP, the router picks the one with the longest (most specific) prefix.

Example. The router has:

Destination network    Next hop
10.0.0.0/8             A
10.5.0.0/16            B
10.5.7.0/24            C
0.0.0.0/0              D

A packet to 10.5.7.42:

• Matches 10.0.0.0/8 (any 10.x.x.x).
• Matches 10.5.0.0/16 (more specific).
• Matches 10.5.7.0/24 (even more specific).
• Matches 0.0.0.0/0 (catches everything).

Longest-prefix match picks 10.5.7.0/24. Packet goes to next hop C.

This is fundamental to how networks are subdivided. A big ISP might announce a /16 to the internet, but internally have many /24s that each go different places. External routers only see the /16; internal routers see the more specific routes.

A packet's journey, end to end

Suppose you're on a home computer (192.168.1.42) loading a webpage on 198.51.100.10. Here's roughly what happens:

1. Your computer's routing decision. The destination is not in 192.168.1.0/24 (your local network), so the packet goes to the default gateway (your home router) at 192.168.1.1.

2. Your home router's decision. It doesn't know how to reach 198.51.100.10 specifically. Its default route points to your ISP. Forward.

3. Your ISP's edge router. Has a more complete picture. Might forward via its transit provider, or peer with the destination network at an IXP. Forward.

4. Several intermediate networks. Each does the same: look up, forward.

5. The destination's ISP. Knows that 198.51.100.10 is on a specific customer's connection. Forwards to that customer's router.

6. The destination's router. Forwards to the specific server on its local network.

Total: 10 to 30 hops, depending on geography and peering.

Each router along the way held the packet for microseconds. None of them needed to know the full path. The forwarding decision was local at each step.

Why this is robust

This design has remarkable resilience. If a link goes down:

1. The routers on either side of the broken link notice (BGP keeps neighbor sessions; loss triggers a "withdrawal" of the routes that went via that link).
2. Neighboring routers update their tables: routes that depended on the broken link now point elsewhere.
3. Routes propagate. Within minutes, the rest of the internet's routers know the alternative paths.
4. Traffic flows the new way.

No central coordinator. No global table rebuild. Just local adaptation propagating to the whole network.

This was a deliberate design choice from the start. The internet was conceived (in part) to be resilient to component failures. The architecture reflects that.

Switches vs routers

A common confusion. Both forward packets, both have multiple ports, both look similar.

Switches work at layer 2 (Ethernet). They forward frames based on MAC addresses. They operate within a single network. Connecting computers on the same LAN, you use switches.

Routers work at layer 3 (IP). They forward packets based on IP addresses. They connect different networks. To reach another network, packets go through routers.

In your home, the device you call a "router" is usually a combination switch + router + Wi-Fi access point + DHCP server + firewall + DNS resolver + NAT translator, all in one box. But the routing function (deciding when packets should go to your ISP vs stay on your LAN) is the router part.

Default routes and the "any address" idea

The 0.0.0.0/0 route ("any address, send here") is special. It's how routers handle destinations they don't have specific routes for.

Your home router has a default route pointing at your ISP. Your ISP has a default route pointing at its transit provider. The transit provider, being a Tier 1, doesn't have a "default" in the same way: it has specific routes for every reachable network on the internet, learned via BGP from its peers.

A Tier 1's BGP table has ~1 million entries as of 2026, covering every prefix announced anywhere on the internet. Smaller networks delegate to a default route to keep their tables manageable.

Convergence time

When routes change, the internet "converges" to the new state. Time depends on:

• Where the change happened.
• How many BGP routers are involved.
• Whether route flap dampening is active.

Typical convergence: seconds to a few minutes for nearby changes. Up to 10 minutes for global propagation in the worst cases.

During convergence, some packets may take suboptimal paths or be dropped. This is usually invisible to end users; a brief glitch.

When routing goes wrong

Routing is mostly invisible until it isn't. Common failure modes:

Hijacks. A network mistakenly (or maliciously) announces a route for IP space it doesn't own. Other routers may believe the announcement. Traffic destined for the legitimate network ends up going to the hijacker. Famous incident: Pakistan Telecom in 2008 accidentally took YouTube offline globally by announcing YouTube's IP space.

Route leaks. A network announces routes it shouldn't (e.g., announcing transit routes to a peer it should only announce its own customers to). Causes traffic to flow through unexpected paths, often with worse performance.

Persistent loops. Misconfigured routers can have rules that bounce a packet back and forth. The TTL counter eventually kills the packet, but performance is hurt.

Black holes. A router accepts packets but doesn't forward them anywhere. Packets disappear silently. Hard to diagnose because nothing announces the failure.

Modern protocols (RPKI for hijack prevention, route filters at peering edges) reduce these issues but don't eliminate them.

Looking at the path

Two tools let you see the actual path:

traceroute (Unix/Mac) or tracert (Windows). Sends packets with increasing TTLs, gets back "TTL exceeded" messages from each hop, and reports them.

$ traceroute google.com
 1  192.168.1.1   1.234 ms
 2  10.42.0.1     8.123 ms   (your ISP's edge)
 3  ...           ...
 ...

mtr (Linux/Mac, runs traceroute repeatedly): great for diagnosing intermittent issues.

These show the routers your packets pass through, by IP. With reverse DNS, you can often see human-readable names that hint at the network operator.

For a hosting customer trying to understand why latency to a specific destination is poor, mtr is essential. It can reveal the specific intermediate router where loss is occurring.

What routers don't do

To round out the model: routers do NOT:

• Decode application data. They look at IP headers and TCP/UDP ports at most. They don't read HTTP requests.
• Provide reliability. That's TCP's job. Routers drop packets when needed.
• Care about content. A router moves bits; it doesn't care if they're a webpage, a game, or a video call.
• Modify packets. Mostly. A few exceptions (NAT routers, transparent proxies) modify packets, but they're acting beyond pure routing.

Pure routing is just: read destination, look up, forward, decrement TTL, repeat.

Why this matters

For most users, routers are invisible until they're not. Understanding them helps with:

• Diagnosing network problems. mtr / traceroute show you which hop is the issue.
• Geographic latency. If you're far from a service, the packet has many hops. Each hop adds time.
• Path selection. VPNs change the path. So can your ISP choice. So can your DNS provider in some cases.
• Game hosting decisions. A host in a well-peered data center will have shorter paths to most players than one in a poorly-peered location.

Coming up

Routers connect networks. But routers need to know which network is which, which is hard when networks have arbitrary numeric IPs. Humans need names, not numbers, and computers need to translate between them. That's DNS, next.