SDN showdown: Examining the differences between VMware's NSX and Cisco's ACI

1 2 Page 2
Page 2 of 2

A new Cisco virtual switch, called the Application Virtual Switch (AVS), supports multiple hypervisors and extends ACI’s programmatic network control into the virtualization layer. While the Nexus 9000 products are the physical switches ACI will be programming, AVS is the virtual switch. Customers of Cisco’s Nexus 1000V virtual switch should be aware, however, that AVS is a different piece of software, and a migration will be necessary for environments desiring a wholesale commitment to ACI.

As with NSX, an overlay is a key element of the solution, in this case VXLAN. However, while NSX uses overlays to connect hypervisors no matter where they are in the network, ACI uses VXLAN in a way most customers will never see. In ACI, VXLAN is a transport that carries traffic between Nexus 9000 leaf and spine switches. Cisco has tweaked VXLAN slightly, using a proprietary extension to label the VXLAN header in way that’s useful to the Nexus 9000 hardware, but is otherwise transparent to network operators.

As with NSX, multi-hypervisors are supported, including those from Microsoft, VMware, Red Hat and Citrix. With multi-hypervisor support, VMware and Cisco have recognized that customers don’t want to be locked into specific virtualization platforms, but still want to be able to automate their network virtualization.

A major difference between ACI and NSX is that Cisco is emphasizing hardware in addition to software. Software by itself won’t cut it, in the Cisco point of view. Frank D’Agostino, senior director at Insieme (now Cisco), says, “We’re going to deliver a platform that’s relevant to the application, whether it’s physical, virtual, a Linux container or legacy, we need to accommodate all of that.”

D’Agostino says, “the battle isn’t about a vSwitch or a physical switch. The battle is about how you do service enablement on top of these things, and how easy it is to stand up these things and audit them after day one.”

Although some pundits mock ACI as “hardware defined networking,” that criticism perhaps misses the point. Even for those who wish to de-emphasize hardware through commoditization, the fact remains that network hardware must be provisioned, monitored and optimized as well as updated to cope with changing network needs.

No amount of decoupling can change that fact. Cisco, in keeping with its business model, has embraced hardware’s continuing importance, placing hardware squarely in the middle of the ACI value proposition. “We know in the fabric, on a hop-by-hop and packet-by-packet basis, such a level of detail that we can start doing traffic engineering differently,” D’Agostino says.  

That’s a claim NSX cannot make.

With the integration of APIC controlled hardware and software, Cisco plans to deliver with ACI a network infrastructure driven by policy. Policy is created in part through the use of End Point Groups (EPG). The idea is to create EPGs that are a useful collection of server, service, virtualization, or network attributes describing an application – not just the IP addresses and port numbers network engineers are used to.

Once the EPG is defined, ACI applies policy that governs the traffic flowing between EPGs. According to Joe Onisick, technical marketing engineer with Insieme (now Cisco), “We group end points together for the enforcement of policy, and use the EPG as our policy instantiation point…We instantiate our policy between groups based on the connectivity graph that we draw within the application network profile.”

This point about policy and EPGs might seem a little detailed, but it raises a larger point that is key to understanding Cisco’s philosophy around ACI. Applications are not merely chunks of amorphous data payload shoved into an IP packet and forwarded across a fabric. Rather, applications can be described in a more nuanced way.

Cisco uses these nuanced EPGs as a means of not only richly identifying applications, but also abstracting that group definition into an object that policy can be applied to. There’s real power in that concept, as it allows network operators – or application developers - to fine-tune treatment of traffic to a degree that would be pragmatically impossible if it required doing it by hand.

Traffic treatment in the ACI model also includes secure separation. D’Agostino makes the case that, “Each of the containers are completely isolated based on policy and based on their segment ID. And whether it’s VXLAN oriented, whether it’s VLAN oriented, whether its NVGRE oriented - to us, it doesn’t matter at the edge. We bring it, we isolate it based on the logical architecture or the system and based on the policy definition. We can keep complete and strict isolation with full visibility into the workloads and resource consumption of any resource that’s defined for any tenant or application that’s running.”

With ACI then, policies that govern application communications are pushed down into the network infrastructure by the APIC. The APIC’s interface is open such that, over time, any number of third parties can interact with it.

Like VMware, Cisco has gone to great lengths to build a partner ecosystem, although Cisco stresses that APIC is an open platform, implying that partnerships are not exclusive relationships. BMC, Citrix, Embrane, F5, Microsoft, NetApp, PuppetLabs, Red Hat, Splunk and several others are already listed as working with Cisco on ACI integration of a variety of applications.

Cisco is sometime criticized for the high cost of its solutions, and has made a point of keeping ACI acquisition costs low. Capex for the Nexus 9000 switches is reportedly quite reasonable. Within Cisco, the 9000s are seen as a viable migration path from the aged Catalyst 6500 platform.

In conjunction with the Nexus 9000 switching products that offer high density 40G Ethernet, Cisco has introduced a 40GbE “BiDi” LC-terminated optic that allows 40GbE to run over a single pair of multimode OM3 grade fiber. As most 40GbE optics require 12 strands of fiber, the BiDi strategy gives customers a migration path from 10GbE to 40GbE that doesn’t require a complete overhaul of their fiber cabling plant. Cisco customers making an investment in Nexus 9000 switches to build their ACI foundation can cost-effectively move to 40GbE at the same time.

Customers invested in the Nexus 7000 product line will be glad to know that ACI support is roadmapped for the latter half of 2014.

The obvious downside of ACI is that it requires compatible network hardware to do what it does. While ACI appears to be one of the most complete architectural approaches yet to software defined networking, even if ACI wins significant mindshare, implementation will be slow as ACI depends on the right hardware to function.

Most network gear has a five to seven year life, so even with reasonable acquisition costs, many organizations still depreciating recent hardware purchases are going to find ACI a tough sell. The promised Nexus 7000 integration with ACI will go a long way to speeding up ACI adoption, if Cisco can pull off the integration successfully.

Conclusion

Philosophically, NSX and ACI are rather different. On the one hand, NSX touts rich virtual switch functionality, abstracting the network using a controller and overlays. On the other, ACI melds both hardware and software into a policy-driven network infrastructure built around the needs of specific applications.

Both approaches will impact IT operations. Are these solutions and SDN in general worth exploring? Yes. NSX and ACI are evidence that software defined networking is real, providing a technological foundation that will allow speedy, reliable application delivery for organizations.

Sure, it’ll change how engineers exercise the art of networking. But sometimes change is good.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2014 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
IT Salary Survey: The results are in