// Guide · Design & architecture

NSX Segment & T1 Gateway Planner

Design your NSX network topology — Tier-1 gateways and the overlay/VLAN-backed segments attached to them. Validate CIDR allocations for conflicts, configure DHCP server or relay per segment, set route advertisement policies, then export as production-ready Terraform HCL or PowerCLI scripts.

Tier-1 GatewaysOverlay SegmentsVLAN-backedCIDR ValidationDHCP Server / RelayTerraform HCLPowerCLI Export

Open the tool Jump to walkthrough

Quick start

Add Tier-1 gateways — name, HA mode (Active-Standby or Active-Active), preemption policy.
Add segments — overlay or VLAN-backed, attach to a T1, set CIDR and gateway IP.
Configure DHCP per segment — none (static), DHCP server (NSX-managed), or DHCP relay (forwards to external).
Validate — tool checks for CIDR overlaps, naming conflicts, unattached segments, missing route advertisements.
Export — Terraform HCL for IaC pipelines, or PowerCLI for direct application.

On this page

When to use this tool
How it works
Step-by-step walkthrough
Examples
Common mistakes
Related tools
FAQ

When to use this tool

Use this tool when you need to:

Plan a new NSX overlay topology — many T1 gateways, many segments, all the relationships between them.
Validate CIDR allocations against an existing IP plan to spot overlaps before they go live.
Generate IaC artifacts — Terraform HCL for GitOps workflows, or PowerCLI for one-off automation.
Document the network topology for handoff to security or operations teams.
Compare designs — does it cost less complexity to use one big T1 with many segments, or multiple T1s for isolation?

How it works

NSX uses a 2-tier routing model: Tier-0 (north-south, connects to physical fabric via BGP) → Tier-1 (east-west, hosts segments). This tool focuses on the T1 + segment layer where most workload traffic lives.

A Tier-1 gateway is a logical router with:

HA mode: Active-Standby (one active edge node) or Active-Active (multiple)
Preemption: whether the original active resumes when it returns from failure
Route advertisement policies: what subnets to advertise upstream to T0/BGP

Segments attach to a T1 and provide L2 broadcast domains. Each segment has a CIDR, gateway IP, and optional DHCP. Overlay segments use GENEVE encapsulation (workload traffic); VLAN-backed segments traverse the physical VLAN (typically used for management or services that need physical visibility).

Step-by-step walkthrough

1. Add Tier-1 gateways

Click Add Gateway. Configure:

Name — e.g. t1-prod-app, t1-dev
HA mode — Active-Standby (simpler, default) or Active-Active (higher throughput, ECMP)
Preemption — Preemptive (active resumes after failover) or Non-preemptive (failover sticks). Non-preemptive is generally preferred to avoid traffic disruption when failed edges return.
Edge cluster — which NSX edge cluster hosts this T1

Plan T1 boundaries: typically one T1 per workload domain or per security zone. Don't overload a single T1 with hundreds of segments — split for blast-radius isolation.

2. Add overlay segments

Click Add Segment on a T1 row. For overlay (default for VCF):

Name — e.g. web-tier, db-tier
Type — Overlay
CIDR — e.g. 10.10.1.0/24
Gateway IP — typically .1 within the CIDR

Tool validates CIDR doesn't overlap any other segment in the design.

3. Add VLAN-backed segments

For services that need physical VLAN visibility (load balancers, legacy management):

Type — VLAN-backed
VLAN ID — the trunked VLAN this segment maps to
Transport zone — VLAN transport zone (vs overlay TZ for overlay segments)

4. Configure DHCP

Per segment, choose:

None (static only) — VMs use static IP. Common for servers.
DHCP Server — NSX runs DHCP for this segment. Specify IP pool range, DNS servers, lease time. Common for end-user/dev segments.
DHCP Relay — forward DHCP to an external server (typically Microsoft DHCP or Infoblox). Specify relay server IP. Common for enterprises with central DHCP.

5. Set route advertisements

Per T1, configure what gets advertised upstream to T0 (and from T0 via BGP to physical fabric):

Connected segments — usually yes, so VM CIDRs are reachable
Static routes — if any defined
NAT IPs — for NAT'd workloads
LB VIPs — for load-balanced services

6. Run validation

Click the Validate tab. Common findings:

CIDR overlaps between segments
Segments without parent T1 attachment
T1s without route advertisement (segments unreachable)
DHCP pool exceeds segment CIDR
Duplicate names

7. Export — Terraform or PowerCLI

Pick export format:

Terraform HCL — uses the official NSX Terraform provider. Drop into your IaC repo, run terraform apply against your NSX manager.
PowerCLI — uses PowerCLI cmdlets (New-NsxTier1, New-NsxSegment). Run from a workstation with NSX module installed.

Both produce idempotent, repeatable artifacts — apply, then re-apply gives same result.

Examples

Example · 3-tier app deployment

One T1 per workload, three segments per app:

T1: t1-app01, Active-Standby, non-preemptive
Segment: app01-web overlay, 10.20.1.0/24, DHCP server
Segment: app01-app overlay, 10.20.2.0/24, static
Segment: app01-db overlay, 10.20.3.0/24, static
Route advertisement: connected segments only (VMs reachable from physical via T0)

Example · Multi-tenant with isolation

Each tenant gets its own T1 (no east-west between tenants without explicit firewall rule):

T1: t1-tenant-a → segments tenantA-web/app/db
T1: t1-tenant-b → segments tenantB-web/app/db
T1: t1-shared → DNS, AD, monitoring (selectively reachable from each tenant)

Inter-T1 communication happens via T0 with explicit DFW/gateway firewall rules — natural blast-radius isolation.

Common mistakes

🚨

CIDR overlaps with physical network Tool checks for overlaps within the design but can't see your physical network CIDRs. If your overlay segment uses 10.10.1.0/24 and your physical also uses 10.10.1.0/24 somewhere, you've created routing chaos. Cross-check against your IP plan.

⚠

Active-Active without ECMP-aware apps Active-Active T1 gateways use ECMP — packets within a flow may take different paths. Most TCP apps handle this fine, but some appliances (legacy firewalls, certain load balancers) misbehave. Use Active-Standby unless you specifically need ECMP throughput.

⚠

Forgetting route advertisement A segment without route advertisement to T0 is invisible to the rest of the world — VMs can't reach anything outside their segment. Common cause of "I deployed the segment but nothing works." The validator catches this.

⚠

DHCP pool > segment CIDR Setting a DHCP pool of 10.20.1.10-200 on a /26 segment doesn't work — the pool exceeds the subnet. Tool flags this; size the pool within the segment's usable range.

⚠

Treating overlay and VLAN segments interchangeably They're fundamentally different. Overlay = NSX manages everything, no physical VLAN consumed. VLAN-backed = consumes a physical VLAN, traverses the physical fabric, no NSX encapsulation. Pick based on whether the workload needs physical visibility.

Tools that pair well with NSX Segment & T1 Gateway Planner:

FAQ

Does this generate Tier-0 configuration too?

No — focus is T1 + segments (the layer most workload changes happen at). T0 is typically configured once during NSX deployment and rarely changes. Use VMware's official guidance for T0/BGP setup.

Can I import an existing NSX configuration?

Not currently — design starts blank. You can manually replicate an existing topology to use as a documentation/migration starting point.

Will the Terraform output work with NSX-T 3.x and NSX 4.x?

Yes — uses the official NSX Terraform provider which supports both. The provider negotiates correct API version. Verify the resource types match if using older provider versions.

How do I handle segment migration between T1s?

Detach from source T1, attach to target T1. The tool models the desired state — for migration runbooks, use the Day 2 Operations Planner.

What's the difference between DHCP server and DHCP relay?

Server: NSX itself runs DHCP for the segment (good for isolated NSX-managed networks). Relay: NSX forwards DHCP requests to an external server (good for enterprise environments with central DHCP/DNS like Microsoft AD).

Should I use Active-Active or Active-Standby?

Active-Standby for almost everything. Active-Active only when you need >10 Gbps north-south throughput on a single T1 and your workloads tolerate ECMP. Active-Standby is simpler to operate and troubleshoot.