ExpressRoute: BGP route limits, route preference and failover to VPN

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

ExpressRoute does not trim excess routes. Advertise more than 4,000 IPv4 prefixes over private peering on a Standard circuit, or 10,000 on Premium, and the BGP session drops until the count falls. A site-to-site VPN only takes over if it holds a usable route when that happens, and only if your own routers also send return traffic the same way.

So treat this as three separate designs: keep route counts inside the limits, set preference in both directions, and test the failover on purpose.

The commands come from Microsoft's published reference and were not run in a lab for this article. Limits were read on 9 November 2026 and change, so check them again before you design to them.

Why it matters

The dangerous route-limit failure is the one caused by something unrelated. Someone adds a redistribution statement on a core router, or a new site brings a large table, and the circuit disappears along with everything behind it.

Backup paths have a matching weakness. Microsoft says the common reason a passive connection fails alongside the primary is lack of active maintenance. A VPN that has carried no production traffic for two years is an untested assumption.

How the limits work

Each limit counts something different, and the failure differs by direction.

These values come from the Azure service limits page and the ExpressRoute FAQ. The per-SKU figures come from the gateway page. They matter when you weigh Premium, because a circuit that accepts 10,000 prefixes does not raise the limit of a Standard gateway behind it.

The 1,000 limit trips hub-and-spoke designs in particular. A hub advertises its own address space and every peered spoke's, so growth in spokes is growth in advertised prefixes. Microsoft's fix is advertised gateway prefixes, set with the summarizedGatewayPrefixes property on the gateway's virtual network. The gateway then advertises the summaries and suppresses the spoke ranges they cover.

What a limit breach looks like

Microsoft's documentation states that the sessions disconnect and return once the count is back in range. It does not describe a partial mode.

Because the same advertisement normally goes down both the primary and secondary links, expect both sessions to be affected. That is editorial inference from the BGP behaviour, and it is the reason a route leak can take out a fully redundant circuit.

Microsoft also warns about one specific source of growth. If you take prefixes received over Microsoft peering and re-advertise them into private peering, you inherit a list that Microsoft updates monthly and that can grow significantly.

The backup has a smaller limit

Azure VPN Gateway supports up to 4,000 prefixes and drops the BGP session above that.

A Premium circuit carrying 6,000 on-premises routes is therefore a working primary whose backup cannot hold the same table. Filter or summarise what you advertise to the VPN side, and confirm that those summaries still cover what matters.

Watching the counts

The ExpressRoute gateway exposes metrics for this:

• ExpressRouteGatewayCountOfRoutesLearnedFromPeer
• ExpressRouteGatewayCountOfRoutesAdvertisedToPeer

Circuit availability is in BgpAvailability and ArpAvailability. Alert on the route counts well below the limit. A threshold around 80 per cent is a reasonable starting point, and that figure is our suggestion rather than a Microsoft value.

How route preference works

Selection happens separately at each end. Getting one direction right does nothing for the other.

Azure's choice, towards on-premises

For a given destination, the order is:

1. Longest prefix wins. Microsoft's coexistence guide says that while ExpressRoute is preferred when both routes are the same, Azure uses the longest prefix match first. A /25 on VPN beats a /24 on ExpressRoute.
2. ExpressRoute over VPN for an identical prefix, by default.
3. Between ExpressRoute circuits, connection weight is considered before AS path length.

The first rule is the common accident. A more specific prefix left on the VPN, perhaps from an old static configuration, silently pulls that subnet off the circuit. Before accepting a design, list the prefixes learned on each path and look for any VPN route more specific than its ExpressRoute equivalent.

If Azure Route Server is in the path, it has its own routing preference setting: ExpressRoute by default, VPN, or AS path. It applies once prefix lengths are equal.

Choosing between circuits

Microsoft lists the options in order of effectiveness:

1. Advertise more specific routes over the preferred circuit.
2. Set a higher connection weight on the preferred circuit's connection. The range is 0 to 32,000 and the default is 0, and the highest wins.
3. Prepend AS path on the less preferred circuit.

With identical routes and attributes and nothing set, Azure load-balances across up to 16 circuits using equal-cost multipath. Microsoft warns that load-balancing across geo-redundant parallel paths gives inconsistent network performance, and says those paths can be in the same metro or different metros. So make a deliberate choice.

The 16-circuit figure also depends on the gateway. Microsoft allows 4 circuits in the same peering location linked to one virtual network. Across different locations it allows 4 on Standard/ERGw1Az, 8 on High Performance/ERGw2Az and 16 on Ultra Performance/ErGw3Az.

Your choice, towards Azure

Azure cannot set this for you. Microsoft's guide says to configure the local network to prefer ExpressRoute with a higher local preference on routes received over the circuit. Its worked example uses 150 against a default of 100.

Local preference is an iBGP attribute, so it must reach every router that makes the decision. Set on one edge router and not carried internally, it does nothing for traffic that enters elsewhere.

If you skip this, traffic can leave over the circuit and return over the VPN. Microsoft's backup guide says it is your responsibility to make on-premises traffic also prefer the ExpressRoute path. Its disaster recovery page notes that asymmetric routing can block traffic where a stateful device such as a NAT or firewall sits in the path, while saying such devices are not typically found on the private peering path itself. Our editorial view is that a VPN often terminates on a firewall, which would put a stateful device on one leg of an asymmetric flow.

Coexistence requirements

The gateway design has to allow both connections before routing matters. Per the coexistence guide:

• The VPN gateway must be route-based and not Basic SKU. The guide names VpnGw1, VpnGw2 and VpnGw3 for this configuration.
• The gateway subnet must be /27 or larger. Connecting 16 circuits needs /26 or larger.
• The two gateways exchange routes using BGP, so a UDR on the gateway subnet must not include the gateway subnet's own range.
• For transit routing between ExpressRoute and VPN, keep the VPN gateway's ASN at 65515.

Microsoft reserves ASNs 65515 to 65520 for internal use, and Azure's own peering AS is 12076.

Two scope limits matter. VPN failover applies only to virtual networks on Azure private peering, so Microsoft peering has no equivalent. And Microsoft does not recommend site-to-site VPN as the backup for latency-sensitive, mission-critical or bandwidth-intensive workloads. It points to multi-site ExpressRoute designs for those.

One further trap sits in the same guide. With Microsoft peering enabled, you can receive the VPN gateway's public address over ExpressRoute. If the tunnel's own underlay follows that route, the backup depends on the circuit it is meant to replace. Microsoft says to route the VPN connection to the internet.

How fast failover happens

Failover needs the routes to be withdrawn, and detection speed sets the delay.

BGP on the Microsoft side uses a keepalive of 60 seconds and a hold time of 180 seconds. Microsoft says a link failure can take up to three minutes to detect without further help.

You can lower the timers on your device, and the session uses the lower value. Microsoft gives floors of a three-second keepalive and 10-second hold, but does not recommend aggressive timers because the protocol is process intensive.

Bidirectional Forwarding Detection (BFD) is the better tool, offering sub-second detection. It is already configured on the Microsoft side for newly created peerings, so you only need to configure it on your primary and secondary devices. Microsoft's intervals are 300 milliseconds and in some scenarios 750.

Older peerings need a reset first. That means private peerings created before August 2018 and Microsoft peerings before January 2020 for IPv4, and circuits configured before November 2025 for IPv6.

Microsoft's examples show the standby path taking over when both connections of the preferred circuit go down. Losing one of the two links is not a failover to VPN. The other link carries on.

A path that drops traffic while BGP stays up will not trigger failover either, because no route is withdrawn. That is editorial reasoning from how BGP works. Monitor traffic, not only session state.

Proving the state

Work up the stack. These commands use the published cmdlets.

Layer 2. An incomplete on-premises MAC address, or a result holding only the Microsoft entry, indicates a layer 2 problem. Microsoft adds that results can vary by hardware platform and may show only the on-premises interface.

Get-AzExpressRouteCircuitARPTable -ResourceGroupName <rg> `
  -ExpressRouteCircuitName <circuit> `
  -PeeringType AzurePrivatePeering -DevicePath Primary

Repeat with -DevicePath Secondary. Check both paths at every step, since a healthy primary can hide a broken secondary.

BGP and routes. Confirm every on-premises prefix you expect is present.

Get-AzExpressRouteCircuitRouteTable -ResourceGroupName <rg> `
  -ExpressRouteCircuitName <circuit> `
  -PeeringType AzurePrivatePeering -DevicePath Primary

If the eBGP state is Active or Idle, Microsoft says to check the peer subnets, VlanId, AzureASN and PeerASN against your device. If you use MD5, the shared key must also match on both sides.

The Azure CLI has list-route-tables and list-route-tables-summary, taking --path primary and --peering-name AzurePrivatePeering. Microsoft marked both as preview when this was checked.

Traffic. Compare byte counters across both paths.

Get-AzExpressRouteCircuitStats -ResourceGroupName <rg> `
  -ExpressRouteCircuitName <circuit> -PeeringType 'AzurePrivatePeering'

What a workload actually uses. Look at the effective routes on a VM's interface.

az network nic show-effective-route-table \
  --resource-group <rg> --name <nic-name> --output table

Our reasoning is that a virtual network gateway next hop type alone does not tell you which of the two gateways is in use, so compare the listed next hop addresses with your known gateway addresses.

The on-premises view. On your routers, confirm the path you expect is best in both tables, routes from Azure and routes towards it.

What to choose and why

These are editorial recommendations.

Filter routes outbound on your edge with an explicit prefix limit, so a mistake is caught on your side. Many routers can shut a session or warn at a set prefix count. Prefer a warning threshold and a filter, since a hard shutdown on your side produces the same outage.

Be careful with default routes. You can advertise a default route only on private peering. Doing so sends the linked virtual networks' internet traffic to your network and breaks Windows and other VM licence activation unless you add the workaround.

Risks and limits

Warning: disabling a peering disconnects the BGP session on both primary and secondary connections and removes connectivity through that peering. Any production test therefore needs an approved window, a verified VPN path and the on-premises network owner present.

Microsoft documents disabling a peering as a way to test disaster recovery between two ExpressRoute circuits, and it advises periodically testing failover on standby circuits. Using the same procedure to test a VPN backup is our application of it.

A failover plan must identify the exact private peering, both affected links, a verified independent management path, the expected VPN routes and the criteria for restoring service. The cited procedure disables connectivity through that peering. Its use for an ExpressRoute-to-VPN test is an editorial adaptation, not a validated runbook. Have the network owner review and rehearse the exact change and recovery sequence in an isolated environment before scheduling any production test.

Record what you measured: time to loss, time to recovery, which prefixes moved, and whether sessions stayed up through the switch back.

During Microsoft maintenance you may see a longer AS path prepend on one connection, which shifts traffic gracefully between connections. Microsoft says you must not ignore it, because that can cause asymmetric routing and an outage. Let your routers honour the longer path, and configure BFD for faster BGP failover between the primary and secondary connections.

These commands were not lab tested for this article. Throughput on the VPN path was not assessed. Check your gateway SKU, since a tunnel can be healthy and still be too small for the failed-over load.

Sources

Opened 9 November 2026. Sources behind the corrections reopened 10 November 2026.

• ExpressRoute FAQ
• ExpressRoute routing requirements
• Azure subscription and service limits
• Using site-to-site VPN as a backup for ExpressRoute private peering
• Configure ExpressRoute and site-to-site coexisting connections
• Designing for disaster recovery with ExpressRoute private peering
• Optimise ExpressRoute routing
• Configure BFD for ExpressRoute
• Verify ExpressRoute connectivity
• Reset ExpressRoute circuit peerings
• Monitoring data reference for ExpressRoute
• About ExpressRoute virtual network gateways
• Link a virtual network to an ExpressRoute circuit
• Routing preference with Azure Route Server
• VPN Gateway FAQ
• az network express-route reference
• az network nic reference

This article was originally published on 10 November 2026.