Can VXLAN and NVGRE solve your cloud network VLAN shortage?

Both VXLAN and NVGRE offer encapsulation methods that create thousands more VLANs in heavily virtualised environments and extend subnets over Layers 2 and 3. Do either work?

Virtualisation and the cloud have spawned all sorts of networking problems, but among the most frustrating have been the lack of necessary VLANs for complex virtual environments and the resulting difficulty in stretching network segments long distances between data centres.

To address these issues, VMware and Microsoft have squared off with two encapsulation and tunneling strategies, respectively: Virtual Extensible VLAN (VXLAN) and Network Virtualisation using Generic Routing Encapsulation (NVGRE).

Both the VXLAN and NVGRE use encapsulation and tunneling to group together related VLANs into subnets that can stretch across Layers 2 and 3. The idea is to address the limited number of VLANs enabled by the IEEE 802.1Q specification and to facilitate load-balanced, multi-tenant networks that can be shared across on-premises and cloud environments.

If both VXLAN and NVGRE take similar approaches, is one superior? Better yet, does either one work? That depends on who you ask. In this guide, contributor David Jacobs assesses the capabilities of both standards. Meanwhile, bloggers Ivan Pepelnjak and Martìn Casado offer up their opinions on each specification. Give them a read and decide for yourself.

VXLAN standard primer: Extended VLANs, long-distance VM migration

VMware's VXLAN aims to extend segmenting for multi-tenant networks by grouping VLANs associated with an application into a segment using a 24-bit identifier called a VXLAN Network Identifier (VNI) in order to isolate application data. This enables VM migration across data centres within these tenants.

Virtual machine (VM) software does not need to be modified in order to operate in a VXLAN environment. A VM would create packets that are identical to packets that would be created in a non-VXLAN, non-virtual environment. In a VXLAN environment, a packet is enclosed in an outer Ethernet packet with the destination MAC of either the router that will forward the packet or the destination server. In a VXLAN environment, however, communication between VMs requires the broadcast packet to be sent to the IP multicast group associated with the VXLAN segment to which the communicating VMs belong.

VMs may also need to communicate outside of the VXLAN environment, which in that case would require no modification of the source VM or the destination equipment. A VXLAN gateway would just remove the VXLAN and UDP headers and forward the packet to the destination MAC specified in the packet set up by the VM.

Read this VXLAN standard primer to learn more.

Virtual Extensible LAN: Awesome or braindead?

The VXLAN standard might seem to be a sign from virtual networking heaven, but’s Fast Packet blogger Ivan Pepelnjak remains sceptical. In this Fast Packet blog, Pepelnjak raises important questions that networking professionals should ask themselves before committing to this technology. He also addresses what kinds of users would really need VXLAN -- and suggests that many don't need it at all.

Pepelnjak also addresses shortfalls of VXLAN, including the fact that there is still a lack of communication in this environment between physical devices such as switches and load balancers or firewalls. Such communication is a requirement of IP multicast for Layer 2 flooding in a VXLAN across any IP network.

Read the rest of Ivan’s review of the VXLAN standard for further insight.

NVGRE standard primer: More VLANs and isolated tenants in the cloud

Like the VXLAN standard, Microsoft's (NVGRE) standard proposal uses encapsulation strategies to create a greater number of VLANs for subnets, resulting in a wider extension across dispersed data centres and Layers 2 and 3. It also aims to enable multi-tenant and load-balanced networks that have the ability to be shared across on-premises and cloud environments. Yet there are some differences.

Some key capabilities of the NVGRE standard include identifying a 24-bit Tenant Network Identifier (TNI) to address problems associated with the multi-tenant network, and utilising a Generic Routing Encapsulation (GRE) to create an isolated virtual Layer 2 network that may be confined to a single physical Layer 2 network or extend across subnet boundaries. NVGRE also isolates individual TNIs by inserting the TNI specifier in the GRE header.

An additional differentiator between the two standards is in the way destination addresses are located. With the VXLAN standard, packets are flooded through the tunnel to locate destination endpoints, while the NVGRE standard defers the process for locating destinations to a future version of the specification.

Load balancing appears to be crucial in both proposals, but with VXLAN, random assignment of port numbers can be used to spread load, while NVGRE uses reserved bits in the GRE key field.

Read this primer to compare the VXLAN and NVGRE standards.

NVGRE, VXLAN and what Microsoft is doing right

There's room for both VXLAN and NVGRE, according to blogger Martìn Casado, but he also points out that neither specification is fully baked -- nor a complete answer for network virtualisation. Both specifications are currently limited in multicasting, and both are limited to supporting Layer 2 only within the logical network. As the standards mature, they will most likely broaden their capabilities regarding the control path.

Read Casado’s blog to see if you agree with him on the impact of NVGRE on a virtualised network and what Microsoft is getting right.

Read more on Telecoms networks and broadband communications