边界网关协议(BGP)的故障分析

bgp协议的几种状态BGP（Border Gateway Protocol，边界网关协议）是一种用于在互联网中交换路由信息的协议。

BGP协议定义了多种状态，用于描述与邻居路由器之间的连接和路由信息的交换状态。

以下是BGP协议的几种状态：1. Idle（空闲状态），在该状态下，BGP路由器尚未建立与邻居路由器的TCP连接。

这可能是因为配置错误、网络故障或邻居路由器尚未配置的原因。

2. Connect（连接状态），在该状态下，BGP路由器正在尝试与邻居路由器建立TCP连接。

如果连接成功，将进入下一个状态；如果连接失败，将返回到Idle状态。

3. Active（活动状态），在该状态下，BGP路由器正在尝试与邻居路由器建立TCP连接，但是尝试失败。

这可能是因为网络故障、配置错误或邻居路由器不可达。

4. OpenSent（已发送打开消息状态），在该状态下，BGP路由器已经成功建立了TCP连接，并向邻居路由器发送了打开消息。

BGP路由器等待邻居路由器的确认。

5. OpenConfirm（确认打开消息状态），在该状态下，BGP路由器已经收到了邻居路由器的确认消息，并等待邻居路由器发送Keepalive消息。

6. Established（已建立状态），在该状态下，BGP路由器与邻居路由器之间的连接已经成功建立，并且可以开始交换路由信息。

BGP路由器将持续发送Keepalive消息以保持连接。

这些状态描述了BGP路由器与邻居路由器之间的连接和路由信息交换的不同阶段。

通过检查这些状态，网络管理员可以了解BGP路由器的连接状态，并进行故障排除和网络维护。

BGP协议故障处理-1 1. 邻居关系不能建立故障现象描述TCP连接没有建立，OPEN报文没有正常交互。

故障可能原因AS号不正确对等体的IP地址不正确环回接口配置错误EBGP没有配置peer ebgp-max-hopTCP连接不正常路由不可达TCP端口179被禁用故障处理流程故障处理步骤1) 检查AS号是否配置正确检查AS号是否正确，使用display current-configuration命令检查本端的AS号配置，在对端使用display bgp peer检查其邻居的AS号是否与本端一致；2) 检查对等体IP是否正确检查对等体的IP地址是否正确；3) 检查环回接口是否配置正确如果使用环回接口，检查是否配置了connect-interface loopback。

缺省情况下，路由器使用最佳路由建立TCP连接，而不是loopback接口；4) 检查EBGP配置peer ebgp-max-hop没有如果是EBGP邻居，且EBGP连接在物理上不是直连的，检查是否配置了peerebgp-max-hop。

默认情况下，EBGP邻居的TTL被置为1，如果不是直连，必须配置peer ebgp-max-hop；5) 检查TCP连接正常否使用扩展的ping命令检查TCP连接是否正常，由于一台路由器可能有多个接口能够到达对端，应使用ping -a ip-address命令指定发送ping包的源IP地址；6) 检查路由是否可达如果Ping不通，使用display ip routing-table命令检查路由表中是否存在到邻居的可用路由；7) 检查179端口是否被禁用如果能Ping通，检查是否配置了禁止TCP端口179的ACL，如果有，取消对179端口的禁止。

2. 邻居关系DOWN掉故障故障现象描述除对端发生重启的情况外，已经建立好的邻居又Down掉一般是由于链路层的问题导致的。

故障可能原因对端设备发生重启MTU问题QoS问题网络拥塞问题故障处理流程图2邻居关系DOWN掉故障处理流程故障处理步骤1) 检查对端BGP是否重启过，一些可能导致BGP重启的事件：对端关闭会话。

BGP协议故障处理-41. 配置BGP反射，不同的群具有相同的cluster-id导致路由丢失故障现象描述在下面的BGP组网应用中，RTA和RTC组成一个群（cluster），RTA作为反射器；RTB和RTD组成一个群，RTB作为反射器。

在RTD上发布一条路由189.1.0.0/16，RTB学习到了这条路由，按照反射器的特性，应该把这条路由反射给非客户机RTA。

但是在RTA上观察发现并没有这条路由。

图1不同的群具有相同的cluster-id导致路由丢失RTA的BGP配置如下：bgp 100reflector cluster-id 2332098817default med 1000undo synchronizationgroup g1 externalgroup g2 internalgroup g3 internalpeer 133.1.1.2 group g1 as-number 200peer g1 ebgp-max-hoppeer 150.1.1.2 group g2peer 200.1.7.2 group g3peer g3 reflect-clientRTB的BGP配置如下：bgp 100undo synchronizationgroup g1 internalgroup g2 internalpeer 150.1.1.1 group g1peer 12.110.250.1 group g1peer g1 reflect-clientdisplay信息或者debugging信息：打开debugging开关，在RTB上可以看到RTB已经向RTA发送了update报文：*0.29444933-RM-7-RTDBG:BGP SEND 150.1.1.2+1025 -> 150.1.1.1+179*0.29444999-RM-7-RTDBG:BGP SEND message type 2 (Update) length 61*0.29445066-RM-7-RTDBG:BGP SEND flags 0x40 code Origin(1): IGP*0.29445133-RM-7-RTDBG:BGP SEND flags 0x40 code ASPath(2): <null>*0.29445199-RM-7-RTDBG:BGP SEND flags 0x40 code NextHop(3): 12.110.250.1*0.29445283-RM-7-RTDBG:BGP SEND flags 0x40 code LocalPref(5): 1000*0.29445349-RM-7-RTDBG:BGP SEND flags 0x80 code Originator_ID(9):12.110.250.1*0.29445449-RM-7-RTDBG:BGP SEND flags 0x80 code Cluster_List(10):139.1.1.1*0.29445533-RM-7-RTDBG:BGP SEND 189.1.0.0/16在RTA上也可以看到RTA收到了RTB发过来的update报文：*0.29444687-RM-7-RTDBG:BGP RECV 150.1.1.2+1025 -> 150.1.1.1+179*0.29444754-RM-7-RTDBG:BGP RECV message type 2 (Update) length 61*0.29444820-RM-7-RTDBG:BGP RECV flags 0x40 code Origin(1): IGP*0.29444887-RM-7-RTDBG:BGP RECV flags 0x40 code ASPath(2): <null>*0.29444954-RM-7-RTDBG:BGP RECV flags 0x40 code NextHop(3): 12.110.250.1*0.29445037-RM-7-RTDBG:BGP RECV flags 0x40 code LocalPref(5): 1000*0.29445104-RM-7-RTDBG:BGP RECV flags 0x80 code Originator_ID(9):12.110.250.1*0.29445204-RM-7-RTDBG:BGP RECV flags 0x80 code Cluster_List(10):139.1.1.1*0.29445287-RM-7-RTDBG:BGP RECV 189.1.0.0/16但是在RTA上发现路由189.1.0.0/16并没有添加到BGP路由表：进一步打开bgp的event调试开关，可发现如下信息：*0.374978900 RM/7/RTDBG:bgp: peer 150.1.1.2 (Internal AS 100) unicastroutes DENIED due to: cluster id loop found故障原因分析在RTB发给RTA的update报文中，可以看到一个originator-id属性和一个cluster-list属性。

BGP协议故障处理-21. 路由发起过程的路由丢失故障故障现象描述路由发起过程的路由丢失，是指在将运行OSPF接口的路由发布出去的时候，因发布命令配置不当而引起的路由丢失。

故障可能原因¾使用network命令发布路由不当导致¾使用network mask命令发布路由不当导致¾使用aggregate-address命令发布聚合路由不当导致故障处理流程图1路由发起过程的路由丢失故障处理流程故障处理步骤1) 检查是否因使用network命令发布路由不当导致使用networ k命令发布路由时，如果不指定发布网络的掩码，则BGP认为发布的是自然网段的路由，使用display ip routing-table检查路由表中是否存在该自然网段的路由。

在AR系列路由器中，BGP缺省不进行子网路由的自动聚合。

所以，如果仅有子网路由，是不能被正确发布的。

network命令发布路由时进行精确匹配才能将子网路由发布出去。

2) 检查是否因使用network mask命令发布路由不当导致使用network mask命令可以发布带子网掩码的路由，必须存在精确匹配的路由才能被正确地发布出去，使用display ip routing-table检查路由表中是否存在网络地址和掩码都精确匹配的路由。

3) 检查是否因使用aggregate-address命令发布聚合路由不当导致使用aggregate命令可以对本地路由进行任意子网掩码长度的聚合，待聚合的路由需要存在于BGP路由表中，使用display bgp routing-table确认BGP路由表是否存在这些路由。

如果使用aggregate detail-suppressed命令进行聚合，则只有聚合后的路由被发布出去，而具体路由都将被抑制。

aggregate对BGP路由表中的路由进行聚合，使用参数detail-suppressed将导致具体路由被抑制发布。

BGP协议故障处理-51. 使用network命令发布路由的精确匹配问题故障现象描述在下面的BGP组网应用中，RTA和RTB属于同一个AS，它们之间运行IGP（如OSPF）；RTA和RTC属于不同的AS，它们之间运行BGP，建立EBGP邻居关系。

在RTB上通过OSPF协议发布三条路由172.16.1.0/24、172.16.2.0/24、172.16.3.0/24，RTA学习到了这三条路由，并通过network 172.16.0.0命令发布出去。

但是在EBGP邻居RTC上并没有学习到这三条路由，RTA和RTC之间的邻居关系稳定，没有出现异常。

图1使用network命令发布路由的精确匹配问题RTA的BGP配置：bgp 100default med 1000network 172.16.0.0undo synchronizationgroup g1 externalgroup g2 internalgroup g3 internalpeer 133.1.1.2 group g1 as-number 200peer g1 ebgp-max-hoppeer 150.1.1.2 group g2peer 200.1.7.2 group g3peer g3 reflect-clientdisplay信息或者debugging信息：在RTA上用display ip routing-table查看本地路由表：[RTA]display ip routing-tableRouting Tables: public netDestination/Mask Protocol Pre Cost Nexthop Interface172.16.1.0/24 OSPF 10 1563 150.1.1.2 Serial1/0172.16.2.0/24 OSPF 10 1563 150.1.1.2 Serial1/0172.16.3.0/24 OSPF 10 1563 150.1.1.2 Serial1/0 可以看到三条OSPF路由已经装入本地路由表中。

1 BGP策略错误导致路由持续震荡场景分析1.1 BGP策略错误导致路由持续震荡概述1.2 典型组网1.3 BGP路由震荡产生原理1.4 BGP路由持续震荡的错误配置示例1.5 防止路由震荡的建议配置示例1.6 适用产品和版本1.7 总结与建议1.1 BGP策略错误导致路由持续震荡概述动态路由协议BGP在现网广泛应用，现网会根据自己的业务特点进行组网部署，但可能因为配置不合理造成BGP路由持续震荡，导致业务受损。

但无论什么配置，路由持续震荡的根因是原始引入路由的设备又从BGP邻居收到了相同前缀的路由，且优先级高于本地引入的路由。

1.2 典型组网如图1-1所示，DeviceA、DeviceC处于AS 100，DeviceB处于AS 200。

由于在DeviceB上配置AS替换功能，且DeviceC上使用入口策略提升来自DeviceB的路由的本地优先级属性后再发布给DeviceA，使DeviceA从DeviceC收到的路由优先级高于本地引入路由，导致BGP路由持续震荡形成环路。

图1-1 BGP路由持续震荡典型组网说明本例中interface1，interface2分别代表GE0/1/0，GE0/2/0。

1.3 BGP路由震荡产生原理1.3.1 数据准备为完成上述组网场景配置，需准备如下数据：1.3.2 BGP路由震荡原理详细介绍各设备详细配置数据参见1.3.1 数据准备和1.4.1 BGP策略错误导致路由持续震荡错误示例。

如图1-1所示，以DeviceA发布的路由192.168.6.6/32为例，形成BGP路由持续震荡的过程可分为如下阶段：阶段一：DeviceA上在BGP视图下通过配置import-route static命令引入静态路由192.168.6.6/32，通过EBGP邻居发布给DeviceB，又通过IBGP邻居发布给DeviceC。

阶段二：DeviceB对与DeviceC建立的EBGP邻居配置peer substitute-as命令，使能AS号替换功能，因此DeviceB给DeviceC发布路由AS_Path属性的AS号为200。

Trouble Shooting 协议故障可以从R1的路由信息，的“State/PfxRcd”列的确实“Idle”试向外部由信息了。

对应的，R1也可以收到相同的BGP路由信息。

可以看出，该故障是由于链路异常造成的，导致邻居关系无法正常建立。

由BGP邻居配置参数错误引发的故障如果R1无法接收来自AS103的路由信息，而且检测和R2的邻居关系处于正常状态，但是在进入R2管理界返回信息中和R3对应的“State/PfxRcd”列显示的是“active”信息，说明在R2和R3之间可以互相发送Hello 包，但是其中的参数没有匹配和对应。

造成无法协商的情况，即使用Hello包中的参数无法继续协商建立邻居关系。

然后执行“ping 172.16.23.3”命令，和R3可以正常通讯。

在R2路由器上执行“show running-configTrouble Shooting上执行以下命令，172.16.23.2 这样就解决了上述故障。

bgp”命令，都没有发现收到172.16.3.0/32网段的信息。

因为R3的172.16.0.3/24是自身的直连网段，在R3上执行“show ip route”命令，显示“172.16.3.0/24 isdirectly connectd”内容，就说明了上述分析的正确性。

该网段应该被注入到R3的BGP数据库，注入的方法有多种，包括通过network指令将其匹配到BGP数据库中，或者将直连网段重分发到BGP数据库中等。

255.255.255.0”信息却与实际情况不符。

是在注入现的错误，入到BGP的IGP协使用重分发指令实现注入。

在默认情况下，中的所有路由都会被重分发。

BGP协议故障处理-81. 直连EBGP邻居发布下一跳非直接可达路由时，路由无效故障现象描述在下面的BGP组网应用中，Router1和Router2之间建立IBGP邻居关系，Router1和Router3之间建立EBGP邻居关系。

Router3发布路由6.6.0.0/16给Router1，Router1把从EBGP邻居学来的路由发布给IBGP邻居Router2，但在Router2上display bgp routing-table发现学到的路由为无效路由。

图1路由发布Router1的配置：interface Ethernet0/0ip address 12.110.150.1 255.255.0.0!interface Serial0/0link-protocol pppip address 150.1.1.1 255.255.0.0!bgp 100undo synchronizationgroup g1 internalgroup g2 externalpeer 150.1.1.2 group g1peer 12.110.250.1 group g2 as-number 200Router2的配置：interface Serial0/0lingk-protocol pppip address 201.1.1.1 255.255.0.0!bgp 100undo synchronizationgroup g1 internalpeer 150.1.1.1 group g1Router3的配置：interface Ethernet0/0ip address 12.110.250.1 255.255.0.0!bgp 200undo synchronizationgroup g1 externalpeer 12.110.150.1 group g1 as-number 100display信息和debugging信息显示：[Router2] display bgp routing-tableFlags: # - valid ^ - active I - internalD - damped H - history S - aggregate suppressedDest/Mask Next-Hop Med Local-pref Origin PathI 6.6.0.0/16 12.110.250.1 0 100 IGP 200在Router2上display ip routing-table：[Router2]display ip routing-tableRouting Table: public netDestination/Mask Protocol Pre Cost Nexthop Interface127.0.0.0/8 DIRECT 0 0 127.0.0.1 InLoopBack0127.0.0.1/32 DIRECT 0 0 127.0.0.1 InLoopBack0150.1.0.0/16 DIRECT 0 0 150.1.1.2 Serial0/0150.1.1.1/32 DIRECT 0 0 150.1.1.1 Serial0/0150.1.1.2/32 DIRECT 0 0 127.0.0.1 InLoopBack0 可以看到没有到达12.110/16网段的路由。

BGP路由协议故障排除排除 1.故障排除BGP邻居关系问题遵循：首先，应检查第1/2层，然后是IP连通性（第3层），TCP连接（第4层），最后是BGP配置。

（1）直接的外部BGP邻居没有初始化自治系统（AS）不会向AS发送或从AS接收任何IP前缀更新，除非邻居关系达到established 状态，该状态是BGP邻居建立的最后阶段。

当AS有一条单一的EBGP连接时，直到BGP完成了它的收发IP前缀操作后IP连通性才能发生。

原因：。

第2层宕掉了，阻止了与直接的EBGP邻居通信。

在BGP配置中有错误的邻居IP地址命令：show ip bgp summary和show ip bgp neighbors检查BGP邻居关系active状态表示邻居间没有发生成功的通信，并且邻居未形成。

用PING测试其连通性，失败则表示要修复第1/2层问题。

debug ip bgp能够帮助诊断问题（2）非直接的外部BGP邻居没有初始化有些情况下，EBGP邻居不是直连的。

BGP邻居关系能够建立在试图形成由一台或多台路由器分隔开的EBGP邻居关系的路由器之间。

这种邻居在IOS中被称为EBGP多跳。

当路由器之间存在多个接口并且需要在那些接口之间IP流量负载均衡时，通常在回环接口之间建立EBGP对等实体。

可能的原因：n 到非直连对等实体地址的路由从路由选择表中丢失了n BGP配置中缺少ebgp-multihop命令n 缺少update-source interface命令命令：show ip bgp summary 和show bgp neighborsrouter bgp 109neighbor x.x.x.x remote-as 110neighbor x.x.x.x ebgp-multihop 2neighbor x.x.x.x update-source loopback0（3）内部BGP邻居没有初始化原因：。

到非直接IBGP邻居的路由丢失了。

BGP网络中监控与故障恢复研究的开题报告一、研究背景BGP（Border Gateway Protocol）是用于交换路由信息的协议，它在Internet中扮演着至关重要的角色。

BGP协议将网络中的路由器连接起来，使得每个路由器都能够了解其它路由器的信息，从而找到最佳的路径将数据包从源节点传递到目的节点。

然而，在BGP网络中，监控和故障恢复对网络的稳定性和可靠性至关重要。

当前，监控和故障恢复的方法主要包括定期轮询路由器状态、监控网络性能指标和采用预测技术等方式，但是这些方法都有一些固有的局限性，例如某些情况下无法及时发现故障、无法预测未来可能出现的故障等。

因此，如何针对BGP网络中的监控和故障恢复问题进行深入研究，具有重要的理论和实践价值。

二、研究目的本研究旨在探讨在BGP网络中监控和故障恢复的方法和技术，以提高网络的可靠性和稳定性。

具体目标如下：1. 分析当前BGP网络监控和故障恢复的方法和技术的优缺点，提出改进方案。

2. 研究BGP网络中故障的影响范围和根本原因，提出有效的故障恢复策略。

3. 研究BGP网络中的节点选择算法，提高网络的负载均衡和性能。

4. 实现BGP网络监控和故障恢复的原型系统，并进行测试，验证其可行性和有效性。

三、研究内容本研究主要包括以下内容：1. BGP网络监控和故障恢复的现状及挑战。

2. BGP网络故障的分类、定位和恢复策略等相关技术。

3. BGP网络节点选择算法的设计和优化。

4. 基于实时数据的BGP网络状态监控和对应的故障恢复算法的研究。

5. 原型系统的设计和实现，验证其可行性和有效性。

四、研究意义本研究的意义在于：1. 提高BGP网络的可靠性和稳定性，保障互联网的正常运行。

2. 提出有效的监控和故障恢复策略，减少故障给互联网带来的影响。

3. 增加对BGP网络节点选择算法的研究，提高网络的负载均衡和性能。

4. 建立原型系统，改进和完善现有的BGP网络监控和故障恢复方法。

BGP协议原理以及工作分析BGP（Border Gateway Protocol，边界网关协议）是互联网中常用的路由协议之一、它负责在不同自治系统（AS）之间进行互连，使得不同AS之间可以互相交换路由信息，从而实现互联网整体的路由控制和转发。

本文将从BGP协议的原理和工作过程两个方面进行分析。

BGP协议的原理主要基于路径矢量路由算法。

它通过自动发现最佳路径、动态交换路由信息和逐跳的可达性确认等机制来实现路由表的建立和更新。

BGP协议中的路由信息以路由对象（route object）的形式进行传递和维护，其中包括目标IP前缀、下一跳IP地址以及AS路径等信息。

BGP协议采用了基于TCP的可靠传输机制，确保路由信息的可靠性和一致性。

在路由表建立过程中，BGP路由器通过与相邻路由器建立TCP连接，并发送Open消息进行协商和参数交换。

协商成功后，路由器之间将建立BGP会话，并进行Keepalive消息交换以保持连接。

建立会话后，路由器将发送Update消息，携带自己的路由信息，同时接收和处理来自其他路由器的Update消息。

通过这种方式，路由器之间的路由表逐渐建立和完善。

在路由表更新过程中，BGP路由器会周期性地向相邻路由器发送Keepalive消息以保持连接，并发送Update消息进行路由信息的更新。

Update消息中包含了新增、修改和撤销的路由信息。

当收到Update消息后，路由器会根据AS路径等属性对路由信息进行选择和处理，并更新自己的路由表。

BGP支持多种策略来决定最佳路径，如AS路径长度、自治系统的经济性或性能等。

在路径选择过程中，BGP路由器根据路由策略选择最佳路径，并将其加入到本地的路由表中。

最佳路径根据路由策略的具体配置而定，可以使用过滤、路由重分发、路由聚合等方式来实现。

BGP路由器还可以使用路由策略来控制路由信息的传递和转发，实现安全性和可靠性的要求。

总结起来，BGP协议通过路由表建立、路由表更新和路径选择等过程，实现了自治系统之间的路由信息交换和控制。

1 BGP故障处理综述作为外部网关路由协议（EGP，Exterior Gateway Protocol），BGP主要关注于控制路由在自治系统间的传播，通过设置丰富的路径属性，BGP能够实现自治系统级的路由管理。

BGP-4支持无类别域间路由（CIDR，Classless Intradomain Routing），能够进行更灵活的路由聚合（aggregate）。

为提高连接的可靠性，BGP使用TCP作为传输层协议，并依赖于TCP的可靠性机制进行诸如对报文的确认、重传、排序等操作。

1.1 BGP协议知识简介1. BGP使用的报文在建立BGP对等连接之前，两个BGP邻居必须完成TCP三次握手，并在179端口上建立TCP连接，保证可靠连接的分片、重传、确认等都由TCP完成，BGP本身不提供这些处理。

BGP使用四种报文类型：BGP使用四种报文类型：z Openz Updatez Keepalivez Notification下面对这四种报文分别进行简要介绍。

Open报文TCP会话建立后，双方邻居开始发送Open报文，协商BGP运行的参数。

Open报文中包含以下信息：¾Version报文发送者的BGP版本，缺省为4。

¾My Autonomous System报文发送者的自治系统号，AS号是使用bgp as-number命令配置的，如果双方的AS号不一致，则它们是EBGP邻居，如果一致，则它们是IBGP邻居。

¾Hold Time保持计时器，如果在该计时器超时之前没有收到keepalive报文或Update报文，则认为BGP邻居已经Down掉。

双方邻居协商取该值较小者作为保持计时器值，使用timer 命令或peer x.x.x.x /group timer命令配置，后者优先级更高。

配置HoldTime的值时，如果不为0，则至少为3秒。

¾ BGP Identifier发送者的BGP Identifier，使用与OSPF选择Router ID同样的原则选择BGPIdentifier¾ Optional Parameters可选参数，包括验证码等，VRP目前版本不支持验证。

全球F、E根服务器瘫痪、BGP路由出故障：全是Cloudflare发布的软件中的bug惹...一番调查让人们对关于私有vs公共Web管理提出了严峻问题。

据互联网系统联盟（ISC）本周发布的一份报告显示，Cloudflare 发布的软件存在一处bug，结果导致互联网基础设施的核心部分出现故障。

ISC运行所谓的F根（F root）服务器，这是全球的13台根DNS 服务器之一，它们被标记为A到M。

这些服务器是支撑全球互联网的中央计算机：比如说，它们确保你在访问时，被定向到为我们的主页提供服务的正确系统。

今年1月23日，ISC接到了反映.net域出故障的报告。

它在调查后发现缺失了关键的A记录和AAAA记录，而这些记录负责将.net域名与IPv4和IPv6网络地址绑定起来。

实际上，所有以.net结尾的互联网地址从ISC的F根服务器统统消失了，.net是互联网上数量最多的注册域名之一，共有1340万个域名。

最终依靠F根服务器连接到众多网站和服务的任何浏览器、应用程序、计算机或设备都将无法通过其.net地址访问那些系统，这是最糟糕的情况。

这个问题也不仅仅局限于ISC的F根服务器。

报告声称，美国宇航局（NASA）运营的E根服务器也遇到了类似的问题。

错误修正版从响应时间表来看，ISC在5分钟内迅速搞清楚了情况：问题出在它与Cloudflare合作运营的互联网节点上，于是将该问题上报给了这家互联网基础设施公司。

Cloudflare也很快采取了行动，它在21分钟内就查明了罪魁祸首是发布的特定代码，该代码旨在修复四小时前带入的一个bug。

不过报告话锋一转，提到了脆弱不堪的边界网关协议（BGP）：互联网错综复杂的庞大网络使用BGP，自动组织管理对方，并保持彼此之间的连接。

不管怎样，花了近两个小时的时间才撤回了导致该问题的BGP通告（BGP announcement），ISC特别指出这项工作本应该更快地完成。

该报告在“汲取的经验教训”部分写道：“回想起来，一旦发现在提供不完整/不正确的数据，我们本应该立即从BGP撤回路由前缀。