Laboratório de Troubleshooting: Design and Implement Azure Route Server
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um engenheiro de rede implantou o Azure Route Server em uma VNet de hub e configurou o peering BGP com um NVA de terceiros. O NVA está rodando corretamente, a sessão BGP foi estabelecida com sucesso e o Route Server aparece como Succeeded no portal. O ASN do NVA é 65001 e o do Route Server é 65515.
No entanto, as VMs nas VNets spoke, conectadas via VNet Peering à VNet de hub, continuam usando rotas padrão do Azure e não enxergam as rotas anunciadas pelo NVA. O time verifica que o NVA está anunciando os prefixos corretamente via BGP e que as rotas aparecem na tabela do Route Server.
A VNet de hub possui um ExpressRoute Gateway configurado, mas sem circuito ativo conectado. O peering entre a VNet hub e as VNets spoke foi criado há seis meses e está no estado Connected.
Qual é a causa raiz do problema?
A) O ASN 65001 do NVA conflita com o intervalo reservado do Azure, impedindo que as rotas sejam programadas nas VNets spoke.
B) A opção Use Remote Gateway or Route Server não está habilitada nos peerings das VNets spoke em direção à VNet de hub.
C) A presença do ExpressRoute Gateway sem circuito ativo bloqueia a propagação de rotas do Route Server para as VNets spoke.
D) O Route Server não propaga rotas para VNets spoke quando a sessão BGP é estabelecida com um NVA de terceiros fora do ecossistema Microsoft.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que a funcionalidade Branch-to-Branch foi habilitada inadvertidamente no Azure Route Server de produção. Como consequência, rotas aprendidas via VPN Gateway estão sendo redistribuídas para o NVA, que por sua vez as está re-anunciando para redes on-premises via ExpressRoute, criando um loop de roteamento assimétrico que afeta sessões críticas de banco de dados.
A causa está confirmada. O ambiente possui as seguintes restrições:
- O ExpressRoute é o caminho principal para workloads financeiras em produção
- O VPN Gateway é usado por filiais secundárias com tolerância a interrupção de até 30 minutos
- Desabilitar o Branch-to-Branch no Route Server não requer recriação do recurso
- Uma janela de manutenção programada está disponível em 48 horas
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção em 48 horas e desabilitar o Branch-to-Branch durante o período programado, minimizando o risco de impacto adicional.
B) Desabilitar imediatamente o Branch-to-Branch no Route Server, pois a operação não requer recriação do recurso e o impacto do loop ativo supera o risco da mudança.
C) Remover o peering BGP entre o NVA e o Route Server imediatamente para interromper o loop, e reconfigurar após a janela de manutenção.
D) Desconectar o VPN Gateway da VNet temporariamente para eliminar a origem das rotas problemáticas sem alterar o Route Server.
Cenário 3 — Causa Raiz
Um NVA foi implantado em uma VNet e o peering BGP com o Azure Route Server foi configurado conforme a documentação. O operador observa que a sessão BGP oscila entre Connected e Idle a cada poucos minutos, nunca permanecendo estável.
O time coleta a seguinte saída do NVA:
BGP neighbor is 10.2.0.4, remote AS 65515
BGP state = Active
Last read 00:00:42, hold time is 90, keepalive interval is 30 seconds
Connect retry interval is 120 seconds
neighbor 10.2.0.4 remote-as 65515
neighbor 10.2.0.4 update-source loopback0
neighbor 10.2.0.4 ebgp-multihop 2
O operador verifica que:
- O NSG associado à RouteServerSubnet permite tráfego de entrada na porta 179 vindo do NVA
- O NVA tem conectividade IP com o endereço 10.2.0.4 (confirmado via ping)
- O Route Server foi implantado há dois dias e nunca estabeleceu sessão estável com este NVA
- A VNet possui três subnets:
default,RouteServerSubnetenva-subnet
Qual é a causa raiz da instabilidade da sessão BGP?
A) O NSG da RouteServerSubnet está bloqueando tráfego de retorno do Route Server para o NVA na porta 179, pois a regra de entrada não é suficiente para sessões BGP bidirecionais.
B) O update-source loopback0 faz com que os pacotes BGP partam de um endereço não reconhecido pelo Route Server como origem válida do peer, impedindo a estabilidade da sessão.
C) O ebgp-multihop 2 está incorreto porque NVA e Route Server estão na mesma VNet, e o valor deve ser 1 para conectividade direta.
D) O hold time de 90 segundos é incompatível com o timer padrão do Route Server, que exige hold time mínimo de 180 segundos para sessões eBGP externas.
Cenário 4 — Impacto Colateral
Um time de operações detectou que o Azure Route Server estava anunciando para o NVA um volume inesperadamente alto de prefixos, incluindo rotas do espaço de endereçamento de todas as VNets conectadas via peering à VNet de hub. Para simplificar a tabela de rotas no NVA e reduzir o processamento BGP, o time decide remover o peering de VNet entre a VNet hub e duas VNets spoke de menor prioridade, mantendo apenas as VNets spoke críticas conectadas.
A ação foi executada com sucesso e o volume de prefixos anunciados ao NVA foi reduzido conforme esperado.
Qual é a consequência secundária mais relevante dessa ação?
A) O Route Server passa a anunciar rotas duplicadas para as VNets spoke restantes, pois detecta inconsistência na topologia de peering.
B) As VMs nas VNets spoke removidas perdem toda a conectividade com a VNet de hub e com quaisquer recursos acessíveis apenas por meio dela, incluindo gateways e serviços compartilhados.
C) O NVA perde a capacidade de anunciar rotas via BGP para o Route Server, pois o quórum mínimo de VNets conectadas não é mais atendido.
D) O Route Server entra em estado degradado e para de propagar rotas para as VNets spoke restantes até que um novo peering seja adicionado.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na descrição do peering: ele foi criado há seis meses, antes do Route Server existir no ambiente. Peerings criados antes da implantação do Route Server não herdam automaticamente a configuração necessária. A opção Use Remote Gateway or Route Server precisa ser habilitada explicitamente no peering de cada VNet spoke em direção à VNet de hub para que o Azure programe as rotas aprendidas pelo Route Server nessas VNets.
A informação sobre o ExpressRoute Gateway sem circuito ativo é propositalmente irrelevante. A ausência de circuito ativo não interfere na propagação de rotas do Route Server para VNets spoke. Esse detalhe existe para induzir o leitor à alternativa C.
O ASN 65001 não pertence ao intervalo reservado pelo Azure (65515 é o ASN fixo do Route Server; o NVA pode usar qualquer ASN privado fora do intervalo reservado). O distrator mais perigoso é a alternativa C: agir removendo ou reconfigurando o ExpressRoute Gateway sem investigar o estado dos peerings causaria impacto real sem resolver o problema.
Gabarito — Cenário 2
Resposta: B
O loop de roteamento está ativo e afetando sessões de banco de dados em produção. A restrição crítica aqui não é o ExpressRoute nem o VPN Gateway em si, mas sim a natureza da correção: desabilitar o Branch-to-Branch é uma operação atômica que não requer recriação do Route Server nem indisponibilidade de outros recursos. Aguardar 48 horas (alternativa A) significa manter o loop ativo e o impacto em produção por mais dois dias, o que é inaceitável dado que a correção é de baixo risco.
A alternativa C é perigosa porque remover o peering BGP com o NVA interrompe todo o roteamento dinâmico da infraestrutura, causando impacto muito maior do que o problema original. A alternativa D desconecta o VPN Gateway, afetando as filiais secundárias desnecessariamente quando a causa raiz pode ser corrigida diretamente no Route Server sem tocar nos gateways. A restrição dos 30 minutos de tolerância das filiais existe para confundir o leitor e fazê-lo considerar a alternativa D como aceitável.
Gabarito — Cenário 3
Resposta: B
A causa raiz é o uso de update-source loopback0. O Azure Route Server exige que o peer BGP use o endereço IP da interface diretamente conectada como origem dos pacotes BGP. Quando o NVA usa uma interface de loopback como update-source, os pacotes TCP da sessão BGP partem de um endereço IP que o Route Server não associa ao peer configurado, resultando na rejeição da sessão e no ciclo de reconexão observado.
O fato de o ping para 10.2.0.4 funcionar é um distrator clássico: confirma conectividade IP, mas não valida a origem dos pacotes BGP. O NSG permitindo entrada na porta 179 é outra informação verdadeira e irrelevante para esta causa específica. A alternativa C sobre ebgp-multihop seria relevante se o valor fosse 1 num cenário de multihop real, mas o valor 2 não causa instabilidade por si só quando a interface correta é usada. A alternativa D sobre hold time é tecnicamente incorreta: o Route Server aceita o valor de 90 segundos sem problema.
O distrator mais perigoso é a alternativa A: um operador pode passar horas ajustando regras de NSG sem perceber que a origem dos pacotes BGP é o problema real.
Gabarito — Cenário 4
Resposta: B
Remover o peering de VNet entre a VNet hub e as VNets spoke é uma operação de infraestrutura com impacto imediato e total na conectividade dessas VNets. Sem o peering, as VMs nessas VNets perdem acesso a tudo que está na VNet hub: o NVA, gateways VPN ou ExpressRoute, serviços de DNS centralizados, jumpboxes e quaisquer outros recursos compartilhados. O Route Server e o NVA continuam funcionando normalmente para as VNets restantes.
As alternativas A, C e D descrevem comportamentos que o Route Server não possui. Não existe quórum mínimo de VNets conectadas, não há anúncio duplicado por inconsistência de topologia e o Route Server não entra em estado degradado por remoção de peerings. Esses distratores exploram a tendência de atribuir ao Route Server efeitos que pertencem ao plano de dados da VNet. A consequência real é simples e severa: isolamento completo das VNets removidas do peering.
Árvore de Troubleshooting: Azure Route Server
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial ou ponto de entrada |
| Azul | Pergunta diagnóstica |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Diante de um problema real com o Azure Route Server, inicie pelo nó raiz e responda cada pergunta com base no que é diretamente observável no ambiente: o estado da sessão BGP no NVA, a presença de rotas na tabela do Route Server via portal ou CLI, e o comportamento de roteamento nas VNets spoke. Cada ramificação elimina uma classe de causa e direciona para o nível seguinte de verificação, até que a causa seja identificada e a ação corretiva correspondente possa ser aplicada com segurança.