Our Commitment to Innovation, Choice and Openness in Next Generation Virtual Switching

Cisco has always been focused on providing customers with the best innovation, under an umbrella of choice and openness, in our next-generation virtual switching portfolio.

Last month, VMware notified customers of its intention to remove the 3rd Party virtual switch APIs in Update 2 of vSphere 6.5. These APIs allow customers to choose a virtual switch to best fit their unique network and data center requirements. This includes Cisco’s portfolio of AVS, Nexus 1000v, or VM-FEX products, the HPE 5900E, or the IBM DVS 5000v.

Instead, VMware has chosen to close the APIs and the open ecosystem to steer customers to its virtual networking products only. Cisco has deployed virtual switch solutions in thousands of customer networks worldwide. We regret that VMware has chosen to impose such a significant operational burden with challenging timelines for so many customers.

We understand customers need to plan and are eager for more information regarding these changes. Cisco believes customers deserve choice. Customers compare and evaluate Cisco solutions with alternatives, and they choose Cisco based on the merits of our technology, services and support.

In anticipation of VMware’s decision to remove the 3rd party virtual switch APIs, we have been working on a platform-independent solution to bring choice back and to free customers from being locked into the VMWare-only virtual switching option. This solution will provide customers with a high level of consistency and control, extending beyond on-premises VMware vSphere environments.  This solution will also provide a migration path forward for current AVS and Nexus 1000v customers when they upgrade to a vSphere version that does not have the 3rd party vSwitch API.  Cisco will not leave our customers behind.

In the meantime, customers and partners should realize that in the spirit of openness and choice, Cisco ACI-based networks do not limit customers to VMware vSphere or mandate the Cisco AVS in vSphere environments. Cisco ACI delivers advanced network virtualization and microsegmentation with all the major virtualization platforms — Microsoft Hyper-V, KVM, and VMware vSphere. When using ACI with VMware vSphere, customers are free to choose and deploy virtual networking and microsegmentation with the native vSphere Distributed Switch (VDS). In fact, more than half of Cisco ACI customers operate their ACI fabrics with the VMware VDS.

We will continue to share more details on our approach with our account teams and partners in the coming weeks. Thank you for your business and partnership.

Availability disclaimer: Products, features and solutions described herein remain in varying stages of development and will be offered on a when-and-if-available basis. These products, features and solutions are subject to change at the sole discretion of Cisco and neither Cisco nor its suppliers will have any liability for delay in the delivery or failure to deliver any of the products, features or solutions referenced herein. 

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. Does Cisco mean with “working on a platform-independent solution”the Open Virtual Switch (OVS) which is supported with Vmware 6.5 and later?

  2. Look at this from customer perspective. Almost no one has 100% virtualized DC but most customers run sigle vendor DC fabric and in most cases it is Cisco. Customers ask for software defined control of network that can serve baremetal, OpenStack, containers baremetal or virtual, VMs in other hypervizors. Can VMware virtual only approach solve my challange? Single fabric for baremetal, containers, and virtual can.

  3. VMware announced EOA back in 2015, did Cisco pay to maintain the API? How would you expect someone to support your commercial product forever?

    Cannot agree more with Anonymous, Cisco’s ACI is the same. VMware NSX also supports many 3rd party security products, it also works with all physical networking products, including Cisco. CDP/PAgP works fine too.

    Cannot believe a SVP writing this piece of xxxx

  4. An understandable move from VMware and also Cisco; competitive decision making while ignoring customers needs. What I don’t understand though, is for how long DC vendors are insisting on adding complexity (in the name of innovation) to DC networks despite we all know this complexity is one of the main reasons why so many customers are moving to public clouds!

  5. I do agree with all the ideas you’ve presented in your post. They’re really convincing and will certainly work. Still, the posts are too short for beginners. Could you please extend them a little from next time? Thanks for the post.


  6. “we have been working on a platform-independent solution to bring choice back and to free customers from being locked into the VMWare-only virtual switching option”
    A great phrase .. if it were not because Cisco is precisely the one that has contributed most to this situation of dominance of VMware, without any power of choice…

    Call Manager, and *all* unified solutions from Cisco: only supported in VMware.
    “VMware vSphere ESXi is mandatory for all virtualized deployments of Cisco Collaboration.”
    “Other virtualization vendors/products are not supported at this time (e.g. Microsoft Hyper-V, Citrix Xen, Red Hat KVM, etc.). ”

    Virutalized NGIPS. Only for VMware…
    Table 1. System Requirements
    Hypervisor VMware ESX 5.0, 5.1

    ISE virtual… again VMware and KVM, of miracle, in 7.x versions. What about Hyper-V?
    “ISE virtual appliances are supported on VMware ESXi 5.x and 6.x or KVM on Red Hat 7.x”

  7. ACI stands for “All Cisco Infrastructure” Hardware but can talk to other vendor software with its spirit of openness and choice! Hardware is Cisco’s bread and butter though! 🙂 Inside the DC Switching that deals with large volume of East-West traffic, I believe hardware based forwarding would offer better performance than software based! My 2 cents 🙂

  8. Cisco you should make your own hypervisor. You already have the compute and network!

    • I am a Cisco employee and I am fine with not having my own hypervisor. I prefer bringing a solution that can work with any hypervisor and any operating system as long as it talks IP than having to say “yes we offer our own hypervisor and we support others also” which sounds like a lock-in to me.

      • Yeah, any hypervisor, any OS but on Cisco HW only. A vendor lock-in is just the matter of perspective. It can be on the hardware level (Cisco ACI), hypervisor level (VMW, MS) or employee level if the ‘open’ solution is taken. Don’t bluff.

  9. Thank you very much Frank, a clear description and statement of direction. CUSTOMER FIRST!

  10. sad indeed but not surprised.

    “In the meantime, customers and partners should realize that in the spirit of openness and choice, Cisco ACI-based networks “… only supports Cisco Nexus 9k switches.

    • I would like to remind you that Cisco ACI supports and works with any firewall, any load balancer, any L2/L3 networking devices. They will not participate to the ACI fabric, but will be completely interoperable.

      • It also reminds me that VMware supports CDP/PAgP, working fine with all Cisco routers and switches too, in fact, all physical network equipment works fine with VMware.

      • The same applies to VMware. 🙂

        A customer has a choice either a vendor lock-in on the hardware level (Cisco), hypervisor level (VMW, MS) or employee level if ‘open’ is chosen.

    • Yeah – Im going to put my money on an OVS variant, Cisco already has a big input into the development of the OVS, and the OVS is supported on vMware going forward.