Laboratório de Troubleshooting: Diagnose and Resolve ExpressRoute Connection Issues
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa possui um circuito ExpressRoute ativo com Private Peering configurado há seis meses sem incidentes. Na última semana, após uma mudança no firewall on-premises, o time de operações reporta que VMs em duas VNets do Azure pararam de responder a pings originados da rede corporativa. O time de rede confirma que o circuito está no estado "CircuitProvisioningState: Enabled" e que o "ServiceProviderProvisioningState: Provisioned". O provedor de conectividade não reportou nenhuma degradação no link físico.
A tabela BGP foi verificada e apresenta o seguinte resultado:
Get-AzExpressRouteCircuitRouteTable `
-ResourceGroupName "rg-expressroute" `
-ExpressRouteCircuitName "erc-corp" `
-PeeringType "AzurePrivatePeering" `
-DevicePath "Primary"
Network NextHop LocPrf Weight Path
10.10.0.0/16 10.0.0.1 100 0 65100
10.20.0.0/16 10.0.0.1 100 0 65100
0.0.0.0/0 10.0.0.5 100 0 65100
O time também confirma que o gateway de rede virtual das duas VNets foi provisionado como ErGw1AZ e está associado ao circuito. O uptime do gateway nas últimas 24 horas é de 100%.
Qual é a causa raiz da falha de conectividade?
A) O gateway ErGw1AZ não suporta tráfego ICMP, bloqueando pings mesmo quando a rota está presente.
B) O anúncio da rota padrão 0.0.0.0/0 pelo ambiente on-premises está sobrepondo as rotas específicas das VNets no plano de roteamento do Azure, redirecionando o tráfego de retorno para o ambiente on-premises e causando loop ou descarte.
C) O circuito está operando apenas no caminho primário; o caminho secundário falhou após a mudança no firewall, reduzindo a largura de banda disponível abaixo do mínimo necessário.
D) A mudança no firewall on-premises introduziu regras que bloqueiam o tráfego de retorno originado dos prefixos das VNets do Azure, impedindo que as respostas cheguem à rede corporativa.
Cenário 2 — Causa Raiz
Um engenheiro está comissionando um novo circuito ExpressRoute com Microsoft Peering para permitir acesso ao Azure Storage e ao Azure SQL via endereços públicos. O peering foi configurado e o estado retornado é "PeeringState: Enabled". Um Route Filter foi criado e associado ao peering, contendo a comunidade BGP 12076:5010 (Azure Storage). O teste de conectividade ao Azure SQL falha completamente, enquanto o acesso ao Azure Storage funciona normalmente.
A configuração atual do Route Filter é:
RouteFilterName : rf-microsoft-peering
Rules:
- Name : allow-storage
Action : Allow
Communities : 12076:5010
Access : Allow
O engenheiro verifica e confirma que o peering tem PeerASN válido, os prefixos de peering são públicos registrados em RIR, e o VLAN ID está correto. O circuito tem SKU Standard.
Qual é a causa raiz da falha no acesso ao Azure SQL?
A) O SKU Standard do circuito não suporta acesso a serviços PaaS como Azure SQL via Microsoft Peering; é necessário o SKU Premium.
B) O Route Filter está configurado apenas com a comunidade BGP do Azure Storage. A comunidade BGP correspondente ao Azure SQL não foi incluída, portanto os prefixos do SQL não estão sendo anunciados ao ambiente on-premises.
C) O peering precisa de uma segunda sessão BGP dedicada para cada serviço PaaS; a sessão atual suporta apenas o serviço cujos prefixos foram aprendidos primeiro.
D) O Azure SQL não é acessível via Microsoft Peering; esse serviço exige Private Peering combinado com Private Endpoint configurado na VNet.
Cenário 3 — Decisão de Ação
A causa raiz foi identificada: o circuito ExpressRoute de produção está com o caminho secundário em estado de falha de camada 2. A análise da tabela ARP do caminho secundário retornou vazia, enquanto o caminho primário opera normalmente. Todo o tráfego de produção está fluindo pelo caminho primário sem degradação perceptível no momento.
O engenheiro responsável tem as seguintes informações de contexto:
- O incidente ocorreu às 14h de uma sexta-feira
- O provedor de conectividade confirmou uma falha no equipamento do lado dele e estima resolução em até 4 horas
- O SLA do ambiente de produção exige redundância ativa nos dois caminhos
- O time de mudanças da empresa exige aprovação formal para qualquer alteração em circuitos de produção fora da janela padrão, que ocorre às terças-feiras
- O caminho primário está estável e não apresenta sinais de degradação
Qual é a ação correta a tomar neste momento?
A) Abrir um chamado formal de mudança emergencial, aguardar aprovação e, após aprovada, realizar o failover manual para um circuito de backup enquanto o provedor resolve a falha.
B) Aguardar a resolução pelo provedor de conectividade, monitorar ativamente o caminho primário e acionar o processo de incidente formal para registro e acompanhamento, sem realizar alterações no circuito.
C) Executar imediatamente o failover de todo o tráfego para um circuito de backup alternativo sem abertura de chamado, priorizando a recuperação da redundância antes que o caminho primário também falhe.
D) Desabilitar e reabilitar o peering no portal do Azure para forçar a renegociação BGP em ambos os caminhos, tentando recuperar o caminho secundário sem envolver o provedor.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte alerta às 09h15:
ALERT: ExpressRoute circuit 'erc-prod-br' connectivity degraded
Affected resource: VNet 'vnet-prod-eastus'
Symptom: On-premises hosts unable to reach VMs in vnet-prod-eastus
Circuit state: Enabled | Provider state: Provisioned
Time of first occurrence: 09:02 UTC
O administrador tem acesso ao portal do Azure, ao PowerShell e ao time do provedor de conectividade. Nenhuma mudança planejada estava agendada para esse período.
Os seguintes passos de investigação estão disponíveis:
- Verificar a tabela ARP dos caminhos primário e secundário para identificar falhas de camada 2
- Verificar o estado do gateway de rede virtual e confirmar se ele está associado ao circuito
- Verificar a tabela de rotas BGP anunciadas e recebidas no peering privado
- Confirmar com o provedor de conectividade se há degradação reportada no lado deles
- Verificar o "ServiceProviderProvisioningState" e o "CircuitProvisioningState" no portal
Qual é a sequência correta de investigação?
A) 2 -> 5 -> 1 -> 3 -> 4
B) 5 -> 1 -> 3 -> 4 -> 2
C) 5 -> 4 -> 1 -> 3 -> 2
D) 1 -> 3 -> 5 -> 2 -> 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: D
A pista decisiva no enunciado é o momento em que a falha começou: imediatamente após uma mudança no firewall on-premises. O circuito está operacional, o provisionamento está correto, a tabela BGP mostra que as rotas das VNets estão sendo recebidas normalmente pelo lado Microsoft, e o gateway está saudável. Isso elimina qualquer hipótese de falha no plano de controle do Azure.
O que mudou foi o firewall. A falha de "ping não responde" é um sintoma de tráfego bloqueado no retorno, não de ausência de rota. As VMs recebem os pacotes (a rota existe), mas a resposta é bloqueada pelas novas regras do firewall ao tentar retornar à rede corporativa.
A informação sobre o uptime do gateway de 100% é irrelevante e foi incluída propositalmente para desviar o diagnóstico para o lado Azure. A alternativa B é o distrator mais perigoso: a rota padrão 0.0.0.0/0 aparece na tabela e pode parecer suspeita, mas ela está sendo anunciada pelo on-premises e não afeta o roteamento de retorno das VMs para a rede corporativa no sentido que causaria o sintoma descrito. A alternativa C descreve um problema de capacidade, não de conectividade total. Agir com base na alternativa B levaria a uma investigação demorada e incorreta no plano de roteamento do Azure, enquanto a causa real estaria no firewall on-premises.
Gabarito — Cenário 2
Resposta: B
O Route Filter é o mecanismo de controle de quais prefixos BGP são anunciados ao ambiente on-premises via Microsoft Peering. Cada serviço Azure tem uma comunidade BGP específica: o Azure Storage usa 12076:5010 e o Azure SQL usa uma comunidade diferente. Como o Route Filter contém apenas a regra para Storage, somente os prefixos do Storage são anunciados. Os prefixos do Azure SQL simplesmente não chegam ao roteador on-premises, tornando o serviço inalcançável.
O SKU Standard suporta Microsoft Peering normalmente; o SKU Premium é necessário para acesso a regiões fora da área geopolítica, não para tipos de serviço. Essa é a confusão que a alternativa A explora. A alternativa C inventa um comportamento que não existe: uma única sessão BGP por peering suporta múltiplas comunidades e prefixos simultaneamente. A alternativa D é tecnicamente incorreta: o Azure SQL é acessível via Microsoft Peering usando seus endereços públicos; Private Endpoint é uma alternativa, não um requisito exclusivo. O distrator mais perigoso é D, pois um engenheiro que acredite nele pode criar uma arquitetura de Private Endpoint desnecessária, adicionando complexidade e custo.
Gabarito — Cenário 3
Resposta: B
O cenário estabelece restrições críticas que eliminam as demais alternativas. O caminho primário está estável e operando normalmente, o provedor já identificou a causa e tem previsão de resolução em 4 horas, e qualquer alteração em produção exige aprovação formal fora da janela padrão.
A ação correta é monitorar, registrar o incidente formalmente e aguardar. O SLA exige redundância, mas não exige que a empresa execute uma mudança emergencial não aprovada quando o caminho principal está funcionando e a resolução está em andamento.
A alternativa A é atraente porque parece responsável, mas abre um processo de mudança emergencial para uma ação (failover) desnecessária dado que o primário está estável. A alternativa C é a mais perigosa: executar um failover não autorizado em produção pode violar políticas de governança e introduzir riscos adicionais desnecessários. A alternativa D é tecnicamente incorreta e potencialmente destrutiva: reabilitar o peering afeta ambos os caminhos, incluindo o primário que está saudável, podendo causar uma interrupção completa enquanto o BGP renegocia.
Gabarito — Cenário 4
Resposta: C
A sequência correta de diagnóstico para ExpressRoute segue a lógica de camadas, do estado geral para o detalhe, priorizando o que pode ser verificado localmente antes de envolver terceiros.
Passo 5 confirma que o circuito está provisionado corretamente em ambos os lados. Sem isso, qualquer investigação subsequente pode ser inútil.
Passo 4 aciona o provedor imediatamente em paralelo, porque falhas de camada 1 e 2 no side do provedor são invisíveis ao portal do Azure e podem ser confirmadas ou descartadas rapidamente com uma ligação.
Passo 1 verifica a tabela ARP para identificar falhas de camada 2 no lado Microsoft.
Passo 3 verifica o plano de controle BGP para identificar se as rotas corretas estão sendo trocadas (camada 3).
Passo 2 verifica o gateway por último, pois o alerta já indica que o circuito está Enabled e Provisioned. O gateway é a camada mais alta e deve ser verificada após confirmar que as camadas inferiores estão saudáveis.
A alternativa A começa pelo gateway, que é uma hipótese de camada alta sem evidência. A alternativa D começa pela tabela ARP antes de confirmar o estado do circuito, o que é um salto prematuro de diagnóstico. O erro representado pelas alternativas incorretas é comum: ir direto ao componente mais familiar ao engenheiro, em vez de seguir a progressão lógica de camadas.
Árvore de Troubleshooting: Diagnose and Resolve ExpressRoute Connection Issues
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou estado observável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Diante de um problema real, inicie pelo nó raiz e responda cada pergunta com base no que é observável diretamente, seja no portal do Azure, via PowerShell ou com informações do provedor. Siga o caminho correspondente à resposta obtida. Nós laranjas indicam que uma verificação adicional é necessária antes de concluir o diagnóstico. Ao atingir um nó vermelho, a causa está identificada e a ação corretiva pode ser iniciada com segurança.