Build the Next-Generation Data Center
6 week online course starting in spring 2017

The Ever-Increasing Complexity

Eyvonne Sharp wrote a great blog post describing Cisco’s love of complexity and how SD-WAN vendors proved things don’t have to be that complex.

I know Cisco (and every other vendor) loves making ever-more-complex solutions that lock you into their morass for the rest of your life (long-distance vMotion anyone?).

I’m also positive a lot of the complexity we’re facing is the result of customer requests. You know, those people that never bothered to understand how technology really works (because vendors promised them it’s easy), designed their network based on whitepapers (written by those same vendors), faced scaling challenges, and started yelling at the vendor to implement a dozen nerd knobs (while sometimes breaking the standards) to make their network work (stretched clusters anyone?). It’s amazing what a large PO can bring you ;)

The latest installment in that soap opera: OSPF Topology-Transparent Zone (RFC 8099) because it's easier to add another layer of indirection than fixing a broken network design. OTOH, fixing a broken design rarely sells more boxes and software upgrades.

Another source of complexity: clueless CYA customers that have no idea what they need because they never invested into a proper network design. When such customers create an RFP it often requires every technology ever published as an Internet draft “because we might need it in the future”. I’ve personally seen RFPs that were a laundry list of acronyms compiled from 3+ different vendor specs. Needless to say, nobody fulfilled all the requirements

HT to @Anonymous for reminding me of this one– I’ve been away from system integration business for too long.

Of course it’s not just the customers. Have you ever heard the “doing more with less” and “leveraging the existing investment” mantras (aka LISP-in-Campus)?

The real difference between Cisco and SD-WAN vendors is the length of their history. Cisco has been evolving their software for 30+ years (and has to support most of the **** they were forced to implement to get a particular PO indefinitely) while SD-WAN solutions started with a clean slate. Let’s see how complex SD-WAN solutions will get after being faced with incompatible impossible-to-turn-down opportunities for a decade or two.

It’s also easier to start from scratch and implement a clean bare-bones solution (quite often after learning the hard lessons while working for an “overly complex” $vendor) than trying to retrofit a new idea into the old framework (I still remember IBM mainframes having virtual punched cards and 132-column line printer printouts deep in the bowels of their operating systems).

Is it fair to make fun of the complexity-ridden legacy vendors? Well, it definitely makes for fun reading, but maybe we should just respect old age while at the same time telling the dinosaurs it’s time to change by voting with our wallet.

Can you get away from the complexity?

You do know you don’t have to use all the complexity the vendors are throwing at you, right? It’s possible to design simple and robust large-scale networks if you understand how technology works, and select the best tools for each job at hand.

We discussed how to do just that in data centers in the Building Next-Generation Data Center course in autumn 2016 (here are some of the questions we covered) and will do it again in less than a month. All you have to do is to accept the challenge of working really hard for two months and register for the course.


  1. "I know Cisco (and every other vendor) loves making ever-more-complex solutions"

    I work for a $vendor. I wish I could share the last 5 RFPs that actually crossed my desk. As long as our customers ask for lock, stock & barrel (i.e. contains every possible feature that they might use somewhere down the line), which is complaint with every standard out there, while leaving all the integration risk with the vendor, all these complex solutions are here to stay.

    Customers need to:
    1) focus: choose what is important and what not
    2) take responsibility: make your own architectural and design decisions

    1. Forgot about this one. Thanks for reminding me - added.

  2. Preach!!!! Just don't get all Brad Reese on us...

    1. Don't worry, it's not so much preaching as scratching a really old itch (had a few customers like that in my 30+ networking years). BTW, is he still around - haven't heard about him for a long while...

    2. His blog is still there, but he hasn't posted since August. It appears he's given up on being a Cisco watch dog, and moved on to promoting Reese's Candy full time.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.