Live data from Hacker News

Route leak incident on January 22, 2026

blog.cloudflare.com

11–20 of 64 posts

Re: Route leak incident on January 22, 2026

#11
That's like what, one major incident per month now, Nov 18, Dec 5, and now this one?

I'll bet JGC can write his own ticket by now, but unretiring would be really bad optics. He's on the board though and still keeping a watchful eye. But a couple more of these and CFs reputation will be in the gutter.

Re: Route leak incident on January 22, 2026

#14

I’m a huge fan of flapping when it’s really hard to do progressive rollouts. What this would mean here is you switch advertising the old and new routes back and forth automatically and this happens let’s say for 1 minute max before the old config is restored. Then a human looks at various metrics before they push a button to really make the new config permanent. It gives you a cheap way to preflight what will happen…

nice way to 100% the router CPUs for all your peers

Re: Route leak incident on January 22, 2026

#16
post #3

> we pushed a change via our policy automation platform to remove the BGP announcements from Miami 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…

> 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?

You can get access to view of routes from different parts of networks but you do not have access to those routers policies, so no

> 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?

Just simulating your peers and maybe layer after is most likely good enough. And you can probably do it with a bunch of cgroups and some actual routing software. There are also network sims like GNS3 that can even just run router images

Re: Route leak incident on January 22, 2026

#17
post #3

> we pushed a change via our policy automation platform to remove the BGP announcements from Miami 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…

I assume it's not possible unless you know the in-memory state of all the other gateway routers on the internet, no? You can know what they advertise, but that's not the same thing as a full description of their internal state and how they will choose to update if a route gets withdrawn.

I think you could know the state of the peers and simulate what they advertise and receive and validate that. The test unit would need to be a simulated router that behaves exactly as the real one, I actually think its technically doable with tight version control for routers.

Re: Route leak incident on January 22, 2026

#18
post #5

The string of recent incidents don't really make the new CTO look good. Too much focus on shipping, not enough on shipping correctly.

Welcome to the age of AI-assisted coding.

I could have sworn "move fast and break things" existed before AI.

Re: Route leak incident on January 22, 2026

#19
post #7

I've had to read the RCA a couple of times to (probably) get what happened, even if I'm reasonably familiar with BGP. 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. T…

I am not very familiar with Juniper config, but this phrase summarizes it well. "This means we (AS13335) took the prefix received from Meta (AS32934), our peer, and then advertised it toward Lumen (AS3356), one of our upstream transit providers. " basically you should not receive a prefix from an eBGP session ( different AS) and advertize to an eBGP session. As they mention at the next steps, good use of communities could help avoiding it, in case of other misconfigurations.

Re: Route leak incident on January 22, 2026

#20
Based on the number of times I've seen these posted about they seem quite frequent[0]. If I'm being honest, the entire BGP system seems to be very fragile with a massive blast radius. I get that it's super 'core' so it's hard to fix, and that it comes from a time when the Internet was more 'cooperative' (in the protocol sense of the word) but are there any attempts at a successor or is it impossible to do so fundamentally?

Surely the notion of who owns an AS should be cryptographically held so that an update has to be signed. Updates should be infrequent so the cost is felt on the control plane, not on the data plane.

I'm sure there's a BGPSec or whatever like all the other ${oldTech}Sec but I don't know if there is a realistic solution here or if it's IPv6 style tech.

0: I looked it up before posting and it's 3000 leakers with 12 million leaks per quarter https://blog.qrator.net/en/q3-2022-ddos-attacks-and-bgp-inci...

Post reply on HN