SD-WAN Transition: Overlay vs. Underlay Considerations
In this blog, we exploring SD-WAN Underlay (physical infra on which your SD-WAN is built) and Overlay (the software, and appliances that comprise the SD-WAN).
This article is for anyone who’s ready to get specific about their SD-WAN overlay and underlay needs. If you’ve worked out that SD-WAN is going to give your enterprise Wide Area Network (WAN) the flexibility and economy you need this year, then it’s time to get your head around the key concepts that define the different iterations of this hugely popular modern network solution.
We’ve written several articles about SD-WAN – it’s a complicated topic, and we know a thing or two about it. If you want to read up on how to undergo an MPLS to SD-WAN transition, combining SD-WAN with an existing MPLS structure, the differences between SD-WAN or SASE, or more detailed info on SD-WAN appliances, we’ve got you covered.
In this blog article, though, we’re exploring what you need to know about SD-WAN Underlay (the physical infrastructure on which your SD-WAN is built) and SD-WAN Overlay (the software, policies, and appliances that comprise the SD-WAN network).
When you’re shopping for SD-WAN, it’s easy to forget about the underlay – but you neglect it at your peril.
If you’re augmenting an existing MPLS network, then you probably still have some quality-of-service assurances that’ll keep things running smoothly. However, it’s likely you want to shift to cheaper, public internet connectivity in the context of your SD-WAN change.
However, if you’re running the whole network on public internet, it’s worth making sure that your SD-WAN vendor provides managed underlay services too – otherwise any underlay issues will be on you and your IT team to figure out and chase up with your internet provider(s). This can be messy and time-consuming.
These issues are often amplified further by the standard SD-WAN practice of using multiple internet providers at the same site (particularly if your network requires active load balancing, which could mean you also have to work out which internet provider is at fault for your issues).
An excellent strategy to help streamline your underlay planning processes is the creation of standardized tiers.
By grouping your enterprise locations into tiers with pre-assigned underlay network requirements, you can avoid reinventing the wheel every time you open a new branch office.
The tiers typically look something like this.
Tier 1 - Large Corporate Sites
Circuit 1 = Dedicated Fiber Based Internet provided by Carrier “A”
Circuit 2 = Dedicated Fiber Based Internet provided by Carrier “B”
Tier 2 = Large Branch Office
Circuit 1 = Dedicated Fiber Based Internet provided by Carrier “A”
Circuit 2 = Broadband Coax Best Effort Internet provided by Carrier “B”
Tier 3 = Small Branch Office
Circuit 1 = Broadband Coax Best Effort Internet provided by Carrier “A”
Circuit 2 = LTE / 5G / Satellite Internet provided by Carrier “B”
Tier 4 = Satellite Office
Circuit 1 = single circuit, single provider
The more you stick to your tiers, the easier you’ll find managing underlay requirements across your network. However, there’ll still likely be what we’d call Individual Case Basis (ICB) locations with unique requirements that aren’t easily accommodated by any one tier.
An example of this would be a site where there’s an IT test bench. When running Proof of Concept tests, these sites often require a range of connectivity options to see whether a prototype solution can be rolled out across all sites.
Multiple internet providers (listed above as “Carrier A” or “B”) are an invaluable addition to your SD-WAN network, wherever possible. Having redundant and diverse connectivity means that if your internet provider suffers a network-level outage, your site and network don’t end up as casualties – you can just shift to the other provider.
If your location is of vital importance, you can double down on your underlay network diversity planning by requesting KMZ files from your prospective providers (though not all vendors are willing to provide these files). KMZ are map-based image files that show the physical fiber routes and allow you to create routing that’s diverse all the way to the data center and beyond.
MPLS as Underlay
One of the great strengths of an SD-WAN topology is its adaptability – the majority of SD- WAN appliances will function equally well on any type of Layer-3 connection, including MPLS networks.
We’ve seen plenty of customers overlay SD-WAN onto MPLS, or conjoin the two. There are a few good reasons to do so, too.
Needing to give SD-WAN a proper “test drive” to experience it firsthand, before transitioning away from MPLS
Maintaining a network model that relies on ultra-low latency and super-consistent network metrics, as you’d find with finance or fintech organizations
Industries with high security and compliance requirements, like healthcare or governmental departments
Companies who are partway through an MPLS contract, and who face being financially penalized for early termination of the contract.
SD-WAN allows companies running MPLS to add additional bandwidth more affordably than if they attempted to increase their throughput solely using MPLS. Sourcing additional bandwidth on a per-site basis allows them to focus the resources exactly where they’re needed.
With the right strategic approach, creating the correct underlay for your SD-WAN network can be relatively straightforward.
Now, here comes the fun part. The “Software Defined” overlay is the secure network that establishes connectivity via links (typically public internet) installed at each of the enterprise locations.
In most cases, this is achieved by installing an SD-WAN appliance at each physical site. On installation, this device contains a simple baseline configuration – just about smart enough to connect online with the centralized configuration server through which the entire network will be controlled.
Once it’s connected, the appliance will download everything it needs to become part of the SD-WAN network, along with any configuration data or policies specific to that location.
This centralized control makes provisioning much easier for the WAN IT administrator. The use of a centralized control portal also means that the admin has far greater visibility across the traffic and users on the network at any given time. These centralized analytics functions allow network IT administrators to identify and troubleshoot any bandwidth issues as they arise.
The Three Types of SD-WAN Overlay Topology
Any attempt to describe SD-WAN overlays comes with a caveat – we’re still a long way off an accepted industry definition or standard.
While a small but growing number of service providers have adopted MEF’s Service Standards, they’re still in the minority – which means that there’s a lot of conflicting information and less-than-useful “interpretation” of some of the key terminology (all the more reason to work with an expert-backed procurement platform like Lightyear).
All the same, a great number of the SD-WAN instances can be safely assigned to one of these three categories.
1. On-Premises Only
This entry-level SD-WAN is typically the lowest-priced of the three categories and is most suitable for networks that don’t rely on cloud-based applications and services.
Here are some key characteristics.
SD-WAN appliances (often referred to as Customer Premises Equipment, or CPE) are used to set up multiple VPN tunnels between the firewalls at each site.
Every appliance communicates directly with the CPE at every other site.
Any remote workers must connect via a firewall or VPN concentrator to the main corporate site or data center.
Any cloud-based services or applications are accessed via public internet – and there’s no middle-mile network provision, so performance metrics will vary in response to public network traffic.
Because each location’s CPE is linked directly to every other CPE, it’s harder to scale – the more locations you add, the harder every CPE must work to keep up with all the route tables.
2. Cloud Gateways
This SD-WAN set-up offers enhanced connectivity to cloud-based apps and services, via the provider’s SD-WAN gateways in the cloud. In this topology, you can expect the following.
Site-to-site traffic is still mainly achieved through Dynamic VPN tunnels between the CPE at each site – but routing is achieved via the SD-WAN gateways, which provide routing information to the CPE
The gateways provide a more stable connection to cloud services, so users can expect improvements in performance and reliability
Remote workers still connect to the corporate network via the firewall or VPN concentrator
There’s still no middle-mile network, so there’s still no consistency in performance, with unpredictable peaks and troughs in throughput
Although CPE is still connected site to site via VPN, the gateways define the routing for each CPE. This avoids the scaling difficulties experienced with “On Premise Only” solutions. As the CPE is effectively told what to do by the gateway, it makes no difference how many locations are included in the network.
3. Cloud Gateways + Middle Mile Network
The addition of a secure middle-mile network takes this SD-WAN topology to a level of service and features more commonly associated with SASE products (as SASE is defined by its middle mile network). This solution is well suited to enterprises who are accustomed to MPLS levels of performance and reliability and want their SD-WAN network to provide comparable results.
Once traffic reaches the secure gateway, it travels through a middle-mile network where traffic is monitored and inspected at every end point. This additional level of analytical insight means that performance metrics can be assessed and predicted with much greater accuracy.
Other things to note about this topology include the following.
A much lower dependency on the CPE – whereas in the two previous topologies, VPN tunnels between sites were required, now the SD-WAN appliance only needs to communicate with one of the secure gateways
Gateways are deployed with redundancy, so any issues that might arise with an individual gateway won’t affect performance across the network
The additional levels of security at the gateway (which in a SASE setup are likely to include features such as Zero Trust Network Access and a Cloud Access Security Broker) mean that remote workers can join the network in the middle mile, just like any of the other sites on the network
Gateway connection to cloud services and apps (often via a Secure Web Gateway) should provide significant improvement in cloud app performance and reliability
Hopefully, this article has given you a solid schooling in the basic requirements for your SD-WAN overlay and underlay (and an understanding of why these two elements need to be considered separately, if you’re preparing to transition to SD-WAN).
As we said, though, there’s significant variation between the products and terminology of the different vendors in this space. If you’re looking for a procurement process that smooths out these bumps and provides the product you’ll need for your enterprise, Lightyear’s combination of automated procurement platform and dedicated expert industry professionals is what you need to get your SD-WAN up and running. Get in touch with Lightyear today.
Want to learn more about how Lightyear can help you?
Let us show you the product and discuss specifics on how it might be helpful.
Not ready to buy?
Stay up to date on our product, straight to your inbox every month.