cloud accounts support ip address assignment in a network profile

vRealize Automation 8: Networks Part 2

von guidosoeldner | Jan 4, 2020 | Allgemein , Automation , Guido Soeldner , vRA , vRealize | Keine Kommentare

As discussed in the last blog post, vRealize Automation allows to manage networks and their configuration settings in an intuitive and comfortable manner. Administrators have an overview over all networks imported from the underlying Cloud Accounts and are able to centrally manage stuff like CIDR Ranges, DNS settings, Gateways and so on.

Besides, administrators can use the IPAM built-in functions of vRA if they don’t have a dedicated IPAM solution like Infoblox.

Perform the following steps to manage IP ranges:

• Within the Networks page, select the network for which you want the IP ranges to be configured and click on „MANAGE IP RANGES“
• Click on [+ NEW IP RANGE]

• Provide a Name for the IP Range
• Optionally, provide a description
• Enter the Start IP address
• Provide the End IP address

Click on Create

IPAM Considerations

Once you have saved your new IP range, you can change to the IP Ranges tab and have an overview about all your configured IP Ranges.

However, there are some caveats in order to use the internal IP Ranges and hence you have to make sure that the following requirements are fulfilled:

• First, you need the VMware Tools installed on the Linux machine
• You need to setup a Guest specification in vSphere
• You have to configure the blueprint to use the guest specification
• You have to change the Network Assignment to Static on the blueprint

The first two items should be easy to be configured or are most likely already set up properly. The following code shows the necessary configuration on the blueprint.

Once you have accomplished these configuration settings, you can monitor the assigned IP addresses:

Network Load Balancers

When you have NSX integrated, the Network section will also display the load balancers that can be used for provisioned resources.

However, except than setting tags (which is optional), no configuration has to be done here.

Last but not least, the Network Domain section will give you an overview over containers or groupings of related networks. Networks in the network domain are related and non-overlapping. Term equivalents:

• AWS = VPC (virtual private cloud)
• Microsoft Azure = Virtual network
• vSphere = Network

Kommentar absenden Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kommentar *

Meinen Namen, meine E-Mail-Adresse und meine Website in diesem Browser für die nächste Kommentierung speichern.

Twitter Feed

Recent posts.

• VMware vSphere Storage from DataCore – DataCore SANsymphony PSP17 news
• vSphere 8 – VM configuration object stored on a VVOL datastore
• NSX 4.0.1.x Stateful Active/Active T0 Drawbacks, can it be improved !?
• Circumventing NSX Gateway Firewall Settings without any Security Privileges
• VMware vSphere Permission Propagation issue

Recent Comments

• Best 28 Nsx-t Context Profile - Cẩm Nang Tiếng Anh bei NSX-T, Distributed Firewall (DFW), ZTNA and Spoofing
• Enterprise Management Associates Evaluates Serverless Technologies – EMA Top 3 Research Rep... - 艾德資訊 bei Serverless Technologies in the Enterprise – EMA Top 3 Market Guide
• Enterprise Management Associates Evaluates Serverless Technologies – EMA Top 3 Research Rep... - 艾德资讯网 bei Serverless Technologies in the Enterprise – EMA Top 3 Market Guide
• How To Learn vRealize Automation #vRA – vRA4U Blog – vRealize Automation & vRealize Orchestrator bei Persönliches
• Bericht vom CloudFoundry Summit in Basel am 11. Oktober | Söldner Consult GmbH bei Cloud Foundry Summit – 2018, Basel
• Januar 2024
• Dezember 2023
• September 2023
• Februar 2023
• Januar 2023
• Dezember 2022
• Januar 2022
• Dezember 2021
• November 2020
• Oktober 2020
• September 2020
• August 2020
• Januar 2020
• Dezember 2019
• November 2019
• Oktober 2019
• Februar 2019
• November 2018
• Oktober 2018
• Februar 2018
• Dezember 2017
• Oktober 2017
• Februar 2017
• Dezember 2016
• November 2016
• Oktober 2016
• September 2016
• August 2016
• Februar 2016
• Januar 2016
• November 2014
• Oktober 2013
• August 2013
• Artificial Intelligence
• CloudFormation
• Constantin Soeldner
• FredHantelmann
• Gerhard Glenk
• Guido Soeldner
• Jens Soeldner
• JensSoeldner
• NSX ALB (AVI)
• Pivotal Cloud Foundy
• Thomas Drilling
• Uncategorized
• vCenter Orchestrator
• Windows Server
• Feed der Einträge
• Kommentare-Feed
• WordPress.org

Want to Unlock All Questions for this Exam?

Full Exam Access, Discussions, No Robots Checks

You've Reached Your Free 2V0-31.21 Exam Questions Limit. Upgrade to Contributor Access to Receive All Exam Questions

• 31 days 1.45 / day
• Full Exam Access
• Community Discussions
• PDF Download
• No Captcha / Robot Checks
• Support ExamTopics
• 365 days 0.18 / day

Get Access to All Our Exams

Get unlimited contributor access to the all examtopics exams, get it certification.

Unlock free, top-quality video courses on ExamTopics with a simple registration. Elevate your learning journey with our expertly curated content. Register now to access a diverse range of educational resources designed for your success. Start learning today with ExamTopics!

Log in to ExamTopics

Contributor access.

Want to Unlock Features That Will Help You Study for 2V0-31.21?

By buying Contributor Access for yourself, you will gain the following features:

Network Automation with Cloud Assembly and NSX – Part 3

Updated April, 2021

Welcome back for part three of a four part series on Network Automation with Cloud Assembly and NSX .  In the previous two posts, I covered how to setup Cloud Accounts, verify and configure your initial network profile, then showed how to create on-demand networks and use existing or provider networks.  For this post, I will cover using security groups plus private and routed network types that can be configured in Cloud Assembly.  If you happened upon part 3 without looking at the first 2 posts, I recommend reading though part 1 and part 2 before going through this post.

NSX Security Groups

NSX Security groups are one method which are used to isolate VMs constrained to private network type deployments.  Security groups and associated firewall rules are a core way we can implement and manage security with NSX.  Cloud Assembly can assign VMs to existing NSX security groups through network profiles and blueprints.  The screenshot shows an existing Security Group is added to the profile named Global through a network profile.  I could also assign membership to multiple Security Groups using this network profile, simply keep adding the required security groups to achieve that result.  One thing to note, all VMs provisioned using this network profile will be members of the same security group(s).  Blueprints offer a different way to assign membership with more granularity, which I’ll cover shortly.

Security groups are visible within Infrastructure -> Resources -> Security.  This view, shown in the screenshot, allows you to see all the of the discovered (existing) security groups.  To assign VMs to an existing security group using a blueprint, you must add a constraint tag to the security group and then add the same tag to the cloud zone where the VM will be deployed.  To add a constraint tag to the security group, click the checkbox for the chosen security group in the Security view then click TAGS to add a constraint tag for later use with a blueprint.

I’ve mentioned that security groups can be leveraged through a blueprint.  Two types of security group objects can specified in a blueprint, existing and new.  Like existing networks, existing security groups are groups that have already been created in NSX using Cloud Assembly, manually in the NSX manager, or 3rd party methods.  New aka on-demand security groups are available for vRealize Automation (vRA) Cloud (our vRA SaaS offering) and on-premises for vRealize Automation 8.1.  I’ll cover on-demand security groups later in the post.

Adding Existing Security Groups to a Blueprint

This process now supports both NSX and VMC.  Since VMC uses NSX on the backend, the process for adding existing security groups to a Cloud Template is the same.

To add an existing security group via the blueprint, click-drag the object to the canvas. You’ll notice the YAML code updates with information on each security group that’s added. Once the machines deploy, they will become members of the specified existing security groups.

To associate a security group with a cloud machine, click the security group object on the canvas and drag the cursor to the cloud machine (similar to the process used to connect machine and network objects). A dialog will appear asking which NIC to assign to the security group. Don’t forget to add the security group constraint tag to the YAML portion of the blueprint as well. As soon as the machines deploy, they’ll become members of the specified existing security groups.

When a security group, whether existing or new, is connected to a cloud machine, a resource binding appears in the YAML code for the connected cloud machine. You can assign independent security groups to each NIC, if so desired.

Assigning security groups from the blueprint offers more flexibility versus assignment via the network profile.  Both methods can still be used.  You may want to assign a common security group, which sets a minimum security baseline, at the network profile and more secure or specific security groups using the blueprint.

Adding On-demand Security Groups to a Blueprint

This process now supports both NSX and VMC.  Since VMC uses NSX on the backend, the process for adding on-demand security groups to a Cloud Template is the same.

Cloud Assembly provides the option to choose “new” for securityGroupType in the YAML code. You also have the option to create firewall rules and take advantage of existing services in NSX. The screenshot shows how to define firewall rules in YAML: source; destination; direction, inbound or outbound; ports; protocol; existing service.

In this scenario, a security group with associated firewall rules is created during the deployment assigned to the NICs of deployed VMs. The security group and rules are removed when the deployment is deleted. The process for connecting the security group and cloud machine are the same as existing groups; here though you won’t use a constraint tag in the YAML code because in this example we’re creating new security groups.

The screenshot shows new security groups being created in NSX. The VMs, Web and DB, will be members of the newly created groups with the distributed firewall rules set in the YAML code. You can also set the source as other VMs in the deployment or a range IP addresses.

Change Security Group Membership – Day-2 Action

vRA now supports the ability to change security group membership for a VM deployment as a day-2 action in both NSX and VMC.  To change a group, choose the group from the Deployment – Topology view.  Click Actions on the right and select Change Security Groups.

The existing security group assignment will be displayed.  You can remove the group and choose from one of the other groups in the deployment.  Once complete, click Apply to update the deployment.

Change a Security Group Iteratively Via the Cloud Template and as a day-2 action

vRA Cloud and vRA 8.4 now support the ability to update a VM’s Security Group membership as a deployment update following a Cloud Template change.  This method provides more flexibility around Security Group assignment than the day-2 action, which only supports Security Groups associated with the deployment.  Simply change the Existing Security Group assigned to a VM within the Cloud Template and initiate a deployment update.  Choose the dropdown to update an existing deployment, select the deployment from the list you would like to update, click Next, confirm the Planned changes and click Deploy.  The deployment will be updated with the new Security Group membership.  This capability is supported with both NSX and VMC.

We also support the reconfiguration of firewalls rules for on-demand Security Groups as a day-2 action. Navigate to the deployment topology, select the Security Group, then click Actions and choose Reconfigure or Delete.  You can add new rules, edit existing rules, or delete the rules from this day-2 action.  When you click Submit, an update actions run to modify or add DFW rules that are associated with the Group in NSX.

Private Network Types

networkType: private  Private network types isolate provisioned VMs from external access via firewall rules or network configuration.  Private allows you to use existing (shown below) or on-demand networks for deployments.  The network profile the provisioning service chooses controls each configuration.  If you choose private on the blueprint and use a constraint tag for a network profile/policy where  Create an on-demand security group is matched (shown below), a security group is created for each network on the blueprint canvas.  All on-demand security groups are created with three associated firewall rules. The associated rules include inbound and outbound reject rules and a third rule allows intra-VM communication for members of that security group.

If you choose to create an on-demand private network, networkType private is still used on the blueprint, but you would constrain the network choice to a network profile with on-demand networking configured.  In that event, a DHCP server and pool is created, however a T-1 isn’t configured, and no security groups are created.  I’ll talk more about this later in the post.  Let’s take a look at how to set this up.

Open a network profile, select Networks, and choose one of the two options:

• For a private on-demand security group deployment, add an existing deployed or discovered switch in Networks, choose Create an on-demand security group in Network Policies, and specify networktype: private on the blueprint.
• For a private on-demand network deployment , the configuration process uses the on-demand network profile config (check out part 2 on outbound network types for more information).  The main difference with this configuration is you don’t need to add an existing switch in Networks and an external network isn’t required in Network Policies.

Routed Network Types

networkType: routed Is available for NSX and requires an NSX network object on the blueprint canvas.  You can’t use the routed network type with a cloud agnostic network object, the option won’t appear in the YAML properties.  Routed networks are similar to Outbound (on-demand networks), except they configure the route advertisement to Advertise all connected routes for the created Logical Router (Outbound uses Advertise all NAT routes) and a NAT rule isn’t created.  In environments where internal NAT is frowned upon, the routed network type is ideal.  Simply point a blueprint, with network type Routed, to a network profile with a on-demand network policy (just like the Outbound type) and Cloud Assembly will handle the configuration at deployment time.

This covers how security groups, plus private and routed network types are configured and the resulting behavior in NSX.  For part 4 of the series, I’ll be covering how to use and deploy NSX load balancers with Cloud Assembly.  I hope you’ve enjoyed our trip down network automation lane!

Network Automation with Cloud Assembly and NSX part 1  – Network Automation with Cloud Assembly and NSX part 2 – Network Automation with Cloud Assembly and NSX part 4

Related Posts:

Related Articles

Introducing VMware Identity Manager Cluster Auto-Recovery in VMware Aria Suite Lifecycle 8.14

Deploying VMware Avi Load Balancer resources with VMware Aria Automation Templates

Enabling Load Balancer as a Service for VCF-based Private Cloud

What’s New for VMware Cloud Foundation offering VMware Aria Operations for Networks 6.12

Announcing VMware Aria Automation 8.16.0 Release

Planning IPv6 adoption in the AWS Cloud network

Elastic network interfaces in an IP network could operate in three different modes:

IPv4-only mode — Your resources can communicate over IPv4, and if communicating to IPv6 nodes, require an interoperability layer.

IPv6-only mode — Your resources can communicate over IPv6, they do not require an IPv4 address, and if they are communicating to IPv4 nodes, they require an interoperability layer achieved through NAT64 and DNS64.

Dual-stack mode — Your resources can communicate over both IPv4 and IPv6. A separate interoperability layer is not required.

IPv6 addressing plan on AWS

Coming up with an IPv6 addressing plan is one of the most important initial tasks for any organization proceeding with IPv6 adoption. For most organizations, IPv6 is deployed in parallel with IPv4 in existing IPv4 AWS and hybrid networks. IPv4 addressing plans tend to grow over time, and consequently may be highly fragmented, not contiguous, or not big enough. Simply duplicating the IPv4 addressing scheme in some fashion in IPv6 might initially prove advantageous. However, any temporary advantage gained by such a shortcut will ultimately be surpassed by the ease and efficiency of operation and design offered by a proper IPv6 addressing plan that incorporates the key benefits of the larger allocations possible with IPv6.

The virtually limitless scale of the IPv6 address space allows for an addressing plan no longer constrained by the scarcity of IPv4 addresses. Techniques like Variable Length Subnet Masking (VLSM) (previously required in IPv4 to economically match subnet size to host count on a given network segment) can be seen as unnecessary and obsolete in IPv6. Instead, it’s possible to adopt a consistent addressing plan by assigning significance to groups of VPCs according to network and segmentation needs.

In AWS, IPv6 address space assigned to VPCs is assigned from the  globally unique unicast address range. There are two options for IPv6 address assignment:

AWS-assigned IPv6 VPC classless inter-domain routings (CIDRs)

Bring your own IPv6 CIDR Blocks (BYOIPv6)

Amazon VPC doesn't support unique local address (ULA) CIDRs. All VPCs must have unique IPv6 CIDR. Two VPCs can’t have the same IPv6 CIDR range.

Amazon VPC IP Address Manager (IPAM)

Amazon VPC IPAM is a VPC feature that makes it easier for you to plan, track, and monitor IP addresses for your AWS workloads. You can also use IPAM's automated workflows to more efficiently manage both IPv4 and IPv6 addresses. With IPAM, you can track and have an inventory of the AWS-supplied IPv6, and you can also have granular control over your IPv6 prefixes configured in AWS with the Bring Your Own IPv6 (BYOIPv6) feature. Choosing AWS-assigned IPv6 addresses or BYOIPv6 addresses influences your ability to summarize prefixes, as well as to control the multi-account, multi-region addressing scheme. For more information, refer to IPAM documentation and the Managing IP pools across VPCs and Regions using Amazon VPC IP Address Manager blog post.

AWS-assigned IPv6 VPC CIDR

By default, Amazon provides one fixed size (/56) IPv6 CIDR block to a VPC. This range is assigned by the service, and consequently, you can’t assign contiguous IPv6 CIDR blocks to VPCs in the same Region or based on other custom-defined criteria.

For customers that have a large VPC footprint in AWS and prefer to use IP route summarization to simplify their overall environment, bring your own IPv6 (BYOIPv6) described, in the next section, may be the preferred solution.

BYOIPv6 VPC CIDR

Alternatively, if you own an IPv6 address space, you can import it into AWS using the Bring Your Own IPv6 service. The smallest IPv6 address range that you can bring is /48 for CIDRs that are publicly advertised by AWS, and /56 for CIDRs that are not publicly advertised by AWS. You can also choose to bring a /48 and mark it as non-advertisable, keeping control of IP advertisements on your on-premises setup. After importing it, you can assign /56 ranges from the space to individual VPCs in the same account.

For the process on how to “Bring Your Own IP (BYOIP),” refer to Configure your BYOIP address range .

As summarization can be easily configured with contiguous IPv6 blocks, for multi-Region deployments, you can bring one or more /48 or larger prefixes to each Region. Consider route summarization at the VPC route table level, as well as when using AWS connectivity options such as AWS Transit Gateway , AWS Direct Connect , and AWS VPN .

VPC subnet addressing

Although you can assign one /56 IPv6 CIDR block to a VPC, the VPC subnets are /64 fixed in length. This yields to the interface ID being /64 in length, in accordance with the general format of the IPv6 unicast addresses. Given the fixed size of the VPC CIDR and the subnet prefix, you have 8 bits for subnet allocation in the VPC, enabling you to create 256 subnets in the VPC. You can allocate IPv6 /64 CIDRs to dual-stack subnets (which allow you to run both IPv4 and IPv6 workloads), and to IPv6-only subnets (which allow you to run IPv6-only enabled resources).

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Thanks for letting us know we're doing a good job!

If you've got a moment, please tell us what we did right so we can do more of it.

Thanks for letting us know this page needs work. We're sorry we let you down.

If you've got a moment, please tell us how we can make the documentation better.

IP addressing options in Google Cloud: Networking basics

Ammett Williams

Developer Relations Engineer

In this blog we’ll be visiting the topics of IP addresses and subnetting on Google Cloud. IP addressing and subnetting can be confusing to many, but addressing is a very important requirement in your network.

An IP address is a unique identifier for a network and a host. To separate an IP address into network and host segments a subnet mask is used. You can compare this to a city block which has a street and buildings with numbers. The IP addresses and city block analogy can be mapped as follows:

Network portion - This would be equivalent to the street address. One street may have many buildings on it. e.g 192.168.10.20/24 the 192.168.10 represents the network and the /24 represent the subnet mask (this will be explained in a later section).

The host portion - This is equivalent to the building number. This is where the building is located on the street. E.g. 192.168.10.20/24 the .20 represents the host on the network.

There are two versions of IP,  IPv4  and  IPv6  each with different address formats. IPV6 addressing was created due to limitations in the amount of available IPv4 addresses. One of the main drivers for increased consumption of IPv4 addressing was the growth of the internet.

An IPV4 address consists of 32 binary bits, divided into 4 octets. This can be written in dotted decimal format. eg. 192.168.20.1 or binary.

An IPV6 address consists of 128 bits, divided into 16 bit hexadecimal fields. Example of IPV6 address is 2001:DB8:7654:3210:FEDC:BA98:764:3203

IP addresses exist both on-prem and in the cloud. Let's explore a few IP options like private, secondary, external and Bring your own IP (BYOIP) that can be used in Google Cloud.

Private addresses (RFC 1918)

Private IP addresses are taken from a reserved block of address that can be used internally within a network. This range is defined as a Request For Comments (RFC) standard RFC1918 . These private address ranges are not unique to Google Cloud and can be used by any enterprise. Private IP addresses are non internet routable, meaning they cannot connect directly to the internet. The private IP ranges are:

10.0.0.0 -10.255.255.255 (/8)

172.16.0.0 - 172.31.255.255 (/12)

192.168.0.0 -192.168.255.255 (/16)

Default Reserved IP addresses

In Google Cloud primary subnets , 4 IP addresses are automatically reserved. These Reserved IP addresses are:

Network address

Default gateway

Second-to-last address

Broadcast address

To help make this clearer let’s look at the same 192.168.10.20 network with a /24 subnet. 

The /24 means 24 bits out of the 32 bits will be used by the network.

The remaining 8 bits will be used by the host. To determine the total amount of addresses we can use the formula 2 8 = 256.

In a standard network the first address and last address is reserved. These are known as the network address and the broadcast address. e.g.  192.168.10.0 and 192.168.10.255. 

Because of this reservation the formula for available host addresses is 2 n - 2. This would be 2 8 - 2 = 254

In Google Cloud because 4 addresses are reserved the formula becomes 2 8 - 4 so a /24 network would have 252 addresses available for hosts.

Address assignment

Ephemeral IP addresses  are assigned automatically to your VMs and services in Google Cloud. This is done via DHCP.  You can also manually assign a  reserved static internal IP address  to your VMs if stable addresses are required. Subnet limitations

The smallest subnet available in GCP is /29 which means 4 hosts or 2 3 - 4. This is different from on-prem private addresses in which the smallest subnet can be a /30 or /31 for point-to-point links. Please keep this in mind when assigning address subnets.

Privately used public IP (PUPI) addresses

These are addresses that would under normal circumstances be routable on the internet. When used in your VPC they are treated as private addresses and not advertised to the internet routing table. PUPI addresses can be used in Google Kubeternes Engine (GKE) as in this   example . 

Secondary addresses 

Secondary IP Addresses are additional addresses that can be assigned to your virtual machines. An example of this would be assigning an  alias IP address  to your VM from the secondary IP address range for use by a particular service running on the VM.

External Addresses

External IP addresses are internet routable and allow direct communication to the internet. Just like private IP addresses, ephemeral external IP addresses can be automatically assigned or you can reserve  static external IP addresses  to use on your VMs, load balancers, and other services where they can be applied. 

External IPv4 addresses are a limited resource and should be used with care. Both static and ephemeral external IP addresses incur cost. If you reserve a static external IP address and do not assign it to a resource, you will be charged at a higher rate than for static and ephemeral external IP addresses that are in use.

Bring your own IP (BYOIP)

With this catchy name it accurately describes that you can bring public IP addresses that you own to use on your Google Cloud resources. This requires a little process that you can read more about in the  VPC BYOIP documentation  .

Prohibited subnet ranges

There are certain ranges that are prohibited from being assigned to your Google Cloud resources. You can get a list of these ranges  here .

IPv6 addresses

IPv6 can be enabled in certain regions. Some on the basic steps to enable IPv6 address are:

Create a custom VPC and add a subnet in any of the following regions

asia-south1

europe-west2

Next  enable IPv6 on the subnet .

Next you create or enable IPv6 on an existing VM in the applicable region

Next you can also create an IPv6 instance template

Common Google Cloud services that use IP addressing

There are several services that use IP addressing. These are the most common, but this is not a complete list:

Load Balancers

Google Kubernetes Engine (Containers, Clusters, Pods, Services, Ingress)

Some helpful advice

Google Cloud helps you by handling a lot of the standard issues with IP addressing so that you can create a project and begin building. As your enterprises and projects evolve you may want to connect to on-prem facilities, other projects, and other clouds. To save yourself a bunch of headaches, spend some time planning your IP address assignments.

This is especially relevant so that you can avoid the problem of overlapping IP addresses. Take time to consider the following as you plan:

Estimated growth plans 

Upcoming expansions 

Existing subnets in other environments

Scaling requirements

Possibility of acquisitions 

To learn more about IP addressing on Google Cloud, check the following links:

Documentation: IP Addressing

Blog post: Understanding IP address management in GKE

Video: IP addressing in the cloud  

Video: BYOIP on Google Cloud

Git:  IPAM Autopilot

Floating IP addresses in Compute Engine

Want to ask a question, find out more or share a thought? Please connect with me on Twitter or Linkedin and send me a message.

From your device to Google Cloud API: Networking basics

In this post we’ll look at some networking touchpoints that occur when you decide to access a Google Cloud API and build in the cloud environment.

By Ammett Williams • 3-minute read

• Developers & Practitioners

Related articles

Tips for troubleshooting Google Cloud Load Balancing backends

By Disha Madaan • 12-minute read

Enhance the security of your DialogFlow CX chatbots with Apigee

By Pallavi Vageria • 4-minute read

Unlocking API performance insights with Apigee custom reports

By Aakanksha Nikhare • 14-minute read

BigQuery community UDFs go global to simplify data transformations for everyone

By Andrew Fleischer • 2-minute read

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Deploy Azure Cloud Services (extended support) using the Azure portal

• 5 contributors

This article explains how to use the Azure portal to create a Cloud Service (extended support) deployment.

Before you begin

Review the deployment prerequisites for Cloud Services (extended support) and create the associated resources.

Deploy a Cloud Services (extended support)

Sign in to the Azure portal .

Using the search bar located at the top of the Azure portal, search for and select Cloud Services (extended support) .

In the Cloud Services (extended support) pane select Create .

The Cloud Services (extended support) creation window will open to the Basics tab.

• Select a Subscription.
• Choose a resource group or create a new one.
• The DNS name of the cloud service is separate and specified by the DNS name label of the public IP address and can be modified in the public IP section in the configuration tab.
• Select the region to deploy to.

Add your cloud service configuration, package and definition files. You can add existing files from blob storage or upload these from your local machine. If uploading from your local machine, these will be then be stored in a storage account.

Once all fields have been completed, move to and complete the Configuration tab.

• Cloud Service (extended support) deployments must be in a virtual network. The virtual network must also be referenced in the Service Configuration (.cscfg) file under the NetworkConfiguration section.
• If you have IP Input Endpoints defined in your Service Definition (.csdef) file, a public IP address will need to be created for your Cloud Service.
• Cloud Services (extended support) only supports the Basic IP address SKU.
• If your Service Configuration (.cscfg) contains a reserved IP address, the allocation type for the public IP must be set tp Static .
• Optionally, assign a DNS name for your cloud service endpoint by updating the DNS label property of the Public IP address that is associated with the cloud service.
• (Optional) Start Cloud Service. Choose start or not start the service immediately after creation.
• Key Vault is required when you specify one or more certificates in your Service Configuration (.cscfg) file. When you select a key vault we will try to find the selected certificates from your Service Configuration (.cscfg) file based on their thumbprints. If any certificates are missing from your key vault you can upload them now and click Refresh .

• Once all fields have been completed, move to the Review and Create tab to validate your deployment configuration and create your Cloud Service (extended support).
• Review frequently asked questions for Cloud Services (extended support).
• Deploy a Cloud Service (extended support) using the Azure portal , PowerShell , Template or Visual Studio .
• Visit the Cloud Services (extended support) samples repository

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

You are using an outdated browser. Please upgrade your browser to improve your experience.

In VMware Aria 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 Automation Assembler 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.

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

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 hosts and clusters.

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

• 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 the Infrastructure > Resources page with all the cloud accounts that they apply to.

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

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

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 VMware Aria 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 Network, security group, and load balancer resource examples in Automation Assembler .

For information about reusing networks, see How to reuse VMware Aria Automation networking and security resources in Automation Assembler .

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

VMware Aria 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 VMware Aria 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 VMware Aria 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 VMware Aria Automation after NSX-T migration from N-VDS to C-VDS, see Updating networking resources in VMware Aria 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 VMware Aria Automation cloud templates .

Network Domains

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