Muokkaa

Jaa

Create a custom IPv4 address prefix in Azure

  • Artikkeli

In this article, you learn how to create a custom IPv4 address prefix using the Azure portal. You prepare a range to provision, provision the range for IP allocation, and enable the range advertisement by Microsoft.

A custom IPv4 address prefix enables you to bring your own IPv4 ranges to Microsoft and associate it to your Azure subscription. You maintain ownership of the range while Microsoft would be permitted to advertise it to the Internet. A custom IP address prefix functions as a regional resource that represents a contiguous block of customer owned IP addresses.

For this article, choose between the Azure portal, Azure CLI, or PowerShell to create a custom IPv4 address prefix.

Global/Regional vs Unified model

Before onboarding your range to Azure, you need to decide on the model that would work best for your architecture. For BYOIPv4, Azure offers two deployment models: "global/regional" and "unified".

  • The Global/Regional model uses a parent/child paradigm. In this paradigm, the Microsoft Wide Area Network (WAN) advertises the global (parent) range, and the respective Azure regions advertise the regional (child) ranges. By default, global ranges can be anywhere from /21 to /24 in size, and regional ranges can be from /22 to /26 in size. Regional ranges are dependent on the size of their respective parent range, and they must be at least one level smaller. For example, a global range using /23 would allow a regional range of /24 to /26. Only the global range needs to be validated as part of the provisioning. The regional ranges are derived from the global range in a similar manner to the way public IP prefixes are derived from custom IP prefixes.

  • The Unified model is a simplified system where both the Microsoft Wide Area Network (WAN) and the Azure region advertises the same range. By default, a unified range can be anywhere from /21 to /24 in size.

  • The choice of the model is dependent on the scope of the desired onboarding. For example, if your plan only involves onboarding a range to a single Azure region, the unified model is the more logical choice and avoids management overhead. If your organization is instead looking to deploy BYOIPv4 ranges to multiple regions--potentially spread across different teams within the organization and over an extended period of time--then a global/regional model can provide more flexibility.

Note

Ranges cannot be "migrated" between the two models once they are onboarded; they must be fully deprovisioned and re-onboarded to utilize the other model.

Prerequisites

  • An Azure account with an active subscription. Create an account for free.

  • A customer owned IPv4 range to provision in Azure.

    • A sample customer range (1.2.3.0/24) is used for this example. This range isn't validated in Azure so replace the example range with yours.

Note

For problems encountered during the provisioning process, please see Troubleshooting for custom IP prefix.

Pre-provisioning steps

To utilize the Azure BYOIP feature, you must perform the following steps before the provisioning of your IPv4 address range.

Requirements and prefix readiness

  • The address range must be owned by you and registered under your name with the one of the five major Regional Internet Registries:

  • The address range must be no smaller than a /24 for Internet Service Providers to accept.

  • A Route Origin Authorization (ROA) document that authorizes Microsoft to advertise the address range must be completed by the customer on the appropriate Routing Internet Registry (RIR) website or via their API. The RIR requires the ROA to be digitally signed with the Resource Public Key Infrastructure (RPKI) of your RIR.

    For this ROA:

    • The Origin AS must be listed as 8075 for the Public Cloud. (If the range will be onboarded to the US Gov Cloud, the Origin AS must be listed as 8070.)

    • The validity end date (expiration date) needs to account for the time you intend to have the prefix advertised by Microsoft. Some RIRs don't present validity end date as an option and or choose the date for you.

    • The prefix length should exactly match the prefixes that Microsoft advertises. For example, if you plan to bring 1.2.3.0/24 and 2.3.4.0/23 to Microsoft, they should both be named.

    • After the ROA is complete and submitted, allow at least 24 hours for it to become available to Microsoft, where it will be verified to determine its authenticity and correctness as part of the provisioning process.

Note

It is also recommended to create a ROA for any existing ASN that is advertising the range to avoid any issues during migration.

Important

While Microsoft will not stop advertising the range after the specified date, it is strongly recommended to independently create a follow-up ROA if the original expiration date has passed to avoid external carriers from not accepting the advertisement.

Certificate readiness

To authorize Microsoft to associate a prefix with a customer subscription, a public certificate must be compared against a signed message.

The following steps show the steps required to prepare sample customer range (1.2.3.0/24) for provisioning to the Public cloud. You can execute these commands with Windows PowerShell or in a Linux Console. Both require OpenSSL to be installed.

  1. A self-signed X509 certificate must be created to add to the Whois/RDAP record for the prefix. For information about RDAP, see the ARIN, RIPE, APNIC, and AFRINIC sites.

    Utilizing the OpenSSL toolkit, the following commands generate an RSA key pair and create an X509 certificate using the key pair that expires in six months.

    ./openssl genrsa -out byoipprivate.key 2048
Set-Content -Path byoippublickey.cer (./openssl req -new -x509 -key byoipprivate.key -days 180) -NoNewline

  2. After the certificate is created, update the public comments section of the Whois/RDAP record for the prefix. To display for copying, including the BEGIN/END header/footer with dashes, use the command cat byoippublickey.cer You should be able to perform this procedure via your Routing Internet Registry.

    Here are instructions for each registry:

    • ARIN - edit the Comments of the prefix record.

    • RIPE - edit the Remarks of the inetnum record.

    • APNIC - edit the Remarks of the inetnum record using MyAPNIC.

    • AFRINIC - edit the Remarks of the inetnum record using MyAFRINIC.

    • For ranges from LACNIC registry, create a support ticket with Microsoft.

    After the public comments are filled out, the Whois/RDAP record should look like the following example. When copying, ensure there aren't spaces, or carriage returns and include all dashes:

    Screenshot of example certificate comment.

  3. To create the message passed to Microsoft, create a string that contains relevant information about your prefix and subscription. Sign this message with the key pair generated previously. Use the following format, substituting 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 following command to create a signed message passed to Microsoft for verification.

    Note

    If the Validity End date was not included in the original ROA, pick a date that corresponds to the time you intend to have the prefix advertised by Azure.

    $byoipauth="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|1.2.3.0/24|yyyymmdd"
Set-Content -Path byoipauth.txt -Value $byoipauth -NoNewline
./openssl dgst -sha256 -sign byoipprivate.key -keyform PEM -out byoipauthsigned.txt byoipauth.txt
$byoipauthsigned=(./openssl enc -base64 -in byoipauthsigned.txt) -join ''

  4. To view the contents of the signed message, enter the variable created from the signed message created previously and select Enter at the prompt:

    $byoipauthsigned

# Output
ABCDEFG0a1b2c0a1b2c0a1b2c0ca1b2c0a1b2c0a10a/1234567a/ABCDEFG0a1b2c0//ABCDEFG0a1b2c0a1b2c0a1b2c0ca1b2c0a1b2c0a10aABCDEFG0a1b2c0a1b2c0a1b2c0ca1b2c0a1b2c0a10aABCDEFG0a1b2c0a1b2c0a1b2c0ca1b2c0a1b2c0a10aABCDEFG0a1b2c0a1b2c0a1b2c0ca1b2c0a1b2c0a10aABCDEFG0a1b2c0a1b2c0a1b2c0ca1b2c0/ABCDEFG0a1b2c0a1b2c0a1b21212121212/ABCDEFG0a1b2c0a1b2c0a1b2c0ca1b2c0a1b2c0a10a==

Provisioning and Commissioning a Custom IPv4 Prefix

The following steps display the procedure for provisioning and commissioning a custom IPv4 address prefix with a choice of two models: Unified and Global/Regional. The steps can be performed with the Azure portal, Azure CLI, or Azure PowerShell.

Use the Azure portal to provision and commission a custom IPv4 address prefix with the Azure portal.

The following steps display the procedure for provisioning a sample customer range (1.2.3.0/24) to the US West 2 region.

Note

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.

Sign in to Azure

Sign in to the Azure portal.

Create and provision a unified custom IP address prefix

  1. In the search box at the top of the portal, enter Custom IP.

  2. In the search results, select Custom IP Prefixes.

  3. Select + Create.

  4. In Create a custom IP prefix, enter or select the following information:

    Setting Value
    Project details
    Subscription Select your subscription
    Resource group Select Create new.
    Enter myResourceGroup.
    Select OK.
    Instance details
    Name Enter myCustomIPPrefix.
    Region Select West US 2.
    IP Version Select IPv4.
    IPv4 Prefix (CIDR) Enter 1.2.3.0/24.
    ROA expiration date Enter your ROA expiration date in the yyyymmdd format.
    Signed message Paste in the output of $byoipauthsigned from the pre-provisioning section.
    Availability Zones Select Zone-redundant.

    Screenshot of create custom IP prefix page in Azure portal.

  5. Select the Review + create tab or the blue Review + create button at the bottom of the page.

  6. Select Create.

The range is pushed to the Azure IP Deployment Pipeline. The deployment process is asynchronous. You can check the status by reviewing the Commissioned state field for the custom IP prefix.

Note

The estimated time to complete the provisioning process is 30 minutes.

Important

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.

Create a public IP prefix from unified custom IP prefix

When you create a prefix, you must create static IP addresses from the prefix. In this section, you create a static IP address from the prefix you created earlier.

  1. In the search box at the top of the portal, enter Custom IP.

  2. In the search results, select Custom IP Prefixes.

  3. In Custom IP Prefixes, select myCustomIPPrefix.

  4. In Overview of myCustomIPPrefix, select + Add a public IP prefix.

  5. Enter or select the following information in the Basics tab of Create a public IP prefix.

    Setting Value
    Project details
    Subscription Select your subscription.
    Resource group Select myResourceGroup.
    Instance details
    Name Enter myPublicIPPrefix.
    Region Select West US 2. The region of the public IP prefix must match the region of the custom IP prefix.
    IP version Select IPv4.
    Prefix ownership Select Custom prefix.
    Custom IP prefix Select myCustomIPPrefix.
    Prefix size Select a prefix size. The size can be as large as the custom IP prefix.

  6. Select Review + create, and then Create on the following page.

  7. Repeat steps 1-3 to return to the Overview page for myCustomIPPrefix. You see myPublicIPPrefix listed under the Associated public IP prefixes section. You can now allocate standard SKU public IP addresses from this prefix. For more information, see Create a static public IP address from a prefix.

Commission the unified custom IP address prefix

When the custom IP prefix is in Provisioned state, update the prefix to begin the process of advertising the range from Azure.

  1. In the search box at the top of the portal, enter Custom IP and select Custom IP Prefixes.

  2. Verify, and wait if necessary, for myCustomIPPrefix to be is listed in a Provisioned state.

  3. In Custom IP Prefixes, select myCustomIPPrefix.

  4. In Overview of myCustomIPPrefix, select the Commission dropdown menu and choose Globally.

The operation is asynchronous. You can check the status by reviewing the Commissioned state field for the custom IP prefix. Initially, the status will 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.

Note

The estimated time to fully complete the commissioning process is 3-4 hours.

Important

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. To prevent these issues during initial deployment, you can choose the regional only commissioning option where your custom IP prefix will only be advertised within the Azure region it is deployed in. For more information, see Manage a custom IP address prefix (BYOIP).

Next steps