No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Taking a Cloud-Side View of SD-WAN


Image: phonlamaiphoto -
Most enterprises know about SD-WAN because they've likely considered or used this technology to connect locations where their MPLS VPNs can't reach or aren't economical. That's still the dominant SD-WAN mission, but another one is gaining ground rapidly—and it seems likely that it will eventually be the major driver of SD-WAN usage. That mission is SD-WAN as a cloud, hybrid cloud, and multi-cloud networking strategy. To support it, you’ll need to look at SD-WAN from the cloud side.
Before COVID-19 existed and work-from-home (WFH) flourished, some enterprises realized that the cloud could also provide an on-ramp for their workers' access to applications and a way of reaching customers and partners without making changes to their core applications. With the WFH explosion came an explosive realization— that workers accessed applications on the company VPN rather than the Internet—and providing worker-level access via the Internet posed security risks. The problem was that company VPNs' access to the cloud became limited by the fact that you can't install your own devices in your cloud provider data centers. Enter SD-WAN.
While most SD-WAN applications involve an appliance deployed in those small-site locations, SD-WAN itself is software, which means that you could run it in the cloud. You can run SD-WAN software in multiple clouds, and since you can also run it in the data center, SD-WAN can extend or create a VPN that covers every worker and every application hosting point, as long as each of them is on some IP network. Are you bridging multiple clouds and multiple networks? That's a tough capability to ignore, especially with so many companies looking at multi-cloud.
SD-WAN implementation varies, but all of them create what we'll call a “virtual overlay network.” That means they layer another routing technology on top of IP—and SD-WAN users (people and applications) are really on that overlay network rather than on whatever network is underneath. Two physical networks exist if you have a VPN and (also) use the Internet, but one SD-WAN rules them all.
If an “overlay” network exists, it (obviously) has to overlay something. With SD-WAN, the SD-WAN overlay network or SD-WAN VPN can be transported over the Internet, over mobile or satellite connections, over MPLS VPNs, private microwave, or fiber—you name it. Users on the SD-WAN VPN are connected to it by an agent, and that agent has one or more underlay network connections. Everywhere an SD-WAN VPN reaches, there must be an agent, which means you need one in the cloud to connect to cloud applications. SD-WANs are networks of agents connected by one or more underlay networks.
A public cloud provider gives users “private” IP addresses for hosting that allows connections within the cloud but not outside. It's similar to a home network, where users can access private IP addresses, but unlike home networks where users connect out—cloud applications require users to connect in. For this to work, applications must be exposed on a public address, either on the Internet or a corporate VPN. Cloud accessibility then depends on user location.
If you access your cloud applications via the corporate VPN, SD-WAN lets you put an agent in the cloud that connects your cloud domain of applications onto the VPN—pretty much the way it would connect a branch office to the VPN. Each of your applications would still have an address from your VPN address space, and VPN routing would route those addresses from the user, through the user's SD-WAN agent, then through the cloud's SD-WAN agent, then to the application.
Where applications get accessed from the Internet, the cloud can host them the same way any web server would, exposing an Internet address to users. Inside the cloud domain, an SD-WAN agent could then connect the traffic back onto the corporate VPN. Traffic could also connect to an SD-WAN agent on another cloud for multi-cloud users.
All this connecting happens virtually within the SD-WAN VPN, but the real traffic has to flow on one or more underlay network paths between those agents. That's important in cloud applications because of potential differences in cost and performance among the underlay path choices. Corporate MPLS VPNs may not be the best or cheapest way to connect cloud traffic, particularly multi-cloud, so it's important to understand how your prospective SD-WAN vendor manages various underlay network services.
SD-WAN traffic can make path choices at nodes that support more than one path, such as the Internet and your VPN. Some vendors (Cisco, most recently) have announced SD-WAN routing gateway relationships with cloud and interconnect providers, allowing better control over the path cloud traffic takes.
Path selection is a feature of most SD-WANs, along with traffic prioritization—but the value depends on just how much the SD-WAN recognizes about traffic types, users, and applications. Some SD-WANs have no traffic recognition at all, and a few can distinguish applications and even application-user relationships. The more an SD-WAN knows about traffic, the better it optimizes both cost and quality of experience. That's particularly true with cloud applications, where the best-efforts Internet is the de facto network of choice.
If the cloud drives more SD-WAN adoption, it has the potential to transform how we build corporate networks and support cloud-resident applications, including hybrid and multi-cloud. SD-WAN is a kind of floating network technology to fit the cloud model of the future. Cisco is seeing a major shift to “cloud SD-WAN” and the need to monitor applications rather than just the infrastructure they run on or with which they connect. Cisco competitors, and cloud users, should probably start paying attention to that, too.