With VMware Cloud Foundation (VCF) 9.1, the Distributed Transit Gateway (DTGW) connectivity model now supports NSX stateful network services through the Virtual Network Appliance (VNA) cluster. This makes it easy for VI Admins to provision Virtual Private Clouds (VPCs), which can then be used to deploy vSphere Kubernetes Service (VKS) workloads using either vCenter Server or VCF Automation (VCFA).
One of the most underappreciated benefits is the ability to complete various NSX workflows including an entire VNA cluster deployment and DTGW configuration directly from vCenter Server, without having to switch to the NSX Manager UI. While NSX Manager still provides the underlying micro-frontend interfaces that are integrated into the vSphere UI, I appreciate having the flexibility to perform these workflows from either the vCenter Server or NSX Manager interface, depending on your roles and responsibilities within an organization.
While there are a number of community blog posts covering DTGW and VNA deployments, they typically start in the vSphere UI for the initial VNA deployment before switching to the NSX Manager UI to complete the remaining configuration, which is perfectly valid. Personally, I prefer using the vSphere UI for as many workflows as possible, especially since enabling vSphere Supervisor and vSphere Kubernetes Service (VKS) is also performed through the vSphere UI.
Step 1 - If you plan to use the Distributed Firewall (DFW) capability as part of vDefend with Distributed Virtual Portgroups (DVPGs), you can now enable the Activate NSX on DVPG feature directly from the vSphere UI. In VCF 9.0, this workflow required using the NSX Manager UI. Select the desired vSphere Cluster and navigate to Configure > Networking > Network Configuration and click on Configure button.
Select the desired vSphere Cluster and navigate to Configure > Networking > Network Configuration and click on Configure button to edit the seting.
Step 2 - Deploy a VNA Cluster with at least one VNA node by selecting the top-level vCenter Server object and then navigate to Configure > Networking > VNA Clusters and follow the Add Cluster workflow which is pretty straight forward, so I will not repeat the specifics and you can refer to the Broadcom documentation for more information.
Step 3 - Once your VNA Cluster is up and running, we need to update the default VPC connectivity profile to use our VNA Cluster along with a few other configuration settings. Select the Network tab view and then the to Virtual Private Clouds inventory object and navigate to Configure > Settings > Connectivity Profiles to edit the settings.
Select your VNA Cluster from the drop down menu, toggle both N-S Services and Default Outbound NAT which will be required for enabling vSphere Supervisor and VKS workloads as well as the Day 0 External IP Block that would have already been configured during your VCF Fleet installation when selecting the DTGW deployment option.
Step 4 - During the initial deployment of your VCF 9.1 Fleet, you specify both the VLAN used for DTGW connectivity and an IP Block (for example, 172.30.70.0/24) that is used for external connectivity. When you enable vSphere Supervisor, it consumes a subset of addresses from this IP Block, but not the entire range. However, if you later enable VCF Automation, which also depends on vSphere Supervisor, you may encounter an unexpected error indicating that there are no available IP addresses for external connectivity.
The reason is that, by default, vSphere Supervisor reserves the entire Day 0 External IP Block, even though it only consumes a portion of the available addresses. This leaves no additional IP Blocks available for other services that require external connectivity.
Instead, we can divide up the original IP Block into smaller IP Blocks that share the same gateway but can be assigned to different services. For example, if your Day 0 External IP Block is 172.30.70.0/24, you could divide it into four /26 networks:
- 172.30.70.0/26
- 172.30.70.64/26
- 172.30.70.128/26
- 172.30.70.192/26
To update the configuration, select the Network tab view and then the to Virtual Private Clouds inventory object and navigate to Configure > Settings > IP Blocks and click on the three dots for Day 0 External Ip Block.
Now when you enable vSphere Supervisor, only one of the /26 IP Blocks will be consumed and the remaining IP Blocks can be used for other external connections including VCF Automation, without needing to provision another VLAN.
Thanks for the comment!