Enabling virtual workloads using overlay technologies to interoperate with physical network services

[0001] This application claims priority to U.S. Provisional Application No. 61/736,577, filed Dec. 13, 2012, the entirety of which incorporated herein by reference.

[0002] The present disclosure relates to virtual switches that use overlay technologies.

[0003] Virtualization of workloads has become pervasive and there is a need for customers to be able to use the existing installed base of physical network services (such as firewalls, load balancers etc.) to offer network service capability to the virtualized workloads in the same way as in the physical environment, in an on-demand, dynamic fashion, particularly in cloud service provider environments.

[0004] In the physical (baremetal) environment, application traffic is assigned to a specific virtual local area network (VLAN) to be sent to the firewall and the traffic from the firewall is sent on another VLAN for ultimate transmission to the network service. To satisfy the needs of large scale multi-tenancy requirements, overlay technologies such as Virtual Extensible LANs (VXLANs) are becoming popular. However, there is no easy way to offer physical network services (such as firewall services) for virtualized workloads using an overlay technology.

[0013] A solution is provided to enable cloud service provider customers/users to offer physical network services to virtualized workloads that use overlay technologies, such as a Virtual Extensible Local Area Network (VXLAN). For a virtual workload that uses an overlay technology, an identifier is received of a logical network to which the virtual workload connects and a policy for the logical network. Based on the identifier of the logical network and the policy, a gateway is configured to connect traffic for the virtual workload on the logical network to a particular virtual local area network (VLAN) interface of the physical network service equipment on which the policy is configured.

[0014] A solution is presented herein that configures a gateway entity and one or more physical networking services so as to extend the physical networking services to virtualized network endpoints.

[0015] Reference is first made to FIG. 1 which shows a network environment 10 that has virtual network components and physical network service equipment. In FIG. 1, the physical network “world” is on the right side and the virtual network “world” is on the left side. The physical network service equipment is shown at reference numeral 20 and may include firewall equipment, load balancer equipment, switches, etc., each of which includes physical networking services capabilities. In other words, the physical network service equipment 20 is embodied by hardware and supporting software. An example of physical network service equipment is Cisco Systems Inc.'s Adaptive Security Appliance (ASA) 5500—Firewall services. Other examples of physical network service equipment/appliances include wide area network (WAN) acceleration devices (WAAS), intrusion prevention system (IPS) devices, etc. In physical computing/networking architectures, segmentation is achieved using virtual local area networks (VLANs). Currently, physical network services can only be applied on VLAN segments.

[0016] On the left side of the diagram, there is a virtual switch 30 running in a hypervisor 40 in a data center. The data center and its supporting equipment are not shown in FIG. 1 for simplicity. In virtualized multi-tenant environments, it is becoming common to use Virtual Extensible LANs (VXLANs). VXLANs are implemented in hypervisors and can only be used to connect to virtualized endpoints.

[0017] VXLAN is a technology to allow for “floating” virtual domains on top of a common networking and virtualization infrastructure. By leveraging industry-standard Ethernet technology, large numbers of virtual domains can be created, which can be isolated from each other and the underlying network. VXLAN provides the capability to create isolated, multi-tenant broadcast domains across data center fabrics, allowing for the creation of logical networks that span physical network boundaries.

[0018] VXLAN can be used to abstract a network into a generalized pool of network capacity. The use of these services can be separated from the underlying physical infrastructure. This pool can span physical boundaries, optimizing compute resource utilization across clusters, pods and even geographically separated datacenters. The pool of network capacity can be segmented into logical networks directly associated with specific applications.

[0019] VXLAN operates by creating Layer 2 logical networks that are encapsulated in standard Layer 3 IP packets. A “Segment ID” in every frame differentiates the individual logical networks (VXLANs) from each other. Numerous isolated Layer 2 VXLAN networks can therefore co-exist on a common Layer 3 infrastructure.

[0020] An example of another overlay technology that may be used, as an alternative to VXLAN, is Network Virtualization using Generic Routing Encapsulation (NVGRE).

[0021] FIG. 1 shows a VXLAN/VLAN gateway 50 connected between the virtual switch 30 and the physical network 60 to which the physical network service equipment 20 is connected. The VXLAN/VLAN gateway 50 permits traffic to be passed between the virtual network world (e.g., a VXLAN) and the physical network world, e.g., a VLAN. The VXLAN/VLAN gateway 50 may be embodied as a software function residing in the data center, such as part of the virtual switch 30 or as a hardware switching device or appliance.

[0022] A virtual service 70 is in communication with the virtual switch 30. Examples of a virtual service 70 include a Virtual Security Gateway (VSG) that serves as a virtual firewall appliance providing trusted access to virtual data center and cloud environments, a Virtual Wide Area Application Services (vWAAS) for application acceleration in private and public cloud environments, and a cloud router. There are virtual workloads, e.g., virtual machines, shown at reference numeral 80 in FIG. 1, that are running on the hypervisor 40.

[0023] FIG. 1 shows that there is a management plane depicted by the dotted arrows, and a data/services plane depicted by the solid arrows. A Cloud Management Platform (CMP) 90 is provided to perform control/management functions of the various entities in the network environment 10. In the CMP 90, there is a virtual services manager 92 and a physical services manager 94. The virtual services manager 92 communicates with, in order to configure, the virtual switch 30 and the virtual service 70. The physical services manager 94 communicates with, in order to configure, the physical network service equipment 20 and with the VXLAN/VLAN gateway 50. The CMP 90 may be embodied as one or more applications running on one or more physical or virtualized servers. Examples of CMPs include vCloud Director by VMware, System Center Virtual Machine Manager (SCVMM) for Microsoft, Openstack and Cloudstack/Cloudplatform for open source hypervisors.

[0024] The arrangement shown in FIG. 1 enables cloud service provider customers to offer physical network services, e.g., firewall services, of the physical network service equipment 20 to the virtualized workloads 80 that connect to the network using overlays (e.g., VXLAN) via the VXLAN/VLAN gateway 50 in an on-demand, dynamic fashion through the CMP 90. This is depicted in a more isolated manner in the paradigm shown in FIG. 2.

[0025] Reference is now made to FIG. 3 that illustrates a flow chart depicting operations to provision the physical network service equipment 20 for multiple tenants. Reference is made to FIG. 1 in connection with the description of the flow chart of FIG. 3. At step 100, the physical services manager 94 provisions the physical network service equipment 20 with a service context for each tenant. At step 110, the physical services manager 94 of the CMP 90 configures the physical network service equipment with multiple policies, each with a policy_id. Each policy is configured within the service context for the particular tenant. One VLAN is associated with each policy. Thus, VLAN_id1 is for policy_id1, VLAN_id2 is for policy_id2, and so on. Each policy is applied to data received on or sent to a corresponding specific VLAN interface. A tenant may have multiple logical networks, e.g., VLANs. As one example, a physical network service equipment 20 can scale to 1000 VLANs and 250 contexts.

[0026] A tie-in is built between the VXLAN segment_id that a virtual machine (VM) is using with the VLAN that is needed to transport the traffic to the appropriate context that is configured in the physical network service equipment, e.g., a firewall context in the case where the physical network service equipment is a firewall.

[0027] Turning now to FIG. 4, a flow chart is provided that sets forth, in more detail, the setup to enable the techniques presented herein. FIG. 1 and FIG. 5 are also referred to in connection with the description of FIG. 4. FIG. 5 illustrates an example of a mapping between logical networks (e.g., VXLAN segments) in the virtual network world and VLANs in the physical network world.

[0028] Each VM is created within a tenant container. At step 120, through the physical services manager 94, a customer provisions the physical network service equipment 20 with a context for each tenant. Tenant VM policies are configured within each context. One or more VLANs may be associated with each context. Thus, each context contains multiple VLAN interfaces, each with its own policy configuration.

[0029] At 130, using the CMP 90, a user/customer acting on behalf of a tenant, defines a policy for each logical network (e.g., VXLAN) to which VMs connect. This policy is to be enforced by the physical network service equipment 20.

[0030] At 140, the CMP 90 sends the logical network identifier, tenant_id and policy information (VXLAN segment_id, tenant_id, policy) to the physical services manager 94. At 150, the physical services manager 94 configures the VXLAN/VLAN gateway 50 to connect the VXLAN segment to the VLAN_id on which the policy will be applied. At 160, the physical services manager 94 defines the policy on the physical network service equipment 20 within the given tenant's service context and instructs it to apply it on the VLAN_id to which the VXLAN segment is connected. The VXLAN/VLAN gateway 50 bridges traffic between a particular VXLAN segment_id (e.g. VXLAN 5500) and a VLAN_id (e.g. VLAN-55). In this example, VLAN 55 belongs to a particular context. The contexts and the associated security policies may be pre-provisioned in the physical network service equipment 20.

[0031] FIG. 5 shows traffic from virtual workloads 80(1), 80(2) and 80(3) associated with corresponding logical networks of VXLAN segments identified by segment_ids VXLAN_—1, VXLAN_—2 and VXLAN_—3 shown at reference numerals 152(1), 152(2) and 152(3), respectively. The VLAN identifiers to which the VXLAN segment identifiers are mapped to are VLAN_—1, VLAN_—2 and VLAN_—3, respectively, shown at reference numerals 162(1), 162(2) and 162(3). The VLAN interfaces on the physical network service equipment 20 for VLAN_—1, VLAN_—2 and VLAN_—3 are shown at reference numerals 170(1), 170(2) and 170(3), respectively. When a customer creates a network using the CMP 90, the customer will create a logical network (and thus allocate a VXLAN segment_id) and associate this network (VXLAN segment) to a VLAN_id and context_id. The customer will choose the context_id based on the security profile he/she wants to associate with the VMs connecting to this network using a pull down menu that is published prior to the CMP 90. These profiles may be published as abstract names (e.g., web-server-fw-policy)

[0032] The CMP 90 will send this information (VXLAN segment_id, VLAN_id, context_name) to the physical services manager 94 which in turn configures the VXLAN/VLAN gateway 50 (for the VXLAN to VLAN mapping) and the physical services network equipment 20 for the VLAN to the context-name mapping.

[0033] Once this is setup, the VMs that connect to the network will send their traffic on that specific VXLAN segment-id through the virtual switch and to the VXLAN/VLAN gateway 50. The VXLAN/VLAN gateway 50 will bridge that traffic to the correct VLAN as defined in the mapping. The physical network service equipment 20 will apply the appropriate policy to the traffic as defined in the VLAN-context mapping. This process does not require any changes to the existing physical network service equipment 20.

[0034] Reference is now made to FIG. 6 (with continued reference to FIG. 1) for a description of a process similar to that depicted in FIG. 4, but used when the physical network service equipment 20 is preconfigured with its policies, etc. At 200, the physical network service equipment 20 (e.g., a firewall) is preconfigured with the appropriate policies (e.g., security/load-balancing etc.) each with the corresponding tenant context and VLAN-id. At 210, this information is published to the CMP 90, via the physical services manager 94, using an integration mechanism between the physical services manager 94 and the CMP 90. At 220, a pool of logical networks (e.g., VXLAN-based networks) for each tenant is configured in the CMP 90. At 230, when a network is allocated from a particular tenant's network pool, a corresponding policy is selected using the CMP 90. At 240, using Application Programming Interfaces (APIs) between the CMP 90 and physical services manager 94, the tuple of (policy identifier for the selected policy and VXLAN segment identifier) is passed to the physical services manager 94. At 250, based on the VXLAN segment identifier and policy identifier, the physical services manager 94 configures the VXLAN/VLAN gateway 50 to connect the VXLAN segment to the corresponding VLAN on which the policy is preconfigured on the physical network service equipment 20.

[0035] FIG. 7 illustrates a flow chart for a process in which policies are configured on-demand on the physical network service equipment 20. Again, reference is also made to FIG. 1 for this description. At 300, a tenant context is created on the physical network service equipment 20 when the tenant is provisioned in the CMP 90. At 310, a pool of logical networks (e.g., VXLAN-based networks) for each tenant is configured in the CMP. At 320, the CMP passes a tuple of (VXLAN segment_id, tenant_id and policy) to the physical services manager 94. At 330, the physical services manager 94 performs several operations. First, it allocates a VLAN specifically for the newly instantiated tenant network and creates the VLAN interface on the physical network service equipment 20. Second, it configures the VXLAN/VLAN gateway 50 to connect the VXLAN-based tenant network to the newly allocated VLAN interface on the physical network service equipment based on the VXLAN segment identifier. Third, it configures the policy obtained from the CMP on the VLAN interface in the physical network service equipment 20 within the tenant's context (based on the tenant identifier).

[0036] Turning now to FIG. 8, a block diagram is shown for a computing apparatus in which may reside software instructions for performing the functions of the physical services manager 94. This same computing apparatus may also include software instructions for the CMP 90 and the virtual services manager 92. The computing apparatus, shown at reference numeral 400, comprises a processor 410, a bus 415, memory 420, a network interface unit 430 and one or more user interface devices, such as a keyboard 440 and display 450. The processor 410 is a microcontroller or microprocessor that executes instructions stored in memory 420. The network interface unit 430 enables network communications to and from the computing apparatus 400.

[0037] The memory 420 may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible memory storage devices. Thus, in general, the memory 420 may comprise one or more tangible (non-transitory) computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed (by the processor 410) it is operable to perform the operations described herein. More specifically, stored/encoded in memory 420 are instructions for physical services manager process logic 500, that when executed by processor 410, cause the processor 410 to perform the operations described herein for the CMP 90, virtual services manager 92 and physical services manager 94 in connection with FIGS. 1-7.

[0038] In summary, the foregoing solution provides for automated on-demand provisioning to leverage the installed base of physical network services. From a method perspective, a method is providing in which, for a virtual workload that uses an overlay technology, receiving an identifier of a logical network to which the virtual workload connects and a policy for the logical network; and based on the identifier of the logical network and the policy, configuring a gateway to connect traffic for the virtual workload on the logical network to a particular VLAN interface of the physical network service equipment on which the policy is configured.

[0039] This method may be embodied or implemented by computer executable instructions stored or encoded in a computer readable storage media, wherein the instructions are operable to: for a virtual workload that uses an overlay technology, receive an identifier of a logical network to which the virtual workload connects and a policy for the logical network; and based on the identifier of the logical network and the policy, configure a gateway to connect traffic for the virtual workload on the logical network to a particular VLAN interface of the physical network service equipment on which the policy is configured.

[0040] Further still, an apparatus, such as a computing apparatus, may be configured to perform these techniques. The apparatus comprises a network interface unit configured to enable network communications; a memory; and a processor coupled to the network interface unit and the memory, wherein the processor is configured to: for a virtual workload that uses an overlay technology, receive an identifier of a logical network to which the virtual workload connects and a policy for the logical network; and based on the identifier of the logical network and the policy, configure a gateway to connect traffic for the virtual workload on the logical network to a particular VLAN interface of the physical network service equipment on which the policy is configured.

[0041] The above description is intended by way of example only.