TL;DR · Key Takeaways
- The product is now just VMware NSX 9. The “NSX-T” name is retired and the version line is unified with VCF (NSX 9.0, the 9.0.x patches, and the 9.1 line shipping with VCF 9.1).
- Four things break old habits: N-VDS on ESX is gone (VDS only), the Manager API for networking and security is removed (Policy API only), Enhanced Data Path Standard is the default, and Projects and VPCs make multi-tenancy first-class.
- In VCF 9 you no longer install or upgrade NSX on its own. It is deployed and lifecycle-managed through VCF, and the NSX VIBs ship pre-packaged with ESX.
- Networking and security are licensed separately. The base VCF entitlement covers NSX networking; the Distributed Firewall and threat features need a vDefend add-on at full core count.
- NSX 9 is the networking and security backplane of the VCF private cloud, not an optional bolt-on.
Half the NSX questions I get on design workshops in 2026 still start with “NSX-T”. That name does not exist anymore. Broadcom folded the product into a single version line, dropped the “-T”, and the thing you deploy inside VMware Cloud Foundation 9 is simply NSX 9. The rename is cosmetic. What sits underneath it is not. Carry NSX-T 3.x assumptions into a VCF 9 design and you will plan around host switches, APIs, tenancy models, and license boundaries that are either gone or no longer the default. This series rebuilds NSX from the ground up for that reality, and this first part is the baseline: what NSX 9 is, what genuinely changed, how traffic moves through it, what it costs you in licensing, and where it sits in VCF 9.
What “NSX 9” actually means now
Under Broadcom’s unified versioning, the SDDC components share a major version and move together through one Bill of Materials. vSphere, vSAN, and NSX all carry the 9 line. So NSX 9.0 shipped with VCF 9.0, the 9.0.x patches followed, and the NSX build that rides with VCF 9.1 is the current target as of mid-2026. Re-verify the exact patch level against the release notes before any change window, because in this model the NSX version is pinned to the VCF version you are running, not chosen independently. When you read the documentation, the product lives at the /nsx/vmware-nsx/9-0/ path on Broadcom TechDocs, not under any “NSX-T” tree.
The bigger structural change: in VCF 9, NSX is not a standalone product you stand up by itself. Broadcom’s guidance is blunt. Standalone deployment or upgrade of NSX is not allowed. You either let VCF deploy a fresh NSX, or you import an existing NSX deployment into VCF using the documented brownfield path, and from that point its lifecycle is the fleet’s lifecycle. That one constraint drives most of what follows in this series, because it means every NSX decision is now also a VCF decision.
The four changes that retire your NSX-T habits
If you have run NSX-T, four shifts will reset your instincts. None of them are visible in the name. All of them change how you design, automate, or migrate. Here they are side by side before I take each one apart.
N-VDS on ESX is removed
For years the design conversation was “N-VDS or converged VDS”. That conversation is over. On ESX hosts the vSphere Distributed Switch (VDS 7.0 or later) is the only host switch NSX uses. N-VDS survives only where there is no vSphere underneath, such as bare-metal Edge or Linux transport nodes. If you are coming from an older NSX-T deployment still running N-VDS on hypervisors, the live task is not “which switch” but the N-VDS to VDS migration (Part 27). The trap I see most: assuming a brownfield NSX-T import will quietly carry N-VDS hosts across. It will not. Sort the switch first.
The Manager API for networking and security is gone
NSX historically exposed two API trees: the older Manager (MP) API at /api/v1/ and the declarative Policy API at /policy/api/v1/. In NSX 9 the Policy API is the supported path for networking and security objects. If your automation, Terraform, or home-grown scripts still call the Manager endpoints for segments, gateways, or DFW rules, they need to move. This is not a find-and-replace; the object models differ, and it is the first thing I audit on a brownfield assessment because a half-migrated automation stack is worse than none.
Enhanced Data Path Standard is the default
EDP is the poll-mode, CPU-pinned datapath that gives NSX its throughput on modern NICs. In NSX-T it was a deliberate opt-in. In NSX 9 it is the default mode, and VCF 9 ships inbox NIC driver support (for example the Cisco nenic ENS driver) to make that practical. Good for performance, but EDP reserves CPU cores for the datapath, so the throughput is not free. Size for it, or you trade network performance for compute you did not budget. Part 26 takes this apart properly.
Projects and VPCs make multi-tenancy first-class
NSX 9 treats tenant isolation as a core construct, not something you fake with naming conventions and a wall of firewall rules. Projects give a tenant its own slice of the NSX object space; VPCs give self-service network containers underneath, with their own segments, gateways, and firewall policy. If you have been hand-rolling tenancy in NSX-T with security tags and discipline, this is the most underrated change in the release, and it reshapes how you design shared platforms (Part 22).
Where NSX sits in VCF 9
NSX keeps the classic three-plane shape. A management plane (the NSX Manager cluster, normally three nodes), a control plane (the Central Control Plane that programs the data plane), and the data plane itself, which lives in two places: distributed in every ESX host via the VDS plus EDP, and concentrated in Edge nodes for north-south routing and stateful services. What VCF 9 changes is the layer above. Lifecycle, certificates, and upgrades are driven from VCF, and the NSX kernel modules ship pre-packaged with ESX so an NSX upgrade folds into the VCF upgrade rather than running as its own separately coordinated event. Part 2 breaks this down plane by plane.
How traffic actually flows through NSX
Architecture diagrams are tidy. Packets are not, so it helps to trace a real flow. Say a web VM on an overlay segment needs to reach the internet. East-west first: traffic between two VMs on the same host never leaves the host, the Distributed Firewall checks it in the kernel at the vNIC, and if allowed it is forwarded locally. Cross-host east-west rides the GENEVE overlay between the two ESX transport nodes. North-south is where the Edge earns its keep: the VM’s segment connects to a Tier-1 gateway, the Tier-1 connects up to a Tier-0, and the Tier-0 on an Edge node peers BGP with your physical fabric and applies NAT and the gateway firewall on the way out.
The overlay rides GENEVE, and the MTU rule has not relaxed: plan for at least 1600 bytes end to end, and I push clients to 1700 to leave headroom for the encapsulation header rather than discovering a fragmentation problem in production. Get this wrong on one uplink and you get the classic intermittent failure, small pings fine, large transfers hang. For how this lands in a VCF deployment, see NSX in VCF 9 Explained: Transit Gateways, VPCs and the Distributed Firewall, and for the datapath specifically, how NSX Enhanced Data Path delivers its throughput boost in VCF 9.
The licensing line that catches teams out
Here is the one I watch people walk straight into. The base VCF entitlement gives you NSX networking: segments, Tier-0 and Tier-1 gateways, routing, NAT, DHCP, load balancing, and the stateless gateway firewall. It does not give you the security stack. The Distributed Firewall, stateful gateway firewall, and the threat-prevention features (IDS/IPS, malware prevention) sit behind a separate VMware vDefend add-on, and the vDefend Firewall license has to match your full VCF core count. You cannot license it for “just the hosts that need micro-segmentation”.
| Capability | In base VCF? | Needs vDefend add-on? |
|---|---|---|
| Segments, Tier-0/Tier-1, routing, BGP, NAT, DHCP | Yes | No |
| Stateless gateway firewall | Yes | No |
| Distributed Firewall (micro-segmentation) | No | Yes (vDefend Firewall) |
| Stateful gateway firewall | No | Yes (vDefend Firewall) |
| IDS/IPS, malware prevention, NDR | No | Yes (vDefend Firewall with ATP) |
The value, stated honestly
What NSX 9 is genuinely good at: putting firewalling in the hypervisor so policy follows the VM, decoupling logical networks from physical topology so you stop renumbering VLANs every time an app moves, and giving you one security and networking model across the whole VCF fleet. Micro-segmentation that would be a change-control nightmare on physical kit becomes a policy object enforced in the kernel at each vNIC. That is the real reason NSX exists, and on a greenfield VCF 9 build it is hard to argue against.
Where it bites: the Distributed Firewall is powerful and unforgiving. It evaluates rules in ordered categories (Ethernet, Emergency, Infrastructure, Environment, Application) with an Applied-To that scopes where each rule lands. Publish a rule with the wrong Applied-To and you can take out a whole segment, and I have watched it happen in a live environment. Edge nodes get under-sized for real north-south throughput because someone read the data sheet and not the design guide. And the operational model assumes you actually run VCF’s lifecycle discipline; bolt NSX onto a poorly governed estate and you have simply moved the mess into software. NSX 9 does not make a sloppy network tidy. It makes a well-designed one programmable.
My Take
If you are standing up VCF 9, NSX is not a decision you get to defer. It is the networking and security plane of the platform, and the sooner you stop treating it as “the NSX-T thing we used to bolt on” the better your design will be. Treat the version rename as a prompt to re-verify three things: your host switches (VDS only), your automation (Policy API only), and your licensing (vDefend for security). Get those three straight and the rest of this series is detail. The next post breaks down the architecture plane by plane so you know exactly what each component does before you design with it. Which of the three, switches, API, or licensing, is most likely to bite your environment?
Reading NSX 9 against your NSX-T 3.x habits
If you are coming from NSX-T 3.x, the fastest way to orient yourself is to hold the changes in your head as a short list rather than relearning the whole product. NSX 9 is the rebranded, VCF-integrated evolution of the same platform, and the headline shifts are concrete: the N-VDS host switch on ESX is gone and the VDS carries everything, the Manager API for logical networking and security is retired in favour of the Policy API, Enhanced Data Path Standard is the default host-switch mode rather than an opt-in, and VPCs with Projects are now a first-class multi-tenancy capability rather than an afterthought.
None of those are cosmetic. Each one changes a design or an operational habit you carried for years, and writing to NSX-T 3.x muscle memory is the most common way experienced engineers trip on NSX 9. Treat this Part as the map, and treat that short list as the set of assumptions to re-examine before you reuse an old design. The product is familiar; the defaults and the supported paths are not, and the gap between them is exactly where the avoidable mistakes live.
References
- VMware Cloud Foundation 9.0 Release Notes (Broadcom TechDocs)
- NSX 9.0.1 Release Notes (Broadcom TechDocs)
- Virtual Private Cloud in NSX and security licensing (Broadcom TechDocs, VCF 9)
- NSX in VCF 9: Guidance to Set Maximum Transmission Unit (Broadcom TechDocs)
About The Author
