News Stay informed about the latest enterprise technology news and product updates.

vCloud and VEPA both fail in virtualization networking

vCloud and VEPA both fail to address the problem with networking for virtualization. The goal of network-aware virtualization is to enable a flat Layer 2 network and networking functions within the virtualized environment, but neither approach enables switching and traffic management within vCloud or vSphere for a truly dynamic cloud, says Fast Packet blogger Ivan Pepelnjak.

If you’ve been designing a virtualized data center network recently, you’ll probably agree that it’s awfully hard to build the scalable flat Layer 2 network domains necessary to support dynamic virtual machines in a private cloud. One would expect useful virtualization networking solutions when every networking and virtualization vendor trumpets its commitment to “flattened,” “agile,” “green,” “next-generation,” “private-cloud-enabled” data center networks. But in reality, all we’ve seen are kludges aimed at winning the minds (and budgets) of various factions of the data center team.

Check out Ivan's blog: Cisco IOSHints

The problem began with VMware, which had to implement switching functionality in its ESX hypervisors to enable connectivity between virtual machines running within the same physical server. The company could have implemented Layer 3 switching, but it decided instead to take the easy route and build a sub-standard switch, which after several years still lacks feature parity with SMB products you can buy at Office Depot.

But embedding third-party Layer 2 switches in physical servers hasn’t worked as a virtualization networking solution either. Since servers could no longer be treated as end-hosts, physical switches had to peer with them on trunked links. We all know large-scale bridging environments tend to be fragile -- and coordinating changes between two teams (when the server team handles whole VMware configurations) made deployment and troubleshooting even more fun.

Virtualization networking solutions emerge -- but still don’t work

VMware has tried to address these virtualization networking problems with the vCloud Director, which implements switching, routing, firewalling, NAT and even DHCP servers within the VMware framework. vCloud could have been a great product, but instead VMware decided to use proprietary protocols and implement most of the networking functions in virtualized appliances. For example, its MAC-in-MAC encapsulation doesn’t follow any standard known to the industry, though the 802.1ah standard (specifying MAC-in-MAC encapsulation) was published two years ago.

Read more Fast Packet bloggers

VMware’s GUI definitely satisfies the eye candy requirements (and must look fantastic in demonstrations), but vCloud fails to solve any of the significant problems: VM mobility still requires bridging; bridging is no more scalable than it was before vCloud, and the traffic trombones are still winding their way around your data center.

Meanwhile, Cisco took a stab at networking for virtualization and launched the Nexus 1000V (which became part of the VN-Link/VN-Tag strategy) with a subliminal “take the control back” message to the networking team. And other networking vendors are hastily inventing Virtual Ethernet Port Adapters (VEPA) -- a technology that would pull all the traffic out of the hypervisor and let the first-hop switch handle all the necessary aspects of bridging, VLANs, routing, QoS and security. Cisco’s VN-Tag story is being considered by the IEEE, along with the VEPA standard (802.1Qbg). The VEPA vendors are quick to tell you how fantastic your life will be after VEPA gets implemented, but they keep quiet about an important detail: VEPA will need hypervisor support. While VMware has supported the Nexus 1000V, I doubt the company will jump at the opportunity to implement VEPA in its vSwitch now that it has a competing product.

What’s more, VEPA does not solve any of the aforementioned problems; it just gives you a different GUI/CLI -- meaning you’re configuring virtual NICs on the physical switches, not in vCenter/vCloud.

With all the confusion and half-baked solutions that vendors are generating, one has to wonder about the real reason for their frantic activities. The answer is simple: All of them are after your limited budget.

If VMware persuades you to go with vCloud, you will need dumb, low-cost commodity switches that are able to perform rudimentary bridging between ESX servers. If the networking vendors sell you on VEPA, you won’t buy vCloud and vShield licenses, but you will have to invest in smarter switches.

But in the heat of the marketing arguments, everyone forgot what the customers really want: A scalable, manageable solution supported by all parties. Easy end-to-end orchestration would be almost too much to hope for, but let’s add it to the wish list. Would it be too much to ask you, dear vendors, to focus on that?

About the author: About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Check out his ISO blog

This was last published in December 2010

Dig Deeper on Server Virtualization Networking

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.