What WAN Optimization Can Teach SDN About Tunneling
November 06, 2012
As software defined networking (SDN) and network virtualization adopt tunneling as a means of communication, long-time detractors of tunnels are now re-assessing their positions and even touting the technology's benefits. One question that IT needs to ask, however, is how it will manage hundreds or thousands of tunnels created in an SDN environment. Lessons learned in the WAN optimization trenches may hold the answer.
For years, tunnel opponents argued that the technology introduced numerous problems, including wasted bandwidth and CPU cycles, and increased complexity from having to configure tunnels. Blogger Michael Morris also added "sub-optimal routing, MTU issues, and hardware/software scalability issues." On the WAN side, it was argued that tunnels might introduce security problems because WAN optimization techniques such as deduplication and compression obscured the payload.
- Agile Service Desk: Keeping Pace or Getting out Paced by New Technology?
- Cobol Techniques For Today And The Future
- Approaches to DDoS Protection: An Overview on Keeping Your Networks Protected
- Advanced Endpoint and Server Protection
- Research: Federal Government Cloud Computing Survey
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
Tunneling proponents countered that tunnel overhead was nominal both on the CPU and the network, and that complexity issues could be resolved through software and best practices. As for dedupe and compression, security policies always needed to be applied prior to WAN optimization.
But now SDNs and virtual networks in general are putting a kibosh on the whole debate. "Tunnels seem to have won," said Stephen Riley, technical director in the Office of the CTO at Riverbed in a recent newsletter explaining the intersection of virtual networks and SDNs. According to Riley, tunneling plays an important role within a software-defined network.
"Most commonly, when the VM in physical machine A wants to talk to the VM in physical machine B, the result is a tunnel that is plumbed from the physical machine A to the physical machine B," he wrote.
As for concerns around tunnel overhead, he pointed to this blog post by Martin Casado, the CTO of Nicira Networks and a consulting professor at Stanford University. (Nicira was acquired by VMware in July). Casado showed the overhead of running a network tunnel to be nominal, if at all:
"At its most basic, a tunnel is a handful of additional bits that need to be slapped onto outgoing packets. Rarely, outside of encryption, is there significant per-packet computation required by a tunnel. The transmission delay of the tunnel header is insignificant, and the impact on throughput is--or should be--similarly minor." Of course, Casado has an interest in tunneling, as Nicira's technology makes extensive use of it. (Not to mention the fact that Nicira's parent company is a major backer of the VXLAN draft standard.)
That said, the best SDN and network virtualization implementations will provide the tools and technologies to simplify and manage tunnel creation. But this problem is hardly unique to SDNs. WAN optimization vendors have developed extensive tools and features to ease the establishment and management of their own optimization tunnels.
Enterprise buyers can use these features to set expectations with their own SDN and network virtualization providers. Such features to look out for include:
• Automated tunnel creation at configuration and in response to new network conditions.
• Automated tunnel assignments where traffic is automatically assigned to new tunnels based on predetermined criteria.
• Group management that lets IT easily define parameters across tunnels.
By adding these and other features and tools to their architectures, SDN deployments will become far simpler to manage and deploy. Without them, SDNs will resurrect old tunneling critics to carry on old battles--something nobody really wants.
David Greenfield is a long-time technology analyst. He currently works in product marketing for Silver Peak.