摘  要:  分析了网络中故障的传播原理，在此基础上提出了一种使用移动代理的三层网络故障管理体系，对网络故障管理中关联问题的难度进行了有效的分解。根据网络故障管理体系的要求设计了不同功能的移动代理，及该体系下它们的工作交互过程。该体系充分利用了现有网络条件，满足了现代网管对于故障管理的及时性、自学习性的要求，减轻了网络负载。此外，按照这种方法建立起来的网络故障管理系统具有一定的通用性和灵活性，能够适应不同的网络和网络的变化，最后通过实验证明了系统的部分优越性。 

    关键词: 网络故障； 移动代理； 代理协作

    随着计算机网络的迅速发展和广泛应用，对网络管理特别是网络故障管理的要求也越来越高，传统的集中式网络管理技术越来越难以适应网络管理功能的需要，充分利用现有网络的智能性进行分布式的网络管理成为现今研究的重点。本文将移动代理技术^[1]与网络故障管理结合起来，探讨解决网络故障管理的方法。 

    移动代理的主要特点是智能性和移动性。它是一个能够自主地在异构网络中迁移并协作的执行任务的程序实体^[2]。它能够自行决定在网络的各个节点之间移动，代表其他实体（人或其他代理）进行工作，它能够自行选择执行的时间和地点，并可以根据具体情况中断当前自身的执行，移动至另一设备恢复运行，并及时地将有关的结果返回。移动代理的移动性使得程序的执行能够尽可能地靠近数据源，降低了网络的通信开销，节省了带宽，平衡负载，加快任务的执行^[3]，从而提高分布式系统的处理效率。智能性使得移动代理能够充分利用现今越来越强的节点计算能力，并能将人工智能技术引入移动代理，以便更充分地完成管理任务^[4]。 

1 基于移动代理的网络故障管理模型 

1.1 网络故障的传播过程 

    当网络中发生故障时，故障会沿着横向和纵向两个方向传播。横向传播是指故障沿着物理的或是逻辑的连接在设备之间水平的传播，例如与发生故障的设备相连的设备感知到故障后也发生告警事件，这种故障甚至会在子网与子网之间传播。纵向传播主要是指故障在一个设备内部沿着协议栈从低层向高层传播，低层协议实体的不正常状态可能引起高层协议实体状态的不正常。 

    基于这种分析，将网络划分为4个层次的网络对象：全网、子网、网络元素NE(Network Element )和原子对象。将被管网络作为全网，而一个被管网络可能包括多个子网，子网的类型可以是总线网、令牌环或星形网等。每个子网由一个或多个NE组成，这些NE的类型可以是主机、路由器、集线器、交换机或一段物理链路等。而每一个NE也可以表示为由多个原子对象组成的集合，例如可以将一台路由器表示成由若干IP对象和若干接口对象组成的集合。网络故障检测的目标就是识别出作为网络故障根本原因的原子对象。 

    网络故障传播过程如图1所示。当某个原子对象发生故障时，例如某接口不可用，会使得包含该接口的网络设备无法进行某种数据的交换，进而影响周围网络元素的正常工作，使得整个子网出现异常，如果故障得不到解决，整个网络都可能受到影响。 

1.2 系统模型设计 

    基于以上分析，本文设计了一种集中式与分布式相结合的、分层的、基于智能代理和移动代理的网络故障管理模型，并按照故障传播顺序将这个模型分为三层，系统模型设计如图2所示。 

    (1) 网络元素端（NE端）。由于故障会在NE端进行纵向传播，所以移动代理在NE端先建立各层常用协议及协议间的依赖模型，根据网络故障及协议实体间依赖关系的不确定性的特点，选用适用于不确定性推理的贝叶斯网络推理模型。当出现故障时使用移动代理进行NE端的故障纵向关联，解决规则库中匹配的故障，并将不匹配的故障上报。 

    (2) 子网端。由于故障的横向传播，在进行告警关联时如果能够只考虑子网内部与其他子网连接点产生的告警，而不考虑其他子网产生的告警，就可以大大减少告警信息的冗余程度。在子网内部与其他子网的连接点上设置移动代理，对NE端移动代理发回的报告进行分析，将事件的关联在事件发出者所在的子网内部进行。告警事件产生时，首先判断其产生者所在的子网，然后只在其内部进行基于规则的事件关联。对于产生的故障在子网连接点的情况，即将事件在其所连接的所有子网内进行关联，并与各子网规则库中的规则进行匹配判断，如果判断成功，则表明故障发生在该子网。 

    (3) 全网端。有一些涉及到全网的告警事件则由各子网代理汇报到全网网络管理站。为了实现实时性和自学习性，网管站采用基于规则的推理与基于案例的推理相结合的方式进行故障告警的关联。网管中心将子网智能代理上报上来的告警事件进行基于规则的推理，当上报事件与规则不匹配时，则产生异常推断，并进入基于案例的推理。在基于案例的推理算法中有一个检索模块和一个修改模块。检索模块负责在规则/案例库中寻找与问题最为相似的案例，然后由修改模块对该实例作适当的修正。一旦修正结果将问题解决，则新的实例将加入到事例库中，以备以后的应用。 

2 故障管理模型的移动代理设计 

2.1 代理功能设计 

    依据一般的故障管理系统应该包含的基本功能设置代理： 

    (1)故障发现代理。故障发现代理主动地或被动地收集网络上的各种事件，并识别出其中与网络和故障相关的内容，确定是否存在故障。 

    (2)过滤关联代理。过滤关联代理将告警过滤与告警关联结合起来。过滤关联代理是用上文介绍的一些过滤关联技术将非主要的、非根本的告警滤除，保留主要的根本原因的告警。例如被派往NE端进行网络纵向关联的移动代理，需要将NE端的协议依赖体系带入到贝叶斯网络推理中进行故障关联，找出原子故障。过滤关联代理可以设置成基于RBR技术的代理，也可以设置成基于贝叶斯推理等技术的代理。 

    (3)故障分析代理。故障分析代理负责将过滤关联后的告警进行分析，判断子网归属，查找规则库匹配，并派出故障解决代理。当信息库中没有相关的告警时，生成如连通性测试代理之类的从代理找出故障的可能位置和原因，形成案例，然后激活故障告知代理更新案例库。 

    (4）故障告知代理。故障告知代理负责将告警关联分析的结果上报给管理者并更新信息库。 

    (5）故障解决代理。当故障原因确定后，派遣相应的故障解决代理解决故障。 

2.2 代理协作模型 

    图3给出了本文设计的多个代理之间协作进行故障关联的交互图。 

    如图3所示，故障发现代理一直在NE端进行故障采集工作。当发现异常后，激活过滤关联代理，进行预定义规则的过滤操作以后，视情况激活基于贝叶斯的关联从代理或基于规则的关联从代理；并将关联结果返回给过滤关联代理，经过过滤关联代理的简单处理后，将结果送到子网端的故障分析代理，子网端的代理在将关联结果进行子网判断后，查找规则库。若规则库中没有匹配的规则时，则激活网络连通性测试之类的从代理，找出故障可能发生的时间、地点等信息，形成案例。并将子网关联结果上报给网管端的故障分析代理，网管端的故障分析代理从全网的角度对上报故障进行分析，查找规则库中的匹配对象，若没有匹配规则，则将最后关联结果以日志的形式上报给网络管理员，并更新案例库。其中故障数据库是案例库和规则库的统称。 

3 实验 

    该实验以对网络扫描的告警为例，对系统的效果进行检测。 

    图4给出了实验使用的网络拓扑图，假设网络存在一个共享的瓶颈连接。一些用户在进行正常的网络业务，网络攻击者对结点C进行结点扫描，为了隐蔽自己，利用s台主机频繁向结点C发送ping命令进行扫描，在B结点派遣移动代理，实验中取Ftp、UDP业务主机数m为7，s为5。设定n=15为1min内观测到的echo request数据包引起告警的门限值，采样间隔为1min，每次持续1min，当采样到的数据包超过150时产生结点扫描告警。 

    图5是实验结果，位于B点的移动代理在第37次扫描时产生结点扫描告警。 

    本文设置代理将结点扫描告警发送到网络管理站，告警中包括被扫描的结点、echo request的发送地址列表等，网络管理站将收到的告警消息解码分析，然后禁止echo request发送地址列表中的地址发送ping消息。将没有应用移动代理系统和应用移动代理系统的A、B间的流量进行对比，如图6所示。非移动代理系统瓶颈链路上的网络流量随着网络扫描流量的增多而逐渐发生拥塞。 

    在结点扫描初期，大量结点扫描数据包占用了瓶颈带宽，当B点设置的移动代理向管理站A点发出告警后， 管理站将禁止告警消息中的echo request发送地址列表中的地址继续发送扫描数据包，代理与管理站之间采用ATP协议进行通信，将数据报头考虑进来，告警消息约在5 KB~6 KB,告警消息的传输引起了瓶颈连接流量的骤然增长，至告警消息传输完毕，结点扫描被禁止后，瓶颈连接处的流量降至了正常业务水平。由图6可以看到应用移动代理的系统整体对网络负载的压力较小。需要指出的是，当网络流量较大时，告警消息的传输带来的流量影响是很小的。因此对于大型异构多应用的网络故障管理，应用移动代理系统的优势是明显的。 

    基于移动代理的网络故障管理体系将移动代理技术引入到网络故障管理之中，它摒弃了传统网络故障管理体系中全网的故障都在网络管理中心进行管理的方式，利用代理的智能性和移动性，将故障管理放在更加靠近故障源的地方进行，减轻了网络负载。本文根据移动代理的特点，设计3层网管体系，并设计了各种代理以及代理之间的协同工作过程。在这种体系下，网管任务被细化，移动代理的特点得到了充分的体现。实验结果证明了系统的部分优越性。 

参考文献 

[1] 张云勇, 刘锦德. 移动Agent技术. 北京: 清华大学出版社, 2003. 

[2] DALMEIJER M, HAMMER D K. TMAERTS A. Mobile software agents. Computers in Industry,2000,(14):251-260. 

[3] SATOH I. Building reusable mobile agents for network management systems. Man and Cybernetics, 2003, 33(3): 350-357. 

[4] MILOJICIC D. Agent systems and applications.IEEE Concurrency, 2000,8(2):22-23.