IBM launched a Nexus 1000V competitor

Three days ago IBM launched Distributed Virtual Switch 5000V, its own distributed vSwitch for VMware ESX platform. On one hand, it proves Cisco has been going the right way with Nexus 1000v (just in case you wondered), on the other hand, things just got way more interesting – IBM is obviously returning to networking.

The feature list of the DVS 5000V is not impressive (bonus point: unlike vSwitch it does include LACP), and it sure looks like a me-too product, until you come to EVB support. Not having anything to lose by implementing standards favored by other vendors, IBM jumped head-on into technology that makes the most sense if you believe VLANs are the way to go when implementing virtual networks.

IBM already has EVB/VEPA support for KVM.

You still need two to tango – EVB support in the hypervisor doesn’t buy you anything unless it’s also implemented in the adjacent switch, and it’s not clear yet which ToR switch you could use. Force10 announced EVB support way before they were bought by Dell and hasn’t delivered yet, HP is promising EVB for years (with no visible results, although HP 5900 is supposedly VEPA-ready), and I couldn’t find anything EVB-related in the specs for IBM’s BNT switches.

There might be an interesting twist in this story. You don’t have to implement EVB in the ToR switches if you’re using OpenFlow. EVB is a control-plane-only protocol and thus a perfect fit for a software module in an OpenFlow controller. We know IBM and NEC are working together on proving OpenFlow is ready for enterprise networks... looks like we have a few very interesting years ahead of us.

Need more information?

Introduction to Virtualized Networking webinar has a pretty self-descriptive name, as does VMware Networking Deep Dive and Data Center Fabric Architectures. All three of them are available as part of the yearly subscription.


  1. Is this a response to Cisco blade solution (UCS)?
  2. It was only a matter of time before this market segment would receive more attention. IBM will certainly not be the last one.
  3. Agreed. Yawn. No OpenFlow? Ok then.. what about Q-in-Q? PBB? I'm ready for something new and different in the vSwitch space... Nicira is already doing better.
    1. How is that new job at VMWare?
  4. Very interesting. While IBM entering the space does give some validation to Cisco's efforts, the timing seems very late. The general feedback that I've been hearing is that VMware's virtual switch has been closing the gap with Cisco and that with each upgrade of vSphere that Cisco is losing customers due to challenges with upgrades (and the solution has always on the expensive side, limiting overall adoption). It makes sense for IBM to be more active in edge-networking, we'll see if it has any impact on slowing its decline in bladeserver market share.
  5. Yep, spot on. The Nexus 1000V was always a tough upsell in my experience, and an increasingly capable VMware VDS doesn't make it any easier.
  6. According to this document: it's source MAC address snooping (similar to what Force10 is doing) and thus not even in the same universe as EVB.
  7. BNT is doing something called VMready which they claim to be compatible with EVB.
  8. 5000V = 5x better than the 1000V ? Or just stealing
  9. Dear vendors:

    Making a vSwitch? Impress me and do something different: PBB, Q-in-Q, or MPLS. Otherwise give up now and adopt OpenFlow and let someone else do the networking like Nicira or Big Switch.

    Thanks, bye.

  10. IEEE 802.1Qbg support is in the IBM Virtual Fabric 10G Switch Module (for BladeCenter H) starting with the 6.9.1 firmware. Check the Application Guide (Chapter 16: Edge Virtual Bridging) at VMReady 4.0 is this new Qbg based implementation.

    Qbg Support in KVM is achieved with macvtap (e.g. in RHEL >= 6.1) and can be used with the IBM Virtual Fabric 10G Switch Module.

    P.S. The IBM Virtual Fabric Mode with Emulex 10GbE VFA (CNA) uses Q-in-Q techniques (check the Virtual Fabric Academy website at

    much more to come 8-)
Add comment