Network management event correlation in environments containing inoperative network elements

• US 6,061,723 A
• Filed: 10/08/1997
• Issued: 05/09/2000
• Est. Priority Date: 10/08/1997
• Status: Expired due to Term

• Current Assignee: Hewlett Packard Enterprise Development LP (Hewlett-Packard Enterprise Company)
• Original Assignee: Hewlett-Packard Company (HP Inc.)
• Inventors: Walker, Anthony, Smith, Darren D., Pulsipher, Eric A.
• Primary Examiner(s): Maung, Zarni
• Assistant Examiner(s): DINH, KHANH Q
• Application Number:
  US08/947,219
• Time in Patent Office: 944 Days
• Field of Search: 709/224, 709/225, 709/300, 709/229, 379/21, 379/111, 370/255
• US Class Current: 709/224
• CPC Class Codes: H04L 41/0631 using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
• CPC Class Codes: H04L 41/12 Discovery or management of network topologies
• CPC Class Codes: H04L 41/22 comprising specially adapted graphical user interfaces [GUI]
• CPC Class Codes: H04L 43/00 Arrangements for monitoring or testing data switching networks
• CPC Class Codes: H04L 43/0811 by checking connectivity
• CPC Class Codes: H04L 43/0817 by checking functioning
• CPC Class Codes: H04L 43/10 Active monitoring, e.g. heartbeat, ping or trace-route

Abstract

A network monitor for distinguishing between broken and inaccessible network elements. The network monitor includes one or more computer readable storage mediums, and computer readable program code stored in the one or more computer readable storage mediums. The computer readable program code includes code for discovering the topology of a plurality of network elements, code for periodically polling a plurality of network interfaces associated with the plurality of network elements, code for computing or validating a criticalRoute attribute for each of the plurality of network interfaces, and code for analyzing a status of network interfaces identified by the criticalRoute attribute of an interface in question (IIQ) which is not responding to a poll or ping. The computer readable program code may also include code for establishing a slowPingList and placing in-memory representations of broken or failed network interfaces thereon, thereby reducing the amount of information which is presented to a network administrator from inaccessible elements not responding to a network interface poll. A means for correlating and/or suppressing events in response to the determination of whether a network interface is failed or broken is also provided. Information which is not critical to a network administrator may be suppressed, and then viewed in a "drill down" of a particular network interface.

Claims

1. A network monitor for distinguishing between broken and inaccessible network elements, comprising:

a) one or more computer readable storage mediums; and

b) computer readable program code stored in the one or more computer readable storage mediums, the computer readable program code comprising;

i) code for discovering the topology of a plurality of network elements;

ii) code for periodically polling a plurality of network interfaces associated with the plurality of network elements;

iii) code for computing or validating a criticalRoute attribute for each of the plurality of network interfaces; and

iv) code for analyzing a status of network interfaces identified by the criticalRoute attribute of an interface in question (IIQ) which is not responding to a poll.

2. A network monitor as in claim 1, wherein the code for computing a criticalRoute attribute for a particular network interface of a network element comprises code for identifying a route taken by a packet used to poll the particular interface.

3. A network monitor as in claim 1, further comprising code for establishing a slowPingList and placing in-memory representations of broken or failed network interfaces thereon.

4. Network management apparatus for distinguishing between broken and inaccessible network elements, and for presenting this information to a network administrator in an easy to comprehend format, comprising:

a) a display process; and

b) a network monitor comprising;

i) means for discovering the topology of a plurality of network elements connected thereto;

ii) means for periodically polling a plurality of network interfaces associated with the plurality of network elements;

iii) means for computing or validating a criticalRoute attribute for each of the plurality of network interfaces; and

iv) means for analyzing a status of network interfaces identified by the criticalRoute attribute of an interface in question (IIQ) which is not responding to a poll;

wherein the display process and network monitor communicate by way of one or more event buses.

5. Network management apparatus as in claim 4, further comprising:

an event correlation system;

wherein the one or more event buses comprise a correlated event bus; and

wherein the display process receives event data over the correlated event bus.

6. Network management apparatus as in claim 5, wherein:

a) the system further comprises an annotation server;

b) the event correlation system comprises an annotation node; and

c) the annotation server and the annotation node communicate by way of a communication channel.

7. Network management apparatus as in claim 6, wherein the annotation server is configured to process the following annotation information:

a) an annotation providing for critical node recognition;

b) an annotation indicating how critical node secondaryFailures should be processed and displayed;

c) an annotation indicating how regular node secondaryFailures should be processed and displayed; and

d) an annotation providing for regular node secondaryFailure suppression.

8. Network management apparatus as in claim 6, wherein the annotation server comprises a portion of the network monitor.

9. Network management apparatus as in claim 5, wherein:

a) the event correlation system comprises a means for suppressing events so they do not appear on the correlated events bus; and

b) the display process comprises a drill down interface through which various suppressed events may be called up for viewing.

10. A computer implemented method of distinguishing between broken and inaccessible network elements, and for presenting this information to a network administrator in an easy to comprehend format, comprising the steps of:

a) discovering the topology of a plurality of network elements;

b) periodically polling a plurality of network interfaces associated with the plurality of network elements;

c) computing or validating a criticalRoute attribute for each of the plurality of network interfaces; and

d) analyzing a status of network interfaces identified by the criticalRoute attribute of an interface in question (IIQ) which is not responding to a poll.

11. A method as in claim 10, wherein the step of analyzing the status of network interfaces identified by the criticalRoute attribute of an IIQ which is not responding to a poll comprises the steps of:

a) first examining in-memory statuses of one or more network interfaces to determine whether a network interface identified by the criticalRoute attribute for the IIQ is Down, and if so, identifying that network interface as a primaryFailure interface;

b) second, if a network interface identified by the criticalRoute attribute for the IIQ has not been identified as a primaryFailure interface, verifying the statuses of one or more network interfaces identified by the criticalRoute attribute for the IIQ to determine if one of them is a primaryFailure interface; and

c) third, if a network interface identified by the criticalRoute attribute for the IIQ has not been identified as a primaryFailure interface, identifying the IIQ as a primaryFailure interface.

12. A method as in claim 11, wherein the steps of examining in-memory statuses of one or more network interfaces, and verifying the statuses of one or more network interfaces, each comprise the step of examining or verifying network interfaces identified by the criticalRoute attribute for the IIQ:

a) one at a time; and

b) beginning with a network interface closest to a network monitor'"'"'s interface.

13. A method as in claim 10, further comprising the step of maintaining a criticalRouteWaitList, wherein a pre-criticalRouteWaitList algorithm comprises the steps of:

a) examining in-memory statuses of one or more network interfaces to determine whether a network interface identified by the criticalRoute attribute for the IIQ is Down, and if so, identifying that network interface as a primaryFailure interface; and

b) if the above step successfully identifies a network interface as a primaryFailure interface,

i) identifying the IIQ as a secondaryFailure interface;

ii) emitting a secondaryFailurelnterfaceDown event; and

iii) placing an in-memory representation of the IIQ on a slowPingList.

14. A method as in claim 13, further comprising the step of, if the step of examining in-memory statuses of one or more network interfaces successfully identifies a network interface as a primaryFailure interface, changing the status of the IIQ to Unknown in a topology database.

15. A method as in claim 13, wherein a criticalRouteWaitList algorithm comprises the steps of:

a) if none of the network interfaces identified by the criticalRoute attribute for the IIQ have been identified as a primaryFailure interface, verifying the statuses of one or more network interfaces identified by the criticalRoute attribute for the IIQ by,

i) moving an in-memory representation of the IIQ, and all network interfaces identified by the criticalRoute attribute for the IIQ, to a criticalRouteWaitList, and removing these network interfaces from all other lists accessible to a network monitor executing this method;

ii) sequentially walking the criticalRouteWaitList, polling each network interface to determine if it is a primaryFailure interface; and

b) if a network interface identified by the criticalRoute attribute for the IIQ has not been identified as a primaryFailure interface, identifying the IIQ as a primaryFailure interface, otherwise identifying the IIQ as a secondaryFailure interface.

16. A method as in claim 15, further comprising the steps of, after a primaryFailure interface has been identified:

a) changing the status of the primaryFailure interface to Critical in a topology database;

b) emitting a primaryFailurelnterfaceDown event; and

c) moving the in-memory representation of the primaryFailure interface from the criticalRouteWaitList to the slowPingList.

17. A method as in claim 15, further comprising the steps of, if the step of verifying statuses of one or more network interfaces successfully identifies a network interface as a primaryFailure interface,

a) identifying the IIQ as a secondaryFailure interface;

b) emitting a secondaryFailurelnterfaceDown event; and

c) moving the in-memory representation of the IIQ to the slowPingList.

18. A method as in claim 10, wherein the step of computing a criticalRoute attribute for a particular interface of a network node comprises giving preference to a route comprising router nodes.

19. A method as in claim 10, further comprising the step of using an IIQ'"'"'s criticalRoute attribute to identify an IIQ as a primaryFailure interface or a secondaryFailure interface.

20. A method as in claim 19, further comprising the step of assigning a UUID var-bind to primaryFailure interfaces and secondaryFailure interfaces.

21. A method as in claim 20, wherein the step of assigning a UUID var-bind to a particular secondaryFailure interface comprises the steps of:

a) looking up a corresponding primaryFailure interface UUID var-bind; and

b) including the corresponding primaryFailure interface UUID var-bind in a UUID var-bind for the particular secondaryFailure interface.