Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring
Reexamination Certificate
2001-07-02
2003-03-25
Meky, Moustafa M. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network monitoring
C709S203000
Reexamination Certificate
active
06539428
ABSTRACT:
FIELD OF INVENTION
The present invention generally relates to management platforms used to manage multiple customer networks and specifically, to processes, apparatus, and systems used to construct management platforms consistent with Simple Network Management Protocol (“SNMP”) to manage multiple customer networks.
BACKGROUND
Existing network management tools, such as Hewlett Packard's Open View Network Node Manager (“HP's NNM”), utilize graphical displays of network components and generally utilize color to relay information. These systems are generally used to manage and control networks, in which they generally provide notification of the status of network elements, particularly, failed elements. Networks are generally comprised of computer communications equipment, including, but not limited to, routers, switches hubs, and servers. HP's NNM can be viewed as being representative of the architecture and approach used by current commercial network management tools and, thus, is used herein to explain some of the problems with existing approaches.
These existing network management tools have a number of problems. Specifically, the displays are not helpful. Since color (shown as varying grey shades in
FIGS. 1 and 2
) is used to relay information, alarms can be hidden by an inappropriate color change threshold. In particular, as shown in
FIGS. 1 and 2
, HP's NNM maps use shapes that represent collections or managed objects. As shown in
FIGS. 1 and 2
, each object can be ‘exploded’ by opening the object until the lowest level is reached. Each aggregate object can have only one (1) of six (6) colors to represent the number of elements grouped together in that aggregate object that are in alarm condition, the color of the aggregate object being determined on a fractional basis Consequently, in certain circumstances, HP's NNM maps fail to communicate the occurrence of an alarm, as the presentation mechanism fails to relay the information to the user of the system in a way that makes the new failure apparent. For example, it may require the user to open additional windows, which, at a certain point, becomes impractical. At the aggregate object layer, as shown in
FIGS. 1 and 2
, the overall color of the aggregate object may not actually change color, even though individual elements of a specific aggregate object may fail.
Specifically,
FIG. 1
is a typical view of an application of HP NNM, as it appears on an engineer's monitor, with one alarm and
FIG. 2
is a typical view of an application of HP NNM, as it appears on a computer monitor, with multiple alarms. It is difficult to track the number of alarms in both
FIGS. 1 and 2
, especially in FIG.
2
. The upper let-hand sub-window, which is labeled “IP Internet,” has not changed colors (or grey shades) in between
FIG. 1 and 2
, which illustrates how changes can be hidden. The color level did not change with the additional alarm, due to the number of objects represented below the “IP Internet” symbol (shown in the sub-windows below) that were not in an alarm condition. Since these maps can be many levels deep, this problem can occur at any level. Additional sub-windows must be opened to avoid the averaging problem, which makes the overall display extremely crowded. Similarly, new alarms in existing systems can be hard to see or detect. Even if the change of status in an individual element does, in fact, change the color of the aggregate object, the change in color can be hard to detect on the display. For example, displays used in these modem systems are typically filled with numerous colored objects and the operator may not notice one more colored icon.
Also, information displayed by modem systems are difficult to relate or otherwise view. Particularly, the objects used in these modem systems are capable of relating only a limited amount of textual data. For instance, please refer to
FIGS. 3 and 4
.
FIG. 3
is a typical view of HP's NNM, as it appears on a computer monitor, showing external data capabilities.
FIG. 4
is a typical view of HP's NNM, as it appears on a computer monitor, showing internal data capabilities. A right click via a standard mouse on a symbol will bring up a menu of options, one of which is to view/modify the object description, but not the relative size of the comments section. This dialog box presents an opportunity to record some relevant external information about the symbol that is reporting the alarm, but, unfortunately, the opportunity is effectively wasted, since it is extremely difficult and time consuming to enter each field by hand and only one or two pieces of information can be shown at a time. For each device, several entries would be required and there may be 1000's to 100,000's of devices. Typically, the label for an object is generated by the HP's NNM application and is indicative of some data internal to HP's NNM and is not related to any external data such as city name or device name.
Furthermore, applications using existing systems are difficult to administer, as the preferred tools are complex and typically require specialized training just to operate the tool. Moreover, scalability is questionable and expensive, as there is a limit to the size of network that HP's NNM can manage, and even for small networks (<500 sites) the hardware and software licenses are expensive. Finally, modem systems are slow and limited in the total number sites that can be reviewed. For instance, actual embodiments of NNM has not been shown to work reliably for more than 500 sites. Actual embodiments of HP's NNM took from fifteen (15) minutes to hours to display information about failed devices and stopped functionally about once a week.
Existing designs and procedures have other problems as well.
SUMMARY
Preferred embodiments pertain to an apparatus and related methods and systems that generally manage networks. Note that preferred methods are preferably performed by the preferred apparatus and systems and are discussed in reference to the preferred apparatus and systems.
Preferred embodiments generally implements the following procedure to operate preferred systems: (i) the SNMP Poll application loads from a database a list of interfaces to be monitored; (ii) the SNMP Poll sends out SNMP and tracks responses to determine which interfaces are reachable and which are not; (iii) if the SNMP Poll fails to reach an interface two (2) consecutive times, a message is sent to server; (iv) the server checks the interface for a total of ten (10) more times and, if the interface replies six (6) or fewer times to the ten (10) requests, an alarm is generated, and, if the interface replies seven (7) or more times to the ten (10) requests, a message is sent back to the SNMP Poll and the interface is placed in the poll queue; (v) the server generates an alarm, if necessary, by associating information from the OSS database with the interface address; (vi) the server distributes the alarm by sending an alarm message to all attached display devices (e.g., a display server and client); (vii) a client can display the alarm information in a hierarchical tree structure; and (viii) the server monitors the interface to determine when the interface become reachable again and generates a clear message which is formatted and sent to the clients and the server then sends a message to the SNMP Poll to return the interface to the poll queue.
Preferred embodiments are used to manage a network by monitoring at least one interface of the network and are generally comprised of a poller, a server, a database, and a client applications module. The poller, server, database, and client applications module are in communication with each other. The poller is in communication with at least one interface of the network. The poller continuously checks at least one interface of the network by continuously sending out a poller query message to at least one interface of the network. The poller sends out the poller query messages to at least one interface in a regular, continu
Hunton & Williams
Meky Moustafa M.
Netsolve Incorporated
LandOfFree
Alarm server systems, apparatus, and processes does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Alarm server systems, apparatus, and processes, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Alarm server systems, apparatus, and processes will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3011542