Managing conditions in a network

The invention relates to managing conditions in a network.

In a computer network, problems or other conditions associated with one or more network devices frequently pop up. To manage and maintain such problems in the network, an event log is typically stored on a selected network management system. To notify the management system of predetermined conditions, a network device sends a message (e.g., trap) to the management system. If the management server is on and it recognizes the trap condition, then an entry is added to the event log. However, if the management system is off when the message is transmitted, the message is missed and the event log is not updated.

As the number of devices connected to the network increases, the size of the event log also increases. To maintain the event log at a manageable size, a network administrator must manually remove entries as conditions are resolved.

In general, in one aspect, the invention features a network system having a network device and a management system configured to identify a condition associated with the network device and to automatically update an event list in response to the condition being resolved.

Implementations of the invention may include one or more of the following features. The management system polls the network device to determine the status of the condition. The network device is configured to transmit a message to the management system in connection with an occurrence of the condition. The management system automatically updates the event list by determining if a condition on the event list has been resolved, and if so, removing a corresponding entry from the event list.

The invention may have one or more of the following advantages. Problems and other conditions kept in a log are automatically removed without user intervention. As a result, the log reflects the current state of all monitored network devices since it only keeps information for conditions that have not been resolved. Because a management system can poll devices for conditions in the network, the likelihood that conditions are missed by the management system is reduced.

Implementations of the invention may further include the following features. The management system includes a storage device for storing a description database identifying information associated with the condition. The description database can be updated to add more conditions. The description database includes an MIB variable associated with the condition.

In general, in another aspect, the invention features a computer system for connection to a network. The computer system includes a processor, a management program executed by the processor to identify a condition on the network, and a storage device on which an event list is stored. The management program updates the event list in response to the condition being resolved.

In general, in another aspect, the invention features a method of managing conditions in a network of network devices. A condition on the network is identified, and a computer system on the network automatically updates an event list in response to the condition being resolved.

In general, in another aspect, the invention features a computer program implemented in a computer for causing the computer to identify a condition in a network, and to automatically update an event list in response to the condition being resolved.

In general, in another aspect, the invention features a computer-implemented graphical user interface method that displays an event list containing an entry associated with an identified condition in a network, and automatically updating the event list in response to the condition being resolved.

In general, in another aspect, the invention features a display that is displayable by a management program on a computer monitor. The display has a first screen listing conditions associated with devices in a network. The first screen is updated in response to the conditions being resolved.

Other features and advantages will become apparent from the following description and from the claims.

FIG. 1 is a block diagram of a computer network.

FIG. 2 is a block diagram of a management console system in the computer network.

FIG. 3 is a flow diagram illustrating the steps of a network management application running on the management console system.

FIG. 4 is a table listing recognized conditions.

FIG. 5 is a table of information and steps associated with the conditions.

FIG. 6 shows an action list and device list maintained by the network management application.

FIG. 7 shows an action detail screen describing the specific help for an action.

FIG. 8 shows an action list log screen listing the complete history of the action list.

FIGS. 9A and 9B are a table listing the conditions identified by data type and fault type.

FIG. 10 is a block diagram of a computer system such as that used to implement the management console system.

Referring to FIG. 1, an exemplary network 8 (including a local area network 10 ) includes computing devices 20 , 22 , 24 , 26 , 28 , 30 , 32 and 34 . The devices can include desktop, laptop, hub, and gateway systems. The network 8 can be a TCP/IP (transmission control protocol/internet protocol), an IPX/SPX (a Novell Netware protocol), or other type protocol network.

A management console system 26 in the network 10 runs a network management application 100 (FIG. 2) that maintains an action list of identified problems and other conditions of network devices. The management application 100 can automatically detect when a condition has been resolved, in which case the condition is automatically removed from the action list. As a result, the action list maintains only conditions that currently exist, which provides a manageable list that a network administrator can quickly look through. A further advantage is that the action list does not need to be manually updated continually.

In addition, the management application 100 maintains a description database 116 to identify information associated with a condition. Using the description database, the application can identify the status of a particular condition and determine the appropriate tasks to perform to resolve a particular condition.

Referring to FIG. 2, a network message passed over the network 8 and addressed to the management application 100 is received by a network interface 118 (including a network interface controller and its associated firmware) through the network connector 120 of the management console system 26 . The message is passed to a network protocol layer 114 (such as a TCP/IP layer), which converts the network message to a format understood by the operating system 112 and the network management application 100 . The description database 116 and action list 117 are stored on a storage device in the management console system 26 . In addition, the action list 117 is displayable on a computer display 102 through a video device driver 110 and video interface 108 .

Referring to FIG. 3, to perform an automated network maintenance process, the management application 100 at step 700 first creates the description database 116 (including tables shown in FIGS. 4 and 5 ). The description database 116 stores the types of problems or conditions that are recognizable by the management application 100 , information to be accessed and processed to determine the status of a condition, and tasks to be performed by a user to resolve the condition. The description database 116 can be easily updated by a network administrator to add new types of problems and conditions that the management application 100 can handle.

Next, the management application at step 702 waits for receipt of an event, which can be either a network device message or a timeout event. The network message can include a notification (in the form of a trap, for example) that a problem or other condition has occurred. The message identifies the particular condition or conditions of the sending device. A periodic timeout event can also be generated in the management application so that it can periodically poll the network devices for problems and other conditions.

The management application at step 704 then accesses the description database 116 to determine the types of information to request. If a specific network device trap is received, then the management application accesses the description database 116 to determine the information associated with the trap condition to request from the sending network device.

If the event is a timeout, then items identified in the description database 116 as requiring periodic updates are addressed. Query messages are sent to the network devices to request the required information. By using the polling feature, the management application 100 can identify when a condition has been resolved so that information associated with that condition can be removed from the action list 117 .

Next, at step 706 , the management application transmits requests to the appropriate network device or devices to request information relating to the relevant problems or conditions. When the requested information is received from the network device or devices, the management application at step 708 checks the information. Next, at step 710 , the action list 117 is updated, by either adding entries (if new problems or conditions are found) or deleting entries (if the problems or conditions have been resolved).

Referring to FIGS. 4 and 5, the description database 116 includes two tables. The first table is the ACTINFO table, which lists action numbers (in column 300 ) and associated descriptions (in column 312 ). For example, action number 5000 corresponds to a Replace Processor action; action number 10004 corresponds to a Check System Temperature action; action number 11001 corresponds to a Degraded Drives action; and so forth. Other supported actions include threshold levels (e.g., fan speed exceeds a predetermined rate); utilization levels (e.g., CPU utilization 80%); and software version control, in which the management application monitors software versions on network devices, reports out of date software on the action list, and informs the user that a software upgrade is available or that a software upgrade must be performed to prevent a critical bug.

The ACTINFO table also includes an Enabled column 302 to indicate whether the particular action is enabled or disabled (Y for enabled and N for disabled). If an action is disabled, then that particular action is not acted upon by the management application 100 . An Action Type column 304 categorizes the fault type of the action (e.g., a mass storage fault, a system board fault, network interface card fault, a software version control fault, etc.).

An Update Type column 306 indicates the type of updates requested for the particular action—whether updates are timed (periodic polling) or performed in response to a trap from a network device. If the latter, then the management application 100 updates the action list 117 only when it receives a trap from a network device and does not periodically issue queries for the particular action. A Severity column 308 indicates the severity of the particular action, with the value 1 indicating the most severe condition and higher values indicating less severe conditions. A Bitmap ID column 310 identifies a graphical user interface (GUI) element (e.g., an icon) associated with an action that is displayed. Thus, the Replace Processor action can be associated with a specific icon displayed by the computer to the user.

In FIG. 5, an ACT_PROC table includes an action number column 400 listing the same action numbers as in the ACTINFO table in FIG. 4 . In addition, the ACT_PROC table includes an Item Name column 404 , which lists variables, (e.g., Management Information Base or MIB variables according to the SNMP or Simple Network Management Protocol), which are checked by the management application 100 to determine the status of the particular action. A Data Source column 406 specifies the particular source of the action, e.g., an SNMP source or other protocol source. A Check Type column 408 indicates the type of checking required of the condition listed in column 404 for a particular action. For example, a value of 1 indicates an “index scan” while a value of 2 indicates a “full scan”. A full scan checks all drives and produces a true result if any combination of the devices contains the conditions to be checked. Thus, for example, if an action is associated with three conditions and all three must be true (AND operation), then the full scan produces a true result if condition 1 is found on device X, condition 2 is found on device Y, and condition 3 is found on device Z, where X, Y, and Z can be the same or different devices.

An index scan, on the other hand, requires that the conditions to be checked must all be located on one device. In the example above, conditions 1, 2, and 3 must all be on one device for the index scan to be true.

A Comp Type column 410 has a number of different values, e.g., 10, 11, 12, 20, 21, 22, or 23, to indicate the type of comparison to be performed on the variables listed in column 404 . The different Comp Type values and what they represent are listed below in Table 1.

The comparison is performed between the variable in column 404 and the data field in column 412 . For example, if the Comp Type value is 10, then the management application 100 determines if the particular variable contains a number equal to the corresponding value in column 412 . As another example, a Comp Type Number of 21 would cause the management application to determine if the particular variable contains a string greater than the corresponding specified value. A Comp Type Number of 23 would cause the application to determine if a specified value is contained in the string in the variable.

A Not column 414 specifies whether the result of the comparison should be inverted; a value of 0 indicates no inversion while a value of 1 indicates inversion. An Operator column 416 indicates the type of operation to be performed with another variable associated with the same action number. For example, for action number 11000 , three variables are specified, including cpqDaPhyDrvStatus, cpqScsiPhyDrvStatus, and cpqDaSpareCondition. The value in the Def Count column 402 indicates the sequence of the three variables associated with an action (e.g., 1, 2, 3). A value of 2 in the Operator column 416 indicates that an OR operation is performed between the variable in the corresponding row and the variable in the next row associated with the same action. A value of 1 would indicate an AND operation and a value of 0 indicates a NOP or no operation.

Thus, the ACT_PROC table specifies the relevant parameters associated with an action and how the parameters are to be processed to determine the status of a condition.

Referring to FIG. 6, an Action List screen 500 displays information from the action list 117 . The screen 500 shows conditions associated with network devices, which are listed in a Device List window 502 . Exemplary network devices are identified as Accounting, Human 13 Factors, Human_Resources, Marketing, Sales, Dave_Smith, Kevin, and Mike. In this example, Dave_Smith, Kevin, and Mike are desktop units while Accounting, Human_Factors, Human_Resources, Marketing and Sales are servers.

There are two different ways of displaying the action list screen 500 , which are to display by action or to display by server (as shown by 504 ). The action list screen provides a convenient means of displaying information associated with network device conditions to a network administrator. If a condition is resolved, the corresponding item is removed from the action list. Each action has a priority, as indicated by the value in the Severity column 308 in FIG. 4, and actions with higher priorities are displayed toward the top of the list.

Referring to FIG. 7, an Action Detail screen 506 provides specific help to the user for each action. The purpose of this screen is to tell the user exactly what happened, and the steps that must be performed to resolve the problem. The action details include a description of the problem, specific details about the problem, and a list of steps to correct the problem. Double clicking on an action in the Action List screen 500 opens the Action Detail screen.

FIG. 8 shows an Action List Log screen 508 , which contains a complete history of the action list. As items are added or removed from the list, they are recorded in the log. As actions come and go, a user who is not constantly watching the screen may miss an important event. The user can conveniently refer to the log to determine events that have occurred. For example, if the user sets a threshold on CPU utilization for 85%, the CPU utilization action will be entered into the log as the utilization varies.

The conditions are divided according to three data types: action data, status data, and utilization data. Action data refers to an action that needs to be taken by the administrator to correct a system fault or degraded condition. Status data refers to the status of a system component. Utilization data displays performance or utilization information. In addition, as noted above, the conditions are also grouped according to fault types: rapid recovery faults, mass storage faults, system board faults, network interface card faults, and software version control faults. Table 2 (in FIGS. 9A and 9B) lists exemplary conditions by data type and fault type.

Referring to FIG. 10, the physical components of the management system 26 are illustrated. The system 26 includes a central processing unit (CPU) 200 connected by a CPU-PCI bridge 202 to a Peripheral Component Interconnect (PCI) bus 206 . A main memory 204 is connected to the CPU 200 and CPU-PCI bridge 202 . A mass storage device 208 , in the form of hard disk drives, for example, is connected to a SCSI controller 210 , which is in turn connected to the PCI bus 206 . A network controller card 212 , which is part of the network interface 102 or 114 described in FIG. 2, is also connected to the PCI bus 206 . A video controller 216 controls signals transmitted between the PCI bus 206 and a video display 214 .

An expansion bus 220 , such as the Extended Industry Standard Architecture (EISA) or the Industry Standard Architecture (ISA) bus, is connected to the PCI bus 206 through a PCI-expansion bus bridge 218 . The expansion bus 220 is connected to an input/output (I/O) controller 222 , which provides interface ports to a keyboard 224 , a pointer device 226 (such as a mouse), and a parallel port 228 . The I/O controller 222 also controls access to a non-volatile random access memory (NVRAM) 230 , which can be implemented with a flash memory or an EEPROM. The NVRAM is used to store the system BIOS for performing the power up sequence in the computer system 26 . Expansion slots 232 are connected to the expansion bus 220 to provide further expansion capabilities.

Other embodiments are within the scope of the following claims. For example, a modified version of the management application can be loaded on network devices other than the management console system 26 . In this alternative network system, the local management application in each network device can obtain and process the information as indicated in a locally loaded description database and send that information to the management console system in place of a trap message.