Embodiments are directed, in general, to identifying network nodes and interfaces in a telecommunications network and, more specifically, to automatically detecting a network topology.
Network topology provides a mapping of the nodes and interconnection in a communications network. Knowledge of a network's topology is necessary to monitor the operation of the network and to identify and resolve any problems that arise in the network. Typically, network topology has been manually created based upon knowledge of which network elements have been put into service. However, tracking the active network nodes and interconnections can be difficult as the network gets larger, more complex and geographically diverse. Network operators need a complete view of the current state and composition of their network. Existing network topology tracking may not reflect how the user perceives the network. Large amounts of time and effort are required to manually create and update a network topology.
In telecommunications networks, new nodes and links between nodes are added often as the network grows or is updated. For example, nodes may be added to increase the network coverage area and number of subscribers supported. New links may be added between these nodes. Service providers and network operators typically monitor their network to evaluate operating conditions and to identify and correct network problems. A monitoring system used for this purpose needs to know the up-to-date network topology under observation, including the new monitored nodes and links, in order to provide correct and accurate measurements and in addition to correlate the measurements to nodes and links (e.g. correlate the alarms to the network entity affected by such event).
The network topology used by the network monitoring system may be updated manually by entering each new node and all associated new interconnections to other nodes. However, manual configuration of the network topology is not desired because it is labor intensive and error prone. Additionally, such manual topology updates typically are delayed some period of time after actual physical updating of the network. In the time between a network update and a manual topology update, the network monitoring system will not be able to properly analyze network protocols or operation.
Embodiments of the network topology monitoring methods and systems disclosed herein provide a complete view of the current state and composition of the network. The network topology is generated automatically by a network monitoring system thereby eliminating the need to manually adjust the topology as the network evolves. The network operator may also correct, modify, or force-detect network topology.
The monitoring system uses a predefined topology data model that inter-relates the network components in a manner that allows for detection and updating of network nodes, ports, physical links, logical links, and SCTP associations. Network components can be treated individually or in groups to support user applications and analysis.
Embodiments of the topology detection system use a generic data model framework that can be used with an IP-based network protocol. Typically, multiple monitoring probes in the network will see traffic from the same network elements . The topology information from each probe must be mediated to identify overlapping detections and to create one view of the network topology. In one embodiment, monitoring probes first identify network nodes, then identify links between the nodes, and finally identify SCTP associations. The monitoring probes detect data in captured PDUs and populate the topology data model using this data.
Having thus described the invention in general terms, reference will now be made to the accompanying drawings, wherein:
The invention now will be described more fully hereinafter with reference to the accompanying drawings. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. One skilled in the art may be able to use the various embodiments of the invention.
The monitoring system may be located in one location, such as a server or equipment rack in which probes 110, 111 run on separate blades. Alternatively, probes 110 and 111 may be located near one or more of nodes 101-104 and remote from monitoring system server/controller 112. Probes 110, 111 and monitoring system server/controller 112 comprise one or more processors running one or more software applications.
The monitoring probes 110, 111 and monitoring system server 112 may incorporate protocol analyzer, session analyzer, and/or traffic analyzer functionality that provides OSI (Open Systems Interconnection) layer 2 to layer 7 troubleshooting by characterizing IP traffic by links, nodes, applications, and/or servers on the network. Such functionality is provided, for example, by the GeoProbe G10 platform, including the Iris Analyzer Toolset applications and SpIprobes, from Tektronix Incorporated. It will be understood that the monitoring system illustrated in
The monitoring probes 110, 111 may be coupled to network interfaces via packet capture devices, such as high-speed, high-density probes that are optimized to handle high bandwidth IP traffic. The monitoring system passively captures message traffic from the interfaces without interrupting the network's operation. The monitoring system may capture and correlate the packets associated with specific data sessions on network interfaces. The related packets can be combined into a record for a particular flow, session or call on the network.
In an alternative embodiment, the monitoring system may be an active component, such as a software agent, that resides on one or more of nodes 101-104, for example, and that captures data packets passing into or out of the node.
Knowledge of a monitored network's topology is a core part of any network monitoring solution. The ultimate goal for any passive monitoring or probing system is to have all network topology auto-detected, including all network nodes, logical and physical links, SCTP associations, radio cells, and the like. Such a feature would significantly reduce installation and maintenance costs and would allow a network to respond to network evolution without requiring intervention from a network operator.
One embodiment of a topology detection schemas fulfills the following requirements:
Servers, Physical Links, Logical Links, and Stream Control Transmission Protocol (SCTP) associations;
Existing data models and processing models suffer from one or more of the following shortcomings:
The unified data and processing model targeted disclosed herein completely fulfills the requirements set forth above and overcomes the shortcomings of existing solutions. Use of a topology detection system such as the one described herein provides significant operational expenditure (OpEx) savings as well as a superior quality of experience for both network-monitoring vendors and network operators.
DOMAIN element 201 may be used to represent different segments of a monitored network, such as regions/subregions or markets/submarkets. Using the defined domains, users may separate different parts of the network for independent analysis or review. For example, DOMAIN elements may be used to separately identify the core network in one area versus a data center in a different area. DOMAINS may also be used to prevent “collisions” between monitored objects in the case where IP address pools are reused in different segments of the network. Every monitoring probe may be assigned to a DOMAIN. The topology information between domains may be independent. For example, if a probe in DOMAIN A detects a node with IP address “IP1,” then the same “IP1” address in DOMAIN B actually refers to a different node.
PROBE element 202 is equivalent to one physical monitoring probe. In one embodiment, the PROBE element 202 in the data model has the properties and attributes illustrated in Table 1.
Each PROBE element is related to one or more PHYSICAL PORT elements (203). Transiently through the PHYSICAL PORT elements (203), each PROBE element is related to one or more PHYSICAL LINKS (204).
The PROBE elements 202 are auto-detected when a new probe makes contact with the monitoring system server. The new probe sends all the properties required to complete Table 1 to the monitoring system server for creation of new PROBE element in the topology. In particular, the probe sends its type, name, and primary IP addresses.
The PHYSICAL PORT element 203 is equivalent to one monitored port on a probe interface card. A typical probe interface card has 4 or 8 ports, but there may be more ports on a probe interface card in the future. In one embodiment, the PHYSICAL PORT element 203 in the data model has the properties and attributes illustrated in Table 2.
Each PHYSICAL PORT element 203 is related to exactly one PROBE element 202. Each PHYSICAL PORT element 203 is a member of one PHYSICAL LINK element 204. In one embodiment, PHYSICAL PORT elements 203 are used by the monitoring system's traffic analyzer and/or protocol analyzer as key performance indicator (KPI) dimensions for port monitoring.
PHYSICAL PORTs are auto-detected when a new probe makes contact with the monitoring system server. The probe sends a list of all known physical ports along with all properties. The monitoring system server assigns unique port IDs to each physical port. Because the direction of the port is very difficult to detect, the direction and mapping to PHYSICAL LINKs may be left as a manual configuration step. Accordingly, the UNKNOWN value may be used as a default for the direction on new ports. The monitoring probes may treat ports with the direction set to UNKNOWN as if the ports were RX/TX ports.
The PHYSICAL LINK element 204 is a bi-directional Ethernet link, consisting of one or more PHYSICAL PORTs. A PHYSICAL LINK is distinct from a LOGICAL LINK, which is further described below. In one embodiment, the PHYSICAL LINK element 204 in the data model has the properties and attributes illustrated in Table 3.
Each PHYSICAL LINK element 204 is related to exactly one PROBE element 202. Each PHYSICAL LINK element 204 is related to one or more PHYSICAL PORT elements 203. For example, PHYSICAL LINK may have one PORT in case of one bi-directional tap (SPAN), or four PORTs in case of uni-directional load-shared taps. PHYSCAL LINKs may further be broken down by defining VLANs, so that one PHYSICAL LINK would correspond to one or more Ethernet-level virtual links. In one embodiment, PHYSICAL LINK elements 204 are used by the monitoring system's traffic analyzer and/or protocol analyzer as key performance indicator (KPI) dimensions for monitored element selection.
In one embodiment, the PHYSCIAL LINKs are not auto-detected because the decomposition of ports into physical links can be a very difficult problem to solve in general. Adding PHYSICAL LINK elements 204 and mapping ports to the PHYSICAL LINKs 204 may be left as a manual configuration step. Such configuration would be a one-time step that would need to be adjusted in cases when physical ports wiring changes.
The PHYSICAL LINK GROUP element 205 is used to group together one or more PHYSICAL LINK elements 204. The PHYSICAL LINK GROUP elements 205 are used by the user interface (UI) applications. For example, the PHYSICAL LINK GROUP element 205 may be used by a traffic analyzer to display KPIs for a selected set (or group) of links versus displaying one link at a time. PHYSICAL LINK GROUP elements 205 may be part of the topology information, but they are typically user interface artifacts, so the monitoring probes should not be concerned with PHYSICAL LINK GROUPs 205. In one embodiment, the PHYSICAL LINK GROUP element 205 in the data model has the properties and attributes illustrated in Table 4.
One or more PHYSICAL LINK elements 204 belong to a PHYSICAL LINK GROUP 205. A given link may be a member of multiple groups. In one embodiment, the PHYSICAL LINK GROUP elements 205 are provisioned by the user and are not auto-detected.
NETWORK NODE element 206 represents one of various active network elements with IP addresses, such as a server, Serving GPRS Support Node (SGSN), Gateway GPRS Support Node (GGSN), MME (Mobility Management Entitiy), eNodeB (enhanced NodeB), Authentication, Authorization and Accounting (AAA) Server, or the like. The IP addresses are the key to NODE definition in using the topology model described herein. Therefore, an IP address cannot belong to more than one node. The IP address used to identify the NETWORK NODE 206 may be a list of IP addresses or a range of IP addresses. Routers may be considered network nodes in one embodiment and are tracked by the network topology if Simple Network Management Protocol (SNMP) monitoring is desired. In one embodiment, the NETWORK NODE element 206 in the data model has the properties and attributes illustrated in Table 5.
In general, the NETWORK NODES element should allow flexibility in terms of adding attributes/properties. Attributes can be separated into two categories. One category includes essential attributes that need to be explicit and known by the probes. The other category includes attributes that are not needed by the probes, but that are used exclusively for the UI and applications. Examples of such attributes are geographical location, map coordinates, custom icon, and the like. Other protocol-specific attributes may be added to the nodes, such as Radio Network Controller identifier (RNC ID), Mobility Management Entity identifier (MME ID), point code, network indicator, or the like. Visualization attributes, such as geographical location, may be added as needed.
Each NETWORK NODE element 206 is associated with zero or more PROBE elements 202, which are where the network node was observed. Force-detected or imported NETWORK NODEs may not have the assigned PROBEs 202. When the monitoring probe detects traffic from/to a network node, the monitoring server's topology information is updated. The NETWORK NODE element 206 represent an endpoint of LOGICAL LINK element 207. There may be zero or more logical links between the network nodes.
Generally, NETWORK NODE element 2-6 is auto-detected by the monitoring probes. For some types of nodes/protocols, auto-detection may not be practical. For example, as there are thousands of HTTP, DNS, POP3, SMTP servers. In one embodiment, the monitoring probe will not auto-detect these nodes, but the user may add these servers to the topology manually if desired. In another embodiment, the monitoring probe would detect these servers only in a user-provisioned IP address range.
The NETWORK NODE GROUP element 208 is used to group together one or more NETWORK NODE elements 206. In one embodiment, the NETWORK NODE GROUP element 208 is used exclusively by the UI applications. For example, a transaction analyzer application may use the NETWORK NODE GROUP element 208 to display KPIs for an entire group of nodes at once versus displaying one node at a time. NETWORK NODE GROUP element 208 is part of the topology information, but because it is created for the UI applications alone, the monitoring probes should not be concerned with creating or updating the NETWORK NODE GROUP element 208. In one embodiment, the NETWORK NODE GROUP element 208 in the data model has the properties and attributes illustrated in Table 7.
One or more NETWORK NODE elements 206 belong to a NETWORK NODE GROUP element 208. A given node may be a member of multiple network node groups.
NETWORK NODE GROUP element 208 is always provisioned by the user and never auto-detected.
The LOGICAL LINK element 207 is an abstractions of the logical-level connections in the network. Typical examples of logical links are IP paths and SCTP connections. LOGICAL LINK element 207 may be grouped at the UI level to provide a level of aggregation for the customer. There may be more than one logical link between two nodes and the links may be differentiated by L4 (OSI layer 4) properties. Accordingly, it is possible to have LOGICAL LINK elements such as:
Because SCTP associations may be set up and torn down at any time and are potentially short-lived, the LOGICAL LINK element 207 is used as a dimension for KPIs and status monitoring. The two nodes associated with the LOGICAL LINK element 207 are designated as server and client. The designation is protocol-specific. Typically, the uplink node is designated as the server, and the downlink node is designated as the client (e.g. in LTE: MME—server/eNB—client; and on Gn interface: GGSN—server/SGSN—client). The direction of the packets on the links is set relative to the server node (RX is uplink, TX is downlink).
In one embodiment, the LOGICAL LINK element 207 in the data model has the properties and attributes illustrated in Table 8.
The LOGICAL LINK element 207 could include an “enabled” flag in other embodiments, such as for enabling/disabling KPIs or a session analyzer for a LOGICAL LINK.
A LOGICAL LINK element 207 has exactly two NETWORK NODE element 206 endpoints. There may be more than one LOGICAL LINK 207 between two NETWORK NODEs 206. Through the NETWORK NODEs 206, the LOGICAL LINK elements 207 will also have relations to PROBE elements 202 via the intersection of the two NETWORK NODE element 206 properties.
Generally, the LOGICAL LINK 207 is auto-detected by the monitoring probes. Most of the typical link types handled by the monitoring probe are detected through SCTP association tracking.
The LOGICAL LINK GROUP element 209 is used to group together one or more LOGICAL LINK elements 207. The LOGICAL LINK GROUP element 209 is used exclusively by the UI applications, for example by a transaction analyzer to display KPIs for a group of links versus one displaying link at a time. LOGICAL LINK GROUP element 209 is part of the topology information like NETWORK NODE GROUP 208 and PHYSICAL LINK GROUP 205. However, GROUP 209 is a user interface artifact, and the monitoring probes should not be concerned with creating or updating LOGICAL LINK GROUP element 209. In one embodiment, the LOGICAL LINK GROUP element 209 in the data model has the properties and attributes illustrated in Table 9.
One or more LOGICAL LINK elements 207 belong to each LOGICAL LINK GROUP element 209. A given link may be a member of multiple logical link groups.
LOGICAL LINK GROUP elements are provisioned by the user and are not auto-detected by the monitoring probes.
The SCTP ASSOCIATION element 210 is, in general, a multi-homed load-shared SCTP connection between two NETWORK NODE elements 206. The SCTP ASSOCIATION element has to be detected and tracked in order for SCTP session correlation to be possible. In one embodiment, due to the nature of SCTP tracking and issues with ephemeral ports and SCTP connection re-establishment, the SCTP associations are tracked internally by the probe interface hardware in real time and not persisted in the topology database on the monitoring server. In that case, only LOGICAL LINK elements 207 are persisted, and there may be on-to-one relation between actual SCTP Associations and logical links.
To satisfy the use cases for SCTP Association status and real-time information, the monitoring probes provide an interface to retrieve detailed up-to-date information about tracked SCTP Associations and their status on demand. In one embodiment, the SCTP ASSOCIATION element 210 in the data model has the properties and attributes illustrated in Table 10.
These attributes are important for external users of SCTP Association information, such as a UI application or topology analyzer. Other attributes may be added by the probe interface hardware as needed for association tracking
Each SCTP ASSOCIATION element 210 belongs to zero or one LOGICAL LINK element 207. The LOGICAL LINK element 207 may not be available in the initial stages of auto detection.
The SCTP ASSOCIATION elements are detected and managed internally by the probe interface hardware.
Two of the approaches available to detect and mediate topology information in a distributed monitoring system are the PUBLISH-SUBSCRIBE approach and the NOTIFY-SUBSCRIBE approach. In the PUBLISH-SUBSCRIBE approach, when a new topology element is detected, the monitoring probe creates the object, publishes it to the monitoring system server and all of the other probes. The detecting probe immediately starts monitoring the new topology element, such as collecting KPIs. An advantage of this approach is that no data will be lost in most cases, since monitoring commences immediately after detection. Disadvantages of this approach include the complexity created by detection of the same elements by multiple probes and the mediating that must be performed for such duplicate detections. This approach also requires either multiple probe-unique identifiers for the same elements, or modifications to the collected data after the monitoring system server assigns a globally unique ID to the newly detected network element. A problem involving double-commits and race conditions may be crated where the same topology object is modified by the probe's PUBLISH mechanism and SUBSCRIBE mechanism at the same time.
In the NOTIFY-SUBSCRIBE approach, there is one exclusive owner of the “master” topology information. The owner receives update notifications from multiple probes, mediates the updates, and commits the changes to the topology. The committed updates are subsequently communicated to the probes. An advantage of this approach is that it is simple, deterministic, and does not have the problems associated with PUBLISH-SUBSCRIBE approach. A disadvantage of the PUBLISH-SUBSCRIBE approach is the time lag between the detection of an element, and propagation of a committed update through the monitoring system to distributed probes. As a result, some data will initially be lost, because the probe does not start monitoring the element until after it receives a master topology update from the server.
In an embodiment described herein, the NOTIFY-SUBSCRIBE approach is selected for topology detection and monitoring. The relatively small lag between the detection and the start of monitoring is considered to be of minor importance in actual deployments. Accordingly, the benefits of the NOTIFY-SUBSCRIBE approach outweigh this delay disadvantage.
Probe topology agent 304 may be a thread or process and is responsible for receiving topology updates from probe topology analyzers 303. Topology agent 304 mediates and throttles updates as needed to prevent double notifications and update floods. Topology agent 304 maintains the probe's communications interface and forwards mediated topology updates to the server topology agent 305.
Server topology agent 305 is a process on server 301 that is responsible for accepting topology updates from probe 302. Server topology agent 305 also mediate the topology updates between multiple probes 302 in cases when same elements have been detected multiple times. Server topology agent 305 is responsible for assigning globally unique IDs to new topology elements and serves as the commit point for import or force-detect scenarios. Server topology agent 305 also provides an interface to the monitoring system's operations, administration, and management (OA&M) topology database 306, which it updates it with new topology information.
The monitoring system includes a server OA&M subsystem 307. The OA&M subsystem 307 provides topology related services including maintaining up-to-date persistent network topology information 306. OA&M subsystem 307 also provides an interface to server applications and clients for retrieving and querying the topology via API. OA&M subsystem 307 operates with OA&M topology service 308 to update probes 302 with pertinent topology information in real-time. To maintain efficiency, the entire topology set is not provided to the probes 302. Instead, the probes receive only the topology subset that is relevant to each probe. OA&M subsystem 307 is also responsible for updating the probes with delta topology information in real-time, which includes only the topology elements that have been changed. Finally, OA&M subsystem 307 keeps the server topology and probe topology synchronized at all times.
Probe 302 may further comprise an SCTP tracking module 309 having logic that provides detection and audit of SCTP Associations, reassembly and debundling of SCTP packets, and sending SCTP Associations events, such as additions/deletions/modifications, to the topology agent 304.
Topology analyzer 402 sends a message to probe topology agent 403 to create a new network node. The detected properties for the new network node include: TYPE, IP ADDRESS, PHYSICAL LINK, and APPLICATION ID. Probe topology agent 403 determines whether new element addition is subject to throttling, which allows only one pending element addition request at a time. If throttling is not active for this IP address, the probe topology agent 403 sends a message to server topology agent 404 to create a new network node. Server topology agent 404 checks the new node against the existing topology database, and then mediates and merges the data, if the node already existed, or creates a new object.
The changes to the network node element are forwarded to server OA&M 405 to be stored in the topology database. The new element information is also published to probe subscribers via probe OA&M 406. The probes then begin monitoring the new network node. After the new node is detected and the server ID is available on the probe, there still may need to be updates to the node object. For example, the list of physical links, probes, and observed application IDs may need to be updated. To avoid querying OA&M processing every incoming PDU, network node updates could be tied to the processing of transaction analysis KPIs or some other routine task.
The following is a description of an example monitoring system using the topology detection system disclosed herein to a 3G and Long-Term Evolution (LTE) network. In LTE networks, it is assumed that SCTP associations between nodes are persistent, and that one side of the connection may be an ephemeral port. For simplification, short-lived SCTP associations may not be handled initially. In one embodiment, 40 probes are used to monitor the network, which corresponds to approximately 1000 eNodeBs and MMEs per probe and 20,000 4-path associations per probe.
The following processing logic is used for Gn/Gi node detection in one embodiment. A traffic processor receives a GTPv1 Control PDU and successfully decodes it. Any PDUs that fail to decode are discarded. A topology analyzer running in the same traffic processor thread receives the PDU and checks the endpoint addresses against known IDs. If both IDs are known, detection is complete. If one or both of the IDs is zero, the PDU is passed to protocol-specific processing module, such as a GTPv1 processor in this example. Based on protocol-specific detection logic, GGSN and SGSN nodes are detected. The topology analyzer checks its internal temporary table to see if the nodes with these IP addresses have already been sent to a topology agent. If so, detection is complete. If the nodes are new, the topology analyzer creates new network nodes in its temporary table, setting all known attributes, and sends an update to the topology agent. At this point, the topology analyzer is done.
The topology agent receives the update and checks its internal update table to see if nodes with these IP addresses already exist. In one embodiment, the topology agent table is not the same as OA&M topology information. If the nodes are already in the topology agent update table, the detection is complete. If the nodes are new, they are added to the update table. The information about new nodes is merged into the OA&M database, and duplicates are detected. The topology agent and topology analyzer receive the updated nodes from OA&M interface and add them to the active topology set. Updated network node lists are sent to all probes and new node-to-ID mappings are added to the probe tables. All later-detected PDUs from/to these IP addresses will have the correct ID.
In one embodiment, initial SLAP interface detection is performed as follows. Initial detection scenario assumes that the probe is starting from clean slate—i.e. there are no nodes, logical links, or interfaces present in the system. It is further assumed that there is a single-homed association between an MME with IP address A and an eNodeB with IP address B. The MME side uses a fixed port P1, and the eNodeB uses ephemeral port P2. The monitoring probe interface hardware detects a new SCTP association between A-P1 and B-P2 and assigns the association a unique internal identifier. The probe interface hardware broadcasts information about the SCTP association to topology analyzers and topology agents. This information is required to detect logical links and to set correct L4 properties. The topology agent and topology analyzers receive and cache the association information hashed by Association Identifier.
When an SlAP protocol PDU on this SCTP association is successfully processed, it is debundled/reassembled as needed, stamped with SlAP protocol ID, and forwarded to a traffic processor thread. The traffic processor receives the SlAP PDU and successfully decodes it. The topology analyzer receives the PDU and passes it to protocol-specific SlAP processing module. If the topology analyzer observes that both Server IDs and Logical Link ID for the PDU is set to zero, then detection of eNodeB and MME is done at this point. The topology analyzer finds the SCTP association in its table, based on the Association ID passed in the extended packet descriptor, and merges the IP information from SCTP associations to the new nodes.
The topology analyzer enters the new nodes into its update tables, and sends a message to the topology agent with the two new elements. The topology agent receives the update and checks its internal update table to see if nodes with these IP addresses and a logical link with these properties already exist. If new, the elements are entered into update tables and probe-side detection of nodes is complete.
Once the nodes are accepted by the server and assigned unique node IDs, the probe is ready to detect a logical link. When the topology analyzer sees the next PDU between A and B, it will detect the logical link between A-P1 and B-WILDCARD. Logical link data is entered into the table, sent to topology agent and subsequently to the server. Logical link detection will only occur if both nodes already have valid node IDs.
In one embodiment, the system segments the topology by probe. The server OA&M tracks the relationship between network Nodes and monitoring probes. This serves two purposes. First, it gives applications, such as a session analyzer and protocol analyzer, a way to apply node filters without broadcasting to all probes. Second, it limits the number of node updates that get downloaded to the probes via the OA&M.
In another embodiment, to make things simple and fail-proof, the server OA&M may download all nodes, with the exception of eNodeBs, to every probe. While the number of eNodeBs may be in thousands in a network, the number of other nodes is comparatively small—in the range of 10-50 per probe. eNodeBs will only go to a probe if they have that probe assigned in the properties. Once all the nodes and pertinent eNBs are configured on the probe, the processing logic is as follows:
The topology detection model used herein allows a network operator to detect nodes and links in an IP-based network without requiring protocol-specific messages. Multiple monitoring probes throughout the network capture data traffic and detect the IP addresses in the data packets. The monitoring probes are distributed throughout the network, and an individual data packet is likely to be detected by multiple probes. Additionally, the same IP address may be identified by different monitoring probes. The topology detection system aggregates the IP addresses and identifies the network nodes. The topology detection system also resolves duplicate detections of data packets and IP addresses from the distributed monitoring network. The topology detection system may also identify the type of each node. The node type information allows the system to evaluate the relevance of each node, such as the impact of a node's failure on the operation of the network.
Many modifications and other embodiments of the invention will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions, and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.