近日，美國互聯網服務提供商 CenturyLink 因數據中心的錯誤配置導致多個網站受到影響。據了解，這次事故是 BGP 路由配置錯誤引起的連鎖反應，受到影響的服務包括 Cloudflare、AWS、Garmin、Steam、Discord 和 Blizzard 等。

作者 | 核子可樂、田曉旭

Twitter 用戶吐槽服務中斷

在此次事故中受到嚴重影響的 Cloudflare 表示：“CenturyLink 的向外傳播問題導致全球互聯網流量下降了 3.5%，這將是有史以來最大的互聯網中斷之一。”最終，CenturyLink 花了 7 個小時才解決了這個問題。

為什么會出現這次事故呢？Cloudflare 官方博客發布了文章來復盤此次事故，下面我們就一起來看看吧。

1服務器上的錯誤數量激增，服務開始大面積出現問題

當天上午 10：03（世界標準時間），Cloudflare 監管系統開始觀察到客戶原始服務器上的錯誤數量有所增加。結果顯示為“522 個錯誤”，代表從 Cloudflare 網絡連接、到客戶托管應用程序的各個位置，開始大面積出現問題。

除 CenturyLink/Level (3) 之外，Cloudflare 還同時與其他眾多大型網絡服務供應商保持對接。在發現某一家網絡服務供應商的設施錯誤量增加時，系統會自動嘗試經由其他供應商訪問客戶的應用程序。憑借這種故障轉移機制，即使某家供應商遭遇問題，一般也可以繼續正常路由流量。

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%。

2那么，問題可能源自何處？

事故發生的真正原因可能只有 CenturyLink/Level(3) 發布最終取證報告之后才能明確，但通過 BGP 公告中的線索以及中斷期間的影響傳播，我們可以做出推測。BGP 是指邊界網關協議，即互聯網上的各路由器如何相互通報其后的 IP 地址，及其接收傳輸流量的具體方式。

從 10：04 開始，互聯網上出現了大量 BGP 更新。BGP 更新，代表著由路由器發出的、原有路由已經發生更改或不再可用的指示信號。在正常情況下，互聯網上每 15 分鐘會出現 1.5 MB 到 2 MB 大小的 BGP 更新流量。但在事件開始之后，BGP 更新的規模激增至每 15 分鐘超過 26 MB，而且在此次故障期間始終保持在較高水平。

資料來源:http://archive.routeviews.org/bgpdata/2020.08/UPDATES/

這些更新表明，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 發生過載，并給在線網絡恢復帶來一系列額外的挑戰。

3為什么修復時間這么長？

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/

end

歡迎關注微信公眾號【廈門微思網絡】。www.xmws.cn專業IT認證培訓19周年 主要課程：思科、華為、紅帽、ORACLE、VMware、CISP、PMP等認證培訓及考證

總結

以上是生活随笔為你收集整理的【热点】因这个配置错误导致全球互联网流量下降了 3.5%的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。