VMware: Let’s get logical – the case for OpenFlow network virtualization (and their failed network plans)

In this blog post at VMware Communities: Security & Networking: Let’s get logical – the case for network virtualization, Alwyn Sequeira ( VP of Networking I think) is talking about how OpenFlow could impact the way that networks are virtualized. When it comes to network virtualization, VMware could play a huge role in changing the shape of the industry. Alwyn says:

In summary, the rigidity and static nature of current network architectures stand in the way of the agility, flexibility and dynamic requirements of modern workloads. Network re-mapping becomes an ongoing, onerous task. A better approach is needed, one which separates the consumption of these network constructs from the underlying physical network. We need to un-tether VMs from the underlying physical network, much as we un-tethered OSes from the server hardware.

VMware has made several strategic moves to implement dynamic networking and overcome the static nature of networking :- vSwitch, vDS, Nexus 1000 (in partnership with Cisco), vCloud External Networks (using MAC in MAC of all things) and have basically failed to deliver overlay technology without implementing technology in the network itself or going for a vendor lock in. Equally, VMware hasn’t been willing to engage with the networking vendors to develop technologies that would solve this problem – and let the IEEE waste time with VNtag / VEPA1 / VEP combined with TRILL 2 / SPBB3, and letting them argue amongst themselves while we wait for the moths to fly up when the next announcement comes from the IEEE 802.1 committee. VMware’s attempt with vCloud networking using MACinMAC encapsulation seems to have failed ( because of undirected broadcast and security concerns) and stalled and they getting set to have another attempt this time using MACinIP.

But what VMware really wants is a software controlled network – just like VAAI – vStorage API’s for Array Integration they want to be able to reduce the network to a set of APIs.

Whoa. That’s a big thing. Having your network configured by software using APIs is kind of new. Or is it ?

Lessons from Storage APIs

Lessons to be learned from the storage folks is that reducing client configuration storage functions to an API didn’t stop EMC or NetApp etc from selling storage. In fact,  it increased the marketplace by making storage arrays easier to use and get business value from for the first time in 20 years. This reduced the friction to buying and implementing even more storage than every before and you can bet they are rubbing their hands over the increased dedupe and backup licenses on the arrays.

Although the customer may not place so much reliance on the firmware in the array boxen like previously, this doesn’t mean those features and functions aren’t required, only the front end that defines certain subset of storage function has been given away.

It’s will probably be same for networking. OpenFlow does not mean that you won’t be configuring switches, routers and firewalls in the future – you will still do that, but some subset of functions will be abstracted into an API for remote configuration, management and administration.

What will the Networks APIs look like ?

So what will these functions be ? In my current perception, I guess the most likely functions are:

  • VLAN creation and port membership
  • QoS Policy
  • port activation and switch provisioning (for very large / Cloudy networks)
  • ACLs / Security features

That’s about it. Most OpenFlow controllers implementations are going to struggle to handle these functions alone and more complexity would require multiple generations of software.

A serious risk to the incumbent vendors ( Juniper, Cisco et al) would be that VMware implements a viable OpenFlow controller and begins to control the top layer of the network stack and thus disintermediates them. I’m sure that the vendors just want VMware to develop an API for VMware / Citrix Xen / HyperV to call and they will provide the “value”. I’ll bet the vendors will be fighting this very hard over the next two years or so.

The EtherealMind View

VMware and other virtualization platforms are demanding virtual networking that is driven by software tools, and they aren’t likely to wait. The virtualization has a lot of push (and hot air) and some serious cash to make things happen. This is what I think drives the OpenFlow opportunity. The fact the people like Alwyn Sequira in making noises tells you that it is serious, and Citrix already has a working implementation as demonstrated here at Interop

OpenFlow might be all clamour and noise, but there is a logical line I can draw from the virtualization vendors to implementation – people like James Hamilton appears to be planning for it at Amazon. I’ve spoken to Facebook about it, they’ve got something going on. While these networks mean nothing for normal enterprises, they will drive exposure – sometimes that’s all it needs to make a technology be adopted.

My view is that Software Defined Networking is well overdue. Networking has been constrained by protocols that attempt to take the discrete elements of network and attempt to create a contiguous infrastructure element. However, those same protocols that attempt to create coherence out of hundreds or thousands of devices are not flexible. Our current network protocols don’t readily change to conditions in the network like congestion, or failure, or dynamically shift loads according to predicted conditions (such as backups for example), or provide automated deployment, or dynamic software configuration from an external system.

And why not ? A simple rules based system for network configuration should be possible. A little intelligence around VLAN creation, or ACL in a system that knows and can parse the configuration of devices isn’t that hard to do compared to the business opportunity that it creates.

And that’s what it’s all about.


  1. Another standard that the IEEE can’t get it’s act together and get out the door. Most likely it being hung up by one of the vendors but no one is saying anything.
  2. TRILL has a number of proprietary variants at this time including Cisco’s FabricPath and Brocades VCS.
  3. SPBB is an incomplete IEEE standard that is taking far too long to ratify, but is probably the long term winner in the L2MP stakes because it works equally well for campus & MANs as it does for Data Centres. And scale wins in the terms of producing mass market acceptance.
  • Bobby Light

    You ever heard of Nicira Networks? They claim to have a “Network Hypervisor” but seems very much like an OpenFlow wrapper.

    Also – Has anyone tinkered with installing Open Vswitch on an Arista device?

    This stuff is getting interesting for sure…..

    Nice Article Greg!

    • Ferro Greg

      Nicira is working on an OpenFlow controller, and they recently acquired Pronto Systems for the OpenFlow ready switches (if I remember these things rightly) so they are an end-to-end OpenFlow solution (-ish).

      I also think that Wireless Networking is probably a much bigger winner from the OpenFlow opportunity but it’s a bit early to visualise that.

      Edit: In fact, Pronto acquired PICA8 to have a hardware platform. Apologies and consolations to all.

      http://prontosystems.wordpress.com/2011/04/12/pronto-to-acquire-pica8/

  • Juan Lage

    “Our current network protocols don’t readily change to conditions in the network like congestion, or failure, or dynamically shift loads according to predicted conditions (such as backups for example), or provide automated deployment, or dynamic software configuration from an external system”

    Congestion isn’t the most common problem in non-WAN environments, and you are mostly talking of DC fabrics. In fact, there are network protocols available that can allow networks to adapt to congestion, but they are not deployed in most network environments because the added complexity is not justified. Existing network protocols most definitely DO change conditions (reconverge) in cases of failures, and they do that pretty well and pretty fast. There are tools available to provided traffic engineering and dedicated topologies to certain traffic needs (i.e. backups) with existing network protocols. Dynamic ACLs are being used on a per user basis on many customers today, and the same technology could be applied to VMs with minimal changes.

    As for automated deployment and dynamic software configuration, it comes down to orchestration systems. No need to change the way networks work for this, and most vendors (including Cisco and Juniper) offer XML APIs to such orchestration systems.

    The existing network protocol stack isn’t the limitation to virtualization. The lack of knowledge of networking within the companies driving virtualization is.

  • Madbox Mail

    I’m standing close to dynamic networking for a while. Don’t you think that openflow like oproaches can take a real place in a enterprise world far faster than official standards will be finished? Open flow keeps hardware networking in its easy nature but allows smart managing by third party “magic” software. Cisco and Juniper have their interest in a software solutions (or it seems so). Such a tech can be realized in a cheap manner and it can be a light point in a networking “dark tunnel”.