Designing A VMware NSX-T Logical Network With Tier-0 And Tier-1 Gateways
A well-designed VMware NSX-T network separates workload connectivity, routing policy, and physical network integration. The Tier-0 gateway connects the virtual environment to the external network, while one or more Tier-1 gateways provide services and routing boundaries closer to applications. This layered model supports scalable east-west traffic, controlled north-south access, and clearer operational ownership.
The design must account for more than gateway creation. Transport nodes, transport zones, uplink profiles, edge nodes, VLAN and overlay segments, dynamic routing, and failover behavior all affect the final result. A functional lab configuration can be built quickly, but a production-ready topology requires deliberate decisions about high availability, IP addressing, MTU, and traffic flows.
The following approach focuses on the logical network components that administrators configure in NSX-T, along with the physical dependencies that must be validated before workloads are connected.
Establish The Underlay And Transport Foundation
NSX-T relies on a physical IP underlay that provides reachability between ESXi transport nodes and the NSX Edge nodes. The underlay does not need to understand every overlay segment, but it must provide reliable Layer 3 connectivity for Geneve tunnel endpoints. Consistent MTU settings are essential because encapsulation adds overhead to packets crossing the overlay.
Create an uplink profile that matches the physical design. It should define the active and standby uplinks, transport VLAN, teaming policy, and maximum transmission unit. Host transport nodes typically use an overlay transport zone, while Edge nodes commonly participate in both an overlay transport zone and a VLAN transport zone. The VLAN zone supports connectivity to external routers, firewalls, and other physical services.
Before moving forward, verify DNS, NTP, management reachability, vCenter registration, and host-to-host tunnel establishment. A simple ping test is insufficient; validate Geneve encapsulation and confirm that the selected physical switches allow the required VLANs and MTU.
Build Segments For Workload Connectivity
Segments are the logical Layer 2 networks assigned to virtual machines, appliances, and other workloads. An overlay segment is backed by Geneve and can span transport nodes that share the same overlay transport zone. A VLAN-backed segment uses the physical network directly and is useful for external handoffs, legacy systems, or services that must remain outside the overlay.
Each workload segment should have a clear purpose and addressing plan. For example, separate application, database, management, backup, and DMZ networks reduce ambiguity and make security policy easier to maintain. Avoid stretching every VLAN into the virtual environment simply because NSX-T can support it; routing at the closest practical boundary usually produces a simpler failure domain.
A segment can connect to a Tier-1 gateway, remain isolated, or attach to other services depending on the design. The default gateway address belongs to the logical router associated with the segment. Document the subnet, gateway IP, DHCP behavior, DNS settings, and intended security policy before deploying application workloads.
Position The Tier-0 Gateway
The Tier-0 gateway is the north-south routing boundary between NSX-T and the physical network. It runs on Edge nodes and can use static routes or dynamic routing protocols such as BGP. In a resilient production design, deploy at least two Edge nodes in an Edge cluster and distribute them across suitable hosts or failure domains.
A Tier-0 gateway can operate in active-standby or active-active mode, depending on the requirements for scale and routing behavior. Active-active designs can provide greater throughput, but they require careful consideration of equal-cost paths, route advertisement, and stateful services. Active-standby may be easier to operate when predictable traffic ownership is more important than maximum parallel forwarding.
BGP is often preferable for larger environments because route changes can be learned and advertised dynamically. Define the local autonomous system, neighbor addresses, remote autonomous system, authentication, and route filters. Confirm whether the Tier-0 should advertise all connected prefixes or only selected networks. Restricting advertisements helps prevent accidental exposure of transit, infrastructure, or management subnets.
Connect Tier-1 Gateways To Applications
Tier-1 gateways provide a second routing layer below Tier-0. They connect to overlay segments and use a Tier-0 gateway for north-south reachability. This arrangement allows application groups to have independent routing and security policies without requiring a separate physical router for every environment.
Create separate Tier-1 gateways when application ownership, lifecycle, security policy, or failure isolation justifies the boundary. A shared Tier-1 may be appropriate for a small environment, while production platforms often use distinct gateways for development, testing, business applications, and DMZ workloads.
Tier-1 gateways can host services such as distributed or centralized NAT, DHCP, and load balancing, depending on the NSX-T version and licensed features. Stateful services may influence whether traffic remains distributed across hosts or is redirected through Edge nodes. When an application also uses an external web application firewall or ingress control, review the application security pattern alongside the NSX-T routing path so inspection points are intentional rather than accidental.
Choose A Routing And Availability Model
The relationship between Tier-0 and Tier-1 gateways is commonly configured as a routed hierarchy, with Tier-1 gateways connected to a Tier-0 gateway through logical router links. The Tier-1 advertises connected workload networks upward, and the Tier-0 advertises approved external routes downward. This creates a predictable path for north-south traffic while keeping east-west traffic distributed across the ESXi hosts.
The main design choices should be documented before implementation:
| Design Area | Common Choice | Operational Consideration |
|---|---|---|
| Tier-0 routing | BGP | Supports dynamic failover and route control |
| Tier-1 placement | One per environment or application domain | Improves ownership and policy separation |
| Edge cluster | Two or more Edge nodes | Reduces impact of node failure |
| Workload network | Overlay segments | Enables mobility across transport nodes |
| External handoff | VLAN-backed segment | Connects Tier-0 to physical routers or firewalls |
| High availability | Active-active or active-standby | Balances throughput, simplicity, and state handling |
| MTU | Underlay sized for Geneve overhead | Prevents fragmentation and tunnel failures |
Test failover with realistic traffic rather than relying only on control-plane status. Shut down an Edge node, withdraw a BGP neighbor, and move a workload between hosts. Observe route convergence, session behavior, and application recovery. Stateful NAT or load-balancing flows may behave differently from ordinary routed traffic.
Validate Security And Operations
Routing determines reachability, but it does not replace security policy. Use distributed firewall rules to restrict east-west communication between segments and workloads. Apply a default-deny approach where practical, then permit required application flows by role, tag, service, or IP set. Keep infrastructure exceptions documented and narrowly scoped.
North-south traffic may pass through a physical firewall, an NSX gateway firewall, or both. Define where inspection occurs and prevent asymmetric paths that cause stateful devices to drop valid sessions. If load balancers, NAT, VPN, or service insertion are included, map each virtual IP and traffic path before enabling production access.
Operational readiness depends on observability. Monitor BGP sessions, Edge node health, tunnel status, gateway interfaces, packet drops, CPU, memory, and connection counts. Maintain configuration exports and record the relationship between Tier-0 gateways, Tier-1 gateways, segments, transport nodes, and physical switch ports.
Recommended Implementation Practices
Start with a small, representative workload rather than migrating every network at once. A test application with frontend, database, and management segments can confirm overlay reachability, routing, firewall behavior, and external access. Capture expected routes and packet paths before testing so deviations are easier to identify.
Use repeatable configuration standards for names, tags, IP allocation, gateway placement, and BGP policy. Automation through Terraform, PowerCLI, or the NSX-T Policy API can reduce configuration drift after the initial design has been proven manually.
- Use redundant Edge nodes and place them across independent host or rack failure domains.
- Validate Geneve MTU end to end before troubleshooting overlay connectivity.
- Advertise only the workload prefixes that external networks need to know.
- Separate Tier-1 gateways when ownership, security, or lifecycle boundaries require it.
- Test routing convergence and stateful service behavior during planned maintenance.
A successful NSX-T logical network is one that remains understandable during an outage. Build the Tier-0 and Tier-1 hierarchy around clear traffic flows, verify every physical dependency, and test failure scenarios before production cutover. Then document the working design and automate the repeatable parts so future environments can be deployed consistently.