A friend of mine involved in multiple Cisco ACI installations sent me this comment on their tenant connectivity model:
I’m a bit allergic to ACI. The abstraction is mis-aligned with familiar configurations, in particular contracts being independent of and over-riding routing, tenants, etc. You can really make a mess with that, and I’ve seen some! One needs to impose some structure, naming conventions…, and most people don’t seem to get that done.
As I noticed in the NSX-or-ACI webinar, it’s interesting how NSX decided to stay with the familiar VLAN/routing/filtering paradigm (more details), whereas the designers of Cisco ACI decided to go down a totally different path.
There’s nothing wrong with being different, and Cisco ACI connectivity model might be an ideal abstraction, and just what’s needed if you’ve never seen IP networking before… but it’s hard to change the mindset of everyone who ever heard about TCP/IP, or support the gazillion of broken enterprise applications that rely on dirty VLAN-based tricks like shared MAC- or IP addresses. Not surprisingly, many Cisco ACI installations turn into glorified (and overly complex) VLAN managers.
But of course it gets worse… enterprise environments expect GUI-based configuration, and while that encourages the continued creation of bespoke snowflake environments, it has another drawback:
Documentation would help. But people think the GUI is the documentation.
Sometimes it gets as ridiculous as a networking engineer writing an automation script to collect Cisco ACI tenant configurations to help identify configuration parameter creep in supposedly-identical tenant deployments.
Is there a way out of this morass? Infrastructure-as-code and automation obviously help, and you can find several Cisco ACI deployment automation examples in our Network Automation Solutions showcase… but it turns out that the moment you start automating your deployments, you might not need Cisco ACI anymore. Back to my friend:
I just did a manual 2-spine/10-leaf VXLAN deployment with multi-site connectivity, and clearly automation is the better way to go, primarily for accuracy of configs. Customer likes Ansible for automation, and now that the fabric is built, adding VLANs is pretty easy templating.
But even if you decide to go down this path, you’ll quickly face another challenge: should you build your own solution (aka “invest in premium people”), in which case you might find our network automation course useful, or buy a premium product from an umbrella orchestration vendor and spend the rest of your life fine-tuning it to meet your “unique” needs. As always, once you start looking into the details, there is no easy answer.