Study guide
5.7 VCF Networking Deployment: NSX Instances, Transport Fabric & Edge Clusters
VMware Certified Professional - VMware Cloud Foundation Administrator VCP-VCF 2V0-17.25
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Private Cloud Vision & Architecture
1.1 Private Cloud Principles & The Modern Cloud Operating Model 1.2 VMware Cloud Foundation Architecture & Full-Stack Value Proposition 1.3 Private Cloud Use Cases, Service Models & Workload Strategy
2 Chapter 2: VMware Compute Fundamentals
2.1 ESXi Host & vCenter Architecture and Deployment 2.2 vSphere Cluster Design, High Availability (HA), and DRS 2.3 Virtual Machine Deployment, Advanced Hardware, & Management 2.4 Managing Virtual Machines Through vCenter: Day-2 Operations
3 Chapter 3: VMware Storage Fundamentals
3.1 vSphere Core Storage Architecture: VMFS, NFS, & vVols 3.2 vSAN Architecture: Express Storage Architecture (ESA) vs. Original Storage Architecture (OSA) 3.3 vSAN Cluster Deployment, Storage Pools, & Disk Configurations 3.4 Storage Policy-Based Management (SPBM), Fault Tolerance, & Space Efficiency 3.5 vSAN Resilience & Data Availability: FTT, Fault Domains, and Stretched Clusters 3.6 vSAN Space Efficiency: Compression, Deduplication, TRIM/UNMAP & Reclamation
4 Chapter 4: VMware Network Fundamentals
4.1 VCF Network Architecture & NSX Core Components 4.2 NSX Virtual Network Fabrics, Transport Nodes, & Geneve Overlays 4.3 Edge Clusters, Tier-0/Tier-1 Gateway Routing, & Uplink Connectivity 4.4 NSX Distributed Firewall (DFW) & Distributed Network Services 4.5 VCF 9.0 Virtual Private Clouds (VPCs) & Transit Gateway Connectivity
5 Chapter 5: VCF Deploy and Configure
5.1 VCF Deployment Models: Standard vs. Consolidated & Prerequisites 5.2 VCF Installer Bring-Up & Management Domain Deployment 5.3 VI Workload Domain Deployment, Commissioning Hosts, & Storage Attachment 5.4 vSphere Supervisor Configuration & vSphere Kubernetes Service (VKS) Integration 5.5 VCF Deployment Components & Additional Required Infrastructure 5.6 Deploying & Configuring the VCF Network Gateway 5.7 VCF Networking Deployment: NSX Instances, Transport Fabric & Edge Clusters 5.8 Workload Domain Storage: Principal vs. Supplemental Storage
6 Chapter 6: VCF Manage & Lifecycle Operations
6.1 VCF Fleet Management & Existing vCenter Import Workflows 6.2 Identity Federation, VCF Identity Broker, & RBAC 6.3 Certificate & Password Lifecycle Management in VCF Operations 6.4 Lifecycle Management (LCM), Upgrade Bundles, & Drift Remediation 6.5 License Management in VMware Cloud Foundation
7 Chapter 7: VCF Operations: Architecture, Metrics & Health Diagnostics
7.1 VCF Operations Architecture, Cluster Nodes, & Deployment Options 7.2 Metrics, Properties, Symptom Definitions, & Alerting Mechanics 7.3 Health Diagnostics, Troubleshooting Workflows, & Operational Policies
8 Chapter 8: VCF Operations: Monitoring, Logs & Compliance
8.1 Dashboards, Views, & Management Reporting in VCF Operations 8.2 Storage, Network, and Workload Application Monitoring 8.3 Log Analytics & Troubleshooting with VCF Operations for Logs 8.4 Security Compliance Benchmarks, Hardening, & Configuration Drift 8.5 VCF Operations for Networks: Flow Analytics, Path Troubleshooting & Micro-Segmentation Planning
9 Chapter 9: VCF Consume & Automate: Architecture, Tenancy & Networking
9.1 VCF Automation Architecture, Services, & Automation Use Cases 9.2 Regions, Cloud Zones, Projects, & Multi-Org Tenancy 9.3 Provider Networking, Org Networks, & Content Library Integration
10 Chapter 10: VCF Consume & Automate: Templates, Extensibility & Governance
10.1 Cloud Templates (Blueprints), Schema, & Infrastructure as Code 10.2 Extensibility: Action-Based Extensibility (ABX) & Orchestrator Workflows 10.3 Governance Policies: Approvals, Leases, Resource Quotas, & Day-2 Actions 10.4 Supervisor-Based Services, vSphere Kubernetes Service (VKS), & Modern App Consumption
5.7 VCF Networking Deployment: NSX Instances, Transport Fabric & Edge Clusters
Key Takeaways Explain This Topic AI
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.
Last updated: September 2026
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.