> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Introduction
> Troubleshooting runbook for Azure ExpressRoute circuits covering provisioning, peerings and BGP, layer‑2 verification, performance diagnostics, tools, commands, and escalation guidance
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:
| Check | Why 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 SKU | Ensures you have the expected throughput and feature set (e.g., Standard vs. Premium) |
| Peerings list | Verifies configured peerings (Private, Microsoft) exist for this circuit |
Azure CLI examples:
```bash theme={null}
# 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:
```powershell theme={null}
# 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:
```bash theme={null}
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):
```text theme={null}
# 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 / Resource | Use case |
| --------------------------------------------------------- | --------------------------------------------------------- |
| iperf, iperf3 | Throughput testing between on‑prem and Azure VM endpoints |
| Router interface counters | Detect 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 ExpressRoute | Bandwidth usage, ingress/egress metrics per circuit |
| Provider-provided telemetry | Demarcation 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.
## Links and references
* ExpressRoute overview: [https://learn.microsoft.com/azure/expressroute/expressroute-introduction](https://learn.microsoft.com/azure/expressroute/expressroute-introduction)
* Azure networking documentation: [https://learn.microsoft.com/azure/networking](https://learn.microsoft.com/azure/networking)
* Network Watcher: [https://learn.microsoft.com/azure/network-watcher/](https://learn.microsoft.com/azure/network-watcher/)
## 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.