How Routers Find a Path Across the Internet

A network of networks, no central controller

It's tempting to imagine the internet as one giant system with a master map, quietly directing traffic the way an air-traffic controller directs planes. The reality is more decentralized, and arguably more remarkable: the internet is a voluntary collection of tens of thousands of independently operated networks, each making its own local decisions, that happen to agree on shared rules for exchanging traffic. No single organization owns or controls the whole thing.

That structure is deliberate, not accidental. The internet's early design favored a network that could keep functioning even if individual pieces failed or refused to cooperate, rather than one that depended on a single authority staying available and trustworthy forever. Decentralized routing is a direct consequence of that design goal, decades later.

Home routers vs. backbone routers

A home router, discussed in why Wi-Fi is only the first hop, manages a handful of devices and one connection out to an ISP — a relatively small job. Backbone and ISP routers operate at a completely different scale: they handle massive volumes of traffic from thousands of sources at once, hold routing information for the internet's entire reachable address space, and make forwarding decisions at extremely high speed. Both kinds of router do fundamentally the same job — read a destination address, decide where to send the packet next — just at very different scales.

The gap in scale is enormous in practice. A backbone router might need to hold hundreds of thousands of routing table entries and forward an immense number of packets every second, all while continuously updating its table as networks around the world announce changes — demands that shape backbone router hardware into something quite different from the consumer device sitting in a living room.

Autonomous systems, peering, and IXPs

Each independently operated network is called an autonomous system (AS). Autonomous systems connect to each other in two main ways. Peering is a direct exchange of traffic between two networks, often at no cost to either side, typically because it benefits both. Transit is a paid arrangement where a smaller network pays a larger one to carry its traffic onward to the rest of the internet. Many of these connections happen at internet exchange points (IXPs) — shared facilities where numerous networks connect in one place, making peering more efficient than arranging a separate direct link to every partner.

These relationships aren't fixed forever. Networks periodically renegotiate peering and transit agreements as their traffic patterns and business priorities shift, which is part of why the internet's underlying topology — who connects directly to whom — keeps evolving even though the protocols governing how that connectivity is used stay comparatively stable.

Routing tables and longest-prefix matching

Every router keeps a routing table: a list of address ranges (prefixes) and which direction — which next hop — to send traffic bound for each one. When a packet arrives, the router compares its destination address against the table and forwards it toward the most specific matching entry, a rule called longest-prefix matching. A very broad "catch-all" entry might cover huge swaths of the address space as a fallback, while a much narrower entry for one specific range takes priority whenever a packet's destination falls inside it.

This is the same principle you'd use giving directions with increasingly specific information: "head north" is a fine general instruction, but "turn left at the second light" overrides it the moment it applies. Longest-prefix matching lets a router keep one broad, simple fallback rule while still handling exceptions correctly, without needing a perfectly exhaustive table listing every possible destination individually.

BGP: exchanging routes, not turn-by-turn directions

Routing tables don't fill themselves in manually. Autonomous systems exchange reachability information with their neighbors using the Border Gateway Protocol (BGP): in effect, announcing "these address ranges can be reached through me." Each network then decides, based on its own policies and the announcements it receives, which path to prefer for each destination. BGP is closer to an ongoing, distributed conversation about what's reachable from where than it is to a GPS calculating one optimal turn-by-turn route — there's no single authority evaluating every possible path and picking a global best answer.

Because BGP relies on networks accurately announcing what they can reach, it depends heavily on trust between operators. Misconfigurations — a network accidentally announcing routes it shouldn't — have occasionally caused real, visible outages by misdirecting traffic that should have gone elsewhere, which is part of why the networking community has invested in additional safeguards to validate that route announcements are legitimate.

Why routes change

Because each network applies its own policy, the path traffic takes reflects more than just physical distance. Business agreements, available capacity, and current network conditions all factor in — a network might prefer a free peering link over a technically shorter but paid transit route, for example. When a link fails or a router goes down, neighboring networks detect the change and propagate new route announcements, so traffic reroutes automatically, typically within seconds, though the replacement path isn't always as fast as the one it replaced.

This is also why "the internet is down" is rarely literally true. What usually happens is narrower: a specific route, network, or service becomes unreachable or degraded while the vast majority of the internet continues operating normally, because the failure is local to one part of a much larger, redundant system rather than a failure of the whole thing.

Traceroute's limits, and a preview of anycast

Traceroute, a common network diagnostic tool, reveals the routers a packet passed through by gradually probing further along the path. It's useful, but incomplete: it only shows the outbound direction at one moment in time, some routers don't respond to its probes at all, and the actual return path can differ, as covered in how the internet reaches your device. One more routing trick worth knowing: anycast lets multiple physical servers around the world share the same address, with routing naturally sending each request toward a nearby one — the foundation for how content delivery networks operate, covered in how CDNs bring websites closer to you.

Despite these limits, traceroute remains genuinely useful for spotting where along a path delay is concentrated — a sudden jump in response time between two consecutive hops usually points to a specific, identifiable link worth investigating, even if the tool can't explain every detail of why that link is behaving the way it is.

What this means for your connection

Routing changes — a rerouted path after a failure, a new peering arrangement, added congestion on a link — can shift your connection's latency to specific destinations even when nothing about your own setup has changed. If a particular site or service suddenly feels slower while everything else feels normal, the cause may be somewhere along that specific route rather than in your home network at all. Comparing a speed test against a nearby, well-connected server with the same test against a distant one can help you see how much of your connection's performance is really about the route, not just raw bandwidth.