Understanding BGP and Why Route Leaks Cause Outages

What BGP Actually Does

The internet is a collection of independent networks called Autonomous Systems (ASes). Your ISP is one. Cloudflare is one. AWS is one. Each AS has a number (an ASN) and owns a set of IP prefixes.

Border Gateway Protocol (BGP) is the routing protocol these networks use to tell each other which IP prefixes they can reach and via which path. When your browser opens a connection to 93.184.216.34, BGP is what decided how packets get from your ISP to that address.

BGP is a path-vector protocol. Each AS advertises prefixes it owns, and when it forwards that advertisement to a neighbor, it prepends its own ASN to the path. Neighboring routers accumulate these AS-PATH attributes and use them — along with local policy — to select the best route.

Route Selection in Brief

BGP routers compare candidate routes using an ordered set of attributes. The most operationally significant ones, in precedence order:

1. Local preference — set by local policy, prefers one upstream or peer over another.
2. AS-PATH length — shorter is preferred.
3. Origin type — IGP < EGP < Incomplete.
4. MED (Multi-Exit Discriminator) — a hint from a neighbor about which entry point to use.
5. eBGP over iBGP — external routes beat internal ones.
6. IGP metric to next-hop — prefer the closest exit point.

In practice, local preference and route filtering policies dominate real-world decisions.

What a Route Leak Is

A route leak happens when an AS re-advertises prefixes it learned from one neighbor to another neighbor in a way that violates the intended routing policy.

The classic example: you are a mid-size ISP (AS 64500). You have two upstream transit providers (AS 1111 and AS 2222) and several customers. You learn a prefix from AS 1111 and — due to a misconfigured BGP policy or a missing no-export community — you re-advertise it to AS 2222. AS 2222 now sees a route to that prefix through you and may prefer it, funneling traffic your way that you never agreed to carry.

At scale this becomes catastrophic. In 2010, AS 23724 (China Telecom) briefly advertised roughly 37,000 prefixes it had no business advertising, briefly attracting global traffic through its network. In 2019, a small Pennsylvania ISP (AS 396531) accidentally leaked routes learned from Verizon to DQE Communications, which accepted them without filtering — redirecting significant volumes of internet traffic for about two hours.

Why Networks Accept Leaked Routes

• Missing or lax prefix filters. Accepting a /24 from a peer that should only announce a /16 is a classic failure.
• No RPKI validation. Route Origin Authorization (ROA) records cryptographically bind a prefix to an ASN. Without RPKI, routers have no automated way to reject invalid origins.
• Absent BGP community filtering. The no-export community tells receiving routers not to propagate a route further. If the leaking AS never sets it, and the receiving AS doesn't enforce policy, the leak spreads.
• Lack of max-prefix limits. Setting a maximum-prefix on a BGP session causes the session to drop if a peer suddenly sends far more prefixes than expected — a cheap safety net.

How a Route Leak Becomes an Outage

When a leaked route propagates, traffic that should travel a direct, low-latency path gets pulled toward the leaking AS. Three things can then happen:

1. Blackholing. The leaking AS doesn't actually have a path to the destination, so packets are dropped.
2. Severe congestion. The network wasn't provisioned to carry the extra load, causing packet loss and high latency.
3. Interception. Traffic transits infrastructure that can inspect or tamper with it — a security concern beyond pure availability.

From a monitoring perspective, these failures look very different depending on where the probe is. A monitor sitting in the same region as the leaking AS might see the service as up (traffic reaches it locally), while monitors in Europe or Asia see complete loss. This is exactly why multi-region monitoring matters: a single vantage point cannot distinguish a route leak from a healthy network.

Defenses Worth Implementing

• Deploy RPKI and validate ROAs on your border routers. Major routers support it; the RIPE NCC and other RIRs publish current ROA data.
• Apply strict prefix filters to all eBGP sessions. Tools like bgpq4 generate filters from IRR data automatically.
• Set maximum-prefix limits on every peer and customer session.
• Use no-export communities when re-advertising customer routes to upstreams.
• Monitor BGP state externally. Services like BGPmon or your own looking-glass alert you when your prefixes are being originated by unexpected ASes.

Key Takeaways

• BGP is a trust-based system; it has no built-in mechanism to reject false advertisements.
• Route leaks occur when an AS re-advertises prefixes in violation of routing policy, usually due to misconfiguration.
• The consequences range from increased latency to complete blackholing, and the blast radius is global.
• RPKI, IRR-based prefix filters, and max-prefix limits are the primary technical controls.
• Outages caused by route leaks are geographically uneven — multi-region monitoring is the only reliable way to detect and attribute them quickly.