Enterprise Strategy Group | Getting to the bigger truth.TM

Posts Tagged ‘VEPA’

Networking and Virtualization Vendors Should Join the Open vSwitch Effort

Thursday, September 16th, 2010

My colleague Mark Bowker and I are knee-deep in new research data on server virtualization. Within this mountain of data, we are discovering some existing and impending networking issues related to network switching.

Today, many server virtualization projects are led by server administrators, with little or no participation from the networking team. As you may imagine, this means that the server team configures all virtual switches to the best of its ability, without considering how physical switches are already configured. As things scale, the server team realizes the error of its ways and quickly calls the networking group in to help out. This is where things really break down. Before doing anything, the networking folks have to learn the virtualization platform, understand how the physical and virtual networks should interoperate, and then roll up their sleeves and start gluing everything together.

This is a painful learning curve but I believe that future issues will be far more difficult. As organizations increase the number of VMs deployed, networking configurations get more difficult — especially when VMs move around. Users regularly complain about the number of VLANs they have to configure, provision, and manage. This situation will grow worse and worse as VMs become the standard unit of IT.

In my mind, it makes no sense for virtualization vendors like Citrix, Microsoft, Oracle, and VMware to recreate the richness of physical L2 switches in the virtual world. So what can be done? Well one alternative is to eliminate virtual switches entirely and do all switching at the physical layer via the Virtual Ethernet Port Aggregator (VEPA) standard being developed in the IEEE.

I believe this will happen but in the meantime there is another alternative being discussed this week at the Citrix Industry Analyst Event — Open vSwitch. As described on the Apache web site, “Open vSwitch is a multilayer virtual switch licensed under the open source Apache 2.0 license. The goal is to build a production quality switch for VM environments that supports standard management interfaces (e.g., NetFlow, RSPAN, ERSPAN, CLI), and is open to programmatic extension and control.”

Here’s why this makes sense to me:

  1. Given a pool of collective resources, a collaborative open effort would provide more advanced switching functionality sooner rather than later.
  2. An open alternative would expose APIs that could be easily integrated with leading switch management tools from Brocade, Cisco, Extreme, Force 10, HP, Juniper, etc.
  3. Vendors would not have to integrate with each hypervisor independently. This would improve code quality and again speed time-to-market.

At the very least, Citrix, Microsoft, and Oracle should back this as a way to push back on VMware’s marketshare lead.

I’ve been around long enough to know the strengths and limitations of open source and standards but I think that with the right support, this one could have legs. I know that vendors have their own businesses to look after but isn’t another end goal to create products that the market wants? I think Open vSwitch would fit this bill.

The VEPA standard — a potential game changer?

Thursday, December 3rd, 2009

I recently spoke with Extreme Networks about its data center networking strategy. One of the highlights for me was Extreme’s plan to embrace the Virtual Ethernet Port Aggregator (VEPA) standard being developed in the IEEE. In simple terms, VEPA off-loads all switching activities from today’s hypervisor-based virtual switches to actual physical switches. There is a bit of debate between HP and Cisco whether this switching should occur at an edge or aggregation switch (note: I like HP’s approach), but suffice it to say that each vendor’s goal is similar.

What’s the big deal about VEPA? According to ESG Research, most enterprises run between 5 and 10 VMs across one virtual switch on each physical server. Pretty elementary stuff, but moving forward it is likely that the VM to server ratio will increase and as it does, server-based networking will have to become more sophisticated. Imagine a physical server running 30 VMs for example. This might require several virtual switches, VLANs, QoS tags, security zones, etc. This network processing will add a lot of overhead to Intel-based servers and require a lot more networking functionality for hypervisors. VEPA proposes an alternative approach where servers remain servers (i.e. for application processing), provide hypervisor visibility to the network, and simply delegate switching tasks to physical switches.

To me, this makes a ton of sense from a security and networking perspective. If next-generation switches support VEPA, it should make the whole virtual data center/cloud migration a lot more straight forward.

My one suggestion would be some type of alignment between VEPA and OVF (i.e. Open Virtualization Format). OVF is a proposed meta data standard to describe the properties of a VM. When a VM moves from one server to another local, remote, or cloud-based server, OVF could provide VM tags that describe networking properties to other VEPA switches (VLAN tags for example). Combined, VEPA and OVF could help automate networking and security operations associated with virtualization and cloud.

If virtualization is really the road to true cloud computing, virtualization intelligence sharing is critical for network engineering and security. VEPA is a step in the right direction toward this goal.

Search
© 2011 Enterprise Strategy Group, Milford, MA 01757 Main: Fax:

Switch to our mobile site