SNMPv2 管理信息結構
SNMPv2 的管理信息結構在總結 SNMP 應用經驗的基礎上對 SNMPv1 SMI 進行了擴充，提供了更精致更嚴格的規范，規定了新的管理對象和 MIB 的文檔，可以說是 SNMPv1 SMI 的超集。
對象的定義
與 SNMPv1 一樣，SNMPv2 也是用 ASN.1 宏定義 OBJECT-TYPE 表示管理對象的語法和語義的。SNMPv2 的 OBJECT-TYPE 增加了新的內容，與 SNMPv1 的宏定義有以下差別。
OBJECT-TYPE MACRO::= BEGIN
TYPE NOTATION::="SYNTAX" Syntax
UnitsPart
"MAX-ACCESS" Access
"STATUS"Status
"DESCRIPTION" Text
ReferPart
IndexPart
DefValPart
VALUE NOTATION::=value (VALUE ObjectName)
END
數據類型
SNMPv2 增加了 Unsigned32 和 Counter64 兩種新的數據類型，Counter64 與 Counter32一樣，都表示計數器，只能增加不能減少。當計數器增加到上限時回零，從頭再增加。SNMPv2 規定計數器沒有定義的初始值，所以只有連續兩次讀計數器得到的增加值才是有意義的。
Unsigned32 與 Gauge32 在 ASN.1 中是無區別的，都是 32 位的整數，但是在 SNMPv2 中語義不一樣。SNMPv2 中規定 Gauge32 的最大值可以設置為小於 2^32 的任意正數 MAX，相比於 SNMPv1 中 Gauge32 的最大值總是 2^32-1，SNMPv2 的規定更細致、方便了。SNMPv2 也明確了當計量器達到最大值時可自動減少，相比於原來的“鎖定在最大值”更為明確具體。
UnitsPart
在 SNMPv2 的 OBJECT-TYPE 宏定義中增加了 UNITS 子句，用文字說明與對象有關的度量單位。
MAX-ACCESS 子句
MAX-ACCESS 子句，說明最大的訪問級別。SNMPv2 定義的訪問類型中去掉了write-only 類，增加了一個與概念行有關的訪問類型 read-create，表示可讀、可寫、可生成。SNMPv2的5種訪問級別由小到大排列依次是：not-accessible、accessible-for-notify、read-only、 read-write、read-create。
STATUS 子句
STATUS 子句指明對象的狀態。新標准去掉了 SNMPvl 中的 optional 和
mandatory，只有 3 種可選的狀態。
| STATUS | 說明 |
|---|---|
| Current | 當前標准中有效 |
| Obsolete | 廢棄，不必實現此對象 |
| deprecated | 過時，但為了兼容應該實現此對象 |
表的定義
與 SNMPv1 一樣，SNMPv2 的管理操作只能作用於標量對象（葉子節點），復雜的信息要用表來表示，表是行的序列，行是列對象的序列。
- 禁止刪除和生成行的表，這種表的最高的訪問級別是 read-write。在很多情況下這種表由代理控制，表中只包含 read-only 型的對象。
- 允許刪除和生成行的表，這種表開始時可能沒有行，由管理站生成和刪除行。
在 SNMPv2 表的定義中必須含有 INDEX 或 AUGMENTS 子句，INDEX 子句定義了一個基本概念行。AUGMENTS 子句的作用是代替 INDEX 子句，表示概念行的擴展。
而 INDEX 子句中的索引對象確定了一個概念行實例，作為索引的列對象叫做輔助對象，是不可訪問的。例如有如下一張表，表中每行有惟一的一對 petType 和 petIndex 實例
假定我們要引用第 2 行第 4 列的對象實例，則實例標識符為：
petCharacteristic2.DOG.5
其中 “DOG” 是無修飾符 IMPLIED 的變長度字符串，編碼為 3.68.79.71（4個子標識符），因此實例標識符為：
A.1.4.3.68.79.71.5
表的操作
狀態列
允許生成和刪除行的表必須有一個列對象，這種列叫做概念行的狀態列。其 SYNTAX 子句的值為 RowStatus，MAX-ACCESS子句的值為 read-write，狀態列可取 6 種值.
| 狀態列 | 讀寫限制 | 說明 |
|---|---|---|
| active | 可讀寫 | 被管理設備可以使用概念行 |
| notInService | 可讀寫 | 概念行存在，但由於其他原因不能使用 |
| notReady | 只讀 | 概念行存在，但因沒有信息而不能使用 |
| createAndGo | 只寫不讀 | 管理站生成一個概念行實例時先設置成 createAndGo，生成過程結束時自動變為 active |
| createAndWait | 只寫不讀 | 管理站生成一個概念行實例時先設置成這種狀態，但不會自動變成 active |
| destroy | 只寫不讀 | 管理站需刪除所有的概念行實例時設置成這種狀態 |
這 6 種狀態中除 notReady 的 5 種狀態是管理站可以用 Set 操作設置的狀態，前 3 種可以是響應管理站的查詢而返回的狀態。
概念行的生成
概念行的生成需要經過如下 4 個步驟：
- 選擇索引對象的實例標識符；
- 管理站通過事務處理產生和激活概念行：管理站通過事務處理產生，與代理協商后生成；
- 初始化非默認值對象：Get 操作查詢所有列，根據返回值確定是否設置為列對象的值；
- 激活概念行：Set 操作設置狀態列對象為 active。
概念行的掛起
當概念行處於 active 狀態時，如果管理站希望概念行脫離服務，以便進行修改，則可以發出 Set 命令，把狀態列由 active 置為 notlnService。這時有兩種可能：
- 若代理不執行該操作，則返回 wrongValue；
- 若代理可執行該操作，則返回 noError。
概念行的刪除
管理站發出 Set 命令，把狀態列置為 destroy，如果這個操作成功，概念行立即被刪除。
通知和信息模塊
SNMPv2 提供了通知類型的宏定義 NOTIFICATION-TYPE，用於定義異常條件出現時 SNMPv2 實體發送的信息。
NOTIFICATION-TYPE MACRO::=BEGIN
TYPE NOTATION::=ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION::=value(VALUE NotificationName)
ObjectsPart::="OBJECTS""{"Objects"}"lempty
Objects::=Object|Object","Object
Object::=value(Name ObjectName)
Status::="current"|"deprecated"|"obsolete"
ReferPart::="REFERENCE” Textlempty
Text::="string""
END
任選的 OBJECT 子句定義了包含在通知實例中的 MIB 對象序列，當 SNMPv2 實體發送通知時這些對象的值被傳給管理站。DESCRIPTION 子句說明了通知的語義，任選的 REFERENCE 子句包含對其他 MIB 模塊的引用。
SNMPv2 還引入了信息模塊的概念，用於說明一組有關的定義。信息模塊共有以下 3 種：
| 信息模塊 | 說明 |
|---|---|
| MIB 模塊 | 包含一組有關的管理對象的定義 |
| MIB 的一致性聲明模塊 | 說明有關管理對象實現方面的最小要求 |
| 代理能力說明模塊 | 說明代理實體應該實現的能力 |
SNMPv2管理信息庫
SNMPv2 MIB 擴展和細化了 MIB-2 中定義的管理對象，又增加了新的管理對象。
| 功能組 | 變更 |
|---|---|
| 系統組 | 增加標題對象 sysORLastChange 和表對象 sysORTable |
| SNMP 組 | 由 MIB-2 對應的組改造而成 |
| MIB 對象組 | 與管理對象的控制有關，包含 2 個子組 |
| 接口組 | 糾正了原接口組存在的缺陷，增加 4 個新表 |
其中SNMP 組是由 MIB-2 的對應組改造而成的，去掉了許多對排錯作用不大的變量。
其中接口組增加了 4 張表，它們是接口擴展表、接口堆棧表、接口測試表、接口地址表。
| 表 | 說明 |
|---|---|
| 接口擴展表 | 根據接口名存儲一些參數 |
| 接口堆棧表 | 說明接口表中屬於同一物理接口的各個行之間的關系 |
| 接口測試表 | 由管理站指示代理系統測試接口的故障 |
| 接收地址表 | 包含每個接口對應的各種地址(廣播地址、組播地址和單地址) |
SNMPv2 協議數據單元
訪問管理信息
SNMPv2 提供了 3 種訪問管理信息的方法，分別是：
- 管理站和代理之間的請求/響應通信：同 SNMPv1
- 管理站和管理站之間的請求/響應通信：SNMPv2 特有（分布式）
- 代理到管理站的非確認通信（Trap）：同 SNMPv1
SNMPv2 報文
SNMPv2 PDU 封裝在報文中傳送，報文頭提供了簡單的認證功能，而 PDU 可以完成上面提到的各種操作。SNMPv2 報文的結構分為 3 部分：版本號、團體名和作為數據傳送的 PDU。這個格式與 SNMPv1 一樣。
SNMPv2 實體發送和接受報文需要做的動作和 SNMPv1 的一樣，不再贅述。
SNMPv2 PDU
SNMPv2 共有 6 種協議數據單元，分為 3 種 PDU 格式。GetRequest、GetNextRequest、SetRequest、InformRequest 和 Trap 等 5 種 PDU 的格式如下。
上述 5 種 PDU 與 Response PDU 具有相同的格式，Response PDU 的格式如下，只是它們的錯誤狀態和錯誤索引字段被置為 0。
這些協議數據單元在管理站和代理系統之間或者是兩個管理站之間交換，以完成需要的協議操作。
GetRequest PDU 和 GetNextRequest PDU
SNMPv2 對 GetRequest PDU、GetNextRequest PDU 操作的響應方式與 SNMPv1 不同，SNMPv1 的響應是原子性的，即只要有一個變量的值檢索不到就不返回任何值。而 SNMPv2 的響應不是原子性的，允許部分響應。
GetBulkRequest PDU
GetBulkRequest PDU 是 SNMPv2 對原標准的主要增強，目的是以最少的交換次數檢索大量的管理信息。對這個操作的響應，在選擇 MIB 變量值時采用與 GetNextRequest 同樣的原理，即按照詞典順序選擇后繼對象實例，但是這個操作可以說明多種不同的后繼。
假設 GetBulkRequestPDU 變量綁定表中有 L 個變量，該 PDU 的“非重復數”字段的值為 N，則對前 N 個變量應各返回一個詞典后繼。再設請求 PDU 的“最大后繼數”字段的值為 M，則對其余的 R = L - N 個變量應該各返回最多 M 個詞典后繼。如果可能，總共返回 N + R x M 個值。如果在任何一步查找過程中遇到不存在后繼的情況，則返回錯誤值 endOfMibView。
例如有如下樣例表：
| ifIndex | ipNetToMediaNetAddress | ipNetToMediaPhysAddress | ipNetToMediaType |
|---|---|---|---|
| 1 | 9.2.3.4 | 00 00 10 54 32 10 | dynamic |
| 1 | 10.0.0.51 | 00 00 10 01 23 45 | static |
| 2 | 10.0.0.15 | 00 00 10 98 76 54 | dynamic |
現管理站要檢索這個表的值和一個標量對象 sysUpTime 的值，可以發出請求：
GetBulkRequest[非重復數 = 1，最大后繼數 = 2]
{sysUpTime，ipNetToMediaPhysAddress，ipNetToMediaType}
非重復數為 1，表示對變量列表中前 1 個變量查詢一次，也就是對 sysUpTime 查詢一次。ipNetToMediaPhysAddress，ipNetToMediaType 2 個變量需要重復查詢，重復查詢的次數為最大后繼樹 2。綜上所述，代理的響應是：
Response((sysUpTime.0 = "123456"),
(ipNetToMediaPhysAddress.1.9.2.3.4 = "00 00 10 54 32 10"),
(ipNetToMediaType.1.9.2.3.4 = "dynamic"),
(ipNetToMediaPhysAddress.1.10.0.0.51 = "00 00 10 01 23 45"),
(ipNetToMediaType.1.10.0.0.51 = "static"))
管理站又發出下一個請求：
GetBulkRequest[非重復數 = 1，最大后繼數 = 2]
{sysUpTime，
ipNetToMediaPhysAddress.1.10.0.0.51，
ipNetToMediaType.1.10.0.0.51}
由於這個查詢重復第 2 次時表已經讀取完畢，會讀取到表外的數據，因此代理的響應是：
Response((sysUpTime.0 = "123466"),
(ipNetToMediaPhysAddress.2.10.0.0.15 = "00 00 10 98 76 54"),
(ipNetToMediaType.2.10.0.0.15 = "dynamic"),
(ipNetToMediaType.1.9.2.3.4 = "dynamic"),
(ipRoutingDiscards.0 = "2"))
SetRequest PDU
SetRequest PDU 請求的格式和語義與 SNMPv1 的基本相同，SNMPv2 實體分兩個階段處理這個請求的變量綁定表。首先是檢驗操作的合法性，然后再更新變量，如果至少有一個變量綁定對的合法性檢驗沒有通過，則不進行下一階段的更新操作。所以這個操作與 SNMPv1 一樣，是原子性的。
Trap PDU
Trap PDU 是由代理發給管理站的非確認性消息，SNMPv2 的陷入采用與 Get 等操作相同的 PDU 格式。
InformRequest PDU
InformRequest PDU 是管理站發送給管理站的消息，其 PDU 格式與Get等操作相同，變量綁定表的內容與陷入報文的一樣。但是這個消息是需要應答的，所以管理站收到通知請求后首先要決定
應答報文的大小，如果應答報文大小超過本地或對方的限制，則返回錯誤狀態 tooBig。如果接收的請求報文不是太大，則把有關信息傳送給本地的應用實體，返回一個錯誤狀態為 noErr 的響應報文，其變量綁定表與收到的請求 PDU 相同。
管理站之間的通信
SNMPv2 增加的管理站之間的通信機制是分布式網絡管理所需要的功能特征，為此引入了通知報文InformRequest 和管理站數據庫(manager-to-manager MIB)。管理站數據庫主要由 3 個表組成，由這 3 個表以及其他有關標量對象共同組成了 snmpM2M 模塊，表示了管理站之間交換的主要信息。
| 表 | 說明 |
|---|---|
| snmpAlarmTable(報警表) | 提供被監視的變量的有關情況 |
| snmpEventTable(事件表) | 記錄 SNMPv2 實體產生的重要事件 |
| snmpEventNotifyTable(事件通知表) | 定義了發送通知的目標和通知的類型 |
參考資料
《計算機網絡管理(第三版)》雷震甲 編著，西安電子科技大學出版社