Skip to main content
Configuring Private peering for Azure ExpressRoute is performed in the Azure portal after you create an ExpressRoute circuit. This guide explains the fields you must provide in the Private peering pane, the recommended values, and the operational considerations to establish secure and resilient BGP peering between your on-premises routers (or your connectivity provider) and Microsoft Edge.

​
What Private Peering Does

Private peering establishes a dedicated, private network path between your on-premises network and your Azure Virtual Networks (VNets) over ExpressRoute. It uses BGP to exchange routes and requires careful alignment of addressing, VLAN tagging, ASN settings, and (optionally) BGP authentication.

​
Key fields you configure in the portal

When you open the ExpressRoute circuit and select the Private peering tab, you’ll supply several technical details required to establish the BGP sessions. These typically include:
  • Non‑VNet subnets (BGP peer IPs)
  • VLAN ID
  • Peer ASN (Autonomous System Number)
  • BGP route advertisement configuration
  • Optional BGP MD5 authentication
  • Optional Global Reach settings
Below is a short table summarizing each field, its purpose, and recommended values.
FieldPurposeRecommended values / notes
Non‑VNet subnets (BGP peer IPs)Point-to-point IPs used for the session between Microsoft Edge and your routerUse a pair of IPv4 /30 subnets (primary and secondary for redundancy). For IPv6, use appropriate prefix (commonly /126). Ensure these do not overlap any VNet or on-prem CIDR.
VLAN IDLayer‑2 tag used on the circuit interfaceMatch the VLAN configured on your on-prem equipment or provider.
Peer ASNASN presented by your side of the BGP sessionUse your on-prem ASN (2-byte or 4-byte supported), or the ASN your provider specifies if they manage the peering.
BGP advertisingRoutes you will advertise to AzureAdvertise only the prefixes you want reachable in Azure; avoid overlapping or overly broad prefixes.
BGP MD5 (optional)Session authentication for BGPEnable where supported; coordinate the password with the Microsoft side.
Global Reach (optional)Interconnects multiple on-prem sites via Azure backboneEnable if you need site-to-site connectivity across different ExpressRoute circuits and providers support it.
The image shows five rounded teal panels on the left labeled "Non‑VNet Subnets", "VLAN ID", "ASN", "BGP Advertising", and "Optional MD5". On the right is a screenshot of an Azure "Private peering" configuration form with fields for peer ASN, IPv4/IPv6 subnets, VLAN ID, and options to add global reach or save.

​
Step-by-step: What to enter in the portal

  1. In the ExpressRoute circuit, open the Private peering tab.
  2. Enter the Peer ASN — the ASN your on-premises router will use.
  3. Provide the IPv4 point-to-point subnets:
    • Primary session: assign one /30 (two usable addresses).
    • Secondary session: assign a second /30 for redundancy.
  4. (Optional) Add IPv6 point-to-point prefixes if using IPv6 (commonly /126).
  5. Enter the VLAN ID that matches your on-prem VLAN configuration.
  6. Configure which routes you will advertise (this determines what becomes reachable in Azure).
  7. (Optional) Enable BGP MD5 and enter the session password if you and Microsoft coordinate MD5 usage.
  8. (Optional) Enable Global Reach if you plan to interconnect on-prem sites via the Microsoft backbone and your provider supports it.
  9. Save the configuration and verify coordination with your provider or operations team.

​
On‑premises configuration checklist

Before activating the peering on Microsoft’s side, ensure your on-premises (or provider) configuration matches exactly:
  • VLAN ID is identical on both ends.
  • BGP peer IP addresses match the Azure-provided /30 addresses.
  • Peer ASN is set correctly (2-byte or 4-byte as applicable).
  • BGP timers and hold times are compatible.
  • BGP MD5 password (if used) is configured on both sides.
  • Route filters or route-map policies align with advertised/accepted prefixes.
  • No IP address or route overlaps with existing VNets or on‑prem ranges.
Ensure the /30 subnets you use for the BGP peering IPs do not overlap with any existing VNet address spaces or on-premises networks. Overlap will prevent proper routing and can cause connectivity failures.

​
Example BGP neighbor configuration snippets

Cisco IOS example:
Output:
Cisco IOS
interface GigabitEthernet0/0
  description ExpressRoute - Private Peering
  encapsulation dot1Q <VLAN_ID>
  ip address <your-peer-ip> 255.255.255.252

router bgp <YOUR_ASN>
  neighbor <azure-peer-ip> remote-as <AZURE_ASN>
  neighbor <azure-peer-ip> password <MD5_PASSWORD>    ! optional
  network <YOUR_ADVERTISED_PREFIX> mask 255.255.255.0
Juniper example:
Output:
Junos Configuration
interfaces ge-0/0/0 unit 0 family inet address <your-peer-ip>/30
vlan-id <VLAN_ID>

protocols {
  bgp {
    group ER-PRIVATE {
      type external;
      peer-as <AZURE_ASN>;
      neighbor <azure-peer-ip> {
        authentication-key "<MD5_PASSWORD>";  # optional
      }
    }
  }
}
Note: Replace placeholders with your actual values. Azure’s remote ASN for private peering varies by region and service — verify the correct Azure ASN in the portal or documentation.

​
Security and resiliency considerations

  • Use BGP MD5 when your router platform and the Microsoft side support it to mitigate session reset attacks.
  • Advertise only the prefixes you intend Azure to reach — filter overly broad or overlapping prefixes.
  • Deploy primary and secondary peering sessions (different subnets) to provide router-level redundancy.
  • Consider Global Reach if you require private connectivity between multiple on-prem sites via Azure’s backbone.

​
Troubleshooting tips

  • If the BGP session fails to come up, verify VLAN ID, peer IPs, and ASNs match exactly.
  • Check for IP overlaps; duplicate subnets prevent proper routing.
  • Confirm BGP timers, hold times, and authentication match.
  • Review route advertisements and inbound route filters on both sides.
  • Use Azure Network Watcher and your router’s BGP show commands to inspect session state and received routes.
In summary, private peering provides a secure, private BGP-based connection between your on-premises network and Azure VNets. Careful alignment of VLANs, peer subnets, ASN, and optional MD5 authentication — plus coordination with your provider — will ensure a resilient and secure ExpressRoute deployment.

Watch Video