SNMP 协议深度解析：从原理到实践的全方位指南

刘马想放假
0 阅读32分钟

本文面向网络工程师、系统管理员、DevOps 从业者以及对网络管理协议有深度理解需求的技术人员，系统性地剖析 SNMP（Simple Network Management Protocol）的完整技术体系。

目录

  1. 引言：为什么需要 SNMP
  2. SNMP 架构模型
  3. 协议栈与传输机制
  4. 版本演进：v1 / v2c / v3
  5. 管理信息库 MIB
  6. 对象标识符 OID
  7. PDU 协议数据单元
  8. 核心操作详解
  9. SNMPv3 安全体系
  10. 数据包分析与抓包实践
  11. SNMP Walk：MIB 树遍历
  12. Trap 与 Inform：异步通知
  13. 配置实践与命令行工具
  14. 完整监控工作流
  15. 常见问题与故障排查
  16. 总结与最佳实践

1. 引言：为什么需要 SNMP

SNMP（Simple Network Management Protocol，简单网络管理协议）是 TCP/IP 协议族中最重要的应用层协议之一，自 1988 年首次标准化以来，已成为网络设备监控与管理的事实标准。无论是数据中心的核心路由器、企业的接入交换机，还是服务器的硬件状态，SNMP 都提供了统一的查询与管理接口。

1.1 网络管理的三大挑战

在 SNMP 出现之前，网络管理面临三个根本性难题：

挑战具体表现SNMP 的解决方案
异构性不同厂商设备使用各自的私有协议定义统一的协议标准和数据格式
可扩展性管理工具难以适应新设备类型通过 MIB 树结构动态扩展管理对象
实时性故障发现滞后，被动式运维支持周期性轮询 + 主动 Trap 告警

1.2 SNMP 的核心价值

  • 标准化：RFC 标准定义，所有主流网络设备厂商均支持
  • 低开销：基于 UDP 传输，协议本身简洁高效
  • 可扩展：MIB 树结构允许厂商自定义私有扩展
  • 成熟生态：Net-SNMP、Zabbix、Nagios、SolarWinds 等工具链完善

2. SNMP 架构模型

SNMP 采用经典的 管理者-代理（Manager-Agent）模型。这一模型将网络管理功能清晰地划分为两个角色，通过标准化的协议进行交互。

SNMP Network Management Architecture

2.1 核心组件

2.1.1 NMS（Network Management Station，网络管理站）

NMS 是运行网络管理软件的中央服务器或工作站，负责：

  • 发起 SNMP 请求（Get / Set / GetNext / GetBulk）
  • 接收并处理 Agent 发送的 Trap / Inform 通知
  • 维护管理数据库，生成报表和告警
  • 提供可视化界面供管理员操作

典型的 NMS 软件包括 Zabbix、PRTG、SolarWinds NPM、Nagios 等。

2.1.2 Agent（代理）

Agent 是运行在被管理设备上的软件模块，负责：

  • 响应 NMS 的 SNMP 请求，返回本地 MIB 中的数据
  • 监听本地系统状态变化，主动发送 Trap 通知
  • 维护本地 MIB 数据结构的实时值

大多数网络设备（路由器、交换机、防火墙）出厂即内置 SNMP Agent。Linux 系统可通过 snmpd（Net-SNMP 套件）启用 Agent 功能。

2.1.3 MIB（Management Information Base，管理信息库）

MIB 是一套层次化的数据结构定义，描述了设备上所有可被管理的数据对象。Agent 根据 MIB 定义来组织和管理本地数据。

2.1.4 被管对象（Managed Objects）

每个被管对象对应设备上的一个具体属性，例如：

  • sysDescr — 系统描述字符串
  • ifInOctets — 接口接收字节数
  • hrProcessorLoad — CPU 负载百分比

2.2 通信模式

SNMP 定义了两种通信模式：

  1. 请求-响应模式（Pull）：NMS 主动向 Agent 发送 Get / Set 请求，Agent 返回 GetResponse。基于 UDP 端口 161。

  2. 异步通知模式（Push）：Agent 检测到预设事件后，主动向 NMS 发送 Trap 或 Inform。基于 UDP 端口 162。

3. 协议栈与传输机制

SNMP 是一个纯粹的应用层协议，其协议栈设计遵循了极简主义原则。

SNMP Protocol Stack

3.1 协议层次

SNMP 消息封装遵循以下层次结构（自顶向下）：

+---------------------------+
|      SNMP Application     |  Get/Set/Trap PDU
+---------------------------+
|      UDP (Port 161/162)   |  Connectionless transport
+---------------------------+
|      IP                   |  Network layer routing
+---------------------------+
|      Data Link / Physical |  Ethernet / WiFi / Fiber
+---------------------------+

3.2 为什么选择 UDP

SNMP 选择 UDP 而非 TCP，主要基于以下考量：

  • 低开销：UDP 头部仅 8 字节，无需连接建立和维护
  • 快速超时：UDP 无连接特性使得请求超时检测更直接
  • 简单模型：请求-响应模型天然适合无状态传输
  • 广泛兼容：即使资源受限的嵌入式设备也能轻松实现

代价是 UDP 不保证可靠性，因此 SNMP 在应用层实现了简单的超时重传机制。

3.3 端口分配

端口用途方向
UDP 161SNMP Agent 监听端口NMS → Agent（请求） / Agent → NMS（响应）
UDP 162SNMP Trap 接收端口Agent → NMS（Trap/Inform）

在 SNMPv3 中，端口分配保持不变，但消息格式增加了安全参数。

4. 版本演进：v1 / v2c / v3

SNMP 自诞生以来经历了三个主要版本，每个版本都在安全性、功能性和性能上有所演进。

SNMP Version Evolution & Comparison

4.1 SNMPv1（1988，RFC 1155-1157）

SNMPv1 是最初的标准化版本，定义了协议的基本框架：

  • 安全机制：基于 Community String（团体字符串）的明文认证
  • PDU 类型：GetRequest、GetNextRequest、SetRequest、GetResponse、Trap
  • 编码方式：ASN.1 BER（Basic Encoding Rules）

局限性：

  • Community String 以明文传输，极易被窃听
  • 无数据完整性校验
  • 不支持批量数据获取（每次请求只能获取一个 OID）

4.2 SNMPv2c（1993，RFC 1901-1908）

SNMPv2c 是 SNMPv2 的 "Community-based" 版本，保留了 v1 的社区字符串认证，但引入了重要的功能性改进：

  • GetBulkRequest：支持批量数据获取，大幅提升表数据检索效率
  • InformRequest：支持带确认的通知机制
  • 错误码扩展：更丰富的错误状态码（noAccess、wrongType、wrongLength 等）
  • 64 位计数器：Counter64 类型，避免高速接口计数器溢出

SNMPv2c 是实际部署中最广泛的版本，但安全模型与 v1 相同，仍是明文传输。

4.3 SNMPv3（2002，RFC 3411-3418）

SNMPv3 是协议的重大升级，核心贡献在于引入了 模块化安全框架：

  • USM（User-based Security Model，基于用户的安全模型）：提供认证和加密
  • VACM（View-based Access Control Model，基于视图的访问控制模型）：精细化权限控制
  • EngineID（引擎标识符）：唯一标识每个 SNMP 实体，支持本地化密钥
  • 时间同步：通过 msgAuthoritativeEngineBoots 和 msgAuthoritativeEngineTime 防止重放攻击

4.4 版本选择建议

场景推荐版本理由
实验室/测试环境v2c配置简单，功能完整
内部可信网络v2c + ACL平衡安全性与易用性
生产环境 / 互联网暴露v3唯一提供加密和认证的标准方案
合规要求（金融/政府）v3 authPriv满足数据保护和审计要求

安全警示：在任何不受信任的网络环境中，绝对禁止使用 SNMPv1/v2c。社区字符串的明文传输使得中间人攻击轻而易举。

5. 管理信息库 MIB

MIB 是 SNMP 体系中最为核心的概念之一。它定义了一个层次化的命名空间，所有网络设备上的可管理对象都在这个命名空间中被唯一标识。

Management Information Base (MIB) Tree Structure

5.1 MIB 树的根结构

MIB 树以 ISO（国际标准化组织）的标准对象标识符体系为根：

root (1)
  └── iso (1.3)
        └── org (1.3.6)
              └── dod (1.3.6.1)  [Department of Defense]
                    └── internet (1.3.6.1)
                          ├── directory (1.3.6.1.1)
                          ├── mgmt (1.3.6.1.2)        ← 标准管理对象
                          ├── experimental (1.3.6.1.3)
                          ├── private (1.3.6.1.4)     ← 厂商私有对象
                          └── security (1.3.6.1.5)

5.2 关键子树

5.2.1 mgmt 子树（1.3.6.1.2）

mgmt 子树包含 IETF 标准化的管理对象。其中最重要的是 MIB-II（1.3.6.1.2.1），定义于 RFC 1213，包含以下主要分组：

组 OID组名管理内容
.1system系统描述、联系人、位置、服务集
.2interfaces网络接口信息、状态、流量计数器
.3at地址转换表（已废弃）
.4ipIP 路由、地址、统计、ICMP/ARP
.5icmpICMP 报文统计
.6tcpTCP 连接表、重传、状态
.7udpUDP 监听端口和统计
.11snmpSNMP 自身统计（接收/发送包数、错误数）

5.2.2 private / enterprises 子树（1.3.6.1.4.1）

private 子树下的 enterprises 节点用于分配厂商私有 OID。每个向 IANA 注册的厂商都会获得一个唯一的企业号：

企业号厂商OID 前缀
9Cisco1.3.6.1.4.1.9
2011Huawei1.3.6.1.4.1.2011
2636Juniper1.3.6.1.4.1.2636
311Microsoft1.3.6.1.4.1.311
8072Net-SNMP1.3.6.1.4.1.8072

5.3 SMI（Structure of Management Information）

SMI（RFC 2578）定义了 MIB 的语法规则：

  • 模块定义：使用 MODULE-IDENTITY 宏定义 MIB 模块
  • 对象类型：使用 OBJECT-TYPE 宏定义被管对象
  • 通知类型：使用 NOTIFICATION-TYPE 宏定义 Trap
  • 数据类型：
    • 简单类型：INTEGER、OCTET STRING、OBJECT IDENTIFIER、NULL
    • 应用类型：IpAddress、Counter32、Gauge32、TimeTicks、Opaque、Counter64

5.4 MIB 文件格式示例

MY-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, Integer32
        FROM SNMPv2-SMI
    DisplayString
        FROM SNMPv2-TC;

myModule MODULE-IDENTITY
    LAST-UPDATED "202406020000Z"
    ORGANIZATION "Example Corp"
    CONTACT-INFO "support@example.com"
    DESCRIPTION  "Example custom MIB module"
    ::= { enterprises 99999 }

myObject OBJECT-TYPE
    SYNTAX      Integer32 (0..100)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION "Custom temperature sensor reading in Celsius"
    ::= { myModule 1 }

END

6. 对象标识符 OID

OID（Object Identifier）是 MIB 树中每个节点的唯一数字地址。理解 OID 的结构和工作原理，是掌握 SNMP 的核心技能。

Object Identifier (OID) Structure

6.1 OID 表示法

OID 采用 点分十进制表示法（dot-decimal notation），从根节点到目标节点的路径上所有节点编号依次连接：

1.3.6.1.2.1.1.1.0
│ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ └── 实例标识符（Scalar 类型固定为 .0）
│ │ │ │ │ │ │ └──── sysDescr 对象（系统描述）
│ │ │ │ │ │ └────── system 组
│ │ │ │ │ └──────── MIB-II（mgmt 下的标准管理对象）
│ │ │ │ └────────── mgmt 子树
│ │ │ └──────────── internet 子树
│ │ └────────────── dod（Department of Defense）
│ └──────────────── org
└────────────────── iso（根节点下）

6.2 实例标识符（Instance Identifier）

OID 的最后一段是实例标识符，用于精确定位对象值：

标量对象（Scalar）：

  • 固定附加 .0 作为实例标识符
  • 例：sysDescr.0 = 1.3.6.1.2.1.1.1.0
  • 原因：标量对象在逻辑上只有一个实例

表列对象（Columnar / Table）：

  • 附加表索引值作为实例标识符
  • 例：ifDescr.1 = 1.3.6.1.2.1.2.2.1.2.1（第 1 个接口的描述）
  • 例：ifDescr.2 = 1.3.6.1.2.1.2.2.1.2.2（第 2 个接口的描述）

6.3 常用 OID 速查表

OID（数字）OID（名称）含义数据类型
1.3.6.1.2.1.1.1.0sysDescr.0系统描述OCTET STRING
1.3.6.1.2.1.1.3.0sysUpTime.0系统运行时间（百分之一秒）TimeTicks
1.3.6.1.2.1.1.5.0sysName.0系统主机名OCTET STRING
1.3.6.1.2.1.2.2.1.2.NifDescr.N第 N 个接口描述OCTET STRING
1.3.6.1.2.1.2.2.1.10.NifInOctets.N第 N 个接口接收字节数Counter32
1.3.6.1.2.1.2.2.1.16.NifOutOctets.N第 N 个接口发送字节数Counter32
1.3.6.1.2.1.25.1.1.0hrSystemUptime.0主机运行时间TimeTicks
1.3.6.1.2.1.25.1.6.0hrSystemProcesses.0进程数量Gauge32
1.3.6.1.2.1.25.3.3.1.2.NhrProcessorLoad.N第 N 个 CPU 负载Integer32
1.3.6.1.4.1.2021.4.5.0memTotalReal.0物理内存总量（KB）Integer32
1.3.6.1.4.1.2021.4.6.0memAvailReal.0可用物理内存（KB）Integer32

6.4 OID 解析流程

当 NMS 向 Agent 发送 OID 查询请求时，Agent 执行以下步骤：

  1. 解析接收到的 OID 数字序列
  2. 在本地 MIB 树中逐层匹配节点
  3. 定位到具体的被管对象定义
  4. 读取对应的运行时值
  5. 将值封装到 GetResponse PDU 中返回

如果 OID 不存在或实例标识符缺失，Agent 返回 noSuchName（v1）或 noSuchObject / noSuchInstance（v2c/v3）错误。

7. PDU 协议数据单元

PDU（Protocol Data Unit）是 SNMP 消息的有效载荷部分，承载了具体的操作指令和数据。

SNMPv1/v2c PDU Format

7.1 SNMPv1/v2c PDU 结构

所有 SNMPv1/v2c 的 PDU 共享相同的基本结构：

+--------------------------------------------------+
| PDU Type        | INTEGER (Get/Set/Trap/...)     |  标识操作类型
+-----------------+----------------------------------+
| Request ID      | INTEGER                          |  请求-响应配对
+-----------------+----------------------------------+
| Error Status    | INTEGER (0=noError, 1=tooBig...) |  错误码
+-----------------+----------------------------------+
| Error Index     | INTEGER                          |  出错 VarBind 索引
+-----------------+----------------------------------+
| Variable        | SEQUENCE of VarBind              |  OID-值绑定列表
| Bindings        |                                  |
+--------------------------------------------------+

7.2 VarBind（变量绑定）

VarBind 是 PDU 的核心数据结构，每个 VarBind 包含一对 OID 和对应的值：

VarBind ::= SEQUENCE {
    name  ObjectSyntax,     -- OID
    value ObjectSyntax      -- 值（或 NULL 在请求中）
}

在 GetRequest 中，value 字段为 NULL（占位符）；在 GetResponse 中，value 字段填充实际数据。

7.3 PDU 类型编码

PDU 类型BER 标签值适用版本
GetRequestCONTEXT [0]0xA0v1/v2c/v3
GetNextRequestCONTEXT [1]0xA1v1/v2c/v3
GetResponseCONTEXT [2]0xA2v1/v2c/v3
SetRequestCONTEXT [3]0xA3v1/v2c/v3
Trap (v1)CONTEXT [4]0xA4v1 only
GetBulkRequestCONTEXT [5]0xA5v2c/v3
InformRequestCONTEXT [6]0xA6v2c/v3
SNMPv2-TrapCONTEXT [7]0xA7v2c/v3
ReportCONTEXT [8]0xA8v3

7.4 SNMPv3 消息格式

SNMPv3 在 PDU 外增加了安全封装层：

+--------------------------------------------------+
| msgVersion      | INTEGER (3)                      |
+-----------------+----------------------------------+
| msgGlobalData   | HeaderData                       |
|   - msgID       | INTEGER                          |
|   - msgMaxSize  | INTEGER                          |
|   - msgFlags    | OCTET STRING (authPriv flags)    |
|   - msgSecurityModel | INTEGER (USM=3)             |
+-----------------+----------------------------------+
| msgSecurityParameters | OCTET STRING               |
|   (USM parameters: authKey, privKey, engineID...)  |
+-----------------+----------------------------------+
| msgData         | ScopedPDU                        |
|   - contextEngineID | OCTET STRING                 |
|   - contextName     | OCTET STRING                 |
|   - data            | PDU (plaintext or encrypted) |
+--------------------------------------------------+

7.5 ASN.1 BER 编码

SNMP 使用 ASN.1（Abstract Syntax Notation One）的 BER 编码规则对消息进行二进制序列化：

每个数据元素编码为 TLV（Type-Length-Value）三元组：

+--------+--------+---------+
|  Tag   | Length |  Value  |
| 1 byte | 1-4 bytes | N bytes |
+--------+--------+---------+
  • Tag：标识数据类型（INTEGER=0x02, OCTET STRING=0x04, NULL=0x05, OID=0x06, SEQUENCE=0x30）
  • Length：Value 字段的字节数
  • Value：实际数据内容

OID 的 Value 字段采用相对编码：第一个字节编码前两个节点（40 * 第一个节点 + 第二个节点），后续节点使用可变长度整数编码。

8. 核心操作详解

SNMP 定义了七种 PDU 类型，覆盖了查询、修改、通知等全部管理操作。

SNMP Core Operations

8.1 GetRequest / GetResponse

GetRequest 是最基础的查询操作，用于获取一个或多个 OID 的当前值。

工作流程：

  1. NMS 构造 GetRequest PDU，包含目标 OID 列表（VarBindList 中 value 为 NULL）
  2. NMS 发送 UDP 报文到 Agent 的 161 端口
  3. Agent 解析 OID，在本地 MIB 中查找对应值
  4. Agent 构造 GetResponse PDU，填充查询结果
  5. Agent 发送响应到 NMS

示例（Net-SNMP 命令行）：

# 查询单个 OID
snmpget -v 2c -c public 192.168.1.1 1.3.6.1.2.1.1.1.0

# 查询多个 OID
snmpget -v 2c -c public 192.168.1.1 sysDescr.0 sysName.0 sysUpTime.0

返回值：

SNMPv2-MIB::sysDescr.0 = STRING: "Cisco IOS Software, C880 Software..."
SNMPv2-MIB::sysName.0 = STRING: "router-core-01"
SNMPv2-MIB::sysUpTime.0 = Timeticks: (1234567) 14 days, 6:56:07.00

8.2 GetNextRequest

GetNextRequest 获取指定 OID 在 MIB 树中 字典序下一个 的 OID 及其值。这是实现 MIB 遍历的核心机制。

关键特性：

  • 不需要知道精确的 OID，只需指定起始点
  • 返回的 OID 可能与请求的 OID 不在同一子树中
  • 当遍历完整个 MIB 后，返回 EndOfMibView

示例：

# 获取 system 组之后的下一个对象
snmpgetnext -v 2c -c public 192.168.1.1 1.3.6.1.2.1.1

8.3 GetBulkRequest

GetBulkRequest（v2c/v3 特有）是 GetNext 的批量优化版本，通过一个请求获取多个连续 OID 的值。

参数定义：

参数含义典型值
non-repeaters请求列表前 N 个 OID 只获取一个值0
max-repetitions其余 OID 各获取的最大连续值数10

示例：

# 获取 ifTable 中各列的前 10 行
snmpbulkget -v 2c -c public -Cn0 -Cr10 192.168.1.1 ifDescr ifInOctets ifOutOctets

GetBulk 显著减少了遍历大表时的网络往返次数。例如，一个包含 48 个接口的 ifTable：

  • 使用 GetNext：需要 48 次请求-响应往返
  • 使用 GetBulk（max-rep=10）：约 5 次请求即可获取全部数据

8.4 SetRequest

SetRequest 用于修改 Agent 上的可写对象值，是 SNMP 中唯一具有"写"语义的操作。

安全考量：

  • Set 操作可能导致设备配置变更甚至重启
  • 大多数设备默认禁用 Set，或限制在特定社区字符串
  • SNMPv3 的 VACM 可精确控制哪些用户/组具有 Set 权限

示例：

# 修改系统联系人（需设备支持且配置写权限）
snmpset -v 2c -c private 192.168.1.1 sysContact.0 s "admin@company.com"

# v3 版本
snmpset -v 3 -u admin -l authPriv -a SHA -A adminpass -x AES -X encryptkey \
  192.168.1.1 sysContact.0 s "admin@company.com"

8.5 Trap

Trap 是 Agent 主动向 NMS 发送的异步通知，用于报告重要事件。

SNMPv1 Trap 特有字段：

字段说明
enterprise发送 Trap 的企业 OID
agent-addrAgent 的 IP 地址
generic-trap通用陷阱类型（0-6）
specific-trap厂商特定陷阱代码
time-stamp自系统启动到 Trap 发生的时间

通用 Trap 类型（v1）：

代码名称含义
0coldStartAgent 重新初始化，配置可能改变
1warmStartAgent 重新初始化，配置不变
2linkDown接口从 up 变为 down
3linkUp接口从 down 变为 up
4authenticationFailure收到非法 Community String
5egpNeighborLossEGP 邻居关系丢失
6enterpriseSpecific厂商自定义事件

v2c/v3 Trap 使用 SNMPv2-Trap-PDU 格式，与 Inform 结构相同，但没有响应要求。

8.6 InformRequest

InformRequest 与 Trap 类似，但要求 NMS 发送确认响应。

特点：

  • 可靠性高于 Trap（丢包可重试）
  • 增加了 NMS 的处理开销
  • Agent 需要维护重传状态
  • 仅 v2c 和 v3 支持

9. SNMPv3 安全体系

SNMPv3 的安全框架由两个核心模块构成：USM（用户安全模型）和 VACM（视图访问控制模型）。

SNMPv3 Security Architecture

9.1 USM（User-based Security Model，RFC 3414）

USM 提供三个安全级别：

9.1.1 noAuthNoPriv

  • 无认证，无加密
  • 仅通过用户名（securityName）识别用户
  • 安全性与 SNMPv1/v2c 的 community string 相当
  • 不推荐用于生产环境

9.1.2 authNoPriv

  • 提供认证，无加密
  • 认证算法：HMAC-MD5、HMAC-SHA、HMAC-SHA-256
  • 消息完整性校验：防止篡改
  • 抗重放攻击：通过时间窗口和引擎启动次数校验

9.1.3 authPriv

  • 提供认证 + 加密
  • 认证算法同 authNoPriv
  • 加密算法：CBC-DES、CFB-AES-128、3DES
  • 数据保密性：PDU 内容在传输中加密
  • 生产环境唯一推荐的安全级别

9.2 USM 密钥本地化

SNMPv3 使用 本地化密钥（Localized Key） 机制增强安全性：

LocalizedKey = Hash(MasterKey + EngineID)
  • Master Key：由用户密码通过扩展哈希算法生成
  • EngineID：每个 SNMP 引擎（Agent）的唯一标识符
  • 效果：同一密码在不同 Agent 上产生不同的本地化密钥，即使一个 Agent 的密钥泄露，也不影响其他 Agent

9.3 VACM（View-based Access Control Model，RFC 3415）

VACM 提供了精细化的访问控制能力，基于三张配置表实现：

9.3.1 vacmSecurityToGroupTable

将安全模型 + 安全名称映射到组名：

snmpVacmMIBObjects (1.3.6.1.6.3.16.1.2)
  └── vacmSecurityToGroupTable (1)
        └── vacmSecurityToGroupEntry (1)
              ├── vacmSecurityModel   (1)  -- 1=v1, 2=v2c, 3=usm
              ├── vacmSecurityName    (2)  -- 用户名/社区名
              └── vacmGroupName       (3)  -- 映射到的组名

9.3.2 vacmAccessTable

定义每个组在不同安全级别下的访问权限：

vacmAccessTable (2)
  └── vacmAccessEntry (1)
        ├── vacmGroupName             (1)
        ├── vacmAccessContextPrefix   (2)
        ├── vacmAccessSecurityModel   (3)
        ├── vacmAccessSecurityLevel   (4)  -- noAuthNoPriv/authNoPriv/authPriv
        ├── vacmAccessContextMatch    (5)  -- exact/prefix
        ├── vacmAccessReadViewName    (6)  -- 读视图名称
        ├── vacmAccessWriteViewName   (7)  -- 写视图名称
        └── vacmAccessNotifyViewName  (8)  -- 通知视图名称

9.3.3 vacmViewTreeFamilyTable

定义视图包含或排除的 OID 子树：

vacmViewTreeFamilyTable (5)
  └── vacmViewTreeFamilyEntry (1)
        ├── vacmViewTreeFamilyViewName   (1)  -- 视图名称
        ├── vacmViewTreeFamilySubtree    (2)  -- OID 子树
        └── vacmViewTreeFamilyType       (3)  -- included(1) / excluded(2)

9.4 VACM 访问决策流程

当 SNMPv3 Agent 收到请求时，按以下步骤进行访问控制判断：

  1. 从消息中提取 securityModel 和 securityName
  2. 在 vacmSecurityToGroupTable 中查找对应的 groupName
  3. 使用 groupName + contextName + securityModel + securityLevel 查询 vacmAccessTable
  4. 根据请求类型（Get/Set/Notify）确定使用的视图名称
  5. 在 vacmViewTreeFamilyTable 中检查请求的 OID 是否落在视图允许的子树范围内
  6. 通过则执行操作，拒绝则返回 noAccess 错误

9.5 SNMPv3 配置示例

# 创建用户（Net-SNMP）
net-snmp-create-v3-user -ro -A authpass -a SHA -X privpass -x AES admin

# 命令行查询
snmpget -v 3 -u admin -l authPriv -a SHA -A authpass -x AES -X privpass \
  192.168.1.1 sysDescr.0

# 参数说明
# -v 3         : SNMPv3
# -u admin     : 用户名
# -l authPriv  : 安全级别（authNoPriv / authPriv / noAuthNoPriv）
# -a SHA       : 认证算法（MD5 / SHA / SHA-256）
# -A authpass  : 认证密码
# -x AES       : 加密算法（DES / AES / 3DES）
# -X privpass  : 加密密码

10. 数据包分析与抓包实践

理解 SNMP 数据包的实际结构，对于故障排查和安全审计至关重要。

SNMP Packet Analysis — Wireshark Dissection

10.1 数据包层次解析

一个完整的 SNMPv2c GetRequest 数据包包含以下层次：

10.1.1 以太网帧头（14 字节）

目的 MAC: 00:50:56:c0:00:08
源 MAC:   00:0c:29:3e:5a:1b
类型:     0x0800 (IPv4)

10.1.2 IP 报头（20 字节）

版本:     4 (IPv4)
头长:     5 (20 bytes)
协议:     17 (UDP)
源 IP:    192.168.1.1
目的 IP:  192.168.1.2
TTL:      64

10.1.3 UDP 报头（8 字节）

源端口:   161
目的端口: 161
长度:     66 bytes
校验和:   0x0000 (optional, may be disabled)

10.1.4 SNMP 消息体（ASN.1 BER 编码）

SEQUENCE {
  INTEGER 1                          -- Version: v2c
  OCTET STRING "public"              -- Community String
  GetRequest-PDU {
    INTEGER 1515875537               -- Request ID
    INTEGER 0                        -- Error Status: noError
    INTEGER 0                        -- Error Index: 0
    VarBindList {
      VarBind {
        OID 1.3.6.1.2.1.1.1.0        -- sysDescr.0
        NULL                         -- Placeholder
      }
    }
  }
}

10.2 BER 编码实战解读

以 sysDescr.0 查询为例：

Hex Dump: 30 36 02 01 01 04 06 70 75 62 6c 69 63 a0 29 ...

30 36        -- SEQUENCE, length = 54 bytes (整个 SNMP 消息)
  02 01 01   -- INTEGER, 1 byte, value = 1 (Version: v2c)
  04 06 ...  -- OCTET STRING, 6 bytes, "public" (Community)
  a0 29      -- CONTEXT [0], 41 bytes (GetRequest PDU)
    02 04 ... -- INTEGER, 4 bytes (Request ID)
    02 01 00  -- INTEGER, 1 byte, 0 (Error Status: noError)
    02 01 00  -- INTEGER, 1 byte, 0 (Error Index)
    30 1b     -- SEQUENCE, 27 bytes (VarBindList)
      30 19   -- SEQUENCE, 25 bytes (VarBind)
        06 0e -- OID, 14 bytes
          2b 06 01 02 01 01 01 00
          -- 解码: 2b = 1.3, 06 = 6, 01 = 1, 02 = 2, 01 = 1, 01 = 1, 01 = 1, 00 = 0
          -- 完整 OID: 1.3.6.1.2.1.1.1.0
        05 00 -- NULL, 0 bytes (请求中的占位符)

10.3 Wireshark 过滤技巧

# 基础过滤：所有 SNMP 流量
snmp

# 按端口过滤
udp.port == 161 || udp.port == 162

# 按 Community String 过滤（检测明文传输）
snmp.community == "public"

# 按版本过滤
snmp.version == 0    # v1
snmp.version == 1    # v2c
snmp.version == 3    # v3

# 按 PDU 类型过滤
snmp.pdu_type == 0   # GetRequest
snmp.pdu_type == 1   # GetNextRequest
snmp.pdu_type == 3   # SetRequest

# 检测异常：大量 Set 请求（可能的安全事件）
snmp.pdu_type == 3

# v3 认证失败
snmp.version == 3 && snmp.error_status != 0

10.4 安全审计要点

使用抓包工具审计 SNMP 流量时，重点关注：

  1. 明文社区字符串：检查是否仍有 v1/v2c 流量，社区字符串是否使用默认的 public / private
  2. 未授权的 Set 操作：SetRequest 应仅来自可信 NMS 源
  3. 异常的访问模式：短时间内大量请求可能表明扫描或暴力破解
  4. Trap 方向：确认 Trap 仅发送到授权的 NMS 地址

11. SNMP Walk：MIB 树遍历

SNMP Walk 是最常用的管理操作之一，通过迭代 GetNext 实现对整个 MIB 子树的遍历。

SNMP Walk: Sequential MIB Tree Traversal using GetNext

11.1 GetNext 遍历原理

Walk 的核心算法非常简单但精妙：

# 伪代码表示 Walk 算法
def snmp_walk(agent, starting_oid):
    current_oid = starting_oid
    results = []

    while True:
        response = snmp_getnext(agent, current_oid)

        if response.value == EndOfMibView:
            break

        if not is_descendant(response.oid, starting_oid):
            break  # 已遍历出起始子树范围

        results.append(response)
        current_oid = response.oid

    return results

关键行为：

  1. 从指定起始 OID 开始发送 GetNext 请求
  2. Agent 返回字典序下一个 OID 及其值
  3. 使用返回的 OID 作为下一个请求的起点
  4. 当返回值超出起始子树范围，或返回 EndOfMibView 时停止

11.2 Walk 实例演示

假设查询 system 组（1.3.6.1.2.1.1）：

步骤请求 OIDAgent 行为响应 OID值
11.3.6.1.2.1.1查找 system 组后的第一个对象1.3.6.1.2.1.1.1.0"Linux router"
21.3.6.1.2.1.1.1.0查找 sysDescr.0 后的下一个1.3.6.1.2.1.1.2.01.3.6.1.4.1.9.1.1
31.3.6.1.2.1.1.2.0查找 sysObjectID.0 后的下一个1.3.6.1.2.1.1.3.01234567
41.3.6.1.2.1.1.3.0查找 sysUpTime.0 后的下一个1.3.6.1.2.1.1.4.0"admin@example.com"
51.3.6.1.2.1.1.4.0查找 sysContact.0 后的下一个1.3.6.1.2.1.1.5.0"CoreRouter"
...............
N1.3.6.1.2.1.1.X.Ysystem 组已无后续对象EndOfMibView停止

11.3 snmpwalk vs snmpbulkwalk

特性snmpwalk（GetNext）snmpbulkwalk（GetBulk）
协议版本v1 / v2c / v3v2c / v3
每次请求获取 OID 数1 个N 个（默认 10）
遍历 48 接口 ifTable 所需往返~48 次~5 次
对 Agent 的负载低（请求简单）较高（单次处理量大）
兼容性所有设备部分旧设备可能不支持

命令示例：

# 使用 GetNext 遍历（兼容性好，速度慢）
snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1

# 使用 GetBulk 遍历（推荐，速度快）
snmpbulkwalk -v 2c -c public -Cn0 -Cr25 192.168.1.1 1.3.6.1.2.1

# v3 版本
snmpwalk -v 3 -u admin -l authPriv -a SHA -A pass -x AES -X pass \
  192.168.1.1 1.3.6.1.2.1.2.2  # ifTable only

11.4 遍历特定子树

# 仅遍历接口表
snmpwalk -v 2c -c public 192.168.1.1 ifTable

# 仅遍历 TCP 连接表
snmpwalk -v 2c -c public 192.168.1.1 tcpConnTable

# 遍历厂商私有 MIB
snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.4.1.9  # Cisco

12. Trap 与 Inform：异步通知

Trap 和 Inform 是 SNMP 的"推"模式，使 Agent 能够主动向 NMS 报告事件，无需 NMS 轮询。

SNMP Trap vs Inform — Asynchronous Notification Flow

12.1 Trap 详解

12.1.1 Trap 的工作流程

  1. 事件检测：Agent 上的监控逻辑检测到阈值越界或状态变更（如接口 down、CPU 超限）
  2. PDU 构建：Agent 根据事件类型构建 Trap PDU，包含事件 OID、时间戳和相关数据
  3. 发送：Agent 通过 UDP 162 端口发送 Trap 到预配置的 NMS 地址列表
  4. 处理：NMS 接收 Trap，根据配置进行告警通知（邮件/短信/工单）
  5. 无响应：Agent 不等待也不期望收到确认

12.1.2 Trap 配置示例

Cisco IOS：

! 启用 SNMP Trap
snmp-server enable traps

! 配置 Trap 接收器（NMS 地址）
snmp-server host 192.168.1.100 version 2c public

! 配置特定类型的 Trap
snmp-server enable traps snmp authentication linkdown linkup
snmp-server enable traps envmon temperature

Linux (Net-SNMP)：

# /etc/snmp/snmpd.conf
trap2sink 192.168.1.100 public

# 发送测试 Trap
snmptrap -v 2c -c public 192.168.1.100 '' 1.3.6.1.6.3.1.1.5.1 \
  ifIndex i 1 ifAdminStatus i 1 ifOperStatus i 2

12.1.3 SNMPv2-Trap PDU 结构

SNMPv2-Trap-PDU ::= SEQUENCE {
    request-id       Integer32,
    error-status     Integer32 (always 0),
    error-index      Integer32 (always 0),
    variable-bindings VarBindList {
        -- 必须包含 sysUpTime.0
        -- 必须包含 snmpTrapOID.0
        -- 可选：其他相关 OID-值对
    }
}

12.2 Inform 详解

12.2.1 Inform 的工作流程

  1. Agent 检测到事件
  2. Agent 构建 Inform PDU（结构与 Trap 相同）
  3. Agent 发送 Inform 到 NMS，启动超时定时器
  4. NMS 接收 Inform，处理事件，发送 Response PDU 确认
  5. Agent 收到确认，停止重传
  6. 若超时未收到确认，Agent 重传（默认最多 3 次）

12.2.2 Inform 配置示例

# Net-SNMP Informsink（发送 Inform）
informsink 192.168.1.100 public

# 发送测试 Inform
snmpinform -v 2c -c public 192.168.1.100 '' 1.3.6.1.6.3.1.1.5.3

12.3 Trap vs Inform 选择指南

维度TrapInform
可靠性低（UDP 无确认）高（需响应确认）
延迟低（发后即忘）稍高（等待响应）
Agent 资源消耗低中（维护重传状态）
NMS 资源消耗低中（需发送响应）
适用场景高频事件、网络稳定关键告警、审计合规
支持版本v1/v2c/v3v2c/v3

实践建议：对于链路状态变化、认证失败等高频但非致命事件，使用 Trap；对于安全告警、硬件故障等关键事件，使用 Inform 确保通知送达。

13. 配置实践与命令行工具

13.1 Net-SNMP 工具套件

Net-SNMP 是 Linux/Unix 平台上最完善的 SNMP 工具集，提供了完整的命令行工具链。

13.1.1 查询类工具

# snmpget — 获取单个 OID 值
snmpget -v 2c -c public 192.168.1.1 sysDescr.0

# snmpgetnext — 获取字典序下一个 OID
snmpgetnext -v 2c -c public 192.168.1.1 sysDescr.0

# snmpwalk — 遍历 MIB 子树
snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1.1

# snmpbulkwalk — 批量遍历（v2c/v3）
snmpbulkwalk -v 2c -c public 192.168.1.1 ifTable

# snmptable — 以表格形式显示 MIB 表
snmptable -v 2c -c public 192.168.1.1 ifTable

13.1.2 修改类工具

# snmpset — 设置 OID 值
snmpset -v 2c -c private 192.168.1.1 sysContact.0 s "new@email.com"

# 类型标识符：i=INTEGER, s=STRING, x=HEX, d=DECIMAL, n=NULL, o=OID, t=TIMETICKS

13.1.3 信息类工具

# snmptranslate — OID 与名称互转
snmptranslate -On SNMPv2-MIB::sysDescr.0
# 输出: .1.3.6.1.2.1.1.1.0

snmptranslate .1.3.6.1.2.1.1.1.0
# 输出: SNMPv2-MIB::sysDescr.0

# snmpstatus — 获取设备概要信息
snmpstatus -v 2c -c public 192.168.1.1

# snmpdf — 显示远程设备的磁盘使用情况
snmpdf -v 2c -c public 192.168.1.1

13.1.4 通知类工具

# snmptrap — 发送 Trap
snmptrap -v 2c -c public 192.168.1.100 '' 1.3.6.1.6.3.1.1.5.1

# snmpinform — 发送 Inform
snmpinform -v 2c -c public 192.168.1.100 '' 1.3.6.1.6.3.1.1.5.3

13.2 常见设备配置

13.2.1 Cisco IOS

! 基础 SNMP 配置
snmp-server community public RO
snmp-server community private RW

! SNMPv3 配置
snmp-server group admin-group v3 priv
snmp-server user admin admin-group v3 auth sha authpass priv aes 128 privpass
snmp-server host 192.168.1.100 version 3 priv admin

! 启用 Trap
snmp-server enable traps
snmp-server host 192.168.1.100 version 2c public

! 系统信息（MIB system 组）
snmp-server location "Data Center A, Rack 12"
snmp-server contact "netops@company.com"

13.2.2 Huawei VRP

# 基础配置
snmp-agent community read public
snmp-agent community write private

# SNMPv3 配置
snmp-agent group v3 admin privacy
snmp-agent usm-user v3 admin admin authentication-mode sha cipher authpass privacy-mode aes128 cipher privpass
snmp-agent target-host trap address udp-domain 192.168.1.100 params securityname admin v3 privacy

# Trap 配置
snmp-agent trap enable
snmp-agent target-host trap address udp-domain 192.168.1.100 params securityname public v2c

13.2.3 Linux (Net-SNMP snmpd)

# /etc/snmp/snmpd.conf

# Agent 地址绑定
agentAddress udp:161,udp6:[::1]:161

# v1/v2c 社区字符串
rocommunity public 192.168.1.0/24
rwcommunity private 192.168.1.100

# v3 用户
createUser admin SHA "authpass" AES "privpass"
rouser admin

# 系统信息
syslocation "Server Room B"
syscontact "sysadmin@company.com"

# Trap 目标
trap2sink 192.168.1.100 public

# 扩展：自定义脚本输出
extend disk_usage /bin/df -h /

13.2.4 Juniper JunOS

# SNMP 社区
set snmp community public authorization read-only
set snmp community private authorization read-write

# SNMPv3
set snmp v3 usm local-engine user admin authentication-sha authentication-key authpass
set snmp v3 usm local-engine user admin privacy-aes128 privacy-key privpass
set snmp v3 vacm security-to-group security-model usm security-name admin group admin-group
set snmp v3 vacm access group admin-group default-context-prefix security-model usm security-level privacy read-view all

# Trap
set snmp trap-options source-address 192.168.1.1
set snmp trap-listeners 192.168.1.100

14. 完整监控工作流

SNMP 在企业网络监控中扮演核心角色，其完整工作流涵盖了从设备发现到告警通知的全生命周期。

Complete SNMP Monitoring Workflow

14.1 阶段一：设备发现

监控系统的第一步是发现网络中的 SNMP 设备：

  1. 网络扫描：通过 ICMP Ping 或端口扫描（UDP 161）发现在线设备
  2. SNMP 探测：尝试使用默认或配置的 Community String 连接设备
  3. 版本识别：通过 SNMP 查询确定设备支持的协议版本
  4. MIB 探测：Walk system 组获取设备描述、厂商、型号信息
  5. 能力发现：识别设备支持的 MIB 模块和私有扩展
# 批量发现脚本示例
for ip in $(seq 1 254); do
  snmpget -v 2c -c public -t 1 -r 0 192.168.1.$ip sysDescr.0 2>/dev/null && \
    echo "192.168.1.$ip: SNMP responsive" &
done
wait

14.2 阶段二：配置与模板

发现设备后，需要配置监控参数：

  1. 认证配置：根据安全策略配置 v2c Community 或 v3 用户凭据
  2. 轮询间隔：关键指标（CPU、接口）建议 30-60 秒；一般指标 5-15 分钟
  3. 阈值规则：定义告警触发条件（如 CPU > 80%，接口丢包率 > 1%）
  4. Trap 订阅：在设备上配置 Trap 目标地址和事件类型

14.3 阶段三：数据采集

数据采集分为两种方式：

主动轮询（Pull）：

  • NMS 按配置间隔向 Agent 发送 Get / GetBulk 请求
  • 采集的指标存入时序数据库（InfluxDB、Prometheus、RRD）
  • 适合周期性指标（CPU、内存、流量速率）

被动接收（Push）：

  • Agent 在事件发生时主动发送 Trap / Inform
  • NMS 接收后立即处理告警
  • 适合状态变更事件（接口 up/down、认证失败）

14.4 阶段四：告警与通知

当指标超过阈值或收到 Trap 时，触发告警流程：

  1. 告警分级：信息（Info）→ 警告（Warning）→ 严重（Critical）→ 紧急（Emergency）
  2. 去重抑制：避免告警风暴，相同问题在一定时间内只通知一次
  3. 升级策略：长时间未处理的告警自动升级到更高级别
  4. 通知渠道：邮件、短信、企业微信/钉钉、PagerDuty、SNMP Trap 转发

14.5 阶段五：报表与容量规划

历史数据用于趋势分析和容量规划：

  • 带宽利用率趋势：识别峰值时段和增长趋势
  • 设备健康评分：综合 CPU、内存、温度等指标
  • 容量预警：预测资源耗尽时间（如磁盘空间、路由表项）
  • SLA 报告：统计可用性、平均修复时间（MTTR）

14.6 主流监控平台对比

平台类型SNMP 支持特色功能
Zabbix开源v1/v2c/v3，自动发现模板丰富，分布式架构
Prometheus开源v1/v2c/v3（snmp_exporter）云原生，PromQL 查询
LibreNMS开源v1/v2c/v3，自动发现专注网络设备，开箱即用
Nagios开源v1/v2c/v3（插件）告警引擎强大
SolarWinds NPM商业v1/v2c/v3可视化强，NetPath 路径分析
PRTG商业v1/v2c/v3传感器模型，配置直观
DatadogSaaSv2c/v3云集成，APM 联动

15. 常见问题与故障排查

15.1 连接类问题

问题：请求超时（Timeout）

排查步骤：

# 1. 验证网络连通性
ping 192.168.1.1

# 2. 验证 SNMP 端口可达性
nc -vzu 192.168.1.1 161

# 3. 验证 Community String
snmpget -v 2c -c public -d 192.168.1.1 sysDescr.0
# (-d 开启调试输出)

# 4. 检查设备 ACL
# Cisco: show snmp community
# 确认 NMS IP 在允许列表中

常见原因：

  • 防火墙阻止 UDP 161/162
  • Community String 不匹配
  • 设备 ACL 限制了 NMS 源地址
  • Agent 未启用或绑定到错误接口

问题：认证失败（Authentication Failure）

# SNMPv3 认证失败排查
snmpget -v 3 -u admin -l authPriv -a SHA -A pass -x AES -X pass \
  -d 192.168.1.1 sysDescr.0 2>&1 | head -20

常见原因：

  • 用户名不存在
  • 认证/加密算法不匹配
  • 密码错误（注意大小写）
  • EngineID 不匹配（复制配置后未重新生成）

15.2 数据类问题

问题：OID 不存在（noSuchName / noSuchObject）

# 检查 OID 是否存在
snmptranslate -Tp -IR sysDescr

# 确认 MIB 文件已加载
snmptranslate -Dmib_parse .1.3.6.1.2.1.1.1.0

常见原因：

  • OID 拼写错误或数字有误
  • 缺少对应的 MIB 文件
  • 设备不支持该 OID（未实现对应功能）
  • 标量对象缺少 .0 实例标识符

问题：Counter32 溢出

Counter32 最大值为 2^32-1（4,294,967,295，约 42.95 亿），在高速接口（10Gbps+）上约 34 秒即可溢出。

解决方案：

  • 使用 Counter64（v2c/v3 支持）
  • 缩短轮询间隔，确保两次采样间计数器未溢出
  • 监控工具自动处理溢出回绕（计算差值时识别负值）

15.3 性能类问题

问题：Walk 操作太慢

优化方案：

# 使用 GetBulk 替代 GetNext
snmpbulkwalk -v 2c -c public -Cr50 192.168.1.1 ifTable

# 仅 Walk 需要的子树，而非整个 MIB-II
snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1.2.2  # 仅 ifTable

# 增加超时和重试
snmpwalk -v 2c -c public -t 10 -r 2 192.168.1.1 ifTable

问题：Agent CPU 占用高

排查方向：

  • NMS 轮询频率过高（调整间隔至 60 秒以上）
  • 多个 NMS 同时轮询同一 Agent
  • 复杂的 GetBulk 请求（减小 max-repetitions）
  • 禁用不必要的 MIB 模块

15.4 安全类问题

问题：Community String 泄露

检测方法：

# 抓包检查明文传输
sudo tcpdump -i any -nn -s0 -w snmp.pcap udp port 161 or udp port 162
# 在 Wireshark 中过滤 snmp.community 查看明文社区名

修复措施：

  1. 立即迁移到 SNMPv3
  2. 如果必须使用 v2c，配置 ACL 限制源地址
  3. 使用非默认的社区字符串（至少 12 位混合字符）
  4. 启用设备日志，监控异常访问

16. 总结与最佳实践

16.1 核心要点回顾

通过本文的系统分析，我们建立了对 SNMP 协议的完整认知框架：

  1. 架构层面：理解 Manager-Agent 模型，明确 NMS、Agent、MIB、OID 的角色和关系
  2. 协议层面：掌握 ASN.1 BER 编码、PDU 结构、版本差异
  3. 操作层面：熟练运用 Get / GetNext / GetBulk / Set / Trap / Inform 七种操作
  4. 安全层面：深刻理解 USM + VACM 的安全框架，坚持生产环境使用 authPriv
  5. 实践层面：能够配置主流设备的 SNMP，使用 Net-SNMP 工具进行故障排查

16.2 生产环境最佳实践

安全优先

  • 禁用 SNMPv1：所有新部署必须使用 v3；现有 v1 设备限期升级
  • 强制 authPriv：noAuthNoPriv 和 authNoPriv 不应出现在生产环境
  • 网络隔离：SNMP 管理流量应限制在独立的管理 VLAN/VPN
  • 定期审计：使用 Wireshark 或审计工具检查是否存在明文 Community String

配置规范

  • 社区字符串策略：长度 >= 16 位，包含大小写字母、数字、特殊字符；定期轮换
  • 最小权限原则：RO（只读）社区用于监控，RW（读写）严格限制 IP 和用途
  • Trap 白名单：仅向授权的 NMS 地址发送 Trap
  • 日志记录：启用 SNMP 访问日志，便于事后审计

监控优化

  • 轮询间隔分层：
    • 关键接口流量：30 秒
    • CPU/内存：60 秒
    • 系统信息：15 分钟
  • 批量采集优先：能用 GetBulk 就不用 GetNext
  • 阈值动态调整：根据历史数据设置自适应阈值，减少误报
  • Trap 补充轮询：关键状态变更使用 Trap 即时通知，辅以周期性轮询兜底

参考资料

  • RFC 1155 — Structure and Identification of Management Information for TCP/IP-based Internets (SMIv1)
  • RFC 1213 — Management Information Base for Network Management of TCP/IP-based Internets: MIB-II
  • RFC 1901 — Introduction to Community-based SNMPv2
  • RFC 2578 — Structure of Management Information Version 2 (SMIv2)
  • RFC 3411 — An Architecture for Describing SNMP Management Frameworks
  • RFC 3414 — User-based Security Model (USM) for Version 3 of SNMP
  • RFC 3415 — View-based Access Control Model (VACM) for SNMP
  • RFC 3418 — Management Information Base (MIB) for SNMP

附录

A. 错误码速查表

错误码（v1）错误码（v2c/v3）名称含义
00noError无错误
11tooBig响应 PDU 超过最大尺寸
22noSuchName请求的 OID 不存在（v1）
—3badValueSet 操作的值类型/范围无效
—4readOnly试图修改只读对象
35genErr一般性错误
—6noAccess访问权限不足（VACM 拒绝）
—7wrongTypeSet 值类型与对象定义不匹配
—8wrongLengthSet 值长度不匹配
—9wrongEncodingSet 值 ASN.1 编码错误
—10wrongValueSet 值超出允许范围
—11noCreation指定索引的行不存在且无法创建
—12inconsistentValueSet 值与当前状态不一致
—13resourceUnavailable资源不足无法执行操作
—14commitFailedSet 操作提交阶段失败
—15undoFailedSet 操作回滚阶段失败
—16authorizationError授权检查失败
—17notWritable对象当前不可写
—18inconsistentNameSet 操作中的 OID 不一致

B. SNMPv3 msgFlags 位定义

位名称含义
0 (LSB)authFlag1 = 启用认证
1privFlag1 = 启用加密
2reportableFlag1 = 需要 Report PDU 响应
3-7—保留，必须为 0

authPriv 对应的 flags 字节值为 0x03（二进制 00000011）。

C. 常用厂商 Enterprise OID

厂商Enterprise Number私有 MIB 根 OID
Cisco91.3.6.1.4.1.9
Huawei20111.3.6.1.4.1.2011
Juniper26361.3.6.1.4.1.2636
H3C255061.3.6.1.4.1.25506
Ruijie48811.3.6.1.4.1.4881
Microsoft3111.3.6.1.4.1.311
Net-SNMP80721.3.6.1.4.1.8072

旨在为网络管理人员提供 SNMP 协议的系统性参考。如有技术问题或勘误建议，欢迎反馈。*

avatar
文章
阅读
粉丝