Feature |
Product |
Release introduced |
---|---|---|
VXLAN Gateway |
5420 Series |
Not Supported |
5520 Series |
Not Supported |
|
VSP 4450 Series |
Not Supported |
|
VSP 4900 Series |
Not Supported |
|
VSP 7200 Series |
VOSS 6.0 |
|
VSP 7400 Series |
VOSS 8.0 |
|
VSP 8200 Series |
VOSS 6.0 |
|
VSP 8400 Series |
VOSS 6.0 |
|
VSP 8600 Series |
Not Supported |
|
XA1400 Series |
Not Supported |
|
OVSDB protocol support for VXLAN Gateway |
5420 Series |
Not Supported |
5520 Series |
Not Supported |
|
VSP 4450 Series |
Not Supported |
|
VSP 4900 Series |
Not Supported |
|
VSP 7200 Series |
VOSS 7.1 |
|
VSP 7400 Series |
VOSS 8.0 |
|
VSP 8200 Series |
VOSS 7.1 |
|
VSP 8400 Series |
VOSS 7.1 |
|
VSP 8600 Series |
Not Supported |
|
XA1400 Series |
Not Supported |
|
ECMP support for VXLAN Gateway |
5420 Series |
Not Supported |
5520 Series |
Not Supported |
|
VSP 4450 Series |
Not Supported |
|
VSP 4900 Series |
Not Supported |
|
VSP 7200 Series |
VOSS 6.0 |
|
VSP 7400 Series |
VOSS 8.0 |
|
VSP 8200 Series |
VOSS 6.0 |
|
VSP 8400 Series |
VOSS 6.0 |
|
VSP 8600 Series |
Not Supported |
|
XA1400 Series |
Not Supported |
VXLAN Gateway terminates virtual extensible LAN (VXLAN) tunnels that stretch emulated Layer 2 segments over an IP network.
VXLAN is an encapsulation protocol for running an overlay network over an existing Layer 3 infrastructure. This tunneling scheme uses a VLAN-like encapsulation mechanism to encapsulate MAC-based traffic. The VXLAN overlays separate workloads from physical networks, which facilitates the movement of VMs in a multi-tenant environment.
For more information about VXLAN, see the Internet Engineering Task Force (IETF) standard RFC 7348.
The VXLAN Gateway feature terminates VXLAN tunnels and operates as a VXLAN tunnel endpoint (VTEP). The VXLAN Gateway is a hardware-based VTEP that allows a VXLAN to communicate with VLANs, other VXLANs, as well as Fabric Connect I-SIDs.
The following figure shows a VXLAN Gateway (labeled as VTEP Source) connecting VXLAN segments to an SPB network. This type of deployment provides a solution for VXLAN in data centers to interoperate with Fabric Connect networks (labeled as SPB).
VXLAN tunnels are also called VXLAN segments. VXLAN segments provide the ability to separate, abstract, and decouple the physical topology from a logical or virtual topology by using encapsulated tunneling. VXLAN segments allows only VMs within the same VXLAN tunnel to communicate with each other.
Each VXLAN segment has a 24-bit segment ID called a VXLAN Network Identifier (VNID). VNID allows up to 16 million VXLAN segments to coexist within the same administrative domain, which enables VMs to migrate between servers in the same data center or between distributed data centers. Each VTEP can support multiple VNIDs. For information about maximum scaling numbers, see VSP 8600 Release Notes.
The VNID uses the inner MAC frame originated by the individual VM. Overlapping MAC addresses can cross VXLAN segments, but never have traffic crossover because the traffic is isolated using the VNID qualifier. Due to this encapsulation, only the VTEP knows the VNID and its associated VXLAN tunnel. VMs are unaware of the VXLAN.
Only VMs within the same VXLAN segment can communicate with each other. The following steps show how a VM communicates with a VM on a different host within the same VXLAN segment:
The VM sends a MAC frame destined to the target.
The VTEP looks up the VNID that the VM is associated with to verify that the destination MAC is on the same segment. If the destination MAC is on the same segment, the process continues.
The VTEP inserts an outer header comprising an outer MAC, outer IP address, and VXLAN header in front of the original MAC frame.
The VTEP transmits the final packet out to the destination IP address of the remote VTEP, connecting the destination VM addressed by the inner MAC destination address.
The remote VTEP verifies that the VNID is valid for the destination VM.
If the VNID is valid, the remote VTEP strips the packet outer header and passes the packet to the destination VM. The destination VM never knows about the VNID, or that the frame transmitted with VXLAN encapsulation.
Two methods are available to manage VXLAN Gateway:
Static management using CLI and local configuration files.
Dynamic management using OVSDB protocol support for VXLAN Gateway.
For static management, you use CLI or local configuration files to configure and manage the VXLAN Gateway hardware-based VTEP functions. You must manually configure the Source-VTEP, VNID, VNID to I-SID bindings, Remote-VTEP, and VNI to Remote-VTEP associations, and MAC learning on the VNID only occurs at the data-plane level.
For dynamic management, you use OVSDB protocol support for VXLAN Gateway to configure and manage the VXLAN Gateway hardware-based VTEP functions with Open vSwitch Database Management Protocol (OVSDB). You must configure at least one physical Network Virtualization Controller (NVC) running VMware NSX with OVSDB features. You can add a Hardware VTEP, add a logical switch, configure VNID to VTEP bindings, and configure a replication cluster in NSX. The VXLAN Gateway must have OVSDB enabled and the Network Virtualization Controller (NVC) must communicate on the OVSDB managed interface. You must manually configure the Source-VTEP and NVC IP addresses, and the VNID to I-SID binding in NSX. The NVC can manage the VNID, Remote-VTEP, and VNI to Remote-VTEP associations. The NVC distributes the hosts MAC and IP addresses learned by the VTEP over the VXLAN.
Function |
Static management |
Dynamic management |
---|---|---|
VNID provisioning |
Manually from CLI or EDM |
Automatically from NVC |
VNID to I-SID binding |
Manually from CLI or EDM |
Automatically from NVC |
Remote-VTEP |
Manually from CLI or EDM |
MAC learning from NVC |
VNID to VTEP association for replicating BUM traffic |
Manually from CLI or EDM |
MAC learning from NVC |
MAC learning at data-plane |
Not distributed to other VXLAN Gateways |
Distributed from NVC to other VXLAN Gateways |
ARP suppression |
Not supported |
Not supported |