erjosito / azcli

Different scripts to test Azure technologies using the Azure CLI

Azure CLI script samples

This repo contains some samples of Azure CLI scripts to create certain Azure scenarios.

The scripts have been tested using zsh, so they will not work in Windows. Regarding Linux, they will probably work with bash too.

The testing that has gone in each scenario is limited, so please do not expect them to work flawlessly.

It is recommended to open the files in Visual Studio Code with the Azure CLI extension installed (so that you get IntelliSense support for Azure CLI commands), and open a terminal (a WSL one if you are working on a Windows machine) to test the different commands step by step.

To download the scripts you can either clone the whole repo with git clone https://github.com/erjosito/azcli or download specific files with wget "https://raw.githubusercontent.com/erjosito/azcli/master/routeserver_2hubs.azcli" -O <filename>.sh.

azcli's Issues

azcli/routeserver-vmss-selfcontained-config.sh bug line 124

Thanks for the great work in the blog, really useful.

It appears the azure json might have changed and this line no longer works as expected

Its privateIPAddress rather than privateIpAddress, e.g.

$ az vmss nic list --vmss-name $nva_name -g $rg --query '[].ipConfigurations[].privateIpAddress' -o tsv
no data

$ az vmss nic list --vmss-name $nva_name -g $rg --query '[].ipConfigurations[].privateIPAddress' -o tsv
10.100.5.5

routeserver_2hubs.azcli: How does the vxlan tunnel establish between the two regions?

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?