You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/expressroute/expressroute-howto-routing-portal-resource-manager.md
+31-18Lines changed: 31 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,6 @@ This section helps you create, get, update, and delete the Microsoft peering con
46
46
> [!IMPORTANT]
47
47
> 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).
48
48
>
49
-
>
50
49
51
50
### To create Microsoft peering
52
51
@@ -74,8 +73,10 @@ This section helps you create, get, update, and delete the Microsoft peering con
74
73
* 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.
75
74
* AS number for peering. You can use both 2-byte and 4-byte AS numbers.
76
75
* 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
77
> [!NOTE]
78
-
> Microsoft creates a "Validation ID" for each configured prefix, which requires verification by the organization that owns the prefixes. The specific steps are provided in the following section.
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
+
79
80
***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.
80
81
* Routing Registry Name: You can specify the RIR / IRR against which the AS number and prefixes are registered.
81
82
***Optional -** An MD5 hash if you choose to use one.
@@ -86,37 +87,49 @@ This section helps you create, get, update, and delete the Microsoft peering con
86
87
87
88
:::image type="content" source="./media/expressroute-howto-routing-portal-resource-manager/configuration-m-validation-needed.png" alt-text="Screenshot showing Microsoft peering configuration.":::
88
89
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.
89
92
90
-
### To validate the Advertised public prefixes (Preview)
93
+
### Prerequisites
91
94
92
-
When you configure Public IP address that you plan to advertise over BGP, Microsoft will verify the authority to advertise those prefixes. These IP addresses can be either owned by your organization or leased from a third party with permission to use and announce those prefixes. The prefixes are verified with the RIR / IRR by validating a signed digital certificate associated with each prefix configured.
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.
1. The organization that owns the prefixes is required to have a self-signed certificate using a secure private key. This certificate should be included in the comments section of the relevant RIR / IRR associated with the IP range.
97
115
> [!IMPORTANT]
98
-
> Microsoft will never request your private key for any verification purposes, and it must never be shared.
116
+
> Microsoft will never request your private key for any verification purposes, and it must never be shared.
99
117
100
-
2. The Certificate must include:
118
+
2. The certificate must include:
101
119
* Organization name
102
120
* ASN
103
121
* IP Range
104
122
105
123
### Authorize the prefix
106
124
107
-
1. Use the Validation ID and your private key to generate a signature for each prefix listed under Advertised Prefixes.
108
-
> [!IMPORTANT]
109
-
> Save the Validation ID to a file using **UTF-8 encoding**, with no spaces or special characters.
110
-
> The generated signature must be in **Base64 format**.
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.
111
126
112
-
2. Upload the signature to the Microsoft portal and save the configuration.
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.":::
113
128
129
+
2. Upload the generated signature to the Azure portal and save your configuration.
114
130
115
-
> [!IMPORTANT]
116
-
> If automatic validation fails, you will see the message "Validation needed", and the process will require manual validation.
117
-
> > Collect documents that prove the public prefixes are assigned to your organization by the entity listed as the owner in the routing registry.
118
-
> > Submit these documents by opening a support ticket for manual validation.
119
-
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.
120
133
121
134
### <a name="getmsft"></a>To view Microsoft peering details
0 commit comments