This invention relates to the field of networks and network analysis, and in particular to a system that facilitates automated network data collection, analysis, and reporting of network configuration and status information.
The management of a communications network is a complex and time-consuming task, particularly as the size and capabilities of such networks continues to grow. Changes to the configuration of a network, or changes in traffic patterns across the network, often cause problems that are difficult to anticipate or diagnose. Often, such problems remain latent until their compound effect cause network disruptions or other anomalous behavior.
Analysis and diagnostic tools are available to facilitate the identification and correction of network problems before they cause major disruptions, but often the cost and overhead associated with routinely collecting the data and performing the analysis outweigh the perceived benefits, particularly while the network appears to be operating efficiently. However, without ongoing data collection and analysis, the isolation of the cause(s) of a network disruption, when the disruption occurs, can be very time consuming, and the subsequent diagnoses may often introduce further network disruptions.
An objective of this invention is to provide an automated network analysis system that requires little or no human interaction. A further objective of this invention is to provide an automated reporting system for alerting network managers of changes to the network configuration and/or performance. A further objective of this invention is to provide a network analysis and reporting system that is easy to configure and run on a regular basis.
These objectives, and others, are achieved by providing an automation engine that is configured to automatically run network data collection, analysis, and reporting tools. Each tool is designed or modified to enable the parameters required for operating the tool to be read from a settings file. The automation engine is configured to provide the appropriate settings file to each tool to perform a given set of tasks. Tasks can be performed on-demand, on predefined schedules, or upon detection of a triggering event, such as a notification that a device configuration has changed, as reported by many vendor-supplied component management systems.
The invention is explained in further detail, and by way of example, with reference to the accompanying drawings wherein:
Throughout the drawings, the same reference numerals indicate similar or corresponding features or functions. The drawings are included for illustrative purposes and are not intended to limit the scope of the invention.
The data collectors 110 include applications, or tools, that facilitate the collection of data related to the configuration and operation of the network. Included in this collection, for example, is a tool that collects network configuration data and creates a model of the network. The VNE (Virtual Network Environment) Server product from OPNET Technologies, Inc., Bethesda, Md., for example, provides an on-line integrated view of a network. The VNE Server collects network data from a variety of sources and merges the information to create a unified network representation that can subsequently be used for network planning, engineering, and operations. Sources of network data include, for example, routers and switches from Cisco Systems, Nortel, and others, as well as a variety of network “discovery” tools and protocols that facilitate the creation of complete topology views.
The data collectors 110 also include applications that facilitate the collection of performance data from the network. Conventional routers and switches, for example, typically include performance monitoring capabilities that can be queried from remote management systems, such as the aforementioned VNE Server.
The data analyzers 120 include applications that provide, for example: flow analysis, failure analysis, security analysis, network differences, network validation, and other analysis and/or diagnostic tools.
A network differences application, for example, compares the aforementioned network configuration data provided by the data collectors 110 at different times to identify any changes that have occurred. In accordance with this invention, the automation engine 150 is configured to allow a user to create a “task” that includes the collection of data by the data collectors 110 that determine the current network configuration, followed by the invocation of a network difference application 120 that compares the current network configuration with a prior network configuration. Also in accordance with this information, any differences that are determined may be reported to an appropriate party, via the report server 130. The report server 130 can be configured, for example, to report all changes, or to report select changes, or to report any change that is coincident with another effect reported by another analyzer 120, and so on.
In a preferred embodiment of this invention, a network differences application includes a process that determines whether the current network configuration conforms to a set of defined design rules, using, for example, a rules-based process that reports any configuration or network element that does not conform to a given set of user-defined rules.
The operations that need to be performed to accomplish each defined task is stored in a task database 170, and the particular parameters/settings for each of the applications 110-130 to effect the task are stored in setting files 160.
The automation engine 150 is also configured to effect “administrative” tasks that facilitate the proper flow of information among the applications. To facilitate the comparison of data collected at different times, for example, the automation engine 150 can be configured to assure the preservation of prior data before the invocation of an application 110, 120 that may overwrite the prior data, or the prior analysis of the data. For example, the automation engine 150 may guarantee uniqueness of data or analysis files by incorporating a date and time substring with the aforementioned file names. Alternatively, the automation engine 150 may change the name of a prior created file to “old” at the start of the collection of new information or the analysis of new information, and compare any newly created file from the data collection tool 110 or the data analysis tool 120 with this “old” file.
The automation engine 150 is also configured to effect “conditional” tasks, or conditional task sequences. For example, the automation engine 150 may be configured to invoke the data collection tool 110 that collects network configuration information, followed by the invocation of a network validation tool 120, followed by the generation of a report by the report server 130, if the network validation tool 120 identifies a configuration error.
Similarly, the automation engine 150 may be configured to invoke a data collection tool 110, and a network difference tool 120, and then selectively invoke another data collection 110 or analysis 120 tool, based on whether a difference in the network configuration is determined, to assess and report any performance degradations or anomalies that appear to be correlated to the detected network change. These and other conditional invocations of applications/tools by the automation engine 150 will be evident to one of ordinary skill in the art in view of this disclosure.
The automation engine 150 includes a user interface (not illustrated) that facilitates the definition and storage of individual tasks and sequences of tasks in the task database 170. These stored tasks can be invoked from the scheduler 170 on-demand, or the automation engine 150 can be configured to execute select tasks or sequences of tasks at particular times or at particular time intervals. In a preferred embodiment of the automation engine 150, the execution of a task or sequence of task is based on the occurrence of an event, and this event can be any combination of a user-induced event, a timed event, an anticipated event, an anomalous event, an alarm event, and so on.
To facilitate the use of the automation engine 150, the accessible applications/tools within the network management arsenal are preferably designed/modified to facilitate the selective invocation of each tool as the situation demands. Of particular note, the parameters/settings associated with each application/tool for inclusion within a given task are preferably stored for access by the automation tool 150 to facilitate the successful execution of each application within a given task, without human intervention.
Conventional task scheduling processing employ “scripts”, which are copies of the interactions required at an application's graphic user interface (GUI) to effect the task. The interactions required at the application's GUI are typically recorded in a script file as the user interacts with the application to perform a given task, then played-back as an input to the GUI to repeat this same set of interactions for subsequent repetitions of the task. For simple applications, such a mimicking of user interactions is sufficient, but complicated applications, such as those typically used for network data collection 110 and network analysis 120, a user's interaction with the GUI is rarely error-free, or straightforward, particularly if the application interacts with the GUI throughout the performance of a task. For example, a data analyzer 120 may ask for a destination file for storing its results only after it has analyzed sufficient data to produce these results, or a data collector 110 may ask for the identification of a target node from which to collect data only after searching the network to create an up-to-date network topology. As such, the capture of a set of inputs to a GUI that will be reliable for repeated tasks is often a difficult and time consuming process.
Alternatively, many simple applications allow for “command-line parameters”, wherein the parameters required to run the application for a given task are provided to the application as part of the command that initiates execution of the application.
Although the automation engine 150 may be configured to provide input-scripts or command-line parameters to each scheduled application 110, 120, 130, in a preferred embodiment of this invention, the automation engine 150 provides a select setting file 160 to each scheduled application, as illustrated in
With the switch 215 in the indicated position in
When the switch 215 is in the opposite position than indicated in
Also in a preferred embodiment, the state of the switch 215 of
Of particular note, the above described configuration of a network monitoring system in accordance with this invention allows for a partitioning of the responsibilities associated with managing a complex network. Technical personnel who are well versed in the particular aspects and characteristics of each application 110, 120, 130, for example, are provided an architecture within which to define, test, and debug defined tasks 170, and settings 160 for each application for each task to accomplish a given function, while network management personnel are provided the architecture to schedule and perform the tasks required to properly maintain the network, without being required to understand the idiosyncrasies of each tool or the interactions among tools.
The foregoing merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the invention and are thus within its spirit and scope. For example, although
In interpreting these claims, it should be understood that:
This application claims the benefit of U.S. Provisional Patent Application No. 60/497,093, filed Aug. 22, 2003.
Number | Date | Country | |
---|---|---|---|
60497093 | Aug 2003 | US |