Wednesday, June 8, 2016

ACI is for physical, NSX is for virtual? Not really ...

During 2014 and 2015 I had a lot of meetings with customers that wanted to compare NSX and ACI. They were assuming that you could deploy one or another, but not both. 

I kept telling them that NSX can not work without a physical fabric, while ACI on the other hand could deliver network virtualisation through integrated overlays. This means you can actually run ACI and not implement a software overlay. However, you could run NSX as a software overlay, and still use ACI as a physical fabric.

Up until late 2015, this idea of using ACI as the physical fabric for NSX would face resistance … some customers would tell me that they "had been told that NSX could not work with ACI". The two were incompatible.

No such thing of course: NSX can run perfectly fine over ACI. Just like any other software overlay from other vendors, by the way.

Nowadays nobody denies that NSX can indeed run over ACI. 

And now, many of the naysayers of two years ago are promoting a new mantra: NSX and ACI are "complementary". The story goes that "NSX is great for virtual assets, and ACI for physical". This mantra is repeated over and over, augmented by uninformed media and bloggers.

Now, every product has strengths and weaknesses, and customers may prefer one solution or another, but this mantra is just wrong. A customer may decide to implement both NSX and ACI, and pick certain functionality from one or another, but I wouldn't say that they are "complementary".

I am sure many readers that know that I work for Cisco will be immediately dismissive of my opinion. But I hope to have readers that are skeptical and have a critical mind, and also an open mind ...

I will review now some of the reasoning behind the "complementary" approach that I have read in various blogs and articles, and provide my "biased" opinion.

"If you have a lot of virtual workloads you are better off with NSX, ACI is fine to manage physical assets"

This is a fallacy that tries to make a strength of what is actually a product weakness imho: NSX is of no use with physical endpoints. However, the opposite is not true: ACI does work well with virtual endpoints.

And the other thing is that "virtual workload" does not equal vSphere workload. It may have been so a few years ago, but not today.

NSX, like other software-only overlays, is certainly a poor solution to deliver network virtualisation and/or security to any physical workloads, including the underlaying ESXi infrastructure that it relies on.

ACI on the other hand allows an IT administrator to programmatically use network virtualisation and the security provided by its contract model to connect physical workloads. This includes the ESXi infrastructure too of course :-) 

But in the case of ACI, this includes not only physical endpoints, but virtual endpoints as well. And this is true for *any* virtual endpoint, not just for those that run in vSphere, but also the ones running on Hyper-V, or on KVM.

"NSX is better to implement security for virtual environments"

When I read this I have to repeat the consideration that "virtual environments" may be based on Hyper-V, that NSX does not support. But in addition, ACI allows administrators to configure similar security like that provided by the NSX Distributed Firewall for vSphere environments and extend it for other virtualisation platforms as well. 

As an example, with NSX you may have multiple Virtual Machines in the same PortGroup, and use Security Groups to implement micro segmentation to isolate those workloads and/or enable communication between them only as per the policies configured. With ACI you can do that too. And you can do it for Hyper-V and KVM and Bare Metal also. 

With NSX you can place vSphere virtual machines on one Security Group or another based on VM Attributes. With ACI you can do that as well. And you can do it for Hyper-V too. 

"NSX provides advanced virtual network services, like Firewall and Load Balancing"

This could be a fair point. You can deploy an NSX ESG as a FW or as a LB. 

However, if we leave NAT aside, the contracts in ACI between an external EPG and a normal EPG or uEPG would provide, in practice, similar protection as that of an ESG acting as a North-South Firewall, and much better performance at a much lower cost. But NAT may be a requirement and ACI does not do NAT (except when managed through OpenStack, where APIC can program NAT on Open vSwitch via OpFlex). 

My observation in this point would also be that the NSX ESG is really a very basic firewall at best, capable of doing NAT and L2-4 packet filtering. It cannot do some basic things expected of a Firewall, like matching on packet size, or on IP options. The NSX ESG as a firewall is equivalent to a Linux VM implementing iptables with connection tracking. Similarly, the ESG as a Load Balancer is equivalent to a Linux VM running HAProxy, a popular open source load balancer.

My Final Thoughts

Yes, you can run NSX and ACI together. In fact, ACI can be the best underlay if you run NSX. Not only for its advanced fabric management and telemetry capabilities. Customers running NSX at certain scale will likely require multiple tiers of ESG doing routing: typically tenant-level ESG doing NAT routed through upstream domain-level ESGs. The latter are easily replaced by the ACI native routing capabilities, saving money and reducing the impact of the ESG potential performance limitations. 

But in my opinion, there are very few objective reasons to run NSX once ACI is your fabric. And there are many good reasons why ACI should be your fabric.

Now, some customers actually require running NSX. I am thinking those that are running vCNS with vCloud Director: as vCNS is End of Sale (and I think soon End of Support), they must upgrade to NSX. These customers could probably envision using other network virtualisation and virtual firewall solutions, but apparently integrating vCD with anything other than vCNS or NSX is extremely complicated and costly. 

Others are using NSX because it is a mandatory component of the EMC Federated Hybrid Cloud, or because it was coming along with a vRA implementation. In these cases, once the customer decides for ACI as the fabric, NSX runs on top as an application. 

Of course ACI also offers vRA integration, so some of these customers could save money in NSX licenses and the compute resources associated to running NSX functions by leveraging the fabric native network virtualisation and contract model capabilities directly provisioned from vRA.

In some cases, customers had deployed some clusters with NSX before refreshing their physical fabric and considering ACI. Most of these customers deploy NSX only for its DFW, working with VLAN-backed PortGroups. Once the customer does a network refresh, if they implement ACI they may continue using NSX DFW in the same model, combined with ACI network virtualisation.

In my experience, customers that are deciding to run both ACI and NSX are doing it more for organisational reasons than actual need. And organisational reasons are sometimes very good reasons. After all, common sense is the least common of all senses. 

No comments:

Post a Comment