Patent Application
20090168645
The present invention relates generally to communications networks, and more particularly to an automated network congestion and trouble locator.
In a managed communications network, once a network administrator is notified of a problem (usually a “symptom” of a problem, such as a user notifying the administrator that he/she cannot access a database or internet access is slow), he/she generally performs manual tasks to fix the problem. This may include manually configuring the network and/or specific devices within the network. In addition, there is no easy way to locate the source of a problem, such as congestion, in the network.
Accordingly, there is a need for an automated network congestion and trouble locator that can automatically locate problems (or symptoms of problems) in the network and identify the actual root cause of those problems or symptoms. Once identified, further action may be taken to eliminate or mitigate the problem(s).
In accordance with one embodiment, there is provided an automated network congestion and trouble locating method for use in a network. The method includes receiving an event notification from a device in a network, the event notification indicative of a problem in the network. A network flow information database storing network flow information about the network is queried and the queried network flow information is received. The received network flow information is processed and a congested link is identified in the network. In response to identifying the congested link, the method further includes examining the received network flow information and a previously determined topology mapping of the network and identifying a host causing the problem in the network.
In accordance with another embodiment of the present invention, there is provided a computer program embodied on a computer readable medium and operable to be executed by a processor within a processing system, the computer program comprising computer readable program code for performing the method described above.
In yet another embodiment, there is provided a processing system coupled to a network for detecting and correcting a problem in the network. The processing system includes a processor operable to: receive an event notification from a device in a network; the event notification indicative of a problem in the network; send a query to a network flow information database storing network flow information about the network; receive the queried network flow information; process the received network flow information and identifying a congested link in the network; and in response to identifying the congested link, examine the received network flow information and a previously determined topology mapping of the network and identifying a host causing the problem in the network.
Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.
For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which:
In this example, the network system 100 includes a data network 102, a network router/gateway 104, and public or other communications network 106. The networks 102 and 106 are interconnected via the router/gateway 104. Additional routers/gateways (or other devices providing a gateway function) and/or networks similar to the router/gateway 104 and the network 106 may be included with the network system 100, but are not shown for brevity. The devices in the system 100 are interconnected or coupled (communicatively) via various communications lines (wire or wireless) within the system 100.
The networks 102 and 106 may further include one or more local area networks (“LAN”), metropolitan area networks (“MAN”), wide area networks (“WAN”), including cluster or server area networks, all or portions of a global network such as the Internet, or any other communication system or systems at one or more locations, or combination of these. Further, the network 102, 106 (and system 100) may include various servers, routers, bridges, and other access and backbone devices. In one embodiment, the network 102 is a packet network that utilizes any suitable protocol or protocols, and in a specific embodiment, the network 102 (and most components connected thereto) operates in accordance with the Internet Protocol (IP) As will be appreciated, the concepts and teachings of the present invention are not limited to IP, but may be utilized in any data packet network that facilitates communication between components of the data network 102 (or within system 100), including Internet Protocol (“IP”) packets, frame relay frames, Asynchronous Transfer Mode (“ATM”) cells, or other data packet protocols, and which may be used with or on any L2 transport.
As will be appreciated, other components and networks may be included in the system 100, and
Coupled to the network 102, and which generally form a part of the network 102, are a plurality of endpoint devices or end devices 108 (communications devices). The endpoint devices 108 represent devices utilized by users or subscribers during communication sessions over/within the system 100. For example, the endpoint devices 108 may communicate with other endpoint devices 108, as well as other network devices 110 (such as servers and applications providing various functionality, e.g., engines, databases, data and service applications, business tools, etc.) in the network. In addition, the endpoint devices may include an input/output device having a microphone and speaker to capture and play audio information. Optionally, they may also include a camera and/or a display to capture and play video information. The endpoint devices 108 are able to communicate with each other (and/or other devices 110 connected to the networks 102 and 106) through the system 100.
Each of the endpoint devices 108 (or communication devices) may be constructed or configured from any suitable hardware, software, firmware, or combination thereof for transmitting or receiving information over a network. As an example, the endpoint devices 108 could represent telephones, videophones, computers, personal digital assistants, remote storage systems, servers, and the like, etc.
The network 102 includes a plurality of network devices 110, which may include devices such as call and applications servers, firewalls, routers, hubs, switches, network management devices, and the like (providing various functionality within the network 102). These network devices 110 generally will include one or more controllers or processors, memory, logic circuitry, and interfacing circuitry to interface within the network 102, and software and/or firmware.
As will be appreciated, the network 102 may also be referred to or understood as a separately managed network.
The endpoint devices 108 are coupled to the network 102. In this document, the term “couple” and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with one another. The gateway 104 facilitates communication between the networks 102 and 106.
Now referring to
In the illustrative embodiment shown in
The IP flow data collector 202 is configured to obtain information about data and traffic flow in the network 102. This flow information may include source and destination addresses, protocol and application information, numbers of bytes, packets and flows. Additional information, such as direction of traffic flow (which nodes) and traffic variances by time, may be determined from the flow information. Such information is commonly known to those skilled in the art under the name or designation Internet Protocol Flow Information export (IPFIX) information, also known as IP Flow, and/or NETFLOW, hereinafter generically referred to as “network flow information” or “flow information” and the IP flow data collector may be referred to as a “network flow data collector.”
Network flow information is retrieved or obtained from one or more of the network devices 110. In
The network flow analyzer 204 receives the network flow information from the IP flow data collector 202 and performs various analyses on the data. The analyzer 204 may provide capacity planning, troubleshooting and other traffic analysis functions (one device suitable for use as the network flow analyzer is a device provided by NetQoS, Inc. under the name “NetQoS ReporterAnalyzer”).
The IP flow data collector 202 may include any suitable hardware, software, firmware, or combination thereof for performing the desired function of obtaining and collecting network flow information. It may also perform some analysis of the network flow information. More than one may be provided. It will be understood that the data collector 202 may a physically separate device or may be logically shown (it may form part of the network device(s) 110 from which the data is collected or obtained).
In alternative embodiments, the analyzer 204 and data collector 202 may be combined into a single device, and/or the RCA (described hereinafter) 200, data collector 204 and the analyzer 204 may be combined into a single device. Optionally, the analyzer 204 may be omitted and the RCA processor 200 may obtain network flow information from the data collector 202. Other configurations are contemplated.
The RCA 200 generally includes one or more controllers or processors, memory, logic circuitry, and interfacing circuitry to interface within the network 102, and software operable for performing the functions described herein. In one embodiment, the RCA 200 includes one or more input/output devices, such as a keyboard, mouse, video display, etc. Thus, the RCA 20 may be a PC, server device or network appliance.
Network flow information (e.g, IPFIX data) has been historically used to analyze the network from a capacity planning perspective or provide basic information on data flows (e.g., amount of data per type of protocols/applications/services, by time periods such as hours, days, etc.). This long-term trending and statistical information would help identify where potential congestion might arise over time in an area of the network. As a result, a system administrator would usually respond by planning (and then adding) new hardware to preempt anticipated congestion.
One aspect of the present invention applies root cause analysis logic to network flow information (e.g. IPFIX data) to analyze traffic on a network, and in the event of trouble (e.g., congestion, failures, security issues, etc.) locate the problem traffic and the offending endpoint or host (or node or user) via data-mining (of the network flow information) and network topology/discovery. Based on the analysis and determination, action(s) are initiated and taken correct or solve the problem. Such action may range from taking no action at all up to blocking all traffic from a given host (or coupled pair of hosts) or subnet or traffic type (e.g., web, FTP, mail, etc.).
The application of corrective action may also be dependent on the policies, procedures and rules configured for the network. For instance, some hosts may be allowed to overload the network under certain conditions, but others may not. For example, a large video file transfer from an important person within the network (such as a CEO) may be permitted even if it is disrupting a group of users running a database application.
The automated network congestion and trouble location method and apparatus of the present invention which provides a network and systems management tool also automates certain tasks normally done manually. Data is gathered from multiple sources and combined with a self-learned network topology to locate and isolate network trouble. Problem-resolution logic is provided for determining that some detected problems/issues/events (i.e., trouble/event notifications) are caused by other problems/issues/events and automatically finding the underlying root-cause problem/issue/event. A solution may be automatically applied in many instances to resolve or correct it.
The following provides a high-level description of a method in accordance with one embodiment of the present invention.
One or more event notifications are received from one or more devices in the network. It is typical a network problem may generate multiple event notifications. Data about the event enters the system. Related events are correlated and only truly disparate events are identified as problems. RCA logic is applied to each event grouping to determine the root cause. A solution is identified to correct or mitigate the root event and the solution is applied.
When a problem (or symptom of a problem) is detected, an event notification is generated. Event notifications may take any form, including an SNMP trap, query, or other notification generated from a source within the network. Event notifications, depending on type, may be triggered when some threshold is reached in the network. Thresholds in the network (or network device(s)) may be set by the system administrator. The event notifications may also be as simple as a message that a given device is having difficulty with a service or communications.
At various times, the RCA 200 scans the network 102 discovering network devices/elements/links and creates a mapping of the network topology. This mapping is cross-referenced to the network flow information (e.g., IPFIX) and may be displayed by the RCA 200. A graphical user interface (GUI) (not shown) may be provided to display the network topology mapping.
It will be understood that one or more network devices 110 continuously report network flow information (e.g., IPFIX data) to the data collector 202. The data collector 202 captures and stores this information in a database or other memory.
Upon receipt of the event notification(s) and correlation/filtering of the events, the RCA queries the data collector 202 for network flow information about the network 102. The RCA 200 combines the returned network flow information with the previously mapped network topology with the correlated events detections and determines the problem link and/or source/destination device. Thus, the network flow information from the data collector 202 is taken into account with the previously gathered topology data to identify the culprit, its impact, and its location in the network. The RCA 200 additionally is operable for determining the impact(s) of congestion based on the network configuration. Further, the offending host(s) may be visually displayed in conjunction with the topology mapping.
Based on this information and the configuration of the network 102, a solution to the problem may be automatically applied by modifying the network configuration.
The present invention solves the problems for intentional bad hosts (e.g., a hacker on the net) and for unintentional bad hosts (e.g., file sharing over a financial wire by people not meaning to cause any problems) by automatically identifying the offending host(s), locating the offending hosts in the network topology, allowing the system administrator to see the offending host(s) on a GUI showing their placement in the network alongside the impacts it/they are having, and optionally automatically taking action to correct or mitigate the problem.
The RCA 200 and associated method is capable of detecting the congestion/problem in the network 102 and locating the host(s) responsible for the congestion/problem. In the event there is more than one offending host, separate hosts and their impacts and the relative severity of each may be identified. For example, two groups of people may be sharing files with others but one may be using more bandwidth then the other or one may be taking bandwidth over a more critical or smaller pipe.
In conventional systems, once a network administrator is notified of a problem, he/she has to fix it, typically involving manual tasks which can take time. Sometimes, these tasks are wasted or unfruitful since network conditions may change quickly such that the problem may not be present before the administrator has time to solve it (e.g., in case of a file-sharing problem, the copying may be completed before the administrator has time discover it). Even as little as a minute or so can be disastrous for some networks such as those carrying phone calls as people will generally hang up after only a few seconds of poor voice quality.
The present invention not only automates the process for the system administrator by pinpointing the problem in the network topology allowing for immediate “identification” of the culprit and “push-button” problem resolution, but can automatically choose the resolution and apply it without involving the administrator (i.e., for devices managed by an enterprise policy manager). A pop-up or email may be used to notify the administrator the problem occurred and was resolved. This may also include sending out a text message to a pager or other hand-held device carried by the administrator.
Now referring to
The network 102 is scanned by the RCA 200 and a topology mapping of the network 102 is generated (step 302). Once initially generated, the topology mapping is usually updated periodically. This may be done using a suitable algorithm or method for discovery of devices in a network, as is generally known to those skilled in the art.
One or more event notifications (or fault data) are generated within the network 102 (step 304) in response to a problem (or symptoms of a problem) occurring in the network 102. The event notifications indicate that a problem (or symptom) is detected in the network, which alerts the RCA processor 200 (or other device in the network). The RCA processor 200 receives these event notification(s) directly from a source network device or via other devices. Examples of common event notifications may include SNMP traps and remote Syslog events, as well as event notifications from the network flow analyzer 204 (e.g., high network traffic on link) or from one of the network devices 110 (such as an application server). SNMP traps are generic and include those related to cold start, warm start, link up, link down, etc. or they may be enterprise specific using enterprise MIBs to generate traps for any desired event notification. Specific examples may include bandwidth usage exceeding a threshold and application server latency or response time outs, though any event notifications may be utilized as desired.
Upon receipt of event notification(s), the RCA processor 200 engages in, what is referred to as “event reduction,” to correlate related event notification(s) (step 308). Related events are grouped together and these dependent events are narrowed down or resolved to a single or few primary events. For example, if a given problem arises in the network 102, it is possible that ten or fifteen (or even hundreds) of event notifications may be generated and received as result. Instead of resolving each event notification individually, the RCA processor 200 correlates/relates these events and identifies them as being originated due to a main or single problem. This correlation is based on trace routing or path tracing. Path tracing is defined as determining the path through the network for traffic from one device to another. Basically, a list of devices is generated linking the starting point with the end point. There are two types of path traces (and hybrid combinations of these two). A live path trace scans through the devices looking at their registries/MIB data or other information to determine the next device in the path until the end point is reached. A database path trace looks at the topology stored in the system to determine the logical rout the path would likely take. The latter takes much less time to perform. In other words, the RCA processor 200 includes problem-resolution logic for determining that some event notifications are a by-product of either a single event or other event notifications (perhaps from more important events/notifications or issues). In one embodiment, the correlation uses path tracing.
Once narrowed down to a detected bona-fide problem, the RCA 200 processor queries the data collector 202 for stored network flow information (e.g., IPFIX data) (step 310), and the relevant network flow information is transmitted back to the RCA processor 200 (step 312). This network flow information provides a snapshot of the network traffic for a given time period (usually for a time period before and after when the event notification(s) were generated).
The previously generated network topology mapping is combined with the received network flow information to identify the problem traffic within the network 102. One or more congested links in the network 102 are identified (step 314). Next, the network flow information, such as type of traffic, source and destination addresses, etc., corresponding to the traffic flowing through the identified link(s) is examined (step 316).
This information is processed by the RCA processor 200, and the problem, or the host(s) causing the problem, is identified (step 318). Thus, the overall process combines event notification information, network topology mapping information, and network flow information (e.g., IPFIX data) to determine and identify a problem in the network 102 and the identity of a host (or hosts) causing the problem. In the event the system correlated a substantial number of events into more than one root event, then the process would be done for each root event.
Based on this information, the RCA processor 200 may output information (such as on a display of the RCA processor 200) identifying the problematic host (e.g., user, device, etc.) (step 320) or automatically applying a solution or taking some corrective action (step 322), or doing both. Such identification may include providing a visual display of the network topology (or relevant portion thereof) and showing the problem host thereon. Automatically applying the solution generally includes initiating an activity or action to be performed by one or more of the network devices 110 (or endpoints 108). These solutions/actions may include, but are not limited to, restricting/blocking all traffic to/from a host(s), restricting/blocking all traffic between a pair (or more) of hosts, restricting/blocking traffic of a certain type, modifying policies on routers to re-route traffic around congestion, restricting/blocking access to a user(s) on a device(s), changing priorities of protocols in the network, lowering bandwidth for the host, modifying network parameters, restricting operation of the host within the network, etc. Upon automatic application, the administrator may receive an email or pop-up message informing that a problem occurred and a solution was applied (i.e., the problem was resolved). Optionally, a text message may be sent to a pager or other hand-held device of the administrator.
If step 322 is performed, the administrator may manually input instructions to the RCA processor 200 (or other device) to take corrective action or the RCA processor may automatically apply. Alternatively, the step 324 may simply be performed.
Optionally, once the problem is identified, the RCA processor 200 may determine a possible resolution or action that may be taken. If only a single action is possible, steps 320 and/or 322 are taken, as described above. If multiple solution actions are possible, the RCA logic may select one solution or multiple solutions, and apply them, as desired. Optionally, the administrator may be notified of the possible choices and allow him/her to choose one or more (or opt to do something else and/or take some manual action).
The present method and apparatus is operable to identify intentional hackers and unintentional misuse by authorized users, detect congestion automatically, determine impact(s) of congestion on the network configuration, and visualize offending host(s) on topology mapping.
In some embodiments, the functions of some or all of the automated network congestion and trouble locating method is implemented or supported by a computer program that is formed from computer readable program code and that is embodied in a computer readable medium. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer readable medium” includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory.
It may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation. The term “or” is inclusive, meaning and/or. The phrases “associated with” and “associated therewith,” as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like.
While this disclosure has described certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure, as defined by the following claims.
This application claims priority under 35 USC 119(e) to U.S. provisional Application Ser. No. 60/784,871 filed on Mar. 22, 2006, and which is incorporated herein by reference.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2006/025859 | 6/30/2006 | WO | 00 | 9/16/2008 |
| Number | Date | Country | |
|---|---|---|---|
| 60784871 | Mar 2006 | US |
