The Case for SD-WAN
March 2, 2016 Leave a comment
• Your organization may be in the minority that won’t benefit from SD-WAN products replacing your existing WAN infrastructure, but for everyone else, there’s significant upside to moving to SD-WAN sooner rather than later.
• Algorithms in SD-WAN products rationalize competing demands such as current conditions and your pre-defined requirements to optimize application performance. Let go and get on with your day.
There are too many times when I see a technology and think, “Yeah, I want to buy that.” I’m talking technology, not products, in this note. SD-WAN is one of those technologies that I think has so much upside that no matter what product you pick the result will be far and away better than what you have, in particular for interconnecting remote sites. I’m not entirely convinced of the efficacy of SD-WAN for inter-data center connectivity. The key feature is operational simplicity when compared to how inter-office connectivity is achieved today.
Naturally, SD-WAN isn’t for everyone. If you have a particular requirement that can’t be met with SD-WAN products or you really like the job security complexity the status quo brings to the table, then SD-WAN products won’t be useful but in either case, I’d think you’d be in the minority.
What’s this operational simplicity? Simply stated, SD-WAN products consolidate a number of other technologies like physical link load balancing, firewalling, VPN, granular access controls, application identification and classification, application performance managed quality of service, centralized management, easy deployment, and in-depth reporting in to a single product that integrates those functions into a cohesive and consistent whole. When making a decision to place traffic on the most appropriate link, SD-WAN products combines what it knows about current conditions such as latency, jitter, and packet loss of each WAN link between two points connected over the SD-WAN with any preferences or requirements for applications to use one link over another, the type of application and its performance requirements.
For example a policy might state that VoIP should go over the WAN link with the best performance characteristics but the interoffice MPLS connection is preferred. Meanwhile bulk file traffic can go over any WAN link but the high speed broadband link is preferred. Based on current conditions, the SD-WAN gateway makes a decision on which WAN link to place traffic based on current conditions and the policy. Of course, if you require WAN traffic always go over a particular path, you can also have a policy statement that says VoIP traffic will always use a particular WAN path and the SD-WAN gateway will make decisions around that requirement. SD-WAN products encrypt the WAN traffic by default but that could also be disabled if needed or desired.
Rather than defining all the parameters and options to make your network run optimally like the way you do today, you define the general requirements in a policy you require like user, device, or location isolation, application performance requirements and so on and then take advantage of the automation within the product to manage the network for you. Ok, ok, that last sentence contained lots of hand waving but the general idea is that you define what you want to see and the SD-WAN product does the dirty work. You can do this today by configuring link load balancers, routers, firewalls, VPNs and other network devices but that’s not very versatile or flexible.
The particular SD-WAN capabilities will vary by product, of course, and enterprises will need to perform their own analysis matching features with requirements, but in general, administrators end up spending less time babysitting interoffice connections and more time on other productive work.