This is part 2 of a series of posts in which I will discuss how to build a virtualized network infrastructure based using VMware NSX, connect it to VMware vRealize Automation (vRA) and deploy applications from vRA to this software defined infrastructure. In part 1 I’ve demonstrated how to build a routed network infrastructure using Ubiquiti EdgeOS and VMware NSX.

In this post we will connect vRA to NSX and define a routed network. The ultimate goal is to deploy a blueprint that includes one or more virtual machines that will be connected to this routed network, this will be explained in part 3 of this series. A routed network, in vRA terminology, is a new layer 2 subnet that is automatically deployed and connected to a Distributed Logical Router (DLR). After you’ve configured routing in a proper way (and we did this in part 1 of this series), the route to new subnet will automatically be advertised to your networking infrastructure so that VMs connected to this new L2 subnet have connectivity.

Before we can deploy these VMs from vRA, we have to go through the following steps:

Add an NSX endpoint to vRA; Let vRA gather information about the NSX environment; Create a routed network network profile in vRA; Link this new network profile to a new or existing reservation;

The new routed network will be deployed and connected to DLR01. After we’ve deployed a blueprint with (for example) two VMs, our network infrastructure will look like this:

Because we’re talking automation here, the deployment process is repeatable. This means we can deploy routed02, 03, 04 and so on…everytime with a new unique subnet, because we want to have connectivity for all the VMs. More on this, later in this article. First things first, so let’s connect NSX to vRA.

Connect NSX to vRealize Automation

Connecting NSX to vRealize Automation is a straightforward process. Add a new endpoint, enter the credentials of a service account and associate the NSX endpoint to a vCenter Endpoint.

Add the endpoint:

…and associate it to an existing vCenter Server endpoint:

A first is inventory collection for the new endpoint is automatically executed, after it has completed you’re ready to use the new endpoint.

Create a routed network profile in vRA

vRA supports three types of network profiles, that are all provided through NSX networking constructs:

External network, sometimes called existing network: this is a connection to an existing VLAN or VXLAN (on a logical switch), so the amount of network automation is limited here. Using an external network is only about automatically configuring an IP address, subnet, gateway, DNS, etc. An external network is used in a scenario where you just want to connect VMs to an existing distributed virtual portgroup (VLAN/VXLAN). You will also need an external network profile for the uplink definition of a DLR when you’re creating a routed network. Routed network, with this type of network vRA automatically deploys a new L2 VXLAN logical switch and connects it to an existing DLR. VMs deployed from vRA are connected to this new logical switch and will get all the required IP settings; NAT network, with this type of network vRA automatically deploys a Edge Service Gateway (ESG) and creates one or more NATed network that are behind the newly deployed ESG. If required you can automatically configure port forwarding rules as part of the deployment. IP configuration is also part in this type of deployment.

Note: An external network can also be used without NSX in your environment. For a routed and NAT network, NSX is required.

Ok, let’s have a closer look at a routed network. The first step in creating a routed network, is defining an external network profile. This network profile is used for the uplink of the DLR that will be used to connect your routed networks to. In our scenario the uplink network is the 172.16.101.0/24 network (called transit02 in my environment) as depicted in the network architecture picture. The external network profile configuration looks like this:

If necessary also define DNS settings. We don’t need any Network Ranges or IP Addresses in this specific scenario.

Now it’s time to define the routed network as detailled in the following screendump:

As you can use the routed network is linked to the created external network profile. You also have to define a subnet- and range subnet- mask. De subnet mask is the subnet mask for the entire network range as defined for this routed network, while the range subnet mask divides the subnet in individual ranges that are deployed as part of a vRA blueprint. Here you have to think about the number of VMs that will be connected to an individual range, the “range subnet mask” pulldown box provides some more information on this. For example a /29 network will provide 8 addresses, a /28 16 and /27 32. Note that you will always loose one IP address for the network address, one IP address for broadcast and one IP address for the gateway (that is configured as an uplink address on the DLR).

After defining the general settings, you can configure your DNS settings. The last step is to generate Network Ranges, this option is included in the last tab. In this example I’ve defined a /28 network, which results in 6 useable IP addresses per subnet, of course we will still loose one IP address to the router:

Link the routed network profile to a reservation

Before we can use the newly created routed network profile, we have to link it to a reservation. We have to go through a couple of steps here:

Link an NSX transport zone to the reservation; Link a DLR to the reservation and set the Network Profile for the DLR uplink, this is the external network profile, and;

Link this same external network profile to the reservation.

And…that’s it! Now we’re ready to deploy a blueprint that has a routed network configured. How this works will be discussed in a follow up post, so stay tuned!