A BGP route leak happens when a network propagates routing information beyond its intended scope — typically when a transit or peer route is re-advertised to another peer or upstream provider. The result is traffic flowing through paths the network operator never intended, causing congestion, latency spikes, or in severe cases, a complete traffic blackhole.
Why route leaks happen
BGP was designed for trust. Its original model assumed that networks would only advertise routes they were legitimately responsible for, and would only re-advertise routes in accordance with peering agreements. That trust model has not aged well.
Most leaks are caused by misconfigurations rather than malice. The most common patterns are: a customer advertising a full routing table back to their provider, a network failing to apply export filters on a new peer session, or an operator making a mistake during maintenance and accidentally removing a route-map.
In 2019, a small Pennsylvania ISP leaked over 70,000 routes learned from Verizon to Cloudflare, causing significant disruption to traffic destined for major networks. Verizon had no maximum-prefix limits configured on that session — a fundamental control that would have contained the damage immediately.
The four controls that prevent route leaks
1. Route filtering with IRR-based prefix lists
The Internet Routing Registry (IRR) is a distributed database of routing policy information. BGP operators publish their route objects — the prefixes they originate — and their AS-SET objects, which describe the downstream networks they are responsible for.
By generating prefix-lists from IRR data using tools like bgpq4, you can automatically build and maintain accurate inbound and outbound filters for every BGP session. Any prefix not in the IRR for that AS is rejected at the border.
2. RPKI Route Origin Validation
Resource Public Key Infrastructure (RPKI) allows the holder of an IP prefix to cryptographically sign a Route Origin Authorisation (ROA) — a statement that says "this AS is authorised to originate this prefix." Routers that perform Route Origin Validation (ROV) drop routes that are Invalid according to the RPKI framework.
RPKI does not prevent all route leaks, but it does prevent origin hijacks — cases where an unauthorised AS announces your prefix. Adoption has grown significantly: as of mid-2025, over 50% of the global routing table is covered by valid ROAs.
- Create ROAs for all your originated prefixes via your RIR (RIPE NCC, ARIN, APNIC)
- Enable ROV (drop Invalid) on all your BGP sessions
- Verify your upstream providers perform ROV — a provider that does not is a leak amplifier
3. Maximum-prefix limits
Every BGP session should have a maximum-prefix limit configured. When a peer sends more routes than expected, the session is torn down rather than accepting an anomalous routing table. This is the simplest and most effective containment control — the Verizon incident above would have been stopped in seconds.
Set limits based on the expected prefix count for that peer, with a 20% buffer. For customer sessions, the limit should reflect only what that customer legitimately originates. For transit sessions, full-table sessions should still have an upper bound — no provider should be sending you 5 million routes.
4. BGP communities for route propagation control
Well-known BGP communities provide a mechanism for signalling propagation policy. The NO_EXPORT community (65535:65281) instructs receiving routers not to re-advertise a route outside the AS. The NO_ADVERTISE community (65535:65282) restricts advertisement even within the AS.
For more granular control, operators define their own community schemes — for example, communities that tag routes by their origin (customer, peer, transit) and export policies that check those tags before re-advertising.
Operational discipline: the last line of defence
Technical controls reduce the blast radius. Operational discipline prevents the mistake in the first place. Change management for BGP modifications, peer review on route-map and prefix-list changes, and automated testing in a staging environment before applying to production — these are the practices that separate mature network operations from reactive ones.
Monitoring is equally critical. A route leak that is detected in 30 seconds causes a blip. One that persists for 20 minutes because no one noticed causes an outage. Your NOC should be alerting on sudden routing table size changes, path length anomalies, and unexpected next-hop changes — all signals that something has gone wrong.
Book a call and we'll give you a straight assessment of where you stand.