基于多Agent的分布式IP網(wǎng)故障診斷系統(tǒng)設(shè)計與實現(xiàn)

史春光， 劉 波， 彭進(jìn)霖,2， 常麗萍

(1. 太原衛(wèi)星發(fā)射中心 技術(shù)部, 山西 太原 030027； 2. 北京跟蹤與通信技術(shù)研究所, 北京 100094)

?

基于多Agent的分布式IP網(wǎng)故障診斷系統(tǒng)設(shè)計與實現(xiàn)

史春光1， 劉 波1， 彭進(jìn)霖1,2， 常麗萍1

(1. 太原衛(wèi)星發(fā)射中心 技術(shù)部, 山西 太原 030027； 2. 北京跟蹤與通信技術(shù)研究所, 北京 100094)

為便于及時定位并排除典型網(wǎng)絡(luò)故障，以數(shù)據(jù)包分析為基礎(chǔ)，基于多Agent系統(tǒng)，設(shè)計實現(xiàn)了一種便于擴(kuò)展的分布式IP網(wǎng)故障診斷系統(tǒng)。該系統(tǒng)采用網(wǎng)絡(luò)端口鏡像的方式進(jìn)行數(shù)據(jù)采集，采用伯克利數(shù)據(jù)包過濾器(BPF)包過濾機(jī)制進(jìn)行數(shù)據(jù)包過濾，基于專家系統(tǒng)進(jìn)行典型網(wǎng)絡(luò)故障診斷。此外，系統(tǒng)采用三元組〈實體，屬性，規(guī)則集〉進(jìn)行知識表示，用支持度表示規(guī)則出現(xiàn)的頻率。實際應(yīng)用表明，該系統(tǒng)可有效地幫助網(wǎng)絡(luò)維護(hù)人員及時了解網(wǎng)絡(luò)狀態(tài)，快速、準(zhǔn)確地診斷典型網(wǎng)絡(luò)故障。

故障診斷；多Agent系統(tǒng)；專家系統(tǒng)

中心通信網(wǎng)自IP化改造以來，發(fā)揮著重要的業(yè)務(wù)承載作用。隨著IP技術(shù)在中心各業(yè)務(wù)系統(tǒng)的推廣應(yīng)用和中心信息化建設(shè)的不斷深入，中心IP網(wǎng)的規(guī)模不斷擴(kuò)大、應(yīng)用業(yè)務(wù)逐漸增多?；赥CP/IP協(xié)議棧設(shè)計的網(wǎng)絡(luò)，考慮網(wǎng)絡(luò)的開放性較多，具有流量突發(fā)性大、安全性不強(qiáng)、可靠性不高等缺點，使得難以對其進(jìn)行維護(hù)管理。如何使網(wǎng)絡(luò)在出現(xiàn)故障之后能迅速、準(zhǔn)確地定位并排除故障，對網(wǎng)絡(luò)維護(hù)人員來說是個很大的挑戰(zhàn)。

目前，中心針對IP網(wǎng)絡(luò)的管理軟件主要有華為公司的iManager U2000網(wǎng)管系統(tǒng)、威睿GenieATM6000網(wǎng)絡(luò)流量檢測分析系統(tǒng)等，這些商用軟件在日常網(wǎng)絡(luò)維護(hù)中對設(shè)備管理、流量監(jiān)測分析起到了一定的作用，但不能針對網(wǎng)絡(luò)中具體的業(yè)務(wù)(如圖像、數(shù)據(jù)等)進(jìn)行分析統(tǒng)計，同時也不具備網(wǎng)絡(luò)故障診斷的功能。

文獻(xiàn)[1]針對IP網(wǎng)建設(shè)和使用中遇到的網(wǎng)絡(luò)問題，從TCP/IP 網(wǎng)絡(luò)原理和IP網(wǎng)的結(jié)構(gòu)模型出發(fā)，總結(jié)出網(wǎng)絡(luò)分層模型分析法、網(wǎng)絡(luò)連接結(jié)構(gòu)分析法和網(wǎng)絡(luò)檢測分析法相結(jié)合的故障排查策略；文獻(xiàn)[2]針對噪聲和動態(tài)網(wǎng)絡(luò)，研究了基于主動探測的故障診斷方法，提出了基于貝葉斯模型的故障診斷算法。與上述文獻(xiàn)不同，本文將專家系統(tǒng)引入到IP網(wǎng)故障診斷中來，設(shè)計并實現(xiàn)了一種分布式IP網(wǎng)故障診斷系統(tǒng)。在IP網(wǎng)故障診斷專家系統(tǒng)中，本文提出采用三元組〈實體，屬性，規(guī)則集〉進(jìn)行知識表示，進(jìn)一步提出用支持度表示規(guī)則出現(xiàn)的頻率。

1 系統(tǒng)設(shè)計

1.1 系統(tǒng)體系架構(gòu)

系統(tǒng)以數(shù)據(jù)包分析為基礎(chǔ)，基于多Agent系統(tǒng)搭建了一種便于擴(kuò)展的分布式架構(gòu)。該系統(tǒng)采用網(wǎng)絡(luò)端口鏡像的方式進(jìn)行數(shù)據(jù)采集，通過比對同一數(shù)據(jù)流發(fā)端、收端數(shù)據(jù)包分析結(jié)果，輔以ping、tracert等工具，定位測控設(shè)備發(fā)送數(shù)據(jù)、網(wǎng)絡(luò)傳輸、數(shù)據(jù)中心接收數(shù)據(jù)異常等故障位置，在此基礎(chǔ)上通過基于案例的專家系統(tǒng)進(jìn)行典型故障診斷。系統(tǒng)分為部署在各個遠(yuǎn)端測站節(jié)點上的數(shù)據(jù)采集端服務(wù)，以及部署于中心節(jié)點的數(shù)據(jù)中心端服務(wù)。其中，數(shù)據(jù)采集端分為數(shù)據(jù)采集、數(shù)據(jù)處理2個層次；數(shù)據(jù)中心端分為數(shù)據(jù)采集、數(shù)據(jù)處理和數(shù)據(jù)應(yīng)用3個層次。數(shù)據(jù)采集端服務(wù)和數(shù)據(jù)中心端服務(wù)通過Agent通信交換消息并傳輸數(shù)據(jù)。系統(tǒng)總體架構(gòu)如圖1所示。

圖1 系統(tǒng)體系架構(gòu)

各層次實現(xiàn)的功能主要包括：(1) 數(shù)據(jù)采集層負(fù)責(zé)各節(jié)點數(shù)據(jù)的采集和預(yù)處理；(2) 數(shù)據(jù)處理層負(fù)責(zé)將采集來的數(shù)據(jù)進(jìn)行數(shù)據(jù)處理和數(shù)據(jù)存儲，為上層應(yīng)用提供強(qiáng)大的數(shù)據(jù)分析和統(tǒng)計信息；(3) 數(shù)據(jù)應(yīng)用層利用數(shù)據(jù)處理層的數(shù)據(jù)分析和統(tǒng)計信息進(jìn)行網(wǎng)絡(luò)性能監(jiān)測、故障診斷等，并將結(jié)果以Web圖形界面形式呈現(xiàn)給用戶。

1.2 系統(tǒng)功能模塊

系統(tǒng)功能模塊如圖2所示。其中，數(shù)據(jù)采集端服務(wù)包括數(shù)據(jù)包捕獲、存儲和分析模塊，完成對發(fā)端數(shù)據(jù)的采集、分析(如重包、丟包、亂序等的檢測)；數(shù)據(jù)中心端服務(wù)包括收端數(shù)據(jù)的捕獲、存儲、分析模塊，以及對收發(fā)兩端分析結(jié)果比對、網(wǎng)絡(luò)性能監(jiān)測、故障診斷等模塊，完成對同一數(shù)據(jù)流發(fā)端、收端數(shù)據(jù)分析結(jié)果的比對和網(wǎng)絡(luò)性能監(jiān)測等，在此基礎(chǔ)上基于專家系統(tǒng)進(jìn)行典型網(wǎng)絡(luò)故障診斷。

圖2 系統(tǒng)功能模塊

1.3 系統(tǒng)運行模式

數(shù)據(jù)采集端以服務(wù)形式在后臺運行，運行前需要配置各類參數(shù)，包括網(wǎng)卡IP、Agent參數(shù)、文件路徑等。系統(tǒng)啟動后，執(zhí)行數(shù)據(jù)包捕獲和分析Agent，通過數(shù)據(jù)包緩存、數(shù)據(jù)包持久化文件對捕獲的數(shù)據(jù)包和分析結(jié)果進(jìn)行存儲；執(zhí)行數(shù)據(jù)交互的Agent定時將捕獲的數(shù)據(jù)包分析結(jié)果傳送到數(shù)據(jù)中心端，同時等待數(shù)據(jù)中心端傳入的交互指令。

數(shù)據(jù)中心端服務(wù)包括數(shù)據(jù)采集服務(wù)、數(shù)據(jù)分析服務(wù)和故障診斷服務(wù)三大部分，將數(shù)據(jù)采集、分析和故障診斷結(jié)果通過Web形式展現(xiàn)給用戶，并提供與用戶交互接口。數(shù)據(jù)中心端服務(wù)運行前需要配置各類參數(shù)，同時初始化數(shù)據(jù)庫和數(shù)據(jù)字典。數(shù)據(jù)中心端Web UI與數(shù)據(jù)中心端服務(wù)之間使用XML、數(shù)據(jù)緩存、持久化文件、數(shù)據(jù)庫接口等交換消息傳遞數(shù)據(jù)。數(shù)據(jù)中心端服務(wù)與數(shù)據(jù)采集端服務(wù)采用Agent交換消息傳遞數(shù)據(jù)。

系統(tǒng)運行采用異步結(jié)構(gòu)，即數(shù)據(jù)采集端和數(shù)據(jù)中心服務(wù)端分別獨立運行。數(shù)據(jù)采集端可以隨時啟動加入分布式系統(tǒng)與數(shù)據(jù)中心交換消息傳遞數(shù)據(jù)。

2 網(wǎng)絡(luò)數(shù)據(jù)采集

2.1 數(shù)據(jù)包捕獲原理

由于以太網(wǎng)共享傳輸介質(zhì)的特點，同一沖突域中的任何節(jié)點都可以捕獲到網(wǎng)絡(luò)中傳輸?shù)乃袛?shù)據(jù)包，接收或者丟棄數(shù)據(jù)包取決于網(wǎng)卡工作模式的設(shè)置。一般情況下，網(wǎng)卡可以工作于單播、組播、廣播或混雜4種接收模式[3]。通常情況下，計算機(jī)網(wǎng)卡會根據(jù)數(shù)據(jù)包中目標(biāo)MAC地址進(jìn)行判斷，若為自己的MAC地址或是廣播MAC地址，則接收該數(shù)據(jù)包，并提交給上層作進(jìn)一步處理，否則丟棄該數(shù)據(jù)包。當(dāng)網(wǎng)卡設(shè)置為混雜接收模式時，則不做任何判斷直接把捕獲到的所有數(shù)據(jù)包交給上一層作進(jìn)一步處理。

基于多Agent的分布式IP網(wǎng)故障診斷系統(tǒng)工作時將網(wǎng)卡設(shè)置為混雜接收模式，從而能捕獲到網(wǎng)絡(luò)中所有數(shù)據(jù)包。

2.2 數(shù)據(jù)包捕獲方式

本系統(tǒng)采用網(wǎng)絡(luò)端口鏡像的方式通過數(shù)據(jù)包捕獲工具進(jìn)行數(shù)據(jù)采集。

網(wǎng)絡(luò)端口鏡像是指將流經(jīng)指定端口的所有數(shù)據(jù)都復(fù)制到交換機(jī)上的另外一個端口，即鏡像端口，計算機(jī)通過連接到鏡像端口可以捕獲所需的數(shù)據(jù)。

為了適應(yīng)自主可控信息系統(tǒng)建設(shè)的發(fā)展需要，考慮到可移植的特性，本系統(tǒng)采用Java語言來實現(xiàn)；相應(yīng)地，采用Jpcap(Java Package for Libpcap)[4]來完成數(shù)據(jù)包捕獲。Jpcap是一個能夠捕獲、發(fā)送網(wǎng)絡(luò)數(shù)據(jù)包的Java類庫包。

2.3 數(shù)據(jù)包過濾

數(shù)據(jù)包過濾是指計算機(jī)捕獲網(wǎng)絡(luò)中的數(shù)據(jù)包后，根據(jù)數(shù)據(jù)包的源地址、目的地址、端口號等信息組合來過濾數(shù)據(jù)包，最終只保留用戶感興趣的數(shù)據(jù)包。本系統(tǒng)采用伯克利數(shù)據(jù)包過濾器(BPF)[5]包過濾機(jī)制對捕獲的數(shù)據(jù)包進(jìn)行過濾。

3 多Agent系統(tǒng)

在人工智能領(lǐng)域，Agent是一種具有智能的實體。這種實體可以是軟件、設(shè)備或計算機(jī)系統(tǒng)等。多Agent系統(tǒng)[6]是一個松散耦合的Agent網(wǎng)絡(luò)，多個Agent通過交互、協(xié)作進(jìn)行問題求解(所解問題一般是單個Agent能力或知識所不及的)。本系統(tǒng)中，通過多Agent系統(tǒng)實現(xiàn)分布式IP網(wǎng)故障診斷。

通過對現(xiàn)有開發(fā)平臺的分析比較，本系統(tǒng)采用JADE(Java Agent DEvelopment Framework)[7]實現(xiàn)多Agent系統(tǒng)。JADE是用Java語言編寫的一個多Agent系統(tǒng)開發(fā)平臺，可以用來開發(fā)基于多Agent的應(yīng)用程序。JADE遵循完全的FIPA(The Foundation for Intelligent Physical Agents)規(guī)范，支持多Agent間的協(xié)作、移動Agent等。JADE將Agent的活動限定于容器(Container)內(nèi)。容器提供了Agent的運行環(huán)境，同一容器可以容納多個Agent。每個容器都必須向一個主容器(Main Container)注冊。主容器確立了一個Agent平臺，平臺包括：(1) Agent管理系統(tǒng)(Agent Management System，AMS)，負(fù)責(zé)注冊、控制其他Agent的活動及外部應(yīng)用程序?qū)ζ脚_的利用；(2) 目錄服務(wù)器(Directory Facilitator，DF)，負(fù)責(zé)為平臺上的Agent提供黃頁服務(wù)；(3) 消息傳送系統(tǒng)，也稱為Agent通信信道(Agent Communication Channel，ACC)，控制平臺內(nèi)或不同平臺之間的消息傳輸。

平臺通過擴(kuò)展容器跨越多臺網(wǎng)絡(luò)設(shè)備。JADE為封裝Agent的任務(wù)而定義了一種行為(Behaviour)類，行為類中可指定任務(wù)執(zhí)行時應(yīng)遵循的不同協(xié)議，從而實現(xiàn)Agent的協(xié)作能力。采用JADE系統(tǒng)，便于利用面向?qū)ο蠹夹g(shù)對系統(tǒng)內(nèi)的各個功能模塊進(jìn)行開發(fā)。在業(yè)務(wù)邏輯上，將分布在不同測站的終端聯(lián)系在一起，實現(xiàn)數(shù)據(jù)從采集端到接收端的全過程檢測，為全面了解網(wǎng)絡(luò)狀態(tài)提供更可靠的手段。

4 IP網(wǎng)故障診斷專家系統(tǒng)

專家系統(tǒng)(Expert System, ES)[8]是一個或一組能在某些特定領(lǐng)域內(nèi)，應(yīng)用專家知識和推理方法求解復(fù)雜問題的一種智能計算機(jī)程序，屬于人工智能的一個發(fā)展分支。專家系統(tǒng)的研究目標(biāo)是模擬人類專家的思維推理過程。

IP網(wǎng)故障診斷專家系統(tǒng)以文本案例為基礎(chǔ)，以知識模板為表達(dá)方式，以系統(tǒng)參數(shù)為元素，通過邏輯推理實現(xiàn)典型故障診斷，主要包括知識表示和故障診斷推理。其處理流程如圖3所示。

圖3 IP網(wǎng)故障診斷專家系統(tǒng)流程圖

4.1 知識表示

本系統(tǒng)中，知識通過一個三元組〈實體，屬性，規(guī)則集〉來表示。從文本到知識的轉(zhuǎn)換通過案例模板聯(lián)系起來。

4.1.1 案例模板

案例模板包括設(shè)備、狀態(tài)、參數(shù)和故障原因。

1) 設(shè)備。設(shè)備是案例文本中出現(xiàn)的、對案例具有關(guān)鍵作用的網(wǎng)絡(luò)設(shè)備，如主機(jī)、交換機(jī)、路由器、防火墻、保密機(jī)、電源系統(tǒng)和線纜等。根據(jù)網(wǎng)絡(luò)拓?fù)淝闆r，設(shè)備還可以分為主設(shè)備和關(guān)聯(lián)設(shè)備。主設(shè)備是案例中出現(xiàn)故障的設(shè)備；圍繞主設(shè)備的檢測，需要對與主設(shè)備物理連接的其他設(shè)備進(jìn)行檢測，這些設(shè)備稱為關(guān)聯(lián)設(shè)備。

2) 狀態(tài)。狀態(tài)是對系統(tǒng)運行情況的一般描述，是設(shè)備狀況的定性描述，如主機(jī)無法ping通等。狀態(tài)無法直接用于計算，因此需要將狀態(tài)轉(zhuǎn)換為參數(shù)集合。

3) 參數(shù)。參數(shù)與設(shè)備相關(guān)聯(lián)。參數(shù)集合的選擇由具有專家領(lǐng)域知識的用戶制訂。參數(shù)還包括參數(shù)值，參數(shù)值分為精確型和模糊型。精確型參數(shù)如各類統(tǒng)計量、ping命令中的Lost參數(shù)等；模糊型參數(shù)的值由模糊方法確定，如描述線纜老化狀態(tài)可以用新、半新和舊等概念描述。為了便于計算，將新舊程度用[0,1]之間的數(shù)字來表示，從而形成量化指標(biāo)。

4) 故障原因。故障原因與案例對應(yīng)，表示由〈設(shè)備，參數(shù)，狀態(tài)〉組成的集合與故障原因集合之間的關(guān)系。

4.1.2 知識模板

知識模板是案例模版的進(jìn)一步抽象，由三元組〈實體，屬性，規(guī)則集〉組成。

1) 實體。實體對應(yīng)案例模板中的設(shè)備，同時加入設(shè)備類的概念，如某鏈路上的華為路由器標(biāo)識為實體是加入路由器概念，轉(zhuǎn)換成〈“路由器”，“華為路由器”〉這樣的條目。其目的是提高案例匹配度。

2) 屬性。屬性由參數(shù)轉(zhuǎn)換而來，同時加入實體類概念，即將各個設(shè)備的參數(shù)加入設(shè)備類元素。如系統(tǒng)統(tǒng)計的重包數(shù)〈重包:amount〉轉(zhuǎn)換為〈主機(jī)，重包數(shù):amount〉。

3) 規(guī)則集。規(guī)則集是案例的邏輯表達(dá)。通過邏輯運算將實體、屬性和故障原因關(guān)聯(lián)起來，表示了實體在什么狀況下發(fā)生了故障，其故障原因是什么。邏輯運算種類很多，由于系統(tǒng)輸入采用“與關(guān)聯(lián)”和“或關(guān)聯(lián)”來表示，因此僅采用“與”和“或”操作。規(guī)則集合的邏輯運算，如Rule1：實體1[與/或]實體[2]→{故障原因集合}；Rule2：屬性集1[與/或]屬性集[2]→{故障原因集合}。

隨著案例庫的增加，各個規(guī)則出現(xiàn)的頻率不同，將規(guī)則出現(xiàn)的頻率稱為支持度。其物理含義是：同樣的實體在不同屬性條件下可能會導(dǎo)致不同類型的錯誤，尤其是長鏈規(guī)則，即與/或鏈很長的規(guī)則。其中有部分鏈頻繁出現(xiàn)，這部分子鏈本身也是一個規(guī)則，同時也是支持度很高的規(guī)則。一方面，這個規(guī)則所導(dǎo)致的故障類型多；另一方面，這類規(guī)則導(dǎo)致某些故障的概率很高。系統(tǒng)實現(xiàn)時假定這些規(guī)則支持度初始都是1，也就是說具有相同的支持度。隨著案例增加，支持度不斷累加。支持度是進(jìn)行案例推理的重要指標(biāo)。

4.2 知識推理

4.2.1 推理過程

推理過程的目標(biāo)是根據(jù)故障現(xiàn)象描述推理出可能的錯誤原因。進(jìn)行推理前，首先將所掌握的故障信息、數(shù)據(jù)通過人工輸入產(chǎn)生案例模板，然后系統(tǒng)再將案例模板轉(zhuǎn)換為知識模板，最后基于知識模板通過知識推理算法推理出可能的故障原因。其本質(zhì)是，查詢規(guī)則庫中規(guī)則集合與輸入的知識模板所提取的規(guī)則集相匹配的案例中，規(guī)則支持度最大的故障原因。

4.2.2 知識推理算法

假設(shè)規(guī)則庫中存在如下規(guī)則：r={r1,r2,r3,…rn}，其支持度分別為{sr1,sr2,sr3,…srn}。將待檢測故障中人工輸入的參數(shù)映射為規(guī)則集R={R1,R2,R3,..Rm}。首先對R中每一個Ri，在r中進(jìn)行匹配，如果R完全匹配，說明待檢測故障與歷史案例完全匹配，可以直接查詢出可能故障原因；如果不能完全匹配，則表示有規(guī)則沒有出現(xiàn)過，可能表示一類新的故障，則選擇支持度最高的規(guī)則。當(dāng)支持度超過一定閾值，則根據(jù)這個規(guī)則提取可能故障原因；如果最大支持度低于閾值，則表示該故障情況與知識庫中歷史故障案例重合度很低，則無法給出故障原因。

5 系統(tǒng)應(yīng)用情況

該系統(tǒng)在中心進(jìn)行了部署應(yīng)用。在遠(yuǎn)端測站部署分布式IP網(wǎng)故障診斷系統(tǒng)(Distributed IP network Fault Diagnosis System, DIFS)客戶端，在中心部署DIFS服務(wù)器端。DIFS客戶端通過交換機(jī)端口鏡像方式對測站設(shè)備發(fā)送的數(shù)據(jù)包進(jìn)行捕獲、分析，并將分析結(jié)果發(fā)給中心；同時，在中心通過交換機(jī)端口鏡像方式對接收的數(shù)據(jù)包進(jìn)行捕獲、分析。通過比對同一數(shù)據(jù)流發(fā)端、收端數(shù)據(jù)包分析結(jié)果，輔以ping、tracert等工具，定位測控設(shè)備發(fā)送數(shù)據(jù)、網(wǎng)絡(luò)傳輸、數(shù)據(jù)中心接收數(shù)據(jù)異常等故障位置，在此基礎(chǔ)上通過基于案例的專家系統(tǒng)進(jìn)行典型故障診斷。

通過該系統(tǒng)的應(yīng)用，網(wǎng)絡(luò)維護(hù)人員可以及時了解網(wǎng)絡(luò)數(shù)據(jù)傳輸質(zhì)量，監(jiān)測網(wǎng)絡(luò)性能，快速、準(zhǔn)確地進(jìn)行網(wǎng)絡(luò)典型故障診斷，為網(wǎng)絡(luò)管理提供多層次的決策支持。

6 結(jié) 束 語

網(wǎng)絡(luò)故障診斷是網(wǎng)絡(luò)管理的重要部分，也是網(wǎng)絡(luò)管理領(lǐng)域多年以來的研究熱點。本文以網(wǎng)絡(luò)分析為手段，基于多Agent系統(tǒng)，設(shè)計實現(xiàn)了一種便于擴(kuò)展的分布式IP網(wǎng)故障診斷系統(tǒng)。在取得了一些初步研究成果的同時，也得到一些新啟示，將在下一步的工作中展開更深入的研究：(1) IP網(wǎng)故障診斷專家系統(tǒng)的自學(xué)習(xí)功能還有待進(jìn)一步加強(qiáng)，后續(xù)可以結(jié)合神經(jīng)網(wǎng)絡(luò)等技術(shù)一起研究；(2) 網(wǎng)絡(luò)管理信息庫為網(wǎng)絡(luò)管理提供了豐富的網(wǎng)絡(luò)狀態(tài)信息，下一步在完善專家系統(tǒng)時應(yīng)綜合考慮各種信息的有效利用。

References)

[1]段慧芬，王華，劉煥敏，等.試驗IP網(wǎng)故障分析策略及方法應(yīng)用[J].飛行器測控學(xué)報,2012,31(4):71-75.

[2]喬焰.基于主動探測的IP網(wǎng)故障診斷與丟包率推理方法[D].北京：北京郵電大學(xué),2012:50-64.

[3]翟光群，胡貴江. 基于Jpcap的數(shù)據(jù)包捕獲器的設(shè)計與實現(xiàn)[J].微計算機(jī)信息,2009,25(7-3):197-199.

[4]Jpcap tutorial[EB/OL].(2009-10-22)[2015-10-07].http://netresearch.ics.uci.edu/kfujii/jpcap/doc/tutorial/index.html.

[5]MCCANNE S，JACOBASON V． The BSD packet filter：a new architecture for user-level packet capture[C]//Proceedings of the 1993 Winter USENIX Technical Conference.San Diego:USENIX,1993:1-11．

[6]廉師友.人工智能技術(shù)導(dǎo)論[M].3版.西安：西安電子科技大學(xué)出版社，2007:261-268.

[7]JADE[EB/OL].(2004-03-17)[2015-10-07].http://jade.tilab.com/.

[8]蔡自興，約翰·德爾金，龔濤.高級專家系統(tǒng)：原理、設(shè)計及應(yīng)用[M].2版.北京：科學(xué)出版社，2014:188-224.

(編輯：李江濤)

Design and Implementation of Distributed IP Network Fault Diagnosis System Based on Multi-agent System

SHI Chunguang1， LIU Bo2， PENG Jinlin1,2， CHANG Liping1

(1. Taiyuan Satellite Launch Center, Taiyuan Shanxi 030027, China；2. Beijing Tracking and Telecommunications Technology, Beijing 100094, China)

To locate and eliminate typical network faults in time, the paper designs an expandable distributed IP network fault diagnosis system based on data packet analysis and multi-agent system. The system adopts the method of network port mirroring to collect data, conducts data filtering with Berkeley Packet Filtering (BPF) mechanism, and performs network fault diagnosis based on expert system. In addition, the system uses triple 〈entity, attribute and rule set〉 to realize knowledge representation, and represent the frequency of the rule appearance by support degree. The practical application shows that the system can effectively help network maintenance personnel to know the network status in time and quickly and accurately diagnose typical network faults.

fault diagnosis; multi-agent system; expert system

2016-04-20

史春光(1979—)，男，工程師，博士，主要研究方向為通信網(wǎng)絡(luò)技術(shù)。flyingshicg@126.com

TP393.1

2095-3828(2016)06-0095-05

A DOI 10.3783/j.issn.2095-3828.2016.06.018