Much like server virtualization has led to a true transformation within the means and speed of that application are managed and extended within the data Centre an equivalent is needed for Network layer also. A virtualized, multitenant environment should enable the unlimited clear migration of workloads across physical servers- whereas controlling the price and maintaining the quality of Service (QoS) the client needs.
Most significantly, virtualized data centers want the flexibleness of provisioning resources that span multiple geographic locations. At a similar time, the virtualized data centers should maintain isolation between tenants and still enable seamless management of the multitenant environment. Following dictates the necessity} of VXLAN technology requirement initially place.
- Massive MAC requirement: With the bigger adoption of ToR (Top of Tack) server farm design, there's an incredible pressure of mac explosion on ToR switches. rather than only one mac address per server link, the ToR currently should learn the mac addresses of the individual VMs (which may home in the whole bunch per server). this can be required as a result of traffic to/from the VMs to the rest of the physical network can traverse the link between the server and also the switch.
- VM Movement: Unfortunately, IP subnetting limits the VM mobility domain to the cluster of vSphere servers whose vSwitches are on identical subnets.
- Multitenant Environments: Isolation of network traffic by a tenant may well be done via Layer two or Layer three networks.
For Layer two networks, VLANs are typically used to segregate traffic -- therefore a tenant may well be known by its own VLAN, for instance. as a result of an oversized range of tenants that a cloud provider would possibly service, the 4094 VLAN limit is commonly inadequate. additionally, there's usually a necessity for multiple VLANs per tenant, that exacerbates the problem.
Layer three networks don't seem to be a comprehensive answer for multi-tenancy either. two tenants may use a similar set of Layer three addresses among their networks, which needs the cloud supplier to produce isolation in another type. Further, requiring all tenants to use IP excludes customers looking forward to directing Layer two or non-IP Layer three protocols for inter-VM communication
What is VXLAN?
VXLAN (Virtual eXtensible Local Area Network) addresses the above requirements in a data center network infrastructure in the presence of VMs in a multi-tenant environment. VXLAN is a Layer 2 overlay scheme on a Layer 3 network. Each overlay is termed a VXLAN segment. Only VMs within the same VXLAN segment can communicate with each other. VXLAN accomplishes its goals by using an overlay of tunnels. Unicast traffic uses unicast tunnels, and multicast traffic is sent to a per-tenant IP multicast group.
VXLAN Frame Format
Each VXLAN network segment is associated with a unique 24bit VXLAN Network Identifier, or VNI. The VNI is in an outer header that encapsulates the inner MAC frame originated by the VM. Therefore it allows us to have overlapping MAC addresses across segments but never has traffic "crossover" since the traffic is isolated using the VNI. Due to this encapsulation, VXLAN could also be called a tunneling scheme to overlay Layer 2 networks on top of Layer 3 networks. The tunnels are stateless, so each frame is encapsulated according to a set of rules.
The endpoint of the tunnel (VXLAN Tunnel End Point or VTEP), is located within the hypervisor on the server that hosts the VM or it could be on the switch as well. Thus, the VNI- and VXLAN-related tunnel / outer header encapsulation are known only to the VTEP, the VM never sees it.
VXLAN Encapsulation & Forwarding
- If the source and destination MAC addresses live on the same host, traffic is locally switched through the vSwitch and no VXLAN encapsulation/decapsulation is performed.
- If the destination MAC address live is not on the ESX host, frames are encapsulated in the appropriate VXLAN header by the source VTEP and are forwarded to the destination VTEP based on its local table. The destination VTEP will unbundle the inner frame from the VXLAN header and deliver it on to the recipient VM.
- For unknown unicast or broadcast/multicast traffic, the local VTEP encapsulates the frame in a VXLAN header and multicasts the encapsulated frame to the VNI multicast address that is assigned to the VNI at the time of creation. This includes all ARPs, Bootp/DHCP requests, etc.
VXLAN overlay networks are designated and operated over the existing LAN infrastructure. To ensure that VXLAN end points and their VTEPs are authorized on the LAN, it is recommended that a VLAN is designated for VXLAN traffic and the servers/VTEPs send VXLAN traffic over this VLAN to provide a measure of security. Administrative measures like 802.1x can be still used for admission control of individual end points.