详解谷歌BGP路由泄漏导致日本互联网中断

2017年8月25日星期五的03:22 UTC，全球互联网经历了一次严重的BGP路由泄漏事故。这次BGP路由泄漏事故是由于谷歌向Verizon泄漏超过16万条路由前缀，而Verizon接受了这些路由并将其传递给部分互联网转接（IP Transit）客户网络。尽管此次BGP路由泄漏事故发生在美国伊利诺伊州芝加哥市的谷歌数据中心，但其后果却漂洋过海，导致日本互联网中断。

日本两大主要电信运营商（KDDI和NTT）受到严重影响，分别向发布故障通知公告（如下图）。

大规模路由泄漏事件时有发生

近年来，大规模（10万条以上路由前缀的）BGP路由泄漏事件通常为以下两种情况，1）路由泄漏网络将全局路由表宣布为其全部网络路由的源路由（如Indosat 2014年引起的路由泄漏），或者2）路由泄漏网络从互联网转接（IP Transit）服务提供商和/或对等互联网络（IP Peering）学习到的全球路由表，错误地发布给另一个互联网转接（IP Transit）服务提供商（如马来西亚电信 2015年引起的路由泄漏）。

但这次由谷歌引起的路由泄漏事故是种新情况。这次大规模路由泄漏所涉及的绝大部分路由当时不在全球路由表中，而是一些细分路由条目。这是不同于以前的路由泄漏的重要区别。在BGP协议中，细分路由越具体，包含的IP地址数越少，并且在BGP路由选择过程中，细分路由所定义的路径会被优先选择。

谷歌采用这种细分路由方式进行网络流量管理。当谷歌向外界宣布这些细分路由时，它们被外部网络选定并替代原有路由，以引导其流量，从而对流量重定向产生了巨大的影响。 

为什么日本会遭受如此严重的影响呢？

谷歌此次泄漏的16万条路由中，超过25,000条路由是属于NTT的路由地址段，在受影响的全部网络，涉及NTT的路由数最多。实际上，本次路由泄漏并不涉及KDDI的路由地址段。 但KDDI为何会遭此灾难呢？因为KDDI是Verizon的互联网转接（IP Transit）客户，也就是说，KDDI买了Verizon的互联网转接（IP Transit）服务。KDDI从Verizon接受了超过95,000条泄漏的路由前缀。日本另一个电信运营商IIJ也从Verizon接受了超过97,000条泄漏的路由前缀。因此，从KDDI或IIJ到NTT 的任何互联网流量，都被先传送到谷歌在芝加哥的数据中心。NTT、KDDI、Softbank BB和IIJ是日本前四大互联网骨干网络，他们之间互联互通流量巨大。这次BGP路由事故导致其中三大日本运营商之间的国内流量国际化，漂洋过海跨越太平洋，经过日美之间众多国际海缆系统，流向谷歌的美国芝加哥数据中心。这种情况下，纵使日美之间国际海缆带宽原本很充足，也承载不了本来应该在日本国内的互联网洪荒之流，导致日美互联网高速公路严重堵塞，互联网流量通达时间过长，从而出现灾难性互联网数据丢包，导致日本互联网中断。

路由跟踪分析

全球知名的互联网智能服务咨询公司DYN对本次由谷歌引起的BGP路由泄漏事故进行了监测和分析。Dyn每天都对全球互联网进行数亿次的路由跟踪监测。每当发生这样的重大路由事件时，Dyn可以通过观察这些路由跟踪的变化来发现问题。 

Dyn 互联网分析总监Doug Madory在其博客中对此次谷歌引起的BGP路由泄漏进行了详细的路由跟踪分析。

下图显示了Dyn监测到的在泄漏时间内进入谷歌网络的跟踪路由数量。下图中心的尖峰显示从Verizon流向谷歌的流量突然暴涨。在短时间内，总共有大约10,000条跟踪路由被吸入谷歌网络，再通往全球互联网各地的目的地。

以下是在此次BGP路由泄漏事故前一天，从设在日本Equinix数据中心的服务器到日本NTT 网络中的一个IP地址的路由跟踪情况。如预期的那样，该路由正常地经过日本境内的互联网节点，在15ms内到达目的地。

下图是在此次BGP路由泄漏期间监测到的相同的路由跟踪。 该路由先到达IIJ网络节点，然后IIJ通过跨太平洋海缆将流量传送给其互联网转接（IP Transit）服务提供商VerizonA（Alter.net）设在美国圣何塞的网络节点，Verizon（Alter.net）再传送到谷歌芝加哥数据中心。最后，谷歌通过其内部网络将此路由跟踪流量传回到日本。与正常的15毫秒可通达目的地相比，此次BGP路由泄漏事故导致往返时延达到256毫秒，是正常值的17倍，时延出现显著的劣化。

中国互联网遭受这次谷歌引起的BGP路由泄漏事故的影响。根据Dyn对中国上海到澳门的路由跟踪结果，该路由先经中国联通网络，传送到中国联通洛杉矶POP，接着进入中国联通的互联网转接（IP Transit）服务提供商Verizon洛杉矶节点和芝加哥节点，然后进入谷歌芝加哥数据中心，再进过谷歌跨太平洋内网从芝加哥传回香港，最后到达终端目的地澳门电信IP地址。从中国上海到澳门的流量也通过美国绕转。

在跨大西洋区域，Dyn同样监测到路由绕转。下图显示一个从伦敦互联网交换中心（LINX）到德国的路由跟踪情况，先从LINX进入Verizon伦敦节点，经Verizon内网跨大西洋到达纽约和芝加哥，然后进入谷歌芝加哥节点，通过谷歌内网从美国芝加哥再跨大西洋进入谷歌德国节点，最后到达目的地Vodafone的德国节点。该欧洲内部路由也被跨大西洋绕转。

结论

据报道，谷歌在第二天对星期五在日本造成互联网连接中断表示道歉。 Verizon对此次BGP路由泄漏也负有一定的责任。正常情况下，在任何一天，谷歌向Verizon发送的路由前缀少于50条。此次BGP路由泄漏，谷歌向Verizon发送的路由前缀瞬间暴涨至超过16万条，相当于增加了4亿个IPv4地址，按理应该在Verizon路由器上达到预设的最大路由条目值(MAXPREF)，并至少触发自动响应。但不知为何在Verizon网络上未能实现该告警机制。幸运的是，Verizon没有向任何大的Tier 1对等互联网络发送泄漏的路由，如Level3，TeliaSonera，或NTT（特别是AS2914）等。否则，此次由谷歌引发的BGP路由泄漏事故的后果将更严重。

启示 

此次由谷歌引发的BGP路由泄漏事故，说明几个问题：

1. 骨干互联网上一个看似简单的错误或疏忽（工程师敲下的一个简单命令），有可能产生蝴蝶效应，导致严重后果。这也是一些保守的运营商管理者谨小慎微的原因之一吧。
2. 任何公司，哪怕像谷歌这样神一般存在的公司，也会患技术错误或疏忽。互联网维护管理压力大，但不可因此裹足不前。
3. 谷歌骨干网确实庞大得可怕，前面几个路由绕转的例子中，不论是跨太平洋，还是跨大西洋，只要到了谷歌网络上，就不会再出去了，都是经过谷歌内网到达最远端目的地。
4. 此次事故产生了典型的蝴蝶效应和虹吸现象。谷歌在芝加哥互联网数据中心的一只小蝴蝶展翅，其后果却漂洋过海，引起滔天巨浪，严重冲击了太平洋彼岸的日本互联网。同时，谷歌也练就了吸星大法，把全球互联网流量瞬间吸引到其芝加哥数据中心。

注：本文由作者裘文荣（Winston Qiu）根据Dyn互联网分析总监Doug Madory的博客文章和数据编译整理，版权所有