簡單網絡管理協議SNMP(Simple Network Management Protocol)是為網絡管理系統提供的底層網絡管理的框架。其應用范圍非常廣泛，諸多種類的網絡設備、軟件和系統中都有所采用。SNMP協議發展到目前的第3版，已經成為一個非常成熟的網絡管理協議[1]。不過由于每個設備的支持程序有所不同，所以面向SNMP的成熟網絡管理框架依然非常少見[2]。在SNMP的支持方面，Cisco是走在最前沿的[3]，除了完整地支持RFC1213中MIB-2的定義外，還在部分設備中支持RFC2819和RFC2021中的RMON。基于Cisco的主流性，開發“可擴展”的基于SNMP的網絡管理框架變得非常現實。

1 開發平臺與架構的選擇

.NET平臺的C#語言有著豐富的語言特性，例如Lambda表達式(在Auto-Topology控件及軟件框架中已多次使用)可以顯著地提升開發效率，而且支持C#的官方開發環境Visual Studio是公認的更加有助于團隊協作的集成開發環境。再者，C#中匿名對象、對象初始化器、閉包支持LINQ等利于DSL表現的特性，加之良好的異步編程支持，使C#成為了首選語言，自然，首選的平臺則為.NET。

軟件必須面對的兩個基本問題是“通用性”與“可擴展性”。所謂通用性，就是在絕大多數的網絡環境中都能夠使用的基本功能；所謂可擴展性，就是在保證通用的前提下，充分發揮特有設備特別功能的能力。這使得通用框架的設計難度加大。

如何使網絡管理任務充分簡化是需要重點考慮的，軟件的工作方式將會影響操作的行為，C/S結構或者純粹的單體軟件無疑有著更為強大的圖形展現能力，而B/S結構則在伸縮性與跨平臺方面有著更為良好的表現。一個較為折衷并且有經濟效益的選擇，就是在框架級別實現通用與跨平臺，在表現層分離為不同的解決方案。最終，軟件采用了普通軟件的工作方式。

雖然可以自主開發SNMP底層的通訊類庫來支持整個項目，但考慮到開發周期等因素，還是尋求一款更為優秀的開源組件來承擔基礎通訊。有兩款開源組件可供選擇：SnmpSharpNet和SharpSnmpLib。在仔細研究了這兩款組件后發現，SharpSnmpLib更新頻率更高，而且代碼更加利于維護，于是選擇SharpSnmpLib來支持開發。

2 系統分析

2.1 重點問題

由于SNMP協議在不同的設備上支持的情況不同，所以要求軟件的一些通用功能兼容大部分設備，這是很有挑戰的。常見的網絡管理任務基本都建立在以拓撲圖為藍本的擴展之上，所以無論設備如何不同、協議支持情況有多復雜，自動網絡拓撲發現功能是一個不能缺少的核心功能。如何在兼容常見設備的基礎上實現擴展功能成為研究的重點問題。

與其說實現兼容，倒不如理解為只使用大部分硬件都能支持的功能來實現。一個顯而易見的解決方案就是只使用RFC1213中定義的MIB-2功能組。MIB-2中定義了網絡管理中經常使用的對象，并且得到了絕大多數設備的支持。如果只使用MIB-2中定義的功能來支撐軟件的核心功能，那么軟件與硬件的兼容性問題自然也會少很多。

2.1.2 通過SNMP的方式得到網絡拓撲

SNMP協議的相關功能中沒有直接獲取拓撲結構的對象，在一些私有MIB中（例如Cisco中關于CDP的相關對象）有這樣直接的功能，但是對網絡環境與設備要求苛刻（CDP協議只在純Cisco網絡中有用，雖然有部分非Cisco開始支持CDP，但是數量很少）[4]，所以這不是一個通用的解決方案。

為了保持設備和網絡的兼容性，前面提到應該采用“保守”的對象來實現核心功能，所以拓撲圖的自動發現只能從MIB-2中查找相應的解決方案。網絡拓撲，顧名思義就是網絡設備之間的邏輯關系，那么反映到網絡技術中，最為直接的對應就是路由表。但是路由表中只有網絡設備間的關系，支持SNMP的PC信息卻不在路由表中。如何解決支持SNMP的PC發現呢？一個方案就是查找網絡設備中的“地址轉換表”，這其中有PC的IP信息，通過對這些PC逐一進行SNMP測試，就可完整地支持整個SNMP網絡[5]。另外，需要知道設備自身接口的IP，這在MIB-2的IP功能組（1.3.6.1.2.1.4）中都有定義。

2.2 難點問題

拓撲圖的機制確定之后，另一個難題就是如何將各個設備以及相關線路布置在屏幕上。由于設備之間的唯一關系就是相互間的鏈路，沒有與物理結構相關的數據可以獲得，所以要想完全通過軟件繪制出與物理結構相同或相似的拓撲圖是非常困難的，可以參考的相關資料和論文非常少[6]。

拓撲圖的分布是個學術難題，環狀權值分布僅作為一種理論嘗試，為了今后有更好的理論支撐，可以靈活地修改布局算法，軟件在開發過程中采用“策略模式”（Strategy）將布局算法抽象出來，易于替換。

領域模型記錄了一個系統中的關鍵概念和詞匯表，顯示出了系統中的主要實體之間的關系，并確定了它們的重要方法和屬性。對于一個SNMP應用系統來說，主要的領域模型就是SNMP實體。另外一個擴展功能就是對網絡設備的“管理”，這涉及到資產評估、設備統計、維修管理等相關的應用，換句話講，如何將軟件獲取到的信息與現實中的設備對應起來，是軟件需要解決的一個方面。

3 總體描述及框架設計

?

3.1 系統核心

系統實現所涉及的核心問題分別如下：

(1)如何獲取和繪制拓撲結構圖，并合理地調整拓撲樣式；
(2)同步引擎的合理調度，以及信息存儲結構；
(3)功能的合理分類，以及對相關OID的分析、組織、建模；
(4)基礎構建塊的選擇。

由于系統采用了分層開發，以及可擴展性等多方面的考慮，軟件在邏輯上分為4層——持久層、基礎層、業務層、表示層，基本的工作模式如圖1所示。

?

3.2 存儲模型

存儲模型為“設備管理”以及相關的擴展應用提供持久化的機制，并為統計、分析等要求查詢對比歷史數據的需求提供基礎。

對于數據庫的選擇，從成本上考慮，有Microsoft SQL Server Express、Microsoft SQL CE、MongoDB、NoSQL可供選擇，而從部署上考慮有MongoDB、部分NoSQL、Microsoft SQL CE可選擇，最后從性能上考慮，采用Microsoft SQL CE來支持存儲模型。
經過持久后的數據可以在相對固定的時間內有效，在此基礎上，進行統計、跟蹤、分析等功能就會迅速許多，同時，網絡的負荷也會明顯降低。

3.3 領域邏輯設計

系統與SNMP網絡交互的主要邏輯依賴于SNMP協議所傳輸的SNMP對象數據，SNMP對象又依賴于相關的MIB來描述其特性與結構。軟件所需要的領域邏輯主要集中在對SNMP實體的操作上，但是SNMP的操作是對程序不友好的。也就是說，無法通過流暢的API來操作SNMP使之為軟件所用。所以需要設計一種領域邏輯，將SNMP的特定領域轉化為程序友好的領域。考慮圖2所示的領域轉化。

SNMP的操作原語被轉化為對應的編程概念，使SNMP的領域完整地轉化為程序設計的領域。這為AOP編程以及存儲模型的擴展奠定了基礎。

4 系統實現

?

4.1 環狀權值分布

拓撲圖的排序算法被叫“環狀權值分布”，主要是因為引入了設備在網絡中 “權重”的概念。由于布局的主要目的是讓主要設備能夠分布且合理定位在屏幕上，所以拓撲布局的算法首先是找出那些“權重”最高的設備，并依此排序進行設備定位。算法主要的步驟有：

(1)設備按“權重”排序。系統主要面向的是路由及交換設備，所以對拓撲圖最為敏感的信息就是“路由”信息。如果一個設備核心的路由數量高于其他的設備，則該設備就是所謂的“核心設備”。

(2)最高權重優先定位。步驟(1)已經確定了最為核心的設備以及按“權值”排序后的設備分組。最為核心的設備是第一組，它們將以屏幕正中央為圓心，均勻分布在某個半徑的圓圈上。半徑的確定取決于要定位的設備數量，數量越多半徑值越大。當這些設備定位結束時，也就確定了此設備在屏幕中心點的角度(∠θ)，此角度將作為下個步驟定位的依據。

(3)“衛星”設備布局。與核心設備相聯接的設備都歸類為該核心設備的衛星設備， “衛星”設備的具體分布算法如下：

假定有n個核心設備，那么每個核心設備的衛星設備只可以分布在360/n的扇形范圍內，如圖3所示。

圖3中有3個核心設備，被分為A、B、C三個扇形區域，以R2為例，它的3個衛星設備就分布在B區域，且在B扇形內根據∠θ均勻分布，半徑會以衛星設備的數量作相應的修正。
(4)繪制鏈路連線。核心設備區域的連線允許交錯，因為這部分的連線幾乎不太可能做到不交叉。由于分布是基于環的，所以連線即便有交錯，問題也不會很嚴重。衛星設備的連線主要是對上一個設備的，這種情況下可以直連，如果衛星設備之間有連線，則可對衛星設備的布局會做一些小調整，盡量不出現連線的過度交叉。

此時如果發現x設備與z設備間有連線，就會根據屏幕上的空間對x或z的位置做一些小的調整，以讓x與z的連線分布得更為合理。

4.2 MIB模塊的實現

為命名方便，基于簡單網絡管理協議的網絡監控系統簡稱為SNMS。根據MIB的命名方式，在1.3.6.1.4.1節點下自定義了一個名為Tute（888）的節點，在該節點下定義SNMS(1)節點。

定義了MIB中的對象標識符以后，就需要對軟件只能夠涉及到的、需要管理的對象進行劃分，在此，將SNMS這個系統分為system、user和file三部分，分別定義為system（1）、user（2）和file（3），如圖4所示。

?

4.3 Trap模塊的實現

為了使軟件在設備出現事件時能得到通知，在SNMP這個背景下就意味著需要一種能夠接收Trap的機制。設備在自己所能夠支持的事件范圍內，通過定義不同含義的Trap報文，按照設備自身所配置的接收對象將Trap發送出去。

SNMP協議不同的版本對應著不同的Trap格式。然而對SNMS自身來說，這些Trap的版本并沒有什么意義，軟件所需要的僅僅是必要的標識和對應標識的意義。所以需要一種機制將這些版本的Trap進行統一。

軟件采用的方式是使用中間層來代理。使用TrapMonitor來偵聽所有版本的Trap，通過不同的處理最終觸

發TrapComing事件，并將處理之后生成的TrapInfoEventArgs傳入，供訂閱者使用。

4.3.2 Trap信息翻譯

Trap包含的信息成百上千，若都由軟件來解析其信息將是一件非常耗時且龐大的工程。況且由于SNMP自身的可擴展性，軟件無法預測其后出現的新Trap定義，所以考慮這樣一種機制：對Trap進行建模，將其核心抽象為一種可擴展可配置的模式。

這種機制使得軟件可以輕松適應不同的場景，而且部署起來也很方便。軟件自身也集成了Trap信息的配置功能，可以避免手動接觸XML文件。

如何過濾出有用的Trap信息非常關鍵，這是由系統的“管理”性質決定的。系統決定采用一種類似于網絡ACL的做法，提出了白名單和黑名單的過濾模式。類似于Trap信息翻譯，系統也采用了基于XML的做法，將過濾規則保存在更加靈活部署的XML文件中。這里白名單是指所有Trap到達后只顯示名單中規則匹配的Trap；黑名單是指所有Trap到達后不顯示規則匹配的Trap。

5 測試及部署

最終的測試環境選用了最為常用的網絡設備——中型路由式數據交換網絡。環境使用5臺Cisco 7200路由器與7臺Cisco 3640交換機搭建，并配置了相關的路由協議，最后開啟SNMP功能和Trap功能。

系統對“中型路由式數據交換網絡”環境進行拓撲發現，測試效果如圖5所示。

圖6是在一個真實網絡環境中進行系統測試得到的網絡拓撲。

作為基于SNMP的上層應用軟件系統，軟件除了實現核心的拓撲發現機制與拓撲布局外，還不斷地完善軟件框架，使其能適應不同的上層開發。軟件理想的演進路線是做成一個基于SNMP的基礎框架，在此框架之上可以不斷地擴充應用。由于SNMP協議本身的成熟性，這種需求的框架有著很大的潛力。