Recently, Versa Networks participated in the AWS integration testing performed by the ESG Group that culminated in their recently published buyer’s guide for SD-WAN solutions in AWS. The timing of this test was perfect as it coincides with increased customer interest in both hybrid and multi-cloud solutions.
The timing was perfect for another reason: Versa has been adding quite a bit of innovation around native integration with various public cloud environments, but these tend to make sense to folks employed by “born-in-the-cloud” employers, where Python and JSON, not BGP and OSPF are the main job requirements. Yet, interestingly enough, most of the people needing SD-WAN-to-Public-Cloud integration are not that. They are the “on-premises network engineers”, to borrow the term Nick Matthews coined so well in his popular blog on AWS networking.
So, what better time to write a series of blogs on the latest developments around public cloud integration, and do so in a way that helps a traditional “routing engineer” to evaluate and implement SD-WAN and extend their SD-WAN to the public cloud. This blog will kick off a series of topics that will focus on specific use-cases and implementation details.
As enterprises migrate their workloads into Public Cloud, they often encounter a dichotomy of sorts:
On one hand, they find sophisticated compute, storage, and database services. These services have truly re-invented their on-premises counterparts for the 21st century. Not only are they designed to scale both up and out, they are also complemented with a large variety of auxiliary toolsets (DNS, messaging, notification, logging, etc.) to aid with operational simplification and automation. Then there are the higher-level managed services built upon their foundation – things like MQTT collectors of IoT, Machine Learning tools, AI, Mobile Services and more. At the time of this writing, AWS re:Invent was going on, and multiple new higher-level services have been announced daily, sometimes hourly. In short, public cloud is a universe of cutting-edge, 21st-century compute, storage, and database services.
On the other hand, there is networking. With networking in the cloud, things are more reminiscent of the early 80’s. Routing is done with static routes and limited BGP. Layer 2 broadcast and multicast break. Analytics tools are rudimentary and fall incredibly short of providing any network visibility, telemetry, and troubleshooting. It is plainly evident that the level of sophistication here is different.
Can SD-WAN be the technology that brings 21st-century routing and security to public cloud?
Interestingly, SD-WAN has mostly been an on-premises phenomenon, driven by enterprises’ desire to reduce the cost of their WAN while gaining flexibility and programmability. Naturally, when customers bring the sophistication of SD-WAN to their on-premises networks, their next question often is “How do I seamlessly connect that to my public cloud resources?”. The answer is actually easy and intuitive – what better place to put a “Software-Defined Branch” than in public cloud environments, where everything is software-defined? Extending on-premises SD-WANs into public cloud (hybrid cloud) is as easy as simply spinning up a branch in the customer’s VPC (in the case of AWS) or VNET (in the case of Azure).
With the topology and security controls available in SD-WAN, it is equally as easy to create a complex multi-cloud environment (where the public cloud resources are split across multiple public-cloud providers). The questions from customers now shift toward two main themes:
With a focus on AWS integration and operationalization, this is where the ESG report comes in. Versa is pleased that the findings of the report accurately highlight how the Versa Cloud IP Platform supports all features deemed of importance in the guide.
As a first in a series of topics, we will start with an example of the intuitive mapping of concepts between a Versa SD-WAN and AWS-based routing artifacts. First, let’s consider a simple example of on-premises sites connected over SD-WAN.
The concept of a Transport Domain (TD) is fundamental in Versa Secure SD-WAN. These are distinct transport networks each with different reachability, capabilities, and SLA behaviors. In on-premises deployments, two typical examples of TD are “MPLS” and “Internet”. Within a branch device, a TD is represented by a dedicated virtual router (VR), so that the routing tables of disjointed TDs do not clash with each other.
Overlays (represented in the above diagram as “LAN-Side VRF”) are created over those TDs, and traffic is steered based on SD-WAN policies which incorporate, among other criteria, the real-time behaviors of the various TDs in the network.
When a branch is instantiated in AWS, this on-premises notion of TDs maps quite nicely to how AWS represents network resources. Here is an example of how Versa TDs will map to AWS distinct routing tables, which allows a Versa AWS-based branch to treat AWS Direct-Connect (DX) as a one TD, and “Internet” as another. The Direct-Connect TD can then be mapped/connected to the MPLS TD used by on-premises branches.
One of the branches (Site 1) is now instantiated in AWS, and in this example, one of the TDs is defined as “Direct-Connect (DX)”. Typically, DX will be connected via a DX-POP to the customer’s on-premises MPLS network. The Direct-Connect Transport Router (and the interface attached to it) will be mapped to a separate routing table in the customer VPC, one that has its default route pointing to a Private VIF. The Internet Transport VR (and the interface attached to it) remains associated with a separate AWS routing table that has a default route pointing to the VPCs Internet gateway (IGW).
A quick look into how Versa Secure SD-WAN can orchestrate an SD-WAN cloud branch in AWS is below:
Versa Director, utilizing an AWS API connector, interrogates your AWS for your environment’s VPCs, subnets, images, etc, and presents them natively as pull-down choices when deploying a branch. Clicking “Continue” on the screen above will result in launching a Versa VOS™ (formerly FlexVNF) instance in your VPC, without having to interact with the AWS Console. As you can see, the Versa SD-WAN naturally maps to existing networking concepts within your AWS infrastructure – by segmenting the IGW and VGW into separate Transport Domains (mapped to separate WAN interfaces above), while extending the application aware traffic steering control and centralized management into your cloud.
This is just a quick look into how easy it is to extend your SD-WAN to the cloud and incorporate your VPC into your SD-WAN. For more information and access to the Versa Networks ESG Report validating our capabilities in AWS, download the report here.
Keep a lookout for the next set of blogs in this series where we will go into additional detail about Versa Head-Ends, CloudFormation templates, VRRP in the cloud, transit VPCs and more.
If you’re interested in seeing a demo reach out to us and our team will be more than happy to show you how we can easily transform your enterprise and extend your WAN to your cloud.
Trial
ROI
Contact