Some Ridiculous SD-WAN Claims

SDx Central is usually a pretty good web site that I love to read, but even they occasionally manage to publish a gem like this one:

The problem with MPLS and similar technologies is that they weren’t designed with today’s business challenges in mind. Today, a company may need to launch an overseas R&D office overnight, or it may acquire a startup and want to immediately network with offices in distant regions and countries. Older technologies just don’t have the flexibility to do this on the fly.

Not surprisingly, the above paragraph triggered a severe case of Deja-Moo.


Technology has nothing to do with it. It’s reasonably easy to deploy auto-configuring DMVPN network if you spend a few days studying how DMVPN work and thinking about configuration templates and auto-configuration mechanisms:

  • Use DNS-based NHRP on DMVPN spoke routers;
  • Use DHCP prefix delegation to assign IP addresses to DMVPN spokes;
  • Use dynamic BGP neighbors to build a scalable network;
  • Use shared keys (if you don’t care that much about security) or certificates.
You might want to consider watching DMVPN and Ansible webinars if you don’t know what I’m talking about ;)

It’s all about the processes and procedures. The real reason service deployment in typical enterprise network is slow are broken processes:

  • Organic growth coupled with lack of good network design (because managers think anyone can do it and thus don’t want to pay for it);
  • Lack of configuration templates (aka the death by thousand kludges);
  • Lack of automated deployment processes (because the software to do it is supposedly too expensive).

The end result: every network (and sometimes even every site) is a unique snowflake. No wonder it takes forever to carefully craft and deploy another unique snowflake instance.

Also, when we’re talking about new offices in distant regions, there might be this small problem of physical connectivity (in some countries it’s neigh impossible to get a free copper pair, particularly in old cities) which is equally bad for MPLS and Internet services.

Finally, immediately connecting a startup might involve a nasty case of dual NAT, which will probably trip most SD-WAN products (which is what the author of that article is promoting), but of course the software-defined evangelists love to gloss over dirty details like this one.

The Advantages of SD-WAN

Things are usually not totally black-and-white. Most SD-WAN products do have advantages (particularly in enterprise networks) over more traditional solutions:

  • They are new, so they haven’t accumulated so many configuration knobs (but I’m positive they eventually will – no vendor can resist the lure of implementing a few per-customer knobs if a big order looms on the horizon);
  • Their architecture uses a central controller (behind the scenes it’s usually a combination of configuration management tool and route reflector), so it’s impossible to create truly unique snowflakes.

However, I’m still waiting to see how well the SD-WAN products survive the clash with enterprise reality (you might want to read Tom Hollingsworth’s take on Meraki, which is facing a similar problem).

But Wait, There’s More

As you might expect, the rest of that article fares no better than it’s beginning. Here’s another Deja-Moo claim:

This is the promise of the SD-WAN: intelligence built into the network; the ability to deploy in minutes; the elimination of vendor lock-in; and the ability for anyone, anywhere to quickly access all enterprise resources, no matter where they are located.

Intelligence built into the network – and how are the existing networks operating? Using a central control plane?

Ability to deploy in minutes – assuming you already got physical connectivity, but then I can as easily deploy another DMVPN spoke router at that same location.

The elimination of vendor lock-in – ah, that’s why Greg Ferro wrote[While standards are important], I don’t believe they are practical in the current situation around the WAN

While some lock-in is usually inevitable, at the moment, every single SD-WAN solution is a total lock-in, and anyone who claims otherwise is either clueless or trying to mislead you.

A Note to Marketers

I think I wrote this before – I understand you have to do what you have to do, but you don’t have to make yourself looking totally ridiculous in the process.


  1. sorry for being anonymous (again), but that's great! one more: those sd-people want us to believe/forget that internet connectivity is the same as MPLS connectivity, same service, same sla, same user experience. it isn't.
  2. SD = snakeoil deception
  3. I like SDx central and for the same reasons.

    There is only one reason for SD-WAN. That reason being an enabler for NFV to deliver services via a third party (off-net).

    Think Tunnel Broker and all will become clear.

    Shifts in design and paradigms are underway.

  4. Thanks Ivan, very intersting!
  5. What people like you don't understand is that SD-WAN doesn't need physical wires. It just transmits packets in software and they just get to the endpoint like the software has told them to. This could be RFC 1149 or 2549. It's software, see? It's not called HD-WAN. You don't need hardware, aka physical network. You just need a horned-pony API and a bash script to put all your curl commands. All you SDN haters need to wake up to the real world. And all you hardware vendors will be bankrupt. And also stop twisting cables, you are wasting time.
    1. Made my day ;)) Thank you!
    2. This is really embarassing my friend. Are you saying the software will switch the packets in the air? Please do your due diligence while you speak in public forums.
  6. "It’s all about the processes and procedures. The real reason service deployment in typical enterprise network is slow are broken processes".

    According to my mate there is no need for processes, procedures or ITIL/ITSM for that matter, all thats required is a light sprinkling of DevOps pixie dust and you're good to go.
  7. Few of videos from sd-wan vendors, one from silverpeak and you can also see viptela... although am still skeptic about sd-wan... but this looks easy

    1. It is easy - and you'll find way more videos from NFD events at TechFieldDay web site. I'm just saying (A) it's not as revolutionary as marketers would like you to think and (B) the claims are greatly exaggerated.
  8. Are there any vendor-interoperable, encrypted Internet overlays that are in the same league as DMVPN in terms of simplicity and configurability? I don't think GETVPN counts because it's not really compatible with public Internet addressing; hence the terrifying GETVPNoDMVPN.
    1. There is "Auto-Discovery VPN" (RFC 7018), but then there's no multi-vendor implementation.
  9. Interesting view .. I know its a year old ..ran into this while searching for something online

    I think this is what it usually means :
    This is the promise of the SD-WAN: intelligence built into the network -> Ability to do packet by packet or application based monitoring to prioritize your traffic.

    the ability to deploy in minutes -> As compared to setting up PBR or adding a whole new circuit to your office

    The elimination of vendor lock-in -> No longer tied up to MPLS vendor for expensive contracts. sdwan is more of an overlay

    and the ability for anyone, anywhere to quickly access all enterprise resources, no matter where they are located -> Basically with public internet links you can still have your version of 'intranet' due to the sdwan overlay/cloud.
Add comment