For years, we’ve been touting the value of one of the unique aspects of our VMware SD-WAN™ by VeloCloud® solution: the VMware SD-WAN Gateway. And yet, almost six years after we first launched our VMware SD-WAN Gateway service, I hear from customers and prospects that this term: “Gateway”, is being used generically in the industry when describing an on-ramp to SaaS applications. While imitation is the sincerest form of flattery, it begs the question: Are all of these “Gateways” the same? Today’s blog post explores that point.
First, what is a VMware SD-WAN Gateway? If you’ve had any exposure to our product, you’ve probably seen a diagram similar to this:
This diagram shows our patented VMware DMPO (Dynamic Multipath Optimization™) technology (the green, red and yellow stripes across the multiple WAN links mirror our “Quality of Experience” graphs) connecting the SD-WAN Edge in the Branch to the Hub in the Data Center, as well as the Branch and Data Center connecting to a Gateway, which in turn connects to SaaS. To better appreciate what’s happening here, let me break it down.
Connecting the Network of Clouds
VMware SD-WAN Gateways serve as an on-ramp to (and a network between!) a variety of clouds—not just SaaS—as more and more services become “cloudified.” We at VMware refer to this as the Network of Clouds. Today we want to discuss why VMware SD-WAN, by leveraging both DMPO and these Gateways, is the absolute best way to connect this ever-expanding Network of Clouds.
This VMware SD-WAN Gateway infrastructure serves as a platform for delivering services. For instance, the services that are provided today include:
Automatic WAN link discovery service
Distributed link analysis service (MTU, bandwidth, loss, latency, jitter)
Full-mesh VPN with dynamic branch-to-branch signaling
Cloud on-ramp service (easy access to any cloud)
Basic cloud interconnect service
Cloud Expansion
For any modern enterprise, a vast majority of their services may now be accessed via one of these clouds. Legacy data centers have migrated to IaaS clouds. On-premises security devices have migrated to security clouds. On-premises network monitoring tools have migrated to analytics clouds. For some customers, even their MPLS core has been replaced by a mid-mile cloud.
For customers interested in cloud adoption there are two major concerns. The first is the Day 0 problem of how to connect easily. For instance, we recently demonstrated API integration with Zscaler, allowing customers to easily establish tunnels directly from edge devices to Zscaler. The second, even larger concern, is monitoring and troubleshooting those tunnels. Just as edges can connect to other edges in the VPN more simply using our VMware SD-WAN Gateways, clouds can also connect to other clouds by transitioning through one of the Gateways.
Consider a “cloud forward” company—where every site may have to connect to security, analytics, mid-mile, SaaS, compute and IaaS clouds. For many of our customers, this traditionally would have meant configuring (automated or not) and then monitoring and maintaining thousands of tunnels. With our SD-WAN solution, there is a one-time configuration (often just a few clicks) to connect their cloud(s) to ours. VMware SD-WAN Gateways are automatically provisioned and provided to edges, which in turn connect and automatically exchange security and routing information. Now I can manage just six connections—one to each of my clouds—and yet have a full mesh of connectivity that is high quality and highly available.
What is a VMware SD-WAN Gateway?
One of the original problems we set out to solve when we started building VeloCloud, now part of VMware in 2013 was ensuring that as applications migrated to the cloud, users could continue to get the same “LAN-like” experience that they have to come to expect from highly reliable corporate networks (e.g. those built on MPLS).
To solve this problem, we wanted to put a device in the cloud itself. Our VMware SD-WAN Multipath Protocol (VCMP) requires devices on both ends of the network so that VCMP can measure network paths unidirectionally and perform link steering and error correction decisions in each direction. This allows us to efficiently take advantage of modern WAN links which are almost always asymmetric: either in capacity (like a typical cable or DSL connection) or in quality (like congestion in one direction or wireless differences due to upstream/downstream antennae strength). But we didn’t want to set up a device for every customer in the cloud, nor did we want to force the user to configure this device.
From these requirements was born our VMware SD-WAN Gateway concept—what if we could build an autonomous, stateless, horizontally scalable cloud-delivered gateway? Edges could connect to any endpoint, providing the ability to do seamless failover and infinite scale. Just over six years ago, that concept became a reality—the Edge device is assigned a list of Gateways from the Orchestrator and connects to them—automatically creating virtual routing and forwarding (VRF) if required (for multitenancy) and auto-provisioning them at runtime. When we have maintenance, we can simply throw away a Gateway and spin up a new one. When scale goes up, we simply add more Gateways.
How do Gateways Help?
Simplicity
There is no customer configuration required to use the VMware SD-WAN Gateway service when deploying. The Gateways are assigned (either automatically or by your network operator) and while using them, VMware SD-WAN Edges can automatically discover answers to these questions:
What WAN links are connected?
What is their ISP?
What is their bandwidth?
What is their quality?
What other edges am I allowed to connect to?
What other cloud services am I allowed to connect to?
Also, you can quickly connect to a new corporate site that does not run VMware SD-WAN by building a standard IPsec tunnel from one of our Gateways, instantly bringing that site into your full mesh VPN.
Flexibility
Other SD-WAN solutions may choose the “best” WAN link for an Internet flow. But if the quality of that WAN link changes during the life of the flow, there is nothing that can be done without terminating the session, because that session has already been established with the network address translated (NAT’d) IP address of the chosen link. With the VMware SD-WAN Gateway, the NAT happens after the packet has traversed the last mile—allowing us to use multiple links simultaneously and move between them on a packet-by-packet basis as needed.
Quality and Capacity
Using VMware DMPO, edges can apply several mechanisms—steering, striping packets across multiple WAN links and error correction—to improve the quality and capacity of your cloud connectivity.
One of my favorite things is the look on a customer’s face when they experience this for the first time— running Internet speed tests combining multiple links or doing seamless voice and video failover tests on their hosted UCaaS solution. We are not just giving you simplified cloud access, we are ensuring a quality connection to those clouds.
To me, getting across the Internet is a lot like driving. In driving there are highways—high speed and high quality (maybe not always here in the Bay Area!)—and there are neighborhoods off those highways where most of the traffic congestion and accidents happen. The Internet is similar—with high speed, high quality backbones and most problems happening in the last mile. VMware SD-WAN performs link steering and error correction across that last mile—guaranteeing you the best passage possible, like a bridge taking you over those neighborhoods filled with traffic directly to the highway on-ramp.
Most importantly, these traffic problems can happen in either direction. Often network quality issues are caused by your applications themselves. For example, during March Madness, when your whole office decides to stream a basketball game at once (nobody actually does this hypothetical thing at work, right?). By the time that video reaches your edge, capacity is already consumed. TCP back pressure alone cannot solve all inbound congestion problems and you may be forced to find users and ask them to stop or add firewall rules to block their application entirely. With the VMware SD-WAN Gateway, inbound QoS happens before any of your transit capacity is consumed—allowing downstream rate limiting of cloud traffic flowing via the Gateway so that it can be permitted but controlled.
Full-mesh VPN Connectivity
Most people familiar with SD-WAN will also be familiar with the concept of an edge device. Whether it’s an edge or a router or a client, all solutions will require some endpoint to connect to the SD-WAN network. One of the hallmarks of SD-WAN solutions is how they simplify the configuration of these endpoints so that they can interconnect.
But no matter how simple it is, there are only so many tunnels that a single device can build. Some SD-WAN solutions are very limited—using static tunnels to build a full mesh VPN via multiple devices, and some (like ours) can use dynamic tunnels to limit connectivity only to those sites required right now. But what if I need to connect to more sites than my device can support? Traditionally, this is done by backhauling traffic to the data center and hair-pinning there. For very large networks, this can be an issue for two reasons. First, the data center might be located far from multiple branches in the network. For example, I don’t want my Anaheim and Los Angeles branch sites sending traffic through Dallas just to talk to each other. Additionally, the data center now must handle two times the traffic for site-to-site communication that doesn’t even involve the data center directly—which can get quite costly (if not improbable in a very large network).
With the VMware SD-WAN Gateway, customers have a geographically distributed (for lower latency) and horizontally scalable (for capacity) network of Gateways that can act as that waypoint, allowing efficient full mesh VPN connectivity with a single click and without building a full mesh of tunnels.
What’s Next?
While VMware SD-WAN Gateways can uniquely provide a high quality on-ramp to SaaS, that’s not the only service they provide. Our vision is that for any topology, our Gateway platform will enable us to easily provide high quality, highly scalable and secure connectivity between any cloud in the Network of Clouds.
Services of Today
Automatic WAN link discovery service
Distributed link analysis service (MTU, bandwidth, loss, latency, jitter)
Full-mesh VPN with dynamic branch-to-branch signaling
Cloud on-ramp service (easy access to any cloud)
Limited API automation (e.g. Microsoft Azure Virtual WAN)
Basic cloud interconnect service
Services of Tomorrow
Expanded API automation to easily interconnect more clouds
We continue to expand the services this platform provides as companies transition into this “Network of Clouds” world and would love to hear feedback from you on the other services you envision being automatically delivered as part of our unique platform. Email me or find me on Twitter (@egregious) to continue the conversation.
For years, we’ve been touting the value of one of the unique aspects of our VMware SD-WAN™ by VeloCloud® solution: the VMware SD-WAN Gateway. And yet, almost six years after we first launched our VMware SD-WAN Gateway service, I hear from customers and prospects that this term: “Gateway”, is being used generically in the industry when describing an on-ramp to SaaS applications. While imitation is the sincerest form of flattery, it begs the question: Are all of these “Gateways” the same? Today’s blog post explores that point.
