Data suppression for faster migration

The subject technology addresses the need in the art for improving intra-cloud migration of virtual machines in a cloud computing environment. A hash database may be prepopulated with key-value pairs corresponding to hash IDs and associated data chunks of a virtual machine image. In this regard, the virtual machine image may be divided into chunks using boundaries chosen by a Rabin fingerprinting technique. A hash (e.g., MD5 or SHA-1) may be computed over each chunk and act as a unique identifier for the data contained in each chunk. At appropriate times, one or more hash IDs are sent instead of the actual data chunks between clouds when performing the inter-cloud migration of a virtual machine.

BACKGROUND

Virtualization is a technology that allows one computer to do the job of multiple computers by sharing resources of a single computer across multiple systems. Through the use of virtualization, multiple operating systems and applications can run on the same computer at the same time, thereby increasing utilization and flexibility of hardware. Virtualization allows servers to be decoupled from underlying hardware, thus resulting in multiple virtual machines sharing the same physical server hardware. The virtual machines may move between servers based on traffic patterns, hardware resources, or other criteria. Migrating a VM may require the transfer of the VM image itself, which can be quite time consuming. The speed and capacity of today's servers allow for a large number of virtual machines on each server, and in large data centers there may also be a large number of servers.

In the context of information technology, cloud computing is a model of service delivery (e.g., instead of a product) for providing on-demand access to shared computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, virtual appliances, and services) that can be provisioned with very little management effort or interaction with a provider of the service. In some instances, cloud infrastructure (“cloud”) may be deployed as a public, private or hybrid cloud. By way of example, in a private cloud, the cloud infrastructure is operated solely for an entity, and may be managed by the entity (or third party). In a public cloud, the cloud infrastructure may be made available to the general public (or another large set of users) and is operated by an entity providing cloud services. In a hybrid cloud, the cloud infrastructure includes at least two clouds (e.g., private and/or public) that are separate but connected by technology that enables data and/or application interoperability.

DETAILED DESCRIPTION

Systems and methods in accordance with various embodiments of the present disclosure may overcome one or more deficiencies experienced in existing approaches to migrating virtual machines.

Overview

Embodiments of the subject technology provide for selecting a first data chunk from a virtual machine image, the virtual machine image being divided into a plurality of data chunks; computing a hash identifier (ID) value for the first data chunk; determining whether the hash ID value is included as part of an entry in a hash database, the entry including at least the hash ID value associated with the first data chunk; and responsive to the hash ID value being included as part of the entry, sending the hash ID value to a receiving data center as part of a migration process for the virtual machine image.

Description of Example Embodiments

The disclosed technology addresses the need in the art for improving migration of virtual machines in a computing environment. More specifically, the disclosed technology addresses the need in the art for data suppression for faster migration of virtual machines.

Examples of Using Data Suppression for Virtual Machine Migration

Embodiments provide a way of migrating images of virtual machines between different cloud deployments (e.g., public, private, hybrid, etc.). By using data suppression techniques described further herein, network resource usage and the time to transfer may be reduced for this migration process.

Data centers may host applications and store large amounts of data for an organization or multiple organizations. An enterprise data center or “cloud” may be privately owned and discreetly provide services for a number of customers, with each customer using data center resources by way of private networks, e.g., virtual private networks (VPNs). In some instances, the (private) enterprise data center may communicate with a public data center, forming a hybrid cloud environment.

In embodiments described further herein, an inter-cloud migration of a virtual machine(s) from a private data center to a public data center (or vice versa) may occur. Virtual machine migration allows a given data center to move a virtual machine in order to accommodate changes in application demand, and to reduce resource consumption on physical machines that host virtual machines when these physical machines become overloaded. The virtual machine migration process involves, among other operations, discovering available resources on available physical machines, deciding on which virtual machines to migrate and where, and then performing the actual movement of a virtual machine image from one physical machine to another (e.g., in another data center), by transferring at least a portion of a virtual machine image over the network, including its static as well as the live (e.g., run-time) state. A virtual machine image may include data corresponding to an operating system that the virtual machine runs on, any applications that are included as part of the virtual machine configuration, and/or the run-time state of the virtual machine.

Example Network Environment

FIG. 1conceptually illustrates an example system100for a multiple data center environment. As shown, system100includes a private data center105(e.g., a private cloud) and a public data center110(e.g., public cloud). The two data centers105and110communicate with each other using edge switches115and140, respectively, by way of interconnect links175over public network170. The data centers105and110include multiple servers and storage devices135and160. The servers may host application services (e.g., World Wide Web server applications or remotely hosted virtual machine (VM) applications). The storage devices may be part of a Storage Area Network (SAN) in an embodiment. Collectively, the system100may be understood as a hybrid cloud configuration.

In an embodiment, each of the data centers105and110include access switches, aggregation switches and core switches shown at reference numerals129,127,125, and155,153, and150, respectively, to aggregate and distribute ingress (e.g., upstream traffic), and egress (e.g., downstream traffic). Multiple switches may be provided at each access, aggregation, and core level to provide redundancy within the data centers105and110. In this example, a single virtual machine (VM)180has been selected for VM migration from data center105to data center110. The migration of VM180may be triggered by operational constraints and/or events (e.g., server overload, scheduled maintenance or downtime, etc.) in the data center105. VM migration may be understood as the process of moving a VM from one host or storage location to another, and in the context of embodiments described herein, involve moving a VM from one data center to another data center.

In an example, VM migration may be performed at the data link layer, (e.g., Layer 2 of the Open Systems Interconnect (OSI) model), for inter-cloud computing operations. When the VM180is part of a local area network (LAN) and is migrated between data centers, the LAN may be connected by a LAN extension through a wide area network (WAN) or public network170(e.g., the Internet, as part of a Layer 3 VPN). LAN extension may be understood as a technology that enables respective LAN entities (e.g., network nodes) in different data centers to communicate with each other by treating the underlying network as a single LAN.

In the example shown inFIG. 1, the migration of VM180from servers and storage135to160is logically represented by the dashed line between data centers105and110. It should be understood that the actual migration occurs over network170by way of the switches (or edge devices) in the data centers105and110in an embodiment.

In an embodiment, the storage devices135and160may include prepopulated data for one or more operating system images (among other types of data). During the migration of the VM180, any known data (e.g., found in the prepopulated data) is not sent over the public network170. As described further herein, data suppression and compression techniques may be used to speed up (e.g., decrease an amount of time for) transfer of images between cloud deployments. A virtual machine image (e.g., raw blocks) may be divided into chunks using boundaries chosen by a Rabin fingerprinting technique. A hash (e.g., MD5 or SHA-1) may be computed over each chunk and used as an unique identifier for the data contained in each chunk. At appropriate times, one or more identifiers are sent instead of the actual data chunk(s) between clouds when performing the inter-cloud migration.

In an embodiment, a database (or other collection of information) may be provided in each cloud deployment. Such a database may be pre-populated with hash identifiers and associated values for each version of an operating system that may be provided (e.g., that is used or included as part of a respective virtual machine image). When a matching entry is found in the database, the hash identifier will be sent instead of the data chunk(s) by the first cloud and the receiving second cloud will use the hash identifier to locate the data chunk(s) in its database to replace the hash identifier received. Any data chunk(s) not located in the database using the hash identifier will be sent compressed by the first cloud to further speed up the transfer to the second cloud. Further, the respective databases in each cloud deployment may be used to “learn” any missed hash/chunk entries and, as a result, potentially speeding up additional transfers of similar virtual machine images that are deployed.

FIG. 2is an example of a conceptual diagram of portions of the multiple data center environment fromFIG. 1. The relevant portions of data centers105and110are shown as indicated by the dashed boxes, along with the interconnect links175that enable communication between the data centers over a public network (not shown). In the illustrated example, two of the servers135(1) and135(2) from data center105are shown along with two of the servers160(1) and160(2) from the data center110.

The servers135(1),135(2),160(1) and160(2) are shown along with their associated hypervisors215(1),215(2),255(1), and255(2), respectively. Hypervisors215(1) and215(2) support multiple VMs220(1)-220(5). VMs220(1)-220(5) may provide one or more private networks in a private cloud. Similarly, hypervisors255(1) and255(2) support multiple VMs260(1)-260(4). VMs260(1)-260(4) have been previously migrated from one or more private networks (e.g., as indicated by the dashed lines). Hypervisors may be understood as hardware and/or software abstraction layers that provide operating system independence for applications and services provided by VMs.

In an embodiment, hypervisors215(1),215(2),255(1), and255(2) perform the functionality of a virtual switch for connecting to one or more virtual machines, and enabling local switching between different virtual machines within the same server. A virtual switch enables virtual machines to connect to each other and to connect to parts of a network. As illustrated, each hypervisor may provide one or more Virtual Ethernet (vEthernet or vEth) interfaces in which each vEthernet interface corresponds to a switch interface that is connected to a virtual port. Each of the virtual machines220(1)-220(5) and VMs260(1)-260(4) may include a virtual Network Interface Cards (vNIC) that are connected to a virtual port of a respective vEthernet interface provided by their associated hypervisor.

In the illustrated example, VM220(5) is targeted for migration from the private cloud/data center105to the public cloud/data center110, (e.g., due to conditions or downtime experienced in the private cloud). It may be determined that the server160(1) provides sufficient resources to support the migrated VM220(5). This migration of the VM220(5) may involve respective hash identifier repositories at the private data center105and the public data center110. As shown inFIG. 2, the private data center105may include hash identifier repository210. Similarly, the data center110may include hash identifier repository250. Each of the hash identifier repositories may include a respective mechanism for managing at least a portion of hash database (or similar collection of information) for use in migrating virtual machine image(s) as described further herein. In at least one embodiment, the mechanism may be configured to provide hash identifiers for block level data of supported operating systems and/or applications using at least one or more different block storage protocols (e.g., iSCSI, SCSI, ATA, SAS/SATA, IDE, etc.). Although the examples described herein relate to migration of virtual machines from a private data center to a public data center, it is appreciated that migration of virtual machines from a public data center to a private data center could also occur. Further, it is contemplated that migration of virtual machines from one public data center to another public data center may occur, and that migration of virtual machines from one private data center to another private data center may occur.

As mentioned before, a virtual machine image may be divided into chunks using boundaries chosen by a Rabin fingerprinting technique. A hash (e.g., MD5 or SHA-1) may be computed over each chunk and act as a unique identifier for the data contained in each chunk. At appropriate times, one or more identifiers are sent instead of the actual chunk data between clouds when performing the inter-cloud migration of a virtual machine.

In one data suppression technique, sequential block data for a virtual machine image may be divided into chunks using boundaries chosen by specifically selected fingerprints using a technique such as, for example, the Rabin fingerprint technique. Once the block data has been divided into chunks, a respective hash value or hash ID may be computed (using, for example, hash algorithms such as MD5 and/or SHA-1) for each chunk. The hash ID provides a unique identifier for the data contained in its associated chunk. Redundant data may then be suppressed by using the hash ID to refer to the data rather than the raw data itself.

Any hash ID that is received by the public data center110may then be used to locate corresponding data chunks in the hash identifier repository250. For example, if a hash ID is sent corresponding to a data chunk in the virtual machine image for the VM220(5), the server160(1) may retrieve the corresponding data chunk by using the received hash identifier on a hash database provided in the hash identifier repository250.

FIG. 3illustrates a conceptual diagram of an example a hash database portion300which may be used for implementing at least one embodiment. As illustrated in the embodiment ofFIG. 3, the hash database portion300is stored as part of a respective hash identifier repository described above, and may be implemented using hash database310. The hash database portion300, in this example, may be part of the hash identifier repository210in the private data center105.

In the example ofFIG. 3, each entry (e.g.,302) in the hash database310may represent a respective Hash ID and data chunk pair. Each entry (e.g.,302) in the hash database310may include different fields relating to various data parameters including, for example: a Hash ID field311which includes a Hash ID value for uniquely identifying an associated data chunk; and a Data Chunk field313which may include one or more bytes from the data chunk (e.g., one of data chunks331,332, or333) associated with the Hash ID value. The Hash ID value, in an example, would be a key generated using a hash function and the associated Data Chunk (e.g., the actual bytes of data) would be a value associated with the key, which are determined for each data chunk of the virtual machine image to prepopulate the hash database310with key-value pairs. This eliminates the need to dynamically build up the hash database310and/or use more network bandwidth. By implementing the hash database310in this fashion, it also allows leveraging common items that may exist between related operating systems. Respective hash databases may be provided in the private data center105and the public data center110(e.g., in the hash identifier repositories210and250).

As illustrated inFIG. 3, the hash database310may be configured to include, for each entry (e.g.,302), respective pairs of values for computed Hash ID values to their associated raw data chunks330,331, and332. The raw data chunks330,331, and332may be stored in local memory or storage of a virtual machine host (e.g., server) in an embodiment. It is appreciated that the number of data chunks, hash IDs, and entries in the hash database310are shown for the sake of discussion of examples inFIG. 3and that any number of data chunks, hash IDs, and/or entries may be supported by embodiments described herein.

In an embodiment, the hash database310may be used to transfer hash IDs corresponding to data chunks of a virtual machine image as part of a virtual machine migration process. Each data chunk of the virtual machine image may be sequentially selected for searching within the hash database to locate its corresponding hash ID. For example, for a selected data chunk, the hash database may be searched for an entry that corresponds to the selected data chunk (e.g., based on a computed hash ID). If located in the hash database, instead of sending the data itself, the corresponding hash ID is transferred as part of the migration process. A selected data chunk that is not represented in the hash database based on its hash ID may be compressed for transferring over the public network to the receiving data center.

Example Processes

FIG. 4conceptually illustrates an example process400in accordance with at least an embodiment of the subject technology. Referring toFIGS. 1 and 2, the process400described below may be performed by a server hosting a virtual machine in a data center as part of a migration process for a virtual machine. In another example, the process400may be performed by an edge device such as the edge switch in the private data center105. As part of the migration process, respective data chunks of a virtual machine image may be selected in a sequential manner for locating within a hash database based on respective hash IDs. During a migration, respective data chunks of a virtual machine image may be pushed to the destination data center. Using the data suppression techniques described herein, hash IDs and/or compressed data may be sent instead of the raw data chunks. As mentioned before, a hash database may be prepopulated with key-value pairs in which each key-value pair includes a hash ID value and an associated data chunk. Data chunks from the virtual machine image may be migrated as discussed in the following example ofFIG. 4.

At step402, a data chunk is selected from a virtual machine image. In an example, the data chunks of the virtual machine image may be selected in a sequential manner. At step404, a hash ID value is computed for the selected data chunk and searched in a hash database in an attempt to locate the hash ID value. Any appropriate hash function may be used to compute the hash ID value. If the hash ID value is located in the hash database, at step406, the hash ID value is sent over a network to a receiving data center (e.g., the public data center110inFIG. 1). The hash ID may therefore be then sent instead of a raw data chunk and, thus, network resources are conserved. In an example, an LBA of the selected data chunk is also sent to the receiving data center in which the LBA may be the next LBA address following a previous LBA address for a previously selected data chunk (e.g., one that has already been migrated as part of the migration process). Once received at the receiving data center, the hash ID value may be looked up in its hash database, and if located, the associated data chunk may be retrieved and written in a disk location based on the received LBA.

However, if it is determined that the hash ID value is not in the hash database, at step410, the hash database is updated with a new entry including a key-value pair with the hash ID value and the selected data chunk. At step412, the selected data chunk is compressed using one or more suitable compression techniques (e.g., Limpel Zif Stac (LZS), Predictor, Point-to-Point Protocol (PPP), X.25 payload compression, etc.). At step414, the hash ID value and the compressed data are sent, over a network, to a receiving data center. Further, as discussed before, an LBA of the selected data chunk may also be sent over to the receiving data center. In this manner, the compressed data, hash ID value and/or LBA information may be then sent over the network to the receiving data center instead of the raw (uncompressed) data chunks and, thus, network resources are conserved. After being received by the receiving data center, the compressed data may be uncompressed into a raw data chunk and then written with the hash ID value as a new key-value pair entry in the respective hash database of the receiving data center. The data chunk may be written to a location of a disk based on the LBA at the receiving data center.

At step408, a determination is made if more data chunk(s) are remaining for processing in the virtual machine image (e.g., either after sending the hash ID value in step406, or after sending the hash ID value and the compressed data chunk in step414). If at least one data chunk remains, the process400may return to step402to select the next data chunk and repeat the aforementioned steps described above in the process400.

Example Devices, Systems and Architectures

FIG. 5illustrates an exemplary network device500suitable for implementing the present invention. Network device500includes a master central processing unit (CPU)562, interfaces568, and a bus515(e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU562is responsible for executing packet management, error detection, and/or routing functions, such as miscabling detection functions, for example. The CPU562preferably accomplishes all these functions under the control of software including an operating system and any appropriate applications software. CPU562may include one or more processors563such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In a specific embodiment, a memory561(such as non-volatile RAM and/or ROM) also forms part of CPU562. However, there are many different ways in which memory could be coupled to the system.

FIG. 6A, andFIG. 6Billustrate exemplary possible system embodiments. The more appropriate embodiment will be apparent to those of ordinary skill in the art when practicing the present technology. Persons of ordinary skill in the art will also readily appreciate that other system embodiments are possible.

FIG. 6Aillustrates a conventional system bus computing system architecture600wherein the components of the system are in electrical communication with each other using a bus605. Exemplary system600includes a processing unit (CPU or processor)610and a system bus605that couples various system components including the system memory615, such as read only memory (ROM)620and random access memory (RAM)625, to the processor610. The system600can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor610. The system600can copy data from the memory615and/or the storage device630to the cache612for quick access by the processor610. In this way, the cache can provide a performance boost that avoids processor610delays while waiting for data. These and other modules can control or be configured to control the processor610to perform various actions. Other system memory615may be available for use as well. The memory615can include multiple different types of memory with different performance characteristics. The processor610can include any general purpose processor and a hardware module or software module, such as module1632, module2634, and module3636stored in storage device630, configured to control the processor610as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor610may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

Storage device630is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs)625, read only memory (ROM)620, and hybrids thereof.

The storage device630can include software modules632,634,636for controlling the processor610. Other hardware or software modules are contemplated. The storage device630can be connected to the system bus605. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor610, bus605, display635, and so forth, to carry out the function.

FIG. 6Billustrates a computer system650having a chipset architecture that can be used in executing the described method and generating and displaying a graphical user interface (GUI). Computer system650is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology. System650can include a processor655, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Processor655can communicate with a chipset660that can control input to and output from processor655. In this example, chipset660outputs information to output665, such as a display, and can read and write information to storage device670, which can include magnetic media, and solid state media, for example. Chipset660can also read data from and write data to RAM675. A bridge640for interfacing with a variety of user interface components645can be provided for interfacing with chipset660. Such user interface components645can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on. In general, inputs to system650can come from any of a variety of sources, machine generated and/or human generated.

Chipset660can also interface with one or more communication interfaces690that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself by processor655analyzing data stored in storage670or675. Further, the machine can receive inputs from a user via user interface components645and execute appropriate functions, such as browsing functions by interpreting these inputs using processor655.

It can be appreciated that exemplary systems600and650can have more than one processor610or be part of a group or cluster of computing devices networked together to provide greater processing capability.

Spine switches702can be L3 switches in the fabric712. However, in some cases, the spine switches702can also, or otherwise, perform L2 functionalities. Further, the spine switches702can support various capabilities, such as 40 or 10 Gbps Ethernet speeds. To this end, the spine switches702can include one or more 40 Gigabit Ethernet ports. Each port can also be split to support other speeds. For example, a 40 Gigabit Ethernet port can be split into four 10 Gigabit Ethernet ports.

In some embodiments, one or more of the spine switches702can be configured to host a proxy function that performs a lookup of the endpoint address identifier to locator mapping in a mapping database on behalf of leaf switches704that do not have such mapping. The proxy function can do this by parsing through the packet to the encapsulated, tenant packet to get to the destination locator address of the tenant. The spine switches702can then perform a lookup of their local mapping database to determine the correct locator address of the packet and forward the packet to the locator address without changing certain fields in the header of the packet.

When a packet is received at a spine switch702i, the spine switch702ican first check if the destination locator address is a proxy address. If so, the spine switch702ican perform the proxy function as previously mentioned. If not, the spine switch702ican lookup the locator in its forwarding table and forward the packet accordingly.

Spine switches702connect to leaf switches704in the fabric712. Leaf switches704can include access ports (or non-fabric ports) and fabric ports. Fabric ports can provide uplinks to the spine switches702, while access ports can provide connectivity for devices, hosts, endpoints, VMs, or external networks to the fabric712.

Leaf switches704can reside at the edge of the fabric712, and can thus represent the physical network edge. In some cases, the leaf switches704can be top-of-rack (“ToR”) switches configured according to a ToR architecture. In other cases, the leaf switches704can be aggregation switches in any particular topology, such as end-of-row (EoR) or middle-of-row (MoR) topologies. The leaf switches704can also represent aggregation switches, for example.

The leaf switches704can be responsible for routing and/or bridging the tenant packets and applying network policies. In some cases, a leaf switch can perform one or more additional functions, such as implementing a mapping cache, sending packets to the proxy function when there is a miss in the cache, encapsulate packets, enforce ingress or egress policies, etc.

Moreover, the leaf switches704can contain virtual switching functionalities, such as a virtual tunnel endpoint (VTEP) function as explained below in the discussion of VTEP808inFIG. 8. To this end, leaf switches704can connect the fabric712to an overlay network, such as overlay network800illustrated inFIG. 8.

Network connectivity in the fabric712can flow through the leaf switches704. Here, the leaf switches704can provide servers, resources, endpoints, external networks, or VMs access to the fabric712, and can connect the leaf switches704to each other. In some cases, the leaf switches704can connect EPGs to the fabric712and/or any external networks. Each EPG can connect to the fabric712via one of the leaf switches704, for example.

Endpoints710A-E (collectively “710”) can connect to the fabric712via leaf switches704. For example, endpoints710A and710B can connect directly to leaf switch704A, which can connect endpoints710A and710B to the fabric712and/or any other one of the leaf switches704. Similarly, endpoint710E can connect directly to leaf switch704C, which can connect endpoint710E to the fabric712and/or any other of the leaf switches704. On the other hand, endpoints710C and710D can connect to leaf switch704B via L2 network706. Similarly, the wide area network (WAN) can connect to the leaf switches704C or704D via L3 network708.

Endpoints710can include any communication device, such as a computer, a server, a switch, a router, etc. In some cases, the endpoints710can include a server, hypervisor, or switch configured with a VTEP functionality which connects an overlay network, such as overlay network400below, with the fabric712. For example, in some cases, the endpoints710can represent one or more of the VTEPs808A-D illustrated inFIG. 8. Here, the VTEPs808A-D can connect to the fabric712via the leaf switches704. The overlay network can host physical devices, such as servers, applications, EPGs, virtual segments, virtual workloads, etc. In addition, the endpoints710can host virtual workload(s), clusters, and applications or services, which can connect with the fabric712or any other device or network, including an external network. For example, one or more endpoints710can host, or connect to, a cluster of load balancers or an EPG of various applications.

Although the fabric712is illustrated and described herein as an example leaf-spine architecture, one of ordinary skill in the art will readily recognize that the subject technology can be implemented based on any network fabric, including any data center or cloud network fabric. Indeed, other architectures, designs, infrastructures, and variations are contemplated herein.

FIG. 8illustrates an exemplary overlay network800. Overlay network800uses an overlay protocol, such as VXLAN, VGRE, VO3, or STT, to encapsulate traffic in L2 and/or L3 packets which can cross overlay L3 boundaries in the network. As illustrated inFIG. 8, overlay network800can include hosts806A-D interconnected via network802.

Network802can include a packet network, such as an IP network, for example. Moreover, network802can connect the overlay network800with the fabric312inFIG. 3. For example, VTEPs808A-D can connect with the leaf switches304in the fabric312via network802.

Hosts806A-D include virtual tunnel end points (VTEP)808A-D, which can be virtual nodes or switches configured to encapsulate and decapsulate data traffic according to a specific overlay protocol of the network800, for the various virtual network identifiers (VNIDs)810A-I. Moreover, hosts806A-D can include servers containing a VTEP functionality, hypervisors, and physical switches, such as L3 switches, configured with a VTEP functionality. For example, hosts806A and806B can be physical switches configured to run VTEPs808A-B. Here, hosts806A and806B can be connected to servers804A-D, which, in some cases, can include virtual workloads through VMs loaded on the servers, for example.

In some embodiments, network800can be a VXLAN network, and VTEPs808A-D can be VXLAN tunnel end points. However, as one of ordinary skill in the art will readily recognize, network800can represent any type of overlay or software-defined network, such as NVGRE, STT, or even overlay technologies yet to be invented.

The VNIDs can represent the segregated virtual networks in overlay network800. Each of the overlay tunnels (VTEPs808A-D) can include one or more VNIDs. For example, VTEP808A can include VNIDs1and2, VTEP808B can include VNIDs1and3, VTEP808C can include VNIDs1and2, and VTEP808D can include VNIDs1-3. As one of ordinary skill in the art will readily recognize, any particular VTEP can, in other embodiments, have numerous VNIDs, including more than the 3 VNIDs illustrated inFIG. 8.

The traffic in overlay network800can be segregated logically according to specific VNIDs. This way, traffic intended for VNID1can be accessed by devices residing in VNID1, while other devices residing in other VNIDs (e.g., VNIDs2and3) can be prevented from accessing such traffic. In other words, devices or endpoints connected to specific VNIDs can communicate with other devices or endpoints connected to the same specific VNIDs, while traffic from separate VNIDs can be isolated to prevent devices or endpoints in other specific VNIDs from accessing traffic in different VNIDs.

Servers804A-D and VMs804E-I can connect to their respective VNID or virtual segment, and communicate with other servers or VMs residing in the same VNID or virtual segment. For example, server804A can communicate with server804C and VMs804E and804G because they all reside in the same VNID, viz., VNID1. Similarly, server804B can communicate with VMs804F, H because they all reside in VNID2. VMs804E-I can host virtual workloads, which can include application workloads, resources, and services, for example. However, in some cases, servers804A-D can similarly host virtual workloads through VMs hosted on the servers804A-D. Moreover, each of the servers804A-D and VMs804E-I can represent a single server or VM, but can also represent multiple servers or VMs, such as a cluster of servers or VMs.

VTEPs808A-D can encapsulate packets directed at the various VNIDs1-3in the overlay network800according to the specific overlay protocol implemented, such as VXLAN, so traffic can be properly transmitted to the correct VNID and recipient(s). Moreover, when a switch, router, or other network device receives a packet to be transmitted to a recipient in the overlay network800, it can analyze a routing table, such as a lookup table, to determine where such packet needs to be transmitted so the traffic reaches the appropriate recipient. For example, if VTEP808A receives a packet from endpoint804B that is intended for endpoint804H, VTEP808A can analyze a routing table that maps the intended endpoint, endpoint804H, to a specific switch that is configured to handle communications intended for endpoint804H. VTEP808A might not initially know, when it receives the packet from endpoint804B, that such packet should be transmitted to VTEP808D in order to reach endpoint804H. Accordingly, by analyzing the routing table, VTEP808A can lookup endpoint804H, which is the intended recipient, and determine that the packet should be transmitted to VTEP808D, as specified in the routing table based on endpoint-to-switch mappings or bindings, so the packet can be transmitted to, and received by, endpoint804H as expected.

However, continuing with the previous example, in many instances, VTEP808A may analyze the routing table and fail to find any bindings or mappings associated with the intended recipient, e.g., endpoint804H. Here, the routing table may not yet have learned routing information regarding endpoint804H. In this scenario, the VTEP808A may likely broadcast or multicast the packet to ensure the proper switch associated with endpoint804H can receive the packet and further route it to endpoint804H.

In some cases, the routing table can be dynamically and continuously modified by removing unnecessary or stale entries and adding new or necessary entries, in order to maintain the routing table up-to-date, accurate, and efficient, while reducing or limiting the size of the table.

As one of ordinary skill in the art will readily recognize, the examples and technologies provided above are simply for clarity and explanation purposes, and can include many additional concepts and variations.

As one of ordinary skill in the art will readily recognize, the examples and technologies provided above are simply for clarity and explanation purposes, and can include many additional concepts and variations.

Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims. Moreover, claim language reciting “at least one of” a set indicates that one member of the set or multiple members of the set satisfy the claim.