SD-WAN Reality Gap

Here’s some feedback I got from a subscriber who got pulled into an SD-WAN project:

I realized (thanks to you) that it’s really important to understand the basics of how things work. It helped me for example at my work when my boss came with the idea “we’ll start selling SD-WAN and this is the customer wish list”. Looked like business-as-usual until I realized I’ve never seen so big a difference between reality, customer wishes and what was promised to customer by sales guys I never met. And the networking engineers are supposed to save the day afterwards…

How did your first SD-WAN deployment go? Please write a comment!

Recent posts in the same categories

7 comments:

  1. Avery Abbott 09 January 2019 20:45
    We're about to hit year 3 of rollout. I'll let you know when it's finished, lol.
  2. Karl_Irl 10 January 2019 10:27
    As per usual Ivan, bang on the money!
  3. Unknown 10 January 2019 15:18
    Buggy as hell and more nerd knobs than a NASA space shuttle, I see the benefits of the technology but not necessarily in detriment to the stability of our WAN, hopefully 2019 will be a more stable year once the last few wrinkles are ironed out - finger's X'd!
  4. lcw 10 January 2019 19:29
    With SD-WAN, you're really buying into a black box that controls how apps are identified, how traffic is forwarded, how asymmetry is handled, how link degradation is detected, how direct-internet-access is utilized, and how public cloud is connected. That's a lot of vendor-proprietary "secret sauce!" It's very tough to compare vendors and predict if their approach is going to serve all your needs now and in the future (or if instead you end up covered in secret sauce).

    Most SD-WAN products are fine to replace simple singly-attached hub-and-spoke WANs, as well as retail where apps are relatively static. But if you have multiple WAN/Internet circuits, multiple WAN destinations, or an app landscape that changes with the wind, then you really need to evaluate carefully.

    And, by all means, please engineer your WAN edge to make it easy to add, remove, and change SD-WAN products, including the ability to run two different products side-by-side.
  5. A Network Artist 11 January 2019 02:51
    By now I have done Pre-Sales, Architecture & Implementation of SD-WAN for couple of clients.

    There are few observations I have based on my own experiences at field.

    1. SD-WAN may or maynot work as expected on Day 1 and you may need to finetune lot of knobs to get things done the way you want.
    2. Most Enterprises traditionally were using MPLS Layer 3 VPNs. Which in most cases means they don't usually have in house expertise into Routing & Overlays. Which is often ignored by both Consultants and Clients as Client might not have enough operational experience with Complex Routing.
    3. SD-WAN is no Silver Bullet. Proper Design, Architecture & Methodology are still very important.
    4. Most SD-WAN vendors over commit when it comes to solutions capabilities and don't have very good documentation publically available.
    5. Most SD-WAN solutions uses some sort of Secret sauce. So essentially it's a Black Box.
    6. To sell SD-WAN as a service , Telco's typically need different set of features which most SD-WAN solutions are not designed around or rather have partial capabilities.

    7. One observation I have personally for different so called SDN products is that most don't get the Abstractions right when it comes to Management portal/platform while trying to introduce programmability approach. While I agree most should support programmability & automation through APIs and that's what most vendors are trying to do, From abstraction standpoint that doesn't mean one should go through 7 different screens to configure a VLAn and map it back to physical interface on switch. I don't understand why vendors don't understand that these are two separate problems to be solved to begin with.

    HTH...
    Evil CCIE
  6. Unknown 11 January 2019 09:43
    The biggest disadvantage for me as a network guy is the lack of transparency in how things work and absence of the generally accepted reference.
    It is all black box magic - you don't know why it works and you don't know why it does not.
    If I add more complex apps over it - will it continue working ?
    For the simple wan redundancy and simplistic load sharing things work for the most vendors. But if something breaks you are left to the vendor tac professionalism mercy. There is no RFC I can read and try to compare/reference.
    Reminds me of wan accelerators history (Cisco WAAS) - if it works it works, but if it breaks have TAC phone ready.
  7. Unknown 17 January 2019 12:40
    Is anyone who has commented able to elaborate a little on the vendor(s) solution you have deployed/worked with?
Add comment
Home
Sidebar