Overly permissive routing policy causes IPv6 route leak from Miami router
Cloudflare · Source
- Started
- Jan 22, 2026
- Duration
- 25m
- Users affected
- Not disclosed
- Revenue impact
- Not disclosed
- Blast radius
- IPv6 traffic transiting Cloudflare's Miami edge and external networks whose prefixes were leaked
- Services
- bgp, network, miami-edge, backbone
Join the waitlist
Aftermath helps you ship structured post-mortems like this one for your own incidents. Encore keeps narrative, timeline, lessons, and action items in one place so the document stays useful after the incident is closed. Join the waitlist on the homepage when you want that workflow for your organization.
Summary
A change pushed via Cloudflare's policy automation platform was meant to stop a Miami router from advertising prefixes for a Bogota data center after recent infrastructure upgrades made that path unnecessary. Removing the prefix-list reference left the export policy matching by route-type internal alone, which JunOS evaluates broadly enough to include all internal BGP routes. As a result, IPv6 prefixes Cloudflare redistributes internally were exported to external peers and providers in Miami, creating a Type 3/Type 4 route leak in the sense of RFC 7908.
Impact
For 25 minutes, traffic from external networks was funneled toward Cloudflare's Miami router, congesting the Miami-to-Atlanta backbone and causing elevated packet loss and latency for some Cloudflare customers. Approximately 12 Gbps of traffic destined for non-customer prefixes was discarded by inbound firewall filters at peak.
Root cause
A change to remove BOG04 site-local prefix lists from several export policies left the policy with only a route-type internal match clause, which JunOS expands to all non-external route types including iBGP routes.
The change was applied via automation on a single Miami edge router as part of work to clean up BGP advertisements for an upgraded Bogota site.
Routing policies relied on positive prefix-list matching alone, with no community-based safeguards explicitly rejecting routes received from peers and providers on external export paths.
CI/CD for routing policy did not catch empty or overly permissive policy terms before the change reached production.
Resolution
A network operator manually reverted the bad configuration on the Miami router and paused automation for that router at 20:50 UTC, stopping the leak. The triggering code change was reverted from the repository at 21:47 UTC, and automation was confirmed safe and re-enabled at 22:40 UTC.
Lessons
- Removing prefix-list filters from a policy can make a route-type match clause significantly more permissive than intended, especially under JunOS where 'internal' includes IBGP.
- Defense in depth in BGP policy needs explicit rejection rules for routes received from peers and providers on external export, not only positive accept rules.
- Routing policy changes are easy to misjudge by reading diffs alone; static analysis in CI is more reliable than human review for catching empty or overly broad terms.
- The same 'leaker' role that other operators sometimes play can be played by a well-resourced network when a single config diff goes the wrong way.
Action items
- Patch the routing policy automation that produced the overly permissive policy and add similar guardrails for related failure modes.
- Add BGP community-based safeguards to external export policies that explicitly reject routes received from providers and peers.
- Add automatic routing policy evaluation into CI/CD pipelines, specifically checking for empty or erroneous policy terms.
- Validate vendor implementations of RFC 9234 (BGP Roles and the Only-to-Customer attribute) and prepare rollout.
- Encourage adoption of RPKI Autonomous System Provider Authorization (ASPA) so networks can reject routes with anomalous AS paths.