以下內容轉自某論壇的高人回覆，看了很有收穫，特貼於此。
第4章 SNMP網絡管理體系結構
CMIP網絡管理體系結構對系統模型、信息模型和通信協議幾個方面都提出了比較完備和理想的解決方案，爲其他網絡管理體系結構建立了理想參考標準。SNMP網絡管理體系結構是爲了管理基於TCP/IP協議的網絡而提出的，與TCP/IP協議與OSI協議的關係類似，SNMP與CMIP相比，突出的特點是簡單。這一特點使SNMP得到了廣泛的支持和應用，特別是在Internet上的成功應用，使得它的重要性越來越突出，目前已經成爲CMIP之外的最重要的網絡管理體系結構。
4.1 SNMP體系結構
4.1.1 TCP/IP網絡管理的發展
在TCP/IP的早期開發中，網絡管理問題並未得到太大的重視。直到70年代，還一直沒有網絡管理協議，只有互聯網絡控制信息協議(ICMP)可以作爲網絡管理的工具。ICMP提供了從路由器或其它主機向主機傳送控制信息的方法，可用於所有支持IP的設備。從網絡管理的觀點來看，ICMP最有用的特性是回聲(echo)和回聲應答(echo reply)消息對。這個消息對爲測試實體間能否通信提供了一個機制。echo消息要求其接收者在echo reply消息中返回接收到的內容。另一個有用的消息對是時間戳(timestamp)和時間戳應答(timestamp reply)，這個消息對爲測試網絡延遲特性提供了機制。
與各種IP頭選項結合，這些ICMP消息可用來開發一些簡單有效的管理工具。典型的例子是廣泛應用的分組互聯網絡探索(PING)程序。利用ICMP加上另外的選項如請求間隔和一個請求的發送次數，PING能夠完成多種功能。包括確定一個物理網絡設備能否尋址，驗證一個網絡能夠尋址，和驗證一個主機上的服務器操作。
PING在一些工具的配合下滿足了TCP/IP網絡初期的管理要求。但是到了80年代後期，當互聯網絡的發展呈指數增加時，人們感到需要開發比PING功能更強並易於普通網絡管理人員學習和使用的標準協議。因爲當網絡中的主機數量上百萬，獨立網絡數量上千的時候，已不能只依靠少數網絡專家解決管理問題了。
1987年11月發佈了簡單網關監控協議(SGMP)，成爲提供專用網絡管理工具的起點。SGMP提供了一個直接監控網關的方法。隨着對通用網絡管理工具需求的增長，出現了3個有影響的方法。
1.高層實體管理系統(HEMS)：主機監控協議(HMP)的一般化。
2.簡單網絡管理協議(SNMP)：SGMP的升級版。
3.TCP/IP上的CMIP(CMOT)：最大限度地與OSI標準的CMIP、服務以及數據庫結構保持一致。
1988年，互聯網絡活動會議(IAB)確定了將SNMP作爲近期解決方案進一步開發，而把CMOT作爲遠期解決方案的策略。當時普遍認爲：TCP/IP不久將會過渡到OSI，因而不應在TCP/IP的應用層協議和服務上花費太多的精力。SNMP開發速度快，並能爲網絡管理經驗庫的開發提供一些基本的工具，可用來滿足眼前的需要。
爲了強化這一策略，IAB要求SNMP和CMOT使用相同的被管對象數據庫。即在任何主機、路由器、網橋以及其它管理設備中，兩個協議都以相同的格式使用相同的監控變量。因此，兩個協議有一個公共的管理信息結構(SMI)，和一個管理信息庫MIB。
但是，人們很快發現這兩個協議在對象級的兼容是不現實的。在OSI的網絡管理中，被管對象是很成熟的，它具有屬性、相關的過程、通報以及其它一些與面向對象有關的複雜的特性。而SNMP爲了保持簡單性，沒有這樣複雜的概念。實際上，SNMP的對象在面向對象的概念下根本就不能稱爲對象，它們只是帶有一些如數據類型、讀寫特性等基本特性的變量。因此IAB最終放鬆了公共SMI/MIB的條件，並允許SNMP獨立於CMOT發展。
從對OSI的兼容性的束縛中解脫後，SNMP取得了迅速的發展，很快被衆多的廠商設備所支持，並在互聯網絡中活躍起來。而且，普通用戶也選擇了SNMP作爲標準的管理協議。
SNMP最重要的進展是遠程監控(RMON)能力的開發。RMON爲網絡管理者提供了監控整個子網而不是各個單獨設備的能力。除了RMON，還對基本SNMP MIB進行了擴充。有些擴充採用標準的網絡接口，例如令牌環(token ring)和光纖分佈數據接口(FDDI)，這種擴充是獨立於廠商的。
但是，單靠定義新的或更細緻的MIB擴充SNMP是有限的。當SNMP被用於大型或複雜網絡時，它在安全和功能方面的不足就變得明顯了。爲了彌補這些不足，1992年7月發表了3個增強SNMP安全性的文件作爲建議標準。增強版與原來的SNMP是不兼容的，它需要改變外部消息句柄及一些消息處理過程。但實際定義協議操作幷包含SNMP消息的協議數據單元(PDU)保持不變，並且沒有增加新的PDU。目的是儘量實現向SNMP的安全版本的平滑過渡。
但是這個增強版受到了另一個方案的衝擊。同樣是在1992年7月，四名SNMP的關鍵人物提出一個稱爲SMP的SNMP新版本。並實現了四個可互操作的方案。兩個是商業產品，兩個是公開軟件。SMP在功能和安全性兩方面提高了SNMP，特別是SMP增加了一些PDU。所有的消息頭和安全功能都與提議的安全性增強標準相似。最終SMP被接受爲定義第二代SNMP即SNMPv2的基礎。1993年安全版SNMPv2發佈。
經過幾年試用以後，IETF(Internet Engineering Task Force) 決定對SNMPv2進行修訂。1996年發佈了一組新的RFC (Request For Comments)，在這組新的文檔中，SNMPv2的安全特性被取消了，消息格式也重新採用SNMPv1的基於“共同體(community)”概念的格式。
刪除SNMPv2中的安全特性是SNMPv2發展過程中最大的失敗。主要原因是廠商和用戶對1993版的SNMPv2的安全機制不感興趣，同時IETF要求的修訂時間也非常緊迫，設計者們來不及對安全機制進行改善，甚至來不及對存在的嚴重缺陷進行修改。因此不得不在1996年版的SNMPv2中放棄了安全特性。
1999年4月IETF SNMPv3工作組提出了RFC2571～RFC2576，形成了SNMPv3的建議。目前，這些建議正在進行標準化。SNMPv3提出了SNMP管理框架的一個統一的體系結構。在這個體系結構中，採用User-based安全模型和View-based訪問控制模型提供SNMP網絡管理的安全性。安全機制是SNMPv3的最具特色的內容。
4.1.2 SNMP基本框架
1) 網絡管理體系結構
SNMP的網絡管理模型包括以下關鍵元素：管理站、代理者、管理信息庫、網絡管理協議。管理站一般是一個分立的設備，也可以利用共享系統實現。管理站被作爲網絡管理員與網絡管理系統的接口。它的基本構成爲：
・一組具有分析數據、發現故障等功能的管理程序；
・一個用於網絡管理員監控網絡的接口；
・將網絡管理員的要求轉變爲對遠程網絡元素的實際監控的能力；
・一個從所有被管網絡實體的MIB中抽取信息的數據庫。
網絡管理系統中另一個重要元素是代理者。裝備了SNMP的平臺，如主機、網橋、路由器及集線器均可作爲代理者工作。代理者對來自管理站的信息請求和動作請求進行應答，並隨機地爲管理站報告一些重要的意外事件。
與CMIP體系相同，網絡資源也被抽象爲對象進行管理。但SNMP中的對象是表示被管資源某一方面的數據變量。對象被標準化爲跨系統的類，對象的集合被組織爲管理信息庫（MIB）。MIB作爲設在代理者處的管理站訪問點的集合，管理站通過讀取MIB中對象的值來進行網絡監控。管理站可以在代理者處產生動作，也可以通過修改變量值改變代理者處的配置。
管理站和代理者之間通過網絡管理協議通信，SNMP通信協議主要包括以下能力：
Get：管理站讀取代理者處對象的值；
Set：管理站設置代理者處對象的值；
Trap：代理者向管理站通報重要事件。
在標準中，沒有特別指出管理站的數量及管理站與代理者的比例。一般地，應至少要有兩個系統能夠完成管理站功能，以提供冗餘度，防止故障。另一個實際問題是一個管理站能帶動多少代理者。只要SNMP保持它的簡單性，這個數量可以高達幾百。
2) 網絡管理協議體系結構
SNMP爲應用層協議，是TCP/IP協議族的一部分。它通過用戶數據報協議(UDP)來操作。在分立的管理站中，管理者進程對位於管理站中心的MIB的訪問進行控制，並提供網絡管理員接口。管理者進程通過SNMP完成網絡管理。SNMP在UDP、IP及有關的特殊網絡協議(如，Ethernet, FDDI, X.25)之上實現。
每個代理者也必須實現SNMP、UDP和IP。另外，有一個解釋SNMP的消息和控制代理者MIB的代理者進程。
圖4.1 SNMP的協議環境
圖4.1描述了SNMP的協議環境。從管理站發出3類與管理應用有關的SNMP的消息GetRequest、GetNextRequest、SetRequest。3類消息都由代理者用GetResponse消息應答，該消息被上交給管理應用。另外，代理者可以發出Trap消息，向管理者報告有關MIB及管理資源的事件。
由於SNMP依賴UDP，而UDP是無連接型協議，所以SNMP也是無連接型協議。在管理站和代理者之間沒有在線的連接需要維護。每次交換都是管理站和代理者之間的一個獨立的傳送。
3) 陷阱引導輪詢(Trap-directed polling)
如果管理站負責大量的代理者，而每個代理者又維護大量的對象，則靠管理站及時地輪詢所有代理者維護的所有可讀數據是不現實的。因此管理站採取陷阱引導輪詢技術對MIB進行控制和管理。
所謂陷阱引導輪詢技術是：在初始化時，管理站輪詢所有知道關鍵信息(如接口特性、作爲基準的一些性能統計值，如發送和接收的分組的平均數)的代理者。一旦建立了基準，管理站將降低輪詢頻度。相反地，由每個代理者負責向管理站報告異常事件。例如，代理者崩潰和重啓動、連接失敗、過載等。這些事件用SNMP的trap消息報告。
管理站一旦發現異常情況，可以直接輪詢報告事件的代理者或它的相鄰代理者，對事件進行診斷或獲取關於異常情況的更多的信息。
陷阱引導輪詢可以有效地節約網絡容量和代理者的處理時間。網絡基本上不傳送管理站不需要的管理信息，代理者也不會無意義地頻繁應答信息請求。
4) 代管(Proxies)
利用SNMP需要管理站及其所有代理者支持UDP和IP。這限制了在不支持TCP/IP協議的設備(如網橋、調制解調器)上的應用。並且，大量的小系統(PC、工作站、可編程控制器)雖然支持TCP/IP協議，但不希望承擔維護SNMP、代理者軟件和MIB的負擔。
爲了容納沒有裝載SNMP的設備，SNMP提出了代管的概念。在這個模式下，一個SNMP的代理者作爲一個或多個其他設備的代管人。即，SNMP代理者爲託管設備(proxied devices)服務。
圖4.2顯示了常見的一類協議體系結構。管理站向代管代理者發出對某個設備的查詢。代管代理者將查詢轉變爲該設備使用的管理協議。當代理者收到對一個查詢的應答時，將這個應答轉發給管理站。類似地，如果一個來自託管設備的事件通報傳到代理者，代理者以陷阱消息的形式將它發給管理站。
圖4.2 SNMP協議體系結構
4.2 SNMP 管理信息
與CMIP體系相同，SNMP的基礎是包含被管元素信息的被稱爲MIB的數據庫。每個被管資源由對象來表示，MIB是這些對象的有結構的集合。在SNMP中，MIB本質上是一個樹型的數據庫結構。網絡中每個的系統都（工作站、服務器、路由器、網橋等）擁有一個反映系統中被管資源狀態的MIB。網絡管理實體可以通過提取MIB中的對象值監測系統中的資源，也可以通過修改這些對象值來控制資源。
4.2.1 管理信息結構
SNMP的規範SMI（structure of management information）爲定義和構造MIB提供了一個通用的框架。同時也規定了可以在MIB中使用的數據類型，說明了資源在MIB中怎樣表示和命名。SMI的基本指導思想是追求MIB的簡單性和可擴充性。因此，MIB只能存儲簡單的數據類型：標量和標量的二維矩陣。我們將看到SNMP只能提取標量，包括表中的單獨的條目。
SMI避開復雜的數據類型是爲了降低實現的難度和提高互操作性。但在MIB中不可避免地包含廠家建立的數據類型，如果對這樣的數據類型的定義沒有嚴格的限制，互操作性也會受到影響。
爲了提供一個標準的方法來表示管理信息，SMI必須：
l 提供一個標準的技術定義MIB的具體結構;
l 提供一個標準的技術定義各個對象，包括句法和對象值;
l 提供一個標準的技術對對象值進行編碼。
1) MIB結構
SNMP中的所有的被管對象都被排列在一個樹型結構之中。處於葉子位置上的對象是實際的被管對象，每個實際的被管對象表示某些被管資源、活動或相關信息。樹型結構本身定義一個將對象組織到邏輯上相關的集合之中的方法。
MIB中的每個對象類型都被賦予一個對象標識符(OBJECT IDENTIFIER)，以此來命名對象。另外，由於對象標識符的值是層次結構的，因此命名方法本身也能用於確認對象類型的結構。
對象標識符是能夠唯一標識某個對象類的符號。它的值由一個整數序列構成。被定義的對象的集合具有樹型結構，樹根是引用ASN.1標準的對象。從對象標識符樹的樹根開始，每個對象標識符成分的值指定樹中的一個弧。從樹根開始，第一級有3個節點:iso、ccitt、joint-iso-ccitt。在iso節點下面有一個爲“其他組織”使用的子樹，其中有一個美國國防部的子樹(dod)。SNMP在dod之下設置一個子樹用於Internet的管理。如下所示:
internet OBJECT IDENTIFIER :: = { iso (1) org (3) dod (6) 1}
因此，internet節點的對象標識符的值是1.3.6.1。這個值作爲internet子樹的下級節點標識符的前綴。
SMI在internet節點之下定義了4個節點:
l directory 爲與OSI的directory相關的將來的應用保留的節點
l mgmt 用於在IAB批准的文檔中定義的對象
l experimental 用於標識在Internet實驗中應用的對象
l private 用於標識單方面定義的對象
mgmt子樹包含IAB已經批准的管理信息庫的定義。現在已經開發了兩個版本的MIB，mib-1和和它的擴充版mib-2。二者子樹中的對象標識符是相同的，因爲在任何配置中，只有一個MIB。
MIB中的mib-1或mib-2以外的對象可以用以下方法定義:
l 由一個全新的修訂版(如mib-3)來擴充或取代mib-2。
l 可以爲特定的應用構造一個實驗MIB。這樣的對象隨後會被移到mgmt子樹之下。例如定義包含各種傳輸媒體的MIB(例如爲令牌環局域網定義的MIB)。
l 專用的擴充可以加在private子樹之下。
private子樹目前只定義了一個子節點enterprises，用於廠商加強對自己設備的管理，與用戶及其他廠商共享信息。在enterprises子樹下面，每個註冊了enterprise對象標識符的廠商有一個分支。
internet節點之下分爲4個子樹的做法爲MIB的進化提供了很好的基礎。通過對新對象的實驗，廠商能夠在其被接受爲mgmt的標準之前有效地獲得大量的實際知識。因此這樣的MIB既是對管理符合標準的對象直接有效的，對適應技術和產品的變化也是靈活的。這一點也反映了TCP/IP協議的如下特性：協議在成爲標準之前進行大量的實驗性的使用和調測。
圖4.3 對象標識符樹型結構
2) 對象句法
SNMP MIB中的每個對象都由一個形式化的方法定義，說明對象的數據類型、取值範圍以及與MIB中的其他對象的關係。各個對象以及MIB的整體結構都由ASN.1描述法定義。爲了保持簡單，只利用了ASN.1的元素和特徵的一個有限的子集。
UNIVERSAL類型:ASN.1的UNIVERSAL類由獨立於應用的通用數據類型組成。其中只有以下數據類型被允許用於定義MIB對象:
l integer (UNIVERSAL 2)
l octetstring (UNIVERSAL 4)
l null (UNIVERSAL 5)
l object identifier (UNIVERSAL 6)
l sequence, sequence-of (UNIVERSAL 16)
前3個是構成其他對象類型的基本類型。
object identifier唯一標識對象的符號，由一個integer序列組成，序列中的integer被稱爲子標識符。對象標識符的integer序列從左到右，定義了對象在MIB樹型結構中的位置。
sequence 和sequence-of 用於構成表。
APPLICATION-WIDE 類型:ASN.1的APPLICATION類由與特定的應用相關的數據類型組成。每個應用，包括SNMP,負責定義自己的APPLICATION數據類型。在SNMP中已經定義了以下數據類型:
l networkaddress: 該類型用CHOICE結構定義，允許從多個協議族的地址格式中進行選擇。目前，只定義了IpAddress一種地址格式。
l ipaddress: IP格式的32位地址。
l counter: 只能做增值不能做減值運算的非負整數。最大值被設爲232 ?1，當達到最大值時，再次從0開始增加。
l gauge: 可做增值也可做減值運算的非負整數。最大值被設爲232 ?1，當達到最大值時被鎖定，直至被複位(reset)。
l timeticks: 從某一參照時間開始以百分之一秒爲單位計算經歷的時間的非負整數。當MIB中定義的某個對象類用到這個數據類型時，參照時間在該對象類的定義中指出。
l opaque: 該數據類型提供一個傳遞任意數據的能力。數據在傳輸時被作爲OCTET STRING編碼。被傳遞的數據本身可以是由ASN.1或其他句法定義的任意的格式。
3) 定義對象
管理信息庫由一個對象的集合構成，每個對象都有一個型和一個值。型是對被管對象種類的定義，因此型的定義是一個句法描述。對象的實例是某類對象的一個具體實現，具有一個確定的值。
怎樣定義MIB中的對象呢？ASN.1是將被使用的描述法。ASN.1中包含一些預定義的通用類型，也規定了通過現有類型定義新類型的語法。定義被管對象的一個可選方法是定義一個被稱爲Object的新類型。這樣，MIB中所有的對象都將是這種類型的。這個方法在技術上是可行的，但會產生定義不便於應用的問題。我們需要多種值的類型，包括counter、gauge等等。另外，MIB支持二維表格或矩陣的定義。因此，一個通用的對象類型必須包含參數來對應所有這些可能性和選擇性。
另一個更有吸引力的方法，並且也是被SNMP所實際採用的方法是利用宏（macro）對在被管對象定義中相互關聯的類型進行集合定義。一個宏的定義給出相關類型集合的句法，而宏的實例定義一個特定的類型。因此定義被分爲以下等級：
l 宏：定義合法的宏實例，即說明相關集合類型的句法
l 宏實例：通過爲宏定義提供實際參數生成實例，即說明一個特定的類型
l 宏實例值：用一個特定的值來表示一個特定的實體
圖4.4是OBJECT-TYPE宏的定義(引自RFC 1212)。
圖4.4 被管對象宏
其中的主要項目是:
l SYNTAX: 對象類的抽象句法，該句法必須從SMI的對象句法類型中確定一種類型。
l ACCESS: 定義通過SNMP或其他協議訪問對象實例的方法。Access子句定義該對象類型支持的最低等級。可選的等級有:read-only、read-write、write-only和not-accessible。
l STATUS: 指出該對象在實現上的要求。要求可以是:mandatory(必須)、optional(可選)、deprecated(懇求―必須實現的對象，但很可能在新版MIB中被刪除)和obsolete(廢除―不再需要被管系統實現的對象)。
l DescrPart: 對象類型語義的文本描述。該子句是可選的。
l ReferPart: 對定義在在其他MIB模塊中的某個對象的文本型交叉引用。該子句是可選的。
l IndexPart: 用於定義表。該子句只是在對象類型對應表中的”行”時纔出現。
l DefValPart: 定義一個默認值，用於建立對象實例。該子句是可選的。
l VALUE NOTATION: 指出通過SNMP訪問該對象時使用的名字。
由於應用OBJECT-TYPE宏的MIB的完整的定義包含在MIB的冗長的文檔中，因此，人們並不常使用它們。比較常用的是更簡捷的方法―基於樹型結構和對象特性的表格表示的方法。
4) 定義表格
SMI只支持一種數據結構化方法:標量值條目的二維表格。表格的定義用到ASN.1的sequence和sequence of兩個類型和OBJECT-TYPE宏中的IndexPart。
表格定義方法可以通過實例進行說明。考慮對象類型tcpConnTable，這個對象包含由相應的被管實體維護的TCP connections的信息。對於每個這樣的connection，以下信息在表中存儲:
l state: TCP connection的狀態
l local address: 該connection的本端的IP地址
l local port: 該connection的本端的TCP端口
l remote address: 該connection的另一端的IP地址
l remote port: 該connection的另一端的TCP端口
需要注意的是，tcpConnTable是存放在某個被管系統維護的MIB中。因此，tcpConnTable中的一個條目對應被管系統中的一個connection的狀態信息。TCP connection的狀態信息有22個項目，按照tcpConnTable的定義，只有上述5個項目對網絡管理者來說是可見的。這也體現了SNMP強調保持網絡管理簡單性的特點。即，在被管對象中，只包含相對應的被管實體的有限的和有用的信息。
圖4.5給出了tcpConnTable的定義(引自RFC1213)。
圖4.5 TCP connection Table
在圖4.5中，可以看到sequence 和sequence of 在定義表格時的應用:
l 整個表由一個SEQUENCE OF TcpConnEntry構成。ASN.1的結構SEQUENCE OF由一個或多個相同的元素構成，在本例中(在所有的SNMP SMI的情況下)每個元素是表中的一行。
l 每一行由一個指定了5個標量元素的SEQUENCE構成。ASN.1的結構SEQUCECE由固定數目的元素組成，元素的類型可以是多種。儘管ASN.1允許這些元素是可選的，但SMI限制這個結構只能使用“mandatory”元素。在本例中，每一行所包含的元素的類型是INTEGER, IpAddress, INTEGER, IpAddress, INTERGE。
tcpConnEntry定義中的INDEX成分確定哪個對象值將被用於區分表中的各行。在TCP中，一個socket (IP地址，TCP端口)可以支持多個connection，而任意一對sockets之間同時只能有一個connection。因此爲了明確地區分各行，每行中的後4個元素是必要的，也是充分的。
4.2.2 MIB-II
在TCP/IP網絡管理的建議標準中，提出了多個相互獨立的MIB，其中包含爲Internet的網絡管理而開發的MIB-II。鑑於它在說明標準MIB的結構、作用和定義方法等方面的重要性和代表性，有必要對其進行比較深入的討論。
MIB-II是在MIB-I的基礎之上開發的，是MIB-I的一個超集。mib-2組被分爲以下分組:
l system:關於系統的總體信息;
l interface:系統到子網接口的信息;
l at (address translation):描述internet到subnet的地址映射;
l ip:關於系統中IP的實現和運行信息;
l icmp:關於系統中ICMP的實現和運行信息;
l tcp:關於系統中TCP的實現和運行信息;
l udp:關於系統中UDP的實現和運行信息;
l egp:關於系統中EGP的實現和運行信息;
l dot3(transmission):有關每個系統接口的傳輸模式和訪問協議的信息。
l snmp:關於系統中SNMP的實現和運行信息。
1) system 組
system組提供有關被管系統的總體信息。表4.1列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.1 system組中的對象
Object Syntax Access Description
sysDescr DisplayString (SIZE(0 … 255)) RO 對實體的描述，如硬件、操作系統等
sysObjectID OBJECT IDENTIFIER RO 實體中包含的網絡管理子系統的廠商標識
sysUpTime TimeTicks RO 系統的網絡管理部分本次啓動以來的時間
sysContect DisplayString (SIZE(0 … 255)) RW 該被管節點負責人的標識和聯繫信息
sysName DisplayString (SIZE(0 … 255)) RW 該被管節點被賦予的名稱
sysLocation DisplayString (SIZE(0 … 255)) RW 該節點的物理地點
sysService INERGER(0 … 127) RO 指出該節點所提供的服務的集合，7個bit對應7層服務
2) interfaces 組
interfaces組包含實體物理接口的一般信息，包括配置信息和各接口中所發生的事件的統計信息。表4.2列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.2 interfaces組中的對象
Object Syntax Access Description
ifNumber INTEGER RO 網絡接口的數目
ifTable SEQUENCE OF ifEntry NA 接口條目清單
ifEntry SEQUENCE NA 包含子網及其以下層對象的接口條目
ifIndex INTEGER RO 對應各個接口的唯一值
ifDescr DisplayString (SIZE(0 … 255)) RO 有關接口的信息，包括廠商、產品名稱、硬件接口版本
ifType INTEGER RO 接口類型，根據物理或鏈路層協議區分
ifMtu INERGER RO 接口可接收或發送的最大協議數據單元的尺寸
ifSpeed Gauge RO 接口當前數據速率的估計值
ifPhysAddress PhysAddress RO 網絡層之下協議層的接口地址
ifAdminStatus INTEGER RW 期望的接口狀態 (up(1), down(2), testing(3))
ifOperStatus INTEGER RO 當前的操作接口狀態 (up(1), down(2), testing(3))
ifLastChange TimeTicks RO 接口進入當前操作狀態的時間
ifInOctets Counter RO 接口收到的8元組的總數
ifInUcastPkts Counter RO 遞交到高層協議的子網單播的分組數
ifInNUcastPkts Counter RO 遞交到高層協議的非單播的分組數
ifInDiscards Counter RO 被丟棄的進站分組數
ifInErrors Counter RO 有錯的進站分組數
ifInUnkownProtos Counter RO 由於協議未知而被丟棄的分組數
ifOutOctets Counter RO 接口發送的8元組的總數
ifOutUcastPkts Counter RO 發送到子網單播地址的分組總數
ifOutNUcastPkts Counter RO 發送到非子網單播地址的分組總數
ifOutDiscards Counter RO 被丟棄的出站分組數
ifOutErrors Counter RO 不能被髮送的有錯的分組數
ifOutQLen Gauge RO 輸出分組隊列長度
ifSpecific OBJECT IDENTIFIER RO 參考MIB對實現接口的媒體的定義
3) address translation 組
address translation組由一個表構成，表中的每一行對應系統中的一個物理接口，提供網絡地址向物理地址的映射。一般情況下，網絡地址是指系統在該接口上的IP地址，而物理地址決定於實際採用的子網情況。例如，如果接口對應的是LAN，則物理地址是接口的MAC地址，如果對應X.25分組交換網，則物理地址可能是一個X.121地址。表4.3列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.3 address translation組中的對象
Object Syntax Access Description
atTable SEQUENCE OF AtEntry NA 包含網絡地址對物理地址的映射
atEntry SEQUENCE NA 包含一個網絡地址、物理地址對
atIfIndex INTEGER RW 表格條目的索引
atPhysAddress PhysAddress RW 依賴媒體的物理地址
atNetAddress NetworkAddress RW 對應物理地址的網絡地址
實際上，address translation組包含在MIB-II中只是爲了與MIB-I兼容，MIB-II的地址轉換信息在各個網絡協議組中提供。
4) ip 組
ip組包含有關節點上IP實現和操作的信息，如有關IP層流量的一些計數器。ip組中包含3個表，ipAddrTable、ipRouteTalbe和ipNetToMediaTable。
ipAddrTable包含分配給該實體的IP地址的信息，每個地址被唯一地分配給一個物理地址。
ipRouteTable包含用於互聯網路由選擇的信息。該路由表中信息是比較原本地從一些協議的路由表中抽取而來的。實體當前所知的每條路由都有一個條目，表格由ipRouteDest索引。ipRouteTable中的信息可用於配置的監測，並且由於表中的對象是read-write的，因此也可被用於路由控制。
ipNetToMediaTable是一個提供IP地址和物理地址之間對應關係的地址轉換表。除了增加一個指示映射類型的對象ipNetToMediaType之外，表中所包含的信息與address translation組相同。
此外，ip組中還包含一些用於性能和故障監測的標量對象。
表4.4列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.4 ip組中的對象
Object Syntax Access Description
ipForwarding INTEGER RW 是否作爲IP網關（1/0）
ipDefaultTTL INTEGER RW 插入到該實體生成的數據報的IP頭中Time-To-Live字段中的默認值
ipInReceives Counter RO 接口收到的輸入數據報的總數
ipInHdrErrors Counter RO 由於IP頭錯被丟棄的輸入數據報總數
ipInAddrErrors Counter RO 由於IP地址錯被丟棄的輸入數據報總數
ipForwDatagrams Counter RO 轉發的輸入數據報數
ipInUnknownProtos Counter RO 由於協議未知被丟棄的輸入數據報數
ipInDiscards Counter RO 無適當理由而被丟棄的輸入數據報數
ipInDelivers Counter RO 成功地遞交給IP用戶協議的輸入數據報數
ipOutRequests Counter RO 本地IP用戶協議要求傳輸的IP數據報總數
ipOutNoRoutes Counter RO 由於未找到路由而被丟棄的IP數據報數
ipReasmTimeOut INTEGER RO 重組接收到的碎片可等待的最大秒數
ipReasmReqds Counter RO 接收到的需要重組的IP碎片數
ipReasmOKs Counter RO 成功重組的IP數據報數
ipRaesmFails Counter RO 由IP重組算法檢測到的重組失敗的數目
ipFragsOk Counter RO 成功拆分的IP數據報數
ipFragsFails Counter RO 不能成功拆分而被丟棄的IP數據報數
ipFragsCreates Counter RO 本實體產生的IP數據報碎片數
ipAddrTable SEQUENCE OF IpAddrEntry NA 本實體的IP地址信息(表內對象略)
ipRouteTable SEQUENCE OF IpRouteEntry NA IP 路由表(表內對象略)
ipNetToMediaTable SEQUENCE OF IpNetToMedis Entry NA 用於將IP 映射到物理地址的地址轉換表(表內對象略)
IpRouting Discards Counter RO 被丟棄的路由選擇條目
5) icmp 組
ICMP (Internet Control Message Protocol)是TCP/IP協議族中的一部分，所有實現IP協議的系統都提供ICMP。ICMP提供從路由器或其他主機向主機傳遞消息的手段，它的基本作用是反饋通信環境中存在的問題，例如:數據報不能到達目的地，路由器沒有緩衝區容量來轉發數據報。
icmp組包含有關一個節點的ICMP的實現和操作的信息，具體地講，icmp組由節點接收和發送的各種ICMP消息的計數器所構成由一個表構成。表4.5列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.5 icmp組中的對象
Object Syntax Access Description
icmpInMsgs Counter RO 收到的ICMP消息的總數
icmpInErrors Counter RO 收到的有錯的ICMP的消息數
icmpInDestUnreachs Counter RO 收到的目的地不可到達的消息數
icmpInTimeExcds Counter RO 收到的超時的消息數
icmpInParmProbs Counter RO 收到的有參數問題的消息數
icmpInSrcQuenchs Counter RO 收到的源有問題的消息數
icmpInRedirects Counter RO 收到的重定向的消息數
icmpInEchos Counter RO 收到的要求echo的消息數
icmpInEchoReps Counter RO 收到的應答echo的消息數
icmpInTimestamps Counter RO 收到的要求Timestamp的消息數
icmpInTimestampReps Counter RO 收到的應答Timestamp的消息數
icmpInAddrMasks Counter RO 收到的要求Address Mask的消息數
icmpInAddrMaskReps Counter RO 收到的應答Address Mask的消息數
icmpOutMsgs Counter RO 發出的ICMP消息的總數
icmpOutErrors Counter RO 發出的有錯的ICMP的消息數
icmpOutDestUnreachs Counter RO 發出的目的地不可到達的消息數
icmpOutTimeExcds Counter RO 發出的超時的消息數
icmpOutParmProbs Counter RO 發出的有參數問題的消息數
icmpOutSrcQuenchs Counter RO 發出的源有問題的消息數
icmpOutRedirects Counter RO 發出的重定向的消息數
icmpOutEchos Counter RO 發出的要求echo的消息數
icmpOutEchoReps Counter RO 發出的應答echo的消息數
icmpOutTimestamps Counter RO 發出的要求Timestamp的消息數
icmpOutTimestampReps Counter RO 發出的應答Timestamp的消息數
icmpOutAddrMasks Counter RO 發出的要求Address Mask的消息數
icmpOutAddrMaskReps Counter RO 發出的應答Address Mask的消息數
6) tcp 組
tcp組包含有關一個節點的TCP的實現和操作的信息，圖4.5定義的tcpConnTable包含在這個組中。表4.6列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.6 tcp組中的對象
Object Syntax Access Description
tcpRtoAlgorithm INTEGER RO 重傳時間
tcpRtoMin INTEGER RO 重傳時間的最小值
tcpRtoMax INTEGER RO 重傳時間的最大值
tcpMaxConn INTEGER RO 實體支持的TCP連接數的上限
tcpActiveOpens Counter RO 實體已經支持的主動打開的數量
tcpPassiveOpens Counter RO 實體已經支持的被動打開的數量
tcpAttemptFails Counter RO 已經發生的試連失敗的次數
tcpEstabResets Counter RO 已經發生的復位的次數
tcpCurrEstab Gauge RO 當前狀態爲established的TCP連接數
tcpInSegs Counter RO 收到的segments總數
tcpOutSegs Counter RO 發出的segments總數
tcpRetranSegs Counter RO 重傳的segments總數
tcpConnTable SEQUENCE OF TcpConnTntry NA 包含TCP各個連接的信息(表內對象略，參考圖4.5)
tcpInErrors Counter RO 收到的有錯的segments的總數
tcpOutRsts Counter RO 發出的含有RST標誌的segments數
7) udp 組
udp組包含有關一個節點的UDP的實現和操作的信息。除了有關發送和接收的數據報的信息之外，這個組中還包含一個udpTable表，該表中包含UDP端點的管理信息。所謂UDP端點是指正在支持本地應用接收數據報的UDP進程。udpTable表中包含每個UDP端點用戶的IP地址和UDP端口。表4.7列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.7 udp組中的對象
Object Syntax Access Description
udpInDatagrams Counter RO 遞交該UDP用戶的數據報的總數
udpNoPorts Counter RO 收到的目的端口上沒有應用的數據報總數
udpInErrors Counter RO 收到的無法遞交的數據報數
udpOutDatagrams Counter RO 該實體發出的UDP數據報總數
udpTable SEQUENCE OF UdpEntry NA 包含UDP的用戶信息
udpTable SEQUENCE NA 某個當前UDP用戶的信息
udpLocalAddress IpAddress RO UDP用戶的本地IP地址
udpLocalPort INTEGER RO UDP用戶的本地端口號
8) egp 組
egp組包含有關一個節點的EGP(External Gateway Protocol)的實現和操作的信息。除了有關發送和接收的EGP消息的信息之外，這個組中還包含一個egpNeighTable表，該表中包含有關相鄰網關的信息。表4.8列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.8 egp組中的對象
Object Syntax Access Description
egpInMsgs Counter RO 收到的無錯的EGP消息數
egpInErrors Counter RO 收到的有錯的EGP消息數
egpOutMsgs Counter RO 本地產生的EGP消息總數
egpOutErrors Counter RO 由於資源限制沒有發出的本地產生的EGP消息數
egpNeighTable SEQUENCE OF EgpNeighEntry NA 相鄰網關的EGP表(表內的對象略)
egpAs INTEGER RO 本EGP實體的自治系統數
4.3 簡單網絡管理協議(SNMP)
4.3.1 SNMP支持的操作
SNMP只支持對變量的檢查和修改的操作，具體地，可以對標量對象進行以下三種操作：
l Get：管理站從被管理站提取標量對象值。
l Set：管理站更新被管理站中的標量對象值。
l Trap：被管理站向管理站主動地發送一個標量對象值。
MIB的結構不能通過增加或減少對象實例被改變，並且，訪問只能對對象標識樹中的葉子對象進行。這些限制大大簡化了SNMP的實現，但同時也限制了網絡管理系統的能力。
4.3.2 共同體和安全控制
網絡管理是一種分佈式的應用。與其他分佈式的應用相同，網絡管理中包含由一個應用協議支持的多個應用實體的相互作用。在SNMP網絡管理中，這些應用實體就是採用SNMP的管理站應用實體和被管理站的應用實體。
SNMP網絡管理具有一些不同於其他分佈式應用的特性，它包含一個管理站和多個被管理站之間一對多的關係。即，管理站能夠獲取和設置各管理站的對象，能夠從各被管理站中接收陷阱信息。因此，從操作或控制的角度來看，管理站管理着多個被管理站。同時，系統中也可能有多個管理站，每個管理站都管理所有的或一部分被管理站。
反過來，我們也要看到SNMP網絡管理中還包含另外一種一對多的關係―一個被管理站和多個管理站之間的關係。每個被管理站控制着自己的本地MIB，同時必須能夠控制多個管理站對這個本地MIB的訪問。這裏所說的控制有以下三個方面:
l 認證服務:將對MIB的訪問限定在授權的管理站的範圍內;
l 訪問策略:對不同的管理站給予不同的訪問權限;
l 代管服務:一個被管理站可以作爲其他一些被管理站(託管站)的代管，這就要求在這個代管系統中實現爲託管站服務的認證服務和訪問權限。
以上這些控制都是爲了保證網絡管理信息的安全，即被管系統需要保護它們的MIB不被非法地訪問。SNMP通過共同體(community)的概念提供了初步的和有限的安全能力。
SNMP用共同體來定義一個代理者和一組管理者之間的認證、訪問控制和代管的關係。共同體是一個在被管系統中定義的本地的概念。被管系統爲每組可選的認證、訪問控制和代管特性建立一個共同體。每個共同體被賦予一個在被管系統內部唯一的共同體名，該共同體名要提供給共同體內的所有的管理站，以便它們在get和set操作中應用。代理者可以與多個管理站建立多個共同體，同一個管理站可以出現在不同的共同體中。
由於共同體是在代理者處本地定義的，因此不同的代理者處可能會定義相同的共同體名。共同體名相同並不意味者共同體有什麼相似之處，因此，管理站必須將共同體名與代理者聯繫起來加以應用。
認證服務
認證服務是爲了保證通信是可信的。在SNMP消息的情況下，認證服務的功能是保證收到的消息是來自它所聲稱的消息源。SNMP只提供一種簡單的認證模式:所有由管理站發向代理者的消息都包含一個共同體名，這個名字發揮口令的作用。如果發送者知道這個口令，則認爲消息是可信的。
通過這種有限的認證形式，網絡管理者可以對網絡監控(set、trap)特別是網絡控制(set)操作進行限制。共同體名被用於引發一個認證過程，而認證過程可以包含加密和解密以實現更安全的認證。
訪問策略
通過定義共同體，代理者將對它的MIB的訪問限定在了一組被選擇的管理站中。通過使用多個共同體，代理者可以爲不同的管理站提供不同的MIB訪問控制。訪問控制包含兩個方面:
l SNMP MIB 視圖:MIB中對象的一個子集。可以爲每個共同體定義不同的MIB視圖。視圖中的對象子集可以不在MIB的一個子樹之內。
l SNMP 訪問模式:READ-ONLY 或 READ-WRITE。爲每個共同體定義一個訪問模式。
MIB視圖和訪問模式的結合被稱爲SNMP共同體輪廓(profile)。即，一個共同體輪廓由代理者處MIB的一個子集加上一個訪問模式構成。SNMP訪問模式統一地被用於MIB視圖中的所有對象。因此，如果選擇了READ-ONLY訪問模式，則管理站對視圖中的所有對象都只能進行read-only操作。
事實上，在一個共同體輪廓之內，存在兩個獨立的訪問限制―MIB對象定義中的訪問限制和SNMP訪問模式。這兩個訪問限制在實際應用中必須得到協調。表4.9給出了這兩個訪問限制的協調規則。注意，對象被定義爲write-only，SNMP也可以對其進行read操作。
表4.9 MIB對象定義中的ACCESS限制與SNMP訪問模式的關係
MIB對象定義中的ACCESS限制 SNMP訪問模式
READ-ONLY READ-WRITE
read-only get和trap操作有效
read-write get和trap操作有效 get，set和trap操作有效
Write-only get和trap操作有效，但操作值與具體實現有關 get，set和trap操作有效，但操作值與具體實現有關
not-accessible 無效
在實際應用中，一個共同體輪廓要與代理者定義的某個共同體聯繫起來，便構成了SNMP的訪問策略(access policy)。即SNMP的訪問策略指出一個共同體中的MIB視圖及其訪問模式。
代管服務
共同體的概念對支持代管服務也是有用的。如前所述，在SNMP中，代管是指爲其他設備提供管理通信服務的代理者。對於每個託管設備，代管系統維護一個對它的訪問策略，以此使代管系統知道哪些MIB對象可以被用於管理託管設備和能夠用何種模式對它們進行訪問。
4.3.3 實例標識
我們已經看到，MIB中的每個對象都有一個由其在樹型結構的MIB中所處的位置所定義的唯一的對象標識符。但是，應該注意到，MIB樹型結構給出的對象標識符在一些情況下只是對象類型的標識符，不能唯一地標識對象的實例。例如表格的對象標識符不能標識表格中各個條目。由於對MIB的訪問是對對象實例的訪問，因此各個對象實例都必須有唯一標識的方法。
縱列對象
表中的對象被稱爲縱列對象。縱列對象標識符不能獨自標識對象實例，因爲表中的每一行都有縱列對象的一個實例。爲了實現這類對象實例的唯一標識，SNMP實際定義了兩種技術:順序訪問技術和隨機訪問技術。順序訪問技術是通過利用辭典編排順序實現的。而隨機訪問技術是通過利用索引對象值實現的。下面首先討論隨機訪問技術。
一個表格是由零到多個行(條目)構成的，每一行都包含一組相同的標量對象類型，或稱縱列對象。每個縱列對象都有一個唯一的標識符。但由於縱列對象可能有多個實例，因此縱列對象標識符並不能唯一標識它的各個實例。然而，在定義表格時，一般包含一個特殊的縱列對象INDEX，即索引對象，它的每個實例都具有不同的值，可以用來標識表中的各行。因此，SNMP採用將索引對象值連接在縱列對象標識符之後的方法來標識縱列對象的實例。
作爲例子，我們看一下interfaces組中的ifTable。表中有一個索引對象ifIndex，它的值是一個1到ifNumber之間的整數，對應每個接口，ifIndex有一個唯一的值。現在假設要獲取系統中第2個接口的接口類型ifType。ifType的對象標識符是1.3.6.1.2.1.2.2.1.3。而第2個接口的ifIndex值是2。因此對應第2個接口的ifType的實例的標識符便爲1.3.6.1.2.1.2.2.1.3.2。即將這個ifIndex的值作爲實例標識符的最後一個子標識符加到ifType對象標識符之後。
表格及行對象
對於表格和行對象，沒有定義它們的實例標識符。這是因爲表格和行不是葉子對象，因而不能由SNMP訪問。在這些對象的MIB定義中，它們的ACCESS特性被設爲not-accessible。
標量對象
在標量對象的場合，用對象類型標識符便能唯一標識它的實例，因爲每個標量對象類型只有一個對象實例。但是，爲了與表格對象實例標識符的約定保持一致，也爲了區分對象的類型和對象實例，SNMP規定標量對象實例的標識符由其對象類型標識符加0組成。
4.3.4 辭典編纂式排序
對象標識符是反映該對象在MIB中的樹型結構的一個整數序列。給出一個MIB的樹型結構，跟蹤從root開始到某個特定對象的路徑，便可以得到該對象的對象標識符。
由於對象標識符是一個整數序列，因此，可以把它們看作是某本書的內容在書中的章節排序。總排序可以通過遍歷MIB中的對象標識符樹來生成。利用這個總排序，也可以對對象實例進行唯一的標識。
因爲網絡管理站對代理者提供MIB視圖的構成不一定完全清楚，因此，它需要一種不必提供對象名稱而能訪問對象的方法。在這種情況下，對象及其實例的排序就是非常重要的。利用這個排序，管理站可以有效地遍歷一個MIB的結構。因爲管理站只要提供樹型結構的任意一點上的一個對象實例的標識符，就可以順序地對其後繼的對象實例進行訪問。
4.3.5 SNMP消息格式
管理站和代理者之間以傳送SNMP消息的形式交換信息。每個消息包含一個指示SNMP版本號的版本號，一個用於本次交換的共同體名，和一個指出5種協議數據單元之一的消息類型。圖4.6描述了這種結構。表4.10對其中的元素進行了說明。
(a) GetRequest PDU, GetNextRequest PDU, SetRequest PDU
(b) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU
(c) Response PDU
(d) Trap PDU
(e) Variable-bindings
圖4.6 SNMP消息格式
表4.10 SNMP消息字段
字 段 描 述
version SNMP版本
community 共同體的名字用作SNMP認證消息的口令
request-id 爲每個請求賦予一個唯一的標識符
error-status noError(0),tooBig(1),noSuchName(2),badValue(3),readOnly(4),genErr(5)
error-index 當error-status非0時，可以進一步提供信息指出哪個變量引起的問題
variable-bindings 變量名及其對應值清單
enterprise 生成trap的對象的類型
agent-addr 生成trap的對象的地址
generic-trap 一般的trap類型:coldStart(0),warmStart(1),linkDown(2),linkUp(3), authentication-Failure(4),egpNeighborLoss(5),enterprise-Specific(6)
secific-triap 特定的Trap代碼
time-stamp 網絡實體從上次啓動到本trap生成所經歷的時間
SNMP消息的發送
一般情況下，一個SNMP協議實體完成以下動作向其他SNMP實體發送PDU:
l 構成PDU。
l 將構成的PDU、源和目的傳送地址以及一個共同體名傳給認證服務。認證服務完成所要求的變換，例如進行加密或加入認證碼，然後將結果返回。
l SNMP協議實體將版本字段、共同體名以及上一步的結果組合成爲一個消息。
l 用基本編碼規則(BER)對這個新的ASN.1的對象編碼，然後傳給傳輸服務。
SNMP消息的接收
一般情況下，一個SNMP協議實體完成以下動作接收一個SNMP消息
l 進行消息的基本句法檢查，丟棄非法消息
l 檢查版本號，丟棄版本號不匹配的消息
l SNMP協議實體將用戶名、消息的PDU部分以及源和目的傳輸地址傳給認證服務。如果認證失敗，認證服務通知SNMP協議實體，由它產生一個trap並丟棄這個消息;如果認證成功，認證服務返回SNMP格式的PDU。
l 協議實體進行PDU的基本句法檢查，如果非法，丟棄該PDU，否則利用共同體名選擇對應的SNMP訪問策略，對PDU進行相應處理。
變量綁定
在SNMP中，可以將多個同類操作(get、set、trap)放在一個消息中。如果管理站希望得到一個代理者處的一組標量對象的值，它可以發送一個消息請求所有的值，並通過獲取一個應答得到所有的值。這樣可以大大減少網絡管理的通信負擔。
爲了實現多對象交換，所有的SNMP的PDU都包含了一個變量綁定字段。這個字段由對象實例的一個參考序列及這些對象的值構成。某些PDU只需給出對象實例的名字，如get操作。對於這樣的PDU，接收協議實體將忽略變量綁定字段中的值。
4.3.6 GetRequest PDU
SNMP實體應網絡管理站應用程序的請求發出GetRequest PDU。發送實體將以下字段包含在PDU之中:
l PDU類型:指出GetRequest PDU類型。
l request-id:Request-id能夠使SNMP應用將得到的各個應答與發出的各個請求一一對應起來。同時也可以使SNMP實體能夠處理由於傳輸服務的問題而產生的重複的PDU。
l variablebindings:要求獲取值的對象實例清單。
GetRequest PDU 的SNMP接收實體用包含相同request-id的GetResponse PDU進行應答。GetRequest操作是原子操作―要麼所有的值都提取回來，要麼一個都不提取。
GetRequst 操作不成功的原因有對象名不匹配(noSuchName)、返回結果太長(tooBig)以及其他原因(genErr)。
SNMP只允許提取MIB樹中的葉子對象的值。因此不能只提供一個表或一個條目的名字來獲取整個表或整行的對象值。但是可以將表中每行的各個對象包含在變量綁定中，來一次獲取一行的對象值。
4.3.7 GetNextRequest PDU
GetNextRequest PDU幾乎與GetRequest PDU相同。它們具有相同交換模式和相同的格式。唯一的不同是:在GetRequest PDU中，變量綁定字段中列出的是要取值的對象實例名本身，而在GetNextRequest PDU中，變量綁定字段列出的是要取值的對象實例的“前一個”對象實例名。與GetRequest相同，GetNextRequest也是原子操作。
雖然與GetRequest的外在差異不大，但是GetNextRequest卻有GetRequest無法替代的用途。它能夠使網絡管理站去動態地發現一個MIB視圖的結構。它也爲查找不知其條目的表提供了一個有效的機制。
簡單對象值的提取
假設網絡管理站希望從某個代理者處提取udp組中的所有簡單對象，則它可以發出一個如下的PDU:
GetRequest(udpInDatagrams.0，udpNoPorts.0,udpInError.0,udpOutDatagrams.0)
如果代理者支持所有這些對象，則將返回一個包含這4個對象值的GetResponse PDU:
GetResponse((udpInDatagrams.0 = 100), (udpNoPorts.0 = 1), (udpInErrors.0 = 2),
(udpOutDatagrams.0 = 200))
這裏，100，1，2和200分別是這4個對象的值。然而，只要有一個對象不被支持，則代理者將返回一個含有錯誤碼NoSuchName的GetResponse PDU，而不返回任何其他值。爲了確保得到所有可用的對象值，管理站必須分別發出4個GetRequest PDU。
現在考慮應用GetNextRequest PDU的情況:
GetNextRequest (udpInDatagrams, udpNoPorts, udpInErrors, udpOutDatagrams)
其中，udpInDatagrams = 1.3.6.1.2.1.7.1, udpNoPorts = 1.3.6.1.2.1.7.2, udpInErrors = 1.3.6.1.2.1.7.3, udpOutDatagrams = 1.3.6.1.2.1.7.4。
在這種情況下，代理者將返回清單中每個標識符的“下一個”對象實例的值。假設4個對象都被支持，則代理者返回一個如下的GetResponse PDU:
GetResponse((udpInDatagrams.0 = 100), (udpNoPorts.0 = 1), (udpInErrors.0 = 2),
(udpOutDatagrams.0 = 200))
這與前面的情況相同。假設udpNoPorts在本視圖中是不存在(不可見)的，則代理者的應答爲:
GetResponse((udpInDatagrams.0 = 100), (udpInErrors.0 = 2), (udpInErrors.0 = 2),
(udpOutDatagrams.0 = 200))
由於udpNoPorts.0 = 1.3.6.1.2.1.7.2.0在本MIB視圖中是不存在的標識符，因此udpNoPorts的“下一個”對象實例便成了udpInError.0 = 1.3.6.1.2.1.7.3.0。
通過對比可知，GetNextRequest在提取一組對象值時比GetRequest效率更高，更靈活。
提取未知對象
GetNextRequest要求代理者提取所提供的對象標識符的下一個對象實例的值，因此，發送這類PDU時，並不要求提供MIB視圖中實際存在的對象或對象實例的標識符。利用這一特點，管理站可以使用GetNextRequest PDU去探查一個MIB視圖，並搞清它的結構。在我們上面的例子中，如果管理站發出一個GetNextRequest(udp) PDU，則將獲得 Response(udpInDatagrams.0 = 100) 的應答。管理站因此便知道了在這個MIB視圖中第一個被支持的對象是udpInDatagrams，並且知道了它的當前值。
4.3.8 SetRequest PDU
SNMP實體應網絡管理站應用程序的請求發出SetRequest PDU。它與GetRequest PDU具有相同的交換模式和相同的格式。但是，SetRequest 是被用於寫對象值而不是讀。因而，變量綁定清單中既包含對象實例標識符，也包含每個對象實例將被賦予的值。
SetRequest PDU 的SNMP接收實體用包含相同request-id的GetResponse PDU進行應答。SetRequest操作是原子操作―要麼變量綁定中的所有變量都被更新，要麼一個都不被更新。如果應答實體能夠更新變量綁定中的所有變量，則GetResponse PDU中包含提供給各個變量的值的變量綁定字段。只要有一個變量值不能成功地設置，則無變量值返回，也無變量值被更新。在GetRequest操作中可能返回的錯誤―noSuchName、tooBig和genErr也是SetRequest可能返回的錯誤。另外一個可能返回的錯誤是badValue，只要SetRequest中有一個變量名和變量值不一致的問題，就會返回這個錯誤。所謂不一致可能是類型的問題，也可能是長度的問題，還可能是提供的實際的值有問題。
利用SetRequest不僅可以對葉子對象實例進行值的更新，也可以利用變量綁定字段進行表格的行增加和行刪除操作。
除此之外，SetRequest還可被用於完成某種動作。SNMP沒有提供一種命令代理者完成某種動作的機制，它的全部能力就是在一個MIB視圖內get和set對象值。但是利用set的功能可以間接地發佈完成某種動作的命令。某個對象可以代表某個命令，當它被設置爲特定值時，就執行特定的動作。例如代理者可以設一個初始值爲0的對象reBoot，如果管理站將這個對象值置1，則代理者系統被重新啓動，reBoot的值也被重新置0。
4.3.9 Trap PDU
SNMP實體應網絡管理代理者應用程序的請求發出Trap PDU。它被用於向管理站異步地通報某個重要事件。它的格式與其他的SNMP PDU完全不同。所包含的字段有:
l PDU類型:指出Trap PDU類型
l enterprise:標識產生本Trap的網絡管理子系統(用System組中的sysObjectId值)
l agent-addr:產生本Trap的對象的IP地址
l generic-trap:一種預定義的trap
l specific-trap:更明確地指出trap特性的代碼
l time-stamp:發出trap的網絡實體從上次重啓到產生本trap所經歷的時間
l variablebindings:有關trap的附加信息(本字段的意義有具體實現有關)
4.3.10 傳輸層的支持
SNMP需要利用傳輸層的服務來傳遞SNMP消息，但是它並未假定傳輸層的服務是可靠的還是非可靠的，是無連接的還是面向連接的。
但是實際上，在TCP/IP體系中，SNMP的實現幾乎都是使用無連接協議用戶數據報(UDP)。UDP頭中包含源和目的端口字段，允許應用層協議，如SNMP填寫地址。它還包含一個可選的覆蓋UDP頭和用戶數據的校驗和(checksum)。如果校驗和有問題，UDP片段(segment)被丟棄。兩個端口號給SNMP應用，用於代理者偵聽GetRequest, GetNextRequest和SetRequest命令的161端口和用於管理站偵聽Trap命令的162端口。
由於UDP是非可靠的，因此SNMP的消息可能被丟失。SNMP本身也不保證消息的可靠傳遞，因此，處理消息丟失問題的負擔只能由SNMP的用戶自己承擔。
如何處理SNMP消息的丟失沒有標準的方法，只能憑通常的感覺處理。在GetRequest和GetNextRequest的場合，如果在規定的時間內得不到應答，管理站可以認爲或者是發出的命令消息被丟失，或者是代理者返回的應答被丟失。管理站可以再次或多次重發請求，直至成功或最終放棄。由於相同的請求具有相同的request-id，因此重發可能會使接收者收到多個相同的消息，但這並不會引起問題，因爲接收者可以簡單地將收到的重複的消息丟棄。
在SetRequest的場合，如果在規定的時間內得不到應答，爲了確認操作是否成功，可以用GetRequest操作進行確認。如果確認set操作沒被執行，可以重發SetRequest。
由於SNMP的Trap沒有應答消息，因此沒有簡單的方法去檢驗Trap的傳遞。在SNMP中，Trap一般用於提供重要事件的早期告警，作爲後備方法，管理站還要定期地輪詢代理者獲取相關的狀態。
4.4 SNMPv2
4.4.1 SNMPv2對SNMPv1的改進
1993年，SNMP的改進版SNMPv2開始發佈，從此，原來的SNMP便被稱爲SNMPv1。最初的SNMPv2最大的特色是增加了安全特性，因此被稱爲安全版SNMPv2。但不幸的是，經過幾年試用，沒有得到廠商和用戶的積極響應，並且也發現自身還存在一些嚴重缺陷。因此，在1996正式發佈的SNMPv2中，安全特性被刪除。這樣，SNMPv2對SNMPv1的改進程度便受到了很大的削弱。
總的來說，SNMPv2的改進主要有以下3個方面：
l 支持分佈式管理；
l 改進了管理信息結構；
l 增強了管理信息通信協議的能力。
SNMPv1採用的是集中式網絡管理模式。網絡管理站的角色由一個主機擔當。其他設備(包括代理者軟件和MIB)都由管理站監控。隨着網絡規模和業務負荷的增加，這種集中式的系統已經不再適應需要。管理站的負擔太重，並且來自各個代理者的報告在網上產生大量的業務量。而SNMPv2不僅可以採用集中式的模式，也可以採用分佈式模式。在分佈式模式下，可以有多個頂層管理站，被稱爲管理服務器。每個管理服務器可以直接管理代理者。同時，管理服務器也可以委託中間管理者擔當管理者角色監控一部分代理者。對於管理服務器，中間管理器又以代理者的身份提供信息和接受控制。這種體系結構分散了處理負擔，減小了網絡的業務量。
SNMPv2的管理信息結構（SMI）在幾個方面對SNMPv1的SMI進行了擴充。定義對象的宏中包含了一些新的數據類型。最引人注目的變化是提供了對錶中的行進行刪除或建立操作的規範。新定義的SNMPv2 MIB包含有關SNMPv2協議操作的基本流量信息和有關SNMPv2管理者和代理者的配置信息。
在通信協議操作方面，最引人注目的變化是增加了兩個新的PDU―GetBulkRequest 和 InformRequest。前者使管理者能夠有效地提取大塊的數據，後者使管理者能夠向其他管理者發送trap信息。
4.4.2 SNMPv2網絡管理框架
SNMPv2提供了一個建立網絡管理系統的框架。但網絡管理應用，如故障管理、性能監測、計費等不包括在SNMPv2的範圍內。用術語來說，SNMPv2提供的是網絡管理基礎結構。圖4.7是這種基礎結構的一個配置例。
SNMPv2本質上是一個交換管理信息的協議。網絡管理系統中的每個角色都維護一個與網絡管理有關的MIB。SNMPv2的SMI對這些MIB的信息結構和數據類型進行定義。SNMPv2提供了一些一般的通用的MIB，廠商或用戶也可以定義自己私有的MIB。
在配置中至少有一個系統負責整個網絡的管理。這個系統就是網絡管理應用駐留的地方。管理站可以設置多個，以便提供冗餘或分擔大網絡的管理責任。其他系統擔任代理者角色。代理者收集本地信息並保存，以備管理者提取。這些信息包括系統自身的數據，也可以包括網絡的業務量信息。
SNMPv2既支持高度集中化的網絡管理模式，也支持分佈式的網絡管理模式。在分佈式模式下，一些系統擔任管理者和代理者兩種角色，這種系統被稱爲中間管理者。中間管理者以代理者身份從上級管理系統接受管理信息操作命令，如果這些命令所涉及的管理信息在本地MIB中，則中間管理者便以代理者身份進行操作並進行應答，如果所涉及的管理信息在中間管理者的下屬代理者的MIB中，則中間管理者先以管理者身份對下屬代理者進行發佈操作命令，接收應答，然後再以代理者身份向上級管理者應答。
所有這些信息交換都利用SNMPv2通信協議實現。與SNMPv1相同，SNMPv2協議仍是一個簡單的請求(request)/應答(response)型協議，但在PDU種類和協議功能方面對SNMPv1進行了擴充。
圖4.7 SNMPv2的配置
4.4.3 協議操作
SNMPv2消息
與SNMPv1相同，SNMPv2以包含協議數據單元(PDU)的消息的形式交換信息。外部的消息結構中包含一個用於認證的共同體名。
SNMPv2確定的消息結構如下:
Message :: = SEQUENCE {
version INTEGER { version (1) }, -- SNMPv2的版本號爲1
community OCTET STRING, -- 共同體名
data ANY -- SNMPv2 PDU
}
4.3.2節中對於共同體名、共同體輪廓和訪問策略的討論同樣適用於SNMPv2。
SNMPv2消息的發送和接收過程與4.3.5節中描述的SNMPv1消息的發送和接收過程相同。
PDU格式
表4.11 SNMP協議數據單元(PDUs)
PDU 描 述 SNMPv1 SNMPv2
GetGetNextGetBulkSetTrapInformResponse 管理者通過代理者獲得每個對象的值管理者通過代理者獲得每個對象的下一個值管理者通過代理者獲得每個對象的N個值管理者通過代理者爲每個對象設置值代理者向管理者傳送隨機信息管理者向代理者傳送隨機信息代理者對管理者的請求進行應答 ○○○○○ ○○○○○○○
在SNMPv2消息中可以傳送7類PDU。表4.11列出了這些PDU，同時指出了對SNMPv1也有效的PDU。圖4.8 描述了SNMPv2 PDU的一般格式。
(a) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU,
SNMPv2-Trap-PDU,InformRequest-PDU
(b) Response-PDU
(c) GetBulkRequest-PDU
(d) Variable-bindings
圖4.8 SNMPv2 PDU格式
值得注意的是，GetRequest、GetNextRequest、SetRequest、SNMPv2-Trap、InformReques 5種PDU具有完全相同的格式，並且與也可以看作是error-status和error-index兩個字段被置零的Response PDU的格式。這樣設計的目的是爲了減少SNMPv2實體需要處理的PDU格式種類。
GetRequest PDU
SNMPv2的GetRequest PDU的語法和語義都與SNMPv1的GetRequest PDU相同，差別是對應答的處理。SNMPv1的GetRequest是原子操作:要麼所有的值都返回，要麼一個也不返回，而SNMPv2能夠部分地對GetRequest操作進行應答。即使有些變量值提供不出來，變量綁定字段也要包含在應答的GetResponse PDU之中。如果某個變量有意外情況(noSuchObject, noSuchInstance,endOfMibView)，則在變量綁定字段中，這個變量名與一個代表意外情況的錯誤代碼而不是變量值配對。
在SNMPv2中，按照以下規則處理GetRequest變量綁定字段中的每個變量來構造應答PDU:
l 如果OBJECT IDENTIFIER前綴與該請求在代理者處所能訪問的變量的前綴都不匹配，則它的值字段被設置爲noSuchObject;
l 否則，如果變量名與該請求在代理者處所能訪問的變量的名稱都不匹配，則它的值字段被設置爲noSuchInstance;
l 否則，值字段被設置爲變量值。
如果由於其他原因導致變量名處理過程的失敗，則無法返回變量值。這時，應答實體將返回一個error-status字段值爲genErr，並在error-index字段中指出出問題的變量的應答PDU。
如果生成的應答PDU中的消息尺寸過大，超過了指定的最大限度，則生成的PDU被丟棄，並用一個error-status字段值爲tooBig，error-index字段值爲0，變量綁定字段爲空的新的PDU應答。
允許部分應答是對GetRequest的重要改進。在SNMPv1中，只要有一個變量值取不回來，所有的變量值就都不能返回。在這種情況下，發出操作請求的管理者往往只能將命令拆分爲多條只取單個變量值的命令。相比之下，SNMPv2的操作效率得到了很大提高。
GetNextRequest PDU
SNMPv2的GetNextRequest PDU的語法和語義都與SNMPv1的GetNextRequest PDU相同。與GetRequestPDU相同，兩個版本的差別是對應答的處理。SNMPv1的GetNextRequest是原子操作:要麼所有的值都返回，要麼一個也不返回，而SNMPv2能夠部分地對GetNextRequest操作進行應答。
在SNMPv2中，按照以下規則處理GetNextRequest變量綁定字段中的每個變量來構造應答PDU:
l 確定被指名的變量下一個變量，將該變量名和它的值成對地放入結果變量綁定字段中;
l 如果被指定的變量之後不存在變量，則將被指定的變量名和錯誤代碼endOfMibView成對地放入結果變量綁定字段中。
如果由於其他原因導致變量名處理過程的失敗，或者是產生的結果太大，處理過程與GetRequest相同。
GetBulkRequest
SNMPv2的一個主要改進是GetBulkRequest PDU。這個PDU的目的是儘量減少查詢大量管理信息時所進行的協議交換次數。GetBulkRequest PDU允許SNMPv2管理者請求得到在給定的條件下儘可能大的應答。
GetBulkRequest操作利用與GetNextRequest相同的選擇原則，即總是順序選擇下一個對象。不同的是，利用GetBulkRequest，可以選擇多個後繼對象。
GetBulkRequest操作的基本工作過程如下：GetBulkRequest在變量綁定字段中放入一個(N+R)個變量名的清單。對於前N個變量名，查詢方式與GetNextRequest相同。即，對清單中的每個變量名，返回它的下一個變量名和它的值，如果沒有後繼變量，則返回原變量名和一個endOfMibView的值。
GetBulkRequest PDU有兩個其他PDU所沒有的字段，non-repeaters和max-repetitions。
non-repeaters字段指出只返回一個後繼變量的變量數。max-repetitions字段指出其他的變量應返回的最大的後繼變量數。爲了說明算法，我們定義：
L = 變量綁定字段中的變量名數量
N = 只返回一個後繼變量的變量名數
R = 返回多個後繼變量的變量名數
M = 最大返回的後繼變量數
在上述變量之間存在以下關係：
N = MAX [MIN(non-reperters, L)，0]
M = MAX [max-repetitions,0]
R = L - N
如果N大於0，則前N個變量與GetNextRequest一樣被應答。如果R大於0並且M大於0，則對應後面的R個變量，返回M個後繼變量。即，對於每個變量：
・獲得給定變量的後繼變量的值；
・獲得下一個後繼變量的值；
・反覆執行上一步，直至獲得M個對象實例。
如果在上面的過程中的某一點，已經沒有後繼變量，則返回endOfMibView值，在變量名處，返回最後一個後繼變量，如果沒有後繼變量，則返回請求中的變量名。
利用這個規則，能夠產生的name-value對的數量是N+(M×R)。後面的(M×R)對在應答PDU中的順序可描述爲：
for i : = 1 to M do
for r : = 1 to R do
retrieve i-th successor of (N+r)-th variable
即，返回的後繼變量是一行一行的，而不是先返回第一個變量的所有後繼變量，再返回第二個變量的所有後繼變量，等等。
GetBulkRequest操作解除了SNMP的一個主要限制，即不能有效地檢索大塊數據。此外，利用這個功能可以減小管理應用程序的規模。管理應用程序自身不需要關心組裝在一起的請求的細節。不需要執行一個試驗過程來確認請求PDU中的name-value對的最佳數量。並且，即使GetBulkRequest發出的請求過大，代理者也會盡量多地返回數據不是簡單地返回一個tooBig的錯誤消息。爲了獲得缺少的數據，管理者只需簡單地重發請求，而不必將原來的請求改裝爲小的請求序列。
SetRequest
SetRequest PDU由管理者發出，用來請求改變一個或多個對象的值。接收實體用一個包含相同request-id的Response PDU應答。與SNMPv1相同，SetRequest操作是原子操作，即或者更新所有被指名的變量，或者所有的都不更新。如果接收實體能夠爲被指名的所有變量設置新值，則Response PDU返回與SetRequest相同的變量綁定字段。只要有一個變量值沒設置成功，就不更新任何值。
SetRequest的變量綁定分兩個階段處理。在第一階段，確認每個綁定對。如果所有的綁定對都被確認，則進入第二階段―改變每個變量。即每個變量的set操作都在第二階段進行。
在第一階段中，對每個綁定對進行以下確認，直至所有的都成功或遇到一個失敗。失敗的原因有:不可訪問(noAccess)、無法建立或修改(notWritable)、數據類型不一致(wrongType)、長度不一致(wrongLength)、ASN.1編碼不一致、變量值有問題(wrongValue)、變量不存在且無法建立(noCreation)等。如果任意一個變量遇到以上情況，則返回一個在error-status字段給出上述錯誤代碼，在error-index字段給出有問題的變量的序號的應答PDU。與SNMPv1相比，提供了更多的錯誤代碼。爲管理站更容易地確定失敗的原因提供了方便。
如果在確認階段沒有遇到問題，則進入第二階段―更新在變量綁定字段中被指名的所有的變量。不存在的變量需要建立，存在的變量被賦予新值。只要遇到任何失敗，則所有的更新都被撤銷，並則返回一個error-status字段值爲commitFailed的應答PDU。
SNMPv2 Trap
SNMPv2 Trap PDU由一個代理者實體在發現異常事件時產生併發給管理站。與SNMPv1相同，它用於向管理站提供一個異步的通報以便報告重要事件。但它的格式與SNMPv1不同，與GetRequest、GetNextRequest、GetBulkRequest、SetRequest和InformRequest PDU擁有相同的格式。變量綁定字段用於容納與陷阱消息有關的信息。Trap PDU是一個非認證消息，不要求接收實體應答。
InformRequest
InformRequest PDU由一個管理者角色的SNMPv2實體應它的應用的要求發給另一個管理者角色的SNMPv2實體，請求後者向某個應用提供管理信息。與SNMPv2 Trap PDU類似，變量綁定字段被用於傳送相關的信息。
收到InformRequest的實體首先檢查承載應答PDU的消息尺寸，如果消息尺寸超過限度，用一個含有tooBig錯誤代碼的Response PDU應答。否則，接收實體將PDU中的內容轉到信息的目的地(某個應用)，同時對發出InformRequest的管理者用error-status字段值爲noError的Response PDU進行應答。
4.5 SNMPv3
4.5.1 SNMP管理框架的體系結構
一個SNMP管理系統由若干包含SNMP實體的節點組成。在這些實體中，至少有一個實體包含命令產生者，和/或通報接收者的應用(對應以往的管理者)，多個實體包含能夠訪問管理設備的命令和通報產生者應用 (對應以往的代理者)。實體間用管理通信協議傳遞管理信息。
執行命令生成者和通報接收者應用的SNMP實體監測和控制被管元素。被管元素是指主機、路由器、終端服務器等設備。這些被管元素的監測和控制通過對它們的管理信息的訪問實現。
在實現方面，對SNMP的體系結構會有以下不同的要求:
1. 具有命令應答者和/或通報生成者應用的實體(最小的SNMP);
2. 具有代管轉發者應用的SNMP實體;
3. 具有命令產生者和/或通報接收者應用的命令行驅動的SNMP實體;
4. 具有命令生成者和/或通報接收者應用，並具有命令應答和/或通報產生者應用的SNMP實體(以往稱爲SNMP中間層管理者或雙重角色實體);
5. 具有命令生成者和/或通報接收者，及爲管理潛在的非常大量的被管節點可能的其它應用的SNMP實體(以往稱爲網絡管理站);
爲了能夠統一滿足以上要求，SNMPv3定義了一個可進化的體系結構。
4.5.2 SNMP實體
SNMP實體是體系結構的一個實現。如圖4.9所示，每個SNMP實體都包含一個SNMP引擎、一個或多個應用。
+-------------------------------------------------------------------+
| SNMP entity |
| |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | | | | | | | | | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
圖 4.9 SNMP 實體
SNMP引擎爲發送和接收消息、認證和加密消息、控制對被管對象的訪問提供服務。SNMP引擎與包含它的SNMP實體之間存在一對一的聯繫。引擎包括中包括
l 發報機(Dispatcher),
l 消息處理子系統(Message Processing Subsystem),
l 安全子系統(Security Subsystem)，
l 訪問控制子系統(Access Control Subsystem)。
在一個管理域中，每個引擎都有一個唯一的和明確的標識符snmpEngingID。由於引擎和實體之間一一對應，因此snmpEngingID也能在管理域中唯一地、明確地標識實體。但是，在不同的管理域中，SNMP的實體可能會有相同的snmpEngineID。
一個引擎中只有一個發報機，但能夠同時支持多個版本的SNMP消息。它的功能包括:
l 向網絡發送或從網絡接收SNMP消息，
l 確定SNMP消息的版本，與相應的消息處理模型相互作用，
l 爲SNMP應用提供抽象接口，用以嚮應用傳遞PDU，
l 爲SNMP應用提供抽象接口，用以允許它們向遠程SNMP實體發送PDU。
4.5.3 消息處理子系統
消息處理子系統負責準備要發送的消息和從收到的消息中抽取數據。如圖4.10所示，消息處理子系統潛在地包含多個消息處理模型。
+------------------------------------------------------------------+
| |
| Message Processing Subsystem |
| |
| +------------+ +------------+ +------------+ +------------+ |
| | * | | * | | * | | * | |
| | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | |
| | Message | | Message | | Message | | Message | |
| | Processing | | Processing | | Processing | | Processing | |
| | Model | | Model | | Model | | Model | |
| | | | | | | | | |
| +------------+ +------------+ +------------+ +------------+ |
| |
+------------------------------------------------------------------+
4.10 消息處理子系統
每個消息處理模型定義一個特定版本的SNMP消息的格式，對應所定義的格式對準備和抽取處理進行相應的調整。
4.5.4 安全子系統
安全子系統提供諸如消息的認證和隱私的安全服務。如圖4.11所示，SNMPv3採用User-Based安全模型，但潛在的安全模型可有多個。
+------------------------------------------------------------------+
| |
| Security Subsystem |
| |
| +----------------+ +-----------------+ +-------------------+ |
| | * | | * | | * | |
| | User-Based | | Other | | Other | |
| | Security | | Security | | Security | |
| | Model | | Model | | Model | |
| | | | | | | |
| +----------------+ +-----------------+ +-------------------+ |
| |
+------------------------------------------------------------------+
4.11 安全子系統
安全模型要指出它所防範的威脅，服務的目標和爲提供安全服務所採用的安全協議，如認證和隱私。
安全協議指出爲提供安全服務所採用的機制、過程和MIB對象。
4.5.5 訪問控制子系統
訪問控制子系統通過一個或多個訪問控制模型提供認證服務。如圖4.12所示，View-Based 訪問控制模型是SNMPv3所建議的。
+------------------------------------------------------------------+
| |
| Access Control Subsystem |
| |
| +---------------+ +-----------------+ +------------------+ |
| | * | | * | | * | |
| | View-Based | | Other | | Other | |
| | Access | | Access | | Access | |
| | Control | | Control | | Control | |
| | Model | | Model | | Model | |
| | | | | | | |
| +---------------+ +-----------------+ +------------------+ |
| |
+------------------------------------------------------------------+
圖4.12 訪問控制子系統
訪問控制模型定義一個特定的訪問決策函數，用以支持訪問權的認定決策。
4.5.5 SNMP應用
SNMP應用分爲以下幾種類型:
l 監測和操縱管理數據的命令產生者；
l 對管理數據提供訪問的命令接收者；
l 發出異步消息的通報產生者；
l 處理異步消息的通報接收者；
l 在實體之間轉發消息的代管轉發者。
SNMP應用與SNMP引擎之間形成應用與服務的關係，即SNMP應用是SNMP引擎的應用，SNMP引擎向SNMP應用提供服務。
SNMP Manager
包含一個或多個命令產生者和/或通報接收者應用的SNMP實體以往被稱爲SNMP管理者。如圖4.13所示
(traditional SNMP manager)
+-------------------------------------------------------------------+
| +--------------+ +--------------+ +--------------+ SNMP entity |
| | NOTIFICATION | | NOTIFICATION | | COMMAND | |
| | ORIGINATOR | | RECEIVER | | GENERATOR | |
| | applications | | applications | | applications | |
| +--------------+ +--------------+ +--------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------+--------+-----------------+ |
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | |
| | | | | +------------+ | | | Other | | |
| | | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->+ | | | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | Transport | | | +------------+ | | | Security | | |
| | Mapping | | | +------------+ | | | Model | | |
| | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +----------------+ |
| | |
| v |
+-------------------------------------------------------------------+
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+
^ ^ ^
| | |
v v v
+------------------------------+
| Network |
+------------------------------+
圖4.13 SNMP Manager
SNMP Agent
包含一個或多個命令接收者和/或通報產生者應用的SNMP實體，以往被稱爲SNMP代理者。如圖4.14所示。
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+ (traditional SNMP agent)
+-------------------------------------------------------------------+
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | Transport | | +->| v1MP * |<--->| +------------+ | |
| | Mapping | | | +------------+ | | | Other | | |
| | (e.g. RFC1906) | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->| +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | | | | +------------+ | | | Security | | |
| | PDU Dispatcher | | | +------------+ | | | Model | | |
| +-------------------+ | +->| otherMP * |<--->| +------------+ | |
| ^ | +------------+ | | | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | application | | | | applications | | application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
圖4.14 SNMP Agent
抽象服務接口
抽象服務接口被定義爲描述一個SNMP實體內各種子系統間的概念接口。抽象服務接口試圖幫助闡明SNMP實體的外部可觀察的行爲，但並不涉及或規範實現的結構或組織方法。特別要明確的是，它們不應被解釋爲API或對API的要求。
這些抽象服務接口由一組原語定義，而由原語定義提供的服務和服務被調用時被傳遞的抽象數據元素。
CMIP網絡管理體系結構對系統模型、信息模型和通信協議幾個方面都提出了比較完備和理想的解決方案，爲其他網絡管理體系結構建立了理想參考標準。SNMP網絡管理體系結構是爲了管理基於TCP/IP協議的網絡而提出的，與TCP/IP協議與OSI協議的關係類似，SNMP與CMIP相比，突出的特點是簡單。這一特點使SNMP得到了廣泛的支持和應用，特別是在Internet上的成功應用，使得它的重要性越來越突出，目前已經成爲CMIP之外的最重要的網絡管理體系結構。
4.1 SNMP體系結構
4.1.1 TCP/IP網絡管理的發展
在TCP/IP的早期開發中，網絡管理問題並未得到太大的重視。直到70年代，還一直沒有網絡管理協議，只有互聯網絡控制信息協議(ICMP)可以作爲網絡管理的工具。ICMP提供了從路由器或其它主機向主機傳送控制信息的方法，可用於所有支持IP的設備。從網絡管理的觀點來看，ICMP最有用的特性是回聲(echo)和回聲應答(echo reply)消息對。這個消息對爲測試實體間能否通信提供了一個機制。echo消息要求其接收者在echo reply消息中返回接收到的內容。另一個有用的消息對是時間戳(timestamp)和時間戳應答(timestamp reply)，這個消息對爲測試網絡延遲特性提供了機制。
與各種IP頭選項結合，這些ICMP消息可用來開發一些簡單有效的管理工具。典型的例子是廣泛應用的分組互聯網絡探索(PING)程序。利用ICMP加上另外的選項如請求間隔和一個請求的發送次數，PING能夠完成多種功能。包括確定一個物理網絡設備能否尋址，驗證一個網絡能夠尋址，和驗證一個主機上的服務器操作。
PING在一些工具的配合下滿足了TCP/IP網絡初期的管理要求。但是到了80年代後期，當互聯網絡的發展呈指數增加時，人們感到需要開發比PING功能更強並易於普通網絡管理人員學習和使用的標準協議。因爲當網絡中的主機數量上百萬，獨立網絡數量上千的時候，已不能只依靠少數網絡專家解決管理問題了。
1987年11月發佈了簡單網關監控協議(SGMP)，成爲提供專用網絡管理工具的起點。SGMP提供了一個直接監控網關的方法。隨着對通用網絡管理工具需求的增長，出現了3個有影響的方法。
1.高層實體管理系統(HEMS)：主機監控協議(HMP)的一般化。
2.簡單網絡管理協議(SNMP)：SGMP的升級版。
3.TCP/IP上的CMIP(CMOT)：最大限度地與OSI標準的CMIP、服務以及數據庫結構保持一致。
1988年，互聯網絡活動會議(IAB)確定了將SNMP作爲近期解決方案進一步開發，而把CMOT作爲遠期解決方案的策略。當時普遍認爲：TCP/IP不久將會過渡到OSI，因而不應在TCP/IP的應用層協議和服務上花費太多的精力。SNMP開發速度快，並能爲網絡管理經驗庫的開發提供一些基本的工具，可用來滿足眼前的需要。
爲了強化這一策略，IAB要求SNMP和CMOT使用相同的被管對象數據庫。即在任何主機、路由器、網橋以及其它管理設備中，兩個協議都以相同的格式使用相同的監控變量。因此，兩個協議有一個公共的管理信息結構(SMI)，和一個管理信息庫MIB。
但是，人們很快發現這兩個協議在對象級的兼容是不現實的。在OSI的網絡管理中，被管對象是很成熟的，它具有屬性、相關的過程、通報以及其它一些與面向對象有關的複雜的特性。而SNMP爲了保持簡單性，沒有這樣複雜的概念。實際上，SNMP的對象在面向對象的概念下根本就不能稱爲對象，它們只是帶有一些如數據類型、讀寫特性等基本特性的變量。因此IAB最終放鬆了公共SMI/MIB的條件，並允許SNMP獨立於CMOT發展。
從對OSI的兼容性的束縛中解脫後，SNMP取得了迅速的發展，很快被衆多的廠商設備所支持，並在互聯網絡中活躍起來。而且，普通用戶也選擇了SNMP作爲標準的管理協議。
SNMP最重要的進展是遠程監控(RMON)能力的開發。RMON爲網絡管理者提供了監控整個子網而不是各個單獨設備的能力。除了RMON，還對基本SNMP MIB進行了擴充。有些擴充採用標準的網絡接口，例如令牌環(token ring)和光纖分佈數據接口(FDDI)，這種擴充是獨立於廠商的。
但是，單靠定義新的或更細緻的MIB擴充SNMP是有限的。當SNMP被用於大型或複雜網絡時，它在安全和功能方面的不足就變得明顯了。爲了彌補這些不足，1992年7月發表了3個增強SNMP安全性的文件作爲建議標準。增強版與原來的SNMP是不兼容的，它需要改變外部消息句柄及一些消息處理過程。但實際定義協議操作幷包含SNMP消息的協議數據單元(PDU)保持不變，並且沒有增加新的PDU。目的是儘量實現向SNMP的安全版本的平滑過渡。
但是這個增強版受到了另一個方案的衝擊。同樣是在1992年7月，四名SNMP的關鍵人物提出一個稱爲SMP的SNMP新版本。並實現了四個可互操作的方案。兩個是商業產品，兩個是公開軟件。SMP在功能和安全性兩方面提高了SNMP，特別是SMP增加了一些PDU。所有的消息頭和安全功能都與提議的安全性增強標準相似。最終SMP被接受爲定義第二代SNMP即SNMPv2的基礎。1993年安全版SNMPv2發佈。
經過幾年試用以後，IETF(Internet Engineering Task Force) 決定對SNMPv2進行修訂。1996年發佈了一組新的RFC (Request For Comments)，在這組新的文檔中，SNMPv2的安全特性被取消了，消息格式也重新採用SNMPv1的基於“共同體(community)”概念的格式。
刪除SNMPv2中的安全特性是SNMPv2發展過程中最大的失敗。主要原因是廠商和用戶對1993版的SNMPv2的安全機制不感興趣，同時IETF要求的修訂時間也非常緊迫，設計者們來不及對安全機制進行改善，甚至來不及對存在的嚴重缺陷進行修改。因此不得不在1996年版的SNMPv2中放棄了安全特性。
1999年4月IETF SNMPv3工作組提出了RFC2571～RFC2576，形成了SNMPv3的建議。目前，這些建議正在進行標準化。SNMPv3提出了SNMP管理框架的一個統一的體系結構。在這個體系結構中，採用User-based安全模型和View-based訪問控制模型提供SNMP網絡管理的安全性。安全機制是SNMPv3的最具特色的內容。
4.1.2 SNMP基本框架
1) 網絡管理體系結構
SNMP的網絡管理模型包括以下關鍵元素：管理站、代理者、管理信息庫、網絡管理協議。管理站一般是一個分立的設備，也可以利用共享系統實現。管理站被作爲網絡管理員與網絡管理系統的接口。它的基本構成爲：
・一組具有分析數據、發現故障等功能的管理程序；
・一個用於網絡管理員監控網絡的接口；
・將網絡管理員的要求轉變爲對遠程網絡元素的實際監控的能力；
・一個從所有被管網絡實體的MIB中抽取信息的數據庫。
網絡管理系統中另一個重要元素是代理者。裝備了SNMP的平臺，如主機、網橋、路由器及集線器均可作爲代理者工作。代理者對來自管理站的信息請求和動作請求進行應答，並隨機地爲管理站報告一些重要的意外事件。
與CMIP體系相同，網絡資源也被抽象爲對象進行管理。但SNMP中的對象是表示被管資源某一方面的數據變量。對象被標準化爲跨系統的類，對象的集合被組織爲管理信息庫（MIB）。MIB作爲設在代理者處的管理站訪問點的集合，管理站通過讀取MIB中對象的值來進行網絡監控。管理站可以在代理者處產生動作，也可以通過修改變量值改變代理者處的配置。
管理站和代理者之間通過網絡管理協議通信，SNMP通信協議主要包括以下能力：
Get：管理站讀取代理者處對象的值；
Set：管理站設置代理者處對象的值；
Trap：代理者向管理站通報重要事件。
在標準中，沒有特別指出管理站的數量及管理站與代理者的比例。一般地，應至少要有兩個系統能夠完成管理站功能，以提供冗餘度，防止故障。另一個實際問題是一個管理站能帶動多少代理者。只要SNMP保持它的簡單性，這個數量可以高達幾百。
2) 網絡管理協議體系結構
SNMP爲應用層協議，是TCP/IP協議族的一部分。它通過用戶數據報協議(UDP)來操作。在分立的管理站中，管理者進程對位於管理站中心的MIB的訪問進行控制，並提供網絡管理員接口。管理者進程通過SNMP完成網絡管理。SNMP在UDP、IP及有關的特殊網絡協議(如，Ethernet, FDDI, X.25)之上實現。
每個代理者也必須實現SNMP、UDP和IP。另外，有一個解釋SNMP的消息和控制代理者MIB的代理者進程。
圖4.1 SNMP的協議環境
圖4.1描述了SNMP的協議環境。從管理站發出3類與管理應用有關的SNMP的消息GetRequest、GetNextRequest、SetRequest。3類消息都由代理者用GetResponse消息應答，該消息被上交給管理應用。另外，代理者可以發出Trap消息，向管理者報告有關MIB及管理資源的事件。
由於SNMP依賴UDP，而UDP是無連接型協議，所以SNMP也是無連接型協議。在管理站和代理者之間沒有在線的連接需要維護。每次交換都是管理站和代理者之間的一個獨立的傳送。
3) 陷阱引導輪詢(Trap-directed polling)
如果管理站負責大量的代理者，而每個代理者又維護大量的對象，則靠管理站及時地輪詢所有代理者維護的所有可讀數據是不現實的。因此管理站採取陷阱引導輪詢技術對MIB進行控制和管理。
所謂陷阱引導輪詢技術是：在初始化時，管理站輪詢所有知道關鍵信息(如接口特性、作爲基準的一些性能統計值，如發送和接收的分組的平均數)的代理者。一旦建立了基準，管理站將降低輪詢頻度。相反地，由每個代理者負責向管理站報告異常事件。例如，代理者崩潰和重啓動、連接失敗、過載等。這些事件用SNMP的trap消息報告。
管理站一旦發現異常情況，可以直接輪詢報告事件的代理者或它的相鄰代理者，對事件進行診斷或獲取關於異常情況的更多的信息。
陷阱引導輪詢可以有效地節約網絡容量和代理者的處理時間。網絡基本上不傳送管理站不需要的管理信息，代理者也不會無意義地頻繁應答信息請求。
4) 代管(Proxies)
利用SNMP需要管理站及其所有代理者支持UDP和IP。這限制了在不支持TCP/IP協議的設備(如網橋、調制解調器)上的應用。並且，大量的小系統(PC、工作站、可編程控制器)雖然支持TCP/IP協議，但不希望承擔維護SNMP、代理者軟件和MIB的負擔。
爲了容納沒有裝載SNMP的設備，SNMP提出了代管的概念。在這個模式下，一個SNMP的代理者作爲一個或多個其他設備的代管人。即，SNMP代理者爲託管設備(proxied devices)服務。
圖4.2顯示了常見的一類協議體系結構。管理站向代管代理者發出對某個設備的查詢。代管代理者將查詢轉變爲該設備使用的管理協議。當代理者收到對一個查詢的應答時，將這個應答轉發給管理站。類似地，如果一個來自託管設備的事件通報傳到代理者，代理者以陷阱消息的形式將它發給管理站。
圖4.2 SNMP協議體系結構
4.2 SNMP 管理信息
與CMIP體系相同，SNMP的基礎是包含被管元素信息的被稱爲MIB的數據庫。每個被管資源由對象來表示，MIB是這些對象的有結構的集合。在SNMP中，MIB本質上是一個樹型的數據庫結構。網絡中每個的系統都（工作站、服務器、路由器、網橋等）擁有一個反映系統中被管資源狀態的MIB。網絡管理實體可以通過提取MIB中的對象值監測系統中的資源，也可以通過修改這些對象值來控制資源。
4.2.1 管理信息結構
SNMP的規範SMI（structure of management information）爲定義和構造MIB提供了一個通用的框架。同時也規定了可以在MIB中使用的數據類型，說明了資源在MIB中怎樣表示和命名。SMI的基本指導思想是追求MIB的簡單性和可擴充性。因此，MIB只能存儲簡單的數據類型：標量和標量的二維矩陣。我們將看到SNMP只能提取標量，包括表中的單獨的條目。
SMI避開復雜的數據類型是爲了降低實現的難度和提高互操作性。但在MIB中不可避免地包含廠家建立的數據類型，如果對這樣的數據類型的定義沒有嚴格的限制，互操作性也會受到影響。
爲了提供一個標準的方法來表示管理信息，SMI必須：
l 提供一個標準的技術定義MIB的具體結構;
l 提供一個標準的技術定義各個對象，包括句法和對象值;
l 提供一個標準的技術對對象值進行編碼。
1) MIB結構
SNMP中的所有的被管對象都被排列在一個樹型結構之中。處於葉子位置上的對象是實際的被管對象，每個實際的被管對象表示某些被管資源、活動或相關信息。樹型結構本身定義一個將對象組織到邏輯上相關的集合之中的方法。
MIB中的每個對象類型都被賦予一個對象標識符(OBJECT IDENTIFIER)，以此來命名對象。另外，由於對象標識符的值是層次結構的，因此命名方法本身也能用於確認對象類型的結構。
對象標識符是能夠唯一標識某個對象類的符號。它的值由一個整數序列構成。被定義的對象的集合具有樹型結構，樹根是引用ASN.1標準的對象。從對象標識符樹的樹根開始，每個對象標識符成分的值指定樹中的一個弧。從樹根開始，第一級有3個節點:iso、ccitt、joint-iso-ccitt。在iso節點下面有一個爲“其他組織”使用的子樹，其中有一個美國國防部的子樹(dod)。SNMP在dod之下設置一個子樹用於Internet的管理。如下所示:
internet OBJECT IDENTIFIER :: = { iso (1) org (3) dod (6) 1}
因此，internet節點的對象標識符的值是1.3.6.1。這個值作爲internet子樹的下級節點標識符的前綴。
SMI在internet節點之下定義了4個節點:
l directory 爲與OSI的directory相關的將來的應用保留的節點
l mgmt 用於在IAB批准的文檔中定義的對象
l experimental 用於標識在Internet實驗中應用的對象
l private 用於標識單方面定義的對象
mgmt子樹包含IAB已經批准的管理信息庫的定義。現在已經開發了兩個版本的MIB，mib-1和和它的擴充版mib-2。二者子樹中的對象標識符是相同的，因爲在任何配置中，只有一個MIB。
MIB中的mib-1或mib-2以外的對象可以用以下方法定義:
l 由一個全新的修訂版(如mib-3)來擴充或取代mib-2。
l 可以爲特定的應用構造一個實驗MIB。這樣的對象隨後會被移到mgmt子樹之下。例如定義包含各種傳輸媒體的MIB(例如爲令牌環局域網定義的MIB)。
l 專用的擴充可以加在private子樹之下。
private子樹目前只定義了一個子節點enterprises，用於廠商加強對自己設備的管理，與用戶及其他廠商共享信息。在enterprises子樹下面，每個註冊了enterprise對象標識符的廠商有一個分支。
internet節點之下分爲4個子樹的做法爲MIB的進化提供了很好的基礎。通過對新對象的實驗，廠商能夠在其被接受爲mgmt的標準之前有效地獲得大量的實際知識。因此這樣的MIB既是對管理符合標準的對象直接有效的，對適應技術和產品的變化也是靈活的。這一點也反映了TCP/IP協議的如下特性：協議在成爲標準之前進行大量的實驗性的使用和調測。
圖4.3 對象標識符樹型結構
2) 對象句法
SNMP MIB中的每個對象都由一個形式化的方法定義，說明對象的數據類型、取值範圍以及與MIB中的其他對象的關係。各個對象以及MIB的整體結構都由ASN.1描述法定義。爲了保持簡單，只利用了ASN.1的元素和特徵的一個有限的子集。
UNIVERSAL類型:ASN.1的UNIVERSAL類由獨立於應用的通用數據類型組成。其中只有以下數據類型被允許用於定義MIB對象:
l integer (UNIVERSAL 2)
l octetstring (UNIVERSAL 4)
l null (UNIVERSAL 5)
l object identifier (UNIVERSAL 6)
l sequence, sequence-of (UNIVERSAL 16)
前3個是構成其他對象類型的基本類型。
object identifier唯一標識對象的符號，由一個integer序列組成，序列中的integer被稱爲子標識符。對象標識符的integer序列從左到右，定義了對象在MIB樹型結構中的位置。
sequence 和sequence-of 用於構成表。
APPLICATION-WIDE 類型:ASN.1的APPLICATION類由與特定的應用相關的數據類型組成。每個應用，包括SNMP,負責定義自己的APPLICATION數據類型。在SNMP中已經定義了以下數據類型:
l networkaddress: 該類型用CHOICE結構定義，允許從多個協議族的地址格式中進行選擇。目前，只定義了IpAddress一種地址格式。
l ipaddress: IP格式的32位地址。
l counter: 只能做增值不能做減值運算的非負整數。最大值被設爲232 ?1，當達到最大值時，再次從0開始增加。
l gauge: 可做增值也可做減值運算的非負整數。最大值被設爲232 ?1，當達到最大值時被鎖定，直至被複位(reset)。
l timeticks: 從某一參照時間開始以百分之一秒爲單位計算經歷的時間的非負整數。當MIB中定義的某個對象類用到這個數據類型時，參照時間在該對象類的定義中指出。
l opaque: 該數據類型提供一個傳遞任意數據的能力。數據在傳輸時被作爲OCTET STRING編碼。被傳遞的數據本身可以是由ASN.1或其他句法定義的任意的格式。
3) 定義對象
管理信息庫由一個對象的集合構成，每個對象都有一個型和一個值。型是對被管對象種類的定義，因此型的定義是一個句法描述。對象的實例是某類對象的一個具體實現，具有一個確定的值。
怎樣定義MIB中的對象呢？ASN.1是將被使用的描述法。ASN.1中包含一些預定義的通用類型，也規定了通過現有類型定義新類型的語法。定義被管對象的一個可選方法是定義一個被稱爲Object的新類型。這樣，MIB中所有的對象都將是這種類型的。這個方法在技術上是可行的，但會產生定義不便於應用的問題。我們需要多種值的類型，包括counter、gauge等等。另外，MIB支持二維表格或矩陣的定義。因此，一個通用的對象類型必須包含參數來對應所有這些可能性和選擇性。
另一個更有吸引力的方法，並且也是被SNMP所實際採用的方法是利用宏（macro）對在被管對象定義中相互關聯的類型進行集合定義。一個宏的定義給出相關類型集合的句法，而宏的實例定義一個特定的類型。因此定義被分爲以下等級：
l 宏：定義合法的宏實例，即說明相關集合類型的句法
l 宏實例：通過爲宏定義提供實際參數生成實例，即說明一個特定的類型
l 宏實例值：用一個特定的值來表示一個特定的實體
圖4.4是OBJECT-TYPE宏的定義(引自RFC 1212)。
圖4.4 被管對象宏
其中的主要項目是:
l SYNTAX: 對象類的抽象句法，該句法必須從SMI的對象句法類型中確定一種類型。
l ACCESS: 定義通過SNMP或其他協議訪問對象實例的方法。Access子句定義該對象類型支持的最低等級。可選的等級有:read-only、read-write、write-only和not-accessible。
l STATUS: 指出該對象在實現上的要求。要求可以是:mandatory(必須)、optional(可選)、deprecated(懇求―必須實現的對象，但很可能在新版MIB中被刪除)和obsolete(廢除―不再需要被管系統實現的對象)。
l DescrPart: 對象類型語義的文本描述。該子句是可選的。
l ReferPart: 對定義在在其他MIB模塊中的某個對象的文本型交叉引用。該子句是可選的。
l IndexPart: 用於定義表。該子句只是在對象類型對應表中的”行”時纔出現。
l DefValPart: 定義一個默認值，用於建立對象實例。該子句是可選的。
l VALUE NOTATION: 指出通過SNMP訪問該對象時使用的名字。
由於應用OBJECT-TYPE宏的MIB的完整的定義包含在MIB的冗長的文檔中，因此，人們並不常使用它們。比較常用的是更簡捷的方法―基於樹型結構和對象特性的表格表示的方法。
4) 定義表格
SMI只支持一種數據結構化方法:標量值條目的二維表格。表格的定義用到ASN.1的sequence和sequence of兩個類型和OBJECT-TYPE宏中的IndexPart。
表格定義方法可以通過實例進行說明。考慮對象類型tcpConnTable，這個對象包含由相應的被管實體維護的TCP connections的信息。對於每個這樣的connection，以下信息在表中存儲:
l state: TCP connection的狀態
l local address: 該connection的本端的IP地址
l local port: 該connection的本端的TCP端口
l remote address: 該connection的另一端的IP地址
l remote port: 該connection的另一端的TCP端口
需要注意的是，tcpConnTable是存放在某個被管系統維護的MIB中。因此，tcpConnTable中的一個條目對應被管系統中的一個connection的狀態信息。TCP connection的狀態信息有22個項目，按照tcpConnTable的定義，只有上述5個項目對網絡管理者來說是可見的。這也體現了SNMP強調保持網絡管理簡單性的特點。即，在被管對象中，只包含相對應的被管實體的有限的和有用的信息。
圖4.5給出了tcpConnTable的定義(引自RFC1213)。
圖4.5 TCP connection Table
在圖4.5中，可以看到sequence 和sequence of 在定義表格時的應用:
l 整個表由一個SEQUENCE OF TcpConnEntry構成。ASN.1的結構SEQUENCE OF由一個或多個相同的元素構成，在本例中(在所有的SNMP SMI的情況下)每個元素是表中的一行。
l 每一行由一個指定了5個標量元素的SEQUENCE構成。ASN.1的結構SEQUCECE由固定數目的元素組成，元素的類型可以是多種。儘管ASN.1允許這些元素是可選的，但SMI限制這個結構只能使用“mandatory”元素。在本例中，每一行所包含的元素的類型是INTEGER, IpAddress, INTEGER, IpAddress, INTERGE。
tcpConnEntry定義中的INDEX成分確定哪個對象值將被用於區分表中的各行。在TCP中，一個socket (IP地址，TCP端口)可以支持多個connection，而任意一對sockets之間同時只能有一個connection。因此爲了明確地區分各行，每行中的後4個元素是必要的，也是充分的。
4.2.2 MIB-II
在TCP/IP網絡管理的建議標準中，提出了多個相互獨立的MIB，其中包含爲Internet的網絡管理而開發的MIB-II。鑑於它在說明標準MIB的結構、作用和定義方法等方面的重要性和代表性，有必要對其進行比較深入的討論。
MIB-II是在MIB-I的基礎之上開發的，是MIB-I的一個超集。mib-2組被分爲以下分組:
l system:關於系統的總體信息;
l interface:系統到子網接口的信息;
l at (address translation):描述internet到subnet的地址映射;
l ip:關於系統中IP的實現和運行信息;
l icmp:關於系統中ICMP的實現和運行信息;
l tcp:關於系統中TCP的實現和運行信息;
l udp:關於系統中UDP的實現和運行信息;
l egp:關於系統中EGP的實現和運行信息;
l dot3(transmission):有關每個系統接口的傳輸模式和訪問協議的信息。
l snmp:關於系統中SNMP的實現和運行信息。
1) system 組
system組提供有關被管系統的總體信息。表4.1列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.1 system組中的對象
Object Syntax Access Description
sysDescr DisplayString (SIZE(0 … 255)) RO 對實體的描述，如硬件、操作系統等
sysObjectID OBJECT IDENTIFIER RO 實體中包含的網絡管理子系統的廠商標識
sysUpTime TimeTicks RO 系統的網絡管理部分本次啓動以來的時間
sysContect DisplayString (SIZE(0 … 255)) RW 該被管節點負責人的標識和聯繫信息
sysName DisplayString (SIZE(0 … 255)) RW 該被管節點被賦予的名稱
sysLocation DisplayString (SIZE(0 … 255)) RW 該節點的物理地點
sysService INERGER(0 … 127) RO 指出該節點所提供的服務的集合，7個bit對應7層服務
2) interfaces 組
interfaces組包含實體物理接口的一般信息，包括配置信息和各接口中所發生的事件的統計信息。表4.2列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.2 interfaces組中的對象
Object Syntax Access Description
ifNumber INTEGER RO 網絡接口的數目
ifTable SEQUENCE OF ifEntry NA 接口條目清單
ifEntry SEQUENCE NA 包含子網及其以下層對象的接口條目
ifIndex INTEGER RO 對應各個接口的唯一值
ifDescr DisplayString (SIZE(0 … 255)) RO 有關接口的信息，包括廠商、產品名稱、硬件接口版本
ifType INTEGER RO 接口類型，根據物理或鏈路層協議區分
ifMtu INERGER RO 接口可接收或發送的最大協議數據單元的尺寸
ifSpeed Gauge RO 接口當前數據速率的估計值
ifPhysAddress PhysAddress RO 網絡層之下協議層的接口地址
ifAdminStatus INTEGER RW 期望的接口狀態 (up(1), down(2), testing(3))
ifOperStatus INTEGER RO 當前的操作接口狀態 (up(1), down(2), testing(3))
ifLastChange TimeTicks RO 接口進入當前操作狀態的時間
ifInOctets Counter RO 接口收到的8元組的總數
ifInUcastPkts Counter RO 遞交到高層協議的子網單播的分組數
ifInNUcastPkts Counter RO 遞交到高層協議的非單播的分組數
ifInDiscards Counter RO 被丟棄的進站分組數
ifInErrors Counter RO 有錯的進站分組數
ifInUnkownProtos Counter RO 由於協議未知而被丟棄的分組數
ifOutOctets Counter RO 接口發送的8元組的總數
ifOutUcastPkts Counter RO 發送到子網單播地址的分組總數
ifOutNUcastPkts Counter RO 發送到非子網單播地址的分組總數
ifOutDiscards Counter RO 被丟棄的出站分組數
ifOutErrors Counter RO 不能被髮送的有錯的分組數
ifOutQLen Gauge RO 輸出分組隊列長度
ifSpecific OBJECT IDENTIFIER RO 參考MIB對實現接口的媒體的定義
3) address translation 組
address translation組由一個表構成，表中的每一行對應系統中的一個物理接口，提供網絡地址向物理地址的映射。一般情況下，網絡地址是指系統在該接口上的IP地址，而物理地址決定於實際採用的子網情況。例如，如果接口對應的是LAN，則物理地址是接口的MAC地址，如果對應X.25分組交換網，則物理地址可能是一個X.121地址。表4.3列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.3 address translation組中的對象
Object Syntax Access Description
atTable SEQUENCE OF AtEntry NA 包含網絡地址對物理地址的映射
atEntry SEQUENCE NA 包含一個網絡地址、物理地址對
atIfIndex INTEGER RW 表格條目的索引
atPhysAddress PhysAddress RW 依賴媒體的物理地址
atNetAddress NetworkAddress RW 對應物理地址的網絡地址
實際上，address translation組包含在MIB-II中只是爲了與MIB-I兼容，MIB-II的地址轉換信息在各個網絡協議組中提供。
4) ip 組
ip組包含有關節點上IP實現和操作的信息，如有關IP層流量的一些計數器。ip組中包含3個表，ipAddrTable、ipRouteTalbe和ipNetToMediaTable。
ipAddrTable包含分配給該實體的IP地址的信息，每個地址被唯一地分配給一個物理地址。
ipRouteTable包含用於互聯網路由選擇的信息。該路由表中信息是比較原本地從一些協議的路由表中抽取而來的。實體當前所知的每條路由都有一個條目，表格由ipRouteDest索引。ipRouteTable中的信息可用於配置的監測，並且由於表中的對象是read-write的，因此也可被用於路由控制。
ipNetToMediaTable是一個提供IP地址和物理地址之間對應關係的地址轉換表。除了增加一個指示映射類型的對象ipNetToMediaType之外，表中所包含的信息與address translation組相同。
此外，ip組中還包含一些用於性能和故障監測的標量對象。
表4.4列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.4 ip組中的對象
Object Syntax Access Description
ipForwarding INTEGER RW 是否作爲IP網關（1/0）
ipDefaultTTL INTEGER RW 插入到該實體生成的數據報的IP頭中Time-To-Live字段中的默認值
ipInReceives Counter RO 接口收到的輸入數據報的總數
ipInHdrErrors Counter RO 由於IP頭錯被丟棄的輸入數據報總數
ipInAddrErrors Counter RO 由於IP地址錯被丟棄的輸入數據報總數
ipForwDatagrams Counter RO 轉發的輸入數據報數
ipInUnknownProtos Counter RO 由於協議未知被丟棄的輸入數據報數
ipInDiscards Counter RO 無適當理由而被丟棄的輸入數據報數
ipInDelivers Counter RO 成功地遞交給IP用戶協議的輸入數據報數
ipOutRequests Counter RO 本地IP用戶協議要求傳輸的IP數據報總數
ipOutNoRoutes Counter RO 由於未找到路由而被丟棄的IP數據報數
ipReasmTimeOut INTEGER RO 重組接收到的碎片可等待的最大秒數
ipReasmReqds Counter RO 接收到的需要重組的IP碎片數
ipReasmOKs Counter RO 成功重組的IP數據報數
ipRaesmFails Counter RO 由IP重組算法檢測到的重組失敗的數目
ipFragsOk Counter RO 成功拆分的IP數據報數
ipFragsFails Counter RO 不能成功拆分而被丟棄的IP數據報數
ipFragsCreates Counter RO 本實體產生的IP數據報碎片數
ipAddrTable SEQUENCE OF IpAddrEntry NA 本實體的IP地址信息(表內對象略)
ipRouteTable SEQUENCE OF IpRouteEntry NA IP 路由表(表內對象略)
ipNetToMediaTable SEQUENCE OF IpNetToMedis Entry NA 用於將IP 映射到物理地址的地址轉換表(表內對象略)
IpRouting Discards Counter RO 被丟棄的路由選擇條目
5) icmp 組
ICMP (Internet Control Message Protocol)是TCP/IP協議族中的一部分，所有實現IP協議的系統都提供ICMP。ICMP提供從路由器或其他主機向主機傳遞消息的手段，它的基本作用是反饋通信環境中存在的問題，例如:數據報不能到達目的地，路由器沒有緩衝區容量來轉發數據報。
icmp組包含有關一個節點的ICMP的實現和操作的信息，具體地講，icmp組由節點接收和發送的各種ICMP消息的計數器所構成由一個表構成。表4.5列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.5 icmp組中的對象
Object Syntax Access Description
icmpInMsgs Counter RO 收到的ICMP消息的總數
icmpInErrors Counter RO 收到的有錯的ICMP的消息數
icmpInDestUnreachs Counter RO 收到的目的地不可到達的消息數
icmpInTimeExcds Counter RO 收到的超時的消息數
icmpInParmProbs Counter RO 收到的有參數問題的消息數
icmpInSrcQuenchs Counter RO 收到的源有問題的消息數
icmpInRedirects Counter RO 收到的重定向的消息數
icmpInEchos Counter RO 收到的要求echo的消息數
icmpInEchoReps Counter RO 收到的應答echo的消息數
icmpInTimestamps Counter RO 收到的要求Timestamp的消息數
icmpInTimestampReps Counter RO 收到的應答Timestamp的消息數
icmpInAddrMasks Counter RO 收到的要求Address Mask的消息數
icmpInAddrMaskReps Counter RO 收到的應答Address Mask的消息數
icmpOutMsgs Counter RO 發出的ICMP消息的總數
icmpOutErrors Counter RO 發出的有錯的ICMP的消息數
icmpOutDestUnreachs Counter RO 發出的目的地不可到達的消息數
icmpOutTimeExcds Counter RO 發出的超時的消息數
icmpOutParmProbs Counter RO 發出的有參數問題的消息數
icmpOutSrcQuenchs Counter RO 發出的源有問題的消息數
icmpOutRedirects Counter RO 發出的重定向的消息數
icmpOutEchos Counter RO 發出的要求echo的消息數
icmpOutEchoReps Counter RO 發出的應答echo的消息數
icmpOutTimestamps Counter RO 發出的要求Timestamp的消息數
icmpOutTimestampReps Counter RO 發出的應答Timestamp的消息數
icmpOutAddrMasks Counter RO 發出的要求Address Mask的消息數
icmpOutAddrMaskReps Counter RO 發出的應答Address Mask的消息數
6) tcp 組
tcp組包含有關一個節點的TCP的實現和操作的信息，圖4.5定義的tcpConnTable包含在這個組中。表4.6列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.6 tcp組中的對象
Object Syntax Access Description
tcpRtoAlgorithm INTEGER RO 重傳時間
tcpRtoMin INTEGER RO 重傳時間的最小值
tcpRtoMax INTEGER RO 重傳時間的最大值
tcpMaxConn INTEGER RO 實體支持的TCP連接數的上限
tcpActiveOpens Counter RO 實體已經支持的主動打開的數量
tcpPassiveOpens Counter RO 實體已經支持的被動打開的數量
tcpAttemptFails Counter RO 已經發生的試連失敗的次數
tcpEstabResets Counter RO 已經發生的復位的次數
tcpCurrEstab Gauge RO 當前狀態爲established的TCP連接數
tcpInSegs Counter RO 收到的segments總數
tcpOutSegs Counter RO 發出的segments總數
tcpRetranSegs Counter RO 重傳的segments總數
tcpConnTable SEQUENCE OF TcpConnTntry NA 包含TCP各個連接的信息(表內對象略，參考圖4.5)
tcpInErrors Counter RO 收到的有錯的segments的總數
tcpOutRsts Counter RO 發出的含有RST標誌的segments數
7) udp 組
udp組包含有關一個節點的UDP的實現和操作的信息。除了有關發送和接收的數據報的信息之外，這個組中還包含一個udpTable表，該表中包含UDP端點的管理信息。所謂UDP端點是指正在支持本地應用接收數據報的UDP進程。udpTable表中包含每個UDP端點用戶的IP地址和UDP端口。表4.7列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.7 udp組中的對象
Object Syntax Access Description
udpInDatagrams Counter RO 遞交該UDP用戶的數據報的總數
udpNoPorts Counter RO 收到的目的端口上沒有應用的數據報總數
udpInErrors Counter RO 收到的無法遞交的數據報數
udpOutDatagrams Counter RO 該實體發出的UDP數據報總數
udpTable SEQUENCE OF UdpEntry NA 包含UDP的用戶信息
udpTable SEQUENCE NA 某個當前UDP用戶的信息
udpLocalAddress IpAddress RO UDP用戶的本地IP地址
udpLocalPort INTEGER RO UDP用戶的本地端口號
8) egp 組
egp組包含有關一個節點的EGP(External Gateway Protocol)的實現和操作的信息。除了有關發送和接收的EGP消息的信息之外，這個組中還包含一個egpNeighTable表，該表中包含有關相鄰網關的信息。表4.8列出了該組中各個對象的名稱、句法、訪問權限和對象描述。
表4.8 egp組中的對象
Object Syntax Access Description
egpInMsgs Counter RO 收到的無錯的EGP消息數
egpInErrors Counter RO 收到的有錯的EGP消息數
egpOutMsgs Counter RO 本地產生的EGP消息總數
egpOutErrors Counter RO 由於資源限制沒有發出的本地產生的EGP消息數
egpNeighTable SEQUENCE OF EgpNeighEntry NA 相鄰網關的EGP表(表內的對象略)
egpAs INTEGER RO 本EGP實體的自治系統數
4.3 簡單網絡管理協議(SNMP)
4.3.1 SNMP支持的操作
SNMP只支持對變量的檢查和修改的操作，具體地，可以對標量對象進行以下三種操作：
l Get：管理站從被管理站提取標量對象值。
l Set：管理站更新被管理站中的標量對象值。
l Trap：被管理站向管理站主動地發送一個標量對象值。
MIB的結構不能通過增加或減少對象實例被改變，並且，訪問只能對對象標識樹中的葉子對象進行。這些限制大大簡化了SNMP的實現，但同時也限制了網絡管理系統的能力。
4.3.2 共同體和安全控制
網絡管理是一種分佈式的應用。與其他分佈式的應用相同，網絡管理中包含由一個應用協議支持的多個應用實體的相互作用。在SNMP網絡管理中，這些應用實體就是採用SNMP的管理站應用實體和被管理站的應用實體。
SNMP網絡管理具有一些不同於其他分佈式應用的特性，它包含一個管理站和多個被管理站之間一對多的關係。即，管理站能夠獲取和設置各管理站的對象，能夠從各被管理站中接收陷阱信息。因此，從操作或控制的角度來看，管理站管理着多個被管理站。同時，系統中也可能有多個管理站，每個管理站都管理所有的或一部分被管理站。
反過來，我們也要看到SNMP網絡管理中還包含另外一種一對多的關係―一個被管理站和多個管理站之間的關係。每個被管理站控制着自己的本地MIB，同時必須能夠控制多個管理站對這個本地MIB的訪問。這裏所說的控制有以下三個方面:
l 認證服務:將對MIB的訪問限定在授權的管理站的範圍內;
l 訪問策略:對不同的管理站給予不同的訪問權限;
l 代管服務:一個被管理站可以作爲其他一些被管理站(託管站)的代管，這就要求在這個代管系統中實現爲託管站服務的認證服務和訪問權限。
以上這些控制都是爲了保證網絡管理信息的安全，即被管系統需要保護它們的MIB不被非法地訪問。SNMP通過共同體(community)的概念提供了初步的和有限的安全能力。
SNMP用共同體來定義一個代理者和一組管理者之間的認證、訪問控制和代管的關係。共同體是一個在被管系統中定義的本地的概念。被管系統爲每組可選的認證、訪問控制和代管特性建立一個共同體。每個共同體被賦予一個在被管系統內部唯一的共同體名，該共同體名要提供給共同體內的所有的管理站，以便它們在get和set操作中應用。代理者可以與多個管理站建立多個共同體，同一個管理站可以出現在不同的共同體中。
由於共同體是在代理者處本地定義的，因此不同的代理者處可能會定義相同的共同體名。共同體名相同並不意味者共同體有什麼相似之處，因此，管理站必須將共同體名與代理者聯繫起來加以應用。
認證服務
認證服務是爲了保證通信是可信的。在SNMP消息的情況下，認證服務的功能是保證收到的消息是來自它所聲稱的消息源。SNMP只提供一種簡單的認證模式:所有由管理站發向代理者的消息都包含一個共同體名，這個名字發揮口令的作用。如果發送者知道這個口令，則認爲消息是可信的。
通過這種有限的認證形式，網絡管理者可以對網絡監控(set、trap)特別是網絡控制(set)操作進行限制。共同體名被用於引發一個認證過程，而認證過程可以包含加密和解密以實現更安全的認證。
訪問策略
通過定義共同體，代理者將對它的MIB的訪問限定在了一組被選擇的管理站中。通過使用多個共同體，代理者可以爲不同的管理站提供不同的MIB訪問控制。訪問控制包含兩個方面:
l SNMP MIB 視圖:MIB中對象的一個子集。可以爲每個共同體定義不同的MIB視圖。視圖中的對象子集可以不在MIB的一個子樹之內。
l SNMP 訪問模式:READ-ONLY 或 READ-WRITE。爲每個共同體定義一個訪問模式。
MIB視圖和訪問模式的結合被稱爲SNMP共同體輪廓(profile)。即，一個共同體輪廓由代理者處MIB的一個子集加上一個訪問模式構成。SNMP訪問模式統一地被用於MIB視圖中的所有對象。因此，如果選擇了READ-ONLY訪問模式，則管理站對視圖中的所有對象都只能進行read-only操作。
事實上，在一個共同體輪廓之內，存在兩個獨立的訪問限制―MIB對象定義中的訪問限制和SNMP訪問模式。這兩個訪問限制在實際應用中必須得到協調。表4.9給出了這兩個訪問限制的協調規則。注意，對象被定義爲write-only，SNMP也可以對其進行read操作。
表4.9 MIB對象定義中的ACCESS限制與SNMP訪問模式的關係
MIB對象定義中的ACCESS限制 SNMP訪問模式
READ-ONLY READ-WRITE
read-only get和trap操作有效
read-write get和trap操作有效 get，set和trap操作有效
Write-only get和trap操作有效，但操作值與具體實現有關 get，set和trap操作有效，但操作值與具體實現有關
not-accessible 無效
在實際應用中，一個共同體輪廓要與代理者定義的某個共同體聯繫起來，便構成了SNMP的訪問策略(access policy)。即SNMP的訪問策略指出一個共同體中的MIB視圖及其訪問模式。
代管服務
共同體的概念對支持代管服務也是有用的。如前所述，在SNMP中，代管是指爲其他設備提供管理通信服務的代理者。對於每個託管設備，代管系統維護一個對它的訪問策略，以此使代管系統知道哪些MIB對象可以被用於管理託管設備和能夠用何種模式對它們進行訪問。
4.3.3 實例標識
我們已經看到，MIB中的每個對象都有一個由其在樹型結構的MIB中所處的位置所定義的唯一的對象標識符。但是，應該注意到，MIB樹型結構給出的對象標識符在一些情況下只是對象類型的標識符，不能唯一地標識對象的實例。例如表格的對象標識符不能標識表格中各個條目。由於對MIB的訪問是對對象實例的訪問，因此各個對象實例都必須有唯一標識的方法。
縱列對象
表中的對象被稱爲縱列對象。縱列對象標識符不能獨自標識對象實例，因爲表中的每一行都有縱列對象的一個實例。爲了實現這類對象實例的唯一標識，SNMP實際定義了兩種技術:順序訪問技術和隨機訪問技術。順序訪問技術是通過利用辭典編排順序實現的。而隨機訪問技術是通過利用索引對象值實現的。下面首先討論隨機訪問技術。
一個表格是由零到多個行(條目)構成的，每一行都包含一組相同的標量對象類型，或稱縱列對象。每個縱列對象都有一個唯一的標識符。但由於縱列對象可能有多個實例，因此縱列對象標識符並不能唯一標識它的各個實例。然而，在定義表格時，一般包含一個特殊的縱列對象INDEX，即索引對象，它的每個實例都具有不同的值，可以用來標識表中的各行。因此，SNMP採用將索引對象值連接在縱列對象標識符之後的方法來標識縱列對象的實例。
作爲例子，我們看一下interfaces組中的ifTable。表中有一個索引對象ifIndex，它的值是一個1到ifNumber之間的整數，對應每個接口，ifIndex有一個唯一的值。現在假設要獲取系統中第2個接口的接口類型ifType。ifType的對象標識符是1.3.6.1.2.1.2.2.1.3。而第2個接口的ifIndex值是2。因此對應第2個接口的ifType的實例的標識符便爲1.3.6.1.2.1.2.2.1.3.2。即將這個ifIndex的值作爲實例標識符的最後一個子標識符加到ifType對象標識符之後。
表格及行對象
對於表格和行對象，沒有定義它們的實例標識符。這是因爲表格和行不是葉子對象，因而不能由SNMP訪問。在這些對象的MIB定義中，它們的ACCESS特性被設爲not-accessible。
標量對象
在標量對象的場合，用對象類型標識符便能唯一標識它的實例，因爲每個標量對象類型只有一個對象實例。但是，爲了與表格對象實例標識符的約定保持一致，也爲了區分對象的類型和對象實例，SNMP規定標量對象實例的標識符由其對象類型標識符加0組成。
4.3.4 辭典編纂式排序
對象標識符是反映該對象在MIB中的樹型結構的一個整數序列。給出一個MIB的樹型結構，跟蹤從root開始到某個特定對象的路徑，便可以得到該對象的對象標識符。
由於對象標識符是一個整數序列，因此，可以把它們看作是某本書的內容在書中的章節排序。總排序可以通過遍歷MIB中的對象標識符樹來生成。利用這個總排序，也可以對對象實例進行唯一的標識。
因爲網絡管理站對代理者提供MIB視圖的構成不一定完全清楚，因此，它需要一種不必提供對象名稱而能訪問對象的方法。在這種情況下，對象及其實例的排序就是非常重要的。利用這個排序，管理站可以有效地遍歷一個MIB的結構。因爲管理站只要提供樹型結構的任意一點上的一個對象實例的標識符，就可以順序地對其後繼的對象實例進行訪問。
4.3.5 SNMP消息格式
管理站和代理者之間以傳送SNMP消息的形式交換信息。每個消息包含一個指示SNMP版本號的版本號，一個用於本次交換的共同體名，和一個指出5種協議數據單元之一的消息類型。圖4.6描述了這種結構。表4.10對其中的元素進行了說明。
(a) GetRequest PDU, GetNextRequest PDU, SetRequest PDU
(b) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU
(c) Response PDU
(d) Trap PDU
(e) Variable-bindings
圖4.6 SNMP消息格式
表4.10 SNMP消息字段
字 段 描 述
version SNMP版本
community 共同體的名字用作SNMP認證消息的口令
request-id 爲每個請求賦予一個唯一的標識符
error-status noError(0),tooBig(1),noSuchName(2),badValue(3),readOnly(4),genErr(5)
error-index 當error-status非0時，可以進一步提供信息指出哪個變量引起的問題
variable-bindings 變量名及其對應值清單
enterprise 生成trap的對象的類型
agent-addr 生成trap的對象的地址
generic-trap 一般的trap類型:coldStart(0),warmStart(1),linkDown(2),linkUp(3), authentication-Failure(4),egpNeighborLoss(5),enterprise-Specific(6)
secific-triap 特定的Trap代碼
time-stamp 網絡實體從上次啓動到本trap生成所經歷的時間
SNMP消息的發送
一般情況下，一個SNMP協議實體完成以下動作向其他SNMP實體發送PDU:
l 構成PDU。
l 將構成的PDU、源和目的傳送地址以及一個共同體名傳給認證服務。認證服務完成所要求的變換，例如進行加密或加入認證碼，然後將結果返回。
l SNMP協議實體將版本字段、共同體名以及上一步的結果組合成爲一個消息。
l 用基本編碼規則(BER)對這個新的ASN.1的對象編碼，然後傳給傳輸服務。
SNMP消息的接收
一般情況下，一個SNMP協議實體完成以下動作接收一個SNMP消息
l 進行消息的基本句法檢查，丟棄非法消息
l 檢查版本號，丟棄版本號不匹配的消息
l SNMP協議實體將用戶名、消息的PDU部分以及源和目的傳輸地址傳給認證服務。如果認證失敗，認證服務通知SNMP協議實體，由它產生一個trap並丟棄這個消息;如果認證成功，認證服務返回SNMP格式的PDU。
l 協議實體進行PDU的基本句法檢查，如果非法，丟棄該PDU，否則利用共同體名選擇對應的SNMP訪問策略，對PDU進行相應處理。
變量綁定
在SNMP中，可以將多個同類操作(get、set、trap)放在一個消息中。如果管理站希望得到一個代理者處的一組標量對象的值，它可以發送一個消息請求所有的值，並通過獲取一個應答得到所有的值。這樣可以大大減少網絡管理的通信負擔。
爲了實現多對象交換，所有的SNMP的PDU都包含了一個變量綁定字段。這個字段由對象實例的一個參考序列及這些對象的值構成。某些PDU只需給出對象實例的名字，如get操作。對於這樣的PDU，接收協議實體將忽略變量綁定字段中的值。
4.3.6 GetRequest PDU
SNMP實體應網絡管理站應用程序的請求發出GetRequest PDU。發送實體將以下字段包含在PDU之中:
l PDU類型:指出GetRequest PDU類型。
l request-id:Request-id能夠使SNMP應用將得到的各個應答與發出的各個請求一一對應起來。同時也可以使SNMP實體能夠處理由於傳輸服務的問題而產生的重複的PDU。
l variablebindings:要求獲取值的對象實例清單。
GetRequest PDU 的SNMP接收實體用包含相同request-id的GetResponse PDU進行應答。GetRequest操作是原子操作―要麼所有的值都提取回來，要麼一個都不提取。
GetRequst 操作不成功的原因有對象名不匹配(noSuchName)、返回結果太長(tooBig)以及其他原因(genErr)。
SNMP只允許提取MIB樹中的葉子對象的值。因此不能只提供一個表或一個條目的名字來獲取整個表或整行的對象值。但是可以將表中每行的各個對象包含在變量綁定中，來一次獲取一行的對象值。
4.3.7 GetNextRequest PDU
GetNextRequest PDU幾乎與GetRequest PDU相同。它們具有相同交換模式和相同的格式。唯一的不同是:在GetRequest PDU中，變量綁定字段中列出的是要取值的對象實例名本身，而在GetNextRequest PDU中，變量綁定字段列出的是要取值的對象實例的“前一個”對象實例名。與GetRequest相同，GetNextRequest也是原子操作。
雖然與GetRequest的外在差異不大，但是GetNextRequest卻有GetRequest無法替代的用途。它能夠使網絡管理站去動態地發現一個MIB視圖的結構。它也爲查找不知其條目的表提供了一個有效的機制。
簡單對象值的提取
假設網絡管理站希望從某個代理者處提取udp組中的所有簡單對象，則它可以發出一個如下的PDU:
GetRequest(udpInDatagrams.0，udpNoPorts.0,udpInError.0,udpOutDatagrams.0)
如果代理者支持所有這些對象，則將返回一個包含這4個對象值的GetResponse PDU:
GetResponse((udpInDatagrams.0 = 100), (udpNoPorts.0 = 1), (udpInErrors.0 = 2),
(udpOutDatagrams.0 = 200))
這裏，100，1，2和200分別是這4個對象的值。然而，只要有一個對象不被支持，則代理者將返回一個含有錯誤碼NoSuchName的GetResponse PDU，而不返回任何其他值。爲了確保得到所有可用的對象值，管理站必須分別發出4個GetRequest PDU。
現在考慮應用GetNextRequest PDU的情況:
GetNextRequest (udpInDatagrams, udpNoPorts, udpInErrors, udpOutDatagrams)
其中，udpInDatagrams = 1.3.6.1.2.1.7.1, udpNoPorts = 1.3.6.1.2.1.7.2, udpInErrors = 1.3.6.1.2.1.7.3, udpOutDatagrams = 1.3.6.1.2.1.7.4。
在這種情況下，代理者將返回清單中每個標識符的“下一個”對象實例的值。假設4個對象都被支持，則代理者返回一個如下的GetResponse PDU:
GetResponse((udpInDatagrams.0 = 100), (udpNoPorts.0 = 1), (udpInErrors.0 = 2),
(udpOutDatagrams.0 = 200))
這與前面的情況相同。假設udpNoPorts在本視圖中是不存在(不可見)的，則代理者的應答爲:
GetResponse((udpInDatagrams.0 = 100), (udpInErrors.0 = 2), (udpInErrors.0 = 2),
(udpOutDatagrams.0 = 200))
由於udpNoPorts.0 = 1.3.6.1.2.1.7.2.0在本MIB視圖中是不存在的標識符，因此udpNoPorts的“下一個”對象實例便成了udpInError.0 = 1.3.6.1.2.1.7.3.0。
通過對比可知，GetNextRequest在提取一組對象值時比GetRequest效率更高，更靈活。
提取未知對象
GetNextRequest要求代理者提取所提供的對象標識符的下一個對象實例的值，因此，發送這類PDU時，並不要求提供MIB視圖中實際存在的對象或對象實例的標識符。利用這一特點，管理站可以使用GetNextRequest PDU去探查一個MIB視圖，並搞清它的結構。在我們上面的例子中，如果管理站發出一個GetNextRequest(udp) PDU，則將獲得 Response(udpInDatagrams.0 = 100) 的應答。管理站因此便知道了在這個MIB視圖中第一個被支持的對象是udpInDatagrams，並且知道了它的當前值。
4.3.8 SetRequest PDU
SNMP實體應網絡管理站應用程序的請求發出SetRequest PDU。它與GetRequest PDU具有相同的交換模式和相同的格式。但是，SetRequest 是被用於寫對象值而不是讀。因而，變量綁定清單中既包含對象實例標識符，也包含每個對象實例將被賦予的值。
SetRequest PDU 的SNMP接收實體用包含相同request-id的GetResponse PDU進行應答。SetRequest操作是原子操作―要麼變量綁定中的所有變量都被更新，要麼一個都不被更新。如果應答實體能夠更新變量綁定中的所有變量，則GetResponse PDU中包含提供給各個變量的值的變量綁定字段。只要有一個變量值不能成功地設置，則無變量值返回，也無變量值被更新。在GetRequest操作中可能返回的錯誤―noSuchName、tooBig和genErr也是SetRequest可能返回的錯誤。另外一個可能返回的錯誤是badValue，只要SetRequest中有一個變量名和變量值不一致的問題，就會返回這個錯誤。所謂不一致可能是類型的問題，也可能是長度的問題，還可能是提供的實際的值有問題。
利用SetRequest不僅可以對葉子對象實例進行值的更新，也可以利用變量綁定字段進行表格的行增加和行刪除操作。
除此之外，SetRequest還可被用於完成某種動作。SNMP沒有提供一種命令代理者完成某種動作的機制，它的全部能力就是在一個MIB視圖內get和set對象值。但是利用set的功能可以間接地發佈完成某種動作的命令。某個對象可以代表某個命令，當它被設置爲特定值時，就執行特定的動作。例如代理者可以設一個初始值爲0的對象reBoot，如果管理站將這個對象值置1，則代理者系統被重新啓動，reBoot的值也被重新置0。
4.3.9 Trap PDU
SNMP實體應網絡管理代理者應用程序的請求發出Trap PDU。它被用於向管理站異步地通報某個重要事件。它的格式與其他的SNMP PDU完全不同。所包含的字段有:
l PDU類型:指出Trap PDU類型
l enterprise:標識產生本Trap的網絡管理子系統(用System組中的sysObjectId值)
l agent-addr:產生本Trap的對象的IP地址
l generic-trap:一種預定義的trap
l specific-trap:更明確地指出trap特性的代碼
l time-stamp:發出trap的網絡實體從上次重啓到產生本trap所經歷的時間
l variablebindings:有關trap的附加信息(本字段的意義有具體實現有關)
4.3.10 傳輸層的支持
SNMP需要利用傳輸層的服務來傳遞SNMP消息，但是它並未假定傳輸層的服務是可靠的還是非可靠的，是無連接的還是面向連接的。
但是實際上，在TCP/IP體系中，SNMP的實現幾乎都是使用無連接協議用戶數據報(UDP)。UDP頭中包含源和目的端口字段，允許應用層協議，如SNMP填寫地址。它還包含一個可選的覆蓋UDP頭和用戶數據的校驗和(checksum)。如果校驗和有問題，UDP片段(segment)被丟棄。兩個端口號給SNMP應用，用於代理者偵聽GetRequest, GetNextRequest和SetRequest命令的161端口和用於管理站偵聽Trap命令的162端口。
由於UDP是非可靠的，因此SNMP的消息可能被丟失。SNMP本身也不保證消息的可靠傳遞，因此，處理消息丟失問題的負擔只能由SNMP的用戶自己承擔。
如何處理SNMP消息的丟失沒有標準的方法，只能憑通常的感覺處理。在GetRequest和GetNextRequest的場合，如果在規定的時間內得不到應答，管理站可以認爲或者是發出的命令消息被丟失，或者是代理者返回的應答被丟失。管理站可以再次或多次重發請求，直至成功或最終放棄。由於相同的請求具有相同的request-id，因此重發可能會使接收者收到多個相同的消息，但這並不會引起問題，因爲接收者可以簡單地將收到的重複的消息丟棄。
在SetRequest的場合，如果在規定的時間內得不到應答，爲了確認操作是否成功，可以用GetRequest操作進行確認。如果確認set操作沒被執行，可以重發SetRequest。
由於SNMP的Trap沒有應答消息，因此沒有簡單的方法去檢驗Trap的傳遞。在SNMP中，Trap一般用於提供重要事件的早期告警，作爲後備方法，管理站還要定期地輪詢代理者獲取相關的狀態。
4.4 SNMPv2
4.4.1 SNMPv2對SNMPv1的改進
1993年，SNMP的改進版SNMPv2開始發佈，從此，原來的SNMP便被稱爲SNMPv1。最初的SNMPv2最大的特色是增加了安全特性，因此被稱爲安全版SNMPv2。但不幸的是，經過幾年試用，沒有得到廠商和用戶的積極響應，並且也發現自身還存在一些嚴重缺陷。因此，在1996正式發佈的SNMPv2中，安全特性被刪除。這樣，SNMPv2對SNMPv1的改進程度便受到了很大的削弱。
總的來說，SNMPv2的改進主要有以下3個方面：
l 支持分佈式管理；
l 改進了管理信息結構；
l 增強了管理信息通信協議的能力。
SNMPv1採用的是集中式網絡管理模式。網絡管理站的角色由一個主機擔當。其他設備(包括代理者軟件和MIB)都由管理站監控。隨着網絡規模和業務負荷的增加，這種集中式的系統已經不再適應需要。管理站的負擔太重，並且來自各個代理者的報告在網上產生大量的業務量。而SNMPv2不僅可以採用集中式的模式，也可以採用分佈式模式。在分佈式模式下，可以有多個頂層管理站，被稱爲管理服務器。每個管理服務器可以直接管理代理者。同時，管理服務器也可以委託中間管理者擔當管理者角色監控一部分代理者。對於管理服務器，中間管理器又以代理者的身份提供信息和接受控制。這種體系結構分散了處理負擔，減小了網絡的業務量。
SNMPv2的管理信息結構（SMI）在幾個方面對SNMPv1的SMI進行了擴充。定義對象的宏中包含了一些新的數據類型。最引人注目的變化是提供了對錶中的行進行刪除或建立操作的規範。新定義的SNMPv2 MIB包含有關SNMPv2協議操作的基本流量信息和有關SNMPv2管理者和代理者的配置信息。
在通信協議操作方面，最引人注目的變化是增加了兩個新的PDU―GetBulkRequest 和 InformRequest。前者使管理者能夠有效地提取大塊的數據，後者使管理者能夠向其他管理者發送trap信息。
4.4.2 SNMPv2網絡管理框架
SNMPv2提供了一個建立網絡管理系統的框架。但網絡管理應用，如故障管理、性能監測、計費等不包括在SNMPv2的範圍內。用術語來說，SNMPv2提供的是網絡管理基礎結構。圖4.7是這種基礎結構的一個配置例。
SNMPv2本質上是一個交換管理信息的協議。網絡管理系統中的每個角色都維護一個與網絡管理有關的MIB。SNMPv2的SMI對這些MIB的信息結構和數據類型進行定義。SNMPv2提供了一些一般的通用的MIB，廠商或用戶也可以定義自己私有的MIB。
在配置中至少有一個系統負責整個網絡的管理。這個系統就是網絡管理應用駐留的地方。管理站可以設置多個，以便提供冗餘或分擔大網絡的管理責任。其他系統擔任代理者角色。代理者收集本地信息並保存，以備管理者提取。這些信息包括系統自身的數據，也可以包括網絡的業務量信息。
SNMPv2既支持高度集中化的網絡管理模式，也支持分佈式的網絡管理模式。在分佈式模式下，一些系統擔任管理者和代理者兩種角色，這種系統被稱爲中間管理者。中間管理者以代理者身份從上級管理系統接受管理信息操作命令，如果這些命令所涉及的管理信息在本地MIB中，則中間管理者便以代理者身份進行操作並進行應答，如果所涉及的管理信息在中間管理者的下屬代理者的MIB中，則中間管理者先以管理者身份對下屬代理者進行發佈操作命令，接收應答，然後再以代理者身份向上級管理者應答。
所有這些信息交換都利用SNMPv2通信協議實現。與SNMPv1相同，SNMPv2協議仍是一個簡單的請求(request)/應答(response)型協議，但在PDU種類和協議功能方面對SNMPv1進行了擴充。
圖4.7 SNMPv2的配置
4.4.3 協議操作
SNMPv2消息
與SNMPv1相同，SNMPv2以包含協議數據單元(PDU)的消息的形式交換信息。外部的消息結構中包含一個用於認證的共同體名。
SNMPv2確定的消息結構如下:
Message :: = SEQUENCE {
version INTEGER { version (1) }, -- SNMPv2的版本號爲1
community OCTET STRING, -- 共同體名
data ANY -- SNMPv2 PDU
}
4.3.2節中對於共同體名、共同體輪廓和訪問策略的討論同樣適用於SNMPv2。
SNMPv2消息的發送和接收過程與4.3.5節中描述的SNMPv1消息的發送和接收過程相同。
PDU格式
表4.11 SNMP協議數據單元(PDUs)
PDU 描 述 SNMPv1 SNMPv2
GetGetNextGetBulkSetTrapInformResponse 管理者通過代理者獲得每個對象的值管理者通過代理者獲得每個對象的下一個值管理者通過代理者獲得每個對象的N個值管理者通過代理者爲每個對象設置值代理者向管理者傳送隨機信息管理者向代理者傳送隨機信息代理者對管理者的請求進行應答 ○○○○○ ○○○○○○○
在SNMPv2消息中可以傳送7類PDU。表4.11列出了這些PDU，同時指出了對SNMPv1也有效的PDU。圖4.8 描述了SNMPv2 PDU的一般格式。
(a) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU,
SNMPv2-Trap-PDU,InformRequest-PDU
(b) Response-PDU
(c) GetBulkRequest-PDU
(d) Variable-bindings
圖4.8 SNMPv2 PDU格式
值得注意的是，GetRequest、GetNextRequest、SetRequest、SNMPv2-Trap、InformReques 5種PDU具有完全相同的格式，並且與也可以看作是error-status和error-index兩個字段被置零的Response PDU的格式。這樣設計的目的是爲了減少SNMPv2實體需要處理的PDU格式種類。
GetRequest PDU
SNMPv2的GetRequest PDU的語法和語義都與SNMPv1的GetRequest PDU相同，差別是對應答的處理。SNMPv1的GetRequest是原子操作:要麼所有的值都返回，要麼一個也不返回，而SNMPv2能夠部分地對GetRequest操作進行應答。即使有些變量值提供不出來，變量綁定字段也要包含在應答的GetResponse PDU之中。如果某個變量有意外情況(noSuchObject, noSuchInstance,endOfMibView)，則在變量綁定字段中，這個變量名與一個代表意外情況的錯誤代碼而不是變量值配對。
在SNMPv2中，按照以下規則處理GetRequest變量綁定字段中的每個變量來構造應答PDU:
l 如果OBJECT IDENTIFIER前綴與該請求在代理者處所能訪問的變量的前綴都不匹配，則它的值字段被設置爲noSuchObject;
l 否則，如果變量名與該請求在代理者處所能訪問的變量的名稱都不匹配，則它的值字段被設置爲noSuchInstance;
l 否則，值字段被設置爲變量值。
如果由於其他原因導致變量名處理過程的失敗，則無法返回變量值。這時，應答實體將返回一個error-status字段值爲genErr，並在error-index字段中指出出問題的變量的應答PDU。
如果生成的應答PDU中的消息尺寸過大，超過了指定的最大限度，則生成的PDU被丟棄，並用一個error-status字段值爲tooBig，error-index字段值爲0，變量綁定字段爲空的新的PDU應答。
允許部分應答是對GetRequest的重要改進。在SNMPv1中，只要有一個變量值取不回來，所有的變量值就都不能返回。在這種情況下，發出操作請求的管理者往往只能將命令拆分爲多條只取單個變量值的命令。相比之下，SNMPv2的操作效率得到了很大提高。
GetNextRequest PDU
SNMPv2的GetNextRequest PDU的語法和語義都與SNMPv1的GetNextRequest PDU相同。與GetRequestPDU相同，兩個版本的差別是對應答的處理。SNMPv1的GetNextRequest是原子操作:要麼所有的值都返回，要麼一個也不返回，而SNMPv2能夠部分地對GetNextRequest操作進行應答。
在SNMPv2中，按照以下規則處理GetNextRequest變量綁定字段中的每個變量來構造應答PDU:
l 確定被指名的變量下一個變量，將該變量名和它的值成對地放入結果變量綁定字段中;
l 如果被指定的變量之後不存在變量，則將被指定的變量名和錯誤代碼endOfMibView成對地放入結果變量綁定字段中。
如果由於其他原因導致變量名處理過程的失敗，或者是產生的結果太大，處理過程與GetRequest相同。
GetBulkRequest
SNMPv2的一個主要改進是GetBulkRequest PDU。這個PDU的目的是儘量減少查詢大量管理信息時所進行的協議交換次數。GetBulkRequest PDU允許SNMPv2管理者請求得到在給定的條件下儘可能大的應答。
GetBulkRequest操作利用與GetNextRequest相同的選擇原則，即總是順序選擇下一個對象。不同的是，利用GetBulkRequest，可以選擇多個後繼對象。
GetBulkRequest操作的基本工作過程如下：GetBulkRequest在變量綁定字段中放入一個(N+R)個變量名的清單。對於前N個變量名，查詢方式與GetNextRequest相同。即，對清單中的每個變量名，返回它的下一個變量名和它的值，如果沒有後繼變量，則返回原變量名和一個endOfMibView的值。
GetBulkRequest PDU有兩個其他PDU所沒有的字段，non-repeaters和max-repetitions。
non-repeaters字段指出只返回一個後繼變量的變量數。max-repetitions字段指出其他的變量應返回的最大的後繼變量數。爲了說明算法，我們定義：
L = 變量綁定字段中的變量名數量
N = 只返回一個後繼變量的變量名數
R = 返回多個後繼變量的變量名數
M = 最大返回的後繼變量數
在上述變量之間存在以下關係：
N = MAX [MIN(non-reperters, L)，0]
M = MAX [max-repetitions,0]
R = L - N
如果N大於0，則前N個變量與GetNextRequest一樣被應答。如果R大於0並且M大於0，則對應後面的R個變量，返回M個後繼變量。即，對於每個變量：
・獲得給定變量的後繼變量的值；
・獲得下一個後繼變量的值；
・反覆執行上一步，直至獲得M個對象實例。
如果在上面的過程中的某一點，已經沒有後繼變量，則返回endOfMibView值，在變量名處，返回最後一個後繼變量，如果沒有後繼變量，則返回請求中的變量名。
利用這個規則，能夠產生的name-value對的數量是N+(M×R)。後面的(M×R)對在應答PDU中的順序可描述爲：
for i : = 1 to M do
for r : = 1 to R do
retrieve i-th successor of (N+r)-th variable
即，返回的後繼變量是一行一行的，而不是先返回第一個變量的所有後繼變量，再返回第二個變量的所有後繼變量，等等。
GetBulkRequest操作解除了SNMP的一個主要限制，即不能有效地檢索大塊數據。此外，利用這個功能可以減小管理應用程序的規模。管理應用程序自身不需要關心組裝在一起的請求的細節。不需要執行一個試驗過程來確認請求PDU中的name-value對的最佳數量。並且，即使GetBulkRequest發出的請求過大，代理者也會盡量多地返回數據不是簡單地返回一個tooBig的錯誤消息。爲了獲得缺少的數據，管理者只需簡單地重發請求，而不必將原來的請求改裝爲小的請求序列。
SetRequest
SetRequest PDU由管理者發出，用來請求改變一個或多個對象的值。接收實體用一個包含相同request-id的Response PDU應答。與SNMPv1相同，SetRequest操作是原子操作，即或者更新所有被指名的變量，或者所有的都不更新。如果接收實體能夠爲被指名的所有變量設置新值，則Response PDU返回與SetRequest相同的變量綁定字段。只要有一個變量值沒設置成功，就不更新任何值。
SetRequest的變量綁定分兩個階段處理。在第一階段，確認每個綁定對。如果所有的綁定對都被確認，則進入第二階段―改變每個變量。即每個變量的set操作都在第二階段進行。
在第一階段中，對每個綁定對進行以下確認，直至所有的都成功或遇到一個失敗。失敗的原因有:不可訪問(noAccess)、無法建立或修改(notWritable)、數據類型不一致(wrongType)、長度不一致(wrongLength)、ASN.1編碼不一致、變量值有問題(wrongValue)、變量不存在且無法建立(noCreation)等。如果任意一個變量遇到以上情況，則返回一個在error-status字段給出上述錯誤代碼，在error-index字段給出有問題的變量的序號的應答PDU。與SNMPv1相比，提供了更多的錯誤代碼。爲管理站更容易地確定失敗的原因提供了方便。
如果在確認階段沒有遇到問題，則進入第二階段―更新在變量綁定字段中被指名的所有的變量。不存在的變量需要建立，存在的變量被賦予新值。只要遇到任何失敗，則所有的更新都被撤銷，並則返回一個error-status字段值爲commitFailed的應答PDU。
SNMPv2 Trap
SNMPv2 Trap PDU由一個代理者實體在發現異常事件時產生併發給管理站。與SNMPv1相同，它用於向管理站提供一個異步的通報以便報告重要事件。但它的格式與SNMPv1不同，與GetRequest、GetNextRequest、GetBulkRequest、SetRequest和InformRequest PDU擁有相同的格式。變量綁定字段用於容納與陷阱消息有關的信息。Trap PDU是一個非認證消息，不要求接收實體應答。
InformRequest
InformRequest PDU由一個管理者角色的SNMPv2實體應它的應用的要求發給另一個管理者角色的SNMPv2實體，請求後者向某個應用提供管理信息。與SNMPv2 Trap PDU類似，變量綁定字段被用於傳送相關的信息。
收到InformRequest的實體首先檢查承載應答PDU的消息尺寸，如果消息尺寸超過限度，用一個含有tooBig錯誤代碼的Response PDU應答。否則，接收實體將PDU中的內容轉到信息的目的地(某個應用)，同時對發出InformRequest的管理者用error-status字段值爲noError的Response PDU進行應答。
4.5 SNMPv3
4.5.1 SNMP管理框架的體系結構
一個SNMP管理系統由若干包含SNMP實體的節點組成。在這些實體中，至少有一個實體包含命令產生者，和/或通報接收者的應用(對應以往的管理者)，多個實體包含能夠訪問管理設備的命令和通報產生者應用 (對應以往的代理者)。實體間用管理通信協議傳遞管理信息。
執行命令生成者和通報接收者應用的SNMP實體監測和控制被管元素。被管元素是指主機、路由器、終端服務器等設備。這些被管元素的監測和控制通過對它們的管理信息的訪問實現。
在實現方面，對SNMP的體系結構會有以下不同的要求:
1. 具有命令應答者和/或通報生成者應用的實體(最小的SNMP);
2. 具有代管轉發者應用的SNMP實體;
3. 具有命令產生者和/或通報接收者應用的命令行驅動的SNMP實體;
4. 具有命令生成者和/或通報接收者應用，並具有命令應答和/或通報產生者應用的SNMP實體(以往稱爲SNMP中間層管理者或雙重角色實體);
5. 具有命令生成者和/或通報接收者，及爲管理潛在的非常大量的被管節點可能的其它應用的SNMP實體(以往稱爲網絡管理站);
爲了能夠統一滿足以上要求，SNMPv3定義了一個可進化的體系結構。
4.5.2 SNMP實體
SNMP實體是體系結構的一個實現。如圖4.9所示，每個SNMP實體都包含一個SNMP引擎、一個或多個應用。
+-------------------------------------------------------------------+
| SNMP entity |
| |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | | | | | | | | | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
圖 4.9 SNMP 實體
SNMP引擎爲發送和接收消息、認證和加密消息、控制對被管對象的訪問提供服務。SNMP引擎與包含它的SNMP實體之間存在一對一的聯繫。引擎包括中包括
l 發報機(Dispatcher),
l 消息處理子系統(Message Processing Subsystem),
l 安全子系統(Security Subsystem)，
l 訪問控制子系統(Access Control Subsystem)。
在一個管理域中，每個引擎都有一個唯一的和明確的標識符snmpEngingID。由於引擎和實體之間一一對應，因此snmpEngingID也能在管理域中唯一地、明確地標識實體。但是，在不同的管理域中，SNMP的實體可能會有相同的snmpEngineID。
一個引擎中只有一個發報機，但能夠同時支持多個版本的SNMP消息。它的功能包括:
l 向網絡發送或從網絡接收SNMP消息，
l 確定SNMP消息的版本，與相應的消息處理模型相互作用，
l 爲SNMP應用提供抽象接口，用以嚮應用傳遞PDU，
l 爲SNMP應用提供抽象接口，用以允許它們向遠程SNMP實體發送PDU。
4.5.3 消息處理子系統
消息處理子系統負責準備要發送的消息和從收到的消息中抽取數據。如圖4.10所示，消息處理子系統潛在地包含多個消息處理模型。
+------------------------------------------------------------------+
| |
| Message Processing Subsystem |
| |
| +------------+ +------------+ +------------+ +------------+ |
| | * | | * | | * | | * | |
| | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | |
| | Message | | Message | | Message | | Message | |
| | Processing | | Processing | | Processing | | Processing | |
| | Model | | Model | | Model | | Model | |
| | | | | | | | | |
| +------------+ +------------+ +------------+ +------------+ |
| |
+------------------------------------------------------------------+
4.10 消息處理子系統
每個消息處理模型定義一個特定版本的SNMP消息的格式，對應所定義的格式對準備和抽取處理進行相應的調整。
4.5.4 安全子系統
安全子系統提供諸如消息的認證和隱私的安全服務。如圖4.11所示，SNMPv3採用User-Based安全模型，但潛在的安全模型可有多個。
+------------------------------------------------------------------+
| |
| Security Subsystem |
| |
| +----------------+ +-----------------+ +-------------------+ |
| | * | | * | | * | |
| | User-Based | | Other | | Other | |
| | Security | | Security | | Security | |
| | Model | | Model | | Model | |
| | | | | | | |
| +----------------+ +-----------------+ +-------------------+ |
| |
+------------------------------------------------------------------+
4.11 安全子系統
安全模型要指出它所防範的威脅，服務的目標和爲提供安全服務所採用的安全協議，如認證和隱私。
安全協議指出爲提供安全服務所採用的機制、過程和MIB對象。
4.5.5 訪問控制子系統
訪問控制子系統通過一個或多個訪問控制模型提供認證服務。如圖4.12所示，View-Based 訪問控制模型是SNMPv3所建議的。
+------------------------------------------------------------------+
| |
| Access Control Subsystem |
| |
| +---------------+ +-----------------+ +------------------+ |
| | * | | * | | * | |
| | View-Based | | Other | | Other | |
| | Access | | Access | | Access | |
| | Control | | Control | | Control | |
| | Model | | Model | | Model | |
| | | | | | | |
| +---------------+ +-----------------+ +------------------+ |
| |
+------------------------------------------------------------------+
圖4.12 訪問控制子系統
訪問控制模型定義一個特定的訪問決策函數，用以支持訪問權的認定決策。
4.5.5 SNMP應用
SNMP應用分爲以下幾種類型:
l 監測和操縱管理數據的命令產生者；
l 對管理數據提供訪問的命令接收者；
l 發出異步消息的通報產生者；
l 處理異步消息的通報接收者；
l 在實體之間轉發消息的代管轉發者。
SNMP應用與SNMP引擎之間形成應用與服務的關係，即SNMP應用是SNMP引擎的應用，SNMP引擎向SNMP應用提供服務。
SNMP Manager
包含一個或多個命令產生者和/或通報接收者應用的SNMP實體以往被稱爲SNMP管理者。如圖4.13所示
(traditional SNMP manager)
+-------------------------------------------------------------------+
| +--------------+ +--------------+ +--------------+ SNMP entity |
| | NOTIFICATION | | NOTIFICATION | | COMMAND | |
| | ORIGINATOR | | RECEIVER | | GENERATOR | |
| | applications | | applications | | applications | |
| +--------------+ +--------------+ +--------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------+--------+-----------------+ |
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | |
| | | | | +------------+ | | | Other | | |
| | | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->+ | | | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | Transport | | | +------------+ | | | Security | | |
| | Mapping | | | +------------+ | | | Model | | |
| | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +----------------+ |
| | |
| v |
+-------------------------------------------------------------------+
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+
^ ^ ^
| | |
v v v
+------------------------------+
| Network |
+------------------------------+
圖4.13 SNMP Manager
SNMP Agent
包含一個或多個命令接收者和/或通報產生者應用的SNMP實體，以往被稱爲SNMP代理者。如圖4.14所示。
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+ (traditional SNMP agent)
+-------------------------------------------------------------------+
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | Transport | | +->| v1MP * |<--->| +------------+ | |
| | Mapping | | | +------------+ | | | Other | | |
| | (e.g. RFC1906) | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->| +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | | | | +------------+ | | | Security | | |
| | PDU Dispatcher | | | +------------+ | | | Model | | |
| +-------------------+ | +->| otherMP * |<--->| +------------+ | |
| ^ | +------------+ | | | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | application | | | | applications | | application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
圖4.14 SNMP Agent
抽象服務接口
抽象服務接口被定義爲描述一個SNMP實體內各種子系統間的概念接口。抽象服務接口試圖幫助闡明SNMP實體的外部可觀察的行爲，但並不涉及或規範實現的結構或組織方法。特別要明確的是，它們不應被解釋爲API或對API的要求。
這些抽象服務接口由一組原語定義，而由原語定義提供的服務和服務被調用時被傳遞的抽象數據元素。