今天，谷歌的服务在互联网的某些部分经历了大约27分钟的有限中断。发生这种情况的原因是深入到人际网络的黑暗角落。我是CloudFlare的一名网络工程师，我在帮助确保Google重新上线方面发挥了很小的作用。这里有一点关于发生了什么。大约在太平洋标准时间下午6:24/02:24（太平洋标准时间2012年11月5日/2012年11月6日）左右，CloudFlare的员工发现谷歌的服务处于离线状态。我们使用谷歌应用程序来处理邮件，这样当我们无法联系到他们的服务器时，办公室会很快通知他们。我是网络工程团队的一员，所以我跳到网上去弄清楚这个问题是美国本地的还是全球的。故障排除我很快意识到我们无法解决所有的谷歌服务-甚至达到8.8.8.8，谷歌公共DNS服务器-所以我开始了DNS故障排除。$dig+跟踪谷歌当我试图联系到古戈尔的名称服务器：谷歌. NS ns2中的172800。google.com.google.com。NS ns1中的172800。google.com.google.com。NS ns3中的172800。google.com.google.com。NS ns4中的172800。谷歌.；从192.12.94.30#53（e.gtld）收到164个字节-服务器.net)152毫秒后；；连接超时；无法访问任何服务器无法访问服务器的事实意味着出了问题。具体来说，这意味着从我们的办公网络我们无法访问任何谷歌DNS服务器。我开始研究网络层，看看问题出在哪里。PING 216.239.32.10（216.239.32.10）：1-1-15.edge2-eqx中icmp_seq 092字节的56个数据字节请求超时-sin.moratelindo.co.公司.id（202.43.176.217）：超过生存时间这很奇怪。正常情况下，我们不应该看到一个印尼ISP（莫拉泰尔）在谷歌的道路上。我跳上了CloudFlare的一个路由器，查看发生了什么。与此同时，其他来自全球各地的报道显示，我们并不是唯一看到问题的人。Internet路由要想了解哪里出了问题，你需要了解一下互联网上的网络是如何工作的。因特网是网络的集合，被称为"自治系统"（as）。每个网络都有一个唯一的编号来标识它，称为数字。CloudFlare的数字是13335，谷歌的是15169。这些网络通过所谓的边界网关协议（BGP）连接在一起。BGP是因特网的粘合剂，它公布每个网络的IP地址，并建立从一个网络到另一个网络的路由。因特网的"路由"正是它听起来的样子：从一个上的IP地址到上的一个IP地址的路径另一个AS。BGP在很大程度上是一个基于信任的系统。网络相互信任，可以说出背后的IP地址和其他网络。当您通过网络发送数据包或发出请求时，您的ISP将连接到其上游提供商或对等方，并找到从ISP到目标网络的最短路径。不幸的是，如果一个网络开始发送一个特定IP地址或其背后的网络的通知，而事实上它不是，如果该网络被其上游和对等方信任，那么数据包可能会被错误路由。这就是这里发生的事。我查看了Google IP地址的BGP路由。这条路线穿过印尼的一家ISP莫拉泰尔（23947）。考虑到我正在考虑从加利福尼亚州的路由，而谷歌正在运营数据中心离我们办公室不远的地方，数据包永远不应该经过印度尼西亚。最可能的原因是莫拉泰尔宣布了一个实际上并不支持他们的网络。我当时看到的BGP路线是：tom@edge01.sfo01>显示路由216.239.34.10 inet.0:422168个目的地，422168个路由（422154活动，0保持，14个隐藏）+=活动路由，-=最后一个活动，*=Both216.239.34.0/24*[BGP/170]00:15:47，MED 18，localpref 100作为路径：4436 3491 23947 15169 I>通过ge-1/0/9.0到69.22.153.1看看其他路由，比如谷歌的公共域名系统，它也被困在同一条（不正确的）路径上：tom@edge01.sfo01>显示route 8.8.8.8 inet.0:422196目的地，422196 routes（422182 active，0 holdown，14 hidden）+=active route，-=Last active，*=Both8.8.8.0/24*[BGP/170]00:27:02，MED 18，localpref 100作为路径：4436 3491 23947 15169 I>通过ge-1/0/9.0到69.22.153.1线路泄漏

（图片来源：辛普森一家）这种情况在业内被称为"路由泄露"，因为路由已经"泄漏"过了正常路径。这不是一个史无前例的事件。谷歌此前也遭遇过类似的宕机事件，据称巴基斯坦正试图审查YouTube上的一段视频，巴基斯坦国家ISP null路由了该服务的IP地址。不幸的是，他们对外泄露了空路由。巴基斯坦电信的上游供应商电讯盈科（PCCW）信任巴基斯坦电信向他们发送的信息，以及在互联网上传播的路线。结果是YouTube被关闭了大约2个小时。今天的情况与此类似。莫拉泰尔的人很可能"指手画脚"了一条互联网路线。电讯盈科是莫拉泰尔的上游供应商，相信莫拉泰尔向他们发送的路线。而且，很快，坏的路线蔓延开来。这不太可能是恶意的，而是一种误解或错误，证明了BGP信任模型中的一些缺陷。修复解决办法是让莫拉泰尔停止宣布他们不该走的路线。作为一名网络工程师，尤其是在像CloudFlare这样的大型网络上工作，很大一部分是与世界各地的其他网络工程师建立关系。当我发现问题时，我联系了莫拉泰尔的一位同事，让他知道发生了什么事。他能够在太平洋标准时间下午2:50和下午6:50解决了这个问题。大约3分钟后，路由恢复正常，谷歌的服务重新上线。看看对等网络地图，我估计这次中断影响了大约3-5%的互联网用户。最重要的影响将是在香港，电讯盈科是现任的供应商。如果你当时在这一地区，无法访问谷歌的服务，现在你知道原因了。建设一个更好的互联网这一切都提醒我们，互联网是一个建立在信任基础上的系统。今天的事件表明，即使你和谷歌一样大，你直接控制之外的因素也会影响你的客户访问你网站的能力，所以有一个网络工程团队24小时监控路线和管理你的连接是很重要的。CloudFlare每天都在工作，以确保我们的客户获得最佳的可能路线。我们留意我们网络上的所有网站，以确保他们的流量总是以最快的速度传递。这是我们拯救网络的又一天。更新：太平洋标准时间11月6日星期二上午11:00莫拉泰尔说，这个问题是由一个意外的硬件故障引起的，导致了这种异常情况。这不是恶意企图。莫拉泰尔在与谷歌取得联系后立即关闭了BGP与谷歌的联系，当时正在调查硬件故障。谢谢你一直读到最后。如果您喜欢这篇文章，请花一点时间了解有关CloudFlare的更多信息，或者提名我们获得2012年Crunchie最佳技术奖创新。