A network profile defines a group of networks and network settings that are available for a cloud account in a particular region or data center in vRealize Automation.

You typically define network profiles to support a target deployment environment, for example a small test environment where an existing network has outbound access only or a large load-balanced production environment that needs a set of security policies. Think of a network profile as a collection of workload-specific network characteristics.

What's in a network profile

A network profile contains specific information for a named cloud account type and region in vRealize Automation, including the following settings:
  • Named cloud account/region and optional capability tags for the network profile.
  • Named existing networks and their settings.
  • Network policies that define on-demand and other aspects of the network profile.
  • Optional inclusion of existing load balancers.
  • Optional inclusion of existing security groups.

You determine the network IP management functionality based on the network profile.

Note:

vRealize Automation supports one network profile for any given VM or VM cluster compute resource. If a VM or VM cluster compute resource has multiple networks and separate network profiles are selected for each, allocation will fail during template deployment. A VM or VM cluster compute resource can only support one network profile, not multiple network profiles.

Network profile capability tags are matched with constraint tags in cloud templates to help control network selection. Further, all tags that are assigned to the networks that are collected by the network profile are also matched with tags in the cloud template to help control network selection when the cloud template is deployed.

Capability tags are optional. Capability tags are applied to all networks in the network profile, but only when the networks are used as part of that network profile. For network profiles that do not contain capability tags, tag matching occurs on the network tags only. The network and security settings that are defined in the matched network profile are applied when the cloud template is deployed.

When using static IP, the address range is managed by vRealize Automation. For DHCP, the IP start and end addresses are managed by the independent DHCP server, not by vRealize Automation. When using DHCP or mixed network address allocation, the network utilization value is set to zero. An on-demand network allocated range is based on the CIDR and subnet size that is specified in the network profile. To support both static and dynamic assignment in the deployment, the allocated range is divided into two ranges - one for static allocation and another for dynamic allocation.

Networks

Networks, also referred to as subnets, are logical subdivisions of an IP network. A network groups a cloud account, IP address or range, and network tags to control how and where to provision a cloud template deployment. Network parameters in the profile define how machines in the deployment can communicate with one another over IP layer 3. Networks can have tags.

You can add networks to the network profile, edit aspects of networks that are used by the network profile, and remove networks from the network profile.

When you add a network to the network profile, you can select available networks from a filtered list of vSphere and NSX networks. If the network type is supported for the cloud account type, you can add it to the network profile.

In a VCF-based deployment, NSX network segments are created locally on the NSX-T network and are not created as global networks.

  • Network domain or Transport zone

    A network domain or transport zone is the distributed virtual switch (dvSwitch) for the vSphere vNetwork Distributed PortGroups (dvPortGroup). A transport zone is an existing NSX concept that is similar to terms like dvSwitch or dvPortGroup.

    When using an NSX cloud account, the element name on the page is Transport zone, otherwise it is Network domain.

    For standard switches, the network domain or transport zone is the same as the switch itself. The network domain or transport zone defines the boundaries of the subnets within vCenter.

    A transport zone controls which hosts an NSX logical switch can reach to. It can span one or more vSphere clusters. Transport zones control which clusters and which virtual machines can participate in the use of a particular network. Subnets that belong to the same NSX transport zone can be used for the same machine hosts.

  • Domain

    Represents the domain name for the machine. The domain name is passed to the vSphere machine customization spec.

  • IPv4 CIDR and IPv4 default gateway

    vSphere machine components in the cloud template support IPv4, IPv6, and dual stack IP assignment for network interfaces. For example, 192.168.100.14/24 represents the IPv4 address 192.168.100.14 and its associated routing prefix 192.168.100.0, or equivalently, its subnet mask 255.255.255.0, which has 24 leading 1-bits. The IPv4 block 192.168.100.0/22 represents the 1024 IP addresses from 192.168.100.0 to 192.168.103.255.

  • IPv6 CIDR and IPv6 default gateway

    vSphere machine components in the cloud template support IPv4, IPv6, and dual stack IP assignment for network interfaces. For example, 2001:db8::/48 represents the block of IPv6 addresses from 2001:db8:0:0:0:0:0:0 to 2001:db8:0:ffff:ffff:ffff:ffff:ffff.

    The IPv6 format is not supported for on-demand networks. For related information, see Using network settings in network profiles and cloud templates in vRealize Automation.

  • DNS servers and DNS search domains
  • Support public IP

    Select this option to flag the network as public. Network components in a cloud template that have a network type: public property are matched to networks that are flagged as public. Further matching occurs during cloud template deployment to determine network selection.

  • Default for zone

    Select this option to flag the network as a default for the cloud zone. During cloud template deployment, default networks are preferred over other networks.

  • Origin

    Identifies the network source.

  • Tags

    Specifies one or more tags assigned to the network. Tags are optional. Tag matching affect which networks are available for your cloud template deployments.

    Network tags exist on the network item itself, irrespective of the network profile. Network tags apply to every occurrence of the network they have been added to and to all network profiles that contain that network. Networks can be instanced into any number of network profiles. Regardless of network profile residency, a network tag is associated with that network wherever the network is used.

    When you deploy a cloud template, constraint tags in a cloud template's network components are matched to network tags, including network profile capability tags. For network profiles that contain capability tags, the capability tags are applied to all the networks that are available for that network profile. The network and security settings that are defined in the matched network profile are applied when the cloud template is deployed.

Network Policies

By using network profiles, you can define subnets for existing network domains that contain static, DHCP, or a mixture of static and DHCP IP address settings. You can define subnets and specify IP address settings by using the Network Policies tab.

When using NSX-V, NSX-T, or VMware Cloud on AWS, network policy settings are used when a cloud template requires the networkType: outbound or networkType: private or when an NSX network requires networkType: routed.

Depending on the associated cloud account, you can use network policies to define settings for the outbound, private, and routed network types and for on-demand security groups. You can also use network policies to control existing networks when there is a load balancer associated with that network.
Note: For information about using a VLAN transport zone to support VLAN segment specification for private NSX networks, see Network resources in vRealize Automation.

Outbound networks allow one way access to upstream networks. Private networks do not allow any outside access. Routed networks allow East/West traffic between the routed networks. The existing and public networks in the profile are used as the underlying or upstream networks.

Options for the following on-demand selections are described in the Network Profiles on-screen help and summarized below.

  • Do not create an on-demand network or on-demand security group

    You can use this option when specifying an existing or public network type. cloud templates that require an outbound, private, or routed network are not matched to this profile.

  • Create an on-demand network

    You can use this option when specifying an outbound, private, or routed network type.

    Amazon Web Services, Microsoft Azure, NSX, vSphere, and VMware Cloud on AWS support this option.

  • Create an on-demand security group

    You can use this option when specifying an outbound or private network type.

    A new security group is created for matched cloud templates if the network type is outbound or private.

    Amazon Web Services, Microsoft Azure, NSX, and VMware Cloud on AWS support this option.

Network policy settings can be cloud account type-specific. These settings are described in the on-screen signpost help and summarized below:

  • Network domain or Transport zone

    A network domain or transport zone is the distributed virtual switch (dvSwitch) for the vSphere vNetwork Distributed PortGroups (dvPortGroup). A transport zone is an existing NSX concept that is similar to terms like dvSwitch or dvPortGroup.

    When using an NSX cloud account, the element name on the page is Transport zone, otherwise it is Network domain.

    For standard switches, the network domain or transport zone is the same as the switch itself. The network domain or transport zone defines the boundaries of the subnets within vCenter.

    A transport zone controls which hosts an NSX logical switch can reach to. It can span one or more vSphere clusters. Transport zones control which clusters and which virtual machines can participate in the use of a particular network. Subnets that belong to the same NSX transport zone can be used for the same machine hosts. Transport zone types are overlay or VLAN. For information about using a VLAN transport zone for defining VLAN segments, see Network resources in vRealize Automation.

  • External subnet

    An on-demand network with outbound access requires an external subnet that has outbound access. The external subnet is used to provide outbound access if requested in the cloud template - it does not control network placement. For example, the external subnet does not affect the placing of a private network.

  • CIDR

    CIDR notation is a compact representation of an IP address and its associated routing prefix. The CIDR value specifies the network address range to be used during provisioning to create subnets. This CIDR setting on the Network Policies tab accepts IPv4 notation ending in /nn and containing values between 0 - 32.

  • Subnet size

    This option specifies the on-demand network size, using IPv4 notation, for each isolated network in a deployment that uses this network profile. The subnet size setting is available for internal or external IP address management.

    The IPv6 format is not supported for on-demand networks.

  • Distributed logical router

    For an on-demand routed network, you must specify a distributed logical network when using an NSX-V cloud account.

    A distributed logical router (DLR) is used to route east/west traffic between on-demand routed networks on NSX-V. This option is only visible if the account/region value for the network profile is associated to an NSX-V cloud account.

  • IP range assignment

    The option is available for cloud accounts that support NSX or VMware Cloud on AWS, including vSphere.

    The IP range setting is available when using an existing network with an external IPAM integration point.

    You can select one of the following three options to specify an IP range assignment type for the deployment network:
    • Static and DHCP

      Default and recommended. This mixed option uses the allocated CIDR and Subnet range settings to configure the DHCP server pool to support half of the address space allocation using the DHCP (dynamic) method and half of the IP address space allocation using the Static method. Use this option when some of the machines that are connected to an on-demand network require assigned static IP addresses and some require dynamic IP addresses. Two IP ranges are created.

      This option is most effective in deployments with machines that are connected to an on-demand network, where some of the machines are assigned static IPs and other machines have IPs dynamically assigned by an NSX DHCP server and deployments where the load balancer VIP is static.

    • DHCP (dynamic)

      This option uses the allocated CIDR to configure an IP pool on a DHCP server. All the IP addresses for this network are dynamically assigned. A single IP range is created for each allocated CIDR.

    • Static

      This option uses the allocated CIDR to statically allocate IP addresses. Use this option when a DHCP server is not required to be configured for the network. A single IP range is created for each allocated CIDR.

  • IP blocks

    The IP blocks setting is available when using an on-demand network with an external IPAM integration point.

    Using the IP block setting, you can add a named IP block, or range, to the network profile from your integrated external IPAM provider. You can also remove an added IP block from the network profile. For information about how to create an external IPAM integration, see Add an external IPAM integration for Infoblox in vRealize Automation.

    External IPAM is available for the following cloud account/region types:
    • vSphere
    • vSphere with NSX-T
    • vSphere with NSX-V
  • Network Resources - External network

    External networks are also referred to as existing networks. These networks are data-collected and made available for selection.

  • Network Resources - Tier-0 logical router

    NSX-T uses the tier-0 logical router as a gateway to networks that are external to the NSX deployment. The tier-0 logical router configures outbound access for on-demand networks.

  • Network Resources - Edge cluster

    The specified edge cluster provides routing services. The edge cluster is used to configure outbound access for on-demand networks and load balancers. It identifies the edge cluster, or resource pool, where the edge appliance is to be deployed.

  • Network Resources - Edge datastore

    The specified edge datastore is used to provision the edge appliance. This setting applies to NSX-V only.

Tags can be used to specify which networks are available to the cloud template.

Load Balancers

You can add load balancers to the network profile. Listed load balancers are available based on information that is data-collected from the source cloud account.

If a tag on any of the load balancers in the network profile matches a tag in a load balancer component in the cloud template, the load balancer is considered during deployment. Load balancers in a matched network profile are used when a cloud template is deployed.

For more information, see Using load balancer settings in network profiles in vRealize Automation and Networks, security resources, and load balancers in vRealize Automation.

Security Groups

When a cloud template is deployed, the security groups in its network profile are applied to the machine NICs that are provisioned. For an Amazon Web Services-specific network profile, the security groups in the network profile are available in the same network domain (VPC) as the networks that are listed on the Networks tab. If the network profile has no networks listed on its Networks tab, all available security groups are displayed.

You can use a security group to further define the isolation settings for an on-demand private or outbound network. Security groups are also applied to existing networks. You can also assign global security groups.

Listed security groups are available based on information that is data-collected from the source cloud account or added as an on-demand security group in a project cloud template. For more information, see Security resources in vRealize Automation.

Security groups are applied to all the machines in the deployment that are connected to the network that matches the network profile. As there might be multiple networks in a cloud template, each matching a different network profile, you can use different security groups for different networks.

Note:

In addition to specifying a security group, you can also select NSX networks (default) or vSphere networks or both. When you deploy a cloud template, vRealize Automation adds the allocated or specified security group to machine NICs that are connected to the allocated NSX network. Only machine NICs that are connected to an NSX network can be added to an NSX security group. If the machine NIC is connected to a vSphere network, the template deployment fails.

Adding a tag to an existing security group allows you to use the security group in a cloud template Cloud.SecurityGroup component. A security group must have at least one tag or it cannot be used in a cloud template. For more information, see Security resources in vRealize Automation and Networks, security resources, and load balancers in vRealize Automation.

More information about network profiles, networks, cloud templates, and tags

For more information about networks, see Network resources in vRealize Automation.

For examples of sample network component code in a cloud template, see Networks, security resources, and load balancers in vRealize Automation.

For sample network automation workflows, see the following VMware blog posts:

For more information about tags and tag strategy, see How do I use tags to manage Cloud Assembly resources and deployments.

For information about how to name machine NICs, see How can I configure a network interface controller name by using extensibility actions.