Troubleshooting Lab: Plan and implement a custom public IP address prefix (bring your own IP)
Diagnostic Scenarios
Scenario 1 — Root Cause
An infrastructure team completed the onboarding process for their own /24 block in Azure. The ROA was correctly created in the RIR pointing to ASN 8075, the authorization file was generated and validated, and the CustomIPPrefix resource was successfully provisioned in the East US region.
Two days after creation, the team attempts to allocate a PublicIPPrefix derived from the custom prefix for use with a Standard Load Balancer. The operation fails.
The engineer executes the following command and gets the output below:
az network custom-ip-prefix show \
--name myCustomPrefix \
--resource-group rg-networking \
--query "{provisioning:provisioningState, commissioned:commissionedState}" \
--output json
{
"provisioning": "Succeeded",
"commissioned": "Provisioning"
}
The team also observes that the prefix doesn't appear as announced in external BGP looking glass tools. The Azure subscription is active and without quota alerts. The security team confirmed that there are no active blocking policies on the subscription.
What is the root cause of the failure when trying to allocate the derived prefix?
A) The subscription's public IP addresses quota was reached, preventing the allocation of new derived resources
B) The CustomIPPrefix resource has not yet completed commissioning, therefore it's not available for derived prefix allocation
C) The ROA was created with the incorrect ASN, causing Azure to silently reject the prefix during the provisioning phase
D) The derived PublicIPPrefix must be created in the same provisioning step as the CustomIPPrefix, and cannot be added later
Scenario 2 — Action Decision
A company's network team identified that the custom public IP prefix 203.0.113.0/24, already in Commissioned state and with derived addresses in use by multiple production resources, is being incorrectly announced to a different region than intended.
The cause was identified: the resource was originally created in the West Europe region by mistake, while the resources consuming the derived IPs are in Brazil South. The company needs to migrate the prefix to the correct region.
The environment has the following constraints:
- The derived IPs are associated with Load Balancers with active external client traffic
- The nearest available maintenance window is in 72 hours
- The company doesn't have alternative IPs for temporary replacement
- Any traffic interruption exceeding 5 minutes generates contractual penalty
What is the correct action to take at this moment?
A) Immediately start decommissioning the current prefix, recreate the resource in Brazil South and re-announce the block in the new region
B) Create a new CustomIPPrefix in Brazil South with the same CIDR block in parallel, without changing the current environment yet
C) Wait for the maintenance window and plan the migration with prior disassociation of derived IPs from Load Balancers before decommissioning
D) Open a support request to Microsoft to perform the regional migration of the resource without downtime, as this operation is not feasible for the customer
Scenario 3 — Root Cause
A company completed all documented BYOIP onboarding steps in Azure, including ROA creation, ownership validation via signed file, and prefix commissioning. The CommissionedState is Commissioned.
However, when checking external BGP tools, the 198.51.100.0/24 block appears announced, but with a different origin ASN than expected. Internally, derived addresses work correctly for incoming traffic. The team rules out connectivity issues and focuses on the announcement.
The engineer checks the change history in the RIR and finds the following record:
ROA Object — 198.51.100.0/24
Origin ASN : 65001
Max Length : 24
Valid Until : 2026-12-31
Status : Valid
The organization has two registered ASNs: 65001 (internal private routing use) and 8075 (Azure). The authorization file submitted to Azure during onboarding was digitally signed with the key associated with the block in the RIR.
What is the root cause of the observed behavior?
A) The authorization file was generated with the wrong key, invalidating the prefix ownership before Azure
B) The ROA was configured with the organization's internal use ASN instead of Azure's ASN, and Azure announces with its own ASN regardless of the ROA
C) Azure was not authorized by the ROA to originate the announcement of the block with ASN 8075, therefore the prefix is being announced by another BGP peer of the organization
D) The ROA's MaxLength is configured as /24, which prevents subdivisions and forces Azure to announce the block in aggregate form with incorrect ASN
Scenario 4 — Diagnostic Sequence
An engineer receives the following report: "We created the custom IP prefix, but the addresses don't appear as available for association with any resource."
The engineer has access to the Azure portal, CLI, and external BGP tools. They need to establish the correct investigation sequence before proposing any corrective action.
The available steps are:
- Check the
CommissionedStateof theCustomIPPrefixvia CLI or portal - Confirm if there are
PublicIPPrefixorPublicIPAddressderived resources created from the custom prefix - Check external BGP tools if the block is being announced
- Confirm the
ProvisioningStateof theCustomIPPrefixresource - Try manually associating a derived IP to a test resource to capture the exact error message
What is the correct diagnostic sequence?
A) 4 -> 1 -> 2 -> 3 -> 5
B) 3 -> 4 -> 1 -> 5 -> 2
C) 1 -> 4 -> 3 -> 2 -> 5
D) 5 -> 2 -> 1 -> 4 -> 3
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the commissionedState: Provisioning field. The lifecycle of a CustomIPPrefix in Azure has two independent phases: the provisioning of the resource in the control plane (reflected in ProvisioningState) and the commissioning, which represents the actualization of the BGP announcement and making the block available for allocation. While the CommissionedState doesn't reach Commissioned, no derived prefix or address can be created from the custom prefix, regardless of provisioning success.
The information about quota and blocking policies is purposefully irrelevant: the statement includes it to simulate real diagnostic pressure, where the team checks multiple hypotheses. The absence of quota alerts doesn't change the fact that the cause lies in the commissioning cycle.
Distractor C is the most dangerous: an incorrect ASN ROA would cause BGP announcement failure, but wouldn't prevent provisioning nor generate the ongoing Commissioning state. Distractor D is technically false: derived resources can be created at any time after commissioning, without temporal dependency with the parent prefix creation.
Answer Key — Scenario 2
Answer: C
The critical constraint of the scenario is the combination of active traffic with contractual penalty for downtime exceeding 5 minutes and the absence of alternative IPs. Any action involving immediate decommissioning would interrupt traffic before the maintenance window, violating the contractual restriction.
Alternative B seems attractive, but is technically unfeasible: it's not possible to create two CustomIPPrefix with the same CIDR block in different regions within the same subscription simultaneously. Azure rejects duplicate prefixes.
Alternative A represents the correct migration sequence, but applied at the wrong time: executing it outside the maintenance window without alternative IPs would cause immediate downtime. Alternative D is incorrect because regional migration of custom IP prefix requires decommissioning and recreation, and this process is not abstracted by Microsoft via support without downtime.
The correct action is to wait for the maintenance window and execute the migration in a planned manner, with prior disassociation of resources during the period of least impact.
Answer Key — Scenario 3
Answer: C
The ROA record explicitly shows Origin ASN: 65001, which is the organization's internal use ASN, not Azure's ASN (8075). The ROA is the authorization mechanism that defines which ASN has permission to originate the announcement of a specific address block on the internet. Since Azure operates with ASN 8075, and the ROA doesn't authorize this ASN as origin, the block is being announced by another equipment or BGP peer of the organization itself that uses ASN 65001.
The information about the correctly signed authorization file is irrelevant to external BGP behavior: the file validates ownership before Azure at onboarding time, but doesn't replace the ROA as the announcement control mechanism on the public internet.
Distractor B contains a subtle and dangerous technical error: Azure doesn't announce with its own ASN regardless of the ROA. The ROA is exactly what determines who can announce. Acting based on distractor B would lead the engineer to ignore the real problem in the RIR and seek non-existent causes on Azure's side.
Answer Key — Scenario 4
Answer: A
The correct sequence follows diagnostic logic from general to specific, validating the resource state before investigating external behaviors or attempting corrective actions:
- Step 4 (ProvisioningState): confirms if the resource exists and was successfully created in the control plane. This is the prerequisite for all other verifications.
- Step 1 (CommissionedState): determines if the prefix is available for allocation. This is the most common failure point for the described symptom.
- Step 2 (derived resources): verifies if derived IPs were actually created, since custom prefix addresses don't appear for direct association without the derivation layer.
- Step 3 (external BGP): validates if the block is being announced, correlating internal state with external visibility.
- Step 5 (controlled attempt): captures the exact error message, which guides the final correction step.
Sequence D (starting with association attempt) is the most common error under pressure: acts before diagnosing and generates an error message that can be misinterpreted without the context of the resource state.
Troubleshooting Tree: Plan and implement a custom public IP address prefix (bring your own IP)
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start at the root node describing the observed symptom and answer each diagnostic question based on what can be directly verified in the Azure portal or via CLI. Follow the path corresponding to your answer until reaching an identified cause node (red) or recommended action (green). Orange nodes indicate that additional verification is needed before acting. The complete path rarely requires more than four questions to isolate the cause in typical BYOIP scenarios.