网络管理:SNMPv2


SNMPv2 管理信息结构


SNMPv2 的管理信息结构在总结 SNMP 应用经验的基础上对 SNMPv1 SMI 进行了扩充,提供了更精致更严格的规范,规定了新的管理对象和 MIB 的文档,可以说是 SNMPv1 SMI 的超集。

对象的定义

与 SNMPv1 一样,SNMPv2 也是用 ASN.1 宏定义 OBJECT-TYPE 表示管理对象的语法和语义的。SNMPv2 的 OBJECT-TYPE 增加了新的内容,与 SNMPv1 的宏定义有以下差别。

OBJECT-TYPE MACRO::= BEGIN
TYPE NOTATION::="SYNTAX" Syntax
                UnitsPart
                "MAX-ACCESS" Access
                "STATUS"Status
                "DESCRIPTION" Text
                ReferPart
                IndexPart
                DefValPart
VALUE NOTATION::=value (VALUE ObjectName)
END

数据类型

SNMPv2 增加了 Unsigned32 和 Counter64 两种新的数据类型,Counter64 与 Counter32一样,都表示计数器,只能增加不能减少。当计数器增加到上限时回零,从头再增加。SNMPv2 规定计数器没有定义的初始值,所以只有连续两次读计数器得到的增加值才是有意义的。

Unsigned32 与 Gauge32 在 ASN.1 中是无区别的,都是 32 位的整数,但是在 SNMPv2 中语义不一样。SNMPv2 中规定 Gauge32 的最大值可以设置为小于 2^32 的任意正数 MAX,相比于 SNMPv1 中 Gauge32 的最大值总是 2^32-1,SNMPv2 的规定更细致、方便了。SNMPv2 也明确了当计量器达到最大值时可自动减少,相比于原来的“锁定在最大值”更为明确具体。

UnitsPart

在 SNMPv2 的 OBJECT-TYPE 宏定义中增加了 UNITS 子句,用文字说明与对象有关的度量单位。

MAX-ACCESS 子句

MAX-ACCESS 子句,说明最大的访问级别。SNMPv2 定义的访问类型中去掉了write-only 类,增加了一个与概念行有关的访问类型 read-create,表示可读、可写、可生成。SNMPv2的5种访问级别由小到大排列依次是:not-accessible、accessible-for-notify、read-only、 read-write、read-create。

STATUS 子句

STATUS 子句指明对象的状态。新标准去掉了 SNMPvl 中的 optional 和
mandatory,只有 3 种可选的状态。

STATUS 说明
Current 当前标准中有效
Obsolete 废弃,不必实现此对象
deprecated 过时,但为了兼容应该实现此对象

表的定义

与 SNMPv1 一样,SNMPv2 的管理操作只能作用于标量对象(叶子节点),复杂的信息要用表来表示,表是行的序列,行是列对象的序列。

  1. 禁止删除和生成行的表,这种表的最高的访问级别是 read-write。在很多情况下这种表由代理控制,表中只包含 read-only 型的对象。
  2. 允许删除和生成行的表,这种表开始时可能没有行,由管理站生成和删除行。

在 SNMPv2 表的定义中必须含有 INDEX 或 AUGMENTS 子句,INDEX 子句定义了一个基本概念行。AUGMENTS 子句的作用是代替 INDEX 子句,表示概念行的扩展。
而 INDEX 子句中的索引对象确定了一个概念行实例,作为索引的列对象叫做辅助对象,是不可访问的。例如有如下一张表,表中每行有惟一的一对 petType 和 petIndex 实例

假定我们要引用第 2 行第 4 列的对象实例,则实例标识符为:

petCharacteristic2.DOG.5

其中 “DOG” 是无修饰符 IMPLIED 的变长度字符串,编码为 3.68.79.71(4个子标识符),因此实例标识符为:

A.1.4.3.68.79.71.5

表的操作

状态列

允许生成和删除行的表必须有一个列对象,这种列叫做概念行的状态列。其 SYNTAX 子句的值为 RowStatus,MAX-ACCESS子句的值为 read-write,状态列可取 6 种值.

状态列 读写限制 说明
active 可读写 被管理设备可以使用概念行
notInService 可读写 概念行存在,但由于其他原因不能使用
notReady 只读 概念行存在,但因没有信息而不能使用
createAndGo 只写不读 管理站生成一个概念行实例时先设置成 createAndGo,生成过程结束时自动变为 active
createAndWait 只写不读 管理站生成一个概念行实例时先设置成这种状态,但不会自动变成 active
destroy 只写不读 管理站需删除所有的概念行实例时设置成这种状态

这 6 种状态中除 notReady 的 5 种状态是管理站可以用 Set 操作设置的状态,前 3 种可以是响应管理站的查询而返回的状态。

概念行的生成

概念行的生成需要经过如下 4 个步骤:

  1. 选择索引对象的实例标识符;
  2. 管理站通过事务处理产生和激活概念行:管理站通过事务处理产生,与代理协商后生成;
  3. 初始化非默认值对象:Get 操作查询所有列,根据返回值确定是否设置为列对象的值;
  4. 激活概念行:Set 操作设置状态列对象为 active。

概念行的挂起

当概念行处于 active 状态时,如果管理站希望概念行脱离服务,以便进行修改,则可以发出 Set 命令,把状态列由 active 置为 notlnService。这时有两种可能:

  1. 若代理不执行该操作,则返回 wrongValue;
  2. 若代理可执行该操作,则返回 noError。

概念行的删除

管理站发出 Set 命令,把状态列置为 destroy,如果这个操作成功,概念行立即被删除。

通知和信息模块

SNMPv2 提供了通知类型的宏定义 NOTIFICATION-TYPE,用于定义异常条件出现时 SNMPv2 实体发送的信息。

NOTIFICATION-TYPE MACRO::=BEGIN
TYPE NOTATION::=ObjectsPart
    "STATUS" Status
    "DESCRIPTION" Text
    ReferPart
VALUE NOTATION::=value(VALUE NotificationName)
ObjectsPart::="OBJECTS""{"Objects"}"lempty
Objects::=Object|Object","Object
Object::=value(Name ObjectName)
Status::="current"|"deprecated"|"obsolete"
ReferPart::="REFERENCE” Textlempty
Text::="string""
END

任选的 OBJECT 子句定义了包含在通知实例中的 MIB 对象序列,当 SNMPv2 实体发送通知时这些对象的值被传给管理站。DESCRIPTION 子句说明了通知的语义,任选的 REFERENCE 子句包含对其他 MIB 模块的引用。
SNMPv2 还引入了信息模块的概念,用于说明一组有关的定义。信息模块共有以下 3 种:

信息模块 说明
MIB 模块 包含一组有关的管理对象的定义
MIB 的一致性声明模块 说明有关管理对象实现方面的最小要求
代理能力说明模块 说明代理实体应该实现的能力

SNMPv2管理信息库


SNMPv2 MIB 扩展和细化了 MIB-2 中定义的管理对象,又增加了新的管理对象。

功能组 变更
系统组 增加标题对象 sysORLastChange 和表对象 sysORTable
SNMP 组 由 MIB-2 对应的组改造而成
MIB 对象组 与管理对象的控制有关,包含 2 个子组
接口组 纠正了原接口组存在的缺陷,增加 4 个新表

其中SNMP 组是由 MIB-2 的对应组改造而成的,去掉了许多对排错作用不大的变量。

其中接口组增加了 4 张表,它们是接口扩展表、接口堆栈表、接口测试表、接口地址表。

说明
接口扩展表 根据接口名存储一些参数
接口堆栈表 说明接口表中属于同一物理接口的各个行之间的关系
接口测试表 由管理站指示代理系统测试接口的故障
接收地址表 包含每个接口对应的各种地址(广播地址、组播地址和单地址)

SNMPv2 协议数据单元

访问管理信息

SNMPv2 提供了 3 种访问管理信息的方法,分别是:

  1. 管理站和代理之间的请求/响应通信:同 SNMPv1
  2. 管理站和管理站之间的请求/响应通信:SNMPv2 特有(分布式)
  3. 代理到管理站的非确认通信(Trap):同 SNMPv1

SNMPv2 报文

SNMPv2 PDU 封装在报文中传送,报文头提供了简单的认证功能,而 PDU 可以完成上面提到的各种操作。SNMPv2 报文的结构分为 3 部分:版本号、团体名和作为数据传送的 PDU。这个格式与 SNMPv1 一样。
SNMPv2 实体发送和接受报文需要做的动作和 SNMPv1 的一样,不再赘述。

SNMPv2 PDU

SNMPv2 共有 6 种协议数据单元,分为 3 种 PDU 格式。GetRequest、GetNextRequest、SetRequest、InformRequest 和 Trap 等 5 种 PDU 的格式如下。

上述 5 种 PDU 与 Response PDU 具有相同的格式,Response PDU 的格式如下,只是它们的错误状态和错误索引字段被置为 0。

这些协议数据单元在管理站和代理系统之间或者是两个管理站之间交换,以完成需要的协议操作。

GetRequest PDU 和 GetNextRequest PDU

SNMPv2 对 GetRequest PDU、GetNextRequest PDU 操作的响应方式与 SNMPv1 不同,SNMPv1 的响应是原子性的,即只要有一个变量的值检索不到就不返回任何值。而 SNMPv2 的响应不是原子性的,允许部分响应。

GetBulkRequest PDU

GetBulkRequest PDU 是 SNMPv2 对原标准的主要增强,目的是以最少的交换次数检索大量的管理信息。对这个操作的响应,在选择 MIB 变量值时采用与 GetNextRequest 同样的原理,即按照词典顺序选择后继对象实例,但是这个操作可以说明多种不同的后继。

假设 GetBulkRequestPDU 变量绑定表中有 L 个变量,该 PDU 的“非重复数”字段的值为 N,则对前 N 个变量应各返回一个词典后继。再设请求 PDU 的“最大后继数”字段的值为 M,则对其余的 R = L - N 个变量应该各返回最多 M 个词典后继。如果可能,总共返回 N + R x M 个值。如果在任何一步查找过程中遇到不存在后继的情况,则返回错误值 endOfMibView。

例如有如下样例表:

ifIndex ipNetToMediaNetAddress ipNetToMediaPhysAddress ipNetToMediaType
1 9.2.3.4 00 00 10 54 32 10 dynamic
1 10.0.0.51 00 00 10 01 23 45 static
2 10.0.0.15 00 00 10 98 76 54 dynamic

现管理站要检索这个表的值和一个标量对象 sysUpTime 的值,可以发出请求:

GetBulkRequest[非重复数 = 1,最大后继数 = 2]
              {sysUpTime,ipNetToMediaPhysAddress,ipNetToMediaType} 

非重复数为 1,表示对变量列表中前 1 个变量查询一次,也就是对 sysUpTime 查询一次。ipNetToMediaPhysAddress,ipNetToMediaType 2 个变量需要重复查询,重复查询的次数为最大后继树 2。综上所述,代理的响应是:

Response((sysUpTime.0 = "123456"),
         (ipNetToMediaPhysAddress.1.9.2.3.4 = "00 00 10 54 32 10"),
         (ipNetToMediaType.1.9.2.3.4 = "dynamic"),
         (ipNetToMediaPhysAddress.1.10.0.0.51 = "00 00 10 01 23 45"),
         (ipNetToMediaType.1.10.0.0.51 = "static")) 

管理站又发出下一个请求:

GetBulkRequest[非重复数 = 1,最大后继数 = 2]
              {sysUpTime,
               ipNetToMediaPhysAddress.1.10.0.0.51,
               ipNetToMediaType.1.10.0.0.51} 

由于这个查询重复第 2 次时表已经读取完毕,会读取到表外的数据,因此代理的响应是:

Response((sysUpTime.0 = "123466"),
         (ipNetToMediaPhysAddress.2.10.0.0.15 = "00 00 10 98 76 54"),
         (ipNetToMediaType.2.10.0.0.15 = "dynamic"),
         (ipNetToMediaType.1.9.2.3.4 = "dynamic"),
         (ipRoutingDiscards.0 = "2"))  

SetRequest PDU

SetRequest PDU 请求的格式和语义与 SNMPv1 的基本相同,SNMPv2 实体分两个阶段处理这个请求的变量绑定表。首先是检验操作的合法性,然后再更新变量,如果至少有一个变量绑定对的合法性检验没有通过,则不进行下一阶段的更新操作。所以这个操作与 SNMPv1 一样,是原子性的。

Trap PDU

Trap PDU 是由代理发给管理站的非确认性消息,SNMPv2 的陷入采用与 Get 等操作相同的 PDU 格式。

InformRequest PDU

InformRequest PDU 是管理站发送给管理站的消息,其 PDU 格式与Get等操作相同,变量绑定表的内容与陷入报文的一样。但是这个消息是需要应答的,所以管理站收到通知请求后首先要决定
应答报文的大小,如果应答报文大小超过本地或对方的限制,则返回错误状态 tooBig。如果接收的请求报文不是太大,则把有关信息传送给本地的应用实体,返回一个错误状态为 noErr 的响应报文,其变量绑定表与收到的请求 PDU 相同。

管理站之间的通信

SNMPv2 增加的管理站之间的通信机制是分布式网络管理所需要的功能特征,为此引入了通知报文InformRequest 和管理站数据库(manager-to-manager MIB)。管理站数据库主要由 3 个表组成,由这 3 个表以及其他有关标量对象共同组成了 snmpM2M 模块,表示了管理站之间交换的主要信息。

说明
snmpAlarmTable(报警表) 提供被监视的变量的有关情况
snmpEventTable(事件表) 记录 SNMPv2 实体产生的重要事件
snmpEventNotifyTable(事件通知表) 定义了发送通知的目标和通知的类型

参考资料

《计算机网络管理(第三版)》雷震甲 编著,西安电子科技大学出版社

posted @ 2021-05-30 12:29  乌漆WhiteMoon  阅读(4315)  评论(0编辑  收藏  举报