Cloudflare 因路由器配置错误：流量下降 50%、80 多个网站瘫痪

Cloudflare出故障，大量网站随之瘫痪， 胆惊受怕了9分钟。

受影响的服务包括Cloudflare API和Cloudflare Recursive DNS，这两项服务都被标注为性能出现降级。在Cloudflare处理网络流量的全球诸多地区，状态页面显示数据在重新路由。

Cloudflare首席执行官Matt Prince指出罪魁祸首是美国亚特兰大的一台路由器：

他补充道，故障“似乎在20分钟多一点的时间内影响了我们约50%的流量。”

由于Cloudflare为许多非商业和商业网站处理DNS服务和边缘计算服务，因此短暂的服务中断立即引起了注意。

处理一半互联网DNS服务的Cloudflare遭遇“故障”。许多网站和服务受影响。

突发新闻：重大故障导致网站托管、网络和互联网安全提供商Cloudflare瘫痪。故障基本上已得到解决。80多个网站和应用出现宕机。

据称受影响的服务包括：Authy、Digital Ocean、Discord、Downdetector、GitLab、Medium，Patron和Riot等。

尽管该事件持续时间很短，但再次向世人提醒关键在线服务是何等脆弱。

以下为Cloudflare首席技术官John Graham-Cumming在官方博客发布的《2020年7月17日Cloudflare故障分析报告》：

今天，我们的骨干网络出现了一个配置错误，导致众多网站和Cloudflare服务出现故障，故障持续了27分钟。我们发现，我们整个网络上的流量下降了约50%。由于我们骨干网的体系结构，这次故障并没有影响整个Cloudflare网络，仅局限于某些地区。

之所以出现故障，是由于我们在处理从纽瓦克到芝加哥的骨干网的一个网段存在的毫无关联的问题时，我们的网络工程团队更新了亚特兰大一台路由器上的配置以缓解拥塞。该配置有一个错误，导致了我们骨干网上的所有流量统统被发送到亚特兰大。这很快使亚特兰大的那台路由器不堪重负，进而导致连接到骨干网的Cloudflare网络位置出现了故障。

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

有必要澄清一下：这次故障不是任何一种攻击或安全事件引起的。

我们为这次故障深表歉意，已经对骨干网配置进行了全局变更，防止故障再次出现。

Cloudflare骨干网

Cloudflare在我们遍布全球的许多数据中心之间运营着骨干网（backbone）。这个骨干网是我们的数据中心之间的一系列专用线路，用于数据中心之间更快速、更可靠的路径。这些连接让我们得以在不经过公共互联网的情况下在不同数据中心之间传输流量。

比如说，我们使用该骨干网来联系位于纽约的一台网站原始服务器，通过我们的专用骨干网将请求传输到加利福尼亚州圣何塞或远至法兰克福或圣保罗的地方。避免使用公共互联网的这个额外选择可以带来更高的服务质量，因为这个专用网络可用来避免互联网拥塞点。借助骨干网，我们可以在何处路由以及如何路由互联网请求和流量方面获得极大的控制权，比公共互联网提供的控制权大得多。

故障时间表

时间一律采用协调世界时（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路由泄露到骨干网。

完整的term看起来是这样的：

该term设置了本地优先级，添加了一些团体（community），并接受与前缀列表匹配的路由。本地优先级是iBGP会话方面的一个传递属性（它会被转移到下一个BGP peer）。

正确的变更应该是使该term无效，而不是使前缀列表无效。

通过删除前缀列表条件，路由器被指令将其BGP路由统统发送到所有其他骨干路由器，本地优先级增加到200。遗憾的是，当时，边缘路由器从我们的计算节点收到的本地路由其本地优先级为100。由于较高的本地优先级占上风，原本发送到本地计算节点的所有流量都改而发送到了亚特兰大计算节点。

路由发送出去后，亚特兰大开始吸引来自整个骨干网的流量。

我们正在进行以下更改：

• 对我们的骨干BGP会话实行最大前缀限制——这会关闭亚特兰大的骨干网，但是我们的网络可以在没有骨干网的情况下正常运行。此更改将在7月20日周一部署到位。

• 更改本地服务器路由的BGP本地优先级。此更改将防止单单一个位置以类似方式吸引其他位置的流量。这次故障事件后，此更改已部署到位。

结束语

我们从未遇到过骨干网出现故障的情况，我们的团队迅速做出了反应，在受影响的位置恢复了服务，但这对于每个受影响的人/公司来说都是一段很痛苦的时期。我们为故障期间无法访问网站的客户和所有用户深表歉意。

我们已经对骨干网配置进行了变更，以确保不会再次发生这种情况，进一步的变更会在周一继续进行。