People often tell us they struggle to clarify the benefits they could expect from SD WAN, and how they might achieve them in their particular situation. This makes it difficult to develop a case to adopt it.
Much of the material on SD WAN has been written by vendors for global enterprises, with relatively little for businesses consuming managed networks and covering a more regional or national footprint. This guide fills some of that gap, outlining in simple terms a number of SD WAN benefits, and how they’re achieved.
For this guide we have assumed that you are
In this context, we’ll consider how an SD WAN network would compare technically, operationally and commercially to your traditional WAN. We won’t try to turn you into an expert practitioner; just surface a number of SD WAN benefits in a single place.
A word about the cost benefits of SD WAN …
A newcomer reading about SD WAN over the last few years could have been forgiven for thinking that the rationale for deploying it was to reduce costs. The vision of a global enterprise moving traffic away from MPLS onto the internet is one of the most frequently cited scenarios, and one in which a business could indeed expect to save money.
So, we have focussed this guide initially on those wider benefits (while noting that many cost saving opportunities are just the flip side of the benefits we have covered here). You can see some specific cost reduction examples in our ‘SD WAN circuit cost-reduction illustration’.
This guide is arranged into three sections:
SD WAN can deliver a wide range of benefits across performance, deployment and in-life management of the WAN. We have provided details below for how each of these benefits are derived. To start, here is a list of the key benefits.
SD WAN can:
Traditional networks frequently employ backup circuits for important sites, and these are often employed in passive mode; switched in when the main circuit fails. Intuitively we can see that it is inefficient (and thus costly) to have one circuit sized for the total traffic requirements of a site and another not used at all in normal circumstances. This is especially so for resilient circuits where the backup circuit matches the bandwidth of the active circuit bandwidth.
How does SD WAN help?
Well, for sites with more than one circuit, SD WAN makes it easier to use both circuits actively, rather than having one active and one passive. Since both circuits are now being used, the site enjoys greater bandwidth and better performance (or alternatively the port speeds could be lowered to reduce cost).
So how does SD WAN make it easier? Or to put it the other way around: why is it more difficult to use both circuits in a traditional WAN?
Well, a traditional WAN can indeed use both circuits, but generally it’s a case of Application 1 using Circuit 1 and Application 2 using Circuit 2. If Circuit 1 is congested then Application 1 doesn’t use Circuit 2, it just drops packets. Or it could be that one set of users uses Circuit 1 and another uses Circuit 2 although this is unhelpfully splitting the network.
There is no intelligence to the way that a traditional MPLS or Ethernet WAN uses dual circuits. It blindly follows configuration rules, rather than determining the best path end-to-end based on parameters that have been set. Site routers are generally set up in an Active/Passive configuration with the Passive circuit only being utilised in the event of a failure of the primary.
SD WAN, on the other hand, will happily use both circuits actively, will consider all of the bandwidth available and monitor spare capacity, therefore using the available bandwidth more intelligently.
Alternatively, the ability of SD WAN to use both circuits gives the option to halve the bandwidth that would otherwise be required on a single active circuit. This should produce cost savings, although it will result lower available bandwidth while one of the circuits is down. We have illustrated potential savings in our SD WAN Cost Illustration.
With SD WAN, each application can be given its own Service Level Agreement (SLA) with conditions that determine the routing for that particular application. This allows you to maximise the performance of your high priority, performance-sensitive applications.
In more detail, a ‘Business Intent’ can be set up for an application(or group of apps). This is a set of rules that reflects what the business wants to happen in different situations and includes the SLA. It could be set up to use any available bandwidth as long as it meets the SLA requirements of the application; or set up always to prefer to use a certain circuit. For voice, it might be set up to use all circuits at the same time. The Business Intent then drives the use of the underlying network in real time to achieve the SLAs identified for each application.
CAVEAT It probably goes without saying that for SD WAN to make real-time changes to the routing of your application traffic, it needs more than one route to choose from. Thus, you will need at least two circuits to your sites. These might be MPLS, VPLS, Fibre Internet, Broadband Internet or 4G connections. If you have only one connection, SD WAN will still give you greater end to end visibility of the performance of that route.
Contrasting with this flexible routing, a traditional WAN will only route differently on the loss of a route, not when that route is merely underperforming or congested.
This brings us onto the discussion of ‘Brown outs’, which refer to the degradation, rather than loss of a connection.
SD WAN can use a number of techniques, such as Path Conditioning, dynamically to overcome these issues.
On ADSL we expect more frequent brown outs because of the nature of the circuits, especially on long lines. Since only traffic that is tolerant of performance degradation would continue to use the circuit, it’s wise to not have two ADSL circuits to a site if it is a long way from the nearest exchange.
One point to note here though is that unless the performance is reviewed, SD WAN could be masking a problem with the underlying network by routing around it. Of course, depending on your point of view, you might see this as a positive as well as a negative!
SD WAN can improve the performance of unstable links, which is particularly useful for voice and for allowing global sites to use local broadband.
Some vendors can overcome the performance issues of the underlying transport rather than simply routing traffic around the problem. This ultimately provides better resource utilisation, higher application performance, improved productivity, a better user experience and lower bandwidth costs.
SD WAN can send voice packets down multiple links to overcome any packet loss on an individual link. We’ve been using this for years on our 4G WAN replacement circuits, to make reliable circuits out of multiple 4G connections.
Some vendors use techniques such as Forward Error Correction and Packet Order Correction to avoid having to re-transmit packets. Forward Error Correction injects loss recovery packets to fix problems at the far end, and Packet Order Correction re-sequences packets at the far end. These Path Conditioning techniques reduce the number of packet re-transmissions required and allow you to achieve call quality on slower and less reliable connections.
Key Point: However, you need to consider that not only do broadband circuits have lower performance and stability than ethernet based access circuits, they also have poorer fix times when they do fail. While an Ethernet circuit might be fixed within hours, a broadband circuit’s fix-time SLA is usually measured in days.
A cynic might argue that SD WAN vendors are promoting a cheaper and poorer performing access circuit but then offering to fix the problem they’ve created! However, it is certainly the case that SD WAN gives you more options to select the most appropriate compromise between performance, reliability and cost.
SD WAN creates End to End tunnels and has an awareness of the multiple tunnels that might be on the SD WAN device at each site. This allows the devices to manage the data that is being sent.
A traditional WAN can have Class of Service (CoS) on the router, but the router isn’t aware what other devices are doing, meaning that a video call between Site A and B could be interrupted by a large file being received from Site C.
With SD WAN, the Business Intent Overlays are set up to maintain the performance of an application. If the network isn’t congested and the end to end SLA meets the applications criteria, then the prioritisation doesn’t need to be applied. However, if the network is contended then the SD WAN devices can prioritise the applications as defined in the Business Intent Overlays. It can send a message to the other devices in the network that Application X is to be prioritised and other traffic needs to be limited.
We discussed above that SD WAN employs path conditioning and real time application routing to improve application performance over the internet. This also works for MPLS, which means that SD WAN could let you dispense with running CoS on an MPLS (or indeed a VPLS) network.
How does this help?
Well, to start with, it reduces complexity. CoS adds an extra layer of complexity to set up, and we’ve seen instances in the past when it’s not been deployed properly anyway. If you have multiple MPLS suppliers then there may be different classes used for different purposes. And if you have a mixed network with layer 2, then you’ll be using different markings again for quality of service. With SD WAN and no CoS then performance is set up consistently across all network types.
Secondly it puts application performance into your hands and makes it quicker to make changes. Setting up and changing CoS is done via the Carrier, which means that you have to request it, await their changes and then have the routers configured. With SD WAN it’s a simple process to make a change across the whole network.
Thirdly, it can save cost, which we’ll explore in our SD WAN Cost Benefit Illustration.
Often when a remote site has an MPLS primary and an Internet broadband back-up, the backup is only used when the primary fails and then just creates an IP Sec tunnel to the HQ.
Many companies are either hosting their applications in the cloud or are using cloud-based Software as a Service such as Salesforce or Microsoft Office 365 (MS365).
If all traffic has to traverse a central firewall at the HQ/DC then not only does this require more bandwidth at the HQ/DC to trombone the traffic in and out but it also adds more latency meaning poorer performing applications.
With SD WAN the remote site can access MS365, for example, directly via the Internet connection. This will provide a shorter path to the application, meaning improved performance. Secondly, it will remove traffic from the MPLS connection, which potentially can contribute to a smaller port and therefore a cost saving.
However, if the performance of the local internet circuit deteriorates and the application SLA is not being met then the network can look at the SLA performance of routing the traffic via HQ/DC and decide whether to route that way instead.
There is a further option to access cloud platforms such as AWS and Azure. That is to have private cloud connectivity from your network.
This would be a third way for the branch site to reach the IaaS platform and it may well have a better SLA than the local Internet break-out. It will depend on geography - which region the Branch site and the IaaS platform reside in. This is usually our preferred method for connecting to Cloud platforms; providing cost effective, high performance through the SAS Gateway.
A traditional WAN typically sends all external traffic to the corporate firewall, which has increasing performance implications as more applications are run from the internet.
SD WAN can treat known applications such as Microsoft 365 and Salesforce as trusted, and route them direct to the internet or to a web proxy such as Zscaler or Cisco Umbrella. This can reduce latency because there are fewer hops. It also allows you to reduce the firewall capacity and also the bandwidth required from the Corporate Firewall.
SD WAN vendors can predefine SLA requirements for known applications, which makes it easier to set up a business intent for them. Silver Peak, for example, recognises over 10,000 Apps for which it has already defined SLA requirements, and uses its ‘first packet IQ’ feature to recognise the traffic from the first packet and route it accordingly.
Not only can applications be routed differently, but also groups of users can also have different policies applied.
Consider two users, one on the guest Wi-Fi, one on the corporate LAN, both trying to get to the same website. The SD WAN router can send the Wi-Fi user’s traffic out to the internet and the Corporate LAN user’s traffic to the Corporate Next Generation Firewall.
Similarly, in a retail environment, Point of Sales devices can be within their own Business Intent. If this is attacked, then the traffic can’t access other parts of the network.
This is possible on a traditional WAN using VLANs, but it is more difficult to configure.
SD WAN uses URL and DNS to keep updated with changing IP addresses for applications such as MS365.
By using the URL and DNS, any update to the available ranges of IP Addresses will automatically be known to the SD WAN device.
With a traditional WAN, one has, periodically, to update the IP Addresses that the firewall will allow inbound traffic from; otherwise it may block MS365 traffic.
Not only does SD WAN do this automatically but it does it instantly.
SD WAN vendors such as Silver Peak and Meraki can improve the performance of applications in a cloud environment such as Microsoft Azure, by being able to deploy a licence within the Infrastructure as if it was a piece of hardware on a site. This allows them to consider both ends of the connection rather than just one.
Customers who run standard Internet access to the virtual network alongside Azure ExpressRoute can benefit from Dynamic Path Control (DPC), a feature that enables simultaneous use of multiple underlay transports (e.g. both ExpressRoute and Internet). This allows you to maximise availability, throughput or efficiency, according to the requirements of the application.
Consider a global network which has 10 sites across Asia needing to access a few applications in your HQ. The latency on those links might mean that the applications don’t work very well. High packet loss might mean that the applications are taking up more bandwidth than they need to.
WAN optimisation can increase throughput by overcoming TCP Windowing (which restricts an individual data flow). It can reduce the demand for data by caching and other methods.
However, with a traditional WAN, separate WAN Optimisation devices would need to be bought, configured, installed and maintained which could make it cost prohibitive for this scenario.
SD WAN allows you to deploy WAN Optimisation purely as software, avoiding these issues. Furthermore, the licence can be apportioned and moved from site to site as needs change, with very little difficulty.
In the example above, a Silver Peak 100Mbps Unity Boost licence would allow 10 Mbps of optimisation at each site and would cost about £4k per annum to improve the performance for all the users at these ten sites.
With SD WAN, key rotation is controlled by the orchestrator whereas with a traditional WAN using IPSEC, this has to be configured on a hub device and has limitations. It's simpler and more flexible with the SD WAN.
SD WAN brings a number of benefits to the deployment of a WAN. If you are a large enterprise managing your own WAN then you should see these benefits directly. If you have bought a Managed WAN then it is likely that your service provider will see them. Nonetheless, it is to be hoped that you would enjoy a better service as a result.
SD WAN allows you to design a template up front, and then have each site deployed using the template (with adjustments for IP Addresses). Devices therefore don’t need to be physically staged, or at least require minimal staging.
With a traditional WAN templates can still be used but they are kept as text files, which can take longer to create and can be misused.
With a traditional WAN, different routers have different Command Line Interface (CLI) commands; making templates more difficult to create. Also, there are many ways to achieve the same result, meaning a lack of consistency to configuration templates.
We periodically hear from businesses who have experienced mistakes in network deployment. One of the drivers for these mistakes is the inconsistent production of router configurations.
SD WAN creates standardisation. The template is contained within the platform, removing the spectre of an engineer designing a new configuration for a site. With SD WAN all elements of the configuration will be centrally issued by the orchestrator, so there is very little for the Commissioning Engineer to configure on a deployment once the business intent overlays are setup.
SD WAN configuration is more intuitive than with a traditional WAN because it uses a Graphical User Interface (GUI) rather than producing lines of code. Although configuring by GUI is available for many Cisco products, the GUI for traditional WAN routers is less comprehensive and still requires using CLI to complete the config.
SD WAN can reduce the cost of deployment by separating the activities of a highly skilled Design Engineer followed by a less skilled Commissioning Engineer when each site goes live.
This works on the basis that a senior engineer will be needed for the template designs and then applying individual site-specific information such as IP Addresses and subnets.
Since the router downloads the config from the cloud, then there shouldn’t need to be a senior engineer on hand for when the install is taking place. Installs should be plug and play.
With a traditional WAN, one might deliver the first couple of sites with a certain understanding of how the configuration will work. Then something changes with the requirements or something isn’t working as well as it should, so the config is tweaked for the next few sites. However, if time isn’t taken (or available) to go back and change the other sites then the estate will end up with a mismatch of config styles. This can also be caused by a software level changing – what worked on one version of the IOS no longer works on the new.
With SD WAN, if the config needs to change, the template can be changed and then all devices that have that config will be updated remotely.
Sometimes mismatches can happen when different carriers are used. For instance:
SD WAN takes control of the CoS and prioritisation and doesn’t need to interact with the Carrier’s CoS so networks can be delivered consistently regardless of the Carrier.
With a traditional WAN there are a number of ways to configure a device for the same end goal, which can lead to different engineers having different preferences and styles. This can cause problems when engineers don’t understand each other’s styles, and cause a long-term knock-on effect for In-Life management.
With SD WAN you design Business Intent Overlays which effectively create the configuration. Since these Overlays are saved as templates, a change in Design Engineer won’t lead to a change in template designs.
Many SD WAN vendors claim that they provide zero touch deployments. This can be true but not in all cases.
When first deployed to site, the SD WAN device first needs to obtain an IP Address. With Internet Broadband this is likely to be DHCP, so the network will give the device this address. With private networks or Internet with Static IP, an engineer or your managed service provider will have applied this to the device before it is sent out.
The device, then calls home over the internet, using DNS, before being assigned to the SD WAN central orchestrator.
It’s perfectly feasible for the device to call home once plugged in, but some businesses are not happy for their own staff to do this. If you have relied on a managed engineer install in the past, then you may not be prepared (or resourced) to have a zero touch deployment at every site.
What we can say is that there is only a basic config required to get up and running. Once your IT team or Managed Service Provider has access, they can initiate the full configuration to be applied – in which case a technical courier would be sufficient.
As with deployment, SD WAN brings a number of benefits to the in-life management of a WAN. Again, while a large enterprise may see these directly, a managed service user may rely on the benefits being flowed down from the service provider in the form of a better service.
With a traditional WAN, changes are often performed manually, which can be time consuming and introduce risks.
You may be able to use a Network Configuration Manager to automate this, but this tends to be for simpler changes. If a line of code is different per device, then this makes it difficult to use a configuration manager. You can also have differences in syntax across variations of IOS – so even when a command is the same in theory, you might still have to tweak per model or range.
SD WAN reduces the time needed to evaluate changes, the time taken to write the change and then the time taken to apply the change, especially if this needs to be applied to multiple devices.
Firmware updates with SD WAN will have been tested against the central orchestrator options and therefore there should be less unforeseen issues.
For true application troubleshooting the entire application path needs to be understood – from application to user, across the LAN and the WAN. SD WAN doesn’t do this and to be fair neither does traditional WAN monitoring from most Service Providers. SD WAN will just look at router to router but not beyond.
However, SD WAN will do this element better and with more detail than most traditional WAN monitoring systems. This is because SD WAN monitors from a customer’s site to where their applications are based, whereas a remote monitoring system will monitor from the providers platform to the site, or from the providers platform to the where the applications are. SD WAN will do this for each site by default since these are the tunnels that have been set up.
At SAS we pride ourselves on our industry leading, award-winning monitoring platform. While we can monitor site by site and through the LAN to the servers and applications, we recognise that SD WAN makes it easy to set up. So, overall the best solution is both! You need the SD WAN monitoring to understand the granular detail on the WAN and SAS’ monitoring to extend this to the LAN, servers and application to see the entire picture.
We hope you have found this guide a useful summary of the benefits you might expect from SD WAN. You can read more about the principles of SD WAN in our Guide to SD WAN. You can see some specific cost reduction examples in our SD WAN circuit cost-reduction illustration.