Many businesses maintain networks that are connected to much wider networks, of which they have limited knowledge. As one representative example, many service providers utilize telecommunication, computer, or other networks in delivering services to customers. The ability to abstract the network into a database, simulate traffic flows through the network, and analyze many aspects of the network's operation, allows service providers to optimize existing networks, plan for future growth, and increase reliability by simulating network failures. The ability to accurately simulate traffic and analyze a network is limited by the information available about actual network facilities (e.g., nodes such as routers and switches, and links such as telecommunication channels). In particular, modeling data flows from a source or to a destination that is not within the service provider's administered network is difficult, since traditional point-to-point (i.e., source-to-destination) analysis is impossible due to the inability to know what off-network facilities the traffic flow is routed through, much less the characteristics and capacities of the off-network facilities.
However, the need remains for service providers and other network administrators to be able to perform high fidelity simulations of real-world traffic, to accurately plan and provision the facilities within their administered network.
According to one or more embodiments disclosed and claimed herein, off-network traffic flows through an administered network are simulated and analyzed by selecting an ingress and/or egress node within the administered network, the ingress node capable of collecting traffic from an off-network source, and the egress node capable of routing traffic to an off-network destination. Traffic flow through the administered network from the ingress to the egress node is simulated and analyzed. Several approaches to selecting the ingress and/or egress nodes are presented.
One embodiment relates to a method of mapping network traffic flow in an administered network from a source to a destination, where at least the destination of the traffic is not within the administered network. Routing information at edge devices of the administered network is inspected. One or more candidate egress nodes within the administered network that are capable of routing traffic to the destination address are determined, based on the routing information. An egress node is selected from among the candidate egress nodes. The traffic flow is mapped from the source or an ingress node, through the administered network, to the selected egress node.
Another embodiment relates to a computer readable medium including one or more computer programs operative to cause a computer to analyze traffic flow in an administered network from a source to a destination, where at least the destination of the traffic is not within the administered network. The computer programs are operative to cause the computer to perform the steps of inspecting routing information at edge devices of the administered network; determining one or more candidate egress nodes within the administered network that are capable of routing traffic to the destination address, based on the routing information; selecting an egress node from among the candidate egress nodes; and mapping the traffic flow from the source or an ingress node, through the administered network, to the selected egress node.
In general, when simulating and analyzing the administered network 108, neither the off-network topology nor any details of off-network facilities are known.
An off-network destination node may be mapped to an egress node in a variety of ways, by consulting edge device routing tables. As well known in the art, a routing table is a file or database structure maintained at a router or other network node that stores routes (i.e., network paths), and optionally metrics associated with the routes, to network destinations. In modern networks utilizing structured network addresses, similar addresses imply proximity within the network. When addresses are structured (such as IP addresses), a partial address, such as a prefix, may be sufficient to route traffic towards a destination node. If the routing table at an edge node does not contain any portion of a destination address, the edge node cannot be an egress node for simulating traffic flows to that destination. Conversely, every edge node with a routing table entry matching some or all of the destination address is a candidate egress node for simulating traffic flows to that destination. A set of candidate egress nodes may thus be determined by inspecting routing tables at all edge nodes. If the routing tables are not available for some or all edge nodes, the tables may be built by a flow analysis run in a network simulator. An egress node may be selected from among the set of candidate egress nodes in a variety of ways.
In one embodiment, an egress node is selected from among the set of candidate egress nodes prior to performing any simulation of traffic through the administered network 108 to the off-network destination 106. In one embodiment, prefix graphs are used to formulate a directed topological graph through the administered network of all paths from the source (or ingress) node 104 to all candidate egress nodes, based on the routing tables. The egress node may then be selected by applying known network constraints to the paths. The constraints may, for example, include least cost, fewest hops, greatest bandwidth, or the like. Alternatively, an egress node may be selected from the candidate set manually, randomly, or by other criteria.
For example, by inspection of
Having a known route through the administered network 108 for the traffic flow to the off-network destination 106 is useful for transit network planning—that is, planning the capacity of the transit network. However, the source/ingress-to-egress simulations do not illuminate the network capacity requirements in the case of failures. For example, if node RT4 failed, traffic to the off-network destination 106 would likely be routed along the path RT1-RT3-CR12-CR11, making node CR11 the egress node for traffic flow to the off-network destination 106. In order to capture all such cases, exit point analysis must be performed to discover all valid egress nodes. Exit point analysis is performed with a single-point flow 114, as depicted graphically in
In one embodiment, only the source (or ingress) node 104, e.g., RT1, is specified, and an egress node is selected from among the set of candidate egress nodes by simulating traffic flow through the administered network 108 to the off-network destination 106. As mentioned above, node 104 (RT1) may be the source of traffic flow to the off-network destination 106. Alternatively, the source node may reside outside of the administered network 108, with the traffic entering the network 108 at the ingress node 104. For the purpose of exit point analysis, the distinction is irrelevant; the node RT1 may be a source of the traffic flow, or it may be the ingress node in the administered network 108 for an off-network source.
In the latter case, traffic analysis (of actual traffic or simulations) discovers the edge nodes that are collection points for traffic routed to the off-network destination 106. If a collection point is an edge device of the administered network 108, it is treated as an ingress node. If the collection point is not an edge device, an ingress node may be determined by treating the collection point as a source and mapping to the off-net source in a manner similar to the search for egress candidates, i.e., by creating a prefix graph and looking for edge devices with routing table destinations to the off-net source. Each ingress node may then be specified in a separate simulation to perform exit point analysis to discover egress node(s).
When specifying only a source/ingress node 104, a simulation of traffic flow through the administered network 108 to the off-network destination 106 will yield all egress nodes. However, since the destination 106 is not within the administered network 108, a metric to evaluate the success or failure of the end point analysis is necessary. In one embodiment, a traffic flow from a source/ingress node 104 to an egress node is defined as successful if it can be routed through the administered network 108 until it reaches a node where the next hop for the destination points to an unconnected interface. However, if a lookup in the routing table for this destination fails on any of the nodes along the way, the flow is defined as failed. For example, the traffic flow 112 depicted in
If the traffic flow source is off-network and more than one ingress node is detected, the method may be repeated for each ingress node (block 218). In the case that the source of traffic flow resides within the administered network, blocks 206 and 218 are omitted, and the source node is treated as the ingress node in the above discussion. When all paths through the administered network have been analyzed, the method terminates (block 220).
The network addresses (e.g., IP addresses) of devices behind a router or firewall are not always fixed. That is, the routing device may dynamically assign the address according to the Dynamic Host Configuration Protocol (DHCP). Network Address Translation (NAT)—the re-writing of source and/or destination addresses of IP packets as they pass through a router or firewall—may be implemented to insure that any transmissions originating from devices behind a router or firewall appear to the outside network as originating from the router or firewall instead of the devices themselves. NAT also enables any return transmissions to be routed back to the correct device.
If a source device is in the administered network 108 but behind a router or firewall, there are three approaches to representing the source. In one embodiment, the flow is simply terminated at the routing device. In another embodiment, a visual indicator is attached to a graphic representation of the routing device in a display or graph, indicating that the true source is unknown. In yet another embodiment, the configuration information of the routing device is captured to determine the true source, and the flow is terminated at that device.
The off-network traffic flow mapping to an administered network as disclosed and claimed herein may be implemented by discrete calculations, by specialized software executing on a general-purpose computer or dedicated network monitoring/optimization workstation, or by any combination of software, dedicated hardware, firmware, or the like, as known in the computing arts. In one exemplary embodiment, off-network traffic flow analyses are implemented as part of a network analysis and optimization software program, such as the OPNET SP Guru Release 12.0, available from OPNET Technologies, Inc. In one embodiment, a computer implementation of the off-network traffic flow mapping to an administered network generates a graphic output of the administered network 108, with the traffic flow mapping depicted, such as shown in
Although the present invention has been described herein with respect to particular features, aspects and embodiments thereof, it will be apparent that numerous variations, modifications, and other embodiments are possible within the broad scope of the present invention, and accordingly, all variations, modifications and embodiments are to be regarded as being within the scope of the invention. The present embodiments are therefore to be construed in all aspects as illustrative and not restrictive and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.
This application claims priority to U.S. Provisional Application Ser. No. 60/821,819, filed Aug. 8, 2006, and incorporated herein by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
5042027 | Takase et al. | Aug 1991 | A |
5870564 | Jensen et al. | Feb 1999 | A |
5996021 | Civanlar et al. | Nov 1999 | A |
6137782 | Sharon et al. | Oct 2000 | A |
6262976 | McNamara | Jul 2001 | B1 |
6538991 | Kodialam et al. | Mar 2003 | B1 |
6584071 | Kodialam et al. | Jun 2003 | B1 |
6647412 | Strandberg et al. | Nov 2003 | B1 |
6804196 | Kadengal | Oct 2004 | B1 |
6873600 | Duffield et al. | Mar 2005 | B1 |
6934745 | Krautkremer | Aug 2005 | B2 |
6956821 | Szviatovszki et al. | Oct 2005 | B2 |
7145867 | Aicklen et al. | Dec 2006 | B2 |
7251215 | Turner et al. | Jul 2007 | B1 |
7260064 | Basu et al. | Aug 2007 | B2 |
7269157 | Klinker et al. | Sep 2007 | B2 |
7468975 | Davis | Dec 2008 | B1 |
20020051449 | Iwata | May 2002 | A1 |
20020083174 | Hayashi et al. | Jun 2002 | A1 |
20020141345 | Szviatovszki et al. | Oct 2002 | A1 |
20030081608 | Barri et al. | May 2003 | A1 |
20030118036 | Gibson et al. | Jun 2003 | A1 |
20030193949 | Kojima et al. | Oct 2003 | A1 |
20040064537 | Anderson et al. | Apr 2004 | A1 |
20040071082 | Basu et al. | Apr 2004 | A1 |
20040156313 | Hofmeister et al. | Aug 2004 | A1 |
20050018608 | Wetherall et al. | Jan 2005 | A1 |
20050254490 | Gallatin et al. | Nov 2005 | A1 |
20050265248 | Gallatin et al. | Dec 2005 | A1 |
20050265364 | Gallatin et al. | Dec 2005 | A1 |
20050271065 | Gallatin et al. | Dec 2005 | A1 |
20060221974 | Hilla et al. | Oct 2006 | A1 |
20070192863 | Kapoor et al. | Aug 2007 | A1 |
20080002588 | McCaughan et al. | Jan 2008 | A1 |
20080002707 | Davis | Jan 2008 | A1 |
20080084890 | Kompella | Apr 2008 | A1 |
20080259793 | Bauer et al. | Oct 2008 | A1 |
20090059793 | Greenberg | Mar 2009 | A1 |
Number | Date | Country | |
---|---|---|---|
20080037423 A1 | Feb 2008 | US |
Number | Date | Country | |
---|---|---|---|
60821819 | Aug 2006 | US |