NSX-T Logical Routing: Tier-0/Tier-1 Routing Design and Failover

Table of Contents

1. Introduction
2. NSX-T Logical Routing Overview
3. Tier-0 and Tier-1: Architecture Deep Dive
4. Production Multi-Site Design: Dell Example
5. High Availability and Failover Models
6. Integration with BGP and OSPF
7. Route Monitoring: Code Examples
8. Troubleshooting: Real-World Scenarios
9. Tier-0 vs Tier-1: Feature Comparison Table
10. Best Practices, Anti-Patterns, and Advanced Tips
11. Conclusion
12. Disclaimer

---

Introduction

Modern data centers require robust, scalable, and highly available network architectures. NSX-T 4.x delivers advanced logical routing with Tier-0 and Tier-1 routers, enabling multi-site, production-grade connectivity. In this guide, you’ll learn how to design, deploy, monitor, and troubleshoot NSX-T logical routing in Dell-backed enterprise environments.

---

NSX-T Logical Routing Overview

NSX-T separates network routing into two logical layers:

• Tier-0 Gateway: Connects your NSX domain to external networks such as physical, cloud, or WAN.
• Tier-1 Gateway: Provides east-west connectivity for internal workloads, services, and segments.

This separation delivers flexibility, granular control, and clear demarcation for security and high availability.

---

Tier-0 and Tier-1: Architecture Deep Dive

Tier-0 Gateway

• Acts as the border gateway between your virtual network and external network.
• Connects to physical routers (for example, Dell S-Series, C-Series) via BGP or OSPF.
• Can be configured as active-active or active-standby for high availability.
• Handles north-south routing, NAT, and edge services.

Tier-1 Gateway

• Connects internal NSX segments such as VMs and services.
• Optionally links to Tier-0 for external access.
• Supports distributed routing for high performance.
• Can run firewall, load balancing, and VPN services.

Topology Diagram (Multi-site Dell Example)

---

Production Multi-Site Design: Dell Example

When designing for multi-site, production-grade environments using Dell switches:

• Use redundant uplinks to multiple ToR switches such as Dell S5248 and S5232.
• Place NSX-T Edge nodes close to physical routers for minimal latency.
• Interconnect Tier-0 gateways in active-active mode for optimal failover.
• Synchronize BGP sessions across both sites for seamless route propagation.

---

High Availability and Failover Models

Active-Active Tier-0

• Both Edge nodes forward traffic and share routing state.
• BGP/OSPF peering from each node to external routers.
• Failure of one Edge instantly reroutes via the other.

Active-Standby Tier-0

• Single node forwards traffic; backup only becomes active on failure.
• Lower complexity but slightly higher failover time.

Tier-1 Resiliency

• Tier-1 is always distributed and runs as a service on all transport nodes.
• No single point of failure; east-west traffic stays on the hypervisor.

---

Integration with BGP and OSPF

• Configure BGP neighbors with Dell routers using the NSX-T UI or API.
• Use route maps and prefix-lists for granular control.
• OSPF can be used in some hybrid scenarios, but BGP is most common for data center fabrics.

Sample PowerCLI snippet to check BGP neighbor status:

# Check BGP Neighbors on Tier-0
Connect-NsxServer -Server <nsx-manager>
Get-NsxEdgeCluster | Get-NsxBgpNeighbor

---

Route Monitoring: Code Examples

PowerCLI: Monitor NSX-T Tier-0 Routes

# List all routes on Tier-0 Gateway
Connect-NsxServer -Server <nsx-manager>
Get-NsxLogicalRouter | Where-Object { $_.routerType -eq "TIER0" } | Get-NsxRoute

Python: Check Edge Uplink Reachability

import requests

nsx_manager = "https://<nsx-manager-ip>"
user = "<username>"
password = "<password>"

r = requests.get(
    nsx_manager + "/api/v1/logical-routers",
    auth=(user, password),
    verify=False
)
print(r.json())

Bash: Ping Test Across Sites

# Ping between Edge Uplink and Physical Router
ping -c 5 <peer_router_ip>

---

Troubleshooting: Real-World Scenarios

Common Failover Issues

• BGP neighbor down on one Edge may lead to traffic blackholing.
• VLAN misconfiguration on Dell switch can cause TEP or Edge to disconnect.
• Asymmetric routing after failover.

Troubleshooting Steps

1. Verify BGP/OSPF Peering
   Check peering status on both NSX-T Edge and Dell switch, such as using show ip bgp summary.
2. Packet Walk with Traceflow
   Use the NSX-T Traceflow UI to walk a packet from a segment through Tier-1 and Tier-0.
3. CLI Diagnostics # On NSX Edge Node get logical-router get bgp neighbor summary
4. Review NSX-T and Dell Logs
   Correlate timestamps of failover with logs from both sides.

Real-World Example Log

Jul 11 10:02:17 nsx-edge-1 bgp[1234]: Neighbor 10.10.10.1 Down: Hold Timer Expired
Jul 11 10:02:18 dell-sw1 BGP: Neighbor 10.10.10.2 Down: Peer closed session

---

Tier-0 vs Tier-1: Feature Comparison Table

Feature	Tier-0 Gateway	Tier-1 Gateway
North-South Routing	Yes	Optional (via Tier-0)
East-West Routing	No	Yes (Distributed)
External Connectivity	Yes	No
BGP/OSPF Support	Yes	No
NAT, VPN, LB Services	Yes	Yes (Limited)
High Availability	Active-Active/Standby	Always Distributed
Placement	Edge Nodes	Transport Nodes
Failover	Edge Cluster	Hypervisor Distributed

---

Best Practices, Anti-Patterns, and Advanced Tips

• Always use active-active Tier-0 for critical, multi-site workloads unless a requirement dictates otherwise.
• Avoid direct user workloads on Tier-0 segments; route internal traffic via Tier-1.
• Monitor routing table changes with automated scripts for proactive failover detection.
• Keep Dell switch firmware up to date for BGP/OSPF compatibility.
• Use redundant, isolated links between Edge nodes and physical routers.
• Document all BGP/OSPF peering and route-map changes for auditability.

---

Conclusion

Logical routing with NSX-T 4.x empowers data center architects to deliver resilient, scalable, and high-performance connectivity. By leveraging Tier-0 and Tier-1 gateways, integrating with Dell physical fabrics, and implementing robust failover strategies, you can achieve true enterprise-grade availability.

---

Disclaimer

Disclaimer: For demonstration purposes only. Refer to official VMware documentation for production deployments.

Disclaimer: The views expressed in this article are those of the author and do not represent the opinions of VMware, my employer, or any affiliated organization. Always refer to the official VMware documentation before production deployment.