SNMP協議入門
1、引言
基於TCP/IP的網絡管理包含3個組成部分：
1) 一個管理信息庫MIB（Management Information Base）。管理信息庫包含所有代理進程的所有可被查詢和修改的參數。RFC1213[McCloghrie and Rose 1991]定義了第二版的MIB，叫做MIB-II。
2) 關於MIB的一套公用的結構和表示符號。叫做管理信息結構SMI（Structure of Management Information）。這個在RFC 1155 [Rose and McCloghrie 1990] 中定義。例如：SMI定義計數器是一個非負整數，它的計數範圍是 0~4294967295，當達到最大值時，又從0開始計數。
3) 管理進程和代理進程之間的通信協議，叫做簡單網絡管理協議SNMP（Simple Network Management Protocol）。在RFC 1157 [Case et al. 1990]中定義。SNMP包括數據報交換的格式等。儘管可以在傳輸層採用各種各樣的協議，但是在SNMP中，用得最多的協議還是UDP。
2、SNMP協議概述
簡單網絡管理協議（SNMP：Simple Network Management Protocol）是由互聯網工程任務組（IETF：Internet Engineering Task Force ）定義的一套網絡管理協議。該協議基於簡單網關監視協議（SGMP：Simple Gateway Monitor Protocol）。利用SNMP，一個管理工作站可以遠程管理所有支持這種協議的網絡設備，包括監視網絡狀態、修改網絡設備配置、接收網絡事件警告等。雖然SNMP開始是面向基於IP的網絡管理，但作爲一個工業標準也被成功用於電話網絡管理。
3、SNMP的發展史
SNMP經過了一個相對較長的發展過程，到目前爲止一共經歷了三個版本。當下使用最廣泛是SNMPv2。
l 1989年發佈了第一個版本的SNMP，稱爲SNMPv1。
l 1991年發佈SNMP的一個補充---RMON(Remote Network Monitoring，遠程網絡監視)。RMON擴充了SNMP的功能，包括對LAN的管理以及對依附於這些網絡設備的管理。注：RMON沒有修改和增加SNMP協議本身以及SMI，只是增加了SNMP監視子網的能力，把整個子網當成一個個體來監視，提供了新的MIB庫及相關的MIB行爲。
l 1993年SNMPv1的升級版被提出，SNMPv2。
l 1995年SNMPv2正式發佈，v2增加了SNMPv1的功能，並規定了如何在基於OSI的網絡中使用SNMP。同時RMON於本年度擴展爲RMONv2
l 1998年SNMPv3發佈，一系列文檔定義了SNMP的安全性，並定義了將來改進的總體結構。SNMPv3可以和v2、v1一起使用。
4、SNMP的工作原理
SNMP採用特殊的客戶機/服務器模式，即代理/管理站模型。對網絡的管理與維護是通過管理工作站與SNMP代理間的交互工作完成的。每個SNMP從代理負責回答SNMP管理工作站（主代理）關於MIB定義信息的各種查詢。
SNMP的應用場景如圖１所示：
管理站和代理端使用MIB進行接口統一，MIB定義了設備中的被管理對象。管理站和代理都實現相應的MIB對象，使得雙方可以識別對方的數據，實現通信。管理站向代理請求MIB中定義的數據，代理端識別後，將管理設備提供的相關狀態或參數等數據轉換成MIB定義的格式，最後將該信息返回給管理站，完成一次管理操作。
5、SNMP的報文類型
SNMP中定義了五種消息類型：Get-Request、Get-Response、Get-Next-Request、Set-Request和Trap。
(1)Get-Request 、Get-Next-Request與Get-Response
SNMP 管理站用Get-Request消息從擁有SNMP代理的網絡設備中檢索信息，而SNMP代理則用Get-Response消息響應。Get-Next- Request用於和Get-Request組合起來查詢特定的表對象中的列元素。
(2)Set-Request SNMP管理站用Set-Request 可以對網絡設備進行遠程配置（包括設備名、設備屬性、刪除設備或使某一個設備屬性有效/無效等）。
(3)Trap SNMP代理使用Trap向SNMP管理站發送非請求消息，一般用於描述某一事件的發生，如接口UP/DOWN，IP地址更改等。
上面五種消息中Get-Request、Get-Next-Request和Set-Request是由管理站發送到代理側的161端口的；後面兩種Get-Response和Trap 是由代理進程發給管理進程的，其中Trap消息被髮送到管理進程的162端口，所有數據都是走UDP封裝。
SNMP工作流程如圖2：
6、SNMP的報文格式
SNMP代理和管理站通過SNMP協議中的標準消息進行通信，每個消息都是一個單獨的數據報。SNMP使用UDP（用戶數據報協議）作爲第四層協議（傳輸協議），進行無連接操作。SNMP消息報文包含兩個部分：SNMP報頭和協議數據單元PDU。
在實際網絡傳輸環境下，SNMP報文的長度取決於其所採用的編碼方式。SNMP統一採用BER(Basic Encoding Rule)的編碼規則，同時在正式SNMP規範中使用的是ASN.1語法，Abastract Syntax Notation v1，即抽象語法描述語言。這兩個概念在後面實踐環節再做進一步介紹，這裏只要稍微瞭解一下即可，不妨礙我們對協議本身的分析。這裏我們簡單解釋一下BER編碼規則：
BER作爲ANS.1的基本編碼規則，描述具體的ANS.1對象如何編碼爲比特流在網絡上進行傳輸。BER編碼規則由三部分組成：
SNMP中定義了幾種基本的數據類型，其中v1和v2版有些改動，具體參見相應的RFC文檔。這裏我們只介紹幾種最常見的類型：
l INTEGER：一個整數
l OCTER STRING： 0或多個8bit字節，每個字節在0~255之間取值
l DisplayString：0或多個8bit字節，每個字節必須是ASCII碼。在MIB-II中，所有該類型變量不能超過255個字符(0個字符可以)
l NULL：代表相關的變量沒有值
l IpAddress：4字節長的OCTER STRING，以網絡字節序表示IP地址
l PhyAddress：6字節長的OCTER STRING，代表物理地址
l Counter：非負整數，可以從0遞增到232-1()。達到最大值後歸0
l TimeTicks：時間計數器，以0.01秒爲單位遞增，不同的變量可以有不同的遞增幅度。所以在定義這種類型的變量時需要制定遞增幅度
l SEQUENCE：與C語言中的結構體類似
l SEQUENCE OF：一個向量，參見後面ANS.1語法詳細介紹章節
SNMP報文在傳輸層是封裝在UDP報文中的，而UDP又是基於IP網絡的，因此，我們可以得到完整的報文描述結構，如下圖所示：
PDU類型其實包含兩個字節，第一個字節表示真實的PDU的類型；第二個字節表示後面報文所佔的字節總數。針對SNMPv1，這個字段取值如下：
表1 PDU類型
PDU類型 | 名稱 |
0 | get-request |
1 | get-next-request |
2 | get-response |
3 | set-request |
4 | trap |
也就是說，trap的類型是4。但是在數據報文中，該字段一般表示爲ax，其中x取[0,4]，即a0~a3表示相應的get、set等操作，a4表示trap報文。這裏除了類型字段意外，其他字段均採用BER編碼方式：
實戰演練之報文格式分析
Trap報文格式和上述圖5所展示的結構有些差別，這裏我們只分析SNMPv1和SNMPv2的Trap報文格式。trap報文前面的部分都一樣，區別在PDU協議數據單元部分。
SNMPv1 Trap報文
SNMPv1的Trap報文格式如下所示：
注意：除了PDU類型和PDU長度字段外，後面的每個字段都是BER編碼方式。
trap類型”可以取以下值，其中0~6是已定義的特定trap，7及其以後的類型由供應商自定義
表2 trap類型、名稱及描述信息
trap類型 | 名稱 | 描述信息 |
0 | coldStart | 代理進程對自己初始化 |
1 | warmStart | 代理進程對自己重新初始化 |
2 | linkDown | 一個接口已從工作狀態變爲故障狀態(報文中的第一個變量標識此接口) |
3 | linkUp | 一個接口已從故障狀態變爲工作狀態(報文中的第一個變量標識此接口) |
4 | authenticationFailure | 從SNMP管理進程收到無效共同體的報文 |
5 | egpNeighborLoss | 一個EGP鄰站已變爲故障狀態(報文中的第一個變量包含鄰站IP地址) |
6 | enterpriseSpecific | 在這個特定的代碼段中查找trap信息 |
通過wireshark抓包工具，捕獲一條如下的SNMP報文，接下來對其進行仔細分析。
SNMPv1原始報文內容：
00 23 5a 9e 58 b9 00 4c41 49 50 55 08 0045 00 00 48 00 00 40 00 40 11 a54e c0 a8 0a 01 c0 a8 0a 05 0c 00 00 a2 00 34 ff e0 30 2a 02 01 00 04 06 70 75 62 6c 69 63 a4 1d 06 0a 2b 06 01 04 01 bf 08 03 02 0a 40 04 c0 a8 0a 01 02 01 00 02 01 00 4301 0e 30 00
目的MAC：00 23 5a 9e 58 b9
源MAC：00 4c 41 49 50 55
協議類型：08 00，爲IP數據報
IP頭：45 00 00 48 00 00 40 00 40 11 a5 4e c0a8 0a 01 c0 a8 0a 05 0c
UDP頭：0c 00 00 a2 00 34 ff e0
其餘部分都爲SNMP報文，接下來我們對照前面的報文結構體來逐個分析一下。
n 30 表示SNMP消息是ASN.1的SEQUENCE類型；
n 2a 表示該SNMP報文的總長度是42(0x2a)個字節，該字段所表示的報文長度起始於它後面的第一個字節直到報文結束；
n 02 01 00 表示版本號，可見其確實爲BER編碼方式。02表示該字段是INTEGER類型；01表示該字段佔1個字節；00表示版本號，該值爲“版本號-1”；
n 04 06 70 75 62 6c 69 63表示團體名，04表示該字段爲OCTET STRING類型；06表示該字段佔6個字節；70 75 62 6c 69 63 表示團體名的ANSII碼的十六進制形式，這裏是“public”；
n a4 1d 其中a4中的“4”表示這是一個trap報文，a4又叫報文的標籤標記；1d表示後面還有29(0x1d)個字節的數據；
n 06 0a 2b 06 01 04 01 bf 08 03 02 0a企業OID標識。06表示該字段是個對象標識符，OBJECT IDENTIFIER；0a表示該字段佔10(0x0a)個字節；關於SNMP的OID的編碼方式有些奇特：例如1.3.6.1.2…. 取前兩個數字分別記爲x和y。編碼時40*x+y，這裏x=1，y=3，因此結果爲40*1+3=43，即表示十六進制的2b。因此，這裏的企業OID編碼即爲1.3.6.1.4.1.8072.3.2.10；
n 40 04 c0 a8 0a 01 同樣40表示該字段爲OCTET STRING 類型；04表示IP地址佔4個字節；IP地址爲192.168.10.1；
n 02 01 00 其中00表示trap類型爲coldStart；
n 02 01 00 其中00表示我們指定的trap即specific-trap也爲coldStart類型；
n 43 01 0e 43表示爲TimeTicks類型；01表示該字段佔1個字節；0e即十進制的14表示時間標籤爲0.14秒，這裏時間計數器以0.01秒遞增；
n 30 00 30表示“鍵-值”值對的編碼類型爲SEQUENCE；00表示該字段佔0個字節，即沒有該字段。
SNMPv2的Trap報文格式如圖8所示：
同樣的，這裏除了trap類型和報文長度是標準網絡字節序之外，其餘協議字段也均爲BER編碼方式。可以看到v2版的trap報文正在向統一的報文格式發展，已經非常類似普通的SNMP請求、響應報文了。
SNMPv2原始報文內容：
00 23 5a 9e 58 b9 00 4c41 49 50 55 08 00 45 0000 7b 00 00 40 00 40 11 a5 1b c0 a8 0a 01 c0 a8 0a 05 0c 01 00 a2 00 67 04 bb 30 5d 02 0101 04 06 70 75 62 6c 69 63 a7 50 02 04 17 73 2c fb 02 01 00 02 01 00 3042 30 0d 06 08 2b 06 01 02 01 01 03 00 43 01 0e 30 17 06 0a2b 06 01 06 03 01 01 04 0100 06 09 2b 06 01 06 03 01 01 05 01 30 18 06 0a 2b 06 01 06 03 01 01 04 03 0006 0a 2b 06 01 04 01 bf 08 03 02 0a
目的MAC：00 23 5a 9e 58 b9
源MAC：00 4c 41 49 50 55
協議類型：08 00，IP報文
IP頭：45 00 00 7b 00 00 40 00 40 11 a5 1b c0a8 0a 01 c0 a8 0a 05
UDP頭：0c 01 00 a2 00 67 04 bb
餘下部分全爲SNMP報文內容，這裏我們做一下簡單的約定：
xx標註類型；xx標註長度；xx標註真正的數據。
這樣一來上面這串原始數據就好分析多了J
n 30 5d 整個SNMP報文的編碼方式爲30，即SEQUENCE類型，報文長度93(0x5d)字節；
n 02 01 01 版本號01即v2版本；
n 04 06 70 75 62 6c 69 63 團體名70 75 62 6c 69 63 即英文的“public”；
n a7 50 a7表示trap類型爲7，即廠商自定義trap；50表示PDU區段佔80(0x50)字節；
n 02 04 17 73 2c fb 請求ID爲17 73 2c fb十進制的393424123；
n 02 01 00 錯誤狀態0；
n 02 01 00 錯誤索引0；
n 30 42 “變量名-值”對編碼類型30即SEQUENCE類型；“變量名-值”所佔總字節0x42，即66字節；
n 30 0d 06 08 2b 06 01 02 01 01 03 00 43 01 0e 第一個“名-值”對區段編碼方式30即SEQUENCE類型；第一個“名-值”對總長度0x0d，13字節；第一個變量名的編碼類型0x06，時間標籤；第一個變量名佔0x08個字節；第一個變量名2b 06 01 02 01 01 0300，爲1.3.6.1.2.1.1.3.0；第一個變量值爲0x0e，即14；
n 30 17 06 0a 2b 06 01 06 03 01 01 04 01 0006 09 2b 06 01 06 03 01 01 05 01 第二個“名-值”對；變量名1.3.6.1.6.3.1.1.4.1.0；變量值1.3.6.1.6.3.1.1.5.1；
n 30 18 06 0a 2b 06 01 06 03 01 01 04 03 0006 0a 2b 06 01 04 01 bf 08 03 02 0a第三個“名-值”對；變量名1.3.6.1.6.3.1.1.4.3.0；變量值1.3.6.1.4.1.8072.3.2.10；