techlist.io
KREN
cloudflare

Route leak incident on January 22, 2026 (opens in new tab)

bgpnetworkingipv6route-leaknetwork-automationjunos

On January 22, 2026, a routing-policy automation error caused Cloudflare to leak IPv6 BGP prefixes from its Miami data center. For 25 minutes, external traffic was redirected through Miami, congesting backbone links, increasing latency and packet loss, and causing some traffic to be dropped by firewall filters. The incident resulted from removing prefix-list constraints, leaving a Juniper policy that accepted and externally advertised unintended internal routes.

What a BGP Route Leak Is

  • A route leak occurs when an autonomous system advertises routes it is not supposed to forward.
  • This violates valley-free routing principles, such as sending routes learned from a peer onward to another peer or provider.
  • The leaking network may lack the capacity or firewall rules to handle the redirected traffic.
  • Cloudflare’s incident involved a mixture of Type 3 and Type 4 route leaks under RFC 7908.

Incident Impact and Timeline

  • The triggering automation change was merged at 19:52 UTC.
  • At 20:25 UTC, it ran on a single Miami edge router and caused unexpected advertisements to peers and transit providers.
  • The network team began investigating at 20:40 UTC and formally coordinated the incident at 20:44 UTC.
  • At 20:50 UTC, an operator reverted the bad configuration and paused automation on the router.
  • The leak lasted approximately 25 minutes, causing:
    • Congestion on Miami backbone infrastructure
    • Increased packet loss and latency for some Cloudflare customers
    • Traffic from unrelated external networks to be funneled through Miami
    • Packet drops from firewalls configured to accept only Cloudflare-related traffic
  • The triggering code change was reverted at 21:47 UTC, and automation was later verified and resumed.

The Configuration Error

  • Cloudflare intentionally removed Miami advertisements for a Bogotá data center after infrastructure changes made the Miami-to-Bogotá forwarding path unnecessary.
  • The change removed 6-BOG04-SITE-LOCAL prefix-list conditions from multiple export policies.
  • Those prefix lists had constrained policies to specific Bogotá prefixes.
  • Once removed, policies such as 6-TELIA-ACCEPT-EXPORT still matched routes with route-type internal and accepted them for export.
  • On Juniper JunOS and JunOS EVO, route-type internal matches any non-external route, including Internal BGP (IBGP) routes.
  • Consequently, routes that should have remained internal were treated as exportable and advertised to external peers and providers.
  • The problem affected IPv6 traffic only.

Response and Remediation

  • Operators manually reverted the generated router configuration.
  • Automation was paused on the affected Miami router to prevent the faulty policy from being reapplied.
  • The source-code change was reverted, and the router was checked before automation resumed.

Cloudflare’s incident demonstrates that removing seemingly obsolete route filters can unintentionally broaden a policy. Export policies should explicitly constrain acceptable prefixes and include validation or safeguards that prevent internal routes from being advertised externally.