NSX-T T1 Gateway: Does a T1 Without an SR Still Live on the Edge Cluster?
The Two Components of Every NSX-T Gateway
Every Tier-0 and Tier-1 Gateway in NSX-T is logically made up of two distinct functional components:
- Distributed Router (DR) — runs on every transport node (hypervisor) that hosts a connected workload segment. It handles east-west routing entirely in the data plane of the host, with no hairpinning through a centralised appliance.
- Services Router (SR) — a centralised component instantiated on the Edge cluster. It handles stateful services that cannot be distributed: NAT, load balancing, stateful gateway firewall, and VPN termination.
The key insight is this: the SR is optional on a T1. NSX-T will only instantiate a T1 SR on the Edge cluster if you configure a service that actually requires it. Without such a service, the T1 remains a purely distributed router.
Architecture Diagram
The Short Answer
No — a T1 without an SR does not reside on the Edge cluster at all. The T1 DR continues to operate on every hypervisor hosting a connected segment, but there is no Edge component, no Edge Edge Node allocated, and no traffic path through the Edge for that T1.
So How Does North-South Traffic Flow?
This is where the design becomes elegant. When a VM on a T1-without-SR needs to reach an external destination, the forwarding path is entirely local to the hypervisor until it hits the T0's Edge SR:
T1 with SR (stateful services enabled)
T1 without SR (no stateful services)
The packet never leaves the hypervisor for T1 routing. The T0 DR, also running distributed on every transport node, receives the handoff from the T1 DR locally and then forwards to the T0 SR on the Edge for the external uplink. This is a significant efficiency gain — it means one fewer hop through the Edge cluster for every north-south flow from that T1.
When Does a T1 Get an SR?
NSX-T automatically instantiates a T1 SR on the Edge cluster when you configure any of the following on that T1:
| Service | SR Required? | Reason |
|---|---|---|
| NAT (SNAT/DNAT) | Yes | Stateful connection tracking required |
| Load Balancing | Yes | Connection state must be centralised |
| Gateway Firewall (stateful) | Yes | Session table cannot be distributed |
| IPsec VPN termination | Yes | Crypto and tunnel state is centralised |
| Simple routing (no services) | No | DR handles all east-west; T0 handles N/S uplink |
| Distributed Firewall (DFW) | No | DFW is kernel-level on each hypervisor, independent of gateways |
East-West Traffic: Always Fully Distributed
Regardless of whether an SR exists or not, east-west routing between segments connected to the same T1 is always handled entirely within the T1 DR on the local hypervisor. If VM-A on Segment-A pings VM-B on Segment-B, and both segments are on the same T1, the packet goes:
No Edge cluster involvement at all. This is the whole point of the distributed routing architecture — it keeps high-volume lateral traffic off the Edge nodes entirely.
Practical Design Guidance
Do not add an SR to a T1 unless you need it
Over-provisioning SRs is a common anti-pattern. Every T1 SR you create consumes Edge Node capacity — memory, CPU, and a pinned Edge Node path. If your workloads just need routing between segments and outbound internet access (handled by NAT on the T0), there is no reason to instantiate a T1 SR.
NAT design: T0 or T1?
You can configure NAT on either the T0 or a T1. If you put NAT on the T0, your T1s can remain SR-free. This is often the right call in smaller environments. In larger multi-tenant designs, T1-level NAT gives you isolation per-tenant at the cost of each T1 needing its own SR on the Edge.
Edge cluster sizing implications
Each T1 SR is placed on an Edge Node in the Edge cluster. If you have 20 T1 gateways all with SRs, your Edge cluster needs to be sized to handle the aggregate stateful service load from all 20. This is a critical input to Edge cluster sizing — count your SRs, not just your T1 count.
Verifying SR Status via NSX Manager
You can quickly confirm whether a T1 has an SR instantiated from the NSX Manager UI:
- Go to Networking > Tier-1 Gateways
- Click the three-dot menu on your T1 and select View and manage gateway
- Under Routing, check whether an SR is listed and which Edge Node it is placed on
Via the NSX CLI on an Edge Node, you can also run:
# On the Edge Node NSX CLI get logical-routers # Look for your T1's SR component (VRF type: SERVICE_ROUTER_TIER1) # If only a DISTRIBUTED_ROUTER_TIER1 appears for your T1, no SR is instantiated
Summary
The presence or absence of an SR on a T1 is not about capability — the T1 DR always exists and always routes. The SR is strictly a function of whether you need stateful services. Without stateful services, the T1 is a lean, fully distributed router with no Edge footprint. North-south traffic traverses the T1 DR locally and is handed off directly to the T0 DR on the same hypervisor, which then forwards to the T0 SR on the Edge for the physical uplink.
Understanding this architecture is essential for anyone designing NSX-T environments — whether you are sitting the VCIX-NV exam, designing a multi-tenant VCF deployment, or simply trying to understand why your Edge nodes are under pressure.
No comments:
Post a Comment