How does Nexus 1000v support VXLAN protocol

In the previous post we we explained how VXLAN works. Below is a complementary video about VXLAN from a Cisco product manager Han Yang showing a live Cisco Nexus 1000V training session.

Interesting facts that are not directly mentioned in the previous post:

• Only one Nexus 1000V (N1V) can be deployed on a single hypervisor (multiple hypervisors have its own 1000V virtual switch)
• Nexus 1000V has built in mechanism for loop prevention (time ~21:00)
• if it receives a packet on the outside interface with a src MAC address that belongs to one of its attached VMs it drops it
• it drops STP BPDU; as hypervisors are considered 'leaves' in the network topology they don't have to participate in STP 
• As VXLAN is an L3/L4 network overlay it handles the VM generated broadcast, multicast and unknowns unicast with a help of IP multicast (time ~27:00)
• The point above says that for example VM ARP request will be distributed to all hypervisors using IP multicast (remember that each hypervisor has its own IP; when there is a communication between hypervisors they communicate using their own IPs. The real VMs communication is encapsulated using VXLAN and is carry over in UDP datagram)
• You don't have to have a separate multicast domain per VXLAN domain (resulting in separate multicast trees and multicast groups that a router need to managed). A single multicast can be shared by many VXLAN (time ~36:00)
• Not sure about this: I have couple of VMs in my VXLAN that want to communicate together using IP multicast. This multicast traffic is not the same like when an ARP need to be distributed among hypervisors. This is VMs internal traffic. Will this VM IP multicast traffic be distributed to all hypervisors or only to these who actually host a relevant VM(s) that joined the VM multicast group before (IGMP snooping) (time 30:00-30:35)
• In a single VXLAN you can have multiple customer defined VLANs (this becomes obvious when you look at the VXLAN frame headers) (time ~30:00)
• You can tunnel VXLAN using OTV (time 45:00)
• You need an L3 gateway device to allow traffic between traditional VLAN and VXLAN domains
• There is an option to integrate within VXLAN network a vASA (virtual ASA) firewall

How does the VXLAN protocol work

The VXLAN is one of the overlay network tunneling protocols that is used to built network infrastructure for cloud environment. Below are some details about the operation and specification.

• Frame headers definition

• The traffic between VMs is encapsulated in IP/UDP packets
• Logical isolation is implemented in a form of logical overlay where the traffic is exchanged between encryption tunnels endpoints
• VXLAN ID is used to identify the specify isolated L2 cloud network that belongs to a tenant
• The tunnel endpoints represent the edge of the cloud network infrastructure
• The tunnel endpoints perform encapsulation and decapsulation
• It is there where all the logic is implemented to find out where to sent next a packet or to witch VM the packet should be delivered after decapsulation

• A comprehensive summary and operational features can be found under the links in reference section, below are few of the main characteristics and benefits:
• It operates over IP and used UDP to carry payload 
• Multicast support is the only other requirement for switches and routers to support VXLAN 
• Multicast is used to handle L2 broadcast traffic (like ARP requests)
• Logical networks can be extended among virtual machines placed in different Layer 2 domains

References

1. http://www.definethecloud.net/vxlan-deep-dive
2. http://www.definethecloud.net/vxlan-deep-divepart-2
3. http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-685115.html
4. http://www.emulex.com/artifacts/d658610a-d3b6-457c-bf2d-bf8d476c6a98/elx_wp_all_VXLAN.pdf
5. http://blogs.cisco.com/datacenter/more-vxlan-qa/
6. http://blog.scottlowe.org/2011/12/07/revisiting-vxlan-and-layer-3-connectivity/
7. http://blog.scottlowe.org/2011/12/22/otv-and-vxlan-layer-3-connectivity-compared/

Introduction into tunneling protocols when deploying cloud network for your cloud infrastructure

Cloud network is a hot topic for cloud providers and hosting companies. In basic the concept should enable and allow tenants to create, manage and destroy network typologies on demand for the cloud servers by using cloud open API. That said, we want to allow a tenant to create an isolated virtual layer 2 network with its own IP subnet.

Before going into further details we have to realize that the problem isn't trivial to solve. The difficulty comes from a fact that the existing network that interconnects hypervizors hosts is not very flexible and adaptable for changes. That physical network architecture was build and tune to  allow to handle all traffic from all cloud VM across you cloud deployment. This represent its strength and limitation as it is not flexible enough when it comes to configure and create many isolated virtual layer 2 or layer 3 networks per single tenant. This is exactly the problem that the cloud network promises to resolve.

At the moment there isn't a single standard how to implement a cloud network. Instead, we have 3 different protocols that were proposed: VXLAN, NVGRE, STT [1].

All these protocols relay on the fact that the hypervisor hosts are interconnected  The implementation of the additional features is done by using tunneling mechanisms. All of them implement a L2 in L3 tunnels by using TCP, UDP or IP datagrams.

A short introduction and more explanation how this works can on the screenshots below that were taken from this video:  Video: Cloud Tunnels @ Cloud Mafia ( slies can be found here http://ifup.org/slides/cloud-tunnels/ )

References

1. VXLAN
2. NVGRE
3. STT