NSX-T 3.2: Micro-Segmentation Only Deployment – Manual Setup

In my previous two posts, we explored deploying VMware NSX via the vCenter plug-in and configuring the plug-in using the Security Only configuration. As a Principal Technical Consultant, I have had experience with deploying NSX in a security only configuration, and I would like to share some caveats that you should be aware of when using this approach.

At PolarCloudsCo, we deployed NSX-T (now known as NSX) in a security only configuration just over twelve months ago. Given the success of our deployment, we are now looking to expand our data center provision by adding a second site or cloud. The second site will be used for provisioning some production services as well as providing failover and resiliency for our existing services run from our existing site. To achieve this, we would like to extend our existing NSX deployment into our second site or cloud and leverage NSX networking and routing as well as NSX security.

When deploying NSX using the vSphere vCenter plug-in security only wizard option, there is no quick way to add virtual networking to the deployment. As we found out, there are some caveats that you should be aware of before proceeding with this approach.

Let’s run through the workflow to see where the wheels fall off:

1. Enable networking and routing by creating an overlay transport zone.

2. Add the overlay transport zone to the transport node profile that our cluster/hosts are currently attached to.

3. Create a new VLAN transport zone as well, since we cannot modify the existing system-owned VLAN transport zone.

4. Update our cluster to use the new transport node profile, which includes both the overlay and VLAN transport zones.

However, we encounter several issues:

1. Edit is greyed out when trying to add the overlay transport zone to the transport node profile.

2. We cannot modify the existing system-owned VLAN transport zone.

3. Updating the Transport Node Collection is not allowed, and uninstalling NSX will also remove the distributed firewall and all our carefully handcrafted firewall rules.

To overcome these issues, we could consider removing a host from the existing cluster, rebuilding it, and using this rebuilt host as a basis to create a new cluster with its own distributed switch. From there, VMs could be migrated from existing hosts onto the new cluster. However, this approach would assume that there is enough capacity in the existing cluster to allow for the removal and rebuild of a host in the first place.

After going through all that work, we would still have the original system-generated VLAN transport zone and transport node profile configurations floating around in our environment that cannot be removed as they remain system-owned. This is a potential issue that you should be aware of when deploying NSX security only via the vSphere plug-in.

To avoid these caveats, it’s recommended to take a different approach if there is even a remote possibility of moving to virtual networking after deployment. In such cases, it’s better to manually configure security only as detailed in my previous post, “NSX-T 3.2: Micro-Segmentation Only Deployment – Manual Setup.” This approach will allow you to maintain control over your environment and avoid any potential issues that may arise from using the vCenter plug-in deployment wizard.

In conclusion, taking a shortcut today can cause undesired consequences tomorrow. When deploying NSX security only via the vSphere plug-in, it’s essential to be aware of these caveats and consider alternative approaches to avoid potential issues in your environment.