网络协议篇之SNMP协议（一）——SNMP报文协议

（前言：最近工作中遇到大量的网络协议开发，现就其中一些网络协议的基础知识进行整理，文中借鉴了一些大神的整理，后面会贴上链接，如侵删）

简单网络管理协议（SNMP）是TCP/IP协议簇的一个应用层协议。在1988年被制定，并被Internet体系结构委员会（IAB）采纳作为一个短期的网络管理解决方案；由于SNMP的简单性，在Internet时代得到了蓬勃的发展，1992年发布了SNMPv2版本，以增强SNMPv1的安全性和功能。现在，已经有了SNMPv3版本。（知道有几个版本就可以了，先公司所用版本是SNMPv2）。

一套完整的SNMP系统主要包括管理信息库（MIB）、管理信息结构（SMI）及SNMP报文协议。

我们先来了解一下SNMP报文协议：

一、SNMP协议概述

简单网络管理协议（SNMP：Simple Network Management Protocol）是由互联网工程任务组（IETF：Internet Engineering Task Force ）定义的一套网络管理协议。该协议基于简单网关监视协议（SGMP：Simple Gateway Monitor Protocol）。利用SNMP，一个管理工作站可以远程管理所有支持这种协议的网络设备，包括监视网络状态、修改网络设备配置、接收网络事件警告等。 虽然SNMP开始是面向基于IP的网络管理，但作为一个工业标准也被成功用于电话网络管理。

二、SNMP的工作原理

SNMP采用特殊的客户机/服务器模式，即代理/管理站模型。对网络的管理与维护是通过管理工作站与SNMP代理间的交互工作完成的。每个SNMP从代理负责回答SNMP管理工作站（主代理）关于MIB定义信息的各种查询。

SNMP的应用场景如图所示：

管理站和代理端使用MIB进行接口统一，MIB定义了设备中的被管理对象。管理站和代理都实现相应的MIB对象，使得双方可以识别对方的数据，实现通信。管理站向代理请求MIB中定义的数据，代理端识别后，将管理设备提供的相关状态或参数等数据转换成MIB定义的格式，最后将该信息返回给管理站，完成一次管理操作。

三、SNMP的报文类型

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工作流程如图

四、SNMP报文格式

下图是封装成UDP数据报的5种操作的SNMP报文格式。可见一个SNMP报文共有三个部分组成，即公共SNMP首部、get/set首部、trap首部、变量绑定。

1、公共SNMP首部

共三个字段：

a — 版本

写入版本字段的是版本号减1，对于SNMP（即SNMPV1）则应写入0。

b — 共同体（community）

共同体就是一个字符串，作为管理进程和代理进程之间的明文口令，常用的是6个字符“public”。

c — PDU类型

根据PDU的类型，填入0～4中的一个数字，其对应关系如下图

2、get/set首部

a — 请求标识符(request ID)

这是由管理进程设置的一个整数值。代理进程在发送get-response报文时也要返回此请求标识符。管理进程可同时向许多代理发出get报文，这些报文都使用UDP传送，先发送的有可能后到达。设置了请求标识符可使管理进程能够识别返回的响应报文对于哪一个请求报文

b — 差错状态（error status）

由代理进程回答时填入0～5中的一个数字，见下图描述

c — 差错索引(error index)

当出现noSuchName、badValue或readOnly的差错时，由代理进程在回答时设置的一个整数，它指明有差错的变量在变量列表中的偏移。

3、trap首部

a — 企业（enterprise）

填入trap报文的网络设备的对象标识符。此对象标识符肯定是在图3的对象命名树上的enterprise结点{1.3.6.1.4.1}下面的一棵子树上。

b — trap类型

此字段正式的名称是generic-trap，共分为表4中的7种

当使用上述类型2、3、5时，在报文后面变量部分的第一个变量应标识响应的接口。

c — 特定代码(specific-code)

指明代理自定义的时间（若trap类型为6），否则为0。

d — 时间戳(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、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相同。

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。这个响应通知网管站对表的遍历已经完成。

3、GetResponse PDU

GetResponse PDU只有当受到getRequest GetNextRequest SetRequest才由协议实体产生，网管站收到这个PDU后，应显示其结果。

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。

5、Trap PDU

Trap PDU的有如下的形式

Trap是被管设备遇到紧急情况时主动向网管站发送的消息。网管站收到trap PDU后要将起变量对偶表中的内容显示出来。一些常用的trap类型有冷、热启动，链路状态发生变化等。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/181092.html原文链接：https://javaforall.cn