從Google宕機事件認識互連網工作原理

標籤：

     原文轉自：http://kb.cnblogs.com/page/166210/

　　英文原文：Why Google Went Offline Today and a Bit about How the Internet Works

　　譯者註：本文中提到 CloudFlare 是一家總部位於美國舊金山的內容分髮網絡(CDN)服務公司，由 Project Honey Pot 項目的三位前開發人員成立於 2009 年。2011 年 10 月被華爾街日報評為最具創新精神的網路科技公司。

　　今天，Google的服務經曆了短暫的宕機事件，持續大概 27 分鐘，對部分地區的互連網使用者造成了影響。此次事件的原因深究起來需要進入互連網絡那深邃的、黑暗的角落。我是 CloudFlare 公司的一名網路工程師，在協助Google從此次宕機中恢複回來提供了一臂之力。下面就是事情發生的過程。

　　大約在太平洋標準時間 2012 年 11 月 5 號下午 6:24 分/時間標準時間 2012 年 11 月 6 號淩晨 2:24 分，CloudFlare 的員工發現Google的服務中斷了。我們使用Google的電子郵件等服務，所以，當它的服務不正常時，辦公室的人會很快發現。我在網路技術小組工作，因此我立刻接上網路查看是什麼情況——是局部地區問題還是全球問題。

　　問題排查

　　我很快就意識到，所有Google的服務我們都不能串連上——甚至包括串連 8.8.8.8，Google的公用 DNS 伺服器——於是，我從追查 DNS 開始。

$ dig +trace google.com

　　下面是我在探測 Google.com 的網域名稱伺服器時得到的回複：

　　google.com. 172800 IN NS ns2.google.com.

　　google.com. 172800 IN NS ns1.google.com.

　　google.com. 172800 IN NS ns3.google.com.

　　google.com. 172800 IN NS ns4.google.com.

　　;; Received 164 bytes from 192.12.94.30#53(e.gtld-servers.net) in 152 ms

　　;; connection timed out; no servers could be reached

　　無法探測到任何伺服器的結果證明確實有什麼地方出了問題。尤其是，這意味著從我們的辦公室將串連不到任何的Google DNS 伺服器。

　　我開始網路層尋找問題，看看是否是在這個通訊層出了問題。

　　PING 216.239.32.10 (216.239.32.10): 56 data bytes

　　Request timeout for icmp_seq 0

　　92 bytes from 1-1-15.edge2-eqx-sin.moratelindo.co.id (202.43.176.217)

　　這裡出現了奇怪的資訊。通常，我們不應該在Google的路由資訊中看到一個印尼的網路服務供應商(Moratel)的名字。我立即進入一個 CloudFlare 的路由器中查看發生了什麼事。與此同時，Twitter 上世界其它地方的報告顯示了我們並不是唯一遇到問題的地方。

　　互連網路由

　　為了理解是出了什麼問題，你需要知道一些互連網是如何工作的基礎知識。整個互連網是由很多的網路組成，這些網路被稱為是“自治系統(AS)”。每個網路都有一個唯一的數字來標誌自己，被稱為 AS 號。CloudFlare 的 AS 號是 13335，Google的 AS 號是 15169。各個網路通過一種叫做邊緣網關協議(BGP)的技術互相串連。邊緣網關協議被稱為是互連網的粘合劑——由它來聲明哪個 IP 位址屬於哪個網路，由它來建立從某個自治網路到另外一個自治網路的路由。一個互連網“路由”跟這個詞的表意完全一樣：由一個自治網路裡的 IP 位址到另外一個自治網路裡的另一個 IP 位址的路徑。

　　邊緣網關協議是基於一個相互信任的體制。各個網路基於信任的原則告訴其它網路哪個 IP 位址屬於哪個網路。當你發送一個資料包，或發送一個穿越網路的請求，你的網路服務供應商會聯絡它的上遊供應商或對等供應商，詢問它們從你的網路服務供應商到網路目的地，哪條路線最近。

　　不幸的是，如果當一個網路發出聲明說某個 IP 位址或某個網路在它的內部，而事實不是這樣，如果它的上遊網路或對等網路信任了它，那麼，這個資料包最終將會迷路丟失。這裡發生的就是這個問題。

　　我查看了邊緣網關協議傳遞的Google IP 的路由地址，路由指向了 Moratel (23947)，一個印尼的網路服務供應商。我們的辦公室在加利福尼亞，離Google的資料中心並不遠，資料包絕不應該經過印尼。很有可能是，Moratel 聲明了一個錯誤的網路路由。

　　當時我看到的邊緣網關協議發來的路由是：

　　[email protected]> show route 216.239.34.10

　　inet.0: 422168 destinations, 422168 routes (422154 active, 0 holddown, 14 hidden)

　　+ = Active Route, - = Last Active, * = Both

　　216. 239.34.0/24 *[BGP/170] 00:15:47, MED 18, localpref 100

     AS path: 4436 3491 23947 15169 I

     > to 69.22.153.1 via ge-1/0/9.0

　　我查看了其它路由，比如Google的公用 DNS，它同樣被劫持到了相同的(不正確的)路徑：

　　[email protected]> show route 8.8.8.8

　　inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, 14 hidden)

　　+ = Active Route, - = Last Active, * = Both

　　8. 8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100

    AS path: 4436 3491 23947 15169 I

    > to 69.22.153.1 via ge-1/0/9.0

　　路由泄漏

　　像這樣的問題在行業內被認為是起源於“路由泄漏”，不是正常的。這種事情並不是沒有先例。Google之前曾遭受過類似的宕機事件，當時推測是巴基斯坦為了禁止 YouTube 上的一個視頻，巴基斯坦國家 ISP 刪除了 YouTube 網站的路由資訊。不幸的是，他們的這種做法被傳遞到了外部，巴基斯坦電信公司的上遊供應商——電訊盈科(PCCW)信任了巴基斯坦電信公司的做法，把這種路由方式傳遞到了整個互連網。這個事件導致了 YouTube 網站大約 2 個小時不能訪問。

　　今天發生的事情屬於類似情況。在 Moratel 公司的某個人很可能是“胖手指”，輸錯了互連網路由。而電訊盈科，Moratel 公司的上遊供應商，信任了 Moratel 公司傳遞給他們的路由。很快，這錯誤的路由就傳到了整個互連網。在邊緣網關協議這種信任模式中，與其說這是惡意的行為，不如說這是誤操作或失誤。

　　修複

　　解決方案就是讓 Moratel 公司停止聲明錯誤的路由。作為一個網路工程師，尤其是像 CloudFlare 這樣的大網路公司裡工作的工程師，很大一部分工作就是和其它世界各地的網路工程師保持聯絡。當探明問題後，我聯絡到了 Moratel 公司的一位同事，告訴他發生了什麼事。他大概在太平洋標準時間下午 6:50 分/世界標準時間淩晨 2:50 分修複了這個問題。3 分鐘後，路由恢複了正常，Google的服務重新可以工作了。

　　從網路傳輸圖上觀察，我估計全球整個互連網使用者的 3-5% 受到了此次宕機事故的影響。重災區是香港，因為那是電訊盈科的總部。如果你所處的地區在當時無法訪問Google的服務，你現在應該知道是什麼原因了。

　　構建更好的互連網

　　我說這些就是想讓大家知道我們的互連網上如何在一個相互信任的機制下建立起來的。今天的事故說明，即使你是一個像Google這樣的大公司，外部你無法掌控的因素也會影響到你的使用者，讓他們無法訪問你。所以，一個網路技術小組是非常必要的，由他們來監控路由，管理你與世界的聯絡。CloudFlare 公司每天的工作就是確保客戶得到最佳的路由。我們照看互連網上的所有網站，確保他們的以最快傳輸速度提供服務。今天的事情只是我們工作內容的一個小片段。

 

 

從Google宕機事件認識互連網工作原理