Myth-busting: ACI or NSX, which is the Real SDN Leader?

April 15, 2015 - 4 Comments

I speak with customers every day and often hear they are confused by conflicting vendor claims, marketing hype and embellishments. This is especially true when discussing SDN, where both the technology and the market have evolved significantly over the past few years.

I’ve invited Frank D’Agostino, one of Cisco’s top technical experts on SDN, to join me in separating fact from fiction. Frank and I are on a mission to debunk trendy technology myths, and this is the first in a three-part video series that we’ll bring to you over the next week.

In this first episode, Frank and I discuss the differences between Cisco’s ACI and VMware’s NSX. Frank is in a unique position to discuss both technologies, since he’s the only expert that has been deeply involved in the development of both NSX and ACI.

We think that ACI and Nexus is the most complete solution on the market. It does everything customers want from SDN, while offering more capabilities than NSX, and being two to three times less costly in typical customer configurations.

Cisco also collaborates very closely with our customers on technology, and we work with a wide variety of industry leaders, including competitors, to offer the best level of technology integration and interoperability. The reality is that the choice between ACI or NSX is not “either or:” if customers want both, NSX can run on ACI just like any other application, and in fact NSX will run better over an ACI infrastructure than over any other infrastructure on the market.

Take a look at our first video below, and then compare for yourself which solution makes the most sense from the perspective of cost, performance, scalability, and features.

We look forward to reading your comments and feedback.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. They gotta get ACI running on existing NX-OS kit even if it is just the 7Ks, or this will be an edge technology for a long time.

    Or admit that cisco can not/will not (or maybe a missed an announcement, that can happen.

    Also that I have to buy ACI to see if I like ACI, less than awesome

    • It’s coming….

      I went through several days of Nexus and ACI training, recently. We were told they would soon release ACI support in existing 7k’s, and then in the 5k’s. They also said they would have support in the virtual appliance as well. Not sure if it will be the existing 1000v, but they will have ACI support in a vm.

  2. Thanks Rob and Frank! Very good insight. As you are well aware,VMware is very aggressively going after us with their Zero-Trust security implementation. While there claims can be quickly de-bunked, we do have risk in the mid-market with customers that are not as high-touch who may be lured in by their marketing claims. Hopefully an upcoming session will address the security aspect VMware Security Claims vs ACI Security Reality!

  3. I see a few problems with VMware’s approach.

    As I understand it, Nicira started with Open vSwitch on Xen, centrally provisioned and managed using OpenFlow to support at-scale deployments in service providers. From there it expanded to include OpenFlow SDN control of white-box switches.

    But after being acquired by VMware, Nicira (now NSX) has been focused more on Network Functions Virtualization (NFV), providing load-balancing, security, etc., with little emphasis on controlling physical switches via OpenFlow. Improved virtual networking and NFV were needed in VMware, but does VMware want to also be a software-only OpenFlow product company, testing its SDN controller on dozens of switches?

    Either way, managing vSwitches on hypervisors, or managing physical switches on networks, VMware seems like it is trying to solve yesterday’s problems.

    I believe VMware is falling into the same trap as Microsoft. Microsoft viewed everything from the point of the physical computer: the PC and the server. Microsoft was blind to the rise of the hypervisor.

    Today, VMware views everything from the point of the hypervisor. Sure, it may say the hypervisor is being commoditized, and as a result it is moving upstack and targeting the adjacent markets of cloud management platforms (CMP), NFV, and other areas. But it is still tied to the hypervisor. It is blind to the rise of containers, and the increasing enterprise interest in OpenStack.

    Sure, VMware claims containers work great–inside of VMs on VMware’s hypervisor. And sure, VMware says OpenStack represents “No fork in the road” on the path to the VMware SDDC. But if a customer uses OpenStack, vRealize is not a factor. And if OpenStack becomes the preferred CMP for Docker-centric IAAS, VMware may face a serious threat.

    Containers may be the most disruptive IT technology since server virtualization. And containers are most disruptive to traditional hypervisor vendors. At the same time, containers benefit traditional OS vendors like Red Hat and Microsoft.

    Virtual networking and NFV for containers is a very different problem to solve than for VMs and hypervisors. To have a solid container strategy, VMware needs an ability to provision, secure, network, and manage RHEL/LXC/Docker on bare-metal as well as it can RHEL inside a VMware VM.

    The IT application environment just got a whole lot more complicated with the rise of Docker containers. It is a difficult and broad task to develop the tools to support this environment. It will consolidate in a few years, but in between, the vendors who have the broadest strategy stand to win.