NSX-T Series: Part 15 – NSX-T Segment with T1 Gateway without EDGE Cluster
Introduction
In this part we will continue the discussion of connecting the segment with T1/T0 Gateway and will explore option of Cluster requirement. We will look the design case where this can be applied in the real scenarios.
If you want to start from beginning you can refer my previous part of the Series:
NSX-T Series : Part 1 -Architecture and Deploy
NSX-T Series : Part 2 – Adding Compute Manager
NSX-T Series : Part 3 – Planning NSX VXLAN
NSX-T Series : Part 4 – Transport Zones and Use cases for Multi-Transport Zone
NSX-T Series: Part 5 – NSX-T N-VDS and VDS 7.0
NSX-T Series: Part 6 – NSX-T Uplink Profile
NSX-T Series: Part 7 – NSX-T ESXi Transport Node
NSX-T Series: Part 8 – NSX-T Logical Switching Use Cases
NSX-T Series: Part 9 – NSX-T Logical Switching Services
NSX-T Series: Part 10 – NSX-T Routing
NSX-T Series: Part 11– NSX-T Multi-Tier Routing
NSX-T Series: Part 12 – NSX-T EDGE Deploy Part-1
NSX-T Series: Part 13 – NSX-T EDGE Deploy Part-2
NSX-T Series: Part 14 – NSX-T Segment without IP Subnet/Gateway
Scenario 2 : Segment with IP Subnet without Gateway(T1/T0):
Initially, I thought about skipping this section and covering it later. However, I decided to include it because it helps clarify the design.
This change does not significantly affect the behavior of Scenario 1, which we discussed in the previous post.
Even if we add a subnet to the Segment, the gateway IP will not become active until we attach the Segment to a Gateway (T0/T1).
The main exception occurs when you terminate the L2VPN.
So keep in mind while terminating L2VPN for this VXLAN double check the IP otherwise there could be issue DUP-IP.


Scenario 3 : Segment with IP Subnet attached to Gateway T1
In our previous series Part-10 and 11 we discussed in detail the difference between T0 and T1 and what is Single Tier and Multi Tier routing. I would suggest to revisit it. In this scenario we will solely focus on the route table update process.
Design Consideration with T0/T1Before implementing the design, we need to revisit a few basic points about T0 and T1 Gateways:
The design also requires additional considerations when we configure Load Balancing as a Service on T1 or T0. These requirements can vary depending on the NSX-T release.
Before implementing the design, let’s review the following basic points about T0 and T1 Gateways:
- T0 provides Tier-0 routing. A Segment can connect directly to T0.
- T0 can operate in Active-Active mode when we do not use stateful services such as NAT or Firewall.
- When we use stateful services, T0 must operate in Active-Standby mode.
- T1 Gateways always operate in Active-Standby mode.
- T0 cannot connect directly to another T0. This communication requires an uplink router.
- Multiple T1 Gateways can connect to a T0 Gateway. We can use separate T1 Gateways for different tenants or environments, such as Production, Development, and Testing.
- A T1 Gateway can connect to only one T0 Gateway at a time.
- Each T1 Gateway can use an overlapping IP subnet with another T1 Gateway. In this scenario, we can use NAT to distinguish the traffic. We will discuss this scenario in a future blog.
- SR services are instantiated when a centralized service is required.
- We also need to consider other factors when configuring Load Balancing as a Service on T1 or T0. These requirements depend on the NSX-T release.
T0 provides Tier-0 routing. A Segment can connect directly to a T0 Gateway.
T0 can operate in Active-Active mode when we do not use stateful services such as NAT or Firewall.
If we need stateful services, we must choose Active-Standby mode for T0.
T1 Gateways always operate in Active-Standby mode.
A T0 Gateway cannot connect directly to another T0 Gateway. This communication requires an uplink router.
Multiple T1 Gateways can connect to a single T0 Gateway. We can use separate T1 Gateways for different tenants or environments, such as Production, Development, and Testing.
A T1 Gateway can connect to only one T0 Gateway at a time.
Each T1 Gateway can use an overlapping IP subnet with another T1 Gateway. In such cases, we can use NAT to distinguish the traffic. We will discuss this scenario in a future blog.
SR services are instantiated when the design requires a centralized service.
Scenario 3.1 T1 without Edge Cluster
While creating T1 we get option of choosing EDGE-Cluster, usually this option should be chosen if the Stateful Service like NAT/Firewall need to be used.


The moment we added segment to T1, the VM was reachable to subnet gateway which we created in Scenario 2.

DR Logical Router instantiated:
When you create a T1, it instantiates a DR service on the compute nodes where the Segment VM resides. NSX-T determines the appropriate nodes based on the realization.


Let’s add another segment SEG_B and connect VM2 with 10.1.2.0/24 ( Gateway as 10.1.2.254 )

Topology : T1 without Edge ClusterT1 Without Edge Cluster
A T1 without an Edge Cluster creates only a T1-DR instance. It does not provide SR capabilities.
As a result, you cannot use stateful services such as NAT, IPsec, and other Edge services.
If the VM only requires routing or switching services within the Compute Node, we recommend not attaching an Edge Cluster to the T1.
You can see this design in the following topology.
I recommend visualizing this topology carefully. As we add more components, NSX-T adds more services to the design.T1 without Edge cluster is design where only T1-DR instance will be instantiated but no SR capability can be used which includes Statefull service like NAT, IPsec, etc. So if the VM is mostly for routing/switching service inside the Compute Node, it is recommended to not attach Edge Cluster.
The same can be viewed in following topology, I would recommend to visualize this diagram on your mind because further the other component when added the service will keep on getting added. The same applies for T0 Gateway also.

This addition quickly updates the routing table for T1-DR instance :

ANYCAST-GATEWAY: If you will look closely the MAC of the DR interface (02:50:56:56:44:52) remains same on every interface and on other host also, this can be considered as similar concept of “Anycast-Gateway” in Cisco ACI or other native VXLAN solutions. The endpoint VM assume it is single router as gateway.
VXLAN Routing : As like many vendors NSX follows Route-Bridge-Route path and always consider route near source concept.

Packet Trace



Summary
In this blog, we covered the basic of Distributed router and verified how the T1-DR is instantiated and makes routing under the ESXi kernel. This method do not require any kind of EDGE VM and traffic is East-West which is processed by DLR kernel of NSX-T. For more reference we can follow VMware configure guide.
In next blog we will see the consequence of adding Edge Cluster on T1 and will verify the traffic flow. I would like to thank for visiting the site.
Hi Abhishek,
The NSX-T Series: Part 6 – NSX-T Uplink Profile seems to have disappeared – URL is faulty?
Best series on NSX-T
Regards
Robert
Thanks Robert… for your comment… great to hear it is useful.
Regarding Part 6 we will re create it..
Hello Abhishek,
As per my knowledge, NSX-T utilize GENEVE as a encapsulation protocol and NSX-V use VXLAN. You are talking about VXLAN routing in NSX-T topic. I don’t understand this. Am I missing something?
Hi Abhishek,
The IPs shown in the first picture of this blog, 10.1.1.1, 20.1.1.2 and 30.1.1.3, shouldn’t be 10.1.1.1, 10.1.1.2 an 10.1.1.3 because the VMs are in the same segment?
Regards.