5.7 VCF Networking Deployment: NSX Instances, Transport Fabric & Edge Clusters
Key Takeaways
- The management domain always receives its own NSX Manager cluster; VI workload domains can each receive a dedicated NSX instance or share one, and that choice is made at workload domain creation.
- Sharing an NSX instance across VI workload domains means sharing its security policy scope and its upgrade cycle, so the decision is a governance and lifecycle decision rather than a licensing one.
- Host transport node preparation installs the kernel modules and creates Geneve tunnel endpoints, drawing addresses from a TEP pool and applying an uplink profile that sets teaming policy, transport VLAN, and MTU.
- Overlay transport zones carry Geneve-encapsulated segments while VLAN transport zones carry untunnelled traffic; a transport node joins the zones whose traffic it must handle.
- The SDDC Manager UI for deploying Application Virtual Networks was removed in VCF 9.0 and replaced by API-driven deployment through VCF Operations.
5.7 VCF Networking Deployment: NSX Instances, Transport Fabric & Edge Clusters
Exam Focus: The blueprint objective is "describe the deployment of VMware Cloud Foundation (VCF) Networking". Earlier sections established what NSX components are; this one covers how VCF provisions them during and after bring-up, and the decisions an administrator makes along the way.
NSX Manager Cluster Placement
Every VCF instance begins with an NSX Manager cluster for the management domain, deployed automatically during bring-up as three appliances with a cluster virtual IP. That much is not optional.
The interesting decision arrives with the first VI workload domain, where the administrator chooses between two models:
| Dedicated NSX instance | Shared NSX instance | |
|---|---|---|
| Appliances | A new three-node cluster per workload domain | Reuses an existing workload domain's cluster |
| Security policy scope | Fully isolated — policies cannot leak across domains | Shared — one policy namespace spans the domains |
| Upgrade cycle | Independent; domains can be upgraded on separate schedules | Coupled — upgrading NSX upgrades it for every domain using it |
| Resource cost | Three additional appliances per domain | None |
| Typical driver | Regulatory separation, independent change control | Consolidation, smaller environments, shared services |
[!IMPORTANT] Sharing couples lifecycles, and that is the exam point. Candidates often evaluate this choice on appliance count alone. The consequential differences are that a shared instance places both domains in one security policy scope and one upgrade cycle. If a scenario says two workload domains must be patched on independent schedules, or that one must be isolated for compliance, dedicated instances are required.
Preparing Host Transport Nodes
A cluster's ESX hosts do not participate in the overlay until they are prepared as transport nodes. VCF drives this automatically as part of workload domain and cluster creation. Preparation performs three things:
- Installs the kernel modules that implement distributed switching, distributed routing, and the distributed firewall in the VMkernel I/O chain.
- Creates Geneve tunnel endpoints (TEPs) as VMkernel adapters, addressed from a TEP pool — either a static IP pool defined for the domain or DHCP.
- Applies an uplink profile, which is the configuration object that carries the settings most likely to be wrong.
The Uplink Profile
An uplink profile defines:
- Teaming policy — how uplinks are used (failover order, load balance by source), and how many are active or standby.
- Transport VLAN — the VLAN ID that TEP traffic is tagged with.
- MTU — which must satisfy the Geneve overhead requirement of at least 1700 bytes, with 9000 the common standard.
A mismatch between the uplink profile MTU and the physical switch configuration is one of the most common causes of tunnels that establish but drop large frames — connectivity appears to work until an application sends a full-size packet.
Transport Zones: What Traffic a Node Can Carry
A transport zone defines the span of a set of segments — which transport nodes can participate in them.
| Zone type | Carries | Typical members |
|---|---|---|
| Overlay transport zone | Geneve-encapsulated segments, tunnelled between TEPs | Host transport nodes and Edge transport nodes |
| VLAN transport zone | Untunnelled VLAN-backed traffic | Edge transport nodes for uplinks; hosts where VLAN-backed port groups are needed |
A node joins the zones whose traffic it must handle. An Edge node typically belongs to both — the overlay zone to reach workloads, and a VLAN zone to reach the physical fabric through its uplinks.
Edge Cluster Deployment
Edge transport nodes are deployed when centralised services are required — the services router component that hosts BGP peering, NAT, gateway firewalling, VPN, and load balancing.
Deployment decisions:
- Form factor — VM appliances in sizes matched to throughput, or bare metal for the highest performance.
- Sizing — larger form factors provide more DPDK fast-path cores and memory.
- Placement — Edge VMs should be distributed across hosts so that one host failure cannot take out both members of an active-standby pair.
- Uplink connectivity — VLANs and interfaces connecting to the top-of-rack switches for BGP peering.
As established in the previous section, VCF 9.0 can install Edge nodes and Edge clusters as part of the guided connectivity workflow, and a Distributed Transit Gateway removes the Edge requirement entirely for suitable VLAN-backed topologies.
Application Virtual Networks and What Changed in 9.0
VCF historically deployed Application Virtual Networks (AVNs) — overlay-backed segments for management applications, giving them portability and protection behind the Tier-0.
In VCF 9.0 the mechanism changed: the SDDC Manager UI for deploying Application Virtual Networks was removed and replaced by API functionality, consistent with the broader move of management surfaces from SDDC Manager to VCF Operations. Study material that instructs an administrator to deploy AVNs from the SDDC Manager UI is describing a removed capability.
Exam Watch: Key Scenarios and Candidate Traps
[!WARNING] Tunnels up but large packets failing is an MTU story. When a scenario describes successful pings and broken application traffic, look for an uplink profile or physical switch MTU below the 1700-byte minimum rather than a routing or firewall fault.
[!TIP] Independent patching schedules force dedicated NSX instances. Shared instances share an upgrade cycle. This is the cleanest discriminator between the two models when a scenario gives you a change-control constraint.
Two VI workload domains must be patched on completely independent change-control schedules, and a compliance mandate requires that security policy in one cannot reference or affect objects in the other. Which NSX deployment model is required?
After a new cluster is added to a VI workload domain, virtual machines can ping each other successfully but application sessions carrying larger payloads fail intermittently. Which configuration should be examined first?
What is the purpose of an overlay transport zone in a VMware Cloud Foundation deployment?
An administrator following a VCF 5.x runbook attempts to deploy Application Virtual Networks from the SDDC Manager user interface in a VCF 9.0 environment but cannot find the workflow. What is the correct explanation?