Laboratório de Troubleshooting: Design and implement ExpressRoute to meet requirements, including cross-region connectivity, redundancy, and disaster recovery
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de rede reporta que, após uma migração bem-sucedida de workloads para Azure East US, as máquinas virtuais nessa região não conseguem mais alcançar o ambiente on-premises. O circuito ExpressRoute existente foi provisionado há dois anos e está com status Enabled no portal do Azure. O provedor de conectividade confirmou que o link físico está operacional e que o peering BGP com o lado do provedor está estabelecido.
Durante a investigação, o engenheiro executa o seguinte comando:
Get-AzExpressRouteCircuit -Name "er-circuit-prod" -ResourceGroupName "rg-network" |
Select-Object -ExpandProperty Peerings
A saída retorna:
Name : AzurePrivatePeering
PeeringType : AzurePrivatePeering
State : Disabled
AzureASN : 12076
PeerASN : 65100
PrimaryAzurePort :
SecondaryAzurePort :
PrimaryPeerAddressPrefix : 10.0.0.0/30
SecondaryPeerAddressPrefix : 10.0.0.4/30
O circuito é do SKU Standard e está associado a uma VNet em East US via gateway ExpressRoute com SKU HighPerformance. A assinatura tem cotas disponíveis e nenhum bloqueio de política foi identificado. O gateway de rede virtual foi recriado durante a migração.
Qual é a causa raiz da falha de conectividade?
A) O SKU Standard do circuito não suporta associação com gateways do tipo HighPerformance
B) O gateway de rede virtual foi recriado sem que a conexão ao circuito ExpressRoute fosse restabelecida
C) O Azure Private Peering está no estado Disabled, impedindo o estabelecimento da sessão BGP entre o Azure e o on-premises
D) Os prefixos de peering configurados (10.0.0.0/30 e 10.0.0.4/30) estão em conflito com o espaço de endereçamento da VNet
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o Azure Private Peering do circuito ExpressRoute de produção está com o estado Disabled após uma alteração administrativa realizada por engelho durante uma janela de manutenção. O circuito atende a workloads críticos de banco de dados com RPO zero e RTO inferior a 15 minutos.
O ambiente possui:
Circuito ExpressRoute: er-circuit-prod (SKU Standard, provedor ativo)
Gateway ExpressRoute: gw-er-prod (SKU HighPerformance, modo ativo-ativo)
Conexão ao circuito: conn-er-prod (estado: Degraded)
Backup disponível: VPN Site-to-Site (conn-vpn-backup, estado: Connected, largura de banda: 1 Gbps)
A janela de manutenção encerrou há 20 minutos. O impacto está em produção. A reabilitação do peering exige que uma sessão BGP seja reestabelecida, o que pode levar até 5 minutos após a configuração. O time de banco de dados está aguardando para reiniciar os serviços.
Qual é a ação correta a tomar neste momento?
A) Reabilitar imediatamente o Azure Private Peering no circuito er-circuit-prod e aguardar o reestabelecimento do BGP antes de liberar o time de banco de dados
B) Redirecionar o tráfego imediatamente para a VPN Site-to-Site e iniciar a reabilitação do peering em paralelo, avisando o time de banco de dados sobre a largura de banda reduzida
C) Excluir e recriar a conexão conn-er-prod para forçar o reestabelecimento sem precisar reabilitar o peering manualmente
D) Escalar para o provedor de conectividade para que ele reinicie a sessão BGP no lado dele, evitando intervenção no plano de controle do Azure
Cenário 3 — Causa Raiz
Uma empresa opera dois circuitos ExpressRoute em provedores distintos, ambos conectados ao mesmo gateway em modo ativo-ativo em Brazil South. O ambiente está em produção há seis meses sem incidentes. Na última semana, o time de operações identificou que, após o failover para o Circuito B (durante um teste programado de desligamento do Circuito A), o tráfego de algumas sub-redes on-premises deixou de alcançar máquinas virtuais específicas no Azure.
O time verifica as tabelas de rota efetivas de uma das VMs afetadas:
Source AddressPrefix NextHopType NextHopIP
------- ------------- ----------- ---------
Default 10.0.0.0/16 VnetLocal -
Default 172.16.0.0/12 VirtualNetworkGateway 10.20.0.4
Default 0.0.0.0/0 Internet -
O Circuito B está com status Enabled e a sessão BGP com o provedor está Established. O gateway reporta ambas as conexões com estado Connected. O time de redes confirma que os prefixos on-premises afetados são do bloco 192.168.50.0/24, que está no escopo do plano de endereçamento da filial impactada. O SKU do circuito B é Standard.
Qual é a causa raiz do problema observado durante o failover?
A) O gateway em modo ativo-ativo não consegue processar rotas de dois circuitos simultaneamente quando um deles entra em failover
B) O Circuito B não está anunciando o prefixo 192.168.50.0/24 via BGP para o Azure, por isso ele não aparece na tabela de rota efetiva das VMs
C) O SKU Standard do Circuito B limita o número de prefixos anunciados, e o bloco 192.168.50.0/24 foi descartado por excesso de rotas
D) O modo ativo-ativo do gateway distribui conexões, mas não sincroniza tabelas de rota entre os dois gateways redundantes
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "Desde ontem à noite, o ExpressRoute está funcionando, mas apenas algumas VNets conseguem se comunicar com o on-premises. Outras VNets, associadas ao mesmo gateway, não têm conectividade".
Os seguintes passos de investigação estão disponíveis:
- Verificar se as VNets sem conectividade estão em regiões geopolíticas diferentes da região do circuito
- Confirmar se o Azure Private Peering está no estado Enabled e com sessão BGP Established
- Verificar se as VNets sem conectividade estão associadas ao mesmo gateway ExpressRoute via conexão ativa
- Confirmar se o circuito possui o add-on Premium habilitado, caso as VNets estejam em regiões fora do escopo do SKU Standard
- Verificar se há rotas anunciadas pelo on-premises que cubram os espaços de endereçamento das VNets afetadas
Qual é a sequência correta de investigação para este sintoma?
A) 2 -> 3 -> 1 -> 4 -> 5
B) 1 -> 4 -> 2 -> 3 -> 5
C) 3 -> 2 -> 1 -> 4 -> 5
D) 2 -> 1 -> 4 -> 3 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista definitiva está na saída do comando: State: Disabled para o Azure Private Peering. Sem o peering habilitado, nenhuma sessão BGP é estabelecida entre o Azure e o lado on-premises, independentemente do estado físico do link ou da saúde do gateway. O plano de dados do ExpressRoute depende inteiramente da sessão BGP do Private Peering para aprender e anunciar rotas.
A informação sobre a recriação do gateway durante a migração é intencionalmente irrelevante: um gateway recriado sem conexão restabelecida causaria sintoma semelhante, mas a saída do comando descarta essa hipótese ao mostrar que o próprio peering está desabilitado, uma camada acima da conexão gateway-circuito.
Análise dos distratores:
- A é falso: o SKU Standard é compatível com gateways HighPerformance; a restrição de SKU refere-se a funcionalidades como Global Reach e número de VNets, não ao tipo de gateway.
- B é plausível e representa o erro de raciocínio mais perigoso: focar na recriação do gateway ignora a evidência direta na saída do comando.
- D é falso: os prefixos /30 são utilizados para a interconexão do peering BGP, não devem coincidir com o espaço da VNet, e os valores apresentados não caracterizam conflito real.
Agir com base no distrator B levaria à recriação desnecessária da conexão, prolongando o incidente sem resolver a causa.
Gabarito — Cenário 2
Resposta: A
A causa está identificada e é simples de corrigir: reabilitar o peering. O cenário especifica RTO inferior a 15 minutos e o reestabelecimento do BGP leva até 5 minutos após a configuração, o que está dentro da janela aceitável. A ação correta é restaurar o caminho original de produção imediatamente.
Análise das alternativas incorretas:
- B parece pragmática, mas é tecnicamente incorreta para o contexto: a VPN Site-to-Site com 1 Gbps pode ser insuficiente para workloads de banco de dados com RPO zero, e introduzir um segundo failover desnecessário aumenta o risco de incidente composto. Além disso, o enunciado declara que a causa é conhecida e a correção é direta.
- C é uma ação tecnicamente possível, mas ineficaz: recriar a conexão não reabilita o peering. O estado do peering é independente da conexão gateway-circuito.
- D é incorreta porque o peering foi desabilitado no lado do Azure, não no lado do provedor. Escalar para o provedor cria um atraso desnecessário para um problema resolvível internamente.
O principal erro de raciocínio dos distratores é confundir urgência com a necessidade de uma ação intermediária, quando a ação direta e definitiva está disponível e dentro do RTO.
Gabarito — Cenário 3
Resposta: B
A tabela de rotas efetivas das VMs afetadas não contém nenhuma entrada para o prefixo 192.168.50.0/24. Isso significa que o Azure nunca aprendeu essa rota via BGP. A causa é que o Circuito B não está anunciando esse prefixo específico, seja por uma configuração incompleta de rota summary no lado on-premises para esse provedor, seja por um filtro de rota BGP no Circuito B que exclui esse bloco.
A informação de que o BGP está Established é a armadilha principal do cenário: uma sessão BGP estabelecida não garante que todos os prefixos necessários estejam sendo anunciados. Sessão ativa e anúncio completo de rotas são condições independentes.
Análise dos distratores:
- A é falso: o modo ativo-ativo processa rotas de múltiplos circuitos normalmente; esse é exatamente seu propósito.
- C é plausível mas incorreto: o limite de prefixos do SKU Standard (4.000 rotas) dificilmente seria atingido por um único bloco /24, e o enunciado não indica nenhum log de descarte de rotas.
- D revela um equívoco sobre a arquitetura do gateway: em modo ativo-ativo, as duas instâncias do gateway compartilham as mesmas conexões e tabelas de rota; não há duas tabelas independentes a sincronizar.
O distrator mais perigoso é A: um engenheiro que acredite nisso poderia reconfigurar o gateway sem resolver o problema real, prolongando o impacto.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 2 -> 3 -> 1 -> 4 -> 5, seguindo a lógica de diagnóstico do mais geral para o mais específico:
Passo 2 primeiro: confirmar que o Private Peering está habilitado e o BGP está estabelecido é o pré-requisito de tudo. Se o peering estiver degradado, os passos seguintes são irrelevantes.
Passo 3 em seguida: verificar se as VNets problemáticas estão de fato associadas ao gateway via conexão ativa elimina o erro de configuração mais básico antes de investigar restrições de SKU.
Passo 1 depois: identificar se as VNets afetadas estão em regiões geopolíticas distintas direciona a investigação para o SKU do circuito.
Passo 4 na sequência: a pergunta sobre o add-on Premium só faz sentido depois de confirmar que as VNets estão em regiões fora do escopo Standard, o que o passo 1 revelaria.
Passo 5 por último: verificar anúncios de rota específicos é a investigação mais granular e só deve ser feita após descartar todos os problemas de escopo e associação.
As alternativas B e D cometem o erro de investigar restrições de SKU antes de confirmar o estado do peering, o que é ineficiente. A alternativa C pula a verificação do peering e começa pela associação de VNet, omitindo a fundação do diagnóstico.
Árvore de Troubleshooting: Design and Implement ExpressRoute
Legenda:
- Azul escuro: sintoma inicial, ponto de entrada do diagnóstico
- Azul: pergunta diagnóstica objetiva com resposta sim ou não
- Vermelho: causa identificada que exige investigação aprofundada
- Verde: ação recomendada ou resolução direta
- Laranja: estado de validação ou ponto de verificação intermediária
Para usar esta árvore diante de um problema real, comece sempre pelo nó raiz descrevendo o sintoma de ausência de conectividade. Responda cada pergunta de diagnóstico com base no que é observável no portal, em comandos PowerShell ou na saída de tabelas de rota efetivas. Siga o caminho indicado pela sua resposta até alcançar um nó vermelho (causa) ou verde (ação). Nós laranjas indicam que o estado atual parece correto e a investigação deve continuar ou ser encerrada com monitoramento ativo.