Automation, the real power of ACI !

Posted on by Soumitra Mukherji

I’ve been in the data networking field for 30+ years and with Cisco for 20 years now.   Of all the products that I have worked with in my career, I can frankly say that ACI is the one that has really impressed me.

The reason ACI (in my view) is such a great product,  is because it was not an afterthought.  This product was built ground up with the proper engineering design and planning that makes it so flexible and powerful.  This is what true SDN was meant to be and as a Data Center Fabric ACI has done it.    I’ve seen products that take the old classical CLI interface and retrofits that with a controller, so under the hood,  the controller goes and does a ssh to the nodes and does configuration ( config t) on the individual nodes, routers and switches.   We’ve all done that sort of automation in our networking career,   — using tcl/expect, python, etc, etc.   If you go to the ACI Leaf/spine, you won’t find any configuration on that from the regular Cisco CLI prospective.  The configurations are all pushed down to hardware from the ACI APIC controller using REST calls.

There are many options to program/get information from ACI Fabric, other than using GUI.  Some of the popular ones are:

  • Direct Posting from API GUI using JSON/XML based configs
  • Postman/Postman Runner using JSON/XML encoding
  • bash with curl sending JSON/XML encoding
  • icurl
  • moquery
  • Python using JSON/XML encoding
  • Python using ACI SDK (cobra)
  • Ansible
  • Terraform
  • Others like puppet, NSO, etc, etc

 

I’ve helped many customers with Proof of Concept testing for ACI.  I’ve been in many environments where I could tell that in the begining, the folks that I was working with were not very enthused with ACI.  Their management wanted them to check out ACI and the network operators were grumbling/mumbling on why they need to turn everything upside down.  They’ve been doing things the old way with their individual routers and switches and it just worked fine. When we go to the point where they actually start looking into the automation I can see the instant change in their demeanor.   It’s so easy and so powerful that you got to get impressed.  For instance a customer needed to have 100 tenants that were all similar and each of the tenant was considered a security zone.  For these tenants to talk to each other the requirement was to go through a North Bound Firewall.   The customer built 1 Tenant, and then pulled in the Json config for that Tenant and used variables to populate the fields that would change for the other tenants.  They then pushed the template down to the fabric using postman runner, and within 15 minutes they had 100 Tenants up and ready to go !  I also want to point out that the majority of those 15 minutes were used to actaully modify the templates and the variables.  The actual configuration push took less than a minute.

Ofcourse the next question that comes up is “what if I make a mistake ?” and push it down with automation.  Yes, for sure with automation you can destroy your network as fast as you can build it !

That becomes a quality control issue.  In a production environment you should not allow scripts to push config until they have been checked by another script that checks for validity. 

In the ACI case every configuration is an object and they have properties.    So, whether you configure from GUI/CLI or whatever, at the end of the day you are manipulating these objects.  Even Faults, Health Scores, Audit Logs, Events are objects.   What this gives you is a Fabric that’s ready to be programmed from day 1 of your operations !   ACI even has a python SDK  (also known as the Cobra SDK) that mimics the object model for the APIC.  You can use this SDK to make your ACI Fabric programming even easier.  However, I tend to stay away from the SDK now a days.  That is because as you go to different releases of ACI software there are newer features that come in and then you have to also upgrade the SDK in your programming platform to take advantage of the new features by automation.   The truth is that you can do anything with API calls sent with JSON or XML  encapsulation.

The object model for ACI is well documented in the management information  model reference guide. ACI even has a real time object browser (also known as Visore) that you can access directly from the ACI GUI where you can browse and search for the ACI objects in your fabric and that shows you what API calls are needed for what objects.  When I help customers with automation requirements, I use this extensively because it’s real easy from there to find out the exact query that you need to do for what you are trying to achieve.    Incidentally,  the built in swagger tool in MSO gives you similar sort of power.

Given that ACI has now been there for 6 years, a lot of folks out in the field have excellent articles written for understanding and getting started with ACI automation.   Here, I will point out a few that are really impressive and are excellent getting started guides. I don’t know these authors, but want to thank them for these excellent guides.

Quick Comment:    For the 1st link in the list from rednectar,  I love the decoding of the acronym of “moquery — Cisco’s Mysterious Obsecure ACI query utility”.  That sure is a catchy acronym decode and I could not help but start laughing when I saw that.    However,  I’m not sure that I agree with the decoding of that acronym.   MoQuery utility is actually quite well documented and it also has a man utility — do a google search and look for yourself.  Most folks that I have worked with are aware of the moquery utility and have used it on and off.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.