Laboratório de Troubleshooting: Recommend a route advertisement configuration
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede reporta que VMs em uma VNet do Azure não conseguem alcançar servidores em 172.16.50.0/24 na rede on-premises. A conexão utiliza ExpressRoute com peering privado. O circuito está no estado Provisioned e o peering privado aparece como Connected no portal do Azure.
O engenheiro executa o seguinte comando para verificar as rotas aprendidas pelo gateway:
Get-AzVirtualNetworkGatewayLearnedRoute `
-VirtualNetworkGatewayName gw-expressroute-prod `
-ResourceGroupName rg-network-prod | Format-Table
LocalAddress Network NextHop SourceType Origin AsPath
------------ ------- ------- ---------- ------ ------
10.0.0.1 10.0.0.0/16 - Network - -
10.0.0.1 192.168.0.0/24 10.0.0.254 EBgp Ibgp 65100
10.0.0.1 172.16.10.0/24 10.0.0.254 EBgp Ibgp 65100
10.0.0.1 172.16.20.0/24 10.0.0.254 EBgp Ibgp 65100
O engenheiro verifica ainda que o circuito tem largura de banda contratada de 500 Mbps e que a utilização atual está em 12%. A MTU configurada no lado on-premises é 1500 bytes.
Qual é a causa raiz do problema?
A) O peering privado do ExpressRoute está degradado e não está propagando todas as rotas corretamente
B) O roteador on-premises não está anunciando o prefixo 172.16.50.0/24 via BGP para o circuito ExpressRoute
C) A VNet do Azure não possui uma User Defined Route (UDR) apontando 172.16.50.0/24 para o gateway
D) A utilização baixa do circuito indica um problema de provisionamento que limita a quantidade de prefixos aceitos
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o Branch-to-Branch está desabilitado no hub do Azure Virtual WAN, impedindo que duas filiais conectadas via VPN S2S se comuniquem diretamente. A habilitação dessa configuração resolve o problema imediatamente, sem necessidade de janela de manutenção segundo a documentação interna.
O contexto atual é:
- Ambiente de produção com SLA de 99,9%
- Outras 15 filiais estão operando normalmente e dependem do mesmo hub
- A alteração afeta as tabelas de rotas do hub globalmente
- O time de segurança ainda não foi consultado sobre o impacto do tráfego direto entre filiais
- O ticket de incidente está aberto há 40 minutos
Qual é a ação correta a tomar neste momento?
A) Habilitar o Branch-to-Branch imediatamente, pois a causa está confirmada e a mudança não requer janela de manutenção
B) Consultar o time de segurança sobre o impacto antes de habilitar o Branch-to-Branch, dado que a mudança afeta o modelo de tráfego de todas as filiais
C) Criar uma rota estática temporária no hub vWAN apontando o tráfego entre as duas filiais problemáticas, evitando impacto nas demais
D) Reabrir o ticket como problema de configuração de VPN e escalar para o fornecedor do dispositivo on-premises
Cenário 3 — Causa Raiz
Uma organização possui uma VNet com um Azure Route Server e uma NVA (Network Virtual Appliance) que faz peering BGP com o Route Server. A NVA aprende rotas on-premises via BGP e as propaga ao Route Server. Existe também uma VNet spoke conectada via peering à VNet do Route Server.
O time reporta que VMs na VNet spoke não conseguem alcançar a rede on-premises 10.200.0.0/16, embora VMs na mesma VNet do Route Server consigam sem problemas.
A configuração de peering entre as duas VNets é:
| Configuração | VNet Route Server (hub) | VNet Spoke |
|---|---|---|
| Allow Gateway Transit | Enabled | N/A |
| Use Remote Gateways | N/A | Disabled |
| Allow Forwarded Traffic | Enabled | Enabled |
| Allow Virtual Network Access | Enabled | Enabled |
O engenheiro verifica que as rotas efetivas das VMs na VNet spoke mostram apenas rotas locais e a rota padrão 0.0.0.0/0. O Route Server na VNet hub mostra corretamente a rota 10.200.0.0/16 aprendida da NVA.
O SKU do Route Server é Standard e foi implantado há três semanas sem alterações.
Qual é a causa raiz do problema?
A) O Allow Forwarded Traffic não está habilitado na VNet spoke, impedindo que pacotes da NVA atravessem o peering
B) O Use Remote Gateways está desabilitado na VNet spoke, impedindo que ela aprenda as rotas propagadas pelo Route Server via peering
C) O Route Server não propaga rotas para VNets spoke via peering sem que o Branch-to-Branch esteja habilitado
D) O SKU Standard do Route Server tem limite de prefixos que foi excedido, causando propagação parcial das rotas
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: VMs em uma VNet do Azure param de alcançar a rede on-premises após uma alteração de manutenção realizada na madrugada. A conexão utiliza VPN Gateway com BGP habilitado. Antes da manutenção, tudo funcionava corretamente.
Os passos de investigação disponíveis são:
- Verificar se o túnel VPN está no estado Connected no portal do Azure
- Examinar as rotas efetivas nas NICs das VMs afetadas
- Confirmar o ASN e o endereço BGP peer configurados no Local Network Gateway
- Verificar as rotas anunciadas e aprendidas pelo VPN Gateway via
Get-AzVirtualNetworkGatewayLearnedRoute - Testar conectividade com
pingouTest-NetConnectionde uma VM para o IP on-premises
Qual é a sequência correta de diagnóstico?
A) 5 → 1 → 4 → 2 → 3
B) 1 → 5 → 2 → 4 → 3
C) 1 → 4 → 3 → 2 → 5
D) 2 → 4 → 1 → 3 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A saída do comando Get-AzVirtualNetworkGatewayLearnedRoute é a pista central do diagnóstico. O gateway aprendeu via BGP os prefixos 192.168.0.0/24, 172.16.10.0/24 e 172.16.20.0/24, mas o prefixo 172.16.50.0/24 está ausente. Isso indica que o problema não está no Azure: o gateway está funcionando, o peering BGP está ativo (origem EBgp) e outras rotas estão sendo recebidas normalmente. A causa só pode estar no lado on-premises, onde o roteador simplesmente não está anunciando esse prefixo específico.
A informação sobre utilização do circuito (12%) e MTU (1500 bytes) é propositalmente irrelevante. Nenhum desses fatores afeta quais prefixos são anunciados via BGP.
A alternativa (A) é incorreta: o peering aparece como Connected e outras rotas estão sendo aprendidas, o que descarta degradação. A alternativa (C) seria válida apenas se a rota estivesse na tabela do gateway mas não nas VMs; como a rota não existe nem no gateway, o problema é anterior. A alternativa (D) não existe como comportamento real do ExpressRoute.
O distrator mais perigoso é (C): um engenheiro poderia criar uma UDR desnecessária apontando para um next-hop inválido, criando um buraco negro de roteamento em vez de resolver o problema real.
Gabarito — Cenário 2
Resposta: B
A causa está confirmada e a solução técnica é clara, mas o cenário introduz uma restrição crítica que não pode ser ignorada: a mudança afeta o modelo de tráfego de todas as 15 filiais e o time de segurança ainda não foi consultado. Habilitar o Branch-to-Branch sem essa validação pode abrir caminhos de comunicação entre filiais que violam políticas de segmentação de rede definidas pela organização.
A alternativa (A) representa o erro clássico de priorizar velocidade técnica sobre governança. O fato de não precisar de janela de manutenção não elimina a necessidade de aprovação de segurança para uma mudança de escopo amplo. A alternativa (C) é tecnicamente inviável: o vWAN gerenciado não permite rotas estáticas entre branches da forma descrita. A alternativa (D) é incorreta porque a causa já foi identificada e está no Azure, não no dispositivo do fornecedor.
Gabarito — Cenário 3
Resposta: B
A tabela de configuração de peering é a pista decisiva. O Use Remote Gateways está Disabled na VNet spoke. Sem essa configuração habilitada, a VNet spoke não instrui o Azure a usar o gateway ou o Route Server da VNet parceira para aprender rotas externas. O resultado é exatamente o observado: as VMs na spoke enxergam apenas rotas locais, enquanto VMs na VNet do Route Server, que está diretamente associada a ele, enxergam as rotas propagadas pela NVA.
O SKU do Route Server e o tempo desde a implantação são informações irrelevantes plantadas no enunciado. O Route Server Standard não tem limite prático de prefixos que causaria esse sintoma específico.
A alternativa (A) é incorreta porque Allow Forwarded Traffic controla se pacotes originados fora da VNet podem atravessar o peering, não se as rotas BGP são propagadas. A alternativa (C) confunde a função do Branch-to-Branch: esse recurso controla a troca de rotas entre gateways (VPN/ExpressRoute) e a NVA, não a propagação para VNets spoke. A alternativa (D) é um distrator de volume sem base técnica para o sintoma apresentado.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 5 → 1 → 4 → 2 → 3, seguindo a lógica de diagnóstico do geral para o específico, começando pelo sintoma observável e avançando em direção à causa.
O passo 5 (testar conectividade) confirma o sintoma e delimita o escopo: é problema de roteamento ou de túnel? O passo 1 (verificar estado do túnel) responde se a camada de transporte está ativa. Se o túnel estiver Connected, o problema é de roteamento, e o passo 4 (verificar rotas aprendidas) revela se o BGP está propagando os prefixos esperados. O passo 2 (rotas efetivas nas VMs) confirma se as rotas chegaram até as instâncias. Só então faz sentido ir ao passo 3 (verificar ASN e BGP peer no Local Network Gateway), pois essa seria a causa de sessão BGP que não se estabelece, o que seria visível antes nos passos anteriores.
A sequência (B) falha ao intercalar teste de conectividade antes de verificar rotas, perdendo informação diagnóstica. A sequência (C) vai direto para rotas antes de confirmar se o túnel está ativo, pulando uma camada. A sequência (D) começa pelas rotas efetivas das VMs, que é uma verificação de impacto, não de causa, e não orienta o diagnóstico de forma eficiente.
Árvore de Troubleshooting: Recommend a route advertisement configuration
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica (decisão) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação intermediária ou validação |
Para usar esta árvore diante de um problema real, comece pelo nó raiz (azul escuro) que descreve o sintoma observado. A cada nó de pergunta (azul médio), responda com base no que você consegue verificar diretamente no portal, via PowerShell ou via CLI. Siga o ramo correspondente à resposta observada. Ao chegar em um nó vermelho, a causa está identificada; o nó verde imediatamente acessível a partir dele indica a ação a tomar. Nunca pule perguntas intermediárias: cada camada elimina uma classe de hipóteses e evita ações corretivas aplicadas no lugar errado.