NSX-T Federation
Local Egress Using Tier 0 Active-Active, All Locations Primary
This is a follow up to my earlier post on NSX-T Federation.
This design uses Local Egress similar to the Local Egress feature in NSX-V.
One has to note that if there are firewalls upstream to Tier 0 Gateway in both the locations, then firewall in one site can drop the connection just because the return packet is actually destined to the other firewall.
This setup uses Asymmetric routing.
Traffic from NSX can egress out via physical routers in Delhi and the return traffic can ingress towards NSX setup using physical routers in Bangalore.
In the lab setup, there is:
a. Stretched Tier 0 Gateway across both the locations Bangalore and Delhi
b. Stretched Tier 1 Gateway across both the locations.
c. Tier 1 Gateway is a DR only Tier 1 Gateway.
d. Segment attached to Tier 1 Gateway is a stretched segment across both the locations.
e. Both the locations are Primary here.
f. AS Path prepending configuration is not applied on the physical routers or on the Tier 0 Gateway.
Lab Topology Diagrams:
 |
| Logical Topology for the Lab Setup |
 |
| BGP AS Setup |
Configuration:
You may follow the steps outlined in the earlier post for:
– Preparing NSX-T Fabric.
– Creating stretched Tier 0 Gateway
– Creating Layer 3 interfaces on this stretched Tier 0 Gateway.
– Applying BGP configuration on stretched Tier 0 Gateway.
– Creating a stretched DR only Tier 1 Gateway across both the locations.
– Creating stretched segment.
Let us jump into the validation part.
 |
| Tier 0 Gateway configured with all locations as Primary |
Validation:
Local egress behavior is noticed for the traffic flows.
 |
| Ping and trace from loopback on physical router in Delhi towards VM 172.16.10.3 in Delhi |
 |
| Ping and trace from loopback on physical router in Bangalore towards VM in Delhi location |
 |
| Trace from VM in Delhi location to loopback IP of Delhi router goes egress out of edges in Delhi directly to Delhi router |
 |
| Trace from VM in Delhi towards loopback network on physical router of Delhi |
The above trace flow is from VM in Delhi location towards loopback network configured on physical router of Delhi location.
Traffic leaves the hypervisor in Delhi location and uses its TEP interface to encapsulate the original packet and send the traffic towards TEP interface on edge in Delhi location.
This edge de encapsulates the packet and forwards it towards the router locally available in Delhi.
 |
| Trace from VM in Delhi towards loopback network on physical router of Bangalore |
 |
| Trace from VM in Bangalore towards loopback network on physical router of Delhi |
 |
| Trace from VM in Bangalore towards loopback network on physical router of Bangalore |
Networking & Security 
Hi Farhan, is there any way to influence the ingress part of the traffic to avoid assymetry? It would be great if we can track the location of the VMs and announce /32 prefixes through the corresponding Edge. Is there any plan to implement this as in Proximity Routing feature of HCX??
LikeLike
Hi Farhan….Great post..I have a quick question on this topo.
I know ESX-1 WIll have tunnels formed to ESX-2.Would ESX-1 have details about remote vtep ESX-3 and ESX4. ?.
If not ,how do we control arp suppression ?…for every ping generated to a unknown vtep , arp goes all the way upto the edge and gets discarded ?
LikeLike