摘要：

????????影響端到端服務可用性的主要因素中，網絡組件故障可能是最無法預知得。 失敗發生的頻率多高，持續多久，原因是什么以及它們如何影響客戶？ 傳統上，回答諸如此類的問題需要在網絡中廣泛部署的專用（并且通常是昂貴的）儀器。

? ? ? ??我們提出了一種替代方法：機會主義地挖掘現代網絡環境中已有的“低質量”數據源。本文提出了一種方法，使用結構化數據（路由器配置和系統日志）和半結構化數據（電子郵件日志）的組合來重新創建IP網絡中故障事件的簡明歷史記錄。 使用這種技術，我們分析了由超過200臺路由器組成的大型區域網絡中超過五年的故障事件; 據我們所知，據我們所知，我們進行的是同類型中最大的研究。

? ? ? 今天的以網絡為中心的企業建立在不間斷服務可用性的承諾之上。 但是，實現這一承諾是一項具有挑戰性的任務，因為可用性不是系統的固有設計屬性; 相反，系統必須適應組件的底層故障屬性。 因此，首先提供可用性需要了解故障：故障多長時間，是什么原因造成的，以及它們被掩蓋的程度如何？ 這對于網絡來說尤其如此，因為網絡呈現出復雜的故障模式，網絡越來越被認為是端到端服務中斷的主要原因。

? ? ? 不幸的是，這種分析在實踐中很少作為衡量網絡故障的常用手段，以細粒度為前提的測量機制（例如IGP日志，普遍高頻SNMP輪詢，無源鏈路監視和成對活動探測），這些研究只為研究而研究，會產生巨大的資本和運營支出。事實上，即使在研究界，由于缺乏可用的經驗數據，也常常使用任意的合成失效模型。

??????作為解決這個問題的一個步驟，我們描述了一種“廉價且骯臟”的方法，從當今生產網絡中常見的“最低公分母”數據源中提取必要的測量數據。我們展示了一種方法用于重建自治系統內的歷史網絡故障事件，該方法使用三個近乎普遍卻被人忽視數據源：路由器配置文件，系統日志歸檔和操作郵件列表通告。

? ? ? ?路由器配置文件（例如，用于配置Cisco IOS和JunOS路由器）在某個時間點描述網絡的靜態拓撲，并且通常記錄在相當大的網絡中以支持配置管理。 每個配置文件描述在路由器上啟用的一組接口，并且通常擁有足夠的信息來推斷其連接性（例如，通過通常分配給點對點鏈路的短IP網絡前綴）。 它絕不是一個完美的數據源; 它可以省略其范圍之外的拓撲結構（例如，透明的光學交叉連接）并且可以包括虛幻的拓撲結構（例如，在鏈路已經停用之后，條目可以在配置文件中很長時間地保持）。 但是，總體而言，當與附加數據結合時，它提供了廣泛的拓撲覆蓋。

? ? ? ?然而，網絡的長期拓撲結構本身并沒有表明故障點。在這里需要用到系統日志，通常在現代路由器上實現，它記錄了大量事件，包括鏈接狀態變化到遠程服務器。因此，它通過描述網絡的動態狀態（即每個時間點所有活動鏈路的狀態）來補充路由器配置數據。然而，重構這種狀態可能是痛苦的：首先，系統日志消息的非結構化質量需要解析各種各樣的消息格式，并將這些事件與接口配置記錄關聯起來，以獲得事件的完整描述。其次，由于系統日志的“盡力而為”的帶內特性，一些消息必然丟失（特別是當到系統日志服務器的最短路徑上的鏈路??失敗時）。然而，根據我們的經驗，通過利用自然報告冗余（即兩個端點通常報告鏈路故障），我們幾乎可以在90％的時間內恢復即時鏈路狀態。

? ? ? ?最后，網絡操作人員幾乎通用的做法是維護郵件列表和故障單系統以共享操作狀態的變化（例如記錄對故障的響應，通告計劃的維護活動等）。這種自由形式的自然語言數據既豐富又不完整：一方面，它提供系統日志中不可用的信息，例如失敗的原因，但同時它是由非確定性社會過程產生的，因此，只反映主觀上足夠大小和持續時間的故障情況，以便得到更廣泛的通知。然而，這種二元性使得這種公告數據有兩個不同的目的：作為故障原因的分類器和作為可用于驗證分析結果的“ground truth”的獨立來源。遵循Feamster和Balakrishnan的方法[12]，我們使用關鍵詞搜索，正則表達式和人工檢查的組合來分析公告。

? ? ? ?綜合這些資料，我們分析了來自CENIC網絡的五年存檔數據 - 這是一個由200多臺路由器組成的IP生產網絡，為大多數加利福尼亞州的公共教育和研究機構提供服務。使用系統日志和路由器配置數據，我們在此期間提取故障事件，從管理員電子郵件日志中推斷原因，并檢查我們的結果是否與三個獨立的網絡故障數據源保持一致：來自CAIDA Skitter / Ark工作的網絡活動探測，由路徑視圖項目收集的BGP日志以及來自CENIC運營商的管理通告。最后，我們使用我們重建的失敗日志來呈現失敗持續時間，原因和影響的具體分析，驗證了一些關于網絡失敗的廣泛持有的觀點（例如，鏈接“撲動”的主導地位），并描述了我們的新發現數據集（例如，計劃維護與非計劃故障的相對重要性以及第三方電信公司在撲動事件中的作用）。

相關工作

? ? ? ?自從第一個網絡建成以來，計算機網絡的設計者不得不面對頻繁的故障 - 鏈路故障，路由器故障，接口故障等。 但是，由于實際原因，大多數故障測量都是從網絡邊緣發生的。 不幸的是，這種斷層攝影技術不能提供網絡的完整圖像; “根據Huang，Feamster和Teixeira的觀點，網絡層析成像研究和可擴展網絡監測的實際系統之間仍存在差距。 直接測量仍然是網絡故障數據的黃金標準.

數據源

? ? ? ?加利福尼亞州教育網絡倡議公司CENIC運營著一個全州性的共同網絡，為加州公共教育和研究機構提供互聯網接入。它的成員合并入學人數超過600萬，其中包括加州大學系統，加利福尼亞州立大學系統，社區學院和K-12學區。在物理上，CENIC網絡是一個光纖主干網，光纖長度超過2700英里，連接主要城市的中心站點，如圖1所示。此外，CENIC還管理位于中心站點外的一些小型成員設備。

? ? ? 在行政上，CENIC網絡可以分為三個主要部分：數字加利福尼亞（DC）網絡，高性能研究（HPR）網絡和客戶端設備（CPE），每一個部分都在下面描述。

? ? ? ?DC網絡。數字加州（DC）網絡（AS 2152）是CENIC的生產網絡，通過其各自的縣教育辦公室向加州大學的學校，加利福尼亞州立大學，加州社區學院，一些私立大學和小學提供互聯網連接。 在測量期結束時（2009年12月），核心網絡由53個路由器（主要是Cisco 12000系列）組成，由178個鏈路連接。 我們將這些鏈接稱為DC（核心）鏈接。DC網絡使用IS-IS路由協議進行域內路由。

? ? ? ?HPR網絡。 除了生產網絡，CENIC還運營高性能研究（HPR）網絡（AS 2153），該網絡以10 Gb / s的速度與主要的加州研究機構相互連接。 它為大型應用用戶提供“尖端服務”[7]。 在2009年底，它由在光纖骨干網上通過七條邏輯鏈路連接的SAC，OAK，SVL，SLO，LAX和RIV集線器站點上的六臺Cisco 12000路由器組成。 HPR網絡運行自己的IS-IS路由協議實例。

? ? ? ?CPE網絡。CENIC還為一些小客戶管理客戶端設備（CPE）。 許多CPE路由器（主要是那些具有冗余連接性的路由器）在連接到DC路由器和其他CPE路由器的鏈路上運行IS-IS。 截至2009年底，有102個這樣的路由器和223個鏈路。我們將這些客戶接入鏈路稱為CPE鏈路。

歷史信息

設備配置文件。CENIC使用RANCID [29]，這是一種流行的開源系統，可自動跟蹤路由器配置的變化。所有更改都將被提交給修訂控制系統，從而可以恢復網絡中任何路由器的配置歷史記錄。我們被授權訪問此存儲庫，其中包括2004年6月至2009年12月期間的41,867個配置文件修訂版。

系統日志消息。 所有CENIC網絡路由器都配置為通過網絡將系統日志[21]消息發送到位于Tustin（TUS）樞紐站點的中央服務器。 這些消息通告了物理鏈路層，鏈路協議層和網絡層（IS-IS）的鏈路故障，覆蓋了網絡協議層次結構的前三層。 與許多本地日志不同，集中式系統日志中的消息被時間戳為只有整秒的粒度。 我們從2004年11月至2009年12月獲得了這些消息的檔案，其中217,498條涉及本研究的網絡。 不幸的是，存檔中缺少176天的系統日志數據（9/23/2007至3/17/2008）。

管理員通知。我們還獲得了用于傳播有關網絡公告的兩個郵件列表的檔案。郵件列表共包含7465條公告，涵蓋了從2004年11月到2009年12月的3505個不同事件。

? ? ? 最后，為了幫助驗證關于什么時候發生故障的結論，我們從Route Views Project [31]中提取了與CENIC網絡相關的BGP通告。 特別是，我們收集加利福尼亞州帕洛阿爾托市的對等和互聯網交換（PAIX）監聽器接收到的屬于CENIC網絡屬于或服務的地址塊的所有BGP消息。 請注意，我們的分析不依賴于BGP數據 - 我們將其用作關于外部可見故障的小子集的基礎事實。

方法

? ? ?我們工作的主要目標是制定一個通用程序來挖掘三個“低質量”歷史數據來源，以構建一個清晰的失敗時間表，其中每個失敗事件都注明了開始和結束時間，一組相關鏈接， 如果可能的話，還有一個潛在的原因。 此外，在適當的情況下，我們設法將多個同時鏈路故障匯聚成更大的事件，例如路由器和存在點（PoP）故障，并將頻繁的背對背鏈路故障合并為封閉的振蕩事件。 除了這個注釋的失敗時間線外，我們還生成關于鏈接生命周期的統計信息，作為我們分析的輸入（第6節）。 圖5描述了提取過程，以及我們在下一節討論的驗證實驗。

修復拓撲

? ? ? 在開始編制故障之前，我們必須首先建立一個正在研究的網絡的拓撲模型。 盡管地圖可能很容易獲得（實際上，目前的CENIC拓撲結構可在Web1上找到），但我們選擇從歷史數據推斷拓撲結構。 我們的理由有兩方面：首先，以前的工作表明，隨著運營商改變物理拓撲以增加容量或響應故障，拓撲數據庫會迅速過時。 其次，我們需要將系統日志信息與物理網絡實體進行交叉關聯; 提取配置文件中使用的實際標識符可以顯著簡化此任務。

????? ? 首先，我們將系統配置文件中描述的實體映射到網絡拓撲中的單個路由器和鏈路。然而，這個過程并不是完全簡單的，因為第3層系統日志消息標識鏈路的兩個端點路由器，而只標識生成系統日志消息的路由器的特定接口。在幾種情況下，這不足以完整描述鏈路，例如，當兩臺路由器之間有多個鏈路時。為了準確識別鏈路兩端的接口，我們參考了路由器的配置。每個配置文件都描述了路由器上的接口種類以及它們的配置方式;

? ? ? ?我們收集的路由器配置文件不僅僅是一個快照，而是每個路由器的一系列配置文件，每個文件版本都用更新時間進行注釋。因此，路由器配置為我們提供了一種有意義的方式，將鏈路“生命周期”定義為從配置文件中第一次提到它到最后一次之間的時間段。

? ? ? ? 我們使用類似于以前關于從配置文件中提取全局網絡狀態的工作的直接迭代過程來識別與每個鏈路相關的端口[13,14]。對于運行IS-IS的每個活動接口，我們確定同一子網上的一組IP地址。壓倒性常見的情況是，一個接口的子網是255.255.255.254（即，點對點鏈路）使得它明顯哪些接口彼此通信。一個重要的警告是，IP地址經常在不同的路由器上改變和重復使用，因此在整個分析過程中允許接口成為多個不同鏈路的一部分是至關重要的。

?

識別故障

? ? ? ?通過網絡中的鏈接集，我們分幾步處理網絡的故障歷史。 我們從syslog歸檔開始，假設它包含鏈接失敗的精確（如果不完整）枚舉。

定義故障

????????出于我們的目的，故障是導致記錄路由狀態更改（第3層）系統日志消息的任何事件。因此，我們重建的事件歷史記錄反映了網絡的路由狀態，即每當路由器拒絕通過它發送流量時，就認為鏈路失敗。因此，我們的事件歷史記錄可能無法準確捕獲網絡組件的物理狀態。例如，路由器可能拒絕通過鏈路路由流量，因為壓下計時器尚未到期，而不是由于實際斷開連接。我們將故障事件的持續時間定義為從syslog中的第一個第3層“down”消息（我們可能會從鏈路兩端的路由器接收消息）延伸到指向同一鏈路的第一個“up”。

????????回想一下，syslog還包含在物理鏈路層和鏈路協議層生成的故障消息。我們選擇關注網絡層，而不是鏈接層，因為它更忠實地捕捉了我們感興趣的狀態，即鏈接是否可以用于傳輸流量。當然，偏見是片面的：如果物理層報告鏈路“關閉”，那么它在網絡層也必然“關閉”;另一方面，鏈路可能在物理層“上”，但不在網絡層（例如，插入具有錯誤配置的VLAN的交換機的以太網鏈路）。

分組

????????一旦發現單個故障事件，我們會進一步考慮故障事件是否重疊。當故障發生在不同的鏈路上，或者在彼此的15秒內恢復時，我們將同時發生的故障定義為兩個及以上。我們確定了三種同時發生的故障：與路由器相關的，與PoP相關的，以及其他類型。 如果所有涉及的鏈路共享公共路由器，則認為同時故障與路由器相關;如果所有鏈路共享公共PoP而不是普通路由器，則為PoPrelated;如果故障沒有共同PoP，則認為是“其他”。

????????除了通過是否跨多個鏈接對同時發生的故障進行分組之外，我們還將單個鏈路上的back-to-back故障事件聚合到封閉的振蕩事件中。 長期以來，鏈路振蕩被理解為路由協議的挑戰[33]。 根據我們在本研究中使用CENIC數據集的經驗，我們將振幅定義為兩次或更多次向上/向下狀態變化，其中向下翻轉時間不超過10分鐘。 （我們在第6.2.4節中證明了我們特定的參數選擇）。

損失處理

????????與Markopoulou等人不同的是 [23]，他們使用專門的IS-IS偵聽器，而我們從路由器自己生成的系統日志消息中收集路由狀態信息。 不幸的是，由于系統日志的基于UDP的傳輸性質不可靠，并非所有的路由器日志消息都將其傳送到系統日志服務器。 因此，通常會聽到一條鏈路發生故障而另一條鏈路故障。 出于這個原因，如果至少有一個端點報告它已關閉，我們會考慮關閉鏈接，如果至少有一個端點報告它開啟，則視為開啟。

????????看到兩個“向上”消息而沒有介入“向下”消息也是常見的，反之亦然。 例如，在一個實例中，系統日志顯示HPR網絡中的LAX和RIV路由器之間的鏈路失敗（由RIV報告“down”，但不是LAX），然后在36天后，LAX報告相同的鏈路 ，沒有關于鏈接的中間消息。 我們放棄了連續的“上行”或“下行”消息之間的這種異常時段，在這種情況下，無法從數據集中推斷鏈路何時改變狀態。 我們選擇這種保守的方法來支持完整性的正確性。 對于我們的數據集，排除的時間段占HPR鏈接的鏈接小時數的12.6％，直流鏈接的鏈接小時數的9.5％，以及CPE鏈接上16小時的鏈接小時數。

故障分類

????????到目前為止，我們已經確定什么時候發生故障以及它們持續多久，但僅此而已。 推斷這些故障的可能原因需要額外的推理和附加數據。

????????除了系統日志條目之外，操作公告歸檔還包含大量信息，如果可用，可將簡單故障轉化為描述良好的事件（例如，參見圖4）。 在手動審查多個通告后，我們觀察到大多數事件可以分為少數類別。

????????我們將管理員通知分為七個類別，如表2所列。我們根據匹配的關鍵字，短語和正則表達式手動標記每個通知。 在某些情況下，可能會有多個有關相同故障事件的公告。 將這些多個公告組合成單個事件需要在每個公告中重復一些信息。 幸運的是，關于事件的第一個公告包含事件的開始時間，以易于識別和解析的格式。 從那里，每個額外的公告或者包含原始公告或者重新說明事件的開始時間。 最后的公告還包含活動正式結束的時間。

????????我們使用時間相關性來匹配故障（通過處理系統日志來計算）和潛在原因（基于管理員通知），從系統日志開始和結束故障的時間以及故障原因標記為啟動時間和結束時間， 。為了找到匹配的結果，我們將運營通告的開始和結束時間擴大了15分鐘，以彌補時鐘同步，保守時間窗口和延遲報告等潛在問題。不幸的是，盲目地將原因分配給公告窗口內的系統日志失敗會導致大量的誤報。為了盡量減少這種錯誤，我們從公告消息中提取路由器名稱或縮寫，并確保在消息中提到鏈路中至少有一臺路由器，然后再將其與相應的基于syslog的推斷相匹配。對于我們的CENIC數據集，我們丟棄了2,535條消息中的1,335條（53％），盡管在系統日志中發生故障事件的同時，并沒有明確提及涉及故障的路由器。手工檢查可能挽救其中相當大的比例。

????????我們使用時間相關性來匹配故障（通過處理系統日志來計算）和潛在原因（基于管理員通知），從系統日志開始和結束故障的時間以及標記著啟動時間和結束時間的故障 。為了找到匹配的結果，我們將運營通告的開始和結束時間擴大了15分鐘，以彌補時鐘同步，保守時間窗口和延遲報告等潛在問題。不幸的是，盲目地將原因分配給公告窗口內的系統日志失敗會導致大量的誤報。為了盡量減少這種錯誤，我們從公告消息中提取路由器名稱或縮寫，并確保在消息中提到鏈路中至少有一臺路由器，然后再將其與相應的基于syslog的推斷相匹配。對于我們的CENIC數據集，我們丟棄了2,535條消息中的1,335條（53％），盡管在系統日志中發生故障事件的同時，并沒有明確提及涉及故障的路由器。手工檢查可能挽救其中相當大的比例。

驗證

????????系統日志數據并不是用于檢測故障的，因此某些遺漏和含糊不可避免是不可避免的。 一般驗證網絡故障數據具有挑戰性的，特別是在過去五年處理事件時尤其如此。 因此，我們采取機會主義的方法，檢查與我們擁有的數據的一致性，了解到會有噪音和錯誤反映這些不同數據源之間的不同優勢點。 特別是，我們的方法有兩個主要缺點：既不完整也不是100％準確：可能有失敗，我們的日志不包括，可能是我們所做的失敗包括虛假，錯誤分類或不正確時間戳。 我們將討論我們選擇數據源所產生的潛在偏差，以及我們如何驗證我們的結果并幫助量化我們的錯誤。

測量偏差

????????如前所述，由于系統日志的不可靠性，可能會從系統日志中丟失一些鏈接狀態更改消息。因此，“下行”鏈路狀態轉換可能沒有對應的先前的“向上”，反之亦然。在我們迄今為止的使用中，我們發現這些差距相對較小（占連接時間的不到13％），但這也可能是我們特定網絡和硬件的人為因素。

????????另外，我們對鏈路故障的定義是基于底層路由協議報告的鄰接狀態。例如，為了確保連接性，IS-IS協議要求路由器發送和接收hello消息。缺省情況下，路由器每10秒發送一個hello消息，如果30秒內沒有收到hello消息，則聲明鏈路已斷開。因此，我們可能會將失敗持續時間減少到每失敗30秒。相反，ISIS會考慮修復鏈路，直到可配置的保持定時器到期（此過程是動態的，但應產生類似的偏差）。

????????另一個模棱兩可的問題在于確定每個環節的“年齡”，以便計算年度化統計數據。年齡的自然定義就是鏈接添加到網絡和刪除鏈接之間的時間間隔。這個定義的一個小問題是，在我們的系統日志數據開始之前（離開審查），一些鏈接被添加到網絡中，直到我們的系統日志數據用完之后才被刪除，并且/或者在syslog數據丟失的月份中繼續運行（權限審查）。為了解決這些問題，我們不允許在系統日志數據啟動之前將任何鏈接添加到網絡中，在系統日志數據結束后刪除網絡中的所有鏈接，并且忽略系統日志數據中缺少時間段的任何操作時間。無法直接克服的第二個問題是維護路由器配置文件的粒度。由于接口沒有創建或刪除時間標記，因此我們依賴于第一個和最后一個包含有效接口描述的配置文件。不幸的是，配置更新會定期記錄 - 而不是即時記錄 - 因此，我們很容易在以后添加到我們網絡的鏈接，而不是實際添加它們，并在它們可能已被刪除后刪除它們。

內部一致性

????????由于我們的數據是歷史數據，而且CENIC網絡運營商沒有收集或維護任何我們可以用作關于失敗的時間或原因的基本事實的額外日志，我們被迫尋找替代的驗證方法。 我們使用兩種定性不同的方法。 首先是交叉驗證我們的記錄; 系統日志和操作電子郵件通告之間的任何不一致或不一致都會增加出錯的可能性。 雖然我們不能確定缺乏不一致意味著正確性，但我們可以量化不一致的程度以提供我們方法準確性的近似上限。 其次，某些失敗可能是外部可見的，在這種情況下，我們可以利用由第三方收集的日志。

????????首先關注內部一致性，我們使用管理員通知（第4.2.3節）來驗證從系統日志歸檔重建的事件歷史記錄。在重建這段歷史時，我們使用管理員通知在可用時標記故障原因 - 特別是，如果有與特定故障有關的通告。可以理解的是，電子郵件列表中的操作員只討論鏈接故障的一小部分。在這里，我們嘗試相反的映射。具體來說，我們檢查重建的事件歷史記錄是否也記錄相應的事件。

????????理想情況下，我們將確認行政公告中提及的3,505個不同事件中的每一個都出現在日志中。由于無法從自由格式的電子郵件中提取精確的細節，因此必須手動完成匹配。因此，我們驗證事件的隨機子集。在我們檢查的35個（大約1％）事件中，只有一個不能與事件歷史中相應（一組）失敗（即97％的準確率）相匹配。

外部可見的事件

????????在設計良好的網絡中，大多數故障都被冗余鏈路和協議所掩蓋。因此，雖然網絡運營商顯然有興趣了解故障，以便他們能夠解決故障并恢復正常運行，但網絡用戶在發生故障時可能不會注意到。但是，某種類型的災難性故障無法隱藏：那些導致網絡分區的故障。 CENIC網絡連接到較大的互聯網，因此，這些網絡中的任何網絡分區都可以從商業互聯網觀察到。

????????我們知道有兩個公開可用的關于可達性的數據集，這些數據集過去可以回溯到驗證我們的失敗日志：CAIDA Skitter / Ark活動跟蹤路由測量和俄勒岡大學路由視圖BGP日志。在這里，我們開發了一種方法來驗證我們的失敗日志 - 至少在導致網絡分區的有限失敗情況下 - 通過檢查公開可用的traceroute和BGP記錄來驗證失敗日志。

CAIDA Ark/Skitter traceroute

????????確定鏈接是否停止的一種直接方法是嘗試使用它。大多數商業網絡運營商定期進行主動式端到端探測[26]，為他們自己的網絡做到這一點。 CAIDA的方舟（néSkitter）項目通過各種跟蹤路由服務器在整個互聯網上的多個目的地進行零星跟蹤路由[5]。偶爾，Skitter在CENIC網絡內探測目的地。雖然我們對實際路線本身沒什么興趣，但我們對終點的可達性有興趣。特別是，對于CENIC內所有目的地的Skitter探測器，我們都可以通過比較Skitter探測器的成功或失敗與我們的事件記錄來驗證我們的失敗日志：對于所有成功的Skitter探測器，我們驗證所有鏈路已經穿越由Skitter記錄方便地列舉出來）根據我們的故障日志在探測時“上升”。相反，如果Skitter探測器失敗，我們驗證1）探測器在到達或通過CENIC網絡之后失敗，或者2）根據我們的探測時間離開最后一次成功跳躍的鏈路“下降”。

????????CAIDA為我們提供了涵蓋我們研究六個月（2007年1月至6月）的Skitter traceroute數據 - 已經超過了四千兆字節的壓縮數據。 從數據中，我們從CENIC網絡中提取了75,493,637針對CENIC網絡中301個不同目的地的探針，覆蓋了來自17個不同的traceroute服務器，覆蓋了131個鏈路和584個不同的路徑。 這7500萬個Skitter探測器的結果與我們事件歷史中反映的鏈接狀態一致。 不幸的是，在CENIC網絡內部沒有一個Skitter探測器失敗 - 換句話說，盡管日志與Skitter數據完全一致，但Skitter并沒有肯定地確認日志中的任何故障事件。

路由視圖BGP歸檔

????????與需要主動探測才能檢測故障的traceroute不同，被動BGP偵聽器是異步通知可達性信息的。 因此，在BGP監控鏈路連接的情況下，其故障歷史可能會更加完整。 俄勒岡大學的路徑視圖項目已經在全球部署了十個BGP監聽器來收集BGP更新，并使其日志公開可用。 然而，BGP數據的主要挑戰是其粗粒度。 BGP會根據網絡或IP前綴進行說明，而不是像traceroute這樣的單獨的第3層鏈路。 因此，一個BGP偵聽器將只檢測整個網絡變得無法到達的時間。

????????在考慮CENIC網絡的特殊情況時，我們必須記住，多個城市中的多個核心路由器將不得不同時對網絡核心進行分區。 因此，我們在研究過程中沒有觀察CENIC核心網絡中的一個分區，這并不奇怪。 但是，大多數帶有CPE路由器的客戶站點只有一個路由器，并且只有一個或兩個到CENIC核心的鏈路。 因此，如果CENIC和CPE路由器之間的所有鏈路都失敗，則該站點將從網絡中分割出來。 這種事件很少發生，但偶爾會發生。

????????我們為CENIC服務的60個不同網絡（即客戶網站）確定了IP前綴。不幸的是，我們只能使用BGP來驗證這些網站的一個子集，因為CENIC不會撤回居住在CENIC地址空間中的客戶的前綴（這些客戶通常是像K-12學區那樣的小客戶）。我們在CENIC故障日志中確定了19個客戶站點，這些站點擁有自己的自治系統（AS），并由CENIC生成BGP撤消消息。我們通過搜索涉及所有CPE路由器與CENIC的鏈接的多鏈路故障事件，在重建的事件歷史記錄中識別這些站點的網絡分區。我們發現這些客戶網站在發生故障期間被隔離。這種方法的一個問題是，一些客戶可能會多宿主 - 換句話說，有訪問除CENIC以外的其他網絡的鏈接。在這種情況下，我們會斷言，一個網站實際上只是遭受退化服務而被隔離。但是，我們沒有在我們的日志或與CENIC運營商的互動中發現任何此類網站的任何證據。

????????位于加利福尼亞州帕洛阿爾托的Peering和Internet Exchange（PAIX）位于距離CENIC網絡最近的地理位置最近的Route Views BGP監聽器中。不幸的是，BGP偵聽器的網絡（AS6447）不直接與CENIC網絡（AS2152）對等，而是與幾個直接與CENIC對等的AS對等。為了適應路由視圖監聽器2的所有對等體之間BGP會聚的特性，如果至少有四個對等AS撤回了該站點的所有前綴，我們就聲明一個根據BGP隔離的CENIC站點。除了這些隔離事件之外，我們還觀察到兩個或三個AS撤回所有站點前綴的情況，但其他幾個AS將通告多個單調遞增長度的站點前綴路徑。我們將這種第二種類型的事件稱為BGP路徑更改。雖然隔離是網絡分區的有力證明，但BGP路徑更改事件也可能是由于CENIC網絡內發生外部可見故障，因此也可用于驗證我們的錯誤日志。

????????在我們的事件歷史中的147個應該在BGP中可見的隔離事件中，我們能夠匹配51來完成BGP隔離 - 即完全收斂的路由撤銷（表3）。 但是，如果我們更保守地考慮BGP路徑更改，我們能夠確認147個事件中的105個。 值得注意的是，在其余的42場事件中，其中23場屬于單一環節。 這個鏈接可能由一個靜態配置的鏈接來備份，這個鏈接并不反映在我們的IS-IS數據集中。

分析

????????通過將前面章節中描述的方法應用于CENIC系統日志和運營公告電子郵件日志，我們獲得一個現代化規模的生產網絡的超過五十年的故障數據。 因此，我們有能力就實際網絡的運作提出幾個基本問題。 特別是，我們認為：

?失敗發生的頻率如何？ 他們持續多久？
?失敗的原因是什么？ 某些類型的鏈接比其他鏈接更容易失敗嗎？

?鏈路故障的影響是什么？ 網絡是否適應沒有顯著的服務中斷？

????????雖然我們對于結果的一般性沒有提出任何要求，但我們認為對這一范圍和持續時間的研究在文獻中是前所未有的，而且我們的研究結果可能代表了一大類教育和研究網絡。

歷史一瞥

垂直條紋。圖中顯示了幾個垂直帶，這對應于全系統事件。例如，圖中2005年9月標記為V1的頻段是需要重啟路由器的全網ISIS配置更改。 （圖的規模使得鏈路故障同時出現;該頻段實際上跨越了大約一周。）2007年3月的另一個頻段（標記為V2）是全網絡軟件升級的結果。第三個頻段V3發生在2009年2月，作為準備IPv6的網絡配置變更。
水平條紋。圖6還包含幾個水平段。在圖中間標記為H1的幾乎堅實的部分對應于核心路由器和縣教育局之間的鏈路上的一系列故障。該部分由許多短時間的故障組成，每天只發生幾次。在至少一次不成功的診斷問題之后，原因最終被發現是硬件故障。

圖中標記為H2的水平段對應于兩個HPR路由器之間的RIV-SAC鏈路。從2006年7月到2007年1月，這個環節經歷了33,000短時間的失敗。雖然最初的原因是光纖切割，但修復過程損壞了光學設備，導致難以診斷的不穩定性。由于這種單次撲動事件占HPR網絡中所有鏈路故障的93％，我們將其從數據集中移除以避免進一步分析偏差。

綜合統計

????????我們通過計算關于每個鏈路的故障頻率和持續時間的匯總統計來開始我們的分析，無論是單個故障事件還是累積鏈路停機時間。 表4顯示了每種分布的平均值，中位數和第95百分位數。 對于所有年度統計數據，我們排除了運行時間少于30天的鏈接，因為它們的方差膨脹。

????????也許我們可能會問的最自然的第一個問題是“有多少失敗？”。圖7顯示了每年每個鏈路數量失效的累積分布函數（CDF）。 我們通過將失效次數除以鏈接的生命周期（不包括運行鏈接少于30天）來計算每個鏈接每年的失敗次數。

????????在直流電網絡中，大多數鏈路幾乎沒有發生故障，正如人們對生產網絡所期望的那樣。 由客戶駐地上的接入鏈路和路由器組成的CPE網絡可靠性稍差，每個鏈路的年平均故障率為20.5個故障。 HPR網絡經歷了更多的故障。

????????到目前為止，我們已經獨立考慮了每個鏈路故障。然而，正如4.2.2節所討論的那樣，我們也會根據時間相關性將鏈路故障分為更大的事件。特別是，我們會在適當的情況下將同時發生的故障匯總到PoP或路由器故障中，并將背對背故障組合成震蕩劇集。然而，CENIC網絡的情況相對較少，因此我們只專注于后者。

?????????圖8（c）繪出單個鏈路上故障事件之間時間的CDF。我們在10分鐘處畫一條垂直線，這是我們對“拍打”的定義：“在相隔10分鐘以內的同一鏈路上的兩個或更多個連續失敗事件被組合成一個更大的拍打事件。 10分鐘剛好超過每個網絡的曲線拐點 - 分布在較長的時間間隔內顯得無記憶。以這種方式構建的所有撲動事件中超過50％僅包含兩次失敗，但是5％的事件包含超過19次失敗（未示出）。圖9顯示了拍打劇集內的停機時間量 - 請注意，這不是劇集的持續時間，而僅僅是劇集內鏈接實際下降的時段。與圖8（b）相比，我們發現撲動事件整體上比典型的失敗事件更具破壞性。

????????再次，我們的研究結果加強了以前的研究。 Watson等人 [33]和Markopoulou等人。 [23]也發現，鏈接拍打是不穩定的主要來源。 所有三項研究都不可能反映異常網絡，相反，我們建議在大型網絡中短時間尺度和振蕩行為可能只是“正常”。 因此，應該準備網絡協議和路由算法來處理撲動作為常見情況。

故障原因

????????現在我們已經量化了發生故障的頻率，我們將注意力轉向其原因。 我們考慮特定類型的鏈接是否更有可能失敗，然后檢查運營商明確指責的情況。

鏈路類型

????????每個組成CENIC網絡由許多不同的鏈路技術組成，包括以太網，SONET和串行線路。 圖10不是通過網絡（c.f.圖8）分解單個故障事件，而是通過所涉及的硬件類型來分解。 圖10（a）表明以太網鏈路比其他技術更可靠。 圖10（b）顯示，雖然以太網故障不像串行線那樣快速修復，但它們不太頻繁（圖10（c））。 這無疑部分歸因于以太網在短距離鏈路中的優勢，而短鏈路對外部故障過程的影響較小。

標記原因

????????于鏈接失敗的一個子集，我們可以通過將它們與管理員通知相匹配來為它們注釋關于其原因的信息。 我們能夠將5,237（19,046）個事件中的一個與此類通知相匹配，占總停機時間的37.5％。 圖12顯示了根據所述原因分解這些事件的情況。 多個故障事件是由于軟件升級造成的，硬件升級成為下一個最常見的原因。 然而，圖13顯示盡管與硬件相關的事件占據了停機時間的大部分，但軟件升級造成的總停機時間要少得多; 事實上，包括電力中斷在內的外部因素的影響更為顯著。 數據也在表6中總結。

????????表5提供了關于每個類別的單個故障事件持續時間的一些基本統計數據。 大多數事件都很短，但硬件和停電的中位時間要長得多 - 超過20分鐘。 然而，幾乎所有的類別都有嚴重的尾巴，導致平均故障持續時間比中間值長一個數量級。

????????除了識別故障原因之外，管理員通知還會指出故障是否預計或“預定”。 管理員公告中發現的大多數故障事件都是按計劃進行的，但大部分實際停機時間都可能歸因于意外故障，這可能是因為操作員注意確保計劃停機時間盡可能有限。 實際上，計劃停電的中值時間不到5分鐘（未顯示）。 有趣的是，似乎在影響網絡運行的事件發生之前，網絡運營商往往不會通知外部實體。

故障影響

????????總的來說，我們很難從故障日志中得知故障對網絡用戶造成的影響（如果有的話）。 但是，對于通過管理員通知注釋的事件集，我們可以報告通知是否明確說明事件是否應該對網絡產生影響。 表6的第三列指出事件的哪一部分應該對網絡產生一些影響 - 不過是簡短的。 在幾乎所有情況下，運營商都會指出可能導致鏈路停機。 然而，這種現象可能是由于運營商的自我選擇造成的。 無影響的失敗事件 - 尤其是不定期的事件 - 似乎不太可能激勵運營商發布公告。

????????正如第5節所討論的那樣，我們可以推斷的唯一影響是隔離網絡分區。 表7列出了我們在故障日志中識別的508個隔離故障，將它們分成有和沒有自己的AS的網絡，并提供原因注釋（如果可用）。 有趣的是，分區事件失敗原因的細分與所有事件有所不同 - 在這里，軟件失敗占主導地位。 表8總結了不同原因引起的隔離故障的修復時間分布，與所涉及的AS無關。 與非隔離事件一樣，電源和硬件事件的持續時間明顯長于軟件故障引起的持續時間。

時間動態

????????像大多數復雜系統一樣，CENIC網絡正在不斷發展。 從2008年開始，最重要的變化是將一些DC路由器指定為“核心”路由器，其余為“接入”路由器。 這導致了235個鏈接的退役和引入了432個新鏈接。 那么一個自然的問題就是，早期檢查的網絡質量是否也發生了變化。 圖14顯示了測量期間每年DC網絡中的年度鏈路停機時間。 我們期望在6.2節中提出的基本統計數據中找到趨勢。 事實上，我們發現這些績效指標每年都不一樣，沒有明顯的趨勢。 2006年以及2008年的較低程度，脫穎而出的是與前幾年和后幾年相比，鏈接停機時間更短。 每個環節的年度失敗次數也相應變化，2006年最低的中位數為0.0，2005年最高的中位數為6.0。

????????進一步調查，我們發現6.3.2節中研究的原因分布也不盡相同。 幾個全網事件負責鏈路故障數量的顯著變化。 最值得注意的是，與軟件相關的鏈路故障和配置更改是幾年內鏈路故障的重要來源，而不是其他故障。 由于網絡范圍內的升級和配置變更（見第6.1節），圖6中的三個垂直頻段對2005年，2007年和2009年的故障的中值數和中值鏈路停機時間產生了重大影響。縱向趨勢（如果存在的話）因此是矮化的 由重大但罕見的事件。

結論

????????在本文中，我們提出了一種推斷和分析缺少專用監控基礎設施的網絡的鏈路故障歷史記錄的方法。 特別是，我們表明，現有的“低質量”數據源已經廣泛地集中在生產網絡中 - 系統日志，路由器配置和運營郵件列表 - 可以機會性地組合以重建拓撲，動態狀態和故障原因。 使用這種方法，我們分析了來自CENIC網絡（一家大型加州互聯網服務提供商）的五年鏈路故障歷史，并驗證了有關故障的現有理解（例如，鏈路振蕩的普遍性）并記錄了較少的贊賞性問題（例如，大 由第三方租用線路問題造成的停機時間）。 我們認為我們的整體方法相當一般，應該很容易適應各種IP網絡。

總結

以上是生活随笔為你收集整理的California Fault Lines: Understanding the Causes and Impact of Network Failures的全部內容，希望文章能夠幫你解決所遇到的問題。

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