NSX for Dummies, Part 2: How an NSX Overlay Fits Together

Part 1 introduced the envelope model. This part explains the components that make that model work, and the design decisions they force you to make. You do not need to deploy any of this to understand it.

The NSX stack

NSX Manager        -> holds and publishes desired configuration
Transport zone     -> defines which hosts can participate in an overlay
TEP                -> a host's tunnel address on the physical underlay
Segment            -> a logical Layer 2 network for workloads
Tier-1 gateway     -> routes inside an application or tenant environment
Tier-0 gateway     -> connects that environment to the physical network
Edge node          -> provides north-south and stateful gateway services
DFW                -> enforces policy at workload virtual NICs

This is not a chain where every packet visits every component. NSX Manager is primarily the control plane: it tells hosts and edges how the network should look. Normal workload traffic uses the data plane already programmed into ESXi hosts and edge nodes.

Transport zones and tunnel endpoints

A transport zone is an eligibility boundary. It says, “these hosts may participate in these logical networks.” An overlay transport zone lets hosts exchange encapsulated workload traffic.

Each prepared host gets a tunnel endpoint (TEP). The TEP is the underlay IP address used on the outside of the Geneve envelope.

VM packet:        10.10.10.20 -> 10.10.20.20
Geneve outer path: TEP-host-01 -> TEP-host-05

The physical network does not need to know the VM subnet. It needs a stable, routable path between host TEPs. IP reachability, MTU, uplink redundancy, and physical switch consistency are therefore part of the NSX design, not background details.

Segments and gateways

An NSX segment is where workloads connect. It supplies a logical Layer 2 domain and, when attached to a gateway, an IP subnet. The difference from a VLAN is ownership: the segment belongs to software policy, not to a list of physical switch ports.

Web segment ----\
                 [Tier-1: payments] ---- [Tier-0: shared border] ---- physical network
App segment ----/

A Tier-1 gateway is usually an application, tenant, or environment boundary. It provides distributed routing between attached segments. A Tier-0 gateway is the shared border that connects Tier-1s to the physical network and external services.

This is an ownership model as much as a routing model. The team that owns the physical border can standardize Tier-0 routing and BGP. Platform teams can then consume Tier-1s and segments without negotiating every application subnet with the physical network team.

Distributed Firewall: policy follows the workload

Traditional firewalls mostly live at a subnet or perimeter boundary. NSX Distributed Firewall is enforced close to each protected workload vNIC. It can control traffic between two VMs on the same segment, even though neither packet needs to reach a central firewall appliance.

The practical design unit becomes a group, not an IP address. A group can represent payments-web, payments-db, or backup-admin using tags and workload attributes. Policy describes allowed dependencies between groups.

payments-web -> payments-api : TCP 8443
payments-api -> payments-db  : TCP 5432
everything else              : denied by the intended security posture

That is the foundation vDefend builds on in Part 4.

Questions to answer before implementation

Which hosts belong in each transport zone?
Which physical networks carry TEP and edge uplink traffic?
Which application boundaries deserve separate Tier-1 gateways?
Which team owns Tier-0 routing, BGP, and physical return routes?
Which workload tags and groups will form the basis of security policy?

If those answers are vague, more configuration will not make the design clearer.

What’s next

Part 3 follows traffic through the gateway and edge layer. Part 4 adds vDefend, showing how NSX workload context becomes distributed security policy and selective threat inspection.