Skip to main content
Troubleshooting ExpressRoute Connections This guide shows a structured, actionable workflow to diagnose and ExpressRoute circuit issues. Follow the steps in sequence to identify whether problems originate from Azure, the connectivity provider, or your on‑premises network. Goals for this troubleshooting runbook:
  • Verify the ExpressRoute circuit is provisioned and operational.
  • Confirm all required ExpressRoute peerings and BGP sessions are correctly configured and established.
  • Validate layer‑2 mappings (ARP/MAC) where applicable.
  • Identify and resolve common performance bottlenecks.
Below each objective is expanded with practical checks, commands, and tools commonly used when troubleshooting ExpressRoute.

​
1) Confirm circuit provisioning and state

Start by verifying the ExpressRoute circuit is provisioned and in a healthy state in Azure. Use the Azure Portal, Azure CLI, or PowerShell depending on your workflow. Key items to validate:
CheckWhy it matters
Circuit provisioning status (provisioningState / status)Confirms Azure has completed provisioning and the circuit is usable
Service key (sKey)Must match the value given to your connectivity provider—mismatches cause provisioning failures
Bandwidth and SKUEnsures you have the expected throughput and feature set (e.g., Standard vs. Premium)
Peerings listVerifies configured peerings (Private, Microsoft) exist for this circuit
Azure CLI examples: 
# Show the ExpressRoute circuit
az network express-route show \
  --name MyExpressRouteCircuit \
  --resource-group MyResourceGroup \
  --output table

# List peerings for the circuit
az network express-route peering list \
  --resource-group MyResourceGroup \
  --circuit-name MyExpressRouteCircuit \
  --output table
PowerShell examples: 
# Get the ExpressRoute circuit
Get-AzExpressRouteCircuit -Name "MyExpressRouteCircuit" -ResourceGroupName "MyResourceGroup"

# List peerings on the circuit
Get-AzExpressRouteCircuitPeering -ResourceGroupName "MyResourceGroup" -CircuitName "MyExpressRouteCircuit"
Always confirm the service key (sKey) shown in Azure matches the value your connectivity provider has. Mismatches are a common provisioning cause.

​
2) Validate ExpressRoute peerings and BGP

Many connection failures stem from missing or misconfigured peerings and BGP sessions. ExpressRoute supports Private Peering (for VNets) and Microsoft Peering (for Microsoft services). Note that the older “public” peering is deprecated in most deployments—use Microsoft peering where applicable. Checklist for peering and BGP verification:
  • Verify the expected peering types (Private and/or Microsoft) are enabled and present.
  • Ensure BGP sessions are in the Established state on both Azure and your on‑prem router.
  • Confirm ASN, primary/secondary Azure peer IPs, and advertised prefixes are correct.
  • Review route filters, prefix limits, and service-specific filters for Microsoft peering.
Quick Azure CLI check for a specific peering: 
az network express-route peering show \
  --resource-group MyResourceGroup \
  --circuit-name MyExpressRouteCircuit \
  --name AzurePrivatePeering \
  --output json
On-prem BGP verification (vendor dependent):
  • Cisco IOS: show ip bgp summary, show bgp neighbors
  • Junos: show bgp summary, show bgp neighbors
  • Arista/EVPN: show ip bgp summary, show bgp neighbors
What to look for:
  • Session state = Established
  • Expected prefixes being received and advertised
  • No AS path tampering or prefix filters blocking routes
  • Correct next-hop attributes for received prefixes

​
3) Layer‑2 verification and ARP

For ExpressRoute (dedicated, non-VPN) connections, layer‑2 visibility—MAC, ARP, VLAN—on your edge device and the provider demarcation can confirm that traffic reaches the Azure edge device. Common layer‑2 checks:
  • ARP tables on edge routers/switches for Azure peer IPs.
  • MAC address tables and VLAN tags on the provider demarcation.
  • Any layer‑2 filtering or ACLs on the demarcation device.
Example vendor commands (syntax varies): 
# Cisco IOS example commands
show ip arp
show mac address-table
When you lack visibility into the provider demarcation, coordinate with your connectivity provider to obtain ARP/MAC table snapshots and validate mappings.
Layer‑2 diagnostics are often limited to the service provider’s demarcation equipment. Coordinate with your connectivity provider if you need ARP/MAC visibility beyond your own edge device.

​
4) Identifying and resolving performance bottlenecks

Performance issues can originate from oversubscription, MTU mismatches, QoS, routing asymmetry, or interface saturation. Use a systematic approach to isolate the cause. Troubleshooting steps:
  • Measure throughput and latency from on‑prem to Azure using tools such as iperf (TCP/UDP tests).
  • Check interface counters and errors on on‑prem and provider-facing links.
  • Confirm MTU is consistent end-to-end; mismatched MTU leads to fragmentation and poor performance.
  • Inspect QoS policies that might deprioritize or rate-limit traffic.
  • Review Azure circuit metrics and Network Watcher diagnostics for anomalous patterns.
Useful tools and Azure resources:
Tool / ResourceUse case
iperf, iperf3Throughput testing between on‑prem and Azure VM endpoints
Router interface countersDetect drops, errors, or collisions on physical links
Network Watcher (connection troubleshoot, packet capture)End-to-end path checks and packet captures in Azure
Azure Portal metrics for ExpressRouteBandwidth usage, ingress/egress metrics per circuit
Provider-provided telemetryDemarcation device stats, if available
Practical guidance:
  • If TCP throughput is low but interface counters are clean, verify MTU and window sizing.
  • If you see high retransmits, test with packet capture and check for drops on intermediate links.
  • For intermittent latency spikes, correlate against interface errors, provider maintenance windows, or Azure edge incidents.

​
Quick reference troubleshooting sequence

  1. Confirm Azure circuit provisioning and that the sKey matches the provider.
  2. Verify peerings exist and BGP sessions are Established (validate ASNs, peer IPs, and prefixes).
  3. Validate layer‑2 mappings (ARP/MAC) on your edge; request demarcation visibility from the provider if required.
  4. Diagnose performance using throughput/latency tests, MTU verification, QoS review, and interface counters.
  5. Collect logs, packet captures, and metric graphs before escalating to Azure or your connectivity provider.

​
Summary

Use the structured workflow above to isolate ExpressRoute problems quickly:
  • Start with provisioning and service key validation.
  • Move to peering and BGP validation.
  • Check layer‑2 mappings when needed.
  • Perform targeted performance diagnostics and use provider telemetry.
With clear evidence (circuit state, BGP status, ARP/MAC mappings, packet captures, and metrics) you can escalate to Azure and your connectivity provider with the right data to resolve the issue faster.

Watch Video