Live data from Hacker News

Route leak incident on January 22, 2026

blog.cloudflare.com

21–30 of 64 posts

Re: Route leak incident on January 22, 2026

#21
I do appreciate these post mortems from Cloudflare, however I wish they would include timestamps of their status page posts in their timelines.

In this case, the timeline states "IMPACT STOP" was at 20:50 UTC and the first post to their status page was 12 minutes later at 21:02 UTC:

"Cloudflare experienced a Network Route leak, impacting performance for some networks beginning 20:25 UTC. We are working to mitigate impact."

Re: Route leak incident on January 22, 2026

#22
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 don't know why you would need a tensor whatever. Dump the state of the router (which peers are connected and for how long what routes are they advertising and for how long) as well as the computed routing table and what routes are advertised to peers.

Set a simulation router to have the same state but a new config, and compute the routing table and what routes would he advertised to peers.

Confirm the diff in routing table and advertised routes is reasonable.

This change seemed to mostly be about a single location. Other BGP config changes leading to problems are often global changes, but you can check diffs and apply the config change one host at a time. You can't really make a simultaneous change anyway. Maybe one host changing is ok, but the Nth one causes a problem... CF has a lot of BGP routers, so maybe checking every diff is too much, but at least check a few.

Is that something out of the box on routers? I don't know, people with BGP routers never let me play with them. But given the BGP haiku, I'd want something like that before I messed around with things. For the price you pay for these fancy routers, you should be able to buy an extra few to run sandboxed config testing on. You could also simulate with open source bgp software, but the proprietary BGP daemon on the router might not act like the open source one does.

Re: Route leak incident on January 22, 2026

#23
post #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 fundamen…

Globally, it is as you want it to be.

Locally, BGP is peer-to-peer — literally! — and no particular peer is forced to check everything, and nobody's even trying to make a single global routing table so local agreements can override anything at a higher level.

Re: Route leak incident on January 22, 2026

#25
post #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 fundamen…

Globally, it is as you want it to be. Locally, BGP is peer-to-peer — literally! — and no particular peer is forced to check everything, and nobody's even trying to make a single global routing table so local agreements can override anything at a higher level.

I see. That makes sense.

Re: Route leak incident on January 22, 2026

#28
post #25

Earlier quoted context omitted.

Globally, it is as you want it to be. Locally, BGP is peer-to-peer — literally! — and no particular peer is forced to check everything, and nobody's even trying to make a single global routing table so local agreements can override anything at a higher level.

I see. That makes sense.

A route leak is often like this: an ISP in Pakistan is ordered to censor YouTube, so they add a route internally to YouTube's IP addresses that passes to their censoring machine, or to nowhere. They accidentally have their edge routers configured to pass this route to all their connected networks instead of keeping it internally to themselves. Some of their peers recognize this as the shortest route to YouTube and install it into their own networks. Others recognize it's not the real YouTube and ignore it. Transit providers check route authorization more thoroughly than peers, so none of them accept it and the route doesn't spread globally.

Re: Route leak incident on January 22, 2026

#29

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.

That’s what I also thought when I saw this incident. I wonder if there’s something up internally at Cloudflare or that it was always like this.

I feel like something such as a route leak should not be something that happens to Cloudflare. I’m surprised they set their systems up to allow this human error.

Post reply on HN