Shikanoko Networks (SKNK)
Back to blog

SKNK Technical Guide

What Is a BGP Route Leak? How Routing Announcements Escape Their Intended Scope

A BGP route leak occurs when routing announcements travel beyond their intended policy scope. Learn how route leaks happen, how they differ from hijacks, and how network operators detect and reduce the risk.

What Is a BGP Route Leak? How Routing Announcements Escape Their Intended Scope

On 22 January 2026, a routine change to a routing-policy automation platform at Cloudflare produced an outcome nobody intended. The change was meant to stop advertising a set of IPv6 prefixes from a data center in Miami toward another site in Bogotá. Instead, one edge router in Miami began redistributing IPv6 routes it had learned from peers back out to other peers and transit providers. Cloudflare later published a detailed post-incident report on the event.

The result unfolded quickly. Networks that had no business sending traffic through Miami started doing exactly that. The misdirected flows overwhelmed backbone links, pushed latency up, and caused packets to be dropped — about 12 Gbps of ingress traffic at the peak, discarded by firewall filters that were never meant to see it. The leak lasted roughly 25 minutes.

The point here is not that Cloudflare made a mistake. The point is that a single, local export-policy error was enough to reach distant networks and degrade service for people who had never touched that router.

White-Face Xiaolu pulls a route announcement back from beyond a simple policy gate.

A route leak begins when an announcement crosses the boundary its policy was meant to enforce.

A BGP route leak is the propagation of routing announcements beyond their intended policy scope.

Definition. A route leak is a routing-policy failure in which a network advertises learned routes to a neighbor or direction that was not part of the route's intended propagation scope.

This article walks through what a route leak actually is, why BGP accepts and propagates it, how it differs from a hijack, what RPKI can and cannot do about it, and how operators can detect and reduce the risk.

1. What Is a BGP Route Leak?

At its simplest, a leak happens in three steps:

  1. A network learns a route from an upstream provider or a peer.
  2. It then re-advertises that route to a neighbor that was never supposed to receive it.
  3. The route has now traveled beyond its intended scope.

RFC 7908, the IETF document that first gave route leaks a working definition, frames the problem in exactly these terms. The key boundary is propagation scope, not the identity of the ASN that originates the route.

To keep the three concepts from blurring together, hold on to this split:

  • Route Leak — the route is propagated beyond its intended scope. The origin may be perfectly legitimate.
  • BGP Hijack — a network originates a prefix it is not authorized to originate. The problem is the origin ASN.
  • Route Withdrawal — an announcement simply disappears. The problem is reachability.

These are three different failures, and they demand three different responses. Confusing them is how operators end up chasing the wrong fix.

2. BGP Is Also a Policy System

It is tempting to think of BGP as a path-selection engine: exchange routes, pick the shortest AS_PATH, done. But BGP has never worked that way. It is a policy system layered on top of a path-exchange mechanism.

The routes a network accepts, the routes it advertises, and the routes it prefers are all shaped by business relationships — customer, provider, peer — and by local attributes such as Local Preference and AS_PATH. When an export policy is wrong, the neighboring networks do not know it is wrong. They see a syntactically valid BGP update and evaluate it with their own local policy, which may actually prefer the leaked path.

This is the part that surprises people. A route leaked by accident can look more attractive than the legitimate one. A network that normally carries a prefix through a transit provider may suddenly see a "customer" route for the same prefix appear — and customer routes are usually preferred. So the leak gets installed, and then propagated further.

The lesson is blunt: the shortest AS_PATH is not the safest or most correct path. It is only the cheapest one according to a specific local policy.

Normal:
Customer → Provider → Internet

Leak:
Peer → Customer → Provider

Read the arrow as the direction a route announcement travels — which network advertised the route to which — not the direction data packets flow. The distinction is what trips people up, and it matters for everything that follows.

Notice that "correct" here has nothing to do with physical distance. It is about whether the propagation matches what both sides of a relationship actually agreed to.

3. The Intended Scope of a Route Announcement

To understand what "beyond scope" means, you need the four relationship types BGP networks form:

  • Customer — pays another network for transit.
  • Transit Provider — sells transit, and typically announces routes to all customers.
  • Peer — exchanges traffic settlement-free, usually between networks of similar size.
  • Sibling — two networks under common ownership or administration.

A simplified version of the propagation logic looks like this:

  • Routes learned from a provider should normally not be re-advertised to another provider or to a peer.
  • Routes learned from a peer are normally only sent to your own customers.
  • Your own routes and your customer routes have the widest legitimate propagation range.

None of this is a single hard rule for every network. Real networks carry exceptions — partial transit, paid peering, complex contracts, regional differences. The wording matters here: normally, typically, expected policy, depending on the relationship. AS_PATH can give you observational evidence about a path, but it cannot by itself prove the business relationship between two ASNs.

White-Face Xiaolu sets a route switch toward an intended path while a side path stays behind a gate.

Routing relationships define which paths a learned route is expected to take.

4. Four Common Shapes of Route Leaks

RFC 7908 classifies six types of route leak. For readability, this section covers the four you are most likely to encounter. The full six-type taxonomy is linked at the end.

4.1 Upstream-to-Upstream Hairpin

A multi-homed network learns a route from Provider A and re-advertises it to Provider B.

Route learned from:  Provider A
Route advertised to: Provider B
Why this is unexpected: Provider routes should normally stay within your own network.

This is the classic "hairpin turn" (RFC 7908 Type 1, or Type 2 when it runs laterally between peers).

4.2 Provider Route Sent to a Peer

A network takes a route learned from a transit provider and sends it to a peer (RFC 7908 Type 3).

Route learned from:  Transit provider
Route advertised to: Peer
Why this is unexpected: Peers typically expect only your customer routes.

4.3 Peer Route Sent to a Provider

A network re-advertises a route learned from a peer up to its own transit provider (RFC 7908 Type 4).

Route learned from:  Peer
Route advertised to: Transit provider
Why this is unexpected: Providers already reach that peer's customers on their own.

The Cloudflare incident of January 2026 was a mix of these two shapes — peer-learned routes redistributed to both peers and providers.

4.4 Internal or More-Specific Prefix Leak

Internal prefixes, test prefixes, or more-specific prefixes are accidentally announced to the public Internet (RFC 7908 Type 6).

Route learned from:  Internal network (iBGP, static, or redistribution)
Route advertised to: Public BGP neighbors
Why this is unexpected: These prefixes were never meant to leave the network.

The configuration bug behind the Miami incident involved internally redistributed routes, but Cloudflare classified the observed Internet leak as a mixture of Type 3 and Type 4 — the route-type internal match was the trigger, not the public-facing classification.

5. How a Route Leak Becomes an Internet Incident

A leak does not stay local. It compounds through a chain of independent decisions:

  1. A wrong route is advertised.
  2. A neighbor accepts it — because nothing in the BGP update signals that it is wrong.
  3. The neighbor's local policy selects it, sometimes over the legitimate path.
  4. That neighbor advertises it onward.
  5. Traffic is attracted to a network that lacks the capacity or the right firewall policy to carry it.
  6. Congestion, packet loss, latency, or partial unreachability follow.
Time Event
T0 Routing policy change is deployed
T1 Unexpected BGP announcements appear
T2 Neighbor networks accept the routes
T3 Traffic shifts toward the leaking path
T4 Operators detect, revert, and verify recovery

Two caveats keep this honest. First, not every route leak causes a global outage — the blast radius depends on the prefix, how far it propagates, path selection, capacity, and filtering. Second, a small network can become the center of a large incident precisely because it attracts traffic it was never sized to carry. That is the Telekom Malaysia lesson from 2015: a regional ISP leaked roughly 170,000 routes to a major transit provider, which accepted and propagated them, and the fallout rippled globally.

White-Face Xiaolu turns a valve as a rush of blank route cards overwhelms a small network booth.

A local export-policy error can redirect more traffic than the receiving network can safely handle.

6. Route Leak vs BGP Hijack vs Route Withdrawal

Event Main problem Origin ASN RPKI result Typical signal
Route Leak Route travels beyond intended scope May remain legitimate May still be Valid Unexpected AS relationship or path
BGP Hijack Wrong network originates the prefix Often unauthorized May be Invalid if covered by ROA Unexpected origin ASN
Route Withdrawal Announcement disappears Not applicable Not necessarily related Prefix visibility drops

Four points deserve emphasis, because they are the source of most misunderstandings:

  • RPKI Valid does not mean the whole path is safe. RPKI validates the origin, not the route.
  • RPKI Invalid does not automatically mean a malicious attack. It can be an operational mistake or a stale ROA.
  • Route leaks and hijacks can happen at the same time. A hijacked prefix can also be leaked further along the path.
  • A single public observation point cannot prove global reachability. You need multiple vantage points before concluding anything about the wider Internet.

7. What Operators See from the Outside

From outside the leaking network, you cannot read its configuration. What you can observe falls into two buckets — BGP signals and traffic telemetry — and they answer different questions.

BGP signals (what the routing system tells you):

  • An AS relationship appears in the AS_PATH that does not match expectations.
  • A single ASN suddenly announces a large number of new prefixes.
  • A more-specific prefix appears unexpectedly.
  • Route visibility changes across multiple regions at the same time.
  • The volume of BGP updates spikes in a short window.

Traffic telemetry (what you measure on the data plane):

  • Traffic concentrates on a network that is not provisioned to carry it.

The two are complementary, not interchangeable. An AS_PATH anomaly is a routing signal you read from BGP feeds; a traffic surge toward an unprepared network is a consequence you measure separately. Don't let one stand in for the other.

A simplified AS_PATH comparison:

Expected:
AS64500 → AS64501 → AS64502

Unexpected:
AS64500 → AS64501 → AS64510 → AS64502

The extra hop, AS64510, is a clue — not proof.

An unusual AS_PATH is evidence for investigation, not proof of a route leak. Relationship data can be incomplete or wrong.

Cloudflare's own detection pipeline makes this explicit. It combines AS-relationship inference (from CAIDA and in-house datasets, refined to per-prefix and per-peer granularity) with the AS Hegemony dataset to cut down false positives, then groups individual announcements into route-leak events. The raw material is BGP data from RouteViews and RIPE RIS — roughly two billion BGP messages a day across dozens of collectors. Even with all of that, the output is a likelihood, not a verdict.

White-Face Xiaolu examines an extra loop in a route string while distant observers watch from different points.

An unusual path is a signal to investigate; multiple vantage points make the picture more reliable.

8. How Networks Prevent and Detect Route Leaks

Think in three layers: prevention, detection, response.

Prevention

  • Deny unknown exports by default — whitelist, never blacklist.
  • Use separate, per-neighbor prefix filters for each customer, peer, and provider.
  • Set a sensible Maximum Prefix Limit on every session. This caps route count, so it catches bulk leaks — but it does not, by itself, validate propagation relationships.
  • Review, canary, and roll back configuration changes deliberately.
  • Give route servers their own explicit, separate policy.
  • Enable First-AS checks and relationship validation where they fit.

Detection

  • Monitor BGP updates and AS_PATH changes.
  • Observe from multiple route collectors and looking glasses.
  • Track prefix counts, origin ASNs, and visibility over time.
  • Alert on suddenly appearing more-specific prefixes.
  • Maintain a historical routing baseline to compare against.

Response

  • Stop the propagation first.
  • Withdraw the incorrect routes.
  • Restore the previous policy.
  • Check whether neighbors are still propagating stale paths.
  • Confirm recovery from multiple external vantage points.
  • Record the timeline and root cause.

9. What RPKI Can—and Cannot—Do

RPKI is a powerful tool, but it has a specific job, and route-leak prevention is not it.

What RPKI can do:

  • Verify whether a given ASN is authorized to originate a given prefix.
  • Help receivers identify some incorrect origins.
  • Reduce the impact of common origin hijacks.

What RPKI cannot do on its own:

  • It cannot validate the full AS_PATH.
  • It cannot tell whether a route was sent to the wrong peer.
  • It cannot guarantee a route is accepted globally.
  • It cannot replace export filters, max-prefix limits, or operational monitoring.
  • It cannot automatically solve every route leak.

Mechanisms that do target the propagation side are emerging. BGP Roles and the Only-to-Customer (OTC) attribute in RFC 9234 let neighbors encode their relationship and detect a leak when a route flows in the wrong direction. ASPA (Autonomous System Provider Authorization) would let a network declare its authorized providers so that others can reject paths that violate that relationship — but ASPA is still an active Internet-Draft, not a finalized RFC with broad deployment. These directions are promising, but their effectiveness depends on adoption, and that adoption is still uneven. None of them is a drop-in replacement for correct local policy.

10. A Practical Route-Leak Checklist

Before a policy change

  • Every neighbor's role is confirmed.
  • Export prefix lists use default-deny.
  • Customer, peer, and provider policies are independent.
  • Maximum Prefix Limit is set.
  • A rollback plan is ready.
  • Monitoring and external vantage points are confirmed working.

After deployment

  • Check the prefixes actually being sent.
  • Check the AS_PATH.
  • Check for abnormal route counts.
  • Re-verify from multiple external vantage points.
  • Confirm no unexpected more-specific prefixes appeared.

During an incident

  • Stop further propagation.
  • Withdraw the incorrect routes.
  • Restore the previous policy version.
  • Check neighbor caches and propagation state.
  • Record the timeline.
  • Verify traffic and visibility have recovered.

White-Face Xiaolu secures a route gate with a latch, gauge, and rope.

Layered controls reduce the chance that one policy mistake becomes a wider leak.

11. FAQ

Is a route leak the same as a BGP hijack?

No. A leak is mainly about propagation scope; a hijack is mainly about an unauthorized origin.

Can RPKI prevent route leaks?

Not by itself. RPKI focuses on origin authorization, not the full AS path or the business relationship.

Can a route leak happen accidentally?

Yes. Misconfigured export policies, automation changes, and incorrect neighbor roles are the most common causes — the Cloudflare incident began as an automation change, not an attack.

Can a small network cause a large outage?

Yes, if larger networks accept and propagate the leaked route. Telekom Malaysia in 2015 is the standing example.

Does an unusual AS_PATH prove a route leak?

No. It is a signal that requires relationship data and additional evidence.

Does "BGP session established" mean the route is safe?

No. Session health and route-policy correctness are separate things. A session can be up while the policy it enforces is wrong.

Conclusion

A route leak is not "the route disappeared." It is a boundary failure — a route announced into a part of the Internet where it was never meant to go, where it can then be believed, preferred, and propagated.

BGP, business relationships, and local policy together decide where a route actually travels. That is why a leak can look completely valid to everyone downstream while being completely wrong.

Real protection is not a single feature. It is export filters and prefix limits, relationship validation, RPKI for origin, and external monitoring for the path — layered together, because each one only covers part of the problem.

In One Sentence

A BGP route leak happens when a routing announcement travels beyond its intended policy boundary — something RPKI alone cannot prevent.

Related reading

Tools

Sources