史上最大服务中断事故复盘：全球互联网流量下降 3.5% 只因一次配置错误？

近日，美国互联网服务提供商 CenturyLink 因数据中心的错误配置导致多个网站受到影响。据了解，这次事故是 BGP 路由配置错误引起的连锁反应，受到影响的服务包括 Cloudflare、AWS、Garmin、Steam、Discord 和 Blizzard 等。

Twitter 用户吐槽服务中断

在此次事故中受到严重影响的 Cloudflare 表示：“CenturyLink 的向外传播问题导致全球互联网流量下降了 3.5%，这将是有史以来最大的互联网中断之一。”最终，CenturyLink 花了 7 个小时才解决了这个问题。

为什么会出现这次事故呢？Cloudflare 官方博客发布了文章来复盘此次事故，下面我们就一起来看看吧。

服务器上的错误数量激增，服务开始大面积出现问题

当天上午 10：03（世界标准时间），Cloudflare 监管系统开始观察到客户原始服务器上的错误数量有所增加。结果显示为“错误 552”，代表从 Cloudflare 网络连接、到客户托管应用程序的各个位置，开始大面积出现问题。

除 CenturyLink/Level (3) 之外，Cloudflare 还同时与其他众多大型网络服务供应商保持对接。在发现某一家网络服务供应商的设施错误量增加时，系统会自动尝试经由其他供应商访问客户的应用程序。凭借这种故障转移机制，即使某家供应商遭遇问题，一般也可以继续正常路由流量。

Cloudflare 接入的各家网络供应商

因此，当 522 错误数量开始增加的几秒钟之后，Cloudflare 的系统开始自动将流量由 CenturyLink/Level (3) 重新路由至其他备用网络供应商处，包括 Cogent、NTT、GTT、Telia 以及 Tata。

上图为 Cloudflare 网络与所对接的各网络服务供应商之间的六条核心一级主干网络之间的流量。红色部分代表 CenturyLink/Level (3) 流量，该流量在故障期间降至接近于零。

上图为故障事件发生期间网络上出现的总计 522 错误数量。10：03 起，急剧上升的部分为 CenturyLink/Level (3) 网络错误数量。当时，自动化系统立即开始重新路由并将流量均衡至其他各网络服务供应商处。通过此举，错误数量减少了一半，随后又通过针对新路径的优化而进一步降低至峰值水平的 25%。

在 10：03 至 10：11 期间，系统自动在 48 座城市中禁用了 CenturyLink/Level (3)，并通过其他网络服务供应商重新路由流量。为了防止级联故障，系统在转移流量之前会考虑到其他服务供应商的网络传输容量。正因为如此，自动化故障转移并非在各个位置同步进行。与此同时，Cloudflare 团队又采取其他手动缓解措施，保证将错误数量再减少 5%。

那么，问题可能源自何处？

事故发生的真正原因可能只有 CenturyLink/Level(3) 发布最终取证报告之后才能明确，但通过 BGP 公告中的线索以及中断期间的影响传播，我们可以做出推测。BGP 是指边界网关协议，即互联网上的各路由器如何相互通报其后的 IP 地址，及其接收传输流量的具体方式。

从 10：04 开始，互联网上出现了大量 BGP 更新。BGP 更新，代表着由路由器发出的、原有路由已经发生更改或不再可用的指示信号。在正常情况下，互联网上每 15 分钟会出现 1.5 MB 到 2 MB 大小的 BGP 更新流量。但在事件开始之后，BGP 更新的规模激增至每 15 分钟超过 26 MB，而且在此次故障期间始终保持在较高水平。

资料来源:http://archive.routeviews.org/bgpdata/2020.08/UPDATES/

这些更新表明，CenturyLink/Level(3) 主干网内部的 BGP 路由很不稳定。问题是，这种不稳定从何而来？通过 CenturyLink/Level(3) 状态更新中的一点线索，加上一项 flowspec 更新中显露的端倪，我们似乎可以做出大胆猜测。

在 CenturyLink/Level(3) 的更新通报中，提到引发此次问题的根源在于错误的 Flowspec 规则。那么 Flowspec 是什么？它是 BGP 的扩展，允许使用 BGP 在网络之内甚至是网络之间轻松分发防火墙规则。Flowspec 是一款功能强大的工具，可以帮助用户几乎即时在整个网络之上高效推送规则。在尝试快速对网络攻击等事件做出响应时，这种推送能力当然非常重要；但在另一方面，如果出现了错误，那么这些错误也将被快速传播到网络中的各个角落。

Cloudflare 的发展历程中也曾使用 Flowspec 推送防火墙规则，借此缓解例如大型网络层 DDoS 攻击等极端事件。但是在 7 年前，Cloudflare 遭遇到由 Flowspec 造成的停机，于是决定不再亲自使用 Flowspec。

我们推测 CenturyLink/Level(3) 到底经历了什么。一种可能的情况是，他们发出了 Flowspec 命令，尝试阻止针对当前网络的攻击或其他滥用行为。状态报告表明，Flowspec 规则阻止了 BGP 本体的正常发布。现在无法知悉 CenturyLink/Level(3) 到底编写了怎样的 Flowspec 规则，唯一可以肯定的就是这是一条 Juniper 格式的规则，会阻止其网络上的所有 BGP 通信。

route DISCARD-BGP {match {protocol tcp;destination-port 179;}then discard;}

另外，在此次事件中，全局 BGP 更新始终保持在较高水平的原因仍旧是个谜。如果说 Flowspec 规则阻止了 BGP，那么更新公告刚开始会有所增加，而后又逐步恢复正常才对。

一种可能的解释是，有问题的 Flowspec 规则正好接上了一条长长的 BGP 更新清单的结尾。如果情况真是如此，那么 CenturyLink/Level(3) 网络中的每个路由器都将接收到 Flowspec 规则，进而开始阻止 BGP 更新，也就是停止接收规则。各中山路将重新启动，遍历所有 BGP 规则，直到再次运行到存在问题的 Flowspec 规则为止——这时，BGP 将再次被丢弃，后续 Flowspec 规则无法正常接收。整个循环一次又一次重复，而每过一轮周期，CenturyLink/Level(3) 网络中的 BGP 更新队列都会持续增加。这个问题有可能已经导致路由器的内存与 CPU 发生过载，并给在线网络恢复带来一系列额外的挑战。

为什么修复时间这么长？

Cloudflare 的服务中断问题是在四个小时之后才得到解决的，为什么这次修复时间这么长？

首先，出现故障的原因不明，Cloudflare 只是依据故障事件作出了相关的推测，可能是由于 Flowspec 以及大量 BGP 更新给其路由器带来了巨大负担，导致 CenturyLink/Level(3) 运营人员难以登录设备接口。所以，在 CenturyLink/Level(3) 的请求下，其他几家一级网络供应商也纷纷采取行动，取消各方之间的对等网络。这一做法限制了 CenturyLink/Level(3) 网络接收到的 BGP 公告数量，帮助他们争取到了宝贵的时间窗口。

其次，存在问题的 Flowspec 规则可能并非由 CenturyLink/Level(3) 发布，而是来自他们的某位客户。目前不少网络服务供应商都允许 Flowspec 对等传播。对于希望阻止攻击流量的下游客户来说，这无疑是一种强大的工具；但一旦出现问题，对违规 Flowspec 规则的追踪也变得更加困难。

最后一点是 CenturyLink/Level(3) 拥有极为庞大且复杂的网络体系，因此故障可以说是一刻不停地出现。

相关链接：

https://blog.cloudflare.com/analysis-of-todays-centurylink-level-3-outage/