BGP Azure Lab Maker

Lately I have been working in creating lab environments to train on some aspects of Azure networking, such as Network Virtual Appliances, VPN or ExpressRoute. I started creating scripts to deploy each of those, but then I realized that those scripts had a lot in common. Would it be possible to generalize them into one single one that rules them all?

That is the idea behind the BGP Azure Lab Maker project (find the script in my Azure CLI repository here). Imagine you want to deploy the topology in the diagram below (you might recognize as a simulation of a redundant ExpressRoute topology, for the ones that cannot afford ExpressRoute circuits for learning purposes):

The idea is having a tool where you give it the topology you want to build, and it creates it for you. Welcome to the Azure BGP Lab Maker. This is a shell script that would take your topology as text input. For example, to build the previous topology, you would use this command line:

zsh bgp.sh \
 "1:vng:65515,2:vng:65515,3:csr:22076,4:csr:22076,5:csr:65001,6:csr:65002" \
 "1:3,1:4,2:3,2:4,3:5,4:6,5:6" \
 bgp1 northeurope "supersecretpsk"

The inputs are easily decomposed: the first string describes which appliances to deploy: either Virtual Network Gateways (“vng”), or Cisco Cloud Services Routers (“csr”), and the Autonomous System Number (ASN) to configure. In this case we have 6 devices, as the string “1:vng:65515,2:vng:65515,3:csr:22076,4:csr:22076,5:csr:65001,6:csr:65002” shows.

I am using those two because they are the ones I know best. If you have other examples of appliances that should be included (like Linux boxes with StrongSwan and Quagga), feel free to send Pull Requests my way!

By the way, you can see I am using the ASN 22076 instead of the standard 12076 for ExpressRoute. That is because the ASN 12076 is reserved in Azure for ExpressRoute, and you cannot use it for anything else (like this kind of scenarios).

The next argument are the connections, essentially which router is connected to which other router: “1:3,1:4,2:3,2:4,3:5,4:6,5:6”. Here we have router1 connected to router3 (“1:3”), router1 to router4 (“1:4”), etc.

And finally, the last three arguments are just the resource group (“bgp1”), the Azure region where to deploy this (“northeurope”) and the pre-shared key to use for the IPsec connections (“supersecretpsk”).

After some minutes (deploy a Virtual Network Gateway in Azure is still painfully slow) you get everything deployed, and you can have a look at the IP addresses. In my case:

az network public-ip list -g $rg -o table
Name      ResourceGroup    Location     Zones    Address         AddressVersion    AllocationMethod    IdleTimeoutInMinutes    ProvisioningState
--------  ---------------  -----------  -------  --------------  ----------------  ------------------  ----------------------  -------------------
csr3-pip  bgp1             northeurope           52.169.146.221  IPv4              Static              4                       Succeeded
csr4-pip  bgp1             northeurope           52.169.118.161  IPv4              Static              4                       Succeeded
csr5-pip  bgp1             northeurope           13.79.189.43    IPv4              Static              4                       Succeeded
csr6-pip  bgp1             northeurope           40.115.125.95   IPv4              Static              4                       Succeeded
pip1a     bgp1             northeurope           13.74.144.88    IPv4              Dynamic             4                       Succeeded
pip1b     bgp1             northeurope           52.169.64.165   IPv4              Dynamic             4                       Succeeded
pip2a     bgp1             northeurope           52.169.3.35     IPv4              Dynamic             4                       Succeeded
pip2b     bgp1             northeurope           52.169.3.47     IPv4              Dynamic             4                       Succeeded

So as you can see a bunch of IP addresses where deployed. If we go to one of the routers in the middle of the topology (such as csr3) we can have a look at its connectivity. For example, the different BGP adjacencies with other routers in the topology:

csr3-nva#sh ip bgp summ
[...]
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.0.4        4        65515      47      52        7    0    0 00:36:13        2
10.1.0.5        4        65515      49      49        7    0    0 00:36:09        2
10.2.0.4        4        65515      47      47        7    0    0 00:33:18        2
10.2.0.5        4        65515      44      49        7    0    0 00:34:00        2
10.205.0.10     4        65001      44      47        7    0    0 00:32:59        2

And you can now go to the edge routers (csr5 and csr6) to see how they learn their routes:

csr5-nva#sh ip route bgp
[...] 
      10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
B        10.1.0.0/16 [20/0] via 10.203.0.10, 00:35:31
B        10.2.0.0/16 [20/0] via 10.203.0.10, 00:35:31
B        10.203.0.0/24 [20/0] via 10.203.0.10, 00:35:31
B        10.204.0.0/24 [20/0] via 10.206.0.10, 00:34:44
B        10.204.0.10/32 [20/0] via 10.203.0.10, 00:35:31
B        10.206.0.0/24 [20/0] via 10.206.0.10, 00:34:56

For example you can see there that CSR5 goes to 10.1.0.0/16 and 10.2.0.0/16 over the same router (CSR3), but what if you wanted to go via CSR6 instead? Now you built your lab, you can start playing with this.

Other interesting scenarios you could build with this:

• Basic example with 1 VNG connected to one CSR: bash bgp.sh “1:vng:65501,2:csr:65502” “1:2” mylab northeurope mypresharedkey
• 4 CSRs connected in full mesh to each other: bash bgp.sh “1:csr:65501,2:csr:65502,3:csr:65503,4:csr:65504” “1:2,1:3,2:4,3:4,1:4,2:3” mylab northeurope mypresharedkey

Can you think of other interesting topologies? Any feedback about the script? Happy to hear from you either here or with issues in the Github repo!