Azure ExpressRoute Disaster Recovery

Microsoft offers the Azure ExpressRoute service for private connections between your on-premises datacenters and Azure regions.

ExpressRoute connectivity is enabled via ExpressRoute circuits, which are logical constructs representing connections between your on-premises and Microsoft edge locations via one or more communications provider.

Each ExpressRoute circuit offers peerings for Public services and Private Services, with each peering offering primary and secondary connections:

  • Azure Private peering: Primary and Secondary connections for Azure private services in your VNets.
  • Microsoft peering: Primary and Secondary connections for Azure public services (e.g. Storage, Dynamics 365)

Azure Private Peering

If you have multiple on-premises datacenters and use multiple Azure regions with multiple ExpressRoute circuits, then you may design for Disaster Recovery for your on-premises-to-Azure private traffic as per the topology shown below. This topology is listed as Scenario 1 in Microsoft's documentation. This scenario is appropriate when your on-premises datacenters much less apart than the Azure paired regions which you use. For example, in the topology below, the on-premises datacenters are less than 50 km part (not great for a regional disaster!) whereas the Azure regions are at least 300 miles apart.

Note that there are 2 levels of redundancy:

  • Within an ExpressRoute circuit (primary and secondary connections)
  • Between ExpressRoute circuits (traffic may be steered via the running ExpressRoute circuit should the other ExpressRoute circuit fail)

Multiple Traffic Paths for Azure Private Services

Each ExpressRoute circuit may be connected to your Azure VNets via a virtual network gateway connection between the ExpressRoute circuit and the Virtual Network Gateway in your VNet (within the GatewaySubnet).

So, as per the topology diagram below, configuring virtual network gateway connections from the virtual network gateways in both Azure regions to both ExpressRoute circuits provides mesh connectivity between your on-premises sites and the Azure regions.

For traffic from Azure to on-premises, a routing weight must be associated with each virtual network gateway connection to set up a connection preference. Connections with higher routing weights are preferred over those with lower routing weights.

For traffic from on-premises to Azure, AS_Path prepend may be used along with Azure private network prefix lists to prefer one ExpressRoute circuit over the other.

Azure private peering DR


Microsoft Peering

If you have multiple on-premises datacenters and use multiple Azure regions with multiple ExpressRoute circuits, then you may design for Disaster Recovery for your on-premises-to-Azure publice service traffic as per the topology shown below. This scenario is appropriate when your on-premises datacenters much less apart than the Azure paired regions which you use. For example, in the topology below, the on-premises datacenters are less than 50 km part (not great for a regional disaster!) whereas the Azure regions are at least 300 miles apart.

Note that there are 2 levels of redundancy:

  • Within an ExpressRoute circuit (primary and secondary connections)
  • Between ExpressRoute circuits (traffic may be steered via the running ExpressRoute circuit should the other ExpressRoute circuit fail)

Multiple Traffic Paths for Azure Public Services

Each Azure Region will have a Route Filter that allows the BGP communities of specific Azure Public services to be advertised over associated ExpressRoute circuits. By configuring each route filter in each region to allow the BGP communities for Azure public services from both regions to be advertised over the associated expressroute circuits, we can ensure that the Azure public services in both regions may be accessed from on-premises via each expressroute circuit. For example, the image below shows that the Azure Storage public service for both Canada Central and Canada East regions has its BGP communities allowed and this route filter is a associated with a specific expressroute circuit.

azure-routefilter

Configuring route filters as explained above provides mesh connectivity between your on-premises sites and the Azure regions for accessing Azure public services over ExpressRoute. The image below shows the topology.

azure-erc-public-peering

For traffic from on-premises to Azure, AS_Path prepend may be used along with Azure public service BGP community lists to prefer one ExpressRoute circuit over the other.

References

  1. BCDR - Azure Paired Regions

  2. Designing for disaster recovery with ExpressRoute private peering

Show Comments