Skip to main content
Validating peering configuration After confirming the ExpressRoute circuit health, the next step is to validate the peering configuration to ensure Azure and your connectivity provider agree on addressing and peering parameters. This confirms Azure-side provisioning and helps identify misconfigurations that prevent BGP adjacency or traffic flow. In the Azure portal, open your ExpressRoute circuit and view the Peerings area (accessible from the circuit Overview or the Peerings blade). You should see all configured peerings (for example: Microsoft, Private, and Public when applicable) and their corresponding statuses. The expected status for each peering is “Provisioned”, and both the primary and secondary subnets should be populated. If a peering is not Provisioned or subnets are missing, it typically indicates issues such as an incorrect IP addressing scheme, VLAN mismatch, or incomplete provisioning from the connectivity provider.
A slide titled "Validating Peering Configuration" showing an Azure portal screenshot for an ExpressRoute circuit. The screenshot highlights Azure Private peering as "Provisioned" with primary/secondary subnets 192.168.20.16/30 and 192.168.20.20/30.
Step-by-step validation checklist
  1. Open the ExpressRoute circuit > Peerings blade in the Azure portal.
  2. Confirm each expected peering (Private, Microsoft, Public) appears in the list.
  3. Verify the status is “Provisioned” for each peering.
  4. Confirm the primary and secondary peer IP subnets shown match the values provided by your connectivity provider.
  5. If Provisioned but traffic isn’t working, proceed to validate BGP adjacency, route exchanges, and local/remote route tables.
Recommended quick checks when a peering is not provisioned or subnets are missing:
  • Confirm the circuit has been provisioned by your service provider and that they report no outstanding actions.
  • Verify the peering configuration (VLAN ID, peer IP addresses, subnet masks) exactly matches the provider’s configuration.
  • Confirm the correct peering types are enabled (Private, Microsoft, Public) and that ASN/BGP settings match both sides.
  • Review the ExpressRoute circuit’s activity log, events, and notifications for provisioning or connectivity errors.
  • If you recently changed settings, allow propagation time and re-check after the provider confirms provisioning.
Common symptoms, probable causes, and remediation
SymptomProbable causeRecommended remediation
Peering missing from Peerings bladeProvider has not finished provisioningContact provider; confirm VLAN and peering provisioning
Peering present but no subnetsIncomplete configuration or mismatched IP schemeVerify expected peer IP subnets with provider and update settings
Status not “Provisioned”VLAN mismatch or provisioning failureCompare VLAN ID and peering type with provider; check circuit events
Provisioned but no trafficBGP adjacency not established or routes not advertisedValidate BGP sessions and routes on both sides
Azure CLI and REST checks
  • List peerings (Azure CLI)
CLI
az network express-route peering list \
  --resource-group <RG_NAME> \
  --circuit-name <CIRCUIT_NAME> \
  --output table
  • Show a specific peering (Azure CLI)
az network express-route peering show \
  --resource-group <RG_NAME> \
  --circuit-name <CIRCUIT_NAME> \
  --name <PEERING_NAME>
Use these commands to quickly verify what Azure has recorded for VLAN, peer IPs, and peering state. Additional troubleshooting
  • Check BGP session status and routes on your on-premises router (vendor-specific CLI).
  • Use Network Watcher and diagnostic logs to inspect route propagation and reachability in Azure.
  • Review ExpressRoute documentation for peering and BGP troubleshooting:
If a peering shows as Provisioned but traffic is not flowing, validate BGP adjacency and route tables next — “Provisioned” means Azure’s side is configured, not that BGP peering or routing is established. Verify BGP state, advertised prefixes, and route filters on both the Azure and provider sides.

Watch Video