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.


All Eyes on voice…

ThousandEyes announced something they called “new and shiny” at Networking Field Day 8 and it definitely caught my attention – not just because the word shiny was used* – but also because voice was the target of the announcement. I am quite used to being the literal and figurative red headed stepchild at networking events due to my involvement in that oh-so-unsavory world of voice** – but this Networking Field Day, voice got some well deserved attention.

ThousandEyes makes a product that via the use of Enterprise and Cloud Agents – those are active probes set out and about in your network, SaaS networks, and around the globe, you can gather some extremely detailed information regarding network performance, even when you don’t own all the pieces of the infrastructure along the path.

ThousandEyes is now leveraging that capability to ease the pain that is voice troubleshooting.  Using probes that emulate RTP traffic, you can gather data that can be used for capacity and voice quality planning purposes, as well as for troubleshooting voice performance issues.

Say you are planning to bring a new site online and route voice to and from this new branch.  Now you can collect detailed information that shows you how much this will suck (or perhaps not suck) *before* you go and purchase all the equipment for your design.

Say you are having trouble with voice between already established sites. This solution can help you identify capacity issues, jitter issues, and even DSCP remarking issues.  That last one really makes me smile.  How often is voice wrecked just because consistent QoS isn’t applied across all devices in the network?  No need to answer that out loud, we all know…

So here’s an idea of what a voice test creation would look like.  You can see there is a codec selection option, DSCP setting, and even a de-jitter buffer option that can be tweaked for the testing.

photo 100000 (24)

Below is an idea of what kind of data is being presented back. I really like that you can jump to the BGP path visualization and other layer tools just as usual with the product. Feel free to watch the short video here for the full show and tell.

photo 100000 (28)

Now it’s important to remember that this isn’t actually running tests on “real” calls being made in your network. While ThousandEyes makes a point of crafting probes to look and feel as much like actual application traffic as possible, it’s still not a live call.  I did ask about workflow integration with some tool like Wireshark or something similar and got a to-be-continued type answer.  In my vision, you would set alerts when thresholds were met that would kick off capture processes of live calls. Then you would correlate the .pcap files with this data to get a complete picture of the network. That way when the Director’s call to his beloved Aunt Erna drops and he wants to blame your really expensive phone system, you will have plenty of evidence to suggest that Aunt Erna just hasn’t mastered the art of speaker phone on her cell. Talk about a happy world.

Published 9/22/2014

*using the word shiny is a pretty good way to get my attention.  Using actual things that are shiny, even better.

**hating on voice is a well-known pastime for those engineers too afraid to touch it. 😉

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.