SNMP操作模型.docVIP

SNMP协议 SNMP操作模型 目前，计算机网络中应用得最广泛的网络管理协议是简单网络管理协议（SNMP）。图1简单示意了SNMP协议的操作模型。 图1 SNMP操作模型 从图中可以看出，SNMP的结构分为NMS和AGENT两部分，NMS（Network Management Station）向Agent发请求，Agent是驻留在被管设备上的一个进程或任务，它负责处理来自NMS的请求报文，进行解码分析，然后从设备上的相关模块中取出管理变量的值，生成Response报文，编码返送回NMS。代理通过Trap报文主动向管理站报告网络异常情况，如接口故障或阈值告警等。 SNMP固定承载在UDP协议之上，占用161和162两个端口号进行信息传输。代理在161端口侦听Request消息，管理站在162端口侦听传来的Trap报文。我们前面介绍过UDP是无连接的不可靠的传输协议，所以在网络管理站和网络管理代理之间不需要保持连接来传输消息，这样降低了连接断开和建立所引起的系统开销。 图2进一步详细描述了SNMP的内容。 图2 SNMP协议框架 从图中可以看出，SNMP使用Get/Set报文对管理信息变量进行操作，所谓管理变量，是在标准MIB库中定义的。MIB是一个树型结构的数据库，是各种管理变量的集合，它反映了被管理对象在系统中的状态。通过读取MIB中对象的值，网络管理站完成网络监视，也通过修改这些值来控制系统中的资源。关于MIB的结构我们在后面进行比较详细的介绍。 在SNMP中，网络管理站和网络管理代理中传递五种报文实现对变量的操作，具体如下： Get Request报文：用于管理站从代理获取指定管理变量的值 GetNext Request报文：用于管理站从代理连续获取一组管理变量的值 GetResponse报文：用于代理响应管理站的请求，返回请求值或错误类型等 Set Request报文：用于管理站设置代理中的指定的管理变量的值 Trap报文：用于代理向管理站发送非请求的管理变量的值 当SNMP 管理站接收到Trap后，可产生相应的动作，如轮询检测（polling）来诊断故障，采取恢复措施，修改网管的相关数据库。 SNMP MIB库 最初在RFC1156中定义了SNMP管理信息库的第一个版本MIB-1，目前已经被在RFC1213中定义的MIB-2所取代。MIB-2是MIB-1的补充，它增加了一些对象和组。如前面所述，MIB库是一个树型结构的数据库，它定义了被管理对象的各种管理变量。每个被管对象对应树形结构的一个叶子接点，称为一个object或一个MIB。 图3 MIB数据库结构示意图 如图3所示，管理对象B可以用一串数字唯一确定 1.2.1.1 ，这串数字是管理对象的object identifier（对象标识符）。通过object identifier可确定从根到 B的一条路径。管理对象A的object identifier 是 1.2.1.1.5 ，或 B 5 ，后一种表示方法表明A是B的第5棵子节点。在agent中这棵树是用较复杂的数据结构来实现的，幸运的是，建树这个工作可由MIB编译器完成。在树的叶节点中，存放有访问函数的指针，Agent就是通过调用这些函数来从相关模块取得管理变量的值的。管理变量则表示管理对象类型在某一时刻的值（或称该类型的实例），SNMP以管理变量作为操作对象。 管理变量的表示方法是这样规定的：形如x.y，其中x是管理对象的object identifier。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。 驻留在被管设备上的Agent从UDP端口161接受来自网络管理站的串行化报文，经解码、团体名验证、分析得到管理变量在MIB树中对应的节点，从相应的模块中得到管理变量的值，再形成响应报文，编码发送回管理站；管理站得到响应报文后，再经同样的处理，最终显示结果。 远程网络监视 由于SNMP使用轮询机制采集设备数据，也就是说，使用SNMP，你必须发出请求以取得响应。这种类型的轮询将产生大量的网络管理报文，一方面可能导致网络拥塞，另一方面也可能引起网管工作站的崩溃。 另外SNMP还有一些众所周知的缺点：它只具有一般的验证功能，无法提供可靠的安全保证；不支持分布式管理，而采用集中式管理。这使得数据采集和数据