这是您处理路线泄漏的方式

Here’s the beginning: for approximately an hour, starting at 19:28 UTC on April 1, 2020, the largest Russian ISP — Rostelecom (AS12389) — was announcing prefixes belonging to prominent internet players: Akamai, Cloudflare, Hetzner, Digital Ocean, Amazon AWS, and other famous names.

这是一个开始：从2020年4月1日世界标准时间19:28 UTC开始，大约一个小时，俄罗斯最大的ISP- Rostelecom (AS12389)-宣布了著名互联网参与者的前缀：Akamai，Cloudflare，Hetzner，Digital Ocean，Amazon AWS和其他著名名称。

Before the issue was resolved, paths between the largest cloud networks were somewhat disrupted — the Internet blinked. The route leak was distributed quite well through Rascom (AS20764), then Cogent (AS174) and in a couple of minutes through Level3 (AS3356) to the world. The issue suddenly became bad enough that it saturated the route decision-making process for a few Tier-1 ISPs.

在问题解决之前，最大的云网络之间的路径已被某种程度的破坏— Internet闪烁。 路由泄漏通过Rascom (AS20764)，然后是Cogent (AS174)以及通过Level3 (AS3356)在几分钟之内就已经分布得很好。 这个问题突然变得非常严重，以至于使一些Tier-1 ISP的路由决策过程变得饱和。

It looked like this:

它看起来像这样：

With that:

接着就，随即：

This leak affected 8870 network prefixes belonging to almost 200 autonomous systems. With a lot of invalid announcements that weren’t discarded by all those accepting tiers. Ultimately, it wouldn’t change the day, but the distribution of the route leak could be lower if the filters were in place. Take a look at RIPE BGPlay if you want to observe the dynamics of what has happened: https://stat.ripe.net/widget/bgplay#w.resource=2.17.123.0/24

此泄漏影响了8870个属于几乎200个自治系统的网络前缀。 许多无效的公告并没有被所有接受等级的人丢弃。 最终，日期不会改变，但如果安装了过滤器，则路线泄漏的分布可能会更低。 如果您想观察发生的情况，请看一下RIPE BGPlay： https ://stat.ripe.net/widget/bgplay#w.resource=2.17.123.0/24

As we wrote yesterday, all network engineers should be aware of what they are doing, preventing the chances of such a crucial mistake. The mistake Rostelecom has made illustrates how fragile the IETF-standardized BGP routing is, and especially — during such stressful times in terms of traffic growth.

就像我们昨天写的那样 ，所有网络工程师都应该意识到自己在做什么，以防止发生这种严重错误的机会。 Rostelecom犯的错误说明了IETF标准化BGP路由的脆弱性，尤其是在流量增长如此紧张的时期。

However, what makes the case very different is that Rostelecom got a warning from the Qrator.Radar’s real-time feed and reached out for help with the incident troubleshooting.

但是，情况却截然不同的是Rostelecom收到了Qrator.Radar的实时提要的警告，并提供了有关事件故障排除的帮助。

Given the simplicity of the BGP mistakes, during the coronavirus crisis, it’s so easy to allow for an error. However, with the monitoring data provided, the incident came to an end rather quickly, and the proper routing was restored.

鉴于BGP错误的简单性，在冠状病毒危机期间，允许错误非常容易。 但是，有了提供的监视数据，事件很快就结束了，并且恢复了正确的路由。

We strongly encourage other ISPs who are not Rostelecom to start monitoring their BGP announcements to prevent incidents of scale. And, of course, RPKI Origin Validation is something everyone shouldn’t just think about, but implement.

我们强烈鼓励非Rostelecom的其他ISP开始监视其BGP公告，以防止发生规模事件。 而且，当然，RPKI Origin Validation是每个人都不应只是考虑而是实施的东西。

翻译自: https://habr.com/en/company/qrator/blog/495260/