Any corporate network thats larger than a very small business is likely going to have a routed network already. Segmenting networks improves performance and more importantly used for security purposes. Many compliance regulations such as PCI-DSS state that machines need to be segmented from each other unless there is a specific reason for them to be on the same network. For instance your corporate file server doesn’t need to communicate directly with your CRM database full of credit card numbers. The quickest way to fix this is to put these systems on different networks but this can be difficult to manage in a highly automated environment. Developers might need to spin up new applications which may need to be on different network segments from the rest of the environment. Its not very feasible to assume we can now spin up test and delete hundred of machines each day, but need the network team to manually create new network segments and tear them down each day. That wouldn’t be a nice thing to do to your network team.

Luckily NSX has the ability to create routed networks and vRealize Automation can leverage this, to automatically setup a new network when we deploy blueprints. The initial setup requires setting up an NSX edge and a transit network. This is done manually to get the environment prepared for the automation piece. The diagram below shows the pieces that are manually created vs the routed networks which are automatically created through vRealize Automation.

Use Case: A compliance regulation or pod design where services or applications are to be build in their own networks but are still able to communicate with the corporate network.

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 Routed. From here we create a network profile for our virtual machines to use. For my setup, I created three separate network profiles for this setup (Web, App, Database) which meant repeating this process three times.  If you’re trying to figure out how this will work, look at one side of the diagram above with a single router and three logical switches.

Give the network profile a name and description. Then be sure to select the Transit network as the external network profile. The external network profile is how the logical router you’ll be spinning up, will connect to the rest of the infrastructure. In our case we’re connecting it to the network hanging off of our NSX edge.

Enter a subnet mask, range subnet mask and Base IP. The range subnet mask made my brain hurt for a second until I looked at the next tab (IP Ranges).

If you look at the IP Ranges tab, you can see how the subnet mask and range subnet mask affect the network settings. Below we can see that I’m starting with the 10.10.72.1 (base IP) and creating multiple /29 subnets inside of my /24 subnet mask.

Once I was done with this process, I created two more network profiles so that I could have a different profile for App, Database and Web tiers. You don’t need to do this, but I wanted to show what was possible here. If I’m only spinning up 3 VMs in a new routed network, I have enough IP Addresses in my range, but I’ve chosen to use three separate networks.

Now we can go back to the Build Information tab and add our virtual machines into the blueprint. Add as many as makes sense to you for your environment. After you add them click the “edit” hyperlink in the network column.

Here you would select the network profile that you created earlier. I assigned my “App” vm to my “App” network profile, but you could assign all three VMs to the same network profile, it would just mean that they are all on the same network segment.

Repeat this process with the rest of your virtual machines in the blueprint, and then finish adding the customization settings such as post-deployment scripts  and actions. After this you should be able to publish the blueprint and add it to a catalog for your users to consume.

Request Item

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

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 is a new NSX edge that has been created automatically.

If we dive into that NSX edge, we will see several new interfaces. One of the interfaces is from the external network profile which is the NSX uplink interface. The rest of the internal interfaces should match up to the network profiles that you added in your multi-machine blueprint. I created three network profiles (App,Database,Web) so I see three of these. You may only see a single internal interface.

Now if we go look at our NSX logical switches, we can see that three new switches were created. Each of those switches are connected to the internal vNICs of the Distributed Logical Router that we just spun up.

Let’s move over and take a look at our virtual machines that were created. I’ve got a new edge appliance and my three VMs.

If I look at the IP Addresses of the new VMs, they should match up to three separate /29 networks.

When we look at the network configs of one of the VMs, we can see that we’ve got a /29 IP Address and a gateway that matches the interface on our distributed logical router. We can also ping the other VMs that were created in this blueprint as well as a public DNS Server to show that we have connectivity throughout. COOL HUH!?

Summary

vRealize Automation gives us some cool ways to deploy virtual machines but combining it with a solution like NSX give us even more power to deploy multi-tier apps. Micro-segmentation is too difficult to manage on a one by one basis, but with an automation solution in place these operations become feasible. Routed networks give us the ability to deploy tiered applications in their own networks to cut down on the amount of manual effort required by the networking team.