I’ve been doing VPN since it was a brand new idea, and not enterprise-y enough for a real company. I’ve been dealing with WANs since Frame Relay was still a neat idea.
Today I find out the new office I’m bringing online this week will not be part of our MPLS network, but instead use a “Software Defined WAN”.
My question is when did they change the name, and how much less expensive would it be of they still called it a VPN?
I just completed our migration from old MPLS to SD-WAN, and in day to day operations, they achieve the same idea, connecting multiple sites together, but being able to have 3 different carriers connected to one router, and having all 3 links concentrated and actively monitored to push specific traffic to one with better conditions, not having to pay for MPLS management, and having a proper cloud based management portal for all sites is pretty decent.
Similar to older Cisco hub and spoke DMVPNs in a sense. But the VMWare VeloClouds have been fantastic so far.
Are routers just a computer with a few extra ports and some specific software?
Are robots just garbage cans with sparks comin’ out?
While I agree that sdwan has been over sold and fluffed to basically devoid most meaning there is a benefit in not equating the two as there are some distinctions.
SDWAN encompasses site-to-site VPNs, automatic failover, policy/performance metric based routing, etc. etc. It is however a fancy marketing term for what IT should have been doing all along though. The first time I heard someone raving about SDWAN’s benefits and features all I could think to myself was “that’s what we’ve been doing for a decade.”
it actually isn’t quite that simple - i used to think the same.
hypothetically - an sd-wan configured correctly is a fantastic thing. i think i’ve only seen a “correctly” utilized sd-wan a few times. everyone else just uses them for vpn.
so an sd-wan (as it has looked to me) should utilize a minimum of 3 WAN links and. the logic in an sd-wan config is to create different routes for your traffic to go in case something messes up on one of the links. there is more but this was the thing i remember seeing and witnessing some cool recovery when different isps gave out and whatnot. was very seamless
Does your Site to site VPN do per packet path selection? Does your VPN do FEC to send VOIP out two connections to survive >50% packet loss with no missed packets on the receive end?
Can your site to site VPN not drop a single VOIP packet or restart any flows if someone yanks a link out?
Does your VPN allow you to break out services locally based on L7 rules yet backhaul those to HQ if a commodity connection goes offline?
Does your VPN allow a single “Rule” change to effect all devices in all branches with a few clicks?
There is quite a bit more to SD-WAN than the underlay VPN tunnel. Some people just need VPNs, and that’s fine. My silverpeak’s are worth every penny.
Last time I heard someone say they wanted SD-WAN it was because they no longer wanted to configure the Firewall or CoreSwitch via a terminal connection or command line. They wanted a full GUI where they can move things around like it was Minority Report.
I think Palo Alto has the best understanding of SD-WAN. P.S. Palo Altos are worth the money.
A software-defined wide area network (SD-WAN) is a virtualized service
that connects and extends enterprise networks over large geographical
distances. WANs use links such as multiprotocol label switching (MPLS),
wireless, broadband, virtual private networks (VPNs) and the internet
to give users in remote offices access to corporate applications,
services and resources, allowing them to work regardless of location.
SD-WAN monitors the performance of WAN connections and manages traffic
in an effort to maintain high speeds and optimize connectivity.
SD WAN was meant to take expensive mpls connections out of the equation as a vpn over sdwan can be faster and have multiple failover links. Whereas an mpls has a defined pipe. Costs lots to grow that pipe in certain markets and sometimes only uses a single link with a single point of failure.
However sdwan has become a buzz word of sorts. It was meant to be a defined grouping of wan links that operated interchangeably with traffic flows being unaware of the underlying connection.
But to be fair here SDWAN is not just VPNs, thats just the underlying technology. What you can do with a modern router + IKE + BGP you can do with most SDWAN appliances, as they use weighted routing, path selection, session weight/watching for TTL, and latency control. SDWAN just tries and automates all of that.
Fun fact, Fatpipe was the first “SDWAN” and that was in 2007. It would take 2+ devices with 2+ ISPs and bond them together with all the same shit SDWANs use today.
SD-WAN is a marketing term, not a technical term. If it was a technical term all the vendors would have the same defintion.
On Fortinet, SD-WAN means a combination of multiple internet connections and application-aware policy routing (eg. Netflix goes out that connection, Microsoft traffic goes out a different one).
Meraki has the same definition. However in Cisco land, despite owning Meraki, SD-WAN appears to be mean everything and anything from zero-touch deployment to “using Webex” and everything in between.
On Juniper, SD-WAN means the application-aware multi-connection routing thing. Unless you’re talking about their NFX devices, in which case it means being able to run VMs on your so-freaking-expensive-you’ll-never-buy-one router. They also have SDN offerings for their switches that they tend to confuse with their “SD-WAN” offerings.
Right about the time when vendors figured out management was dumb enough to switch to a continuous revenue model where you paid per bandwidth if they called it software defined anything.
FWIW, true SDWAN usually has a little bit more going on than “just an IPsec vpn.” I’m not quite as crusty as you (dodged Frame Relay), but my last job did have a lot of T1s sprinkled all over the place.
I’ve had a lot of experience with Velocloud; they do forward error correction, some light L7 QoS, packet duplication over multiple WAN interfaces… lots of “special sauce.” The cool demo was to have a VoIP call going across the WAN, and you could just yank one of the upstream connections, with absolutely no impact on the voice call.
Job[-1] was able to save tens of thousands by dropping MPLS/EVPLS circuits, ending costly local PRIs, backhauling most voice to corporate (and using SIP outbound from there) and just using multiple “commodity” connections plus Velocloud. Savings were still that large even factoring in the MRC for Velocloud itself. This was a company spanning 6 states with north of 120 locations.
Holy hell reading this thread is like “Tell me you don’t keep up on emerging technologies without telling me you don’t keep up with emerging technology”
Sure SDWAN does a bunch of things that already existed, but they existed seperatley. It rolls them into one product, has superior link managment, link analytics, link aggregations, next gen firewalls, Software defined auto VPN’s, provide a useful GUI (not everyone has the time to learn everything about a systems CLI), dynamic traffic routing, provides a lot of the benefits of costly MPLS lines but is able to utilize multiple cheaper consumer lines. And so much more stuff.
Have fun configuring and maintain 50 different systems for all that stuff when you could use it in 1.