animind - Fotolia
Software-defined WAN, or SD-WAN, offers plenty of operational benefits, including seamless failover and prioritized packet routing. It's a powerful platform, and its feature set is one reason why SD-WAN has become so popular over the past few years.
Yet, if you're stuck managing a legacy WAN deployment and are assessing whether to upgrade to SD-WAN, don't forget about the underlay network. Without a solid SD-WAN underlay foundation, you won't reap SD-WAN's true benefits.
In this article, we'll first describe the difference between an underlay and an overlay network as it relates to SD-WAN. We'll then cite the portions of the underlay that must be verified before you decide which SD-WAN platform to deploy.
How SD-WAN is designed
While some SD-WAN architectures operate natively on dedicated hardware, most rely on a combination of underlay and overlay networks. In these architectures, all the new and exciting SD-WAN functions operate within the overlay -- a virtualized network that runs on top of the underlying, or physical, network.
In this scenario, the underlay plays second fiddle to the overlay network. For example, core functions, such as packet routing, quality of service and route or packet policy enforcement, move from the underlay to the overlay. The underlay's only responsibilities are to provide IP connectivity to neighboring underlay routers or gateways.
Because the underlay now plays a different role, enterprises need to assess the underlay hardware, software and configurations to be certain they can operate as an SD-WAN router. Many organizations forget to take that step, and this oversight can lead to deployment problems and the inability to run certain SD-WAN functions.
Regardless of the fancy things going on in the overlay network, its performance depends on the ability of the underlay network to do its job. Keep in mind that underlay networks are where all WAN connections terminate. This is where internet broadband, carrier MPLS or dark fiber links connect a remote site to the rest of the corporate network.
Today's distributed computing model poses other considerations around WAN connectivity. Many companies have shifted their applications and data away from on-premises data centers to private or public clouds.
Therefore, your SD-WAN underlay network must be able to accommodate this shift in data flows. WAN selection and bandwidth sizing must be reworked to squeeze the most out of the SD-WAN. This means existing WAN links will need to be right-sized for bandwidth, latency and resiliency.
Cellular connectivity must be factored in
Additionally, the number of WAN connections and the types of connections will also likely change and grow within the SD-WAN underlay network. For example, advancements in LTE and 5G are enabling SD-WAN architects to deploy these wireless technologies far more effectively than in the past. Many public cloud customers are also opting to deploy dedicated cloud interconnects between critical corporate and remote offices and the public cloud provider.
Next, consider that your current WAN hardware will be responsible for running both the underlay and virtualized overlay network. This often means that, compared to legacy WAN deployments, additional processing power and memory capacity may be required. SD-WAN vendors often list compatible WAN routing hardware and minimum requirements for proper operation. If your current underlay hardware does not meet those specifications, you'll be forced to find an SD-WAN platform that does or spend additional money to upgrade your existing WAN edge hardware and software.
Last is visibility. While an SD-WAN overlay provides a host of different visibility and monitoring options, the same cannot be said for the SD-WAN underlay network. Before deploying any type of SD-WAN, be sure you'll be able to efficiently monitor the performance of the underlay and that alerts are appropriately triggered and tracked.
Lower-level visibility will no doubt come in handy -- especially when troubleshooting carrier WAN outages. The overlay network will often mask which link is down or degraded. This can result in too much time spent troubleshooting. Instead, monitoring the WAN links at the underlay level will provide more granular and relevant information when troubleshooting.