SD-WAN resources\n\n What is SD-WAN and what does it mean for networking, security, cloud?\n 10 SD-WAN features you're probably not using but should be\n SD-WAN may be the key to smart network services\n SD-WAN and analytics: A marriage made for the new normal\n Native SD-WAN monitoring tools are not enough, survey says\n\n\nWhy 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? is a technology like that, and because all SD-WANs aren\u2019t the same, or even close to the same, you\u2019ll have to do some digging to make SD-WAN your own.\nSD-WAN overhead\nAlways 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.\n\nThose 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.\nIt\u2019s 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.\nPrioritizing packets\nThere are other ways that SD-WAN performance can be affected by features most prospective users don\u2019t 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.\nMost 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.\nIf you have specific reasons for selecting an SD-WAN that has higher header overhead or one that can\u2019t prioritize as you\u2019d like, you can reduce the impact of both these issues by using access links with higher bandwidth if they\u2019re 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.\nThat also goes for security.\u00a0 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.\u00a0 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.\nAdd-on application and relationship awareness can be helpful, but it\u2019s 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\u2019s really nice if all these features work together, and that\u2019s not always going to be the case.\nSD-WAN-off-ramp performance\nAnother often-hidden issue in SD-WAN is how traffic gets off the SD-WAN overlay and into the data center.\u00a0 Remember the \u201cwhat goes up must come down\u201d 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\u2019d 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\u2019ll need and what you\u2019ll have to run them on.\nManaged service or roll-your-own?\nThe final question to consider is, \u201cHow am I going to manage this stuff?\u201d If you\u2019re struggling to staff your network ops center with skilled people, imagine how you\u2019ll 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.\u00a0 The recent acquisition of MSP Masergy by Comcast shows that managed SD-WAN options are growing and changing, so check them out.\nYou may think you want to buy an SD-WAN, but you\u2019re wrong. You want to buy your own SD-WAN, one that fits all the requirements you have, even those you\u2019ve not really thought about. Researching requirements versus features up front can save you from an expensive, disruptive, mistake.