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.
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
- Fast Packet blogger Michael J. Martin asks: Where's the session-based application-aware routing? It's certainly not what vendors promise.
- Beyond anti-social behavior, enterprise guest wireless networks and Wi-Fi hotspots cause businesses a heap of trouble, according to Fast Packet blogger Jennifer Huber.
- Fast Packet blogger Brandon Carroll wonders whether you have a meaningful enterprise security policy.
- Fast packet blogger Josh Stephens wants to know if you're really prepared to manage the distributed enterprise network.
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 http://www.nil.com 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