Tailoring SD-WAN to fit your needs

Why is it that we always seem to think that we can adopt a technology that has seriously revolutionary pieces by just buying it and hooking it up? This, despite the undeniable fact that everything in tech is getting more sophisticated, more complex? Software-defined WAN is a technology like that, and because all SD-WANs aren’t the same, or even close to the same, you’ll have to do some digging to make SD-WAN your own.

SD-WAN overhead

Always start with the top, or over it, in this case. The original mission of SD-WAN was to connect small sites to the corporate VPN, sites where traditional MPLS VPNs are either too expensive or not available. SD-WANs all work by creating a routing overlay, a kind of network above IP. SD-WAN software and appliances usually do that by adding a virtual-network header to the IP packets. The size of this header depends on the specific implementation, but it can add anywhere from a half-dozen to several dozen bytes to packets. SD-WAN devices route based on the overlay header addresses, and since these addresses can be from the same address space used by the MPLS VPN, the SD-WAN effectively adds its sites to the company VPN.

Those SD-WAN headers are rarely an issue with business applications, but they can create challenges with applications that generate especially small packets. VoIP packets are about 200 bytes long, so a 12-byte SD-WAN overhead, for example, would increase it by about 6%. IoT packets can be much smaller, between 30 and 50 bytes, so the same header size would increase packet size by between 24% and 40%. Since an increase in packet overhead has the effect of reducing effective connection bandwidth by that percentage, this can mean that small sites with limited broadband capability could see their speed further reduced by overhead.

It’s important to ask prospective SD-WAN vendors about this overhead and also about just how they route packets. A very few SD-WAN vendors add their routing header not to every packet but to every session between users and applications, which adds the least overhead of all. So get accurate data on whether sessions or packets are routed, as well as what overhead is added, to make an optimum SD-WAN selection.

Prioritizing packets

There are other ways that SD-WAN performance can be affected by features most prospective users don’t even consider. Voice, video, and some IoT applications are likely sensitive to latency, and that can vary if traffic is heavy and packets back up at the source. Some applications are more critical than others, and many users would like to let these applications jump the line and get sent before other lower priority packets. Prioritizing packets is a feature of some SD-WAN implementations, but how effective it is will depend on how effectively specific applications can be identified for prioritization.

Most SD-WANs simply look at packet types or maybe TCP/UDP port numbers, which assumes that all voice packets or all packets for a particular application have the same priority. In many cases, users prioritize specific worker-to-application relationships, not all users of a given application, so prioritization may offer less value than you think.

If you have specific reasons for selecting an SD-WAN that has higher header overhead or one that can’t prioritize as you’d like, you can reduce the impact of both these issues by using access links with higher bandwidth if they’re available. If not, and you need to use access bandwidth efficiently, then take the time to assess your vendor options in light of the overhead and prioritization issues.

That also goes for security.  If an SD-WAN can recognize specific worker-to-application relationships, it can not only prioritize the important ones, but also recognize which of all the possible worker-to-application relationships are actually permitted. That means that the SD-WAN can actually create better security.  Some SD-WAN implementations include this level of relationship awareness, and others may add on a security layer to provide these features. This is what secure access service edge (SASE) technology adds, for example.

Add-on application and relationship awareness can be helpful, but it’s important to find out what you can do with that knowledge. For example, an additional application-awareness or SASE feature may improve security, but can it influence prioritization, or be used to pick a different route for an SD-WAN packet to avoid congestion? It’s really nice if all these features work together, and that’s not always going to be the case.

SD-WAN-off-ramp performance

Another often-hidden issue in SD-WAN is how traffic gets off the SD-WAN overlay and into the data center.  Remember the “what goes up must come down” saying? What goes onto an SD-WAN has to come off at the point those small sites are trying to connect with, meaning the cloud or the data center. SD-WAN implementations vary enormously in the performance of these off-ramps, and performance limits mean you’d need a bunch of off-ramp elements to carry all the traffic. That adds to cost and operational complexity, so be sure you know just how many off-ramp elements you’ll need and what you’ll have to run them on.

Managed service or roll-your-own?

The final question to consider is, “How am I going to manage this stuff?” If you’re struggling to staff your network ops center with skilled people, imagine how you’ll struggle to get even minimally knowledgeable on-site staff to help fix problems in those small sites you just connected. Management features are very important for SD-WAN success, and even they may not be enough for some international SD-WAN applications. You may want to consider getting your SD-WAN from a service provider or managed service provider (MSP) rather than buying hardware and software and rolling it out on your own.  The recent acquisition of MSP Masergy by Comcast shows that managed SD-WAN options are growing and changing, so check them out.

You may think you want to buy an SD-WAN, but you’re wrong. You want to buy your own SD-WAN, one that fits all the requirements you have, even those you’ve not really thought about. Researching requirements versus features up front can save you from an expensive, disruptive, mistake.