Cisco Value in vCider is All Programmable Networking

Cisco recently bought vCider. vCider gives Cisco tools for cloud bursting and a proven network driver to deliver overlay networks. It’s a significant boost to their Programmable Networks strategy and definitely an SDN play.

The vCider technology was architecturally similar to Nicira by building tunnels overlays in a network and, in my view, many people are incorrectly misinterpreting this as the core value on the acquisition.

I would posit that there are two aspects to vCider that Cisco is likely to extract value from.

  1. Network driver in Linux.
  2. Cloud burst networking

Linux Network Driver

vCider technology is primarily based on a network driver for Linux. The value of the proven and stable network interface software stack is high. There aren’t too many people who could develop and ship a network driver alone but vCider have been successful. Although Cisco could develop its own, it’s quicker to build from a known, tested software core and innovate around that.

The value from the network driver is that vCider can build machine-to-machine networks without a virtual switch. Most of the focus today is about building virtual switches in hypervisors like Openvswitch and Nexus 1000V. vCider went directly to the network driver in the Linux operating system and created overlay networks in the operating system.

From a solution perspective this creates opportunities for networks that are

  • VM-to-VM
  • VM-to-Physical
  • Cloud to-Physical
  • Cloud to Cloud

That’s a significantly more interesting networking approach than simple configuration of software switches. It breaches several of the problem areas in cloud networking.

Cloud-Burst Networking

The second aspect of vCider is that the controller platform was about delivering “cloud bursting”. vCider was connecting networks between public/public and public/private clouds. Technically, the vCider network adapter was encapsulating packets into their own UDP protocol, using an external cloud management system to locate end points and transfer data between clouds.

I have the view that the Linux network driver is the core asset here but if the cloud bursting survives the product management process internal to Cisco, this could be a long-term move. By intercepting the value chain in Amazon’s networking stack, Cisco can move to sell more of their software appliances. This value is unlocked by building an overlay over Amazon’s own overlay networks, that can create connectivity to other cloud providers including private clouds.

As the purchase was announced, the vCider website was wiped clean so there is little information available.

EtherealMind View

I take the view that Cisco has acquired a few strategic pieces in the SDN networking space. vCider was certainly an SDN play in the form of programmatic control of the network layer (long before SDN became a thing). When combined with Cisco’s other efforts, there are new opportunities created. I feel it’s most likely that Cisco will fold the network driver into it’s software appliances to build cloud-to-cloud networks via the Nexus 1000V brand.

Consider a network of XEN / VMware / Amazon / Rackspace virtual machines with software firewalls, routers and hosted management service. That’s where the vCider acquisition is likely to be useful as part of a wider strategy.

  • Jim

    Really like this article, now that there is such little content about vCider, it’s refreshing to find such a concise view of the fundamentals. thank you.


    • Etherealmind

      Thanks Jim.

  • naveen gurjar

    Good post, got a better prespective of what Cisco’s response to SDN. I have another aspect as to where the future of Networking may lie, please help me: We will have a base enterprise network. This the current data center core network that is made of static network logic. This base will not be changable dynamically. Now on this ‘base’ ‘static’ network..several Virtual/Elasctic overlay networks can be built and torn….’without using SDN’..per se…thats what Cisco/Juniper can drive the development of elastic networks…. WHat is your take on this?

    • Etherealmind

      overlay networks is one option when relying on legacy autonomous protocols. The other option is to use flow based network and manage all networks flows using a controller platform.

      Both will work, and likely we will see networks using both in what is known as “hybrid mode” and “mixed mode”.

      • naveen gurjar

        Thanks for the reply…also is there a movement in SDN to do ‘away’ entirely with TCP/IP OSI layers and use a pure software-as-only networks…atleast within the phy server farm…this is a bit worrying for us network enggs…what is your view on this? The other two forms (overlay and flow based) still holds value for network engss…only that we need to adapt to new ways of networking.

        • Etherealmind

          No. SDN will change the paths through the network, it’s won’t change the protocol stack.

          • naveen gurjar

            Thanks…you have been very helpful in clearing the air about SDNs.