Azure Global Reach in Action

Recently, I was lucky to get two ExpressRoutes in a Microsoft Lab environment so that I could test the Azure Global Reach in Action. ExpressRoutes are not something you can test typically like the other resources in Azure, because it requires, customer router configuration, last mile provider configuration. Therefore, I thought I would share my experience with the rest of the world. This blog post is around the experience, a bit of a glimpse, to what happens when you enable Azure Global Reach.

A bit of background on the environment that I setup is below. I have two on-premises data centers, one in Seattle, one in Washington DC. They are connected to their local Azure regions respectively, in West US2 and East US.

I have also cross connected the two ExpressRoute together so that one on-premises datacenter can talk to each other Azure datacenter using the ExpressRoute. This is allowed with a standard ExpressRoute between the same geopolitical region. However, this setup doesn’t allow me to talk from one on-premises datacenter to the other on-premises datacenter. For this to happen I would need Azure Global Reach enabled. Let do some testing to verify this behavior.

As you can see in the above ping tests, from a test machines in Washington DC, I can reach to East US and West US2 but not the Seattle on-premises VM.
My ExpressRoute Connections currently looks as below.

There are two connections on each ExpressRoute, One to each Azure Datacenter region.

If I check my routes that appear in one of the ExpressRoutes, It will look like below.

Now let’s go ahead and enable Global Reach in my two ExpressRoutes. This is something you cannot do in the Azure Portal as of today. You must use PowerShell to enable Global Reach. The instructions to enable Global reach can be found in this article. In my case I ran the following PowerShell Commands. It creates following orange connection.

$ER1RG = "Company17"
$ER1 = "Company17-er"


$ER2RG = "AComp17"
$ER2 = "AComp17-er"


$ckt_1 = Get-AzExpressRouteCircuit -Name $ER1 -ResourceGroupName $ER1RG
$ckt_2 = Get-AzExpressRouteCircuit -Name $ER2 -ResourceGroupName $ER2RG
 

$PeeringAddressPrefix1 = '10.200.0.0/29'


Add-AzExpressRouteCircuitConnectionConfig -Name 'GlobalReach-EastUS' -ExpressRouteCircuit $ckt_1 -PeerExpressRouteCircuitPeering $ckt_2.Peerings[0].Id -AddressPrefix $PeeringAddressPrefix1
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt_1

The Peering Address Prefix is a /29 ip range that does not overlap in your existing environment. Once the PowerShell commands are successfully executed, you will see this additional property on the ExpressRoute. It will appear only on the ExpressRoute that you execute the command. It will not appear on the other ExpressRoute. However, routing will work both ways.

If I go back and do my connectivity tests, I can see it is working as below.

If I look at the advertised routes in an ExpressRoute now, you will see the following.

You will see three additional entries with the peering prefix IP address you provided. The first one is the path to the Washington DC Datacenter from the Seattle datacenter. Because of this path, it adds two more additional paths to the East US Azure DC and West US 2 DC. Those are added as well.
You will not see any changes on the ER connections in the portal. They remain the same.

This is how technically Global reach works. I add additional routes to your ExpressRoute which advertises the other data center IP ranges in your local ExpressRoute.