1. Field of the Invention
The present invention relates generally to computer networks and network management.
2. Description of the Background Art
Private address domains are commonly used in local area networks (LANs). Reasons for using private address domains include, among others, hiding internal addresses, the freedom of such an internal addressing scheme, and insulating the internal addresses from enterprise or service provider address changes. Such private address domains are typically implemented using a network address translation (NAT) device to route packets between address realms.
For explanatory purposes, the operation of a conventional NAT device is now described in relation to
In this scenario, the host 108 generates and transmits a transmission control protocol (TCP) packet 110 requesting a connection, in this instance, to the domain name “openview.hp.com”. Of course, this resource is just a particular example, and the connection may be to another resource. The packet 110 includes a header 112 and content (or payload) 114. The header 112 includes, among various other data, the source IP address of the host 108. In this example, the source address is 10.1.1.5. The packet content 114 may include, for example, a hypertext transfer protocol (http) request to connect to and receive a web page from the example domain “openview.hp.com”. Of course, the request may be for other web pages, and may utilize other protocols besides the http protocol (for example, file transfer protocol, and so on).
The packet 110 is communicated to and received by the NAT device 104. The NAT device 104 translates the source address from the internal IP address (in this instance, 10.1.1.5) in the original header 112 to a corresponding external IP address (in this instance, 15.133.219.25). The internal address is typically private and non-unique, while the external address is typically public and unique. In addition, the NAT device 104 recalculates and replaces the checksum for the packet. The modified packet 116, including the modified header 118 with translated source, is transmitted from the NAT device 104 to the external network 106 so as to reach its destination.
As depicted in
The packet 152 is communicated to and received by the NAT device 104. The NAT device 104 translates the destination address from the external IP address (in this instance, 15.133.219.25) in the external header 154 to the corresponding internal IP address (in this instance, 10.1.1.5). In addition, the NAT device 104 recalculates and replaces the checksum for the packet. The modified packet 158, including the modified header 160 with translated destination, is transmitted from the NAT device 104 to the private network 102 so as to reach the destination host 108.
It is desirable to manage network components or devices by way of a central management system. For example, the Simple Network Management Protocol (SNMP) and Common Management Information Protocol (CMIP) are network management protocols providing mechanisms to communicate management information between network components on the network. Using such protocols, network components can be monitored and controlled from a management system, such as one residing on a UNIX server. Network components may include networked personal computers, workstations, servers, routers, and bridges.
One mechanism by which various network devices communicate with a management system is via SNMP traps or CMIP events. Hereafter, “events” will be used to refer to either SNMP traps or CMIP events. Events allow for unsolicited notifications to be sent from one network device to another. This same mechanism can be used for communication between various cooperating software components within the management system.
There are several software products that receive events and allow a user to manage network devices. One of these products, Network Node Manager (NNM) from the Hewlett-Packard Company of Palo Alto, Calif., enables a user to manage network devices using a graphical user interface (GUI) along with graphically representing relationships between network devices. Hereafter “NNM” may be used to generically refer to a product that receives events and allows a user to manage network devices, such as Network Node Manager.
One embodiment of the invention relates to a method of configuring a network including multiple overlapping private address domains. A configuration file is created for each overlapping address domain (OAD). The configuration file includes an identifier for the OAD, a gateway address to the OAD, and mappings between private addresses in the OAD and corresponding management addresses.
Another embodiment relates to a system for managing a network including multiple OADs. The system has a computer system including software for a network management system and a plurality of network address translation (NAT) devices. Each NAT device in the plurality is communicatively coupled to said computer system and communicatively coupled to one of the OADs. A route distinguisher is associated with each OAD to facilitate management thereof.
Another embodiment relates to a method of processing a trap from a network with multiple OADs. A trap packet originating from a managed network device is received, and a management internet protocol (IP) address is extracted from its header. A domain identifier and a private IP address corresponding to the management IP address is determined and used to uniquely identify the managed network device.
Another embodiment relates to a method of finding an active route across a static NAT device. A gateway to a private network is found, wherein the gateway comprises the static NAT device. A private address of a next device in the private network is looked-up, and a corresponding management address is determined. The management address is added to a route being calculated. The looking-up, determining, and adding steps are repeated until the next device comprises a destination device.
The present invention relates to the management of multiple private networks with overlapping address domains (OADs). Such networks are commonly found in service provider environments. Each customer may have one or more private networks interconnected to the service provider network.
It is common for one private network to have overlapping internet protocol (IP) addresses with another private network. Unfortunately, such overlapping address domains make it more complicated and challenging to provide centralized network management over these private networks.
An example network with multiple overlapping private address domains is described in relation to
There are difficulties in providing centralized management of private networks with overlapping address domains. One reason for these difficulties is that network address translation may not work well when the applications use IP addresses as part of the protocol itself. For example, an SNMP query to a device would return private addresses in the payload of the response. Hence, it can be problematic to identify the correct source device and to navigate easily to views of the specific domain from a single centralized management system. As described below, a solution to these difficulties is provided by embodiments of the present invention.
As shown in
In accordance with an embodiment of the invention, route distinguishers are advantageously utilized to manage the private networks with overlapping address domains. In one embodiment, a route distinguisher may comprise an identifier number (“OAD id”) and a descriptive string (“name”) for each overlapping address domain. In one specific implementation, the OAD id may comprise a 32-bit integer greater than zero. By definition, each overlapping address domain comprises a set of IPv4 addresses that are internally non-overlapping (i.e. none of the addresses in the set are duplicates) and typically are directly routable from each other without manipulation of the IPv4 header. For example, an OAD might represent the set of private IP addresses of a small business or of a specific workgroup in a larger company. In the simple example shown in
As shown in
The directory created 404 is a separate directory defined for each OAD. The directory is created 404 so as to be accessible by the centralized network management system at the ISP. For example, in a specific implementation under a UNIX-type operating system, the directory created may be, for instance, beneath the directory named “$OV_CONF/nnmet/dupip”. If there is two OADs (for example, for a “red” group and a “blue” group), then two directories are created, one may be named “$OV_CONF/nnmet/dupip/red” and the other may be named “$OV_CONF/nnmet/dupip/blue”.
The configuration file is created 406 within each such new directory. In one implementation, the configuration file may be named “dupip.conf”. Commands are included in the configuration file. These commands define the associated OAD.
One command may define the OAD. For example, this command may be of the form: OverlappingAddressDomain id=“number” name=“string”. Gateway, routable, and mapping commands which follow this are for this address domain. One and only one OverlappingAddressDomain command is needed per configuration file.
Another command (“gateway”) may be used to specify gateways to be managed for this particular OAD. Multiple such commands may follow the OAD definition command. Each such command gives a gateway IP address for the OAD. In one embodiment, the address given is a management IP address. A management address is the address that is used by the management server to communicate with the network device. This address should be unique across all IPv4 addresses visible to the instance of the management station. For example, this command may be of the form: Gateway IP=“IP addr”.
Another command (“routable”) may be used to specify a management IP address which is routable. Multiple such commands may follow the OAD definition command. In one implementation, wildcards may be allowed in these mappings. For example, this command may be of the form: Routable managementIP=“IP addr”.
Another command (“mapping”) may be used to delineate a mapping between private addresses and management addresses. Multiple such commands may follow the OAD definition command. For example, this command may be of the form: Mapping privateIP=“IP addr” managementIP=“IP addr”.
In addition to the configuration file, a seed file is also created 408 in the directory for each OAD. The seed file defines the discovery zone for the OAD. In other words, only the IP addresses in the seed file are discovered. Each seed file includes a list of the management IP addresses to be managed for a given OAD. In one implementation, one management IP address is entered per line, along with an optional hostname (which should be resolvable to the management address at the management station).
Once the configuration and seed files have been created, a command may be run to check 410 the syntax of these files. In one implementation, this command may be called the “ovdupip -u” command. This command may also be run after any modification of the configuration or seed files so as to make sure the files remain syntactically correct. If there are errors in the files, this checking tool may return an indication of what is wrong and where to look to remedy the problem.
In one embodiment, the configuration and seed files (nor changes therein) do not affect the networking software currently running until they are loaded 412 into a configuration system and deployed 414 to the running configuration. The loading 412 and deployment 414 may be accomplished, in one specific implementation, using an Extended Topology Configuration GUI, such as the example web page depicted in
The system 606 includes various components. A TCP/IP stack 608 is provided to communicate with the private networks (and with other networks). Above the TCP/IP stack 610 resides a duplicate-IP-aware (Dup IP aware) communications layer 610, and above that layer 610 resides an application programming interface (API) layer. The API layer may include various APIs, including a duplicative IP Address API 612, an SNMP API 614, and an ICMP API 616.
Other components include duplicate IP (Dup IP) configuration and seed files which are discussed above. These files are accessible by way of the Dup IP aware communication layer 610 of the stack. In addition, there is an event engine 622 which includes a module 624 for trap/syslog reception. This module 624 receives and transmits communications by way of the Dup-IP address API 612 and/or the Dup IP-aware communications layer 610. A discovery engine 626 communicates by way of the Dup-IP Address API 612, SNMP API 614, and ICMP API 616. A polling and fault analysis engine communicates by way of the SNMP API 614 and ICMP API 616. A Dup-IP Aware Topology store component 630 is configured to receive data and/or communicatively interact with the discovery engine 626 and the analysis engine 628.
Using the information in the configuration and seed files, the management system software in
When a trap is received 702 on a socket, a management address of the device from where the trap originated (i.e. the trap management address) is typically returned via the user datagram protocol (UDP) header. This management IP address is extracted 704 from the UDP header. The configuration file 620 is accessed 706 and the corresponding OAD id and private IP address are determined 708. Thereafter, the OAD id and private address information is attached 710 to the trap event generated internally at the network management system. Subsequent software processes at the network management system may then use 712 this information to uniquely identify the private network and the device therein from which the trap originated. Advantageously, this method enables the unique identification of the private network and device therein that a trap comes from, even if duplicate private IP addresses exist in the network.
An active route is a current route packets take through network devices to get from a source device to a destination device. Active route information is valuable because knowing the active route is useful to the determination of where problems could be that are limiting bandwidth or stopping traffic.
Routers update tables, such as an IP address table and an IP routing table, during the course of normal operation. These tables allow the router to adapt to its surroundings to know the preferable way to forward a packet to get the packet to its destination quickly. Algorithms to find an active route typically query these tables in order to predict the flow of packets (without having to send test packets). However, a problem arises when the destination device resides in a private network, protected by a static NAT device. The problem is that the static NAT device will not reveal details on how it forwards packets.
The present application discloses mechanisms to inform network management software of the details of a private network behind a static NAT device. In particular, the above-described gateway command in the configuration file 406 indicates the gateway static NAT device used to enter the private network. In a specific implementation, the configuration file may include the following gateway command: Gateway IP=“133.45.22.1”. This command indicates to the network management software that the device at IP address 133.45.22.1 is a static NAT device and is used as a gateway into the private network associated with the configuration file.
In accordance with an embodiment of the invention, an additional command is provided in the configuration file. In one implementation, the additional command is of the following form: NextHop IP=“133.45.23.1”. This next hop command indicates that the packets will flow from the gateway address (for example, 133.45.22.1) to the next hop address (for example, 133.45.23.1) as the packets enter the private network. The next hop address given is an external (management) address that can be communicated and used outside the private network. The device at the next hop address is located inside the private network, so that device also has a private address (in addition to the external address).
As shown in
A determination is made 810 as to whether this device is the destination device. If this device is the destination, then the algorithm may return 812 the route being calculated.
Otherwise, a determination is made 814 as to whether this device is a gateway NAT device. If this device is not a gateway device, then the algorithm “moves” 815 to it. The algorithm then loops back and performs the look-up 804 to the router tables at this device, finds 806 the next-hop device along the route, and adds 808 that the management address for the next-hop device to the route being calculated. The algorithm continues in this way until the destination or a gateway is reached.
If a gateway NAT device is reached, then the algorithm continues as depicted in
A determination 828 is then made as to whether this device is the destination device. If this device is not the destination device, then the algorithm “moves” 829 to this device. The algorithm then loops back and again performs the look-up 820 to the router tables for the private network, finds 822 the private address for the next device, determines 824 the corresponding management address, and adds 826 that address to the route being calculated. The algorithm continues in this way until the destination is reached. When the destination is finally reached, then the calculated route is returned 830. Advantageously, the calculated route comprises a complete list of hops taken from the source through the static NAT to the destination.
In the above description, numerous specific details are given to provide a thorough understanding of embodiments of the invention. However, the above description of illustrated embodiments of the invention is not intended to be exhaustive or to limit the invention to the precise forms disclosed. One skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific details, or with other methods, components, etc. In other instances, well-known structures or operations are not shown or described in detail to avoid obscuring aspects of the invention. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.