Controlling Cisco ACI with Ansible

It’s no secret that I’m a Cisco fanboy. I started networking on Cisco kit and honestly got all of my foundations from studying for Cisco certs. So it should come as no surprise that I like finding excuses to automate Cisco in interesting ways.

This was my first experience with automating Cisco ACI(Application Centric Infrastructure) SDN controller. In essence they are trying to make a product that can discover your infrastructure(switches) as you connect them to the network, and auto configure the underlay/overlay networks. I have to admit, it does take a lot of the complicated parts out of the equation as it takes care of configuring IS-IS and the VXLAN connectivity.

I’ll be the first to admit that I have limited experience with the product, so if you use it on a regular basis, please contact me so I can make these demos more meaningful(make it do some much cooler stuff). I’m going to use Ansible as the conductor and ACI will be my brass section. Ansible is the center of the universe orchestrating my IT symphony.

Here’s a video overview(quick demo):

First things first; connect to Cisco’s developer site and browse their sandbox section.

Here you can reserve an ACI server or do like me and just go with the “always on” box. They will supply you with a URL and some credentials to connect with.

Keep in mind these are development environments, so they run a little slow(especially the always-on box). They have one spine and two leaf switches connect with a few basic configurations already in place. Be a good steward of the shared environment and only delete what you create(and don’t go too bananas at creation as there are limited resources).

So my automation will connect in, create a tenant, create an application profile, create a VRF, add a bridge domain, then last it will create 10 EPGs. It’s going to do all of that in about one minute…bonkers, right?

I’ll start by showing the playbook(which can be found here), and while I have this as a single playbook, this could easily be broken down into multiple task files or roles. I do use a lot of variables for easy replacement/flexibility.

First I’ll look at the vars section. The aci_host, username, and password I just keep in a custom credential in Ansible Tower, so it keeps it secure and make it convenient to use. I talked about creating custom creds in this article.

Here I’m also specifying the tenant, app, bridge domain, and VRF info. After that I have a list of EPGs along with their descriptions. For the sake of keeping it all in one file I did it like this, but in production I would have this in some other form(at a minimum an external YAML file that will be referenced at run time).

Looking at the first task you can see just how simple all of this is. All of the ACI modules for Ansible(which there are a lot of) require host(IP/DNS name of ACI box), username, and password. All of which I variablized. The tenant is then specified, the state is set to present, I ignore invalid certs, and Bob’s your uncle. It’s just that simple.

This is my run output:

This is what the ACI server shows once complete:

These modules are also idempotent, which means I can rerun the exact same command and instead of showing changed, they just show OK, which means nothing needed to be done:

Manipulation of ACI with Ansible is almost too easy; how would you use this functionality? What orchestrations or events would you have take advantage of this functionality?