Move a public peering to Microsoft peering
This article helps you move a public peering configuration to Microsoft peering with no downtime. ExpressRoute supports using Microsoft peering with route filters for Azure PaaS services, such as Azure storage and Azure SQL Database. You now need only one routing domain to access Microsoft PaaS and SaaS services. You can use route filters to selectively advertise the PaaS service prefixes for Azure regions you want to consume.
Important
Public peering for ExpressRoute is being retired on March 31, 2024. For more information, see retirement notice.
Azure public peering has one NAT IP address associated to each BGP session. Microsoft peering allows you to configure your own NAT allocations, and use route filters for selective prefix advertisements. Public Peering is a unidirectional service using which Connectivity is always initiated from your WAN to Azure services. Azure services can't initiate connections into your network through this routing domain.
Peering comparison
| Aspect | Public peering | Microsoft peering |
|---|---|---|
| Number of NAT IP addresses | 1 (not scalable) | Per scale*** |
| Call initiation direction | Unidirectional: on-premises to Microsoft | Bidirectional |
| Prefix advertisement | Nonselectable | Advertisement of Microsoft prefixes controlled by route filters |
| Support | No new public peering deployments. Public peering will be retired on March 31, 2024. | Fully supported |
*** BYOIP: you can scale the number of NAT IP addresses assigned depending on your call volume. To get NAT IP addresses, work with your service provider.
Once public peering is enabled, you can connect to all Azure services. We don't allow you to selectively pick services for which we advertise routes to. While Microsoft peering is a bi-directional connectivity where connection can be initiated from Azure service along with your WAN. For more information about routing domains and peering, see ExpressRoute circuits and routing domains.
Before you begin
To connect to Microsoft peering, you need to set up and manage NAT. Your connectivity provider may set up and manage the NAT as a managed service. If you're planning to access the Azure PaaS and Azure SaaS services on Microsoft peering, it's important to size the NAT IP pool correctly. For more information about NAT for ExpressRoute, see the NAT requirements for Microsoft peering. When you connect to Azure through Azure ExpressRoute(Microsoft peering), you have multiple links to Microsoft. One link is your existing Internet connection, and the other is via ExpressRoute. Some traffic to Azure might go through the Internet but come back via ExpressRoute, or vice versa.
Warning
The NAT IP pool advertised to Azure must not be advertised to the Internet. This will break connectivity to other Azure services.
Refer to Asymmetric routing with multiple network paths for caveats of asymmetric routing before configuring Microsoft peering.
- If you're using public peering and currently have IP Network rules for public IP addresses that are used to access Azure Storage or Azure SQL Database, you need to make sure that the NAT IP pool configured with Microsoft peering gets included in the list of public IP addresses for the Azure storage account or the Azure SQL account.
- Legacy Public peering makes use of Source Network Address Translation (SNAT) to a Microsoft-registered public IP, while Microsoft peering doesn't.
- In order to move to Microsoft peering with no downtime, use the steps in this article in the order that they're presented.
1. Create Microsoft peering
If Microsoft peering hasn't been created, use any of the following articles to create Microsoft peering. If your connectivity provider offers managed layer 3 services, you can ask the connectivity provider to enable Microsoft peering for your circuit.
If you manage layer 3, the following information is required before you can proceed:
A /30 subnet for the primary link. The prefix must be a valid public IPv4 prefix owned by you and registered in an RIR / IRR. From this subnet, you assign the first useable IP address to your router as Azure uses the second useable IP for its router.
A /30 subnet for the secondary link. The prefix must be a valid public IPv4 prefix owned by you and registered in an RIR / IRR. From this subnet, you assign the first useable IP address to your router as Azure uses the second useable IP for its router.
A valid VLAN ID to establish this peering on. Ensure that no other peering in the circuit uses the same VLAN ID. For both Primary and Secondary links you must use the same VLAN ID.
AS number for peering. You can use both 2-byte and 4-byte AS numbers.
Advertised prefixes: You must provide a list of all prefixes you plan to advertise over the BGP session. Only Public IP prefixes are accepted. If you plan to send a set of prefixes, you can send a comma-separated list. These prefixes must be registered to you in an RIR / IRR.
Routing Registry Name: You can specify the RIR / IRR against which the AS number and prefixes are registered.
Optional - Customer ASN: If you're advertising prefixes not registered to a peering AS number, you can specify the registered AS number to which t registered.
Optional - An MD5 hash if you choose to use one.
Detailed instructions to enable Microsoft peering can be found in the following articles:
- Create Microsoft peering using Azure portal
- Create Microsoft peering using Azure PowerShell
- Create Microsoft peering using Azure CLI
2. Validate Microsoft peering is enabled
Verify that the Microsoft peering is enabled and the advertised public prefixes are in the configured state.
3. Configure and attach a route filter to the circuit
By default, new Microsoft peering don't advertise any prefixes until a route filter is attached to the circuit. When you create a route filter rule, you can specify the list of service communities for Azure regions that you want to consume for Azure PaaS services. This feature provides you with the flexibility to filter the routes as per your requirement, as shown in the following screenshot:
Note
Public peering advertises all the Azure regions prefixes by default. Whereas, in the Microsoft peering you can select the regions in the route filter associated with Microsoft peering to limit the number of routes advertised to your on-premises network. To get the same routing behavior as Public peering, select all the Azure regions and service prefixes.
Configure route filters using any of the following articles:
- Configure route filters for Microsoft peering using Azure portal
- Configure route filters for Microsoft peering using Azure PowerShell
- Configure route filters for Microsoft peering using Azure CLI
4. Delete the public peering
After verifying Microsoft peering is configured and the prefixes you want to use are correctly advertised through Microsoft peering, you can then delete the public peering. To delete public peering, you can use Azure PowerShell or Azure CLI. For more information, see the following articles:
5. View peerings
You can see a list of all ExpressRoute circuits and peerings in the Azure portal. For more information, see View Microsoft peering details.
Next steps
For more information about ExpressRoute, see the ExpressRoute FAQ.