用於故障測量的方法和裝置的製作方法

2023-04-30 16:32:36 1

專利名稱：用於故障測量的方法和裝置的製作方法
背景技術：
高可用性是支持諸如電話、視頻會議和在線事務處理之類應用的網際網路協議(IP)網絡和其它電信網絡中的關鍵系統需求。故障測量對於評估和提高網絡可用性很關鍵。大多數網際網路服務提供商(ISP)使用諸如基於網絡管理系統(NMS)的輪詢等自動化工具或者手動使用事故單(trouble ticket)資料庫進行故障測量。
兩種故障測量基準已被用於測量網絡故障網絡設備故障和用戶連接停機時間(downtime)。由於可量測性的限制，大多數系統僅提供到ISP的接入路由器程度的故障測量。接入路由器和用戶器件之間的任何故障測量和計算都不得不手動進行。隨著網絡變得更大，該過程變得冗長、耗時、易出錯並且代價高昂。
當前的故障測量方案也不能充分滿足對準確性、可量測性、性能、成本效率和易管理的需求。一個原因是從故障管理伺服器到用戶器件的端到端網絡監控在網絡路徑上引入了開銷，從而可量測性有限。從故障管理伺服器到用戶器件的多跳(hop)還降低了測量的準確性。例如，管理伺服器和用戶器件之間的一些失效可能不是由用戶連接故障引起的，而是由IP網絡中別處的故障引起的。基於故障管理伺服器的監控工具還需要伺服器來進行網絡可用性測量，並且還需要ISP更新或者替換現有的故障管理軟體。
幾種現有的管理信息庫(MIB)被用於對象運行/停機(up/down)狀態監控，所述現有的MIB包括網際網路工程任務組(IETF)接口MIB、IETF實體MIB和其它實體警告MIB。但是，這些MIB並不保持對就每個對象的失效計數和累積故障時間而言的故障數據的跟蹤，並且缺乏某些故障測量可能需要的數據存儲能力。
本發明解決了和現有技術相關聯的該問題和其它問題。

發明內容
一種故障測量系統(OMS)在網絡處理設備處監控並測量故障數據。故障數據可以被傳送到網絡管理系統或者其它相關分析工具，以得到故障信息。故障數據被存儲在開放訪問數據結構中，例如管理信息庫(MIB)，所述開放訪問數據結構允許為不同的過濾和相關分析工具輪詢故障數據或者提供故障數據的通知。OMS使故障測量處理自動化，並且與現有的故障測量系統相比更加準確、有效並且成本有效。
由下面本發明優選實施例的詳細說明和附圖，本發明的上述和其它目的、特徵和優點將變得更加清楚。


圖1是示出了使用故障測量系統(OMS)的網絡的圖。
圖2是示出了可由OMS檢測的不同故障中的一些的框圖。
圖3是示出了如何使用多層方案進行故障測量的框圖。
圖4是OMS的詳細框圖。
圖5示出了OMS中所使用的事件歷史表和對象故障表。
圖6示出了在OMS中如何使用配置表和配置文件。
圖7示出了如何由OMS處理命令的一個示例。
圖8示出了累積故障時間(AOT)如何用於故障測量。
圖9示出了累積失效次數(NAF)如何用於故障測量。
圖10示出了平均失效間隔時間(MTBF)和平均失效前時間(MTTF)是如何由OMS故障數據計算得到的。
圖11A和11B示出了如何區分本地故障和遠程故障。
圖12示出了故障數據是如何傳送到網絡管理系統(NMS)的。
圖13是示出了OMS如何進行路由器處理器-磁碟檢查點(checkpoint)操作的圖。
圖14是示出了OMS如何進行路由器處理器-路由器處理器檢查點操作的圖。
具體實施例方式
圖1示出了IP網絡10，IP網絡10包括位於不同網絡處理設備16中的一個或多個故障測量系統(OMS)15。在一個示例中，網絡處理設備16是接入路由器16A和16B、交換機或者核心路由器16C。但是，這些僅為示例，OMS15可以位於任何需要故障監控和測量的網絡設備中。網絡管理系統(NMS)12位於網絡10中的任何伺服器或者其它網絡處理設備，其處理由OMS15產生的故障數據。
所示出的接入路由器16A連接到用戶器件20和另一接入路由器16B。本例中的用戶器件20是路由器，但可以是用於將端點(未示出)連接到IP網絡10的任何設備。端點可以是任何個人計算機、區域網(LAN)、T1線路或者任何其它在IP網絡10上通信的設備或接口。
所示出的核心路由器16C耦合到接入路由器16D和16E。但是核心路由器16C代表組成IP網絡10部分的任何網絡處理設備。為簡單起見，路由器、核心路由器、交換機、接入路由器和其它網絡處理設備在下面被通稱為「路由器」或者「網絡處理設備」。
在一個示例中，OMS15選擇性地位於網絡處理設備16中，其中網絡處理設備16組成網絡10中的單一失效點(single point of failure)。單一失效點可以指包括使設備可在網絡10上通信的單個路徑的任何網絡處理設備、鏈路或者接口。例如，接入路由器16A可能是用戶器件20可用來接入網絡10的唯一設備。這樣，接入路由器16A可以被認為是用戶路由器20的單一失效點。
路由器16中的OMS15實施故障監控和測量。來自這些測量的故障數據然後被傳送到NMS12。NMS12然後對故障數據進行相關分析(correlation)，並且計算不同的故障統計和故障值。
圖2標識了由OMS15自動監控和測量的故障。這些不同類型的故障包括路由器處理器(RP)30失效。RP失效可以包括對處理器30的拒絕服務(DOS)攻擊22。這指的是下述情況在某段時間內處理器30被100％使用，從而導致對用戶請求拒絕服務的情況。OMS15還檢測可在網絡處理設備中運行的軟體進程的失效。
OMS15還可以檢測線路卡33中線路卡33的失效、一個或多個物理接口34的失效(第2層故障)或者一個或多個邏輯接口35的失效(第3層故障)。在一個示例中，邏輯接口35可以包括多個T1信道。OMS15還可以檢測路由器16和用戶器件20之間的鏈路36的失效，或者檢測路由器16和對等路由器39之間的鏈路36的失效。也可檢測多路復用機(MUX)、集線器或者交換機37的失效，或者MUX37和用戶器件20之間的鏈路38的失效。還可以檢測遠程用戶器件20的失效。
OMS15中的故障監控管理器40在本地監控這些不同的失效，並且存儲與該故障監控和測量相關聯的故障數據42。故障數據42可以由NMS12或者其它工具訪問，以進行進一步的相關分析和計算操作。
圖3示出了如何使用混合兩層方法來處理故障。第一層使用路由器16來自治地並且自動地進行本地故障監控、測量以及原始(raw)故障數據存儲。第二層(tier)包括路由器製造商工具78、第三方工具76和網絡管理系統(NMS)12，用於使用路由器16中的故障數據個別地或者組合地進行相關分析以及計算故障值。
故障管理信息庫(MIB)14提供由不同的過濾和相關分析工具76、78和NMS12對故障數據的開放訪問。工具76和78輸出的相關分析後的故障信息可以與NMS12結合使用以標識故障。在替代性實施例中，NMS12直接從路由器16接收原始故障數據，然後進行任何必要的過濾和相關分析操作。在另一實施例中，過濾和相關分析操作的一些或者全部是在路由器16本地或者另一工作站中進行的，然後被傳送到NMS12。
故障事件過濾操作可以儘可能地在故障事件源附近進行，以減少IP網絡中所需的處理開銷，以及減少在上面的相關分析層處所需的系統資源。例如，路由器16中的OMS15可以僅發送指示線路卡失效的一條通知，而不是發送和同一線路卡相關聯的許多邏輯接口的失效指示。故障數據被存儲於路由器16中，然後由NMS12或者其它工具輪詢。這避免了由於不可靠的網絡傳輸、鏈路故障或者鏈路擁塞導致某些數據丟失。
故障MIB14可以支持進行故障計算的不同工具76和78，所述故障計算例如平均失效間隔時間(MTBF)，平均修復時間(MTTR)和每個對象、設備或者網絡的可用性。故障MIB14還可以用於用戶服務級別協議(SLA)分析。
圖4A和4B示出了在路由器16內部運行的OMS15的不同的功能元件。故障測量44是從路由器系統日誌50、錯誤管理器(FM)52和路由器處理器30獲得的。故障測量44是根據命令行接口58上管理的配置數據62進行的。CLI命令和配置信息是從NMS12或者其它上層故障工具發送的。通過MIB56管理並且向NMS12中的一個或多個或者其它上層工具發送從故障測量44獲得的故障數據42。
故障測量44由故障監控管理器40來控制。配置數據62是通過CLI解析器60產生的。MIB56包括使用故障MIB14傳送的故障MIB數據42。
故障監控管理器40實施系統日誌消息過濾64和來自路由器作業系統(OS)74的第2層(L2)輪詢66，以及作業系統錯誤管理器68。故障監控管理器40還控制流量監控與第3層(L3)輪詢70以及用戶器件檢測器72。
故障MIB數據結構圖5更詳細地示出了圖4中先前示出的故障MIB14的一個示例。在一個示例中，在故障MIB14中使用對象故障表80和事件歷史表82。故障MIB14跟蹤就每個對象的累積故障時間(AOT)和累積失效數(NAF)而言的故障數據。
故障MIB14維持基於每個對象的故障信息，從而NMS12或者上層工具可以輪詢MIB14以查找感興趣對象的故障信息。監控對象的數目是可配置的，這取決於路由器存儲器的可用性和性能權衡考慮。表1.0更詳細地描述了兩個表80和82中的參數。
表1.0故障MIB數據結構



表2.0中圖示了對象故障表80的示例。作為示例，「FastEthernet0/0/0」接口對象當前在運行。該對象累積故障時間(AOT)為7分鐘。累積失效數(NAF)為2。
表2.0對象故障表

AOT累積故障時間NAF累積失效數對象故障表80的大小決定了所監控對象的數目。操作方可以基於應用需求和路由器資源(存儲器和CPU)限制來選擇對哪些對象和多少對象進行故障監控。例如，路由器可以具有10,000個用戶電路。操作方可能由於SLA需求或者路由器資源的限制而僅希望監控2,000個用戶電路。
事件歷史表82維持對象故障表中所標識的對象的故障事件歷史。事件歷史表82的大小是可以配置的，這取決於路由器存儲器的可用性和性能權衡考慮。表3.0示出了事件歷史表82的示例。表3.0中所示出的事件歷史表中所記錄的第一事件是在時刻13:28:05接口對象「serial3/0/0/1.0」關機。在此事件之前，接口處於「運行」狀態有525600分鐘的持續時間。
表3.0故障MIB中的事件歷史表

事件歷史表82是可選的，並且操作方可以確定是否需要維持該表，這取決於應用需求和路由器資源(存儲器和CPU)限制。
配置圖6示出了OMS是如何配置的。路由器16維持配置表92，其中表92不是由來自NMS12的配置文件86、操作方輸入90佔著，就是由用戶器件檢測器72佔著。也可以將配置表92從路由器16導出到NMS12。
表4.0描述了可用在配置表92中的參數的類型。
表4.0配置表參數定義

配置文件86可以由遠程配置下載88或者由操作方輸入90來創建。CLI解析器60解釋CLI命令和配置文件86，並且向配置表92寫入與表4.0中所示出的相類似的配置參數。
故障管理命令操作方輸入90被用於向故障監控管理器40發送命令。操作方輸入90被用於復位、添加、去除、使能、禁止和停止不同的故障操作。表5.0中描述了這些操作的示例列表。
表5.0故障管理命令

圖7示出了如何使用故障管理命令來控制OMS15的示例。下面所示出的一系列命令被從NMS12發送到路由器16中的OMS15。
(1)start-file config1.data；
(2)add IF2；(3)auto-discovery enable；(4)ping-enable all rate 60；(5)removeIF1；和(6)export config2.data在命令(1)中，start-file命令和配置文件86一起被發送到路由器16。配置文件86指引故障監控管理器40啟動監控接口IF1，並且使能遠程用戶路由器C1的監控持續60秒周期。配置文件86還向配置表92(圖6)添加用戶路由器C2，但是禁止測試路由器C2。
在命令(2)中，接口IF2被添加到配置表92，並且啟動監控接口IF2。命令(3)使能通過圖6中所示出的用戶器件檢測器72的auto-discovery。用戶器件檢測器72僅發現了連接到路由器16的遠程路由器設備C3和C4，並且將他們添加到配置表92。將對用戶路由器C3和C4的監控被置於禁止模式。下面進一步詳細描述Auto-discovery。
命令(4)啟動對所有用戶路由器C1、C2、C3和C4的ping操作。這使能了對先前被禁止的遠程路由器C2、C3和C4的ping操作。命令(5)從配置表92中去除作為監控條目的接口IF1。連接到IF1的遠程設備C1和C2作為監控條目也被從配置表92中去除。命令(6)向NMS12或者某些其它故障分析工具輸出配置文件86中的當前條目(config2.data)。這包括第2層和第3層、模式以及速率參數。
自動用戶器件檢測現再參考圖6，用戶器件檢測器72自動搜索連接到路由器16的網絡設備的當前配置。然後將所標識的配置寫入配置表92中。當執行故障監控管理器40時，故障監控管理器40試圖打開配置表92。如果配置表92不存在，則故障監控管理器40可以使用用戶器件檢測器72來搜索路由器16中所有的線路卡和接口，然後自動創建配置表92。用戶器件檢測器72還可以被用於補充配置表92中已經標識出的任何對象。當檢測器72位於核心路由器中時，檢測器72可以用來辨識其它被連接的核心路由器、交換機或者設備。
任何專有(proprietary)設備標識協議都可以用於檢測鄰近的用戶設備。如果沒有專有協議，則可以請求ping廣播來檢測鄰近的用戶設備。一旦用戶器件檢測器72向子網內的鄰接設備發送ping廣播請求消息，則接收到該請求的鄰近設備發回ping應答消息。如果ping應答消息的源地址是新的，則該地址將作為新的遠程用戶設備被存儲到配置表92中。這快速標識了鄰近設備中的變化，並且在更新後的靜態配置信息變為可從NMS操作方獲得之前就啟動監控用戶器件。
圖4和圖6中所示出的用戶器件檢測器72可以使用各種現有協議來標識鄰近設備。例如，Cisco發現協議(CDP)、地址解析協議(ARP)協議、網際網路控制消息協議(ICMP)或者追蹤路由(traceroute)可以被用於標識附接到路由器16上的設備的IP位址。CDP協議可用於Cisco設備，並且ping廣播可以用於非Cisco用戶假定器件。
第2層輪詢參考圖4和圖6，第2層(L2)輪詢功能66輪詢位於路由器16和用戶器件20之間的本地接口的第2層狀態。一個示例中的第2層故障是通過從系統日誌50收集UP/DOWN接口狀態信息來測量的。第2層連接性信息可由路由器作業系統74提供，所述第2層連接性信息例如是連接到接口的所有用戶器件20的鏈路狀態和協議狀態。
如果OS錯誤管理器(FM)68在系統上可用，則FM68可以檢測諸如「接口UP」或者「接口DOWN」的接口狀態。故障監控管理器40可以通過註冊接口ID來監控該接口狀態。當第2層輪詢已被註冊時，FM68報告接口的當前狀態。基於該狀態，L2接口被故障監控管理器310註冊為「接口UP」或者「接口DOWN」。
如果FM68不可用，則故障監控管理器40使用它自己的第2層輪詢66。故障監控管理器40在時間調度表上註冊對象，並且該調度表基於特定輪詢時間段產生輪詢事件。除了監控第2層接口狀態外，第2層輪詢66還可以通過註冊線路卡33的槽號來測量線路卡失效事件。
第3層輪詢除了檢查第2層鏈路狀態外，諸如「輸入速率」、「輸出速率」、「輸出隊列分組丟失」和「輸入隊列分組丟失」的第3層(L3)流量可以可選地由流量監控與L3輪詢功能70來監控。雖然接口的第2層鏈路狀態可以是「UP」，但是在延長的時間段內沒有流量交換，或者用戶設備的分組丟失，這可以指示路徑失效。
可以進行兩種級別的第3層測試。第一級別標識輸入速率、輸入速率和輸出隊列分組丟失信息，這些信息通常是由路由器作業系統74跟蹤的。但是，較長的休眠狀態可能導致低分組速率。因而，對於懷疑具有第3層故障的用戶設備，在輪詢功能70中使用諸如活動探測(ping)的額外檢測機制。在活動探測期間，OMS15向連接到路由器16的設備發送測試分組。在圖11A中更詳細地示出了這種情況。
配置文件86(圖6)指定第3層輪詢是否發生以及向用戶器件20發送ping測試分組的速率。例如，無論OS74指示哪裡在某一特定時間段內鏈路上沒有活動，都可以發送ping分組。或者，可以周期性地從接入路由器16向用戶器件20發送測試分組。故障監控管理器40監控本地鏈路，以確定用戶器件20是否發回測試分組。
故障監控示例故障監控的目標被稱作「對象」，這是對路由器16本地的物理與邏輯接口、在路由器16、用戶器件20和對等路由器39(圖2)中間的邏輯鏈路、遠程接口、線路卡、路由器處理器或者軟體進程的一般概括。
由故障監控管理器40從路由器16的內部對下述對象狀態進行監控即，運行/停機狀態、從啟動測量起的累積故障時間(AOT)以及從啟動測量起的累積失效數(NAF)。NMS12或者更高層工具78或76(圖3)然後使用此原始數據導出和計算諸如對象的平均失效間隔時間(MTBF)、平均修復時間(MTTR)和可用性的信息。下面提供了幾個應用示例。
參考圖8，故障監控管理器40測量在從時刻T1到時刻T2的某時間段內對象的運行或停機狀態。在此示例中，時間段為1,400,000分鐘。在此持續時間期間，故障監控管理器40自動確定所監控對象的任何失效的持續時間。由故障監控管理器40導出修復時間(TTR)、失效間隔時間(RBF)以及失效前時間(TTF)。
在圖8的示例中，檢測出對象i的第一故障持續了10分鐘，檢測出對象i的第二故障持續了4分鐘。路由器16中的故障監控管理器40計算AOTi＝10分鐘+4分鐘＝14分鐘。AOT信息被傳送到NMS12或者更高層工具，NMS12或者更高層工具然後計算對象可用性(Ai)以及每百萬次缺陷數(DPM)。例如，對於起始時刻為T1而終止時刻為T2，可用性Ai＝1-AOTi/(T2-T1)＝1-14/1,400,000＝99.999％。DPMi＝[AOTi/(T2-T1)]×106＝10DPM。
存在兩種不同的故障監控管理器40可以自動計算AOTi的途徑。在一種方案中，每次失效發生時，故障監控管理器40從路由器作業系統74(圖4)接收中斷，而當對象回到運行態(back up)時接收另一中斷。在第二方案中，故障監控管理器40不斷地輪詢對象狀態，以在每個輪詢周期跟蹤對象是運行還是停機。
圖9示出了如何由NMS12導出對象i的平均恢復時間(MTTR)的一個示例。故障監控管理器40在測量間隔100期間計數累積失效數(NAFi)。AOTi和NAFi值被傳送到NMS12或者更高層工具。NMS12或者更高層工具然後計算MTTRi＝AOTi/NAFi＝14/2＝7分鐘。
圖10示出了NMS12或者更高層工具如何使用AOT和NAF來從NAFi信息確定對象i的平均失效間隔時間(MTBF)和平均恢復時間(MTTF)，其中MTBFi＝(T2-T1)/NAFi；以及MTTFi＝MTBFi-MTTRi。
賣方或網絡處理器件或者網絡處理器器件的操作方可能被要求籤訂服務水平協議(SLA)，以確保網絡器件在某百分比時間內是可操作的。圖11A示出了由故障監控管理器40產生的AOT信息是如何用於確定器件是否滿足SLA協議的以及本地或遠程器件是否對故障負有責任的。
在圖11A中，OMS15監控路由器16中的本地接口對象34，並且還監控位於遠程設備102處的對應遠程接口對象17。遠程設備102可以是用戶路由器、對等路由器或者其它網絡處理設備。由單個鏈路19連接路由器16和遠程設備102。
在一個示例中，可使用對物理接口的狀態信息的第2層輪詢來監控本地接口對象34。在此示例中，可通過OMS15向遠程設備102發送測試分組104來監控遠程接口17和遠程設備102。OMS15然後監控測試分組104向路由器16的返回。圖11B中示出了本地接口對象34和其對應的遠程接口對象17的運行/停機期間。
NMS12對來自兩個對象34和17的所測量AOT進行相關分析，並且確定是否存在直接和鏈路19的遠程端相關聯的任何停機時間。在此示例中，本地IF對象34的AOT34＝30分鐘，遠程IF對象17的AOT17＝45分鐘。在接入路由器16和遠程設備102之間僅存在一條物理鏈路19。這意味著比IF34的30分鐘故障時間超出的任何故障時間都很可能是由鏈路19或者遠程設備102上的故障引起的。從而，NMS12確定遠程設備102或者鏈路19的AOT＝(遠程IF對象17的AOT)-(本地IF對象34的AOT)＝15分鐘。
應該理解，圖11A中的IF34可以實際上具有耦合在IF34和不同的遠程設備之間的許多邏輯鏈路。OMS15可以監控存在於路由器16中的每個邏輯接口或者鏈路的狀態。通過僅在本地ping路由器16和其鄰近之間的測試分組104，在網絡帶寬上的負擔少得多。
對象運行/停機事件的潛在原因可以被記入日誌並且和事件相關聯。這樣的原因可以包括例如線上插拔(OIR)和目的地不可到達。
事件過濾事件過濾的簡單形式可以在路由器16之內執行，以抑制對NMS12的「事件風暴(event storm)」，以及減少由於事件風暴引起的網絡/NMS資源消耗。事件風暴和事件風暴過濾的一個示例可以和線路卡失效有關。故障監控管理器40可以識別相同線路卡的所有故障事件，並且向NMS12僅報告一個LC失效事件，而不是將和相同線路卡相關聯的成百上千個信道接口失效事件通知NMS12。這樣，OMS15僅發送根本原因通知，而不是發送許多失效。如果需要將根本原因事件報告給NMS12，則將不進行事件過濾。事件過濾可以是基於規則的或者是由個體操作方定義的。
解析度解析度指的是故障測量時間的粒度。當採用基於輪詢的測量方法時，故障時間解析度和故障監控頻率之間存在關係。例如，給定用戶故障時間解析度為一分鐘，則故障監控管理器40可以每30秒輪詢一次。通常，故障監控的輪詢速率應該是故障時間解析度頻率的兩倍。但是，取決於對象和期望的解析度，可以選擇不同的輪詢速率。
ping用戶或者對等路由器接口如上面圖11A中所述，OMS15可以提供ping功能(發送測試分組)，以監控諸如用戶路由器或對等路由器的遠程設備102和測量路由器16之間的物理和邏輯鏈路的故障。可基於每個對象來配置ping功能，從而用戶能夠基於應用需要來使能/禁止ping。
ping功能的可配置性可以依賴於幾個因素。首先，IP網際網路控制消息協議(ICMP)ping需要使用要被ping的遠程接口的IP位址。但是，該地址可能並不總是輕易可得的，或者可能是隨時間變化的。此外，由於遠程設備可能出於安全和/或性能的考慮而關閉發現協議，所以遠程設備地址可能不能經由這樣的自動發現協議獲得。對很多遠程接口的頻繁ping操作也可能導致路由器性能降級。
為了避免這些問題，可以對被認為是對用戶SLA很關鍵的少數選定遠程設備應用ping操作。在這些情況下，OMS15配置使用戶能夠如表4.0所示基於每個對象選取ping功能。
當ping功能被使能時，可以執行某些監控機制和方案來降低開銷。這些基本序列中的一些包括檢查線路卡狀態、檢查物理鏈路完整性、檢查分組流統計。然後，如果需要的話，則ping遠程設備處的遠程接口。利用此監控序列，ping可以變成僅當最先三個測量步驟不能完全令人滿意時的最後動作。
故障數據收集參考圖12，OMS15為NMS12或者上層工具78或76(圖3)收集測量後的故障數據108。OMS15可以提供不同的數據收集功能，例如基於事件的通知、本地存儲和數據訪問。
OMS15可以經由基於SNMP的「推(push)」機制114將故障事件110和相關聯的故障數據108一起通知給NMS12。SNMP可以提供兩種基本的通知功能，「陷阱(trap)」和「告知(inform)」114。當然也可以使用其它類型的通知方案。陷阱和告知通知功能114都從嵌入到路由器16中的SNMP代理112向NMS12發送事件。陷阱功能依賴於可能不可靠的用戶數據報協議(UDP)傳輸。告知功能通過簡單請求-應答協議以可靠的方式使用UDP。
通過簡單網絡管理協議(SNMP)和MIB14，NMS12不是通過來自路由器16的事件通知就是通過對路由器16的數據訪問來收集原始故障數據。利用事件通知機制，NMS12可以在故障事件發生後就接收故障數據。利用數據訪問機制，NMS12時常讀取存儲在路由器16中的故障數據108。換言之，不是由路由器16向NMS12推出故障數據108，就是由NMS12從路由器16中拉取故障數據108。
NMS12時常經由基於SNMP的「拉(pull)」機制116訪問或者輪詢存儲於路由器16中的測量後的故障數據108。SNMP提供兩種基本的收集MIB數據的訪問功能，「取(get)」和「大量取(getbulk)」。取功能檢索一條數據項，而大量取功能檢索數據項的集合。
測量路由器崩潰參考圖13，OMS15可以測量「軟(soft)」路由器崩潰和「硬(hard)」路由器崩潰的時刻和持續時間。整個路由器120可能在某些失效模式下崩潰。「軟」路由器崩潰指允許路由器在路由器完全崩潰前產生崩潰信息的路由器失效類型，例如軟體崩潰或者奇偶校驗錯引起的崩潰。產生的該軟體崩潰信息可以具有崩潰事件的時間戳，並且被存儲在非易失存儲器124中。當系統重新啟動時，崩潰信息中的時間戳可以用來計算路由器故障持續時間。「硬」路由器崩潰是指崩潰時路由器沒有時間產生崩潰信息的路由器崩潰。硬崩潰的一個示例是由於突然斷電導致的瞬時路由器停機。捕獲硬崩潰信息的一種方法是採用永久存儲，例如非易失存儲器124或者磁碟存儲器126，其本地留駐於測量路由器120中。
利用這種方法，OMS15周期性地向永久存儲器124或126中的固定位置寫系統時間。例如，每分鐘寫一次。當路由器120從崩潰中重新啟動時，OMS15從永久存儲設備124或126讀取時間戳。則路由器故障時刻位於蓋戳時刻後的一分鐘之內。故障持續時間是蓋戳時刻和當前系統時間之間的間隔。
這排除了另一網絡處理設備不得不周期性地ping路由器120以及使用網絡帶寬。由於內部產生的時間戳更準確地代表了路由器120的當前操作時間，所以該方法也比ping更準確。
測量硬崩潰的另一方法是讓一個或者多個外部設備周期性地輪詢路由器120。例如，NMS12(圖1)或者(一個或多個)鄰近路由器可以每分鐘都ping被監控的路由器120，以確定路由器120的可用性。
本地存儲故障信息也可以被存儲在鄰近路由器處或路由器120內的冗餘存儲器124或者126中，以避免單一存儲失效點。除了路由器120和路由器處理器對象121外的所有被監控對象的故障數據可以被存儲在易失存儲器122中，並且由NMS周期性地輪詢。
當存儲空間和運行時間(run-time)性能允許時，包括路由器120和路由器處理器對象121在內的所有被監控對象的故障數據可以被存儲在永久非易失存儲器124或盤126中。
在路由器120中本地存儲故障信息增加了信息的可靠性，並且防止當網絡的其它部分中出現故障或者鏈路擁塞時數據丟失。使用永久存儲器124或126存儲故障信息也使得能夠測量路由器崩潰。
當易失存儲器122被用於故障信息存儲時，NMS或者其它設備可以周期性地或在要求時輪詢來自路由器120的故障數據，以避免由於易失存儲器122或者路由器120失效而導致故障信息丟失。OMS15可以為所有被監控對象使用永久存儲器124或者126，這取決於大小和性能開銷限制。雙路由器處理器檢查點參考圖14，一些路由器120可以用雙處理器121A和121B來配置。在故障數據更新期間，OMS15可以將來自活動路由器處理器的存儲器122A或者124A(永久的和非永久的)的故障數據複製到備用路由器處理器121B的備用存儲器122B或者124B(永久的和非永久的)。
這允許OMS15在從活動處理器121A切換到備用處理器121B之後繼續故障測量功能。這還允許即使包含故障數據的處理器121A或者121B之一被物理替換，路由器120也保持路由器崩潰信息。
故障測量差距(gap)OMS15捕獲路由器崩潰並防止故障數據丟失，以避免故障測量差距。由進行故障測量的對象的類型支配可能的故障測量差距。例如，路由器處理器(RP)對象與其它對象。還由路由器崩潰的類型(軟與硬)和故障數據存儲的類型(易失的與永久的—非易失存儲器或磁碟)來支配測量差距。表6總結了用於捕獲路由器崩潰和防止測量差距的解決方案。
表6.捕獲路由器崩潰的故障


即使使用永久存儲設備，所存儲的故障數據也可能潛在地由於存儲設備的替換或者單一失效點而丟失，冗餘是解決此問題的一種方法。一些潛在的冗餘解決方案包括從路由器處理器上的存儲器到本地盤(圖13)的數據檢查點操作、從活動路由器處理器上的存儲器到備用路由器處理器上的存儲器(圖14)的數據檢查點操作、或者從路由器120到鄰近路由器的數據檢查點操作。
上述系統可以使用專用的處理器系統、微控制器、可編程邏輯設備或者微處理器，這些器件執行操作的一些或全部。上述操作的一些可用軟體實現，而其它操作可用硬體實現。
為方便起見，操作被描述為各種互連的功能塊或者不同的軟體模塊。但是，這並不是必需的，可以存在下述情況即這些功能塊或者模塊被等同地聚集到具有不清楚界限的單個邏輯設備、程序或者操作中。無論如何，功能塊和軟體模塊或者靈活接口的特徵可以以硬體或者軟體形式由自己實現，或者和其它操作結合來實現。
在已經以優選實施例描述和說明了本發明的原理後，應該很清楚，可以在安排和細節上修改本發明，而不背離這樣的原理。所有修改和改變都落入權利要求的精神和範圍內。
權利要求
1.一種檢測故障的方法，包括使用位於網絡處理設備本地中的故障測量系統來自動測量故障。
2.如權利要求1所述的方法，包括使用所述故障測量系統來測量直接附接到所述網絡處理設備的設備的故障。
3.如權利要求1所述的方法，包括測量所述網絡處理設備中的本地對象的故障。
4.如權利要求1所述的方法，包括將故障數據本地存儲於所述網絡處理設備中。
5.如權利要求4所述的方法，包括使用永久存儲設備來存儲所述故障數據。
6.如權利要求4所述的方法，包括將所述故障數據存儲於管理信息庫中。
7.如權利要求6所述的方法，包括使用簡單網絡管理協議來傳送所述管理信息庫中的所述故障數據。
8.如權利要求1所述的方法，包括向網絡管理系統或者上層工具傳送所述故障數據以進行相關分析。
9.如權利要求1所述的方法，包括利用所述故障測量系統輪詢找到第2層故障。
10.如權利要求1所述的方法，包括利用所述故障測量系統輪詢找到第3層故障。
11.如權利要求1所述的方法，包括自動發現被連接到所述本地網絡處理設備的設備，以及自動輪詢找到與所述被發現的設備相關聯的故障。
12.如權利要求1所述的方法，包括在所述網絡處理設備處從網絡管理系統接收配置數據；以及根據所接收的配置數據，利用所述故障測量系統自動監控故障。
13.如權利要求12所述的方法，包括將所述配置數據保持在位於所述網絡處理設備中的配置表中。
14.如權利要求1所述的方法，包括利用所述故障測量系統來過濾本地故障數據。
15.一種測量網絡中故障的方法，包括標識所述網絡中的單一失效點設備；選擇性地將故障測量系統定位於所標識的單一失效點設備中；以及使用所述故障測量系統自動地本地測試所選擇的單一失效點設備中的故障。
16.如權利要求15所述的方法，包括將所述故障的故障數據存儲於所標識的設備中；用一個或多個相關分析系統對所述故障數據進行相關分析；以及根據所述相關分析後的故障數據來標識故障統計。
17.如權利要求16所述的方法，其中一個或多個所述相關分析系統位於遠離所標識設備的網絡管理系統上。
18.如權利要求15所述的方法，包括使用所述故障測量系統輪詢找到第2層故障，以及根據所述第2層輪詢的結果輪詢找到第3層故障。
19.如權利要求18所述的方法，包括使用所述輪詢後的第2層和第3層故障的組合，來對所標識的設備本地的本地故障和與連接到所述所標識的設備的鏈路或者設備相關聯的遠程故障進行區分。
20.一種標識故障的方法，包括在網絡處理設備處本地監控與所述網絡處理設備相關聯的對象的流量統計信息；以及使用所述流量統計來標識所述對象的故障。
21.如權利要求20所述的方法，包括監控與所述網絡處理設備相關聯的對象的鏈路狀態，以及根據所監控的流量統計和所監控的鏈路狀態來檢測故障。
22.如權利要求21所述的方法，包括ping被連接到所述網絡處理設備的遠程設備；監控所述ping的結果；以及根據所監控的流量統計、所監控的鏈路狀態和所監控的ping來檢測故障。
23.如權利要求20所述的方法，包括監控所述網絡處理設備中處理器的利用情況，以及使用所監控的利用情況來標識所述網絡處理設備中的拒絕服務狀況。
24.一種標識故障的方法，包括輪詢找到網絡處理設備處的本地對象的本地故障；輪詢找到被連接到所述網絡處理設備的遠程對象的遠程故障；以及將所述本地故障和所述遠程故障相比較，以對由所述本地對象引起的故障和由所述遠程對象引起的故障進行區分。
25.如權利要求24所述的方法，包括通過利用測試分組ping所述遠程對象來輪詢找到所述遠程故障。
26.如權利要求24所述的方法，包括導出所述本地對象的累積故障時間；導出所述遠程對象的累積故障時間；以及通過將所述本地對象的所述累積故障時間和所述遠程對象的所述累積故障時間進行比較，來區分本地對象故障和遠程對象故障。
27.如權利要求24所述的方法，其中所述本地對象包括本地物理與邏輯接口、本地線路卡或者本地路由器處理器。
28.如權利要求24所述的方法，其中所述遠程對象包括遠程對等路由器或者遠程用戶器件。
29.一種標識故障的方法，包括在網絡處理設備處本地標識故障事件；以及向網絡管理伺服器或者相關分析工具提供所述故障事件，以進行故障分析。
30.如權利要求29所述的方法，包括至少在所述故障事件的故障數據被提供給所述網絡管理伺服器或者相關分析工具之前，將所述故障數據本地存儲在所述網絡處理設備中。
31.如權利要求30所述的方法，包括將所述故障數據存儲在故障管理信息庫中。
32.如權利要求29所述的方法，包括根據從所述網絡管理伺服器發送的配置文件來輪詢找到所述故障事件。
33.如權利要求32所述的方法，包括根據從所述網絡管理伺服器發送的命令來修改在所述網絡設備中監控哪些故障事件。
34.如權利要求29所述的方法，包括將對象故障表存儲在所述網絡處理設備中，所述對象故障表標識對哪個對象輪詢以找到故障。
35.如權利要求34所述的方法，包括自動發現被連接到所述網絡處理設備的遠程設備；以及用所發現的遠程設備來自動更新所述對象故障表。
36.如權利要求29所述的方法，包括過濾在所述網絡處理設備處標識的所述故障事件；以及向所述網絡管理系統或者相關分析工具發送所述過濾後的事件。
37.一種用於網絡故障監控的方法，包括監控與被連接到網絡處理設備的設備的配置相關聯的故障；自動發現被連接到所述網絡處理設備的設備的新配置；以及根據設備的所述新配置動態更新故障監控。
38.如權利要求37所述的方法，包括使用思科發現協議、地址解析協議或者網際網路控制消息協議來自動發現設備的所述新配置。
39.如權利要求37所述的方法，包括存儲用於標識連接到所述網絡處理設備的設備的配置表；以及用設備的所述新配置來自動更新所述配置表。
40.一種網絡處理設備，包括處理器，所述處理器被配置成管理與所述網絡處理設備相關聯的對象的故障監控。
41.如權利要求40所述的網絡處理設備，包括用於存儲所監控對象的故障數據的存儲器。
42.如權利要求41所述的網絡處理設備，其中所述存儲器包括當所述網絡處理設備掉電時永久存儲故障監控數據的永久存儲裝置。
43.如權利要求40所述的網絡處理設備，其中所述故障數據被存儲在管理信息庫中。
44.如權利要求41所述的網絡處理設備，其中所述處理器通過監控在所述網絡處理設備內的本地對象來監控故障。
45.如權利要求44所述的網絡處理設備，其中所述本地對象與在所述網絡處理設備內部的路由器處理器、線路卡或者軟體程序相關聯。
46.如權利要求40所述的網絡處理器，其中所述處理器根據故障監控結果啟動對被連接到到所述網絡處理設備的鄰近設備的測試分組ping操作。
47.如權利要求40所述的網絡處理設備，其中所述處理器自動發現耦合到所述網絡處理設備的對象，以及自動輪詢找到所發現對象的故障。
48.如權利要求40所述的網絡處理設備，其中所述處理器確定所監控對象的累積故障時間或累積失效數。
49.如權利要求40所述的網絡處理設備，包括備份處理器和相關聯的備份存儲器，所述處理器將來自故障監控的數據存儲在所述備份存儲器中。
50.一種測量故障的方法，包括在網絡處理設備處本地監控故障；利用本地網絡處理設備過濾所監控的故障；以及向故障相關分析系統發送所述過濾後的故障。
51.如權利要求50所述的方法，包括從所監控的故障計算累積故障時間故障參數或累積失效數故障參數，以及向所述相關分析系統發送所述累積故障時間或累積失效數。
52.如權利要求51所述的方法，包括利用所述相關分析系統從所述累積故障時間或累積失效數參數導出平均故障間隔時間或者平均修復時間值。
53.如權利要求50所述的方法，包括標識與相同線路卡相關聯的不同故障；將所述不同的線路卡故障過濾成單個線路卡故障指示；以及向所述故障相關分析系統發送所述單個線路卡故障指示。
54.如權利要求50所述的方法，包括從系統日誌文件過濾所監控的故障。
55.一種用於測量網絡處理設備的故障的方法，包括產生所述網絡處理設備的時間戳；將所述時間戳本地存儲在所述網絡處理設備中；周期性地用所述網絡處理設備的最新近的時間戳更新所存儲的時間戳；在網絡處理設備故障期間保持所述最新近的所存儲時間戳；以及使用所保持的最新近的所存儲時間戳來確定所述網絡處理設備的故障時間。
56.如權利要求55所述的方法，包括標識當所述網絡處理設備已經從所述故障恢復時的系統運行時間；以及將所存儲時間戳和所述系統運行時間相比較，以確定所述故障時間。
57.如權利要求55所述的方法，包括周期性地將所述最新近的時間戳存儲在永久存儲器中。
58.如權利要求55所述的方法，其中所述故障包括所述網絡處理設備掉電。
59.如權利要求55所述的方法，其中存儲於所述網絡處理設備中的所述時間戳大約每分鐘更新一次。
60.一種用於存儲用來檢測故障的計算機可執行代碼的電子存儲介質，所述計算機可執行代碼包括用於使用位於網絡處理設備本地中的故障測量系統來自動測量故障的代碼。
61.如權利要求60所述的電子存儲介質，包括用於將故障數據本地存儲在所述網絡處理設備中的代碼。
62.如權利要求60所述的電子存儲介質，包括用於將所述故障數據傳送到網絡管理系統或者上層工具以進行相關分析的代碼。
63.如權利要求60所述的電子存儲介質，包括用於自動發現被連接到所述本地網絡處理設備的設備以及自動輪詢找到與所發現的設備相關聯的故障的代碼。
64.如權利要求60所述的電子存儲介質，包括用於在所述網絡處理設備處從網絡管理系統接收配置數據的代碼；以及用於根據所接收的配置數據利用所述故障測量系統自動監控故障的代碼。
65.一種用於檢測故障的系統，包括用於使用位於網絡處理設備本地中的故障測量系統來自動測量故障的裝置。
66.如權利要求65所述的系統，包括用於將故障數據本地存儲在所述網絡處理設備中的裝置。
67.如權利要求65所述的系統，包括用於將所述故障數據傳送到網絡管理系統或上層工具以進行相關分析的裝置。
68.如權利要求65所述的系統，包括用於自動發現被連接到本地網絡處理設備的設備以及自動輪詢找到與所發現設備相關聯的故障的裝置。
69.如權利要求65所述的系統，包括用於在所述網絡處理設備處從網絡管理系統接收配置數據的裝置；以及用於根據所接收的配置數據利用所述故障測量系統自動監控故障的裝置。
全文摘要
一種故障測量系統(OMS)在網絡處理設備處監控並且測量故障數據。故障數據可以被存儲在設備中，並且可以被傳送到網絡管理系統(NMS)或者其它相關分析工具以導出故障信息。OMS使故障測量處理自動化，並且與現有故障測量系統相比更加準確、有效和成本有效。
文檔編號H04L12/24GK1672362SQ03818320
公開日2005年9月21日 申請日期2003年7月30日 優先權日2002年7月30日
發明者黃建東, 宋瑟君, 馬達夫·馬拉泰 申請人:思科技術公司