VMworld: Brocade Announces Support for VXLAN

By itself, Ethernet isn't well suited to virtual machine networking. Traditional technologies like those from VLAN isolate applications and tenants from one another, but making sure the VLANs are properly provisioned and managed is complex and error-prone. Network overlay protocols like VXLAN resolve many of those problems by creating a virtual network that's independent from the physical one. However, traffic on overlay networks may still need to be forwarded onto a network outside the overlay domain. Brocade announced at VMworld this week that it's adding support for VXLAN to its application delivery controller (ADC), the ADX, which should ship by year's end as a free upgrade.

VXLAN tunnel endpoints map VXLAN traffic to the physical network--usually a VLAN--so that Ethernet traffic from virtual machines can reach applications that aren't virtualized, like firewalls, the Internet or Oracle’s E-Business Suite (which many organizations don't want to virtualize in order to maintain consistent performance). The tunnel endpoint is a gateway that maps VXLAN-encapsulated traffic onto VLANs or physical networks. Brocade is adding VXLAN TEP to the ADX rather than its switch line because the ADX already contains the software to maintain high availability, stateful failover and load balancing. The alternative would be adding TEP functions to its switch line, but it would also have to add the HA and ADC features, as well.

Brocade is targeting the VXLAN capabilities for two sorts of customers: first, for large carriers and providers that simply need an HA VXLAN tunnel endpoint, and, second, for enterprises or cloud providers that want to perform both VXLAN tunnel endpoint as well as leverage the ADX's application delivery features. In either case, the ADX is a critical part of the infrastructure, and to achieve lossless failover means using only 50% of the capacity on each ADX so that one appliance isn't oversubscribed. We'd like to see Brocade increase the number of ADXes in an HA cluster, which would offer better scaling and session protection against any single ADX failure. Combining tunnel endpoints and application delivery functions, along with Brocade's OpenScript automation software, also solves a problem with automatically inserting an ADX into an application stack. Pointing application traffic at an ADC makes the application resilient--but the ADC has to be preconfigured to handle the traffic, which is usually a separate, manual step.

Brocade's tunnel endpoint feature is managed through a plug-in to VMware's vCenter and vShield via Brocade’s Network Advisor. Working with vShield, the VXLAN provides support for multi-tenant public and private clouds that are isolated from the VM to the physical network using VLANs. In addition, applications can be load-balanced and scaled on demand using the ADX and the company’s Application Resource Broker. In addition, managing tunnel endpoint configurations can be automated using Brocade's OpenScript automation capability, which the company acquired with the Foundry acquisition.

VXLAN isn't the only overlay protocol being developed for virtual networking. VXLAN is an IETF Experimental overlay protocol spearheaded by Arista, Broadcom, Citrix, Cisco, Red Hat and VMware, while a competing overlay protocol--NVGRE--is being developed by Microsoft, Dell, Emulex HP and Intel. None of these protocols is in the IETF standards track, so all products should be considered proprietary implementations. (For more on both protocols, listen to an extensive podcast from Network Computing contributor Greg Ferro.) Nicira, prior to its acquisition by VMware, also published Stateless Tunnel Transport (STT) as an informational RFC. There are also purely proprietary overlay products from the likes of Embrane and Context Stream.

In all of these protocols and products, there needs to be a way to interact with servers and appliances on the physical network. One way to manage this is to use a VM within a hypervisor as a tunnel endpoint--Brocade’s virtual ADX can do that, but there are performance considerations that affect scalability. Since VMs can move, administrators need to ensure that the VLANs are present wherever the virtual tunnel endpoints are. Hypervisors could also perform tunnel end functions, but that adds more processing requirements on the hypervisor already burdened with managing shared compute, memory and I/O subsystems. Hardware tunnel endpoints will likely be the preferred way to bridge virtual and physical networks for organizations large and small.

As overlay protocols mature, we expect to see tunnel endpoint features show up in other ADC products, like Cisco's ACE and F5's Big-IP, as well as switching and routing platforms.