SNMP 是什麼協議：管理站、代理與 MIB 怎麼配合

SNMP 是什麼協議？它是 Simple Network Management Protocol 的縮寫，中文叫簡單網路管理協議，由 IETF 制定，用來監控和管理網路中的裝置。交換器、路由器、防火牆、伺服器、BMC、UPS 網路卡、智慧 PDU、精密空調的監控卡，大多內建了 SNMP 代理。監控系統定期向這些代理發請求，讀出連接埠狀態、流量計數、CPU、溫度等數值；裝置出現連接埠斷開、重啟、風扇故障時，代理也會主動發一條 Trap 通知監控系統。它跑在 UDP 上，代理在 161 連接埠接收查詢，監控系統在 162 連接埠接收 Trap。SNMP 最早在 1988 年提出，v1 於 1990 年以 RFC 1157 釋出，幾十年過去，仍是機房裡裝置覆蓋面很廣的監控協議。

SNMP 的三個角色：管理站、代理和 MIB

角色	是什麼	例子
管理站（Manager，也叫 NMS）	發起查詢、接收告警、儲存資料的一方	Zabbix、LibreNMS、Prometheus 的 snmp_exporter，或 net-snmp 的命令列工具
代理（Agent）	執行在被管裝置上，回答查詢、傳送 Trap	交換器內建的 SNMP 代理、Linux 的 snmpd、Windows 的 SNMP 服務、UPS 網路卡韌體
MIB（管理資訊庫）	描述裝置上有哪些物件可讀寫的“資料字典”	IF-MIB（連接埠）、HOST-RESOURCES-MIB（主機資源）、UPS-MIB、各廠商私有 MIB
OID（物件識別符號）	MIB 裡每個物件的編號，相當於它在樹上的路徑	1.3.6.1.2.1.1.5.0 是裝置名 sysName

MIB 把所有物件組織成一棵樹，每個節點有一個數字編號，從樹根一路數下來就是 OID。這棵樹的主幹是這樣的：

1 iso
└─ 3 org
   └─ 6 dod
      └─ 1 internet                     1.3.6.1
         ├─ 2 mgmt
         │  └─ 1 mib-2                  1.3.6.1.2.1     標準 MIB
         │     ├─ 1 system              1.3.6.1.2.1.1   裝置名、描述、執行時長
         │     ├─ 2 interfaces          1.3.6.1.2.1.2   連接埠表
         │     └─ 25 host               1.3.6.1.2.1.25  主機資源：CPU、記憶體、磁碟、程序
         ├─ 4 private
         │  └─ 1 enterprises            1.3.6.1.4.1     廠商私有 MIB，後接各廠商的企業號
         └─ 6 snmpV2
            └─ 3 snmpModules            1.3.6.1.6.3     SNMP 自身的物件，包括 v3 的使用者和檢視

物件分兩種：標量只有一個值，OID 末尾加 .0，例如 sysName.0；表格物件每行一個值，OID 末尾接行索引，例如連接埠表裡的 ifDescr.12 是索引為 12 的那個連接埠的名稱。MIB 檔案只是把數字翻譯成名字的字典，裝置返回的永遠是“OID = 值”。

以一台 Linux 伺服器為例，它上面的 snmpd 就是代理，管理站這樣讀它的裝置名，以及每顆邏輯 CPU 最近一分鐘的負載：

# 標量：裝置名
snmpget -v2c -c 'Rd-Srv-2026' 10.10.0.31 1.3.6.1.2.1.1.5.0
# SNMPv2-MIB::sysName.0 = STRING: web01

# 表格：hrProcessorLoad，每顆邏輯 CPU 一行，值為最近一分鐘的非空閒百分比
snmpwalk -v2c -c 'Rd-Srv-2026' 10.10.0.31 1.3.6.1.2.1.25.3.3.1.2
# HOST-RESOURCES-MIB::hrProcessorLoad.196608 = INTEGER: 7
# HOST-RESOURCES-MIB::hrProcessorLoad.196609 = INTEGER: 12

SNMP 服務是幹什麼的

在伺服器上看到的“SNMP 服務”，就是代理程式：Linux 上是 snmpd，Windows 上服務名為 SNMP（顯示名 SNMP Service），另有一個 SNMPTRAP 服務負責接收 Trap。它的作用只有一個：讓監控系統能透過網路讀到這台機器的狀態。沒有任何監控系統在用 SNMP 採集這台機器，就沒必要開著它。

在 Linux 上讓 snmpd 只對監控伺服器開放，最少兩行配置：

# /etc/snmp/snmpd.conf
# 只監聽管理網位址，不監聽公網位址
agentaddress udp:10.10.0.31:161
# 唯讀團體名，只允許監控伺服器 10.10.0.10 使用
rocommunity Rd-Srv-2026 10.10.0.10

改完執行 systemctl restart snmpd。Windows Server 用 PowerShell 執行 Install-WindowsFeature SNMP-Service 安裝，Windows 10/11 在“可選功能”裡新增。微軟從 Windows Server 2012 起已把 SNMP 服務列為棄用功能，現在仍可安裝，但 Windows 上的新監控方案更多使用 WMI、WinRM 或監控軟體自帶的 agent。

SNMP 的幾種操作：Get、Set、Trap

SNMP 的報文型別很少，這也是它“簡單”的地方：

操作	方向	作用	從哪個版本開始
Get	管理站 → 代理	讀取一個或幾個指定 OID 的值	v1
GetNext	管理站 → 代理	讀取樹上“下一個” OID，snmpwalk 就是反覆用它遍歷整棵子樹	v1
GetBulk	管理站 → 代理	一個請求讀回多行，用於批次遍歷表格	v2c
Set	管理站 → 代理	修改可寫物件，例如關閉連接埠、修改裝置名	v1
Response	代理 → 管理站	對以上請求的應答	v1（當時叫 GetResponse）
Trap	代理 → 管理站	主動通知事件，發出後不等確認	v1，v2c 起改用新格式
Inform	代理 → 管理站	需要接收方確認的通知，沒收到確認會重發	v2c
Report	雙向	v3 內部用來報告錯誤、發現對方的引擎 ID	v3

GetBulk 帶來的效率差別很明顯。讀一台 48 口交換器的連接埠名稱表（假設表裡正好 48 行）：用 GetNext 每次只取一行，48 行要 48 次請求，再加 1 次確認已經走出這張表，一共 49 次往返；用 GetBulk，net-snmp 的 snmpbulkwalk 預設每次取 10 行，5 次往返就夠了。管理站要輪詢幾百台裝置時，這個差距直接決定一輪採集要花多久。

輪詢和 Trap 互為補充。 輪詢按固定間隔讀資料，能畫出曲線、算出流量，但兩次輪詢之間發生又恢復的事件可能被漏掉；Trap 在事件發生時立即發出，但它基於 UDP、沒有確認，網路擁塞或接收端重啟時會丟。常見做法是兩者並用：輪詢採集指標，Trap 接收即時事件，Trap 丟了還有下一次輪詢兜底。

Set 在實際中很少用。 v1、v2c 的團體名明文傳輸，開放寫許可權風險很大，廠商開放的可寫物件也有限。改配置一般走 SSH 命令列或 NETCONF，SNMP 只配唯讀許可權。

SNMP v1、v2c、v3 有什麼區別

對比項	v1	v2c	v3
標準	1990 年，RFC 1157	1996 年，RFC 1901 等	2002 年，RFC 3411～3418
身份驗證	團體名，明文傳輸	團體名，明文傳輸	使用者名稱加認證密碼（USM），HMAC-MD5、HMAC-SHA，較新的實現支援 SHA-2
加密	無	無	可選，DES 或 AES
存取控制	團體名加來源 ACL	同 v1	VACM 檢視，可以按使用者限定能讀哪些 OID 子樹
計數器	只有 32 位	新增 64 位的 Counter64	同 v2c
批次讀取	無	GetBulk	GetBulk
通知	Trap	Trap、Inform	Trap、Inform
錯誤處理	一次請求裡有一個 OID 不存在，整個請求報錯	只在不存在的那個 OID 位置返回 noSuchObject 等異常值，其餘照常返回	同 v2c
現在的定位	基本淘汰	獨立管理網內的主流選擇	跨網路或合規要求高時使用

幾點補充：

• v2c 的“c”是 community（團體）。 團體名就是一個共享口令，在請求裡明文攜帶，抓包就能看到。很多裝置出廠預設的唯讀團體名是 public、讀寫團體名是 private，上線前必須改掉。
• 64 位計數器是放棄 v1 的硬理由。 連接埠位元組計數器 ifHCInOctets 這類 64 位物件只能用 v2c 或 v3 讀取。32 位的位元組計數器到約 43 億位元組就歸零，萬兆口跑滿時約 3.4 秒轉一圈，1 分鐘、5 分鐘的常規輪詢間隔根本接不住。
• v3 有三種安全級別。 noAuthNoPriv 只有使用者名稱，不認證也不加密；authNoPriv 認證但不加密；authPriv 既認證又加密，經過不受信任的網路時用這一級。v3 的每個代理有一個引擎 ID，使用者的金鑰由密碼和引擎 ID 共同生成，修改引擎 ID 後，已配置的使用者通常要重新建立。

SNMP 在機房監控中的位置

機房裡不只有 SNMP 一種採集方式，各有各的分工：

方式	主要物件	擅長	和 SNMP 的關係
SNMP	交換器、路由器、防火牆、UPS、PDU、伺服器	通用的狀態與計數器採集，網路裝置普遍支援	—
IPMI、Redfish	伺服器 BMC	電源控制、溫度、風扇、硬體日誌、遠端控制檯	不少 BMC 也提供 SNMP 唯讀和 Trap，但功能少於 IPMI、Redfish
Syslog	網路裝置、伺服器	文字日誌，排障時還原事件經過	與 Trap 互補：Trap 報“出事了”，日誌說清“怎麼出的事”
NetFlow、sFlow、IPFIX	路由器、交換器	誰和誰在通訊、各佔多少流量	SNMP 只能給出連接埠的總量
流式遙測（Telemetry、gNMI）	較新的資料中心交換器	裝置主動推送，採集頻率可以到秒級	適合大規模、高頻率採集，正在承擔一部分原本由 SNMP 輪詢完成的工作
Modbus	動環：配電櫃、空調、溫溼度感測器	讀取工業裝置的暫存器	部分動環採集器可以把 Modbus 資料以 SNMP 方式提供給上層平台
主機 agent（Zabbix agent、node_exporter）	伺服器作業系統	程序、檔案系統、應用指標，比 SNMP 細	能裝 agent 的伺服器一般優先用 agent

放到 IDC 的日常裡，SNMP 主要承擔三件事：

1. 連接埠流量採集。 定時讀取交換器每個連接埠的 64 位位元組計數器，兩次讀數的差值換算成頻寬，畫出流量曲線，按 5 分鐘取樣算出 95 值，作為頻寬計費和擴容的依據。
2. 裝置健康狀態。 讀取交換器的 CPU、記憶體、溫度、風扇和電源狀態，UPS 的負載率和電池剩餘時間，超過閾值就告警。
3. 事件通知。 接收連接埠 linkDown、linkUp 和裝置 coldStart 等 Trap，第一時間知道哪台裝置出了問題。

它不擅長的事也很明確：分析流量內容要用連接埠映象或流統計，修改配置用 SSH 或 NETCONF，伺服器內部的應用指標交給 agent。

用 SNMP 要注意的安全問題

1. 改掉預設團體名，不用 public、private 這類容易猜到的名字，只配置唯讀許可權。
2. 限定來源。 裝置上用 ACL 只允許監控伺服器存取，代理只監聽管理網位址。
3. UDP 161 不對公網開放。 暴露在外的 SNMP 代理不僅會被猜團體名，還會被拿去做反射放大攻擊。
4. 跨網路用 v3 authPriv，再用 VACM 檢視只開放需要的子樹，例如只開放 system 和 interfaces，不開放路由表和 ARP 表。
5. 關掉不用的代理。 伺服器上沒有系統在採集，就停掉 snmpd 或 Windows 的 SNMP 服務：

# Linux：確認 snmpd 是否在監聽，不用就停掉並取消開機啟動
ss -ulnp 'sport = :161'
systemctl disable --now snmpd

在管理系統裡怎麼落地

在 IDC 的管理系統裡，SNMP 通常只負責“讀”。Toplink DCIM 的交換器管理就是這樣分工的：SNMP 僅用於唯讀採集交換器資料，連接埠開關、VLAN、限速這些配置透過 SSH 或 Telnet 下發，Juniper 系列還支援 NETCONF，所以交換器上只需開放 SNMP 唯讀許可權。DCIM 還提供即時流量圖、異常檢測和網路 TOP 排行，用來定位高佔用節點；流量計費與 95 計費再按週期統計出站、入站、總流量或 95 峰值，用量達到設定比例時自動通知，超量後可以自動限速或關閉連接埠。