Nicira, BigSwitch, NEC, OpenFlow and SDN

Numerous articles published in the last few days describing how Nicira clashes heads-on with Cisco and Juniper just proved that you should never let facts interfere with a good story (let alone eye-catching headline). Just in case you got swayed away by those catchy stories, here’s the real McCoy (as I see it):

What are they actually doing?

Nicira is building virtual networks solution using tunneling (VLAN tags, MAC-over-GRE or whatever else is available) between hypervisor switches. It expects the underlying network transport to do its work, be it at layer-2 or layer-3. An Open vSwitch appears as a regular VLAN-capable learning switch or as an IP host to the physical network, and uses existing non-OpenFlow mechanisms to interact with the network.

Deployment paradigm: complexity belongs to the hypervisor soft switches, let’s keep the network simple. It should provide no more and no less than optimal transport between equidistant hypervisor hosts (Clos fabrics come to mind).

Target environment: Large cloud builders and other organizations leaning toward Xen/OpenStack.

NEC and BigSwitch are building virtual networks by rearranging the forwarding tables in the physical switches. Their OpenFlow controllers are actively reconfiguring the physical network, creating virtual networks out of VLANs, interfaces, or sets of MAC/IP addresses.

Deployment paradigm: we know hypervisor switches are stupid and can’t see beyond VLANs, so we’ll make the network smarter (aka VM-aware networking).

Target environment: large enterprise networks and those that build cloud solutions with existing software using VLAN-based virtual switches.

Competitive hot spots?

Between Nicira and NEC/BigSwitch: few. There is an overlap in functionality (NEC and BigSwitch can obviously manage Open vSwitch as well), but not much overlap in typical use case or sweet-spot target environments (I am positive there will be marketing efforts to shoehorn all of them in places where they don’t really fit, but that’s a different story).

Between Nicira and Cisco/Juniper switches: few. Large cloud providers already got rid of enterprisey kludges and use simple L2 or L3 fabrics. Facebooks, Googles and Amazons of the world run on IP; they don’t care much about TRILL-like inventions. Some of them buy equipment from Juniper, Cisco, Force10 or Arista, some of them build their own boxes, but however they build their network, that won’t change because of Nicira. No wonder Michael Bushong from Juniper embraced Nicira's solution.

Between Nicira and Cisco’s Nexus 1000V: not at the moment. Open vSwitch runs on Xen/KVM, Nexus 1000V runs on VMware/Hyper-V. Open vSwitch runs on vSphere, but with way lower throughput than Nexus 1000V. Obviously Cisco could easily turn Nexus 1000V VSM into an OpenFlow controller (I predicted that would be their first move into OpenFlow world, and was proven dead wrong) and manage Open vSwitches, but there's nothing at the moment to indicate they're considering it.

Between BigSwitch/NEC and Cisco/Juniper. This one will be fun to watch, more so with IBM, Brocade and HP clearly joining the OpenFlow camp and Juniper cautiously being on the sidelines.

However, Nicira might trigger an interesting mindset shift in the cloud aspirant community: all of a sudden, Xen/OpenStack/Quantum makes more sense from the scalability perspective. A certain virtualization vendor will indubitably notice that ... unless they already focused their true efforts on PaaS (at which point all of the above becomes a moot point).


  1. I would add that Xen/OpenStack/Quantum also makes more sense from a $$ perspective. Making it easier to deploy (like VMware) is something that gets better every day (see Piston Cloud, Nebual, and others).
  2. And of course, how could I forget, Dell's Crowbar cloud deployment software :-)
  3. I don't know about Nicira *in particular* but Open vSwitch at the hypervisor level is a good move. Juniper has a platform (Space!) where they could easily deploy JUNOS features into the hypervisor via OpenFlow v1.2. If that ever becomes a standard.
  4. Ivan,

    Excellent post as usual. I have a quick question though. You said somewhere that technologies like Trill or FabricPath won't be needed if complexity and services intelligence is moved to the edge. Wont you still need Trill to build fat and thick networks?
  5. If the virtual networks require IP connectivity in the transport (core) network, not bridging (L2 switching), then you don't need any new technology - we were building large-scale IP networks for decades.
  6. provides SDN for L4-7 (and does not compete with Nicira).
Add comment