📣 Route Advertisement: What Actually Happens When a Prefix Goes Live

Somewhere between "we own this IP block" and "this IP block works from anywhere in the world" sits a specific, mechanical process: a route advertisement. It's easy to take for granted precisely because it usually works invisibly — a network engineer configures a BGP session, the prefix appears in the global routing table within minutes, and traffic starts flowing. Understanding what actually happens in between matters most when something goes wrong: a new prefix that never appears, an old one that mysteriously stops working, or a migration where two networks briefly both claim the same address space.

The UPDATE Message: Where Advertisement Actually Happens

A BGP route advertisement is, mechanically, a BGP UPDATE message — one of the four BGP message types defined in RFC 4271. This message carries the prefix being announced along with a set of path attributes (AS-path, next-hop, local preference, MED, and others) describing that route. When a router receives an UPDATE announcing a new prefix, it evaluates the announcement against its own import policy (accepting it, rejecting it, or modifying its attributes per configured rules), potentially runs it through the best-path selection process if multiple paths exist, and — if it becomes the chosen best path — generates its own UPDATE message to pass the announcement on to its own neighbors, with its own AS number prepended to the AS-path. This hop-by-hop re-announcement is exactly how a single origin announcement eventually reaches every corner of the internet.

Step-by-Step: A New Prefix Going Live

1. Allocation confirmed. The organization has a valid RIR allocation or a sub-allocation from their upstream provider for the prefix.
2. Configuration applied. The network engineer configures the router to announce the prefix, typically via a route-map or prefix-list tied to the BGP session with each upstream.
3. UPDATE sent to first-hop neighbors. The router sends a BGP UPDATE message to each configured neighbor, containing the prefix and relevant path attributes.
4. Neighbor evaluates and re-announces. Each receiving router applies its own import policy, potentially selects this as a best path, and re-announces to its own neighbors with the AS-path extended.
5. Propagation continues hop by hop. This process repeats across the internet's topology until the announcement has reached (in principle) every network capable of receiving it.
6. Global visibility achieved. Within a few minutes under normal conditions, the prefix becomes visible from route collectors and looking glasses worldwide — the point at which a BGP lookup tool would show it as an active route.

Each hop prepends its own ASN to the AS-path before re-announcing — the growing AS-path is a live record of the announcement's propagation history.

Route Withdrawal: The Other Half of the Lifecycle

When a prefix stops being reachable — planned decommissioning, a link failure, or an intentional migration — the originating router sends a BGP UPDATE message containing a withdrawal for that prefix (technically, an UPDATE with the prefix listed only in the withdrawn routes field, no path attributes attached). This propagates hop-by-hop exactly like an announcement, and each receiving router removes the corresponding route from its table, recalculating its best path from any remaining alternatives if one exists, or marking the destination unreachable if this was the only known path.

Route Flapping: When Advertisement and Withdrawal Cycle Rapidly

Route flapping occurs when a prefix is repeatedly announced and withdrawn in quick succession — commonly caused by an unstable physical link, a misconfigured router restarting a BGP session repeatedly, or a genuine intermittent connectivity issue. Each flap forces every router that received the original announcement to recompute its best path, which at internet scale, repeated across a large peering fabric, creates real processing overhead. Route flap damping (RFC 2439) is a mechanism some networks apply specifically to suppress excessively unstable routes temporarily, trading brief unavailability of a flapping route against protecting overall routing table stability — though damping has fallen out of favor at some large operators due to legitimate route changes occasionally being penalized alongside genuinely unstable ones.

Advertisement Comparison Across Scenarios

Real-World Scenarios

Verifying an Advertisement Went Live Correctly

Common Mistakes

Case Study: A SaaS Platform's Migration Cutover

A SaaS platform migrating its primary API prefix from one cloud provider's network to a self-managed multi-homed setup planned the cutover in three phases specifically to avoid a reachability gap: first, announce the prefix from the new infrastructure alongside the existing cloud-provider announcement (a deliberate, temporary MOAS the team monitored closely via external lookups), second, confirm via multiple external vantage points that the new announcement had propagated broadly and traffic was successfully reaching the new infrastructure, and only then, third, withdraw the original cloud-provider announcement. This overlap-then-withdraw sequencing — rather than an abrupt cutover — meant the migration had zero measurable downtime, at the cost of a short window where the team had to actively monitor for any unexpected traffic imbalance between the two temporarily-coexisting origins.

Developer and Operations Notes

Automation pipelines that programmatically manage BGP announcements (common at large cloud and CDN operators) need explicit handling for the propagation delay between announcement and full global visibility — a naive automated failover script that announces a new prefix and immediately assumes traffic has shifted will misbehave if it doesn't account for the several-minute window before propagation completes across the internet's topology.

Checklist for a Clean Route Advertisement

1. Confirm the prefix and origin ASN are correctly configured before sending the first announcement.
2. Verify propagation externally using a BGP lookup tool or public looking glass, not just internal router state.
3. For migrations, prefer an overlap-then-withdraw sequence over an abrupt cutover.
4. Monitor for unexpected flapping in the minutes following any change.
5. Document expected propagation time in change-management plans so on-call teams don't misdiagnose normal delay as a failure.

Summary

A route advertisement is a specific, traceable BGP event — an UPDATE message propagating hop-by-hop from an origin AS outward across the internet's topology, typically reaching broad visibility within a few minutes. Understanding this lifecycle, including how withdrawal and flapping work as the advertisement's counterparts, turns what can feel like an opaque "the internet just knows about it now" process into something you can plan around, verify externally, and troubleshoot methodically when it doesn't behave as expected.