ExpressRoute routing requirements

To connect to Microsoft cloud services 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:

Refer to the Circuits and routing domains article for a description of the routing sessions that need to be set up in to facilitate connectivity.

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 these IP addresses must be acquired and used.

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 used for configuring routes can't overlap with address ranges used for virtual networks in Azure.

• IPv4:

  • You must reserve a /29 subnet or two /30 subnets for routing interfaces.

  • The subnets used for routing can be either private IP addresses or public IP addresses.

  • The subnets must not conflict with the range reserved by the customer for use in the Azure cloud.

  • If a /29 subnet is used, it's split into two /30 subnets.

    • The first /30 subnet is used for the primary link and the second /30 subnet is used for the secondary link.
    • For each of the /30 subnets, you must use the first IP address of the /30 subnet for your router. Azure 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:

  • You must reserve a /125 subnet or two /126 subnets for routing interfaces.

  • The subnets used for routing can be either private IP addresses or public IP addresses.

  • The subnets must not conflict with the range reserved by the customer for use in the Azure cloud.

  • If a /125 subnet is used, it's split into two /126 subnets.

    • The first /126 subnet is used for the primary link and the second /126 subnet is used for the secondary link.
    • For each of the /126 subnets, you must use the first IP address of the /126 subnet for your router. Azure 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, it's split into two /30 subnets. In the following example, notice how the a.b.c.d/29 subnet is used:

• a.b.c.d/29 is split to a.b.c.d/30 and a.b.c.d+4/30 and passed down to Azure through the provisioning APIs.
  • You use a.b.c.d+1 as the VRF IP for the Primary PE and Azure uses a.b.c.d+2 as the VRF IP for the primary MSEE.
  • You use a.b.c.d+5 as the VRF IP for the secondary PE and Azure 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 Azure using 192.168.100.130.
• 192.168.100.132/30 is assigned to link2, with provider using 192.168.100.133 and Azure using 192.168.100.134.

IP addresses used for Microsoft peering

You must use public IP addresses that you own for setting up the BGP sessions. Azure must be able to verify the ownership of the IP addresses through Routing Internet Registries and Internet Routing Registries.

• The IPs listed in the portal for Advertised Public Prefixes for Microsoft Peering creates ACLs for the Azure core routers to allow inbound traffic from these IPs.
• You must 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 a /29 subnet is used, it's split into two /30 subnets.
• The first /30 subnet is used for the primary link and the second /30 subnet is used for the secondary link.
• For each of the /30 subnets, you must use the first IP address of the /30 subnet on your router. Azure uses the second IP address of the /30 subnet to set up a BGP session.
• If a /125 subnet is used, it's split into two /126 subnets.
• The first /126 subnet is used for the primary link and the second /126 subnet is used for the secondary link.
• For each of the /126 subnets, you must use the first IP address of the /126 subnet on your router. Azure uses the second IP address of the /126 subnet to set up a BGP session.
• You must set up both BGP sessions for our availability SLA to be valid.

Public IP address requirement

Private peering

You can choose to use public or private IPv4 addresses for private peering. We provide 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 Internet.

Microsoft peering

The Microsoft peering path lets you connect to Microsoft cloud services. Azure supports bi-directional connectivity on the Microsoft peering. Traffic destined to Microsoft cloud services must use valid public IPv4 addresses before they enter the Azure network.

Make sure that your IP address and AS number are registered to you 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.

A Private AS Number is allowed with Microsoft Peering, but requires manual validation. In addition, we remove 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. Additionally, AS numbers 64496 - 64511 reserved by IANA for documentation purposes aren't allowed in the path.

Dynamic route exchange

Routing exchange is over eBGP protocol. EBGP sessions are established between the MSEEs and your routers. Authentication of BGP sessions isn't a requirement. If necessary, an MD5 hash can be configured. See the Configure routing and Circuit provisioning workflows and circuit states for information about configuring BGP sessions.

Autonomous System numbers (ASN)

Azure uses AS 12076 for Azure public, Azure private and Microsoft peering. We have reserved ASNs from 65515 to 65520 for internal use. Both 16 bit and 32-bit AS numbers are supported.

There are no requirements around data transfer symmetry. The forward and return paths may traverse different router pairs. Identical routes must be advertised from either sides across multiple circuit pairs belonging to you. Route metrics aren't required to be identical.

Route aggregation and prefix limits

ExpressRoute supports up to 4000 IPv4 prefixes and 100 IPv6 prefixes advertised to Azure through the Azure private peering. This limit can be increased up to 10,000 IPv4 prefixes if the ExpressRoute premium add-on is enabled. ExpressRoute accept up to 200 prefixes per BGP session for Azure public and Microsoft peering.

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

Transit routing and cross-region routing

ExpressRoute can't be configured as transit routers. You have to rely on your connectivity provider for transit routing services.

Advertising default routes

Default routes are permitted only on Azure private peering sessions. In such a case, ExpressRoute routes all traffic from the associated virtual networks to your network. Advertising default routes into private peering results in the internet path from Azure being blocked. You must rely on your corporate edge to route traffic from and to the internet for services hosted in Azure.

Some services are not able to be accessed 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 get used with ExpressRoute. Azure advertises routes in the private, Azure and public (deprecated) peering paths with routes tagged with appropriate community values. The rationale for doing so and the details on community values are describe as followed. Microsoft, however, 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'll see this custom value and a regional BGP community value on the Azure routes advertised to your on-premises over ExpressRoute.

For Microsoft peering, you're connecting to Azure 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.

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 Azure on the Microsoft peering paths. This configuration results in multiple paths from your network into Microsoft. This set up can potentially cause suboptimal routing decisions to be made within your network. As a result, you may 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.

BGP Community support in Azure operated by 21Vianet

National Clouds Azure Region	BGP community value
China
China North	12076:51301
China East	12076:51302
China East 2	12076:51303
China North 2	12076:51304
China North 3	12076:51305

• Office 365 communities aren't supported over Microsoft Peering for 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