It will make more sense once you notice within a few months or quarters those expensive mpls links getting out ordered for cost savings.
MPLS = rock solid and private but expensive
Internet = cheap but unpredictable
SD-WAN is nothing more than a fancy term for some routing logic over private or VPN links
Your company is probably implementing VPNs over the internet as a backup route to the MPLS. The SD-WAN logic then determines which path to use for the different applications.
Eg time-sensitive but low bandwidth services like VoIP can be set to run over MPLS but switch to VPN if there’s an issue with the MPLS. Intranet web access can be set to go over MPLS as it’s not latency sensitive but it’s more bandwidth hungry.
First and foremost SDWAN is just a way to manage and drive efficient utilization of a “a variety of different transports between the sites”. It’s just lots of tunnels, and clever routing to make good use of them.
Of course it’s all (or nearly all, depending on vendor) achievable through other means, but generally that’s HARD. With traditional routers, typically getting dual MPLS, or even dual MPLS with additional tunnels over DIA to work is easy. Making sure you’re actually USING all of that bandwidth instead of just letting it sit idle waiting for a failover event is harder. Doing that and ALSO ensuring that traffic is taking the right transport at any given point is even harder (i.e. if 2 of the paths meet your SLA for a given app, but the other 2 don’t, use those 2 for that traffic. Other traffic with looser SLAs can use the other paths). Since doing this at all inevitably involves creating hundreds or thousands of IPSEC tunnels, managing those effectively and securely (i.e. not using the same PSK everywhere for 7 years, and other such best practices) is a whole bucket of additional pain. Likewise to get failover times you to look right you’d probably want a similar mesh of IPSLAs or BFD sessions, so that’s ANOTHER big mess to handle.
SDWAN is there to do all that stuff. Different vendors succeed with different parts of that to different degrees, but that’s the general idea.
And of course a lot of what I said is “optional”. Plenty of orgs just run strict active/passive. But that’s pissing away a bunch of money, which is fine until it isn’t. Likewise plenty of folks call 30s failover times “good enough” and sure, until it isn’t. Plenty of folks half-ass IPSEC configs and again, it’s fine until someone decides it’s not anymore.
So “get better utilization out of our circuits” is one big thing you’re probably aiming for. That’s either “open up more bandwidth to users and apps” or “downsize or cut some of the circuits”. Probably the 2nd, but who knows?
Another is possibly “simplify / improve the existing situation”. Hitting all those marks without SDWAN is hard, so maybe you’re hitting them with great effort, in which case it add simplicity. Or maybe you’re missing some and the goal is to not do that anymore, etc.
Just have a plan to fully get rid of MPLS…have two internet links each branch…save more money…nowadays most public internet provided by ISP are good…
My company was an earlier adopter of SD-WAN, when we first invested in that “terminate our contract with MPLS provider” was the primary objective of the project. We replaced with broadband connections at smaller branches and DIA fiber at larger locations. 6 years later it’s gone good, but I will say there were some speed bumps here and there. We engineered it to have two different ISP at the smaller broadband branches but we found out that’s not always possible in a lot of rural areas especially if you’re using a broker to source circuits. So we did end up with a lot of branches who only have one ISP… against our original design. Sometimes there’s just no second option available at the location. We also invested in smart PDUs to remotely reboot modems because when you’re using broadband “reboot the modem” becomes a thing, and much easier for us to do remotely via PDU than to call a branch and try to walk a non tech person through it… they usually end up unplugging the wrong thing! Lastly we invested in cradlepoint cell modems for added redundancy after a few longer outages where a location ended up being down for a week. So we’ve had some bumps and bruises along the way but we were able to completely eliminate our MPLS L3VPN service. When you total the cost of all our broadband, SIM cards, and the license/support of our SD-WAN we’re still paying about a quarter of what we were under the L3VPN service. So for us it was a huge cost savings.
My experience is that most people with SDWAN throw out their MPLS quickly. They find the internet connections perform better at much less cost, say 60-80% less.
YMMV depending on what telco’s you can get, but in first world countries SDWAN over internet is the best solution IMO.
MPLS has a contractual SLA, but is expensive as all get out compared to regular DIA.
This is where SD-WAN’s “Link Monitoring” shines, you buy 2 or 3 DIA Circuits, it’ll give you 95% of the reliability of MPLS, which for many - if not most - businesses is good enough.
Yeah that is a thing but now it’s basically more cost efficient to just throw more bandwidth at it, so there are no congestion issues.
Is the separate internet used as a failover?
This very on the nose description is loaded with implications. One of the killer apps for SD-WAN is encapsulated metrics for goodput. PM data is one of the most challenging aspects of networking. It’s hard to obtain. It’s hard to read. It’s hard to manage. It’s hard to interpret. SD-WAN takes all that away from network operators and owners. It gives people an opportunity to perform metrics based forwarding. This is not an L3VPN or DIA problem. It’s a network operator problem. SD-WAN providers have done a decent job marketing this but I think it’s probably the only compelling thing about it. Otherwise it’s just another overlay.
More likely you will notice that SDWAN sends all the traffic over the DIA/internet connection because its the BEST connection.
Both MPLS and Internet services run over the same backbone today. Internet must be predictable and reliable or vendors lose money on interchange with their competitors. In fact, its a general experience in first world countries that internet is MORE reliable than MPLS because its far more resilient, far more scalable, and way more closely monitored than MPLS.
This is a really interesting use case and the question of overall spend in terms of CapEx and OpEx is not always immediately clear. If you had designed for all the components and services from the jump would you have done it? SDWAN provider and gear, PDU, cell service and gear, staffing and phone calls and MTTR measurements.
I agree. Only issue is when you have sub 30ms requirements between sites. Haven’t been able to accomplish that with cable or general internet connections.
This. Almost every SD-WAN design I’ve delivered, one if the primary goals for the customer was to eliminate expensive leased-line costs. The cost savings would quickly pay for the cost of the SD-WAN itself along with all the other benefits the technology provides.
Can confirm, this right here. DIA cost at less than half the cost of mpls. Plus significantly more bandwidth with sla on the speeds. Reduced costs and better bandwidth’s. Plus a lot of sd-wans allow local egress to the dia (direct internet access). Which allows for centralized control of branch locations public internet access.
Agreed as far back as I can remember, say 2003, we were doing OSPF over VPN on Sonic Wall with policy routes.
What’s improved is the ability to measure latency, delay, jitter, higher up the cake and the fact that we aren’t dealing with 768k DSL and 1500k Cable Modems. Also broadband is certainly available in more places. While latency sensitive workloads, on per stream basis, have remained pretty static.
I still have healthcare and financial customers that are going for private carrier networks for the guarantees.
Certainly better this then Frame Relay we were setting up back then.
But the reality is that internet links are oversubscribed in all but the most expensive tier, and nobody really needs that
That’s a narrow use case but yes, MPLS still useful for that if you can’t deplo your own DWDM or dark fibre.
I agree here. And in our environment, we have two of our heaviest use cases (our ERP and our Design software) require sub 40ms, which we cannot get over any DIA offerings.
Until now, we were forced to use remote options to accommodate this.