ExpressRoute circuits and peering

Important

Public peering for ExpressRoute is being retired on March 31, 2024. For more information, see retirement notice.

ExpressRoute circuits connect your on-premises infrastructure to Microsoft through a connectivity provider. This article helps you understand ExpressRoute circuits and routing domains/peering. The following figure shows a logical representation of connectivity between your WAN and Microsoft.

Diagram showing how ExpressRoute circuits connect your on-premises infrastructure to Microsoft through a connectivity provider.

Note

  • In the context of ExpressRoute, the Microsoft Edge describes the edge routers on the Microsoft side of the ExpressRoute circuit. This is the ExpressRoute circuit's point of entry into Microsoft's network.
  • Azure public peering has been deprecated and is not available for new ExpressRoute circuits. New circuits support Microsoft peering and private peering.

ExpressRoute circuits

An ExpressRoute circuit represents a logical connection between your on-premises infrastructure and Microsoft cloud services through a connectivity provider. You can have multiple ExpressRoute circuits. Each circuit can be in the same or different regions, and can be connected to your premises through different connectivity providers.

ExpressRoute circuits don't map to any physical entities. A circuit is uniquely identified by a standard GUID called as a service key (s-key). The service key is the only piece of information exchanged between Microsoft, the connectivity provider, and you. The s-key isn't a secret for security purposes. There's a 1:1 mapping between an ExpressRoute circuit and the s-key.

New ExpressRoute circuits can include two independent peerings: Private peering and Microsoft peering. Whereas existing ExpressRoute circuits may have three peerings: Azure Public, Azure Private and Microsoft. Each peering is a pair of independent BGP sessions, each of them configured redundantly for high availability. There's a 1:N (1 <= N <= 3) mapping between an ExpressRoute circuit and routing domains. An ExpressRoute circuit can have any one, two, or all three peerings enabled per ExpressRoute circuit.

Each circuit has a fixed bandwidth (50 Mbps, 100 Mbps, 200 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps) and is mapped to a connectivity provider and a peering location. The bandwidth you select is shared across all circuit peerings

Quotas, limits, and limitations

Default quotas and limits apply for every ExpressRoute circuit. Refer to the Azure Subscription and Service Limits, Quotas, and Constraints page for up-to-date information on quotas.

Circuit SKU upgrade and downgrade

Allowed workflow

  • Upgrade from Standard to Premium SKU.
  • Upgrade from Local to Standard or Premium SKU.
    • Can only be done using Azure CLI or Azure PowerShell.
    • Billing type must be unlimited.
  • Changing from MeteredData to UnlimitedData.
  • Downgrade from Premium SKU to Standard.

Unsupported workflow

  • Changing from UnlimitedData to MeteredData.

ExpressRoute peering

An ExpressRoute circuit has multiple routing domains/peerings associated with it: Azure public, Azure private, and Microsoft. Each peering is configured identically on a pair of routers (in active-active or load sharing configuration) for high availability. Azure services are categorized as Azure public and Azure private to represent the IP addressing schemes.

Diagram showing how Azure public, Azure private, and Microsoft peerings are configured in an ExpressRoute circuit.

Azure private peering

Azure compute services, namely virtual machines (IaaS) and cloud services (PaaS), that are deployed within a virtual network can be connected through the private peering domain. The private peering domain is considered to be a trusted extension of your core network into Microsoft Azure. You can set up bi-directional connectivity between your core network and Azure virtual networks (VNets). This peering lets you connect to virtual machines and cloud services directly on their private IP addresses.

You can connect more than one virtual network to the private peering domain. Review the FAQ page for information on limits and limitations. You can visit the Azure Subscription and Service Limits, Quotas, and Constraints page for up-to-date information on limits. Refer to the Routing page for detailed information on routing configuration.

Microsoft peering

Microsoft 365 was created to be accessed securely and reliably via the Internet. Because of this, we recommend ExpressRoute for specific scenarios. For information about using ExpressRoute to access Microsoft 365, visit Azure ExpressRoute for Microsoft 365.

Connectivity to Microsoft online services (Microsoft 365, Azure PaaS services and Microsoft PSTN services) occurs through Microsoft peering. We enable bi-directional connectivity between your WAN and Microsoft cloud services through the Microsoft peering routing domain. You must connect to Microsoft cloud services only over public IP addresses that are owned by you or your connectivity provider and you must adhere to all the defined rules. For more information, see the ExpressRoute prerequisites page.

For more information on services supported, costs, and configuration details, see the FAQ page. For information on the list of connectivity providers offering Microsoft peering support, see the ExpressRoute locations page.

Important

If you're connecting to a service using Microsoft Peering with unlimited data, only egress data won't be charged by ExpressRoute. Egress data will still be charged for services such as compute, storage, or any other services accessed over Microsoft peering even if the destination is a Microsoft peering public IP address.

Peering comparison

The following table compares the three peerings:

Private Peering Microsoft Peering Public Peering (deprecated for new circuits, will be retired on March 31, 2024)
Max. # IPv4 prefixes supported per peering 4000 by default, 10,000 with ExpressRoute Premium 200 200
Max. # IPv6 prefixes supported per peering 100 200 N/A
IP address ranges supported Any valid IP address within your WAN. Public IP addresses owned by you or your connectivity provider. Public IP addresses owned by you or your connectivity provider.
AS Number requirements Private and public AS numbers. You must own the public AS number if you choose to use one. You can set private and public AS numbers for peer ASN. However, you must prove ownership of public IP addresses. Note: If you use customer ASN, you can set public ASN only. Private and public AS numbers. However, you must prove ownership of public IP addresses.
IP protocols supported IPv4, IPv6 IPv4, IPv6 IPv4
Routing Interface IP addresses RFC1918 and public IP addresses Public IP addresses registered to you in routing registries. Public IP addresses registered to you in routing registries.
MD5 Hash support Yes Yes Yes

You may enable one or more of the routing domains as part of your ExpressRoute circuit. You can choose to have all the routing domains put on the same VPN if you want to combine them into a single routing domain. You can also put them on different routing domains, similar to the diagram. The recommended configuration is that private peering is connected directly to the core network, and the public and Microsoft peering links are connected to your DMZ.

Each peering requires separate BGP sessions (one pair for each peering type). The BGP session pairs provide a highly available link. If you're connecting through layer 2 connectivity providers, you're responsible for configuring and managing routing. You can learn more by reviewing the workflows for setting up ExpressRoute.

ExpressRoute health

ExpressRoute circuits can be monitored for availability, connectivity to VNets and bandwidth utilization using ExpressRoute Network Insights.

Connection Monitor for Expressroute monitors the health of Azure private peering and Microsoft peering. For more information on configuration, see Configure Connection Monitor for ExpressRoute.

Next steps