snmp v2

4.4 SNMPv2
4.4.1 SNMPv2对SNMPv1的改进
1993年,SNMP的改进版SNMPv2开始发布,从此,原来的SNMP便被称为SNMPv1。最初的SN
MPv2最大的特色是增加了安全特性,因此被称为安全版SNMPv2。但不幸的是,经过几年
试用,没有得到厂商和用户的积极响应,并且也发现自身还存在一些严重缺陷。因此,
在1996正式发布的SNMPv2中,安全特性被删除。这样,SNMPv2对SNMPv1的改进程度便受
到了很大的削弱。
总的来说,SNMPv2的改进主要有以下3个方面:
l 支持分布式管理;
l 改进了管理信息结构;
l 增强了管理信息通信协议的能力。
SNMPv1采用的是集中式网络管理模式。网络管理站的角色由一个主机担当。其他设备(包
括代理者软件和MIB)都由管理站监控。随着网络规模和业务负荷的增加,这种集中式的
系统已经不再适应需要。管理站的负担太重,并且来自各个代理者的报告在网上产生大
量的业务量。而SNMPv2不仅可以采用集中式的模式,也可以采用分布式模式。在分布式
模式下,可以有多个顶层管理站,被称为管理服务器。每个管理服务器可以直接管理代
理者。同时,管理服务器也可以委托中间管理者担当管理者角色监控一部分代理者。对
于管理服务器,中间管理器又以代理者的身份提供信息和接受控制。这种体系结构分散
了处理负担,减小了网络的业务量。
SNMPv2的管理信息结构(SMI)在几个方面对SNMPv1的SMI进行了扩充。定义对象的宏中
包含了一些新的数据类型。最引人注目的变化是提供了对表中的行进行删除或建立操作
的规范。新定义的SNMPv2 MIB包含有关SNMPv2协议操作的基本流量信息和有关SNMPv2管
理者和代理者的配置信息。
在通信协议操作方面,最引人注目的变化是增加了两个新的PDU—GetBulkRequest 和 I
nformRequest。前者使管理者能够有效地提取大块的数据,后者使管理者能够向其他管
理者发送trap信息。
  
4.4.2 SNMPv2网络管理框架
  SNMPv2提供了一个建立网络管理系统的框架。但网络管理应用,如故障管理、性能
监测、计费等不包括在SNMPv2的范围内。用术语来说,SNMPv2提供的是网络管理基础结
构。图4.7是这种基础结构的一个配置例。
  SNMPv2本质上是一个交换管理信息的协议。网络管理系统中的每个角色都维护一个
与网络管理有关的MIB。SNMPv2的SMI对这些MIB的信息结构和数据类型进行定义。SNMPv
2提供了一些一般的通用的MIB,厂商或用户也可以定义自己私有的MIB。
  在配置中至少有一个系统负责整个网络的管理。这个系统就是网络管理应用驻留的
地方。管理站可以设置多个,以便提供冗余或分担大网络的管理责任。其他系统担任代
理者角色。代理者收集本地信息并保存,以备管理者提取。这些信息包括系统自身的数
据,也可以包括网络的业务量信息。
  SNMPv2既支持高度集中化的网络管理模式,也支持分布式的网络管理模式。在分布
式模式下,一些系统担任管理者和代理者两种角色,这种系统被称为中间管理者。中间
管理者以代理者身份从上级管理系统接受管理信息操作命令,如果这些命令所涉及的管
理信息在本地MIB中,则中间管理者便以代理者身份进行操作并进行应答,如果所涉及的
管理信息在中间管理者的下属代理者的MIB中,则中间管理者先以管理者身份对下属代理
者进行发布操作命令,接收应答,然后再以代理者身份向上级管理者应答。
  所有这些信息交换都利用SNMPv2通信协议实现。与SNMPv1相同,SNMPv2协议仍是一
个简单的请求(request)/应答(response)型协议,但在PDU种类和协议功能方面对SNMPv
1进行了扩充。
图4.7 SNMPv2的配置
4.4.3 协议操作
SNMPv2消息
与SNMPv1相同,SNMPv2以包含协议数据单元(PDU)的消息的形式交换信息。外部的消息结
构中包含一个用于认证的共同体名。
SNMPv2确定的消息结构如下:
Message :: = SEQUENCE {
   version   INTEGER { version (1) }, -- SNMPv2的版本号为1
   community  OCTET STRING,   -- 共同体名
   data   ANY     -- SNMPv2 PDU
   }
4.3.2节中对于共同体名、共同体轮廓和访问策略的讨论同样适用于SNMPv2。
SNMPv2消息的发送和接收过程与4.3.5节中描述的SNMPv1消息的发送和接收过程相同。
PDU格式
表4.11 SNMP协议数据单元(PDUs)
PDU 描  述 SNMPv1 SNMPv2
GetGetNextGetBulkSetTrapInformResponse 管理者通过代理者获得每个对象的值管理者
通过代理者获得每个对象的下一个值管理者通过代理者获得每个对象的N个值管理者通过
代理者为每个对象设置值代理者向管理者传送随机信息管理者向代理者传送随机信息代
理者对管理者的请求进行应答 ○○○○○ ○○○○○○○
  在SNMPv2消息中可以传送7类PDU。表4.11列出了这些PDU,同时指出了对SNMPv1也有
效的PDU。图4.8 描述了SNMPv2 PDU的一般格式。
(a) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU,
SNMPv2-Trap-PDU,InformRequest-PDU
(b) Response-PDU
(c) GetBulkRequest-PDU
(d) Variable-bindings
图4.8 SNMPv2 PDU格式
值得注意的是,GetRequest、GetNextRequest、SetRequest、SNMPv2-Trap、InformReq
ues 5种PDU具有完全相同的格式,并且与也可以看作是error-status和error-index两个
字段被置零的Response PDU的格式。这样设计的目的是为了减少SNMPv2实体需要处理的
PDU格式种类。
GetRequest PDU
SNMPv2的GetRequest PDU的语法和语义都与SNMPv1的GetRequest PDU相同,差别是对应
答的处理。SNMPv1的GetRequest是原子操作:要么所有的值都返回,要么一个也不返回,
而SNMPv2能够部分地对GetRequest操作进行应答。即使有些变量值提供不出来,变量绑
定字段也要包含在应答的GetResponse PDU之中。如果某个变量有意外情况(noSuchObje
ct, noSuchInstance,endOfMibView),则在变量绑定字段中,这个变量名与一个代表意
外情况的错误代码而不是变量值配对。
在SNMPv2中,按照以下规则处理GetRequest变量绑定字段中的每个变量来构造应答PDU:

l 如果OBJECT IDENTIFIER前缀与该请求在代理者处所能访问的变量的前缀都不匹配,则
它的值字段被设置为noSuchObject;
l 否则,如果变量名与该请求在代理者处所能访问的变量的名称都不匹配,则它的值字
段被设置为noSuchInstance;
l 否则,值字段被设置为变量值。
如果由于其他原因导致变量名处理过程的失败,则无法返回变量值。这时,应答实体将
返回一个error-status字段值为genErr,并在error-index字段中指出出问题的变量的应
答PDU。
如果生成的应答PDU中的消息尺寸过大,超过了指定的最大限度,则生成的PDU被丢弃,
并用一个error-status字段值为tooBig,error-index字段值为0,变量绑定字段为空的
新的PDU应答。
允许部分应答是对GetRequest的重要改进。在SNMPv1中,只要有一个变量值取不回来,
所有的变量值就都不能返回。在这种情况下,发出操作请求的管理者往往只能将命令拆
分为多条只取单个变量值的命令。相比之下,SNMPv2的操作效率得到了很大提高。
GetNextRequest PDU
SNMPv2的GetNextRequest PDU的语法和语义都与SNMPv1的GetNextRequest PDU相同。与
GetRequestPDU相同,两个版本的差别是对应答的处理。SNMPv1的GetNextRequest是原子
操作:要么所有的值都返回,要么一个也不返回,而SNMPv2能够部分地对GetNextReques
t操作进行应答。
在SNMPv2中,按照以下规则处理GetNextRequest变量绑定字段中的每个变量来构造应答
PDU:
l 确定被指名的变量下一个变量,将该变量名和它的值成对地放入结果变量绑定字段中
;
l 如果被指定的变量之后不存在变量,则将被指定的变量名和错误代码endOfMibView成
对地放入结果变量绑定字段中。
如果由于其他原因导致变量名处理过程的失败,或者是产生的结果太大,处理过程与Ge
tRequest相同。
GetBulkRequest
  SNMPv2的一个主要改进是GetBulkRequest PDU。这个PDU的目的是尽量减少查询大量
管理信息时所进行的协议交换次数。GetBulkRequest PDU允许SNMPv2管理者请求得到在
给定的条件下尽可能大的应答。
  GetBulkRequest操作利用与GetNextRequest相同的选择原则,即总是顺序选择下一
个对象。不同的是,利用GetBulkRequest,可以选择多个后继对象。
  GetBulkRequest操作的基本工作过程如下:GetBulkRequest在变量绑定字段中放入
一个(N+R)个变量名的清单。对于前N个变量名,查询方式与GetNextRequest相同。即,
对清单中的每个变量名,返回它的下一个变量名和它的值,如果没有后继变量,则返回
原变量名和一个endOfMibView的值。
  GetBulkRequest PDU有两个其他PDU所没有的字段,non-repeaters和max-repetiti
ons。
non-repeaters字段指出只返回一个后继变量的变量数。max-repetitions字段指出其他
的变量应返回的最大的后继变量数。为了说明算法,我们定义:
L = 变量绑定字段中的变量名数量
N = 只返回一个后继变量的变量名数
R = 返回多个后继变量的变量名数
M = 最大返回的后继变量数
  在上述变量之间存在以下关系:
N = MAX [MIN(non-reperters, L),0]
M = MAX [max-repetitions,0]
R = L - N
  如果N大于0,则前N个变量与GetNextRequest一样被应答。如果R大于0并且M大于0,
则对应后面的R个变量,返回M个后继变量。即,对于每个变量:
·获得给定变量的后继变量的值;
·获得下一个后继变量的值;
·反复执行上一步,直至获得M个对象实例。
  如果在上面的过程中的某一点,已经没有后继变量,则返回endOfMibView值,在变
量名处,返回最后一个后继变量,如果没有后继变量,则返回请求中的变量名。
  利用这个规则,能够产生的name-value对的数量是N+(M×R)。后面的(M×R)对在应
答PDU中的顺序可描述为:
  for i : = 1 to M do
   for r : = 1 to R do
   retrieve  i-th successor of (N+r)-th variable
  即,返回的后继变量是一行一行的,而不是先返回第一个变量的所有后继变量,再
返回第二个变量的所有后继变量,等等。
GetBulkRequest操作解除了SNMP的一个主要限制,即不能有效地检索大块数据。此外,
利用这个功能可以减小管理应用程序的规模。管理应用程序自身不需要关心组装在一起
的请求的细节。不需要执行一个试验过程来确认请求PDU中的name-value对的最佳数量。
并且,即使GetBulkRequest发出的请求过大,代理者也会尽量多地返回数据不是简单地
返回一个tooBig的错误消息。为了获得缺少的数据,管理者只需简单地重发请求,而不
必将原来的请求改装为小的请求序列。
SetRequest
SetRequest PDU由管理者发出,用来请求改变一个或多个对象的值。接收实体用一个包
含相同request-id的Response PDU应答。与SNMPv1相同,SetRequest操作是原子操作,
即或者更新所有被指名的变量,或者所有的都不更新。如果接收实体能够为被指名的所
有变量设置新值,则Response PDU返回与SetRequest相同的变量绑定字段。只要有一个
变量值没设置成功,就不更新任何值。
SetRequest的变量绑定分两个阶段处理。在第一阶段,确认每个绑定对。如果所有的绑
定对都被确认,则进入第二阶段—改变每个变量。即每个变量的set操作都在第二阶段进
行。
在第一阶段中,对每个绑定对进行以下确认,直至所有的都成功或遇到一个失败。失败
的原因有:不可访问(noAccess)、无法建立或修改(notWritable)、数据类型不一致(wro
ngType)、长度不一致(wrongLength)、ASN.1编码不一致、变量值有问题(wrongValue)、
变量不存在且无法建立(noCreation)等。如果任意一个变量遇到以上情况,则返回一个
在error-status字段给出上述错误代码,在error-index字段给出有问题的变量的序号的
应答PDU。与SNMPv1相比,提供了更多的错误代码。为管理站更容易地确定失败的原因提
供了方便。
如果在确认阶段没有遇到问题,则进入第二阶段—更新在变量绑定字段中被指名的所有
的变量。不存在的变量需要建立,存在的变量被赋予新值。只要遇到任何失败,则所有
的更新都被撤销,并则返回一个error-status字段值为commitFailed的应答PDU。
SNMPv2 Trap
SNMPv2 Trap PDU由一个代理者实体在发现异常事件时产生并发给管理站。与SNMPv1相同
,它用于向管理站提供一个异步的通报以便报告重要事件。但它的格式与SNMPv1不同,
与GetRequest、GetNextRequest、GetBulkRequest、SetRequest和InformRequest PDU拥
有相同的格式。变量绑定字段用于容纳与陷阱消息有关的信息。Trap PDU是一个非认证
消息,不要求接收实体应答。
InformRequest
InformRequest PDU由一个管理者角色的SNMPv2实体应它的应用的要求发给另一个管理者
角色的SNMPv2实体,请求后者向某个应用提供管理信息。与SNMPv2 Trap PDU类似,变量
绑定字段被用于传送相关的信息。
收到InformRequest的实体首先检查承载应答PDU的消息尺寸,如果消息尺寸超过限度,
用一个含有tooBig错误代码的Response PDU应答。否则,接收实体将PDU中的内容转到信
息的目的地(某个应用),同时对发出InformRequest的管理者用error-status字段值为n
oError的Response PDU进行应答。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值