Laboratório de Troubleshooting: Configure Azure private peering
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa acaba de concluir a migração de seus servidores de banco de dados para VMs no Azure. O circuito ExpressRoute foi provisionado pelo provedor há três dias e o status retornado pelo portal é Provisioned. O engenheiro responsável configurou o Azure private peering com os seguintes parâmetros:
PeeringType : AzurePrivatePeering
PeerASN : 65001
PrimaryPeerAddress : 192.168.100.0/30
SecondaryPeerAddress: 192.168.100.4/30
VlanId : 200
State : Enabled
Uma connection foi criada entre o circuito e o Virtual Network Gateway da VNet de produção. O gateway é do tipo ExpressRoute, SKU Standard, e foi provisionado há uma semana. A VNet contém sub-redes nas faixas 10.10.0.0/16.
O engenheiro executa um teste de conectividade a partir de um servidor on-premises e não consegue alcançar nenhuma VM na VNet. Ao verificar as rotas aprendidas pelo gateway com o comando abaixo, o resultado é vazio:
Get-AzVirtualNetworkGatewayLearnedRoute `
-ResourceGroupName "rg-prod" `
-VirtualNetworkGatewayName "gw-expressroute-prod"
# Output:
# (empty - no routes learned)
O provedor confirmou que a camada física do circuito está operacional e que o BGP no lado deles está configurado corretamente com o ASN 65001.
Qual é a causa raiz da ausência de rotas aprendidas pelo gateway?
A) O prefixo 192.168.100.0/30 utilizado como PrimaryPeerAddress está sobrepostos ao espaço de endereçamento da VNet, causando conflito de roteamento.
B) O SKU Standard do gateway ExpressRoute não suporta aprendizado de rotas via BGP; é necessário o SKU HighPerformance.
C) O provedor está configurado com o ASN 65001, mas esse ASN é reservado pela Microsoft para uso interno no Azure private peering, tornando a sessão BGP inválida.
D) O roteador on-premises está anunciando prefixos para o Azure, mas o Azure não consegue devolver as rotas da VNet porque o provedor está configurando o BGP com o ASN do cliente e não com o ASN designado para o lado do provedor.
Cenário 2 — Decisão de Ação
A equipe de rede identificou que a causa de uma falha de conectividade via ExpressRoute é um conflito de VLAN ID: o provedor atribuiu a VLAN 300 para o circuito de private peering, mas a configuração atual no Azure registra a VLAN 200. A sessão BGP nunca foi estabelecida por esse motivo.
O ambiente é de produção. O circuito ExpressRoute é o único caminho de rede entre o datacenter on-premises e as VMs no Azure. Uma janela de manutenção de duas horas foi aprovada para esta noite. Não há circuito de backup nem VPN site-to-site configurada como fallback. O time de aplicação confirmou que todos os serviços dependentes já foram notificados e estão em modo de manutenção.
Qual é a ação correta a tomar neste momento?
A) Deletar o circuito ExpressRoute e recriar um novo com a VLAN ID correta, para garantir que nenhuma configuração residual cause problemas futuros.
B) Aguardar a janela de manutenção aprovada e então atualizar a VLAN ID do peering no Azure de 200 para 300, alinhando com o valor configurado pelo provedor.
C) Atualizar imediatamente a VLAN ID no Azure sem aguardar a janela de manutenção, pois a sessão BGP já está inativa e não há impacto adicional a produção.
D) Solicitar ao provedor que reconfigure o lado dele para VLAN 200, mantendo a configuração do Azure inalterada, para minimizar o número de mudanças no ambiente.
Cenário 3 — Causa Raiz
Um circuito ExpressRoute com Azure private peering está operacional há meses. Nenhuma alteração foi feita nos últimos 30 dias. Na segunda-feira de manhã, o time de operações recebe alertas de queda de conectividade de todos os servidores on-premises para VMs em uma VNet específica. Outras VNets conectadas ao mesmo circuito continuam funcionando normalmente.
O engenheiro verifica o estado do peering e o encontra como Enabled. O gateway ExpressRoute da VNet afetada exibe estado Succeeded. Os logs do gateway não mostram erros de BGP. A equipe de identidade informa que realizou uma limpeza de permissões no Microsoft Entra ID na sexta-feira anterior, sem relação com redes.
O engenheiro então verifica as connections associadas ao gateway da VNet afetada:
Get-AzVirtualNetworkGatewayConnection `
-ResourceGroupName "rg-vnet-app" `
-Name "conn-expressroute-app"
# ProvisioningState : Succeeded
# ConnectionStatus : Unknown
# EgressBytesTransferred : 0
# IngressBytesTransferred : 0
A VNet impactada tem endereçamento 172.20.0.0/16. As demais VNets funcionais usam endereços no espaço 10.x.x.x.
Qual é a causa raiz mais provável para a falha isolada nessa VNet?
A) O BGP do gateway foi reiniciado automaticamente pelo Azure durante uma atualização de plataforma, e os prefixos da VNet 172.20.0.0/16 ainda não foram reanunciados.
B) A connection entre o gateway e o circuito ExpressRoute foi deletada ou ficou em estado inválido, pois o ConnectionStatus Unknown com zero bytes transferidos indica ausência de plano de dados, e não apenas falha de roteamento.
C) O espaço de endereçamento 172.20.0.0/16 entrou em conflito com prefixos anunciados pelo provedor, fazendo o Azure suprimir a rota dessa VNet.
D) A limpeza de permissões realizada no Microsoft Entra ID removeu a atribuição de função necessária para que o gateway mantenha a connection ativa com o circuito.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe um chamado relatando que servidores on-premises não conseguem alcançar VMs no Azure via ExpressRoute. O circuito foi configurado recentemente. O engenheiro tem acesso ao portal do Azure, ao PowerShell e ao time de provedor de colocation.
Os passos de investigação disponíveis são:
- Verificar se existe uma connection criada entre o Virtual Network Gateway e o circuito ExpressRoute.
- Confirmar com o provedor se o status físico do circuito (camada 1) está operacional.
- Executar
Get-AzVirtualNetworkGatewayLearnedRoutepara verificar se o gateway está aprendendo rotas via BGP. - Verificar o estado do Azure private peering no circuito e confirmar se a sessão BGP está Enabled.
- Validar se os prefixos on-premises estão sendo corretamente anunciados pelo roteador do cliente para o provedor.
Qual é a sequência correta de diagnóstico progressivo?
A) 2 -> 4 -> 1 -> 3 -> 5
B) 4 -> 2 -> 5 -> 1 -> 3
C) 1 -> 3 -> 2 -> 4 -> 5
D) 2 -> 1 -> 4 -> 3 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
O ASN 65515 é reservado pela Microsoft para uso interno no Azure private peering. Quando o provedor configura o BGP usando esse ASN no lado do peer, o Azure rejeita a sessão silenciosamente, pois interpreta o anúncio como um loop ou conflito interno. O resultado prático é que nenhuma rota é aprendida pelo gateway, exatamente o sintoma descrito.
A pista no enunciado está na confirmação do provedor de que o BGP está configurado com o ASN 65001 do cliente. A informação relevante aqui é que o provedor deve usar um ASN próprio (público ou privado, diferente dos reservados), não o ASN do cliente nem um ASN reservado pela Microsoft.
A alternativa A é um distrator clássico: os endereços /30 usados no peering (192.168.100.x) são os endereços das sessões BGP ponto a ponto, completamente separados do espaço da VNet (10.10.0.0/16). Não há sobreposição. A alternativa B é falsa porque o SKU Standard suporta plenamente BGP e aprendizado de rotas. A alternativa D descreve um cenário de roteamento assimétrico que não se aplica aqui, pois o problema é anterior ao estabelecimento da sessão BGP.
O distrator mais perigoso é o A, pois leva o engenheiro a investigar o endereçamento do peering em vez de verificar a validade dos ASNs configurados.
Gabarito — Cenário 2
Resposta: B
A causa está identificada, a solução é tecnicamente simples (corrigir a VLAN ID no Azure), e a janela de manutenção aprovada já está disponível. Aguardar a janela é a ação correta porque o procedimento, embora a sessão BGP esteja inativa, ainda envolve uma alteração em ambiente de produção com dependências declaradas, e a janela foi formalmente aprovada com o alinhamento do time de aplicação.
A alternativa C parece razoável à primeira vista porque a sessão BGP já está inativa. No entanto, ignorar a janela de manutenção aprovada viola o processo de gestão de mudanças estabelecido, especialmente em um ambiente sem fallback. A alternativa A é tecnicamente incorreta porque deletar o circuito é uma ação destrutiva e desnecessária para corrigir apenas a VLAN ID. A alternativa D pode funcionar em teoria, mas introduz uma segunda mudança no ambiente do provedor quando a correção mais simples e controlada é no lado do Azure.
A consequência real de escolher a alternativa C seria expor a organização a um risco de mudança não planejada em produção sem o suporte formal ativado, mesmo que tecnicamente o impacto seja mínimo neste caso.
Gabarito — Cenário 3
Resposta: B
O sintoma central é ConnectionStatus: Unknown combinado com zero bytes transferidos em ambas as direções. Esse estado específico indica que o plano de dados da connection está completamente inativo, o que é consistente com uma connection deletada, corrompida ou em estado inválido. O fato de o peering estar Enabled e o gateway em estado Succeeded confirma que os problemas estão isolados na connection, não no circuito nem no gateway em si.
A informação irrelevante no enunciado é a limpeza de permissões no Microsoft Entra ID. Permissões de identidade não controlam o estado de connections de rede no ExpressRoute. Esse detalhe foi inserido propositalmente para induzir a alternativa D, que seria o distrator mais perigoso: levar o engenheiro a abrir um chamado para o time de identidade enquanto o problema real está na connection de rede.
A alternativa A é plausível em teoria, mas seria refutada pela verificação das rotas aprendidas e não explicaria o ConnectionStatus Unknown. A alternativa C é descartável porque um conflito de prefixo causaria supressão de rota, não ausência total de plano de dados com esse status específico.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 2 -> 4 -> 1 -> 3 -> 5, que segue a lógica de diagnóstico progressivo por camadas:
| Ordem | Passo | Justificativa |
|---|---|---|
| 1 | Confirmar camada física com o provedor | Sem conectividade física, nenhum passo lógico adianta |
| 2 | Verificar estado do private peering e BGP | Confirma se a sessão BGP foi estabelecida |
| 3 | Verificar se a connection existe | Valida o vínculo entre circuito e gateway |
| 4 | Verificar rotas aprendidas pelo gateway | Confirma se o plano de controle está funcionando fim a fim |
| 5 | Validar prefixos anunciados pelo roteador on-premises | Investiga o que está sendo anunciado pelo cliente |
A alternativa C começa verificando a connection antes de confirmar se o BGP sequer foi estabelecido, saltando camadas. A alternativa B começa pelo estado do peering sem antes confirmar a camada física, o que pode gerar diagnóstico incorreto se o problema for físico. A alternativa D inverte a ordem entre verificar a connection e verificar o estado do BGP, levando a investigar o plano de dados antes de confirmar o plano de controle.
Árvore de Troubleshooting: Configure Azure private peering
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 que descreve o sintoma observado e responda cada pergunta diagnóstica com base no que você pode verificar diretamente no portal, via PowerShell ou com o provedor. Cada resposta elimina um ramo e aproxima o diagnóstico da causa real. Quando chegar a um nó vermelho, a causa está identificada; o nó verde imediatamente ligado a ele indica a ação corretiva a executar. Nunca pule um nível: cada camada da árvore valida um plano diferente da solução, da camada física até o plano de controle BGP e o plano de dados.