Using network settings in network profiles and cloud templates in vRealize Automation

You use networks and network profiles in vRealize Automation to help define the behavior of network provisioning for your deployments.

In vRealize Automation, you can define cloud-specific network profiles. See Learn more about network profiles in vRealize Automation.

Using network and network profile settings, you can control how network IP addresses are used in vRealize Automation cloud templates and deployments.

IPv4 and IPv6 support in vRealize Automation networks

vRealize Automation networks support single stack IPv4, single stack IPV6, or dual stack IPv4 and IPv6.

IPv6 is supported for existing vSphere networks and existing NSX networks.

IPv6 is not supported for load balancers, NSX on-demand networks, or external third-party IPAM providers such as Infoblox.

VLAN segments and private NSX-T networks

You can specify VLAN segments for private NSX on-demand network when the network segments are used with a Policy API-type of NSX-T cloud account. For information on supported configurations and network profile requirements, see Network resources in vRealize Automation.

External IPAM provider support

In addition to the supplied internal IPAM support, you can use an external IPAM provider to dynamically or statically allocate IP address for networks - as IP ranges for existing networks in your cloud template designs and deployments and IP blocks for on-demand networks in your cloud template designs and deployments. You can use external IPAM derived from an external provider integration that is based on the vRealize Automation IPAM SDK - for example one of the Infobox plug-ins that are available for download from the vRealize Automation Marketplace.

Support for external IPAM providers, such as Infoblox, is available for vendor-specific IPAM integration points that you create by using the Infrastructure > Connections > Add Integration > IPAM menu sequence.

Options for defining external IPAM provider address information is available by using the Add IPAM IP Range option on the Network Policies > Add IPAM IP Range page.

For information about how to create an external IPAM integration point, see How to configure an external IPAM integration in vRealize Automation. For an example of how to create an IPAM integration point for a specific IPAM vendor, see Tutorial: Configuring a provider-specific external IPAM integration for vRealize Automation.

In addition to the above vRealize Automation IPAM options, you can also specify a vRealize Orchestrator extensibility action in a cloud template to use a Network Configure event topic. For more information about this related IPAM method, see Event topics provided with Cloud Assembly.

Network types

A network component in a cloud template is defined as one of the following networkType types.

Network type	Definition
existing	Selects an existing network that is configured on the underlying cloud provider, such as vCenter, Amazon Web Services, and Microsoft Azure. An existing network is required by the outbound on-demand network. You can define a range of static IP addresses on an existing network.
public	Machines on a public network are accessible from the Internet. An IT administrator defines these networks. The definition of a public network is identical to that of an existing network for networks that allow network traffic to occur along public networks.
private	An on-demand network type. Limits network traffic to occur only between resources on the deployed network. It prevents inbound and outbound traffic. In NSX, it can be equated to on-demand NAT one-to-many.
outbound	An on-demand network type. Limits network traffic to occur between the compute resources in the deployment but also allows one-way outbound network traffic. In NSX, it can be equated to on-demand NAT one-to-many with external IP.
routed	An on-demand network type. Routed networks contain a routable IP space divided across available subnets that are linked together. The virtual machines that are provisioned with routed networks, and that have the same routed network profile, can communicate with each other and with an existing network. Routed networks are an on-demand network type that is available for NSX-V and NSX-T networks. Microsoft Azure and Amazon Web Services provides this connectivity by default. A routed network is only available for cloud template specification in a Cloud.NSX.Network network component.

For more information, see More about network resources in vRealize Automation cloud templates.

For examples of populated cloud templates that contain network component data, see Networks, security resources, and load balancers in vRealize Automation.

Sample network scenarios

You can expect the following behavior when you deploy a cloud template that uses the following network profile configuration.

Network type or scenario	No network profiles available for cloud zone	Network profiles available for cloud zone
No network	If no network is specified in the cloud template, a random network is selected from the same provisioning region as the compute. Preference is given to networks that are labeled as default. If no networks exist in an available provisioning region, provisioning fails.	A network is selected from a matched network profile. Preference is given to networks that are labeled as default. If none of the network profiles meet the criteria, provisioning fails.
Existing network	If the network component in the cloud template contains constraint tags, those constraints are used to filter the list of available networks. Constraint tags in the cloud templatefd's network component are matched to network tags and, if available, network profile constraint tags. From the filtered list of networks, a single network is selected from the same provisioning region as the compute. Preference is given to networks that are labeled as default. If after filtering based on constraints there are no networks in the provisioning region, provisioning fails.	A network is selected from a matching network profile. Preference is given to networks that are labeled as default. If none of the network profiles meet the criteria, provisioning fails. Network constraints can be used to filter existing networks in the profile based on their pre-assigned tags.
Public network	If the network has constraints, those constraints are used to filter the list of available networks that have the supports public IP attribute set. From the filtered list of networks, a random network is selected from the same provisioning region as the compute. Preference is given to networks that are labeled as default. If after filtering based on constraints there are no public networks in the provisioning region, provisioning fails.	A network with the supports public IP attribute is selected from a matching network profile. Preference is given to networks that are labeled as default. Network constraints can be used to filter existing public networks in the profile based on their pre-assigned tags.
Private network	Provisioning fails because private networks require information from a network profile.	A new network or new security group is created based on settings in the matched network profile. Network constraint tags can be used to filter network profiles and networks.
Outbound network	Provisioning fails because outbound networks require information from a network profile.	A new network or new security group is created based on settings in the matched network profile. Network constraint tags can be used to filter network profiles and networks.
On-demand routed network	Provisioning fails because routed networks require information from a network profile.	For NSX-V we need DLR (Distributed Logical Router) selection. For NSX-T and VMware Cloud on AWS, we require similar on-demand settings as private and outbound.
Example Wordpress use case with existing or public networks	Provisioning occurs as described for an existing network or public network.	See above descriptions for existing network and public network behavior. See Tutorial: Setting up and testing multi-cloud infrastructure and deployments in Cloud Assembly.
Example Wordpress use case with existing or public networks and private or outbound networks	Provisioning fails because the network requires information from a network profile.	See above descriptions for a private network and an outbound network. See Tutorial: Setting up and testing multi-cloud infrastructure and deployments in Cloud Assembly.
Example Wordpress use case with load balancer	Provisioning fails because a load balancer requires information from a network profile. Provisioning can occur when existing load balancers are present.	A new load balancer is created based on the network profile configuration. You can specify an existing load balancer that has been enabled in the network profile. Provisioning fails if you request an existing load balancer, but none meet the constraints in the network profile. See Tutorial: Setting up and testing multi-cloud infrastructure and deployments in Cloud Assembly.