網(wǎng)管技術(shù)第4章

第4章簡單網(wǎng)絡(luò)管理協(xié)議與管理系統(tǒng)實現(xiàn)4.1SNMP的演變

4.2SNMPvX協(xié)議數(shù)據(jù)單元

4.3SNMPvX的操作

4.4SNMP功能組

4.5實現(xiàn)問題

習(xí)題

4.1SNMP的演變

4.1.1SNMPv1TCP/IP網(wǎng)絡(luò)管理最初使用的是1987年11月提出的簡單網(wǎng)關(guān)監(jiān)控協(xié)議(SimpleGatewayMonitoringProtocol，SGMP)，在此基礎(chǔ)上改進(jìn)成簡單網(wǎng)絡(luò)管理協(xié)議第一版(SimpleNetworkManagementProtocol，SNMPv1)，陸續(xù)公布在1990年和1991年的幾個RFC(RequestForComments)文檔中，即RFC1155(SMI)、RFC1157(SNMP)、RFC1212(MIB定義)和RFC1213(MIB-2規(guī)范)。前面ASN.1描述的SNMP協(xié)議的格式在哪？當(dāng)初提出SNMP的目的是將其作為彌補(bǔ)網(wǎng)絡(luò)管理協(xié)議發(fā)展階段之間空缺的一種臨時性措施。SNMP出現(xiàn)后顯示了許多優(yōu)點，最主要的的優(yōu)點是簡單，容易實現(xiàn)，而且基于人們熟悉的SGMP(SimpleGatewayMonitoringProtocol)協(xié)議，已有相當(dāng)多的操作經(jīng)驗。因此在1988年，為了適應(yīng)當(dāng)時緊迫的網(wǎng)絡(luò)管理需要，確定了網(wǎng)絡(luò)管理標(biāo)準(zhǔn)開發(fā)的雙軌制策略。

4.1.2SNMPv2有人又提出了另外一個協(xié)議SMP(SimpleManagementProtocol)，這個協(xié)議由8個文件組成，它對SNMP的擴(kuò)充表現(xiàn)在以下4個方面：●適用范圍●

復(fù)雜程度、速度和效率●安全設(shè)施：結(jié)合了S-SNMP提供的安全功能。●兼容性：可以運行在TCP/IP網(wǎng)絡(luò)上，也適合OSI系統(tǒng)和運行其他通信協(xié)議的網(wǎng)絡(luò)。擴(kuò)展SNMP的功能并增強(qiáng)其安全設(shè)施，使用戶和制造商盡快地從原來的SNMP過渡到第二代SNMP。以SMP為基礎(chǔ)開發(fā)SNMP第2版，即SNMPv2。

4.1.3SNMPv3由于SNMPv2沒有達(dá)到“商業(yè)級別”的安全要求，因而SNMPv3工作組一直在從事新標(biāo)準(zhǔn)的研制工作，終于在1999年4月發(fā)布了SNMPv3新標(biāo)準(zhǔn)。SNMPv3工作組的目標(biāo)是：產(chǎn)生一組必要的文檔，作為下一代SNMP核心功能的單一標(biāo)準(zhǔn)。要求盡量使用已有的文檔，使新標(biāo)準(zhǔn)：

●能夠適應(yīng)不同管理需求的各種操作環(huán)境；●便于已有的系統(tǒng)向SNMPv3過渡；●

可以方便地建立和維護(hù)管理系統(tǒng)。

4.2SNMPv1協(xié)議數(shù)據(jù)單元

4.2.1SNMPv1支持的操作定義哪些操作？定義那幾個PDU?每個PDU中包含哪些字段內(nèi)容？操作的方向是怎樣的？get-request操作：從代理進(jìn)程處提取一個或多個參數(shù)值get-next-request操作：從代理進(jìn)程處提取緊跟當(dāng)前參數(shù)值的下一個參數(shù)值set-request操作：設(shè)置代理進(jìn)程的一個或多個參數(shù)值get-response操作：返回的一個或多個參數(shù)值。這個操作是由代理進(jìn)程發(fā)出的，它是前面三種操作的響應(yīng)操作。trap操作：代理進(jìn)程主動發(fā)出的報文，通知管理進(jìn)程有某些事情發(fā)生。圖4.0描述了SNMP的這5種報文操作。在代理進(jìn)程端是用熟知端口161接收get、getnext、set報文，而在管理進(jìn)程端是用熟知端口162來接收trap報文。注意箭頭方向?端口？圖4.04.2.2SNMPPDU格式各字段的含義？不同PDU之間有什么區(qū)別？

RFC1157給出了SNMPv1協(xié)議的定義，這個定義是用ASN.1表示的。根據(jù)這個定義我們可以畫出如圖4.1所示的圖4.1SNMP報文格式

？設(shè)計這些字段的目的是什么？（1）公共SNMP首部（共三個字段）：版本

對于SNMP（即SNMPV1）則應(yīng)寫入0。

共同體（community）（團(tuán)體名）作用？

共同體就是一個字符串，作為管理進(jìn)程和代理進(jìn)程之間的明文口令，常用的是6個字符“public”。

PDU類型

根據(jù)PDU的類型，填入0～4中的一個數(shù)字，其對應(yīng)關(guān)系如表1所示意圖。

表1PDU類型（2）get/set首部

請求標(biāo)識符(requestID)

這是由管理進(jìn)程設(shè)置的一個整數(shù)值。代理進(jìn)程在發(fā)送get-response報文時也要返回此請求標(biāo)識符。管理進(jìn)程可同時向許多代理發(fā)出get報文，這些報文都使用UDP傳送，先發(fā)送的有可能后到達(dá)。設(shè)置了請求標(biāo)識符可使管理進(jìn)程能夠識別返回的響應(yīng)報文對于哪一個請求報文

差錯狀態(tài)（errorstatus）？？

由代理進(jìn)程回答時填入0～5中的一個數(shù)字，見表2的描述差錯索引(errorindex)

當(dāng)出現(xiàn)noSuchName、badValue或readOnly的差錯時，由代理進(jìn)程在回答時設(shè)置的一個整數(shù)，它指明有差錯的變量在變量列表中的偏移?？赡軙惺裁村e誤？Get_Request_PDU中填寫status字段什么內(nèi)容？（3）trap首部

企業(yè)（enterprise）

填入trap報文的網(wǎng)絡(luò)設(shè)備的對象標(biāo)識符。此對象標(biāo)識符肯定是在圖3的對象命名樹上的enterprise結(jié)點{.4.1}下面的一棵子樹上。trap類型

此字段正式的名稱是generic-trap，共分為表3中的7種。

特定代碼(specific-code)

指明代理自定義（如trap類型為6）的類型，否則為0。

時間戳(timestamp)

指明自代理進(jìn)程初始化到trap報告的事件發(fā)生所經(jīng)歷的時間，單位為10ms。例如時間戳為1908表明在代理初始化后1908ms發(fā)生了該時間。

該默認(rèn)節(jié)點值如何而來？該時間有何用處？Trap類型和特定代碼字段有何聯(lián)系？表3trap類型字段（4）變量綁定(variable-bindings)

指明一個或多個變量的名和對應(yīng)的值。在get或get-next報文中，變量的值應(yīng)忽略。特定代碼的由來？4.2.3報文應(yīng)答序列SNMP報文在管理站和代理之間傳送，包含GetRequest、GetNextRequest和SetRequest的報文由管理站發(fā)出，代理以GetResponse響應(yīng)。Trap報文由代理發(fā)給管理站，不需要應(yīng)答。所有報文的發(fā)送和應(yīng)答序列如圖4.2所示。圖4.2SNMP報文發(fā)送和應(yīng)答序列

圖4.3生成和發(fā)送SNMP報文

4.2.4報文的發(fā)送和接收如圖4.3所示。Get-request-PDU::=[0]IMPLICITSEQUENCE{Request-idINTEGERError-statusINTEGER{0…18}Error-indexINTEGER{0…max-bindings}Variable-bindingsVarBindList}VarBindList::=SEQUENCEOFVarBindVarBind::=SEQUENCE{nameOBJECTINDETIFIERvalueNULL}Get-request報文的ASN.1定義形式namevalue

V010306010201010100

L09TOBJECTIDENTIFIERTNULL

L00

L01TSEQUENCE

L0C

L0E

L04TINTEGER

L01request-iderror-statuserror-indexvariable-bindingsTINTEGER

V05AE5602

V00TSEQUENCEOFTINTEGER

V00VarBindTA0

L1DGetRequest-PDUrequest-ID..0GetRequest-PDUGet-request報文ASN.1編碼該結(jié)構(gòu)對應(yīng)前面的那一部分？圖4.4接收和處理SNMP報文

接收到報文時執(zhí)行下面的過程：接收處理過程如圖4.4所示。

驗證的過程達(dá)到什么目的？4.3SNMPv1的操作

4.3.1檢索簡單對象檢索簡單的標(biāo)量對象值可以用Get操作。如果變量綁定表中包含多個變量，則一次還可以檢索多個標(biāo)量對象的值。接收GetRequest的SNMP實體以請求標(biāo)識相同的GetResponse響應(yīng)。特別要注意的是GetResponse操作的原子性：如果所有請求的對象值可以得到，則給予應(yīng)答；反之，只要有一個對象的值得不到，則可能返回下列錯誤條件之一：

可能會有哪些錯誤發(fā)生？●變量綁定表中的一個對象無法與MIB中的任何對象標(biāo)識符匹配，或者要檢索的對象是一個數(shù)據(jù)塊(子樹或表)，沒有對象實例生成。在這些情況下，響應(yīng)實體返回的GetResponsePDU中錯誤狀態(tài)字段置為noSuchName，錯誤索引設(shè)置為一個數(shù)，指明有問題的變量。變量綁定表中不返回任何值。●

響應(yīng)實體可以提供所有要檢索的值，但是變量太多，一個響應(yīng)PDU裝不下，這往往是由下層協(xié)議數(shù)據(jù)單元大小限制的。這時響應(yīng)實體返回一個應(yīng)答PDU，錯誤狀態(tài)字段置為tooBig。

●由于其他原因(例如代理不支持)響應(yīng)實體至少不能提供一個對象的值，則返回的PDU中錯誤狀態(tài)字段置為getError，錯誤索引置一個數(shù)，指明有問題的變量。變量綁定表中不返回任何值。

例4.1為了說明簡單對象的檢索過程，考慮圖4.6所示的例子，這是UDP組的一部分。我們可以在檢索命令中直接指明對象實例的標(biāo)識符：（下面是命令的形式化描述）GetRequest(udpInDatagrams.0,udpNoPorts.0,udpInErrors.0,udpOutDatagrams.0)可以預(yù)期得到下面的響應(yīng)：GetResponse(udpInDatagrams.0=100,udpNoPorts.0=1,udpInErrors.0=2,udpOutDatagrams.0=200)Windows工具包中的snmputil.exe程序?qū)崿F(xiàn)（重點）此處為何每個OID后面都要加.0?圖4.6檢索簡單對象的值

對應(yīng)的命令格式：(對應(yīng)的真實命令）snmputilgetpublic.......7.3.0

...0請注意格式:1.檢索多個不同對象屬性值時，他們之間要用空格隔開2.每個檢索對象標(biāo)示符號(OID)前面“.”號不要忘記加3.當(dāng)然可以一次只檢索一個對象屬性的值4...和udpDatagrams等價性？命令參數(shù)含義？GetNextRequest的作用與GetRequest基本相同，PDU格式也相同，惟一的差別是GetRequest檢索變量名所指的是對象實例，而GetNextRequest檢索變量名所指的是“下一個”對象實例。根據(jù)對象標(biāo)識樹的詞典順序，對于標(biāo)量對象，對象標(biāo)識符所指的下一實例就是對象的值。

差別？和前面所講的詞典順序有何關(guān)系？為什么還要多出一個getrequest命令。

例4.2我們用GetNext命令檢索圖4.6中的4個值，直接指明對象標(biāo)識符：GetNextRequest(udpInDatagrams.0,udpNoPorts.0,udpInErrors.0,udpOutDatagrams.0)得到的響應(yīng)與上例是相同的嗎？：GetResponse(udpNoPorts.0=1,udpInErrors.0=2,udpOutDatagrams.0=200，udp.udpTable.udpEntry.udpLocalAddress..161=IpAddress)為什么會有這樣的響應(yīng)?

對應(yīng)的命令格式：snmputilgetnextpublic.......7.3.0

...0例4.3如果對udpNoPorts的訪問標(biāo)示符錯誤，則響應(yīng)會不同。發(fā)出同樣的命令：GetRequest(udpInDatagrams.0,udpNoPorts.0,udpInErrors.0,udpOutDatagrams.0)而得到的響應(yīng)是：Error:errorStatus=2,errorIndex=2)snmputilgetpublic.....2.0

...1

...0請問命令格式錯在哪？4.3.2檢索未知對象（特殊情況）

GetNext命令檢索變量名指示的下一個對象實例，但是并不要求變量名是對象標(biāo)識符或者是實例標(biāo)識符。例如udpInDatagrams是標(biāo)量對象，它的實例標(biāo)識符是udpInDatagrams.0,而標(biāo)識符udpInDatagrams.2并不表示任何對象。如果我們發(fā)出一個命令：GetNextRequest(udpInDatagrams.2)則得到的響應(yīng)是：GetResponse(udpNoPorts.0=1)udpNoPorts對象為udpInDatagrams.0的下一個對象這說明代理沒有檢查標(biāo)識符udpInDatagrams.2的有效性，而是直接查找下一個有效的標(biāo)識符，得到udpInDatagrams.0后返回了它的下一個對象實例。

命令格式：snmputilgetnextpublic...2返回的結(jié)果：Variable=udp.udpNoPorts.0Value=Counter32340以上是屏幕截圖格式，說明什么？請問該種命令處理機(jī)制所帶來的好處？

例4.4利用GetNext的檢索未知對象的特性可以發(fā)現(xiàn)MIB的結(jié)構(gòu)。例如管理站不知道udp組有哪些變量，先試著發(fā)出命令：GetNextRequest(udp)得到的響應(yīng)是：GetResponse(udpInDatagrams.0=100)這樣管理站知道了udp組的第一個對象，還可以繼續(xù)這樣找到其他管理對象。

和我們以前介紹的詞典順序是否一致？命令格式：snmputilgetnextpublic..2.1.7得到響應(yīng)：該命令的處理機(jī)制和上一個例子有什么相似性？4.3.3檢索表對象

GetNext可用于有效地搜索表對象。

例4.5考慮圖4.7所示的例子，如果我們發(fā)出下面的命令，檢索ifNumber的值：GetRequest(..0)GetResponse(2)命令格式：snmputilgetpublic..0圖4.7檢索表對象例

我們知道有兩個接口。如果想知道每個接口的數(shù)據(jù)速率，則可以用下面的命令檢索if表的5個元素：GetRequest(..1.5.1)最后的1是索引項ifIndex的值。得到的響應(yīng)是：GetResponse(100000000)說明第一個接口的數(shù)據(jù)速率是10Mb/s。如果我們發(fā)出的命令是：

GetNextRequest(..1.5.1)則得到的是第二個接口的數(shù)據(jù)速率：GetResponse(56000)說明第二個接口的數(shù)據(jù)速率是56kb/s。

例4.6(作業(yè)）考慮圖4.8所示的表。假定管理站不知道該表的行數(shù)而想檢索整個表，則可以連續(xù)使用GetNext命令每次檢索表對象一行數(shù)據(jù)嗎？我們怎么知道一張表什么時候檢索完畢？GetNextRequest(ipRouteDest,ipRouteMetric1,ipRouteNextHop)GetResponse(ipRouteDest.=,ipRouteMetric.3=3,ipRouteNextHop.=)圖4.8檢索表對象例

以上是第1行的值，據(jù)此可以檢索下一行：GetNextRequest(ipRouteDest.,ipRouteMetric.3,ipRouteNextHop.)上面命令的含義是什么？用意是什么?GetResponse(ipRouteDest.1=1,ipRouteMetric.51=5,ipRouteNextHop.1=2)這種形式化的表述轉(zhuǎn)化成snmputil命令格式是什么？繼續(xù)檢索第3行和第4行：GetNextRequest(ipRouteDest.1,ipRouteMetric.51,ipRouteNextHop.1)GetResponse(ipRouteDest.9=9,ipRouteMetric.99=5,ipRouteNextHop.9=2)下面的這段檢索對我們有什么啟示？GetNextRequest(ipRouteDest.9,ipRouteMetric.99,ipRouteNextHop.9)GetResponse(ipRouteIfIndex.=65539,ipRouteMetric.3=-1,ipRouteType=3)具體命令格式snmputilgetnextpublic.....3

..1.1.7snmputilgetnextpublic...0.0.0

.......0……（注意：由于每個計算機(jī)的IpRouteTable內(nèi)容不同，上述的命令可能有所差異，請根據(jù)具體情況而定。)4.3.4表的更新和刪除Set命令用于設(shè)置或更新變量的值。它的PDU格式與Get是相同的，但是在變量綁定表中必須包含要設(shè)置的變量名和變量值。對于Set命令的應(yīng)答也是GetResponse，同樣是原子性的。如果所有的變量都可以設(shè)置，則更新所有變量的值，并在應(yīng)答的GetResponse中確認(rèn)變量的新值；如果至少有一個變量的值不能設(shè)置，則所有變量的值都保持不變，并在錯誤狀態(tài)中指明出錯的原因。Set出錯的原因與Get是類似的(tooBig、noSuchName和genError)，然而若有一個變量的名字和要設(shè)置的值在類型、長度或?qū)嶋H值方面不匹配，則返回錯誤條件badValue。

例4.7再一次考慮圖4.8所示的表。如果我們想改變列對象ipRouteMetric1的第一個值，則可以發(fā)出命令：SetRequest(ipRouteMetric.3=9)得到的應(yīng)答是：GetResponse(ipRouteMetric.3=9)其效果是該對象的值由1變成了2。(見圖形工具)注意:并不是所有的對象屬性值都可以更改，首先該對象屬性要就有write-read權(quán)限，而且還要更改團(tuán)體名public的權(quán)限，使它為write-read權(quán)限。以下幾個例子權(quán)限都要設(shè)置為write-read，才能進(jìn)行操作。例4.8假定我們想增加一行，則可以發(fā)出下面的命令：SetRequest(ipRouteDest.2=2,ipRouteMetric2=9,ipRouteNextHop.2=)對這個命令如何執(zhí)行，RFC1212有3種解釋：(1)代理可以拒絕這個命令，因為對象標(biāo)識符ipRouteDest.2不存在，所以返回錯誤狀態(tài)noSuchName。(2)代理可以接受這個命令，并企圖生成一個新的對象實例，但是發(fā)現(xiàn)被賦予的值不適當(dāng)，因而返回錯誤狀態(tài)badValue。(3)代理可以接受這個命令，生成一個新的行，使表增加到4行，并返回下面的應(yīng)答：GetResponse(ipRouteDest.2=2,ipRouteMetric2=9,ipRouteNextHop.2=)在具體實現(xiàn)中，以上3種情況都是可能的。

例4.9假定原來是3行的表，現(xiàn)在發(fā)出下面的命令：SetRequest(ipRouteDest.2=2)對于這個命令也有兩種處理方法：(1)由于變量ipRouteDest是索引項，因而代理可以增加一個表行，對于沒有指定值的變量賦予默認(rèn)值。(2)代理拒絕這個操作。如果要生成新行，必須提供一行中所有變量的值。采用哪種方法也是由具體實現(xiàn)決定的。

例4.10如果要刪除表中的行，則可以把一個對象的值置為invalid：SetRequest(ipRouteType.=invalid)得到的響應(yīng)說明表行確已刪除：GetResponse(ipRouteType.=invalid)這種刪除是物理的還是邏輯的，又是由具體實現(xiàn)決定的。在MIB-2中只有兩種表是可刪除的：ipRouteTable包含ipRouteType，可取值invalid；ipNetToMediaTable包含ipNetToMediaType，可取值invalid。

4.3.5陷入操作陷入是由代理向管理站發(fā)出的異步事件報告，不需要應(yīng)答報文。SNMPv1規(guī)定了6種陷入條件，另外還有由設(shè)備制造商定義的陷入。●coldStart：發(fā)送實體重新初始化，代理的配置已改變，通常是由系統(tǒng)失效引起的?！駑armStart：發(fā)送實體重新初始化，但代理的配置沒有改變，這是正常的重啟動過程?！駆inkDown：鏈路失效通知，變量綁定表的第一項指明對應(yīng)接口表的索引變量及其值。●linkUp：鏈路啟動通知，變量綁定表的第一項指明對應(yīng)接口表的索引變量及其值?！馻uthenticationFailure：發(fā)送實體收到一個沒有通過認(rèn)證的報文?！馿gpNeighborLoss：相鄰的外部路由器失效或關(guān)機(jī)?！馿nterpriseSpecific：由設(shè)備制造商定義的陷入條件，在特殊陷入(specific-trap)字段指明具體的陷入類型。

例4.11測試自陷服務(wù)命令格式：snmputiltrap(代理端)snmputilgetliqiao1.1.0(管理端）觀察屏幕的含義，有什么提示信息？注意：要啟用兩個DOS命令窗口,而且必須在“SNMP服務(wù)屬性”對話框中，將主機(jī)添加為陷進(jìn)目標(biāo)…這屬于自陷服務(wù)中的哪種？4.4SNMP功能組

SNMP組包含的信息關(guān)系到SNMP協(xié)議的實現(xiàn)和操作。這一組中共有30個對象，參見圖4.9。圖4.9MIB-2SNMP功能組SNMPv2協(xié)議數(shù)據(jù)單元

SNMPv2提供了3種訪問管理信息的方法：●管理站和代理之間的請求/響應(yīng)通信，這種方法與SNMPv1是一樣的；●管理站和管理站之間的請求/響應(yīng)通信，這種方法是SNMPv2特有的，可以由一個管理站把有關(guān)管理信息告訴給另外一個管理站；●

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

SNMPv2報文SNMPv2PDU封裝在報文中傳送，報文頭提供了簡單的認(rèn)證功能，而PDU可以完成上面提到的各種操作。我們首先介紹報文頭的格式和作用，然后討論協(xié)議數(shù)據(jù)單元的結(jié)構(gòu)。SNMPv2報文的結(jié)構(gòu)分為3部分：版本號、團(tuán)體名和作為數(shù)據(jù)傳送的PDU。這個格式與SNMPv1一樣。版本號取值0代表SNMPv1，取值1代表SNMPv2。團(tuán)體名提供簡單的認(rèn)證功能，與SNMPv1的用法一樣。

SNMPv2實體發(fā)送一個報文一般要經(jīng)過下面4個步驟：(？與SNMPv1的區(qū)別）(1)根據(jù)要實現(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)加入版本號和團(tuán)體名，構(gòu)造報文。(4)進(jìn)行BER編碼，產(chǎn)生0/1比特串，發(fā)送出去。

SNMPv2實體接收到一個報文后要完成下列動作：(1)對報文進(jìn)行語法檢查，丟棄出錯的報文。(2)把PDU部分、源和目標(biāo)端口號交給認(rèn)證服務(wù)。如果認(rèn)證失敗，發(fā)送一個陷入，丟棄報文。(3)如果認(rèn)證通過，則把PDU轉(zhuǎn)換成ASN.1的形式。(4)協(xié)議實體對PDU做句法檢查，如果通過，根據(jù)團(tuán)體名和適當(dāng)?shù)脑L問策略作相應(yīng)的處理。

SNMPv2PDU（PDU與原有的SNMPv1版本有什么不同？）SNMPv2共有6種協(xié)議數(shù)據(jù)單元，分為3種PDU格式，見圖4.25。注意GetRequest、GetNextRequest、SetRequest、InformRequest和Trap等5種PDU與ResponsePDU具有相同的格式，只是它們的錯誤狀態(tài)和錯誤索引字段被置為0，這樣就減少了PDU格式的種類。圖4.25SNMPv2PDU格式

questtrapPDU??這些協(xié)議數(shù)據(jù)單元在管理站和代理系統(tǒng)之間或者是兩個管理站之間交換，以完成需要的協(xié)議操作。它們的交換序列如圖4.26和圖4.27所示。下面解釋管理站和代理系統(tǒng)對這些PDU的處理和應(yīng)答過程。

圖4.26管理站和代理之間的通信

圖4.27管理站和管理站之間的通信

1.GetRequestPDUSNMPv2對這種操作的響應(yīng)方式與SNMPv1不同，SNMPv1的響應(yīng)是原子性的，即只要有一個變量的值檢索不到，就不返回任何值。而SNMPv2的響應(yīng)不是原子性的，允許部分響應(yīng)，按照以下規(guī)則對變量綁定表中的各個變量進(jìn)行處理。●如果該變量的對象標(biāo)識符前綴不能與這一請求可訪問的任何變量的對象標(biāo)識符前綴匹配，則返回一個錯誤值noSuchObject?！袢绻兞棵荒芘c這一請求可訪問的任何變量名完全匹配，則返回一個錯誤值noSuchInstance。這種情況可能出現(xiàn)在表訪問中，即訪問了不存在的行或正在生成中的表行等。

●如果不屬于以上情況，則在變量綁定表中返回被訪問的值?！袢绻捎谌魏纹渌蚨幚硎?，則返回一個錯誤狀態(tài)genErr，對應(yīng)的錯誤索引指向有問題的變量。●

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

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

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

●如果找不到按照詞典順序排列的后繼變量，則返回請求PDU中的變量名和錯誤值endOfMibView。●如果出現(xiàn)其它情況使得構(gòu)造響應(yīng)PDU失敗，則以與GetRequest類似的方式返回錯誤值。

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

這個表的索引由前兩個變量組成。如果管理站希望檢索這個表的值和一個標(biāo)量對象sysUpTime的值，則可以發(fā)出這樣的請求：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ā)出下一個請求：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這個請求的格式和語義與SNMPv1的相同，差別是處理響應(yīng)的方式不同。SNMPv2實體分兩個階段處理這個請求的變量綁定表：首先是檢驗操作的合法性，然后再更新變量。如果至少有一個變量綁定對的合法性檢驗沒有通過，則不進(jìn)行下一階段的更新操作。因此這個操作與SNMPv1一樣，是原子性的。合法性檢驗包括以下內(nèi)容：為什么寫要是原子性？●

如果有一個變量不可訪問，則返回錯誤狀態(tài)noAccess。●如果與綁定表中變量共享對象標(biāo)識符的任何MIB變量都不能生成、不能修改，也不接受指定的值，則返回錯誤狀態(tài)notWritable?！袢绻O(shè)置的值的類型不適合被訪問的變量，則返回錯誤狀態(tài)wrongType。●如果要設(shè)置的值的長度與變量的長度限制不同，則返回錯誤狀態(tài)wrongLength?！袢绻O(shè)置的值的ASN.1編碼不適合變量的ASN.1標(biāo)簽，則返回錯誤狀態(tài)wrongEncoding?！袢绻付ǖ闹翟谌魏吻闆r下都不能賦予變量，則返回錯誤狀態(tài)wrongValue。Snmpv2在寫入操作做了哪些改進(jìn)？

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

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

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

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

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

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

如果對任何變量檢查出上述任何一種錯誤，則在響應(yīng)PDU變量綁定表中設(shè)置對應(yīng)的錯誤狀態(tài)，錯誤索引設(shè)置為問題變量的序號。使用如此之多的錯誤代碼也是SNMPv2的一大進(jìn)步，這使得管理站能了解詳細(xì)的錯誤信息，以便采取糾正措施。如果沒有檢查出錯誤，就可以給所有指定變量賦予新值。若有至少一個賦值操作失敗，則所有賦值被撤消，并返回錯誤狀態(tài)為commitFailed的PDU，錯誤索引指向問題變量的序號；但是若不能全部撤消所賦的值，則返回錯誤狀態(tài)undoFailed，錯誤索引字段置0。

5.TrapPDU陷入是由代理發(fā)給管理站的非確認(rèn)性消息。SNMPv2的陷入采用與Get等操作相同的PDU格式，這一點也是與原標(biāo)準(zhǔn)不同的。TrapPDU的變量綁定表中應(yīng)報告下面的內(nèi)容：●sysUpTime.0的值，即發(fā)出陷入的時間?！駍nmpTrapOID.0的值，這是SBNPv2MIB對象組定義的陷入對象的標(biāo)識符?！裼嘘P(guān)通知宏定義中包含的各個變量及其值?！?/p>

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

6.InformRequestPDU這是管理站發(fā)送給管理站的消息，PDU格式與Get等操作相同，變量綁定表的內(nèi)容與陷入報文一樣。但是與陷入不同，這個消息是需要應(yīng)答的。因此，管理站收到通知請求后首先要決定應(yīng)答報文的大小，如果應(yīng)答報文的大小超過本地或?qū)Ψ降南拗?，則返回錯誤狀態(tài)tooBig。如果接收的請求報文不是太大，則把有關(guān)信息傳送給本地的應(yīng)用實體，返回一個錯誤狀態(tài)為noErr的響應(yīng)報文，其變量綁定表與收到的請求PDU相同。管理站之間的通信SNMPv2增加的管理站之間的通信機(jī)制是分布式網(wǎng)絡(luò)管理所需要的功能特征，為此引入了通知報文InformRequest和管理站數(shù)據(jù)庫(manager-to-managerMIB)。管理站數(shù)據(jù)庫主要由3個表組成。●snmpAlarmTable：報警表提供被監(jiān)視的變量的有關(guān)情況，類似于RMON警報組的功能，但這個表記錄的是管理站之間的報警信息?！?/p>

snmpEventTable：事件表記錄SNMPv2實體產(chǎn)生的重要事件，或者是報警事件，或者是通知類型宏定義的事件。

●snmpEventNotifyTable：事件通知表定義了發(fā)送通知的目標(biāo)和通知的類型。典型的網(wǎng)絡(luò)管理系統(tǒng)（教材十一章）1.Ciscoworks20002.HPOpenView3.IBMNetView4.SNMPc5.SiteView6.OpManager4.5實現(xiàn)問題和典型的網(wǎng)絡(luò)管理系統(tǒng)4.5.1網(wǎng)絡(luò)管理站的功能？？在選擇站管理產(chǎn)品時首先要關(guān)心它與標(biāo)準(zhǔn)的一致程度，與代理的互操作性，當(dāng)然更要關(guān)心其用戶界面，既要功能齊全，又要使用方便。更具體地說，我們對管理站應(yīng)提出以下選擇的標(biāo)準(zhǔn)：●支持?jǐn)U展的MIB。強(qiáng)有力的SNMP對管理信息庫的支持必須是開放的。特別對于管理站來說，應(yīng)該能夠裝入其他制造商定義的擴(kuò)展MIB?！駡D形用戶接口。好的用戶接口可以使網(wǎng)絡(luò)管理工作更容易、更有效。通常要求管理站具有圖形用戶接口，而且對網(wǎng)絡(luò)管理的不同部分有不同的窗口。例如能夠顯示網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，顯示設(shè)備的地理位置和狀態(tài)信息，可以計算并顯示通信統(tǒng)計數(shù)據(jù)圖表，具有各種輔助計算工具等?！褡詣影l(fā)現(xiàn)機(jī)制。要求管理站能夠自動發(fā)現(xiàn)代理系統(tǒng)，能夠自動建立圖標(biāo)并繪制出連接圖形?！窨删幊痰氖录?。管理站應(yīng)支持用戶定義事件以及出現(xiàn)這些事件時執(zhí)行的動作。例如路由器失效時應(yīng)閃動圖標(biāo)或改變圖標(biāo)的顏色，顯示錯誤狀態(tài)信息，向管理員發(fā)送電子郵件并啟動故障檢測程序等。

查看Mib數(shù)據(jù)

長期保存統(tǒng)計數(shù)據(jù)

設(shè)置報警閾值

輪詢TCP應(yīng)用服務(wù)

網(wǎng)絡(luò)發(fā)現(xiàn)疑難解答SNMPcSNMPc的用戶界面

SNMPc多層次網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖

SNMPc控制臺的主要組件

4.5.2輪詢頻率

SNMP定義的陷入類型是很少的，雖然可以補(bǔ)充設(shè)備專用的陷入類型，但專用的陷入往往不能被其他制造商的管理站所理解，因此管理站主要靠輪詢收集信息。輪詢的頻率對管理的性能影響很大。如果管理站在啟動時輪詢所有代理，以后只是等待代理發(fā)來的陷入，則就很難掌握網(wǎng)絡(luò)的最新動態(tài)，例如不能及時了解網(wǎng)絡(luò)中出現(xiàn)的擁擠。我們需要一種能提高網(wǎng)絡(luò)管理性能的輪詢策略？，以決定合適的輪詢頻率。通常輪詢頻率與網(wǎng)絡(luò)的規(guī)模和代理的多少有關(guān)。而網(wǎng)絡(luò)管理性能還取決于管理站的處理速度、子網(wǎng)數(shù)據(jù)速率、網(wǎng)絡(luò)擁擠程度等其他諸多因素，因此很難給出準(zhǔn)確的判斷規(guī)則。使問題簡化我們假定管理站一次只能與一個代理作用，輪詢只采用Get請求/響應(yīng)這種簡單形式，而且管理站全部時間都用來輪詢，于是我們有下面的不等式：