Comparing ACI & NSX on Network World

C

nww-logo-fb2I wrote a piece comparing Cisco ACI & VMware NSX for Network World. I hopefully avoided sensationalizing the issues or making NSX/ACI an either/or situation. I tried to simply break down just what the two SDN approaches do and how they might be of value to organizations. Perhaps the biggest point I hope to make in the piece is that ACI and NSX are not easy to compare. They don’t accomplish the same things, nor do they work in identical ways.

Here are a few quotes. Take each one separately; don’t read them as one long statement.

  1. Multi-hypervisor support is an important part of the NSX strategy, adding, as it does, Citrix Xen and KVM users to the mix. In fact, NSX is agnostic to many environment elements, including network hardware, which is an important attribute.
  2. Since all the endpoints are known to NSX, there’s no requirement for unknown unicast flooding. Multicast and broadcast packets are copied from hypervisor to hypervisor.
  3. A distributed firewall is another key part of NSX. In the NSX model, security is done at the network edge in the vSwitch. Policy for this distributed firewall is managed centrally. Conceptually, the NSX distributed firewall is like having many small firewalls, but without the burden of maintaining many small firewall policies.
  4. With ACI, network virtualization isn’t the whole story. Rather ACI is an entire SDN solution wrapped around the idea that IT applications are the most important thing in an organization. In that sense, it’s difficult to compare NSX and ACI directly.
  5. The 9000 switches are high-density 10GbE and 40GbE built on the idea of “merchant plus” silicon, as in merchant silicon plus custom Cisco ASICs.
  6. Cisco says that APIC is open, in that the APIs to access APIC data are to be made available to anyone wishing to write to them. In fact, customers will be able to download “open device packages” that allow network hardware not currently part of an ACI infrastructure to be exposed to APIC.
  7. 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.

I’m happy to engage in further discussion about what you think I got right or wrong in my analysis.

6 comments

  • Hi Ethan,

    I appreciate the attempt to compare Apples and Oranges :-). However considering that the ACI solution isn’t deployable today – it’s comparing an Apple to a virtual Orange. Personally ACI seems to be too much of a lock-in.

    In particular, ACI appears to be an all or nothing solution. Nexus 9K boxes have to boot up in ACI mode and it’s not clear if the APIC can work with “non ACI mode” switches. Can you shed some light on this? On the other hand it looks like NSX can be eased into a network piece meal since it integrates with OpenStack.

    • On lock-in, is there an SDN strategy offered by a major vendor that isn’t some sort of a lock-in? ACI’s hardware dependency is certainly a significant one, but from an operation standpoint, would NSX be less of a vendor/customer marriage? Admittedly, you said ACI is “too much” of a lock-in, and maybe that’s really the interesting point of conversation.

      To the best of my knowledge, APIC isn’t able to programmatically influence switches in non-ACI mode, i.e. “does not work.” But Cisco has released little information on APIC, ACI-mode, and the long-term roadmap for APIC/ACI hardware support across the Cisco line. At the moment, Cisco has stated that there will be support for the N7K platform. If that’s the case, it opens the question, “What other Cisco hardware might be eligible to take part in ACI?” That’s hard to say, as I’m not at all clear what the silicon dependencies are for APIC/ACI. We know that the N9K is “merchant plus” silicon, but I haven’t heard any detail on what the Cisco-custom “plus” silicon is actually achieving. That makes it difficult to speculate on the other hardware lines and how their existing silicon might be able to work with ACI & APIC.

  • Ethan: good blogs!

    Yes, NSX is deployable today. It still seems to be somewhat of a work in progress, although the marketing seems to imply otherwise. (Well, no vendor is going to advertise “my product is half-baked” — not that NSX is half-baked.) I’m still trying to get a handle on that. Yes, it does appear (so far) to be ahead of ACI. Both will likely be initially usable, with additional features planned (and awaited eagerly by the customer thereof).

    What also needs to be considered is that datacenters generally evolve in an incremental way. How well does NSX fit a 50:50 physical and virtual world? It will want to control its half, and that’s fine. But what about managing connectivity to the physical devices? What are the implications for throughput, traffic patterns, etc.? I have some info on that but am still mulling it over.

    • The half-virtualized scenario is an interesting one, especially when considering multi-tenancy. Assuming VXLAN for segmentation, how does NSX control encapsulation for physical hosts? I wonder if the gateway component would help cope with this situation. I don’t have a good answer, but I suspect VMware does. I’ll send out an e-mail or two and see if I can get their stance.

By Ethan Banks

Ethan Banks is a podcaster and writer with a BSCS and 20+ years in enterprise IT. He's operated data centers with a special focus on infrastructure — especially networking. He's been a CNE, MCSE, CEH, CCNA, CCNP, CCSP, and CCIE R&S #20655. He's the co-founder of Packet Pushers Interactive, LLC where he creates content for humans in the hot aisle.

Newsletter