今天上午9:47 UTC CloudFlare实际上已从互联网上退出。宕机影响了CloudFlare的所有服务，包括DNS和任何依赖于我们的web代理的服务。在停电期间，任何人CloudFlare.com网站或者CloudFlare网络上的任何站点都会收到DNS错误。到CloudFlare网络的ping和Traceroutes导致"No Route to Host"错误。中断的原因是我们的边缘路由器的全系统故障。CloudFlare目前在全球运营23个数据中心。这些数据中心通过路由器连接到互联网的其余部分。这些路由器公布了从因特网上的任何一点，数据包应该用来到达我们的网络的路径。当路由器从网络的其余部分退出网络时，路由器就退出了。当我们升级一个设备时，我们会定期关闭一个或一小部分路由器。因为我们使用Anycast，所以流量自然无法到达下一个最近的数据中心。然而，今天早上我们遇到了一个bug，它导致我们所有的路由器在网络范围内出现故障。数据流说明我们主要是CloudFlare的Juniper商店，所有受影响的边缘路由器都来自Juniper。我们喜欢Juniper的原因之一是他们支持一个叫做Flowspec的协议。Flowspec允许您高效地将路由器规则传播到大量路由器。在CloudFlare，我们不断更新路由器上的规则。我们这样做是为了抵抗攻击，以及转移流量，以便尽可能快地提供服务。今天早上，我们看到了一个针对我们的客户的DDoS攻击。这次攻击专门针对客户的DNS服务器。我们有一个内部工具来分析攻击并输出特征信号，我们的自动化系统和我们的运营团队可以用来阻止攻击。通常，我们使用这些签名来创建路由器规则，以限制速率或丢弃已知的错误请求。在这种情况下，我们的攻击探查器会输出攻击数据包的长度介于99971和99985字节之间。这很奇怪，因为通过互联网发送的最大数据包通常在1500字节的范围内，平均在500-600字节左右。我们的网络上的最大数据包大小设置为4470，这是一个大的数据包，但远远低于攻击分析器告诉我们的这些攻击数据包的大小。坏规则我们的运营团队有人在全天候监控我们的网络。对于我们来说，通常的做法是，我们的一个ops团队成员从profiler获取输出，并根据其输出添加一个规则来丢弃长度在99971到99985字节之间的数据包。以下是Juniper操作系统Junos中的规则（有点简化，IPs模糊）：+路线173.X.X.X/32-DNS-DROP{+匹配{+目的地173.X.X.X/32；+端口53；+包长度[999719985]；+ }+然后丢弃；+ }Flowspec接受了规则并将其转发到我们的边缘网络。应该发生的是没有数据包应该与该规则相匹配，因为实际上没有任何数据包那么大。相反，路由器遇到了这个规则，然后继续消耗所有的RAM，直到崩溃。在所有情况下，我们都会运行一个监控过程，在路由器崩溃时自动重新引导它们。在一些情况下是有效的。不幸的是，许多路由器崩溃的方式，他们没有自动重新启动，我们无法访问路由器的管理端口。尽管一些数据中心最初恢复了在线状态，但由于整个网络上的所有流量都对它们造成了冲击，并使其资源过载，因此它们又重新出现故障。旧金山城市学院（City College of San Francisco）的计算机科学教授萨姆·鲍恩（Sam Bowne）使用BGPlay捕捉到以下视频：我们的路由器崩溃时，BGP会话被撤回：事件响应由于我们在网络上运行内部和外部监视器，CloudFlare的运营和网络团队立即意识到了这一事件。虽然最初还不清楚路由器崩溃的原因，但很明显，这是由于数据包无法找到到我们网络的路由而引起的。我们可以访问一些路由器，看到它们在遇到这个坏规则时崩溃了。我们删除了这个规则，然后打电话给路由器没有反应的数据中心的网络运营团队，要求他们物理上访问路由器并执行硬重启。CloudFlare的23个数据中心跨越14个国家/地区，因此响应需要一些时间，但在大约30分钟内，我们开始恢复CloudFlare的网络和服务。到UTC时间10:49，CloudFlare的所有服务都已恢复。我们继续调查一些边缘案例，人们看到了停机。在几乎所有这些情况下，问题是缓存了坏的DNS响应。通常清除DNS缓存将解决此问题。我们已经联系了Juniper，看看这是一个已知的bug，还是我们的设置所特有的东西，以及我们当时看到的流量类型。我们将对Flowspec提供的过滤器进行更广泛的测试，并评估是否有办法将规则的应用隔离到需要更新的数据中心，而不是在整个网络范围内应用规则。最后，我们计划主动向sla涵盖的客户发放服务积分。任何停机时间都是我们完全不能接受的，整个CloudFlare团队都很抱歉今天早上让我们的客户失望了。与叙利亚相似在写这篇文章时，我想起了我们今年早些时候报道的叙利亚互联网中断事件。在这种情况下，我们能够察觉到叙利亚政府关闭了他们的板卡路由器，并有效地切断了该国与其他互联网的联系。在CloudFlare的例子中，原因不是故意的，也不是恶意的，但是最终效果是一样的：路由器的改变导致网络离线。在CloudFlare，我们花了大量时间沉浸在互联网路由的黑暗艺术中。这次事件和叙利亚事件一样，说明了这些网络协议的力量和重要性。我们今天早上让我们的客户失望了，但我们会从这次事件中吸取教训，并采取更多的控制措施，以便将来消除此类问题。