Unleashing the Power of Software-Defined Networking on Virtual Tunnels

Posted by Mike Fratto
June 08, 2012

Tired of long wait times for new networking features? Software-defined networking (SDN) may be the answer. Case in point: Big Switch Networks plans to bring switch virtual tunnel endpoints to market this summer.

SDN is a great idea, but, at some point, it has to solve practical problems for IT. There are lots of theories and promises but precious little there there. The big cloud providers like Google are doing cool things with OpenFlow, but their lead doesn't necessarily translate down to the enterprise market. On the other hand, the overlay protocols like NVGRE, VXLAN and STT aid in VM-to-VM networking, but they complicate integration of the physical network with the virtual one. But here's a case in which SDN can solve thorny issues quickly.

Big Switch announced a new application (in beta now but shipping by the end of summer) that runs on its controller and will program OpenFlow switches to terminate virtual tunnels in switches and routers directing traffic from the OpenFlow network to the Ethernet network. The switch can be a dedicated OpenFlow switch that's fully programmed via OpenFlow or a hybrid switch that simultaneously runs the native OS and an OpenFlow environment.

If the switches are running OpenFlow 1.2 or 1.3, then Big Switch's controller can terminate the virtual tunnels seamlessly. If the switches are running OpenFlow 1.0, which is currently more likely, then the switch vendor has to add support for the required extensions Big Switch uses to program the tunnel termination. Big Switch is also adding the ability to program the hypervisor virtual switches directing traffic into the overlays as if they are OpenFlow switches.

These are important steps not only for Big Switch, but also for the OpenFlow protocol and the value of SDN. The proponents of network overlays such as VXLAN, NVGRE and STT argue that physical networking is too constrained to meet the demands of a virtualized data center or private cloud. Even if you aren't operating at Amazon AWS scale--like most IT shops--the difficulty in getting the physical network and hypervisors integrated poses a challenge for virtual machine mobility, interconnectivity and bandwidth management.

Overlays like VXLAN, NVGRE and STT encapsulate network traffic between virtual switches. Since the virtual switches are tightly integrated with the hypervisor, there's no need to synchronize state with the physical network, and the virtual network can operate independently of the physical one. Overlays have the additional problem of integrating existing physical appliances with overlay networks.

The solution is to have a virtual tunnel endpoint, which decapsulates the network traffic from the overlay and forwards it on to the next destination. Currently the tunnel endpoints are the hypervisors themselves, but they could also be physical switches or other devices like firewalls, routers or load balancers (to name a few). Traditional equipment vendors tunnel endpoint support specific to each protocol and updated via firmware. Like all things IT-related, the most widely deployed products--in this case, VMware and VXLAN--will likely be supported first and the others will be delayed pending "customer demand" (a euphemism for "we don't really care about your needs until you show us the money").

Big Switch's beta application shows that IT doesn't necessarily need to wait for big equipment vendors to implement new features via firmware upgrades because the network, through the controller in the case of OpenFlow, is programmable. Depending on the ability of your controller's vendor to add new features or your organization's programming ability, the speed in which you can get new features may be getting faster.

Mike Fratto is editor of Network Computing. You can email him, follow him on Twitter, or join the Network Computing group on LinkedIN. He's not as grumpy as he seems.

Related Reading