Real-Life SD-WAN Experience

SD-WAN is the best thing that could have happened to networking according to some industry “thought leaders” and $vendor marketers… but it seems there might be a tiny little gap between their rosy picture and reality.

This is what I got from someone blessed with hands-on SD-WAN experience:

First of all let me be very honest that I’m not the subject expert but a user of SDN WAN technology who happen to work with it on daily basis (suffer could be used interchangeably with “use” as well :)).

My personal opinion is that many vendors have really jumped to this wagon prematurely, in fear of not to miss it. All they did was put together a bunch of programmers who wrote code hoping that it would change the networking world. I must say that legacy networking had a lot of imperfections, however the code along with the supporting hardware was put to the production after a rigorous testing and expected to behave as it was supposed to. On the SDN part, it appears everyone has caught the fire and they must jump into the pool before it’s too late.

We are using an Overlay based SDN solution and with every release it appears that we are opening a new can of worms. SDN and NFV are fantastic technologies but I must say some implementations are way too raw and un-milled (they are not even qualified to be called Beta versions). Industry should have moved a little slower when it comes to offering something for production networks.

Unfortunately this is not how this industry works. For more delightful banter on the same topic listen to The Trough of Disillusionment on Network Collective (including Tom Hollingsworth being aggravated about me calling RADIUS an SDN solution :D)… and if you need more detailed SD-WAN horror stories check out the latest version of SD-WAN security presentation.

8 comments:

  1. I’ve had some stick time with a couple SD-WAN solutions as well and generally agree with the comment you quoted. I’m still debating whether the software is more buggy than normal (completely possible since it’s a fairly unique way of doing things) or if the bugs hurt so much more since everything is abstracted and the operator doesn’t have the tools to effectively troubleshoot these issues.

    When a bug appears on a traditional switch/router, an experienced operator tends to be able narrow down the problem and have a specific conversation with the vendor about what needs to be done. The problems that I’m running across in SD-WAN solutions are typically show stoppers and there is little I can do to remediate, troubleshoot, or diagnose.

    It makes the whole experience a bit frustrating. I’m still convinced that SD-WAN can provide significant value in today’s enterprise/SP market but we still have some maturing to do before we can expect the hype to even come close to reality.
    Replies
    1. You just proved my "there's a bit of a difference between a network and a car" theory ;))

      https://blog.ipspace.net/2018/02/how-self-sufficient-do-you-want-to-be.html

      Thank you!
      Ivan
  2. Ivan, great post, it's time to say stop to all these marketing stupidities.
    I think you should write a similar one on Segment Routing: "Real-Life Segment Routing Experience". How many ISPs are using it? Which business case they want to solve deploying SR? Which controller they use use to define paths? and so forth.
    Lately, in a consulting service I have heard the most stupid thing in my humble life of networker: a well known $vendor wanted to sell an IXP which has currently a classical DC L2 and want to switch to VXLAN+EVPN, their products telling us they support Segment Routing, which is very important for a DC. Did you hear well? Segment Routing in a DC Leaf-and-Spine, where all paths are two hops. It reminded me of "Thast's incredible", an old entertainment show of USA TV...
    Replies
    1. There are supposedly very-large-scale data centers that could benefit from segment routing in the core (more so if you're the only $vendor with this particular hammer). However, as I did interviews with routing gurus a while ago nobody could give me a persuasive use case. Please note that the WAN edge is a different story.

      So it seems like you were dealing with either a $vendor evangelist who drank too much Kool-Aid or someone blinded by the glitz of the new technology to the extent that he couldn't figure out whether it makes sense to deploy it (along the lines of "LISP is the answer... what exactly was the question?" discussion I had a long while ago)
  3. I was also lucky enough to pilot two of the leading SD-WAN vendors, one of which actually made it out of the lab and into a remote site. It was fine and even better than what we have in some respects but the remote stack turns out to still include our current security appliances because the SD-WAN products can't really do everything in a single edge product. The vendor's solution to our limited space and power at the remotes is to move the delicate SD-WAN edge product onto a universal CPE running the edge and our existing security appliance as service-chained virtual instances in an openstack jenga tower. Aside from this not working at all in our labs yet, how in the world is this easier to deploy and manage than what we already have? I'm cautiously optimistic but if I were a betting man, I'd put my money on just upgrading our aging security appliances.
  4. Well most problems in this world can be only solved once we admit there are problems. As soon you admit, you can pretty much find a set of possible solutions.

    Most SD-WAN vendors documentation is not good enough, Having some sort of secret sauce added into it makes it a Black Box solution anyways. Their own SMEs have limited understanding about how things work behind the scenes. To my personal understanding 90%+ deployments of SD-WAN in industry are still manual which itself defeat the purpose of rosy SDx concepts.

    And of course everyone want to take this madness to next level with IBN idea.

    HTH...
    Evil CCIE
  5. I'm interested in reading the latest version of SD-WAN security presentation, but the URL shows broken to me (404)
    Replies
    1. https://github.com/sdnewhop/sdwannewhope/blob/master/slides/insomnihack-2019.pdf
Add comment
Sidebar