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.


2 thoughts on “ACI – Initial Impressions

  1. An interesting article and, I think, confirms my fears about ACI. Don’t very me wrong, this isn’t meant to be an ACI-bashing comment, I’m just coming at it from my perspective and my use case.
    We have an enterprise network with a load of 6500-Es in our data centre which hosts our internal and external systems on shared but segmented infrastructure (don’t get me started on that one!). We have adopted a lot of infrastructure as code and DevOps methodologies and toolsets for our environment provisioning but the network was holding us back. In looking at options for a data centre refresh, we obviously looked at ACI and attended an ACI Test Drive.
    From that research, it suggested to me that whilst ACI had a lot of things going for it, I think ultimately it would have added greater overhead to managing our network, not less, fur the very reasons you state: “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”.
    We are a mid sized enterprise with about 1000 staff. Our infrastructure is shared for internal and external services. We have a lot of external services each with differing or unique connectivity requirements, not a small number that need to scale horizontally. My conclusion at the time, and reinforced by your post, is that ACI is geared more towards large- rather than mid-scale deployments and environments that need more repeatable scalability which offset the high initial setup effort by the savings made in easier reuse, rather than regular new set ups where the initial setup time outweighs any subsequent changes or scaling up tweaks made.

    • Hey Paul!

      I totally understand where you’re coming from. While I personally think ACI does have a home in pretty much any data center, thats obviously up to individual companies/people to decide. I think the learning curve and work up front will subside rapidly. I just upgraded from 1.0.3 to 1.1.1 on the APIC/Fabric and I already have noticed significant improvements. I had a call with TAC the other day and was talking to the lady about adoption etc., and she mentioned the massive effort Cisco is doing internally to “flatten” some of the GUI to make it more accessible. With the improvements I’ve seen in the last few months, and the promised improvements coming I really think the bar to entry will just keep getting lower. Lastly, my feeling is that if you are on the precipice of a Data Center refresh/overhaul, you are going to have to make some hard decisions. You could go with a traditional (but aging rapidly) three tier design. You could set off about on learning EVPN/VXLAN stuff to have some more future potential, but that isn’t necessarily easy (maybe a bit easier since its a familiar CLI). Or you could commit to a significant undertaking up front and jump into the “SDN” space with ACI or NSX or Nuage or some other vendor. I think all of them will have a huge learning curve, but in the longer term will yield more benefits. As always “it depends” on your situation and you and your companies appetite for perceived risk (I say perceived because I think its not so much a risk, but a challenge of adoption).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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