近日，美國互聯網服務提供商 CenturyLink 因數據中心的錯誤配置導致多個網站受到影響。據瞭解，這次事故是 BGP 路由配置錯誤引起的連鎖反應，受到影響的服務包括 Cloudflare、AWS、Garmin、Steam、Discord 和 Blizzard 等。
在此次事故中受到嚴重影響的 Cloudflare 表示：“CenturyLink 的向外傳播問題導致全球互聯網流量下降了 3.5%，這將是有史以來最大的互聯網中斷之一。”最終，CenturyLink 花了 7 個小時才解決了這個問題。
爲什麼會出現這次事故呢？Cloudflare 官方博客發佈了文章來複盤此次事故，下面我們就一起來看看吧。
服務器上的錯誤數量激增，服務開始大面積出現問題
當天上午 10：03（世界標準時間），Cloudflare 監管系統開始觀察到客戶原始服務器上的錯誤數量有所增加。結果顯示爲“錯誤552”，代表從 Cloudflare 網絡連接、到客戶託管應用程序的各個位置，開始大面積出現問題。
除 CenturyLink/Level (3) 之外，Cloudflare 還同時與其他衆多大型網絡服務供應商保持對接。在發現某一家網絡服務供應商的設施錯誤量增加時，系統會自動嘗試經由其他供應商訪問客戶的應用程序。憑藉這種故障轉移機制，即使某家供應商遭遇問題，一般也可以繼續正常路由流量。
因此，當522錯誤數量開始增加的幾秒鐘之後，Cloudflare 的系統開始自動將流量由 CenturyLink/Level (3) 重新路由至其他備用網絡供應商處，包括 Cogent、NTT、GTT、Telia 以及 Tata。
上圖爲 Cloudflare 網絡與所對接的各網絡服務供應商之間的六條核心一級主幹網絡之間的流量。紅色部分代表 CenturyLink/Level (3) 流量，該流量在故障期間降至接近於零。
上圖爲故障事件發生期間網絡上出現的總計 522 錯誤數量。10：03 起，急劇上升的部分爲 CenturyLink/Level (3) 網絡錯誤數量。當時，自動化系統立即開始重新路由並將流量均衡至其他各網絡服務供應商處。通過此舉，錯誤數量減少了一半，隨後又通過針對新路徑的優化而進一步降低至峯值水平的 25%。
在 10：03 至 10：11 期間，系統自動在 48 座城市中禁用了 CenturyLink/Level (3)，並通過其他網絡服務供應商重新路由流量。爲了防止級聯故障，系統在轉移流量之前會考慮到其他服務供應商的網絡傳輸容量。正因爲如此，自動化故障轉移並非在各個位置同步進行。與此同時，Cloudflare 團隊又採取其他手動緩解措施，保證將錯誤數量再減少 5%。
那麼，問題可能源自何處？
事故發生的真正原因可能只有 CenturyLink/Level(3) 發佈最終取證報告之後才能明確，但通過 BGP 公告中的線索以及中斷期間的影響傳播，我們可以做出推測。BGP 是指邊界網關協議，即互聯網上的各路由器如何相互通報其後的 IP 地址，及其接收傳輸流量的具體方式。
從 10：04 開始，互聯網上出現了大量 BGP 更新。BGP 更新，代表着由路由器發出的、原有路由已經發生更改或不再可用的指示信號。在正常情況下，互聯網上每 15 分鐘會出現 1.5 MB 到 2 MB 大小的 BGP 更新流量。但在事件開始之後，BGP 更新的規模激增至每 15 分鐘超過 26 MB，而且在此次故障期間始終保持在較高水平。
這些更新表明，CenturyLink/Level(3) 主幹網內部的 BGP 路由很不穩定。問題是，這種不穩定從何而來？通過 CenturyLink/Level(3) 狀態更新中的一點線索，加上一項 flowspec 更新中顯露的端倪，我們似乎可以做出大膽猜測。
在 CenturyLink/Level(3) 的更新通報中，提到引發此次問題的根源在於錯誤的 Flowspec 規則。那麼 Flowspec 是什麼？它是 BGP 的擴展，允許使用 BGP 在網絡之內甚至是網絡之間輕鬆分發防火牆規則。Flowspec 是一款功能強大的工具，可以幫助用戶幾乎即時在整個網絡之上高效推送規則。在嘗試快速對網絡攻擊等事件做出響應時，這種推送能力當然非常重要；但在另一方面，如果出現了錯誤，那麼這些錯誤也將被快速傳播到網絡中的各個角落。
Cloudflare 的發展歷程中也曾使用 Flowspec 推送防火牆規則，藉此緩解例如大型網絡層 DDoS 攻擊等極端事件。但是在 7 年前，Cloudflare 遭遇到由 Flowspec 造成的停機，於是決定不再親自使用 Flowspec。
我們推測 CenturyLink/Level(3) 到底經歷了什麼。一種可能的情況是，他們發出了 Flowspec 命令，嘗試阻止針對當前網絡的攻擊或其他濫用行爲。狀態報告表明，Flowspec 規則阻止了 BGP 本體的正常發佈。現在無法知悉 CenturyLink/Level(3) 到底編寫了怎樣的 Flowspec 規則，唯一可以肯定的就是這是一條 Juniper 格式的規則，會阻止其網絡上的所有 BGP 通信。
route DISCARD-BGP {
match {
protocol tcp;
destination-port 179;
}
then discard;
}
另外，在此次事件中，全局 BGP 更新始終保持在較高水平的原因仍舊是個謎。如果說 Flowspec 規則阻止了 BGP，那麼更新公告剛開始會有所增加，而後又逐步恢復正常纔對。
一種可能的解釋是，有問題的 Flowspec 規則正好接上了一條長長的 BGP 更新清單的結尾。如果情況真是如此，那麼 CenturyLink/Level(3) 網絡中的每個路由器都將接收到 Flowspec 規則，進而開始阻止 BGP 更新，也就是停止接收規則。各中山路將重新啓動，遍歷所有 BGP 規則，直到再次運行到存在問題的 Flowspec 規則爲止——這時，BGP 將再次被丟棄，後續 Flowspec 規則無法正常接收。整個循環一次又一次重複，而每過一輪週期，CenturyLink/Level(3) 網絡中的 BGP 更新隊列都會持續增加。這個問題有可能已經導致路由器的內存與 CPU 發生過載，並給在線網絡恢復帶來一系列額外的挑戰。
爲什麼修復時間這麼長？
Cloudflare 的服務中斷問題是在四個小時之後纔得到解決的，爲什麼這次修復時間這麼長？
首先，出現故障的原因不明，Cloudflare 只是依據故障事件作出了相關的推測，可能是由於 Flowspec 以及大量 BGP 更新給其路由器帶來了巨大負擔，導致 CenturyLink/Level(3) 運營人員難以登錄設備接口。所以，在 CenturyLink/Level(3) 的請求下，其他幾家一級網絡供應商也紛紛採取行動，取消各方之間的對等網絡。這一做法限制了 CenturyLink/Level(3) 網絡接收到的 BGP 公告數量，幫助他們爭取到了寶貴的時間窗口。
其次，存在問題的 Flowspec 規則可能並非由 CenturyLink/Level(3) 發佈，而是來自他們的某位客戶。目前不少網絡服務供應商都允許 Flowspec 對等傳播。對於希望阻止攻擊流量的下游客戶來說，這無疑是一種強大的工具；但一旦出現問題，對違規 Flowspec 規則的追蹤也變得更加困難。
最後一點是 CenturyLink/Level(3) 擁有極爲龐大且複雜的網絡體系，因此故障可以說是一刻不停地出現。
相關鏈接：
https://blog.cloudflare.com/analysis-of-todays-centurylink-level-3-outage/