SNMP 协议

SNMP协议

目录[隐藏]

概述

SNMP协议详解

1. 1. SNMP基本原理
2. 2. 管理信息库MIB
3. 3. SNMP的五种消息类型
4. SNMP的运行过程

收集数据的方法

概述

SNMP协议详解

1. 1. SNMP基本原理
2. 2. 管理信息库MIB
3. 3. SNMP的五种消息类型
4. SNMP的运行过程

收集数据的方法

　　

[ 编辑本段]

概述

　　简单网络管理协议 (Simple Network Management Protocol SNMP)首先是由Internet工程任务组织(Internet Engineering Task Force)(IETF)的研究小组为了解决Internet上的路由器管理问题而提出的。许多人认为 SNMP在IP上运行的原因是Internet运行的是TCP/IP协议，然而事实并不是这样。 　　SNMP被设计成与协议无关，所以它可以在IP，IPX，AppleTalk，OSI以及其他用到的传输协议上被使用。 　　SNMP是一系列协议组和规范（见下表），它们提供了一种从网络上的设备中收集网络管理信息的方法。SNMP也为设备向网络管理工作站报告问题和错误提供了一种方法。 　　名字 说明 　　MIB 管理信息库 　　SMI 管理信息的结构和标识 　　SNMP 简单网络管理协议 　　SNMP在TCP/IP协议族中的地位如下图： 　　

[ 编辑本段]

SNMP协议详解

1. SNMP基本原理

　　SNMP采用了Client/Server模型的特殊形式：代理/管理站模型。对网络的管理与维护是通过管理工作站与SNMP代理间的交互工作完成的。每个SNMP从代理负责回答SNMP管理工作站（主代理）关于MIB定义信息的各种查询。下图10是NMS公司网络产品中SNMP协议的实现模型。 　　

　　SNMP代理和管理站通过SNMP协议中的标准消息进行通信，每个消息都是一个单独的数据报。SNMP使用UDP（用户数据报协议）作为第四层协议（传输协议），进行无连接操作。SNMP消息报文包含两个部分：SNMP报头和协议数据单元PDU。数据报结构如下图 　　

　　版本识别符（version identifier）：确保SNMP代理使用相同的协议，每个SNMP代理都直接抛弃与自己协议版本不同的数据报。 　　团体名（Community Name）：用于SNMP从代理对SNMP管理站进行认证；如果网络配置成要求验证时，SNMP从代理将对团体名和管理站的IP地址进行认证，如果失败，SNMP从代理将向管理站发送一个认证失败的Trap消息 　　协议数据单元（PDU）：其中PDU指明了SNMP的消息类型及其相关参数。

2. 管理信息库MIB

　　IETF规定的管理信息库MIB（由中定义了可访问的网络设备及其属性，由对象识别符（OID：Object Identifier）唯一指定。MIB是一个树形结构，SNMP协议消息通过遍历MIB树形目录中的节点来访问网络中的设备。　 　　下图给出了NMS系统中SNMP可访问网络设备的对象识别树（OID：Object Identifier）结构。 　　

　　下图给出了对一个DS1线路状态进行查询的OID设置例子。 　　

3. 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组合起来查询特定的表对象中的列元素。如：首先通过下面的原语获得所要查询的设备的接口数： 　　{iso org(3) dod(6) internet(1) mgmt(2) mib(1) interfaces(2) ifNumber(2)} 　　后再通过下面的原语，进行查询（其中第一次用Get-Request，其后用Get-Next-Request）： 　　{iso org(3) dod(6) internet(1) mgmt(2) mib(1) interfaces(2) ifTable(2)} 　　(2)Set-Request 　　SNMP管理站用Set-Request 可以对网络设备进行远程配置（包括设备名、设备属性、删除设备或使某一个设备属性有效/无效等）。 　　(3)Trap 　　SNMP代理使用Trap向SNMP管理站发送非请求消息，一般用于描述某一事件的发生。

SNMP的运行过程

　　留在被管设备上的AGENT从UDP端口161接受来自 网管站的串行化报文，经解码、团体名验证、分析得到管理变量在MIB树中对应的节点，从相应的模块中得到管理变量的值，再形成响应报文，编码发送回网管站。网管站得到响应报文后，再经同样的处理，最终显示结果。

[ 编辑本段]

收集数据的方法

　　从被管理设备中收集数据有两种方法：一种是只轮询（polling-only）的方法，另一种是基于中断（interrupt-based）的方法。 　　如果你只使用只轮询的方法，那么网络管理工作站总是在控制之下。而这种方法的缺陷在于信息的实时性，尤其是错误的实时性。你多久轮询一次，并且在轮询时按照什么样的设备顺序呢？如果轮询间隔太小，那么将产生太多不必要的通信量。如果轮询间隔太大，并且在轮询时顺序不对，那么关于一些大的灾难性的事件的通知又会太馒。这就违背了积极主动的网络管理目的。 　　当有异常事件发生时，基于中断的方法可以立即通知网络管理工作站（在这里假设该设备还没有崩溃，并且在被管理设备和管理工作站之间仍有一条可用的通信途径）。然而，这种方法也不是没有他的缺陷的，首先，产生错误或自陷需要系统资源。如果自陷必须转发大量的信息，那么被管理设备可能不得不消耗更多的时间和系统资源来产生自陷，从而影响了它执行主要的功能（违背了网络管理的原则2）。 　　而且，如果几个同类型的自陷事件接连发生，那么大量网络带宽可能将被相同的信息所占用（违背了网络管理的原则1）。尤其是如果自陷是关于网络拥挤问题的时候，事情就会变得特别糟糕。克服这一缺陷的一种方法就是对于被管理设备来说，应当设置关于什么时候报告问题的阈值（threshold）。但不幸的是这种方法可能再一次违背了网络管理的原则2，因为设备必须消耗更多的时间和系统资源，来决定一个自陷是否应该被产生。 　　结果，以上两种方法的结合：面向自陷的轮询方法（trap-directed polling）可能是执行网络管理最为有效的方法了。一般来说，网络管理工作站轮询在被管理设备中的代理来收集数据，并且在控制台上用数字或图形的表示方式来显示这些数据。这就允许网络管理员分析和管理设备以及网络通信量了。 　　被管理设备中的代理可以在任何时候向网络管理工作站报告错误情况，例如预制定阈值越界程度等等。代理并不需要等到管理工作站为获得这些错误情况而轮询他的时候才会报告。这些错误情况就是众所周知的SNMP自陷（trap）。 　　在这种结合的方法中，当一个设备产生了一个自陷时，你可以使用网络管理工作站来查询该设备（假设它仍然是可到达的），以获得更多的信息。