This is a guest blog post by Andrea Dainese, senior network and security architect, and author of UNetLab (now EVE-NG) and  Route Reflector Labs. These days you’ll find him busy automating Cisco ACI deployments.

---

In this post we’ll focus on a simple question that arises in numerous chats I have with colleagues and customers: how should a network engineer operate Cisco ACI? A lot of them don’t use any sort of network automation and manage their Cisco ACI deployments using the Web Interface. Is that good or evil? As you’ll see we have a definite answer and it’s not “it depends”.

If you’re reading this blog post, you probably already know what Cisco ACI is (hint: Data Center SDN solution from Cisco). If you don’t know anything about Cisco ACI, you should probably read some other blog posts, watch this webinar, and then come back.

Interacting with Cisco ACI

Engineers can interact with Cisco ACI through multiple programmatic- and user interfaces:

• Web User Interface (Web UI, or GUI)
• Command Line Interface (CLI)
• REST API
• Software Development Kit (SDK)
• Visore

GUI, CLI, SDK and Visore are actually calling REST API. We can say that Cisco ACI is implementing REST API in a proper way as you can do everything APIC offers through REST API, and most components use the same REST API to get their job done.

Let’s forget Visore for a while because it’s not a configuration tool, and focus on the configuration tasks:

• There are dozens of configuration objects that can be combined in numerous ways (tenants, bridge domains, application profiles, leaf and spine interface profiles…);
• Every object can be configured with at least a dozen different options;

Conclusion: Every simple task we’re trying to accomplish can be achieved in a pretty unique way, and that’s bad!

Let’s make a simple example: a network engineer must attach a new fancy device to ACI fabric. The device is using two aggregated interfaces (in virtual port-channel configuration). Next he has to map a VLAN used by that device to a specific EPG inside an application profile inside a tenant. Here are the tasks he has to perform:

1. Connect the new device.
2. Configure the port-channel:
3. Bind a VLAN from the port-channel to a specific EPG (assuming that the EPG already exists).

Configuring the port channel involves at least:

1. Configuring interface policies unless they have already been created;
2. Create the interface policy group and attach all related interface policies… after figuring out which ones to choose. Should LACP be active? Should he use no suspend? BPDU Guard, Filter or Forward? Should CDP or LLDP be enabled or disabled and which one should be used? Which AEP? And finally, how should the new object be named?
3. Create interface profiles: one for both interfaces or one for each interface? And, again, what should their names be?
4. Bind the interface profile to the switch profile: that’s should be the easiest task in the whole sequence.

Now documents every step in details (naming convention, policies to be used…), and try to give the same task to 5 different network engineer. Will their results be identical? How long did they take? How many of them introduced an error… and how would you even identify that an error has been made?

As you would expect, in a real-world environment:

• many of them made mistakes while completing this relatively simple task;
• it took them anywhere from 30 minutes to a couple of hours depending on their skills.

As expected, using GUI is the worst possible way of doing things (probably even worse than using CLI).

The right way

Because of the complexity of configuring Cisco ACI, the number of manual tasks must be reduced… and if you keep doing manual configuration, you are going to have hundreds/thousands of concatenated objects without knowing what each one is for. It’s like firewall policies: it’s easy to add a firewall rule, it’s almost impossible to clean them up.

I’m not discussing why and how automation should be introduced in organizations, I’m just saying that Cisco ACI cannot be configured or managed by manual GUI-driven operations.

Start with:

• understanding why and how you want to introduce automation;
• analyze how your staff is working;
• standardize tasks;
• automate tasks;
• orchestrate group of tasks.

Optional:

• find the right skills to analyze, standardize and develop what is needed.

Real examples of automated tasks

Here arew a few real-life examples of automated deployments I did.

Configuring a virtual port-channel (described above):

• by a medium-skilled network engineer: 30 minutes
• by a script: less than one minute

Building a new tenant from scratch (including hundreds of bridge domains, application profiles, hundreds of EPGs, dozens of L3Outs, dozens of static routes, dynamic routing…):

• by a medium-skilled network engineer: days, maybe weeks
• by a script: 5 minutes

Documenting a Cisco ACI installation (find out what is connected, and which object is using which other object):

• by a medium-skilled network engineer: days, maybe weeks
• by a script: 5 minutes

Conclusions

I’m not saying that building automation for Cisco ACI is easy, I’m saying that operating manually on Cisco ACI is the worst thing you can do:

• you’re doing things in a non repeatable way;
• you’re probably introducing many errors;
• you’re spending more time that needed doing repeatable tasks;
• you still have a lot of manual work in your deployment phase.

And finally:

• you’ll soon lose control having hundreds/thousands of objects with operators trying to understand what is going on.

Rather than doing error-prone manual work you should automate your Cisco ACI installation to:

• avoid manual mistakes/mistypes;
• have repeatable and reproducible tasks;
• execute tasks fast;
• execute tasks by non skilled operators or directly by third party softwares;
• continuously document what is going on;

Change your mind, start automating your processes and individual tasks, and then stop doing things manually.

Finally, if you’re managing a bunch of independent devices, you can still do that manually. But if you have Cisco ACI in place, or you plan to get it, the only way to retain sanity and survive its complexity is to start automating… and if you don’t have the required skills to approach the problem, either train your team or find them outside.

---

Want to implement something similar in your Cisco ACI deployment? Dirk Feldhaus described the details of his Cisco ACI documentation and automated Cisco ACI tenant deployments solutions in Building Network Automation Solutions online course.

---

To learn more about what Andrea is doing these days, and whether he might be able to help you doing something similar, contact him through LinkedIn.