聊聊SNMP協議


注:博主 Chloneda個人博客 | 博客園 | Github | Gitee | 知乎

本文源鏈接https://www.cnblogs.com/chloneda/p/snmp-protocol.html

SNMP概述

SNMP(Simple Network Management Protocol):簡單網絡管理協議,是基於TCP/IP五層協議中的應用層協議。由於其簡單可靠,提供了一種監控和管理網絡設備的系統方法,因此受到了眾多廠商的歡迎,成為了目前最為廣泛的網管協議。

SNMP的基本思想:為不同種類、廠家、型號的設備,定義一個統一的接口和協議,使得管理員可以是使用統一的外觀面對這些需要管理的網絡設備。通過網絡,管理員可以管理位於不同物理空間的設備,從而大大提高網絡管理的效率,簡化網絡管理員的工作。

Snmp版本

SNMP目前共有v1,v2,v3這三個版本,三個版本的聯系與區別。

  • SNMP v1:是SNMP協議的最初版本,存在較多安全缺陷,現在這個版本是使用的比較少了。
  • SNMP v2:也采用團體名認證,在兼容SNMPv1的同時又擴充了SNMPv1的功能,具體是擴展了數據類型、支持分布式網絡管理、可以實現大量數據的傳輸,提高了效率和性能、豐富了故障處理能力及增加了集合處理功能。
  • SNMP v3:是最新版本的SNMP。它相對於V2版本,在安全性上得到了重要提升,增加了對認證和密文傳輸的支持。

SNMP核心概念

SNMP管理架構

SNMP管理架構應包含四個部分進行網絡管理:SNMP管理站SNMP代理MIB(管理信息庫)SNMP管理協議

SNMP管理站(management station):通常被稱作為網絡管理工作站(NMS),負責收集維護各個SNMP元素的信息,通過UDP協議向SNMP代理發送各種命令,當SNMP代理收到命令后,對收集的信息進行處理,並返回SNMP管理站需要的參數。而此時被管理對象中一定要有代理進程,這樣才能響應管理站發來的請求。

SNMP代理(Agent):運行在各個被管理的網絡節點之上,負責統計該節點的各項信息,並且負責與SNMP管理站交互,接收並執行管理站的命令,上傳各種本地的網絡信息。

snmp_structure

:協議棧中帶有陰影的部分是原主機或路由器所具有的,而沒有陰影的部分是為實現網絡管理而增加的。

  
MIB(管理信息庫):是對象的集合,它代表網絡中可以管理的資源和設備。每個對象基本上是一個數據變量,它代表被管理的對象的一方面的信息。

SNMP管理協議:用於管理站與SNMP代理之間的通信規則,其SNMP報文格式請查看底下章節。

管理站和代理之間利用 SNMP 報文進行通信,而 SNMP 報文又使用 UDP協議來傳送,由於采用UDP協議,不需要在代理和管理站之間保持連接。
 

SNMP報文格式

管理站(NMS)和代理(Agent)之間交換的管理信息構成了SNMP報文,報文的基本格式如下圖:

snmp_MessageFormat.png

下面將對該SNMP報文格式逐個進行說明!

SNMP消息報文包含兩個部分:SNMP報頭和PDU(協議數據單元)。

SNMP報頭

  • 版本:版本號字段,規則為版本號減 1,如SNMP V1則應寫入 0。如果SNMP代理使用不相同的協議,會直接拋棄與自己協議版本不同的數據報。
  • 共同體(community):即團體名,作為管理進程和代理進程之間的明文口令,相當於密碼,默認為public,該字段可讀可寫,用來限制NMS對Agent的訪問。如果團體名沒有得到NMS/Agent的認可,該報文將被丟棄。
  • PDU 類型:填入 0~4 中的一個數字,其對應關系如圖。

snmp_PDUType.png

PDU類型請參考PDU(協議數據單元)章節!

Get/Set 首部

  • 請求標識符(request ID),這是由管理進程設置的一個整數值。代理進程在發送 get-response 報文時也要返回此請求標識符。管理進程可同時向許多代理發出 get 報文,這些報文都使用 UDP 傳送,先發送的有可能后到達。設置了請求標識符可使管理進程能夠識別返回的響應報文對於哪一個請求。
  • 差錯狀態(error status):由代理進程回答時填入 0~5 中的一個數字,見表 3 的描述。

snmp_ErrorStatus.png

  • 差錯索引(error index):當出現 noSuchName、badValue 或 readOnly 的差錯時,由代理進程在回答時設置的一個整數,它指明有差錯的變量在變量列表中的偏移。

Trap 首部

  • 企業(enterprise):填入 trap 報文的網絡設備的對象標識符。此對象標識符肯定是在圖 3 的對象命名樹上的 enterprise 結點{1.3.6.1.4.1}下面的一棵子樹上。
  • Trap 類型:此字段正式的名稱是 generic-trap,共分為表 4 中的 7 種。

snmp_TrapType.png

當使用上述類型 2、3、5 時,在報文后面變量部分的第一個變量應標識響應的接口。

  • 特定代碼(specific-code):指明代理自定義的時間(若 trap 類型為 6),否則為 0。
  • 時間戳(timestamp):指明自代理進程初始化到 trap 報告的事件發生所經歷的時間,單位為 10ms。例如時間戳為 1908 表明在代理初始化后 1908ms 發生了該時間。
  • 變量綁定(variable-bindings):指明一個或多個變量的名和對應的值。在 get 或 get-next 報文中,變量的值應忽略。

PDU(協議數據單元)

SNMP v1 版本規定了 5 種核心 PDU(協議數據單元),用來在管理進程和代理之間信息的交換。

  • get-request 操作:從代理進程處提取一個OID值。
  • get-next-request 操作:從代理進程(MIB中)處提取緊跟當前參數值的下一個OID值,常被用於檢索表數據,也被用於不能指定名稱的變量,可以瀏覽MIB樹。
  • set-request 操作:設置代理進程的一個或多個參數值。
  • get-response 操作:返回的一個或多個參數值。這個操作是由代理進程發出的,它是前面三種操作的響應操作。
  • trap 操作:代理進程主動發出的報文,通知管理進程有某些事情發生。

前面的 3 種操作是由管理進程向代理進程發出的,后面的 2 個操作是代理進程發給管理進程的,其中代理進程端是用 161 端口接收 get 或 set 報文,而在管理進程端是用 162 端口來接收 trap 報文。

snmp_fivePDU.png

另外,在SNMP v2版本又增加了 3 種PDU(協議數據單元),它們分別是:

  • inform-request 操作:允許路由器向SNMP管理器發送通知請求。
  • getBulk-request 操作:從代理進程處提取多個參數值,該操作會根據最大重試值執行一連串的GetNext操作,減少管理站與代理之間的交互,提高效率。
  • report 操作:

SNMP的操作類型

其實上述 8 種PDU(協議數據單元)按照功能不同,可以歸結為三類操作。

  • 查詢、設置SNMP變量,如get-request、get-next-request、set-request、getBulk-request、inform-request。
  • 應答請求,如 get-response。
  • 事件報告,如trap。

實際上,在SNMP中,SNMP管理站對被管理設備的SNMP變量的操作只能有 兩種基本動作。

ASN.1(抽象語法標記)

ASN.1:高級的數據描述語言。描述數據的類型、結構、組織、及編碼方法。包括符號和語法兩部分。SNMP使用ASN.1描述PDU和MIB(管理信息庫)。

關於ASN.1詳細信息請查看這篇博文:SNMP從入門到開發:進階篇

BER(基本編碼規則)

BER(Basic Encoding Rule),中文名稱:基本編碼規則。描述具體的ASN.1對象如何編碼為比特流在網絡上傳輸。SNMP使用BER(Basic Encoding Rule)作為編碼方案,數據首先先經過BER編碼,再經由傳輸層協議(一邊是UDP)發往接收方。接收方在SNMP端口上收到PDU后,經過BER解碼后,得到具體的SNMP操作數據。

BER的數據都由三個域構成:標識域(tag)+長度域(length)+值域(value)。

SMI(管理信息結構)

SMI(Structure of Managerment Intormation),中文名稱:管理信息結構,是SNMP的描述方法。規定了使用ASN.1子類型、符號。ASN.1功能強大,但SNMP只用到了其中很小一部分,對於這一部分內容的描述,限定了范圍,即為SMI。SMI規定了使用到的ASN.1類型、宏、符號等。SMI是ASN.1的一個子集和超集。

MIB(管理信息庫)

MIB(Management Information Base),中文名稱:管理信息庫,由網絡管理協議訪問的管理對象數據庫。MIB是對象的集合,它代表網絡中可以管理的資源和設備。每個對象基本上是一個數據變量,它代表被管理的對象的一方面的信息。

管理信息庫 MIB 指明了網絡元素所維持的變量(即能夠被管理進程查詢和設置的信息)。MIB 給出了一個網絡中所有可能的被管理對象的集合的數據結構。SNMP 的管理信息庫采用和域名系統 DNS 相似的樹型結構,它的根在最上面,根沒有名字。底下的圖 畫的是管理信息庫的一部分,它又稱為對象命名(object naming tree)。

MIB采用分層樹形結構,對象命名樹的頂級對象有三個,即 ISO、ITU-T 和這兩個組織的聯合體。在 ISO 的下面有 4 個結點,其中的餓一個(標號 3)是被標識的組織。在其下面有一個美國國防部(Department of Defense)的子樹(標號是 6),再下面就是 Internet(標號是 1)。在只討論 Internet 中的對象時,可只畫出 Internet 以下的子樹(圖中帶陰影的虛線方框),並在 Internet 結點旁邊標注上{1.3.6.1}即可。

在 Internet 結點下面的第二個結點是 mgmt(管理),標號是 2。再下面是管理信息庫,原先的結點名是 mib。1991 年定義了新的版本 MIB-II,故結點名現改為 mib-2,其標識為{1.3.6.1.2.1},或{Internet(1) .2.1}。這種標識為對象標識符。

snmp_Mib.png

最初的結點 mib 將其所管理的信息分為 8 個類別,如圖,現在的 mib-2 所包含的信息類別已超過 40 個。

snmp_MibInfoType.png

應當指出,MIB 的定義與具體的網絡管理協議無關,這對於廠商和用戶都有利。廠商可以在產品(如路由器)中包含 SNMP 代理軟件,並保證在定義新的 MIB 項目后該軟件仍遵守標准。用戶可以使用同一網絡管理客戶軟件來管理具有不同版本的 MIB 的多個路由器。當然,一個沒有新的 MIB 項目的路由器不能提供這些項目的信息。這里要提一下MIB中的對象{1.3.6.1.4.1},即enterprises(企業),其所屬結點數已超過 3000。例如IBM為{1.3.6.1.4.1.2},Cisco為{1.3.6.1.4.1.9},Novell為{1.3.6.1.4.1.23}等。世界上任何一個公司、學校只要用電子郵件發往iana-mib@isi.edu進行申請即可獲得一個結點名。這樣各廠家就可以定義自己的產品的被管理對象名,使它能用SNMP進行管理。

ASN.1、BER、SMI、MIB、PDU的關系

關於ASN.1、BER、SMI、MIB、PDU的關系如下圖所示。
snmp_SMI_MIB.png

OID(對象標識符)

OID(Object Identifier),中文名稱:對象標識符,被管理設備的每個管理資源和對象都有自己的OID(Object Identifier),管理對象通過樹狀結構進行組織,OID由樹上的一系列整數組成,整數之間用點( . )分隔開,樹的葉子節點才是真正能夠被管理的對象。

常用OID

這里總結了一些常用的OID,當需要時可以及時查詢。
SNMP監控常用OID查詢
SNMP監控一些常用OID的總結
下載不同廠商的MIB包
查看不同廠商的OID代號

SNMP協議實現

SNMP協議的Java實現是SNMP4J,其jar包可以在SNMP官方網站上下載。開發前請簡單了解一下SNMP4J,具體細節請看這篇博文:SNMP4J介紹;更多SNMP4J示例請參考Github

本文小結

SNMP支持Window、Linux、MacOS系統的安裝,關於SNMP的安裝步驟請自行查詢。



免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM