Skip to content

Commit 9002a7f

Browse files
authored
Merge pull request #303460 from duongau/prefixvalid
ExpressRoute - Microsoft Peering (prefix validation updates)
2 parents f2c494d + e09224a commit 9002a7f

File tree

2 files changed

+46
-7
lines changed

2 files changed

+46
-7
lines changed

articles/expressroute/expressroute-howto-routing-portal-resource-manager.md

Lines changed: 46 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ services: expressroute
55
author: duongau
66
ms.service: azure-expressroute
77
ms.topic: how-to
8-
ms.date: 02/11/2025
8+
ms.date: 07/23/2025
99
ms.author: duau
1010
---
1111

@@ -46,7 +46,6 @@ This section helps you create, get, update, and delete the Microsoft peering con
4646
> [!IMPORTANT]
4747
> Microsoft peering of ExpressRoute circuits that were configured prior to August 1, 2017 will have all Microsoft Office service prefixes advertised through the Microsoft peering, even if route filters are not defined. Microsoft peering of ExpressRoute circuits that are configured on or after August 1, 2017 will not have any prefixes advertised until a route filter is attached to the circuit. For more information, see [Configure a route filter for Microsoft peering](how-to-routefilter-powershell.md).
4848
>
49-
>
5049
5150
### To create Microsoft peering
5251

@@ -74,6 +73,10 @@ This section helps you create, get, update, and delete the Microsoft peering con
7473
* 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.
7574
* AS number for peering. You can use both 2-byte and 4-byte AS numbers.
7675
* Advertised prefixes: You provide a list of all prefixes you plan to advertise over the BGP session. Only public IP address 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.
76+
77+
> [!NOTE]
78+
> For each configured prefix, Microsoft generates a **Validation ID**. The organization that owns the prefixes will use this ID to verify their authority to advertise the prefixes. Detailed verification steps are provided in the next section.
79+
7780
* **Optional -** Customer ASN: If you're advertising prefixes not registered to the peering AS number, you can specify the AS number to which they're registered with.
7881
* Routing Registry Name: You can specify the RIR / IRR against which the AS number and prefixes are registered.
7982
* **Optional -** An MD5 hash if you choose to use one.
@@ -84,13 +87,49 @@ This section helps you create, get, update, and delete the Microsoft peering con
8487

8588
:::image type="content" source="./media/expressroute-howto-routing-portal-resource-manager/configuration-m-validation-needed.png" alt-text="Screenshot showing Microsoft peering configuration.":::
8689

90+
### To validate the advertised public prefixes (Preview)
91+
When you configure public IP address prefixes to advertise over BGP, Microsoft verifies your authority to announce those prefixes. The IP addresses may be owned by your organization or leased from a third party with permission to use and advertise them. Verification is performed by checking a signed digital certificate associated with each prefix against the relevant RIR or IRR records.
92+
93+
### Prerequisites
94+
95+
1. The organization that owns the prefixes must generate a self-signed certificate using a secure private key. You can use OpenSSL to create this certificate. The certificate should be included in the comments section of the relevant RIR / IRR associated with the IP range.
96+
97+
```bash
98+
# Generate a private key using openssl:
99+
100+
openssl.exe genpkey -algorithm rsa -out privkey.pem -pkeyopt rsa_keygen_bits:4096
101+
102+
# Generate the corresponding public key:
103+
104+
openssl rsa -in privkey.pem -outform PEM -pubout -out pubkey.pem
105+
106+
# Generate a Certificate Signing Request (CSR):
107+
108+
openssl req -new -key privkey.pem -out request.csr
109+
110+
# Generate a self signed public certificate:
111+
112+
openssl x509 -req -days 365 -in request.csr -signkey privkey.pem -out certificate.crt
113+
```
114+
87115
> [!IMPORTANT]
88-
> Microsoft verifies if the specified 'Advertised public prefixes' and 'Peer ASN' (or 'Customer ASN') are assigned to you in the Internet Routing Registry. If you are getting the public prefixes from another entity and if the assignment is not recorded with the routing registry, the automatic validation will not complete and will require manual validation. If the automatic validation fails, you will see the message 'Validation needed'.
89-
>
90-
> If you see the message 'Validation needed', collect the document(s) that show the public prefixes are assigned to your organization by the entity that is listed as the owner of the prefixes in the routing registry and submit these documents for manual validation by opening a support ticket.
91-
>
116+
> Microsoft will never request your private key for any verification purposes, and it must never be shared.
117+
118+
2. The certificate must include:
119+
* Organization name
120+
* ASN
121+
* IP Range
122+
123+
### Authorize the prefix
124+
125+
1. Use your private key and the *Validation ID* to generate a Base64-encoded signature for each prefix listed under Advertised Prefixes. Save the Validation ID to a file using UTF-8 encoding, ensuring there are no spaces or special characters.
126+
127+
:::image type="content" source="./media/expressroute-howto-routing-portal-resource-manager/validation-id.png" alt-text="Screenshot showing the Validation ID field in the Azure portal for ExpressRoute Microsoft peering.":::
128+
129+
2. Upload the generated signature to the Azure portal and save your configuration.
92130

93-
If your circuit gets to a **Validation needed** state, you must open a support ticket to show proof of ownership of the prefixes to our support team. You can open a support ticket directly from the portal.
131+
> [!NOTE]
132+
> If automatic validation fails, indicated by a **Validation needed** message, gather documentation proving your organization’s ownership of the public prefixes as registered in the routing registry. Submit these documents by opening a support ticket for manual validation.
94133

95134
### <a name="getmsft"></a>To view Microsoft peering details
96135

75.4 KB
Loading

0 commit comments

Comments
 (0)