Academy/VCF 9.0 Support (2V0-15.25)/Networking Core Concepts — NSX Architecture
This lab targets VCF 9.0

Networking Core Concepts — NSX Architecture

VCF 9.0Beginnersupportadmin⏱ 60 min

VCFFTS9 course content — VCF 9.0 focused

Objectives

  • Describe NSX three-plane architecture (management, control, data)
  • Explain overlay networking concepts (TEPs, GENEVE, transport zones, segments)
  • Describe VPC constructs in NSX for multi-tenancy
  • Differentiate Tier-0 (north-south) from Tier-1 (east-west) gateways
  • List NSX networking services (NAT, DHCP, DNS, LB, L2 VPN)

Prerequisites

Active Holodeck VCF 9.0 lab or access to VCF documentation

Required skills:

  • Basic VMware terminology

Tasks

Task 1 NSX Architecture & Overlay Networking

NSX architecture in VCF is tightly integrated — NSX Manager deploys during VCF bring-up, not separately. Understanding overlay vs VLAN-backed transport zones and when to use each is a key design decision.

Understand NSX three-plane architecture and overlay networking

Step 1
NSX Three-Plane Architecture

Management Plane: NSX Manager cluster (3 nodes for HA), built-in policy/manager/controller roles. Policy role: centralized config for networking and security. Manager role: prepares data plane components. Controller role: maintains realized state, configures data plane. Data Plane: ESX hosts (transport nodes) + NSX Edge nodes. Architectural separation enables scalability without affecting workloads.

Step 2
NSX Overlay Networking

Transport nodes: ESX hosts and Edge nodes prepared for NSX. TEP (Tunnel End Points): encapsulate/decapsulate overlay traffic using GENEVE protocol. Transport zones: overlay (GENEVE tunnels) or VLAN-backed. Segments: L2 broadcast domains in the overlay network. N-VDS: NSX-managed virtual distributed switch.

[HOLODECK NOTE] In Holodeck, GENEVE overlay tunnels run over virtual NICs between nested ESXi hosts. TEP (Tunnel Endpoint) traffic traverses the physical host's virtual switch — there is no physical network underlay separation. MTU 1700+ requirement for GENEVE is handled at the virtual switch level. Overlay performance in nested environments is significantly lower than bare-metal due to double encapsulation overhead.

Step 3
Virtual Private Clouds (VPCs)

NSX Projects segment a single NSX deployment into multiple tenants. Each project contains one or more VPCs. VPC constructs: subnets (public/private), gateways, security policies. Native VPCs in vCenter and VCF Automation — VI admins create/manage VPCs via vCenter UI or automate with VCF Automation.

Validation Gate

Check: Explain the difference between overlay and VLAN-backed transport zones and when to use each in VCF

Expected: Overlay: GENEVE-encapsulated, supports micro-segmentation, spans hosts without VLAN provisioning on physical switches. Use for workload segments. VLAN-backed: no encapsulation, maps to physical VLANs, used for uplinks, management, vMotion. Use for infrastructure traffic.

Common Errors

Deploying NSX Manager as a single node in production
Fix: NSX Manager must be a 3-node cluster for production (VCF HA deployment). Single-node is Simple deployment only. Loss of the single NSX Manager means complete loss of control plane — no DFW rule changes, no segment provisioning, no Edge redeployment.
Not understanding GENEVE encapsulation overhead
Fix: NSX overlay uses GENEVE encapsulation adding ~50 bytes per packet. Physical MTU must be 9000 (jumbo frames) to avoid fragmentation. If physical switches don't support MTU 9000, overlay performance degrades significantly. Verify MTU end-to-end before deploying overlay segments.
Confusing T0 and T1 gateway roles
Fix: T0 (Tier-0): north-south gateway connecting to physical network via BGP/static routes. Runs on Edge VMs. T1 (Tier-1): tenant/workload gateway providing services (NAT, LB, firewall) to connected segments. T1 connects upward to T0. In VCF, T0 is shared across domains; T1 is per-tenant or per-workload.

Task 2 NSX Routing & Services

NSX security features (DFW, Gateway Firewall, IDS/IPS) are layered — understanding which operates where and what each protects against is essential for security architecture.

Understand Tier-0/Tier-1 routing and NSX networking services

Step 1
NSX Routing — Tier-0 and Tier-1 Gateways

Tier-0: north-south routing, connects overlay to physical network via BGP/OSPF/static routes, runs on Edge cluster. Tier-1: east-west routing, connected to Tier-0, provides gateway services to segments. Edge cluster: active-standby or active-active deployment modes.

[HOLODECK NOTE] Tier-0 gateway BGP peering in Holodeck connects to a simulated physical router (often VyOS or similar VM). North-south traffic performance is limited by nested virtualization. In production, Tier-0 runs on dedicated Edge nodes with SR-IOV or DPDK for line-rate forwarding — Holodeck cannot replicate this performance.

Step 2
NSX Networking Services

NAT: source/destination NAT on gateways. DHCP: server or relay on segments. DNS: forwarder on gateways. Load Balancing: must be attached to Tier-1 gateway, includes virtual servers, profiles, server pools, health monitors. Tier-1 must run on Edge cluster in active-standby mode for LB. L2 VPN: extends overlay/VLAN segments across sites on same broadcast domain — requires Tier-0 in active-standby mode, configured from NSX UI.

Validation Gate

Check: Where does DFW enforce rules — on the ESXi host kernel or on Edge VMs?

Expected: DFW enforces on the ESXi host kernel via dvfilter — at the vNIC level of each VM. This is east-west (VM-to-VM) traffic. Gateway Firewall enforces on Edge VMs — this is north-south (VM-to-physical) traffic. They are complementary, not redundant.

Common Errors

Assuming DFW rules require NSX Manager to be online for enforcement
Fix: DFW rules are programmed into the ESXi kernel (dvfilter). Once realized, they persist even if all NSX Manager nodes go down. New rules cannot be created or modified without NSX Manager, but existing rules continue enforcing.
Not planning Edge VM sizing for service insertion
Fix: Edge VMs handle north-south traffic + services (NAT, IDS/IPS, gateway firewall). Each service consumes CPU beyond raw packet forwarding. Size Edge VMs based on throughput + services, not just throughput alone. Medium: 2-4 Gbps. Large: 10+ Gbps with DPDK.

Design Reflection (VCDX)

NSX architecture questions in VCDX defense focus on overlay justification (why not VLANs?), Edge sizing methodology, and DFW data-plane/control-plane separation. Be prepared to defend your overlay choice with customer-specific reasoning.

Requirements

  • Understand NSX overlay and VLAN-backed transport zones
  • Know T0/T1 gateway architecture and placement
  • Explain DFW enforcement location and control plane separation

Constraints

  • Physical switches must support MTU 9000 for overlay
  • NSX Manager cluster requires 3 nodes for HA
  • Edge VM sizing must account for services, not just throughput

Assumptions

  • Physical underlay supports GENEVE encapsulation
  • BGP peering available for T0 north-south connectivity

Risks

  • MTU mismatch causing overlay fragmentation and performance degradation
  • Single NSX Manager node creating control plane SPOF

⚠ Known Pitfalls (from Community KB)

Citing DFW as a replacement for perimeter firewall — DFW handles east-west micro-segmentation; you still need north-south gateway firewall or physical firewall for perimeter security.
Forgetting that overlay encapsulation adds 50 bytes — if physical MTU is 1500, effective payload drops to ~1450 bytes, causing TCP MSS issues.

References

Was this page useful?
Type to search. ↑ ↓ to move, Enter to open, Esc to close.