{"id":21789,"date":"2020-01-23T12:41:44","date_gmt":"2020-01-23T12:41:44","guid":{"rendered":"https:\/\/aidanfinn.com\/?p=21789"},"modified":"2020-01-23T10:51:51","modified_gmt":"2020-01-23T10:51:51","slug":"verifying-propagated-bgp-routes-on-azure-expressroute","status":"publish","type":"post","link":"https:\/\/aidanfinn.com\/?p=21789","title":{"rendered":"Verifying Propagated BGP Routes on Azure ExpressRoute"},"content":{"rendered":"

An important step of verifying or troubleshooting communications over ExpressRoute is checking that all the required routes to get to on-premises or WAN subnets have been propagated by BGP to your ExpressRoute Virtual Network Gateway (and the connected virtual networks) by the on-premises edge router.<\/p>\n

The Problem<\/h2>\n

Routing to Azure is often easy; your network admins allocate you a block of private address space on the “WAN” and you use it for your virtual network(s). They add a route entry to that CIDR block on their VPN\/ExpressRoute edge device and packets can now get to Azure. The other part of that story is that Azure needs to know how to send packets back to on-premises – this affects responses and requests. And I have found that this is often overlooked and people start saying things like “Azure networking is broken” when they haven’t sent a route to Azure so that the Azure resources connected to the virtual network(s) can respond.<\/p>\n

The other big cause is that the on-premises edge firewall doesn’t allow the traffic – this is the #1 cause of RDP\/SSH to Azure virtual machines not working, in my experience.<\/em><\/p>\n

I had one such scenario where a system in Azure was “not-accessible”. We verified that everything in Azure was correct. When we looked at the propagated BGP routes (via ExpressRoute) then we saw the client subnets were not included in the Route Table. The on-prem network admins had not propagated those routes so the Azure ExpressRoute Gateway did not have a route to send clients responses to. Once the route was propagated, things worked as expected.<\/p>\n

Finding the Routes<\/h2>\n

There are two ways you can do this. The first is to use PowerShell:<\/p>\n

Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName\u00a0TheNameOfMyCircuitResourceInAzure\u00a0-PeeringType AzurePrivatePeering -ResourceGroupName TheNameOfTheResourceGroupTheCircuitResourceIsIn<\/pre>\n
The command takes quite a while to run. Eventually, it will spit out the full route table. If there are lots of routes (there could be hundreds if not thousands) then they will scroll beyond the buffer of your console. So modify the command to send the output to a text file:<\/p>\n
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TheNameOfMyCircuitResourceInAzure -PeeringType AzurePrivatePeering -ResourceGroupName TheNameOfTheResourceGroupTheCircuitResourceIsIn > BgpRouteTable.txt<\/pre>\n
Unfortunately, it does not create a CSV format by default but one could format the output to get something that’s easier to filter and manipulate.<\/p>\n
You can also use the Azure Portal where you can view routes from the Route Table and export a CSV file with the contents of the Route Table. Open the ExpressRoute Circuit and browse to Peerings.<\/p>\n
\"\"<\/a><\/p>\n
Click Azure Private, which is the site-to-site ExpressRoute connection.<\/p>\n
\"\"<\/a><\/p>\n
Now a pop-up blade appears in the Azure Portal called Private Peering. There are three interesting options here:<\/p>\n