Border Gateway Protocol (BGP) route leaks are a routine consequence of a protocol that was never designed to enforce the business rules networks rely on. Understanding them is essential for any organization that depends on internet routing—which today, means almost everyone.
Over the years, BGP monitoring services have recorded several route-leak events worldwide. Most were brief. Some were not. In 2019, one of the most devastating incidents unfolded when a single event caused hours of global internet degradation. No attacker was involved. Just one misconfiguration, and one upstream provider that trusted blindly. Let's explore what's actually happening when a route leak occurs and why BGP makes them so difficult to prevent.
The IETF defines a BGP route leak in RFC 7908 as the propagation of routing announcements beyond their intended scope. In plain terms: An autonomous system (AS) advertises a route it received from one neighbor to another neighbor that should never have seen it.
The route itself is legitimate. It originated correctly and represents a real network. The problem is where it ends up being advertised. Other networks, trusting the announcement, begin sending traffic through the leaking AS—often a network with insufficient capacity or no direct path to the destination. From a user's perspective, this presents as connection timeouts, failed API calls, and requests that disappear entirely. In short, the service appears down even though nothing at the origin has failed.
BGP route leaks only make sense in the context of the business relationships between networks. AS relationships are primarily either provider-to-customer or peer-to-peer.
In a provider-to-customer relationship, the transit provider advertises its full routing table to the customer. The customer advertises only its own prefixes and those of its downstream customers back to the provider. The customer pays for transit.
In a peer-to-peer relationship, two networks of roughly equal size exchange routes to each other's networks and their customers—but not their upstream providers' routes. Neither party should be carrying the other's transit traffic.
These relationships produce the principle of valley-free routing: traffic flows from customers to providers, or laterally across peers, but never from a provider down to a customer and back up to another provider. A route leak breaks this order by creating exactly such a path.
BGP has no built-in mechanism to enforce this order. There is no field in a BGP update message that says, "This route came from my provider—do not re-advertise it." Instead, every AS operator must configure import and export filters manually. When those filters are missing or wrong, leaks happen.
Missing outbound export filters is the most common cause. An AS receives routes from its upstream transit provider—often tens of thousands of prefixes—and sets up a new peer session without applying an export policy. The peer sees all those routes as valid and propagates them. The leaking AS becomes an unintended transit network.
Overly broad route maps and policy mistakes cause leaks that are subtler and harder to catch. If prefix lists are removed accidentally, or a route-map becomes too permissive during a policy change, the export policy quietly opens up. This is what happened in a global network company's January 2026 incident: an automation change meant to block certain prefixes instead allowed all internal IPv6 routes to be advertised from the provider's specific PoP.
Route redistribution errors occur when routes from an internal protocol such as OSPF or IS-IS are imported into BGP without adequate filtering. Internal routes that should stay private end up in the BGP table and get advertised to peers before anyone notices.
Automation failures are an increasingly significant risk. As network management becomes more automated, a bug in a template, a wrong variable, or an unreviewed change can remove a filter or alter a route-map across many routers simultaneously—turning a single mistake into an instant, widespread misconfiguration.
The technical controls to prevent route leaks have existed for years. RPKI has been deployable for over a decade. Strict prefix filtering is well understood. The reason leaks still cause global incidents is not ignorance—it's incentives.
Large transit providers have limited commercial motivation to enforce strict inbound filtering on paying customers. Rejecting a customer's leaked routes means adding operational overhead and potentially blocking legitimate traffic during a dispute. Accepting all routes is easier. The 2019 incident is attributed to two independent failures: a leaking AS had no outbound filter and no meaningful inbound filter either. Either one alone would have contained it.
This is the structural problem BGP route leaks represent: the cost of a misconfiguration is often borne by third parties, not the operator who made the mistake.
Preventing route leaks requires layered defenses. No single mechanism catches every failure type.
Deny-all export policy with explicit permits is the safest default. Only an AS's own prefixes and those of its direct customers should be advertised to peers or upstream providers. Routes learned from providers must never be re-advertised to other providers or peers.
Inbound filtering and max-prefix limits address the receiving side. Inbound prefix filters set the maximum routes accepted from a neighbor—a transit provider should only accept prefixes matching the customer's registered address space. Max prefix limits on every BGP session mean that if a peer suddenly sends too many routes, at the first sign of a leak, the session is suspended before the leak spreads further.
RPKI origin validation lets AS operators sign Route Origin Authorizations (ROAs), linking a prefix to the AS number permitted to originate it. Routers validate incoming routes as Valid, Invalid, or NotFound, and drop those marked Invalid. RPKI is important but incomplete: it verifies who can originate a prefix, not who should receive it. It cannot catch a leak where a valid prefix is advertised to the wrong AS.
RFC 9234 BGP roles and the Only-to-Customer (OTC) attribute is the most direct protocol-level fix. Published in 2022, RFC 9234 introduces a BGP Role capability exchanged during session establishment. Routers declare their role—Provider, Customer, Peer, RS, or RS-Client—and if roles conflict, the session fails to establish. Once roles are agreed, routes carry an OTC attribute set to the advertising AS's number. Downstream routers use the OTC value and their peering role to determine whether propagating the route would violate valley-free rules. If it would, the route is suppressed. RFC 9234 is the first in-band mechanism specifically designed to prevent route leaks at the protocol level. Adoption of this fix is still maturing.
IRR-based filter generation uses Internet Routing Registry databases, which list which prefixes an AS can originate and which AS-sets it routes for. Tools like bgpq4 generate prefix lists and AS-path filters automatically from IRR data, allowing filter policies to scale without manual updates for every peer or customer. IRR data quality varies. Entries can be outdated or inconsistent, so IRR-generated filters should be cross-checked against RPKI ROAs wherever possible.
Continuous BGP monitoring is what turns a major outage into a recoverable incident. Effective BGP monitoring tools watch for unexpected AS path lengths, new intermediate ASes appearing in paths to prefixes, prefixes being announced by unknown ASes, sudden jumps in route counts from a peer, and route changes that don't correspond to any planned maintenance. Linking BGP events to application metrics, like error rates, latency, or connection failures, connects network instability to business impact and cuts mean time to resolution.
The difference between a route leak that affects a handful of users for two minutes and one that degrades the global internet for hours comes down to two things: whether both sides of the peering session had proper filters in place, and how quickly the leak was detected and reversed.
There are now ways to avoid a BGP route leak. RFC 7908 defined the problem. RFC 9234 gave the protocol its first real mechanism to address it. RPKI gave operators a way to verify route origins cryptographically. MANRS gave the industry a framework to hold each other accountable. The tools exist. The protocol won't enforce them—but the people running the network can.
A BGP route leak happens when a network advertises a route to a neighbor that should never have received it. The route itself is legitimate, but the issue is where the announcement ends up. Other networks trust the announcement and start sending traffic through the leaking AS, which often can't handle the load. From a user's perspective, the issue looks like the service is down, even though nothing at the origin has failed.
When a leaked route propagates, traffic meant for one network gets rerouted through an unintended path—often a smaller network with insufficient capacity or no direct route to the destination. Requests time out, API calls fail, and connections disappear entirely.
A route leak is almost always accidental—a misconfiguration causes a network to advertise routes it shouldn't. A hijack is deliberate: an attacker announces ownership of IP prefixes they don't control to intercept or redirect traffic. Both produce similar symptoms, but a hijack carries the additional risk of data interception, manipulator-in-the-middle attacks, and credential theft.
No. RPKI verifies who is permitted to originate a prefix, not who should receive it. It can stop a hijack where an unauthorized AS announces your prefix, but it cannot catch a leak where a valid prefix is advertised to the wrong AS. RPKI has to be combined with strict export filtering, inbound prefix limits, and continuous monitoring for it to be effective.
RFC 9234, published in 2022, is the first protocol-level mechanism designed specifically to stop route leaks. It works by having routers declare their relationship—Provider, Customer, or Peer—during session setup. Routes carry a tag that tells downstream routers whether forwarding them would violate routing rules. If it would, the route is suppressed. The limitation is adoption. It only works when both sides of a session have implemented it, and deployment of this fix is still maturing.
The signals to watch for are: your prefixes appearing in unexpected AS paths, new intermediate ASes showing up in routes to your network, sudden jumps in route counts from a peer, and route changes that don't correspond to any planned maintenance. The most actionable approach is correlating BGP events with application metrics. Continuous BGP monitoring turns what could be a multi-hour outage into a recoverable event.
Mutually Agreed Norms for Routing Security (MANRS) is an industry initiative backed by the Internet Society that asks network operators to commit to four practices: filtering, anti-spoofing, coordination, and global validation. It exists to make route leak prevention an industry-wide effort, because an AS that follows every best practice is still exposed if its peers don't. Broad community adoption of filtering standards and RPKI is what makes leaks hard to propagate at scale—not just hard to originate in the first place.
