个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。

因此本文将在 SNMPv3 协议报文的基础上进行介绍。
SNMPv3 相关 RFC 文档。

• 关于 SNMPv3 的基本内容介绍，可参考RFC3410-Introduction and Applicability Statements for Internet Standard Management Framework。
• 关于 SNMPv3 的管理框架，可参考RFC3411-An Architecture for Describing SNMP Management Frameworks。
• 关于 SNMPv3 的交互原理，可参考RFC3412-Message Processing and Dispatching for the SNMP。
• 关于 SNMPv3 的 USM 模型，可参考RFC3414-User-based Security Model for version 3 of the SNMPv3。
• 关于 SNMPv3 的 VACM 模型，可参考RFC3415-View-based Access Control Model for the SNMP。

• 关于SMI Numbers分类及其定义的OID值，可参考IANA发布的Structure of Management Information (SMI) Numbers (MIB Module Registrations)。
• 关于SNMP字段空间定义，可参考IANA发布的Simple Network Management Protocol (SNMP) Number Spaces。
• 关于SNMP的 v1/v2/v3 版本间的共存，可参考RFC3484-Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework。
• 关于企业私有识别码的相关字段，可参考IANA的Private Enterprise Numbers (PENs)。
  常见企业识别码有：CISCO=9, Ericsson=193(…), Microsoft=311(…), Juniper=1411(…), HUAWEI=2011, ZTE=3902, RUIJIE=4881, MAIPU=5651, TP-Link Corporation Limited=11863, H3C=25506。
• 关于常用OID值及其定义，可参考Global OID reference database。
• 关于OID技术的现状和发展，可参考中国电子技术标准化研究院发布的《对象标识符(OID)白皮书 (2015)》。
• 关于 SMI, MIB, OID 等术语的详细介绍以及 SNMPv1/v2c 的原理，可参考博客-SNMPv1/v2c-原理浅谈+报文示例+简易配置。
• 关于SNMP简易工具及其使用指导，可参考博客-Windows系统下的可用SNMP软件-[资源]。
  …

SNMP的不同版本还存在大量相关RFC，感兴趣者可查阅相关资料。

除上述提到的 SNMP 协议外，其他网络管理协议还有 CMOT/CMIP(RFC1189)，Netconf(RFC6241) 和 Telemetry(RFC9232) 等。
个人能力有限，如有疑问烦请指导学习。

目录

1.背景介绍

SNMP 协议各版本间不存在严格迭代关系，并且共享相同的基本结构和内容。此外，Internet 标准管理框架的所有 SNMP 规范版本都遵循相同的体系结构。其基本通用概念已在之间博客进行了简单介绍。感兴趣者，可参考博客-SNMPv1/v2c-原理浅谈+报文示例+简易配置。

1.1.相关术语

MIB：Management Information Base，管理信息库。被管理对象的信息库。MIB 中的对象由 ASN.1（Abstract Syntax Notation One，抽象语法标记1）描述。
OID：Object IDentifier，对象标识符。每类对象都有其命名、语法结构和编码类型。OID 某种程度上就是管理定义对象的名称。

OID：是一种用于识别某些对象的方法而不管与该对象相关的语义，是遍历全局树的整数序列。
对象类型的语法：定义了对象对应抽象数据结构。其结构可以为 INTEGER 或 OCTET 字符串等，并且通常在定义语法时允许任何满足 ASN.1 结构的对象类型。
对象类型的编码：使用对象类型语法表示该对象类型实例的方式。 与对象的语法和编码概念隐含相关的是对象在网络上传输时的编码方式。

OID树：该树由一个根为基础，通过边连接到多个标记节点。反过来，每个节点都可以有自己的标记子节点，也可称子树。当遍历树时，可以委派对分配给节点对应含义标签的管理控制。标签是简短的文本描述和整数的配对。

RFC1155 认为根节点不可被标签化，但至少有3个子节点。
ccitt(0)：由 International Telegraph and Telephone Consultative Committee 国际电报和电话咨询委员会定义的 Label0。
iso(1)：由 International Organization for Standardization 国际标准化组织定义的 Label1。
joint-iso-ccitt(2)：由 ISO 和 CCITT 共同管理的 Label2。
自动换行
在 iso(1) 节点下，ISO 指定了一个子树供其他（国际）国家组织 org(3) 使用。在现有的子节点中，有两个已分配给 NIST（U.S. National Institutes of Standards and Technology，美国国家标准与技术研究院）。其中一个子树已由 NIST 转移给 dod(6)（Department of Defense，美国国防部）。
RFC1155 中定义了 IAB（Internet Activities Board，网络活动委员会）负责管理的 Internet 团体串节点 1.3.6.1。并且由 IAB 批准指定了管理对象标识符4个子树：
directory = Internet 1：被保留用于将来的备忘录，以讨论如何在 Internet 中使用 OSI Directory。
mgmt = Internet 2：用于识别 IAB 批准的文档中定义的对象，该子树的管理由 IAB 委托给 IANA（Internet Assigned Numbers Authority，互联网号码分配局）。
experimental = Internet 3：用于在网络实验中标识对象，该子树的管理由 IAB 委托给 IANA（Internet Assigned Numbers Authority，互联网号码分配局）。
private = Internet 4：用于厂商私有等场景下标识对象，该子树的管理由 IAB 委托给 IANA（Internet Assigned Numbers Authority，互联网号码分配局）。 关于企业私有识别码的相关字段，可参考IANA的Private Enterprise Numbers (PENs)。
//常用 OID 树结构。上图仅罗列部分内容，感兴趣者可查阅相关资料。

Managed Objects：被管理对象。

RFC1155-SMIv1 中定义对象由 5 部分组成：OBJECT DESCRIPTOR、Syntax、Definition、Access 和 Status。MIB 中未定义引用对象实例的方法，对对象实例的引用是通过特定于协议的机制实现的。例如 SNMP 和 CMOT 协议。
OBJECT DESCRIPTOR：对象类型的文本名称，OID 与其对应。或者说对象的数字表达为 OID，文本表达为OBJECT DESCRIPTOR。
Syntax：定义对象的表达语法结构，是 ASN.1 type ObjectSyntax 的一种。
Definition/Description：对象类型语义的文本描述。
Access：访问权限，可分为只读、读写、只写和不允许访问。
Status：对象状态，可分为必需的、可选的或过时的。
下文将进行详细介绍。

SMI：Structure of Management Information，管理信息结构。用于定义改编的子集，并分配关联的管理值。

RFC2578–SMIv2/SNMPv2-SMI 中描述的较为详细将 SMI 分为了三部分：
Module definitions：用于描述信息模块。
Object definitions：用于描述管理对象。
Notification definitions：用于描述未经请求的管理信息传输。

v3MP：SNMP version 3 Message Processing Model，SNMPv3 消息处理模型。

NMS：Network management stations，网络管理站。是一个执行监视和控制网元的管理应用程序，也即管理对象服务器。
NE：Network elements，网元。通常是主机、网关、终端服务器等被管理对象设备。它们具有管理代理，负责执行 NMS 请求的网络管理功能。

1.2.BER 规则示例

SNMP协议所涉及到的 BER 规则已在之前博客进行了简单介绍。此处为便于阅读，仅摘取部分内容进行介绍。感兴趣者，可参考博客-SNMPv1/v2c-原理浅谈+报文示例+简易配置。

这里以上图所示结构进行举例说明。

需要说明的是以下例子仅用于展示说明，实际情况还需针对进行考虑。

boolean：
也即0x0101FF。布尔值只有 False 和 True，当布尔值为 False 时 Contents octets 取 0x00；当布尔值为 True 时Contents octets 取任意非0值。也即分别编码为 0x0101 00 和 0x0101 FF。

integer：
也即0x02XXXX。那么对应 十进制数字128 应编码为0x0202 0100。

bit string：
也即0x03XXXX。由于传输时以字节为最小单位，bit string不一定占据完整字节，因此高位填充后有可能需要将剩余 bit 额外以 0 填充。同时在 Contents octets 字段第一个字节标识补位 bit 的个数。那么对应 bit string = 10101，应编码为0x0302 03A8；对应 bit string = 000111001101，应编码为0x0303 041CD0 (这里填充了 4 bit 0 以组成完整字节。)。

octet string：
也即0x04XXXX。相比于 bit string，octet string 高位填充后直接占据了整个字节。那么对应 octet string = 1010 1100 1110，应编码为0x0402 ACE0。

此外还有一种 IA5String 类型的字节串0x16XXXX，其内容字段采用 ASCII 方式进行编码。

null：
也即0x0500。contents octets不含任何内容。

object identifier：
也即0x06XXXX。对于此类型进行编码时，需将前两个节点记作 X 和 Y 并以 (X*40)+Y 的形式编码在同一个字节中。那么对应 OID = 1.3.6.1.2.1.2，应编码为0x0606 2B0601020102。

sequence：是标签号为 16 号的构造类型，因此 P/C-bit 置位。这是多个 TLV 的组合。
定义一个 sequence 具有格式 sequence {name IA5String, ok BOOLEAN}，且有值{name “smith”, ok TRUE}。则其编码应为
也即 0x300A 1605736D697468 0101FF，这里的 0x736D697468 是 smith 对应的 ASCII 值。

set：是标签号为 17 号的构造类型，因此 P/C-bit 置位。这是多个 TLV 的组合。与 sequence 区别在于，set 是无序的。
那么对于上文的结构可表示为
0x310A 1605736D697468 0101FF 或
0x310A 0101FF 1605736D697468。

//这里简单介绍下其他类型的 Identifier octets。感兴趣者可查阅相关资料。

点击此处回到目录

2.SNMPv3详解

2.1.SNMP协议框架-RFC3411

2002年发布的《RFC3411 - Message Processing and Dispatching for the SNMP Management Frameworks》描述了迄今为止最为丰富和清晰的 SNMP 架构和组成内容。在这一架构下可以实现不同 SNMP 版本间的相互兼容和调度。

RFC3411 中将 SNMP 组织架构主要分为 3 类元素：Entities，Identities 和 Management Information

1@Entities：SNMP Entitiy 由 SNMP engine 和 Application 组成。SNMP engine 提供用于发送和接收消息的服务，对消息进行身份验证和加密，并控制对托管对象的访问。SNMP engine 与包含SNMP engine 的 SNMP Entitiy 之间存在一对一的关联。Application 主要利用 SNMP engine 完成 SNMP 消息收发，产生 Trap 信息以及代理转发等工作。

SNMP Entitiy 基本组织如下图所示：1@Dispatcher：每个 SNMP engine 仅包含一个 Dispatcher 调度者，其主要完成并发运行多个版本的 SNMP 消息。
2@Message Processing Subsystem：用于处理不同 SNMP 版本模型。例如，SNMPv1 Message Processing Model、SNMPv2 Message Processing Model 和 SNMPv3 Message Processing Model。
3@Security Subsystem：用于提供消息认证和加密等服务。在 RFC3414 中定义了常用的 User-based Security Model 基于用户的安全模型，将在下文进行介绍。
4@Access Control Subsystem：用于提供相应的授权服务。在 RFC3415 中定义了常用的 View-Based Access Control Model 基于视图的访问控制模型，将在下文进行介绍。
5@Application：主要分为 SNMP Manager 和 SNMP Agent。主要描述了管理对象和网元如何调用 SNMP Engine 以提供各种服务。
自动换行
相关内容不在进行详细介绍，感兴趣者可查阅相关资料。

2@Identities：一个应用程序或一组应用程序及其集合通过 securityName 及其关联的 Security Model 进行 SNMP engine 执行内容的区分和标识。

3@Management Information：管理信息驻留于 SNMP entity 中，并于该实体中，应用程序对可能的与之对应多个上下文赋予本地访问权限。 应用程序使用的 contextEngineID 等于其关联的 SNMP engine 的 snmpEngineID。

管理信息又包含如下概念：
SNMP Context：SNMP上下文（简称“上下文”）是 SNMP Entitiy 可访问的管理信息的集合。管理信息项可能存在于多个上下文中。 SNMP Entitiy 也可能有权访问多个上下文。MIB 模块指定的实例识别方法不允许在管理域内的所有实例集中区分每个实例。相反，它只允许在某个范围或“上下文”中标识每个实例，其中管理域中有多个这样的上下文。
contextEngineID：管理域中唯一的标识 SNMP entity 的 ID。
contextName：SNMP entity 中唯一的标识上下文。通常，上下文是物理设备，或者可能是逻辑设备，尽管上下文也可以包含多个设备，或单个设备的子集，甚至是多个设备的子集，但上下文始终定义为单个 SNMP Entitiy 的子集。
自动换行
例如：RFC2863 中定义了 ifDescr 的管理对象类型，OID = 1.3.6.1.2.1.2.2.1.2。若要标识 device-X 设备第一个接口描述需要获得 4 条信息：SNMP entity 的snmpEngineID，contextName（device-X），管理对象类型（ifDescr）和 Instance (“1”)。

SNMP的其他结构：
maxSizeResponseScopedPDU：PDU 发送者通常所能接受的PDU最大尺寸。需要说明的是，该值不包含 SNMP 消息头。
Local Configuration Datastore：SNMP entities 中的子系统、模型和应用通常需要在本地留存部分配置信息。这部分信息通常称为 LCD，并且部分内容可被管理对象访问。
securityLevel：在 RFC3411 中主要定义了 3 种安全级别：noAuthNoPriv、authNoPriv 和 authPriv。

• noAuthNoPriv：不进行认证和加密。
• authNoPriv：仅认证而不加密。
• authPriv：认证和加密。

在这3种安全级别中，authPriv安全级别最高，noAuthNoPriv安全级别最低。每条消息都有一个关联的 securityLevel。所有子系统（消息处理、安全性、访问控制）和应用程序都需要在处理消息及其内容时提供 securityLevel 值或遵守提供的 securityLevel 值。

2.1.1.SNMPv3使用的VACM模型-RFC3415

在2002年发布的《RFC3415 - View-based Access Control Model (VACM) for the SNMP》中定义了 SNMP engine 使用的 一种访问控制子系统模型 VACM（View-based Access Control Model，基于视图的访问控制模型）。

访问控制（隐式或显式）发生在 SNMP entity 处理 SNMP 检索或修改请求消息时。 例如，命令响应应用在处理从命令生成器应用接收的请求时应用访问控制。

VACM模型主要包含如下元素：
Groups：组是一个或多个 <securityModel, securityName> 元组的集合，代表了 SNMP 可以访问的管理对象。组可以为其包含了所有 securityName 提供访问权限。组以 groupName 进行标识，并确定为 securityModel 和 securityName 的函数。securityModel 和 securityName 的组合最多映射到一个组。

securityLevel：前文介绍 RFC3411 中定义的 3 种安全级别：noAuthNoPriv、authNoPriv 和 authPriv。VACM 模型要求在调用访问控制模块以检查访问权限时将 securityLevel 作为输入参数传递给访问控制模块。

Contexts：上下文是 SNMP entity 中可访问的管理信息的集合。SNMP entity 可能有权访问许多上下文。

在 RFC3415 定义的 SNMP-VIEW-BASED-ACM-MIB 文件（OID=1.3.6.1.6.3.16）中定义了一个子节点 vacmContextTable（OID=1.3.6.1.6.3.16.1.1）。该 list 类型的管理对象可按 contextName 列出本地可用的上下文。

MIB Views：对于给定的上下文，通常始终有一个 MIB 视图提供对该上下文中所有管理信息的访问，并且通常会有其他 MIB 视图，每个视图都包含一些信息子集。 因此，可以通过根据组在每个适当上下文中可以访问的特定（子集）MIB 视图指定其权限，以所需的方式限制组允许的访问。

在创建指定的 MIB 视图时，可以通过添加或删除指定 OID 为用于提供不同的权限。同时 RFC3415 定义的 SNMP-VIEW-BASED-ACM-MIB 文件（OID=1.3.6.1.6.3.16）中提到：

• 创建 MIB 视图时，强烈建议先创建“排除”的 vacmViewTreeFamilyEntrys，然后创建“包含”条目。
• 删除 MIB 视图时，强烈建议先删除“包含”的 vacmViewTreeFamilyEntrys，然后删除“排除”条目。
• 如果创建实例级 accesscontrol 条目时，不支持对应颗粒度的是操作，则必须返回 inconsistentName 错误。

自动换行//snmp-agent mib-view Mib-test 用于指定创建名为 Mib-test 的视图时，排除还是包含指定的 ViewTree。

ViewTreeFamily：视图树族是 OID 与 bit 字符串的组合。

Access Policy：VACM 模型确定组访问权限的策略，表示具有相同访问权限的 securityNames。 对于由 contextName 标识的特定上下文，由 groupName 标识的组可以使用特定的 securityModel 和 securityLevel 访问该上下文，该组的访问权限由 read-view、write-view 和 notify-view 提供。

read-view 表示在读取对象时为组授权的对象实例集。
write-view 表示在写入对象时为组授权的对象实例集。
notify-view 表示在通知中发送对象时（例如发送通知时（发送通知类 PDU 时）时为组授权的对象实例集。

VACM 模型工作时基本过程如上图所示。

点击此处回到目录

2.2.SNMPv3报文格式-RFC3412

关于 SNMPv3 协议的报文格式，可参考2002年发布的《RFC3412 - Message Processing and Dispatching for the SNMP》。此外，关于 USM 模型下的 msgSecurityParameters 字段可参考2002年发布的《RFC3414 - User-based Security Model (USM) for version 3 of the SNMP》。

在具体介绍之前，这里先介绍 SNMPv3 底层封装：
在 IP 网络中的 SNMP 协议通常使用的是 UDP 的161端口。

//snmp-agent udp-port用来修改 SNMP Agent 侦听的端口号，默认161。需要与 SNMP Manger 一致。
同样的 snmp-agent target-host 命令中也包含参数可以修改 trap 型 SNMP 消息的监听端口。默认162。
//默认情况下发送Trap报文的源端口号是随机分配的，可以通过 snmp-agent trap source-port 指定其端口固定为1025～65535 的任意值。

其中《RFC3412-Message Processing and Dispatching for the SNMP》定义 SNMPv3 报文格式有：
也即其结构为：
SNMPv3Message共分为4部分：
1@msgVersion：数据类型为 INTEGER。

取 0x03 时表示 SNMPv3。

2@msgGlobalData：数据类型为 HeaderData。

也即有上图所示结构。其中：
msgID：在两个 SNMP entity 之间用于协调请求消息和响应，并由 v3MP 用于协调体系结构中不同子系统模型对消息的处理。可以防止重放攻击。
同时，考虑到 PDU 加密情况，SNMP 应用程序可以使用 PDU 中的 request-id 来标识 PDU，而引擎使用 msgID 来标识带有 PDU 的消息。并且不应假定 msgID 和 request-id 是等效的。通过使用 msgID 值，引擎可以区分（可能多个）未完成的请求，从而将传入的响应与未完成的请求相关联。如果重新传输请求，则每次重新传输都应使用新的 msgID 值。
msgMaxSize：表示消息发送方支持的最大消息大小。
msgFlags：包含 3 个位字段，用于控制消息的处理。
通常为1字节，3个bit。

• reportableFlag：确定是否必须发送 Report-PDU 的标记位。收到 reportableFlag 值为 1 的 SNMPv3报文时，则必须在可能导致生成 Report-PDU 的条件下将 Report-PDU 返回给发送方；reportableFlag 值为零时，则不得发送 Report-PDU。并且在收到 Report-PDU、GetRequest-PDU、Trap-PDU 时无论其 reportableFlag 值为何都应当正常进行处理。
  此外，Report-PDU 可以用于确定 SNMP engine 检测到的问题类型。根据检测到的错误，SNMP引擎可能会尝试发送更正的SNMP消息或将错误指示传递给发出 SNMP 问题的应用程序。
• authFlag：指示在通过网络发送消息之前应用于消息的 securityLevel。 消息的接收方在接收消息和处理内容时必须应用相同的 securityLevel。如果 authFlag 设置为 1，则发送消息的 SNMP 引擎使用的 msgSecurityModel 必须标识代表其生成 SNMP 消息的 securityName，并且必须为消息的接收方提供足够的数据，以便能够验证该标识。如果 authFlag 设置为 0，必须同样标识代表其生成 SNMP 消息的 securityName，但它无需携带额外数据进行身份验证。
• privFlag：指示在通过网络发送消息之前应用于消息的 securityLevel。 消息的接收方在接收消息和处理内容时必须应用相同的 securityLevel。

msgSecurityModel：标识发送方使用哪种安全模型来生成消息，因此接收方必须使用哪种 securityModel 来执行消息的安全处理。

3@msgSecurityParameters：数据类型为 OCTET STRING。
RFC3412 认为 msgSecurityParameters 字段中的数据由安全模型独占使用，数据的内容和格式由安全模型定义。 此 OCTET STRING 不由 v3MP 解释，而是传递给消息中 msgSecurityModel 字段指示的安全模型的本地实现。

4@msgData：数据类型为 ScopedPduData。其包含数据为加密或非加密的信息。如果 msgFlags 中的 privFlag 为零，则 scopedPduData 字段表示纯文本 scopedPDU。反之，表示由 securityModel 指定加密的 PDU。

也即有上图所示结构。其中：
contextEngineID：在管理域中唯一标识一个 SNMP 实体，该实体可以实现具有特定 contextName 的上下文实例。
接收消息中 contextEngineID 与 pduType 结合使用，以确定将 scopedPDU 发送到哪个应用程序进行处理；传出消息中 v3MP 将 contextEngineID 设置为应用程序在请求中提供的值。
//需要说明的是，contextEngineID 格式为16进制字符串。但在 MIB Browser 中进行如上图所示的指定时，通常需要以“# + 0x”的方式进行指定。
contextName：contextName 字段与 contextEngineID 字段一起标识与 PDU 关联的特定上下文。
data：ANY PDU define in RFC3416。也即此处填充的是 SNMPv2 所定义的8种PDU。

点击此处回到目录

2.2.1.SNMPv3使用的USM模型-RFC3414

在2002年发布的《RFC3414 - User-based Security Model (USM) for version 3 of the SNMP》中定义了 SNMPv3 报文中使用的一种 USM 模型下的常用的 SecurityParameters。
SNMPv3 报文中的 msgSecurityParameters 字段即为填充的 USM 模型下的信息。

其中 USM 模型下的用户主要由以下部分组成：
userName：代表用户名的字符串。
securityName：独立于安全模型，以人类可读字符串格式表示的用户。 userName 和 securityName 是一对一的关系。
authProtocol：用户认证使用的协议。RFC3414 定义了 HMAC-MD5-96 和 HMAC-SHA-96。
authKey：authProtocol 使用的加密密钥，由 SNMP 实体事先确认。
privProtocol：用户数据加密协议。RFC3414 定义了CBC-DES Symmetric Encryption Protocol。
privKey：privProtocol 使用的加密密钥。

到目前为止共定义了如上7种认证协议。
到目前为止共定义了如上3种加密协议。

出于防重放攻击需要，SNMPv3 实体还应包含：
snmpEngineID：在一个管理域内，snmp-agent local-engineid 800007DB03360102101100用于唯一且明确的标识SNMP引擎。
snmpEngineBoots：自上次配置 snmpEngineID 以来 SNMP 引擎重新引导/重新初始化的次数。
snmpEngineTime：自 snmpEngineBoots 计数器上次次递增以来的秒数。如果 snmpEngineTime 达到其最大值 2^{^31}= 2147483647，则 snmpEngineBoots 将 + 1。同时 snmpEngineTime 将重置为零并再次开始递增。

在 《RFC3411 - An Architecture for Describing SNMP Management Frameworks》第 5 章所定义的 SNMP-FRAMEWORK-MIB (OID = 1.3.6.1.6.3.10) 文件中定义了 snmpEngineID 子节点属性。
snmpEngineID 目前主要有 2 种格式：当第一个 bit 为 0 时表示 RFC3411 标准之前的生成方式；当第一个 bit 为 1 时为表示 RFC3411 标准定义的生成方式。
格式1@：共长 12 字节。其中前 4 字节用于标识企业私有代码，其余 8 字节是通过一种或多种特定于企业的方法确定的。
格式2@：不定长。其中前 4 字节用于标识企业私有代码，第 5 字节用于表示第 6 字节及之后字节的组成格式。
//目前明确定义了以上 6 种。
snmp-agent local-engineid 用来设置本地 SNMP entity 的 entity ID。
例如，当设置 entity ID 为 800007DB034C1FCC000001 表示制造厂商 2011 以 MAC 格式（MAC =4C1F.CC00.0001）形成的 entity ID。

RFC3414 中定义了如下 USMSecurityParametersSyntax：
也即其应具有如下编码格式：
同时需要说明的是 RFC3412 中 定义 msgSecurityParameters 数据类型为 OCTET STRING，因此以上还需封装值为 0x04 的 ldentifier octets 进行识别。

上图为 wireshark 拆解的 USM 模型所使用的相关字段。其中未包含具有意义的内容。

在《RFC3414 - User-based Security Model (USM) for version 3 of the SNMP》的第 5 章中定义了 SNMP-USER-BASED-SM-MIB (OID = 1.3.6.1.6.3.15) 文件。其中主要包含了 usmUserStatus 以描述模型状态，以及 usmUser 以描述用户信息。

2.2.2.SNMPv3使用的PDU-RFC3416

2002年发布的《RFC3416 - Version 2 of the Protocol Operations for SNMP》中定义了 8 种 PDU：GetRequest-PDU、GetNextRequest-PDU、Response-PDU、SetRequest-PDU、GetBulkRequest-PDU、InformRequest-PDU、SNMPv2-Trap-PDU 和 Report-PDU。

SNMPv2 和 SNMPv3 所使用的 PDU是完全相同的。只是 SNMPv3 新增了安全加密功能。

这里只介绍常用的几种 PDU。

除 GetBulk 类型外的 PDU 封装结构为：
详细内容不在介绍，感兴趣者可查阅相关资料。

GetBulkRequest-PDU具有如下结构类型：
详细内容不在介绍，感兴趣者可查阅相关资料。

SNMPv1 和 SNMPv2c 中 PDU 的 Identifier octets 编码对别：

	SNMPv1	SNMPv2c
GetRequest-PDU	0xA0	0xA0
GetNextRequest-PDU	0xA1	0xA1
GetResponse-PDU	0xA2	0xA2
SetRequest-PDU	0xA3	0xA3
Trap-PDU	0xA4	0xA7
GetBulkRequest-PDU	—	0xA5
InformRequest-PDU	—	0xA6
Report-PDU	—	0xA8

GetRequest-PDU示例。

那么通过上述对 SNMPv3 协议报文格式的介绍便可分析 SNMPv3 正常交互的数据流了。
此处展示的 58 字节的 SNMPv3 报文中，有部分字段为空因此 wireshark 将其解析为 <MISSING>。这里不在详细描述感兴趣者可自行解读。

点击此处回到目录

2.3.SNMPv3报文交互

在2002年发布的《RFC3412 - An Architecture for Describing SNMP》中介绍了 SNMP entity 应当如何处理SNMPv3 Message Processing Model，同时在《RFC3413 - Simple Network Management Protocol (SNMP) Applications》中介绍了 SNMP entity 应当如何调用 SNMP Engine 中的应用以提供各种服务。

这里不对详细内容进行介绍，而仅简单说明交互过程。同时为简化描述过程，忽略了明显不符合程序交互逻辑是 SNMP entity 的程序判断。并且不对 SNMP proxy 场景进行说明。感兴趣者可查阅相关资料。

在《RFC3414 - User-based Security Model (USM) for version 3 of the SNMP》的第 4 章中要求应当在发现过程中首先获取有关其他 SNMP engine 的足够信息，以便与它们进行通信。

因此 SNMPv3 基本交互过程如上图所示。

//这里以 192.168.9.100 作为 NMS Server，192.168.9.108 作为 Management Agent 为例进行简单说明。

1@：首先 NMS Server 携带 msgflags = 0x04 及其他不携带任何含义的安全参数向 Management Agent 发送 GetRequest-PDU 请求获取 SNMP entity 的相关参数信息。

//USM 模型参数为空，并不携带请求信息。

2@：首先 Management Agent 将 msgflags = 0x08。同时携带自身 SNMP entity 启动信息向 NMS Server 发送 Report-PDU。

//携带 SNMP entity 的 engine-id 及 SNMP 应用启动信息。

3@：NMS Server 根据自身所配置的用户信息向 Management Agent 发送具体的请求信息。

//这里 msgflags 中 encrypted-bit 及 authenticated-bit 标志位置位以及对应的 SecurityParameters 是由本地配置的用户信息决定的。
并且如果知晓 SNMPv3 交互所使用的 SecurityParameters，可在 wireshark 的【编辑】→【首选项】→【protocol】→【SNMP】中进行如上图所示的相关设置以便对交互数据进行解密分析。

4@：最终由 Management Agent 以对应的 SecurityParameters 向 NMS Server 回应消息。

这里 SecurityParameters 满足对应要求，因此回应以加密数据。如果 Management Agent 与 NMS Server 所请求的 SecurityParameters 不一致会在 Report-PDU 进行提示。Report-PDU 将会携带《RFC3414 - User-based Security Model (USM) for version 3 of the SNMP》的第 5 章中定义的 SNMP-USER-BASED-SM-MIB (OID = 1.3.6.1.6.3.15) 文件中的子树节点。

点击此处回到目录

2.4.SNMP各版本之间的兼容

SNMP 协议各版本间不存在严格迭代关系，并且共享相同的基本结构和内容。此外，Internet 标准管理框架的所有 SNMP 规范版本都遵循相同的体系结构。在 《RFC3484 - Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework》中，IANA 对不同 SNMP 协议版本进行相应区分。

SNMP 协议各版本间的兼容需要解决如下问题：

• RFC1155-SMIv1 和 RFC2578–SMIv2/SNMPv2-SMI 格式之间的 MIB 文档转换。
• notification 参数的映射。
• 多语言网络中支持各种版本 SNMP entity 共存的方法。

1@SMI和MIB映射：

通常情况下 SNMPv1 使用 RFC1155/RFC1212 定义的 SMIv1，RFC1157 定义的协议规则，RFC1215 定义的 Trap 消息。而 SNMPv2 和 SNMPv3 大部分内容相同。SNMPv3 使用 RFC3416 到 RFC3418 的 SNMPv2 定义以及 RFC2578 到 RFC2580 的 SMIv2 定义。

用于描述管理对象集合的 RFC2578–SMIv2/SNMPv2-SMI 方法几乎是 RFC1155-SMIv1 中定义的方法的适当超集。因此在 MIB 转换时应当遵循某些原则。
1@：IMPORTS 语句必须引用 RFC2578–SMIv2/SNMPv2-SMI，而不是 RFC1155-SMIv1 和 RFC-1212。
2@：必须在任何 IMPORTs 语句之后立即调用 MODULE-IDENTITY 宏。
3@：由于两者版本定义了不同的 Syntax/语法，应当对语法做相应的转换映射。例如，RFC1155-SMIv1 定义的 Counter 类型对象应当映射为 RFC2578-SMIv2/SNMPv2-SMI 定义的 Counter32 类型的对象；同样的，Gauge 应映射为 Gauge32/Unsigned32；NetworkAddress 应映射为 IpAddress；访问权限的 ACCESS 应当映射为 MAX-ACCESS。
4@：必须定义一个或多个对象组，并且必须将相关对象收集到适当的组中。 并且 RFC2578-SMIv2/SNMPv2-SMI 要求所有 OBJECT-TYPE 至少是一个 OBJECT-GROUP 的成员。
5@：TRAP-TYPE macro 向 NOTIFICATION-TYPE macro 映射时应当移除 ENTERPRISE，添加 DESCRIPTION。

详细规则可查看相关资料。

2@notification 参数的映射：Trap-PDU/Inform-PDU

SNMPv1 notification 参数通常包含 OID 类型的 enterprise parameter，NetworkAddress 类型的 Agent 网元地址，INTEGER 类型的 generic-trap 或 specific-trap parameter，TimeTicks 类型的 time-stamp parameter ，以及所需通知的 VarBindList 类型的 variable-bindings。
SNMPv2 notification 参数通常包含 TimeTicks 类型的 sysUpTime，OID 类型的snmpTrapOID，以及所需通知的 VarBindList 类型的 variable-bindings。

SNMPv1 Notification 参数向 SNMPv2 Notification 参数映射时应当：
1@：SNMPv2 sysUpTime 参数应直接取自 SNMPv1 time-stamp 参数。
2@：如果 SNMPv1 generic-trap 为 ‘enterpriseSpecific（6）’，则 SNMPv2 snmpTrapOID 参数应为 SNMPv1 enterprise parameter 和两个附加子标识符 ‘0’ 和 SNMPv1 specific-trap 参数的串联。
3@：如果 SNMPv1 generic-trap 非 ‘enterpriseSpecific（6）’，则 SNMPv2 snmpTrapOID 参数应为 RFC3418 所定义 SNMPv2-MIB 文件（OID=1.3.6.1.6.3.1.1）中的相关参数。
4@：SNMPv2 variable-bindings 应替换为 SNMPv1 variable-bindings。

详细规则可查看相关资料。

SNMPv2 Notification 参数向 SNMPv1 Notification 参数映射时应当：
1@：如果 SNMPv2 snmpTrapOID 参数是 RFC3418 中定义的标准 trap 且存在 variable-binding，应将 SNMPv1 enterprise parameter 设置为 SNMPv2 variable-bindings 中的 snmpTrapEnterprise.0。否则，应将 SNMPv1 enterprise parameter 应根据 SNMPv2 snmpTrapOID 参数确定。
2@：SNMPv1 agent-addr 参数应设置为通知发起方所在的 SNMP entity 的 IP 地址。如果存在代理场景应当设置为 0.0.0.0。
3@：SNMPv1 generic-trap 参数应当设置为 SNMPv2 snmpTrapOID 参数。如果 SNMPv2 snmpTrapOID 参数是非标准 Trap，则应当设置为 6。
4@：SNMPv1 specific-trap 参数应当设置为 0。如果 SNMPv2 snmpTrapOID 参数是非标准 Trap，则应当设置为 SNMPv2 snmpTrapOID 参数最后一个子节点/子树的值。
5@：SNMPv1 time-stamp 参数应当设置为 SNMPv2 sysUpTime 参数。
6@：SNMPv1 variable-bindings 应替换为 SNMPv2 variable-bindings。但不应包含 sysUpTime.0 节点和 snmpTrapOID.0。此外，由于 SNMPv2 字句存在例如 Counter64 等 SNMPv1 中未定义的字句，不能在 SNMPv1 数据包中编码对应数据。

详细规则可查看相关资料。

3@多语言下 SNNP entity 的共存：
这通常指的是一个 SNMP entity 应当可以同时支持多个版本的 SNMP 消息。同时由于 SNMPv2 和 SNMPv3 使用相同的 PDU 类型，因此将两者进行合并介绍。

SNMP entity 的 command generator 在向另一个实体发送请求时必须选择适当的消息版本。尤其在选择 SNMPv1 作为传出请求的消息版本时，命令生成器必须将 GetBulk 请求“降级”为 GetNext 请求。

的 SNMP entity 的 command responder 在处理 MIB 数据时应当在 SNMPv1 message processing 中不返回 SNMPv1 不支持的 Counter64 值，不携带 SNMPv1 不支持的错误代码。此外，在处理 SNMPv2c 或 SNMPv3 消息时，不应使用对 MIB 数据的 SNMPv1 访问。

例如，在 SNMPv1 GetRequest-PDU 的 variable-bindings 中名称字段指向 Counter64 类型的对象实例，应返回 GetResponsePDU ，error-status 为 noSuchName，error-index 设置为导致此错误的变量绑定。
并且，应丢弃与此类问题相同的 PDU，并递增计数器 snmpInASNParseErrs。

SNMPv2 提供了一种称为异常的功能，它允许 SNMPv2 Response-PDU 返回尽可能多的管理信息。而 SNMPv1 无法返回任何管理信息，只能返回 error-status 和 error-index。在此情况下，收到 SNMPv1 请求时，命令响应程序必须检查使用 SNMPv2 访问 MIB 数据返回的任何变量绑定，以获取异常值，并将这些异常值转换为 SNMPv1 错误代码。

RFC3584 中定义了如上图所示的 Error Status 映射关系。

详细规则可查看相关资料。

点击此处回到目录

3.SNMPv3协议简易配置

 snmp-agent
 snmp-agent password min-length 10
 snmp-agent local-user password complexity-check disable
 //用于设置本地用户的认证和加密密码、SNMP用户的认证和加密密码、团体名的强度校验及指定长度。
 snmp-agent local-engineid 800007DB034C1FCC000001
 //local-engineid 为系统自动生成引擎ID，标识SNMP agent。通常在SNMPv3下使用。
 snmp-agent group v3 <Group1> privacy read-view <View1> write-view <View1> notify-view
 <View1>
//指定USM模型参数的组名及VACM模型的视图。
 snmp-agent target-host trap-hostname <hostname1> address 192.168.1.1 udp-port 162 pub
lic-net
//配置Trap目的地址为公网192.168.1.1，主机名为hostname1，端口为162。
 snmp-agent target-host trap-paramsname <Name1> v3 securityname <User1> privacy priv
ate-netmanager
//配置Trap报文的发送参数信息列表：列表名为Name1，传送协议为SNMPv3，SNMPv3用户名User1，对报文认证并加密。
 snmp-agent usm-user v3 <User1> <Group1> authentication-mode md5 <a-key00000> privacy-mode des56 <p-key00000>
//指定USM模型的用户及加密认证信息。要求用户的安全级别不低于其所加入的用户组的安全级别。
 snmp-agent protocol source-interface Loopback0
 //设定NE/Agent与NMS交互时使用的源地址。
 snmp-agent sys-info version v3
 //设定SNMP版本信息。缺省情况下，SNMP的协议版本为SNMPv3。
 snmp-agent target-host inform address udp-domain 1.1.1.2 params securityname public v2c
 //指定trap消息的目的服务器及加密信息。
#
 snmp-agent mib-view <View1> included lldpMIB 
 //人为创建名为View1的MIB视图，这里还加入了lldpMIB 子树。系统默认具有ViewDefault视图。 ViewDefault的MIB子树中包括了大部分internet子节点。
#
snmp-agent inform timeout 5
snmp-agent inform resend-times 6
snmp-agent inform pending 7
//设定SNMP inform消息超时时间为 5s，超时后重复发送 6 次，待确认告警的最大条数为 7 条。
//默认为15秒，3次，39条。
snmp-agent packet-priority snmp 5
//设置SNMP报文优先级。取值0-7。
#

点击此处回到目录

更新