Pular para o conteúdo principal

Laboratório de Troubleshooting: Create a prefix for public IP addresses

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Uma equipe de operações mantém um ambiente de produção na região West Europe com um prefixo de IP público /28 SKU Standard criado há seis meses. O ambiente possui 14 máquinas virtuais, cada uma com um IP público derivado desse prefixo. Hoje, ao tentar provisionar a 15ª máquina virtual com um novo IP público derivado do mesmo prefixo, a operação falha com a seguinte saída:

az network public-ip create \
  --name vm15-pip \
  --resource-group rg-prod-we \
  --allocation-method Static \
  --sku Standard \
  --public-ip-prefix /subscriptions/.../publicIPPrefixes/prefixo-prod \
  --location westeurope

ERROR: (PublicIPPrefixExhausted) The public IP prefix
'/subscriptions/.../publicIPPrefixes/prefixo-prod' has no available
IP addresses. The prefix is exhausted.

Informações adicionais coletadas pela equipe:

  • A assinatura possui limite de 100 IPs públicos e apenas 22 estão em uso no total
  • A região West Europe está sem alertas de capacidade no Azure Service Health
  • O grupo de recursos rg-prod-we tem política de bloqueio de exclusão ativa
  • Duas das 14 VMs foram desligadas (deallocated) ontem, mas seus IPs públicos permanecem associados às NICs

Qual é a causa raiz da falha?

A) O limite de IPs públicos da assinatura foi atingido e nenhum novo IP pode ser criado

B) O prefixo /28 possui 16 endereços, e com 14 endereços alocados ainda haveria espaço, portanto a política de bloqueio do grupo de recursos está impedindo a criação

C) O prefixo /28 possui exatamente 16 endereços, todos já alocados como IPs públicos individuais, incluindo os IPs das VMs desligadas que permanecem reservados

D) O estado deallocated das duas VMs corrompeu o estado interno do prefixo, bloqueando novas alocações

Cenário 2 — Decisão de Ação​

A equipe de rede identificou que um prefixo de IP público IPv4 com comprimento /28 criado na região Brazil South precisa ser migrado para a região East US 2, pois toda a infraestrutura do cliente está sendo relocada. A causa do problema operacional é clara: os IPs públicos derivados do prefixo atual são específicos da região Brazil South e não podem ser usados pelos recursos na nova região.

A migração deve ocorrer durante uma janela de manutenção de 30 minutos, em produção, com os seguintes fatos conhecidos:

  • Seis aplicações dependem dos IPs derivados do prefixo atual para regras de firewall de parceiros
  • Os parceiros foram notificados e aceitaram atualizar as regras em até 72 horas após a migração
  • O prefixo original não pode ser excluído enquanto houver IPs derivados associados a recursos
  • Já existe um novo prefixo /28 criado na região East US 2 com 16 endereços disponíveis

Qual é a ação correta a tomar durante a janela de manutenção?

A) Excluir o prefixo antigo em Brazil South imediatamente e associar os recursos ao novo prefixo em East US 2

B) Desassociar os IPs derivados do prefixo antigo dos recursos, associar os novos IPs do prefixo em East US 2 e comunicar os novos endereços aos parceiros dentro do prazo acordado

C) Manter ambos os prefixos ativos simultaneamente e configurar roteamento de tráfego entre regiões até que todos os parceiros atualizem suas regras

D) Solicitar ao suporte da Microsoft a transferência do bloco CIDR do prefixo de Brazil South para East US 2, preservando os mesmos endereços IP

Cenário 3 — Causa Raiz​

Um engenheiro executa o seguinte comando para criar um prefixo de IP público:

az network public-ip prefix create \
  --name prefixo-dmz \
  --resource-group rg-dmz \
  --location eastus \
  --length 30 \
  --version IPv4 \
  --zone 1 2 3

O comando retorna sucesso. Em seguida, o engenheiro tenta criar um IP público derivado desse prefixo e associá-lo a uma NIC de SKU Basic:

az network public-ip create \
  --name pip-dmz-01 \
  --resource-group rg-dmz \
  --allocation-method Static \
  --sku Basic \
  --public-ip-prefix /subscriptions/.../publicIPPrefixes/prefixo-dmz \
  --location eastus

ERROR: (InvalidParameter) Public IP address SKU must be Standard
when created from a public IP prefix.

O engenheiro reporta que o prefixo foi criado com sucesso e que a NIC-alvo estava disponível e sem associações anteriores. A equipe suspeita que o erro está relacionado às zonas de disponibilidade configuradas no prefixo.

Qual é a causa raiz do erro observado?

A) Prefixos com zonas de disponibilidade configuradas não permitem derivar IPs públicos via CLI; a operação deve ser feita pelo portal do Azure

B) O comprimento /30 é incompatível com configurações de zona de disponibilidade, invalidando o prefixo após a criação

C) IPs públicos derivados de um prefixo de IP público devem obrigatoriamente ter SKU Standard; a tentativa de criar um IP com SKU Basic viola essa restrição

D) As zonas de disponibilidade 1 2 3 configuram o prefixo como zone-redundant, e IPs derivados de prefixos zone-redundant não podem ser associados a NICs diretamente

Cenário 4 — Sequência de Diagnóstico​

Um administrador recebe o seguinte relato: "Criamos um prefixo de IP público há uma semana e hoje, ao tentar excluí-lo, a operação falha sem mensagem de erro clara no portal."

O administrador dispõe dos seguintes passos de investigação, apresentados fora de ordem:

  1. Verificar se existem IPs públicos individuais associados a recursos ativos que foram derivados do prefixo
  2. Tentar excluir o prefixo novamente após confirmar que nenhum IP derivado está em uso
  3. Listar todos os IPs públicos da assinatura e filtrar pelo campo publicIPPrefix para identificar dependências
  4. Verificar se o grupo de recursos possui bloqueio de exclusão ativo no nível do recurso de prefixo
  5. Desassociar ou excluir cada IP público derivado que ainda estiver vinculado a um recurso

Qual é a sequência correta de diagnóstico?

A) 4 → 1 → 3 → 5 → 2

B) 1 → 3 → 4 → 5 → 2

C) 3 → 1 → 5 → 4 → 2

D) 4 → 3 → 1 → 5 → 2

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: C

A pista decisiva está na matemática do prefixo combinada com o estado dos IPs. Um prefixo /28 contém exatamente 2⁴ = 16 endereços. Com 14 VMs ativas e 2 VMs desligadas, há 16 IPs derivados no total, todos ainda associados a NICs. O estado deallocated de uma VM no Azure não libera automaticamente o IP público vinculado à NIC; o IP permanece reservado e alocado enquanto a associação existir. Portanto, o prefixo está genuinamente esgotado.

A informação sobre o limite de assinatura (100 IPs, 22 em uso) é deliberadamente irrelevante: o problema não é de cota da assinatura, mas de esgotamento do bloco do prefixo específico. A política de bloqueio do grupo de recursos impede exclusões, não criações, tornando a alternativa B incoerente.

A alternativa D representa o erro mais perigoso: atribuir o problema a uma corrupção de estado levaria a abrir um chamado de suporte desnecessário, atrasando a solução real, que é simplesmente desassociar IPs das VMs desligadas ou criar um segundo prefixo.

Gabarito — Cenário 2​

Resposta: B

A restrição crítica do cenário é a ordem de operações: o prefixo original não pode ser excluído enquanto houver IPs derivados associados. Isso elimina a alternativa A imediatamente, pois a tentativa de exclusão direta falharia antes de qualquer progresso.

A alternativa D descreve uma operação impossível: blocos CIDR de prefixos de IP público são específicos de região e não podem ser transferidos entre regiões pela Microsoft; os endereços IP de regiões distintas pertencem a intervalos de roteamento diferentes.

A alternativa C é tecnicamente inviável em termos práticos: prefixos de regiões distintas não estabelecem roteamento automático entre si, e a janela de 30 minutos não comporta essa abordagem.

A alternativa B é a única que respeita todas as restrições: desassociação dos IPs antigos para viabilizar a futura exclusão do prefixo, associação dos novos IPs do prefixo em East US 2, e comunicação dentro do prazo acordado com os parceiros.

Gabarito — Cenário 3​

Resposta: C

A mensagem de erro é direta e a pista está na própria saída do comando: Public IP address SKU must be Standard when created from a public IP prefix. Esta é uma restrição fundamental do recurso: qualquer IP público derivado de um prefixo de IP público deve ter SKU Standard, independentemente de qualquer outra configuração.

A informação sobre as zonas de disponibilidade é deliberadamente irrelevante para este erro específico. O prefixo foi criado com sucesso com --zone 1 2 3, o que é válido. O erro não tem relação com zonas; ele ocorreria igualmente em um prefixo sem zonas configuradas.

A alternativa D representa o erro de raciocínio mais comum: associar o comportamento das zonas ao problema observado por parecer a variável "diferente" no comando. Agir com base nessa hipótese levaria o engenheiro a recriar o prefixo sem zonas, apenas para encontrar o mesmo erro novamente.

Gabarito — Cenário 4​

Resposta: D

A sequência correta é 4 → 3 → 1 → 5 → 2, por seguir a lógica de diagnóstico do mais simples para o mais destrutivo:

  • Passo 4 primeiro: verificar bloqueio de exclusão no nível do recurso é uma checagem não destrutiva e imediata que pode explicar a falha sem nenhuma outra investigação.
  • Passo 3 em seguida: listar todos os IPs derivados com filtro por publicIPPrefix fornece visibilidade completa das dependências antes de qualquer ação.
  • Passo 1 depois: confirmar quais desses IPs estão efetivamente associados a recursos ativos refina o diagnóstico.
  • Passo 5: desassociar ou excluir os IPs vinculados é uma ação destrutiva e deve ocorrer apenas após confirmação das dependências.
  • Passo 2 por último: tentar a exclusão do prefixo somente após garantir que não há mais dependências.

A alternativa A inverte passo 1 e 3, o que é menos eficiente: verificar bloqueio antes de mapear dependências é correto, mas checar cada IP individualmente antes de listar todos é redundante. A alternativa B pula a verificação de bloqueio, que poderia ser a causa imediata. A alternativa C começa pela listagem sem verificar bloqueio, o que pode levar a desassociações desnecessárias se a causa for apenas um bloqueio de recurso.

Árvore de Troubleshooting: Create a prefix for public IP addresses​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Legenda:

CorTipo de nó
Azul escuroSintoma inicial (ponto de entrada)
Azul médioPergunta diagnóstica
LaranjaVerificação ou validação intermediária
VermelhoCausa identificada
VerdeAção recomendada ou resolução

Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga a ramificação respondendo cada pergunta com base no que é verificável no ambiente. Perguntas de diagnóstico (azul) exigem observação direta antes de avançar; nós de verificação (laranja) indicam passos de coleta de dados; ao atingir um nó vermelho, a causa está identificada e o próximo passo é sempre um nó verde de ação corretiva. Nunca pule da causa para a ação sem confirmar o estado real do recurso.