What are some of the problems with SD WAN?
Like all technologies, SD WAN has different considerations and trade-offs to be examined before you decide to deploy. Consider the quality of your WAN links, what kind of features and performance you need, and the implications of working with different vendors. The myth of cost savings with SD WAN are also examined.
1. Quality of Connections
One of the functions of SD WAN that has made it so popular is that SD WAN makes it very easy to use cheaper Internet connections for your transport instead of requiring private lines similar to traditional WAN architectures. While the technologies for site to site VPNs over the Internet using IPsec have existed for many years, they have often been somewhat complicated to set up. They have traditionally been even more complex to manage when a large number of locations are involved. SD WAN platforms make using a VPN over the Internet easier and much more scalable due to the orchestration engine built into the platform.
Similarly, SD WAN makes it easier to work with multiple kinds of connectivity. A popular option for backup network services is a 4G/5G/LTE connection. Smaller sites might even be able to get away with using a wireless link as their sole connection to the rest of the network, and for more rural sites, it may be the only cost-effective option available. When using wireless for a backup connection, the location may have reduced network performance when the primary circuit goes offline but will still provide network access. This could potentially allow your location to continue operating, even if in a reduced capacity, as opposed to being at a complete standstill until the primary circuit is repaired.
However, as always, there is trade-off to be had. Different SD WAN vendors utilise different methods in attempt to improve the quality of experience (QoE) for a given connection. One of the most common methods is Forward Error Correction (FEC) where packets are sent with extra parity bits or even completely duplicated in the hopes of either receiving a full copy of the packet or being able to rebuild it when the packet reaches the other end of the VPN tunnel. This is a software process that requires CPU processing time on the SD WAN edge devices. If you use cheaper, lower quality links your packets may be delivered across the WAN correctly, but there will be a performance penalty for it and your users may suffer a lower QoE, depending on the application. Voice and video traffic, in particular, is very sensitive to low quality connections.
2. Underlay and Overlay Considerations
SD WAN is built on the premise of underlay and overlay networks. The SD WAN edge devices communicate both with each other and to a centralised orchestration engine using the underlay network. The underlay is composed of the physical links connecting to the SD WAN edges, which can be any number of technologies such as broadband, MPLS, wireless, and more. The VPN portion of the SD WAN environment is contained in the overlay network.The overlay is a logical network that is encapsulated over top of the underlay network. The advantage of this design is that changes can be made to the topology of the underlay without affecting the overlay. For example, if a new physical link is added or an existing link is changed from dynamic to static IP addressing, no modifications need to be made to the overlay VPN network.
The types of physical connectivity you choose for the underlay are important both for performance reasons (as detailed in the last section), as well as features, depending on your application needs. The two most common features available with private WAN services such as MPLS, which are often not available with broadband and 4G/5G/LTE Internet links, are multicast and quality of service (QoS).
Some SD WAN vendors are able to reproduce aspects of these features in the overlay network, but true multicast and QoS must be performed in the underlay. For example, multicast can be simulated in the overlay by just sending multiple copies of the multicast packet to all receivers, whereas true multicast only sends a single packet. Likewise, outbound prioritisation for QoS can occur across a public Internet connection, but once the packet leaves your network it no longer receives preferential treatment, whereas a private WAN circuit in the underlay can guarantee end-to-end QoS.
When using private WAN links for your underlay, you must take into consideration that most SD WAN platforms require some form of public Internet connectivity to reach the orchestration engine. Receiving Internet traffic through a private MPLS link can lead to more complicated network design considerations. For these situations, it may be best to have a private WAN link with the features you need as your primary connection, and a secondary broadband or wireless link as your Internet-connected backup. With this configuration you receive the performance and features of the private link while still using the public Internet link for connectivity back to the orchestrator and for less-important traffic.
3. Feature Considerations
SD WAN edge devices have the potential to replace multiple separate network functions and comingle them into a single platform. Before you decide which SD WAN vendor’s platform to deploy, take the time to carefully evaluate your specific needs and determine if there is a SD WAN vendor that has each of the features you desire already integrated into the product.
Some SD WAN vendors have WAN optimisation features included, such as the ability to cache and compress different kinds of network traffic to improve performance. Others have higher levels of security features built in. Other SD WAN platforms include tight integrations with third-party vendors, particularly when it comes to security.
Additional considerations include the SD WAN edge device appliance itself. If you are still working with legacy serial-based WAN links (very rare in the UK), there are very few SD WAN vendors that directly support these kinds of connections and you may need to use an intermediate device to convert from serial to Ethernet. Companies with larger sites require high availability (HA) features where at least two SD WAN devices can be clustered together for failover. Not all SD WAN devices support this kind of feature. Likewise, it is typically only the most expensive appliances that feature dual power supplies.
Finally, you must carefully consider the performance level needed for each location across your network. You can potentially encounter major issues with your SD WAN if you undersize the edge devices at your locations. Most SD WAN features and performance are directly tied to the CPU of the SD WAN edge device. Less-costly appliances feature very weak processors and are unable to handle larger volumes of network traffic. Your users will have a much better QoE if you overprovision, rather than under provision, when it comes to your SD WAN edge devices.
4. Working with Multiple Carriers
SD WAN enables you to more easily use multiple different kinds of WAN links simultaneously. One of the most common reasons to have multiple WAN links is for carrier diversity. If one service provider is having issues, you purchase a link from a different carrier so that the second link is not affected, and you can continue to operate. However, you must perform due diligence to ensure that your carriers do not share any underlying infrastructure. This is particularly true if both circuits are delivered using the same technology, such as fibre optics. Similarly, remote areas in particular may have multiple kinds of circuits available, but services are delivered to the area with a single underlying fibre optic connection, and if that link is cut, all of the services become unavailable until it is repaired.
Since SD WAN encourages the use of multiple links with multiple carriers, this creates new potential problems with carrier billing. More circuits mean more bills to keep track of, and more issues to be encountered. If you have a large SD WAN deployment, managing billing can easily be a full-time job for someone. You might be better served by outsourcing this aspect of WAN management to a third-party. Likewise, many managed services providers (MSPs) can handle this for you and simply present you with a single consolidated bill for each contract period.
5. Extending Your Network into the Cloud
Businesses are continuing to move their workloads into public cloud environments like Amazon AWS, Microsoft Azure, and Google GCP, among others. Public cloud resources allow for elastic operations where you provision only the level of services you need, and you can easily grow or shrink as necessary. This is almost always a gradual move rather than a hard cutover. To bridge the gap between your network and the public cloud, it is beneficial to have an SD WAN edge operate in the public cloud environment.
Several SD WAN vendors provide virtualised edge appliances specifically designed to operate in public cloud environments. If you are considering moving your workloads into the cloud, this is the easiest way to go. However, if your chosen SD WAN vendor does not have any virtualised offerings (which is becoming increasingly rare), you must account for this. Very few cloud service providers allow you to ship a physical SD WAN appliance to them. If you must use a physical SD WAN appliance, your next best option will be to establish a private WAN link with your cloud provider. Many colocation facilities offer these kinds of cross-connects.
6. Support Issues
SD WAN is still a maturing technology, and while many of the underlying components of SD WAN are built on open technology standards like IPsec, nearly all SD WAN platforms feature vendor-proprietary extensions and are not directly interoperable with each other. This means that you will ultimately be working with the SD WAN vendor if you begin to encounter issues with the service. If you purchased SD WAN through an MSP, they may work with the SD WAN platform vendor directly on your behalf, though it is common for the end customer to become involved if the issues are more difficult to detect as deeper levels of troubleshooting within your corporate network may need to be performed.
When working with a vendor of any kind, whether the SD WAN platform vendor themselves or an MSP, they need to be held accountable for some kind of service level agreement (SLA). A large part of being able to meet an SLA when issues arise is the expertise level and number of technical staff employed. Both vendors and MSPs may have multiple tiers of support that your issue has to pass through if it is particularly complicated. Always ask what the support and escalation process is before working with a vendor so that both parties have clear expectations set as a precedent.
A large part of a successful SD WAN deployment is determining your application network traffic patterns and designing the correct solution for your environment. Your vendor and/or MSP should work with you in the initial design stages to ensure there are fewer support-related issues after the SD WAN environment has been deployed.
7. SD WAN Costs
The most common myth of migrating to SD WAN is that you will save money on circuit costs because you can switch from more expensive private WAN links to cheaper commodity public Internet circuits. As discussed, this may or may not be true, depending on the performance needs of your application traffic. Private WAN circuits like MPLS continue to be an important part of a performant and reliable SD WAN offering.
SD WAN equipment is also a major consideration. Some newer routers, such as Cisco’s ISR 4000 series, can be upgraded to run SD WAN code. However, most SD WAN deployments involve completely replacing legacy routers with new SD WAN edge appliances. If you have hundreds or thousands of sites to upgrade, this can be a significant upfront cost when taking the DIY approach to SD WAN deployment.
When you purchase SD WAN as a service through a partner like an MSP, the SD WAN hardware is typically included as part of your monthly contracted fee. The MSP approach allows you to more quickly invest in the improvements that SD WAN can bring to your network with fewer upfront costs. Consider also that the cost of having access to expert-level staff with the MSP is built into your contract and may be less expensive than hiring your own full-time experts.
Many organisations have built their WANs on a single connection per location. Larger or more critical sites may have multiple links, but the majority may have just a single link to keep costs down. While SD WAN can improve some of the reliability characteristics of a single link, its use ultimately encourages provisioning of multiple circuits. Luckily, this is something that can be incrementally added quite easily, but you should be prepared to face the costs associated with having additional circuits if you wish to have a much more reliable WAN. It is important to perform a cost-benefit analysis of how much revenue you could lose at a location with a malfunctioning single WAN link, which is a practical inevitability, versus having a significantly higher level of uptime by having a backup connection.
8. Deciding to Deploy
Migrating from a traditional WAN architecture to SD WAN can bring tremendous new opportunities to your business in terms of performance, reliability, and flexibility. However, there are always trade-offs to be had and you should carefully examine what is most important to your network and your business before taking the plunge. An MSP may become an important ally as you move forward.
About Jedadiah Casey
Senior Network Engineer for 5 years General IT/sysadmin experience 10 years prior Bachelor of Science degree in Information Systems Certifications: Cisco CCNP Routing & Switching, CCDP Network Design, CCNA Routing & Switching, CCNA Wireless, CCNA Industrial, CCNA Service Provider Certified Wireless Network Professional CWNA VMware VCP-DCV Juniper JNCIA Working toward Cisco CCIE R&S, first lab attempt was June 2018.