Welcome to part 14 of the VCF-9.1 home lab series. The previous post in this series discussed the architecture and deployment of a VNA cluster for distributed connectivity. This post will discuss implementing the distributed transit gateway for VPC connectivity.
If you are not following along, I encourage you to read the earlier parts of this series from the links below:
3: VCF 9.1 Pre-Deployment Planning
4: Setting up VCF 9.1 Offline Depot
5: VCF 9.1 Deploy Management Domain
6: Configure Management Domain Network Connectivity
8: Enable Avi on Workload Domain
9: Deploy Supervisor in Workload Domain
11: VCFA Provider Management Configuration
12: Deploy VCF Operations for Logs
13: VNA Cluster for Distributed Connectivity
Within a VPC, routing between subnets is handled by a VPC Gateway, which behaves like a distributed tier-1. It runs on every ESXi transport node, keeping east-west traffic local to the hypervisor. The Transit Gateway sits one layer up: it interconnects VPC Gateways to one another (inter-VPC routing) and provides a path to any external connection the provider has made available.
The critical architectural question is, where does traffic actually leave the virtual environment and hit physical switches? That question is what separates centralized from distributed transit gateways. I covered centralized transit gateways in a previous post of this series.
In the distributed model, there is no edge node and no tier-0 in the forwarding path at all. The Transit Gateway connects directly to a VLAN that’s reachable from every participating ESXi host — the same uplinks already carrying TEP overlay traffic are reused to reach that external VLAN. Traffic from a VM leaves the virtual environment straight from the ESXi host it’s running on.
So, the obvious question arises: how do I run stateful services with DTGW? Do I need to switch back to a centralized transit gateway (CTGW)? The answer is yes and no.
In VCF 9.0, DTGW only provided DHCP and basic external NAT. So if you are on VCF 9.0, you must use CTGW to run any stateful services in VPC. VCF 9.1 introduces the Virtual Network Appliance (VNA)—a lightweight, purpose-built appliance whose only job is to host the stateful services a Distributed Transit Gateway cannot itself distribute across hypervisors.
With the VNA cluster in place, the services available to a VPC on a Distributed Transit Gateway expand considerably. The table below compares DTGW features in VCF 9.0/VCF 9.1
| Service | VCF 9.0 (DTGW) | VCF 9.1 (DTGW + VNA) |
| DHCP | Yes | Yes |
| External IP / 1:1 NAT | Yes | Yes |
| SNAT / DNAT | No | Yes, via VNA |
| N:1 Outbound NAT (PAT) | No | Yes, New in 9.1 |
| Load balancing | No | Yes, via VNA |
| NSX LB for Supervisor / VKS | No | Yes, New in 9.1 |
| DNS forwarding | No | Yes, via VNA |
| IPsec VPN | No | Yes, via VNA |
Distributed Transit Gateway Design Considerations
The Distributed Transit Gateway model is compelling, but “distributed” and “appliance-free” aren’t quite synonyms once you add stateful services. A few things worth weighing:
- VNA is still an appliance dependency: Enabling SNAT/DNAT or load balancing on a DTGW means VNA placement, capacity, health, lifecycle, and recovery now matter—you’ve removed the edge cluster from the external forwarding path, but you haven’t removed operational appliance management from the stateful-services path. Plan VNA cluster sizing the way you’d plan any shared service tier.
- Physical topology constraint: Because the external VLAN required by a Distributed Transit Gateway is, by design, stretched across the racks participating in that VPC, the multi-rack Layer 3 vSphere cluster model isn’t supported for DTGW—you need a multi-rack Layer 2 model, meaning that VLAN has to be reachable from every host in the cluster.
- Only qualifying traffic hits the VNA: L2/L3 forwarding and External IP (1:1 NAT) traffic remain fully distributed regardless of whether a VNA cluster is attached. Only NAT-beyond-1:1 and load-balanced flows get redirected. This keeps the “distributed-first” performance characteristic intact for the majority of traffic even in a stateful-services design.
- Increased IP Addressing Complexity: With external IP blocks, VLAN ranges, public subnets, private VPC ranges, and Transit Gateway address blocks, all need distinct, non-overlapping IP addresses. Overlaps can produce failures even when the VPC and the physical network configuration look correct. This gets harder, not easier, once you’re running multiple TGWs and multiple external connections per tenant.
- Test failure and mobility explicitly: Distributed connectivity’s correctness depends on the physical network keeping up with workload mobility (the gratuitous ARP/RARP on vMotion). Validate both live migration and failure scenarios rather than assuming steady-state testing is sufficient.
Let’s dive into the distributed transit gateway deployment and configuration.
In my lab, I am using the following information for setting up distributed connectivity.
| Network Type | VLAN/IP CIDR |
| Distributed External Connection | VLAN: 227, 10.252.227.0/24 |
| External IP Block | 10.252.227.0/24 |
| VPC Pvt Transit Gateway | 192.168.0.0/23 |
| VPC Private Subnet | 172.30.0.0/16 |
In the vCenter UI, select the vCenter instance and navigate to Configure > Networking > External Connections. Click Add External Connection.
Specify the connection name and select type as “Distributed VLAN Connection.”
Enter the VLAN ID configured on your upstream router/switch and the gateway CIDR backing that VLAN.
The new distributed VLAN external connection is now ready.
The next step is to create an IP address block so that the IPs can be handed over to the VPC when requesting an external connection. This IP block must contain the IP from the same CIDR that you used in the distributed VLAN connection.
Provide a meaningful name for the IP block and set the visibility to External. Under CIDR/Ranges, add the IP CIDR and exclude any IP that must not be assigned to VPCs.
Click Save to complete the configuration.
How do I consume distributed connections?
Now that the distributed external connection is ready and the IP block is configured, how do I consume this? The answer is VPC.
For this demonstration, I am creating a new NSX Project and VPCs inside the project. In the new project, you must define the following:
- An external connection to use.
- An external IP block.
- The VNA cluster.
Click the Set button for External Connection and select the distributed VLAN connection that you created earlier.
Select the external IP block created for the distributed connection and click Apply.
Select the VNA cluster and click Apply. The VNA cluster deployment I covered in my previous post.
Click Save to finish the project creation wizard.
Switch to the new project and navigate to Networking > Transit Gateways. A new transit gateway is auto-created with the project and leverages the external connection specified in the project creation workflow.
Navigate to the VPCs > Profiles > VPC Connectivity Profile tab. A new connectivity profile is auto-created for the VPC, but it doesn’t have a private transit gateway IP block associated. If you plan to deploy more than one VPC in this project and want cross-VPC connectivity, you must add an IP block to the profile.
Edit the VPC connectivity profile and, under Private Transit Gateway IP block, click Create New.
Specify the IP block name and add the IP CIDR. This IP CIDR is not advertised northbound, so you can choose any CIDR here (unless restricted by your networking team).
Click Save to close the wizard.
Enable N-S services and select the VNA cluster that this profile will use when instantiating any stateful services.
Enable Default Outbound NAT and select the external IP block that you created earlier. When Default Outbound NAT is enabled, a NAT rule is auto-created in the VPC for translating the transit gateway IP block to one of the IP addresses from the external IP block.
VPC and Subnet Creation
Let’s create a new VPC and start consuming the distributed connectivity. Go back to the VPC tab and click Add VPC.
Specify the VPC name and the VPC private subnet CIDR. The private subnet provides connectivity to the workloads inside the VPC.
Select the connectivity profile. If you only have one profile, it’s auto-selected for you. If you have more than one, selection is available in the drop-down menu.
Click Next to go to the next screen. Create VPC subnets under the connectivity option.
I created three VPC subnets in my lab. The screenshots below show the subnet creation workflow.
The VPC subnets are now ready for consumption.
This is how the network topology looks. The VPC Gateway is connected to the Distributed Transit Gateway, which in turn is directly connected to the physical infrastructure.
I created a couple of VMs and attached them to the VPC public and private subnets, respectively.
Connectivity Test
Now that the VMs are attached to the VPC subnets, let’s perform a connectivity test.
From the private VM, I initiated a ping to the following IP addresses:
- 172.30.20.1: VPC Gateway IP
- 10.252.227.254: VLAN Gateway IP on the physical switch.
- 10.252.80.1: A VM connected to another VLAN in the infrastructure.
And I can reach all endpoints.
The same tests were performed from the public VM, and successful connectivity was established.
And that’s it for this post.
In the next post of this series, I will demonstrate the ingress/egress data path for VMs leveraging distributed connections. Stay tuned!!!
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.