I have heard some organizations complaining that deploying a fully functional ExpressRoute circuit takes too long: days, or even weeks. Does this always have to be like that?
I recently got access to Megaport‘s service portal: Megaport is one of Azure ExpressRoute providers, and they can provision virtual routers dynamically and connect them to Azure ExpressRoute private and Microsoft peerings. Additionally, the Megaport API allows to interact with the services programmatically to deploy them, modify them and delete them. So here is the question: would I be able to code a script that deploys an Azure environment end to end, including ExpressRoute connectivity, in under 1 hour?
The first step was creating some code to interact with the Megaport API. I decided to use curl as my client, because you can easily use it in bash scripts together with the Azure CLI. And here the result: megaport.sh. Essentially a wrapper for the Megaport API that allows to login to the Megaport API using credentials stored in Azure Key Vault, create Megaport Cloud Routers, connect them to Azure ExpressRoute, and delete them when they are no longer needed.
Once that script was ready, I only needed to create some Azure resources, and plumb everything together. My main goal here is automating the creation of testbeds with which I can test and debug ExpressRoute designs, for which I need to simulate an on-premises network. I do that by connecting a second circuit to the Megaport Cloud Router, in a topology similar to this one:
Obviously, a production setup would look like different to the diagram above, that is just my ExpressRoute testbed creation script.
And the resulting script is not too complex, you can see the final result here: expressroute.azcli. If you look at the script commands, the most time-consuming activity is creating the Azure ExpressRoute gateways, which can take around half an hour. The whole script runs unattended without any user input or click, so you can start it, go have lunch, and you will find a fully functional ExpressRoute environment when you come back.
Thanks to Megaport for showing how easy Azure ExpressRoute can be!
Cloudtrooper 
Hi Jose thanks a lot for doing this. I’m not part of any org that consumes the cost of having an ExR Circuit so was wondering if I want to have one for testing purposes how expensive would it be?
LikeLike
Are you aware of the ER pricing page? (https://azure.microsoft.com/pricing/details/expressroute/)
LikeLike
Thank you for sharing this! It is an excellent learning tool.
LikeLike
Happy it is helpful! Agreed, the command is confusing, but it is correct though. In Azure the same object type is used to connect to both VPN and ExpressRoute gateways.
LikeLiked by 1 person
Thank you for putting this together and sharing it. I have worked throught the script several times, connected Azure with GCP. Very cool! One question though, why is the command “az network vpn-connection create” used to associate the connection with the gateway? I am confused since this is not a vpn-connection, is it?
LikeLike
Could you please help me understand why the Next Hop IP addresses are 10.2.146.34 and 10.2.146.35 ? I was expecting that the Next Hop IP would be the IP of the Virtual Network Gateway.
$ az network nic show-effective-route-table –ids $vm_nic_id -o table
Source State Address Prefix Next Hop Type Next Hop IP
——————— ——- —————- ——————— ————-
Default Active 192.168.64.0/23 VnetLocal
VirtualNetworkGateway Active 10.4.2.0/24 VirtualNetworkGateway 10.2.146.34
VirtualNetworkGateway Active 10.4.2.0/24 VirtualNetworkGateway 10.2.146.35
VirtualNetworkGateway Active 172.31.0.0/16 VirtualNetworkGateway 10.2.146.34
VirtualNetworkGateway Active 172.31.0.0/16 VirtualNetworkGateway 10.2.146.35
10.4.2.0/24 is GCP and 172.31.0.0/16 is AWS.
LikeLike
Hey Joblini! Traffic from Azure to ExpressRoute bypasses the ER Gateway and goes straight to the MSEE. The next hop IP addresses that you see there are the internal Microsoft IP addresses assigned to the MSEE.
LikeLiked by 1 person