Feedback from Another SD-WAN Fan
I don’t know what’s wrong with me, but I rarely get emails along the lines of “I deployed SD-WAN and it was the best thing we did in the last decade” (trust me, I would publish those if they’d come from a semi-trusted source).
What I usually get are sad experiences from people being exposed to vendor brainwashing or deployments that failed to meet expectations (but according to Systems Engineering Director working for an aggressive SD-WAN vendor that’s just because they didn’t do their research, and thus did everything wrong).
Here’s another story coming from Adrian Giacometti.
This was my first encounter with SDWAN a couple of years ago and I realized that there was no magic, it’s just a Linux with some coding, and if all the traffic has to go trough it, bingo, you can do whatever you want.
At that moment I used to ask simple question to the vendors.
Me: “How does your device decide which link to use?”
Vendor: “They measure the quality and packet loss but you don’t have to worry about it, look at this demo is magic”
And it was like magic… but still. For the second time I asked
Me: “The question remains, is it a ping? What is it? And how I can influence that decision? The logic? How i can be sure the it will not screw up things with flapping links?”
I never had a good answer. Ok let’s continue with the questions
Me: “How is the deployment?”
Vendor: “It’s easy, one per-site, in the middle of the way of your current devices”
Me: “Ok, it’s a little bit disruptive. Does it have a fall back? What happens if your device hangs up. Because I trust my routers? Make me trust in your device…”
Vendor: “Eeeh …. Mmmmm”
Ok, let’s move on…
Me: “I have to deploy them at all the sites or just on the main sites?”
Vendor: “It’s not necessary but we recommend that you deploy them at all sites.”
Ok, you are just trying to sell boxes. Fair answer.
Me: “How my current routing scheme will work if I don’t deploy SD-WAN at all sites?”
Vendor: “If traffic will go through SD-WAN devices, no problem”
Ok, another thing inserted in my working routing scheme. I assume it might work, but…
Me: “Ok then, how much does it cost because I might need a lot of boxes?”
Crazy expensive… for a Linux server.
Ok… I believe in progress, but you are trying to sell me something that is not as magical as you say, it’s just a nice compilation of old and very basic techniques with a beautiful GUI. And I say “very basic techniques” mainly because it seems to use only ICMP for calculations, it works as-is, and I can’t modify or check it further. Or at least you are not willing to give me more low-level details.
So, I like the concept, but I have to go back to your premise, this is a lock-in and nothing so new, it’s just the ability to code faster than some big players.
Or like when I started to study OpenStack and VMWare-NSX… what? They all use the concept of the old fellow Linux-bridge and tunnel interfaces!
And I hit my forehead… of course… remarketed old concepts just that with some additional coding you can scale easily.
1 - It's connection agnostic, let's get a bunch of DIA's from different ISP's and bundle them all together so we can get one fat pipe and not worry about circuit failover. We no longer need our big expensive MPLS circuits, and don't have to wait 2 months for $Large ISP.
I may have them in the wrong order, or missed some key buzzwords.. but that's the basic idea. I think it will take time to mature, but for those who like to know exactly what's going on under the hood, it's a tough call.
Mario
You pretty much nailed it ;)... all without in-depth documentation of implementation details that would help us troubleshoot it, and often with security holes big enough to drive an Abrams through...
Hi Ivan,
Interestingly I was having chat with another fellow engineer today on somewhat along similar lines. In my case the context I was asked about - " Can we move a potential client from 100% MPLS (today) to 100% Internet from Transport perspective with SD-WAN"
My answer was -
You can either bring math and science into this (Which most SD-WAN vendors wouldn't prefer) - As it takes time, resources and makes sales cycle lengthy.
Just run a Production POC with Client and figure out
Now as you might have imagine, 90% of enterprises in my view and vendors too prefer the 2nd option.
If you look closely , 1st option is more sensible though but in most cases it's not only vendor but also clients want to go down 2nd path. Part of the equation is not every client has people like Adrian on their side and most clients don't perhaps even the nuances of Design choices even if we wish to explain them.
But again, on the flip side we as Network Architects shouldn't get offended if Vendor guy can't explain in detail a certain feature on functioning. Point being most of Engineers on both Client and Vendors sides are merely Product Engineers and focus into Technology depth is going down in my view since SDN came as one of it's fame claim was to hide complexity. And IBN perhaps makes that gap wider since as operator I should only focus on policy constructs and no need to look into or care about stuff going in the background.
But otherwise If I were that Vendor guy running presentation for Adrian, I would rather tell him to get this stuff through Semi Production POC and let the solution do the talking for itself.
Since personally I have spoken to people on Client side occasionally which would go into the depth and ask questions around packet flow at HW level including ASIC pipeline, NOS Structure and so forth. And as you can see it's a never ending story so personally I wouldn't mind if someone who is presenting to me doesn't have that depth in most cases as still in real life most Engineers not often go that far.
My 2 Cents...
At at level of absolute sarcasm a cisco router is nothing more than some PDP11 code so give me Linux any day. The question that needs answering is not about SDWAN but do we still need MPLS or branches? If we don't need them then we don't need to replace them.