Dr. Pranay Jha

Myth: VCF 9 networking is NSX-T 4.x with a coat of paint. Reality: the Tier-0 and Tier-1 constructs are still there, but VCF 9 puts a public-cloud-style consumption layer in front of them, and if you keep building the old way you pay for capability you never use. The split between the two models is the single thing to get straight before you design anything.

NSX is no longer a bolt-on

In earlier releases you staged NSX, pushed VIBs to the hosts, and stitched it into vCenter as a separate product. VCF 9 collapses that. The virtual networking kernel modules ship inside ESX, so a new workload domain comes up network-ready without a separate NSX install pass, and NSX lifecycle (certificates, credentials, patches) is handled by the VCF stack with upgrades aligned to the vSphere cycle. Fewer manual steps, fewer version-mismatch incidents, one console to operate. This is the layer you stood up during the VI workload domain deployment in Part 9.

Two object models: Segment and VPC

VCF 9 exposes two networking object models, and the UI makes the split explicit:

• Segment Networking is the world NSX-T admins already know: Tier-0 gateways for north-south routing to the physical fabric, Tier-1 gateways, and overlay or VLAN segments you attach VMs to. The infrastructure team designs and owns this plumbing.
• VPC Networking is the cloud-style consumption layer. It introduces the NSX project as a tenancy boundary, and inside a project, app and platform teams get isolated Virtual Private Clouds with their own subnets, NAT, firewall rules, and load balancing, self-service from vCenter or VCF Automation.

The mental shift is that you stop handing consumers Tier-1s and segments. You hand them a VPC. If the underlay and overlay design is not settled yet, that work sits upstream of all of this, and the network design mistakes from Part 5 are worth a read before you commit a topology.

---

The Transit Gateway, and the project that owns it

The new connectivity construct is the Transit Gateway, a routing hub. Here is the detail people miss: an NSX project has exactly one Transit Gateway, and that gateway interconnects all the VPCs provisioned in the project and provides their path to the outside. You do not attach each VPC to a Tier-0 by hand anymore. The Transit Gateway is the hub, and it comes in two forms that route very differently.

• Centralized Transit Gateway reaches the physical network through an upstream Tier-0 gateway running on NSX Edge nodes. This is the model closest to classic designs and the one you want when you need advanced or stateful north-south services at the edge.
• Distributed Transit Gateway routes on the ESX hosts and connects directly to the physical network over a VLAN, with no NSX Edge VMs in the path. Fewer hops, higher throughput, and no Edge cluster to size.

The distributed model is the genuinely new idea. For years, north-south VPC connectivity meant deploying and sizing Edge VMs, and that was a recurring capacity-planning chore and a frequent bottleneck. In VCF 9 you can skip them for many distributed patterns and let the hosts route. The catch: services that need a centralized enforcement point still pull you back to the Tier-0 path, so the choice is about what services the workloads actually need, not about which one is newer.

Dimension	Centralized TGW	Distributed TGW
External path	Via upstream Tier-0 gateway	Direct to a VLAN from the hosts
NSX Edge nodes	Required	Not required
Data path	Hosts to Edge to fabric	Hosts straight to fabric
Best when	You need stateful or advanced edge services	You want throughput and a thin footprint
Trade-off	Edge cluster to deploy, size, and patch	Edge-only services not available on this path

Inside a VPC: the VPC gateway and the DFW

Each VPC is handed a VPC gateway automatically, and that gateway routes between the subnets inside the same VPC. East-west traffic between those subnets is allowed unless you restrict it, and the thing doing the restricting is the same crown jewel NSX always had: the Distributed Firewall. The DFW enforces rules at each VM virtual NIC, inside the hypervisor, so traffic between two VMs on the same host is inspected without hairpinning to a physical appliance. You write policy against dynamic groups (by tag, name, or OS) rather than IP addresses, so the rule follows the workload as it vMotions. That is the part to design well, because group-based policy is what makes microsegmentation survive a moving fleet.

Distributed Firewall (per vNIC, group-based, follows vMotion)

Action	Source	Destination	Port
allow	any	tier-web	tcp 443
allow	tier-web	tier-app	tcp 8080
allow	tier-app	tier-db	tcp 5432
deny	any	any	any (default)

The bare-metal and L2 caveat

One caution for NSX-T veterans before you upgrade. The way NSX 9 handles physical, bare-metal servers and overlay-backed L2 bridging has changed across the 9.x line, and some attachment patterns that worked under NSX-T 3.x and 4.x do not carry forward unchanged. The Distributed Firewall still protects physical servers, but if your current design bridges bare-metal hosts onto overlay segments or leans on NSX L2 bridging, do not assume it survives the move. Check your exact pattern against the NSX 9 release notes and the VCF 9 networking documentation, and plan that workload deliberately rather than discovering the gap mid-cutover.

Lifecycle and live patching

Because the networking modules live inside ESX, NSX upgrades stop being a separate project. They align with vSphere lifecycle, and vLCM live patching applies many fixes without the rolling host evacuations that NSX-T upgrades used to demand. That removes a real class of incident: the version drift where NSX and vCenter fall out of step and a workflow breaks, because the VCF stack now manages the pairing. You give up some independent-upgrade flexibility in exchange. For most shops that is a good trade, because the flexibility mostly bought you the freedom to create the drift in the first place.

Who owns what

The payoff of the VPC model is that the infrastructure team stops being a ticket queue for subnets. Once the Segment Networking plumbing is designed and the project and its Transit Gateway are in place, a platform or app team can request a VPC with its own subnets, NAT, firewall rules, and load balancing without touching Tier-0 or the physical fabric. Hold the boundary explicitly: infrastructure owns the underlay, the overlay design, the project, and the Transit Gateway; consumers own what lives inside their VPC. The most common failure here is not technical. It is an infrastructure team that keeps doing VPC-level work out of habit and never realizes the self-service benefit it just paid for.

The Bottom Line

NSX in VCF 9 rewards you for not rebuilding your old topology out of muscle memory. Design the Segment Networking layer once, define a project per tenancy boundary, and expose VPCs so consumers self-serve. Reach for a distributed Transit Gateway unless a workload genuinely needs Edge-hosted services, keep the three-node Manager cluster in production, and verify the bare-metal and L2 story against the release notes before any upgrade. Which part of your NSX design are you most likely to over-engineer out of habit, the Edge cluster or the Tier-1 sprawl? That is usually the first thing to simplify. Load balancing inside this model is its own decision, covered in Part 11.

References

• Broadcom TechDocs: What’s New in NSX (VCF 9.1)
• Broadcom TechDocs: Advanced Network Management (VCF 9)
• VCF Blog: Modernize Networking in VCF 9.0

About The Author