Browse Prior Art Database

Autonomic Network Problem Determination and Resolution

IP.com Disclosure Number: IPCOM000119088D
Original Publication Date: 2005-Apr-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 31K

Publishing Venue

IBM

Abstract

Disclosed in this article is an architecture to autonomically detect and correct network problems using event correlation and real-time network availability and performance monitors.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Autonomic Network Problem Determination and Resolution

Disclosed in this article is an architecture to autonomically detect and correct network problems using event correlation and real-time network availability and performance monitors.

This invention ties together closely event correlation, task automation and network monitoring tools to complete a feedback loop to keep a network in a stable state. Using a network availability and performance monitor, which implements a real-time network monitoring interface, event correlation servers could receive notification of base network events. Given these base network events, the event server using rules could determine autonomically that more information is necessary to determine the root cause of a network issue, and issue a request to the real-time network monitoring interface to gather more information about the network and forward this information as events to the event server. Using this information, plus any new events the event server could automatically solve the network outages, alleviating the burden of collecting and solving issues from the network administrators.

The network monitoring application, consists of an architecture that has a central control point running on WebSphere, and distributed, lightweight JAVA / C network monitors. The central control point contains the logistics for what is to be monitored by each of the distributable monitors. What the monitors poll in the network can be configured in one of two ways, either a persistent configuration, or a non-persistent "real-time" poller configuration. The real-time poller configuration will be used by the event server to collect more network information when an original event has triggered a rule to collect more information. The network monitoring application also has network topology information which would be used in the problem determination part of the invention.

IBM Tivoli Enterprise Console, will be used as the event server and rule/correlation engine. In IBM Tivoli Enterprise Console you can write rules which will allow the user to run tasks when particular events are received by the event server. Specific rules would be written to handle network problem events, which will kick off the task of initiating a real-time poller configuration to the central control point for the network monitoring application. The networking monitoring application will then issue the real-time poller configuration to one or more of the distributed monitors depending on the severity of the problem or configuration. Distributing the real-time poller configuration to multiple monitors will allow for different vantage points from the network to assure that the problem is not specific to one subnet, etc.

The distributed monitors would poll availability and performance metrics from the network device in question, and possibly from other key network devices that the device in question is dependent on ( i.e. routers, swit...