ExpressRoute routing requirements

To connect to Microsoft cloud services by using ExpressRoute, you need to set up and manage routing. Some connectivity providers offer setting up and managing routing as a managed service. Check with your connectivity provider to see if they offer this service. If they don't, you must adhere to the following requirements.

For a description of the routing sessions that you need to set up to facilitate connectivity, see Circuits and routing domains.

IP addresses used for peering

You need to reserve a few blocks of IP addresses to configure routing between your network and Microsoft's Enterprise edge (MSEEs) routers. This section provides a list of requirements and describes the rules regarding how you must acquire and use these IP addresses.

IP addresses used for Azure private peering

You can use either private IP addresses or public IP addresses to configure the peering. The address range you use for configuring routes can't overlap with address ranges used for virtual networks in Azure.

• IPv4:
  • Reserve a /29 subnet or two /30 subnets for routing interfaces.
  • Use either private IP addresses or public IP addresses for the subnets used for routing.
  • The subnets must not conflict with the range reserved by the customer for use in the Microsoft cloud.
  • If you use a /29 subnet, split it into two /30 subnets.
    • Use the first /30 subnet for the primary link and the second /30 subnet for the secondary link.
    • For each of the /30 subnets, use the first IP address of the /30 subnet for your router. Microsoft uses the second IP address of the /30 subnet to set up a BGP session.
    • You must set up both BGP sessions for the availability SLA to be valid.
• IPv6:
  • Reserve a /125 subnet or two /126 subnets for routing interfaces.
  • Use either private IP addresses or public IP addresses for the subnets used for routing.
  • The subnets must not conflict with the range reserved by the customer for use in the Microsoft cloud.
  • If you use a /125 subnet, split it into two /126 subnets.
    • Use the first /126 subnet for the primary link and the second /126 subnet for the secondary link.
    • For each of the /126 subnets, use the first IP address of the /126 subnet for your router. Microsoft uses the second IP address of the /126 subnet to set up a BGP session.
    • You must set up both BGP sessions for the availability SLA to be valid.

Example for private peering

If you choose to use a.b.c.d/29 to set up the peering, split it into two /30 subnets. In the following example, notice how the a.b.c.d/29 subnet is used:

• Split a.b.c.d/29 into a.b.c.d/30 and a.b.c.d+4/30. Pass these subnets down to Microsoft through the provisioning APIs.
  • Use a.b.c.d+1 as the VRF IP for the primary PE and Microsoft uses a.b.c.d+2 as the VRF IP for the primary MSEE.
  • Use a.b.c.d+5 as the VRF IP for the secondary PE and Microsoft uses a.b.c.d+6 as the VRF IP for the secondary MSEE.

Consider a case where you select 192.168.100.128/29 to set up private peering. 192.168.100.128/29 includes addresses from 192.168.100.128 to 192.168.100.135, among which:

• 192.168.100.128/30 is assigned to link1, with provider using 192.168.100.129 and Microsoft using 192.168.100.130.
• 192.168.100.132/30 is assigned to link2, with provider using 192.168.100.133 and Microsoft using 192.168.100.134.

IP addresses used for Microsoft peering

To set up the BGP sessions, use public IP addresses that you own. Microsoft must be able to verify the ownership of the IP addresses through Routing Internet Registries and Internet Routing Registries.

• The portal lists IPs for Advertised Public Prefixes for Microsoft Peering. These IPs create ACLs for the Microsoft core routers to allow inbound traffic from these IPs.
• Use a unique /29 (IPv4) or /125 (IPv6) subnet, or two /30 (IPv4) or /126 (IPv6) subnets, to set up the BGP peering for each peering per ExpressRoute circuit, if you have more than one.
• If you use a /29 subnet, split it into two /30 subnets.
• Use the first /30 subnet for the primary link and the second /30 subnet for the secondary link.
• For each of the /30 subnets, use the first IP address of the /30 subnet on your router. Microsoft uses the second IP address of the /30 subnet to set up a BGP session.
• If you use a /125 subnet, split it into two /126 subnets.
• Use the first /126 subnet for the primary link and the second /126 subnet for the secondary link.
• For each of the /126 subnets, use the first IP address of the /126 subnet on your router. Microsoft uses the second IP address of the /126 subnet to set up a BGP session.
• You must set up both BGP sessions for the availability SLA to be valid.

Public IP address requirement

Private peering

For private peering, you can choose to use public or private IPv4 addresses. Azure provides end-to-end isolation of your traffic, so overlapping of addresses with other customers isn't possible for private peering. These addresses aren't advertised to the Internet.

Microsoft peering

By using the Microsoft peering path, you can connect to Microsoft cloud services. This list of services includes Microsoft 365 services, such as Exchange Online, SharePoint Online, and Microsoft Teams. Microsoft supports bi-directional connectivity on the Microsoft peering. Traffic destined for Microsoft cloud services must use valid public IPv4 addresses before it enters the Microsoft network.

Make sure that you're registered as the owner of your IP address and AS number in one of the following registries:

• ARIN
• APNIC
• AFRINIC
• LACNIC
• RIPENCC
• RADB
• ALTDB

If your prefixes and AS number aren't assigned to you in the preceding registries, you need to open a support case for manual validation of your prefixes and ASN. Support requires documentation, such as a Letter of Authorization that proves you're allowed to use that prefix.

You can use a private AS number with Microsoft peering, but it requires manual validation. In addition, Microsoft removes private AS numbers in the AS PATH for the received prefixes. As a result, you can't append private AS numbers in the AS PATH to influence routing for Microsoft peering. Also, AS numbers 64496 through 64511 reserved by IANA for documentation purposes aren't allowed in the path.

Dynamic route exchange

Routing exchange happens over the eBGP protocol. The MSEEs and your routers establish eBGP sessions. Authentication of BGP sessions isn't required. If necessary, you can configure an MD5 hash. For more information about configuring BGP sessions, see Configure routing and Circuit provisioning workflows and circuit states.

Autonomous System numbers (ASN)

Microsoft uses AS 12076 for Azure public, Azure private, and Microsoft peering. Microsoft reserves ASNs from 65,515 to 65,520 for internal use. ExpressRoute supports both 16-bit and 32-bit AS numbers.

There are no requirements around data transfer symmetry. The forward and return paths can traverse different router pairs. You must advertise identical routes from either side across multiple circuit pairs that belong to you. Route metrics don't need to be identical.

Route aggregation and prefix limits

ExpressRoute supports up to 4,000 IPv4 prefixes and 100 IPv6 prefixes advertised to Microsoft through the Azure private peering. You can increase this limit to 10,000 IPv4 prefixes by enabling the ExpressRoute premium add-on. ExpressRoute accepts up to 200 prefixes per BGP session for Azure public and Microsoft peering.

The BGP session drops if the number of prefixes exceeds the limit. ExpressRoute accepts default routes on the private peering link only. You must filter out default routes and private IP addresses (RFC 1918) from the Azure public and Microsoft peering paths.

Transit routing and cross-region routing

You can't configure ExpressRoute as transit routers. You need to rely on your connectivity provider for transit routing services.

Advertising default routes

You can advertise default routes only on Azure private peering sessions. In this configuration, ExpressRoute routes all traffic from the associated virtual networks to your network. If you advertise default routes into private peering, you block the internet path from Azure. You must rely on your corporate edge to route traffic from and to the internet for services hosted in Azure.

You can't access some services from your corporate edge. To enable connectivity to other Azure services and infrastructure services, you must use user-defined routing to allow internet connectivity for every subnet requiring internet connectivity for these services.

Support for BGP communities

This section provides an overview of how BGP communities work with ExpressRoute. Microsoft advertises routes in the private, Microsoft, and public (deprecated) peering paths with routes tagged with appropriate community values. The rationale for doing so and the details on community values are described in the following sections. However, Microsoft doesn't honor any community values tagged to routes advertised to Microsoft.

For private peering, if you configure a custom BGP community value on your Azure virtual networks, you see this custom value and a regional BGP community value on the Azure routes you advertise to your on-premises over ExpressRoute.

For Microsoft peering, you connect to Microsoft through ExpressRoute at any one peering location within a geopolitical region. You also have access to all Microsoft cloud services across all regions within the geopolitical boundary.

For example, if you connect to Microsoft in Amsterdam through ExpressRoute, you have access to all Microsoft cloud services hosted in North Europe and West Europe.

Refer to the ExpressRoute partners and peering locations page for a detailed list of geopolitical regions, associated Azure regions, and corresponding ExpressRoute peering locations.

You can purchase more than one ExpressRoute circuit per geopolitical region. Having multiple connections offers you significant benefits on high availability due to geo-redundancy. In cases where you have multiple ExpressRoute circuits, you receive the same set of prefixes advertised from Microsoft on the Microsoft peering paths. This configuration results in multiple paths from your network into Microsoft. This configuration can potentially cause suboptimal routing decisions within your network. As a result, you might experience suboptimal connectivity experiences to different services. You can rely on the community values to make appropriate routing decisions to offer optimal routing to users.

All routes advertised from Microsoft include the appropriate community value tag.

Service to BGP community value

In addition to the BGP tag for each region, Microsoft also tags prefixes based on the service they belong to. This tagging only applies to Microsoft peering. The following table provides a mapping of service to BGP community value. You can run the Get-AzBgpServiceCommunity cmdlet for a full list of the latest values.

(1) Azure Global Services includes only Azure DevOps at this time.

(2) Authorization required from Microsoft. See Configure route filters for Microsoft Peering.

(3) This community also publishes the needed routes for Microsoft Teams services.

(4) CRM Online supports Dynamics v8.2 and earlier. For higher versions, select the regional community for your Dynamics deployments.

(5) Use of Microsoft Peering with PSTN services is restricted to specific use cases. See Using ExpressRoute for Microsoft PSTN services.

BGP community support in national clouds

• Office 365 communities aren't supported over Microsoft Peering for Microsoft Azure operated by 21Vianet region.

Next steps

• Configure your ExpressRoute connection.

  • Create and modify a circuit.
  • Create and modify peering configuration.
  • Link a VNet to an ExpressRoute circuit.