CN1113505C - 具有分布网管代理的网管方法 - Google Patents

Abstract

本发明涉及一种计算机网络管理领域中具有分布网管代理的网管方法。包括：在主网管代理上建立用于描述运行子网管代理的网络设备状态的私有MIB，当网管站需要对运行子网管代理的网络设备进行查询或设置时，首先向主网管代理发出请求，查询运行子网管代理的网络设备的状态，然后根据查询结果决定是否向运行子网管代理的网络设备发出请求并执行，子网管代理在接到来自网管站的请求时，做相应操作并向网管站发回响应报文。

Description

具有分布网管代理的网管方法

技术领域

本发明涉及一种计算机网络管理领域中的网络管理方法，更确切地说是涉及一种具有子网管代理的网管方法。

背景技术

监视网络性能、检测并恢复网络故障以及配置网络设备等是网络管理的主要任务。具体地说，在网络正常工作的情况下，网络管理需实施统计、配置和测试等功能；而在网络出现故障的情况下，网络管理又需实施各种差错的检测和恢复功能，以便将损失减少到最小范围。而随着计算机网络规模的迅速扩大，对网络的管理也变得异常重要了。

目前，SNMP协议(Simple Network Management Protocol)是Internet网络管理的标准协议，按照该协议，主要需由两部分结构的相互配合实现网络管理，包括网管站部分(NMS-Network Management Station)和运行在被管网络设备上的网管代理(SNMP Agent)软件部分，网管站向被管网络设备发出请求，由运行在被管网络设备上的网管代理分析来自网管站的请求，并对被管网络设备进行相应操作。

子网管代理(subagent)方案是对普通网管代理(SNMP Agent)的扩展，通过子网管代理(subagent)方案，可动态地对一些网络设备实现管理，从而使网络管理变得更加灵活和富有弹性。所谓动态地对网络设备进行管理，主要是指网络设备对管理对象的抽象-管理信息库(MIB)是可以动态改变的。

在Integrated Systems，Inc.的实时操作系统PSOS网管用户手册(SNMPUser’Guide)中已详细描述了通用的子网管代理方法，该子网管代理方法包括两个部分，即运行在多个被管网络设备上的多个子网管代理(subagent)和运行在一个被管设备上的主网管代理(master agent)。一个子网管代理(subagent)的抽象-管理信息库(MIB)可以被动态地注册到主网管代理(master agent)的抽象-管理信息库(MIB)树上。

图1中示出采用子网管代理方法的网管工作流程。步骤a：网管站(NMS)11向主网管代理12(master agent)发出对抽象-管理信息库(MIB)的请求；步骤b：由主网管代理12(master agent)将网管站(NMS)11对抽象-管理信息库(MIB)的请求发给子网管代理(subagent)13(或14)；步骤c：子网管代理(subagent)13(或14)根据请求进行相应操作并构造响应报文，发回主网管代理12(master agent)；步骤d：最后由主网管代理12(master agent)将所收到的各子网管代理的响应报文汇合成对应于请求报文的响应报文发给提出请求的网管站(NMS)11。上述步骤实现了网管站11对运行子网管代理的网络设备的管理。

这种子网管代理方案适用于对一些状态经常改变的网络设备的网络管理，如IP地址改变或经常中断与网络连接的网络设备，而且这种改变住住是由运行主网管代理的网络设备所决定的，或者为其所知的。由于对这些设备难以采用传统的网管代理(SNMP Agent)方法实现网管，因此用上述子网管代理的方法将会收到很好的效果。

但上述子网管代理方法也有其不足之处：

1.由于网管站对运行子网管代理的网络设备的管理都必须通过运行主网管代理的网络设备来完成，因此，当通过一个主网管代理来实现网络管理的子网管代理较多时，运行主网管代理的网络设备就必须拿出大量开销来支持网管站对运行子网管代理的网络设备的管理，运行主网管代理的网络设备就成了“瓶颈”，这不仅会影响网管站对这些设备进行管理的效率，而且会影响运行主网管代理的网络设备的其它功能的实现，及影响运行主网管代理的网络设备与运行子网管代理的网络设备之间的其它通讯；

2.开发难度及程序规模大，首先主网管代理需要判断来自网管站的报文是对运行主网管代理的本网络设备的请求还是对运行子网管代理的网络设备的请求，如果是对本网络设备的请求，则按普通网管代理(SNMP Agent)的方式处理，进行相应操作后发回响应报文；如果是对运行子网管代理的网络设备的请求，则需要先将报文转发给相应的运行子网管代理的网络设备，并随时侦听其响应报文是否返回，在接收到响应报文后再将响应报文发回网管站。实现上述一系列的复杂关系，所需编写的程序将远远超过实现普通网管代理软件的代码量，对于本来就处于“瓶颈”位置的运行主网管代理的网络设备将无疑是雪上加霜。其次，子网管代理完成的功能虽然与普通网管代理完成的功能基本相似，但也必须判断请求报文中的变量约束(Varbinds)是否是关于本网络设备的，如果是关于本网络设备的，则按照普通网管代理的方式处理，否则，就不能做任何改变，这也需通过编写程序进行妥当处理，所做的各判断分支也会增加代码量。

发明内容

本发明的目的是设计一种具有分布网管代理的网管方法，以弥补子网管代理方法的不足，且针对某一类设备来说是非常高效的。本发明所涉及的该类设备是：运行子网管代理的网络设备状态变化频繁，若采用普通网管代理方法将难以实现对它们的网络管理；运行主网管代理的网络设备能够维护运行子网管代理的网络设备的状态信息，即网络设备间的关系可由设备内部实现。

在计算机及电信领域中普遍存在有该类设备，如经常进行单板热插拔的电信设备，及接口很多且各自IP地址可以随时重设的路由器等。

本发明的目的是这样实现的：一种具有分布网管代理的网管方法，其特征在于包括：

a.在主网管代理上建立用于描述运行子网管代理的网络设备状态的私有管理信息库；

b.在运行主网管代理的网络设备与运行子网管代理的网络设备内部之间，实现由运行主网管代理的网络设备维护运行子网管代理的网络设备的状态信息；

c.在网管站对运行子网管代理的网络设备进行查询或设置时，先向主网管代理发出查询运行子网管代理的网络设备状态信息的请求；

d.网管站根据查询结果决定是否向运行子网管代理的网络设备发出请求并执行；

e.子网管代理在接到来自网管站的请求后，作相应操作，并向网管站发回响应报文。

所述的运行主网管代理的网络设备上还建立有与描述运行子网管代理的网络设备状态的私有管理信息库相关联的、并用于向网管站报告网络设备重要状态改变事件的私有管理信息库，在运行子网管代理的网络设备发生指定状态的改变时，由主网管代理主动向网管站发送陷阱(Trap)报文，报告该状态改变的发生。

所述的在网络设备之间的内部实现的由运行主网管代理的网络设备维护运行子网管代理的网络设备的状态，其中的网络设备是一个组合在一起且相互之间存在内在关系的单一或多个产品，运行子网管代理的网络设备的状态变化是由主网管代理决定的，或向主网管代理报告的。

所述的主网管代理或子网管代理，是按普通网管代理的功能执行的，接收来自网管站的请求后，对所在的被管网络设备进行相应操作，再根据操作结果，构造响应报文并发回网管站。

所述的网管站运行执行网络管理的普通SNMP客户(Client)网管软件。

所述c、d中的请求过程和逻辑，是由网络管理人员通过通用的SNMP客户(Client)网管软件实现的。

所述的网管站针对运行主网管代理和子网管代理的网络设备，运行执行网络管理的专用SNMP客户(Client)网管软件，包括先向主网管代理发出查询运行子网管代理的网络设备状态信息的请求，再根据主网管代理的响应结果决定是否向运行子网管代理的网络设备发出请求的过程和逻辑。

本发明方法的有益效果是：

1.解决了主网管代理的“瓶颈”问题，网管站只是最初从主网管代理查询关于运行子网管代理的网络设备的状态，以后就会直接向子网管代理发出查询，而不必再通过主网管代理；

2.无论是主网管代理还是子网管代理，其功能都与普通的网管代理完全相同，即接收请求报文、根据请求进行操作和发回响应报文，因此主网管代理和子网管代理的开发与普通网管代理完全相同，比较简单且往往有标准模式。

附图说明

图1是子网管代理方法的网管工作流程：

图2是本发明具有分布网管代理方法的网管工作流程。

具体实施方式

下面结合实施例及附图进一步说明本发明的技术

图1说明前已述及，不再赘述。

参见图2，图中示出将本发明具有分布网管代理的方法应用于接入服务器中的网管工作流程。

该接入服务器，为了提供灵活的大容量接入而采用了模块化、分布处理的方式，一台接入服务器最多可有192个基本接入模块，一个接入模块包括一块路由协议处理单元板RPU和四块数字调制解调器(Modem)处理单元板DMU，这样一台接入服务器最多可包括192块RPU板和768块DMU板。每一块RPU板都有一个网络接口，并且有自己的IP地址，因而可看作是一个网络设备，并且可作为所在模块中四块DMU板的外部代理来实现网管站对DMU板的网络管理。其中的RPU板具有状态多变的特点，如可以热插拔或从终端重新设置IP地址等，若采用传统的网管代理(SNMP Agent)方法，是很难实现对RPU板的网络管理的。

如果采用通用的子网管代理方法，使终端具有主网管代理功能、RPU板具有子网管代理功能，则对上百块RPU板和近千块DMU板的网络管理都要由运行在终端上的主网管代理来实现，此时的终端就成了“瓶颈”，严重影响了网络管理的效率和终端本身功能的实现。

采用本发明的方法进行管理，在终端22的网管代理软件上建立描述RPU板和DMU板状态的私有管理信息库(MIB)对象，并且从内部实现对各个RPU板和DMU板的状态维护，则只需要网管站21首先通过步骤a查询保存在终端22中的关于各RPU板23状态的信息，然后根据步骤b的查询结果再通过步骤c直接向RPU板23发出请求，被查询的RPU板在接到来自网管站21的请求后，作相应操作，并通过步骤d向网管站21发回响应报文。图中所示的步骤e及f表示终端设备22与RPU板23间的内部通信。本发明的方法也可以是：在运行主网管代理的终端设备22上建立与描述运行子网管代理的RPU板或DMU板状态的私有管理信息库相关联的并用于向网管站21报告网络设备重要状态改变事件的私有管理信息库，当运行子网管代理的RPU板或DMU板发生某些重要的状态改变时，可由主网管代理主动向网管站21发送陷阱(Trap)报文，报告上述状态改变的发生。

本发明的具有分布网管代理的网管方法，无论是主网管代理还是子网管代理，均仅实现普通网管代理的功能，即接收来身网管站的请求，对其所在的被管网络设备进行相应的操作，再根据操作结构，构造响应报文并发回网管站。

在本发明的方法中，网管站上运行的可以是通用的SNMP Client(SNMP客户)网管软件，较常见的SNMP Client网管软件有IBM的NetView，HP的OpenView和SUN的NetManager，它们都支持标准SNMP协议。此时在网管站对运行子网管代理的网络设备进行查询或设置时，先向主网管代理发出查询运行子网管代理的网络设备状态信息的请求，然后根据主网管代理的响应结果决定是否向运行子网管代理的网络设备发出请求的过程和逻辑的实现，由网络管理人员通过通用SNMP Client(SNMP客户)网管软件实现。

在本发明的方法中，网管站上所运行的也可以是针对运行主网管代理和子网管代理的网络设备专门开发的SNMP Client(SNMP客户)网管软件，专门开发的SNMP Client(SNMP客户)网管软件可以自动实现先向主网管代理发出查询运行子网管代理的网络设备的状态信息请求，然后根据主网管代理的响应结果决定是否向运行子网管代理的网络设备发出请求的过程和逻辑。

应用上述方法后，大大减轻了终端22的负担，且开发难度大为减小。

Claims (7)

1.一种具有分布网管代理的网管方法，其特征在于包括：

a.在主网管代理上建立用于描述运行子网管代理的网络设备状态的私有管理信息库；

b.在运行主网管代理的网络设备与运行子网管代理的网络设备内部之间，实现由运行主网管代理的网络设备维护运行子网管代理的网络设备的状态信息；

c.在网管站对运行子网管代理的网络设备进行查询或设置时，先向主网管代理发出查询运行子网管代理的网络设备状态信息的请求；

d.网管站根据查询结果决定是否向运行子网管代理的网络设备发出请求并执行；

e.子网管代理在接到来自网管站的请求后，作相应操作，并向网管站发回响应报文。

2.根据权利要求1所述的具有分布网管代理的网管方法，其特征在于：所述的运行主网管代理的网络设备上还建立有与描述运行子网管代理的网络设备状态的私有管理信息库相关联的、并用于向网管站报告网络设备重要状态改变事件的私有管理信息库，在运行子网管代理的网络设备发生指定状态的改变时，由主网管代理主动向网管站发送陷阱报文，报告该状态改变的发生。

3.根据权利要求1或2所述的具有分布网管代理的网管方法，其特征在于：所述的在网络设备之间的内部实现的由运行主网管代理的网络设备维护运行子网管代理的网络设备的状态，其中的网络设备是一个组合在一起且相互之间存在内在关系的单一或多个产品，运行子网管代理的网络设备的状态变化是由主网管代理决定的，或向主网管代理报告的。

4.根据权利要求1所述的具有分布网管代理的网管方法，其特征在于：所述的主网管代理或子网管代理，是按普通网管代理的功能执行的，接收来自网管站的请求后，对所在的被管网络设备进行相应操作，再根据操作结果，构造响应报文并发回网管站。

5.根据权利要求1或2所述的具有分布网管代理的网管方法，其特征在于：所述的网管站运行执行网络管理的普通SNMP客户网管软件。

6.根据权利要求1所述的具有分布网管代理的网管方法，其特征在于：所述c、d中的请求过程和逻辑，是由网络管理人员通过通用的SNMP客户网管软件实现的。

7.根据权利要求1所述的具有分布网管代理的网管方法，其特征在于：所述的网管站针对运行主网管代理和子网管代理的网络设备，运行执行网络管理的专用SNMP客户网管软件，包括先向主网管代理发出查询运行子网管代理的网络设备状态信息的请求，再根据主网管代理的响应结果决定是否向运行子网管代理的网络设备发出请求的过程和逻辑。

Images