Laboratório de Troubleshooting: Design and implement ExpressRoute options, including Global Reach, FastPath, and ExpressRoute Direct
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de rede de uma empresa industrial relata que a conectividade entre o data center on-premises em Chicago e as VMs hospedadas em uma VNet no Azure foi interrompida após uma janela de manutenção realizada na véspera. O circuito ExpressRoute aparece como Provisioned no portal do Azure e o status do provedor também consta como Provisioned.
Durante a investigação, o engenheiro coleta as seguintes informações:
az network express-route show \
--name er-chicago-prod \
--resource-group rg-network \
--query "{circuitStatus:circuitProvisioningState, provider:serviceProviderProvisioningState}"
{
"circuitStatus": "Enabled",
"provider": "Provisioned"
}
az network express-route peering list \
--circuit-name er-chicago-prod \
--resource-group rg-network \
--query "[].{type:peeringType, state:state, primaryPrefix:primaryPeerAddressPrefix}"
[
{
"type": "AzurePrivatePeering",
"state": "Disabled",
"primaryPrefix": "10.0.0.0/30"
}
]
O engenheiro também verifica que o gateway de rede virtual associado à VNet está no estado Succeeded e que nenhuma rota foi alterada nas tabelas de roteamento on-premises durante a manutenção. O circuito foi migrado para um novo grupo de recursos nessa janela de manutenção.
Qual é a causa raiz da perda de conectividade?
A) O circuito foi movido para um novo grupo de recursos, o que desassocia automaticamente o gateway de rede virtual da connection resource
B) O peering privado foi desabilitado, impedindo o estabelecimento de sessões BGP entre os roteadores de borda da Microsoft e o equipamento on-premises
C) O gateway de rede virtual perdeu a rota estática para a rede on-premises após a migração do circuito
D) O prefixo de peering 10.0.0.0/30 está em conflito com o espaço de endereçamento da VNet, bloqueando a sessão BGP
Cenário 2 — Decisão de Ação
Uma empresa de logística utiliza ExpressRoute Global Reach para conectar seus data centers de São Paulo e de Buenos Aires pelo backbone da Microsoft. O time de segurança identificou que, por exigência regulatória do setor, o tráfego entre os dois sites on-premises não pode mais transitar pela rede da Microsoft a partir da meia-noite do próximo dia útil. Ambos os circuitos devem continuar operando normalmente para acessar as VNets no Azure, onde rodam sistemas críticos de rastreamento de cargas em produção contínua.
A causa está identificada: o Global Reach entre os dois circuitos precisa ser removido. A janela de manutenção aprovada é de 30 minutos, iniciando às 23h30 da noite anterior ao prazo regulatório.
Qual é a ação correta a tomar dentro da janela de manutenção?
A) Excluir ambos os circuitos ExpressRoute e reprovisioná-los sem habilitar o Global Reach, garantindo conformidade total
B) Remover apenas a associação de Global Reach entre os dois circuitos, preservando os circuitos e suas conexões com as VNets intactos
C) Desabilitar o peering privado em ambos os circuitos durante a janela e reabilitá-lo sem reconfigurar o Global Reach
D) Reconfigurar as tabelas de roteamento on-premises para bloquear os prefixos anunciados via Global Reach, sem alterar a configuração do Azure
Cenário 3 — Causa Raiz
Uma empresa de serviços financeiros provisionou ExpressRoute Direct com portas de 100 Gbps em uma localização de peering em Nova York. Sobre esse par de portas, foram criados três circuitos lógicos para três unidades de negócio diferentes. A equipe reporta que o circuito da terceira unidade de negócio, denominado er-direct-bu3, está com status NotProvisioned e nenhum tráfego flui por ele.
O engenheiro coleta os seguintes dados:
az network express-route list \
--resource-group rg-direct-ny \
--query "[].{name:name, bandwidth:serviceProviderProperties.bandwidthInMbps, state:circuitProvisioningState}"
[
{ "name": "er-direct-bu1", "bandwidth": 50000, "state": "Enabled" },
{ "name": "er-direct-bu2", "bandwidth": 40000, "state": "Enabled" },
{ "name": "er-direct-bu3", "bandwidth": 20000, "state": "NotProvisioned" }
]
O engenheiro também verifica que o peering privado do circuito er-direct-bu3 está configurado corretamente, que as sessões BGP estão tentando estabelecer, e que não há alertas de saúde no painel do ExpressRoute Direct Port no portal do Azure.
Qual é a causa raiz do estado NotProvisioned no terceiro circuito?
A) O peering privado do circuito er-direct-bu3 foi configurado antes do circuito ser habilitado, o que corrompe o estado de provisionamento
B) As sessões BGP não podem ser estabelecidas enquanto o circuito estiver em estado NotProvisioned, o que indica falha na camada física da porta
C) A soma das bandas dos três circuitos ultrapassa a capacidade da porta de 100 Gbps, impedindo o provisionamento do terceiro circuito
D) O circuito er-direct-bu3 pertence a um grupo de recursos diferente dos outros dois, o que bloqueia o provisionamento compartilhado sobre o mesmo ExpressRoute Direct Port
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "As VMs em uma VNet pareada via VNet Peering com a VNet principal não estão sendo alcançadas a partir do ambiente on-premises. A VNet principal tem conectividade on-premises normal via ExpressRoute. O FastPath está habilitado no gateway da VNet principal."
O engenheiro tem disponíveis os seguintes passos de investigação:
- Passo P: Verificar se o VNet Peering está configurado com a opção "Allow Gateway Transit" na VNet principal e "Use Remote Gateway" na VNet pareada
- Passo Q: Confirmar que o gateway de rede virtual está no estado Succeeded e associado ao circuito ExpressRoute correto
- Passo R: Verificar as tabelas de rotas efetivas nas NICs das VMs da VNet pareada para confirmar se a rota on-premises está presente
- Passo S: Confirmar que o FastPath está habilitado e que o tier do gateway é compatível com FastPath
- Passo T: Testar conectividade direta entre on-premises e uma VM da VNet principal para isolar se o problema é geral ou restrito à VNet pareada
Qual sequência de diagnóstico é a mais eficiente e tecnicamente correta para esse cenário?
A) S, Q, P, T, R
B) T, Q, P, R, S
C) Q, S, T, P, R
D) T, P, R, Q, S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída do comando de listagem de peerings: o AzurePrivatePeering está com "state": "Disabled". Sem o peering privado ativo, nenhuma sessão BGP pode ser estabelecida entre os MSEEs e o equipamento on-premises, e portanto nenhuma rota é trocada, interrompendo toda a conectividade de dados. O status do circuito e do provedor serem Provisioned e Enabled indica que a camada de provisionamento está correta, mas o plano de controle de roteamento está inativo.
A informação sobre a migração de grupo de recursos é a armadilha irrelevante do cenário. Mover um circuito entre grupos de recursos no Azure não altera o estado dos peerings nem desassocia conexões; é uma operação de metadados de gestão, não de configuração de rede.
O distrator mais perigoso é A, pois a migração de grupo de recursos é mencionada explicitamente no enunciado e cria uma correlação temporal convincente mas falsa. Agir com base nesse distrator levaria o engenheiro a recriar a connection resource e o gateway sem resolver o peering desabilitado, mantendo a falha.
Gabarito — Cenário 2
Resposta: B
O Global Reach é uma associação pontual entre dois circuitos específicos. Remover essa associação encerra exclusivamente o caminho entre os dois sites on-premises, sem afetar a conectividade de nenhum dos circuitos com as VNets do Azure. Essa é exatamente a ação cirúrgica que o cenário exige: cumprir a exigência regulatória sem introduzir downtime nos sistemas críticos de produção.
A alternativa A representa a ação tecnicamente nuclear: excluir os circuitos interromperia toda a conectividade Azure, incluindo os sistemas de rastreamento em produção, causando um impacto gravíssimo que as restrições do cenário proíbem explicitamente. A alternativa C, desabilitar o peering privado, também derrubaria a conectividade com as VNets, violando a mesma restrição. A alternativa D resolve o problema apenas localmente em um dos sites on-premises e não é uma solução gerenciada pelo Azure; além disso, não garante que o outro site também bloqueie o tráfego.
Gabarito — Cenário 3
Resposta: C
A soma das bandas dos três circuitos é 50.000 + 40.000 + 20.000 = 110.000 Mbps (110 Gbps), o que ultrapassa a capacidade total da porta de 100 Gbps. O ExpressRoute Direct não permite que a soma das bandas dos circuitos lógicos provisionados sobre o mesmo par de portas exceda a capacidade contratada. Por isso, o terceiro circuito, que foi o último a ser criado, fica em estado NotProvisioned.
A informação sobre as sessões BGP tentando estabelecer e sobre o peering privado estar configurado corretamente é irrelevante nesse contexto: o problema ocorre na camada de capacidade de banda, antes mesmo de qualquer negociação BGP. O painel do ExpressRoute Direct Port sem alertas pode confundir o diagnóstico, mas alertas de saúde da porta física são distintos de alertas de capacidade de banda alocada.
O distrator mais perigoso é B, pois o estado NotProvisioned de fato impede o BGP, mas o engenheiro estaria confundindo sintoma com causa. Investigar a camada física seria um caminho caro e demorado sem resultado.
Gabarito — Cenário 4
Resposta: B
A sequência correta é T, Q, P, R, S, que segue a lógica de diagnóstico progressivo do geral para o específico:
- T primeiro: confirmar que a VNet principal tem conectividade on-premises normal isola se o problema é geral (circuito ou gateway) ou restrito à VNet pareada. Se T falhar, o escopo muda completamente.
- Q segundo: validar o estado do gateway garante que a infraestrutura de base está saudável antes de investigar configurações de peering.
- P terceiro: verificar as configurações de "Allow Gateway Transit" e "Use Remote Gateway" é o passo mais provável de conter a causa raiz nesse cenário, pois sem essas opções a VNet pareada não recebe as rotas on-premises via o gateway da VNet principal.
- R quarto: inspecionar as rotas efetivas nas NICs da VNet pareada confirma se as rotas on-premises estão de fato sendo propagadas após validar P.
- S por último: verificar a compatibilidade do FastPath é relevante, mas o FastPath não afeta a alcançabilidade de VNets pareadas, portanto deve ser o último passo, apenas para descartar hipótese secundária.
Começar por S (alternativa A) seria o erro mais comum, pois o FastPath é explicitamente mencionado no enunciado e atrai atenção, mas ele não é a causa de falhas em VNets pareadas.
Árvore de Troubleshooting: Design and Implement ExpressRoute Options
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta de diagnóstico |
| Vermelho | Causa identificada ou estado de falha |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o sintoma de conectividade. A cada nó de pergunta, observe o que é verificável diretamente: estado de provisionamento no portal, saída de comandos CLI, estado do BGP, configurações de peering. Siga o caminho correspondente ao que você observa até chegar a um nó vermelho (causa identificada) ou verde (ação recomendada). Nunca pulem etapas: a ordem das perguntas foi desenhada para eliminar hipóteses progressivamente, do mais geral para o mais específico, evitando ações corretivas prematuras que podem ampliar o impacto.