Patent ID: 12255812

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating an example network100including a data center102in which examples of the techniques described herein may be implemented. In general, data center102provides an operating environment for applications and services for customers120coupled to the data center, e.g., by a service provider network (not shown). Data center102may, for example, host infrastructure equipment, such as networking and storage systems, redundant power supplies, and environmental controls. A service provider network that couples customers120to data center102may be coupled to one or more networks administered by other providers, and may thus form part of a large-scale public network infrastructure, e.g., the Internet.

In some examples, data center102represents one of many geographically distributed network data centers. As illustrated in the examples ofFIG.1, data center102may be a facility that provides network services for customers120. Customers120may be collective entities such as enterprises and governments or individuals. For example, a network data center may host web services for several enterprises and end users. Other exemplary services may include data storage, virtual private networks, traffic engineering, file service, data mining, scientific- or super-computing, and so on. In some embodiments, data center102may be individual network servers, network peers, or otherwise.

In this example, data center102includes a set of storage systems and application servers108A-108N (servers108) interconnected via interconnected topology118, which may comprise a switch fabric provided by one or more tiers of physical network switches and routers. Servers108may be respective bare metal servers (BMSs). In the examples ofFIG.1, interconnected topology118includes chassis switches104A-104N (chassis switches104) and top-of-rack (TOR) switches106A-106N (TOR switches106). For instance, chassis switches104may form spine nodes of a spine and leaf topology, while TOR switches106may form leaf nodes of the spine and leaf topology. It should be understood that other topologies may be used in other examples, as discussed in greater detail below. Servers108provide execution and storage environments for applications and data associated with customers120and may be physical servers, virtual machines or combinations thereof.

In general, interconnected topology118represents layer two (L2) and (in some examples) layer three (L3) switching and routing components that provide point-to-point connectivity between servers108. In one example, interconnected topology118comprises a set of interconnected, high-performance yet off-the-shelf packet-based routers and switches that implement industry standard protocols. In one example, interconnected topology118may comprise off-the-shelf components that provide Internet Protocol (IP) over an Ethernet (IPoE) point-to-point connectivity.

InFIG.1, virtual network controller112provides a high-level controller for configuring and managing routing and switching infrastructure of data center102. Details of virtual network controller112operating in conjunction with other devices of network100or other software-defined networks can be found in International Application Number PCT/US2013/044378, filed May 6, 2013, and in U.S. patent application Ser. No. 14/226,509, filed Mar. 26, 2014, and issued as U.S. Pat. No. 9,571,394, the entire contents of each of which are incorporated by reference. Virtual network controller112may represent, for example, a software defined network (SDN) controller that communicates and manages the devices of data center102using an SDN protocol, such as the OpenFlow protocol. Additional details regarding OpenFlow are found in “OpenFlow Switch Specification version 1.1.0”, OpenFlow Consortium, February 2011, which is incorporated by reference herein. In addition, controller112may communicate with the routing and switching infrastructure of data center102using other interface types, such as a Simple Network Management Protocol (SNMP) interface, path computation element protocol (PCEP) interface, a Device Management Interface (DMI), a CLI, Interface to the Routing System (IRS), or any other node configuration interface.

Virtual network controller112provides a logically—and in some cases, physically—centralized controller for facilitating operation of one or more virtual networks within data center102in accordance with examples of this disclosure. In some examples, virtual network controller112may operate in response to configuration input received from network administrator110. Additional information regarding virtual network controller112operating in conjunction with other devices of data center102can be found in International Application Number PCT/US2013/044378, filed Jun. 5, 2013, and entitled PHYSICAL PATH DETERMINATION FOR VIRTUAL NETWORK PACKET FLOWS, which is hereby incorporated by reference.

Although not shown, data center102may also include one or more additional switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices.

In general, network traffic within interconnected topology118, such as packet flows between servers108, can traverse the physical network of interconnected topology118using many different physical paths. For example, a “packet flow” can be defined by values used in a header of a packet, such as the network “five-tuple,” i.e., a source IP address, destination IP address, source port and destination port that are used to route packets through the physical network, and a communication protocol. For example, the protocol specifies the communications protocol, such as TCP or UDP, and Source port and Destination port refer to source and destination ports of the connection.

A set of one or more packet data units (PDUs) that match a particular flow entry represent a flow. Flows may be broadly classified using any parameter of a PDU, such as source and destination data link (e.g., MAC) and network (e.g., IP) addresses, a Virtual Local Area Network (VLAN) tag, transport layer information, a Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) label, and an ingress port of a network device receiving the flow. For example, a flow may be all PDUs transmitted in a Transmission Control Protocol (TCP) connection, all PDUs sourced by a particular MAC address or IP address, all PDUs having the same VLAN tag, or all PDUs received at the same switch port.

As shown in the examples ofFIG.1, each of TOR switches106is communicatively coupled to each of chassis switches104in interconnected topology118. Similarly, in this example, each of chassis switches104is communicatively coupled to each of TOR switches106. Accordingly, the number of paths from any one of TOR switches106to any other one of TOR switches106is equal to the number of chassis switches104, in this example. Although the letter “N” is used to represent undefined numbers of both TOR switches106and chassis switches104, it should be understood that there may be a different number of TOR switches106than chassis switches104.

In the examples ofFIG.1, interconnected topology118allows for multi-path forwarding. Multi-path forwarding has been deployed in various levels and scales of networks as a way to increase network capacity and resiliency. Developments have been made to multi-path systems to determine how to achieve balanced redistribution of traffic among the multiple paths and how to avoid packet reordering while packets are travelling on the different paths. TOR switches106may utilize hash tables to prevent packet reordering for a particular flow, as described in greater detail below. In general, to prevent packet reordering, once a flow is assigned to a path through interconnected topology118, all packets of the flow are sent along the same path. However, as also discussed in greater detail below, the techniques of this disclosure include moving a flow from one path to a different path through interconnected topology118while also preventing packet reordering.

Servers108may correspond to respective tenants of data center102. For example, servers108A may correspond to a first tenant, servers108B may correspond to a second tenant, and so on. Interconnected topology118allows for inter-tenant communication, e.g., between servers108A-108N. In accordance with the techniques of this disclosure, virtual network controller112may be configured to automatically configure one or more service devices to provide physical network functions (PNFs) to inter-tenant communications. The service devices may be, for example, TOR switches106, chassis switches104, or other devices connected thereto. In general, the service devices may be any International Organization for Standardization (ISO) Open Systems Interconnection (OSI) model Layer3Virtual Extensible LAN (VxLAN) Network Identifier (VNI) capable devices, which may be configured in active-active mode.

In general, virtual network controller112may configure the service devices to have service virtual routing and forwarding (VRF) tables specific to each set of tenant devices. For example, when servers108A host data for a first tenant and servers108B host data for a second tenant, chassis switches104may each have a first service VRF table for servers108A and a second service VRF table for servers108B. In this manner, when chassis switch104A receives a network communication (e.g., a packet) from one of servers108A destined for one of servers108B, chassis switch104A may apply the first service VRF table to the packet to determine one or more PNFs to apply to the packet. The PNFs may be, for example, firewall services, intrusion detection and prevention (IDP) services, load balancing services, or the like.

In some examples, virtual network controller112receives a high level configuration for the various network devices, e.g., from administrator110, and translates the high level configuration into low level configuration data. The high level configuration data may be vendor-neutral, whereas the low level configuration data may be vendor-specific, and thus, executable or otherwise usable by each respective one of chassis switches104, TOR switches106, and servers108. Details regarding translation of configuration data from high level configuration to low level configuration are explained in, e.g., Jiang et al., “TRANSLATING HIGH-LEVEL CONFIGURATION INSTRUCTIONS TO LOW-LEVEL DEVICE CONFIGURATION,” U.S. patent application Ser. No. 15/198,657, filed Jun. 30, 2016, the entire contents of which are hereby incorporated by reference.

The first service VRF table may identify an output interface (e.g., a logical interface or a physical interface) associated with a service device of chassis switch104A that performs the service. The output interface may direct traffic from a forwarding plane of chassis switch104A to a service plane in which the service device is positioned, or to an external service device. In either case, chassis switch104A may direct the traffic to the output interface to cause the service device to perform the service. In some examples, multiple services may be performed by one or more service devices. Ultimately, chassis switch104A may receive the processed traffic back from the service device(s), and use the second VRF table to determine an output interface by which to output the processed traffic to reach servers108B.

Interconnected topology118may be implemented in various ways, and does not necessarily include the devices or arrangement shown inFIG.1. In one example, interconnected topology118is implemented as a spine and leaf topology. In such an example, chassis switches104are configured as spine switches (e.g., Layer3switches) and TOR switches106are configured as leaf switches.

In another example, interconnected topology118is implemented as a Clos network with three or more stages. A spine and leaf network is functionally similar to a three-stage Clos network, and therefore, spine and leaf networks are sometimes referred to as folded three-stage Clos networks. In general, Clos networks include three or more stages: an ingress stage, one or more mid-stages, and an egress stage. Nodes of each stage are connected to each node of each neighboring stage. For example, each node of the ingress stage is connected to each node of the first mid-stage, and each node of the last mid-stage (which is also the first mid-stage in a three-stage Clos network) is connected to each node of the egress stage. An example Clos network is shown inFIG.2, as discussed in greater detail below.

In another example, interconnected topology118is implemented as a Virtual Chassis Fabric (VCF), e.g., as explained in Yafan An, “Tiers in Virtual Chassis Fabric,” Oct. 30, 2013, available at http://forums.juniper.net/t5/Data-Center-Technologists/Tiers-in-Virtual-Chassis-Fabric/ba-p/214765. A VCF allows interconnected topology118to be managed as a single device, e.g., by virtual network controller112. One example VCF implementation may be realized using four QFX5100-24Q switches from Juniper Networks, Inc., Sunnyvale, CA as spine switches and sixteen QFX5100-48S switches from Juniper Networks, Inc., Sunnyvale, CA as leaf switches. In this example, the spine switches support 48×10 Gigabit Ethernet (GbE) and 6×40 GbE interfaces, while each leaf uses 4×40 GbE interfaces as uplinks to the spine switches. This creates an oversubscription of 480:160 or 3:1 per leaf, in this example. Each leaf supports 48×10 GbE interfaces, such that the total port count is 768×10 GbE with 3:1 oversubscription.

In another example, interconnected topology118is implemented as an Internet protocol (IP) Fabric. An IP Fabric is made up of routing devices implementing a Border Gateway Protocol (BGP), and each of the routing devices is a BGP neighbor to each of the other devices in the IP Fabric. An example IP Fabric can be formed from four Juniper Networks QFX5100-24Q switches as spine switches and QFX5100-96S switches, available from Juniper Networks, Inc., Sunnyvale, CA, as leaf switches. Such an arrangement results in an IP Fabric of 3072×10 GbE usable ports. As an example, the leaves are constructed using the QFX5100-96S, and 8×40 GbE interfaces are used as uplinks into the spine, in this example. Because each leaf in this example has eight uplinks into the spine, the maximum width of the spine is eight in this example. Each 40 GbE interface per leaf connects to a separate spine-thus, each leaf consumes one 40 GbE interface per spine. To calculate the maximum size of the IP Fabric, the number of server interfaces is multiplied by the number of leaves supported by the spine.

In yet another example, rather than interconnected topology118ofFIG.1, servers108may be connected by an interconnected topology according to IEEE 802.1BR. In accordance with IEE 802.1BR, interconnected topology118may instead include two spine switches, multiple leaf nodes, and two or more satellite switches, such that there are two or more paths from any satellite switch to any other satellite switch. For example, in accordance with IEEE 802.1BR, there may be two controlling bridges in the position of chassis switches104and a plurality of port extenders in the position of TOR switches106, interconnected as shown in interconnected topology118.

In this manner, network100represents an example of a data center network including a first set of one or more server devices of the data center, the first set of server devices hosting data of a first tenant of the data center; a first network device of an interconnected topology communicatively coupled to the first set of one or more server devices, the first network device including a first service virtual routing and forwarding (VRF) table for the first set of server devices; a second set of one or more server devices of the data center, the second set of server devices hosting data of a second tenant of the data center; a second network device of the interconnected topology communicatively coupled to the second set of one or more server devices, the second leaf node device including a second VRF table for the second set of server devices; and one or more service devices that communicatively couple the first network device to the second network device, wherein the service devices include a third service VRF table for the first tenant and a fourth service VRF table for the second tenant, wherein the first network device applies the first service VRF table to network traffic flowing between the first set of server devices and the second set of server devices, wherein the second network device applies the second service VRF table to the network traffic flowing between the first set of server devices and the second set of server devices, and wherein the service devices apply services to the network traffic flowing between the first set of server devices and the second set of server devices using the third service VRF table and the fourth service VRF table.

FIG.2is a block diagram illustrating an example Clos network130. Clos network130, or a similar Clos network, may be used in place of interconnected topology118ofFIG.1. Clos network130includes three stages of switches: ingress switches132A-132N (ingress switches132), mid-stage switches134A-134N (mid-stage switches134), and egress switches136A-136N (egress switches136). Although the letter “N” is used to designate a variable number for each of ingress switches132, mid-stage switches134, and egress switches136, it should be understood that the number of switches included in each stage is not necessarily the same. That is, there may be different numbers of ingress switches132, mid-stage switches134, and egress switches136. Furthermore, although Clos network130includes three stages, it should be understood that a general Clos network may include any number of stages.

FIG.3is a block diagram illustrating an example IEEE 802.1BR network150with a multi-chassis link aggregation group (LAG) for resilient multi-pathing. Network150may be used in place of interconnected topology118ofFIG.1. Network150includes two controlling bridges150, which are coupled to each other and to a plurality of port extender devices154A-154N (port extenders154). Network150provides extended ports156. That is, each of port extenders154includes a plurality of ports. Although four ports are shown inFIG.3, it should be understood that each of port extenders154may have any number of ports.

FIG.4is a block diagram illustrating an example network system200including spine and leaf network devices configured to perform techniques of this disclosure. In particular, network system200includes leaf devices202A,202B,220A, and220B (leaf devices202,220), as well as service devices210A,210B (service devices210). Service devices210may correspond to spine devices of a spine and leaf topology, such as chassis switches104or TOR switches106ofFIG.1, mid-stage switches134ofFIG.2, or controlling bridges152ofFIG.3. Leaf devices202,220may correspond to leaf devices of the spine and leaf topology, such as TOR switches106or servers108ofFIG.1, ingress switches132and egress switches136ofFIG.2, or port extenders154ofFIG.3. Although in the example ofFIG.4leaf devices are shown, it should be understood that in other examples, spine devices may be coupled to service devices210, e.g., as explained with respect toFIG.5below.

In this example, leaf devices202may be referred to as “left” devices, while leaf devices220may be referred to as “right” devices. Accordingly, leaf devices202include left virtual routing and forwarding (VRF) table204′, while leaf devices220include right VRF table222′. Likewise, service devices210, in this example, include left VRF table204and right VRF table222. Furthermore, in leaf devices202, left VRF table204′ is separate from logical router VRF table206, while in leaf devices220, right VRF table222′ is separate from logical router VRF table224. Similarly, left VRF table204and right VRF table222of service devices210are separate from forwarding (FW) policy212.

Moreover, leaf devices202may correspond to one tenant of a data center including system200, while leaf devices220may correspond to a different tenant of the data center. Thus, logical router VRF table206may include data for forwarding network traffic in one or more bridge domains associated with one tenant, while logical router VRF table224may include data for forwarding network traffic in one or more different bridge domains associated with a different tenant.

Leaf devices202,220also include respective network interfaces, such as network interface cards (NICs) that may, e.g., operate according to the Ethernet protocol or aggregated Ethernet protocol. In particular, leaf device202A includes network interfaces208A-1and208A-2, leaf device202B includes network interfaces208B-1and208B-2, leaf device220A includes network interfaces226A-1and226A-2, and leaf device220B includes network interfaces226B-1and226B-2. Although not shown inFIG.4for brevity, service devices210should also be understood to include respective network interfaces. In this example, network interfaces208A-1and208B-1are coupled to a network interface of service device210A, while network interfaces208A-2and208B-2are coupled to a network interface of service device210B. Similarly, network interfaces226A-1and226B-1are coupled to a network interface of service device210A, while network interfaces226A-2and226B-2are coupled to a network interface of service device210B.

Service devices210include respective service units214A,214B (service units214) that perform physical network layer (PNF) functions on packets. Such services may include, for example, a firewall service, an intrusion detection and prevention (IDP) service, a quality of service (QOS) service, a load balancing service, or the like.

Service devices210may be International Organization for Standardization (ISO) Open Systems Interconnection (OSI) model Layer3Virtual Extensible LAN (VxLAN) Network Identifier (VNI) capable devices configured in active-active mode, in accordance with the techniques of this disclosure.

As shown in the example ofFIG.4, service device210A includes, for example, left VRF table204and right VRF table222, which are separate from FW policy212. Because left VRF table204and right VRF table222are used for performing services on inter-tenant communications, left VRF table204and right VRF table222may be referred to as “service VRFs.” A single virtual local area network (VLAN) and an associated bridge domain (VxLAN VNI) may be configured for such service VRFs on access ports to service devices210. In this manner, service device210A may perform services on inter-tenant communications. For example, leaf device202A (corresponding to one tenant) may send packet230to leaf device220A (corresponding to a different tenant). In particular, in order to send packet230to leaf device220A, leaf device202A may use left VRF table204′ to determine a next hop to which to direct packet230to reach leaf device220A, rather than logical router VRF table206. Logical router VRF table206may include data for reaching devices external to the data center, such as customers120ofFIG.1.

Accordingly, when service device210A receives packet230, service device210A may initially use left VRF table204to determine a device to which to forward packet230. In this example, left VRF table204may indicate that a packet received from leaf device202A destined for leaf device220A is to have a particular service performed, e.g., by214A. That is, left VRF table204of service device210A may define a logical interface by which to forward packet230to reach service unit214. Service unit214A may then perform one or more services on packet230.

After performing the services, service unit214A may forward packet230via a logical interface, by which service device210A receives the packet, e.g., in a forwarding plane of service device210A. Service device210A may then use right VRF table222to determine an interface by which to send packet230. In this example, right VRF table222indicates that packet230is to be forwarded via the network interface of service device210A that is coupled to leaf device220A. Thus, service device210A forwards the packet to leaf device220A.

Although not shown inFIG.4, it should be understood that system200may further include a software defined network (SDN) controller, such as virtual network controller112ofFIG.1. The SDN controller may configure leaf devices202,220and service devices210, e.g., by configuring left VRF tables204,204′, right VRF tables222,222′, logical router VRF206, and FW policy212, to cause service devices210to apply one or more PNFs to inter-tenant communications using service units214.

Although service devices210are shown as including service units214A,214B, it should be understood that in other examples, service units214A,214B may be included in one or more separate devices that are communicatively coupled to service devices210.

In some examples, service devices210may correspond to a service appliance including four PNFs, two in active/active mode and two in a redundant cluster, which may be treated as part of the service appliance itself. Spine devices where the PNFs are attached may be configured in the role of a service chaining gateway. Such spine devices may be a subset of all devices with roles as a centrally routed bridging gateway (CRB-GW) or an edge routed bridging gateway (ERB-GW). Ethernet VPN (EVPN) Ethernet Segment Identifier multihoming may be used between service devices210and spine devices. That is, an SDN controller, such as virtual network controller112, may configure service devices210and the spine devices to use EVPN Ethernet segment Identifier multihoming.

An integrated routing and bridging (IRB) feature may be configured in left VRF tables204,204′ and right VRF tables222,222′, both in leaf devices202,220and in service devices210. For example, an SDN controller may configure left VRF tables204,204′ and right VRF tables222,222′ to include an IRB feature. Leaf devices202,220and service devices210may use the IRB as an Inet-BGP loopback. Service devices210may also (additionally or alternatively) use a loopback address (LOO) as the Inet-BGP loopback. In some examples, firewall policies of service devices210may dictate that network communications received from leaf devices202are to be sent to one of leaf devices220, while network communications received from leaf devices220are to be sent to one of leaf devices202. There may be a need for an Inet-BGP session on service devices210between left VRF table204and right VRF table222.

In this manner, system200ofFIG.4represents an example of a data center system including a first set of one or more server devices of the data center, the first set of server devices hosting data of a first tenant of the data center; a first network device of an interconnected topology communicatively coupled to the first set of one or more server devices, the first network device including a first service virtual routing and forwarding (VRF) table for the first set of server devices; a second set of one or more server devices of the data center, the second set of server devices hosting data of a second tenant of the data center; a second network device of the interconnected topology communicatively coupled to the second set of one or more server devices, the second leaf node device including a second VRF table for the second set of server devices; and one or more service devices that communicatively couple the first network device to the second network device, wherein the service devices include a third service VRF table for the first tenant and a fourth service VRF table for the second tenant, wherein the first network device applies the first service VRF table to network traffic flowing between the first set of server devices and the second set of server devices, wherein the second network device applies the second service VRF table to the network traffic flowing between the first set of server devices and the second set of server devices, and wherein the service devices apply services to the network traffic flowing between the first set of server devices and the second set of server devices using the third service VRF table and the fourth service VRF table.

FIG.5is a block diagram illustrating an example system250including another example set of devices of a data center that may perform the techniques of this disclosure. In this example, system250includes leaf devices252A,252B, Virtual Extensible LAN (VxLAN) Network Identifier (VNI) capable device254, and service device260. Leaf device252A is coupled to virtual networks270A,270B, while leaf device252B is coupled to virtual network270C. VNI capable device254may correspond to a TOR switch or a spine switch, e.g., one of TOR switches106or chassis switches104ofFIG.1. Leaf devices252may correspond to, for example, servers108ofFIG.1.

As noted above with respect toFIG.4, in some examples, a service device may be separate from a Layer3VNI capable device. In the example ofFIG.5, service device260is separate from VNI-capable device254. Service device260may represent one of a plurality of service devices (e.g., as shown inFIG.4), and VNI-capable device254may represent one of a plurality of VNI-capable devices. Moreover, the plurality of service devices may be communicatively coupled to the plurality of VNI-capable devices in active-active mode.

In general, leaf device252A and virtual networks270A,270B correspond to one tenant, while leaf device252B and virtual network270C correspond to a different tenant. Leaf device252A may send packet280to leaf device252B, and thus, packet280represents an example of an inter-tenant network communication. In some examples, the tenants may be different cloud service providers.

In accordance with the techniques of this disclosure, VNI-capable device254is configured with left VRF table256for leaf device252A and right VRF table258for leaf device252B. Left VRF table256and right VRF table258represent examples of service VRFs that are distinct VRFs from tenant VRFs (not shown). When VNI-capable device254receives packet280, VNI-capable device254performs a lookup in left VRF table256, and determines that packet280is to be sent to service device260to have one or more PNFs applied. Service device260may then perform the one or more PNFs on packet280. VRF-LR1and security policy262of service device260may define one or more security policies for a firewall PNF, for example.

Service device260may then send packet280back to VNI-capable device254per a lookup in VRF-LR1security policy262, assuming packet280does not match any elements of a security policy of VRF-LR1security policy262indicating that packet280is to be dropped. VNI-capable device254receives packet280from security device260and performs a lookup in right VRF table258. Right VRF table258indicates that packet280is to be sent to leaf device252B, and thus, VNI-capable device254forwards packet280to leaf device252B.

In some examples, an SDN controller (not shown) of system250(e.g., corresponding to virtual network controller112ofFIG.1) is configured to receive data from an administrator (e.g., administrator110ofFIG.1) representing whether to use BGP between VNI-capable device254and service device260(including a PNF routing instance) or to configure static routes to divert traffic from VNI-capable device254and service device260. In some examples, additionally or alternatively, the SDN controller is configured to receive data from the administrator representing whether service left VRF table256and right VRF table258are shared with logical router VRF tables of, e.g., leaf devices252. In general, the SDN controller may further configure the various devices of system250according to the discussion above. For example, the SDN controller may receive high level configuration data for the various devices, and translate the high level configuration data to low level (that is, device-level) configuration data.

In this manner, system250ofFIG.5represents an example of a data center system including a first set of one or more server devices of the data center, the first set of server devices hosting data of a first tenant of the data center; a first network device of an interconnected topology communicatively coupled to the first set of one or more server devices, the first network device including a first service virtual routing and forwarding (VRF) table for the first set of server devices; a second set of one or more server devices of the data center, the second set of server devices hosting data of a second tenant of the data center; a second network device of the interconnected topology communicatively coupled to the second set of one or more server devices, the second leaf node device including a second VRF table for the second set of server devices; and one or more service devices that communicatively couple the first network device to the second network device, wherein the service devices include a third service VRF table for the first tenant and a fourth service VRF table for the second tenant, wherein the first network device applies the first service VRF table to network traffic flowing between the first set of server devices and the second set of server devices, wherein the second network device applies the second service VRF table to the network traffic flowing between the first set of server devices and the second set of server devices, and wherein the service devices apply services to the network traffic flowing between the first set of server devices and the second set of server devices using the third service VRF table and the fourth service VRF table.

Further details of examples of configuration of the devices of system250are discussed in “contrail-specs/5.1/cfm-le-pnf-support.md,” Nov. 12, 2018, available at github.com/Juniper/contrail-specs/blob/master/5.1/cfm-13-pnf-support.md, which is incorporated herein by reference in its entirety, and is the inventors' own publication.

FIG.6is a flowchart illustrating an example method for performing techniques of this disclosure. Various portions of the method ofFIG.6are attributed to virtual network controller112, chassis switches104, TOR switches106, and servers108, although it should be understood that other devices may perform these and other elements of the method. For example, the devices ofFIGS.2-5may be configured to perform these or other functions, as discussed above.

Initially, virtual network controller112configures a first set of server devices (e.g., servers108A ofFIG.1) to host data of a first tenant of a data center (300). For example, virtual network controller112may configure servers108A to serve data of one or more bridge domains associated with the first tenant. Virtual network controller112also configures a second set of server devices (e.g., servers108B ofFIG.1) to host data of a second tenant of the data center (302). For example, virtual network controller112may configure servers108B to serve data of one or more bridge domains associated with the second tenant. Virtual network controller112also configures network devices of an interconnected topology (e.g., TOR switches106or chassis switches104) to couple the server devices (e.g., servers108A and108B) to one or more service devices (304), such as service devices210ofFIG.4. In particular, virtual network controller112configures the network devices to include service virtual routing and forwarding (VRF) tables (e.g., left VRF table204′ and right VRF table222′ ofFIG.4).

Virtual network controller112then configures service devices (e.g., service devices210ofFIG.4)) with service VRF tables (304) for the first set of network devices and the second set of network devices. For example, as shown inFIG.4, virtual network controller112may configure the service devices to include service left VRF table204and service right VRF table222. Virtual network controller112may also configure the first and second sets of network devices to include respective service VRF tables that are separate from logical router VRF tables. That is, an administrator (e.g., administrator110) may specify in high level configuration data that the service VRF tables are not to be shared (i.e., to be separate from the logical router VRF tables). When not shared, virtual network controller112may enable route leaking from logical router VRFs206,224to left VRF table204′ and right VRF table222′. Virtual network controller112may translate this high level configuration data to low level configuration data indicating that separate service left and right VRF tables are to be maintained by, e.g., servers108, from logical router VRF tables (which servers108may use to communicate with customers120ofFIG.1).

Although in this example, it is assumed that the service devices include the service VRF tables, it should be understood that in other examples, such as inFIG.5, virtual network controller112may configure a L3VNI-capable device to include the service left and right VRF tables, and a separate service device may actually perform the service. In either case, virtual network controller112configures to the service devices to perform the service to inter-tenant communications (306). For example, virtual network controller112may configure the service devices to perform the service on packets flowing between servers108A and108B, in this example.

In light of such configuration, a first tenant device (e.g., one of servers108A) sends a packet to the service device (308). For example, the first tenant device may determine that a service VRF thereof indicates that packets destined for one of servers108B is to be sent to a service device (e.g., one of TOR switches106or chassis switches104) that either performs the service (e.g., as inFIG.4) or directs the packet to a device that performs the service (e.g., as inFIG.5).

The service device then receives the packet and (using a service left VRF table associated with servers108A, in this example) applies the service to the packet (310). For example, the service device may apply one or more firewall and/or IDP policies, QoS rules, load balancing rules, or the like to the packet. The service device then determines that the packet is to be sent to one of servers108B (in this example) using, e.g., a service right VRF table associated with servers108B. Accordingly, the service device forwards the packet to a second tenant device (312) (e.g., one of servers108B).

In this manner, the method ofFIG.6represents an example of a method including configuring, by a virtual network controller device of a data center network, a first set of one or more server devices of the data center to host data of a first tenant of the data center; configuring, by the virtual network controller device, a second set of one or more server devices of the data center to host data of a second tenant of the data center; configuring, by the virtual network controller device, a first network device of an interconnected topology communicatively coupled to the first set of one or more server devices to include a first service virtual routing and forwarding (VRF) table for the first set of server devices and to apply the first VRF table to network traffic flowing between the first set of server devices and the second set of server devices; configuring, by the virtual network controller device, a second network device of the interconnected topology communicatively coupled to the second set of one or more server devices to include a second service VRF table for the second set of server devices and to apply the second VRF table to network traffic flowing between the first set of server devices and the second set of server devices; and configuring, by the virtual network controller device, one or more service devices to communicatively couple the first network device to the second network device, wherein configuring the one or more service devices comprises configuring the service devices to include a third VRF table for the first set of server devices and a fourth service VRF table for the second set of network devices, and configuring the service devices to apply services to network traffic flowing between the first set of server devices and the second set of server devices using the third service VRF table and the fourth service VRF table.

The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit comprising hardware may also perform one or more of the techniques of this disclosure.

Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media. Computer readable storage media, which is tangible and non-transitory, may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer-readable storage media. It should be understood that the term “computer-readable storage media” refers to physical storage media, and not signals, carrier waves, or other transient media.

Various examples have been described. These and other examples are within the scope of the following claims.