In the first two posts of this
series we looked at what could possibly go wrong when we tried to connect a service designed to face the Internet, to not one, not many, but lots of customers’ wide area networks (WANs). We learned that NAT was a great tool, but that it was only part of the solution. We also learned that to connect two networks which use the same addresses, we need an intermediate set of addresses to hide the two networks from each other. In this post, we’ll find some suitable addresses for that intermediate stage, and look at the scaling of this model for multiple customers connecting to multiple services.
In Part 1 of this series we looked at the problem Cloud Providers and their customers face when accessing provider services over their Wide Area Networks (WANs). In this second post in the series we’ll explore a number of possible solutions. In some instances, services were designed from the beginning to face multiple tenant networks, each with possible overlapping address space. Where this is the case, we don’t really need to “design” a solution, just ensure that our service, and the connectivity model which connects our tenant WAN environments to it, follows the way the service’s designer envisioned it.
In some cases of course, this isn’t the case, and we need to hide the complexity of those overlapping customer networks from our service, so that we don’t confuse or scare it. We’ll look at both scenarios in this post.
A number of Cloud Services require the transfer of large volumes of data. In the Cloud Provider world, that could be uploading VMs in the form of OVA files, ISO disk images, or sending backup data to a DRaaS service. Customers can connect their on-prem SDDCs to the Cloud Provider with only an Internet connection, and make use of these great services. How easy is that! In locations where the Internet is readily available, fast and reliable, this is great. But what about locations where that’s not the case? Well, that’s where the trusty WAN steps in. Using a Communication Provider’s services, customers can get direct network links to their Cloud Provider’s datacenters which, while more costly, may offer the speed and reliability which local Internet services lack.
Excellent, problem solved! We’ll just connect our services to our customers’ WANs and go back to watching Netflix, right? Hang on, surely it can’t be that simple? Of course not, for one thing, if the Internet is poor, how will we watch Netflix????
In Part 1 of this series we introduced the Route-Based VPN. Here in Part 2 we’ll look at the deployment steps for the NSX-V Edge. Because a likely use case for this is to connect an on-premises NSX-V environment to a VMC SDDC, we’ll touch on the setup for the VMC end too [Spoiler Alert].
With the introduction of NSX-T as the Software Defined Network (SDN) layer in VMware Cloud on AWS ("VMC") we gained the ability to create both traditional “Policy-Based” and the less common but arguably more powerful, “Route-Based” VPNs. Although some planning and design is necessary for either type of VPN between VMC sites, the actual configuration is quite straight forward. Fill in the fields on the SDDC console, click “Save”, repeat for the other site and you’re done. However, if the “other” site is not a VMC SDDC but instead an “on-prem” location running NSX-V, and you’re setting up a route-based VPN, things get a little more complicated. In this post we’ll look at the differences between the two VPN types, and in the second post in the series we’ll go through the steps necessary to set up a route-based VPN on an NSX-V Edge Service Gateway (“Edge”).
vCloud Director v9.5 introduced support for OrgVDC networks which could span multiple OrgVDCs in one, or more, Provider VDCs. While this is a powerful capability, it brought with it some new configuration workflows both within vCD and in the surrounding networking layers. My VMware colleagues Daniel Paluszek, Abhinav Mishra and Wissam Mahmassani wrote a series of great blog posts over on the VMware Cloud Provider Blog which explain these workflows and the different options they bring. I can’t take any credit for the posts, awesome though they are, but I do find myself regularly using them as a reference in workshops with VMware partners. I usually end up searching for the posts, and then sending links to them to the workshop attendees so they can read the content at their leisure.
To make that process easier, I decided to list them here so they’re easier to find, and, in order.
