Network Automation with Cloud Assembly and NSX – part 2

In the first post, I covered how to add Cloud Accounts and view discovered compute and network resources in Cloud Assembly.  If you missed the first post or need a refresher, click here – part 1 – to check it out.  Each of the posts in this series assumes you have access to Cloud Assembly with the pre-reqs for provisioning handled.  You will also want NSX configured and running with uplink connectivity to your gateway.

Let’s dive in.  Network Profiles control which network constructs are used for placement decisions during a deploy.  They also control the level of isolation a workload will have when deployed.  If you recall from the first post, I added vc-south and nsx-south environments and will continue working with those entities.  In the examples, two network profiles have been created for nsx-south, the NSX-T environment.  Each profile widget includes a summary of the compute and networking entities associated with the profile.  The options for NSX-v and NSX-T are very similar, with some differences behind the scenes, but essentially the same end results.  The first networkTypes I will cover are Existing networks and Outbound on-demand networks.  I’ll cover Private on-demand security group options, public and routed networks in the third post.

The best place to begin learning how Cloud Assembly interacts with networking is by looking at a blueprint.  Selecting the Blueprints option allows you to add and interact with blueprints.  I’ll start by opening the example blueprint called Single-VM-Nat.  As the blueprint name suggests, a single machine object and network with a NAT rule will be created, among other configurations, during the deployment.



To create a similar blueprint, simply drag the Cloud Agnostic machine object and NSX Network object to the canvas.  I highlighted the portion of yaml code which tells Code Assembly what network capabilities to look for during a deployment.  In the example below, I’ve selected an NSX network entity.  The networkType: outbound code will create a new network with outbound access and NAT configured.  The networkType setting instructs the placement engine to look for a network profile that matches the request.  But I’m getting ahead of myself, I’ll provide more detail on network profile and blueprint interactions later in the post.

Note: you could also drag a Cloud Agnostic or vSphere network onto the canvas.  For this example, I chose NSX in order to display all available networkTypes in the blueprint.



Before moving forward, I removed outbound from the code panel and selected networkType.  Doing so displays available networkType options as shown below.  We’ll go through each type and I’ll show you how to configure Cloud Assembly network profiles to accommodate each blueprint setting.



networkType: existing uses a discovered network or deployed network Origin type.  I know that can be confusing so let me explain.

  • Discovered origin: manually created network objects found through the Cloud Assembly discovery service
  • Deployed origin: network objects provisioned by Cloud Assembly

For example, a provider network would appear as deployed.  A provider network is created from a blueprint where the only object on the canvas is a network.  No machines are associated.  There are scenarios where an organization may want to create a static provider network for developers to use without creating an on-demand network each time a deployment occurs.  I’ll spend more time on that topic in another blog post.  The key thing to remember is both Origin types can be used for existing networkTypes provisioning.

When NSX is involved, deployed and discovered networks can be a switch configured for VXLAN or Geneve overlay networking.  The switch could be VLAN backed too.  Workloads deployed, using networkType: existing, with either Origin type, will use static or dynamically assigned IP addresses depending on your NSX, VM, and potentially cloudConfig setup.

Switching from my blueprint to a network profile, I’ve selected the Networks option.  I added existing networks, notice the switch configured manually (outside Cloud Assembly) shows Discovered for an Origin, whereas the Cloud Assembly created switch shows Deployed, as I mentioned.



In another example, I added existing networks that will be used for placement decisions.  I chose App and DB with the tags net:app and net:db for each switch.  These tags allow me to assign specific networks to each tier of my application in the blueprint.  The switches have their own DHCP server and assigned IP range, importantly this is configured in NSX.

So using this configuration, App and DB will have their own distinct IP ranges.  We could take it further and create tags in NSX as part of the provisioning process to help with identification of Cloud Assembly deployed resources.  I’m working on another blog post covering how to tag objects in NSX with Cloud Assembly.  Keep an eye out for that post.



Next, switch to the Network Policies option and confirm the Do not create on-demand network or on-demand security group radio button is selected, as shown in the screenshot.  Don’t forget to confirm the Existing network, T-0 logical router, and Edge cluster provide the desired network connectivity for your VMs.



networkType: outbound creates on-demand networks.  For NSX-T, a new T-1 gateway, L2 switch, one-to-many SNAT rule, DHCP server with IP pool, and the proper uplinks/downlinks will be created for each blueprint deployment.  Allocated IPs and DHCP IP pools are based upon the CIDR and subnetting configuration specified in the network policies and network options.



Outbound networkTypes require that we have a network configured with a routable network range.  Well, it’s ‘required’ if you want outbound network connectivity!  In the example, I used Management – Switch and a pool of routable IPs.  The correct routed network CIDR must be used for placement decisions.  Click the checkbox for the switch and choose Manage IP Ranges.



Manage IP Ranges creates a pool of routable IPs Cloud Assembly will allocate for use as translated external IPs.  The IPs are assigned to each SNAT rule that is created in NSX.

Remember Cloud Assembly requires a fully configured NSX environment with uplink connectivity to an underlay network for this scenario to work properly.

Cloud Assembly will track the allocation of IP addresses using the built-in IPAM capability.  Click the IP range name to view allocation details.  If you are running out of IP addresses, simply modify the start and end IP addresses to increase the pool size.  Alternatively a new IP range can be added.


Switching to the Network Policies option, in a network profile, select the Create an on-demand network radio button.  Then you must add the discovered transport zone, external switch, T-0 gateway, and Edge cluster.  You will need to add a desired private network CIDR and subnet range, in this case I chose a /29 that will be assigned to each on-demand network.



Clicking the dropdown presents the available subnet size options.  Subnet size instructs Cloud Assembly to create a new network based on the configured /24 CIDR, in this case part of  Remember with NSX, a T-1 gateway, switch, DHCP server and pool, plus SNAT rule is configured for each subnet Cloud Assembly adds.  The VM(s) are assigned to the switch as part of the deployment process.  This is a really cool option, and is similar to how a network team might carve up private network ranges in an underlay network, but with far less effort and a much shorter time for creation.



In summary, each time a blueprint with networkType: outbound is deployed, Cloud Assembly is instructing NSX to spin up networking entities and make numerous configuration changes.  In fact, it’s so easy to create on-demand networks (and delete them) in NSX, you will want to provide governance over their creation and use to minimize potential network sprawl.  This situation is also where Provider networks often come into play.

The awesome news is VMware provides a number of options allowing you to manage network creation, including instance limits, and leases in Cloud Assembly.  Also you can see what has been deployed through Cloud Assembly and NSX.  Of course, if you want the best visibility into your NSX and vSphere networking and security configurations, there is no better product than vRealize Network Insight!

Now that you see how easy it is to create and use networks in NSX, don’t hesitate to try it out in your environment.  In the next post I’ll go through the other networkTypes and ability to use NSX security groups.  For the final post, existing and on demand load balancers are on tap.  You can expect to see part 3 soon!



The post Network Automation with Cloud Assembly and NSX – part 2 appeared first on VMware Cloud Management.

Powered by WPeMatico