原文地址：https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
原文标题：Why Google Went Offline Today and a Bit about How the Internet Works
原文作者：Tom Paseka
原文写于：2012/11/6 GMT+8 下午 5:09:00
译者：驱蚊器喵#ΦωΦ
翻译水平有限，有不通顺的语句，请见谅。
今天，2012年11月6日，Google 的服务在 Internet 的某些地方经历了大约27分钟的服务中断。要探究发生这种情况的原因，需要潜入到网络的深层黑暗角落。我是 Cloudflare 的网络工程师，在帮助确保 Google 恢复在线事件中发挥了很小的作用。以下是发生的事情。
在2012年11月5日下午 6:24 (太平洋标准时间) / 2012年11月6日 02:24 (世界标准时间)，Cloudflare 员工注意到 Google 的服务处于离线状态。我们使用 Google Apps 处理电子邮件之类的事情，因此当我们无法访问 Google 的服务器时，员工会迅速注意到。我在网络工程团队中工作，所以我转至线上了解，这是我们本地的问题还是全球性的问题。
排除故障
我很快意识到，我们无法解析所有 Google 的服务，甚至无法访问 Google 的公共 DNS 服务器 8.8.8.8，因此我开始对 DNS 进行故障排除。
1 | $ dig +trace google.com |
这是我尝试访问 Google.com 的域名服务器时收到的响应：
1 | google.com. 172800 IN NS |
无法访问服务器，意味着某个地方出问题了。具体来说，这意味着我们的办公网络无法访问任何 Google 的 DNS 服务器。
我开始研究网络层(network layer)，看看问题出在哪里。
1 | PING 216.239.32.10 (216.239.32.10): 56 data bytes |
这很奇怪。通常，在通往 Google 的路由上我们应该不会看到印尼 ISP（Moratel）。我登陆到 Cloudflare 的一台路由器上，查看发生了什么。同时，Twitter 上来自全球的其他推文报告表明，我们并不是唯一看到此问题的人。
互联网路由
要了解出了什么问题，您需要对 Internet 上的网络工作原理有所了解。互联网是网络的集合，被称为”自治系统(Autonomous Systems,AS)”。每个网络都有一个唯一的编号来标识它，称为 AS 编号。CloudFlare 的 AS 编号是 13335，Google 的 AS 编号是 15169。网络通过边界网关协议(Border Gateway Protocol,BGP)连接在一起。BGP 是 Internet 的胶水 - 宣告哪些 IP 地属于的每个网络，并建立从一个 AS 到另一个 AS 的路径。互联网”路由(route)”的确切含义是：从一个 AS 上的 IP 地址到另一个 AS 上的 IP 地址的路径。
BGP在很大程度上是基于信任的系统。网络之间彼此信任，并宣告各自网络背后的 IP 地址和其他网络。当你通过网络发送数据包或发出请求时，你的 ISP 将连接到它的上游提供商(upstream providers)或对等方(peers)，并找到从 ISP 到目标网络的最短路径。
不幸的是，如果一个网络开始发出一个特定 IP 地址或它背后网络的通告，而实际上 IP 地址和网络是错误的，如果该网络受到其上游供应商和对等方的信任，则数据包最终可能会路由错误。这就是现在发生的事情。
我查看了一个 Google 的 IP 地址的 BGP 路由。路由穿过了一家来自印度尼西亚的 ISP ，Moratel (23947)。鉴于我正在查看的路由是从加利福尼亚出发的，而 Google 正在运营的数据中心离我们办公室不远，因此数据包永远不可能通过印度尼西亚的路由。最有可能的原因是，Moratel 宣告了一个错误的网络。
我当时看到的 BGP 路由是这样的：
1 | [email protected]> show route 216.239.34.10 |
看看其他路由，例如到 Google 公共 DNS 的路由，也是沿着一样的（错误）路由：
1 | [email protected]> show route 8.8.8.8 |
译者注：你可以看到 Moratel 的 AS 编号 23947，在路由之中。
路由泄漏
(Image Credit: The Simpsons)
这种情况，在行业内被称为”路径泄漏(route leakage)”，因为该路由已经从正常的路径”泄漏”出去了。这不是史无前例的事件。Google 此前曾遭受过类似的服务中断，原因是巴基斯坦试图审查 YouTube 上的视频，而巴基斯坦国家 ISP 空路由了该服务的 IP 地址。不幸的是，他们从外部泄漏了空路由。巴基斯坦电信的上游提供商PCCW 信任巴基斯坦电信发送给他们的内容，错误路由传播到了 Internet。造成的结果是 YouTube 被离线关闭了大约 2 个小时。
今天的情况是类似的。Moratel的某个人可能”意外敲错(fat fingered)”了互联网的路由。曾是 Moratel 上游提供商的 PCCW 信任 Moratel 向他们发送的路由。错误的路由很快蔓延开来。但，这不太可能是恶意的，而是错误的配置，或是表明 BGP 信任模型中某些故障。
修复方案
解决方案是让 Moratel 停止宣告他们不应该使用的路由。网络工程师的很大一部分，尤其是在像 CloudFlare 这样的大型网络上工作的人，与全球其他网络工程师建立着联系。当我找出问题所在时，我联系了 Moratel 的一位同事，让他知道发生了什么事。他在 2:50 UTC / 6:50pm PST 时解决了这个问题。大约 3 分钟后，路由恢复正常，Google 的服务恢复在线。
从对等地图(peering maps)来看，我估计中断影响了互联网中 3-5％ 的流量。影响最大的将是香港，因为 PCCW 是香港目前的服务提供商。如果那时你在香港，并且无法访问 Google 的服务，那么你现在知道为什么了。
建立更好的互联网
这一切都在提醒人们，互联网是如何建立在信任基础之上的。今天的事件表明，即使您像 Google 一样强大，在你直接控制之外的因素也会影响客户访问您网站的能力，因此拥有一支网络工程团队来全天候的监视路由和管理您的连接是非常重要。Cloudflare 每天的工作，是确保我们的客户获得最佳的路线。我们关注我们网络上的所有网站，确保他们的流量总是尽可能快的送达。这是我们不断努力#savetheweb(拯救网络)的又一天。
更新：11月6日，星期二，太平洋标准时间上午 11:00
Moratel 说，此问题是由意外的硬件故障引起的，故障导致这样的异常情况。这不是恶意的行为。Moratel 在接到联系后，调查了硬件故障，并立即关闭了与 Google 的 BGP 对等连接。