CN101662388B

CN101662388B - 一种网络故障分析方法及设备

Info

Publication number: CN101662388B
Application number: CN200910180840XA
Authority: CN
Inventors: 丁文涛
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: New H3C Technologies Co Ltd
Priority date: 2009-10-19
Filing date: 2009-10-19
Publication date: 2012-02-08
Anticipated expiration: 2029-10-19
Also published as: CN101662388A

Abstract

本发明公开了一种网络故障分析方法和设备，根据实体MIB物理表建立系统中的设备实体模型，并据此分析网络故障。通过应用本发明的技术方案，能够基于设备的实体结构，识别出真正的故障实体，排除由于故障实体问题所引起的源实体包含的子实体和逻辑实体故障。

Description

一种网络故障分析方法及设备

技术领域

本发明涉及通信技术领域，特别涉及一种网络故障分析方法及设备。

背景技术

随着社会科技的发展，网络越来越成为企业不可或缺的核心组成部分，而随着业务的拓展，企业网络的规模也经历了爆炸性的增长。

网络的应用已经不仅仅是简单的互连互通，通信、计算、应用和技术的融合，更多的扮演业务平台的角色，而网络运行的安全、稳定、高效直接决定企业核心业务能否顺利开展。对于用户来说，随着IT技术的发展，信息化系统的建设日益复杂，用户对网络管理和运营提出了更高的要求，除了保障设备的互通、兼容外，IT系统的安全问题等都是用户必须要面对的。

因此，如今网络操作员和系统操作员面临的严峻挑战是如何处理大量与网络、系统和应用程序问题相关的信息。

信息有多种格式，关键是管理解决方案要准确理解哪些信息是需要发送给操作员的重要信息，哪些信息可以丢弃，哪些信息是在诊断非常复杂的问题时所必需的依据。

为此，就需要网络管理软件能够对大量的网络事件进行分析，尽量提供更加有意义的网络事件，以便能够使管理人员从繁重的工作中解脱出来。

然而，现有的网络管理平台会接收到大量网络故障告警，这些故障告警之间存在着诸多的因果关系，尤其是设备元器件的故障，必然会连带造成其所附属的逻辑实体上产生大量的告警。根据收集到的多个用户的实际数据来看，这些告警的总数占到其全年告警总数的很大部分。

因此，如果不对这些告警加以区分，并进行相应的分析处理，无法就这些告警为用户提供任何有益的帮助。

发明内容

本发明提供一种网络故障分析方法和设备，识别网络故障所对应的设备实体。

本发明提供了一种网络故障分析方法，应用于包括多个网络设备和一个网络管理设备的系统中，所述多个网络设备之间的关系结构通过实体MIB物理表进行表示，所述方法包括以下步骤：

所述网络管理设备根据所述实体MIB物理表建立所述系统相对应的设备实体模型；

所述网络管理设备将接收到的网络故障的告警信息与所述设备实体模型中相应的网络设备建立联系；

所述网络管理设备根据所述设备实体模型和所述故障联系，分析所述网络故障的告警信息所对应的故障原因。

所述网络管理设备根据所述实体MIB物理表建立所述系统相对应的设备实体模型，具体通过以下方式进行设定：

所述网络管理设备在进行自动发现或添加设备时，读取所述实体MIB物理表中的设备关系信息；

所述网络管理设备将所述实体MIB物理表中当前最高级别的设备信息所对应的物理实体作为设备实体模型的根节点；

所述网络管理设备根据所述实体MIB物理表中的其他的设备关系信息，按照所述根节点建立所述设备实体模型。

当建立或更新所述设备实体模型之后，还包括：

所述网络管理设备根据预设的设备实体模型约束策略，查找所述设备实体模型中是否有违反所述约束策略的节点；

如果有，则将违反所述约束策略的节点及其以下节点从所述设备实体模型中删除；

其中，如果是根节点违反所述约束策略，则所述网络管理设备确定所述设备实体模型无效。

所述网络管理设备将接收到的网络故障的告警信息与所述设备实体模型中相应的网络设备建立联系，具体包括：

当所述网络管理设备接收到故障告警信息时，所述网络管理设备查询所述告警信息中是否包含预设的标识信息；

如果包含与各级别设备相对应的标识信息，则所述网络管理设备将所述网络故障的告警信息与相应的设备建立联系；

如果包含与更新设备相对应的标识信息，则所述网络管理设备重新读取实体MIB物理表，更新所述设备实体模型。

所述网络管理设备根据所述设备实体模型和所述故障联系，分析所述网络故障的告警信息所对应的故障原因，具体包括：

如果所述网络管理设备判断一个网络设备存在对应的故障告警信息，则查找所述网络设备的上级设备是否包含故障告警信息；

如果所述网络设备的直接上级设备包含故障告警信息，则以所述直接上级设备的故障告警信息为临时根源，并以该上级设备为基础，进一步向上查找各级上级设备，以确定故障告警信息的根源；

如果所述网络设备的直接上级设备不包含故障告警信息，则查找其超级上级设备是否包含故障告警信息，如果包含，则查找tbl_trap_catalog_main数据表，如果所述网络设备与其超级上级设备的故障告警信息的类别相同，则以所述超级上级设备的故障告警信息为根源；

如果所述网络设备的直接上级设备和超级上级设备都不包含故障告警信息，或所述网络设备与其超级上级设备的故障告警信息的类别不相同，则以所述网络设备的故障告警信息为根源；

进一步的，如果所述网络管理设备判断所述网络设备包含多个故障告警信息，则查找tbl_trap_catalog_main数据表，如果所述多个故障告警信息的类别相同，则以最早收到的故障告警信息为根源。

所述网络管理设备根据所述设备实体模型，分析所述网络故障的告警信息所对应的故障原因之前，还包括：

所述网络管理设备对所述设备实体模型中的网络设备进行标识；

当所述网络管理设备判断所述设备实体模型中的设备中包含告警信息未分析的标识时，分析所述网络设备是否存在故障；

所述网络管理设备根据所述分析结果，确定所述网路故障的原因。

另一方面，本发明还提出了一种网络管理设备，应用于包括多个网络设备和一个网络管理设备的系统中，所述多个网络设备之间的关系结构通过实体MIB物理表进行表示，包括：

模型建立模块，用于根据所述实体MIB物理表建立所述系统相对应的设备实体模型；

联系模块，与所述模型建立模块相连接，用于将接收到的网络故障的告警信息与所述设备实体模型中相应的网络设备建立联系；

分析模块，与所述联系模块相连接，用于根据所述联系模块所建立的故障联系，分析所述网络故障的告警信息所对应的故障原因。

所述模型建立模块，用于根据所述实体MIB物理表建立所述系统中的设备实体模型，具体通过以下方式进行设定：

所述模型建立模块读取所述实体MIB物理表中的设备关系信息，将所述实体MIB物理表中当前最高级别的设备信息所对应的物理实体作为设备实体模型的根节点，并根据所述实体MIB物理表中的级别关系建立所述设备实体模型；

其中，所述模型建立模块还用于根据预设的设备实体模型约束策略，查找所述设备实体模型中是否有违反所述约束策略的节点；

其中，如果是根节点违反所述约束策略，则所述模型建立模块确定所述设备实体模型无效。

所述网络管理设备还包括：

标识模块，用于对所述网络故障的告警信息所对应的设备实体模型中的设备进行标识；

所述分析模块，用于当所述设备实体模型中的设备中包含告警信息未分析的标识时，分析所述网络设备是否存在故障，并根据所述分析结果，确定所述网路故障的原因。

所述分析模块根据所述分析结果，确定所述网路故障的原因，具体包括：

如果所述分析模块判断一个网络设备存在对应的故障告警信息，则查找所述网络设备的上级设备是否包含故障告警信息，如果所述网络设备的直接上级设备包含故障告警信息，则以所述直接上级设备的故障告警信息为临时根源，并以该上级设备为基础，进一步向上查找各级上级设备，以确定故障告警信息的根源；

进一步的，如果所述分析模块判断所述网络设备包含多个故障告警信息，则查找tbl_trap_catalog_main数据表，如果所述多个故障告警信息的类别相同，则以最早收到的故障告警信息为根源。

与现有技术相比，本发明具有以下优点：

本发明能够基于设备的实体结构，识别出真正的故障实体，排除由于故障实体问题所引起的源实体包含的子实体和逻辑实体故障。

附图说明

图1为本发明所提出的网络故障分析方法的流程示意图；

图2为本发明所提出的具体的应用场景设备中物理实体关系的示意图；

图3为本发明所提出的具体应用场景下网络故障分析方法的流程示意图；

图4为本发明所提出的网络管理设备的结构示意图。

具体实施方式

为了解决现有技术的问题，本发明提出了一种网络故障分析方法，应用于包括多个网络设备和一个网络管理设备的系统中，多个网络设备之间的关系结构通过实体MIB物理表进行表示。

如图1所示，为本发明所提出的一种网络故障分析方法的流程示意图，具体包括以下步骤：

步骤S101、网络管理设备根据实体MIB物理表建立系统中的设备实体模型。

本步骤具体通过以下方式进行设定：

网络管理设备在进行自动发现或添加设备时，读取实体MIB物理表中的设备关系信息；

网络管理设备将实体MIB物理表中当前最高级别的设备信息所对应的物理实体作为设备实体模型的根节点；

网络管理设备根据实体MIB物理表中的级别关系建立设备实体模型。

进一步的，在设备实体模型建立之后，该方法还包括网络管理设备根据预设的设备实体模型约束策略，查找设备实体模型中是否有违反约束策略的节点的过程；

如果有，则将该节点及其以下节点从设备实体模型中删除；

其中，如果是根节点违反约束策略，则网络管理设备确定设备实体模型无效。

步骤S102、网络管理设备将接收到的网络故障的告警信息与设备实体模型中相应的网络设备建立联系，具体包括：

当网络管理设备接收到故障告警信息时，网络管理设备查询告警信息中是否包含预设的信息；

如果包含与各级别设备相对应的标识信息，则网络管理设备将网络故障的告警信息与相应的设备建立联系；

如果包含与更新设备信息相对应的标识信息，则网络管理设备重新读取实体MIB物理表，更新设备实体模型。

步骤S103、网络管理设备根据设备实体模型和故障联系，分析网络故障的告警信息所对应的故障原因。

其中，网络管理设备分析网络故障的告警信息所对应的故障原因之前，还包括：

对网络故障的告警信息所对应的设备实体模型中的设备进行标识；

当网络管理设备发现设备实体模型中的设备中包含告警信息未分析的标识时，分析网络设备是否存在故障；

网络管理设备根据分析结果，确定网路故障的原因。

在此基础上，本步骤的具体实现过程包括：

如果网络管理设备判断一个网络设备存在对应的故障告警信息，则查找网络设备的直接上级设备是否包含故障告警信息；

如果网络设备的直接上级设备包含故障告警信息，则以直接上级设备的故障告警信息为临时根源信息，此处需要说明的是，由于本发明所提出的技术方案需要对所建立的设备实体模型中的各设备均进行故障分析后，才能最终正式确定故障根源的，因此，对于某个设备，如果其直接上级设备存在故障告警信息，此时，并不能判定该上级设备是否为所述设备故障告警的根源.此时只能初步确定其直接上级设备可能为故障告警信息的根源，因此，将该上级设备标识为故障告警的临时根源。这样做的考虑是基于本发明技术方案还会对其直接上级设备进行故障分析，并进而得出其直接上级的故障告警信息的根源，并进而得出真正的故障根源，不仅如此，本发明技术方案对于进行故障分析的顺序没有必然要求，如果先进行下级设备的故障检测，则根据后续的上级设备的故障检测可以不断推进故障根源的推测，并进而找出真正的故障根源，如果先进行上级设备的故障检测，则在进行下级设备的故障检测时，只将其余直接上级设备的故障进行关联，而其直接上级设备的故障则进一步与更上级的设备的故障进行关联，通过层进关联的方式追溯故障根源；

如果网络设备的直接上级设备不包含故障告警信息，则继续查找级别为该上级设备的所有上级设备(以下统称“超级设备”)是否包含故障告警信息，如果包含，则查找tbl_trap_catalog_main数据表，如果网络设备与其超级上级设备的故障告警信息的类别相同，则以超级上级设备的故障告警信息为根源，如果信息类别不同，则认为两个故障告警信息无关，需要独立进行分析；

如果网络设备的直接上级设备和超级上级设备都不包含故障告警信息，或网络设备与其超级上级设备的故障告警信息的类别不相同，则以网络设备的故障告警信息为根源；

进一步的，如果网络管理设备判断网络设备包含多个故障告警信息，则查找tbl_trap_catalog_main数据表，如果多个故障告警信息的类别相同，则以最早收到的故障告警信息为根源。

与现有技术相比，本发明具有以下优点：

通过应用本发明的技术方案，能够基于设备的实体结构，识别出真正的故障实体，排除由于故障实体问题所引起的源实体包含的子实体和逻辑实体故障。

下面，进一步结合具体的示例，对本发明的技术方案进行说明。

实体MIB(ENTITY-MIB)物理表(entPhysicalTable)描述了以树型模型管理设备中各种类型的物理实体，以及各物理实体之间的关系。通过实体MIB，可以获得设备上物理实体之间的关系结构，获取物理实体的相关数据和状态。

RFC4133是RFC2737的更新版，定义了如下12种实体类型。

PhysicalClass::＝TEXTUAL-CONVENTION

STATUS current

SYNTAX INTEGER {

other(1)，

unknown(2)，

chassis(3)，

backplane(4)，

container(5)， --e.g.，chassis slot or daughter-card holder

powerSupply(6)，

fan(7)，

sensor(8)，

module(9)， --e.g.，plug-in card or daughter-card

port(10)，

stack(11)， --e.g.，stack of multiple chassis entities

cpu(12)

}

其中，设定各个实体类型和产品类型对应关系如表1所示：

表1 各实体类型和产品类型对应关系

根据entPhysicalTable表中的entPhysicalContainedIn和entPhysicalParentRelPos两个MIB对象实例的值来完成设备上物理实体排列及包含关系的计算。

进一步的，在具体的应用场景中，一个设备中物理实体关系可以用图2所示。

在其中，该设备需要遵循的实体关系实现约束包括以下几个方面：

1、stack类型物理实体下直接包含chassis类型物理实体；对于不会实现堆叠或堆叠类似特性的产品，则可以不实现物理实体类型为stack的物理实体。实现stack物理类型的产品，物理类型为stack的实体在物理实体树中仅能出现一次，并且必须为物理实体树的树根。不实现stack物理实体类型的产品以chassis物理实体类型作为物理实体树中的根节点，物理类型为chassis的实体在物理实体树中仅能出现一次，并且必须为物理实体树的树根。

2、每个chassis类型物理实体下挂的物理实体类型只能为container。

3、Powersupply，unknown，fan，other，module，cpu，backplane，sensor等实体类型必须被container类型实体包含，即它们的父实体为container类型实体。

4、container类型实体可以被chassis、module、backplane类型实体包含。被chassis包含的container实体称为一级container(container level 1)。如果从本container向树根(stack)回溯的路径上包含(N-1)个container类型实体，那么本container就是N级container实体(Container level N)。

5、module类型物理实体的级别根据其所属container类型实体的级别来决定。例如，module类型物理实体的父实体container级别为N级，那么该module的级别就为N，成为N级module(module lever N)

6、Port类型实体的父实体必须为module。

7、Cpu类型实体的父实体类型必须为container，该container实体的父实体应该为module或者backplane。

8、Sensor类型实体的父实体类型必须为container，该container实体的父实体应该为module或者backplane。

9、module类型实体只允许包含port和container类型的实体。

10、一个container类型实体只允许包含一个其它类型的实体，不应该出现一个container同时包含多个相同类型实体的情况(例如不允许一个container下包含多个cpu类型实体)。

11、powersupply，fan，cpu类型物理实体的父实体container所在位置，由powersupply，fan，cpu类型实体服务的对象决定。例如，为这个设备散热工作的fan，那么包含该fan类型物理实体的container应该被chassis类型实体包含。

12、sensor类型物理实体的父实体container所在位置，由该sensor类型物理实体监控的对象决定。例如，监控整机温度的sensor，其父实体container应该为chassis所包含。

13、container类型实体不允许直接包含container类型实体。

14、stack，chassis，container三类物理实体所在层次上不允许出现其它类型物理实体。例如上图中，在container实体层级上仅有container类型实体，不会出现其它类型的实体。

15、允许在同一物理实体层级上排列的实体，必须遵循以下排列顺序：

module-backplane-powerSupply-fan-sensor-other-unknown

如果某种类型的物理实体在设备上实际不存在，则跳过该实体，顺次排列后续物理实体。

16、当某一层级上某类物理实体类型的实体个数在多于1个时，物理实体排列顺序应遵循分类排列的原则，即先排列完一类实体再顺次排列下一类实体，如上图中以container level 1为父实体的module等实体，所有module类型实体排列完成后，再排列后续的powersupply实体。

基于上述的物理实体关系及各部分间的约束关系，网络管理设备需要根据实体MIB的结构特征，分析出设备的物理、逻辑结构，然后将故障告警与该结构相关联，并根据结构路径分析告警的因果关系。

具体的算法过程如下：

步骤S301、网络管理设备根据设备实体MIB建立设备实体模型。

进行自动发现或添加设备时，网络管理设备需要读取实体MIB的entPhysicalTable表中的以下各列的数据：

entPhysicalIndex，

entPhysicalClass，

entPhysicalContainedIn，

entPhysicalParentRelPos。

网络管理设备读取IF-MIB信息，并将ifIndex与entPhysicalIndex对应关系保存在内存中。

网络管理设备查找stack类型物理实体作为根节点，如没有则查找chassis类型物理实体作为根节点。

网络管理设备根据entPhysicalContainedIn、entPhysicalParentRelPos列信息建立实体所引的树型模型。

网络管理设备基于上述的各约束，查找树型模型中是否有违反约束的节点。

如果发现则将该节点及其以下节点从树型模型中删除，

如果从根节点违反约束，则标识整棵设备实体树型模型无效。

步骤S302、网络管理设备将网络故障与实体模型建立关系。

网络管理设备接收到故障告警，一方面，查找参数中是否包含“1.3.6.1.2.1.47.1.1.1.1.1”参数，如果包含则将其与设备实体树型模型相关联。其中，参数“1.3.6.1.2.1.47.1.1.1.1.1”是实体MIB表中“entPhysicalIndex”数据的对象标识(Object identifier，OID)，根据是否包含该参数可以确定故障告警是否与具体的设备实体相对应。

另一方面，查找参数中是否包含“1.3.6.1.2.1.2.2.1.1”参数，如果包含该参数则查找内存信息将其转换为entPhysicalIndex，同时将其与设备实体树型模型相关联。其中，参数“1.3.6.1.2.1.2.2.1.1”是实体MIB表中“InterfaceIndex”数据的OID，根据是否包含该参数可以确定故障告警是否与当前系统中的接口相对应，从而，如果可以确定故障接口(InterfaceIndex)，则可以进一步确定故障所对应的具体的设备实体(entPhysicalIndex)。

在具体的应用场景下，如果网络管理设备接收到了包含参数“1.3.6.1.2.1.47.2.0.1”的告警，则网络管理设备重新读取实体MIB和IF-MIB，刷新设备实体树型模型。其中，参数“1.3.6.1.2.1.2.2.1.1”是实体MIB表中“entConfigChange”数据的OID，如果告警中包含该参数，则表示实体MIB表中的信息发生变化，需要根据变化后的实体MIB表信息对设备实体模型进行更新。

步骤S303、网络管理设备基于实体模型分析网络故障的原因。

如果某设备实体模型包含未分析过的告警信息则将其标志为1；如果某设备实体树中不存在告警，则将其标志为2。

网络管理设备定期轮询各个设备，如果设备分析标志位为1，则分析该设备：

如果某实体存在故障，查找其直接上级是否包含故障告警，如果包含则以上级告警为根源；

如果某实体存在故障，且其直接上级不包含故障告警，则查找其超级上级是否半酣故障告警，如果包含则查找tbl_trap_catalog_main数据表，如果该两告警属于同类告警，则以超级告警为根源；

同一实体包含多个故障，则查找tbl_trap_catalog_main数据表，如果多个告警属于同类告警，则以先到告警为根源；

为了更好的实现分析效果，对于分析后告警设定初次分析计时器，并查找是否之前设定过初次分析计时器，

如果距离初次分析时间超过时间窗则，则将该告警自身作为根告警，并从实体树中拆离。

为了实现本发明的技术方案，本发明还提出了一种网络管理设备，应用于包括多个网络设备和一个网络管理设备的系统中，其特征在于，多个网络设备之间的关系结构通过实体MIB物理表进行表示。

如图4所示，为本发明所提出的一种网络管理设备的结构示意图，具体包括：

模型建立模块41，用于根据实体MIB物理表建立系统中的设备实体模型，具体通过以下方式进行设定：

模型建立模块读取实体MIB物理表中的设备关系信息；

模型建立模块将实体MIB物理表中当前最高级别的设备信息所对应的物理实体作为设备实体模型的根节点；

模型建立模块根据实体MIB物理表中的级别关系建立设备实体模型。

其中，模型建立模块还用于根据预设的设备实体模型约束策略，查找设备实体模型中是否有违反约束策略的节点；

如果有，则将该节点及其以下节点从设备实体模型中删除；

其中，如果是根节点违反约束策略，则模型建立模块确定设备实体模型无效。

联系模块42，用于根据模型建立模块41所建立的设备实体模型，将接收到的网络故障的告警信息与相应的故障设备建立联系；

分析模块43，用于根据联系模块42所建立的故障联系，分析网络故障的告警信息所对应的故障原因。

在具体的应用场景中，的网络管理设备还包括：

标识模块44，用于对网络故障的告警信息所对应的设备实体模型中的设备进行标识；

分析模块43，用于当设备实体模型中的设备中包含告警信息未分析的标识时，分析网络设备是否存在故障，并根据分析结果，确定网路故障的原因。

相应的，分析模块根据分析结果，确定网路故障的原因的过程具体包括：

如果分析模块43判断网络设备存在故障，则查找网络设备的上级设备是否包含故障告警，如果包含则以上级设备的故障告警为临时根源，并以该上级设备为基础，进一步向上查找各级上级设备，以确定故障告警信息的根源；

如果分析模块43判断网络设备存在故障，且网络设备的直接上级不包含故障告警，则查找其超级上级是否包含故障告警，如果包含则查找tbl_trap_catalog_main数据表，如果该两告警属于同类告警，则以超级上级的告警信息为根源；

如果分析模块43判断网络设备包含多个故障，则查找tbl_trap_catalog_main数据表，如果多个告警信息属于同类告警，则以先到的告警信息为根源。

与现有技术相比，本发明具有以下优点：

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

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

以上公开的仅为本发明的几个具体实施场景，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims

1.一种网络故障分析方法，应用于包括多个网络设备和一个网络管理设备的系统中，其特征在于，所述多个网络设备之间的关系结构通过实体MIB物理表进行表示，所述方法包括以下步骤：

2.如权利要求1所述的方法，其特征在于，所述网络管理设备根据所述实体MIB物理表建立所述系统相对应的设备实体模型，具体通过以下方式进行设定：

3.如权利要求1所述的方法，其特征在于，所述网络管理设备将接收到的网络故障的告警信息与所述设备实体模型中相应的网络设备建立联系，具体包括：

当所述网络管理设备接收到网络故障的告警信息时，所述网络管理设备查询所述告警信息中是否包含预设的标识信息；

如果包含设备信息变更的标识信息，则所述网络管理设备重新读取实体MIB物理表，更新所述设备实体模型。

4.如权利要求1至3中任意一项所述的方法，其特征在于，当建立或更新所述设备实体模型之后，还包括：

5.如权利要求1所述的方法，其特征在于，所述网络管理设备根据所述设备实体模型，分析所述网络故障的告警信息所对应的故障原因之前，还包括：

所述网络管理设备根据所述分析结果，确定所述网络故障的原因。

6.一种网络管理设备，应用于包括多个网络设备和一个网络管理设备的系统中，其特征在于，所述多个网络设备之间的关系结构通过实体MIB物理表进行表示，包括：

分析模块，与所述联系模块相连接，用于根据所述联系模块所建立的故障联系，分析所述网络故障的告警信息所对应的故障原因，具体包括：

7.如权利要求6所述的网络管理设备，其特征在于，所述模型建立模块，用于根据所述实体MIB物理表建立所述系统中的设备实体模型，具体通过以下方式进行设定：

8.如权利要求6所述的网络管理设备，其特征在于，还包括：

所述分析模块，用于当所述设备实体模型中的设备中包含告警信息未分析的标识时，分析所述网络设备是否存在故障，并根据所述分析结果，确定所述网络故障的原因。