4.4 ExpressRoute BFD, Monitoring & Connection Troubleshooting
Key Takeaways
- MSEE devices use a BGP keepalive of 60 seconds and a hold time of 180 seconds, so without BFD a link failure behind an intermediate Layer 2 device can take up to three minutes to detect.
- Bidirectional Forwarding Detection is supported over both ExpressRoute private peering and Microsoft peering and is enabled by default on the Azure side of newly created peering interfaces, so only the customer CE/PE devices need configuring.
- MSEE BFD transmit and receive intervals are set to 300 milliseconds and in some scenarios 750 milliseconds; the slower of the two peers determines the rate, so you can lengthen the interval but never shorten it below the Microsoft value.
- Enabling BFD on a peering created before August 2018 for IPv4 private peering, January 2020 for IPv4 Microsoft peering, or November 2025 for IPv6 requires resetting that peering.
- BFD speeds link-failure detection to sub-second, but overall convergence between ExpressRoute virtual network gateways and MSEEs still takes up to a minute.
ExpressRoute BFD, Monitoring & Connection Troubleshooting
An ExpressRoute circuit is always deployed as a redundant pair of connections to a pair of Microsoft Enterprise Edge routers (MSEEs). Redundancy only helps if a failure is detected, and detection is exactly where naive ExpressRoute designs fall down: when a Layer 2 device sits between your router and the MSEE, the physical link on your side stays up even after the path has broken, so the only thing that notices is BGP — slowly.
1. Why BFD Exists: The Three-Minute Problem
On MSEE devices, BGP timers are configured as:
| Timer | MSEE value |
|---|---|
| BGP keepalive | 60 seconds |
| BGP hold time | 180 seconds |
If a link fails and there is more than one Layer 2 device in the path, responsibility for detecting the failure falls to the overlying BGP session. With a 180-second hold time, it can take up to three minutes to notice the failure and shift traffic to the alternate connection. Three minutes of blackholed traffic is unacceptable for most production workloads.
The tempting wrong fix
You can lower BGP timers on your own edge device — when the timers differ between peers, the session establishes using the lower value, and BGP keepalive can go as low as 3 seconds with a hold time as low as 10 seconds. Microsoft explicitly recommends against this, because BGP is a process-intensive protocol and aggressive timers destabilise the control plane.
The right fix
Bidirectional Forwarding Detection (BFD) is a lightweight protocol that provides link-failure detection in a sub-second interval with low overhead. It runs independently of BGP and simply tells BGP to tear the session down when the path dies.
2. BFD on ExpressRoute: Support and Defaults
| Question | Answer |
|---|---|
| Which peerings support BFD? | Both private peering and Microsoft peering |
| Is it on by default? | Yes on the Microsoft side. BFD is configured by default under all newly created ExpressRoute private and Microsoft peering interfaces on the MSEEs |
| What must the customer do? | Configure BFD on both the primary and secondary CE/PE devices — a two-step process: configure BFD on the interface, then link it to the BGP session |
| Is customer-side BFD mandatory? | No, it is optional. But the Azure-side BFD configuration for new peerings is not optional and cannot be removed |
| Connectivity model | Works whether you use Layer 2 connections or a managed Layer 3 connection service; configure on your edge routers or your partner's edge routers |
Legacy peerings need a reset
BFD is enabled by default only for peerings created after specific dates. To enable BFD on an older peering you must reset the peering:
| Peering | Created before | Action required |
|---|---|---|
| IPv4 private peering | August 2018 | Reset the peering |
| IPv4 Microsoft peering | January 2020 | Reset the peering |
| IPv6 peering | November 2025 | Reset the peering |
3. BFD Timer Negotiation
Between BFD peers, the slower of the two peers determines the transmission rate.
| Setting | Value |
|---|---|
| MSEE BFD transmit / receive interval | 300 milliseconds |
| MSEE interval in certain scenarios | 750 milliseconds |
| Can you make it faster than Microsoft's value? | No |
| Can you make it slower? | Yes — configure a higher value on your device |
[!NOTE] Because of device-vendor differences in handling, Microsoft recommends disabling BFD echo mode for ExpressRoute connections.
[!IMPORTANT] BFD does not make failover instant. Microsoft states that BFD gives faster failure detection, but overall connection convergence between ExpressRoute virtual network gateways and MSEEs still takes up to a minute. If an exam option promises sub-second end-to-end failover, it is overstating the feature. BFD is also the documented way to speed failover when you run geo-redundant ExpressRoute circuits or use a site-to-site IPsec VPN as backup.
4. Gateway Limits That Cause "Mystery" ExpressRoute Failures
Many ExpressRoute incidents are not faults at all — they are documented limits being exceeded.
| Gateway SKU | VPN/ER coexistence | FastPath | Max circuit connections | Throughput | Routes learned |
|---|---|---|---|---|---|
| Standard / ErGw1Az | Yes | No | 4 | 1,000 Mbps | 4,000 |
| High Performance / ErGw2Az | Yes | No | 8 | 2,000 Mbps | 9,500 |
| Ultra Performance / ErGw3Az | Yes | Yes | 16 | 10,000 Mbps | 9,500 |
| ErGwScale | Yes | Yes (minimum 10 scale units) | 4 / 8 / 16 by scale units | 1,000 Mbps per scale unit | 9,500 |
Additional hard limits:
- The maximum number of ExpressRoute circuits from the same peering location that can connect to the same virtual network is 4, for every gateway SKU.
- ExpressRoute private peering advertises up to 1,000 IPv4 prefixes and 100 IPv6 prefixes from a virtual network to on-premises. Use the
summarizedGatewayPrefixesproperty to advertise summarised prefixes and suppress covered spoke address spaces in hub-and-spoke designs. - Avoid advertising more than 11,000 routes to ExpressRoute across VNet address spaces, on-premises networks, and peerings.
- A virtual network with an ExpressRoute gateway can peer with up to 500 other virtual networks.
- NSGs on
GatewaySubnetare not supported, and a0.0.0.0/0UDR onGatewaySubnetis not supported. BGP route propagation must remain enabled on the gateway subnet or the gateway will not function.
5. A Structured ExpressRoute Troubleshooting Order
Work outward from the physical layer. Skipping layers is how engineers spend an afternoon on BGP when an optic is dark.
| Layer | What to check | Where |
|---|---|---|
| 1. Circuit / provider | Is the circuit Provisioned? Has the provider completed provisioning on their side? | Circuit blade — ServiceProviderProvisioningState |
| 2. Layer 2 | Is the ARP table populated on both primary and secondary? Correct VLAN ID / tagging? | Get-AzExpressRouteCircuitARPTable |
| 3. Layer 3 / BGP | Is the peering Enabled? Are the /30 peer subnets correct and non-overlapping? Is the ASN right? | Get-AzExpressRouteCircuitRouteTable, peering blade |
| 4. Route advertisement | Are the expected prefixes learned and advertised? Are you over the 1,000-prefix limit? | Get-AzExpressRouteCircuitRouteTableSummary |
| 5. Gateway | Right SKU for circuit count and throughput? Gateway health and metrics? | Gateway metrics, Network Insights |
| 6. Path / performance | Latency, packet loss, hop-by-hop path | Network Watcher Connection Monitor |
Common root causes and their signatures
| Symptom | Likely cause |
|---|---|
| Failover takes about three minutes | BFD not configured on the customer edge devices |
| BGP session never establishes | Reserved ASN used on-premises (65515-65520, 8074, 8075, 12076), or mismatched peer subnets |
| Some prefixes missing from on-premises | Route-advertisement limit exceeded, or route filter on Microsoft peering |
| Small requests work, large transfers hang | MTU / fragmentation — ExpressRoute supports 1,400 bytes and gateways drop fragmented packets |
| Throughput plateaus well below the circuit bandwidth | Gateway SKU ceiling; consider a higher SKU or FastPath on Ultra Performance / ErGw3Az |
| Private endpoint connectivity drops during maintenance | Expected; set on-premises TCP timeout to 15-30 seconds |
[!TIP] ASN 12076 is Microsoft's public ASN for ExpressRoute peerings. When ExpressRoute advertises routes to on-premises it strips private BGP ASN information, so on-premises receives prefixes with AS 12076 — which is why AS-path prepending applied by an NVA toward Route Server does not survive to the on-premises router.
An enterprise runs a dual-connection ExpressRoute circuit through a managed Layer 3 provider. During a provider fibre cut, the customer edge router's interface stayed up because an intermediate switch masked the failure, and traffic blackholed for just under three minutes before shifting to the secondary connection. Which change directly addresses the detection delay?
A network engineer configures BFD on their customer edge routers with an interval of 100 milliseconds, expecting 100-millisecond detection against the MSEE. After the session comes up, the observed BFD transmission interval is 300 milliseconds. Why?
A hub virtual network uses a Standard ExpressRoute virtual network gateway. The team wants to connect a fifth ExpressRoute circuit to this virtual network and to enable FastPath for a latency-sensitive trading application. What must change?