|
|
|
网络管理协议是管理者和被管理者之间共同遵循的规则，他们之间可以通过网络管理协议完成管理信息的交换任务。常用的网络管理协议包括SNMP、MIB-Ⅱ和RMON等，它们都是基于TCP/IP协议工作的。
|
|
|
|
|
|
|
|
SNMP的前身是简单网关监控协议（SGMP），用来对通信线路进行管理。随后对其改进并加入了符合Internet定义的SMI和MIB体系结构，改进后的协议就是著名的SNMP。SNMP的目标是管理Internet上众多厂家生产的软硬件平台，因此SNMP受Internet标准网络管理框架的影响很大。SNMP的体系结构如下图所示。
|
|
|
|
|
|
|
|
SNMP的体系结构围绕以下4个概念和目标进行设计。
|
|
|
|
|
|
◆最大限度地保持远程管理的功能，以便充分利用Internet上的网络资源。
|
|
|
|
|
|
◆保持SNMP的独立性，不依赖于具体的计算机、网关和网络传输协议。
|
|
|
|
在SNMP的改进版本SNMPv2中，又加入了保证SNMP体系本身安全性的目标。
|
|
|
|
|
|
|
|
◆get-next操作：通过遍历操作来提供强大的管理信息的提取能力。
|
|
|
|
◆set操作：用来对管理信息进行控制（修改、设置）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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），只不过转换代理中包含的对象主要是其他设备的内容。
|
|
|
|
|
|
为了提供遍历管理信息库的手段，SNMP在其MIB中采用了树状命名方法对每个管理对象的实例进行命名。每个对象实例的名字都由对象类名字加上一个后缀构成，对象类的名字是不会相互重复的，因而不同对象类的对象实例之间也很少有重名的危险。
|
|
|
|
在共同体的定义中一般要规定该共同体授权的管理对象的范围，相应地也就规定了哪些对象实例是该共同体的"管辖范围"。据此，共同体的定义可以想象为一个多叉树，以字典序提供了遍历所有管理对象实例的手段。有了这个手段，SNMP就可以使用get-next操作符，顺序地从一个对象找到下一个对象。get-next（object-instance）操作返回的结果是一个对象实例的标识符及其相关信息，该对象实例在上面的多叉树中紧排在指定标识符object-instance对象的后面。这种手段的优点在于：即使不知道管理对象实例的具体名字，管理系统也能逐个地找到它，并提取到它的有关信息。遍历所有管理对象的过程可以从第一个对象实例开始（这个实例一定要给出），然后逐次使用get-next，直到返回一个差错（表示不存在的管理对象实例）结束（完成遍历）。
|
|
|
|
由于信息是以表格形式（一种数据结构）存放的，在SNMP的管理概念中，把所有表格都视为子树，其中一张表格（及其名字）是相应子树的根节点，每个列是根下面的子节点，一列中的每个行则是该列节点下面的子节点，并且是子树的叶节点，如下图所示。
|
|
|
|
|
|
|
|
因此，按照前面的子树遍历思路，对表格的遍历是先访问第一列的所有元素，再访问第二列的所有元素……直到最后一个元素。若试图得到最后一个元素的"下一个"元素，则返回差错标记。
|
|
|
|
SNMP中的各种管理信息大多以表格形式存在，一个表格对应一个对象类，每个元素对应于该类的一个对象实例。那么，管理信息表对象中单个元素（对象实例）的操作可以用前面提到的get-next方法，也可以用get/set等操作。下面主要介绍表格内一行信息的整体操作。
|
|
|
|
◆增加一行：通过SNMP只用一次set操作就可在一个表格中增加一行。操作中的每个变量都对应于待增加行中的一个列元素，包括对象实例的标识符。
|
|
|
|
◆删除一行：删除一行也可以通过SNMP调用set操作，将该行中的任意一个元素（对象实例）设置成"非法"即可。
|
|
|
|
至于删除一行时，表中的一行元素是否真的在表中消失，则与每个设备（管理代理）的具体实现有关，因此管理进程必须能通过各数据字段的内容来判断数据的合法性。
|
|
|
|
|
|
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协议的部分特点和关键内容进行介绍。
|
|
|
|
|
|
在大多数SNMP操作中都使用一个相同的报文数据结构。对于前面提到的身份鉴别方法，报文中包含三种数据（信息）传递给专门的"身份鉴别实体"：共同体名称、有关数据和发送方SNMP实体的传输层地址。
|
|
|
|
身份鉴别实体负责验证发送方是否是合法的对等实体，并返回两种可能的结果：一种结果是返回本次报文中的SNMP协议数据类型和发送方SNMP实体的权限标识符；另一种结果是返回例外。其中第一种结果表明发送方SNMP实体确实是本共同体的成员之一，接收方SNMP实体接下来对它进行处理。第二种结果（"例外"）表明发送方SNMP实体并非本共同体成员，不能接受此报文，并且接收方SNMP实体还可能根据配置产生一个"身份非法"的trap事件。
|
|
|
|
|
|
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在记录中查找有无这个序号的请求，如果没有则丢弃该响应，否则接收该响应，管理进程要进行响应处理。
|
|
|
|
|
|
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，再将其发送出去。
|
|
|
|
|
|
SNMP的设计是独立于具体的传输网络的，也就是说，它既可以在TCP/IP的支持下操作，也可以在OSI的传输层协议支持下完成操作，甚至可以在以太网的直接支持下实现操作。其中对OSI传输层的服务没有要求，既可以是有连接的服务，也可以是无连接的服务。为了实现上述目标，Internet组织定义了若干映射标准，规定了如何将SNMP协议数据单元PDU映射到下层的无连接传输请求上去。
|
|
|
|
在所有各种映射定义中，有一点是相同的，即所有SNMP报文数据是通过一个"顺序化"过程在网络上传输的，这个顺序化过程可以将任意结构的数据编码成一个有序的字符串进行传送。对方收到这些字符串后则按照完全相同的语法将它们解码成原来的数据结构。
|
|
|
|
|
|
在Internet的第二版管理信息库（MIB-Ⅱ）中，为SNMP应用实体定义了若干管理对象，其中包括SNMP的各种服务原语、各种收发协议数据单元、各种参数指示或统计变量等，凡SNMP中可操作的数据结构或变量都包括在内，下面将详细介绍。
|
|
|
|
|
|
在TCP/IP网络管理的建议标准中，提出了多个相互独立的MIB，其中包含为Internet的网络管理而开发的MIB-Ⅱ。鉴于它在说明标准MIB的结构、作用和定义方法等方面的重要性和代表性，有必要对其进行比较深入的讨论。
|
|
|
|
MIB-Ⅱ是在MIB-Ⅰ的基础上开发的，是MIB-Ⅰ的一个超集。MIB-Ⅱ组被分为以下分组。
|
|
|
|
|
|
|
|
◆at（address translation）：描述Internet到子网的地址映射。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
◆dot3（transmission）：有关每个系统接口的传输模式和访问协议的信息。
|
|
|
|
|
|
|
|
|
|
|
|
interfaces组包含实体物理接口的一般信息，包括配置信息和各接口中所发生的事件的统计信息。
|
|
|
|
|
|
address translation组由一个表构成，表中的每一行对应系统中的一个物理接口，提供网络地址向物理地址的映射。一般情况下，网络地址是指系统在该接口上的IP地址，而物理地址决定于实际采用的子网情况。例如，如果接口对应的是LAN，则物理地址是接口的MAC地址；如果对应X.25分组交换网，则物理地址可能是一个X.121地址。
|
|
|
|
实际上，address translation组包含在MIB-Ⅱ中只是为了与MIB-Ⅰ兼容，MIB-Ⅱ的地址转换信息在各个网络协议组中提供。
|
|
|
|
|
|
ip组包含有关节点上IP的实现和操作的信息，如有关IP层流量的一些计数器。ip组中包含3个表：ipAddrTable、ipRouteTable和ipNetToMediaTable。
|
|
|
|
ipAddrTable包含分配给该实体的IP地址的信息，每个地址被唯一地分配给一个物理地址。
|
|
|
|
ipRouteTable包含用于互联网路由选择的信息，该路由表中的信息是从一些协议的路由表中抽取而来的。实体当前所知的每条路由都有一个条目，表格由ipRouteDest索引。ipRouteTable中的信息可用于配置的监测，并且由于表中的对象是read-write的，因此也可被用于路由控制。
|
|
|
|
ipNetToMediaTable是一个提供IP地址和物理地址之间对应关系的地址转换表。除了增加一个指示映射类型的对象ipNetToMediaType之外，表中所包含的信息与address translation组相同。
|
|
|
|
此外，ip组中还包含一些用于性能和故障监测的标量对象。
|
|
|
|
|
|
ICMP（Internet Control Message Protocol）是TCP/IP协议族中的一部分，所有实现IP协议的系统都提供ICMP。ICMP提供从路由器或其他主机向主机传递消息的手段，它的基本作用是反馈通信环境中存在的问题。例如，数据报不能到达目的地，路由器没有缓冲区来转发数据报。
|
|
|
|
icmp组包含有关一个节点的ICMP的实现和操作的信息，具体地讲，icmp组为节点接收和发送的各种ICMP消息的计数器构成一个表。
|
|
|
|
|
|
tcp组包含有关一个节点的TCP的实现和操作的信息。
|
|
|
|
|
|
udp组包含有关一个节点的UDP的实现和操作的信息。除了有关发送和接收的数据报的信息之外，这个组中还包含一个udpTable表，该表中包含UDP端点的管理信息。所谓UDP端点是指正在支持本地应用接收数据报的UDP进程。udpTable表中包含每个UDP端点用户的IP地址和UDP端口。
|
|
|
|
|
|
egp组包含有关一个节点的EGP（Extemnal Gateway Protocol）的实现和操作的信息。除了有关发送和接收的EGP消息的信息外，这个组中还包含一个egpNeighTable表，该表中包含有关相邻网关的信息。
|
|
|
|
|
|
简单网络管理协议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监视器根据控制表的配置，把收集到的数据存放到数据表中。
|
|
|
|
|
|
|
|
统计组（Statistics）统计被监控的每个子网的基本统计信息。网络管理员可以从RMON探针监测的设备端口获取一个网段的各种统计信息。目前只能对网络设备的以太网接口进行监控和统计，将来会扩展到包括更多接口的特定表格（如FDDI）。它能统计一个网段的流量（如交通流量的总包数和总字节数），统计各种类型包的分布（如广播包、多点广播包、不同大小包的数量），还能统计各种类型错误包数、碰撞次数等。
|
|
|
|
|
|
历史组（History）定期收集统计网络值的记录并为日后的处理把统计存储起来。它包含历史控制组和以太网历史组两个小组。其中历史控制组主要用来设置采样间隔时间等控制信息；以太网历史组为网络管理员提供有关网段流量、错误包、广播包、利用率以及碰撞次数等其他统计信息的历史数据。
|
|
|
|
|
|
警报组（Alarm）允许网络管理站为网络性能（可以是监视器本地MIB的任意整数类型的对象）定义一组报警阈值。如果阈值在相应的方向被越过，监视器就会产生警报并把警报发往网络管理站。警报组需要事件组的实现。
|
|
|
|
|
|
主机组（Host）包含对连接在一个子网上所有主机的各种类型交通流量的记数值。它能够发现网上的新主机，对每个主机的MAC地址保持一组统计数据，例如，主机发送或接收的数据包总数、广播包数、流量字节数和错误包数等。它有一个控制表和两个数据表，且这两个数据表的内容相同，只是组织排列顺序不同。
|
|
|
|
|
|
最高主机组（Host Top）包括排序后的主机统计，该报告基于主机表中的一些参数生成列表。它用于统计在一个子网上一些参数最高的一组主机，例如，它可以列出10个传输数据最多的主机，但依赖于主机组的实现。
|
|
|
|
|
|
矩阵组（Matrix）用于记录关于子网上两个主机之间流量的信息，该信息以矩阵形式存储。这种方法对于检索特定主机之间的流量信息十分有用，例如，用于找出哪些设备对服务器的使用最多。矩阵组由三个表组成：一个控制表和两个数据表。
|
|
|
|
|
|
过滤组（Filter）允许监视器观测与过滤器相匹配的数据包。网络监视器可以捕获所有通过过滤器的数据包或简单地记下基于这些数据包的统计。
|
|
|
|
|
|
包捕获组（Capture）控制数据被发往网管站的方式，它可以在把报文发送到某个通道后记录数据报文。
|
|
|
|
|
|
事件组（Event）提供关于RMON代理所产生的所有事件的列表。当某个事件发生时可以记录日志和发送IRAP到网管站。
|
|
|
|
尽管RMON有很多优点，但也有其局限性。RMON的MAC层探测器不能确定由服务器进入本地网段的数据包的源点和终点，或者不能确定经过被监视网段的通信数据包的源点和终点。
|
|
|
|
1994年，RMON2工作组开始致力于提高现存的物理层和数据链路层之间的RMON规范，以实现在网络层和应用层提供历史和数据的统计服务。下图说明了OSI参考模型与RMON相关规范的对应关系。
|
|
|
|
|
|
|
|
在网络层，RMON2通过监视点对点通信来记录网络使用的模式。另外，RMON2还显示单个应用所占用的带宽，以及出现疑难故障的关键因素。
|
|
|
