Express Circuit Failover

Question

We have the following ExpressRoute setup configured in Azure:

• 2 ExpressRoute circuits from different providers
• 2 ExpressRoute connections
• 1 Virtual Network Gateway connected to both circuits

The design expectation is that if one ExpressRoute circuit goes down, traffic should automatically fail over to the second active circuit without impacting connectivity.

However, when one circuit went down, connectivity was disrupted even though the second circuit and connection remained active. We had to manually remove the circuit which was down to make the another circuit up and running

We would like to understand:

1. Why traffic did not automatically fail over to the active ExpressRoute connection.
2. Whether this is an expected ExpressRoute routing behavior or limitation.
3. What is the recommended Microsoft best practice to achieve proper high availability and site resiliency so that failure of one circuit/site does not impact connectivity through the other active connection.

Answer 1

Hi @ Abrar Adil S,

Welcome to Microsoft Q&A Platform.

It sounds like you expected seamless failover across two different ExpressRoute circuits but saw a full outage when one circuit went down. Here's what’s likely happening and how to architect for true high availability:

Why you didn’t see automatic failover

• By default each ExpressRoute circuit operates in active-active only on its own two redundant connections. Azure treats the two circuits you added as separate resources and will prefer one path based on BGP attributes (weight, local-pref, AS-path prepends or communities). If the “preferred” circuit goes into a failed provisioning state (rather than just BGP session flapping), Azure doesn’t immediately withdraw all routes or shift traffic to the other circuit—you often have to “Refresh” or manually disable that peering to force a switch.
• If you’ve inadvertently prepended AS paths or set unequal local-preference on the second circuit, Azure will keep advertising and trying to use the primary until you tear down the failed one.

Is this expected behavior?

• Yes. ExpressRoute’s cross-circuit failover relies on clean BGP convergence. A circuit in a failed provisioning state doesn’t behave like a simple BGP flap. Azure will hold onto the resource until you disable/refresh that peering. This is a known limitation—you won’t get an instant automatic switch until routes are actually withdrawn.

Best practices for true HA and resiliency a. Active-Active at every level

• Provision two fully independent circuits (from different providers) into different peering locations or metros.
• Use the Premium ExpressRoute gateway SKU or a zone-redundant VPN gateway so you can attach both circuits to separate instances. Each gateway instance should be in active-active mode. b. Equalize BGP metrics
• Don’t prepend on one circuit or bias local-pref. Advertise identical prefixes and AS-paths so Azure load-balances per-flow across both circuits. c. Zone-redundant Gateway
• Deploy your ExpressRoute/VPN gateway across Availability Zones. This protects against a single AZ failure. https://docs.microsoft.com/azure/vpn-gateway/create-zone-redundant-vnet-gateway d. Backup over Internet VPN
• Coexist a Site-to-Site VPN as a passive backup for private peering. If both ExpressRoute circuits go down, your on-premises can still reach Azure over IPsec. https://docs.microsoft.com/azure/expressroute/use-s2s-vpn-as-backup-for-expressroute-privatepeering e. Test and validate
• Use the ExpressRoute resiliency validation preview to simulate site/circuit failures and measure BGP convergence times. https://docs.microsoft.com/azure/expressroute/resiliency-validation

Reference

https://docs.microsoft.com/azure/expressroute/designing-for-high-availability-with-expressroute#active-active-connections

https://docs.microsoft.com/azure/expressroute/design-architecture-for-resiliency

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.