vRealize Automation 8: Network Profiles – Routed

Table of Contents:

Tags:

Understanding Routed Network Policies in vRealize Automation

The next type of Network Policy we want to talk about is called Routed Network Policy. If you have worked with vRealize Automation 7 before, you might notice that Routed Network Policies correspond to Routed Networks in vRA 7.

Hence you use a routed network policy when there is a need for end-to-end routable access with unique IP addresses. When deploying a blueprint with a routed network policy referenced, vRealize Automation will instruct NSX to connect the newly created network to the existing DLR and configure the DLR in such a way that the newly created network is routed to the upstream gateway.

Hence, vRealize Automation dynamically creates a network with different subnets and a routing table. Routed networks are a valid choice if there is end-to-end routable access with unique IP addresses needed.

IP Address Assignment in Routed Networks

Routed network polices support static and dynamic IP address assignment. If you prefer static IP address assignment, consider the following items to be configured.

Guest customization specification – IP addresses will be assigned using the guest customization specification. Without configuring this, IP addresses will be reserved from the pool, but they will not be applied to the provisioned machine.

VMware tools – behind the scenes, the configuration of virtual machines with new IP addresses happens with the VMware tools. Dynamic IP address work as well. In this case, there will be a DHCP server for the newly created subnet.

A routed network can be depicted as follows:

The image is a simplified diagram of a network infrastructure, showing a multi-tier architecture. There are three horizontal layers labeled "Web," "Application," and "Database." Each layer consists of two virtual machine (VM) icons, symbolizing the servers or instances in that tier. Lines connect the VMs from each layer to a central point, which then connects to a "Tier 1 LR" icon, symbolizing a Tier 1 Logical Router. Another line connects this Tier 1 LR to a "Tier 0 LR" icon, indicating a Tier 0 Logical Router, which is connected to an outward-pointing arrow, symbolizing the external network or Internet access point. The layout represents the flow of data from the database tier up through the application and web tiers to the internet.

Configuring a Routed Network Policy for Network Connectivity

In order to configure a routed network policy, there are a couple of steps to be done:

First, a network profile must be created. We have shown this in the blog post before, so will skip the instructions here.

Second, make sure, there is a network with a routable network range configured if you want to have external network connectivity (Tier0 LR).

Next, on your network profile change to the Network Polices tab and perform the following configuration:

  • Select „Create an on-demand network“
  • Choose a transport zone (A transport zone controls which hosts an NSX logical switch can reach to. It can span one or more vSphere clusters. Transport zones dictate which clusters and, therefore, which virtual machines can participate in the use of a particular network)
  • Provide a CIDR range: The network address range to be used during provisioning to create isolated subnets. The CIDR address should be large enough, for example 192.168.0.0/16, to create multiple isolated subnets in a deployment.
  • Specify the Subnet size. For example a /24 network provide 256-2=254 IP addresses.
  • Specify the Distributed Logical Router
  • Define the IP range assignment:DHCP (dynamic) – Uses the allocated CIDR to configure an IP pool on a DHCP server. All the IP addresses for this network are dynamically assigned.Static – Uses the allocated CIDR to statically allocate IP addresses. Use this option when no DHCP server is configured for this network.Static and DHCP – Using the CIDR and Subnet range settings, the DHCP server pool is configured to support half of the address space allocation using the DHCP method and half of the IP address space allocation using the Static method. Use this option when some of the machines connected to the on-demand network require assigned, static IPs and some require dynamic IPs.
  • External network
  • Edge cluster: Identifies the edge cluster or resource pool where the edge appliance is to be deployed.
  • Edge datastore: Identifies the edge datastore used to provision the edge appliance.
The image is a screenshot from vRealize Automation 8, showing the "Network Policies" configuration tab. This interface section is for defining network properties in a cloud environment. The main options are to create on-demand networks and specify network settings. The selected option is "Create an on-demand network" with a "Transport zone" field populated with 'GlobalTZ', a "CIDR" field with the value '192.168.0.0/16', a "Subnet size" dropdown menu set to '/24 (<254 IP addresses)', a "Distributed logical router" field with 'DLR1', and "IP range assignment" set to 'Static and DHCP'. Below, there's an unselected option to "Create an on-demand security group". The "Network Resources" section lists an "External network" field with a placeholder 'BundesagenturVLAN-41', and the "Compute Resources" section has an "Edge cluster" field named 'Spielwiese' and an "Edge datastore" field named 'Labs'. At the bottom, "SAVE" and "CANCEL" buttons are displayed.

Once, this has been done, we can continue with configuring a blueprint. The following code snipped shows how to setup a blueprint that uses a NSX network of type „routed“.

formatVersion: 1
inputs:
  name:
    type: string
    title: VM Name
    description: Name of the virtual machine
resources:
  Cloud_Machine_1:
    type: Cloud.Machine
    properties:
      flavor: small
      image: Ubuntu1804
      cloudConfig: |
        #cloudconfig
        repo_update: true
        repo_upgrade: all
        package_update: true
        package_upgrade: all
        hostname: ${input.name}
        manage_etc_hosts: true
      networks:
        - network: '${resource.Cloud_NSX_Network_1.id}'
      name: Ubuntu
  Cloud_NSX_Network_1:
    type: Cloud.NSX.Network
    properties:
      networkType: routed

Once provisioned the deployment can be visualized as follows:

The image is a user interface screenshot from vRealize Automation 8, showing the "Request Details" section with progression tabs for "NETWORK ALLOCATION," "MACHINE ALLOCATION," "NETWORK PROVISIONING," and "MACHINE PROVISIONING." The "NETWORK ALLOCATION" tab is active. The interface is divided into multiple sections. The first section, titled "Request: Cloud_NSX_Network_1," lists the request type as "Allocation," network type as "ROUTED," and shows no constraints. Below, a "Project: Playground" section indicates no network, storage, or extensibility constraints, associated with "Region: SC labs/SCLABS." Further down, there are network profile sections. "Profile: NP Routed" is selected for allocation, associated with the subnet "BundesagenturVLAN-41." Adjacent to it are profiles "Profile: np_vlan41" and "Profile: np41," both highlighted in red, indicating an error or warning, with the message "Network profile isolation type 'NONE' does not satisfy network type 'ROUTED'." The screenshot also displays a toggle for "Dev mode" at the top-right corner, currently turned off.

If you go to the Deployment overview, you can see the created on-demand networks as well.

The image is a snapshot from the vRealize Automation 8 interface, detailing two deployment summaries. The first deployment, named "Routed 2," has no description and is part of the "Playground" project requested by a user named "guido." It consists of "2 Resources," labeled "vra-0057" and "vra-0058," was created "18 minutes ago," has a status of "On," is assigned an IP address "192.168.1.130," and is noted to "Never expire." The second deployment, named "Routed Test," also has no description, belongs to the "Playground" project, was requested by "guido," includes "2 Resources," labeled "vra-0056" and "vra-0055," was created "a day ago," has a status of "On," has an assigned IP of "192.168.0.130," and similarly is set to "Never expire." Each summary has an "ACTIONS" dropdown menu for further options. The overall theme indicates a management console where network-related configurations and resources are monitored and managed.

Autor

Dr. Guido Söldner

Geschäftsführer

Guido Söldner ist Geschäftsführer und Principal Consultant bei Söldner Consult. Sein Themenfeld umfasst Cloud Infrastruktur, Automatisierung und DevOps, Kubernetes, Machine Learning und Enterprise Programmierung mit Spring.