这是另一起重大的BGP失误事件。
上周五，谷歌一名笨手笨脚的工程师搞错了边界网关协议（BGP）通告环节，从而将日本的互联网流量发送到了黑洞。
这次故障的起源是，素有“巧克力工厂”之称的谷歌将一张庞大的路由表“泄露”给了韦里逊（Verizon），结果是，来自像NTT和KDDI这些日本电信巨头的流量被发送到了谷歌，谷歌无意中被当成了一家转接（transit）提供商。
正如BGP Mon解释的那样，由于谷歌其实并不提供转接服务，这些流量不是塞满链路，导致链路不堪重负，就是进入访问控制列表（ACL），然后消失得无影无踪。
日本的故障事件只持续了几个小时，但是后果极其严重，以至于《日本时报》报道，日本总务省已要求相关电信公司报告发生的问题（https://www.japantimes.co.jp/news/2017/08/26/national/japanese-government-probes-internet-disruption/#.WaMuopMjGCQ）。
BGP Mon在这里仔细分析了发生的问题，声称谷歌－韦里逊路径上的135000个前缀被通告了，实际上不应该被通告。
由于谷歌将监管系统所说的“整个表”泄露给了韦里逊，这个粗心大意的错误还“让人得以了解谷歌的对等关系是什么样的，及其对等体（peer）是如何针对谷歌规划流量（traffic engineering）的。”
比如说，BGP Mon解释了这个错误如何影响日本互联网服务提供商（ISP）Jastel的：
1103 286 701 15169 45629 13335 9498 5511 701 15169 45629 202140 29075 5511 701 15169 45629 52342 20299 262206 701 15169 45629 |
“如果我们更仔细地分析一下从右边开始的相关的AS路径，我们就能看到前缀由45629（Jastel）来通告，这在意料之中。由于Jastel是谷歌（15169）的对等对象，谷歌是我们看到的下一个AS。这条路径中的下一个AS是710（韦里逊），这时情况变得有意思起来，因为韦里逊现在已开始通过谷歌为Jastel提供转接服务。”
“然后韦里逊（701）将该信息通告给了它的几个客户，其中几个客户是超大客户，比如KPN（286）和Orange（5511）。所以，只要看一下四条示例路径，我们就能看到这个问题影响了欧洲、拉美、美国和印度（9498 Airtel）的各大网络。”
BGP是互联网的协议，用来在诸网络之间分发路由信息。BGP通告实际上告知互联网的其余部分，以宣布诸如此类的信息：“如果你向我发送通往韦里逊的流量，它会抵达目的地。”
BGP是当初为更可信（而且小得多）的互联网设计的，其最严重的不足就是，得由网络管理员来检查和过滤路由通告中的信息。
正如BGP Mon特别指出，BGP泄露“是互联网的稳定性面临的一大风险”，通告两头在接受BGP通告之前应该先进行过滤。
之前的BGP事件引发过诸多乌龙事件：误将YouTube流量发送到巴基斯坦，将中国流量发送到黑洞，使白俄罗斯成为默认路由，处理它无力处理的更多流量，以及误将Level 3通信公司的流量发送到马来西亚。
相关组织已提出了多项提议以改动BGP，从而阻止这种问题发生，但是与往常一样，具体实施常常远远落后于实际需求。
