In technology, we are surrounded by acronyms and buzzwords. One that gets a fair amount of utterance in the market today is SD-WAN. Software Defined Wide Area Networking services promise to give network engineers and architects more control over their networks. SD WAN implementations vary, of course in what they can do, but many enterprises use SD WAN to “glue” together a multitude of different connectivity types and make them work more seamlessly together.
SD WAN is an outgrowth of SDN technologies that became the rage around 2011. Software Defined Networking, put simply, is separating the control plane and data plane of our networks. It allows smaller, less intelligent (and cheaper) network devices to be controlled by compute and configuration mechanisms that are centralized and homogenized across platforms.
How to define the business case for SD WAN?
1. Cost savings are a possibility using SD WAN services and Internet connectivity.
2. Flexibility and agility mean a faster setup and support for small and remote offices.
3. Security is available for all connectivity types.
4. Hybrid networking is a reality with SD WAN devices using Internet, MPLS, VPLS or private circuits.
5. Cloud applications are available easily across public connections secured by SD WAN.
The promises of SD WAN were many. Cheaper, more agile.These cheaper, lighter network devices serve as the “data plane” simply storing a minimal config, and forwarding packets as fast as possible. The SD WAN controller (control plane) may be anything from an appliance, to software running on your own VM infrastructure. It might even be on compute nodes in the cloud somewhere. There are a variety of SDN implementations on the market, and they all work somewhat differently, but that’s a basic high-level overview.
The promises of SDN were many. By asking multiple vendors to come to terms with a common management API, the SDN standards would allow single “management panels” to control devices from multiple vendors consistently. It would even simplify how we control devices by the same vendor, but across multiple platforms. By providing a single, shared management API, we could dramatically simplify how we automate network provisioning tasks. By simplifying automation, we could now dramatically speed up provisioning times. This means we can react more quickly to user needs, we can steer traffic to new links more quickly when congestion occurs, and we can deploy new network services much faster to meet new demand.
For the above reasons and others, SDN gained traction in its first 5 years, but primarily in the datacenter. Large cloud and datacenter operators like Google, Amazon, Facebook and others adopted SDN early on and saved large amounts of money. They saved money both on hardware, and on better automation tools. About two years ago, WAN operators began to take notice, and SD WAN implementations began to find their legs.The features and functions of SD WAN solutions are similar to SDN solutions, although a WAN engineer might apply them a bit differently. Many of the core concepts exist, you’re going to deploy cheaper, lighter network devices at your branch offices or at the edge of your provider network. You’ll use some sort of “single pane of glass” management system to manage these devices in a uniform, predictable way. A standardized API means that there are ample opportunities for automation. You can use your “single pane of glass” to rapidly deploy new edge devices. All you will likely need is the IP address of the new device and you can push a full configuration template onto it almost instantly. Once you understand a little about what SD WAN is and what it does, the business cases begin to become clear.
Let’s examine just a few. Let’s suppose for a moment that you’re an enterprise with a large, established network of MPLS services between branches. Because of recent growth (in SaaS or cloud services), you’re faced with almost half of your branches needing large bandwidth upgrades. We know that every megabit/s on the MPLS circuits means money, so it would be great if you could utilize cheap, readily available Internet connections in those locations. The right SD WAN solution can allow you to use cheaper commodity bandwidth at these locations, while still preserving the MPLS circuits for intra-enterprise, mission critical applications. Most SD WAN solutions allow you to easily configure some rules to allow “steering” some types of traffic onto one connection, while sending everything else out the other. You can also deploy the appropriate security rules out to that branch to make sure that Internet bound traffic is secured and your users are safe from the dangers of that “direct” internet connection. You simply deploy your SD WAN CPE out to that branch, plug it into both connections and begin provisioning.
Or maybe your organization is coming to the end of some MPLS circuit contracts. As you’ve moved a lot of your internal applications to the cloud, your need for some of these “dedicated” circuits is waning. So perhaps you’re considering a shift to a mixed environment where some branches use commodity connections and others stay on the MPLS network. If you do this, you’ll likely be getting the commodity circuits from many different providers in different cities. You’ll probably be looking at different connection types as well (cable modem, direct fiber, DSL). This sort of diversity will likely leave you wondering about a mixed bag of CPE, and how you’ll manage the complexity. If this is the case, you should explore SD WAN solutions. The standards based, connection-agnostic nature of the SD WAN CPE means you can likely just deploy the same CPE across all connection types and dramatically simplify your management landscape.
Another case for SD WAN can be found in the flexibility and agility it can give to your enterprise. If you choose to use SD WAN and start taking advantage of those commodity connections, you can respond more quickly than before. Commodity Internet connections typically don’t require the long-term contracts that come with some legacy circuit types. So you can now deploy new branch offices more quickly. You can also set up temporary branches for seasonal offices like tax preparers (or pop-up offices for remote workers) with very little effort. You can also change those commodity connections when a better offer from another local provider comes along. Remember that the connection to the branch is a virtual network overlay. It really doesn’t matter that the (provider) external IP address changed. All of the same policies, security restrictions, and rules for the branch will be exactly the same after the switch. This virtual overlay makes these sorts of connectivity changes essentially transparent to your users and to your enterprise.
Finally, if you are at the end of an equipment lifecycle, and you are considering replacing your branch office CPE across the enterprise. In the older scenario, CPE at each location most likely had to be a branch router with enough brains and power to be a router, firewall, IPSEC endpoint, and perhaps serve in other roles as well. Those extra features add a LOT of cost when amplified across dozens or hundreds of devices. Considering a switch to an SD WAN solution at a time like this can save you a ton of money on that branch office CPE. You have a wide variety of SD WAN CPE to choose from (sometimes referred to as uCPE or vCPE depending on its feature set and intended use), and you can be sure there is a solution to fit your small branches, and large branches alike.
It’s true that for the first several years of development, SDN grew and matured in the datacenter. However, the time has come to consider it seriously for helping to manage your Wide Area Network as well. There are now a number of vendors on market and a number of mature solutions to choose from. More importantly, the business cases for SD WAN are growing by the day.
