SNMP協(xié)議以及在OLT產(chǎn)品中的應(yīng)用詳解

SNMP協(xié)議

在OLT產(chǎn)品中的應(yīng)用詳解

V1.0深圳市中舟通信技術(shù)有限公司（內(nèi)部保密）一、網(wǎng)絡(luò)管理的概念1.1網(wǎng)絡(luò)管理的基本概念網(wǎng)絡(luò)管理包括對(duì)硬件、軟件和人力的使用、綜合與協(xié)調(diào)，以便對(duì)網(wǎng)絡(luò)資源進(jìn)行監(jiān)視、測(cè)試、配置、分析、評(píng)價(jià)和控制，這樣就能以合理的價(jià)格滿足網(wǎng)絡(luò)的一些需求，如實(shí)時(shí)運(yùn)行性能，服務(wù)質(zhì)量等。網(wǎng)絡(luò)管理常簡(jiǎn)稱為網(wǎng)管。網(wǎng)絡(luò)管理功能可概括為OAM﹠P，即網(wǎng)絡(luò)的運(yùn)行（Operation）、處理（Administration）、維護(hù)（Maintenance）、服務(wù)提供（Provisioning）等所需要各種活動(dòng)。有時(shí)也考慮前三種，即把網(wǎng)絡(luò)管理功能歸結(jié)為OAM。1.2網(wǎng)絡(luò)管理的一般模型管理站因特網(wǎng)網(wǎng)絡(luò)管理員

被管設(shè)備——

管理程序（運(yùn)行SNMP客戶程序）——代理程序（運(yùn)行SNMP服務(wù)器程序）M

被管設(shè)備

被管設(shè)備

被管設(shè)備MA網(wǎng)管協(xié)議

被管設(shè)備AAAAA1.3網(wǎng)絡(luò)管理模型中的主要構(gòu)件網(wǎng)絡(luò)管理中常用術(shù)語(yǔ)網(wǎng)絡(luò)元素網(wǎng)絡(luò)中具體的通信設(shè)備或邏輯實(shí)體，又稱網(wǎng)元。

綜合網(wǎng)絡(luò)管理INM，用統(tǒng)一的方法在一個(gè)異構(gòu)網(wǎng)絡(luò)中管理多廠商生產(chǎn)的計(jì)算機(jī)硬件和軟件資源。

對(duì)象通信和信息處理范疇里可標(biāo)識(shí)的切擁有一定信息特性的資源。

被管對(duì)象通信和信息處理范被管理對(duì)象指可使用管理協(xié)議進(jìn)行管理和控制的網(wǎng)絡(luò)資源的抽象表示。

管理信息庫(kù)MIBMIB是網(wǎng)絡(luò)管理系統(tǒng)中的重要構(gòu)件，它有一個(gè)系統(tǒng)內(nèi)的許多被管對(duì)象及其屬性組成。

1.4網(wǎng)絡(luò)管理中常用術(shù)語(yǔ)1.5網(wǎng)絡(luò)管理協(xié)議網(wǎng)絡(luò)管理協(xié)議，簡(jiǎn)稱為網(wǎng)管協(xié)議。需要注意的是，并不是網(wǎng)管協(xié)議本身來(lái)管理網(wǎng)絡(luò)。網(wǎng)管協(xié)議就是管理程序和代理程序之間進(jìn)行通信的規(guī)則。網(wǎng)絡(luò)管理員利用網(wǎng)管協(xié)議通過(guò)管理站對(duì)網(wǎng)絡(luò)中的被管設(shè)備進(jìn)行管理。網(wǎng)絡(luò)管理的基本原理：

若要管理某個(gè)對(duì)象，就必然會(huì)給該對(duì)象添加一些軟件或硬件，但這種“添加”必須對(duì)原有對(duì)象的影響盡量小些。1.6客戶服務(wù)方式

管理程序和代理程序按客戶服務(wù)器方式工作。

管理程序運(yùn)行SNMP客戶程序，向某個(gè)代理程序發(fā)出請(qǐng)求（或命令），代理程序運(yùn)行SNMP服務(wù)器程序，返回響應(yīng)（或執(zhí)行某個(gè)動(dòng)作）。

在網(wǎng)管系統(tǒng)中往往是一個(gè)（或少數(shù)幾個(gè)）客戶程序與很多的服務(wù)器程序進(jìn)行交互。二、SNMP協(xié)議2.1SNMP概述SNMP是一系列協(xié)議組和規(guī)范，它們提供了一種從網(wǎng)絡(luò)上的設(shè)備中收集網(wǎng)絡(luò)管理信息的方法，也為設(shè)備向網(wǎng)絡(luò)管理工作站報(bào)告問(wèn)題和錯(cuò)誤提供了一種方法。SNMP基于傳輸層UDP用戶數(shù)據(jù)報(bào)協(xié)議，在管理者和被管理設(shè)備（確切的說(shuō)是agent）之間傳遞信息。2.2SNMP基礎(chǔ)SNMP的指導(dǎo)思想SNMP的管理站和委托管理SNMP的三個(gè)組成部分SNMP2.2.1SNMP的指導(dǎo)思想SNMP最重要的指導(dǎo)思想就是要盡可能簡(jiǎn)單。SNMP的基本功能包括監(jiān)視網(wǎng)絡(luò)性能、檢測(cè)分析網(wǎng)絡(luò)差錯(cuò)和配置網(wǎng)絡(luò)設(shè)備等。在網(wǎng)絡(luò)正常工作時(shí)，SNMP可實(shí)現(xiàn)統(tǒng)計(jì)、配置、和測(cè)試等功能。當(dāng)網(wǎng)絡(luò)出故障時(shí)，可實(shí)現(xiàn)各種差錯(cuò)檢測(cè)和恢復(fù)功能。雖然SNMP是在TCP/IP基礎(chǔ)上的網(wǎng)絡(luò)管理協(xié)議，但也可擴(kuò)展到其他類型的網(wǎng)絡(luò)設(shè)備上。2.2.2SNMP的管理站和委托管理

右圖是使用SNMP的典型配置。整個(gè)系統(tǒng)必須有一個(gè)管理站（managementstation），它實(shí)際上是網(wǎng)控中心。在管理站內(nèi)運(yùn)行管理進(jìn)程。在每個(gè)被管對(duì)象中一定要有代理進(jìn)程。管理進(jìn)程和代理繼承利用SNMP報(bào)文進(jìn)行通信，而SNMP報(bào)文又使用UDP來(lái)傳送。圖中有兩個(gè)主機(jī)和一個(gè)路由器。這些協(xié)議棧中帶有陰影的部分是這些主機(jī)和路由器所具有的，而沒(méi)有陰影的部分是為實(shí)現(xiàn)網(wǎng)絡(luò)管理而增加的。2.2.2SNMP的管理站和委托管理（續(xù)）有時(shí)網(wǎng)絡(luò)管理協(xié)議無(wú)法控制某些網(wǎng)絡(luò)元素，例如該網(wǎng)絡(luò)元素使用的是另一種網(wǎng)絡(luò)管理協(xié)議。這是可使用委托代理（proxyagent）。委托代理能提供如協(xié)議轉(zhuǎn)換和過(guò)濾操作的匯集功能。然后委托代理來(lái)對(duì)管理對(duì)象進(jìn)行管理。下圖表示委托管理的配置情況。2.2.3SNMP的構(gòu)成SNMP的三個(gè)組成部分SNMP本身 SNMP定義了管理站和代理之間所交換的分組格式。所交換的分組包含各代理中的對(duì)象（變量）名及其狀態(tài)（值）。 SNMP負(fù)責(zé)讀取和改變這些數(shù)值。SMI管理信息結(jié)構(gòu)SMI定義了命名對(duì)象和定義對(duì)象類型（包括范圍和長(zhǎng)度）的通用規(guī)則，以及把對(duì)象和對(duì)象的值進(jìn)行編碼的規(guī)則。這樣做是為了確保網(wǎng)絡(luò)管理數(shù)據(jù)的語(yǔ)法和語(yǔ)義的無(wú)二義性。但從SMI的名稱并不能看出它的功能。SMI并不定義一個(gè)實(shí)體應(yīng)管理的對(duì)象數(shù)目，也不定義被管對(duì)象名以及對(duì)象名及其值之間的關(guān)聯(lián)。MIB管理信息庫(kù)MIB在被管理的實(shí)體中創(chuàng)建了命名對(duì)象，并規(guī)定了其類型。2.3SNMP工作原理2.3.1SNMP協(xié)議的版本2.3.2SNMPv12.3.3SNMPv2c2.3.5SNMP網(wǎng)絡(luò)管理工作站收集數(shù)據(jù)的方法2.3.4SNMPv32.3.1SNMP協(xié)議的版本SNMPV1

采用UDP協(xié)議，支持最為廣泛，安全機(jī)制脆弱，通信不加密。SNMPV2c

語(yǔ)義進(jìn)行了增強(qiáng)，安全機(jī)制脆弱，通信不加密。SNMPV3

普及度不高，增強(qiáng)了安全機(jī)制，協(xié)議可以加密。2.3.2SNMPv1

SNMPv1支持的操作

SNMPPDU格式

報(bào)文應(yīng)答序列

SNMPv1的局限性

報(bào)文的發(fā)送和接收SNMPv1支持的操作 SNMP僅支持對(duì)管理對(duì)象值的檢索和修改等簡(jiǎn)單操作。具體地說(shuō)，SNMP實(shí)體可以對(duì)MIB-2中的對(duì)象執(zhí)行下列操作：●Get：管理站檢索管理信息庫(kù)中標(biāo)量對(duì)象的值；●Set：管理站設(shè)置管理信息庫(kù)中標(biāo)量對(duì)象的值；●

Trap：代理向管理站報(bào)告管理對(duì)象的狀態(tài)變化。

SNMP不支持管理站改變管理信息庫(kù)的結(jié)構(gòu)，即不能增加和刪除管理信息庫(kù)中的管理對(duì)象實(shí)例，例如不能增加或刪除表中的一行。一般來(lái)說(shuō)，管理站也不能向管理對(duì)象發(fā)出執(zhí)行一個(gè)動(dòng)作的命令。管理站只能逐個(gè)訪問(wèn)管理信息庫(kù)中的葉結(jié)點(diǎn)，不能一次性訪問(wèn)一個(gè)子樹(shù)，例如不能訪問(wèn)整個(gè)表的內(nèi)容。從上一章我們知道，MIB-2中的子樹(shù)結(jié)點(diǎn)都是不可訪問(wèn)的。這些限制確實(shí)簡(jiǎn)化了SNMP的實(shí)現(xiàn)，但是也限制了網(wǎng)絡(luò)管理的功能SNMPPDU格式RFC1157給出了SNMPv1協(xié)議的定義，這個(gè)定義是用ASN.1表示的。根據(jù)這個(gè)定義我們可以畫(huà)出如下圖所示的SNMP報(bào)文格式。在SNMP管理中，管理站和代理之間交換的管理信息構(gòu)成了SNMP報(bào)文。報(bào)文由3部分組成，即版本號(hào)、團(tuán)體名和協(xié)議數(shù)據(jù)單元(PDU)?！駡?bào)文頭中的版本號(hào)是指SNMP的版本，RFC1157為第1版?！駡F(tuán)體名用于身份認(rèn)證。●SNMP共有5種管理操作，但只有4種PDU格式。管理站發(fā)出的3種請(qǐng)求報(bào)文GetRequest、GetNextRequest和SetRequest采用的格式是一樣的，代理的應(yīng)答報(bào)文格式只有一種GetResponsePDU，從而簡(jiǎn)少了PDU的種類。

網(wǎng)絡(luò)管理模型中的主要構(gòu)件圖SNMP報(bào)文格式

從圖

看出，除過(guò)Trap之外的4種PDU格式是相同的，共有5個(gè)字段：

(1)PDU類型：共5種類型的PDU。

(2)請(qǐng)求標(biāo)識(shí)(request-id)：賦予每個(gè)請(qǐng)求報(bào)文惟一的整數(shù)，用于區(qū)分不同的請(qǐng)求。由于在具體實(shí)現(xiàn)中請(qǐng)求多是在后臺(tái)執(zhí)行的，因而當(dāng)應(yīng)答報(bào)文返回時(shí)要根據(jù)其中的請(qǐng)求標(biāo)識(shí)與請(qǐng)求報(bào)文配對(duì)。請(qǐng)求標(biāo)識(shí)的另一個(gè)作用是檢測(cè)由不可靠的傳輸服務(wù)產(chǎn)生的重復(fù)報(bào)文。 (3)錯(cuò)誤狀態(tài)(error-status)：表示代理在處理管理站的請(qǐng)求時(shí)可能出現(xiàn)的各種錯(cuò)誤，共有6種錯(cuò)誤狀態(tài)：noError(0)、tooBig(1)、noSuchName(2)、badValue(3)、readOnly(4)、genError(5)。對(duì)不同的操作，這些錯(cuò)誤狀態(tài)的含義不同。

(4)錯(cuò)誤索引(error-index)：當(dāng)錯(cuò)誤狀態(tài)非0時(shí)指向出錯(cuò)的變量。

(5)變量綁定表(variable-binding)：變量名和對(duì)應(yīng)值的表，說(shuō)明要檢索或設(shè)置的所有變量及其值。在檢索請(qǐng)求報(bào)文中，變量的值應(yīng)為0。

Trap報(bào)文的格式與其他報(bào)文不同，它有下列字段：

(1)制造商ID(enterprise)：表示設(shè)備制造商的標(biāo)識(shí)，與MIB-2對(duì)象sysObjectID的值相同。

(2)代理地址(agent-addr)：產(chǎn)生陷入的代理的IP地址。

(3)一般陷入(generic-trap)：SNMP定義的陷入類型，共分coldStart(0)、warmStart(1)、linkDown(2)、linkUp(3)、authenticationFailure(4)、egpNeighborLoss(5)、enterpriseSpecific(6)7類。

(4)特殊陷入(specific-trap)：與設(shè)備有關(guān)的特殊陷入代碼。

(5)時(shí)間戳(time-stamp)：代理發(fā)出陷入的時(shí)間，與MIB-2中的對(duì)象sysUpTime的值相同。

報(bào)文應(yīng)答序列SNMP報(bào)文在管理站和代理之間傳送，包含GetRequest、GetNextRequest和SetRequest的報(bào)文由管理站發(fā)出，代理以

GetResponse響應(yīng)。Trap報(bào)文由代理發(fā)給管理站，不需要應(yīng)答。所有報(bào)文的發(fā)送和應(yīng)答序列如下圖所示。一般來(lái)說(shuō)，管理站可連續(xù)發(fā)出多個(gè)請(qǐng)求報(bào)文，然后等待代理返回應(yīng)答報(bào)文。如果在規(guī)定的時(shí)間內(nèi)收到應(yīng)答，則按照請(qǐng)求標(biāo)識(shí)進(jìn)行配對(duì)，亦即應(yīng)答報(bào)文必須與請(qǐng)求報(bào)文有相同的請(qǐng)求標(biāo)識(shí)。網(wǎng)絡(luò)管理模型中的主要構(gòu)件圖

SNMP報(bào)文發(fā)送和應(yīng)答序列

報(bào)文的發(fā)送和接收一個(gè)SNMP協(xié)議實(shí)體(PE)發(fā)送報(bào)文時(shí)執(zhí)行下面的過(guò)程：首先按照ASN.1的格式構(gòu)造PDU，交給認(rèn)證進(jìn)程；認(rèn)證進(jìn)程檢查源和目標(biāo)之間是否可以通信，如果通過(guò)這個(gè)檢查則把有關(guān)信息(版本號(hào)、團(tuán)體名、PDU)組裝成報(bào)文；最后經(jīng)過(guò)BER編碼，將報(bào)文交傳輸實(shí)體發(fā)送出去，如下圖所示。圖

生成和發(fā)送SNMP報(bào)文構(gòu)造PDU（ASN.1對(duì)象）加入團(tuán)體名及源和目的傳輸?shù)刂窐?gòu)造SNMP報(bào)文檢驗(yàn)并通過(guò)認(rèn)證把ASN.1報(bào)文按BER編碼發(fā)送給對(duì)等實(shí)體當(dāng)一個(gè)SNMP協(xié)議實(shí)體(PE)接收到報(bào)文時(shí)執(zhí)行下面的過(guò)程：首先按照BER編碼恢復(fù)ASN.1報(bào)文，然后對(duì)報(bào)文進(jìn)行語(yǔ)法分析，驗(yàn)證版本號(hào)和認(rèn)證信息等。如果通過(guò)分析和驗(yàn)證，則分離出協(xié)議數(shù)據(jù)單元并進(jìn)行語(yǔ)法分析，必要時(shí)經(jīng)過(guò)適當(dāng)處理后返回應(yīng)答報(bào)文。在認(rèn)證檢驗(yàn)失敗時(shí)可以生成一個(gè)陷入報(bào)文，向發(fā)送站報(bào)告通信異常情況。無(wú)論何種檢驗(yàn)失敗，都丟棄報(bào)文。接收處理過(guò)程如下圖所示。圖

接收和處理SNMP報(bào)文按BER解碼，恢復(fù)ASN.1報(bào)文語(yǔ)法分析ASN.1報(bào)文驗(yàn)證版本號(hào)認(rèn)證檢查語(yǔ)法分析PDU處理PDU，必要時(shí)產(chǎn)生應(yīng)答丟棄報(bào)文必要時(shí)產(chǎn)生陷入出錯(cuò)正確出錯(cuò)正確正確正確正確SNMPv1的局限性用戶利用SNMP進(jìn)行網(wǎng)絡(luò)管理時(shí)一定要清楚SNMPv1本身的局限性。

●由于輪詢的性能限制，SNMP不適合管理很大的網(wǎng)絡(luò)。輪詢產(chǎn)生的大量管理信息傳送可能引起網(wǎng)絡(luò)響應(yīng)時(shí)間的增加。

●SNMP不適合檢索大量數(shù)據(jù)，例如檢索整個(gè)表中的數(shù)據(jù)。

●SNMP的陷入報(bào)文是沒(méi)有應(yīng)答的，管理站是否收到陷入報(bào)文，代理不得而知。這樣可能丟掉重要的管理信息。

●

SNMP只提供簡(jiǎn)單的團(tuán)體名認(rèn)證，這樣的安全措施是很不夠的。

●SNMP并不直接支持向被管理設(shè)備發(fā)送命令。

●SNMP的管理信息庫(kù)MIB-2支持的管理對(duì)象是很有限的，不足以完成復(fù)雜的管理功能。

●SNMP不支持管理站之間的通信，而這一點(diǎn)在分布式網(wǎng)絡(luò)管理中是很需要的。

以上局限性有很多在SNMP的第2版中都有所改進(jìn)。

2.3.3SNMPv2c

SNMPv2提供了3種訪問(wèn)管理信息的方法：

●管理站和代理之間的請(qǐng)求/響應(yīng)通信，這種方法與SNMPv1是一樣的；

●管理站和管理站之間的請(qǐng)求/響應(yīng)通信，這種方法是SNMPv2特有的，可以由一個(gè)管理站把有關(guān)管理信息告訴給另外一個(gè)管理站；

●

代理系統(tǒng)到管理站的非確認(rèn)通信，即由代理向管理站發(fā)送trap報(bào)文，報(bào)告出現(xiàn)的異常情況，SNMPv1中也有對(duì)應(yīng)的通信方式。

SNMPv2報(bào)文 SNMPv2PDU封裝在報(bào)文中傳送，報(bào)文頭提供了簡(jiǎn)單的認(rèn)證功能，而PDU可以完成上面提到的各種操作。我們首先介紹報(bào)文頭的格式和作用，然后討論協(xié)議數(shù)據(jù)單元的結(jié)構(gòu)。

SNMPv2報(bào)文的結(jié)構(gòu)分為3部分：版本號(hào)、團(tuán)體名和作為數(shù)據(jù)傳送的PDU。這個(gè)格式與SNMPv1一樣。版本號(hào)取值0代表SNMPv1，取值1代表SNMPv2。團(tuán)體名提供簡(jiǎn)單的認(rèn)證功能，與SNMPv1的用法一樣。

SNMPv2實(shí)體發(fā)送一個(gè)報(bào)文一般要經(jīng)過(guò)下面4個(gè)步驟：

(1)根據(jù)要實(shí)現(xiàn)的協(xié)議操作構(gòu)造PDU。

(2)把PDU、源和目標(biāo)端口地址以及團(tuán)體名傳送給認(rèn)證服務(wù)，認(rèn)證服務(wù)產(chǎn)生認(rèn)證碼或?qū)?shù)據(jù)進(jìn)行加密，返回結(jié)果。

(3)加入版本號(hào)和團(tuán)體名，構(gòu)造報(bào)文。

(4)進(jìn)行BER編碼，產(chǎn)生0/1比特串，發(fā)送出去。 SNMPv2實(shí)體接收到一個(gè)報(bào)文后要完成下列動(dòng)作：

(1)對(duì)報(bào)文進(jìn)行語(yǔ)法檢查，丟棄出錯(cuò)的報(bào)文。

(2)把PDU部分、源和目標(biāo)端口號(hào)交給認(rèn)證服務(wù)。如果認(rèn)證失敗，發(fā)送一個(gè)陷入，丟棄報(bào)文。

(3)如果認(rèn)證通過(guò)，則把PDU轉(zhuǎn)換成ASN.1的形式。

(4)協(xié)議實(shí)體對(duì)PDU做句法檢查，如果通過(guò)，根據(jù)團(tuán)體名和適當(dāng)?shù)脑L問(wèn)策略作相應(yīng)的處理。

SNMPv2PDUSNMPv2共有6種協(xié)議數(shù)據(jù)單元，分為3種PDU格式，見(jiàn)下圖。注意GetRequest、GetNextRequest、SetRequest、InformRequest和Trap等5種PDU與ResponsePDU具有相同的格式，只是它們的錯(cuò)誤狀態(tài)和錯(cuò)誤索引字段被置為0，這樣就減少了PDU格式的種類。圖

SNMPv2PDU格式這些協(xié)議數(shù)據(jù)單元在管理站和代理系統(tǒng)之間或者是兩個(gè)管理站之間交換，以完成需要的協(xié)議操作。它們的交換序列如下2圖所示。下面解釋管理站和代理系統(tǒng)對(duì)這些PDU的處理和應(yīng)答過(guò)程。圖1管理站和代理之間的通信圖2管理站和管理站之間的通信1.GetRequestPDU

SNMPv2對(duì)這種操作的響應(yīng)方式與SNMPv1不同，SNMPv1的響應(yīng)是原子性的，即只要有一個(gè)變量的值檢索不到，就不返回任何值。而SNMPv2的響應(yīng)不是原子性的，允許部分響應(yīng)，按照以下規(guī)則對(duì)變量綁定表中的各個(gè)變量進(jìn)行處理。

●如果該變量的對(duì)象標(biāo)識(shí)符前綴不能與這一請(qǐng)求可訪問(wèn)的任何變量的對(duì)象標(biāo)識(shí)符前綴匹配，則返回一個(gè)錯(cuò)誤值noSuchObject。

●如果變量名不能與這一請(qǐng)求可訪問(wèn)的任何變量名完全匹配，則返回一個(gè)錯(cuò)誤值noSuchInstance。這種情況可能出現(xiàn)在表訪問(wèn)中，即訪問(wèn)了不存在的行或正在生成中的表行等。

●如果不屬于以上情況，則在變量綁定表中返回被訪問(wèn)的值。

●如果由于任何其它原因而處理失敗，則返回一個(gè)錯(cuò)誤狀態(tài)genErr，對(duì)應(yīng)的錯(cuò)誤索引指向有問(wèn)題的變量。

●

如果生成的響應(yīng)PDU太大，超過(guò)了本地的或請(qǐng)求方的最大報(bào)文限制，則放棄這個(gè)PDU，構(gòu)造一個(gè)新的響應(yīng)PDU，其錯(cuò)誤狀態(tài)為tooBig，錯(cuò)誤索引為0，變量綁定表為空。

2.GetNextRequestPDU

在SNMPv2中，這種檢索請(qǐng)求的格式和語(yǔ)義與SNMPv1基本相同，惟一的差別就是改變了響應(yīng)的原子性。SNMPv2實(shí)體按照下面的規(guī)則處理GetNextPDU變量綁定表中的每一個(gè)變量，構(gòu)造響應(yīng)PDU：

●

對(duì)變量綁定表中指定的變量在MIB中查找按照詞典順序排列的后繼變量，如果找到，返回該變量(對(duì)象實(shí)例)的名字和值。

●如果找不到按照詞典順序排列的后繼變量，則返回請(qǐng)求PDU中的變量名和錯(cuò)誤值endOfMibView。

●如果出現(xiàn)其它情況使得構(gòu)造響應(yīng)PDU失敗，則以與GetRequest類似的方式返回錯(cuò)誤值。

3.GetBulkRequestPDU

這是SNMPv2對(duì)原標(biāo)準(zhǔn)的主要增強(qiáng)，目的是以最少的交換次數(shù)檢索大量的管理信息，或者說(shuō)管理站要求盡可能大的響應(yīng)報(bào)文。對(duì)這個(gè)操作的響應(yīng)，在選擇MIB變量值時(shí)采用與GetNextRequest同樣的原理，即按照詞典順序選擇后繼對(duì)象實(shí)例，但是這個(gè)操作可以說(shuō)明多種不同的后繼。

這種塊檢索操作的工作過(guò)程是這樣的：假設(shè)GetBulkRequestPDU變量綁定表中有L個(gè)變量，該P(yáng)DU的“非重復(fù)數(shù)”字段的值為N，則對(duì)前N個(gè)變量應(yīng)各返回一個(gè)詞典后繼。再設(shè)請(qǐng)求PDU的“最大后繼數(shù)”字段的值為M，則對(duì)其余的R=L-N個(gè)變量應(yīng)該各返回最多M個(gè)詞典后繼。如果可能，總共返回N+R×M個(gè)值，這些值的分布如下圖所示。如果在任何一步查找過(guò)程中遇到不存在后繼的情況，則返回錯(cuò)誤值endOfMibView。圖

GetBulkRequest檢索得到的值為了說(shuō)明塊檢索的方法，讓我們考慮一個(gè)例子。假設(shè)有下面的表：

這個(gè)表的索引由前兩個(gè)變量組成。如果管理站希望檢索這個(gè)表的值和一個(gè)標(biāo)量對(duì)象sysUpTime的值，則可以發(fā)出這樣的請(qǐng)求：

GetBulkRequest[非重復(fù)數(shù)=1，最大后繼數(shù)=2]

{sysUpTime，

ipNetToMediaPhysAddress，ipNetToMediaType}代理的響應(yīng)是 Response((sysUpTime.0="123456"),(ipNetToMediaPhysAddress..4="000010543210"),(ipNetToMediaType..4="dynamic"),(ipNetToMediaPhysAddress..51="000010012345"),(ipNetToMediaType..51="static"))

管理站又發(fā)出下一個(gè)請(qǐng)求： GetBulkRequest[非重復(fù)數(shù)=1，最大后繼數(shù)=2]{sysUpTime，ipNetToMediaPhysAddress..51,

ipNetToMediaType..51}

代理的響應(yīng)是 Response((sysUpTime.0="123466"),(ipNetToMediaPhysAddress..15="000010987654"),(ipNetToMediaType..15="dynamic"),(ipNetToMediaType..4="dynamic"),(ipRoutingDiscards.0="2"))4.SetRequestPDU

這個(gè)請(qǐng)求的格式和語(yǔ)義與SNMPv1的相同，差別是處理響應(yīng)的方式不同。SNMPv2實(shí)體分兩個(gè)階段處理這個(gè)請(qǐng)求的變量綁定表：首先是檢驗(yàn)操作的合法性，然后再更新變量。如果至少有一個(gè)變量綁定對(duì)的合法性檢驗(yàn)沒(méi)有通過(guò)，則不進(jìn)行下一階段的更新操作。因此這個(gè)操作與SNMPv1一樣，是原子性的。合法性檢驗(yàn)包括以下內(nèi)容：

●

如果有一個(gè)變量不可訪問(wèn)，則返回錯(cuò)誤狀態(tài)noAccess。

●如果與綁定表中變量共享對(duì)象標(biāo)識(shí)符的任何MIB變量都不能生成、不能修改，也不接受指定的值，則返回錯(cuò)誤狀態(tài)notWritable。

●如果要設(shè)置的值的類型不適合被訪問(wèn)的變量，則返回錯(cuò)誤狀態(tài)wrongType。

●如果要設(shè)置的值的長(zhǎng)度與變量的長(zhǎng)度限制不同，則返回錯(cuò)誤狀態(tài)wrongLength。

●如果要設(shè)置的值的ASN.1編碼不適合變量的ASN.1標(biāo)簽，則返回錯(cuò)誤狀態(tài)wrongEncoding。

●如果指定的值在任何情況下都不能賦予變量，則返回錯(cuò)誤狀態(tài)wrongValue。

●如果變量不存在，也不能生成，則返回錯(cuò)誤狀態(tài)noCreation。

●如果變量不存在，只是在當(dāng)前的情況下不能生成，則返回錯(cuò)誤狀態(tài)inconsistantName。

●如果變量存在，但不能修改，則返回錯(cuò)誤狀態(tài)notWritable。

●如果變量在其它情況下可以賦予指定的值，但當(dāng)前不行，則返回錯(cuò)誤狀態(tài)inconsistantValue。

●如果為了給變量賦值而缺乏需要的資源，則返回錯(cuò)誤狀態(tài)resourceUnavailable。

●如果由于其它原因而處理變量綁定對(duì)失敗，則返回錯(cuò)誤狀態(tài)genErr。

如果對(duì)任何變量檢查出上述任何一種錯(cuò)誤，則在響應(yīng)PDU變量綁定表中設(shè)置對(duì)應(yīng)的錯(cuò)誤狀態(tài)，錯(cuò)誤索引設(shè)置為問(wèn)題變量的序號(hào)。使用如此之多的錯(cuò)誤代碼也是SNMPv2的一大進(jìn)步，這使得管理站能了解詳細(xì)的錯(cuò)誤信息，以便采取糾正措施。

如果沒(méi)有檢查出錯(cuò)誤，就可以給所有指定變量賦予新值。若有至少一個(gè)賦值操作失敗，則所有賦值被撤消，并返回錯(cuò)誤狀態(tài)為commitFailed的PDU，錯(cuò)誤索引指向問(wèn)題變量的序號(hào)；但是若不能全部撤消所賦的值，則返回錯(cuò)誤狀態(tài)undoFailed，錯(cuò)誤索引字段置0。

5.TrapPDU

trap是由代理發(fā)給管理站的非確認(rèn)性消息。SNMPv2的trap采用與Get等操作相同的PDU格式，這一點(diǎn)也是與原標(biāo)準(zhǔn)不同的。TrapPDU的變量綁定表中應(yīng)報(bào)告下面的內(nèi)容：

●sysUpTime.0的值，即發(fā)出trap的時(shí)間。

●snmpTrapOID.0的值，這是SBNPv2MIB對(duì)象組定義的trap對(duì)象的標(biāo)識(shí)符。

●有關(guān)通知宏定義中包含的各個(gè)變量及其值。

●

代理系統(tǒng)選擇的其他變量的值。

6.InformRequestPDU這是管理站發(fā)送給管理站的消息，PDU格式與Get等操作相同，變量綁定表的內(nèi)容與陷入報(bào)文一樣。但是與陷入不同，這個(gè)消息是需要應(yīng)答的。因此，管理站收到通知請(qǐng)求后首先要決定應(yīng)答報(bào)文的大小，如果應(yīng)答報(bào)文的大小超過(guò)本地或?qū)Ψ降南拗?，則返回錯(cuò)誤狀態(tài)tooBig。如果接收的請(qǐng)求報(bào)文不是太大，則把有關(guān)信息傳送給本地的應(yīng)用實(shí)體，返回一個(gè)錯(cuò)誤狀態(tài)為noErr的響應(yīng)報(bào)文，其變量綁定表與收到的請(qǐng)求PDU相同。2.3.4SNMPv3

SNMPv3管理框架

SNMP引擎

應(yīng)用程序

基于用戶的安全模型(USM)

SNMP管理站和代理

基于視圖的訪問(wèn)控制(VACM)模型SNMPv3管理框架在RFC2571描述的管理框架中，以前叫做管理站和代理的東西現(xiàn)在統(tǒng)一叫做SNMP實(shí)體(SNMPEntity)。實(shí)體是體系結(jié)構(gòu)的一種實(shí)現(xiàn)，由一個(gè)SNMP引擎(SNMPEngine)和一個(gè)或多個(gè)有關(guān)的SNMP應(yīng)用(SNMPApplication)組成。下圖顯示了SNMP實(shí)體的組成元素。圖

SNMP實(shí)體SNMP引擎SNMP引擎提供下列服務(wù)：●發(fā)送和接收?qǐng)?bào)文；●認(rèn)證和加密報(bào)文；●

控制對(duì)管理對(duì)象的訪問(wèn)SNMP引擎有惟一的標(biāo)識(shí)snmpEngineID，這個(gè)標(biāo)識(shí)在一個(gè)上層管理域中是無(wú)二義性的。由于SNMP引擎和SNMP實(shí)體具有一一對(duì)應(yīng)的關(guān)系，因而snmpEngineID也是對(duì)應(yīng)的SNMP實(shí)體的惟一標(biāo)識(shí)。SNMP引擎具有復(fù)雜的結(jié)構(gòu)，它包含：一個(gè)調(diào)度器(Dispatcher)、一個(gè)報(bào)文處理子系統(tǒng)(MessageProcessingSubsystem)、一個(gè)安全子系統(tǒng)(SecuritySubsystem)以及一個(gè)訪問(wèn)控制子系統(tǒng)(AccessControlSubsystem)。(詳情介紹：略)

應(yīng)用程序 SNMPv3的應(yīng)用程序分為5種，如上圖SNMP應(yīng)用實(shí)體所示。

●命令生成器(CommandGenerator)：建立SNMPRead/Write請(qǐng)求，并且處理這些請(qǐng)求的響應(yīng)。

●

命令響應(yīng)器(CommandResponder)：接收SNMPRead/Write請(qǐng)求，對(duì)管理數(shù)據(jù)進(jìn)行訪問(wèn)，并按照協(xié)議規(guī)定的操作產(chǎn)生響應(yīng)報(bào)文，返回給讀/寫(xiě)命令的發(fā)送者。

●通知發(fā)送器(NotificationOriginator)：監(jiān)控系統(tǒng)中出現(xiàn)的特殊事件，產(chǎn)生通知類報(bào)文，并且要有一種機(jī)制，以決定向何處發(fā)送報(bào)文，使用什么SNMP版本和安全參數(shù)等。

●通知接收器(NotificationReceiver)：監(jiān)聽(tīng)通知報(bào)文，并對(duì)確認(rèn)型通知產(chǎn)生響應(yīng)。

●代理轉(zhuǎn)發(fā)器(ProxyForwarder)：在SNMP實(shí)體之間轉(zhuǎn)發(fā)報(bào)文。

在SNMP的歷史上使用的“proxy”一詞有多種含義，但是在RFC2573中則專指轉(zhuǎn)發(fā)SNMP報(bào)文，而不考慮報(bào)文中包含何種對(duì)象，也不處理SNMP請(qǐng)求，因此它與傳統(tǒng)的SNMP代理(agent)是不同的。

SNMP管理站和代理一個(gè)SNMP實(shí)體包含一個(gè)或多個(gè)命令生成器以及通知接收器，這種實(shí)體傳統(tǒng)上叫做SNMP管理站，如下圖所示。圖4.36管理站一個(gè)SNMP實(shí)體包含一個(gè)或多個(gè)命令響應(yīng)器以及通知發(fā)送器這種實(shí)體傳統(tǒng)上叫做SNMP代理，如下圖所示。圖代理

基于用戶的安全模型(USM) SNMPv3把對(duì)網(wǎng)絡(luò)協(xié)議的安全威脅分為主要的和次要的兩類。標(biāo)準(zhǔn)規(guī)定安全模塊必須提供防護(hù)的兩種主要威脅是：

●修改信息(ModificationofInformation)，就是某些未經(jīng)授權(quán)的實(shí)體改變了進(jìn)來(lái)的SNMP報(bào)文，企圖實(shí)施未經(jīng)授權(quán)的管理操作，或者提供虛假的管理對(duì)象。

●假冒(Masquerade)，即未經(jīng)授權(quán)的用戶冒充授權(quán)用戶的標(biāo)識(shí)，企圖實(shí)施管理操作。

標(biāo)準(zhǔn)還規(guī)定安全模塊必須對(duì)兩種次要威脅提供防護(hù)：

●修改報(bào)文流(MessageStreamModification)。由于SNMP協(xié)議通常是基于無(wú)連接的傳輸服務(wù)，因而重新排序報(bào)文流、延遲或重放報(bào)文的威脅都可能出現(xiàn)。這種威脅的危害性在于通過(guò)報(bào)文流的修改可能實(shí)施非法的管理操作?！?/p>

消息泄露(Disclosure)。SNMP引擎之間交換的信息可能被偷聽(tīng)，對(duì)這種威脅的防護(hù)應(yīng)采取局部的策略。

有兩種威脅是安全體系結(jié)構(gòu)不必防護(hù)的，因?yàn)樗鼈儾皇呛苤匾?，或者這種防護(hù)沒(méi)有多大作用：

●拒絕服務(wù)(DenialofService)。因?yàn)樵诤芏嗲闆r下拒絕服務(wù)和網(wǎng)絡(luò)失效是無(wú)法區(qū)別的，所以可以由網(wǎng)絡(luò)管理協(xié)議來(lái)處理，安全子系統(tǒng)不必采取措施。

●

通信分析(TrafficAnalysis)。通信分析是指由第三者分析管理實(shí)體之間的通信規(guī)律，從而獲取需要的信息。由于通常都是由少數(shù)管理站來(lái)管理整個(gè)網(wǎng)絡(luò)的，因而管理系統(tǒng)的通信模式是可預(yù)見(jiàn)的，防護(hù)通信分析就沒(méi)有多大作用了。

因此，RFC2574把安全協(xié)議分為以下3個(gè)模塊：

●時(shí)間序列模塊：提供對(duì)報(bào)文延遲和重放的防護(hù)；

●認(rèn)證模塊：提供完整性和數(shù)據(jù)源認(rèn)證；

●

加密模塊：防止報(bào)文內(nèi)容的泄露。（詳情描述：略）

基于視圖的訪問(wèn)控制(VACM)模型

當(dāng)一個(gè)SNMP實(shí)體處理檢索(Get、Get-next等)或修改(Set)請(qǐng)求時(shí)，都要檢查是否允許訪問(wèn)指定的管理對(duì)象，以及是否允許執(zhí)行請(qǐng)求的操作。另外，當(dāng)SNMP實(shí)體生成通知報(bào)文時(shí)，也要用到訪問(wèn)控制機(jī)制，以決定把消息發(fā)送給誰(shuí)。在VACM模型中要用到以下概念：

●

SNMP上下文(Context)：簡(jiǎn)稱上下文，是SNMP實(shí)體可以訪問(wèn)的管理信息的集合。一個(gè)管理信息可以存在于多個(gè)上下文中，而一個(gè)SNMP實(shí)體也可以訪問(wèn)多個(gè)上下文。在一個(gè)管理域中，SNMP上下文由惟一的名字contextName標(biāo)識(shí)。

●組(Group)：由二元組<securityModel,securityName>的集合構(gòu)成。屬于同一組的所有安全名securityName在指定的安全模型securityModel下的訪問(wèn)權(quán)限相同。組的名字用groupName表示。

●安全模型(SecurityModel)：表示訪問(wèn)控制中使用的安全模型。

●安全級(jí)別(SecurityLevel)：在同一組中的成員可以有不同的安全級(jí)別，即noAuthNoPriv(無(wú)認(rèn)證不保密)、authNoPriv(有認(rèn)證不保密)和authPriv(有認(rèn)證要保密)。任何一個(gè)訪問(wèn)請(qǐng)求都有相應(yīng)的安全級(jí)別。

●

操作(Operation)：指對(duì)管理信息執(zhí)行的操作，例如讀、寫(xiě)和發(fā)送通知等。

（詳情描述：略）

2.3.5SNMP網(wǎng)絡(luò)管理工作站收集數(shù)據(jù)的方法輪詢（polling）的方法中斷（Interrupt）的方法面向自陷的輪詢方法（trap-directedpolling）

輪詢?nèi)绻阒皇褂弥惠喸兊姆椒?，那么網(wǎng)絡(luò)管理工作站總是在控制之下。而這種方法的缺陷在于信息的實(shí)時(shí)性，尤其是錯(cuò)誤的實(shí)時(shí)性。路由器

網(wǎng)橋交換機(jī)服務(wù)器集線器網(wǎng)絡(luò)管理工作站SNMP輪詢收集數(shù)據(jù)

中斷基于中斷的方法可以在出現(xiàn)異常事件時(shí)，立即通知網(wǎng)絡(luò)管理工作站。但產(chǎn)生錯(cuò)誤或自陷需要系統(tǒng)資源路由器

網(wǎng)橋交換機(jī)服務(wù)器集線器網(wǎng)絡(luò)管理工作站SNMP中斷收集數(shù)據(jù)

面向自陷的輪詢網(wǎng)絡(luò)管理工作站輪詢?cè)诒还芾碓O(shè)備中的代理來(lái)收集數(shù)據(jù)，并且在控制臺(tái)上用數(shù)字或圖形的表示方式來(lái)顯示這些數(shù)據(jù)。路由器

網(wǎng)橋交換機(jī)服務(wù)器集線器網(wǎng)絡(luò)管理工作站面向自陷的輪詢方法三、管理信息結(jié)構(gòu)SMI3管理信息結(jié)構(gòu)SMI管理信息結(jié)構(gòu)SMI（structureofmanagementinformation)的主要類容有三部分，一是為MIB中定義的被管理對(duì)象分配對(duì)象標(biāo)示符空間；二是定義了宏OBJECT-TYPE，用來(lái)在MIB中定義被管理對(duì)象；三是定義了被管理對(duì)象可以使用ASN.1集合。定義和構(gòu)造MIB的通用框架，規(guī)定了可以在MIB中使用的數(shù)據(jù)類型，說(shuō)明了資源在MIB中怎樣表示和命名。

SMI是ASN.1的一個(gè)子集，使用了部分的ASN.1中的元素來(lái)定義管理對(duì)象。（管理信息是由一個(gè)個(gè)管理對(duì)象組成的）同時(shí)SMI使用了ASN.1的BER編碼規(guī)則對(duì)管理對(duì)象進(jìn)行編碼/解碼3.1管理信息的結(jié)構(gòu)從樹(shù)根開(kāi)始，第一級(jí)有3個(gè)節(jié)點(diǎn):iso、ccitt、joint-iso-ccitt。在iso節(jié)點(diǎn)下面有一個(gè)為“其他組織”使用的子樹(shù)，其中有一個(gè)美國(guó)國(guó)防部的子樹(shù)(dod)。SNMP在dod之下設(shè)置一個(gè)子樹(shù)用于Internet的管理。internetOBJECTIDENTIFIER::={iso(1)org(3)dod(6)1}

因此，internet節(jié)點(diǎn)的對(duì)象標(biāo)識(shí)符的值是。internet節(jié)點(diǎn)之下的4個(gè)節(jié)點(diǎn)：directory為與OSI的directory相關(guān)的將來(lái)的應(yīng)用保留的節(jié)點(diǎn)mgmt用于在IAB批準(zhǔn)的文檔中定義的對(duì)象experimental用于標(biāo)識(shí)在Internet實(shí)驗(yàn)中應(yīng)用的對(duì)象private用于標(biāo)識(shí)單方面定義的對(duì)象3.2管理信息的語(yǔ)法下面的ASN.1數(shù)據(jù)類型被用來(lái)定義對(duì)象類型。簡(jiǎn)單類型結(jié)構(gòu)類型自定義類型3.2.1簡(jiǎn)單類型類型值集合INTEGER整數(shù)類型，其值集合為正數(shù)、負(fù)數(shù)和零..(使用枚舉類型整數(shù)時(shí)，禁止使用整數(shù)0)OCTETSTRING零個(gè)或者多個(gè)字節(jié)（byte）構(gòu)成的序列,每一個(gè)字節(jié)值在0~255之間OBJECTIDENTIFIER對(duì)象標(biāo)識(shí)符，有一列整數(shù)構(gòu)成，用于確定對(duì)象.NULL空值3.2.2結(jié)構(gòu)類型SEQUENCE被用來(lái)定義行（SEQUENCE定義的序列類型中，不能有DEFAULT和OPTIONAL選項(xiàng)）SEQUENCEOF被用來(lái)定義表（這是一個(gè)向量的定義，其所有元素具有相同的類型。如果每一個(gè)元素都具有簡(jiǎn)單的數(shù)據(jù)類型，例如是整數(shù)類型，那么我們就得到一個(gè)簡(jiǎn)單的向量（一個(gè)一維向量）。但是我們將看到，SNMP在使用這個(gè)數(shù)據(jù)類型時(shí)，其向量中的每一個(gè)元素是一個(gè)SEQUENCE（結(jié)構(gòu)）。因而可以將它看成為一個(gè)二維數(shù)組或表。）3.2.3SMI自定義類型類型值集合NetworkAddress用CHOICE結(jié)構(gòu)定義，允許從多個(gè)協(xié)議地址格式中選擇。目前只定義了IpAddress一種地址格式。IpAddress32位的IPv4地址格式PhysAddress48位的MAC地址格式Counter只能做增值不能做減值運(yùn)算的非負(fù)整數(shù)。最大值被設(shè)為232–1，當(dāng)達(dá)到最大值時(shí)，再次從0開(kāi)始增加。Gauge可做增值也可做減值運(yùn)算的非負(fù)整數(shù)。最大值被設(shè)為232–1，當(dāng)達(dá)到最大值時(shí)被鎖定，直至被復(fù)位(reset)。TimeTicks時(shí)間計(jì)數(shù)器，記錄從一時(shí)間點(diǎn)起經(jīng)過(guò)的百分之一秒的數(shù)量DisplayString可顯示打印的字符串類型，方便閱讀.Opaque提供一個(gè)傳遞任意數(shù)據(jù)的能力。數(shù)據(jù)在傳輸時(shí)被作為OCTETSTRING編碼。被傳遞的數(shù)據(jù)本身可以是由ASN.1或其他句法定義的任意的格式。3.3管理信息的定義管理信息以管理對(duì)象為單位，被管理對(duì)象在MIB中定義，以樹(shù)狀結(jié)構(gòu)為組織方式，其中每一個(gè)管理對(duì)象需要定義的信息基本相同，即都需要定義如下信息：對(duì)象標(biāo)識(shí)符：管理對(duì)象的對(duì)象標(biāo)識(shí)符數(shù)據(jù)類型：管理對(duì)象的數(shù)據(jù)類型取值范圍：管理對(duì)象的取值是否存在限制條件訪問(wèn)控制：允許對(duì)管理對(duì)象采取哪些操作權(quán)限描述信息：管理對(duì)象的說(shuō)明性文字信息SMI以及MIB定義在一個(gè)模塊中，而MIB中的每一個(gè)管理對(duì)象則使用了宏定義的方式管理信息結(jié)構(gòu)舉例

OBJECT-TYPEMACRO::=BEGINTYPENOTATION::=--mustconformtoRFC1155'sObjectSyntax"SYNTAX"type(ObjectSyntax)"ACCESS"Access"STATUS"Status

DescrPart --描述

ReferPart --引用

IndexPart --索引

DefValPart --缺省值

VALUENOTATION::=value(VALUEObjectName)Access::="read-only" --缺省值

|"read-write"|"write-only"|"not-accessible"Status::="mandatory" --缺省值

|"optional"|"obsolete"|"deprecated"

DescrPart::= --描述對(duì)象的意義，使用范圍等相關(guān)信息

"DESCRIPTION"value(descriptionDisplayString)|empty

ReferPart::= --引用描述

"REFERENCE"value(referenceDisplayString)|empty

IndexPart::= --當(dāng)對(duì)象類型是entry時(shí)，為表指定索引

"INDEX""{"IndexTypes"}"|empty

IndexTypes::=

IndexType|IndexTypes","IndexType

IndexType::=--ifindexobject,usetheSYNTAX--valueofthecorrespondent--OBJECT-TYPEinvocationvalue(indexobject

ObjectName)--otherwiseusenamedSMItype--mustconformtoIndexSyntaxbelow|type(indextype)

DefValPart::= --允許為對(duì)象提供缺省值

"DEFVAL""{"value(defvalue

ObjectSyntax)"}"|emptyENDatIfIndexOBJECT-TYPESYNTAXINTEGERACCESSread-writeSTATUSdeprecatedDESCRIPTION"Theinterfaceonwhichthisentry'sequivalenceiseffective.TheinterfaceidentifiedbyaparticularvalueofthisindexisthesameinterfaceasidentifiedbythesamevalueofifIndex."::={atEntry1}3.4管理對(duì)象管理對(duì)象通過(guò)管理對(duì)象宏定義，管理對(duì)象是數(shù)據(jù)的類型，而管理對(duì)象宏是數(shù)據(jù)類型的類型。管理對(duì)象存在兩種：標(biāo)量對(duì)象和表對(duì)象（二維數(shù)組）管理對(duì)象是通過(guò)管理對(duì)象宏定義的管理信息，是一種數(shù)據(jù)類型。而對(duì)象實(shí)例是一個(gè)管理對(duì)象類型的實(shí)例，實(shí)例具有具體的取值標(biāo)量對(duì)象一個(gè)標(biāo)量對(duì)象具有唯一的對(duì)象實(shí)例（對(duì)標(biāo)量對(duì)象的實(shí)例，是通過(guò)在其對(duì)象標(biāo)示符后面添加“.0”。）概念表一個(gè)概念表具有多個(gè)列對(duì)象的實(shí)例（對(duì)列對(duì)象的實(shí)例，則由列對(duì)象標(biāo)示符和索引對(duì)象（索引可能不只一個(gè)）組合表示。如果定義了多哥索引對(duì)象，則依次用“.”連接所有索引值。值順序與索引對(duì)象在行對(duì)象定義中的INDEX部分出現(xiàn)的順序相同。）管理對(duì)象的實(shí)例整數(shù)類型：該列對(duì)象的OID和對(duì)象實(shí)例所在行的索引對(duì)象實(shí)例值，用“.”連接起來(lái)。定長(zhǎng)字節(jié)串（n個(gè)字符）：該列對(duì)象的OID后面依次用“.”連接n個(gè)字節(jié)的值。字節(jié)串的轉(zhuǎn)換成十進(jìn)制。變長(zhǎng)的字節(jié)串：該列對(duì)象的OID后面用“.”連接一個(gè)整數(shù)，該整數(shù)是指明字節(jié)串的字節(jié)個(gè)數(shù)，后面再依次用“.”連接每個(gè)字節(jié)的值（十進(jìn)制）。IP地址：該列對(duì)象的OID后面依次用“.”連接IP地址的四個(gè)部分。網(wǎng)絡(luò)地址：該列對(duì)象的OID后面用“.”連接“1”，指明后面的地址為IP地址，后面依次用“.”連接IP地址的四個(gè)部分。對(duì)象標(biāo)示符：該列對(duì)象的OID后面用“.”連接一個(gè)整數(shù)，該整數(shù)指明對(duì)象標(biāo)示符中子標(biāo)示符的個(gè)數(shù)，后面依次用“.”連接每個(gè)子標(biāo)示符。概念表的實(shí)例ID規(guī)則（下列規(guī)則都是爭(zhēng)對(duì)索引）IP型：ipRouteTable是ip組中的一個(gè)表。該表索引是ipRouteDest，取值是路由的IP，如果一臺(tái)機(jī)器有如下路由：，則路由表應(yīng)該有至少３條路由記錄，即：，，，則ipRouteTable表應(yīng)該有３個(gè)實(shí)例舉例：以索引類型為IP型對(duì)象名對(duì)象標(biāo)識(shí)符OID實(shí)例標(biāo)識(shí)符ipRouteDest.1.1.1..0.0.0ipRouteIfIndex.1.1.2..0.0.0ipRouteMetric..0.0.0ipRouteMetric..0.0.0ipRouteMetric..0.0.0ipRouteMetric..0.0.0ipRouteType.1.1.7..0.0.0…默認(rèn)路由對(duì)象名對(duì)象標(biāo)識(shí)符OID實(shí)例標(biāo)識(shí)符ipRouteDest.1.1.1.ipRouteIfIndex.1.1.2.ipRouteMetric.ipRouteMetric.ipRouteMetric.ipRouteMetric.ipRouteType.1.1.7.…環(huán)回路由對(duì)象名對(duì)象標(biāo)識(shí)符OID實(shí)例標(biāo)識(shí)符ipRouteDest.1.1.1.ipRouteIfIndex.1.1.2.ipRouteMetric.ipRouteMetric.ipRouteMetric.ipRouteMetric.ipRouteType.1.1.7.…外網(wǎng)路由四、管理信息庫(kù)MIB4管理信息庫(kù)MIBSMI解決了管理信息的數(shù)據(jù)類型表示、命名標(biāo)識(shí)和編碼問(wèn)題。而MIB則是遵循SMI制定的規(guī)則，按照一定的組織來(lái)定義被管理的文檔。最早的MIB是RFC1156，也稱為MIB-I。RFC1213，也就是MIB-II,使用了RFC1212中定義的OBJECT-TYPE宏，并在MIB-I的基礎(chǔ)上修訂完成了MIB-II。MIB-II被稱為標(biāo)準(zhǔn)的MIB，所有支持SNMP的設(shè)備都必須實(shí)現(xiàn)MIB-II。4.1MIB定義定義：MIB是一個(gè)ASN.1模塊，是一個(gè)ASN.1數(shù)據(jù)類型定義或值定義的集合。也可以說(shuō)（MIB是一個(gè)主要用來(lái)定義被管理對(duì)象的ASN.1模塊，這是因?yàn)镸IB文檔90%以上的內(nèi)容是定義被管理對(duì)象。）4.2MIB結(jié)構(gòu)SNMP環(huán)境中的所有管理對(duì)象組織成分層的樹(shù)結(jié)構(gòu)，如圖4.1和圖4.2所示。這種層次樹(shù)結(jié)構(gòu)有以下3種作用。圖4.1注冊(cè)層次

圖4.2MIB-2的分組結(jié)構(gòu)

1)表示管理和控制關(guān)系

從圖4.1可看出，上層的中間結(jié)點(diǎn)是某些組織機(jī)構(gòu)的名字，說(shuō)明這些機(jī)構(gòu)負(fù)責(zé)它下面的子樹(shù)信息的管理和審批。有些中間結(jié)點(diǎn)雖然不是組織機(jī)構(gòu)名，但已委托給某個(gè)組織機(jī)構(gòu)代管，例如org(3)由ISO代管，而internet(1)由IAB代管等。樹(shù)根沒(méi)有名字，默認(rèn)為抽象語(yǔ)法表示ASN.1。

2)提供了結(jié)構(gòu)化的信息組織技術(shù)

從圖4.2可看出，下層的中間結(jié)點(diǎn)代表的子樹(shù)是與每個(gè)網(wǎng)絡(luò)資源或網(wǎng)絡(luò)協(xié)議相關(guān)的信息集合。例如，有關(guān)IP協(xié)議的管理信息都放置在ip(4)子樹(shù)中。這樣，沿著樹(shù)層次訪問(wèn)相關(guān)信息就很方便了。

3)提供了對(duì)象命名機(jī)制

樹(shù)中每個(gè)結(jié)點(diǎn)都有一個(gè)分層的編號(hào)。葉子結(jié)點(diǎn)代表實(shí)際的管理對(duì)象。從樹(shù)根到樹(shù)葉的編號(hào)串聯(lián)起來(lái)，用圓點(diǎn)隔開(kāi)，就形成了管理對(duì)象的全局標(biāo)識(shí)。例如internet的標(biāo)識(shí)符是,或者寫(xiě)為{iso(1)org(3)dod(6)1}。

internet下面的4個(gè)結(jié)點(diǎn)需要解釋。directory(1)是為OSI的目錄服務(wù)(X.500)使用的；mgmt(2)包括由IAB批準(zhǔn)的所有管理對(duì)象，而mib-2是mgmt(2)的第一個(gè)孩子結(jié)點(diǎn)；experimental(3)子樹(shù)用來(lái)標(biāo)識(shí)在互聯(lián)網(wǎng)上實(shí)驗(yàn)的所有管理對(duì)象；private(4)子樹(shù)是為私人企業(yè)管理信息準(zhǔn)備的，目前這個(gè)子樹(shù)只有一個(gè)孩子結(jié)點(diǎn)enterprises(1)。如果一個(gè)私人企業(yè)(例如ABC公司)向Internet編碼機(jī)構(gòu)申請(qǐng)注冊(cè)并得到一個(gè)代碼100，該公司為它的令牌環(huán)適配器賦予代碼25，則令牌環(huán)適配器的對(duì)象標(biāo)識(shí)符就是.5。把internet結(jié)點(diǎn)劃分為4個(gè)子樹(shù)，為SNMP的實(shí)驗(yàn)和改進(jìn)提供了非常靈活的管理機(jī)制。4.3MIB-II

通過(guò)MIB-II就可以完成基本的網(wǎng)絡(luò)管理功能。閱讀一個(gè)MIB，需要重點(diǎn)關(guān)注如下問(wèn)題： 1、它是描述哪方面網(wǎng)絡(luò)技術(shù)信息的？ 2、這個(gè)MIB是標(biāo)準(zhǔn)的還是私有的？ 3、是遵循SMIv1還是SMIv2? 4、它從哪些模塊引用了哪些類型？ 5、是否定義了文本約定？ 6、是否定義了trap? 7、被管理對(duì)象是如何組織的？即被管理對(duì)象分了哪幾個(gè)組。 8、組中是否定義了表？如是，表的索引是什么？ 9、在OID樹(shù)中所處的子樹(shù)的位置？4.3.1系統(tǒng)組系統(tǒng)組(SystemGroup)提供了系統(tǒng)的一般信息，如圖4.3和表4.1所示。系統(tǒng)服務(wù)對(duì)象sysServices是7位二進(jìn)制數(shù)，每一位對(duì)應(yīng)OSI/RM7層協(xié)議中的一層。如果系統(tǒng)提供某一層服務(wù)，則對(duì)應(yīng)的位為1，否則為0。例如系統(tǒng)提供應(yīng)用層和傳輸層服務(wù)，則該系統(tǒng)的sysServices對(duì)象具有值1001000=7210。系統(tǒng)啟動(dòng)時(shí)間sysUpTime有多種使用用法。例如，管理站周期地查詢某個(gè)計(jì)數(shù)器的值，同時(shí)也查詢系統(tǒng)啟動(dòng)時(shí)間的值，這樣，管理站就可以知道該計(jì)數(shù)器在多長(zhǎng)時(shí)間內(nèi)變化了多少值。另外在故障管理中，管理站可以周期地查詢這個(gè)值，如果發(fā)現(xiàn)當(dāng)前得到的值比最近一次得到的值小，則可推斷出系統(tǒng)已經(jīng)重啟動(dòng)過(guò)了。圖4.3MIB-2系統(tǒng)組對(duì)象語(yǔ)法訪問(wèn)方式功能描述用途sysDescr(1)DisplayString(SIZE(0..255))RO有關(guān)硬件和操作系統(tǒng)的描述配置管理sysObjectID(2)OBJECTIDENTIFIERRO系統(tǒng)制造商標(biāo)識(shí)故障管理sysUpTime(3)TimeticksRO系統(tǒng)運(yùn)行時(shí)間故障管理sysContact(4)DisplayString(SIZE(0..255))RW系統(tǒng)管理人員描述配置管理sysName(5)DisplayString(SIZE(0..255))RW系統(tǒng)名配置管理sysLocation(6)DisplayString(SIZE(0..255))RW系統(tǒng)的物理位置配置管理sysServices(7)INTEGER(0..127)RO系統(tǒng)服務(wù)故障管理表4.1系

統(tǒng)

組

對(duì)

象

4.3.2接口組

接口組(InterfaceGroup)包含關(guān)于主機(jī)接口的配置信息和統(tǒng)計(jì)信息，如圖4.4和表4.2所示。這個(gè)功能組是必須實(shí)現(xiàn)的。

接口組中的變量ifNumber是指網(wǎng)絡(luò)接口數(shù)。另外還有一個(gè)表對(duì)象ifTable，每個(gè)接口對(duì)應(yīng)一個(gè)表項(xiàng)。該表的索引是ifIndex，取值為1到ifNumber之間的數(shù)。ifType是指接口的類型，每種接口都有一個(gè)標(biāo)準(zhǔn)編碼。表4.3是幾種常用接口的類型和編碼。

圖4.4MIB-2接口組

表4.2接口組對(duì)象續(xù)表

表4.3幾種常用接口的類型和編碼

本組有兩個(gè)關(guān)于接口狀態(tài)的對(duì)象：ifAdminStatus表示操作員說(shuō)明的管理狀態(tài)，而ifOperStatus表示接口的實(shí)際工作狀態(tài)。這兩個(gè)變量狀態(tài)組合的含義如表4.4所示。表4.4接

口

狀

態(tài)

對(duì)象ifSpeed是一個(gè)只讀的計(jì)量器，表示接口的比特速率。例如ifSpeed取值10000000，表示10Mb/s。有些接口速率可根據(jù)參數(shù)變化，ifSpeed的值反映了接口當(dāng)前的數(shù)據(jù)速率。

接口組中的對(duì)象可用于故障管理和性能管理。例如可以通過(guò)檢查進(jìn)出接口的字節(jié)數(shù)或隊(duì)列長(zhǎng)度檢測(cè)擁擠；可以通過(guò)接口狀態(tài)獲知工作情況；還可以統(tǒng)計(jì)出輸入/輸出的錯(cuò)誤率，即

輸入錯(cuò)誤率=ifInErrors/(ifInUcastPkts+ifInNUcastPkts)

輸出錯(cuò)誤率=ifOutErrors/(ifOutUcastPkts+ifOutNUcastPkts)

最后，該組可以提供接口發(fā)送的字節(jié)數(shù)和分組數(shù)，這些數(shù)據(jù)可作為記賬的依據(jù)。

4.3.3地址轉(zhuǎn)換組

地址轉(zhuǎn)換組(AddressTranslationGroup)包含一個(gè)表(見(jiàn)圖4.5)，該表的一行對(duì)應(yīng)系統(tǒng)的一個(gè)物理接口，表示網(wǎng)絡(luò)地址到接口的物理地址的映像關(guān)系。MIB-2中地址轉(zhuǎn)換組的對(duì)象已被收編到各個(gè)網(wǎng)絡(luò)協(xié)議組中，保留地址轉(zhuǎn)換組僅僅是為了與MIB-1兼容。這種改變的理由有兩點(diǎn)：

(1)為了支持多協(xié)議結(jié)點(diǎn)。當(dāng)一個(gè)結(jié)點(diǎn)支持多個(gè)網(wǎng)絡(luò)層協(xié)議(例如IP和IPX)時(shí)，多個(gè)網(wǎng)絡(luò)地址可能對(duì)應(yīng)一個(gè)物理地址，而該組只能把一個(gè)網(wǎng)絡(luò)地址映像到一個(gè)物理地址。

(2)為了表示雙向映像關(guān)系。地址轉(zhuǎn)換表只允許從網(wǎng)絡(luò)地址到物理地址的映像，然而有些路由協(xié)議卻要從物理地址到網(wǎng)絡(luò)地址的映像。

圖4.5MIB-2地址轉(zhuǎn)換組

4.3.4IP組 IP組提供了與IP協(xié)議有關(guān)的信息。由于端系統(tǒng)(主機(jī))和中間系統(tǒng)(路由器)都實(shí)現(xiàn)IP協(xié)議，而這兩種系統(tǒng)中包含的IP對(duì)象又不完全相同，因而有些對(duì)象是任選的，這取決于是否與系統(tǒng)有關(guān)。

IP組包含的對(duì)象如圖4.6和表4.5所示。這些對(duì)象可分為4大類，包括有關(guān)性能和故障監(jiān)控的標(biāo)量對(duì)象以及3個(gè)表對(duì)象。下面分別講述這些對(duì)象的語(yǔ)義和作用。

圖4.6MIB-2IP組

圖4.6MIB-2IP組

圖4.6MIB-2IP組

圖4.6MIB-2IP組

表4.5IP組

對(duì)

象

表4.5IP組

對(duì)

象

IP地址表(ipAddrTable)包含與本地IP地址有關(guān)的信息。每一行對(duì)應(yīng)一個(gè)IP地址，由ipAddrEntIfIndex作為索引項(xiàng)，其值與接口表的ifIndex一致。這反映了一個(gè)IP地址對(duì)應(yīng)一個(gè)網(wǎng)絡(luò)接口這一事實(shí)。在配置管理中，可以利用這個(gè)表中的信息檢查網(wǎng)絡(luò)接口的配置情況。該表中的對(duì)象屬性都是只讀的，因此SNMP不能改變主機(jī)的IP地址。

IP路由表(ipRouteTable)包含關(guān)于轉(zhuǎn)發(fā)路由的一般信息。表中的一行對(duì)應(yīng)于一個(gè)已知的路由，由目標(biāo)IP地址ipRouteDest索引。對(duì)于每一個(gè)路由，通向下一結(jié)點(diǎn)的本地接口由ipRouteIfIndex表示，其值與接口表中的ifIndex一致。每個(gè)路由對(duì)應(yīng)的路由協(xié)議由變量ipRouteProto指明，其值可能是：

●other(1)；●local(2)；●netmgmt(3)；●icmp(4)；●egp(5)；●ggp(6)；●hello(7)；●rip(8)；●is-is(9)；●es-is(10)；●ciscoIgrp(11)；●bbnSpfIgp(12)；●ospf(13)；●

bgp(14)。

其中有些是制造商專用的協(xié)議，例如ciscoIgrp(CISCO專用)。如果路由是人工配置的，則ipRouteProto表示為local。

路由表中的信息可用于配置管理。因?yàn)檫@個(gè)表中的對(duì)象是可讀寫(xiě)的，所以可以用SNMP設(shè)置路由信息。這個(gè)表也可以用于故障管理。如果用戶不能與遠(yuǎn)程主機(jī)建立連接，可檢查路由表中的信息是否有錯(cuò)。

IP地址轉(zhuǎn)換表(ipNetToMediaTable)提供了物理地址和IP地址的對(duì)應(yīng)關(guān)系。每個(gè)接口對(duì)應(yīng)表中的一項(xiàng)。這個(gè)表與地址轉(zhuǎn)換組語(yǔ)義相同。

圖4.7IP轉(zhuǎn)發(fā)表

另外，RFC1354(1992年7月)提出了代替IP路由表的新標(biāo)準(zhǔn)，叫做IP轉(zhuǎn)發(fā)表。原來(lái)的MIB-2中的IP路由表只由一項(xiàng)ipRouteDest索引，因此對(duì)一個(gè)目標(biāo)只能定義一個(gè)路由。RFC1354定義的轉(zhuǎn)發(fā)表可以表示多路由的路由表，如圖4.7所示。ipForward中的ipForwardNumber是一個(gè)只讀的計(jì)量器，它記錄IP轉(zhuǎn)發(fā)表的項(xiàng)數(shù)。ipForwardTable的大部分對(duì)象與ipRouteTable的對(duì)象對(duì)應(yīng)，有相同的語(yǔ)法和語(yǔ)義。增加的對(duì)象是：

●

ipForwardPolicy：表示路由選擇策略。在IP網(wǎng)絡(luò)中，路由策略是基于IP協(xié)議的服務(wù)類型，共有8個(gè)優(yōu)先級(jí)和高低不同的延遲、吞吐率和可靠性。

●ipForwardNextHopAS：下一個(gè)自治系統(tǒng)的地址。

如圖4.7所示，IP轉(zhuǎn)發(fā)表由4個(gè)入口索引，因此對(duì)同一目標(biāo)地址可根據(jù)不同的路由協(xié)議、不同的轉(zhuǎn)發(fā)策略發(fā)送到不同的下一結(jié)點(diǎn)去。

4.3.5ICMP組ICMP是IP的伴隨協(xié)議。所有實(shí)現(xiàn)IP協(xié)議的結(jié)點(diǎn)都必須實(shí)現(xiàn)ICMP協(xié)議。ICMP組包含ICMP實(shí)現(xiàn)和操作的有關(guān)信息，如圖4.8和表4.6所示?？梢钥闯?，這一組是有關(guān)各種接收的或發(fā)送的ICMP報(bào)文的計(jì)數(shù)器。圖4.8ICMP組

表4.6ICMP組

對(duì)

象

續(xù)表

4.3.6TCP組 TCP組包含與TCP協(xié)議的實(shí)現(xiàn)和操作有關(guān)的信息(見(jiàn)圖4.9和表4.7)。這一組的前3項(xiàng)與重傳有關(guān)。一個(gè)TCP實(shí)體發(fā)送數(shù)據(jù)段后就等待應(yīng)答并開(kāi)始計(jì)時(shí)。如果超時(shí)后沒(méi)有得到應(yīng)答，就認(rèn)為數(shù)據(jù)段丟失了，因此要重新發(fā)送。該組對(duì)象tcpRtoAlgorithem說(shuō)明計(jì)算重傳時(shí)間的算法，其值可取

●other(1)：不屬于以下3種類型的其他算法；

●

constant(2)：重傳超時(shí)值為常數(shù)；

●rsre(3)：這種算法根據(jù)通信情況動(dòng)態(tài)地計(jì)算超時(shí)值，即把估計(jì)的周轉(zhuǎn)時(shí)間(來(lái)回傳送一周的時(shí)間)乘一個(gè)倍數(shù)。這種算法是美國(guó)軍用TCP標(biāo)準(zhǔn)MIL-STD-1778定義的。

●vanj(4)：這是由VanJacobson發(fā)明的一種動(dòng)態(tài)算法。這種算法在網(wǎng)絡(luò)周轉(zhuǎn)時(shí)間變化較大時(shí)比前一種算法好。

TCP組只包含一個(gè)連接表。TCP的連接狀態(tài)取自MIL-STD-1778標(biāo)準(zhǔn)的TCP連接狀態(tài)圖。變量tcpConnState可取下列值：

●closed(1)；●listen(2)；●synSent(3)；●synReceived(4)；●established(5)；●finWait1(6)；●finWait2(7)；●closeWait(8)；●lastAck(9)；●closing(10)；●timeWait(11)；●

deleteTCB(12)。

圖4.9TCP組

表4.7TCP組

對(duì)

象

4.3.7UDP組UDP組類似于TCP組，它包含的對(duì)象都是必要的。這一組提供了關(guān)于UDP數(shù)據(jù)報(bào)和本地接收端點(diǎn)的詳細(xì)信息。UDP組對(duì)象表示在圖4.10中。UDP表相當(dāng)簡(jiǎn)單，只有本地地址和本地端口兩項(xiàng)。圖4.10UDP組

4.3.8EGP組EGP組(見(jiàn)圖4.11)提供了關(guān)于EGP路由器發(fā)送和接收的EGP報(bào)文的信息，以及關(guān)于EGP鄰居的詳細(xì)信息等。在EGP鄰居表中，鄰居狀態(tài)egpNeighState可取的值有：圖4.11EGP組

●idel(1)；●acquisition(2)；●down(3)；●up(4)；●cease(5)。輪詢模式egpNeighMode可取的值有active(1)和passive(2)兩種。

4.3.9傳輸組(TransmissionGroup)設(shè)置這一組的目的是針對(duì)各種傳輸介質(zhì)提供詳細(xì)的管理信息。事實(shí)上這不是一個(gè)組，而是一個(gè)聯(lián)系各種接口專用信息的特殊結(jié)點(diǎn)。前面介紹過(guò)的接口組包含各種接口通用的信息，而傳輸組則提供與子網(wǎng)類型有關(guān)的專用信息。下面介紹一個(gè)傳輸組的例子。RFC1643在傳輸結(jié)點(diǎn)下定義了以太網(wǎng)接口的有關(guān)對(duì)象，并且已經(jīng)成為正式的Internet標(biāo)準(zhǔn)。圖4.12和表4.8列出了以太網(wǎng)MIB的有關(guān)對(duì)象。在統(tǒng)計(jì)表中記錄以太網(wǎng)通信的統(tǒng)計(jì)信息，這個(gè)表以dot3StatsIndex為索引項(xiàng)，其值與接口組的ifIndex相同，因此對(duì)應(yīng)每個(gè)接口有一個(gè)統(tǒng)計(jì)表項(xiàng)。表中的一組計(jì)數(shù)器記錄以太網(wǎng)接口接收和發(fā)送的各種幀數(shù)，包括正確的和錯(cuò)誤的幀。沖突次數(shù)統(tǒng)計(jì)表可用于畫(huà)有關(guān)各種沖突的直方圖。圖4.13給出了一個(gè)例子，可以看出426個(gè)幀經(jīng)一次沖突而發(fā)送成功，318個(gè)幀經(jīng)兩次沖突而發(fā)送成功，等等。dot3MIB的最后一部分是關(guān)于以太網(wǎng)接口測(cè)試的信息。目前定義了兩種測(cè)試和兩種錯(cuò)誤。當(dāng)管理站訪問(wèn)代理中的測(cè)試對(duì)象時(shí)，代理就完成對(duì)應(yīng)的測(cè)試。圖4.12以太網(wǎng)MIB表4.8以太網(wǎng)MIB對(duì)象

表4.8以太網(wǎng)MIB對(duì)象

圖4.13dot3沖突統(tǒng)計(jì)表的直方圖

4.3.10SNMP組 SNMP組定義了29個(gè)標(biāo)量對(duì)象，描述了SNMP自身的一些信息。例如，發(fā)送、接收的各種SNMP消息，各種異常消息，等等。所有實(shí)現(xiàn)SNMP的設(shè)備，必須實(shí)現(xiàn)該組。

這些標(biāo)量對(duì)象，有的是描述代理有關(guān)信息的，有些是描述管理工作站有關(guān)信息的。當(dāng)設(shè)備不僅僅作為管理工作或代理時(shí)，某些被管理對(duì)象實(shí)例可以設(shè)置為0值。但往往會(huì)由設(shè)備即是網(wǎng)管工作站，同時(shí)也是代理的。

圖4.14為SNMP組在MIB中的位置。圖4.14SNMP組MIB五、抽象語(yǔ)法標(biāo)記ASN.15抽象語(yǔ)法標(biāo)記ASN.1抽象語(yǔ)法標(biāo)記（ASN.1）是一種數(shù)據(jù)對(duì)象描述標(biāo)準(zhǔn)，包括數(shù)據(jù)描述語(yǔ)言（CCITTX.208）和數(shù)據(jù)