HomeArticlesInternet & Networks

BGP Route Propagation: How the Internet Agrees on a Path

Path-vector routing, the customer/peer/provider hierarchy, the valley-free rule, and why convergence after an outage takes minutes, not milliseconds.

mysimulator teamUpdated June 2026≈ 9 min read▶ Open the simulation

The internet is not one network, it is thousands agreeing to talk

The public internet is a federation of roughly 70,000 independently operated networks, each called an Autonomous System (AS) and identified by a number — AS15169 is Google, AS7922 is Comcast, AS13335 is Cloudflare. No central authority tells any of them how to reach any other. Instead, every AS runs the Border Gateway Protocol (BGP), speaking to its direct neighbours over TCP port 179, and reachability information propagates hop by hop until, eventually, every AS on the path has heard an announcement for a given block of IP addresses.

This is a path-vector protocol, a middle ground between two older ideas. Distance-vector protocols (like early RIP) only exchange a hop count, which is cheap but blind — a router cannot tell if a neighbour's route loops back through itself. Link-state protocols (like OSPF) flood the entire topology to every router, which is precise but does not scale past a single organisation. BGP's compromise is to advertise the full AS path with every route: not just “I can reach 8.8.8.0/24” but “I can reach it via AS15169, AS3356, AS6453”. A router that sees its own AS number already in a received path drops it instantly — that one check is BGP's entire loop-prevention mechanism.

live demo · an announcement propagating hop-by-hop across AS nodes● LIVE

What actually gets announced

An AS does not announce individual IP addresses — it announces prefixes, blocks like 8.8.8.0/24 (the /24 meaning the first 24 bits are fixed, giving 256 addresses). Each announcement — a BGP UPDATE message — carries the prefix plus a set of path attributes: AS_PATH (every AS the route has crossed, oldest first), NEXT_HOP (the router to send packets to), and optional attributes like MED and communities used for traffic engineering. When a router receives an UPDATE, it prepends its own AS number to the path before re-announcing it onward, which is exactly why the path grows by one hop at each AS boundary and why counting hops in the AS_PATH is a rough proxy for network distance.

Choosing the best path: it is a business decision, not a shortest path

Here is what surprises people coming from IGP routing (OSPF, shortest-path routing inside one network): BGP does not pick the shortest AS path by default. Real ISPs commercially classify every neighbour into one of three relationships, and that classification decides which route wins before path length is even considered:

customer  → a network that pays you for transit          (you carry their traffic anywhere)
peer      → a network you exchange traffic with for free  (usually equal-sized networks)
provider  → a network you pay for transit                 (they carry your traffic anywhere)

Standard preference order: customer route > peer route > provider route
(a customer route earns you money; a provider route costs you money)

This is the Gao-Rexford model, formalised from observed ISP behaviour in 2001, and it produces the famous valley-free rule: a legitimate AS path goes uphill through zero or more provider links, crosses at most one peer link at the top, then goes downhill through zero or more customer links. A path that goes provider → peer → provider (a “valley”) would mean an AS is providing free transit between two networks it has no commercial reason to subsidise, and in practice such paths are filtered out or simply never announced.

Only after the commercial relationship is decided does BGP fall back to a tie-break chain: shortest AS_PATH, lowest origin type, lowest MED (a hint from the neighbouring AS about its own internal preference), eBGP over iBGP routes, lowest IGP cost to the next hop, and finally the lowest router ID as an arbitrary last resort. Every one of these steps exists because two routers, applying the exact same deterministic rule set to the exact same input routes, must reach the exact same answer — otherwise the network oscillates.

Convergence: why the internet is slow to heal

When a link fails or an AS withdraws a prefix, that information has to ripple hop by hop through every AS that had a route through the failure, and each router along the way must recompute its best path and potentially explore several alternates before it settles — a phenomenon called path exploration. Measured convergence after a real-world failure is commonly tens of seconds to a few minutes, not milliseconds, because BGP intentionally rate-limits how fast a router re-announces a flapping route (MinRouteAdvertisementInterval, historically 30 seconds) to avoid flooding the whole internet with updates every time one link blinks.

The simulation on this page runs exactly this mechanic: an announcement enters at one AS, each neighbour evaluates it against the customer/peer/provider policy of the link it arrived on, and — if it wins — re-announces it outward with its own AS number appended to the path, generation by generation, until the network converges on a stable set of best paths.

When it goes wrong: route leaks and hijacks

BGP was designed in 1989 on an assumption of good faith: every AS honestly announces only the prefixes it actually owns or has been authorised to carry. There is no cryptographic proof built into the base protocol that an announcement is legitimate, which is why route leaks (accidentally re-announcing a provider's routes to another provider, creating a valley) and BGP hijacks (announcing a prefix you do not own, deliberately or by fat-fingered configuration) have caused real, repeated internet outages — Pakistan Telecom's accidental hijack of YouTube's prefix in 2008 being the textbook case. The modern defence is RPKI (Resource Public Key Infrastructure), which lets a prefix owner cryptographically sign a statement of which AS is allowed to originate it, so routers can reject an obviously forged announcement instead of blindly propagating it.

Frequently asked questions

Does BGP always pick the shortest path?

No. Commercial relationship beats path length: a route learned from a paying customer is preferred over a route learned from a settlement-free peer, which is preferred over a route learned from a paid transit provider. Only when two candidate routes tie on relationship class does BGP fall back to comparing the length of the AS path.

What is a valley-free path?

An AS path that only ever goes uphill through providers, crosses at most one peer-to-peer link, then goes downhill through customers — never provider, then peer, then provider again. That shape reflects who is willing to carry whose traffic for free versus for money, and paths that violate it are a strong signal of a route leak.

Why does it take so long for the internet to notice an outage?

An update has to propagate hop by hop through every AS on an affected path, each one re-evaluating its best route and sometimes exploring several intermediate candidates before settling — plus routers deliberately rate-limit how often they re-announce a route to avoid flooding the internet during a flapping link. Real convergence after a major failure typically takes tens of seconds to a few minutes.

Try it live

Everything above runs in your browser — open BGP Route Propagation and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.

▶ Open BGP Route Propagation simulation

What did you find?

Add reproduction steps (optional)