You’re network isn’t fully on IPv6 yet? Ah, well don’t worry you’re certainly not alone, in fact you’re for sure in the majority. Knowing this, you’re probably using some sort of network address translation (NAT). Luckily, vRealize Automation can help you deploy translated networks as well as routed and private networks with a little help from NSX.

A quick refresher here, a translated network is a network that remaps an IP Address space from one to another. The quickest way to explain this is a public and a private IP Address. Your computer likely sits behind a firewall and has a private address like 192.168.1.50 but when you send traffic to the internet, the firewall translates it into a public IP Address like 143.95.32.129. This translation can be used to do things like keeping two servers on a network with the exact same IP Address.

Use Case: A NAT’d network can be used to deploy an application multiple times with the same local IP Addressing. The application could still communicate on the network even though it has the same IP Address as another application.

Build It

If you haven’t already gone through the process of setting up NSX and connecting it to vRealize Automation, you should do this first. Assuming you’ve already done this then lets begin.

Login to vRA and add a new Multi-Machine Blueprint. Fill out the Blueprint information tab and then skip over to the Network tab where the magic starts.

Select the Transport Zone from the dropdown list. Then select the New Network Profile dropdown list and then select NAT. Give the new profile a name and description. Then select an external network profile. This should be your transit network that connects the newly created NSX Edge routers to your NSX edge that was created earlier. The NAT type I chose “One-to-Many” but you could do a One-to-One mapping if you needed every address to be translated to separate addresses.

Next select the IP Ranges tab. Create a new network range and a set of starting and ending IP Addresses. These will be assigned to the virtual machines when they’re provisioned in this new network.

Now we go to back to the Build Information tab. Select the Add Blueprints option to select a blueprint that you’ve already created. You can do this several times to add many virtual machines to your multi-machine blueprint. In my case, I’ve added only a pair of servers to simulate a multi-tiered app.

Once you’ve added your machines, click the hyperlink under network. Select your network profile that we created in the previous steps.

Once this is done you can finish up your blueprint setup with any additional configurations you might want to add such as post deployment scripts, Lease settings, Build Profiles or actions. Save the blueprint and publish it. Assign the blueprint to a service and grant entitlements. All of this is outside the scope of this article but is a standard process for deploying blueprints in vRealize Automation 6.

Request Item

What are you waiting for? Go request your new catalog item. For this test I’m using the “Tiered NAT” item we just created.

I’ve requested a pair of multi-tiered apps to show how the IP Addressing can be reused for each multi-tiered app.

Wait for the VMs to provision and then go check your vCenter to see what happened! The first thing you might notice that that in your NSX UI there are new NSX edges that has been created automatically.

If we take a look at the first NSX edge interfaces, we’ll see that there is an internal interface and an uplink. The uplink will have at least two IP addresses. One of which will be used for the translation of the internal addresses.

If we move over to the NAT tab, we’ll see that the internal IP Address range is being translated to one of the uplink interface’s IP Addresses.

If we were to look at the second edge interface, you’ll notice that the internal IP Addresses are identical, but the uplink IP Addresses are different. The same range will be translated to a different IP Address.

Now that you’ve seen some of the coolness, you probably aren’t surprised that a new logical switches have been created. This logical switch is connected to the internal interface of the new NSX edges.

Testing

In my vRA workloads cluster, I’ve got my new pair of NSX edges and a two pair of virtual machines that are part of my NAT test. 

If we console into our first vm (Hollow-32) we notice the IP Address and subnet mask of 10.10.71.1 and we can ping a public IP address confirming that we have network connectivity.

If I then console into the first VM created in the second multi-tier app, we see that it has the same IP Address and can also communicate on the network. This is possible without issue, because we’ve translated the addresses so that other machines don’t see these addresses. They instead will see the 10.10.80.X address.

Summary

If I had a nickel for every time I heard a customer say that they wanted to have a test lab or application that had Identical settings including network, I’d be able to spend a fun day at the arcade. (Qbert would be my game of choice.) vRealize Automation 6 combined with NSX and NAT will allow you to do this.