Description
Hello, this is a fantastic article, thank you
https://blog.cloudtrooper.net/2021/03/06/route-server-multi-region-design/
One thing though: How does the vxlan tunnel form to get around the routing loop UDR issue?
Example:
hub1 NVA1 is 10.1.1.4
hub2 NVA1 is 10.2.1.4
hub2nva1 is advertising 10.1.0.0/16 via bgp to the route server so the spokes will use hub2nva1 as the "UDR" gateway for hub1 , but the routing loop occurs when hub2nva1 wants to route to 10.1.1.4 and the route table kicks it right back to itself. This I can reproduce, and this I can solve by using a "transit" subnet with a route table where route propogation is disabled and just making "static" UDRs to hub1
You said a more dynamic solution was to encapsulate this in a vxlan tunnel, but your config still shows hub2nva1 establishing the vxlan tunnel and run the 10.1.0.0/16 route "over" the vxlan tunnel. However, to establish the vxlan tunnel in your azcli config, you are still connecting to the private address of 10.1.1.4 to build the tunnel. When I tried this it still got loopbacked because of the route table. If I tell hub2 to stop advertising 10.1.0.0/16, then the tunnel establishes, but the hub2 spoke networks no longer route via hub2nva1 because the route is gone, instead they go via the vnet peering because hub1 is advertising it, but that bypasses the NVA.
What am I missing here? How did you establish the vxlan tunnel to the same address that was a problem with looping to begin with and have the spoke networks still flow "through" the nva on the hub2 side?