🌐 Route Propagation: Why a Route Change Takes Minutes, Not Milliseconds, to Reach Everyone

Configure a BGP announcement change and your own router applies it immediately — the local routing table updates the instant the configuration commits. It's tempting to assume the rest of the internet sees it just as fast. It doesn't, and understanding exactly why takes the mystery out of what otherwise looks like unpredictable, frustrating delay during a migration or failover event.

The Hop-by-Hop Reality Behind "The Internet"

There's no broadcast mechanism that instantly notifies every router on the internet of a routing change simultaneously. Instead, propagation happens hop-by-hop: your router sends an UPDATE to its directly-connected neighbors, each of those neighbors processes the update, potentially recalculates its own best path, and — if the change affects what it would announce — sends its own UPDATE to its neighbors, and so on outward across the internet's topology. Every one of these hops adds processing time, and every hop may also apply timers specifically designed to rate-limit how often it re-announces changes, which is where a meaningful chunk of the real-world delay actually comes from.

The MRAI Timer: Deliberate, Designed-In Delay

The Minimum Route Advertisement Interval (MRAI) is a per-neighbor timer, typically defaulting to around 30 seconds for eBGP sessions on many implementations, that limits how frequently a router will send updates about the same prefix to a given neighbor. Without this throttle, a rapidly flapping or frequently-updated route could flood neighbors with a continuous stream of updates, consuming processing resources disproportionate to the actual value of each individual update. MRAI trades a bounded, deliberate delay for meaningfully reduced update churn — a reasonable engineering trade-off, but one with a direct, cumulative consequence: every hop's MRAI timer potentially adds up to 30 seconds (or whatever the configured value is) to the total propagation time, and these delays compound across a multi-hop path rather than happening in parallel.

A simplified illustration — actual timing varies significantly based on topology, specific MRAI configuration at each hop, and whether best-path recalculation is required at each point.

Convergence: The Endpoint Propagation Is Working Toward

"Convergence" describes the state where every router on the internet that's capable of learning about a route change has done so and has stabilized on a consistent view — no more updates flowing as a direct consequence of the original change. For a single, isolated announcement or withdrawal, convergence across most of the internet typically completes within a few minutes. More complex events — like a large network's session failure causing many dependent routes to simultaneously need recalculation — can take meaningfully longer, since the sheer volume of simultaneous updates being processed and re-throttled by MRAI timers across many affected routers compounds the delay.

Withdrawal vs Announcement: Similar, Not Identical

Route withdrawals propagate through essentially the same hop-by-hop, timer-throttled mechanism as new announcements, though historically some BGP implementations have handled withdrawal processing with slightly different internal priority than new announcements, occasionally leading to minor differences in observed propagation speed between the two in specific implementations. For practical planning purposes, the safe assumption is that both take a broadly similar multi-minute window to reach full convergence — treating a withdrawal as instantaneous is just as much a planning mistake as assuming an announcement is.

Propagation Time Comparison by Scenario

Why Topology Position Changes Your Propagation Speed

A network's position in the internet's topology directly affects how quickly its changes reach broad visibility — a network with many direct peering relationships at major Internet Exchange Points (IXPs) needs fewer hops to reach a large share of the internet, meaning its changes converge faster on average than an equivalent change from a smaller, more peripherally-connected network relying on a single upstream transit provider. This is a genuine, structural reason (not just anecdote) why well-peered networks like major CDNs and Tier-1 backbone providers often see their own routing changes stabilize noticeably faster than a smaller regional ISP would for a comparable change.

Real-World Scenarios

Common Mistakes in Planning Around Propagation

Case Study: A Streaming Platform's Failover Time Objective Miss

A streaming platform's disaster recovery plan specified a five-minute failover time objective for shifting traffic from a primary to backup region during an outage, based on internal testing that measured only the time for their own automation to detect the failure and issue the new BGP announcement — not accounting for the additional several minutes needed for that announcement to actually converge across the internet. During an actual regional outage, the automation performed exactly as designed within its measured window, but a meaningful share of user traffic didn't actually shift to the backup region until several minutes past the stated objective, once external propagation caught up. The team's subsequent revision explicitly separated "time to announce" from "time to converge" as two distinct, separately-measured components of their failover objective, setting more realistic expectations with stakeholders going forward.

Best Practices for Planning Around Propagation

1. Always distinguish "time to make the change" from "time for the change to converge globally" as separate planning figures.
2. Verify convergence using external tools (a BGP lookup tool, public looking glasses, or dedicated monitoring) rather than local router state alone.
3. Build maintenance windows sized around realistic convergence time, not just configuration application time.
4. Communicate realistic timing to stakeholders and customers, avoiding "should be live now" messaging that precedes actual convergence.
5. Account for topology position — peripheral networks should expect slower convergence than well-peered ones for comparable changes.

Developer and Automation Notes

Automated failover and infrastructure-as-code pipelines that trigger BGP announcement changes need an explicit wait-and-verify step before downstream automation proceeds to dependent actions — a pipeline that immediately assumes success the instant the announcement command completes, without confirming external convergence, risks downstream steps (like DNS cutover or customer notification) firing before the routing change has actually taken effect for real user traffic.

Summary

Route propagation feels instant from inside your own network and is anything but instant from the internet's perspective — a hop-by-hop process, deliberately throttled at each step by mechanisms like the MRAI timer, that typically takes a few minutes to reach broad convergence for a straightforward change, and longer for complex, high-volume events. Planning around this reality — distinguishing "the change is configured" from "the change has converged," verifying externally, and setting stakeholder expectations accordingly — turns what otherwise feels like unpredictable delay into a well-understood, plannable part of any BGP-dependent operational change.