In the last month, no less than two new standards were submitted to the Internet Engineering Task Force to improve...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the scalability of virtual LANs in very large virtual environments. But the emerging tussle between VMware and Cisco’s VXLAN and a Microsoft consortium’s NVGRE is probably more a matter of vendor politics than technical need, some networking experts say.
Benefit to the end user? None.
- Ivan Pepelnjak, chief technology advisor at NIL Data Communications
Both Virtual Extensible LAN (VXLAN) and Network Virtualization using Generic Routing Encapsulation (NVGRE) dramatically increase the number of possible VLANs from 4,094 today, to over 16 million. They do so using network encapsulation -- the insertion of additional headers into IP packets -- to add 24-bit network identifiers (in VXLAN called the VXLAN Network Identifier and in NVGRE called the Tenant Network Identifier) to virtual machine traffic.
Cisco, VMware, Arista Networks, Broadcom Corporation, Citrix Systems and Red Hat Inc. co-authored VXLAN’s Internet Engineering Task Force (IETF) draft in August and announced the technology at VMworld 2011.
Microsoft, Arista, Intel, Dell, HP, Broadcom, and Emulex co-authored NVGRE and submitted it to IETF in September. It was uncovered during the Tech Field Day conference last week.
Another problem these specs are looking to solve is the separation of virtual segments from physical networks, with the added goal of easing management in large cloud service provider or enterprise data centers. In networking speak, both specs route layer 2 over layer 3.
According to Ivan Pepelnjak, chief technology advisor at NIL Data Communications and independent blogger at ioshints.info, “today, network admins and server admins have to coordinate VLAN usage. With VXLAN, they live in parallel universes.”
At least in theory, making layer 2 traffic routable over layer 3 should cut down on the amount of manual configuration needed at the physical network layer to direct network connections to the right place as a virtual machine (VM) is moved live, whether within or across data centers.
At VMworld, VMware and Cisco emphasized the VM mobility angle of VXLAN, and a Cisco whitepaper about VXLAN mentions “transporting virtual machines across a broader diameter” as a goal of the spec.
With VXLAN, the primary focus is “on the networking infrastructure within the data center and the issues related to them,” according to the IETF draft. At the same time, an important requirement for virtualized environments “is having the layer 2 network scale across the entire data center or even between data centers for efficient allocation of compute, network and storage resources.”
Improved VM mobility could also have implications for public cloud adoption, authors of the NVGRE draft argued, but that is still down the road:
"One application of this framework is that it provides a seamless path for enterprises looking to expand their virtual machine hosting capabilities into public clouds. Enterprises can bring their entire IP subnet(s) and isolation policies, thus making the transition to or from the cloud simpler. It is possible to move portions of an IP subnet to the cloud, however, that requires additional configuration on the enterprise network and is not discussed in this document."
A new space race?
VXLAN and NVGRE take slightly different approaches to network virtualization. To experts, the VXLAN standard seems a bit more fleshed out in its IETF draft than NVGRE, which makes several references to problems which must be solved separately or in forthcoming versions of the draft. It’s also important to note that VXLAN is supported in a shipping product (the Nexus 1000V) today, while Microsoft’s approach remains theoretical.
There are other subtle differences between the way the specs operate.
“VXLAN uses UDP which is lossy but easy to handle, whereas NVGRE uses Generic Route Encapsulation which is [a] standard [form of] tunneling,” said Greg Ferro, a network architect at a bank in the U.K. and the author of the blog Etherealmind.com.
But at a high level, the differences are negligible, experts say, meaning the differentiation between them -- and thus the impetus for dual standards at this point -- is probably more political than technical.
Meanwhile, “nobody seems to be heading toward any reconciliation of these two standards,” said Eric Hanselman, an analyst with the 451 Group. “Everybody seems to be digging in for a pitched fight.”
Experts debate whether virtual networking needs either of these standards. Some point out that technologies such as OpenFlow, which introduces a software management broker above the network to do sophisticated routing, or layer 2-level encapsulation technologies such as QinQ, are already being developed or used today to solve similar problems.
Ferro compared VXLAN to the various storage APIs VMware released in vSphere 4.1 and 5, which suck storage management functionality up into the hypervisor. “VXLAN allows [VMware] to program [network virtualization] into their vCenter console, and in my opinion probably pull an IBM. They want to own the ecosystem.”
Now, it appears, both major virtualization vendors -- and their respective camps -- want a stake in this space race.
“This at least smells like something that’s been a primarily VMware and Cisco-led effort that’s trying to make sure that they can solidify some level of control over… the next step in virtualization, which is network virtualization,” said Hanselman. “I think [NVGRE] is just Microsoft and HP… firing a shot across VMware and Cisco’s bow saying ‘hey, if there are going to be standards, well heck, we can participate in this too.’”
In the meantime, two standards muddy the waters even further.
“It's all about us-versus-them. Microsoft versus VMware, HP/Dell versus Cisco, Pepsi versus Coke,” Pepelnjak said. “Benefit to the end user? None.”
Beth Pariseau is a senior news writer for SearchServerVirtualization.com. Write to her at firstname.lastname@example.org.