SD WAN can be considered a packaging of many different underlying technologies, typically tied together with software orchestration. This combination of technologies and automation enables organisations to benefit from fast, easy network operations without needing to concern themselves with all of the underlying technological details.
When evaluating SD WAN solutions for your organisation, it is important to understand your existing WAN environment along with the current and projected business needs. You should have a high-level understanding of the underlying components that an SD WAN solution consists of, as well as the different management and deployment options that are available. Purchasing an SD WAN platform, like any other technology, requires careful consideration of how your business will be impacted and potential risks you may encounter.
What is importance of traditional routing technologies?
Before diving into the business and organisational aspects of an SD WAN deployment, it helps to understand the history and components behind SD WAN architectures. We will get a little technical for this section but the information is important to your engineering / architecture teams if you are reading this from a larger Enterprise business. Where your requirements are simpler, some of this detail will be less relevant as many managed solutions are essentially plug and play.
SD WAN platforms are typically a packaging of traditional routing technologies with various proprietary software enhancements along with some form of automation and orchestration. By understanding the motivations and mechanisms, you will be empowered to make better decisions on the SD WAN platform that is right based on your specific requirements across users, applications, security, cloud, reporting and budget.
Traditional routing technologies include open standard protocols such as Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP), which are considered Interior Gateway Protocol (IGP) class, and Exterior Gateway Protocol (EGP) class protocols, respectively. IGPs such as OSPF are typically used to interconnect routing-capable devices within an Autonomous System (AS). An AS can be considered a collection of interconnected network devices under a single administrative control or authority. BGP is typically used to interconnect different AS groups together, though it is commonly used between network devices within the same AS as well.
The afore mentioned routing technologies are still very important in any SD WAN platform due to the required interoperability with non-SD WAN networking devices. For example, it is common to have SD WAN edge devices located in your organisation’s data centres where they may communicate with the rest of the network via BGP. A branch location may have an SD WAN edge device that uses OSPF to communicate with the local network and distribute routes to the datacenter.
How SD WAN relates to SDN?
SD WAN also has roots in a concept developed in the mid-2000s known as “Software Defined Networking” (SDN). Traditional routing technologies represent a fully-distributed system, where each networking device makes traffic forwarding decisions independently of other devices based on both local configuration as well as information received from other devices in the network. The original SDN paradigm changes the model of distributed control to centralised. With the centralised model, one or more synchronised controllers contain a full view of the network and program the individual network forwarding devices with the appropriate configuration.
The tradeoff between these two models is that with SDN, less operational state is held in the network devices themselves because it is stored centrally in the SDN controller (which increases information consistency), however the centralised model can create significant single points of failure. There may also be latency between the controller making a decision and the actual network forwarding devices receiving the updated information. If the network forwarding devices are unable to reach the central controller for any reason, what should they do?
The solution is that newer SDN services (including most SD WAN solutions) use a “hybrid” approach between the traditional networking and “classic SDN” models. Centralised controllers still program the individual networking devices, but if those devices lose contact with the controller (management server), they continue to operate with the last known configured state. This is a very important consideration with SD WAN in particular, since WAN links can sometimes be unreliable, which breaks constant communication.
What about NFV Network Functions Virtualisation?
Closely associated with SDN and SD WAN is Network Functions Virtualisation (NFV). NFV takes network traffic processing functions traditionally run on standalone appliances, such as routers, firewalls, and load balancers, and executes them in virtual machines (VMs) or containers on regular general-purpose computers, such as the servers in your datacenter. Standalone network appliances are usually more expensive, but also more performant.
With NFV, it is easier to create multiple smaller, less-performant instances of the same network functions (known as Virtual Network Functions or VNFs), and because the software runs on the standard Intel x86 architecture, it can be deployed in more places in the network, instead of requiring centralised placement due to cost. Many SD WAN platforms use NFV to modularise certain network functions, such as firewalls, to enable a more distributed system and create new network architectures.
Automation and orchestration
Automation and orchestration of the different software functions are what tie SD WAN technologies together into a single easy-to-use platform. With traditional networking, when a network policy needed to be implemented across many different devices, it was typical to either manually configure each device independently (which takes more time and is more prone to human error), or attempt to automate the process with customised scripts. This is also prone to error, and potentially creates a large “blast radius” if the script has a mistake or the configuration has unintended consequences.
Most SD WAN solutions have this type of automation and orchestration built-in. From an automation standpoint, the platform reduces human error by only presenting valid configuration options. From an orchestration point of view, SD WAN maintains a device inventory, and it is easy to select the group of devices to receive particular policy or configuration changes.
How to characterise your existing WAN
When planning to migrate from a traditional WAN to SD WAN, you must understand your current environment. By evaluating how your network is put together now, you can more thoroughly define and justify the Return on Investment (ROI). Your organisation may be under contract with a current WAN circuit provider, which could have implications on both selection, as well as which types of transport you can use.
Your existing WAN may also rely on older networking equipment. Sometimes the older equipment can support SD WAN with a software upgrade, but most frequently the deployment of SD WAN requires hardware replacement for each site on the current WAN. Thanks to the use of traditional routing protocols like OSPF and BGP, this replacement can be done in a phased approach; it doesn’t have to be all-or-nothing.
Deploying SD WAN is also your chance to change your functional and operational model of WAN features and management. For example, once the SD WAN capability is in place, it can typically be managed with less-knowledgeable staff due to the underlying platform automations which present a limited set of well-defined options and processes to the users.
How to determine your business needs?
Your WAN serves the needs of your organisation by maintaining connectivity between all of your locations. The motivations for migrating to SD WAN include requiring new features and functionality, supporting different underlying transport technologies (such as 3G/4G/5G), and frequently it is simply just time for a WAN refresh, and SD WAN holds the promise of easier deployment of new software features as they are developed without necessarily requiring a “rip and replace” of the existing networking equipment in the future.
One of SD WAN’s most compelling features is the ability to use multiple WAN links simultaneously. While traditional routers may support multiple links, typically traffic is only sent over one at a time. SD WAN devices or client software can send traffic over all of the links due to software extensions that are proprietary to each vendor’s platform. Link quality characteristics such as available bandwidth, packet loss, delay and jitter (variations in delay), are constantly monitored and traffic is adjusted accordingly based on policy. A common example is to automatically send all voice traffic over the link that has the lowest jitter and packet loss, even though the link may not necessarily have the most bandwidth available.
When evaluating different SD WAN providers, it is critical to know which kinds of networking technologies are currently in use. For example, many businesses use multicast for telephone paging systems or other reasons. Not all SD WAN platforms support multicast. The sales team of any particular SD WAN platform may tell you that missing features like multicast are “on the roadmap” but are frequently hesitant to give an exact timeline.
Your organisation may be using a niche technology that is unlikely to be developed for a mainstream SD WAN platform. You may have to make the decision to migrate away from an uncommon or proprietary technology in order to use SD WAN. Mainstream platforms are going to develop features for the most common use cases that will appeal to the largest number of customers first. This may be an issue if you are running non-standard applications or network features.
How to view the managed services deployment approach?
SD WAN services have different deployment models. Some platforms are available only to managed services providers and require you to partner with them in order to use the platform. Other platforms require you to install and manage everything yourself (similar to a traditional deployment model), though managed service options are also typically available for these particular platforms.
With a managed service, you can choose a provider that will handle as many of the details as required. Managed Services Providers (MSPs) can provide a “zero touch” deployment where they handle installing, configuring, and maintaining all of the equipment as well as handling the ordering and provisioning of the actual WAN circuits for each location. MSPs can also work with you to provide the level of control that you need. For example, the MSP can enable access to the SD WAN platform so that you can make policy changes to reflect your organisational needs at will, instead of requiring the MSP to make the changes for you.
A key consideration of the MSP approach is trading responsibility for control. The MSP is contracted to handle the details for which your business doesn’t have either the time or technical skills to manage. The MSP can also act as insurance for your project, since you will have a path of remediation if things do not go as planned during deployment. This is a primary advantage of the MSP approach.
What if you need wires only unmanaged SD WAN?
Self-Deployment is the other popular model. With this option, your IT team handles all aspects of the SD WAN service, including procuring WAN circuits at each of the locations, installation and management of upgraded hardware, and all configuration aspects from design to actual deployment. This deployment model is appropriate for organisations that have very specific needs along with in-house staff with the necessary technical skills to support the rollout.
That’s not to say self-deployment is only applicable to very large Enterprises. Smaller businesses who either have simpler requirements or have technical staff are able to make use of the self-deployment model as well, and are likely to save money by doing so. The biggest advantage of self-deployment, other than potential cost savings, is that your IT team maintains complete control over everything.
For large Enterprise business with many remote locations, management of all the WAN circuits can be a full-time position unto itself. If you decide to handle everything yourself, you must be aware of the different access methods available for each location, and whether your bandwidth requirements will be met. For example, a particular location may only have slower DSL broadband readily available to them, but they have a requirement to transfer large files across the WAN. You would most likely have to look into more expensive fibre-based Direct Internet Access (DIA) lines, or a point-to-point Line of Sight (LoS) wireless connection, if available. An MSP should discover and present these kinds of issues to you, whereas when you perform a self-deployment, it is incumbent upon your IT team to realise this issue.
Is SD WAN right for you?
SD WAN opens new opportunities for organisations to have a more robust, agile WAN and potentially break away from being tied to a single service provider for all of your WAN circuits. Having underlying network transport independence makes it easier to customise your WAN environment for each location’s specific needs. Understanding the history and motivations behind SD WAN helps you make appropriate decisions.
One often discussed area surrounds QoS (Quality of Service) which offers the ability to prioritise traffic. In this article, we’ve mentioned how SD WAN is an agnostic technology; able to terminate any connectivity type. However, many vendors are marketing software WAN services as the Internet VPN v2. With this in mind, and while SD WAN offers some fairly sophisticated traffic treatment abilities, end to end QoS over the Internet is not possible. And this is perhaps the biggest reason why an MPLS VPN remains a component of Hybrid WAN architecture. If clients require strict traffic priority between mission critical sites, MPLS remains the only true guaranteed option. If your vendor of choice is ensuring your architecture is Hybrid WAN based, an SD WAN device with MPLS offers serious functionality with a significant SLA upgrade vs the Internet.
You will have a more successful SD WAN deployment if you carefully examine your existing WAN environment along with present and future technological needs. Be wary of SD WAN platforms that do not support technologies that your business relies on, or vendors who provide only vague promises of upcoming feature support. Finally, when evaluating SD WAN, take into consideration the tradeoffs of managed services versus self-deployment. Realise deployment options run a full spectrum, and there are businesses who can provide as little or as much support as your organisation needs for any SD WAN deployment model.