Laboratório de Troubleshooting: Connect a virtual network to an ExpressRoute circuit
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que as VMs em uma rede virtual de produção perderam conectividade com os servidores on-premises às 14h37. O circuito ExpressRoute continua com status "Enabled" no portal do Azure. O Virtual Network Gateway está com estado "Succeeded". A connection resource aparece com Connection State: Connected.
O engenheiro responsável executa os seguintes comandos para investigar:
# Saída do Get-AzVirtualNetworkGatewayLearnedRoute
Network NextHop Origin SourcePeer Prefix AsPath Weight
------- ------- ------ ---------- ------ ------ ------
VNet 10.0.0.1 Network 10.0.0.0/16 32768
O time de infraestrutura on-premises informa que não houve manutenção programada. O circuito foi contratado via provedor parceiro e o link físico está ativo segundo o provedor. A equipe de segurança informa que uma nova política de firewall foi aplicada no perímetro on-premises nessa mesma manhã, mas garante que apenas tráfego de saída para internet foi afetado.
Qual é a causa raiz da perda de conectividade?
A. O Virtual Network Gateway entrou em modo de manutenção automática, suspendendo temporariamente o encaminhamento de pacotes
B. O roteador on-premises parou de anunciar os prefixos da rede local via BGP para o circuito, e por isso nenhuma rota para destinos on-premises aparece na tabela do gateway
C. A política de firewall aplicada pela equipe de segurança está bloqueando o tráfego de retorno das VMs, pois regras de saída para internet podem inadvertidamente afetar o roteamento assimétrico via ExpressRoute
D. O peering BGP entre o gateway e o Microsoft Edge Router foi derrubado por expiração de timer de keepalive, e a connection resource ainda não refletiu esse estado
Cenário 2 — Decisão de Ação
A causa de uma falha de conectividade entre uma VNet e a rede on-premises foi identificada: o Authorization Key utilizado na connection resource expirou. O circuito ExpressRoute pertence a uma assinatura diferente da assinatura que contém a VNet e o gateway. A janela de manutenção permitida é de apenas 30 minutos, iniciada há 10 minutos. Qualquer alteração na connection resource derruba a sessão BGP durante a reconfiguração. O time on-premises confirmou disponibilidade para o procedimento.
O engenheiro tem acesso de Network Contributor na assinatura da VNet, mas apenas acesso de leitura na assinatura do circuito.
Qual é a ação correta a tomar neste momento?
A. Deletar a connection resource existente, solicitar ao proprietário do circuito que gere um novo Authorization Key e recriar a connection resource com a nova chave dentro da janela de manutenção
B. Atualizar o campo de Authorization Key diretamente na connection resource existente, sem deletá-la, para minimizar o tempo de indisponibilidade
C. Escalar imediatamente para o proprietário da assinatura do circuito e solicitar que ele gere um novo Authorization Key, pois a ação de redefinição requer permissão nessa assinatura, e a janela de manutenção ainda tem tempo suficiente para o procedimento completo
D. Aguardar o encerramento da janela de manutenção atual e agendar um novo procedimento com janela mais ampla, pois 20 minutos restantes são insuficientes para recriar a conexão com segurança
Cenário 3 — Causa Raiz
Uma empresa conectou recentemente uma segunda VNet ao mesmo circuito ExpressRoute Standard. A primeira VNet continuou funcionando normalmente. As VMs da segunda VNet conseguem alcançar recursos on-premises, mas não conseguem alcançar as VMs da primeira VNet pelo caminho privado.
A configuração das duas VNets é a seguinte:
| Configuração | VNet-A (original) | VNet-B (nova) |
|---|---|---|
| Address space | 10.1.0.0/16 | 10.2.0.0/16 |
| Gateway SKU | ErGw2AZ | ErGw1AZ |
| Peering com a outra VNet | Não configurado | Não configurado |
| Conexão ao circuito | Ativa | Ativa |
O engenheiro verifica as rotas aprendidas no gateway da VNet-B e confirma que o prefixo 10.1.0.0/16 não aparece na tabela. O time de rede informa que o circuito utilizado é do tipo Standard, não Premium. O roteador on-premises está anunciando corretamente os prefixos das duas VNets para os clientes locais.
Qual é a causa raiz do problema?
A. A diferença de SKU entre os gateways (ErGw2AZ vs ErGw1AZ) impede que rotas sejam trocadas entre VNets conectadas ao mesmo circuito
B. O circuito ExpressRoute não funciona como mecanismo de trânsito entre VNets conectadas a ele; a comunicação entre VNet-A e VNet-B exige VNet peering ou outro mecanismo de conectividade direta
C. O circuito do tipo Standard não suporta múltiplas conexões simultâneas de VNets; seria necessário fazer upgrade para Premium antes de conectar a VNet-B
D. Os prefixos das duas VNets precisam ser anunciados manualmente via BGP para que o circuito propague as rotas entre elas; a ausência de configuração de route advertisement explica a falha
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte alerta às 09h12:
ALERT: ExpressRoute connection 'conn-prod-expressroute'
Status: Degraded
Gateway: vnet-gw-prod (ErGw3AZ)
Circuit: circuit-prod-br
Symptom: Partial packet loss on private peering path
Time detected: 09:08 UTC
O administrador tem disponíveis os seguintes passos de investigação:
- Verificar o estado do BGP peer no gateway com
Get-AzVirtualNetworkGatewayBGPPeerStatus - Verificar se há manutenção programada no circuito pelo provedor via portal ou suporte
- Confirmar se o provider provisioning state do circuito ainda é "Provisioned"
- Executar Connection Monitor ou testes de latência entre uma VM da VNet e um host on-premises para quantificar a perda
- Verificar os logs de diagnóstico do gateway no Log Analytics para identificar eventos de reconexão ou erros de plano de controle
Qual é a sequência correta de investigação para esse cenário?
A. 3 → 2 → 1 → 5 → 4
B. 4 → 1 → 3 → 5 → 2
C. 1 → 3 → 2 → 4 → 5
D. 2 → 4 → 3 → 1 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída do comando Get-AzVirtualNetworkGatewayLearnedRoute: a tabela contém apenas a rota da própria VNet (10.0.0.0/16 com origem Network), sem nenhuma rota aprendida via BGP de origem EBgp. Isso indica que o gateway não está recebendo anúncios de rota do lado on-premises. Quando o roteador on-premises para de anunciar prefixos via BGP, o gateway não tem como saber como chegar aos destinos locais, e o tráfego das VMs simplesmente não encontra caminho de retorno.
A informação sobre a política de firewall aplicada pela equipe de segurança é a informação irrelevante inserida propositalmente. Ela descreve regras de saída para internet, o que não afeta o plano de controle BGP do ExpressRoute. A alternativa C tenta explorar essa informação para desviar o diagnóstico.
A alternativa A é incorreta porque manutenção automática de gateway não suspende o encaminhamento silenciosamente; o estado do gateway refletiria isso. A alternativa D é plausível, mas seria refutada pelo fato de que a connection resource ainda aparece como "Connected"; uma queda de peering BGP acabaria refletindo no estado da conexão ou seria visível via Get-AzVirtualNetworkGatewayBGPPeerStatus. O distrator mais perigoso é o C, pois aproveita uma informação real do enunciado para induzir o engenheiro a investigar no lugar errado.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é que o engenheiro tem apenas acesso de leitura na assinatura do circuito. A operação de gerar um novo Authorization Key requer permissão de escrita nessa assinatura. Portanto, o engenheiro não pode executar essa etapa sozinho. A ação correta é escalar imediatamente para o proprietário da assinatura do circuito, pois a janela de manutenção ainda tem 20 minutos disponíveis, tempo suficiente para um procedimento que envolve gerar uma chave e recriar uma connection resource.
A alternativa A descreve a sequência técnica correta, mas ignora a restrição de permissão: o engenheiro não conseguiria solicitar a geração da chave por si mesmo. A alternativa B seria a ação mais elegante se fosse possível, mas Authorization Keys não são campos editáveis in-place em uma connection resource existente; a connection precisa ser recriada. A alternativa D é o distrator mais conservador e representa o erro de paralisia por excesso de cautela: 20 minutos são suficientes para o procedimento se o time on-premises já está disponível.
Gabarito — Cenário 3
Resposta: B
O ExpressRoute não funciona como roteador de trânsito entre VNets. Mesmo que duas VNets estejam conectadas ao mesmo circuito, o tráfego entre elas não é roteado pelo circuito. Cada VNet aprende as rotas on-premises a partir do circuito, mas o prefixo de uma VNet não é propagado para a outra VNet via ExpressRoute. Para que VNet-A e VNet-B se comuniquem, é necessário configurar VNet peering entre elas, ou usar uma arquitetura hub-spoke com gateway transit habilitado.
A pista que confirma essa causa está na tabela: nenhuma das VNets tem peering configurada com a outra, e o prefixo 10.1.0.0/16 não aparece nas rotas aprendidas pelo gateway da VNet-B. O fato de o roteador on-premises anunciar corretamente os prefixos é a informação irrelevante: ela confirma que o circuito funciona corretamente para o caminho VNet-to-on-premises, mas não tem relação com a ausência de comunicação VNet-to-VNet.
A alternativa A é um distrator que explora uma confusão real sobre compatibilidade de SKUs: SKUs diferentes não impedem a conexão ao mesmo circuito. A alternativa C é incorreta porque o limite de VNets do tipo Standard diz respeito ao número de conexões, não à capacidade de operar múltiplas conexões simultâneas. A alternativa D representa um equívoco sobre como o BGP funciona no ExpressRoute: os prefixos de VNet são anunciados automaticamente.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 3 → 2 → 1 → 5 → 4.
O raciocínio diagnóstico parte do nível mais fundamental para o mais granular:
Primeiro, confirmar se o circuito ainda está com provider provisioning state = "Provisioned" (passo 3), pois uma mudança nesse estado invalidaria toda investigação subsequente no plano de controle do Azure. Em seguida, verificar se há manutenção programada pelo provedor (passo 2), que é uma causa externa e frequente de degradação parcial não visível no portal. Depois, verificar o estado do BGP peer (passo 1) para confirmar se o plano de controle está intacto. Na sequência, analisar os logs de diagnóstico do gateway (passo 5) para identificar eventos de reconexão ou erros que confirmem ou refutem a hipótese. Por fim, executar testes de latência e perda (passo 4) para quantificar e documentar o impacto, o que é útil para abertura de chamado com o provedor, mas não é o primeiro passo em um diagnóstico sob pressão.
A alternativa B erra ao começar pelo teste de latência (passo 4), que mede o sintoma em vez de investigar a causa. A alternativa C começa pelo BGP (passo 1), o que é prematuro sem antes validar se o circuito está provisionado. A alternativa D começa pela manutenção do provedor, o que seria razoável, mas coloca o teste de latência como segundo passo, antes de qualquer validação do plano de controle.
Árvore de Troubleshooting: Connect a virtual network to an ExpressRoute circuit
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (#1a1a2e) | Sintoma inicial (ponto de entrada) |
| Azul (#0077b6) | Pergunta diagnóstica |
| Vermelho (#d62828) | Causa identificada |
| Verde (#2d6a4f) | Ação recomendada ou resolução |
Diante de uma falha real, inicie sempre pelo nó raiz e responda cada pergunta com base no que é observável no portal, em comandos PowerShell ou CLI, ou em informações do provedor. Cada ramificação elimina uma classe de causas e conduz progressivamente ao nó de causa identificada. Ao chegar a um nó vermelho, a causa está confirmada e o nó verde seguinte indica a ação imediata. Nunca pule perguntas intermediárias: um sintoma de alto nível como "sem conectividade" pode ter origens no plano físico, no plano de controle BGP ou na lógica de roteamento da VNet, e cada nível exige validação independente antes de agir.