Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
What happens when your VLAN reaches 4,094 tags? If your switches haven’t crashed by then, you run out of space. That’s fine if you’re only building virtual networks in tiny places, but if you want to create logical networks that are scalable and link your virtual machines across different networks, then you need something else.
That something else is Virtual eXtensible Local Area Network (VXLAN), the current pop star of overlay technologies. A protocol developed by VMware, VXLAN lets you create a Layer 2 network on top of a Layer 3 network using encapsulation, increasing the number of entities you can connect up to about 16 million. Since virtual machines (VMs) can’t connect across multiple Layer 2 networks without breaking their links, it’s a game-changer for the software defined network and is now fully supported inside Linux. VXLAN bounced into the cloud services environment in 2011.
Benefits of VXLAN
The benefits are obvious. VXLAN can solve the problem of wanting overlay networks in virtualized data centers with multiple tenants and Layer 2 connectivity across several data centers. It can address the security issues that come with VLAN groupings. It provides the flexibility to create new networks on the fly when used in conjunction with other VMware solutions like vCloud Director. It fools VMs into believing that they are part of one big, flat network, and it’s massively scalable. Perfect for bigger virtual networks.
We really do need new solutions for bigger virtual networks, by the way. With Gartner predicting $72 billion being spent on Infrastructure as a Service (IaaS) before 2016 and public cloud services growing at a compound rate of 17.7% through 2016, the VXLAN protocol is the start of a different approach to software-driven networks.
VXLAN’s performance problem
VXLAN isn’t a perfect solution, of course. In a world where we can Google something in a fraction of a second, response times are everything. Infrastructure performance is a deal-breaker for many companies wanting to use virtual networks. After all, if your user response times are poor, you’re setting yourself up for trouble. Unhappy customers, endless complaints, lost sales…Your service desk has heard it all before, and your senior management team won’t want to go there. So network professionals don’t want to risk anything that could upset the delicate balance of hardware and software that gives speedy response times. And VXLAN carries that risk.
VXLAN has many benefits, but it can impact your IaaS performance. A performance evaluation study done by VMware itself shows that adding VXLAN capabilities to your network can raise CPU overhead. The protocol adds an additional layer of packet processing, which requires adding and then removing protocol headers, so that’s some extra work for the CPU. The rest of it comes from the need to process encapsulated packages differently: for example, the system can’t use the standard offloading capabilities of the network interface controller (NIC), so the CPU has to perform these tasks instead.
If you’re already struggling with high CPU utilization, you’d be advised to fully investigate the impact that VXLAN will have on your network before making the jump to this protocol.
VXLAN, NVGRE, and STT: what’s your best choice?
The VXLAN protocol is still fairly new, but plenty of companies are jumping on the bandwagon and rushing to launch VXLAN-compatible products. VMware announced that it developed the VXLAN protocol in conjunction with other serious industry players like Cisco, Citrix, Red Hat, Broadcom, and Arista Networks, so from its inception, it already had a wide base of switch stacks and other products that worked with the protocol. A quick vendor survey today shows that more and more products support VXLAN natively, including F5’s BIG-IP solutions and Mellanox Technologies’ ConnectX-3 Pro adapter cards.
While it might seem like everyone is busy pushing out VXLAN solutions, however, VXLAN isn’t the only choice for a network overlay protocol. NVGRE (Network Virtualization using Generic Routing Encapsulation), supported by giants like Microsoft, Intel, HP, and Dell, is also a contender. This protocol does broadly the same thing as VXLAN, using another approach to encapsulation, but it suffers from issues with load balancing.
VMware also supports the other encapsulation format, STT (Stateless Transport Tunneling), now that it has acquired Nicira. STT works well with off-the-shelf NICs, cutting those pesky CPU processing overheads, as it has been designed to tunnel between hypervisor and hypervisor. That CPU benefit might not last for long, though, as the big development for the future of VXLAN will be to bring out solutions that eliminate the processing overhead.
That’s three protocols. While you could use STT and VXLAN together (one to sort out the CPU processing issue and deal with hypervisor-to-hypervisor links, the other to operate in a multi-vendor environment), we’re still going to see competition in the market for the foreseeable future. However, using the number of demos of VXLAN at VMworld last year as an indicator, commentators like Mike Fratto say that VXLAN is the clear leader in the overlay protocol market. This is partly because it’s backed by VMware and Cisco, and partly because the industry can cope with only so many standards, and VXLAN got there first.
All three protocols have submitted their drafts to the Internet Engineering Task Force (IETF), which is the primary standards-setting body. Over the next few months (and perhaps longer), we’ll see the protocols battle it out to become both an adopted standard and the market leader. For now, VXLAN is top of the pile, but as with all things in networking, nothing stays still for long.
