Tag Archives: SD-Access

Cisco DNA SD-Access: Evolution or Identity Crisis?

This blog will make the most sense to those who use (or are very familiar with) both Cisco and Meraki network environments. (Not you? Feel free to leave, but before you go let me at least show you my boat– and yes, it is for sale. OK, now get outta here.) For the rest of you… onward we go.

Get Your SD-Access Mind Right

I’ve been trying to educate myself on Cisco’s latest evolutionary moves, as I happen to be a twenty-year Cisco customer. There’s a lot of energy going on between DNA, SD-Access, THE NETWORK. INTUITIVE. (God that one is just terrible, I’m sorry) fabric this and that, and a procession of other grandly named initiatives. It’s all very fascinating, and impressive to a certain degree. I want to share my impressions on SD-Access specifically, and am curious what others in the game might think of my take on it after you digest all of this.

First- you have to understand what SD-Access is all about. This will get you started if you need a kick-start, but I suggest getting a better look by viewing these Techwise TV episodes.

Now the part about Meraki. After learning about SD-Access, it feels to me that Cisco is trying to somewhat “Merakify” their network approach. SD-Access even starts with the Meraki-style networky map, before continuing in many Meraki-ish ways:

Landing Page
SD-Access Map

Compare to the Meraki map:

Landing Page 2

Meraki Map

The similarities continue- in the videos the presenters enthusiastically talk about doing virtual configurations for equipment that’s not in place yet, etc. Much of this is Meraki 101 in look and feel, but with significant operational differences.

All That’s Good About Meraki, All That’s Bad About Cisco?

As a long-time Meraki customer, I have LOVED not having to deal with the administrative and OpEx pain that comes along with Cisco’s approaches at times. With Meraki there is NO bloated, chronically quirky NMS (like PI), or wireless controllers that have their own history of hardware and code issues. All that’s in the cloud, and someone else’s problem to keep up at upgrade and debug time.

(I am NOT saying Meraki is perfect, by any means. All solutions are trade-offs. I’m only pointing out that the hundreds of man-hours per year in OpEx troubleshooting bugs and such in PI and WLC have not had equal headache on the Meraki side for me.)

With SD-Access, it seems that APIC-EM becomes the on-premise magic that is equal to the magic that Meraki uses out in the cloud, but only for Merakifying traditional Cisco components. So at the end of it all, if you have the right Cisco components, SD-Access will give you a very Meraki-like experience from the admin side.

Now, I do realize that SD-Access does A LOT of stuff, and likely delivers some features that Meraki can’t right now. But..

I actually use daily many of the Cisco components that fall under the SD-Access framework, and they can demand copious amounts of care and feeding. For the Wireless LAN Controllers (just one example), you may have to play several rounds of Let’s Make a Deal with TAC to get code that works good enough in your environment- and the larger your environment, the harder it seems to be for Cisco to test at scale. Having been around this block with Cisco dozens of times, I have no reason to think the underlying culture of bug tolerance and hyper-complexity is probably going to change soon. So often-problematic components becomes part of a new, API-driven architecture? That’s fairly terrifying to me.

At the same time, achieving “The Meraki Experience” is an admirable goal, as using Meraki’s own approach has been fairly fantastic for me, by and large (with only the rare “oh shit” moment along the way.)

The Point

I think it’s awesome that Cisco can try to poach what’s good from Meraki (and visa versa), but it also makes for confusion. If Cisco is trying to be Meraki for access, then what’s Meraki supposed to be at the end of it all? Or will SD-Access be ultimately marketed as “on-premise Meraki” or some such?

Meanwhile, I can’t imagine the inevitable TAC case nightmare that will come when something isn’t working in SD-Access and I have to wade through PoE bugs on switches, any number of problems on WLCs, API debugs and ISE logs to figure out which part of the magic isn’t behaving THIS time around.  For me, if I want a Meraki-like experience, I think I’ll opt to stay with Meraki’s lack of in-house moving parts and give SD-Access a pass- at least until something happens on the Cisco side that convinces me the solution won’t be as buggy as is it’s parts.

Your thoughts? Please share an opinion, as all are valued.