Network Automation with Cloud Assembly and NSX – Part 3

Network Automation with Cloud Assembly and NSX – Part 3

This post was originally published on this site ---

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 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.  The screenshot shows an existing Security Group is added to the profile named Web.  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).




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:

  1. 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.
  2. For a private on-demand network deployment, from here 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.


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 they don’t create a NAT rule.  In environments where internal NAT is frowned upon, the routed network type is ideal.  Simply point a blue print with network type Routed to an on-demand network profile/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!




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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.