失败的原因是作为Level3提供程序的CenturyLink错误地制定了BGP规则安全协议中的Flowspec。 BGP Flowspec用于重定向流量，因此此错误导致提供商网络内的严重路由问题，这也影响了全球Internet的稳定性。当然，美国的用户受到的打击最大，但是在世界各地都感受到了这些问题的回声。
值得注意的是，CenturyLink是美国第三大电信公司，仅次于AT＆T和Verizon。
IETF的BGP Flowspec是RFC 5575，被描述为BGP MP-BGP的多协议扩展，其中包含网络层可达性信息（NLRI）可达性。 BGP FlowSpec是一种从路由转储攻击DDoS流量的替代方法，与RTBH（远程触发黑洞过滤）相比，这是一种比RTBH（远程触发黑洞过滤）更微妙的躲避攻击的方法，当从攻击地址到目的地址的所有流量都被阻止时。通常，RTBH是“末日武器”，并且是制止攻击的最后手段，因为RTBH的使用通常可以使攻击者实现自己想要的目标，即隔离其中一个地址。
BGP FlowSpec更加微妙，它本质上是一个防火墙过滤器，已插入BGP以过滤特定的端口和协议，并确定通过哪个路由的流量。因此，“白色”流量到达目的地地址，并定义为DDoS-从路由中删除。通过至少12个NLRI参数分析流量：
- 目标前缀。指定匹配的目标前缀。
- 源前缀。指定原始前缀。
- IP协议。包含一组{operator，value}对，用于映射IP数据包中的IP值字节。
- 港口。确定数据包是否将由TCP，UDP或两者处理。
- . , FlowSpec.
- . , FlowSpec.
- ICMP.
- ICMP.
- TCP.
- . IP- ( 2, IP-).
- DSCP. Class Of Service flag.
- Fragment Encoding
CenturyLink本身没有完整的崩溃报告，他们只提到了安大略省附近的数据中心。但是，路由故障非常严重，不仅普通用户而且CloudFlare工程师都注意到了，后者还使用CenturyLink的服务作为大型提供商。
根据CloudFlare的报告，这一切都是从格林尼治标准时间8月30日上午10:03出现522个错误的峰值开始的。
例如，自动故障重新路由系统能够减少错误的数量并将其减少到峰值的25％，但是网络连接和资源可用性方面的问题仍然存在并且具有全球性。所有这些都是在坠机开始时上午10:03到UTC上午10:11之间的一个窗口中完成的。在这八分钟内，自动化和工程师将其基础设施与北美48个（！）城市中的CenturyLink断开连接，并将流量重定向到其他提供商的备用通道。
显然，这不仅是在CloudFlare上完成的。但是，这并不能完全解决问题。为了清楚起见，有问题的提供商对美国和加拿大的电信市场产生了什么影响，该公司的工程师提供了CenturyLink服务可用性的官方地图：
在美国，该提供商有4900万人使用，这意味着对于某些客户而言，如果我们谈论CloudFlare报告，甚至是整个数据中心，CenturyLink是唯一可用的提供商。
结果，由于CenturyLink几乎全面倒下，CloudFlare专家记录了全球Internet流量减少了3.5％。这是该公司与之合作的六个主要提供商的图表。 CenturyLink是红色的。
该故障本身是全球性的，而不仅仅是提供商本身所说的“安大略省以外的数据中心的问题”，这一事实可以通过Flowspec规则更新的规模得到证明。通常，BGP Flowspec配置更新的大小约为2 MB，但是CloudFlare专家记录的BGP配置更新最大为26 MB（！）。
这些更新每15分钟发布一次，它们与主机共享有关路由运行状况更改的信息。这使您可以灵活地应对一些本地问题。比平常大10到15倍的更新表明几乎整个提供商的网络都已关闭，或者存在极其严重的连接问题。
CloudFlare认为，失败的原因是不正确的全局BGP Flowspec规则，该规则被绝大多数路由器接收，然后又进行了反向重启以尝试恢复连接。这与持续了4个小时以上的崩溃情况相符。那时路由器的内存和CPU过载可能导致工程师失去对多个节点和控制接口的远程访问。
顺便说一句，这个故事远非独特。一年多前，由于CloudFlare本身的故障和DNS的失败，全世界的互联网“瘫痪了”，加上同一家公司诚实地提到了7年前Flowspec的类似问题，之后他们停止使用它。