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 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 thepage.
- 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.
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:
- 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.
- VLAN - a VLAN network applies to a single local manager and the transport zone can be manually selected.
Global networks are listed on thepage 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.
You specify one or more VLAN segments, or arrays of VLAN IDs, by using the
vlanIdsproperty in the
Cloud.NSX.Networkcomponent in the VMware cloud template YAML. To specify multiple
vlanIdsvalues in the private network
Cloud.NSX.Networkcomponent, 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.
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.
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.
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.
- 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.
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.
The network domains list contains related and non-overlapping networks.