Route leak incident on January 22, 2026

Route leak incident on January 22, 2026
blog.cloudflare.com

Is there any way to test these changes against a simulation of real world routes? Including to ensure that traffic that shouldn’t hit Cloudflare servers, continues to resolve routes that don’t hit Cloudflare?

I have to imagine there’s academic research on how to simulate a fork of global BGP state, no? Surely there’s a tensor representation of the BGP graph that can be simulated on GPU clusters?

If there’s a meta-rule I think of when these incidents occur, it’s that configuration rules need change management, and change management is only as good as the level of automated testing. Just because code hasn’t changed doesn’t mean you shouldn’t test the baseline system behavior. And here, that means testing that the Internet works.

Basically, my understanding (simplified) is:

- they originally had a Miami router advertise Bogota prefixes (=subnets) to Cloudflare's peers. Essentially, Miami was handling Bogota's subnets. This is not an issue.

- because you don't normally advertise arbitrary prefixes via BGP, policies were used. These policies are essentially if/then statements, carrying out certain actions (advertise or not, add some tags or remove them,...) if some conditions are matched. This is completely normal.

- Juniper router configuration for this kind of policy is (simplifying):

set from

set from

set then

set then

...

- prior to the incident, CF changed its network so that Miami didn't have to handle Bogota subnets (maybe Bogota does it on its own, maybe there's another router somewhere else)

- the change aimed at removing the configurations on Miami which were advertising Bogota subnets

- the change implementation essentially removed all lines from all policies containing "from IP in the list of Bogota prefixes". This is somewhat reasonable, because you could have the same policy handling both Bogota and, say, Quito prefixes, so you just want to remove the Bogota part.

HOWEVER, there was at least one policy like this:

(Before)

set from is_internal(prefix) == True

set from prefix in bogota_prefix_list

set then advertise

(After)

set from is_internal(prefix) == True

set then advertise

Which basically means: if you have an internal prefix advertise it

- an "internal prefix" is any prefix that was not received by another BGP entity (autonomous system)

- BGP routers in Cloudflare exchange routes to one another. This is again pretty normal.

- As a result of this change, all routes received by Miami through some other Cloudflare router were readvertised by Miami

- the result is CF telling the Internet (more accurately, its peers) "hey, you know that subnet? Go ask my Miami router!"

- obviously, this increases bandwidth utilization and latency for traffic crossing the Miami router.