ACI – Initial Impressions

I’ve written a fair bit about ACI, having attended as many Cisco roadshow/classes as possible on the subject. I learned a ton about ACI and the theory, the underlying infrastructure bits, I learned a bit about how to navigate the GUI, and I’ve gone on to talk about it with lots of cool customers. I’ve really enjoyed it so far. I believe in the overall direction that Cisco is trying to go with ACI — VxLAN underlay, Hypervisor Agnosticism, Media Agnosticism (bare metal and/or virtual), and the heavy use of Broadcom chips to keep the cost down, with a bit of Cisco ASIC magic sprinkled in to be able to do some other cool things. Since I really do like where all of this is going I’ve been preaching about VxLAN/9ks and even ACI to customers and people within my company. Apparently to some effect, as I was able to convince my company to acquire an ACI lab! I wanted to write a bit about my first impressions outside of the guidance of Cisco classes and slide decks. This will be a brief post as I want to get back to the lab and start churning out some material, so here we go!

First things first — we all know that ACI is API and GUI driven, but once you get out on your own and don’t have a lab guide to follow it is seriously overwhelming! Theres a CLI on the 9ks, but its a weird pseudo CLI that is actually just a sort of front end for the Linux kernel. It’s there, you can certainly validate some things, but you can’t just fall back to typing “switchport mode access” etc., you’re pretty well forced into the GUI/API. I think longer term this won’t be such a big deal, but it for sure is a difficult adjustment to make.

It’s VERY object driven. I’ve heard that, I’ve read that, I knew it was going to be like that, but it really really is. I’ve not had any real UCS experience, so I was starting out in this world from scratch. I think for the UCS junkies out there this will be pretty familiar. I don’t have any particular gripe about how object driven it is — in fact I think it’s actually a good thing; orderly and hierarchical. What has been difficult for me is understanding all of the object interactions. If you change something in a bridge domain, it obviously has lots of impacts. Something I would love to see is a way to highlight a particular configuration and to immediately be able to see what objects reference that. Perhaps more importantly, if you go to delete an object, it would be great to know if it’s still being referenced elsewhere. I suspect some of these improvements will get ironed out as the platform matures.

Abstraction is great, but not ALL the time. I think this is maybe just a product of the learning curve, but I’ve been getting frustrated with simple tasks mostly it seems. Setting up NTP… I think I set it up right… the NTP server is reachable, but it’s still throwing (cryptic) faults at me? What gives? I don’t know because I don’t have my normal show commands. Setting up a routed interface… do I really have to have 10 different things setup? It seems that way. This kind of thing sucks for one-off configurations, but the repeatability and reusability will be awesome for larger deployments.

So far I think the time I’ve spent on the lab, getting it setup and tested, has been pretty evenly divided between being frustrated and being excited. There is clearly a learning curve at play here, it’s also a big shift from the traditional way we configure networks, but its all for the best I think. As ACI progresses and more people adopt it and more blog posts are written and more how-tos are created everything will get easier. I’m looking forward to trying to crank out some posts and videos over the next few months to try to help others as they dive into this.