Techniques for allowing software defined (SD) network fabrics to accept network devices from other fabric technologies

Techniques and apparatus for allowing a network fabric to accept network devices associated with other fabric networks are described. An example technique involves establishing a communication session between a first network node and a first control plane of the network fabric, wherein the first network node supports a second control plane different from the first control plane; First routing information from the first network node is imported into a first routing table of the first control plane. Second routing information from a second network node is imported into a second routing table of the first network node.

TECHNICAL FIELD

Embodiments presented in this disclosure generally relate to network fabrics, and more specifically, to techniques for allowing a network fabric to accept network devices associated with other fabric networks.

BACKGROUND

Many applications may involve communications across multiple network fabrics. The devices in different network fabrics establish communication pathways with each other through border nodes in the fabrics. These border nodes are responsible for establishing and maintaining the communication pathways between the fabrics and for routing incoming and outgoing packets to their destinations.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

One embodiment presented in this disclosure is a computer-implemented method. The computer-implemented method includes establishing, by a controller of a first control plane of a network fabric, a communication session between a first network node and the first control plane of the network fabric. The first network node supports a second control plane different from the first control plane. The computer-implemented method also includes importing, by the controller via the communication session, first routing information from the first network node into a first routing table of the first control plane. The first routing information includes a first endpoint identifier of the first network node. The first endpoint identifier is associated with a first overlay identifier for the first network node. The computer-implemented method further includes exporting, by the controller via the communication session, second routing information from at least one second network node into a second routing table of the first network node.

Another embodiment presented in this disclosure is a network device. The network device includes a processor and a memory containing a program that, when executed by the processor, performs an operation. The operation includes establishing a communication session between a first network node and a first control plane of a network fabric. The first network node supports a second control plane different from the first control plane and the network device is a controller of the first control plane. The operation also includes importing, via the communication session, first routing information from the first network node into a first routing table of the first control plane. The first routing information includes a first endpoint identifier of the first network node. The first endpoint identifier is associated with a first overlay identifier for the first network node. The operation further includes exporting, via the communication session, second routing information from at least one second network node into a second routing table of the first network node.

Another embodiment presented in this disclosure is a computer-readable medium. The computer-readable medium includes computer program code that, when executed by one or more processors, performs an operation. The operation includes establishing, by a controller of a first control plane of a network fabric, a communication session between a first network node and the first control plane of the network fabric. The first network node supports a second control plane different from the first control plane. The operation also includes importing, by the controller via the communication session, first routing information from the first network node into a first routing table of the first control plane. The first routing information includes a first endpoint identifier of the first network node. The first endpoint identifier is associated with a first overlay identifier for the first network node. The operation further includes exporting, by the controller via the communication session, second routing information from at least one second network node into a second routing table of the first network node.

EXAMPLE EMBODIMENTS

In conventional systems, there may be limited interoperability between different network fabrics. In some cases, for example, the network fabrics may use a common data-path (or data plane) technology (e.g., Layer 2 (L2) protocol), but may support different control plane technology (e.g., L3 protocols). In these cases, the first network fabric may be able to exchange communications with another second network fabric via border nodes. For example, one or more border nodes in the first network fabric may establish communication pathways with one or more border nodes in the second network fabric, and communications (and other information) may be routed between the first and second network fabrics via the communication pathways.

However, while communications between the network fabrics may be facilitated with border nodes, the first network fabric may not be able to accept (or support) network devices (or nodes) from the second network fabric as part of the first network fabric. Similarly, the second network fabric may not be able to accept (or support) network devices (or nodes) from the first network fabric as part of the second network fabric. In one reference example, assume the first network fabric supports software-defined (SD) access technology (e.g., an SD-access network fabric) and the second network fabric supports Border Gateway Protocol (BGP) Ethernet Virtual Private Network (EVPN) (BGP-EVPN) (e.g., a BGP-EVPN network fabric). In this example, because the SD-access network fabric supports different control plane technology than the BGP-EVPN network fabric, the SD-access network fabric may not be able to accept nodes of the BGP-EVPN network fabric as part of the SD-access fabric, and vice versa. That is, the SD-access network fabric may not be able to directly interact with the BGP-EVPN nodes (as part of managing or configuring the SD-access network fabric), add or remove the BGP-EVPN nodes from the SD-access network fabric, integrate services provided by the BGP-EVPN network fabric with the SD-access network fabric, etc.

To address this, embodiments described herein provide techniques that allow a network fabric to directly interact with nodes of another network fabric, where the network fabrics support different control plane technologies. More specifically, embodiments enable a first network fabric to accept (or support or add), as a part of the first network fabric, a network device (or node) associated with (or that supports) a different second network fabric. As described below, embodiments may import routing information associated with the network device (of the second network fabric) into a control plane associated with the first network fabric and maintain the routing information associated with the network device (of the second network fabric) during the import. Additionally, embodiments can enable (i) the control plane of the first network fabric to reflect identifying information of one or more nodes across the first network fabric and the second network fabric and (ii) the control plane of the second network fabric to reflect identifying information of one or more nodes across the first network fabric and the second network fabric.

FIG.1illustrates a networking system100. The networking system100(also referred to as network system) includes a border node102and a border node104in a network fabric110. In some examples, the border nodes102and104sever as an external ingress and egress function for the network fabric110. In some examples, the networking system100may use software to form software-defined (SD) networks. For example, the network fabric110may include an SD-access (SDA) fabric including endpoints140-1to140-n. In an example where the network fabric110is a SDA fabric, the endpoints140-1to140-nmay be referred to as fabric edges (FEs) and may include associated endpoint identifiers (EIDs) for identification in the network fabric110.

The border nodes102and104are associated with a first external traffic connection such as the external route120associated with the border node102and the external route130associated with the border node104. In some examples, the external routes120and130are SD wide area networks (SD-WAN) and/or networks provided by one or more service providers providing access to an external network160via the external connection nodes122and124. In some examples, the external network160includes external networks, such as the Internet, a service provider external network, another fabric external to the network fabric110, etc. In one particular embodiment, the external network160is a fabric network that supports BGP-EVPN (e.g., a BGP-EVPN network fabric). The external network160includes network nodes170-1to170-n. In embodiments where the external network160is a BGP-EVPN network fabric, the BGP-EVPN network fabric may implement a spine-leaf architecture, where the network nodes170-1to170-nare leaf switches. In various embodiments, the leaf switches170-1to170-nmay retain addressing information for devices connected thereto or that have previously been in communication with the switch in an internal cache.

The border nodes102and104maintain connections to the external network160through the external routes120and130via network connections126and128, respectively. In some examples, the border nodes102and104also maintain alternate connections to the external network160through the alternate external connections142and144, respectively. However, while the network fabric110can communicate with the external network160via border nodes102and104, the network fabric110generally cannot support adding (or incorporating) network nodes170-1to170-nas part of the network fabric110.

In one embodiment described herein, a network fabric is configured to support one or more network nodes associated with a different network fabric.FIG.2, for example, illustrates an example network architecture200, which includes a network fabric210, a central controller220, and a host tracking database240. The network fabric210includes one or more network nodes1401-nand one or more network nodes1701-n.

In one embodiment, the network architecture200may be implemented as a Cisco Application Center Infrastructure (ACI) or SDN. From a management perspective, the central controller220(e.g., SDN controller) (also referred to as the Application Policy Infrastructure Controller (APIC) manages and configures the policy on one or more of the nodes1401-nin the network fabric210. The central controller220can act as a central repository for all policies and has the ability to rapidly deploy and re-deploy hardware, as needed, based on network performance. The SDN may also serve as a platform for other services that are performed within the data center or cloud environment. For example, through the use of the central controller220, third party services may be integrated for advanced security, load balancing, and monitoring. Note that ACI is merely used as an example of an SDN platform. The embodiments herein are not limited to such and can be used with any other suitable SDN platform.

In the network architecture200, network nodes1401-nmay be initially configured to support SDN technology (e.g., SDN-capable network nodes), and the network nodes1701-nmay not be initially configured to support SDN technology (e.g., non-SDN-capable network nodes). For example, the network nodes1401-nmay support a first control plane technology and the network nodes1701-nmay support a different second control plane technology. In some embodiments, the control plane supported by the network nodes1401-nmay use a routing protocol, such as Locator/ID Separation Protocol (LISP), to route communication traffic, and the control plane supported by the network nodes1701-nmay use a different routing protocol, such as BGP-EVPN to route communication traffic. In routing protocols, such as BGP-EVPN, there may not be a central control plane, whereas in routing protocols, such as LISP, there may be a central control plane (e.g., central controller220). In examples where the network nodes1701-nsupport BGP-EVPN, the network nodes1701-nmay be referred to as BGP-EVPN leafs (or leaf nodes).

Embodiments herein can enable the network architecture200to support both network nodes1401-n(SDN-capable network nodes) and network nodes1701-n(non SDN-capable network nodes) as part of the network fabric110(when implanted as a SDN fabric). As shown, the central controller220includes a routing component212, and each of the network nodes1701-nincludes a routing component214. The routing component212is generally configured to implement one or more techniques described herein for enabling the network fabric210to directly interact with (and support) network nodes1701-n, which do not have native support for the control plane technology used by the network fabric210. Similarly, the routing component214is generally configured to implement one or more techniques described herein for enabling the network nodes1701-nto be accepted as part of the network fabric210, e.g., as FEs.

In one embodiment, the routing components212,214are configured to establish communication sessions with each other. For example, each routing component214can establish a communication session with the routing component212. Once the communication sessions are established, the routing component212can import routing information associated with each of the network nodes1701-ninto a routing table associated with the central controller220. Similarly, each routing component214can import routing information maintained by the routing component212(for each of the network nodes1401-n) into a routing table maintained by the routing component214. In one embodiment, the routing table associated with the central controller220may be located within the host tracking database240.

Additionally, in embodiments herein, the routing component212may maintain original L2 overlay information associated with the network nodes1701-nwithin the routing table in the host tracking database240. For example, the L2 overlay information can include at least one of a routing locator (RLOC), transport location (TLOC), or virtual tunnel endpoint (VTEP). Similarly, each routing component214can maintain original L2 overlay information associated with the network node1401-nwithin the routing table maintained by the routing component214.

In one embodiment, the central controller220may be implemented with a general-purpose computing device or may be implemented with multiple computing devices distributed across a network. The central controller220can include a processor, communication ports, memory, and storage. The processor may be any processing element capable of performing the functions described herein. The processor can represents a single processor, multiple processors, a processor with multiple cores, and combinations thereof. The communication ports facilitate communication between the central controller220and other network devices (e.g., network nodes1401-n). The memory may be either volatile or non-volatile memory and include RAM, flash, cache, disk drives and the like. The memory may be divided into different memory storage elements such as RAM and one or more hard disk drives. The memory may include the routing component212, which may include hardware components, software modules, or combinations thereof. The routing component212is described in more detail below. The storage may include a routing table for storing routing information associated with one or more network nodes of the network fabric.

In one embodiment, each network node170may include a processor, communication ports, memory, and storage. The processor may be any processing element capable of performing the functions described herein. The processor can represents a single processor, multiple processors, a processor with multiple cores, and combinations thereof. The communication ports facilitate communication between the network node170and other network devices (e.g., central controller220, network nodes170, etc.). The memory may be either volatile or non-volatile memory and include RAM, flash, cache, disk drives and the like. The memory may be divided into different memory storage elements such as RAM and one or more hard disk drives. The memory may include the routing component214, which may include hardware components, software modules, or combinations thereof. The routing component214is described in more detail below. The storage may include a routing table for storing routing information associated with one or more network nodes of the network fabric.

FIG.3illustrates an example implementation of accepting a leaf node into a network fabric210, which supports a different control plane, according to one embodiment. Here, the network fabric210includes network nodes1401-n(e.g., FE-1 to FE-n) and network nodes1701-n(e.g., Leaf-1 to Leaf-N). The network nodes1401-nmay support the same L2 protocol (or data plane technology) (e.g., Virtual Extensible Local Area Network (VXLAN)) as network nodes1701-n, but the network nodes1401-nmay support a different control plane than network nodes1701-n. For instance, network nodes1401-nmay support a central control plane (e.g., SDN), whereas network nodes1701-nmay not support a central control plane. In this particular embodiment, the network nodes1401-nsupport a central control plane that uses LISP to distribute routing information (e.g., via the central controller220), and the network nodes1701-nsupport a control plane that uses BGP-EVPN to distribute routing information (e.g., without a central controller).

The network nodes1401-nmay be connected to hosts3401-n, respectively. The network nodes1701-nmay be connected to hosts3421-n, respectively. In particular, network node140-1is connected to host340-1, which has IP address “10.1.1.2,” network node140-nis connected to host340-n, which has IP address “10.1.1.4,” network node170-1is connected to host342-1, which has IP address “10.1.1.5,” and network node170-nis connected to host342-n, which has IP address “10.1.1.3.”

In this embodiment, to enable each network node1701-nto join the network fabric210as an FE node, a BGP-EVPN communication session360is established between the central controller220and each network node1701-n. For each network node170, the central controller220may appear as a BGP route reflector (RR). The same instance-identifiers (for each pool shared by BGP-EVPN) may be configured on each network node170.

The central controller220(using the routing component212) may be configured to accept, via the BGP-EVPN communication session3601-n, the EVPN routes (along with VTEP info) coming from each of the network nodes170. The central controller220can add a LISP map-server entry for each corresponding instance-identifier in the routing table310. In some embodiments, the central controller220may be configured with a set of command line interfaces (CLIs) to accept the EVPN routes coming from each of the network nodes170into the routing table310. In some embodiments, the central controller220can mark the LISP map-server entries with an additional flag to indicate that it belongs to an EVPN route or LISP route. Additionally, in some embodiments, the central controller220(using the routing component212) may be configured with a set of CLIs to export all of the routes (along with the RLOC/VTEP information) to each of the network nodes1701-nvia respective BGP-EVPN communication sessions3601-n.

Once the LISP routes are exported via the central controller220, the network nodes1701-ncan receive all the BGP-EVPN routes and LISP routes (along with the VTEP/RLOC information) using a BGP-EVPN routing protocol and can program their hardware accordingly. For example, each network node170may maintain a routing table320, which includes the BGP-EVPN routes and LISP routes.

Once all BGP-EVPN routes are present in the routing table310, the central controller220may receive (e.g., from an edge device) a request for a route behind one or more of the network nodes170. In response to the request, the central controller220can respond with a map-cache pointing towards the VTEP (in terms of RLOC) of the network node170. Additionally, since the data-plane in both LISP and BGP-EVPN may be the same (e.g., VXLAN), the data path can work seamlessly without each side knowing what the other side is.

In the particular embodiment shown inFIG.3, the RLOC/TLOC/VTEP information associated with each of the network nodes1701-nis preserved as the network nodes1701-njoin the network fabric210. To preserve the RLOC/TLOC/VTEP information, embodiments can modify the update of the endpoint-ids (EIDs) for each network node170, so that as the EID reaches the central controller220, its VTEP is preserved. In other words, the VTEP information may be maintained on import of the BGP-EVPN routes to the central controller220. The EID may be registered to the network fabric210(with its preserved VTEP).

As also shown inFIG.3, the RLOC/TLOC/VTEP information associated with each of the network nodes1401-nis preserved as the routing information is exported to BGP-EVPN control plane. For example, the EIDs (associated with network nodes1401-n) may be exported to the BGP-EVPN control plane, while maintaining their original VTEP information. The EIDs received from a network node170may be reflected to other network nodes170using the fabric control plane.

FIG.4is a flowchart of a method400for accepting at least one (first) network node (e.g., leaf node(s), such as network node(s)170) into a network fabric (e.g., network fabric210) that supports a different control plane than the at least one (first) network node, according to one embodiment. The method400may be performed by a central controller (e.g., central controller220) of a control plane supported by the network fabric.

Method400may enter at block402, where the central controller configures at least one communication session (e.g., communication session(s)360) between the at least one first network node and a control plane of the network fabric. The control plane of the network fabric may be a central control plane, e.g., based on LISP. The control plane supported by the at least one first network node may be a control plane based on BGP-EVPN. In some embodiments, the communication session may be established using the control plane supported by the first network node. For example, the communication session can include a BGP-EVPN communication session.

At block404, the central controller imports routing information from the at least one first network node into a routing table (e.g., routing table310) of the control plane of the network fabric. In one embodiment, the routing information from the at least one first network node may include an EID for each of the at least one first network node. The EID may be associated with a VTEP for the at least one first network node.

At block406, the central controller exports routing information from at least one second network node (e.g., network node(s)140) into a routing table of the at least one first network node. The routing information from the at least one second network node may include an EID for each of the at least one second network node. The EID may be associated with a VTEP for the at least one second network node.

FIG.5is a flowchart of a method500for accepting at least one (first) network node (e.g., leaf node(s), such as network node(s)170) into a network fabric (e.g., network fabric210) that supports a different control plane than the at least one (first) network node, according to one embodiment. The method500may be performed by a central controller (e.g., central controller220) of a control plane supported by the network fabric.

Method500may enter at block502, where the central controller configures at least one communication session (e.g., communication session(s)360) between each first network node and a control plane of the network fabric. At block504, the central controller configures same instance-ids on each first network node. The instance-ids may be associated with a pool shared by the control plane (e.g., BGP-EVPN) of the first network nodes.

At block506, the central controller imports first routing information from each of the first network nodes into a first routing table (e.g., routing table310) of the control plane of the network fabric. In one embodiment, the central controller may use a set of CLIs to accept the first routing information coming from each of the first network nodes and may add entries for the first routing information into the first routing table. The first routing information may include EVPN route information (along with the original VTEP information) for each of the first network nodes. That is, the original VTEP information from each first network node may be maintained during the import into the first routing table.

At block508, the central controller provides, within the first routing table, an indication of the supported control plane for the first routing information. For example, the central controller can mark the added entries (for the imported first routing information in the first routing table) with a flag to indicate that the routing information includes EVPN route information.

At block510, the central controller exports second routing information from each of second network nodes (e.g., network nodes140) into at least one second routing table (e.g., routing table320) of the at least one first network node. In one embodiment, the central controller may use a set of CLIs to export the second routing information (from each of the second network nodes) into the at least one second routing table. The second routing information may include LISP route information (along with the original RLOC/VTEP information) for each of the second network nodes.

At block512, the central controller provides, within each at least one second routing table, an indication of the supported control plane for the second routing information. For example, the central controller can mark the added entries (for the imported second routing information in the second routing table) with a flag to indicate that the routing information includes LISP route information.

In some embodiments, the method500may further include the central controller receiving a request for a route that is behind a given network node170. In response to the request, the central controller can respond with routing information that indicates the original VTEP associated with that network node170(in terms of RLOC). The method500may then exit.