??? 摘? 要:? 分析了網絡中故障的傳播原理，在此基礎上提出了一種使用移動代理的三層網絡故障管理體系，對網絡故障管理中關聯問題的難度進行了有效的分解。根據網絡故障管理體系的要求設計了不同功能的移動代理，及該體系下它們的工作交互過程。該體系充分利用了現有網絡條件，滿足了現代網管對于故障管理的及時性、自學習性的要求，減輕了網絡負載。此外，按照這種方法建立起來的網絡故障管理系統具有一定的通用性和靈活性，能夠適應不同的網絡和網絡的變化，最后通過實驗證明了系統的部分優越性。?

??? 關鍵詞: 網絡故障； 移動代理； 代理協作

?

??? 隨著計算機網絡的迅速發展和廣泛應用，對網絡管理特別是網絡故障管理的要求也越來越高，傳統的集中式網絡管理技術越來越難以適應網絡管理功能的需要，充分利用現有網絡的智能性進行分布式的網絡管理成為現今研究的重點。本文將移動代理技術^[1]與網絡故障管理結合起來，探討解決網絡故障管理的方法。?

??? 移動代理的主要特點是智能性和移動性。它是一個能夠自主地在異構網絡中遷移并協作的執行任務的程序實體^[2]。它能夠自行決定在網絡的各個節點之間移動，代表其他實體（人或其他代理）進行工作，它能夠自行選擇執行的時間和地點，并可以根據具體情況中斷當前自身的執行，移動至另一設備恢復運行，并及時地將有關的結果返回。移動代理的移動性使得程序的執行能夠盡可能地靠近數據源，降低了網絡的通信開銷，節省了帶寬，平衡負載，加快任務的執行^[3]，從而提高分布式系統的處理效率。智能性使得移動代理能夠充分利用現今越來越強的節點計算能力，并能將人工智能技術引入移動代理，以便更充分地完成管理任務^[4]。?

1 基于移動代理的網絡故障管理模型?

1.1 網絡故障的傳播過程?

??? 當網絡中發生故障時，故障會沿著橫向和縱向兩個方向傳播。橫向傳播是指故障沿著物理的或是邏輯的連接在設備之間水平的傳播，例如與發生故障的設備相連的設備感知到故障后也發生告警事件，這種故障甚至會在子網與子網之間傳播。縱向傳播主要是指故障在一個設備內部沿著協議棧從低層向高層傳播，低層協議實體的不正常狀態可能引起高層協議實體狀態的不正常。?

??? 基于這種分析，將網絡劃分為4個層次的網絡對象：全網、子網、網絡元素NE(Network Element )和原子對象。將被管網絡作為全網，而一個被管網絡可能包括多個子網，子網的類型可以是總線網、令牌環或星形網等。每個子網由一個或多個NE組成，這些NE的類型可以是主機、路由器、集線器、交換機或一段物理鏈路等。而每一個NE也可以表示為由多個原子對象組成的集合，例如可以將一臺路由器表示成由若干IP對象和若干接口對象組成的集合。網絡故障檢測的目標就是識別出作為網絡故障根本原因的原子對象。?

??? 網絡故障傳播過程如圖1所示。當某個原子對象發生故障時，例如某接口不可用，會使得包含該接口的網絡設備無法進行某種數據的交換，進而影響周圍網絡元素的正常工作，使得整個子網出現異常，如果故障得不到解決，整個網絡都可能受到影響。?

?

?

1.2 系統模型設計?

??? 基于以上分析，本文設計了一種集中式與分布式相結合的、分層的、基于智能代理和移動代理的網絡故障管理模型，并按照故障傳播順序將這個模型分為三層，系統模型設計如圖2所示。?

?

?

??? (1) 網絡元素端（NE端）。由于故障會在NE端進行縱向傳播，所以移動代理在NE端先建立各層常用協議及協議間的依賴模型，根據網絡故障及協議實體間依賴關系的不確定性的特點，選用適用于不確定性推理的貝葉斯網絡推理模型。當出現故障時使用移動代理進行NE端的故障縱向關聯，解決規則庫中匹配的故障，并將不匹配的故障上報。?

??? (2) 子網端。由于故障的橫向傳播，在進行告警關聯時如果能夠只考慮子網內部與其他子網連接點產生的告警，而不考慮其他子網產生的告警，就可以大大減少告警信息的冗余程度。在子網內部與其他子網的連接點上設置移動代理，對NE端移動代理發回的報告進行分析，將事件的關聯在事件發出者所在的子網內部進行。告警事件產生時，首先判斷其產生者所在的子網，然后只在其內部進行基于規則的事件關聯。對于產生的故障在子網連接點的情況，即將事件在其所連接的所有子網內進行關聯，并與各子網規則庫中的規則進行匹配判斷，如果判斷成功，則表明故障發生在該子網。?

??? (3) 全網端。有一些涉及到全網的告警事件則由各子網代理匯報到全網網絡管理站。為了實現實時性和自學習性，網管站采用基于規則的推理與基于案例的推理相結合的方式進行故障告警的關聯。網管中心將子網智能代理上報上來的告警事件進行基于規則的推理，當上報事件與規則不匹配時，則產生異常推斷，并進入基于案例的推理。在基于案例的推理算法中有一個檢索模塊和一個修改模塊。檢索模塊負責在規則/案例庫中尋找與問題最為相似的案例，然后由修改模塊對該實例作適當的修正。一旦修正結果將問題解決，則新的實例將加入到事例庫中，以備以后的應用。?

2 故障管理模型的移動代理設計?

2.1 代理功能設計?

??? 依據一般的故障管理系統應該包含的基本功能設置代理：?

??? (1)故障發現代理。故障發現代理主動地或被動地收集網絡上的各種事件，并識別出其中與網絡和故障相關的內容，確定是否存在故障。?

??? (2)過濾關聯代理。過濾關聯代理將告警過濾與告警關聯結合起來。過濾關聯代理是用上文介紹的一些過濾關聯技術將非主要的、非根本的告警濾除，保留主要的根本原因的告警。例如被派往NE端進行網絡縱向關聯的移動代理，需要將NE端的協議依賴體系帶入到貝葉斯網絡推理中進行故障關聯，找出原子故障。過濾關聯代理可以設置成基于RBR技術的代理，也可以設置成基于貝葉斯推理等技術的代理。?

??? (3)故障分析代理。故障分析代理負責將過濾關聯后的告警進行分析，判斷子網歸屬，查找規則庫匹配，并派出故障解決代理。當信息庫中沒有相關的告警時，生成如連通性測試代理之類的從代理找出故障的可能位置和原因，形成案例，然后激活故障告知代理更新案例庫。?

??? (4）故障告知代理。故障告知代理負責將告警關聯分析的結果上報給管理者并更新信息庫。?

??? (5）故障解決代理。當故障原因確定后，派遣相應的故障解決代理解決故障。?

2.2 代理協作模型?

??? 圖3給出了本文設計的多個代理之間協作進行故障關聯的交互圖。?

?

?

??? 如圖3所示，故障發現代理一直在NE端進行故障采集工作。當發現異常后，激活過濾關聯代理，進行預定義規則的過濾操作以后，視情況激活基于貝葉斯的關聯從代理或基于規則的關聯從代理；并將關聯結果返回給過濾關聯代理，經過過濾關聯代理的簡單處理后，將結果送到子網端的故障分析代理，子網端的代理在將關聯結果進行子網判斷后，查找規則庫。若規則庫中沒有匹配的規則時，則激活網絡連通性測試之類的從代理，找出故障可能發生的時間、地點等信息，形成案例。并將子網關聯結果上報給網管端的故障分析代理，網管端的故障分析代理從全網的角度對上報故障進行分析，查找規則庫中的匹配對象，若沒有匹配規則，則將最后關聯結果以日志的形式上報給網絡管理員，并更新案例庫。其中故障數據庫是案例庫和規則庫的統稱。?

3 實驗?

??? 該實驗以對網絡掃描的告警為例，對系統的效果進行檢測。?

??? 圖4給出了實驗使用的網絡拓撲圖，假設網絡存在一個共享的瓶頸連接。一些用戶在進行正常的網絡業務，網絡攻擊者對結點C進行結點掃描，為了隱蔽自己，利用s臺主機頻繁向結點C發送ping命令進行掃描，在B結點派遣移動代理，實驗中取Ftp、UDP業務主機數m為7，s為5。設定n=15為1min內觀測到的echo request數據包引起告警的門限值，采樣間隔為1min，每次持續1min，當采樣到的數據包超過150時產生結點掃描告警。?

?

?

??? 圖5是實驗結果，位于B點的移動代理在第37次掃描時產生結點掃描告警。?

?

?

??? 本文設置代理將結點掃描告警發送到網絡管理站，告警中包括被掃描的結點、echo request的發送地址列表等，網絡管理站將收到的告警消息解碼分析，然后禁止echo request發送地址列表中的地址發送ping消息。將沒有應用移動代理系統和應用移動代理系統的A、B間的流量進行對比，如圖6所示。非移動代理系統瓶頸鏈路上的網絡流量隨著網絡掃描流量的增多而逐漸發生擁塞。?

?

?

??? 在結點掃描初期，大量結點掃描數據包占用了瓶頸帶寬，當B點設置的移動代理向管理站A點發出告警后， 管理站將禁止告警消息中的echo request發送地址列表中的地址繼續發送掃描數據包，代理與管理站之間采用ATP協議進行通信，將數據報頭考慮進來，告警消息約在5 KB~6 KB,告警消息的傳輸引起了瓶頸連接流量的驟然增長，至告警消息傳輸完畢，結點掃描被禁止后，瓶頸連接處的流量降至了正常業務水平。由圖6可以看到應用移動代理的系統整體對網絡負載的壓力較小。需要指出的是，當網絡流量較大時，告警消息的傳輸帶來的流量影響是很小的。因此對于大型異構多應用的網絡故障管理，應用移動代理系統的優勢是明顯的。?

??? 基于移動代理的網絡故障管理體系將移動代理技術引入到網絡故障管理之中，它摒棄了傳統網絡故障管理體系中全網的故障都在網絡管理中心進行管理的方式，利用代理的智能性和移動性，將故障管理放在更加靠近故障源的地方進行，減輕了網絡負載。本文根據移動代理的特點，設計3層網管體系，并設計了各種代理以及代理之間的協同工作過程。在這種體系下，網管任務被細化，移動代理的特點得到了充分的體現。實驗結果證明了系統的部分優越性。?

參考文獻?

[1] 張云勇, 劉錦德. 移動Agent技術. 北京: 清華大學出版社, 2003.?

[2] DALMEIJER M, HAMMER D K. TMAERTS A. Mobile?software agents. Computers in Industry,2000,(14):251-260.?

[3] SATOH I. Building reusable mobile agents for network?management systems. Man and Cybernetics, 2003, 33(3):?350-357.?

[4]?MILOJICIC D. Agent systems and applications.IEEE Concurrency, 2000,8(2):22-23.?