In vRealize Automation, cloud administrators can view and edit the network resources that have been data-collected from the cloud accounts and integrations that are mapped to your project.

After you add a cloud account to your Cloud Assembly infrastructure, for example by using the Infrastructure > Connections > Cloud Accounts menu sequence, data collection discovers the cloud account's network and security information. That information is then available for to use in networks, network profiles, and other definitions.

Networks are the IP-specific components of an available network domain or transport zone. If you're an Amazon Web Services or Microsoft Azure user, think of networks as subnets.

You can display information about the networks in your project by using the Infrastructure > Resources > Networks page.

The Cloud Assembly Networks page contains information such as:
  • Networks and load balancers that are defined externally in the network domain of your cloud account, for example in vCenter, NSX-T, or Amazon Web Services.
  • Networks and load balancers that have been deployed by the cloud administrator.
  • IP ranges and other network characteristics that have been defined or modified by your cloud administrator.
  • External IPAM provider IP ranges for a particular address space in an provider-specific external IPAM integration.

For more information about networks, see the following information, signpost help for various settings on the Networks page, and Learn more about network profiles in vRealize Automation.

Networks

vSphere networks, regular NSX networks, and global (federated) NSX networks are supported.

You can view and edit networks and their characteristics, for example to add tags or remove support for public IP access. You can also manage network settings such as DNS, CIDR, gateway, and tag values. You can also define new, and manage existing, IP ranges within a network.

For existing networks you can change the IP range and tag settings by selecting the network's checkbox and selecting either Manage IP Ranges or Tags. Otherwise you can select the network itself to edit its information.

Tags provide a means for matching appropriate networks, and optionally network profiles, to network components in cloud templates. Network tags are applied to every instance of that network, regardless of any network profiles in which the network may reside. 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. Network tag matching occurs with other components in the cloud template after the cloud template has been matched with one or more network profiles.

Machine tags are defined in the cloud template and apply to the machine if deployed to a vCenter. Machines that are connected to an NSX-T local manager or global manager are also tagged in the cloud template. Note that machine tagging is different than machine NIC (network interface) tagging.

  • Using global (federated) NSX networks

    NSX-T global networks are networks that are defined by the NSX-T global manager and apply to one or more NSX-T local managers. For global networks, existing and public networks are supported for NSX-T global manager and local manager cloud accounts and the vCenter cloud accounts that are associated to the local managers. Local manager representation of stretched networks is defined within a transport zone. The transport zone is an NSX-T local manager construct that defines the span of NSX-T networks for vCenter Server hosts and clusters.

    Cloud Assembly enumerates, or data collects, existing and public networks. You can create a global network by adding an existing or public network on an NSX-T global manager. The global network can then be consumed by all the associated local managers. Global networks can span one, all, or a subset of the associated local managers.

    You can provision a machine on a global network by using a static IP assignment. DHCP is not supported.

    You can create the following types of global networks on a global manager:
    1. Overlay - an overlay network is associated with a Tier-0/Tier-1 local manager and automatically stretches to all the sites connected to the Tier-0/Tier-1 local manager. For each local manager, the default overlay transport zone is used.
    2. VLAN - a VLAN network applies to a single local manager and the transport zone can be manually selected.

    Global networks are listed on the Infrastructure > Resources page with all the cloud accounts that they apply to.

    The following Day 2 operations are supported for global networks:
    • Reconfigure a network in a cloud template definition from a global network to a local network and vice versa.
    • Scale-out/scale-in of machines on global networks.

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

  • Using VLAN segments in non-federated NSX networks

    You can provision NSX-T VLAN segments by specifying one or more VLAN IDs on a private NSX network type. Use this technique when, for example, your overall design prohibits you from provisioning overlay networks on NSX-T. This option requires that you select a VLAN transport zone in a supporting network profile.

    When using non-federated networks, you can provision private NSX on-demand VLAN segments when the network segments are used with a Policy API-type of NSX-T cloud account. VLAN segments are not connected to a Tier-1 router, therefore only private networks support VLAN segment specification. Once created, VLAN segments that are provisioned by vRealize Automation can also be used as existing networks in other VMware cloud templates.

    To use VLAN segments, you must first configure the intended network profile to allow subnet isolation for the on-demand network. You must specify a VLAN transport zone in the network profile. If you specify an overlay transport zone, the network profile cannot be used for VLAN specifications. An example of VLAN transport zone selection in a network profile is shown below. For related information about configuring network profiles, see Learn more about network profiles in vRealize Automation.

    choose a VLAN-backed transport zone

    You specify one or more VLAN segments, or arrays of VLAN IDs, by using the vlanIds property in the Cloud.NSX.Network component in the VMware cloud template YAML. To specify multiple vlanIds values in the private network Cloud.NSX.Network component, use a separate row entry for each value. The vRealize Automation API requires that you specify multiple VLAN values in a comma-separated list, but using that format in the cloud template YAML is unsupported. The supported VLAN values range between 0 to 4094. For sample cloud template YAML code, see Networks, security resources, and load balancers in vRealize Automation.

IP Ranges

Use an IP range to define or make changes to the start and end IP address for a particular network in your organization. You can display and manage IP ranges for listed networks. If the network is managed by an external IPAM provider, you can manage IP ranges in connection with the associated IPAM integration point.

Click New IP Range to add an additional IP range to the network. You can specify an internal IP range, or if there is a valid IPAM integration available you can specify an External IP range.

You cannot include the default gateway in an IP range. The subnet IP range cannot include the subnet gateway value.

If you are using an external IPAM integration for a particular IPAM provider, you can use the External IP range to select an IP range from an available external IPAM integration point. This process is described within the context of an overall external IPAM integration workflow at Configure a network and network profile to use external IPAM for an existing network in vRealize Automation.

Note: When an IP range from an external IPAM provider is deleted in the external IPAM application, the IP range is automatically deleted during enumeration in vRealize Automation. The deleted IP range is no longer visible or available for network association in vRealize Automation, thus avoiding orphaned IP address ranges.

vRealize Automation allows you to apply and manage an IP address range across multiple vSphere and NSX networks. Shared IP range support is provided for both internal and external IPAM. You can set a single IP range on an NSX stretch network such that machines on that network can use IP addresses that are assigned from the single IP address even if they are deployed to different vCenters.

IP Addresses

You can see the IP addresses that are currently used by your organization and display their status, for example available or allocated. The IP addresses that are displayed are either IP addresses that are managed internally by vRealize Automation or IP addresses that are designated for deployments that contain an external IPAM provider integration. External IPAM providers manage their own IP address allocation.

If the network is managed internally by vRealize Automation, and not by an external IPAM provider, you can also release IP addresses.

When using internal IPAM and releasing IP addresses, for example after deleting a machine that had been using the IP addresses or clicking Release IP address for a selected network, there is a wait period between when the unused addresses are released and when they become available for reuse. The wait period, or release timeout period, allows the DNS cache to clear. The IP addresses can then be allocated to a new machine. By default, the IP address release wait period is 30 minutes. You can change the wait period by clicking the Settings option in the upper right corner of the Networks page and changing the Release timeout value.
  • During the release timeout period, relevant IP addresses are listed as released. When the release timeout period has expired, they are listed as available.
  • The system checks every 5 minutes for newly released IP addresses, so even if the release timeout value is 1 minute it can take between 1 and 6 minutes for released IP addresses to become available, depending on when the last check was run. The 5 minute checking interval applies to all values other than 0.
  • If you set the release timeout value to 0, IP addresses are released immediately and become available immediately.
  • The release timeout value applies to all cloud accounts in the organization.

Updating vSphere networks after NSX migration to C-VDS

For information about updating vSphere networks in vRealize Automation after NSX-T migration from N-VDS to C-VDS, see Updating networking resources in vRealize Automation after N-VDS to C-VDS migration in NSX-T.

Load Balancers

You can manage information about available load balancers for the account/region cloud accounts in your organization. You can open and display the configured settings for each available load balancer. You can also add and remove tags for a load balancer.

For more information about using load balancers in cloud templates, see More about load balancer resources in vRealize Automation cloud templates.

Network Domains

The network domains list contains related and non-overlapping networks.