Laboratório de Troubleshooting: Create and configure an ExpressRoute gateway
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que o provisionamento de um ExpressRoute gateway falhou após 45 minutos de execução. O ambiente de destino é uma VNet de produção recém-criada na região East US 2. O time informa que a assinatura tem cotas disponíveis, que o SKU escolhido foi ErGw2AZ e que a operação foi executada por um usuário com papel de Network Contributor na VNet.
A saída do portal no momento da falha foi:
Deployment failed
Resource: Microsoft.Network/virtualNetworkGateways
Error code: GatewaySubnetNotFound
Message: The GatewaySubnet was not found in the virtual network
'vnet-prod-eastus2'. A subnet named 'GatewaySubnet' is
required to deploy a virtual network gateway.
O time verifica que existe uma subnet chamada gateway-subnet com prefixo /27 e que ela não possui nenhum Network Security Group associado. A equipe de segurança confirma que nenhuma política de bloqueio foi aplicada sobre essa subnet.
Qual é a causa raiz da falha no provisionamento?
A) O prefixo /27 é insuficiente para o SKU ErGw2AZ, que exige no mínimo /26
B) O nome da subnet está incorreto; o Azure exige obrigatoriamente o nome exato GatewaySubnet
C) O papel Network Contributor não tem permissão para provisionar gateways de rede virtual
D) SKUs zonais como ErGw2AZ exigem que a subnet esteja associada a uma zona de disponibilidade específica antes do provisionamento
Cenário 2 — Decisão de Ação
A causa raiz já foi identificada: o ExpressRoute gateway de uma VNet de produção está configurado com o SKU Standard, que não suporta ExpressRoute FastPath. O time de arquitetura aprovou a migração para o SKU UltraPerformance para habilitar esse recurso. O gateway atualmente tem duas conexões ativas com circuitos ExpressRoute em uso por cargas de trabalho críticas com SLA de 99,9%.
As restrições do momento são:
- A janela de manutenção programada começa em 6 horas
- Não há aprovação para impacto em produção fora da janela
- A atualização de SKU de gateway no Azure causa interrupção temporária das conexões
Qual é a ação correta a tomar neste momento?
A) Iniciar imediatamente a atualização de SKU para aproveitar o tempo disponível antes da janela e concluir antes do pico de uso
B) Aguardar a janela de manutenção aprovada e executar a atualização de SKU dentro do período autorizado
C) Criar um novo gateway com SKU UltraPerformance em paralelo e migrar as conexões agora, evitando a atualização in-loco
D) Remover as conexões ativas, atualizar o SKU imediatamente e recriar as conexões antes da janela de manutenção
Cenário 3 — Causa Raiz
Um engenheiro de rede está investigando por que uma VNet não consegue receber rotas anunciadas por um circuito ExpressRoute recém-associado. O gateway já está no estado Succeeded e a conexão entre o gateway e o circuito também aparece como Succeeded no portal. O circuito foi confirmado pelo provedor como provisionado e ativo.
O engenheiro executa o seguinte comando para verificar as rotas aprendidas:
az network vnet-gateway list-learned-routes \
--name ergw-prod \
--resource-group rg-network \
--output table
A saída retorna uma tabela vazia, sem nenhuma rota listada. O engenheiro verifica que o SKU do gateway é ErGw1AZ, que a GatewaySubnet tem prefixo /27 e que não há nenhum Route Table associado à GatewaySubnet. O time do provedor confirma que o peering privado do circuito está configurado, mas que a sessão BGP ainda não foi estabelecida com o lado do Azure.
Qual é a causa raiz da ausência de rotas aprendidas?
A) O SKU ErGw1AZ não suporta aprendizado de rotas via BGP e deve ser atualizado para ErGw2AZ
B) A ausência de um Route Table na GatewaySubnet impede o gateway de propagar rotas recebidas para a VNet
C) A sessão BGP entre o peering privado e o gateway ainda não foi estabelecida, portanto nenhuma rota foi trocada
D) O comando list-learned-routes requer que o gateway esteja no modo ativo-ativo para retornar resultados
Cenário 4 — Sequência de Diagnóstico
Um operador recebe o seguinte relato: "Após uma reconfiguração de rede realizada ontem à noite, as VMs em uma VNet de produção pararam de acessar recursos no ambiente on-premises via ExpressRoute. O gateway está no estado Succeeded e o circuito está Enabled."
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se a sessão BGP do peering privado está no estado
Connectedno portal do circuito - Confirmar se a conexão entre o gateway e o circuito está no estado
Succeeded - Executar
az network vnet-gateway list-learned-routespara verificar se o gateway está recebendo rotas do on-premises - Verificar se as rotas aprendidas estão sendo propagadas para as tabelas de rota das subnets da VNet
- Testar conectividade de uma VM específica usando
Test-NetConnectionpara o IP de destino on-premises
Qual sequência representa a ordem correta de diagnóstico progressivo?
A) 5, 1, 2, 3, 4
B) 2, 1, 3, 4, 5
C) 1, 3, 2, 4, 5
D) 3, 2, 1, 5, 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro é direta: GatewaySubnetNotFound. O Azure exige que a subnet utilizada por qualquer virtual network gateway, incluindo o ExpressRoute gateway, tenha o nome exato GatewaySubnet, com essa capitalização. O nome gateway-subnet não é reconhecido pela plataforma como a subnet reservada para esse fim, independentemente de prefixo, NSG ou permissões.
A pista confirmadora está na própria mensagem de erro, que nomeia explicitamente o que não foi encontrado.
As informações sobre ausência de NSG e cotas disponíveis são irrelevantes para esse diagnóstico e foram incluídas propositalmente para induzir o leitor a investigar uma direção errada. O prefixo /27 é adequado para produção, portanto a alternativa A é um distrator baseado em um requisito mal aplicado. A alternativa C é incorreta porque Network Contributor tem permissão para criar gateways. A alternativa D não corresponde a nenhum comportamento real da plataforma Azure.
O distrator mais perigoso é o C: atribuir o erro a permissões insuficientes pode levar a uma escalada desnecessária enquanto o problema real permanece sem solução.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é que não há aprovação para impacto em produção fora da janela de manutenção. A atualização de SKU de um ExpressRoute gateway causa interrupção temporária das conexões ativas, o que configura impacto direto nas cargas de trabalho com SLA de 99,9%. Executar a operação antes da janela autorizada viola o processo aprovado e expõe o ambiente a risco sem autorização.
A alternativa A ignora a restrição de aprovação, que é uma restrição de processo, não apenas técnica. A alternativa C é tecnicamente válida como estratégia de migração sem downtime, mas a questão não diz que essa abordagem foi aprovada ou planejada, e criar um novo gateway em paralelo também pode impactar o ambiente sem autorização prévia. A alternativa D combina remoção de conexões ativas com atualização imediata, o que representa o maior risco possível ao SLA.
A disciplina de não agir antes da janela aprovada é a habilidade central testada neste cenário.
Gabarito — Cenário 3
Resposta: C
O estado Succeeded da conexão no portal indica que o recurso de conexão foi criado com sucesso no plano de controle do Azure, mas não garante que a sessão BGP tenha sido estabelecida no plano de dados. Sem uma sessão BGP ativa no peering privado, nenhuma rota é trocada entre o lado on-premises e o gateway, o que explica a tabela vazia retornada pelo comando.
A pista confirmadora está na afirmação do provedor: "a sessão BGP ainda não foi estabelecida com o lado do Azure." Essa informação diretamente explica o sintoma observado.
A ausência de Route Table na GatewaySubnet é irrelevante para o estabelecimento de sessão BGP e não impede o aprendizado de rotas. O SKU ErGw1AZ suporta BGP normalmente. O comando list-learned-routes funciona independentemente do modo ativo-ativo. Esses três pontos foram incluídos como informações plausíveis mas irrelevantes para filtrar o raciocínio.
O distrator mais perigoso é o B: focar na ausência do Route Table pode levar o engenheiro a criar configurações desnecessárias sem resolver o problema real, que está no plano de controle BGP do circuito.
Gabarito — Cenário 4
Resposta: B
A sequência correta de diagnóstico progressivo é: 2, 1, 3, 4, 5.
O raciocínio parte do componente mais próximo do gateway em direção ao destino final:
| Passo | Ação | Lógica |
|---|---|---|
| 1 | Verificar estado da conexão (Succeeded) | Confirma se o vínculo gateway-circuito existe no plano de controle |
| 2 | Verificar sessão BGP do peering privado | Confirma se o plano de dados está operacional |
| 3 | Listar rotas aprendidas pelo gateway | Confirma se rotas on-premises estão chegando ao Azure |
| 4 | Verificar propagação para tabelas de rota das subnets | Confirma se as rotas chegam às VMs |
| 5 | Testar conectividade de uma VM específica | Valida o comportamento real de ponta a ponta |
Iniciar pelo teste de conectividade da VM (alternativa A) é o erro mais comum: testar o sintoma sem qualquer diagnóstico intermediário não indica onde está a falha. A alternativa C inverte a verificação de conexão e BGP, o que impede isolar rapidamente se o problema está no plano de controle ou no plano de dados. A alternativa D começa pelas rotas aprendidas sem primeiro confirmar se os componentes anteriores estão operacionais.
Árvore de Troubleshooting: Create and configure an ExpressRoute gateway
Legenda de cores:
- Azul escuro: sintoma inicial ou ponto de entrada do diagnóstico
- Azul médio: pergunta diagnóstica objetiva com ramificação sim/não
- Vermelho: causa identificada que requer investigação externa ou aprofundada
- Verde: ação recomendada ou estado de resolução
- Laranja: nó de validação ou verificação intermediária
Para usar esta árvore diante de um problema real, comece pelo nó raiz que representa o sintoma observado e responda cada pergunta de diagnóstico com base no que é diretamente verificável no portal ou via CLI. Siga o caminho correspondente à resposta até chegar a um nó de causa identificada ou ação recomendada. Não pule níveis: a ordem das perguntas reflete a dependência entre os componentes do ExpressRoute gateway, do plano de controle ao plano de dados.