25.1 引言
隨著網(wǎng)絡(luò)技術(shù)的飛速發(fā)展，網(wǎng)絡(luò)的數(shù)量也越來(lái)越多。而網(wǎng)絡(luò)中的設(shè)備來(lái)自各個(gè)不同的廠家，如何管理這些設(shè)備就變得十分重要。本章的內(nèi)容就是介紹管理這些設(shè)備的標(biāo)準(zhǔn)。
基于TCP/IP的網(wǎng)絡(luò)管理包含兩個(gè)部分：網(wǎng)絡(luò)管理站（也叫管理進(jìn)程，manager）和被管的網(wǎng)絡(luò)單元（也叫被管設(shè)備）。被管設(shè)備種類繁多，例如：路由器、X終端、終端服務(wù)器和打印機(jī)等。這些被管設(shè)備的共同點(diǎn)就是都運(yùn)行TCP/IP協(xié)議。被管設(shè)備端和管理相關(guān)的軟件叫做代理程序(agent)或代理進(jìn)程。管理站一般都是帶有彩色監(jiān)視器的工作站，可以顯示所有被管設(shè)備的狀態(tài)(例如連接是否掉線、各種連接上的流量狀況等)。
管理進(jìn)程和代理進(jìn)程之間的通信可以有兩種方式。一種是管理進(jìn)程向代理進(jìn)程發(fā)出請(qǐng)求，詢問(wèn)一個(gè)具體的參數(shù)值（例如：你產(chǎn)生了多少個(gè)不可達(dá)的ICMP端口？）。另外一種方式是代理進(jìn)程主動(dòng)向管理進(jìn)程報(bào)告有某些重要的事件發(fā)生（例如：一個(gè)連接口掉線了）。當(dāng)然，管理進(jìn)程除了可以向代理進(jìn)程詢問(wèn)某些參數(shù)值以外，它還可以按要求改變代理進(jìn)程的參數(shù)值（例如：把默認(rèn)的IP TTL值改為64）。
基于TCP/IP的網(wǎng)絡(luò)管理包含3個(gè)組成部分：
1：一個(gè)管理信息庫(kù)MIB（Management Information Base）。管理信息庫(kù)包含所有代理進(jìn)程的所有可被查詢和修改的參數(shù)。RFC 1213 [McCloghrie and Rose 1991]定義了第二版的MIB，叫做MIB-II。
2：關(guān)于MIB的一套公用的結(jié)構(gòu)和表示符號(hào)。叫做管理信息結(jié)構(gòu)SMI（Structure of Management Information）。這個(gè)在RFC 1155 [Rose and McCloghrie 1990]中定義。例如：SMI定義計(jì)數(shù)器是一個(gè)非負(fù)整數(shù)，它的計(jì)數(shù)范圍是0~4294 967 295，當(dāng)達(dá)到最大值時(shí)，又從0開(kāi)始計(jì)數(shù)。
3：管理進(jìn)程和代理進(jìn)程之間的通信協(xié)議，叫做簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議SNMP（Simple Network Management Protocol）。在RFC 1157 [Case et al.1990]中定義。SNMP包括數(shù)據(jù)報(bào)交換的格式等。盡管可以在運(yùn)輸層采用各種各樣的協(xié)議，但是在SNMP中，用得最多的協(xié)議還是UDP。
上面提到的RFC所定義的SNMP叫做SNMP v1，或者就叫做SNMP，這也是本章的主要內(nèi)容。到1993年為止，又有一些新的關(guān)于SNMP的RFC發(fā)表。在這些RFC中定義的SNMP叫做第二版SNMP（SNMP v2），這將在25.12章節(jié)中討論。
本章首先介紹管理進(jìn)程和代理進(jìn)程之間的協(xié)議，然后討論參數(shù)的數(shù)據(jù)類型。在本章中將用到前面已經(jīng)出現(xiàn)過(guò)的名詞，如：IP、UDP和TCP等。我們?cè)跀⑹鲋袑⑴e一些例子來(lái)幫助讀者理解，這些例子和前面的某些章節(jié)相關(guān)。
25.2 協(xié)議
關(guān)于管理進(jìn)程和代理進(jìn)程之間的交互信息，SNMP定義了5種報(bào)文：
1：get-request操作：從代理進(jìn)程處提取一個(gè)或多個(gè)參數(shù)值。
2：get-next-request操作：從代理進(jìn)程處提取一個(gè)或多個(gè)參數(shù)的下一個(gè)參數(shù)值（關(guān)于“下一個(gè)（next）”的含義將在后面的章節(jié)中介紹）。
3：set-request操作：設(shè)置代理進(jìn)程的一個(gè)或多個(gè)參數(shù)值。
4：get-response操作：返回的一個(gè)或多個(gè)參數(shù)值。這個(gè)操作是由代理進(jìn)程發(fā)出的。它是前面3中操作的響應(yīng)操作。
5：trap操作：代理進(jìn)程主動(dòng)發(fā)出的報(bào)文，通知管理進(jìn)程有某些事情發(fā)生。
前面的3個(gè)操作是由管理進(jìn)程向代理進(jìn)程發(fā)出的。后面兩個(gè)是代理進(jìn)程發(fā)給管理進(jìn)程的（為簡(jiǎn)化起見(jiàn)，前面3個(gè)操作今后叫做get、get-next和set操作）。圖25-1描述了這5種操作。
既然這些操作中的前4種操作是簡(jiǎn)單的請(qǐng)求-應(yīng)答方式（也就是管理進(jìn)程發(fā)出請(qǐng)求，代理進(jìn)程應(yīng)答響應(yīng)），而且在SNMP中往往使用UDP協(xié)議，所以可能發(fā)生管理進(jìn)程和代理進(jìn)程之間數(shù)據(jù)報(bào)丟失的情況。因此一定要有超時(shí)和重傳機(jī)制。
管理進(jìn)程發(fā)出的前面3種操作采用UDP的161端口。代理進(jìn)程發(fā)出的Tr ap操作采用UDP的162端口。由于收發(fā)采用了不同的端口號(hào)，所以一個(gè)系統(tǒng)可以同時(shí)為管理進(jìn)程和代理進(jìn)程（參見(jiàn)習(xí)題25.1）。
圖25-2是封裝成UDP數(shù)據(jù)報(bào)的5種操作的SNMP報(bào)文格式。
在圖中，我們僅僅對(duì)IP和UDP的首部長(zhǎng)度進(jìn)行了標(biāo)注。這是由于：SNMP報(bào)文的編碼采用了ASN.1和BER，這就使得報(bào)文的長(zhǎng)度取決于變量的類型和值。關(guān)于ASN.1和BER的內(nèi)容將在后面介紹。在這里介紹各個(gè)字段的內(nèi)容和作用。
版本字段是0。該字段的值是通過(guò)SNMP版本號(hào)減去1得到的。顯然0代表SNMP v1。
圖25-3顯示各種PDU對(duì)應(yīng)的值（PDU即協(xié)議數(shù)據(jù)單元，也就是分組）。
共同體字段是一個(gè)字符串。這是管理進(jìn)程和代理進(jìn)程之間的口令，是明文格式。默認(rèn)的值是public。
對(duì)于get、get-next和set操作，請(qǐng)求標(biāo)識(shí)由管理進(jìn)程設(shè)置，然后由代理進(jìn)程在getresponse中返回。這種類型的字段我們?cè)谄渌鸘DP應(yīng)用中曾經(jīng)見(jiàn)過(guò)（回憶一下在圖14-3中DNS的標(biāo)識(shí)字段，或者是圖16-2中的事務(wù)標(biāo)識(shí)字段）。這個(gè)字段的作用是使客戶進(jìn)程（在目前情況下是管理進(jìn)程）能夠?qū)⒎?wù)器進(jìn)程（即代理進(jìn)程）發(fā)出的響應(yīng)和客戶進(jìn)程發(fā)出的查詢進(jìn)行匹配。這個(gè)字段允許管理進(jìn)程對(duì)一個(gè)或多個(gè)代理進(jìn)程發(fā)出多個(gè)請(qǐng)求，并且從返回的眾多應(yīng)答中進(jìn)行分類。
差錯(cuò)狀態(tài)字段是一個(gè)整數(shù)，它是由代理進(jìn)程標(biāo)注的，PDU類型名稱指明有差錯(cuò)發(fā)生。圖25-4是參數(shù)值、名稱和描述之間的對(duì)應(yīng)關(guān)系。
差錯(cuò)索引字段是一個(gè)整數(shù)偏移量，指明當(dāng)有差錯(cuò)發(fā)生時(shí)，差錯(cuò)發(fā)生在哪個(gè)參數(shù)。它是由代理進(jìn)程標(biāo)注的，并且只有在發(fā)生noSuchName、readOnly和badValue差錯(cuò)時(shí)才進(jìn)行標(biāo)注。
在get、get-next和set的請(qǐng)求數(shù)據(jù)報(bào)中，包含變量名稱和變量值的一張表。對(duì)于get和get-next操作，變量值部分被忽略，也就是不需要填寫。
對(duì)于trap操作符（PDU類型是4），SNMP報(bào)文格式有所變化。我們將在25.10節(jié)中當(dāng)討論到trap時(shí)再詳細(xì)討論。
25.3 管理信息結(jié)構(gòu)
SNMP中，數(shù)據(jù)類型并不多。在本節(jié)，我們就討論這些數(shù)據(jù)類型，而不關(guān)心這些數(shù)據(jù)類型在實(shí)際中是如何編碼的。
1：INTEGER。一個(gè)變量雖然定義為整型，但也有多種形式。有些整型變量沒(méi)有范圍限制，有些整型變量定義為特定的數(shù)值（例如，IP的轉(zhuǎn)發(fā)標(biāo)志就只有允許轉(zhuǎn)發(fā)時(shí)的1或者不允許轉(zhuǎn)發(fā)時(shí)的2這兩種），有些整型變量定義為一個(gè)特定的范圍（例如，UDP和TCP的端口號(hào)就從0到65535）。
2：OCTERSTRING。0或多個(gè)8bit字節(jié)，每個(gè)字節(jié)值在0~255之間。對(duì)于這種數(shù)據(jù)類型和下一種數(shù)據(jù)類型的BER編碼，字符串的字節(jié)個(gè)數(shù)要超過(guò)字符串本身的長(zhǎng)度。這些字符串不是以NULL結(jié)尾的字符串。
3：DisplayString。0或多個(gè)8bit字節(jié)，但是每個(gè)字節(jié)必須是ASCII碼（26.4中有ASCII字符集）。在MIB-II中，所有該類型的變量不能超過(guò)255個(gè)字符（0個(gè)字符是可以的）。
4：OBJECTIDENTIFIER 。將在下一節(jié)中介紹。
5：NULL。代表相關(guān)的變量沒(méi)有值。例如，在get或get-next操作中，變量的值就是NULL，因?yàn)檫@些值還有待到代理進(jìn)程處去取。
6：IpAddress。4字節(jié)長(zhǎng)度的OCTER STRING，以網(wǎng)絡(luò)序表示的IP地址。每個(gè)字節(jié)代表IP地址的一個(gè)字段。
7：PhysAddress。OCTER STRING類型，代表物理地址（例如以太網(wǎng)物理地址為6個(gè)字節(jié)長(zhǎng)度）。
8：Counter。非負(fù)的整數(shù)，可從0遞增到232-1（4294 976 295）。達(dá)到最大值后歸0。
9：Gauge。非負(fù)的整數(shù)，取值范圍為從0到4294 976 295(或增或減)。達(dá)到最大值后鎖定,直到復(fù)位。例如，MIB中的tcpCurrEstab就是這種類型的變量的一個(gè)例子，它代表目前在ESTA BLISHED或CLOSE_WA IT狀態(tài)的TCP連接數(shù)。
10：TimeTicks。時(shí)間計(jì)數(shù)器,以0.01秒為單位遞增，但是不同的變量可以有不同的遞增幅度。所以在定義這種類型的變量的時(shí)候，必須指定遞增幅度。例如，MIB中的sysUpTime變量就是這種類型的變量，代表代理進(jìn)程從啟動(dòng)開(kāi)始的時(shí)間長(zhǎng)度，以多少個(gè)百分之一秒的數(shù)目來(lái)表示。
11：SEQUENCE。這一數(shù)據(jù)類型與C程序設(shè)計(jì)語(yǔ)言中的“structure”類似。一個(gè)SEQUENCE包括0個(gè)或多個(gè)元素，每一個(gè)元素又是另一個(gè)ASN.1數(shù)據(jù)類型。例如，MIB中的UdpEntry就是這種類型的變量。它代表在代理進(jìn)程側(cè)目前“激活”的UDP數(shù)量（“激活”表示目前被應(yīng)用程序所用）。在這個(gè)變量中包含兩個(gè)元素：
1）IpAddress類型中的udpLocalAddress，表示IP地址。
2）INTEGER類型中的udpLocalPort，從0到65535，表示端口號(hào)。
12：SEQUENDEOF。這是一個(gè)向量的定義，其所有元素具有相同的類型。如果每一個(gè)元素都具有簡(jiǎn)單的數(shù)據(jù)類型，例如是整數(shù)類型，那么我們就得到一個(gè)簡(jiǎn)單的向量（一個(gè)一維向量）。但是我們將看到，SNMP在使用這個(gè)數(shù)據(jù)類型時(shí)，其向量中的每一個(gè)元素是一個(gè)SEQUENCE（結(jié)構(gòu)）。因而可以將它看成為一個(gè)二維數(shù)組或表。
例如，名為udpTable的UDP監(jiān)聽(tīng)表(listener)就是這種類型的變量。它是一個(gè)二元的SEQUENCE變量。每個(gè)二元組就是一個(gè)UdpEntry。如圖25-5所示。
在SNMP中，對(duì)于這種類型的表格并沒(méi)有標(biāo)注它的列數(shù)。但在25.7節(jié)中，我們將看到get-next操作是如何判斷已經(jīng)操作到最后一列的情況。同時(shí)，在25.6節(jié)中，我們還將介紹管理進(jìn)程如何表示它對(duì)某一行數(shù)據(jù)進(jìn)行g(shù)et或set操作。
25.4 對(duì)象標(biāo)識(shí)符
對(duì)象標(biāo)識(shí)是一種數(shù)據(jù)類型，它指明一種“授權(quán)”命名的對(duì)象。“授權(quán)”的意思就是這些標(biāo)識(shí)不是隨便分配的，它是由一些權(quán)威機(jī)構(gòu)進(jìn)行管理和分配的。
對(duì)象標(biāo)識(shí)是一個(gè)整數(shù)序列，以點(diǎn)（“.”）分隔。這些整數(shù)構(gòu)成一個(gè)樹型結(jié)構(gòu)，類似于DNS（圖14-1）或Unix的文件系統(tǒng)。對(duì)象標(biāo)識(shí)從樹的頂部開(kāi)始，頂部沒(méi)有標(biāo)識(shí)，以root表示（這和Unix中文件系統(tǒng)的樹遍歷方向非常類似）。
圖25-6顯示了在SNMP中用到的這種樹型結(jié)構(gòu)。所有的MIB變量都從1.3.6.1.2.1這個(gè)標(biāo)識(shí)開(kāi)始。
樹上的每個(gè)結(jié)點(diǎn)同時(shí)還有一個(gè)文字名。例如標(biāo)識(shí)1.3.6.1.2.1和iso.org.dod.internet.memt.mib對(duì)應(yīng)。這主要是為了人們閱讀方便。在實(shí)際應(yīng)用中，也就是說(shuō)在管理進(jìn)程和代理進(jìn)程進(jìn)行數(shù)據(jù)報(bào)交互時(shí)，MIB變量名是以對(duì)象標(biāo)識(shí)來(lái)標(biāo)識(shí)的，當(dāng)然都是以1.3.6.1.2.1開(kāi)頭的。
在圖25-6中，我們除了給出了mib對(duì)象標(biāo)識(shí)外，還給出了iso.org.dod.internet.private.enterprises（1.3.6.1.4.1）這個(gè)標(biāo)識(shí)。這是給廠家自定義而預(yù)留的。在AssignedNumber RFC中列出了在該結(jié)點(diǎn)下大約400個(gè)標(biāo)識(shí)。
25.5 管理信息庫(kù)介紹
所謂管理信息庫(kù)，或者M(jìn)IB，就是所有代理進(jìn)程包含的、并且能夠被管理進(jìn)程進(jìn)行查詢和設(shè)置的信息的集合。我們?cè)谇懊嬉呀?jīng)提到了在RFC 1213 [McColghrie 和 Rose 1991]中定義的MIB-II。
如圖25-6所示，MIB被劃分為若干個(gè)組，如system、interfaces、at（地址轉(zhuǎn)換）和ip組等。
在本節(jié)，我們僅僅討論UDP組中的變量。這個(gè)組比較簡(jiǎn)單，它包含幾個(gè)變量和一個(gè)表格。在下一節(jié)，我們將以UDP組為例，詳細(xì)講解什么是實(shí)例標(biāo)識(shí)（instance identification），什么是字典式排序(lexicographic ordering)以及和這些概念有關(guān)的一些簡(jiǎn)單例子。在這些例子之后，在25.8節(jié)我們繼續(xù)回到MIB，描述MIB中的其他一些組。
在圖25-6中我們畫出了udp組在mib的下面。圖25-7就顯示了UDP組的結(jié)構(gòu)。
在該組中，包含4個(gè)簡(jiǎn)單變量和1個(gè)由兩個(gè)簡(jiǎn)單變量組成的表格。圖25-8描述了這4個(gè)簡(jiǎn)單變量。
在本章中，我們就以圖25-8的格式來(lái)描述所有的MIB變量。“R/W”列如果為空，則代表該變量是只讀的；如果變量是可讀可寫的，則以“·”符號(hào)來(lái)表示。哪怕整個(gè)組中的變量都是只讀的，我們也將列出“R/W”列，以提示讀者管理進(jìn)程只能對(duì)這些變量進(jìn)行查詢操作（上圖UDP組我們就是這樣做的）。同樣，如果變量類型是INTEGET類型并且有范圍約束，我們也將標(biāo)明它的下限和上限，就如我們?cè)谙聢D中描述UDP端口號(hào)所做的一樣。
圖25-9描述了在udpTable中的兩個(gè)簡(jiǎn)單變量。
每次當(dāng)我們以SNMP表格形式來(lái)描述MIB變量時(shí)，表格的第1行都表示索引的值，它是表格中的每一列的參考。在下一節(jié)中讀者將看到的一些例子也是這樣做的。
Case圖
在圖25-8中，前3個(gè)計(jì)數(shù)器是有相互關(guān)系的。Case圖真實(shí)地描述了一個(gè)給出的MIB組中變量之間的相互關(guān)系。圖25-10就是UDP組的Case圖。
這張圖表明，發(fā)送到應(yīng)用層的UDP數(shù)據(jù)報(bào)的數(shù)量（udpInDatagrams）就是從IP層送到UDP層的UDP數(shù)據(jù)報(bào)的數(shù)量，當(dāng)然udpInError和udpNoPorts也類似。同樣，發(fā)送到IP層的UDP數(shù)據(jù)報(bào)的數(shù)量（udpOutDatagrams）就是從應(yīng)用層發(fā)出的UDP數(shù)據(jù)報(bào)的數(shù)量。這表明udpInDatagram不包括udpInError和udpNoPorts。
在深入講解MIB的時(shí)候，這些Case圖被用來(lái)驗(yàn)證：分組的所有數(shù)據(jù)路徑都是被計(jì)數(shù)的。[Rose 1994]中顯示了所有MIB組的Case圖。
25.6 實(shí)例標(biāo)識(shí)
當(dāng)對(duì)MIB變量進(jìn)行操作，如查詢和設(shè)置變量的值時(shí)，必須對(duì)MIB的每個(gè)變量進(jìn)行標(biāo)識(shí)。首先，只有葉子結(jié)點(diǎn)是可操作的。SNMP沒(méi)法處理表格的一整行或一整列。回到圖25-7，在圖25-8和圖25-9中描述過(guò)的變量就是葉子結(jié)點(diǎn)，而mib、udp、udpTable和udpEntry就不是葉子結(jié)點(diǎn)。
25.6.1 簡(jiǎn)單變量
對(duì)于簡(jiǎn)單變量的處理方法是通過(guò)在其對(duì)象標(biāo)識(shí)后面添加“.0”來(lái)處理的。例如圖25-8中的計(jì)數(shù)器udpInDatagrams，它的對(duì)象標(biāo)識(shí)是1.3.6.1.2.1.7.1，它的實(shí)例標(biāo)識(shí)是1.3.6.1.2.1.7.1.0，相對(duì)應(yīng)的文字名稱是iso.org.dod.internet.mgmt.mib.udp.udpInDatagrams.0。
雖然這個(gè)變量處理后通常可以縮寫為udpInDatagrams.0，但我們還是要提醒讀者在SNMP報(bào)文中（圖25-2）該變量的名稱是其對(duì)象的標(biāo)識(shí)1.3.6.1.2.1.7.1.0。
25.6.2 表格
表格的實(shí)例標(biāo)識(shí)就要復(fù)雜得多。回顧一下圖25-8中的UDP監(jiān)聽(tīng)表。
每個(gè)MIB中的表格都指明一個(gè)以上的索引。對(duì)于UDP監(jiān)聽(tīng)表來(lái)說(shuō)，MIB定義了包含兩個(gè)變量的聯(lián)合索引，這兩個(gè)變量是：udpLocalAddress，它是一個(gè)IP地址；udpLocalPort，它是一個(gè)整數(shù)（在圖25-9中的第1行就顯示了這個(gè)索引）。
假設(shè)在UDP監(jiān)聽(tīng)表中有3行具體成員：第1行的IP地址是0.0.0.0，端口號(hào)是67；第2行的IP地址是0.0.0.0，端口號(hào)是161；第3行的IP地址是0.0.0.0，端口號(hào)是520。如圖25-11所示。
這意味著系統(tǒng)將從端口67（BOOTP服務(wù)器）、端口161（SNMP）和端口520（RIP）接受來(lái)自任何接口的UDP數(shù)據(jù)報(bào)。表格中的這3行經(jīng)過(guò)處理后的結(jié)果在圖25-12中顯示。
25.6.3 字典式排序
MIB中按照對(duì)象標(biāo)識(shí)進(jìn)行排序時(shí)有一個(gè)隱含的排序規(guī)則。MIB表格是根據(jù)其對(duì)象標(biāo)識(shí)按照字典的順序進(jìn)行排序的。這就意味著圖25-12中的6個(gè)變量排序后的情況如圖25-13所示。從這種字典式排序中可以得出兩個(gè)重要的結(jié)論。
1）在表格中，一個(gè)給定變量（在這里指udpLocalAddress）的所有實(shí)例都在下個(gè)變量（這里指udpLocalPort）的所有實(shí)例之前顯示。這暗示表格的操作順序是“先列后行”的次序。這是由于對(duì)對(duì)象標(biāo)識(shí)進(jìn)行字典式排序所得到的，而不是按照人們的閱讀習(xí)慣而排列的。
2）表格中對(duì)行的排序和表格中索引的值有關(guān)。在圖2513中，67的字典序小于161，同樣161的字典序小于520。
圖25-14描述了例子中UDP監(jiān)聽(tīng)表的這種“先列后行”的次序。
在下節(jié)中，講述到get-next操作時(shí)，同樣還會(huì)遇到這種“先列后行”的次序。
25.7 一些簡(jiǎn)單的例子
在本節(jié)中，我們將介紹如何從SNMP代理進(jìn)程處獲取變量的值。對(duì)代理進(jìn)程進(jìn)行查詢的軟件屬于ISODE系統(tǒng)，叫做snmpi。兩者在[Rose 1994]中有詳細(xì)的介紹。
25.7.1 簡(jiǎn)單變量
對(duì)一個(gè)路由器取兩個(gè)UDP組的簡(jiǎn)單變量值：
其中，-a選項(xiàng)代表要和之通信的代理進(jìn)程名稱，-c選項(xiàng)表示SNMP的共同體名。所謂共同體名，就是客戶進(jìn)程（在這里指snmpi）提供、同時(shí)能被服務(wù)器進(jìn)程（這里指代理進(jìn)程gateway）所識(shí)別的一個(gè)口令，共同體名稱是管理進(jìn)程請(qǐng)求的權(quán)限標(biāo)志。代理進(jìn)程允許客戶進(jìn)程用只讀共同體名對(duì)變量進(jìn)行讀操作，用讀寫共同體名對(duì)變量進(jìn)行讀和寫操作。
Snmpi程序的輸出提示符是snmpi>，在后面可以鍵入如get這樣的命令，該軟件將把它轉(zhuǎn)化為SNMP中的get-request報(bào)文。當(dāng)結(jié)束時(shí)，鍵入quit就退出（在后面的例子中，我們將省略掉quit的操作）。
圖25-15顯示的是對(duì)于這個(gè)例子tcpdump的兩行輸出結(jié)果。
對(duì)這兩個(gè)變量的查詢請(qǐng)求是封裝在一個(gè)UDP數(shù)據(jù)報(bào)中的，而響應(yīng)也在一個(gè)UDP數(shù)據(jù)報(bào)中。
顯示的變量是以其對(duì)象標(biāo)識(shí)的形式顯示的，這是在SNMP報(bào)文中實(shí)際傳輸?shù)膬?nèi)容。我們必須指定這兩個(gè)變量的實(shí)例是0。注意，變量的名稱（它的對(duì)象標(biāo)識(shí)）同樣也在響應(yīng)中返回。在下面我們將看到對(duì)于get-next操作這是必需的。
25.7.2 get-next操作
get-next操作是基于MIB的字典式排序的。在下面的例子中，首先向代理進(jìn)程詢問(wèn)UDP后的下一個(gè)對(duì)象標(biāo)識(shí)（由于不是一個(gè)葉子對(duì)象，沒(méi)有指定任何實(shí)例）。代理進(jìn)程將返回UDP組中的第1個(gè)對(duì)象，然后我們繼續(xù)向代理進(jìn)程取該對(duì)象的下一個(gè)對(duì)象標(biāo)識(shí)，這時(shí)候第2個(gè)對(duì)象將被返回。重復(fù)上面的步驟直到取出所有的對(duì)象為止。
這個(gè)例子解釋了為什么get-next操作總是返回變量的名稱，這是因?yàn)槲覀兿虼磉M(jìn)程詢問(wèn)下一個(gè)變量，代理進(jìn)程就把變量值和名稱一起返回了。
采用這種方式進(jìn)行g(shù)et-next操作，我們可以想象管理進(jìn)程只要做一個(gè)簡(jiǎn)單的循環(huán)程序，就可以從MIB樹的頂點(diǎn)開(kāi)始，對(duì)代理進(jìn)程一步步地進(jìn)行查詢，就可以得出代理進(jìn)程處所有的變量值和標(biāo)識(shí)。該方式的另外一個(gè)用處就是可以對(duì)表格進(jìn)行遍歷。
25.7.3 表格的訪問(wèn)
對(duì)于“先列后行”次序的UDP監(jiān)聽(tīng)表，只要采用前面的簡(jiǎn)單查詢程序一步一步地進(jìn)行操作，就可以遍歷整個(gè)表格。只要從詢問(wèn)代理進(jìn)程udpTable的下一個(gè)變量開(kāi)始就可以了。由于udpTable不是葉子對(duì)象，我們不能指定一個(gè)實(shí)例，但是get-next操作依然能夠返回表格中的下一個(gè)對(duì)象。然后就可以以返回的結(jié)果為基礎(chǔ)進(jìn)行下一步的操作，代理進(jìn)程也會(huì)以“先列后行”的次序返回下一個(gè)變量，這樣就可以遍歷整個(gè)表格。我們可以看到返回的次序和圖25-14相同。
但是管理進(jìn)程如何知道已經(jīng)到達(dá)表格的最后一行呢？既然get-next操作返回結(jié)果中包含表格中的下一個(gè)變量的值和名稱，當(dāng)返回的結(jié)果是超出表格之外的下一個(gè)變量時(shí)，管理進(jìn)程就可以發(fā)現(xiàn)變量的名稱發(fā)生了較大的變化。這樣就可以判斷出已經(jīng)到達(dá)表格的最后一行。例如在我們的例子中，當(dāng)返回的是snmpInPkts變量的時(shí)候就代表已經(jīng)到了UDP監(jiān)聽(tīng)表的最后一個(gè)變量了。
25.8 管理信息庫(kù)（續(xù)）
現(xiàn)在繼續(xù)討論MIB。我們僅僅介紹下列MIB組：system（系統(tǒng)標(biāo)識(shí)）、if（接口）、at（地址轉(zhuǎn)換）、ip、icmp和tcp。
25.8.1 system組
system組非常簡(jiǎn)單，它包含7個(gè)簡(jiǎn)單變量（例如，沒(méi)有表格）。圖25-16列出了system組的名稱、數(shù)據(jù)類型和描述。
可以對(duì)netb路由器查詢一些簡(jiǎn)單變量：
回到圖25-6中，system的對(duì)象標(biāo)識(shí)符在internet.private.enterprises組（1.3.6.1.4.1）中，在Assigned Numbers RFC文檔中可以確定下一個(gè)對(duì)象標(biāo)識(shí)符（12）肯定是指派給了廠家（Epilogue）。
同時(shí)還可以看出，sysServices變量的值是4與8的和，它支持網(wǎng)絡(luò)層（例如選路）和運(yùn)輸層的應(yīng)用（例如端到端）。
25.8.2 interface組
在本組中只定義了一個(gè)簡(jiǎn)單變量，那就是系統(tǒng)的接口數(shù)量，如圖25-17所示。
在該組中，還有一個(gè)表格變量，有22列。表格中的每行定義了接口的一些特征參數(shù)。如圖25-18所示。
可以向主機(jī)sun查詢所有這些接口的變量。如3.8節(jié)中所示，我們還是希望訪問(wèn)三個(gè)接口，如果SLIP接口已經(jīng)啟動(dòng)：
對(duì)于第1個(gè)接口，采用get操作提取5個(gè)變量值，然后用get-next操作提取第2個(gè)接口的相同的5個(gè)參數(shù)。對(duì)于第3個(gè)接口，同樣采用get-next操作。
對(duì)于SLIP鏈路的接口類型，所報(bào)告的是一個(gè)點(diǎn)到點(diǎn)的專用串行鏈路，而不是SLIP鏈路。此外，SLIP鏈路的速率沒(méi)有報(bào)告。
這個(gè)例子對(duì)我們理解get-next操作和“先列后行”次序之間的關(guān)系十分重要。如果我們鍵入命令“next ifDescr.1”，則系統(tǒng)返回的是表格中的下一行所對(duì)應(yīng)的變量，而不是同一行中的下個(gè)變量。如果表格是按照“先行后列”次序存放，我們就不能通過(guò)一個(gè)給定變量來(lái)讀取下一個(gè)變量。
25.8.3 at組
地址轉(zhuǎn)換組對(duì)于所有的系統(tǒng)都是必需的，但是在MIB-II中已經(jīng)沒(méi)有這個(gè)組。從MIB-II開(kāi)始，每個(gè)網(wǎng)絡(luò)協(xié)議組（如IP組）都包含它們各自的網(wǎng)絡(luò)地址轉(zhuǎn)換表。例如對(duì)于IP組，網(wǎng)絡(luò)地址轉(zhuǎn)換表就是ipNetToMediaTable。
在該組中，僅有一個(gè)由3列組成的表格變量。如圖25-19所示。
我們將用snmpi程序中的一個(gè)新命令來(lái)轉(zhuǎn)儲(chǔ)(dump)整個(gè)表格。向一個(gè)叫做kinetics的路由器（該路由器連接了一個(gè)TCP/IP網(wǎng)絡(luò)和一個(gè)AppleTa lk網(wǎng)絡(luò)）查詢其整個(gè)ARP高速緩存。命令的輸出是字典式排序的整個(gè)表格內(nèi)容。
讓我們來(lái)分析一下用tcpdump命令時(shí)的分組交互情況。當(dāng)snmpi要轉(zhuǎn)儲(chǔ)整個(gè)表格時(shí)，首先發(fā)出一條get-next命令以取得表格的名稱（在本例中是at），該名稱就是要獲取的第一個(gè)表項(xiàng)。然后在屏幕上顯示的同時(shí)生成另一條get-next命令。直到遍歷完整個(gè)表格的內(nèi)容后才終止。
圖25-20顯示了在路由器中實(shí)際表格的內(nèi)容。
注意圖中，接口2的AppleTa lk協(xié)議的物理地址是32 bit的數(shù)值，而不是我們所熟悉的以太網(wǎng)的48 bit物理地址。同時(shí)請(qǐng)注意，正如我們所希望的那樣，在圖中有一條記錄和netb路由器（其IP地址是140.252.1.183）有關(guān)。這是因?yàn)閚etb路由器和kinetics路由器在同一個(gè)以太網(wǎng)中（140.252.1），而且kinetics路由器必需采用ARP來(lái)回送SNMP響應(yīng)。
25.8.4 ip 組
ip組定義了很多簡(jiǎn)單變量和3個(gè)表格變量。圖25-21顯示了所有的簡(jiǎn)單變量。
ip組中的第一個(gè)表格變量是IP地址表。系統(tǒng)的每個(gè)IP地址都對(duì)應(yīng)該表格中的一行。每行中包含了5個(gè)變量，如圖25-22所示。
同樣可以向主機(jī)sun查詢整個(gè)IP地址表：
輸出的接口號(hào)碼可以和圖25-18中的輸出進(jìn)行比較，同樣IP地址和子網(wǎng)掩碼可以和3.8節(jié)中采用ifconfig命令時(shí)的輸出進(jìn)行比較。
ip組中的第二個(gè)表是IP路由表（請(qǐng)回憶一下我們?cè)?.2節(jié)中講到的路由表），如圖25-23所示。訪問(wèn)該表中每行記錄的索引是目的IP地址。
圖25-24顯示的是用snmpi程序采用dumpipRouteTable命令從主機(jī)sun得到的路由表。在這張表中，已經(jīng)刪除了所有5個(gè)路由度量，那是由于這5條記錄的度量都是-1。在列的標(biāo)題中，對(duì)每個(gè)變量名稱已經(jīng)刪除了ipRoute這樣的前綴。
為比較起見(jiàn)，下面的內(nèi)容是我們用netstat命令（在9.2節(jié)中曾經(jīng)討論過(guò)）格式顯示的路由表信息。圖25-24是按字典序顯示的，這和netstat命令顯示格式不同：
ip組的最后一個(gè)表是地址轉(zhuǎn)換表，如圖25-25所示。正如我們前面所說(shuō)的，at組已經(jīng)被刪除了，在這里已經(jīng)用IP表來(lái)代替了。
這里顯示的是系統(tǒng)sun上的ARP高速緩存信息：
相應(yīng)的SNMP輸出：
25.8.5 icmp組
icmp組包含4個(gè)普通計(jì)數(shù)器變量（ICMP報(bào)文的輸出和輸入數(shù)量以及ICMP差錯(cuò)報(bào)文的輸入和輸出數(shù)量）和22個(gè)其他ICMP報(bào)文數(shù)量的計(jì)數(shù)器：11個(gè)是輸出計(jì)數(shù)器，另外11個(gè)是輸入計(jì)數(shù)器。如圖25-26所示。
對(duì)于有附加代碼的ICMP報(bào)文（請(qǐng)回憶一下圖6-3中，有15種報(bào)文代表目的不可達(dá)），SNMP沒(méi)有為它們定義專門的計(jì)數(shù)器。
25.8.6 tcp組
圖25-27顯示的是tcp組中的簡(jiǎn)單變量。其中的很多變量和圖18-12描述的TCP狀態(tài)有關(guān)。
現(xiàn)在向系統(tǒng)sun查詢一些tcp組變量：
本系統(tǒng)（指SunOS4.1.3）使用的是Van Jacobson超時(shí)重傳算法，超時(shí)定時(shí)器的范圍在200 ms~12.8 s之間，并且對(duì)TCP連接數(shù)量沒(méi)有特定的限制（這里的超時(shí)上限12.8 s恐怕有錯(cuò)，因?yàn)槲覀冊(cè)?1章中曾經(jīng)介紹大多數(shù)應(yīng)用的超時(shí)上限是64 s）。
tcp組還包括一個(gè)表格變量，即TCP連接表，如圖25-28所示。對(duì)于每個(gè)TCP連接，都對(duì)應(yīng)表格中的一條記錄。每條記錄包含5個(gè)變量：連接狀態(tài)、本地IP地址、本地端口號(hào)、遠(yuǎn)端IP地址以及遠(yuǎn)端端口號(hào)。
讓我們看一看在系統(tǒng)sun上的這個(gè)表。由于有許多服務(wù)器進(jìn)程在監(jiān)聽(tīng)這些連接，所以我們只顯示該表的一部分內(nèi)容。在轉(zhuǎn)儲(chǔ)全部表格的變量之前，我們必需先建立兩條TCP連接：
在所有的監(jiān)聽(tīng)服務(wù)器進(jìn)程中，我們僅僅列出了FTP服務(wù)器進(jìn)程的情況，它使用21號(hào)端口。
對(duì)于rlogin到gemini，只顯示一條記錄，這是因?yàn)間emini是另外一個(gè)主機(jī)。而且我們僅僅能夠看到連接的客戶端信息（端口號(hào)是1023）。但是Telnet連接，客戶端和服務(wù)器端都顯示（客戶端口號(hào)是1415，服務(wù)器端口號(hào)是23），這是因?yàn)檫@種連接通過(guò)環(huán)回接口。同時(shí)我們還可以看到，F(xiàn)TP監(jiān)聽(tīng)服務(wù)器程序的本地IP地址是0.0.0.0。這表明它可以接受通過(guò)任何接口的連接。
25.9 其他一些例子
現(xiàn)在開(kāi)始回答前面一些沒(méi)有回答的問(wèn)題，我們將用SNMP的知識(shí)進(jìn)行解釋。
25.9.1 接口MTU
回憶一下在11.6節(jié)的實(shí)驗(yàn)中，我們?cè)噲D得出一條從netb到sun的SLIP連接的MTU。現(xiàn)在可以采用SNMP得到這個(gè)MTU。首先從IP路由表中取到SLIP連接（140.252.1.29）的接口號(hào)（ipRouteIfIndex），然后就可以用這個(gè)數(shù)值進(jìn)入接口表并且取得想要的SLIP連接的MTU（通過(guò)SLIP的描述和數(shù)據(jù)類型）。
可以看到，即使連接的類型是SLIP連接，但是MTU仍設(shè)置為以太網(wǎng)，其值為1500，目的可能是為了避免分片。
25.9.2 路由表
回憶一下在14.4節(jié)中，我們討論了DNS如何進(jìn)行地址排序的問(wèn)題。當(dāng)時(shí)我們介紹了從域名服務(wù)器返回的第1個(gè)IP地址是和客戶有相同子網(wǎng)掩碼的情況。還介紹了用其他的IP地址也會(huì)正常工作，但是效率比較低。現(xiàn)在我們從SNMP的角度來(lái)查閱路由表的入口，在這里將用到前面章節(jié)中和IP路由有關(guān)的很多相關(guān)知識(shí)。
路由器gemini是一個(gè)多接口主機(jī)，有兩個(gè)以太網(wǎng)接口。首先確認(rèn)一下兩個(gè)接口都可以Telnet登錄：
可以看出這兩個(gè)地址的連接沒(méi)有什么區(qū)別。現(xiàn)在我們采用traceroute命令來(lái)看一下對(duì)于每個(gè)地址，是否有選路方面的不同：
可以看到：如果采用屬于140.252.3子網(wǎng)的地址，就多了額外的一跳。下面解釋造成這個(gè)額外一跳的原因。
圖25-29是系統(tǒng)的連接關(guān)系圖。從traceroute命令的輸出結(jié)果可以看出主機(jī)gemini和路由器swnrt都連接了兩個(gè)網(wǎng)段：140.252.3子網(wǎng)和140.252.1子網(wǎng)。
回憶一下在圖4-6中，我們解釋了路由器netb采用ARP代理進(jìn)程，使得sun工作站好象是直接連接到140.252.1子網(wǎng)上的情況。我們忽略了sun和netb之間SLIP連接的調(diào)制解調(diào)器，因?yàn)檫@和我們這里的討論不相關(guān)。
在圖25-29中，我們用虛線箭頭畫出了當(dāng)Te lnet到140.252.3.54時(shí)的路徑。返回的數(shù)據(jù)報(bào)怎么知道直接從gemini到netb，而不是從原路返回呢？我們采用在8.5節(jié)中介紹過(guò)的，帶有寬松選路特性的traceroute版本來(lái)解釋：
當(dāng)在命令中指明是寬松源站選路時(shí)，swnrt路由器就不再有響應(yīng)。看一下前面沒(méi)有指明源站選路的traceroute命令輸出，可以看出swnrt路由器是事實(shí)上的第2跳。超時(shí)數(shù)據(jù)必須這樣設(shè)置的原因是：當(dāng)數(shù)據(jù)報(bào)指定了寬松源站選路選項(xiàng)時(shí)，該路由器沒(méi)有發(fā)生ICMP超時(shí)差錯(cuò)。所以在traceroute命令的輸出中可以得出，返回路徑是從gemini(TTL 3,4和5)路由器直接到達(dá)netb路由器，而不通過(guò)swnrt路由器。
還剩下一個(gè)需要用SNMP來(lái)解釋的問(wèn)題就是：在netb路由器的路由表中，哪條信息代表尋徑到140.252.3？該信息表示netb路由器把分組發(fā)送給swnrt而不是直接發(fā)送給gemini？用get命令來(lái)取下一跳路由器的值。
sun % snmpi -a netb -c secret get ipRouteNextHop.140.252.3.0
ipRouteNextHop.140.252.3.0=140.252.1.6
正如我們所看到發(fā)生的那樣，路由表設(shè)置使得netb路由器把分組發(fā)送到swnrt路由器。
為什么gemini路由器直接把分組回送給netb路由器？那是因?yàn)樵趃emini路由器端，它要回送的分組目的地址是140.252.1.29，而子網(wǎng)140.252.1是直接連接到gemini路由器上的。
從上面這個(gè)例子可以看出選路的策略。由于gemini是打算作一個(gè)多接口主機(jī)而不是路由器，所以默認(rèn)的到140.253.3子網(wǎng)的路由器是swnrt。這是多接口主機(jī)和路由器之間差異的一個(gè)典型例子。
25.10 Trap
本章我們看到的例子都是從管理進(jìn)程到代理進(jìn)程的。當(dāng)然代理進(jìn)程也可以主動(dòng)發(fā)送trap到管理進(jìn)程，以告訴管理進(jìn)程在代理進(jìn)程側(cè)有某些管理進(jìn)程所關(guān)心的事件發(fā)生，如圖25-1所示。trap發(fā)送到管理進(jìn)程的162號(hào)端口。
在圖25-2中，我們已經(jīng)描述了trap PDU的格式。在下面關(guān)于tcpdump輸出內(nèi)容中我們將再一次用到這些字段。
現(xiàn)在已經(jīng)定義了6種特定的trap類型，第7種trap類型是由供應(yīng)商自己定義的特定類型。圖25-30給出了trap報(bào)文中trap類型字段的內(nèi)容。
用tcpdump命令來(lái)看看trap的情況。我們?cè)谙到y(tǒng)sun上啟動(dòng)SNMP代理進(jìn)程，然后讓它產(chǎn)生coldStart類型的trap（我們告訴代理進(jìn)程把trap信息發(fā)送到bsdi主機(jī)。雖然在該主機(jī)上并沒(méi)有運(yùn)行處理trap的管理進(jìn)程，但是可以用tcpdump來(lái)查看產(chǎn)生了什么樣的分組。回憶一下在圖25-1中，trap是從代理進(jìn)程發(fā)送到管理進(jìn)程的，而管理進(jìn)程不需要給代理進(jìn)程發(fā)送確認(rèn)。所以我們不需要trap的處理程序）。然后我們用snmpi程序發(fā)送一個(gè)請(qǐng)求，但該請(qǐng)求的共同體名稱是無(wú)效的。這將產(chǎn)生一個(gè)authenticationFailure類型的trap。圖25-31顯示了命令的輸出結(jié)果。
首先注意一下兩個(gè)UDP數(shù)據(jù)報(bào)都是從SNMP代理進(jìn)程（端口是161，圖中顯示的名稱是snmp）發(fā)送到目的端口號(hào)是162的服務(wù)器進(jìn)程上的（圖中顯示的名稱是snmp-trap）。
再注意一下C=traps是trap報(bào)文的共同體名稱。這是ISODE SNMP代理進(jìn)程的配置選項(xiàng)。
下一個(gè)要注意的是：第1行中的Trap（28）和第2行中的Trap（29）是PDU類型和長(zhǎng)度。
兩個(gè)輸出行的第一項(xiàng)內(nèi)容都是相同的 E:unix.1.2.5。這代表企業(yè)名字段和代理進(jìn)程的sysObjiectID。它是圖25-6中1.3.6.1.4.1（iso.org.dod.internet.private.enterparses）結(jié)點(diǎn)下面的某個(gè)結(jié)點(diǎn)，所以代理進(jìn)程的對(duì)象標(biāo)識(shí)是1.3.6.1.4.1.4.1.2.5。它的簡(jiǎn)稱是：unix.agents.fourBSD-isode.5。最后一個(gè)數(shù)字“5”代表ISODE代理進(jìn)程軟件的版本號(hào)。這些企業(yè)名的值代表了產(chǎn)生trap的代理進(jìn)程軟件信息。
輸出的下一項(xiàng)是代理進(jìn)程的IP地址（140.252.13.33）。
在第1行中，trap的類型顯示的是coldStart，第2行中，顯示的是authenticationFailure。與之相對(duì)應(yīng)的trap類型值是0和4（如圖25-30所示）。由于這些都不是廠家自定義的trap，所以特定代碼必須是0，在圖中沒(méi)有顯示。
輸出的最后分別是20和1907，這是時(shí)間戳字段。它是TimeTicks類型的值，表示從代理進(jìn)程初始化開(kāi)始到trap發(fā)生所經(jīng)歷了多少個(gè)百分之一秒。在冷啟動(dòng)trap的情況下，在代理進(jìn)程初始化后到trap的產(chǎn)生共經(jīng)歷了200 ms。同樣，tcpdump的輸出表明第2個(gè)trap在第1個(gè)trap產(chǎn)生的18.86s后出現(xiàn)，這對(duì)應(yīng)于打印出的1907個(gè)百分之一秒減去200 ms所得到的值。
圖25-2表明trap報(bào)文還包含很多代理進(jìn)程發(fā)送給管理進(jìn)程的變量，但在這些在例子中沒(méi)有再討論。
25.11 ASN.1和BER
在正式的SNMP規(guī)范中都是采用ASN.1（Abstract Syntax Notation 1）語(yǔ)法，并且在SNMP報(bào)文中比特的編碼采用BER（Basic Encoding Rule）。和其他介紹SNMP的書不同，我們有目的地把ASN.1和BER的討論放到最后。因?yàn)槿绻旁谇懊嬗懻摚锌赡苁棺x者產(chǎn)生混淆而忽略了SNMP的真正目的是進(jìn)行網(wǎng)絡(luò)管理。在這里我們也只是對(duì)這兩個(gè)概念簡(jiǎn)單地進(jìn)行解釋，[Rose 1990]的第8章詳細(xì)討論了ASN.1和BER。
ASN.1是一種描述數(shù)據(jù)和數(shù)據(jù)特征的正式語(yǔ)言。它和數(shù)據(jù)的存儲(chǔ)及編碼無(wú)關(guān)。MIB和SNMP報(bào)文中的所有的字段都是用ASN.1描述的。例如：對(duì)于SMI中的ipAddress數(shù)據(jù)類型，ASN.1是這樣描述的：
用SEQUENCE和SEQUENCE OF來(lái)定義表格的描述更加復(fù)雜。
當(dāng)有了這樣的ASN.1定義，可以有多種編碼方法把數(shù)據(jù)編碼為傳輸?shù)谋忍亓鳌NMP使用的編碼方法是BER。例如，對(duì)于一個(gè)簡(jiǎn)單的整數(shù)如64，在BER中需要用3個(gè)字節(jié)來(lái)表示。第一個(gè)字節(jié)說(shuō)明類型是一個(gè)整數(shù)，下個(gè)字節(jié)說(shuō)明用了多少個(gè)字節(jié)來(lái)存儲(chǔ)該整數(shù)（在這里是1），最后一個(gè)字節(jié)才是該整數(shù)的值。
幸運(yùn)的是，ASN.1和BER這兩個(gè)繁瑣的概念僅僅在實(shí)現(xiàn)SNMP的時(shí)候才重要，對(duì)我們理解網(wǎng)絡(luò)管理的概念和流程并沒(méi)有太大的關(guān)系。
25.12 SNMPv2
在1993年，發(fā)表了定義新版本SNMP的11個(gè)RFC。RFC 1441[Case et al.1993]是其中的第一個(gè)，它系統(tǒng)地介紹了SNMPv2。同樣，有兩本書[Stallings 1993;Rose 1994]也對(duì)SNMPv2進(jìn)行了介紹。現(xiàn)在已經(jīng)有兩個(gè)SNMPv2的基本模型（參見(jiàn)附錄B.3中的[Rose 1994]），但是廠家的實(shí)現(xiàn)到1994年才能廣泛使用。
在本節(jié)中，我們主要介紹SNMPv1和SNMPv2之間的重要區(qū)別。
1：在SNMPv2中定義了一個(gè)新的分組類型get-bulk-request，它高效率地從代理進(jìn)程讀取大塊數(shù)據(jù)。
2：另的一個(gè)新的分組類型是inform-request，它使一個(gè)管理進(jìn)程可以向另一個(gè)管理進(jìn)程發(fā)送信息。
3：定義了兩個(gè)新的MIB，它們是：SNMPv2 MIB和SNMPv2-M2M MIB（管理進(jìn)程到管理進(jìn)程的MIB）。
4：SNMPv2的安全性比SNMPv1大有提高。在SNMPv1中，從管理進(jìn)程到代理進(jìn)程的共同體名稱是以明文方式傳送的。而SNMPv2可以提供鑒別和加密。
廠家提供的設(shè)備支持SNMPv2的會(huì)越來(lái)越多，管理站將對(duì)兩個(gè)版本的SNMP代理進(jìn)程進(jìn)行管理。[Routhier 1993]中描述了如何將SNMPv1的實(shí)現(xiàn)擴(kuò)展到支持SNMPv2。
25.13 小結(jié)
SNMP是一種簡(jiǎn)單的、SNMP管理進(jìn)程和SNMP代理進(jìn)程之間的請(qǐng)求-應(yīng)答協(xié)議。MIB定義了所有代理進(jìn)程所包含的、能夠被管理進(jìn)程查詢和設(shè)置的變量，這些變量的數(shù)據(jù)類型并不多。
所有這些變量都以對(duì)象標(biāo)識(shí)符進(jìn)行標(biāo)識(shí)，這些對(duì)象標(biāo)識(shí)符構(gòu)成了一個(gè)層次命名結(jié)構(gòu)，由一長(zhǎng)串的數(shù)字組成，但通常縮寫成人們閱讀方便的簡(jiǎn)單名字。一個(gè)變量的特定實(shí)例可以用附加在這個(gè)對(duì)象標(biāo)識(shí)符后面的一個(gè)實(shí)例來(lái)標(biāo)識(shí)。
很多SNMP變量是以表格形式體現(xiàn)的。它們有固定的欄目，但有多少條記錄并不固定。對(duì)于SNMP來(lái)講，重要的是對(duì)表格中的每一行如何進(jìn)行標(biāo)識(shí)（尤其當(dāng)我們不知道表格中有多少條記錄時(shí)）以及如何按字典方式進(jìn)行排序（“先列后行”的次序）。最后要說(shuō)明的一點(diǎn)是：SNMP的get-next操作符對(duì)任何SNMP管理進(jìn)程來(lái)講都是最基本的操作。
然后我們介紹了下列的SNMP變量組：system、interface、address translation、IP、ICMP、TCP和UDP。接著是兩個(gè)例子，一個(gè)介紹如何確定一個(gè)接口的MTU，另外一個(gè)介紹如何獲取路由器的路由信息。
在本章的后面介紹了SNMP的trap操作，它是當(dāng)代理進(jìn)程發(fā)生了某些重大事件后主動(dòng)向管理進(jìn)程報(bào)告的。最后我們簡(jiǎn)單介紹了ASN.1和BER，這兩個(gè)概念比較繁瑣，但所幸的是，它對(duì)我們了解SNMP并不十分重要，僅僅在實(shí)現(xiàn)SNMP的時(shí)候才要用到。
