订阅以接收新文章的通知:

2020 年 7 月 17 日 Cloudflare 中断故障

2020-07-18

3 分钟阅读时间
这篇博文也有 English日本語한국어繁體中文版本。

今天(7 月 17 日),我们主干网络的一个配置错误导致互联网资产和 Cloudflare 服务中断了 27 分钟。我们发现整个网络的流量下降了大约 50%。鉴于我们的主干架构设计,这次中断没有影响到整个 Cloudflare 网络,而是仅限于局部地区。

中断的原因是:在处理从纽瓦克到芝加哥的一段主干网的不相关问题时,我们的网络工程团队更新了亚特兰大一台路由的配置,以期缓解拥塞。该配置包含一个错误,导致我们主干网上的所有流量都被发送到亚特兰大。这很快导致亚特兰大路由器不堪重负,使得连接至主干网的 Cloudflare 网络位置出现故障。

受影响的位置包括圣何塞、达拉斯、西雅图、洛杉矶、芝加哥、华盛顿、里士满、纽瓦克、亚特兰大、伦敦、阿姆斯特丹、法兰克福、巴黎、斯德哥尔摩、莫斯科、圣彼得堡、圣保罗、库里蒂巴和阿雷格里港。其他位置继续正常运行。

为避免疑义,故作此解释:这不是由任何类型的攻击或破坏造成的。

我们对此中断深感抱歉,并且已经对主干网配置进行了全局更改,以防中断再次发生。

Cloudflare 主干网

Cloudflare 运营着_我们全球多家数据中心之间的主干网。_主干网是我们数据中心之间的一系列专用线路,我们使用这些线路在它们之间建立更快、更可靠的路径。这些链接让我们能在不同的数据中心之间传输流量,而无需通过公共互联网。

例如:我们用它来访问位于纽约的网站源服务器,通过我们的专用主干网将请求传送到加利福尼亚州的圣何塞,甚至法兰克福或圣保罗。这种避开公共互联网的额外方案可以实现更高质量的服务,因为专用网络可以用来避开互联网拥塞点。通过主干网,我们对于在何处和如何路由互联网请求和流量的控制方面优于公共互联网。

时间表

所有时间均为格林威治时间 (UTC)。

首先,纽瓦克和芝加哥之间的主干网线路出现问题,导致亚特兰大和华盛顿之间发生主干网拥塞。

为了解决这个问题,工作人员在亚特兰大进行了配置更改。此更改导致于 21:12 发生中断。工作人员立即查明中断原因,禁用了亚特兰大路由器,流量在 21:39 开始恢复正常流动。

不久,我们在一个处理日志和指标的核心数据中心发现了拥塞,导致一些日志丢失。在此期间,边缘网络继续正常运行。

  • 20:25:EWR 和 ORD 之间的主干网链接丢失

  • 20:25:ATL 和 IAD 之间的主干网拥塞

  • 21:12 至 21:39:ATL 从整个主干网中吸引流量

  • 21:39 至 21:47:ATL 从主干网断开,服务恢复

  • 21:47 至 22:10:核心拥塞导致一些日志丢失,边缘网络继续运行

  • 22:10:全面恢复,包括日志和指标

这是关于 Cloudflare 内部流量管理工具影响的视图。顶部的红色和橙色区域显示亚特兰大的 CPU 利用率达到过载,白色区域则显示受影响的数据中心的 CPU 利用率降至接近零,因为它们不再处理流量。这就是中断期间的情况。

其他未受影响的数据中心在中断期间的 CPU 利用率没有发生变化。事实表明,在这些数据中心发生中断故障期间,绿色区域没有变化。

事件描述以及我们的措施

由于亚特兰大发生主干网拥塞,该团队决定移除亚特兰大的部分主干网流量。这原本一行的命令修改,本应将亚特兰大的路由从主干网中移除,但结果反而泄露了所有的 BGP 路由至主干网。

{master}[edit]
atl01# show | compare 
[edit policy-options policy-statement 6-BBONE-OUT term 6-SITE-LOCAL from]
!       inactive: prefix-list 6-SITE-LOCAL { ... }

完整术语看起来是这样的

from {
    prefix-list 6-SITE-LOCAL;
}
then {
    local-preference 200;
    community add SITE-LOCAL-ROUTE;
    community add ATL01;
    community add NORTH-AMERICA;
    accept;
}

该术语设置了 local-preference,添加了一些 BGP Communities,接受了可以匹配 prefix-list 的路由。Local-preference 是 iBGP 会话的一个传递属性(它将被转移到下一个 BGP 邻居)。

正确的更改方式应该是停用该 Term,而不是修改 prefix-list。

通过移除 prefix-list 条件,路由器得到指示,将所有 BGP 路由,以 local-preference 200 的属性,发送到所有其他主干网路由器。但不幸的是,当时边缘路由器从我们的计算节点收到的本地路由的 local-preference 仅为 100。随着 local-preference 的增高,本地计算节点的所有流量转而流向亚特兰大计算节点。

随着路由的发出,亚特兰大开始从主干网中吸引流量。

我们的更改措施如下:

  • 在我们的主干网 BGP 会话中引入最大前缀限制——这将关闭亚特兰大的主干网。但我们的网络设计,是可以在没有主干网的情况下继续正常运行的。此更改将于 7 月 20 日(周一)部署。

  • 更改当地服务器路由的 BGP local-preference。此更改将避免单个位置以类似的方式吸引其他位置的流量。此更改已在故障发生后部署。

总结

我们的主干网以前从未中断过,故障发生后,我们的团队迅速做出反应,帮助受影响的位置恢复了服务,但对于所有涉及到的人员来说都是一段痛苦的经历。对于我们的客户以及所有在中断期间无法使用互联网资产的用户,我们深感抱歉。

我们已经对主干网配置进行了更改,以确保这种情况不会再次发生,我们将在周一(7 月 20 日)继续进一步更改。

我们保护整个企业网络,帮助客户高效构建互联网规模的应用程序,加速任何网站或互联网应用程序抵御 DDoS 攻击,防止黑客入侵,并能协助您实现 Zero Trust 的过程

从任何设备访问 1.1.1.1,以开始使用我们的免费应用程序,帮助您更快、更安全地访问互联网。要进一步了解我们帮助构建更美好互联网的使命,请从这里开始。如果您正在寻找新的职业方向,请查看我们的空缺职位
Post MortemOutage

在 X 上关注

Cloudflare|@cloudflare

相关帖子

2024年9月20日 14:00

Cloudflare incident on September 17, 2024

On September 17, 2024, during planned routine maintenance, Cloudflare stopped announcing 15 IPv4 prefixes, affecting some Business plan websites for approximately one hour. During this time, IPv4 traffic for these customers would not have reached Cloudflare and users attempting to connect to websites using addresses within those prefixes would have received errors. ...