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
The following steps display the procedure for provisioning a sample customer range (1.2.3.0/24) to the US West 2 region.
82
-
83
-
> [!NOTE]
84
-
> Clean up or delete steps aren't shown on this page given the nature of the resource. For information on removing a provisioned custom IP prefix, see [Manage custom IP prefix](../articles/virtual-network/ip-services/manage-public-ip-address-prefix.md).
85
-
86
-
### Create a resource group and specify the prefix and authorization messages
87
-
88
-
Create a resource group in the desired location for provisioning the BYOIP range.
89
-
90
-
```azurepowershell-interactive
91
-
$rg =@{
92
-
Name = 'myResourceGroup'
93
-
Location = 'WestUS2'
94
-
}
95
-
New-AzResourceGroup @rg
96
-
```
97
-
98
-
### Provision a unified custom IP address prefix
99
-
100
-
The following command creates a custom IP prefix in the specified region and resource group. Specify the exact prefix in CIDR notation as a string to ensure there's no syntax error. For the `-AuthorizationMessage` parameter, substitute your subscription ID, prefix to be provisioned, and expiration date matching the Validity Date on the ROA. Ensure the format is in that order. Use the variable **$byoipauthsigned** for the `-SignedMessage` parameter created in the certificate readiness section.
The range is pushed to the Azure IP Deployment Pipeline. The deployment process is asynchronous. To determine the status, execute the following command:
Here's a sample output with some fields removed for clarity:
121
-
122
-
```
123
-
Name : myCustomIpPrefix
124
-
ResourceGroupName : myResourceGroup
125
-
Location : westus2
126
-
Id : /subscriptions/xxxx/resourceGroups/myResourceGroup/providers/Microsoft.Network/customIPPrefixes/MyCustomIPPrefix
127
-
Cidr : 1.2.3.0/24
128
-
Zones : {1, 2, 3}
129
-
CommissionedState : Provisioning
130
-
```
131
-
132
-
The **CommissionedState** field should show the range as **Provisioning** initially, followed in the future by **Provisioned**.
133
-
134
-
> [!NOTE]
135
-
> The estimated time to complete the provisioning process is 30 minutes.
136
-
137
-
> [!IMPORTANT]
138
-
> After the custom IP prefix is in a **Provisioned** state, a child public IP prefix can be created. These public IP prefixes and any public IP addresses can be attached to networking resources. For example, virtual machine network interfaces or load balancer front ends. The IPs won't be advertised and therefore won't be reachable. For more information on a migration of an active prefix, see [Manage a custom IP prefix](../articles/virtual-network/ip-services/manage-public-ip-address-prefix.md).
139
-
140
-
### Commission the unified custom IP address prefix
141
-
142
-
When the custom IP prefix is in the **Provisioned** state, the following command updates the prefix to begin the process of advertising the range from Azure.
As before, the operation is asynchronous. Use [Get-AzCustomIpPrefix](/powershell/module/az.network/get-azcustomipprefix) to retrieve the status. The **CommissionedState** field will initially show the prefix as **Commissioning**, followed in the future by **Commissioned**. The advertisement rollout isn't completed all at once. The range is partially advertised while still in the **Commissioning** status.
149
-
150
-
> [!NOTE]
151
-
> The estimated time to fully complete the commissioning process is 3-4 hours.
152
-
153
-
> [!IMPORTANT]
154
-
> As the custom IP prefix transitions to a **Commissioned** state, the range is being advertised with Microsoft from the local Azure region and globally to the Internet by Microsoft's wide area network under Autonomous System Number (ASN) 8075. Advertising this same range to the Internet from a location other than Microsoft at the same time could potentially create BGP routing instability or traffic loss. For example, a customer on-premises building. Plan any migration of an active range during a maintenance period to avoid impact. Additionally, you could take advantage of the regional commissioning feature to put a custom IP prefix into a state where it is only advertised within the Azure region it is deployed in. For more information, see [Manage a custom IP address prefix (BYOIP)](../articles/virtual-network/ip-services/manage-public-ip-address-prefix.md).
The following steps display the modified steps for provisioning a sample global (parent) IP range (1.2.3.0/4) and regional (child) IP ranges to the US West 2 and US East 2 Regions.
75
+
---
159
76
160
-
> [!NOTE]
161
-
> Clean up or delete steps aren't shown on this page given the nature of the resource. For information on removing a provisioned custom IP prefix, see [Manage custom IP prefix](../articles/virtual-network/ip-services/manage-public-ip-address-prefix.md).
162
-
163
-
### Create a resource group and specify the prefix and authorization messages
164
-
165
-
Create a resource group in the desired location for provisioning the global range resource. Although the global range is associated with a region, the prefix is advertised by the Microsoft WAN to the Internet globally.
166
-
167
-
```azurepowershell-interactive
168
-
$rg =@{
169
-
Name = 'myResourceGroup'
170
-
Location = 'USWest2'
171
-
}
172
-
New-AzResourceGroup @rg
173
-
```
174
-
175
-
### Provision a global custom IP address prefix
176
-
177
-
The following command creates a custom IP prefix in the specified region and resource group. Specify the exact prefix in CIDR notation as a string to ensure there's no syntax error. No zonal properties are provided because the global range isn't associated with any particular region (and therefore no regional availability zones). The global custom IP prefix resource will still sit in a region in your subscription; this has no bearing on how the range is advertised by Microsoft.
After the global custom IP prefix is in a **Provisioned** state, regional custom IP prefixes can be created. These ranges must always be of size /64 to be considered valid. The ranges can be created in any region (it doesn't need to be the same as the global custom IP prefix), keeping in mind any geolocation restrictions associated with the original global range. The *child* custom IP prefixes advertise from the region where they're created. Because the validation is only done for global custom IP prefix provision, no Authorization or Signed message is required (but availability zones can be utilized).
After the regional custom IP prefix is in a **Provisioned** state, public IP prefixes can be derived from the regional custom IP prefix. These public IP prefixes and any public IP addresses derived from them can be attached to networking resources, though they aren't yet being advertised.
214
-
215
-
### Commission the custom IP address prefixes
216
-
217
-
When commissioning custom IP prefixes using this model, the global and regional prefixes are treated separately. In other words, commissioning a regional custom IP prefix isn't connected to commissioning the global custom IP prefix.
218
-
219
-
:::image type="content" source="./media/create-custom-ip-address-prefix-portal/any-region-prefix-v4.png" alt-text="Diagram of custom IPv4 prefix showing parent prefix and child prefixes across multiple regions.":::
220
-
221
-
The safest strategy for range migrations is as follows:
222
-
1. Provision all required regional custom IP prefixes in their respective regions. Create public IP prefixes and public IP addresses and attach to resources.
223
-
2. Commission each regional custom IP prefix and test connectivity to the IPs within the region. Repeat for each regional custom IP prefix.
224
-
3. Commission the global custom IP prefix, which advertises the larger range to the Internet. Complete this step only after verifying all regional custom IP prefixes (and derived prefixes/IPs) work as expected.
225
-
226
-
With the previous example ranges, the command sequence would be:
> The estimated time to fully complete the commissioning process for a custom IP global prefix is 3-4 hours. The estimated time to fully complete the commissioning process for a custom IP regional prefix is 30 minutes.
It's possible to commission the global custom IP prefix before the regional custom IP prefixes. Since this process advertises the global range to the Internet before the regional prefixes are ready, it's not recommended for migrations of active ranges. You can decommission a global custom IP prefix while there are still active (commissioned) regional custom IP prefixes. Also, you can decommission a regional custom IP prefix while the global prefix is still active (commissioned).
> As the global custom IP prefix transitions to a **Commissioned** state, the range is being advertised with Microsoft from the local Azure region and globally to the Internet by Microsoft's wide area network under Autonomous System Number (ASN) 8075. Advertising this same range to the Internet from a location other than Microsoft at the same time could potentially create BGP routing instability or traffic loss. For example, a customer on-premises building. Plan any migration of an active range during a maintenance period to avoid impact.
Copy file name to clipboardExpand all lines: includes/ip-services-provision-ipv4-cli.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -186,5 +186,3 @@ az network custom-ip prefix update \
186
186
It's possible to commission the global custom IP prefix before the regional custom IP prefixes. Doing this advertises the global range to the Internet before the regional prefixes are ready so it's not recommended for migrations of active ranges. You can decommission a global custom IP prefix while there are still active (commissioned) regional custom IP prefixes. Also, you can decommission a regional custom IP prefix while the global prefix is still active (commissioned).
Copy file name to clipboardExpand all lines: includes/ip-services-provision-ipv4-portal.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -255,5 +255,3 @@ To commission a custom IP prefix (regional or global) using the portal:
255
255
It's possible to commission the global custom IP prefix before the regional custom IP prefixes. Doing this advertises the global range to the Internet before the regional prefixes are ready so it's not recommended for migrations of active ranges. You can decommission a global custom IP prefix while there are still active (commissioned) regional custom IP prefixes. Also, you can decommission a regional custom IP prefix while the global prefix is still active (commissioned).
Copy file name to clipboardExpand all lines: includes/ip-services-provision-ipv4-powershell.md
+1-2Lines changed: 1 addition & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -177,5 +177,4 @@ It's possible to commission the global custom IP prefix before the regional cust
177
177
> [!IMPORTANT]
178
178
> As the global custom IP prefix transitions to a **Commissioned** state, the range is being advertised with Microsoft from the local Azure region and globally to the Internet by Microsoft's wide area network under Autonomous System Number (ASN) 8075. Advertising this same range to the Internet from a location other than Microsoft at the same time could potentially create BGP routing instability or traffic loss. For example, a customer on-premises building. Plan any migration of an active range during a maintenance period to avoid impact.
0 commit comments