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

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

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

IPv4 and IPv6 support in VMware Aria Automation networks

VMware Aria 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.

You can assign an IPv6 address space to single and dual stacked workloads when an IPv6 address is requested per integration with an external IPAM system. This capability requires that the integrated external IPAM plug-in also supports IPv6.

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 VMware Aria 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 VMware Aria Automation IPAM SDK - for example one of the Infobox plug-ins that are available for download from the VMware 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 VMware Aria 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 VMware Aria Automation.

In addition to the above VMware Aria Automation external IPAM options, you can also specify a VMware Aria Automation 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 Automation Assembler.

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 VMware Aria Automation cloud templates.

For examples of populated cloud templates that contain network component data, see Network, security group, and load balancer resource examples in Automation Assembler.

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 Automation Assembler.

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 Automation Assembler.

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 Automation Assembler.