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.

Network profile capability tags are matched with constraint tags in blueprints 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 blueprint to help control network selection when the blueprint 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 blueprint 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 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 blueprint 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.

  • 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 vCenter Single Sign-On domain for a target virtual machine. Domains are configured by a vCenter administrator during vSphere configuration. The domain determines the local authentication space in vCenter.

  • IPv4 CIDR and IPv4 default gateway

    vSphere cloud accounts, and vSphere machine components in the blueprint, support dual IPv6 and IPv4 internet protocol methods. 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 cloud accounts, and vSphere machine components in the blueprint, support dual IPv6 and IPv4 internet protocol methods. 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.

  • DNS servers and DNS search domains
  • Support public IP

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

  • Default for zone

    Select this option to flag the network as a default for the cloud zone. During blueprint 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 blueprint 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 blueprint, constraint tags in a blueprint'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 blueprint 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.

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.

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. Blueprints 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 blueprints 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.

  • 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 blueprint - 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 size of the on-demand network, using IPv4 notation, to create 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 this 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 point 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.

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 used in a load balancer component in the blueprint, the load balancer is considered during deployment. Load balancers in a matched network profile are used when a blueprint is deployed.

For more information, see Using load balancer settings in network profiles in vRealize Automation Cloud Assembly and Network, security, and load balancer design samples in vRealize Automation blueprints.

Security Groups

When a blueprint is deployed, the security groups in its network profile are applied to the machines 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.

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 blueprint, each matching a different network profile, you can use different security groups for different networks.

Adding a tag to an existing security group allows you to use the security group in a blueprint Cloud.SecurityGroup component. A security group must have at least one tag or it cannot be used in a blueprint. For more information, see Security resources and Network, security, and load balancer design samples in vRealize Automation blueprints.

More information about network profiles, networks, blueprints, and tags

For more information about network profiles, see other topics in this section of the help as well as WordPress use case: add network profiles.

For more information about networks, see Network resources.

For examples of sample network component code in a blueprint, see Network, security, and load balancer design samples in vRealize Automation blueprints.

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