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 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.
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.
