CN106789177A - 一种网络故障处理的系统 - Google Patents

Abstract

本发明公开了一种网络故障处理的系统，属于网络技术领域。所述系统包括监测探针和网管设备，网管设备与监测探针、分组传送网中的网元设备连接，监测探针包括主动探针和被动探针，主动探针用于发送业务流检测分组传送网是否发生故障，被动探针用于镜像复制业务流检测分组传送网是否故障；监测探针在分组传送网发生故障时向网管设备发送告警信息，告警信息包括监测探针的标识和故障的类型；网管设备接收告警信息，根据告警信息确定故障的位置；在预设的策略库中查找故障的类型和故障的位置对应的处理方式，并按照找到的处理方式控制网元设备动作。本发明在网络故障时对网元设备进行一定的应急处理，避免故障继续影响分组传送网的运行。

Description

一种网络故障处理的系统

技术领域

本发明涉及网络技术领域，特别涉及一种网络故障处理的系统。

背景技术

分组传送网(英文：Packet Transport Network，简称：PTN)是传送技术和以太网承载技术相结合的产物，以分组作为传送单位，主要承载电信级以太网业务，兼容时分复用模式(英文：Telemetric Data Monitor，简称：TDM)、异步传输模式(英文：AsynchronousTransfer Mode，简称ATM)等业务的综合传送技术。

为了保障分组传送网的稳定运行，通常对网络进行监测。监测的方式分成主动监测和被动监测两种。主动监测是采用主动向网络发起少量业务流，模拟真实业务的方式，评估网络的业务传输性能。被动监测是镜像复制所有实际业务流，采用被动分析实际业务流的方式，对网络的传输能力和业务质量进行评价。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

对网络进行主动监测或者被动监测，只能在故障发生时进行告警，通知工作人员进行处理，放任故障继续影响网络运行。

发明内容

为了解决现有技术的问题，本发明实施例提供了一种网络故障处理的系统。所述技术方案如下：

本发明实施例提供了一种网络故障处理的系统，所述系统包括监测探针和网管设备，所述网管设备与所述监测探针、分组传送网中的网元设备连接，所述监测探针包括部署在所述分组传送网中每个网元设备上的主动探针和部署在所述分组传送网中至少一个网元设备上的被动探针，所述主动探针用于发送业务流检测所述分组传送网是否发生故障，所述被动探针用于镜像复制业务流检测所述分组传送网是否故障；

所述监测探针，用于在所述分组传送网发生故障时向所述网管设备发送告警信息，所述告警信息包括所述监测探针的标识和故障的类型；

所述网管设备，用于接收所述告警信息，根据所述告警信息确定故障的位置；在预设的策略库中查找所述故障的类型和所述故障的位置对应的处理方式，并按照找到的所述处理方式控制所述网元设备动作。

在本发明一种可能的实现方式中，所述分组传送网中的网元设备包括第一网元设备和第二网元设备，所述第一网元设备和所述第二网元设备为两个不同的网元设备；所述第一网元设备上的主动探针用于，

向所述第二网元设备发送业务流；

当第一网元设备上的主动探针没有接收到所述第二网元设备回复的业务流时，向所述网管设备发送所述告警信息；

当所述第一网元设备上的主动探针接收到所述第二网元设备回复的业务流时，检测所述第二网元设备回复的业务流是否符合设定的关键绩效指标；

当所述第二网元设备回复的业务流不符合所述关键绩效指标时，向所述网管设备发送所述告警信息。

可选地，所述分组传送网中的网元设备包括第一网元设备和第二网元设备，所述第一网元设备和所述第二网元设备为两个不同的网元设备；所述第一网元设备上的主动探针用于，

向所述第二网元设备发送业务流；

当第一网元设备上的主动探针没有接收到所述第二网元设备回复的业务流时，向所述网管设备发送所述告警信息；

当所述第一网元设备上的主动探针接收到所述第二网元设备回复的业务流时，检测所述第二网元设备回复的业务流是否符合设定的关键绩效指标；

当所述第二网元设备回复的业务流不符合所述关键绩效指标时，向所述网管设备发送所述告警信息。

可选地，所述网管设备用于，

获取所述第二网元设备上的主动探针的检测结果，所述检测结果包括是否接收到所述第一网元设备上的主动探针发送的业务流；

当接收到所述第一网元设备上的主动探针发送的业务流时，确定所述第二网元设备故障；

当没有接收到所述第一网元设备上的主动探针发送的业务流时，确定所述第一网元设备和所述第二网元设备之间的连接链路故障。

优选地，所述网管设备用于，

根据所述故障的位置调整所述网元设备的传输路径，并输出故障消息，所述故障消息用于通知用户所述故障的类型和所述故障的位置。

可选地，所述第一网元设备上的主动探针用于，

当所述第一网元设备发送的业务流的传输速率不超过设定阈值时，占用所述第一网元设备的带宽，通过虚拟专用网络向所述第二网元设备发送业务流。

在本发明另一种可能的实现方式中，所述分组传送网中的网元设备包括第一网元设备，所述第一网元设备上的被动探针用于，

检测所述第一网元设备接收的业务流是否符合设定的关键绩效指标；

当所述第一网元设备接收的业务流不符合所述关键绩效指标时，向所述网管设备发送所述告警信息，并镜像复制所述第一网元设备接收的业务流。

可选地，所述第一网元设备上的被动探针用于，

当所述第一网元设备发送的业务流的传输速率超过设定阈值时，向所述网管设备发送所述告警信息，镜像复制并向所述网管设备发送所述第一网元设备发送的业务流，所述告警信息中所述故障的类型为广播风暴。

优选地，所述网管设备用于，

获取所述第一网元设备上的被动探针镜像复制的所述第一网元设备发送的业务流；

确定所述第一网元设备发送的业务流中的源IP地址是否相同；

当所述源IP地址相同时，确定所述广播风暴来自于所述分组传送网外；

当所述源IP地址不同时，确定所述源IP地址是否属于同一个接入网；

当所述源IP地址不属于同一个接入网时，确定所述广播风暴来自于所述分组传送网内形成环路的网元设备；

当所述源IP地址属于同一个接入网时，确定所述第一网元设备接收的业务流的传输速率是否超过所述设定阈值；

当所述第一网元设备接收的业务流的传输速率超过所述设定阈值时，确定所述广播风暴来自接入网；

当所述第一网元设备接收的业务流的传输速率不超过所述设定阈值时，确定所述广播风暴来自接入网的边缘。

更优选地，所述网管设备用于，

当所述广播风暴来自于所述分组传送网外时，关闭所述分组传送网中对应所述源IP地址的端口；

当所述广播风暴来自于所述分组传送网内形成环路的网元设备时，关闭所述分组传送网内形成环路的网元设备发送业务流的端口；

当所述广播风暴来自接入网时，关闭所述接入网的接入端口；

当所述广播风暴来自接入网的边缘时，关闭所述接入网的边缘的接入端口。

本发明实施例提供的技术方案带来的有益效果是：

通过监测探针在分组传送网发生故障时发送包括监测探针的标识和故障的类型的告警信息，网管设备接收告警信息并根据告警信息确定故障的位置，在预设的策略库中查找故障的类型和故障的位置对应的处理方式，并按照找到的处理方式控制网元设备动作，在网络故障时可以对网元设备进行一定的应急处理，避免故障继续影响分组传送网的运行。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种网络故障处理的系统的应用场景图；

图2是本发明实施例一提供的一种网络故障处理的系统的结构示意图；

图3是本发明实施例一提供的系统处理网络故障的流程图；

图4是本发明实施例二提供的系统处理网络故障的流程图；

图5是本发明实施例二提供的主动探针的分布图；

图6是本发明实施例三提供的系统处理网络故障的流程图；

图7是本发明实施例四提供的系统处理网络故障的流程图；

图8是本发明实施例四提供的被动探针的分布图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

下面先结合图1简单介绍一下本发明实施例提供的网络故障处理的系统的应用场景。参见图1，分组传送网10包括核心网11和接入网12，核心网11和接入网12均由若干网元设备组成，核心网11中的所有网元设备形成网状拓扑结构，接入网12中的多个网元设备与核心网11中的至少一个网元设备形成环型结构。各个网元设备分别与网管设备连接。

例如，如图1所示，分组传送网10包括网元设备R1～R10，网元设备R3、R4、R8、R9组成核心网11，网元设备R1、R2、R10组成一个接入网12，网元设备R5、R6、R7组成另一个接入网12。网元设备R1～R10分别与网管设备20连接。

在实际应用中，网管设备用于实现网元设备的管理，核心网用于实现各个接入网之间的数据传输，接入网用于实现客户端和服务器的接入。例如，参见图1，服务器21通过一个接入网12中的网元设备R2接入分组传送网10，客户端22通过另一个接入网12中的网元设备R5接入分组传送网10，服务器21的数据可以通过网元设备R2、核心网11中的网元设备R3和网元设备R4、以及网元设备R5传输到客户端22，客户端22的数据也可以按照相反的路径传输到服务器21。

具体地，服务器可以为实现各种业务的服务器，如超文本传输协议(英文：Hypertext Transfer Protocol，简称：HTTP)服务器。客户端22可以为手机、平板电脑、笔记本电脑、台式电脑等终端。网元设备可以为路由器、交换机、网关等路由交换设备。

需要说明的是，图1所示的应用场景仅为举例，本发明并不限制于此。

实施例一

本发明实施例提供了一种网络故障处理的系统，参见图2，该系统包括监测探针41和网管设备42，网管设备42与监测探针41、分组传送网中的网元设备连接，监测探针41包括部署在分组传送网中每个网元设备上的主动探针和部署在分组传送网中至少一个网元设备上的被动探针，主动探针用于发送业务流检测分组传送网是否发生故障，被动探针用于镜像复制业务流检测分组传送网是否故障，告警信息包括监测探针的标识和故障的类型；

监测探针41，用于在分组传送网发生故障时向网管设备发送告警信息；

网管设备42，用于接收告警信息，根据告警信息确定故障的位置；在预设的策略库中查找故障的类型和故障的位置对应的处理方式，并按照找到的处理方式控制网元设备动作。

相应地，参见图3，该系统实现如下步骤处理网络故障：

步骤101：监测探针在分组传送网发生故障时向网管设备发送告警信息。

在本实施例中，告警信息包括监测探针的标识和故障的类型。

本发明采用主动探针和被动探针相结合的监测方式，充分利用主动探针和被动探针各自的特点进行互补，其与现有单独采用主动探针监测和被动探针监测进行对比的具体情况可以参见下表一：

表一

从表一可以看出，在单独采用主动探针的方式中，主动探针是对自身发送的业务进行处理分析，通过构造较大的测试样本使结果接近真实网络状况，能够对当前网络状况进行预测，及时发现网络中存在的问题，但是无法记录和存储用户业务数据，分析和定位问题的能力不足，不能实现故障记录和后续的详细分析。在单独采用被动探针的方式中，如果全网都部署被动探针，虽然能够对每个用户行为均作出分析并准确定位故障，但是整体部署成本过高、实施方案复杂、维护难度大。在采用主动探针和被动探针相结合的方式中，主动探针实现网络指标的监测和上报，被动探针实现业务数据的记录和重放，网管设备实现主动探针和被动探针的配置管理、告警和性能数据的收集整理和统一呈现、网络运行状态的评估和优化建议。

其中，主动探针的被动探针的监测功能划分情况可以参见下表二：

表二

在具体实现中，主动探针和被动探针对网络进行7*24小时不间断的业务性能实时监测，利用设置的网元设备和网管设备之间的传输通道，将网络状态(如是否出现故障)传输给网管设备，从而在网管设备上构建实时、精确、直观的图形化信息监测平台，为网络的告警管理、性能管理和趋势分析等功能提供数据支撑。监测设备可以支持提供多种业务的网络运行趋势预测图或报表，预测可能的网络瓶颈，为流量负载均衡、链路带宽设置、路由选择和网络优化等提供数据支持，最终实现分组传送网的自动巡检、网络资源分析和故障定位，提升分组传送网的自动运行和维护的能力。

具体地，监测设备可以具备独立的虚拟专用网络(英文：Virtual PrivateNetwork，简称VPN)，所有监测设备将收集到的告警信息上报给网管设备进行统一管理，网管设备可以控制监测设备的配置和生成，如为维护人员提供web界面进行统一管理，形成分布式结构，有利于后续网络的扩展和统一管理。

步骤102：网管设备接收告警信息，根据告警信息确定故障的位置。

步骤103：网管设备在预设的策略库中查找故障的类型和故障的位置对应的处理方式，并按照找到的处理方式控制网元设备动作。

需要说明的是，在网管设备中预先就配置好各种故障的处理方式，当监测到故障发生时，查找并执行能对应的处理方式即可。

本发明实施例通过监测探针在分组传送网发生故障时发送包括监测探针的标识和故障的类型的告警信息，网管设备接收告警信息并根据告警信息确定故障的位置，在预设的策略库中查找故障的类型和故障的位置对应的处理方式，并按照找到的处理方式控制网元设备动作，在网络故障时可以对网元设备进行一定的应急处理，避免故障继续影响分组传送网的运行。

实施例二

本发明实施例提供了另一种网络故障处理的系统，适用于实施例一适用的所有情况中主动探针监测到分组传送网业务传输失败的情况，在本实施例中，分组传送网中的网元设备包括第一网元设备和第二网元设备，第一网元设备和第二网元设备为不同的网元设备，参见图4，该系统实现如下步骤处理网络故障：

步骤201：第一网元设备上的主动探针向第二网元设备发送业务流。

在实际应用中，主动探针能够完全模拟分组传送网中多种协议类型的常见业务，如HTTP业务、文件传输协议(英文：File Transfer Protocol，简称：FTP)业务、因特网包探索器(英文：Packet Internet Groper，简称：PING)业务、电子邮件(英文：ElectronicMail，简称：Email)业务、网际组管理协议(Internet Group Management Protocol，简称：IGMP)业务、组播业务、网络电话(英文：Voice over Internet Protocol，简称：VoIP)业务、用户数据报协议(英文：User Datagram Protocol，简称UDP)业务等，同时支持模拟各种业务的行为，如HTTP业务的get/response流程、FTP业务的passive模式、Email业务的信令面和媒体面等，作为客户端与真实业务的服务器进行通信，或者作为服务器与真实业务的客户端进行通信。例如，模拟用户拨打电话、浏览网页等，可以验证网络的可达性和传输特性。

另外，为了客观评估业务的运行状态，通常为每项业务指定有可量化的关键绩效指标(英文：Key Performance Indicator，简称KPI)并配置阈值，当监测结果超过阈值时产生告警信息，精确表征业务的运行状态和用户的客观体验，为主动监测业务测试结果提供评估依据。

可选地，该步骤201可以包括：

当第一网元设备发送的业务流的传输速率不超过设定阈值时，第一网元设备上的主动探针占用第一网元设备的带宽，通过虚拟专用网络(英文：Virtual Private Network，简称VPN)向第二网元设备发送业务流。

在实际应用中，第一网元设备上的主动探针只发送少量业务流(如平均流量的1％)进行监测，速率范围通常设置为0～100M/s，并且优先级低于用户业务的优先级，确保不会对用户业务的承载、传输和交换产生影响。

优选地，第一网元设备上的主动探针每隔设定的时间段发送业务流，以进行周期性的模拟测试确保网络处于正常运行状态，主要是模拟客户端或者服务器与目标设备进行业务通信，判断目标设备是否正常进行业务，当目标设备不能进行业务时，进一步判断是网络连接的原因还是目标设备自身原因导致的，具体可参见图5部分的说明。

更优选地，第一网元设备可以选择用户数量较多的网元设备、经常出现问题的网元设备。

需要说明的是，为了模拟客户端或者服务器与目标设备进行业务通信，会预先在主动探针上安装带有目标设备功能的软件，配置好地址、端口、页面等参数，保证能够模拟目标设备的运行。

步骤202：当第一网元设备上的主动探针没有接收到第二网元设备回复的业务流时，第一网元设备上的主动探针向网管设备发送故障信息。

在本实施例中，该告警信息包括第一网元设备的标识和业务流传输失败的消息。

步骤203：网管设备接收告警信息，并根据告警信息获取第二网元设备上的主动探针的检测结果。

在本实施例中，检测结果包括是否接收到第一网元设备上的主动探针发送的业务流。当接收到第一网元设备上的主动探针发送的业务流时，执行步骤204；当没有接收到第一网元设备上的主动探针发送的业务流时，执行步骤205。

步骤204：网管设备确定第二网元设备故障。

步骤205：网管设备确定第一网元设备和第二网元设备之间的连接链路故障。

如图5所示，网元设备R1～R10上均设置有主动探针31，主动探针31利用网元设备与网管设备20之间的连接，在监测到网络出现故障时通知网管设备20。

以图5为例，网元设备R5上的主动探针31模拟客户端，依次通过网元设备R4、网元设备R3、网元设备R2，向HTTP服务器21发送HTTP请求，若HTTP服务器21接收到HTTP请求，则会回复网元设备R5上的主动探针31。如果网元设备R5上的主动探针31没有接收到HTTP服务器21回复的业务流，则网元设备R5上的主动探针31向网管设备20发送故障信息。

网管设备20接收到故障信息之后，根据故障信息确定HTTP服务器21上的主动探针是否接收到网元设备R5上的主动探针31发送的业务流。如果接收到网元设备R5上的主动探针31发送的业务流，则说明网元设备R5和HTTP服务器21之间的连接链路没有问题，是HTTP服务器21存在问题；如果没有接收到网元设备R5上的主动探针31发送的业务流，则说明网元设备R5和HTTP服务器21之间的连接链路存在问题。

进一步地，网元设备R5和HTTP服务器21之间依次通过网元设备R4、网元设备R3、网元设备R2连接，如果网元设备R5和HTTP服务器21之间的连接链路存在问题，则可以依次根据网元设备R4、网元设备R3、网元设备R2上的主动探针是否接收到网元设备R5上的主动探针31发送的业务流，从而确定出具体出现故障的网元设备。

需要说明的是，服务器上的主动探针可以为通过trace route等方式确定的服务器的出口网元地址对应的主动探针。保证该探针上的HTTP服务正常进行，配置HTTP客户端(网元设备R5上的主动探针)访问服务器上的主动探针进行测试，测试过程中的数据经历与HTTP服务器相同。如果服务器上的主动探针提供的HTTP服务正常，则说明网络正常，HTTP服务器存在问题；如果服务器上的主动探针提供的HTTP服务不正常，则说明网络异常，可以进一步通过trace route判断具体出现故障的网元设备。

步骤206：网管设备根据故障的位置调整网元设备的传输路径，并输出故障消息。该步骤206在步骤204或步骤205之后执行。

在本实施例中，故障消息用于通知用户故障的类型和故障的位置。

还是以图5为例，如果网元设备R3故障，则网元设备R5与HTTP服务器21之间的传输路径，从依次通过网元设备R4、网元设备R3、网元设备R2，改为依次通过网元设备R4、网元设备R8、网元设备R9、网元设备R10、网元设备R1、网元设备R2。

需要说明的是，步骤201-步骤202用于实现监测探针在分组传送网发生故障时发送告警信息，步骤203-步骤205用于实现网管设备接收告警信息，根据告警信息确定故障的位置，步骤206用于实现网管设备在预设的策略库中查找故障的类型和故障的位置对应的处理方式，并按照找到的处理方式控制网元设备动作。

本发明实施例通过主动探针监测到分组传送网业务传输失败的情况并告知网管设备，网管设备接收到告警信息确定故障的位置，并调整网元设备的传输路径，避免继续采用有问题的传输路径传输数据。

实施例三

本发明实施例提供了又一种网络故障处理的系统，适用于实施例一适用的所有情况中主动探针监测到业务达不到关键绩效指标(英文：Key Performance Indicator，简称KPI)的情况，在本实施例中，分组传送网中的网元设备包括第一网元设备和第二网元设备，第一网元设备和第二网元设备为不同的网元设备，参见图6，该系统实现如下步骤处理网络故障：

步骤301：第一网元设备上的主动探针向第二网元设备发送业务流。

具体地，该步骤301可以与实施例二中的步骤201相同，在此不再详述。

步骤302：当第一网元设备上的主动探针接收到第二网元设备回复的业务流时，第一网元设备上的主动探针检测第二网元设备回复的业务流是否符合设定的KPI。

步骤303：当第二网元设备回复的业务流不符合KPI时，第一网元设备上的主动探针向网管设备发送故障信息。

在本实施例中，该告警信息包括第一网元设备的标识和不符合的KPI。

步骤304：网管设备接收告警信息，并根据告警信息获取第二网元设备上的主动探针的检测结果。

在本实施例中，检测结果包括第一网元设备发送的业务流是否符合KPI。当述第一网元设备发送的业务流符合KPI时，执行步骤305；当第一网元设备发送的业务流不符合KPI时，执行步骤306。

步骤305：网管设备确定第二网元设备故障。

具体地，该步骤305可以与实施例二中的步骤204相同，在此不再详述。

步骤306：网管设备确定第一网元设备和第二网元设备之间的连接链路故障。

具体地，该步骤306可以与实施例二中的步骤205相同，在此不再详述。

步骤307：网管设备根据故障的位置调整网元设备的传输路径，并输出故障消息。该步骤307在步骤305或步骤306之后执行。

在本实施例中，故障消息用于通知用户故障的类型和故障的位置。

具体地，该步骤307可以与实施例二中的步骤206相同，在此不再详述。

需要说明的是，步骤301-步骤303用于实现监测探针在分组传送网发生故障时发送告警信息，步骤304-步骤306用于实现网管设备接收告警信息，根据告警信息确定故障的位置，步骤307用于实现网管设备在预设的策略库中查找故障的类型和故障的位置对应的处理方式，并按照找到的处理方式控制网元设备动作。

本发明实施例通过主动探针监测到业务达不到关键绩效指标的情况并告知网管设备，网管设备接收到告警信息确定故障的位置，并调整网元设备的传输路径，避免继续采用有问题的传输路径传输数据。

实施例四

本发明实施例提供了另一种网络故障处理的系统，适用于实施例一适用的所有情况中被动探针监测到分组传送网存在广播风暴的情况，在本实施例中，分组传送网中的网元设备包括第一网元设备，参见图7，该系统实现如下步骤处理网络故障：

步骤401：第一网元设备上的被动探针检测第一网元设备接收的业务流是否符合设定的KPI。

由于被动探针的部署成本远高于主动探针，因此在具体实现中，通常被动探针没有部署在分组传送网中每个网元设备中，而是选择部分网元设备部署被动探针，如核心网中的网元设备、接入用户多的网元设备、经常故障的网元设备。

以图8为例，网元设备在网元设备R1、R3、R4、R8、R9、R10上部署被动探针32，并且网元设备R1、R3、R4、R8、R9、R10设有独立于用户业务传输的数据线(如光纤，考虑到发送和接收两个传输方向，通常为四芯光缆)，该数据线可以分开设置，也可以汇聚在一起，如图8中网元设备R3、R4、R8的数据线都汇聚到网元设备R9再连接到网管设备20(如采用航空连接器连接)，网元设备R1、R10的数据线直接单独连接到网管设备20，从而将所有被动探针镜像复制的数据传输给网管设备20。

步骤402：当第一网元设备接收的业务流不符合KPI时，第一网元设备上的被动探针向网管设备发送告警信息，并镜像复制第一网元设备接收的业务流。

在本实施例中，当第一网元设备接收的业务流不符合KPI时才镜像复制第一网元设备接收的业务流，只将网络中的异常流量进行记录，可以有效节省硬件空间，延长被动探针的工作时间。通过将故障发生时的所有数据抓取并存储，使得维护人员可以根据需要选择性重放异常流量，进行故障的定位分析，深入查找和分析故障原因。

在实际应用中，被动探针实施监测网络中的所有流量，当流量出现异常时，被动探针开始采集数据，采用镜像的方式将网络中的用户业务流量复制到被动探针中进行分析；当流量恢复正常时，被动探针停止采集数据。所有被动探针采集的数据可以集中存储在同一个硬盘中，该硬盘设置在网管设备上或与网管设备连接(如通过舰船用以太网电缆连接)，网管设备可以随时对被动探针采集的数据进行分析或者重放。

在本实施例中，该步骤402具体包括：

当第一网元设备发送的业务流的传输速率超过设定阈值时，第一网元设备上的被动探针向网管设备发送告警信息，镜像复制并向网管设备发送第一网元设备发送的业务流，告警信息中故障的类型为广播风暴。

需要说明的是，分组传送网的各接入网按照IP地址进行划分，因此可以设置监测端口的流量阈值，利用IP地址定位广播风暴的源头。广播风暴一般可以分为分组传送网外引入、分组传送网内成环、接入网内成环和网络边缘形成，成环通常是由于人为误操作，将网元设备之间额外对接造成的。具有如下特性：

1、发送数据包的数量超过阈值，产生告警信息；

2、接收数据包的数量没超过阈值，无告警信息产生；

3、发送的数据包中源IP地址不同。

步骤403：网管设备接收告警信息，并获取第一网元设备上的被动探针镜像复制的第一网元设备接收的业务流。

步骤404：网管设备确定第一网元设备接收的业务流中的源IP地址是否相同。当源IP地址相同时，执行步骤405；当源IP地址不同时，执行步骤406。

步骤405：网管设备确定广播风暴来自于分组传送网外，并关闭分组传送网中对应源IP地址的端口。

可选地，该步骤405可以包括：

确定分组传送网外引入广播风暴；

查找源IP地址对应的物理端口；

告警提示源IP地址对应的物理端口导致广播风暴产生；

确定是否开启故障隔离功能；

当开启故障隔离功能时，强制关闭源IP地址对应的物理端口。

步骤406：网管设备确定源IP地址是否属于同一个接入网。当源IP地址不属于同一个接入网时，执行步骤407：当源IP地址属于同一个接入网时，执行步骤408。

步骤407：网管设备确定广播风暴来自于分组传送网内形成环路的网元设备，并关闭分组传送网内形成环路的网元设备发送业务流的端口。

可选地，该步骤407可以包括：

确定分组传送网内形成环路导致广播风暴；

监测网元设备发送的业务流是否超过设定阈值；

记录并告警提示发送的业务流超过设定阈值发送的网元设备；

确定是否开启故障隔离功能；

当开启故障隔离功能时，强制关闭发送的业务流超过设定阈值发送的网元设备的发送端口。

步骤408：网管设备确定第一网元设备发送的业务流的传输速率是否超过设定阈值。当第一网元设备发送的业务流的传输速率超过设定阈值时，执行步骤409；当第一网元设备发送的业务流的传输速率不超过设定阈值时，执行步骤410。

步骤409：网管设备确定广播风暴来自接入网，并关闭接入网的接入端口。

可选地，该步骤409可以包括：

确认接入网导致的广播风暴；

查找接入网对应的接入端口；

告警提示接入网导致广播风暴产生；

确定是否开启故障隔离功能；

当开启故障隔离功能时，强制关闭接入网对应的接入端口。

步骤410：网管设备确定广播风暴来自接入网的边缘，并关闭接入网的边缘的接入端口。

可选地，该步骤410可以包括：

确认网络边缘导致的广播风暴；

查找网络边缘对应的接入端口；

告警提示网络边缘导致广播风暴产生；

确定是否开启故障隔离功能；

当开启故障隔离功能时，强制关闭网络边缘对应的接入端口。

在具体实现中，在执行步骤405、步骤407、步骤409或者步骤410之后，会再次执行步骤401。

本发明实施例通过被动探针监测到分组传送网存在广播风暴的情况并告知网管设备，网管设备接收到告警信息广播风暴的来源，并关闭分组传送网中相应的端口，避免风暴继续造成网络瘫痪。

需要说明的是：上述实施例提供的网络故障处理的系统在处理网络故障时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种网络故障处理的系统，其特征在于，所述系统包括监测探针和网管设备，所述网管设备与所述监测探针、分组传送网中的网元设备连接，所述监测探针包括部署在所述分组传送网中每个网元设备上的主动探针和部署在所述分组传送网中至少一个网元设备上的被动探针，所述主动探针用于发送业务流检测所述分组传送网是否发生故障，所述被动探针用于镜像复制业务流检测所述分组传送网是否故障；

所述监测探针，用于在所述分组传送网发生故障时向所述网管设备发送告警信息，所述告警信息包括所述监测探针的标识和故障的类型；

所述网管设备，用于接收所述告警信息，根据所述告警信息确定故障的位置；在预设的策略库中查找所述故障的类型和所述故障的位置对应的处理方式，并按照找到的所述处理方式控制所述网元设备动作。

2.根据权利要求1所述的系统，其特征在于，所述分组传送网中的网元设备包括第一网元设备和第二网元设备，所述第一网元设备和所述第二网元设备为两个不同的网元设备；所述第一网元设备上的主动探针用于，

向所述第二网元设备发送业务流；

当所述第一网元设备上的主动探针没有接收到所述第二网元设备回复的业务流时，向所述网管设备发送所述告警信息；

当所述第一网元设备上的主动探针接收到所述第二网元设备回复的业务流时，检测所述第二网元设备回复的业务流是否符合设定的关键绩效指标；

当所述第二网元设备回复的业务流不符合所述关键绩效指标时，向所述网管设备发送所述告警信息。

3.根据权利要求2所述的系统，其特征在于，所述网管设备用于，

获取所述第二网元设备上的主动探针的检测结果，所述检测结果包括是否接收到所述第一网元设备上的主动探针发送的业务流；

当接收到所述第一网元设备上的主动探针发送的业务流时，确定所述第二网元设备故障；

当没有接收到所述第一网元设备上的主动探针发送的业务流时，确定所述第一网元设备和所述第二网元设备之间的连接链路故障。

4.根据权利要求2所述的系统，其特征在于，所述网管设备用于，

获取所述第二网元设备上的主动探针的检测结果，所述检测结果包括所述第一网元设备发送的业务流是否符合所述关键绩效指标；

当所述第一网元设备发送的业务流符合所述关键绩效指标时，确定所述第二网元设备故障；

当所述第一网元设备发送的业务流不符合所述关键绩效指标时，确定所述第一网元设备和所述第二网元设备之间的连接链路故障。

5.根据权利要求3或4所述的系统，其特征在于，所述网管设备用于，

根据所述故障的位置调整所述网元设备的传输路径，并输出故障消息，所述故障消息用于通知用户所述故障的类型和所述故障的位置。

6.根据权利要求2～4任一项所述的系统，其特征在于，所述第一网元设备上的主动探针用于，

当所述第一网元设备发送的业务流的传输速率不超过设定阈值时，占用所述第一网元设备的带宽，通过虚拟专用网络向所述第二网元设备发送业务流。

7.根据权利要求1所述的系统，其特征在于，所述分组传送网中的网元设备包括第一网元设备，所述第一网元设备上的被动探针用于，

检测所述第一网元设备接收的业务流是否符合设定的关键绩效指标；

当所述第一网元设备接收的业务流不符合所述关键绩效指标时，向所述网管设备发送所述告警信息，并镜像复制所述第一网元设备接收的业务流。

8.根据权利要求7所述的系统，其特征在于，所述第一网元设备上的被动探针用于，

当所述第一网元设备发送的业务流的传输速率超过设定阈值时，向所述网管设备发送所述告警信息，镜像复制并向所述网管设备发送所述第一网元设备发送的业务流，所述告警信息中所述故障的类型为广播风暴。

9.根据权利要求8所述的系统，其特征在于，所述网管设备用于，

获取所述第一网元设备上的被动探针镜像复制的所述第一网元设备发送的业务流；

确定所述第一网元设备发送的业务流中的源IP地址是否相同；

当所述源IP地址相同时，确定所述广播风暴来自于所述分组传送网外；

当所述源IP地址不同时，确定所述源IP地址是否属于同一个接入网；

当所述源IP地址不属于同一个接入网时，确定所述广播风暴来自于所述分组传送网内形成环路的网元设备；

当所述源IP地址属于同一个接入网时，确定所述第一网元设备接收的业务流的传输速率是否超过所述设定阈值；

当所述第一网元设备接收的业务流的传输速率超过所述设定阈值时，确定所述广播风暴来自接入网；

当所述第一网元设备接收的业务流的传输速率不超过所述设定阈值时，确定所述广播风暴来自接入网的边缘。

10.根据权利要求9所述的系统，其特征在于，所述网管设备用于，

当所述广播风暴来自于所述分组传送网外时，关闭所述分组传送网中对应所述源IP地址的端口；

当所述广播风暴来自于所述分组传送网内形成环路的网元设备时，关闭所述分组传送网内形成环路的网元设备发送业务流的端口；

当所述广播风暴来自接入网时，关闭所述接入网的接入端口；

当所述广播风暴来自接入网的边缘时，关闭所述接入网的边缘的接入端口。