? ? ? 在開始編制故障之前，我們必須首先建立一個正在研究的網(wǎng)絡(luò)的拓?fù)淠Ｐ汀?盡管地圖可能很容易獲得（實(shí)際上，目前的CENIC拓?fù)浣Y(jié)構(gòu)可在Web1上找到），但我們選擇從歷史數(shù)據(jù)推斷拓?fù)浣Y(jié)構(gòu)。 我們的理由有兩方面：首先，以前的工作表明，隨著運(yùn)營商改變物理拓?fù)湟栽黾尤萘炕蝽憫?yīng)故障，拓?fù)鋽?shù)據(jù)庫會迅速過時。 其次，我們需要將系統(tǒng)日志信息與物理網(wǎng)絡(luò)實(shí)體進(jìn)行交叉關(guān)聯(lián); 提取配置文件中使用的實(shí)際標(biāo)識符可以顯著簡化此任務(wù)。

????? ? 首先，我們將系統(tǒng)配置文件中描述的實(shí)體映射到網(wǎng)絡(luò)拓?fù)渲械膯蝹€路由器和鏈路。然而，這個過程并不是完全簡單的，因?yàn)榈?層系統(tǒng)日志消息標(biāo)識鏈路的兩個端點(diǎn)路由器，而只標(biāo)識生成系統(tǒng)日志消息的路由器的特定接口。在幾種情況下，這不足以完整描述鏈路，例如，當(dāng)兩臺路由器之間有多個鏈路時。為了準(zhǔn)確識別鏈路兩端的接口，我們參考了路由器的配置。每個配置文件都描述了路由器上的接口種類以及它們的配置方式;

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

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

?

識別故障

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

定義故障

????????出于我們的目的，故障是導(dǎo)致記錄路由狀態(tài)更改（第3層）系統(tǒng)日志消息的任何事件。因此，我們重建的事件歷史記錄反映了網(wǎng)絡(luò)的路由狀態(tài)，即每當(dāng)路由器拒絕通過它發(fā)送流量時，就認(rèn)為鏈路失敗。因此，我們的事件歷史記錄可能無法準(zhǔn)確捕獲網(wǎng)絡(luò)組件的物理狀態(tài)。例如，路由器可能拒絕通過鏈路路由流量，因?yàn)閴合掠?jì)時器尚未到期，而不是由于實(shí)際斷開連接。我們將故障事件的持續(xù)時間定義為從syslog中的第一個第3層“down”消息（我們可能會從鏈路兩端的路由器接收消息）延伸到指向同一鏈路的第一個“up”。

????????回想一下，syslog還包含在物理鏈路層和鏈路協(xié)議層生成的故障消息。我們選擇關(guān)注網(wǎng)絡(luò)層，而不是鏈接層，因?yàn)樗覍?shí)地捕捉了我們感興趣的狀態(tài)，即鏈接是否可以用于傳輸流量。當(dāng)然，偏見是片面的：如果物理層報(bào)告鏈路“關(guān)閉”，那么它在網(wǎng)絡(luò)層也必然“關(guān)閉”;另一方面，鏈路可能在物理層“上”，但不在網(wǎng)絡(luò)層（例如，插入具有錯誤配置的VLAN的交換機(jī)的以太網(wǎng)鏈路）。

分組

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

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

損失處理

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

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

故障分類

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

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

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

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

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

驗(yàn)證

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

測量偏差

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

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

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

內(nèi)部一致性

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

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

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

外部可見的事件

????????在設(shè)計(jì)良好的網(wǎng)絡(luò)中，大多數(shù)故障都被冗余鏈路和協(xié)議所掩蓋。因此，雖然網(wǎng)絡(luò)運(yùn)營商顯然有興趣了解故障，以便他們能夠解決故障并恢復(fù)正常運(yùn)行，但網(wǎng)絡(luò)用戶在發(fā)生故障時可能不會注意到。但是，某種類型的災(zāi)難性故障無法隱藏：那些導(dǎo)致網(wǎng)絡(luò)分區(qū)的故障。 CENIC網(wǎng)絡(luò)連接到較大的互聯(lián)網(wǎng)，因此，這些網(wǎng)絡(luò)中的任何網(wǎng)絡(luò)分區(qū)都可以從商業(yè)互聯(lián)網(wǎng)觀察到。

????????我們知道有兩個公開可用的關(guān)于可達(dá)性的數(shù)據(jù)集，這些數(shù)據(jù)集過去可以回溯到驗(yàn)證我們的失敗日志：CAIDA Skitter / Ark活動跟蹤路由測量和俄勒岡大學(xué)路由視圖BGP日志。在這里，我們開發(fā)了一種方法來驗(yàn)證我們的失敗日志 - 至少在導(dǎo)致網(wǎng)絡(luò)分區(qū)的有限失敗情況下 - 通過檢查公開可用的traceroute和BGP記錄來驗(yàn)證失敗日志。

CAIDA Ark/Skitter traceroute

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

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

路由視圖BGP歸檔

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

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

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

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

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

分析

????????通過將前面章節(jié)中描述的方法應(yīng)用于CENIC系統(tǒng)日志和運(yùn)營公告電子郵件日志，我們獲得一個現(xiàn)代化規(guī)模的生產(chǎn)網(wǎng)絡(luò)的超過五十年的故障數(shù)據(jù)。 因此，我們有能力就實(shí)際網(wǎng)絡(luò)的運(yùn)作提出幾個基本問題。 特別是，我們認(rèn)為：

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

?鏈路故障的影響是什么？ 網(wǎng)絡(luò)是否適應(yīng)沒有顯著的服務(wù)中斷？

????????雖然我們對于結(jié)果的一般性沒有提出任何要求，但我們認(rèn)為對這一范圍和持續(xù)時間的研究在文獻(xiàn)中是前所未有的，而且我們的研究結(jié)果可能代表了一大類教育和研究網(wǎng)絡(luò)。

歷史一瞥

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

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

綜合統(tǒng)計(jì)

????????我們通過計(jì)算關(guān)于每個鏈路的故障頻率和持續(xù)時間的匯總統(tǒng)計(jì)來開始我們的分析，無論是單個故障事件還是累積鏈路停機(jī)時間。 表4顯示了每種分布的平均值，中位數(shù)和第95百分位數(shù)。 對于所有年度統(tǒng)計(jì)數(shù)據(jù)，我們排除了運(yùn)行時間少于30天的鏈接，因?yàn)樗鼈兊姆讲钆蛎洝?/p>

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

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

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

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

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

故障原因

????????現(xiàn)在我們已經(jīng)量化了發(fā)生故障的頻率，我們將注意力轉(zhuǎn)向其原因。 我們考慮特定類型的鏈接是否更有可能失敗，然后檢查運(yùn)營商明確指責(zé)的情況。

鏈路類型

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

標(biāo)記原因

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

????????表5提供了關(guān)于每個類別的單個故障事件持續(xù)時間的一些基本統(tǒng)計(jì)數(shù)據(jù)。 大多數(shù)事件都很短，但硬件和停電的中位時間要長得多 - 超過20分鐘。 然而，幾乎所有的類別都有嚴(yán)重的尾巴，導(dǎo)致平均故障持續(xù)時間比中間值長一個數(shù)量級。

????????除了識別故障原因之外，管理員通知還會指出故障是否預(yù)計(jì)或“預(yù)定”。 管理員公告中發(fā)現(xiàn)的大多數(shù)故障事件都是按計(jì)劃進(jìn)行的，但大部分實(shí)際停機(jī)時間都可能歸因于意外故障，這可能是因?yàn)椴僮鲉T注意確保計(jì)劃停機(jī)時間盡可能有限。 實(shí)際上，計(jì)劃停電的中值時間不到5分鐘（未顯示）。 有趣的是，似乎在影響網(wǎng)絡(luò)運(yùn)行的事件發(fā)生之前，網(wǎng)絡(luò)運(yùn)營商往往不會通知外部實(shí)體。

故障影響

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

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

時間動態(tài)

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

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

結(jié)論

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。