<p>RMON和SNMP的主要区别是(47)。</p>

和SNMP同一时期还出现了用于监控局域网通信的标准——远程网络监控RMON（Remote MONitoring），即RMON-1（1991）和RMON-2（1995）。RMON是一组定义了监视网络通信的管理信息库的标准，是SNMP管理信息库的扩充，与SNMP配合可以提供更有效的管理性能。同时，为了适应电信网络的管理需要，ITU-T在1989年定义了电信网络管理标准（Telecommunications Management Network， TMN），即M.30建议。

MIB-Ⅱ能提供的只是关于单个设备的管理信息。通常把用于监视整个网络通信情况的设备称为网络监视器（Monitor）或网络分析器（Analyzer）、探测器（Probe）等。监视器观察LAN上出现的每个分组，并进行统计，给管理人员提供重要的管理信息。监视器还能存储部分分组，供以后分析用。监视器也根据分组类型进行过滤并捕获特殊的分组。通常是每个子网配置一个监视器，并且与中央管理站通信，因此称为远程监视器，如下图所示。图中监视器可以是一个独立设备，也可以是运行监视器软件的工作站或服务器等。中央管理站具有RMON管理能力，能够与各个监视器交换管理信息。RMON监视器或探测器（RMON Probe）实现RMON管理信息库（RMON MIB）。这种系统与通常的SNMP代理一样包含一般的MIB，另外，还有一个探测器进程，提供与RMON有关的功能。探测器进程能够读／写本地的RMON数据库，并响应管理站的查询请求。所以也把RMON探测器称为RMON代理。

远程网络监视的配置

RMON定义了远程网络监视的管理信息库，以及SNMP管理站与远程监视器之间的接口。

一般地说，RMON的目标就是监视子网范围内的通信，从而减少管理站和被管理系统之间的通信负担。更具体地说，RMON有下列目标。

.离线操作。必要时管理站可以停止对监视器的轮询，有限的轮询可以节省网络带宽和通信费用。

.主动监视。如果监视器有足够的资源，通信负载也允许，监视器可以连续地、周期地运行诊断程序，收集并记录网络性能参数。

.问题检测和报告。如果主动监视消耗网络资源太多，监视器也可以被动地获取网络数据。

.提供增值数据。监控器可以分析收集到的子网数据，从而减轻了管理站的计算任务。

.多管理站操作。一个互联网可能有多个管理站，这样可以提高可靠性，或者分布地实现各种不同的管理功能。

在SNMPv1的管理框架中，对表操作的规定是很不完善的，至少增加和删除表行的操作是不明确的。RMON规范包含一组文本约定和过程化规则，在不修改、不违反SNMP管理框架的前提下提供了明晰而规律的行增加和行删除操作。

RMON的管理信息库

RMON规范定义了RMON管理信息库RMON MIB，它是MIB-Ⅱ下面的第十六个子树。RMON MIB分为10组，如下图所示。存储在每一组中的信息都是监视器从一个或几个子网中统计和收集的数据。这10个功能组都是任选的，但实现时有下列连带关系。

RMON MIB子树

.实现警报组时必须实现事件组。

.实现最高N台主机组时必须实现主机组。

.实现捕获组时必须实现过滤组。

这10个功能组的功能说明如下。

1）统计组

统计组（Statistics）统计被监控的每个子网的基本统计信息。网络管理员可以从RMON探针监测的设备端口获取一个网段的各种统计信息。目前只能对网络设备的以太网接口进行监控和统计，将来会扩展到包括更多接口的特定表格（如FDDI）。它能统计一个网段的流量（如交通流量的总包数和总字节数），统计各种类型包的分布（如广播包、多点广播包、不同大小包的数量），还能统计各种类型错误包数、碰撞次数等。

2）历史组

历史组（History）定期地收集统计网络值的记录并存储起来，方便日后的处理。它包含历史控制组和以太网历史组两个小组。其中，历史控制组主要用来设置采样间隔时间等控制信息；以太网历史组为网络管理员提供有关网段流量、错误包、广播包、利用率及碰撞次数等其他统计信息的历史数据。

3）警报组

警报组（Alarm）允许网络管理站为网络性能（可以是监视器本地MIB的任意整数类型的对象）定义一组报警阈值。如果阈值在相应的方向上被越过，监视器就会产生警报并把警报发往网络管理站。警报组需要事件组的实现。

4）主机组

主机组（Host）包含对连接在一个子网上所有主机的各种类型统计的计数值。它能够发现网上的新主机，对每个主机的MAC地址保持一组统计数据，如主机发送或接收的数据包总数、广播包数、流量字节数和错误包数等。它有一个控制表和两个数据表，且这两个数据表的内容相同，只是组织排列顺序不同。

5）最高主机组

最高主机组（Host TopN）包括排序后的主机统计，该报告基于主机表中的一些参数生成列表。它用于统计在一个子网上一些参数最高的一组主机，如它可以列出10个传输数据最多的主机，但依赖于主机组的实现。

6）矩阵组

矩阵组（Matrix）用于记录关于子网上两个主机之间流量的信息，该信息以矩阵形式存储。这种方法对于检索特定主机之间的流量信息十分有用，如用于找出哪些设备对服务器的使用最多。矩阵组由3个表组成，即一个控制表加上两个数据表。

7）过滤组

过滤组（Filter）允许监视器观测与过滤器相匹配的数据包。网络监视器可以捕获所有通过过滤器的数据包或简单地记下基于这些数据包的统计。

8）包捕获组

包捕获组（Capture）控制数据被发往网管站的方式，它可以在把报文发送到某个通道后记录数据报文。

9）事件组

事件组（Event）提供关于RMON代理所产生的所有事件的列表。当某事件发生时可以记录日志和发送IRAP到网管站。

10）令牌环网组

RFC1513扩展了RMON MIB，增加了有关IEEE 802.5令牌环网的管理信息。首先是在统计组增加了两个表，即tokenRingMLStatsTable和tokenRingPStatsTable，前者统计令牌环中各种MAC控制分组，后者统计各种数据分组。根据RFC1757的定义，好的分组就是没有错误并具有有效长度的分组；坏的分组是帧格式可以识别，但是含有错误，或者具有无效长度的分组。

RMON2的管理信息库

尽管RMON有很多优点，但也有其局限性。RMON的MAC层探测器不能确定由服务器进入本地网段的数据包的源点和终点，或者是不能确定经过被监视网段的通信数据包的源点和终点。

1994年，RMON2工作组开始致力于提高现存的物理层和数据链路层之间的RMON规范，以实现在网络层和应用层提供历史和数据的统计服务。

在网络层，RMON2通过监视点对点通信来记录网络使用的模式。另外，RMON2还显示单个应用所占用的带宽，以及出现疑难故障的关键因素。

RMON2监视OSI/RM第三至七层的通信，能对数据链路层以上的分组进行译码。这使得监视器可以管理包括IP等网络层协议。因而能了解分组的源和目标地址，能知道路由器负载的来源，使得监视的范围扩大到局域网外。监视器也能监视应用层协议，如电子邮件协议、文件传输协议、HTTP等，这样监视器就可以记录主机应用活动的数据，可以显示各种应用活动的图表。这些对网络管理人员都是很重要的信息。另外，在网络管理标准中通常把网络层上的协议都称为应用层协议，以后提到的应用层包含OSI的第五至七层。

RMON2扩充了原来的RMON MIB，增加了9个新的功能组，如下图所示。

RMON2 MIB

下面对这9个新功能组进行说明。

协议目录组（protocolDir）：提供了表示各种网络协议的标准化方法，使得管理站可以了解监视器所在的子网上运行什么协议。

协议分布组（protocolDist）：提供每个协议产生的通信统计数据。

地址映像组（addressMap）：建立网络层地址（IP地址）与MAC地址的映像关系。这些信息在发现网络设备、建立网络拓扑结构时有用。

网络层主机组（nlHost）：类似于RMON1的主机组，收集网上主机的信息。但是与RM0N1不同，这一组不是基于MAC地址，而是基于网络层地址发现主机。这样管理人员可以超越路由器看到子网之外的IP主机。

网络层矩阵组（nlMatrix）：记录主机对（源／目标）之间的通信情况，收集的信息类似于RM0N1的矩阵组，但是按网络层地址标识主机。

应用层主机组（alHost）：对应每个主机的每个应用协议（指第三层之上的协议）在alHost表中有一个表项，记录有关主机发送／接收的分组／字节数等。这一组使用户可以了解每个主机上的每个应用协议的通信情况。

应用层矩阵组（alMatrix）：统计一对应用层协议之间的各种通信情况，以及某种选定的参数（如交换的分组数／字节数）最大的（TopN）一对应用层协议之间的通信情况。

用户历史组（usrHistory）：按照用户定义的参数，周期性地收集统计数据。这使得用户可以研究系统中的任何计数器。

监视器配置组（probeConfig）：定义了监视器的标准参数集合，这样可以提高管理站和监视器之间的互操作性，使得管理站可以远程配置不同制造商的监视器。

RMON

简单网络管理协议SNMP是基于TCP/IP协议并在Internet中应用最广泛的网管协议，但是SNMP也有一些明显的不足，主要有以下4点。

◆由于SNMP使用轮询采集数据，而在大型网络中轮询会产生数量巨大的网络管理通信报文，导致网络交通拥挤甚至阻塞，故不适合管理大型网络。

◆不适合回收大信息量的数据，如一个完整的路由表。

◆基于SNMP的标准仅提供一般的验证，不能提供可靠的安全保证。

◆不支持Manager-to-Manager的分布式管理，它将收集数据的负担加在网管站上，使其成为瓶颈。

为了提高传送管理信息的可用性，减少管理站的负担，满足网络管理员监控网段性能的需求，IETF开发了RMON以解决SNMP在日益扩大的分布式互联中的局限性。

远程网络监视（RMON）首先实现了对异构环境进行一致的远程管理，它为通过端口远程监视网段提供了解决方案。RMON是IETF定义的MIB（RFC1757），是对SNMP标准的扩展，它定义了标准功能以及在基于SNMP管理站和远程监控者之间的接口，主要实现对一个网段乃至整个网络的通信流量的监视功能，目前已成为网络管理标准之一。它可以对数据网进行防范管理，使SNMP更有效、更积极主动地监测远程设备，使网络管理员可以更快地跟踪网络、网段或设备出现的故障，然后采取防范措施，防止网络资源的失效。RMON MIB的实现可以记录网络事件，即使在网络管理站没有与监控设备主动进行连接（脱机）的情况下也如此。另外，RMON MIB也用于记录网络性能数据和故障历史，可以在任何时候访问故障历史数据以进行有效的故障诊断。使用这种方法减少了管理者同代理间的通信流量，使简单而有力地管理大型互联网络成为可能。

RMON监视器可用两种方法收集数据：一种方法是通过专用的RMON探测仪，网管站直接从探测仪上获取管理信息并控制网络资源，这种方法可以获取RMON MIB的全部信息；另一种方法是将RMON代理直接植入网络设备（路由器、交换机、Hub等），使其成为带RMON Probe功能的网络设施，网管站用SNMP的基本命令与其交换数据信息，收集网络管理信息，但这种方式受设备资源的限制，一般不能获取RMON MIB的所有数据，大多只收集4个组的信息。

RMON MIB对网段数据的采集和控制通过控制表和数据表来完成。RMON MIB按功能分成9个组。每个组都有自己的控制表和数据表（有些组两者合一，如统计组）。其中，控制表可以读写，数据表只能读，控制表用于描述数据表所存放数据的格式。配置的时候，由管理站设置数据收集的要求，存入控制表。开始工作后，RMON监视器根据控制表的配置，把收集到的数据存放到数据表中。

RMON MIB包含以下9组数据。

1）统计组

2）历史组

历史组（History）定期收集统计网络值的记录并为日后的处理把统计存储起来。它包含历史控制组和以太网历史组两个小组。其中历史控制组主要用来设置采样间隔时间等控制信息；以太网历史组为网络管理员提供有关网段流量、错误包、广播包、利用率以及碰撞次数等其他统计信息的历史数据。

3）警报组

警报组（Alarm）允许网络管理站为网络性能（可以是监视器本地MIB的任意整数类型的对象）定义一组报警阈值。如果阈值在相应的方向被越过，监视器就会产生警报并把警报发往网络管理站。警报组需要事件组的实现。

4）主机组

主机组（Host）包含对连接在一个子网上所有主机的各种类型交通流量的记数值。它能够发现网上的新主机，对每个主机的MAC地址保持一组统计数据，例如，主机发送或接收的数据包总数、广播包数、流量字节数和错误包数等。它有一个控制表和两个数据表，且这两个数据表的内容相同，只是组织排列顺序不同。

5）最高主机组

最高主机组（Host Top）包括排序后的主机统计，该报告基于主机表中的一些参数生成列表。它用于统计在一个子网上一些参数最高的一组主机，例如，它可以列出10个传输数据最多的主机，但依赖于主机组的实现。

6）矩阵组

矩阵组（Matrix）用于记录关于子网上两个主机之间流量的信息，该信息以矩阵形式存储。这种方法对于检索特定主机之间的流量信息十分有用，例如，用于找出哪些设备对服务器的使用最多。矩阵组由三个表组成：一个控制表和两个数据表。

7）过滤组

过滤组（Filter）允许监视器观测与过滤器相匹配的数据包。网络监视器可以捕获所有通过过滤器的数据包或简单地记下基于这些数据包的统计。

8）包捕获组

包捕获组（Capture）控制数据被发往网管站的方式，它可以在把报文发送到某个通道后记录数据报文。

9）事件组

事件组（Event）提供关于RMON代理所产生的所有事件的列表。当某个事件发生时可以记录日志和发送IRAP到网管站。

尽管RMON有很多优点，但也有其局限性。RMON的MAC层探测器不能确定由服务器进入本地网段的数据包的源点和终点，或者不能确定经过被监视网段的通信数据包的源点和终点。

1994年，RMON2工作组开始致力于提高现存的物理层和数据链路层之间的RMON规范，以实现在网络层和应用层提供历史和数据的统计服务。下图说明了OSI参考模型与RMON相关规范的对应关系。

RMON和RMON2所支持的协议层

在网络层，RMON2通过监视点对点通信来记录网络使用的模式。另外，RMON2还显示单个应用所占用的带宽，以及出现疑难故障的关键因素。

SNMP

1）SNMP概述

SNMP的前身是简单网关监控协议（SGMP），用来对通信线路进行管理。随后对其改进并加入了符合Internet定义的SMI和MIB体系结构，改进后的协议就是著名的SNMP。SNMP的目标是管理Internet上众多厂家生产的软硬件平台，因此SNMP受Internet标准网络管理框架的影响很大。SNMP的体系结构如下图所示。

SNMP的体系结构

SNMP的体系结构围绕以下4个概念和目标进行设计。

◆使管理代理的软件成本尽可能低。

◆最大限度地保持远程管理的功能，以便充分利用Internet上的网络资源。

◆体系结构必须有扩充的余地。

◆保持SNMP的独立性，不依赖于具体的计算机、网关和网络传输协议。

在SNMP的改进版本SNMPv2中，又加入了保证SNMP体系本身安全性的目标。

另外，SNMP中提供了以下4类管理操作。

◆get操作：用来提取特定的网络管理信息。

◆get-next操作：通过遍历操作来提供强大的管理信息的提取能力。

◆set操作：用来对管理信息进行控制（修改、设置）。

◆trap操作：用来报告重要的事件。

各种操作的执行如下图所示。

SNMP的4种操作

2）SNMP管理控制框架与实现

（1）SNMP管理控制框架。

SNMP定义了管理进程（Manager）和管理代理（Agent）之间的关系，这个关系被称为共同体（Community）。描述共同体的语义是非常复杂的，但其句法却很简单。位于网络管理工作站（运行管理进程）和各网络元素上，利用SNMP相互通信，并对网络进行管理的软件统称为SNMP应用实体。若干个应用实体和SNMP组合起来形成一个共同体，不同的共同体之间用名字来区分。共同体的名字必须符合Internet的层次结构命名规则，由非保留字符串组成。此外，一个SNMP应用实体可以加入多个共同体。

SNMP的应用实体对Internet管理信息库中的管理对象进行操作。一个SNMP应用实体可操作的管理对象子集称为SNMP MIB授权范围。SNMP应用实体对授权范围内管理对象的访问还有进一步的访问控制限制，比如只读、读／写等；SNMP体系结构中要求每个共同体都规定其授权范围及其对每个对象的访问方式。记录这些定义的文件被称为共同体定义文件。

SNMP的报文总是源自每个应用实体，报文中包括该应用实体所在的共同体的名字。这种报文在SNMP中称为有身份标识的报文，共同体名字是在管理进程和管理代理之间交换管理信息报文时使用的。管理信息报文中包括以下两部分内容。

◆共同体名：加上发送方的一些标识信息（附加信息），用以验证发送方确实是共同体中的成员。共同体实际上就是用来实现管理应用实体之间身份鉴别的机制。

◆数据：这是两个管理应用实体之间真正需要交换的信息。

第三版本前的SNMP只是实现了简单的身份鉴别，接收方仅凭共同体名来判定收发双方是否在同一个共同体中，而前面提到的附加信息尚未应用。接收方在验明发送报文的管理代理或管理进程的身份后要对其访问权限进行检查。访问权限检查涉及以下因素。

◆一个共同体内各成员可以对哪些对象进行读、写等管理操作，这些可读写对象称为该共同体的授权对象（在授权范围内）。

◆共同体成员对授权范围内每个对象定义了访问模式：只读或可读写。

◆规定授权范围内每个管理对象（类）可进行的操作（包括get、get-next、set和trap）。

◆管理信息库（MIB）限制对每个对象的访问方式（如MIB中可以规定哪些对象只能读而不能写等）。

管理代理通过上述预先定义的访问模式和权限，来决定共同体中其他成员要求的管理对象访问（操作）是否允许。共同体概念同样适用于转换代理（Proxy Agent），只不过转换代理中包含的对象主要是其他设备的内容。

（2）SNMP的实现方式。

为了提供遍历管理信息库的手段，SNMP在其MIB中采用了树状命名方法对每个管理对象的实例进行命名。每个对象实例的名字都由对象类名字加上一个后缀构成，对象类的名字是不会相互重复的，因而不同对象类的对象实例之间也很少有重名的危险。

在共同体的定义中一般要规定该共同体授权的管理对象的范围，相应地也就规定了哪些对象实例是该共同体的"管辖范围"。据此，共同体的定义可以想象为一个多叉树，以字典序提供了遍历所有管理对象实例的手段。有了这个手段，SNMP就可以使用get-next操作符，顺序地从一个对象找到下一个对象。get-next（object-instance）操作返回的结果是一个对象实例的标识符及其相关信息，该对象实例在上面的多叉树中紧排在指定标识符object-instance对象的后面。这种手段的优点在于：即使不知道管理对象实例的具体名字，管理系统也能逐个地找到它，并提取到它的有关信息。遍历所有管理对象的过程可以从第一个对象实例开始（这个实例一定要给出），然后逐次使用get-next，直到返回一个差错（表示不存在的管理对象实例）结束（完成遍历）。

由于信息是以表格形式（一种数据结构）存放的，在SNMP的管理概念中，把所有表格都视为子树，其中一张表格（及其名字）是相应子树的根节点，每个列是根下面的子节点，一列中的每个行则是该列节点下面的子节点，并且是子树的叶节点，如下图所示。

管理信息库中的对象标识

因此，按照前面的子树遍历思路，对表格的遍历是先访问第一列的所有元素，再访问第二列的所有元素……直到最后一个元素。若试图得到最后一个元素的"下一个"元素，则返回差错标记。

SNMP中的各种管理信息大多以表格形式存在，一个表格对应一个对象类，每个元素对应于该类的一个对象实例。那么，管理信息表对象中单个元素（对象实例）的操作可以用前面提到的get-next方法，也可以用get/set等操作。下面主要介绍表格内一行信息的整体操作。

◆增加一行：通过SNMP只用一次set操作就可在一个表格中增加一行。操作中的每个变量都对应于待增加行中的一个列元素，包括对象实例的标识符。

◆删除一行：删除一行也可以通过SNMP调用set操作，将该行中的任意一个元素（对象实例）设置成"非法"即可。

至于删除一行时，表中的一行元素是否真的在表中消失，则与每个设备（管理代理）的具体实现有关，因此管理进程必须能通过各数据字段的内容来判断数据的合法性。

3）SNMP协议

SNMP是一个异步的请求／响应协议，即SNMP的请求和响应之间没有必定的时间顺序关系，换句话说，SNMP是一个面向无连接的协议。这样，SNMP实体不需要在发出请求后立即等待响应的到来，因此SNMP响应也可能丢失或出现错误。SNMP中设计了四种基本协议的交互过程。

第一种情况是管理进程从管理代理处提取管理信息。管理进程通过SNMP和传输网络发送get-request给管理代理，请求中包括管理对象的标识符等参数；管理代理收到请求后返回相应内容的get-response，响应中包括待提取的管理信息。

第二种情况是管理进程在管理代理的可见范围内遍历一部分管理对象实例。管理进程通过SNMP和传输网络发送get-next-request给管理代理，管理代理收到后完成遍历的一次操作，用get-response将遍历结果返回给管理进程。

第三种情况是管理进程在管理代理中存储信息，即对管理代理的管理信息库（MIB）进行写操作（包括设置工作参数）。管理进程发送一个set-request给管理代理，由管理代理完成set操作，然后用set-response返回操作结果。

第四种情况则是管理代理主动向管理进程报告事件。管理代理通过SNMP和传输网络将trap发送给管理进程，这个操作没有响应。

注意：上面的各个请求都是管理进程发给管理代理的，响应则都是由管理代理发给管理进程的。只有trap是无响应的，由管理代理单向发给管理进程。另外，请求、响应和trap的传输处理都要受"共同体"定义的限制，包括访问权限。

SNMP协议是一个对称协议，没有主从关系。SNMP上的管理进程和管理代理都可以得到SNMP完全相同的服务。下面对SNMP协议的部分特点和关键内容进行介绍。

（1）管理信息报文。

在大多数SNMP操作中都使用一个相同的报文数据结构。对于前面提到的身份鉴别方法，报文中包含三种数据（信息）传递给专门的"身份鉴别实体"：共同体名称、有关数据和发送方SNMP实体的传输层地址。

身份鉴别实体负责验证发送方是否是合法的对等实体，并返回两种可能的结果：一种结果是返回本次报文中的SNMP协议数据类型和发送方SNMP实体的权限标识符；另一种结果是返回例外。其中第一种结果表明发送方SNMP实体确实是本共同体的成员之一，接收方SNMP实体接下来对它进行处理。第二种结果（"例外"）表明发送方SNMP实体并非本共同体成员，不能接受此报文，并且接收方SNMP实体还可能根据配置产生一个"身份非法"的trap事件。

（2）协议数据单元及其管理操作。

SNMP协议实体之间的协议数据单元（PDU）只有两种不同的结构和格式，一个PDU格式在大部分操作中使用，而另一个则只在trap操作中作为trap的协议数据单元。

PDU一般包含多个代表特殊意义的字段：request-id是一个整数值，用来区分不同的PDU；error-status反映管理操作是成功还是失败；error-index表明操作中哪个变量错误；variable-bindings是一系列变量的清单，序列中每一项包含一个变量名及其变量值。

在SNMP中，接收方完成身份鉴别并得到共同体定义信息之后，SNMP实体根据PDU内容执行以下几种操作：get操作，根据变量名取出指定的对象实例；get-next操作，该操作与get操作不同，不是取变量名指定的对象实例，而是取出变量名指定的对象实例的按字典排序的下一个对象实例；set操作，对指定对象实体的值用请求中的新值替换；get-response对get/set报文做出响应并返回操作结果，收到该响应报文的操作请求方首先根据报文中的request-id在记录中查找有无这个序号的请求，如果没有则丢弃该响应，否则接收该响应，管理进程要进行响应处理。

（3）trap操作。

trap是一种捕捉事件并报告的操作，实际上几乎所有网络管理系统和管理协议都具有这种机制。trap在OSI网络管理国际标准中称为"事件和通报"，一般都简称为事件报告。

为了减少管理信息的业务流量，管理代理负责对管理对象的trap进行检查，管理检查可以设置检查条件，这样，管理进程就可以在一定程度上控制trap报告过程。引入trap报告的最大好处是许多重要事件的发生得以及时让管理进程知道。因为一般只有比较关键的trap事件才确实需要报告，再加上每个trap事件都很简短，因此由于trap而引入的不确定管理信息业务量是较少的，但却能大大改善网络管理的时效性。

由于事件多种多样，各种事件的发生环境也不一样，trap操作的复杂性比前面讲的几种操作都大，SNMP的trap操作PDU中的字段类型也较多。这些trap操作PDU中的字段包括：enterprise，记录发送trap事件的管理代理的标识符；agent-addr，管理代理的网络节点地址；generic-trap，描述该trap操作报告是哪一种异常事件；specific-trap，给出各管理代理自行定义的trap事件代码；time-stam，表示trap事件发生的时刻；variable-bindings，给出一组变量，这些变量及其值给出了与trap事件有关的详细信息。

当管理代理检测到一个例外或异常事件发生时，管理代理首先要判断需要将该事件报告给哪个或哪些管理进程。对每个管理进程，管理代理要选择相应的共同体号，由SNMP协议实体按照前面的字段格式构造trap报告的PDU，再将其发送出去。

（4）SNMP PDU的传输。

SNMP的设计是独立于具体的传输网络的，也就是说，它既可以在TCP/IP的支持下操作，也可以在OSI的传输层协议支持下完成操作，甚至可以在以太网的直接支持下实现操作。其中对OSI传输层的服务没有要求，既可以是有连接的服务，也可以是无连接的服务。为了实现上述目标，Internet组织定义了若干映射标准，规定了如何将SNMP协议数据单元PDU映射到下层的无连接传输请求上去。

在所有各种映射定义中，有一点是相同的，即所有SNMP报文数据是通过一个"顺序化"过程在网络上传输的，这个顺序化过程可以将任意结构的数据编码成一个有序的字符串进行传送。对方收到这些字符串后则按照完全相同的语法将它们解码成原来的数据结构。

（5）MIB中为SNMP定义的管理对象。

在Internet的第二版管理信息库（MIB-Ⅱ）中，为SNMP应用实体定义了若干管理对象，其中包括SNMP的各种服务原语、各种收发协议数据单元、各种参数指示或统计变量等，凡SNMP中可操作的数据结构或变量都包括在内，下面将详细介绍。

简单网络管理协议

SNMPv1

Internet最初的网络管理框架由4个文件定义，如下图所示，这就是SNMP第1版。RFC1155定义了管理信息结构（SMI），即规定了管理对象的语法和语义。SMI主要说明了怎样定义管理对象和怎样访问管理对象。RFC1212说明了定义MIB模块的方法，而RFC1213则定义了MIB-Ⅱ管理对象的核心集合，这些管理对象是任何SNMP系统必须实现的。RFC1157是SNMPv1的规范文件。

SNMP网络管理框架的定义

SNMP的通信基础是TCP/IP，它利用了传输层上的用户数据报协议（UDP）。SNMP的协议体系结构如下图所示。

SNMP的通信基础

其中的一些协议解释如下。

.BGP（Border Gateway Protocol）：边界网关协议。

.FTP（File Transfer Protocol）：文件传输协议。

.HTTP（HyperText Transfer Protocol）：超文本传输协议。

.SMTP（Simple Mail Transfer Protocol）：简单邮件传输协议。

.MIME（Multi-Purpose Internet Mail Extension）：多用途的网际邮件扩展。

.ICMP（Internet Control Message Protocol）：因特网控制报文协议。

SNMPv2

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

.对象的定义。

.表的定义。

.通知的定义。

.信息模块。

对象的定义

对象的定义是使用对象语法来描述的。在每一个MIB内部的对象都有一个正式的定义，它规定了对象的数据类型、允许的形式、取值范围以及与其他MIB内部对象之间的关系。使用ASN.1符号定义了每一个对象，而且也定义了整个MIB的结构。为了保持对象的简单性，只是使用了ASN.1元素和特性的一个有限子集。其中对象的数据类型通常是UNIVERSAL，但是在MIB-Ⅱ中只有下列数据类型可用于MIB对象的定义。

.integer（UNIVERSAL 2）。

.octetstring（UNIVERSAL 4）。

.null（UNIVERSAL 5）。

.object identifier（UNIVERSAL 6）。

.sequence、sequence-of（UNIVERSAL 16）。

其中，前面4种是基本类型，是组成其他对象类型的基本块。sequence和sequence-of用来构建表。

在MIB-2中，每个应用程序都定义了自己的APPLICATION数据类型。这里APPLICATION类型是ASN.1的APPLICATION类，它由与特定应用程序相关的数据类型组成。RFC1155中定义的一些应用程序范围类型如下。

.networkaddress：使用CHOICE结构来定义，允许从许多协议组中选择一种地址格式。

.ipaddress：由IP定义的32位地址。

.counter：只能增加不能减少的非负整数。

.gauge：可增可减的非负整数。

.timeticks：计算从某一个时刻开始时间的非负整数，以0.01s为单位进行计算。

.opaque：该类型能够产生任意类型数据。

与SNMPv1一样，SNMPv2也是用ASN.1宏定义OBJECT-TYPE表示管理对象的语法和语义，但是SNMPv2的OBJECT-TYPE增加了新的内容，如下图所示。

SNMPv2新添内容

对象宏定义说明如下。

.UnitsPart：在SNMPv2的OBJECT-TYPE宏定义中增加了UNITS子句。这个子句用文字说明与对象有关的度量单位。当管理对象表示一种度量手段（如时间）时，这个子句是有用的。

.MAX-ACCESS子句：类似于SNMPv1的ACCESS子句，说明最大的访问级别，与授权策略无关。SNMPv2定义的访问类型中去掉了write-only类，增加了一个与概念行有关的访问类型read-create，表示可读、可写、可生成。还增加了accessible-for-notify访问类，这种访问方式与陷入有关。

.STATUS子句：这个子句是必要的，也就是说必须指明对象的状态。新标准去掉了SNMPv1中的optional和mandatory，只有3个可选的状态。如果说明管理对象的状态是current，则表示在当前的标准中是有效的。如果管理对象的状态是obsolete，表示不必实现这种对象。状态deprecated表示对象已经过时了，但是为了与旧的实现互操作，实现时还要支持这种对象。

其他子句的意义和SNMPv1相同。

表的定义

由于SMI只支持简单的二维标量表这一种数据结构，因此，与SNMPv1一样，SNMPv2的管理操作只能作用于标量对象，复杂的信息要用表来表示。按照SNMPv2规范，表是行的序列，而行是列对象的序列。SNMPv2把表分为两类。

（1）禁止删除和生成行的表。这种表的最高访问级别是read-write。在很多情况下这种表由代理控制，表中只包含read-only型的对象。

（2）允许删除和生成行的表。这种表开始时可能没有行，由管理站生成和删除行。行数可由管理站或代理改变。

在SNMPv2表的定义中必须含有INDEX或AUGUMENTS子句，但是只能有一个。INDEX子句定义了一个基本概念行，而INDEX子句中的索引对象确定了一个概念行实例。与SNMPv1不同，SNMPv2的INDEX子句中增加了任选的IMPLIED修饰符。假定一个对象的标识符为y，索引对象为i₁,i₂,…，i_N,则对象y的一个实例标识符为y.（i₁）.（i₂）.…（i_N）。

SMI中表的定义不允许嵌套，也就是说，不允许表中的元素又是另外一个表，这限制了SMI的性能和灵活性。

表的操作

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

.active（可读写）：被管理设备可以使用概念行。

.notInService（可读写）：概念行存在，但由于其他原因（下面解释）而不能使用。

.notReady（只读）：概念行存在，但因没有信息而不能使用。

.createAndGo（只写不读）：管理站生成一个概念行实例时先设置成这种状态，生成过程结束时自动变为active，被管理设备就可以使用了。

.createAndWait（只写不读）：管理站生成一个概念行实例时先设置成这种状态，但不会自动变成active。

.destroy（只写不读）：管理站需删除所有的概念行实例时设置成这种状态。

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

表中概念行的生成可以使用两种不同的方法，分成4个步骤。

（1）选择实例标识符。针对不同的索引对象可考虑用不同的方法选择实例标识符。

（2）a管理站通过事务处理产生和激活概念行。b管理站与代理协商生成概念行。

（3）初始化非默认值对象。管理站用get命令查询所有列，以确定是否能够或需要设置列对象的值。

（4）激活概念行。

概念行的挂起：当概念行处于active状态时，如果管理站希望概念行脱离服务，以便进行修改，则可以发出set命令，把状态列由active置为notInService。

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

通知和信息模块

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

SNMPv2还引入了信息模块的概念，用于说明一组有关的定义。共有以下3种信息模块。

.MIB模块：包含一组有关的管理对象的定义。

.MIB的依从性声明模块：使用MODULE-COMPLIANCE和OBJECT-GROUP宏说明有关管理对象实现方面的最小要求。

.代理能力说明模块：用AGENT-CAPABILITIES宏说明代理实体应该实现的能力。

SNMPv3

在SNMPv3中，以前叫作管理站和代理的东西现在统一称为SNMP实体（SNMP Entity）。

实体是体系结构的一种实现，由一个或多个有关的SNMP引擎（SNMP Engine）和一个或者多个有关的SNMP应用（SNMP Application）组成。下图显示了SNMP实体的组成元素。

SNMP实体组成元素

SNMP引擎

SNMP引擎提供下列服务。

.发送和接收报文。

.认证和加密报文。

.控制对管理对象的访问。

SNMP引擎有唯一的标识snmpEngindID，这个标识在一个上层管理域中是无二义性的。

应用程序

SNMPv3的应用程序分为5种。

（1）命令生成器（Command Generators）：建立SNMP Read/Write请求，并且处理对这些请求的响应。

（2）命令响应器（Command Responders）：接收SNMP Read/Write请求，对管理数据进行访问，并按照协议规定的操作产生响应报文，返回读／写命令的发送者。

（3）通知发送器（Notification Originators）：监控系统中出现的特殊事件，产生通知类报文，并且要有一种机制，以决定向何处发送报文，使用何种SNMP版本和安全参数等。

（4）通知接收器（Notification Receivers）：监听通知报文，并产生响应。

（5）代理转发器（Proxy Repeaters）：在SNMP实体之间转发报文。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5