Understanding BGP and Why Route Leaks Cause Outages

What Is BGP?

The Border Gateway Protocol (BGP) is the routing protocol that holds the internet together. Every autonomous system (AS) — a network operated by an ISP, cloud provider, CDN, or large enterprise — announces to its peers which IP prefixes it can reach. BGP is how those announcements propagate globally.

Unlike interior routing protocols that optimize for shortest path inside a single network, BGP is a path-vector protocol. It carries the full sequence of AS hops to a destination and applies policy rules — not just math — to decide which path wins.

That policy flexibility is BGP's power. It is also why mistakes are catastrophic.

How Route Announcements Work

When your network wants to tell the world it owns 203.0.113.0/24, it originates a BGP announcement. Your upstream providers accept it, attach their own AS number to the path, and re-announce it to their peers. Within minutes, routers worldwide know to send traffic destined for that prefix toward you.

Three relationships govern who accepts what:

• Customer → Provider: A customer pays a provider for transit. The provider accepts the customer's routes and advertises them widely.
• Peer → Peer: Two networks exchange routes for mutual benefit, usually without money changing hands. Neither re-advertises the other's routes to third parties.
• Provider → Customer: The provider sends the customer a default route or full table so the customer can reach the rest of the internet.

Violating these relationships — accidentally or otherwise — is a route leak.

What Is a Route Leak?

A route leak happens when an AS re-advertises routes it learned from one neighbor to another neighbor in a way that violates policy. The most common pattern:

1. AS A (a customer) learns routes from Provider B.
2. AS A also has a separate transit relationship with Provider C.
3. AS A incorrectly advertises Provider B's routes to Provider C.
4. Provider C sees a seemingly valid path and starts sending traffic through AS A.
5. AS A, never intended to be a transit network, becomes overwhelmed or drops the traffic entirely.

The result: traffic that was flowing fine gets rerouted through an unequipped middleman and either degrades severely or blackholes completely.

A well-known real-world example is the 2019 incident where a small ISP in Pennsylvania leaked roughly 70,000 routes it had learned from Verizon. Because Verizon had no maximum-prefix limits configured on that session, it accepted the full leak and began sending a significant portion of internet traffic through the small network. The congestion caused widespread slowdowns across the US for several hours.

Why BGP Has No Built-In Trust

BGP was designed in 1989 for a cooperative, relatively small internet. It assumes that if a neighbor announces a route, the announcement is legitimate. There is no cryptographic verification of origin or path by default.

Two standards exist to fix this:

• RPKI (Resource Public Key Infrastructure): Ties IP prefixes to AS numbers using cryptographically signed Route Origin Authorizations (ROAs). Routers that validate RPKI will reject announcements where the origin AS doesn't match the ROA.
• BGPsec: Extends RPKI to validate the entire AS path, not just the origin. Adoption remains very low due to performance and operational complexity.

RPKI adoption has grown meaningfully in recent years, but coverage is still incomplete. A leak that originates from an AS with a valid ROA can still propagate.

Operational Defenses

While the protocol catches up, operators can reduce blast radius with existing tools:

• Configure prefix limits on BGP sessions. If a peer suddenly announces 10x more prefixes than expected, drop the session automatically.
• Apply strict route filters. Only accept prefixes your neighbor is authorized to announce. Maintain and update these filters regularly.
• Implement RPKI validation. Drop invalid ROA announcements at your border routers. It's supported in BIRD, FRR, Junos, and IOS-XR.
• Use IRR data. Internet Routing Registry entries give a second layer of filtering even where RPKI is absent.
• Monitor your own prefix visibility. Tools like the RIPE RIS Looking Glass or BGPmon can alert you if your prefixes are being announced by an unexpected origin AS.

How Monitoring Fits In

BGP incidents often manifest as regional or carrier-specific failures. A route leak might cause traffic from European ISPs to blackhole while US traffic is unaffected, or vice versa. Single-region monitoring will miss this entirely.

Multi-region uptime monitoring — checking your endpoints from probes across different networks and geographies — gives you the vantage points to see carrier-level failures as they happen. When checks from one region fail while others pass, that asymmetry is a strong signal to look at routing before assuming an application problem.

Key Takeaways

• BGP is policy-driven, not authenticated. Mistakes propagate at internet scale.
• A route leak occurs when an AS re-advertises routes in violation of its peering relationships.
• The consequences range from latency spikes to full traffic blackholes.
• RPKI origin validation is the most practical near-term mitigation; deploy it if you haven't.
• Prefix limits and strict route filters are basic hygiene that many networks still skip.
• Because leaks are often regional, multi-region monitoring is the fastest way to detect the symptom before you've identified the cause.