簡單網路管理協議SNMP(史上最全)
簡單網路管理協議(SNMP)是TCP/IP協議簇的一個應用層協議。在1988年被制定,並被Internet體系結構委員會(IAB)採納作為一個短期的網路管理解決方案;由於SNMP的簡單性,在Internet時代得到了蓬勃的發展,1992年釋出了SNMPv2版本,以增強SNMPv1的安全性和功能。現在,已經有了SNMPv3版本。
SNMP版本
SNMPv1
SNMPv1 是 SNMP 協議的最初版本,提供最小限度的網路管理功能。SNMPv1 的 SMI 和 MIB 都比較簡單,且存在較多安全缺陷。SNMPv1 採用團體名認證。團體名的作用類似於密碼,用來限制NMS對Agent 的訪問。如果 SNMP 報文攜帶的團體名沒有得到 NMS/Agent 的認可,該報文將被丟棄。SNMPV1 是一種簡單的請求/響應協議。網路管理系統發出一個請求,管理器則返回一個響應。這一行為的實現是通過使用四種協議操作中的其中任一種完成的。這四種操作分別是 GET、GETNEXT、SET 和 TRAP。NMS 通過 GET 操作,從 SNMP 代理處得到一個或 更多的物件(例項)值。如果代理處不能提供請求列表中所有的物件(例項)值,它也就不提供任何值。 NMS 使用 GETNEXT 操作請求代理從請求列表或物件列表中取出下一 個物件例項值。NMS 通過 SET 操作向 SNMP 代理髮送命令,要求對物件值重新配置。SNMP 代理通過 TRAP 操作不定時的通知 NMS 所發生的特定事件 SNMP 是一種應用程式協議。
SNMPv2
SNMPv2c 也採用團體名認證。在相容 SNMPv1 的同時又擴充了 SNMPv1 的功能:它提 供了更多的操作型別(GetBulk--批量獲取操作等);支援更多的資料型別(Counter32等),提供了更豐富的錯誤程式碼,能夠更細緻地區分錯誤。
SNMPV1 中的 GET、GETNEXT 及 SET 操作同樣適用於 SNMPV2,只是 SNMPV2 新增和增強了有關協議操作。例如 SNMPV2 中的 TRAP 操作,不但具備 SNMPV1 中 TRAP 的相同功能,而且它採用了一種不同的訊息格式,它用於替換 SNMPV1 中的 TRAP。
SNMPV2 中還定了兩種新操作,即 GET BULK 和 INFORM。NMS 通過 GET BULK 操作能有效地獲取大塊資料,如物件列表中的多行。請求多少資料 GETBULK 返回一個包含儘可能多的請求資料的應答訊息。INFORM 操作使一個NMS 能傳送 TRAP 給另一個 NMS 並收到回覆。SNMPV2中,如果回覆 GET BULK 操作的 SNMP 代理不能提供請求表中所有變數值,那麼SNMP代理只提供部分結果。
SNMPV3
SNMPv3主要在安全性方面進行了增強,它採用了 USM(基於使用者的安全控制模型)和 VACM(基於檢視的訪問控制模型) 技術。USM 提供了認證和加密功能,VACM 確定使用者是否允許訪問特定的 MIB 物件以及訪問方式。
SNMPV3 中增加了安全管理方式及遠端控制。SNMPV3 結構引入了基於使用者的安全模型用於保證訊息安全及基於檢視的訪問控制模型用於訪問控制(USM)。這種安全管理方式支援不同安全性,訪問控制安全性認證和隱私授權和訪問控制管理框架人員和政策使用者名稱及金鑰管理通知目標檔案代理關係實體命名。
SNMPV3 使用 SNMP SET 命令配置MIB物件,使之能動態配置SNMP代理。這種動態配置方式支援本地或遠端地配置實體的新增、刪除及修改。
一套完整的SNMP系統主要包括管理資訊庫(MIB)、管理資訊結構(SMI)及SNMP報文協議。
管理資訊庫MIB
任何一個被管理的資源都表示成一個物件,稱為被管理的物件。MIB是被管理物件的集合。它定義了被管理物件的一系列屬性:物件的名稱、物件的訪問許可權和物件的資料型別等。每個SNMP裝置(Agent)都有自己的MIB。MIB也可以看作是NMS(網路管理系統,網路管理系統既可以指一臺專門用來進行網路管理的伺服器,也可以指某個網路裝置中執行管理功能的一個應用程式)和Agent之間的溝通橋樑。它們之間的關係如圖1所示。
圖1 NMS Agent和MIB的關係
MIB檔案中的變數使用的名字取自ISO和ITU管理的物件識別符號(object identifier)名字空間。它是一種分級樹的結構。如圖2所示,第一級有三個節點:ccitt、iso、iso-ccitt。低階的物件ID分別由相關組織分配。一個特定物件的識別符號可通過由根到該物件的路徑獲得。一般網路裝置取iso節點下的物件內容。如名字空間ip結點下一個名字為ipInReceives的MIB變數被指派數字值3,因而該變數的名字為:
iso.org.dod.internet.mgmt.mib.ip.ipInReceives
相應的數字表示(物件識別符號OID,唯一標識一個MIB物件)為:
1.3.6.1.2.1.4.3
圖2 MIB樹結構
當網路管理協議在報文中使用MIB變數時,每個變數名後還要加一個字尾,以作為該變數的一個例項。如ipInReceives的例項數字表示為:1.3.6.1.2.1.4.3.0.
需要注意的是,MIB中的管理物件的OID有些需要動態確定,如IP路由表,為了指明地址202.120.86.71的下一站路由(next hop),我們可以引用這樣的例項:
iso.org.dod.internet.mgmt.mib.ip. ipRouteTable.ipRouteEntry.ipRouteNextHop.202.120.86.71, 相應的數字表示為:1.3.6.1.2.1.4.21.1.7.202.120.86.71
管理資訊結構(SMI)
SMI定義了SNMP框架所用資訊的組織、組成和標識,它還為描述MIB物件和描述協議怎樣交換資訊奠定了基礎。
SMI定義的資料型別:
◆ 簡單型別(simple)
Integer:整型是-2,147,483,648~2,147,483,647的有符號整數
octet string: 字串是0~65535個位元組的有序序列
OBJECT IDENTIFIER: 來自按照ASN.1規則分配的物件識別符號集
◆ 簡單結構型別(simple-constructed)
SEQUENCE 用於列表。這一資料型別與大多數程式設計語言中的“structure”類似。一個SEQUENCE包括0個或更多元素,每一個元素又是另一個ASN.1資料型別
SEQUENCE OF type 用於表格。這一資料型別與大多數程式設計語言中的“array”類似。一個表格包括0個或更多元素,每一個元素又是另一個ASN.1資料型別。
◆ 應用型別(application-wide)
IpAddress: 以網路序表示的IP地址。因為它是一個32位的值,所以定義為4個位元組;
counter:計數器是一個非負的整數,它遞增至最大值,而後回零。在SNMPv1中定義的計數器是32位的,即最大值為4,294,967,295;
Gauge :也是一個非負整數,它可以遞增或遞減,但達到最大值時保持在最大值,最大值為232-1;
time ticks:是一個時間單位,表示以0.01秒為單位計算的時間;
彙總如下:
SNMP報文
SNMP報文結構如下:(編碼之前)
版本號 |
團體名 |
協議資料單元PDU |
SNMP共有5種報文,所以其PDU也有5中。
1 SNMP的5種協議資料單元
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:
下圖是封裝成UDP資料包的5種操作的SNMP報文格式。可見一個SNMP報文共有三個部分組成,即公共SNMP首部、get/set首部、trap首部、變數繫結。
(1)公共SNMP首部
共三個欄位:
版本
寫入版本欄位的是版本號減1,對於SNMP(即SNMPV1)則應寫入0。
共同體(community)
共同體就是一個字串,作為管理程式和代理程式之間的明文口令,常用的是6個字元“public”。
PDU型別
根據PDU的型別,填入0~4中的一個數字,其對應關係如表2所示意圖。
表2 PDU型別
PDU型別
名稱
0
get-request
1
get-next-request
2
get-response
3
set-request
4
trap
(2)get/set首部
請求識別符號(request ID)
這是由管理程式設定的一個整數值。代理程式在傳送get-response報文時也要返回此請求識別符號。管理程式可同時向許多代理髮出get報文,這些報文都使用UDP傳送,先傳送的有可能後到達。設定了請求識別符號可使管理程式能夠識別返回的響應報文對於哪一個請求報文
差錯狀態(error status)
由代理程式回答時填入0~5中的一個數字,見表3的描述
表3 差錯狀態描述
差錯狀態 | 名字 | 說明 |
0 | noError | 一切正常 |
1 | tooBig | 代理無法將回答裝入到一個SNMP報文之中 |
2 | noSuchName | 操作指明瞭一個不存在的變數 |
3 | badValue | 一個set操作指明瞭一個無效值或無效語法 |
4 | readOnly | 管理程式試圖修改一個只讀變數 |
5 | genErr | 某些其他的差錯 |
差錯索引(error index)
當出現noSuchName、badValue或readOnly的差錯時,由代理程式在回答時設定的一個整數,它指明有差錯的變數在變數列表中的偏移。
(3)trap首部
trap報文格式如下:
企業(enterprise)
填入trap報文的網路裝置的物件識別符號。此物件識別符號肯定是在圖3的物件命名樹上的enterprise結點{1.3.6.1.4.1}下面的一棵子樹上。
代理地址
即代理程式所在系統的地址。
trap型別
此欄位正式的名稱是generic-trap,共分為表4中的7種。
trap型別 | 名字 | 說明 |
0 | coldStart | 代理進行了初始化 |
1 | warmStart | 代理進行了重新初始化 |
2 | linkDown | 一個介面從工作狀態變為故障狀態 |
3 | linkUp | 一個介面從故障狀態變為工作狀態 |
4 | authenticationFailure | 從SNMP管理程式接收到具有一個無效共同體的報文 |
5 | egpNeighborLoss | 一個EGP相鄰路由器變為故障狀態 |
6 | enterpriseSpecific | 代理自定義的事件,需要用後面的“特定程式碼”來指明 |
當使用上述型別2、3、5時,在報文後面變數部分的第一個變數應標識響應的介面。
特定程式碼
特定程式碼僅僅在trap型別為6時有效,否則都置為0,他是廠家自定義的事件程式碼。
時間戳(timestamp)
指明自代理程式初始化到trap報告的事件發生所經歷的時間,單位為10ms。例如時間戳為1908表明在代理初始化後1908ms發生了該時間。
(4)變數繫結(variable-bindings)
指明一個或多個變數的名和對應的值。在get或get-next報文中,變數的值應忽略。
管理變數的表示
管理變數表示管理物件型別在某一時刻的值(或稱該型別的例項),SNMP以管理變數作為操作物件。
管理變數的表示方法是這樣規定的:形如x.y,其中x是管理物件的object identifer。y是能唯一確定物件型別值的一組數字,在非表型變數中為0,在表型變數中是這個表的索引,比如介面表中的介面號,或路由表中的目的網路地址等等 。如:在MIB檔案裡定義了ipAdEntNetMask這一管理物件,其object identifier為1.3.6.1.1.5.6.1.3它是個路由表中的一項,它的一個例項就是路由表中某一行的子網掩碼,如果這行的索引、目的網路地址為129.102.1.0。則這個變數名是:1.3.6.1.1.5.6.1.3.129.102.1.0。在以後的說明中,為了方便,把唯一確定管理變數的一組數字,也就是x.y中的y稱作例項。
SNMP的執行過程
駐留在被管裝置上的AGENT從UDP埠161接受來自網管站的序列化報文,經解碼、團體名驗證、分析得到管理變數在MIB樹中對應的節點,從相應的模組中得到管理變數的值,再形成響應報文,編碼傳送回網管站。網管站得到響應報文後,再經同樣的處理,最終顯示結果。
下面根據RFC1157詳細介紹Agent接受到報文後採取的動作:
首先解碼生成用內部資料結構表示的報文,解碼依據ASN.1的基本編碼規則,如果在此過程中出現錯誤導致解碼失敗則丟棄該報文,不做進一步處理。
第二步:將報文中的版本號取出,如果與本Agent支援的SNMP版本不一致,則丟棄該報文,不做進一步處理。當前北研的資料通訊產品只支援SNMP版本1。
第三步:將報文中的團體名取出,此團體名由發出請求的網管站填寫。如與本裝置認可的團體名不符,則丟棄該報文,不做進一步處理,同時產生一個陷阱報文。SNMPv1只提供了較弱的安全措施,在版本3中這一功能將大大加強。
第四步:從通過驗證的ASN.1物件中提出協議資料單元PDU,如果失敗,丟棄報文,不做進一不處理。否則處理PDU,結果將產生一個報文,該報文的傳送目的地址應同收到報文的源地址一致。
根據不同的PDU,SNMP協議實體將做不同的處理:
1.1 GetRequest PDU
第一種情況:如果PDU中的變數名在本地維護的MIB樹中不存在,則接受到這個PDU的協議實體將向發出者傳送一個GetResponse報文,其中的PDU與源PDU只有一點不同:將ERROR-STATUS置為noSuchName,並在ERROR-INDEX中指出產生該變數在變數LIST中的位置。
第二種情況:如果本地協議實體將產生的響應報文的長度大於本地長度限制,將向該PDU的發出者傳送一個GetResponse報文,該PDU除了ERROR-STATUS置為tooBig,ERROR-INDEX置為0以外,與源PDU相同。
第三種情況:如果本地協議實體因為其他原因不能產生正確的響應報文,將向該PDU的發出者傳送一個GetResponse報文,該PDU除了ERROR-STATUS置為genErr,ERROR-INDEX置為出錯變數在變數LIST中的位置,其餘與源PDU相同。
第四中情況:如果上面的情況都沒有發生,則本地協議實體向該PDU的發出者傳送一個GetResponse報文,該PDU中將包含變數名和相應值的對偶表,ERROR-STATUS為noError,ERROR-INDEX為0,request-id域的值應與收到PDU的request-id相同。
1.2 GetNextRequest PDU
GetNextRequest PDU的最重要的功能是表的遍歷,這種操作受到了前面所說的管理變數的表示方法的支援,從而可以訪問一組相關的變數,就好象他們在一個表內。
下面通過一個例子解釋表遍歷的過程:
被管裝置維護如下路由表:
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
假設網管站欲取得這張路由表的資訊,該表的索引是目的網路地址。
網管站向被管裝置傳送一個GetNextRequest PDU,其中的受管物件的標識如下
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
SNMP agent響應如下GetResponse PDU:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
網管站繼續:
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
agent響應:
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
值得注意的是agent必須能夠確定下一個管理變數名,以保證所有變數能被取到且只被取到一次。
網管站繼續:
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
agent 響應:
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
網管站繼續
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
這時因為路由表中所有的行都被取遍,agent因返回路由表物件的下一字典後繼即該管理物件在MIB樹中的後序遍歷的直接後繼。這裡應是nettoMediaIndex,管理物件的OBJECT IDENTIFIER。這個響應通知網管站對錶的遍歷已經完成。
1.3 GetResponse PDU
GetResponse PDU只有當受到getRequest GetNextRequest SetRequest才由協議實體產生,網管站收到這個PDU後,應顯示其結果。
1.4 SetRequest PDU
SetRequest PDU除了PDU型別標識以外,和GetRequest相同,當需要對被管變數進行寫操作時,網管站側的協議實體將生成該PDU。
對SetRequest的響應將根據下面情況分別處理:
如果是關於一個只讀變數的設定請求,則收到該PDU的協議實體產生一個GetReponse報文,並置error status為noSuchName, error index的值是錯誤變數在變數list中的位置。
如果被管裝置上的協議實體收到的PDU中的變數對偶中的值,型別、長度不符和要求,則收到該PDU的協議實體產生一個GetReponse報文,並置error status為badValue, error index的值是錯誤變數在變數list中的位置。
如果需要產生的GetReponse報文長度超過了本地限制,則收到該PDU的協議實體產生一個GetReponse報文,並置error status為tooBig, error index的值是0。
如果是其他原因導致SET失敗,則收到該PDU的協議實體產生一個GetReponse報文,並置error status為genErr, error index的值是錯誤變數在變數list中的位置。
如果不符合上面任何情況,則agent將把管理變數設定收到的PDU中的相應值,這往往可以改變被管裝置的執行狀態。同時產生一個GetResponse PDU,其中error status置為noError,error index的值為0。
1.5 Trap PDU
Trap PDU的有如下的形式
產生trap的系統的OBJECT IDENTIFIER |
系統的IP地址 |
普通型別 |
特定型別 |
時戳 |
變數對偶表 |
Trap是被管裝置遇到緊急情況時主動向網管站傳送的訊息。網管站收到trap PDU後要將起變數對偶表中的內容顯示出來。一些常用的trap型別有冷、熱啟動,鏈路狀態發生變化等。
通過wireshark抓包工具,捕獲一條如下的SNMP報文,接下來對其進行仔細分析。
SNMPv1原始報文內容:
00 23 5a 9e 58 b9 00 4c 41 49 50 55 08 00 45 00 00 48 00 00 40 00 40 11 a5 4e 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 43 01 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 c0 a8 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個位元組,即沒有該欄位。
同樣的,這裡除了trap型別和報文長度是標準網路位元組序之外,其餘協議欄位也均為BER編碼方式。可以看到v2版的trap報文正在向統一的報文格式發展,已經非常類似普通的SNMP請求、響應報文了。
SNMPv2原始報文內容:
00 23 5a 9e 58 b9 00 4c 41 49 50 55 08 00 45 00 00 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 5d02 01 01 04 06 70 75 62 6c 69 63 a7 50 02 04 17 73 2c fb 02 01 00 02 01 00 30 42 30 0d 06 08 2b 06 01 02 01 01 03 00 43 01 0e 30 1706 0a 2b 06 01 06 03 01 01 04 01 00 06 09 2b 06 01 06 03 01 01 05 01 30 18 06 0a 2b 06 01 06 03 01 01 04 03 00 06 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 c0 a8 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 03 00,為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 00 06 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 00 06 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;
相關文章
- 簡單網路管理協議SNMP通訊基礎篇-熊健-專題視訊課程協議
- 最全網路協議(轉載)協議
- SNMP協議協議
- SNMP 協議協議
- 網路管理協議協議
- 【網路協議】TCP協議簡介協議TCP
- SNMP協議詳解協議
- 網際網路協議簡介協議
- 網路管理之ICMP協議篇協議
- win10系統無法解除安裝簡單網路管理協議(SNMP)提示0x800736B3怎麼辦Win10協議
- 【網路協議】UDP協議協議UDP
- IP協議(網路層協議)協議
- 網路協議協議
- 【網路協議】IP協議、ARP協議、RARP協議協議
- web網路協議Web協議
- 網路協議大全協議
- 簡單談談DNS協議DNS協議
- 一個簡單混合協議通訊列子,物聯網和網際網路通訊。協議
- 網路通訊協議-ICMP協議詳解!協議
- 網路通訊協議-TCP協議詳解!協議TCP
- 網路通訊協議-HTTP協議詳解!協議HTTP
- 網路通訊協議-SMTP協議詳解!協議
- 【網路協議】ICMP協議、Ping、Traceroute協議
- 什麼是協議?| 網路協議定義協議
- 【怒贊】史上最全的網際網路思維精髓總結
- 網路協議 1 - 概述協議
- 網路協議基本概述協議
- 防火牆 | 網路協議防火牆協議
- 網路通訊協議協議
- 網路協議入門協議
- 【網路協議之OSPF】協議
- 網路傳輸協議協議
- 網路協議之TCP協議TCP
- TCP/IP網路協議TCP協議
- 網路七層協議協議
- 計算機網路之TCP/IP協議簡介計算機網路TCP協議
- 網路安全網路協議知識點中,http協議是什麼?協議HTTP
- http 協議集合,超級簡單HTTP協議