The Cisco ACI approach blends software with hardware to allow capabilities to be built into one or the other, where they will offer the most value. For example, hardware can be built to reroute traffic in 150ns or less in failure scenarios, while software routing reconvergence averages 50ms or more. This is an order of magnitude difference from a packet loss perspective. To better understand this, look at the following examples of packet loss software and hardware failover options.
ACI is a centrally provisioned "zero-touch" fabric, which is deployed and operated via a central controller cluster. ACI uses the language of applications and their business requirements to automatically provision the underlying virtual and physical networking infrastructure, including software and hardware Layer 4-7 appliances. ACI provides a comprehensive networking, security, and compliance automation system for all aspects of application delivery, including forwarding, security, and user experience.
Choosing Cisco ACI or VMware NSX
Starting with assessing NSX, the first step is to understand that with or without NSX, a physical network will be required to actually move packets between devices. In addition to this, modern data centers are only about 70% virtualized from a workload perspective. Legacy applications still exist on bare metal, while modern applications are written to utilize bare metal without the cost and overhead of a hypervisor. This means that you'll want to ensure you're able to provide network services and security to all existing workloads, without artificially choking traffic through hypervisors or server-based gateway devices.
Because NSX provides no management or visibility into the physical network that the NSX application utilizes, you'll want to ensure that any network chosen for NSX provides native automation for provisioning and network change, as well as advanced visibility and telemetry tools for troubleshooting and day-two operations. These tools should not be limited to simple databases for mapping virtual tunnels to VLANs, but offer more comprehensive visibility and automation, including firmware and patch management. Without this, your network will become more complex with two management and monitoring systems for performance and failure troubleshooting.
You'll next want to look at the hypervisors you're using, or could potentially use moving forward. More than half of data centers use multiple hypervisors, so you'll want to take this into account. When choosing NSX, you must choose between the VMware-only NSX for vSphere, or the multi-hypervisor version, VMware NSX-MH, which uses a VMware-proprietary distribution of Open vSwitch (OVS). Additionally, at the time of this writing, NSX-MH is being phased out. The two products are not compatible, and the features vary greatly between the two. Additionally, you'll want to consider licensing costs and future licensing model changes that may occur.
You'll next want to consider what the business objective/requirement is for NSX. Are you looking for an SDN solution to speed up deployment of new applications and services, the ability to move to cloud computing models, or the ability to move to agile software deployment models? If so, NSX may not be the right tool, because it focuses on only the VM-to-VM traffic pattern, with no ability to move traffic between VMs on different physical devices.
If your goal is to tighten security and move beyond legacy perimeter-based defense postures, then NSX may be a solid choice for virtual traffic. This is especially true if you've chosen to standardize 100% on the VMware hypervisor and are (or intend to be) a 100% VMware-based virtualization environment. In this case, NSX offers segmentation abilities within the hypervisor by providing basic semi-stateful firewall capabilities within the virtual environment.
It's important to remember that even in this second scenario you'll need to have a separate set of security tools for physical environments. Even 100% VMware virtualized environments need security for vMotion, hypervisor management, IP storage ports, NSX management, gateway servers, and BUM (broadcast, unknown unicast, and multicast) appliances that are run as physical servers, etc. You’ll also still utilize perimeter security, typically consisting of physical appliances that do not tie into NSX solutions.