嵌入式SNMP網(wǎng)管代理系統(tǒng)的研究

譚小波，李 冬

(沈陽理工大學 信息科學與工程學院，遼寧 沈陽 110159)

嵌入式SNMP網(wǎng)管代理系統(tǒng)的研究

譚小波，李 冬

(沈陽理工大學 信息科學與工程學院，遼寧 沈陽 110159)

針對OmniStar有線電視網(wǎng)絡設備僅支持本地監(jiān)控，難以滿足遠程網(wǎng)絡管理的需求，在硬件方面設計了以ARM-S3C2416為基礎的、具備15路串口的網(wǎng)管代理服務器；在軟件方面設計了支持SNMP協(xié)議與設備專有協(xié)議之間轉換的網(wǎng)管代理軟件。網(wǎng)管代理服務器采用串并行相結合的方式，最多管理75臺設備，降低了網(wǎng)絡管理的成本。網(wǎng)管代理軟件實現(xiàn)了OmniStar設備的集中遠程管理，減輕了網(wǎng)管工作人員的負擔。

有線電視網(wǎng)絡；網(wǎng)絡管理；網(wǎng)管代理；SNMP

網(wǎng)絡管理是對網(wǎng)絡中包括軟件、硬件和人力的綜合、使用以及協(xié)調(diào)，以實現(xiàn)對網(wǎng)絡資源的監(jiān)督、組合和控制[1]。隨著有線電視網(wǎng)絡技術的快速發(fā)展及業(yè)務規(guī)模的不斷擴大，建立一個科學有效的網(wǎng)管系統(tǒng)，實現(xiàn)所有有線電視網(wǎng)絡設備的集中管理，提高網(wǎng)絡運營的可靠性與服務質量，成為有線電視網(wǎng)絡管理研究的重點[2]。

SNMP(Simple Network Management Protocol )協(xié)議以其簡單、實用的特點成為網(wǎng)絡管理事實上的標準協(xié)議[3]。目前大部分網(wǎng)絡設備都支持SNMP協(xié)議的網(wǎng)絡管理[4-6]。然而仍然有部分有線電視設備不支持SNMP協(xié)議，因此針對不支持SNMP協(xié)議的有線電視設備，設計支持SNMP協(xié)議的代理轉換器，使其能夠融入到網(wǎng)管系統(tǒng)中，實現(xiàn)網(wǎng)絡設備的集中管理。

GI公司的OmniStar光纖寬帶高密度傳輸平臺是為將來的寬帶混合光纖/同軸網(wǎng)絡(HFC接入技術)設計的一種光纖傳輸平臺。前端監(jiān)控軟件HCS通過串口監(jiān)控管理平臺，即通過串行總線對OmniStar平臺參數(shù)變量信息和告警信息通過A/D轉換組成數(shù)據(jù)幀，返回給前端監(jiān)控軟件，達到管理平臺的目的。在這種管理模式下每臺PC只能對一臺OmniStar設備進行本地監(jiān)控，極大地增加了管理成本和工作人員的負擔。

本文針對OmniStar設備只支持串口通信的本地監(jiān)控，難以滿足遠程網(wǎng)絡管理的需求，在硬件方面設計了以ARM-S3C2416為基礎的、具備15路串口的網(wǎng)管代理服務器。該代理服務器采用串并行相結合的方式最多管理75臺設備，一個機房只需要配備一臺代理服務器和一臺PC，降低了網(wǎng)絡管理的成本。在軟件方面設計了支持SNMP協(xié)議與設備專有協(xié)議之間轉換的網(wǎng)管代理軟件，實現(xiàn)了OmniStar設備的遠程管理，減輕了網(wǎng)管工作人員的負擔。測試結果表明，本嵌入式網(wǎng)管代理系統(tǒng)能夠解析來自管理端的網(wǎng)管請求，通過協(xié)議轉換向OmniStar光傳輸平臺發(fā)送串口通信指令，進行實時數(shù)據(jù)采集和參數(shù)配置，并將采集的數(shù)據(jù)封裝成SNMP應答報文，提交給管理端，實現(xiàn)了OmniStar設備的遠程監(jiān)控管理。

1 網(wǎng)管代理硬件設計

本網(wǎng)管代理硬件的設計不僅要盡量滿足各種功能要求，還需要考慮到系統(tǒng)的整體性能、封裝尺寸、數(shù)據(jù)傳輸速率、器件間干擾大小等諸多因素，并且確保系統(tǒng)的安全和穩(wěn)定運行。根據(jù)網(wǎng)管代理系統(tǒng)的實際需求，并基于機房中通常放有60～70臺OmniStar設備，考慮到整個系統(tǒng)的成本和所占空間大小等問題，用一個ARM處理器管理機房中所有設備。如果單純采用S3C2416原有的四個串口，其中一個串口用于本地管理，剩余三個串口管理設備，則每個串口下需要級聯(lián)20～30臺的設備，這就大大加劇了數(shù)據(jù)的提取和輪詢的緩慢程度。因此，考慮到數(shù)據(jù)輪詢和傳輸速度等問題，設計了基于S3C2416的15路串口網(wǎng)管代理服務器設備，其設計如圖1所示。

圖1 網(wǎng)管代理服務器硬件設計

網(wǎng)管代理服務器除具有網(wǎng)管代理硬件組成的電源、DDR2、Nand Flash、復位芯片和Interface接口外，網(wǎng)管代理服務器把ARM-S3C2416的四路串口經(jīng)與RS-485擴展為15路串口，其中一個串口為CONSOLE口，這樣每路串口下串聯(lián)5臺OmniStar平臺，最多可實現(xiàn)管理75臺設備，滿足系統(tǒng)需求，并降低了成本、節(jié)省了空間。

根據(jù)具體設計圖設計了如圖2所示的網(wǎng)管代理服務器。網(wǎng)管代理服務器的總體形態(tài)采用目前已經(jīng)成熟的19英寸1U機箱，內(nèi)部結構分為電源模塊、Motherboard、CPU Core Board、Front Panel。

圖2 網(wǎng)管代理服務器實物圖

2 網(wǎng)管代理軟件設計

在基于開源開發(fā)包AGENT++和SNMP++的基礎上，設計了網(wǎng)管代理系統(tǒng)，實現(xiàn)了信息參數(shù)輪詢模塊、DB模塊和Agent代理模塊。圖3為網(wǎng)管代理系統(tǒng)的總體設計圖。

圖3 網(wǎng)管代理軟件總體設計圖

從圖3可以看出，網(wǎng)管代理系統(tǒng)支持多個管理站同時對網(wǎng)管代理進行實時監(jiān)控；參數(shù)輪詢模塊通過串口通信進程與OmniStar設備之間進行串口通信，得到網(wǎng)管代理服務器下所有級聯(lián)機架數(shù)據(jù)，并把機架數(shù)據(jù)寫入DB中，若在輪詢過程中發(fā)現(xiàn)告警則直接通過Trap進程發(fā)送給管理端；數(shù)據(jù)庫模塊主要負責存儲機架數(shù)據(jù)，為Agent代理進程提供數(shù)據(jù)支持；Agent代理模塊將數(shù)據(jù)庫提供的數(shù)據(jù)封裝為SNMP報文上傳給管理站，并能接受管理站信息對串口通信進程相應的參數(shù)進行設值；CLI界面提供了對串口通信進程的命令行界面管理；告警日志為Trap進程發(fā)送告警進行記錄。

2.1 信息參數(shù)輪詢模塊

信息參數(shù)輪詢模塊也稱參數(shù)輪詢，主要負責輪詢設備數(shù)據(jù)以及查找告警信息。當代理進程啟動后，參數(shù)輪詢對串口進程下的所有機架進行輪詢，并把輪詢得到的數(shù)據(jù)存儲到內(nèi)存DB中，若發(fā)現(xiàn)告警信息則直接通過Trap進程發(fā)送到管理端。圖4為信息參數(shù)輪詢模塊查詢和設置信息流程圖。

圖4 參數(shù)輪詢模塊流程圖

從圖4中可以看出，參數(shù)輪詢模塊接收來自AGENT代理模塊的請求時，首先進行初始化操作(包塊串口參數(shù)的設置、信號量的初始化、多進程的同步互斥和與OmniStar平臺的握手操作等)。建立通信關系成功后，判斷AGENT模塊發(fā)出的請求，AGENT模塊的請求有兩種，分別為查詢請求和設置請求。若為查詢請求，則將查詢請求封裝成串口查詢指令并傳遞給串口通信部分。串口通信將查詢指令發(fā)送給OmniStar設備，設備接收到查詢指令后返回相應的返回指令，通過指令解析把返回指令中的數(shù)據(jù)部分解析出來存到DB中， DB將數(shù)據(jù)信息提交給MIB庫。這樣，管理端就可以通過對MIB庫的查看查詢數(shù)據(jù)信息。若串口通信失敗則重新封裝指令繼續(xù)發(fā)送。若為設置請求，則將設置請求封裝成串口設置指令并傳遞給串口通信部分。串口通信將設置指令發(fā)送給OmniStar設備，接收到返回指令后，更新DB的相應設值信息，最后將設值成功返回給AGENT代理。若失敗則重新封裝指令繼續(xù)發(fā)送。

2.2 DB模塊

DB模塊主要負責保存所有設備的數(shù)據(jù)信息，采用內(nèi)存DB的方式。內(nèi)存DB是在嵌入式內(nèi)核開辟的內(nèi)存，這樣使數(shù)據(jù)的讀寫速度提高了幾個數(shù)量級。DB模塊也實現(xiàn)了MIB庫設計。MIB 是網(wǎng)絡管理系統(tǒng)中的重要構件,它由系統(tǒng)內(nèi)的許多被管對象及其屬性組成。MIB實際上是一個虛擬數(shù)據(jù)庫。這個數(shù)據(jù)庫提供相關被管理網(wǎng)絡元素的信息,而這些信息由管理進程和各個代理進程之間共享。

針對OmniStar設備進行相應的MIB設計，MIB的根節(jié)點(1.3.6.1.4.1.11606)為企業(yè)節(jié)點，其中公共信息系統(tǒng)節(jié)點(從1.3.6.1.4.1.11606.29.1開始)定義為標量對象，其它OmniStar設備模塊狀態(tài)參數(shù)被定義為表對象，MIB節(jié)點從1.3.6.1.4.1.11606.29.3到1.3.6.1.4.1.11606.29.10。

我靜下心來左思右想，突然想到以前我們都是一起吃漢堡的。3個人吃3個漢堡用了3分鐘，1個人吃1個漢堡也是3分鐘，那么9個人吃9個漢堡，也是3分鐘。我反反復復地想了幾遍，覺得應該沒有問題了，就把答案告訴了媽媽。媽媽點點頭笑了笑，夸我是個愛動腦筋的孩子。

2.3 Agent代理模塊

Agent代理模塊既能通過DB得到所有機架的相關數(shù)據(jù)信息，并將其封裝為SNMP報文實時地提供給管理端，又能接受管理端的SET信息，對有修改權限的數(shù)值進行設值操作。

根據(jù)SNMP網(wǎng)管協(xié)議的特點，AGENT++開發(fā)包提供了一套解析SNMP消息報文的處理過程，圖5為SNMP代理進程的狀態(tài)轉換圖。

圖5 狀態(tài)轉換圖

(1)啟動SNMP代理進程，由close狀態(tài)轉換成listen狀態(tài)；

(2)listen狀態(tài)監(jiān)聽來自管理端的Request請求，并發(fā)送該請求；

(3)SNMP代理模塊將發(fā)送Request請求，并從listen狀態(tài)轉換成receive狀態(tài)，由Request List類捕獲管理端v1/v2C版本的SNMP Request，通過receive方法可以獲取SNMP請求的ID號、變量綁定的數(shù)量、SNMP協(xié)議的版本、管理端IP地址、端口號及安全認證等，并發(fā)送OID；

(5)接收到參數(shù)后轉換成answer狀態(tài)，并將相應參數(shù)組裝成報文發(fā)送；向管理端發(fā)送完報文后轉換成finish狀態(tài)，finish狀態(tài)主動關閉進程回到close狀態(tài)。

3 測試與分析

網(wǎng)管代理系統(tǒng)根據(jù)網(wǎng)管接口測試標準進行測試，包括標準MIB變量的讀取和設置、告警信息的獲取以及代理系統(tǒng)響應時間等測試。

表1 網(wǎng)管代理的取值響應時間

系統(tǒng)的響應時間主要分為網(wǎng)管代理的取值響應時間和告警響應時間。網(wǎng)管代理的取值響應時間是指網(wǎng)管代理系統(tǒng)發(fā)送一次或多次GetRequest請求，然后由嵌入式網(wǎng)管代理返回響應報文之間的時間間隔。表1為網(wǎng)管代理的部分響應時間。

通過分析上表中各個模塊的所有數(shù)據(jù)響應時間和全部模塊的響應時間，以及對數(shù)據(jù)進行逐漸增多而對響應時間進行測試，得到如圖6所示的關系，可以看出隨著數(shù)據(jù)的增多，響應時間呈現(xiàn)逐漸增大的線性關系。

網(wǎng)管代理的告警響應時間是OmniStar設備產(chǎn)生一個告警，在管理端接收到告警的響應時間。圖7為手動在OmniStar設備上制造的告警信息，主要分為插入模塊告警、拔掉模塊告警、接入串口連接告警和斷開串口連接告警。

圖7 告警響應時間

由圖7可以看出，Y軸為響應時間，X軸為第N次測試。從圖中可以看出，插入模塊的響應時間一般在5～20s之間，平均值為10s；拔掉模塊的響應時間為5～8s之間，平均值為6.5s；接入串口連接的響應時間為5s；斷開串口連接的響應時間為15s。從結果中得出告警類型不同，告警的響應時間也不同，經(jīng)大量測試取平均值的告警響應時間大概為10s。

經(jīng)測試網(wǎng)管代理系統(tǒng)響應時間符合網(wǎng)管代理軟件要求，根據(jù)系統(tǒng)響應時間可以看出網(wǎng)管代理系統(tǒng)能夠快速發(fā)送數(shù)據(jù)信息和告警信息，保證了對OmniStar平臺實時的監(jiān)控和管理。

4 結論

本文根據(jù)有線電視網(wǎng)絡設備的具體特點設計并實現(xiàn)了以ARM-S3C2416為基礎的網(wǎng)管代理服務器設備，網(wǎng)管代理服務器具有15路串口，采用串并行相結合的方式對多機架進行級聯(lián)，為OmniStar平臺的網(wǎng)管代理系統(tǒng)提供了硬件支持。

在基于開源開發(fā)包AGENT++和SNMP++的基礎上，設計了網(wǎng)管代理系統(tǒng)，實現(xiàn)了信息參數(shù)輪詢模塊、DB模塊和Agent代理模塊。測試結果表明本嵌入式網(wǎng)管代理系統(tǒng)滿足了OmniStar設備的遠程集中管理需求。

[1]胡成松,汪凱澤.SNMP網(wǎng)絡管理[M].北京:中國電力出版社,2001:59-65.

[2]張會生.有線電視工程設計與新技術應用[M].北京:科學出版社,2006:65-73.

[3]周立功.ARM嵌入式系統(tǒng)基礎教程[M].北京:北京航空航天大學出版社，2005:45-57.

[4]楊家海，任沖.網(wǎng)絡管理原理與實現(xiàn)技術[M].北京:清華大學出版社，2000:43-61.

[5]William Stalling.SNMP網(wǎng)絡管理[M].胡成松等譯.北京:中國電力出版社，2001:42-68.

[6]Fu Guoqiang,Yang Wanpeng.Research on scheme of intelligent network management [J].Journal of Xi′an University of Engineering Science and Technology,2005,(19):89-92.

[7]G.Kramer,G.Pesavento.Ethernet Passive Optical Network (EPON):Building a Next-Generation Optical Access Network[J].IEEE Communications,2002,40(2):66-73.

(責任編輯：馬金發(fā))

Research on Embedded SNMP Network Management Agent

TAN Xiaobo,LI Dong

(Shenyang Ligong University,Shenyang 110159,China)

It is difficult for OmniStar cable TV network equipment to meet the needs of remote network management because it only supports local monitoring.So the network proxy server is designed with 15 serial ports based on ARM-S3C2416in terms of hardware and the network management agent supporting conversion between SNMP protocol and device proprietary protocol in terms of software.Adopting the method of combining series connection and parallel connection,network proxy server and managing OmniStar equipments up to 75,the network management cost is reduced.Network management agent is used to realize centralized remote management for OmniStar equipment,which reduces the management burden on staff.

cable television network;network management;network management agent;SNMP

2014-07-01

遼寧省優(yōu)秀人才計劃基金資助項目(LR201034)

譚小波(1977—)，男，副教授，博士，研究方向：網(wǎng)絡管理，嵌入式技術.

1003-1251(2015)03-0005-05

TP393.07

A