VMware's End of Third-Party Virtual Switch Support: The Fallout

Earlier this spring, VMware announced that it was discontinuing its support of third-party virtual switches. How will this decision impact organizations that have already deployed VMware vSphere with Cisco's ACI software-defined networking platform using Nexus1000v or Application Virtual Switch (AVS)?

First, the good news. VMware is only ending third-party vSwitch support as of vSphere 6.5 update 1 and onward, not for all versions of vSphere. Additionally, since many customers implementing ACI with vSphere are doing so utilizing the native vSphere Distributed Switch (VDS) with Application Policy Infrastructure Controller (APIC) integration to vCenter, VMware’s decision should have little to no impact for the majority of organizations.

Now for the bad news. If you are among those who  deployed ACI using Cisco's AVC or Nexus 1000v, the time to begin planning is now. Luckily there are several options.

First, you can simply choose not to upgrade. Of course, since this means limited access to support and software updates, and older versions of vSphere will eventually reach end-of-life, it isn't a very viable option. Second, you could investigate Microsoft Hyper-V, RedHat KVM, or Citrix XenServer, as these vendors are part of a group that's working with Cisco on a standard protocol for virtual switching known as OpFlex and they provide support for third-party virtual switches.

This could provide a compelling option as OpFlex allows the Cisco ACI policy model to extend all the way to the virtual switch, acting as a virtual leaf in the ACI fabric. Additionally, all network and policy -enforcement can be performed locally on an OpFlex-supported vSwitch, greatly increasing performance and manageability of devices in the Cisco ACI environment. 

discontinued.jpg

However, while there is a lot of benefit to using a hypervisor that supports OpFlex, it's a very large undertaking and will likely result in a mixed hypervisor environment for some time. Cisco ACI helps with this; ACI is inherently platform agnostic and will allow integration with Microsoft, VMware, and others via the APIC. Cisco ACI will also natively normalize all traffic to VXLAN regardless of specific vendor encapsulations. 

Another option to consider: Cisco is said to be working on a platform-independent solution that will allow customers running VMware to leverage features eliminated by the removal of third-party switch support in vSphere. Yet again, this requires some waiting, and delays could result in support issues for your vSphere environment.

All this being said, your mostly likely, short-term solution, will be to migrate to the VMware native virtual distributed switch (VDS) and integrate vCenter with the Cisco ACI APIC. This will allow the APIC to centrally manage the creation of port groups and assign them to ACI End-Point Groups (EPG) through integration with vCenter. Unfortunately, this means organizations will not be able to take advantage of OpFlex or local switching for Cisco ACI, both features available with AVS on VMware.

Ultimately, while VMware’s decision to end third-party switch support will likely require some work depending on your situation, this is a manageable change. If you have decided to deploy VMware with Cisco ACI you are likely committed to the solution, and will either look to migrate to VMware native switching or wait for a platform independent virtual switching solution to upgrade.

If you are considering deploying VMware NSX you can still look to Cisco ACI as a scalable, easy-to-implement, data center fabric. Finally, if you haven’t standardized on a hypervisor you could look at vendors that do support third-party switching. There is still choice; you'll just have to look a little deeper for it.