Getting to know Cisco ACI…

Watching Cisco present on ACI at Networking Field Day 8 was a nice expansion to the introduction I received on the product almost a year ago at the ACI launch event in New York.  Now that APIC is shipping, companies can swap over from NX-OS mode to ACI mode and start playing with the magic that is application network profiles.

The basic components of ACI are the fashionable spine/leaf architecture that is all the rage these days, an APIC controller talking OpFlex southbound, and a switch operating system on Nexus 9Ks that interprets policy and forces it down to the endpoints.  Underneath the covers, each switch uses ISIS to build a routed topology from any VTEP (virtual tunnel endpoint) to any VTEP (basically from any leaf to any leaf). Rather than the controller programming routes and handling traffic forwarding, the controller focuses on pushing down policies that are understood and then implemented by the switches.

The concept of a self provisioning network also comes into play with the ACI solution, as does the concept of one big fabric to rule them all. The fabric can be zero touch provisioned, with the controller finding new switches brought online. The controller also acts as a single point of policy provisioning – the fabric itself scaling up to 12 spines, with multiple active controllers all sharing data for redundancy.

The heart of ACI really lies with the policy model and associated concepts.  ACI works by putting things into groups – usually done with identifiers like vlan/vxlan ID, subnet, 802.1q tag, or by physical/virtual port – and then these groups are assigned policy contracts which basically “turn on” connectivity between these groups, according to the rules of the policy assigned. The level of abstraction inherent in these contracts lend themselves well to automation and consistency in network policies, as well as allowing for a clean up process as applications are removed – therefore solving some of the what-the-heck-was-this-thing-nobody-remembers problems we engineers often encounter.

Application network profiles can be home brewed as well as provided in the form of device packages from vendors.  These device packages will automagically roll out the best practices for the application at hand, and if they are from an official partner, TAC will even handle support issues that arise from using the package. As Joe Onisick put it, “think of it as an automatically deployed Cisco validated design.”

There’s much more covered in the Networking Field Day 8 presentations, including service graphs – think service chaining but with flexibility for differing behaviors for various traffic groups, an API inspector that allows you to see the API code as you make calls through the GUI so you can create automation scripts from it, and atomic counters which allow for detailed health scores and packet tracking, but as I’m a sucker for a good demo, I’ll leave you with this, Paul Lesiak showing off APIC’s mad programmability skillz.


Published: 10/14/2014

For more links to ACI resources, you can check out my previous post, check out some excellent videos by both Lilian Quan and Joe Onisick on the subject (just go to youtube and seach for Cisco ACI), or check out Lauren Malhoit’s blog where there’s some good posts on getting to know ACI as welll.

Also, mucho bonus points to Lauren for not only being generally awesome all the time, but for also providing this ginger with a desperately needed Diet Coke as a caffeine source at this 8am presentation, an un-caffeinated ginger is a scary, scary thing.

Disclaimer: While Networking Field Day, which is sponsored by the companies that present, was very generous to invite me to this fantastic event and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.


Interop 2013 – HP’s UC SDN Application for Lync

Thanks to HP Networking* I got to attend Interop last week and it was quite the experience.  Besides being inundated with tons of cool technology, ample opportunities to chat with some incredible engineers, and some really good food, I actually saw a proof of concept SDN application for voice that was definitely intriguing.

Now I’m one of those who has heard the phrase SDN enough times in the last few months that I often want force-choke anyone who dare whispers anything about network programmability in my presence.  Up until recently I have focused pretty exclusively on voice, and while route/switch engineers are wondering if this SDN thing is really going to affect them, I guarantee it isn’t even a blip on the radar for most voice engineers.

That’s why this UC&C SDN Application for Lync from HP was interesting.  You see, HP has taken SDN and paired it with Lync – now the SDN controller finds out from Lync about the endpoints and how much bandwidth a dynamic desktop sharing session needs, and then marks packets and ensures they are treated properly along their network journey. Sort of reminds me of RSVP but without all the heavy configuration. It also gets the bonus of receiving stats on the flow for quality reporting.

There’s a decent demo here:

I was going to write up how this solution was working, but I found this post which already does an excellent job of that *and* has a nice pretty pictures:

Now not being a Lync guru, I am not sure how helpful those that are Lync gurus think this solution will be, but the proof of concept gets me thinking about what SDN might look like for all our other latency sensitive voice applications. To me it looks like voice engineers might have to pay attention to SDN after all.

*Disclosure: HP paid my expenses to Interop and arranged for me as a blogger to see presentations, demos, and experts on their products. While they did an excellent job providing information and resources for their invited bloggers, they didn’t pay for me to say nice things about them. Opinions are of course my own because I am far too stubborn to have it any other way.

Published 05/13/2013