Patent Grant
9331910
The present invention relates to methods and systems for automatically generating routing configuration files, and more particularly relates to automatically generating routing configuration files based on a network topology and a collection of routing configuration templates.
In a typical communication network, a source and destination are separated by a plurality of intermediary devices, such as routers, bridges, gateways, firewalls and switches. Network routing involves, among other things, selecting a route (often the most optimal route according to some metric, such as latency etc.) from the source to the destination through the intermediary devices. Before routes can be selected, the intermediary devices need to be configured. In some cases, configuring the intermediary devices involves specifying the directly connected neighbor devices of each intermediary device, specifying the group membership of an intermediary device (e.g., membership in an Autonomous System, peer group, confederation, etc.), specifying whether routing tables should be forwarded to other devices (e.g., route reflectors).
Routing protocols have been developed to facilitate the configuration of the intermediary devices. Example routing protocols include the Routing Information Protocol (RIP), the Enhanced Interior Gateway Routing Protocol (EIGRP), the Open Shortest Path First (OSPF) protocol, Intermediate System to Intermediate System (IS-IS) protocol and the Border Gateway Protocol (BGP). While routing protocols facilitate the configuration of intermediary devices, in most cases, such configuration is not automatic, and requires a significant amount of a network operator's attention. In fact, Cisco Systems™ of San Jose, Calif. has developed the Networking Academy Program to train individuals to properly configure routing protocols such as RIP, EIGRP, OSPF, IS-IS and BGP. Highly trained network operators are necessary, as configuration errors can lead to network system failure and consequently a loss of productivity at an enterprise.
One approach to address routing configuration errors, specifically cabling errors, has been to verify the cabling dynamically at link-up. The prescribed topology of the network specified in a graph description language such as DOT is compared with the actual topology of the network, determined via a discovery protocol such as the link layer discovery protocol (LLDP). Differences between the prescribed topology and the actual topology may include missing cabling in the actual topology (e.g., in the event that cable is damaged or misconnected), or may include an extra cable in the actual topology (e.g., in the event that cable is misconnected). Any differences may be logged for analysis by a network operator. While verifying the cabling dynamically at link-up helps address cabling errors, other types of routing configuration errors remain.
In various embodiments of the present invention, a routing configuration file generator automatically generates configuration files for configuring a network device (e.g., router, switch) in accordance with a routing protocol (e.g., RIP, EIGRP, OSPF, IS-IS and BGP). Since the generation of a configuration file is an automated process, configuration errors by network operators are significantly reduced. Further, time spent by network operators to configure and troubleshoot network devices is significantly reduced, freeing up network operators for other tasks.
In one embodiment of the invention, the routing configuration file generator receives as input a network topology specified in a graph description language, such as DOT, and/or in a graph modeling language, such as GraphML. A network topology may also be specified as a network diagram, in which case, the network diagram may be first converted into a DOT or GraphML file, before being provided to the routing configuration file generator.
In one embodiment of the invention, the routing configuration file generator also receives as input routing configuration templates, which include certain sequences of routing protocol commands that are frequently repeated in the configuration of a network device. The routing configuration file templates may include placeholders for information specific to a certain network configuration. Such information may include identifiers associated with nodes (i.e., node is another name for a network device or an intermediary device), identifiers associated with interfaces of a node, identifiers associated with a group of nodes, etc. A different template may be provided for different types of nodes, such as a leaf node, mid-spine node, and top-spine node. Further, a template may be provided for different node interfaces, such as an interface that is communicatively coupled to a leaf node, an interface that is communicatively coupled to a spine node, etc.
In one embodiment of the invention, the routing configuration file generator also receives as input the routing protocol for the network (e.g., RIP, EIGRP, OSPF, IS-IS and BGP). The routing protocol may be received as part of the DOT or GraphML file.
In one embodiment of the invention, the routing configuration file generator also receives as input neighbor addresses associated with the nodes. In one embodiment of the invention, link local addresses are automatically generated for node neighbors, eliminating the need to acquire Internet Protocol (IP) addresses associated with the node neighbors.
Based on one or more of the above-described input, the routing configuration file generator automatically generates a routing configuration file for one or more nodes of the network. In one embodiment of the invention, the routing configuration file generator may instantiate a particular template for each node of the network topology, substituting any placeholders with information specific to the network topology. Further, the routing configuration file generator may instantiate a particular template for each node interface of the network topology, substituting any placeholders with information specific to the network topology.
These and other embodiments of the invention are more fully described in association with the drawings below.
The present invention is illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:
In the following detailed description of the preferred embodiments, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.
Network topology 10 specifies the interconnection between nodes of the network. Nodes may include the above-mentioned intermediary devices (e.g., routers, bridges, gateways, firewalls and switches). Each node may have one or more interfaces. More specifically, network topology 10 may specify the interconnection between interfaces of the nodes. The interconnection may be a directional connection or a bi-directional connection between two interfaces. Example network topologies include a Clos topology, a folded Clos topology (i.e., a “fat tree”) and a leaf and spine network.
In one embodiment of the invention, network topology 10 may be specified using a graph description language, such as DOT, and/or a graph modeling language, such as GraphML. Alternatively, network topology 10 may be specified by a network diagram, such as that depicted in
An exemplary DOT file is depicted in
The nodes may be assigned certain attributes, such as a layer attribute. In the example of
Each node may be assigned an external identifier, such identifier used to identify a node in a routing configuration file. In the example of
Interconnections between nodes (or more precisely between interfaces of the nodes) are further specified in the exemplary DOT file. For instance, the statement “r1:swp1->r3:swp1;” specifies that interface “swp1” of node “r1” is communicatively coupled to interface “swp1” of node “r3”. Such arrangement may be more clearly understood from
The DOT file may specify a type of routing protocol, such as BGP, OSPF, EIGRP, etc., for the network. The automatically generated routing configuration file (i.e., the output of the routing configuration file generator 18, further described below) will be generated in accordance with the specified routing protocol. In the exemplary DOT file of
The DOT file may also specify certain clusters of nodes. In the example of
In one embodiment of the invention, internal BGP (IBGP) may be used as the routing protocol inside a network with a topology such as leaf and spine. The template for IBGP can be described by the following method. The nodes above the leaf layer are configured to be route reflectors in their own cluster. They use the router-id as their cluster-id by default (no configuration needed). While reflecting routes from one layer to the next, these nodes set next-hop-self through configuration, thus inserting themselves into the data path. In the absence of an IGP cost in the network, the nodes use cluster-list length as a metric representation. This ensures loop-free forwarding and forms the basis for equal-cost multipath.
Routing configuration file generator 18 also takes as input routing configuration templates 12. A template generally captures one or more lines of configuration commands that repeat in a routing configuration file or across multiple routing configuration files (i.e., captures the basic repeating unit). A template further may include placeholders for information specific to a network topology, such as node identifiers, interface identifiers, etc.
In one embodiment of the present invention, different templates may be provided for different node types. In the example of
A discussion is now provided for the instantiation of the node and interface BGP templates associated with the “leaf” node r1. The following node template for a leaf node is instantiated once for node r1:
Any placeholders may be appropriately completed along with the instantiation of the template. For instance, the <AS number> placeholder may be specified as 65000. More generally, the <AS number> may be any Autonomous System (AS) number, while a private AS number may be a convenient choice. For node r1, the <id> placeholder may be specified as 0.0.0.1, in accordance with the external node identifier 0.0.0.1 being assigned to node r1 in the DOT file.
The following interface template for a “leaf” node is instantiated once per each router facing interface of r1:
For interface “swp1” of node “r1”, the placeholder <any> may be replaced by the interface identifier “swp1”, followed by the tag “ipv6” specifying that interface “swp1” uses ipv6 addressing. For interface “swp2” of node “r1”, the placeholder <any> may be replaced by the interface identifier “swp2”, followed by the tag “ipv6” specifying that interface “swp2” uses ipv6 addressing. Depending on the implementation of the network, interfaces “swp1” and “swp2” may use ipv4 addressing instead, in which case the tag “ipv4” is used. Whether an interface uses ipv6 or ipv4 addressing may be specified by the user via network topology 10 (or other user input, not depicted in
The following interface template for a “leaf” node is instantiated once per each host facing interface of r1:
For interface “swp10” (i.e., a host facing interface) of node “r1”, the placeholder <host-any> may be replaced by the interface identifier “swp10”, followed by the tag “ipv6” specifying that interface “swp10” uses ipv6 addressing. Depending on the implementation of the network, interface “swp10” may use ipv4 addressing instead, in which case the tag “ipv4” is used.
Assuming AS number 65000 is used, the following is an automatically generated configuration file for node r1:
Next, a discussion is provided for the instantiation of the node and interface BGP templates associated with the “midsp” node r3. The following node template for a “midsp” node is instantiated once for node r3:
Any placeholders may be appropriately completed along with the instantiation of the template. For instance, the <AS number> placeholder may be specified as 65000. For node r3, the <id> placeholder may be specified as 0.0.0.3, in accordance with the external node identifier 0.0.0.3 being assigned to node r3 in the DOT file.
The interface template for a “midsp” node is instantiated once per node interface. For “midsp” nodes, there are two variations of the interface template. One variation is used if the node interface is communicatively coupled to a node that is a leaf node:
Another variation is used if the node interface is communicatively coupled to a node that is a “spine” node (i.e., a “spine” node including a “midsp” and a “topsp” node):
As one example, since interface “swp1” of node “r3” is communicatively coupled to “leaf” node r1, the interface template corresponding to interface “swp1” of node “r3” is:
As another example, since interface “swp3” of node “r3” is communicatively coupled to the “topsp” node r9, the interface template corresponding to interface “swp3” of node “r3” is:
Assuming ipv6 addressing and the AS number of 65000, the following is an automatically generated configuration file for node r3:
Next, a discussion is provided for the instantiation of the node and interface BGP templates associated with the “topsp” node r9. The following node template for a “topsp” node is instantiated once for node r9:
Any placeholders may be appropriately completed along with the instantiation of the template. For instance, the <AS number> placeholder may be specified as 65000. For node r9, the <id> placeholder may be specified as 0.0.0.9, in accordance with the external node identifier 0.0.0.9 being assigned to node r9 in the DOT file.
The following interface template for a “topsp” node is instantiated once per node interface:
While the discussion above has focused on BGP templates, OSPF templates may alternatively be used.
A discussion is now provided for the instantiation of the node and interface OSPF templates associated with the “leaf” node r1. The following node template for a “leaf” node is instantiated once for node r1:
Any placeholders may be appropriately completed along with the instantiation of the template. For node r1, the <id> placeholder may be specified as 0.0.0.1, in accordance with the external node identifier 0.0.0.1 being assigned to node r1 in the DOT file.
The following interface template for a “leaf” node is instantiated once per router facing interface of r1:
For interface “swp1” of node “r1”, the placeholder <any> may be replaced by the interface identifier “swp1”. The placeholder <clusterid> may be replaced by 1.1.1.1, since “swp1” of node “r1” is connected to port of “swp1” of node “r3”, and node “r3” is in cluster 1.1.1.1. An interface template corresponding to interface “swp2” of node “r1” may be instantiated in a similar manner.
The following interface template for a “leaf” node is instantiated once per each host facing interface of r1:
For interface “swp10” (i.e., a host facing interface) of node “r1”, the placeholder <host-any> may be replaced by the interface identifier “swp10”, followed by the tag “ipv6” specifying that interface “swp10” uses ipv6 addressing. Depending on the implementation of the network, interface “swp10” may use ipv4 addressing instead, in which case the tag “ipv4” is used. The placeholder <clusterid> may be replaced by the cluster corresponding to node “r1”, which in this case is 1.1.1.1.
The following is the automatically generated configuration file for node r1:
Next, a discussion is provided for the instantiation of the node and interface OSPF templates associated with the “midsp” node r3. The following node template for a “midsp” node is instantiated once for node r3:
Any placeholders may be appropriately completed along with the instantiation of the template. For node r3, the <id> placeholder may be specified as 0.0.0.3, in accordance with the external node identifier 0.0.0.3 being assigned to node r3 in the DOT file.
The interface template for a “midsp” node will be instantiate once per node interface. For “midsp” nodes, there are two variations of the interface template. One variation is used if the node interface is communicatively coupled to a node that is a “leaf” node:
Another variation is used if the node interface is communicatively coupled to a node that is a “topsp” node:
As one example, since interface “swp1” of node “r3” is communicatively coupled to “leaf” node r1, the template for interface “swp1” of node “r3” is:
where the placeholder <to-leaf > is replaced by the interface identifier “swp1”, and the placeholder <clusterid> is replaced by 1.1.1.1, since “swp1” of node “r3” is connected to port of “swp1” of node “r1”, and node “r1” is in cluster 1.1.1.1.
As another example, since interface “swp3” of node “r3” is communicatively coupled to the “topsp” node r9, the template for interface “swp3” of node “r3” is:
The following is an automatically generated configuration file for node r3:
Next, a discussion is provided for the instantiation of the node and interface OSPF templates associated with the “topsp” node r9. The following node template for a “topsp” node is instantiated once for node r9:
Any placeholders may be appropriately completed along with the instantiation of the template. For node r9, the <id> placeholder may be specified as 0.0.0.9, in accordance with the external node identifier 0.0.0.9 being assigned to node r9 in the DOT file.
The following interface template for a “topsp” node is instantiated once per node interface:
For interface “swp1” of node “r9”, the placeholder <any> may be replaced by interface identifier “swp1”. Templates for other interfaces of node “r9” may be instantiated in a similar manner. The following is an automatically generated configuration file for node r9:
Automatically generated BGP and OSPF routing configuration files for nodes r1, r3 and r9 are summarized in
It is noted that the above-described interface templates have certain advantages as compared to the neighbor specification currently used in BGP. Today, BGP neighbors are specified in the configuration with peering addresses. As the network scales, managing and configuring the peering addresses can be quite cumbersome and error-prone. In the above-described interface templates, neighbors are specified as interfaces, which can yield a significant operational advantage. In one embodiment of the invention, the routing configuration file generator 18 discovers the peering address for each interface through neighbor addresses 16 and notifies the connected clients.
It is also noted that the above-described templates for originating interface prefixes also have certain advantages to the BGP configuration currently used for originating connected prefixes. Today, a BGP configuration for originating connected prefixes involves a ‘network’ statement as follows:
As described above, an extension to the network statement is used so that interfaces can be used instead.
Returning to
Another input to the routing configuration file generator 18 is neighbor addresses 16. Some routing protocols require the IP addresses of node neighbors (i.e., directly connected neighbors of a node) to be specified in the routing configuration file. In one embodiment of the invention, link local addresses are assigned to node neighbors, eliminating the need to acquire the IP addresses of the node neighbors. Link local addresses are, in many cases, generated automatically based on the media access control (MAC) address of a node and a well-defined prefix fe80:.
As a specific example, link local addresses may be utilized in a BGP configuration file. As is known, the following BGP command is used to start a TCP connection:
where <address> is a placeholder for the remote peer's L3/IP address, <ASx> is a placeholder for Autonomous System X and <ASy> is a placeholder for Autonomous System Y.
One way of acquiring the remote peer's L3/IP address is to discover the remote peer's link local address. In one embodiment of the invention, link-local addresses (discovered via the well known IPv6 neighbor discovery protocols) are used for BGP peering (i.e., link-local address is substituted in place of the <address> placeholder).
In step 112, the interface template corresponding to the node type (and optionally an interface type, if determined in step 110) is applied or instantiated. In step 114, it is determined whether the first node has additional interfaces. If the first node has additional interfaces, the next interface is selected at step 116, and the routine is repeated from step 110. If the first node does not have additional interfaces, it is determined in step 118 whether there are additional nodes in the network topology that have not been processed. If so, the next node is selected in step 120, and the routine is repeated from step 104. If not, the routine terminates.
As is apparent from the foregoing discussion, aspects of the present invention involve the use of various computer systems and computer readable storage media having computer-readable instructions stored thereon.
Computer system 200 includes a bus 202 or other communication mechanism for communicating information, and a processor 204 coupled with the bus 202 for processing information. Computer system 200 also includes a main memory 206, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 202 for storing information and instructions to be executed by processor 204. Main memory 206 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 204. Computer system 200 further includes a read only memory (ROM) 208 or other static storage device coupled to the bus 202 for storing static information and instructions for the processor 204. A storage device 210, which may be one or more of a floppy disk, a flexible disk, a hard disk, flash memory-based storage medium, magnetic tape or other magnetic storage medium, a compact disk (CD)-ROM, a digital versatile disk (DVD)-ROM, or other optical storage medium, or any other storage medium from which processor 204 can read, is provided and coupled to the bus 202 for storing information and instructions (e.g., operating systems, applications programs and the like).
Computer system 200 may be coupled via the bus 202 to a display 212, such as a flat panel display, for displaying information to a computer user. An input device 214, such as a keyboard including alphanumeric and other keys, may be coupled to the bus 202 for communicating information and command selections to the processor 204. Another type of user input device is cursor control device 216, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 204 and for controlling cursor movement on the display 212. Other user interface devices, such as microphones, speakers, etc. are not shown in detail, but may be involved with the receipt of user input and/or presentation of output.
The processes referred to herein may be implemented by processor 204 executing appropriate sequences of computer-readable instructions contained in main memory 206. Such instructions may be read into main memory 206 from another computer-readable medium, such as storage device 210, and execution of the sequences of instructions contained in the main memory 206 causes the processor 204 to perform the associated actions. In alternative embodiments, hard-wired circuitry or firmware-controlled processing units (e.g., field programmable gate arrays) may be used in place of or in combination with processor 204 and its associated computer software instructions to implement the invention. The computer-readable instructions may be rendered in any computer language including, without limitation, C#, C/C++, Fortran, COBOL, PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), and the like, as well as object-oriented environments such as the Common Object Request Broker Architecture (CORBA), Java™ and the like. In general, all of the aforementioned terms are meant to encompass any series of logical steps performed in a sequence to accomplish a given purpose, which is the hallmark of any computer-executable application. Unless specifically stated otherwise, it should be appreciated that throughout the description of the present invention, use of terms such as “processing”, “computing”, “calculating”, “determining”, “displaying” or the like, refer to the action and processes of an appropriately programmed computer system, such as computer system 200 or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within its registers and memories into other data similarly represented as physical quantities within its memories or registers or other such information storage, transmission or display devices.
Computer system 200 also includes a communication interface 218 coupled to the bus 202. Communication interface 218 provides a two-way data communication channel with a computer network, which provides connectivity to and among the various computer systems discussed above. For example, communication interface 218 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN, which itself is communicatively coupled to the Internet through one or more Internet service provider networks. The precise details of such communication paths are not critical to the present invention. What is important is that computer system 200 can send and receive messages and data through the communication interface 218 and in that way communicate with hosts accessible via the Internet.
Thus, methods and systems for automatically generating routing configuration files based on a network topology and a collection of routing configuration templates have been described. It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6587874 | Golla et al. | Jul 2003 | B1 |
| 7523185 | Ng | Apr 2009 | B1 |
| 7603445 | Fehrle | Oct 2009 | B1 |
| 7865577 | O'Neil | Jan 2011 | B1 |
| 8122110 | Wilbur et al. | Feb 2012 | B1 |
| 8213453 | Voruganti | Jul 2012 | B1 |
| 8335171 | Purkayastha | Dec 2012 | B1 |
| 20020126642 | Shitama | Sep 2002 | A1 |
| 20020165961 | Everdell | Nov 2002 | A1 |
| 20020194497 | McGuire | Dec 2002 | A1 |
| 20050015777 | Liss | Jan 2005 | A1 |
| 20050076144 | Boylan | Apr 2005 | A1 |
| 20050198247 | Perry | Sep 2005 | A1 |
| 20050240990 | Trutner | Oct 2005 | A1 |
| 20070230367 | Chitale | Oct 2007 | A1 |
| 20090043912 | Archer | Feb 2009 | A1 |
| 20090198707 | Rohner | Aug 2009 | A1 |
| 20100042708 | Stamler et al. | Feb 2010 | A1 |
| 20100054156 | DeHaan | Mar 2010 | A1 |
| 20100061242 | Sindhu | Mar 2010 | A1 |
| 20100150025 | Oman | Jun 2010 | A1 |
| 20100165877 | Shukla | Jul 2010 | A1 |
| 20100208615 | Soon et al. | Aug 2010 | A1 |
| 20100268803 | Calippee | Oct 2010 | A1 |
| 20100299414 | Nyman | Nov 2010 | A1 |
| 20110087757 | Paalanen | Apr 2011 | A1 |
| 20130132850 | Subramanian | May 2013 | A1 |
| 20130254405 | Nadaf | Sep 2013 | A1 |
| 20130332996 | Fiala | Dec 2013 | A1 |
| 20140153437 | Tracy | Jun 2014 | A1 |
| 20140241205 | Virk et al. | Aug 2014 | A1 |
| 20140280801 | Cardona | Sep 2014 | A1 |
| Entry |
|---|
| D'Ltri, “RPSL and rpsltool: Automatic generation of BGP configurations and filters”, Trex Workshop 2012 PPT (Sep. 14, 2012), 28 pgs. |
| Lapukhov; et al., “Using BGP for routing in large-scale data centers”, IDR (Aug. 10, 2012), 10 pgs. |
| Number | Date | Country | |
|---|---|---|---|
| 20140376402 A1 | Dec 2014 | US |
