In a series of posts, I’m discussing network automation features of vRealize Automation and NSX in combination with a Ubiquiti EdgeOS based router. In the first two posts I’ve covered setting up the basic network architecture and the required configuration steps in vRealize Automation:

In this third part we will configure a blueprint in vRA that will deploy a routed network to the NSX infrastructure. For more details on a routed network see this earlier post. The network architecture we’re building is depicted in the diagram:



In this post we will focus on the blueprint that will create the two VMs connected to the w.x.y.z/aa network.

Create the vRA blueprint

The first step in this process is of course creating a new blueprint. It’s important to configure the NSX settings in this blueprint otherwise we don’t have access to any of the dynamically created network constructs. This is done in the blueprint properties screen:

Create one or more VMs by dragging the vSphere VM type onto the canvas. Also drag an on-demand routed network construct to the canvas and link it to the routed network profile created earlier as explained this post: How to configure an NSX routed network profile in vRealize Automation.

The next step to link your VMs to this routed network profile:

Another important configuration step is that you are 100% sure the VMs are deployed to a reservation that has NSX network virtualization configured in a proper way. You can achieve this through a Reservation Policy:

The ReservationPolicy02-vSphere is linked to the reservation with the same name, that has the routed network profile available.

Actually it’s that simple, you’re all set and ready to deploy this blueprint. Of course you first have to publish the blueprint to the vRA catalog, I will not cover this in this article.

Deploy the blueprint and check the routing

So let’s just request the brand new blueprint. After the request from the vRealize Automation self-service portal, you will find all the required steps under execution information. This of course includes the creation of the routed network.

After a short while the newly deployed blueprint will appear as an item in vRA, the IP address(es) (configured based one of the network ranges of the routed network) is/are provided in the portal:

As you can see one of the network ranges in the network profiles changed its status to allocated:

Let’s have a look at the routing table on my EdgeRouter, to see if the new range is available in the routing table:

admin@ubnt:~$ show ip route ospf IP Route Table for VRF "default" O IA *> 172.16.101.0/24 [110/2] via 172.16.100.2, eth1.100, 02:02:24 O E2 *> 172.20.1.0/24 [110/0] via 172.16.100.2, eth1.100, 02:02:15 O E2 *> 172.30.1.80/29 [110/0] via 172.16.100.2, eth1.100, 00:24:18

And of course the NSX Edge ESG01 will display similar results:

esg01.viktorious.local-0> show ip route ospf O E2 172.20.1.0/24 [110/0] via 172.16.101.2 O E2 172.30.1.80/29 [110/0] via 172.16.101.2 O 192.168.178.0/24 [110/2] via 172.16.100.1

And as a final confirmation that everything works as expected, let’s open the website 172.30.1.82:

To see what is configured in NSX, open the DLR01 interface and see that vNIC #11 is added, and connected to a new logical switch with routed01172301024 in it’s name:

Also note that the first IP address in the range 172.30.1.81 is configured as the gateway interface.

So that’s it, I hope this one was helpful as well. In a follow up post we will see how to configure micro-segmentation in automated way and we will implemented the DMZ anywhere networking concept.