I had the pleasure again this year of attending Cisco Live last week in San Francisco. Last year, I focused on attending ACI sessions and wrote a short blog on what I had learned about ACI from Cisco Live. Last year, very few people at the show seemed to know what ACI was. In contrast, this year everybody knew what ACI was and many were investigating the technology for a future roll out. ACI sessions were packed with many I attended having wait lines for those who didn’t reserve a spot.
This year I thought I would write about our experiences working with ACI over the last 2 months. As a Cisco Partner, we built a monitoring solution for Cisco ACI. ScienceLogic provides the most comprehensive monitoring tool in the industry which provides visibility into the entire IT Stack. Support for ACI is just one more piece of the complex IT puzzle.
Some of the key items that really helped us develop a solution for ACI are as follows:
- dCloud – We started our project using Cisco dCloud. This was a really cool virtualized lab environment with support for many technologies. For ACI specifically there are 7 different environments that you can select from. Full access to all components is provided via a VPN, which enabled us to develop over 80-90% of our solution. We needed to go to a physical system only when we needed the actual fabric in place so that the attached endpoints could be discovered. It is possible that this could also have been done with the simulator but not when operating in the dCloud environment since it was very clear that the LLDP from the server to the leaf switch would not be supported and this is needed for the leafs to discover the endpoints.
- ACI Simulator – The ACI simulator is a fully functioning ACI system that simulates the APIC, with 2 leafs and 2 spine switches. The Simulator was fully functional and really enabled us to quickly learn the ACI technology as well as the APl. The simulator leverages APIC production SW so what works on the simulator works on the production APICs and we had no trouble moving from the simulated environment to a physical environment. The simulator also provided a mechanism to insert faults and alerts which really helped in integrating this aspect into our monitoring system.
- APIC and the Object Model – The APIC is the brains of ACI. The APIC is the repository of the very complex but well-documented management information tree. The APIC provides centralized access to all the fabric and tenant related information. The APIC provides very powerful scoping and filtering capabilities that make it easy to get the exact data you need. Scoping capabilities allow you to specify the scope of the query. For example, you can query an entire subtree by identifying the class name and requesting all the children under that class. You can then further reduce the scope, for example, by specifying a subtree class and finally you can apply a filter to specifically pick the objects that meet any criteria you specify. Filtering allows you to select only objects that match your filter requirements.
- Visore – Visore is an object browser that lets you retrieve objects by class name or class type. This tool was critical in developing the user stories for our development team. The tool lets you browse the management information tree moving by up and down the tree as well as exploring all the relationships between objects. The following shows a screen shot of the Visore browser. In this case we were looking for the Client Endpoints object class and Visore returns the 3 instances of that class. The ? instantly brings up detailed documentation about that object. The green parentheses allow you to click on them to either see all the children of the object or the parent of the object.
- API Inspector – Since the APIC GUI relies on the APIC API, the API inspector allows you to see exactly what the APIC GUI is querying to display/update the data. This was another critical tool that came in handy to enable us to quickly figure out what objects were being use to drive the APIC displays. For example the first picture shows the APIC displaying the virtual machines that make up the EPG while the second screenshot shows the API inspector which shows the requests and responses that were sent to the APIC to generate the screen. This is incredibly helpful when trying to better understand the overall object model and what objects represent what data on the APIC GUI.
- SDKs – Cisco does support a python SDK. However, we did not make use of that due to its memory footprint size. Instead, we used the REST API directly.
In summary, working on ACI was a pleasure. This was one of the most well-done APIs I have worked on. The API, along with several tools made supporting this complex technology relatively easy. I have to really give Cisco credit for not only building what seems to be a fantastic product, but also focusing on all the tools needed to easily integrate this product with other products.