What is a route leak?

A route leak is the propagation of BGP routes beyond the scope intended by the routing policies of the autonomous systems involved. It most often happens when a network passes routes learned from one neighbour on to another neighbour that should never have received them. As defined in RFC 7908, a leak violates the commercial relationship (customer, provider, peer): routes meant to stay within a narrow scope propagate more widely and pull traffic toward a network that has neither the capacity nor the intent to carry it. Unlike a prefix hijack, the origin of the route usually stays legitimate, and the problem is the direction and scope of propagation.

Route leak types per RFC 7908

RFC 7908, published in 2016, formalises the phenomenon and defines six leak types based on the relationship between networks. Most of them come down to breaking the valley-free rule, under which routes learned from a provider or peer should not be passed on to another provider or peer:

• Type 1, Hairpin: a multihomed network passes a route from one transit provider to another and becomes accidental transit between them.
• Type 2, Lateral ISP-ISP-ISP: routes learned from one peer are announced to another peer, even though peering is meant to be bilateral.
• Type 3, provider prefixes leaked to a peer: a network announces routes learned from its own transit provider to a peer.
• Type 4, peer prefixes leaked to a provider: a network announces routes learned from a peer to its transit provider.
• Type 5, prefix re-origination: a network strips the received AS_PATH and announces the prefix as if it were the origin itself.
• Type 6, accidental leak of internal and more-specific prefixes that were never meant to be advertised in BGP.

Common causes

Leaks are rarely deliberate and almost always stem from configuration errors. The classic case is a missing outbound (export) filter on an eBGP session, so a router redistributes the full BGP table to a neighbour to which it should only send its own prefixes. Other causes include incorrect mapping of policy-driving BGP communities, accidental IGP-to-BGP redistribution, faulty aggregation and automation mistakes. The impact can be severe. In June 2019 a leak by a small operator in Pennsylvania (DQE Communications), amplified by a Noction BGP optimiser, was passed on by Verizon, which lacked filtering. This disrupted reachability for parts of Cloudflare, AWS and other networks for hours.

Prevention: filtering, RPKI and peerlock

Preventing leaks relies on several layers that complement one another. None is sufficient on its own, but together they close off the most common paths for bad routes to propagate:

• Strict inbound and outbound prefix filters built from route and as-set objects in the IRR, plus max-prefix limits on every session.
• RPKI origin validation (RFC 6811): dropping invalid routes limits the scale of a leak, though it does not detect the AS_PATH relationship violation itself.
• ASPA (IETF SIDROPS drafts): AS_PATH relationship verification based on signed RPKI objects, designed specifically to catch valley-free leaks.
• Peerlock and peerlock-lite: filters that reject routes whose AS_PATH contains Tier-1 transit ASNs where they should not appear.
• Applying MANRS practices and the BGP Roles plus Only-to-Customer (OTC) attribute from RFC 9234, which automatically blocks propagation of a route beyond a customer.

Route leaks and AS202520 SkyPass

AS202520 SkyPass applies strict filtering on every BGP session, both on peering at the Polish IXPs (THINX, TPIX, WRIX and 1-IX) and on customer transit sessions. We build prefix lists from IRR objects, validate route origin with RPKI and enforce max-prefix limits, so a faulty announcement from a customer or partner does not propagate further through the network. IP transit and remote IXP customers benefit from the same protections, and our looking glass lets you verify in real time how our prefixes and paths are seen from the outside.