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
Query via OpenMCP
This encore is part of the public Open Playback corpus. Connect OpenMCP in Claude or Cursor to search and retrieve structured post-mortems like this one from your agent.
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.