JP6057470B2 - Network alarm processing system - Google Patents

Description

  The present invention relates to an alarm processing system for a network, and more particularly, to a network that can reduce the total number of alarms by aggregating alarms issued from a plurality of node devices for one alarm cause and reliably detect silent failures. The present invention relates to an alarm processing system.

  With the development of network virtualization technology, the number of managed objects in the interface and the network itself has increased explosively, and the number of alarms that are generated tends to increase, resulting in a delay in grasping the network failure status (especially failure cause analysis) There are challenges.

  In response to such a technical problem, the inventors of the present invention offload data processing inside each node device on the network, rather than managing the data held by the network device on a centralized management platform. A method was developed and a patent application (Patent Document 1) was filed. Furthermore, quality and performance information such as traffic volume has also increased significantly, and the load on the management system side is expected to increase. Therefore, a method for offloading processing to the device was developed, and a patent application (patent document) 2)

Japanese Patent Application No. 2012-030371 Japanese Patent Application No. 2013-059035

  In order to detect and understand network service abnormalities, network operators receive SNMP (Simple Network Management Protocol) and Syslog information set by all devices using an external management system (NMS: Network Management System) The state transition is grasped. However, since alarm information is transmitted in units of devices in the existing method, alarms that are not directly caused are sent out, and alarm information increases explosively as the number of node devices to be managed increases, resulting in processing. There is a delay. In addition, there may be a delay in finding silent failures.

  An object of the present invention is to solve the above technical problem, and distribute a part of the alarm management function of the management system inside each node device on the network, and the adjacent node devices alarm each other. An object of the present invention is to provide an alarm processing system capable of reducing the number of alarms to be notified to a management system by confirming information and detecting a silent failure.

  In order to achieve the above object, the present invention is characterized in that the following configuration is an invention-specific item in an alarm processing system that distributes alarm information on node devices of a network.

  (1) Configuration management means for managing network topology and ID of each node device, alarm DB for storing alarm information detected by the node device, means for identifying neighboring devices based on the network topology, and adjacent to each other One of the node devices to be referenced refers to the other alarm DB, and if the same alarm information as the alarm information is registered, means for deleting the alarm information from the alarm DB of the own device, and stored in the alarm DB Means for transmitting alarm information to the management system.

  (2) When the same alarm information as the alarm information is registered in the alarm DB of the other node device, one node device sets the adjacency confirmation flag in the alarm information, and the other node device reports the alarm. The information is transmitted to the management system together with the adjacency confirmation flag.

  (3) If the same alarm information as the alarm information is not registered in the alarm DB of the other node device, one node device sets a silent flag in the alarm information and sends the alarm to the management system together with the silent flag. I sent it.

  (4) The other node device sets a silent flag if the adjacency confirmation flag is not set in the alarm information registered in the alarm DB, and transmits the alarm to the management system together with the silent flag.

According to the present invention, the following effects are achieved.
(1) Even if the same alarm due to the same network failure is detected in multiple node devices, the same alarm is aggregated to one adjacent node between adjacent nodes, so the same alarm is managed from multiple node devices. Inconvenience sent to the system is prevented.

  (2) An alarm that is registered only in the local device and not registered in the adjacent node device is estimated as an alarm caused by a silent failure, and the alarm is sent to the management system together with information indicating that the alarm is caused by a silent failure. Thus, the management system can easily determine the silent failure.

It is the functional block diagram which showed the structure of the network node apparatus with which the alarm processing system which concerns on this invention is applied. It is the figure which expressed typically operation | movement of one Embodiment of invention. It is the flowchart which showed operation | movement of one Embodiment of this invention. It is the figure which showed the format of the alarm notification.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 is a functional block diagram showing a configuration of a network node device to which an alarm processing system according to the present invention is applied. A large number of network node devices INM and its management system 1 are arranged on the network.

  Each node device INM operates an SNMP agent, and each SNMP agent sends an SNMP trap (Trap) when occurrence of a predetermined event, detection of a process value exceeding a threshold value, or the like is detected. The SNMP trap is transmitted to the SNMP manager of the management system 1 via the API of each node device INM.

  In the node device INM, the alarm processing board 21 monitors an SNMP trap sent by the SNMP agent in real time, and performs a mask process based on an alarm mask rule set on the board. The alarm mask rule is a function for masking alarms determined to be unnecessary by a filter function set on the high-speed data processing platform, and also has an alarm processing flow function for confirming the alarm reception status between adjacent devices. .

  In the present embodiment, Connections and ConnectionLess managed by the configuration management DB, and OID information held in the network are masked. The alarm masked alarm is stored in the alarm storage DB 23 for a certain period of time, while the alarm not masked is stored in the alarm DB 22. The shared database 25 provides a mechanism for sharing and managing configuration management data (device configuration information and network topology information) among a plurality of node devices.

  The API (external interface function unit) realizes an interface function for transferring an SNMP trap in which alarm information is described to the management system 1. In the shared DB 25, a network topology and an identification ID unique to each node device INM are registered. In this embodiment, an IP address is used as the identification ID of each node device INM.

  Next, the operation of the present invention will be described in detail with reference to the block diagram of FIG. 2 and the flowchart of FIG.

  In step S1, it is determined whether an alarm (Trap) sent from the active SNMP agent in each node device INM has been received. Here, the description will be continued assuming that the traps describing the same alarm caused by the same network failure are received at substantially the same time in the mutually adjacent node devices INM1 and INM2.

  In step S2, the alarm is registered in the alarm DB 22 of the own device in each of the node devices INM1 and INM2. In this embodiment, as shown in FIG. 2, the alarm reception time and its source information, and the alarm information described in the SNMP trap OID (object ID) are extracted and the alarm is extracted. It is registered in the same record of DB22.

  In step S3, the adjacent node device INM is identified based on the network topology registered in the configuration management DB 25, and the identification ID (IP address in this embodiment) of the adjacent node device is stored in the registered alarm record. Registered as adjacent information. That is, since the node device INM1 recognizes the node device INM2 as an adjacent device, its IP address is registered as adjacent information in the corresponding record in the alarm DB 22. Since the node device INM2 recognizes the node device INM1 as an adjacent device, its IP address is registered as adjacent information in the corresponding record in the alarm DB 22.

  In step S4, each node device INM1, INM2 refers to the alarm DB 22 of the own device, and which of the device ID (source information) of the own device and the device ID (adjacent information) of the adjacent device is relatively young. To be judged. Here, the description will be continued assuming that the device ID (node 2) of the node device INM2 is lower than the device ID (node 1) of the node device INM1. Therefore, in the node device INM1, the process proceeds from step S4 to step S5, and in the node device INM2, the process proceeds from step S4 to step S12.

  First, paying attention to the operation of the old node device INM1, in steps S5 and S6, an attempt is made to connect the adjacent node device INM2 to the alarm DB 22, and if the connection is established, the process proceeds to step S7. In step S7, it is determined whether or not the same alarm as the alarm (alarm 1) received by the own device in step S1 is registered in the alarm DB 22 of the node device INM2. Here, since it is determined that the alarm 1 is registered in duplicate, the process proceeds to step S10, and the adjacency confirmation flag Fn of the same record associated with the alarm 1 is set in the alarm DB 22 of the adjacent node device INM2. = 1). In step S11, the duplicately registered alarm 1 is deleted from the alarm DB 22 of the node device INM1.

  Next, paying attention to the operation of the young node device INM2, the process waits for a predetermined time in step S12. In step S13, it is determined whether or not the adjacent confirmation flag Fn is “1” for the alarm already registered in the alarm DB 22 of the own device INM2. If the adjacent confirmation flag Fn is “1”, the process proceeds to step S9. If not "1", the process proceeds to step S8. In this embodiment, since the adjacency confirmation flag Fn for alarm 1 is set in step S10, the process proceeds to step S9. In step S9, the SNMP trap describing the alarm 1 is sent to the management system 1.

  On the other hand, if a silent failure occurs in the node device INM1 and the trap in which the alarm (alarm 2) is described is received only by the node device INM1, the process is executed only by the node device INM1. In step S7, since it is determined that the same alarm is not registered in the alarm DB 22 of the adjacent node device INM2, the process proceeds to step S8. In step S8, the silent flag Fs associated with the alarm 2 is set in the alarm DB 22 of the own device INM1. In step S9, the SNMP trap in which the alarm 2 is described is sent to the management system 1.

  FIG. 4 is a diagram showing a format of an SNMP trap transmitted from each node device INM to the management system 1. In this embodiment, “opposite device information” and “silent failure” are set as extended areas in the OID (object ID). Information "is prepared. When the silent flag Fs is set in step S8, in step S9, the alarm 2 is described as “original alarm information”, source information is described as “opposite device information”, and “silent failure information”. As described above, an SNMP trap in which the value of the silent flag Fs (here, 1) is described is generated and sent to the management system 1.

  In the management system 1, when the SNMP trap is received, if the “silent failure information” of the OID is set (= 1), a silent failure occurs in the node device INM described in “opposite device information”. Can be recognized. If “silent failure information” is not set, it can be determined that, for example, a link failure other than the silent failure has occurred.

  In the above embodiment, it has been described that SNMP is used as a communication protocol for monitoring and controlling network devices. However, the present invention is not limited to this, and is detected in each node device. Other protocols may be used as long as the original message or flag can be described in the failure and notified to the management system.

  According to the present embodiment, even if the same alarm due to the same network failure is detected in a plurality of node devices INM, the same alarm is aggregated to one adjacent node between adjacent nodes. The inconvenience of sending the same alarm from the INM to the management system 1 is prevented.

  In addition, according to the present embodiment, an alarm that is registered only in the own device and not registered in the adjacent node device is estimated as an alarm caused by a silent failure, and information indicating that the alarm is an alarm caused by a silent failure. Since it is transmitted to the management system 1 together, the management system 1 can easily determine the silent failure.

  DESCRIPTION OF SYMBOLS 1 ... Management system, 21 ... Alarm processing base, 22 ... Alarm DB, 23 ... Alarm storage DB, 24 ... API, 25 ... Shared database

Claims (6)

In an alarm processing system that distributes alarm information on node devices in a network,
Configuration management means for managing the network topology and the ID of each node device;
An alarm DB for storing alarm information detected by the node device;
Means for identifying neighboring devices based on the network topology;
One of adjacent node devices refers to the alarm DB of the other node device, and if the same alarm information as the alarm information is registered, means for deleting the alarm information from the alarm DB of the own device;
An alarm processing system comprising: means for transmitting alarm information stored in an alarm DB to a management system.   The one node device sets an adjacency confirmation flag in the alarm information when the same alarm information as the alarm information is registered in the alarm DB of the other node device, and the other node device The alarm processing system according to claim 1, wherein the alarm processing system is transmitted together with the adjacency confirmation flag to the management system.   The one node device sets a silent flag in the alarm information if the same alarm information as the alarm information is not registered in the alarm DB of the other node device, and the alarm is stored in the management system together with the silent flag. The alarm processing system according to claim 1, further comprising:   The other node device sets a silent flag if the adjacency confirmation flag is not set in the alarm information registered in the alarm DB, and transmits the alarm to the management system together with the silent flag. The alarm processing system according to any one of claims 1 to 3.   5. The node device adjacent to each other determines one of the node devices by comparing an ID unique to the own device with an ID unique to the adjacent device. 6. Alarm processing system.   6. The alarm processing system according to claim 1, wherein the alarm information transmitted to the management system is described in an SNMP trap and transmitted.