Laboratório de Troubleshooting: Plan and implement a custom public IP address prefix (bring your own IP)
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de infraestrutura concluiu o processo de onboarding de um bloco /24 próprio no Azure. O ROA foi criado corretamente no RIR apontando para o ASN 8075, o arquivo de autorização foi gerado e validado, e o recurso CustomIPPrefix foi provisionado com sucesso na região East US.
Dois dias após a criação, o time tenta alocar um PublicIPPrefix derivado a partir do custom prefix para uso em um Load Balancer Standard. A operação falha.
O engenheiro executa o seguinte comando e obtém a saída abaixo:
az network custom-ip-prefix show \
--name myCustomPrefix \
--resource-group rg-networking \
--query "{provisioning:provisioningState, commissioned:commissionedState}" \
--output json
{
"provisioning": "Succeeded",
"commissioned": "Provisioning"
}
O time observa também que o prefixo não aparece como anunciado em ferramentas externas de looking glass BGP. A assinatura do Azure está ativa e sem alertas de quota. O time de segurança confirmou que não há políticas de bloqueio ativas na subscription.
Qual é a causa raiz da falha ao tentar alocar o prefixo derivado?
A) A quota de public IP addresses da subscription foi atingida, impedindo a alocação de novos recursos derivados
B) O recurso CustomIPPrefix ainda não concluiu o comissionamento, portanto não está disponível para alocação de prefixos derivados
C) O ROA foi criado com o ASN incorreto, fazendo com que o Azure rejeite silenciosamente o prefixo durante a fase de provisionamento
D) O PublicIPPrefix derivado deve ser criado na mesma etapa de provisionamento do CustomIPPrefix, e não pode ser adicionado posteriormente
Cenário 2 — Decisão de Ação
A equipe de redes de uma empresa identificou que o custom public IP prefix 203.0.113.0/24, já em estado Commissioned e com endereços derivados em uso por múltiplos recursos em produção, está sendo anunciado incorretamente para uma região diferente da pretendida.
A causa foi identificada: o recurso foi criado originalmente na região West Europe por engano, enquanto os recursos que consomem os IPs derivados estão em Brazil South. A empresa precisa migrar o prefixo para a região correta.
O ambiente tem as seguintes restrições:
- Os IPs derivados estão associados a Load Balancers com tráfego ativo de clientes externos
- A janela de manutenção mais próxima disponível é em 72 horas
- A empresa não possui IPs alternativos para substituição temporária
- Qualquer interrupção de tráfego superior a 5 minutos gera penalidade contratual
Qual é a ação correta a tomar neste momento?
A) Iniciar imediatamente o descomissionamento do prefixo atual, recriar o recurso em Brazil South e reanunciar o bloco na nova região
B) Criar um novo CustomIPPrefix em Brazil South com o mesmo bloco CIDR em paralelo, sem alterar o ambiente atual ainda
C) Aguardar a janela de manutenção e planejar a migração com desassociação prévia dos IPs derivados dos Load Balancers antes de descomissionar
D) Abrir uma solicitação de suporte à Microsoft para realizar a migração regional do recurso sem downtime, pois essa operação não é realizável pelo cliente
Cenário 3 — Causa Raiz
Uma empresa concluiu todos os passos documentados de onboarding de BYOIP no Azure, incluindo a criação do ROA, a validação de posse via arquivo assinado e o comissionamento do prefixo. O CommissionedState está como Commissioned.
No entanto, ao verificar em ferramentas externas de BGP, o bloco 198.51.100.0/24 aparece anunciado, mas com o ASN de origem diferente do esperado. Internamente, os endereços derivados funcionam corretamente para tráfego de entrada. A equipe descarta problemas de conectividade e foca na anunciação.
O engenheiro verifica o histórico de alterações no RIR e encontra o seguinte registro:
ROA Object — 198.51.100.0/24
Origin ASN : 65001
Max Length : 24
Valid Until : 2026-12-31
Status : Valid
A organização tem dois ASNs registrados: 65001 (uso interno de roteamento privado) e 8075 (Azure). O arquivo de autorização submetido ao Azure durante o onboarding foi assinado digitalmente com a chave associada ao bloco no RIR.
Qual é a causa raiz do comportamento observado?
A) O arquivo de autorização foi gerado com a chave errada, invalidando a posse do prefixo perante o Azure
B) O ROA foi configurado com o ASN de uso interno da organização em vez do ASN do Azure, e o Azure anuncia com seu próprio ASN independentemente do ROA
C) O Azure não foi autorizado pelo ROA a originar o anúncio do bloco com o ASN 8075, portanto o prefixo está sendo anunciado por outro peer BGP da organização
D) O MaxLength do ROA está configurado como /24, o que impede subdivisões e força o Azure a anunciar o bloco de forma agregada com ASN incorreto
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "Criamos o custom IP prefix, mas os endereços não aparecem como disponíveis para associação em nenhum recurso."
O engenheiro tem acesso ao portal do Azure, ao CLI e a ferramentas externas de BGP. Ele precisa estabelecer a sequência correta de investigação antes de propor qualquer ação corretiva.
Os passos disponíveis são:
- Verificar o
CommissionedStatedoCustomIPPrefixvia CLI ou portal - Confirmar se existem
PublicIPPrefixouPublicIPAddressderivados criados a partir do custom prefix - Verificar em ferramentas externas de BGP se o bloco está sendo anunciado
- Confirmar o
ProvisioningStatedo recursoCustomIPPrefix - Tentar associar manualmente um IP derivado a um recurso de teste para capturar a mensagem de erro exata
Qual é a sequência correta de diagnóstico?
A) 4 -> 1 -> 2 -> 3 -> 5
B) 3 -> 4 -> 1 -> 5 -> 2
C) 1 -> 4 -> 3 -> 2 -> 5
D) 5 -> 2 -> 1 -> 4 -> 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no campo commissionedState: Provisioning. O ciclo de vida de um CustomIPPrefix no Azure tem duas fases independentes: o provisionamento do recurso no plano de controle (refletido em ProvisioningState) e o comissionamento, que representa a efetivação do anúncio BGP e a disponibilização do bloco para alocação. Enquanto o CommissionedState não atingir Commissioned, nenhum prefixo ou endereço derivado pode ser criado a partir do custom prefix, independentemente do sucesso do provisionamento.
A informação sobre quota e políticas de bloqueio é propositalmente irrelevante: o enunciado a inclui para simular a pressão diagnóstica real, onde o time verifica múltiplas hipóteses. A ausência de alertas de quota não muda o fato de que a causa está no ciclo de comissionamento.
O distrator C é o mais perigoso: um ROA com ASN incorreto causaria falha de anúncio BGP, mas não impediria o provisionamento nem geraria o estado Commissioning em curso. O distrator D é tecnicamente falso: recursos derivados podem ser criados em qualquer momento após o comissionamento, sem dependência temporal com a criação do prefixo pai.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é a combinação entre tráfego ativo com penalidade contratual por downtime superior a 5 minutos e a ausência de IPs alternativos. Qualquer ação que envolva descomissionamento imediato interromperia o tráfego antes da janela de manutenção, violando a restrição contratual.
A alternativa B parece atraente, mas é tecnicamente inviável: não é possível criar dois CustomIPPrefix com o mesmo bloco CIDR em regiões diferentes na mesma assinatura simultaneamente. O Azure rejeita prefixos duplicados.
A alternativa A representa a sequência correta de migração, mas aplicada no momento errado: executá-la fora da janela de manutenção sem IPs alternativos causaria downtime imediato. A alternativa D é incorreta porque a migração regional de custom IP prefix exige descomissionamento e recriação, e esse processo não é abstraído pela Microsoft via suporte sem downtime.
A ação correta é aguardar a janela de manutenção e executar a migração de forma planejada, com desassociação prévia dos recursos durante o período de menor impacto.
Gabarito — Cenário 3
Resposta: C
O registro do ROA mostra explicitamente Origin ASN: 65001, que é o ASN de uso interno da organização, não o ASN do Azure (8075). O ROA é o mecanismo de autorização que define qual ASN tem permissão para originar o anúncio de um determinado bloco de endereços na internet. Como o Azure opera com o ASN 8075, e o ROA não autoriza esse ASN como origem, o bloco está sendo anunciado por outro equipamento ou peer BGP da própria organização que usa o ASN 65001.
A informação sobre o arquivo de autorização assinado corretamente é irrelevante para o comportamento BGP externo: o arquivo valida a posse perante o Azure no momento do onboarding, mas não substitui o ROA como mecanismo de controle do anúncio na internet pública.
O distrator B contém um erro técnico sutil e perigoso: o Azure não anuncia com ASN próprio independentemente do ROA. O ROA é exatamente o que determina quem pode anunciar. Agir com base no distrator B levaria o engenheiro a ignorar o problema real no RIR e buscar causas inexistentes no lado do Azure.
Gabarito — Cenário 4
Resposta: A
A sequência correta segue a lógica de diagnóstico do geral para o específico, validando o estado do recurso antes de investigar comportamentos externos ou tentar ações corretivas:
- Passo 4 (ProvisioningState): confirma se o recurso existe e foi criado com sucesso no plano de controle. É o pré-requisito de todas as demais verificações.
- Passo 1 (CommissionedState): determina se o prefixo está disponível para alocação. Este é o ponto de falha mais comum para o sintoma descrito.
- Passo 2 (recursos derivados): verifica se os IPs derivados foram de fato criados, pois endereços do custom prefix não aparecem para associação direta sem a camada de derivação.
- Passo 3 (BGP externo): valida se o bloco está sendo anunciado, correlacionando o estado interno com a visibilidade externa.
- Passo 5 (tentativa controlada): captura a mensagem de erro exata, que orienta o passo final de correção.
A sequência D (começando pela tentativa de associação) é o erro mais comum sob pressão: age antes de diagnosticar e gera uma mensagem de erro que pode ser mal interpretada sem o contexto do estado do recurso.
Árvore de Troubleshooting: Plan and implement a custom public IP address prefix (bring your own IP)
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e responda cada pergunta de diagnóstico com base no que for verificável diretamente no portal do Azure ou via CLI. Siga o caminho correspondente à sua resposta até alcançar um nó de causa identificada (vermelho) ou ação recomendada (verde). Nós laranja indicam que uma verificação adicional é necessária antes de agir. O percurso completo raramente exige mais de quatro perguntas para isolar a causa em cenários típicos de BYOIP.