> ## 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.

# Validate Peering Configuration

> Guide to validating Azure ExpressRoute peerings via portal, Azure CLI and PowerShell including checks, troubleshooting steps and configuration verification for BGP, VLANs, ASNs, and IP assignments

After confirming circuit health, the next step is to validate your peering configuration. This ensures the peerings for an ExpressRoute circuit are present, properly provisioned, and ready for BGP session establishment and traffic flow.

This guide shows how to verify peerings both in the Azure portal and from the command line (Azure CLI and PowerShell). It also includes common troubleshooting steps and quick checks to help you identify configuration mismatches.

## What to verify (Quick checklist)

* Peerings (Private, Microsoft, Public) exist for the circuit.
* Each peering's provisioning state is `Provisioned`.
* Primary and secondary IP addresses for Private peering are present and correct.
* VLAN ID and peer ASN match what your connectivity provider expects.
* BGP session parameters (peer ASN, authentication, passwords) are consistent on both sides.

<Callout icon="lightbulb" color="#1CB2FE">
  Before making changes, record the current peering settings (VLAN, ASN, IP pairs). You can use the Azure CLI or PowerShell to export these settings for auditing or troubleshooting.
</Callout>

## Verify in the Azure portal

1. Open the Azure portal and navigate to your ExpressRoute circuit.
2. From the circuit Overview, open the "Peerings" section.
3. Confirm the configured peerings appear (for example: Private, Microsoft, Public—as applicable).
4. For each peering:
   * Check the provisioning status: it should be `Provisioned`.
   * For Private peering, confirm both primary and secondary IP addresses are populated and match your design.
   * Validate VLAN ID and peer ASN are correct for your environment.

Mismatches or missing entries commonly indicate configuration issues that will prevent BGP session establishment or traffic flow.

## Command-line checks

Use the CLI for scripted validation and quick automation-friendly checks.

* Azure CLI (recommended for scripting)

```bash theme={null}
# Show the circuit and inspect the peerings section
az network express-route show \
  --name MyCircuit \
  --resource-group MyResourceGroup \
  -o json | jq '.peerings'
```

Check each peering object for:

* `provisioningState` or `status` = `Provisioned`

* `ipv4Routes?` and IP address fields (primary/secondary) for Private peering

* `peeringType`, `vlanId`, `peerASN`

* PowerShell

```powershell theme={null}
# Retrieve the ExpressRoute circuit and expand the Peerings property
(Get-AzExpressRouteCircuit -Name 'MyCircuit' -ResourceGroupName 'MyResourceGroup') |
  Select-Object -ExpandProperty Peerings
```

Inspect the returned objects for `ProvisioningState`, `PeeringType`, `PeerASN`, `VlanId`, and IP configuration properties.

## Quick reference table

| Check               | Portal location               | CLI / PowerShell                              | Expected                                          |                                                  |
| ------------------- | ----------------------------- | --------------------------------------------- | ------------------------------------------------- | ------------------------------------------------ |
| Peerings exist      | Circuit → Peerings            | \`az network express-route show ...           | jq '.peerings'\`                                  | `Private`, `Microsoft`, `Public` (as applicable) |
| Provisioning state  | Peerings list                 | `jq '.provisioningState'`                     | `Provisioned`                                     |                                                  |
| Private peering IPs | Peering details               | Inspect `properties.ipConfigurations` in JSON | `Primary` and `Secondary` IPs present and correct |                                                  |
| VLAN and ASN        | Peering details               | `vlanId`, `peerASN` fields                    | Match service provider values                     |                                                  |
| BGP status          | Peering details / Router logs | Router and provider logs                      | BGP session established                           |                                                  |

Note: In the table above, any JSON or object-like values are shown as code to avoid parsing issues (for example, `properties.ipConfigurations`).

## Troubleshooting tips

* If a peering is missing:
  * Confirm the peering was created on the correct ExpressRoute circuit and in the correct resource group.
  * Verify you selected the correct peering type (Private, Microsoft, Public) when creating the peering.

* If a peering's provisioning state is not `Provisioned` or is stuck:
  * Verify VLAN ID and peer ASN are configured correctly both in Azure and by your connectivity provider.
  * Confirm primary/secondary IP address pairs match the provider's assigned addresses.
  * Ensure required route filters, service keys, or other provider-specific settings have been applied.

* If BGP does not establish:
  * Validate BGP authentication (if used), peer ASNs, and BGP passwords on both sides.
  * Review edge-router logs and any notifications from your connectivity provider for session negotiation errors.
  * Confirm prefix advertisements and route filters are correctly applied.

* If you see inconsistent or unexpected IP settings in the portal vs. provider documentation:
  * Do not change values unilaterally—coordinate changes with the connectivity provider to avoid mismatched configurations.

<Callout icon="warning" color="#FF6B6B">
  Do not change VLAN IDs, peer ASNs, or IP assignments without confirming with your connectivity provider—these values must match exactly on both sides to establish BGP and avoid outages.
</Callout>

## Example inspection of Azure CLI JSON output

When you run the Azure CLI command above, a peering object in the JSON might include fields such as:

* `peeringType`
* `peerASN`
* `vlanId`
* `ipConfigurations` (contains `primaryIPv4` and `secondaryIPv4` for Private peering)
* `provisioningState`

Use `jq` or equivalent JSON parsing tools to extract and compare these values programmatically as part of validation scripts.

## Links and references

* [Azure ExpressRoute overview](https://learn.microsoft.com/azure/expressroute/expressroute-introduction)
* [Azure CLI documentation](https://learn.microsoft.com/cli/azure/)
* [Get-AzExpressRouteCircuit](https://learn.microsoft.com/powershell/module/az.network/get-azexpressroutecircuit)

By following these checks and using the portal and CLI examples above, you can quickly validate ExpressRoute peering configuration and identify common provisioning issues.

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/az-700-designing-and-implementing-microsoft-azure-networking-solutions/module/6190597d-0e7a-4ffd-ac5d-afe70f482a27/lesson/8ac98c84-a85f-4045-bf3f-596ec84035db" />
</CardGroup>