Laboratório de Troubleshooting: Configure Virtual Hub Routing
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que VMs em VNet-Prod não conseguem alcançar VMs em VNet-Shared, ambas conectadas ao mesmo Virtual WAN hub na região East US. O hub tem duas Route Tables configuradas: RT-Prod e defaultRouteTable.
A equipe informa que o problema começou logo após uma reorganização das conexões realizada ontem à noite. Ela também menciona que o peering entre VNet-Prod e o hub foi recriado durante a janela de manutenção, e que o status da connection no portal aparece como Succeeded. O time de segurança confirma que os NSGs aplicados às VMs não foram alterados e que as regras permitem o tráfego na porta 443.
A inspeção da configuração atual revela:
VNet-Prod connection:
Association: RT-Prod
Propagation: RT-Prod
VNet-Shared connection:
Association: defaultRouteTable
Propagation: defaultRouteTable
RT-Prod não contém rotas aprendidas de VNet-Shared. defaultRouteTable contém a rota para o prefixo de VNet-Prod.
Qual é a causa raiz da falha de conectividade?
A) Os NSGs nas VMs de VNet-Prod estão bloqueando o tráfego de retorno de VNet-Shared, mesmo sem alteração declarada pela equipe de segurança.
B) A connection de VNet-Shared não propaga suas rotas para RT-Prod, portanto VNet-Prod nunca aprende o prefixo de VNet-Shared.
C) A connection de VNet-Prod propaga apenas para RT-Prod, o que impede que outros recursos aprendam a rota de volta para VNet-Prod.
D) O status Succeeded da connection indica apenas que o objeto foi criado, mas o peering ainda pode estar em estado de sincronização incompleta causando perda de rotas.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o Routing Intent com política de tráfego privado foi habilitado no hub de produção durante uma mudança aprovada, mas o Azure Firewall configurado como próximo salto ainda não concluiu o provisionamento. O status do Firewall no portal é Updating.
O ambiente possui as seguintes restrições:
- Aproximadamente 40 VNet connections estão associadas ao hub
- Todas as conexões de Site-to-Site VPN de filiais dependem do hub para rotear tráfego entre si
- O SLA de disponibilidade do ambiente é de 99,9% e o incidente já está aberto há 22 minutos
- O time de rede possui permissão de Contributor no hub, mas não possui permissão para modificar políticas de Firewall Manager
- Reverter o Routing Intent requer permissão de escrita no recurso de Routing Intent, que o time possui
Qual é a ação correta a tomar neste momento?
A) Aguardar a conclusão do provisionamento do Azure Firewall, pois o Routing Intent estabiliza automaticamente assim que o Firewall fica disponível, sem necessidade de intervenção.
B) Remover o Routing Intent imediatamente para restaurar o roteamento anterior e abrir um chamado para o time responsável pelo Firewall Manager completar o provisionamento em uma próxima janela controlada.
C) Criar rotas estáticas manuais em cada Route Table do hub apontando os prefixos RFC 1918 diretamente para as connections de destino, contornando o Routing Intent sem removê-lo.
D) Solicitar ao time de Firewall Manager que force o reprovisioning do Azure Firewall via portal, pois essa ação não impacta as conexões existentes e resolve o estado Updating em menos de 5 minutos.
Cenário 3 — Causa Raiz
Um arquiteto sênior recebe um alerta: VMs em VNet-App (Hub-A, região Brazil South) não conseguem alcançar VMs em VNet-DB (Hub-B, região East US). Ambos os hubs pertencem à mesma Virtual WAN.
O arquiteto verifica o seguinte:
Hub-A:
Status: Succeeded
VNet-App connection: Associated=defaultRouteTable, Propagates=defaultRouteTable
defaultRouteTable rotas aprendidas:
10.10.0.0/16 --> VNet-App connection
10.30.0.0/16 --> Hub-B (inter-hub)
Hub-B:
Status: Succeeded
VNet-DB connection: Associated=defaultRouteTable, Propagates=defaultRouteTable
defaultRouteTable rotas aprendidas:
10.20.0.0/16 --> VNet-DB connection
10.10.0.0/16 --> Hub-A (inter-hub)
O arquiteto também confirma que não há Route Tables customizadas em nenhum dos hubs, que o peering entre os hubs está ativo, e que nenhuma mudança de configuração foi realizada nos últimos 7 dias. Um colega sugere que o problema pode ser o prefixo de VNet-DB (10.20.0.0/16) não estar aparecendo na defaultRouteTable do Hub-A.
O arquiteto executa o seguinte comando:
az network vhub route-table route list \
--resource-group rg-vwan \
--vhub-name Hub-A \
--name defaultRouteTable
Saída:
[
{ "destinations": ["10.10.0.0/16"], "nextHopType": "ResourceId", "nextHops": ["...VNet-App-connection"] },
{ "destinations": ["10.30.0.0/16"], "nextHopType": "ResourceId", "nextHops": ["...Hub-B-connection"] }
]
Qual é a causa raiz do problema?
A) O prefixo 10.20.0.0/16 de VNet-DB não está sendo propagado do Hub-B para o Hub-A, indicando que a connection de VNet-DB não está propagando suas rotas para a defaultRouteTable do Hub-B.
B) O peering inter-hub está ativo mas operando em modo read-only devido a um estado de sincronização pendente, impedindo a troca de rotas entre os hubs.
C) A ausência do prefixo 10.20.0.0/16 na defaultRouteTable do Hub-A é causada por um bug de propagação inter-hub que requer abertura de chamado ao suporte da Microsoft.
D) A rota 10.30.0.0/16 presente na defaultRouteTable do Hub-A representa um prefixo diferente do prefixo de VNet-DB, indicando que o espaço de endereçamento configurado na connection de VNet-DB no Hub-B está incorreto ou não coincide com o prefixo real da VNet.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: tráfego de branches conectados via Site-to-Site VPN a um Virtual WAN hub está chegando corretamente ao hub, mas não está alcançando VMs em uma VNet spoke conectada ao mesmo hub. O hub não possui Routing Intent habilitado e não há NVAs no ambiente.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se a VPN connection do branch está propagando rotas para a Route Table à qual a VNet spoke connection está associada.
- Confirmar se o status da VNet spoke connection no hub é Succeeded e se o peering está provisionado corretamente.
- Verificar se existem rotas aprendidas do prefixo do branch na Route Table associada à VNet spoke connection.
- Executar um teste de conectividade ponta a ponta (ex: ping ou traceroute) a partir de uma VM no branch para confirmar onde o tráfego para.
- Checar se a Route Table associada à VNet spoke connection contém a rota de retorno para o prefixo do branch.
Qual é a sequência correta de investigação?
A) 4 → 2 → 3 → 1 → 5
B) 2 → 4 → 1 → 3 → 5
C) 4 → 2 → 1 → 3 → 5
D) 2 → 3 → 1 → 4 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na tabela de configuração: VNet-Shared propaga apenas para defaultRouteTable, e VNet-Prod está associada a RT-Prod. Como VNet-Prod só aprende o que é propagado para RT-Prod, e VNet-Shared nunca propaga para RT-Prod, o prefixo de VNet-Shared nunca aparece na tabela de roteamento efetiva de VNet-Prod. O resultado é a ausência de rota para o destino, o que provoca descarte silencioso dos pacotes.
A informação irrelevante no cenário é o status dos NSGs. Os NSGs não foram alterados e a equipe de segurança confirmou as regras: esse dado existe para desviar o raciocínio para a camada 4, mas o problema é de roteamento na camada de controle do hub.
O distrator C descreve o impacto inverso: a propagação de VNet-Prod para RT-Prod afeta o que outros aprendem sobre VNet-Prod, não o que VNet-Prod aprende sobre outros. O distrator D é tecnicamente possível em teoria, mas contradiz a informação de que o status é Succeeded, que no Virtual WAN indica provisionamento completo do peering.
Gabarito — Cenário 2
Resposta: B
A restrição crítica é o SLA de 99,9% e o incidente já em andamento há 22 minutos, combinado com o fato de que o time possui permissão para reverter o Routing Intent. Remover o Routing Intent é a ação que restaura imediatamente o comportamento anterior de roteamento para todas as 40 connections e para os branches de VPN, sem depender de uma permissão que o time não possui (Firewall Manager).
O distrator A ignora o impacto operacional ativo: aguardar é aceitável apenas quando não há degradação de serviço, o que não é o caso. O distrator C é tecnicamente inválido porque criar rotas estáticas manuais coexistindo com um Routing Intent habilitado pode gerar conflitos de roteamento imprevisíveis e não resolve a causa raiz. O distrator D pressupõe que o time tem permissão de ação sobre o Firewall Manager e que a operação é segura e rápida, nenhuma das quais é confirmada pelo cenário.
Gabarito — Cenário 3
Resposta: A
A saída do comando mostra que a defaultRouteTable do Hub-A contém apenas dois prefixos: o da própria VNet-App e o 10.30.0.0/16, que não corresponde ao prefixo de VNet-DB (10.20.0.0/16). O prefixo de VNet-DB simplesmente não existe na tabela do Hub-A.
A lógica de propagação inter-hub funciona assim: Hub-B só anuncia para Hub-A os prefixos que foram propagados para sua defaultRouteTable. Se a connection de VNet-DB no Hub-B não estiver propagando para defaultRouteTable, Hub-B não tem o prefixo para anunciar ao Hub-A.
A informação irrelevante é a sugestão do colega: ela descreve corretamente o sintoma (prefixo ausente no Hub-A), mas não aponta a causa. O sintoma já é visível na saída do comando; o que importa é por que o prefixo não chegou.
O distrator D é o mais perigoso: ele propõe que o espaço de endereçamento está errado no Hub-B, o que desviaria o engenheiro para verificar a VNet em si, quando a causa está na configuração de propagação da connection.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 4 → 2 → 3 → 1 → 5
O raciocínio diagnóstico progressivo parte do sintoma observável para as camadas de controle:
- Passo 4 primeiro: confirmar onde o tráfego realmente para antes de assumir qualquer hipótese. Um traceroute revela se o tráfego sequer sai do branch, chega ao hub ou para antes da VNet spoke.
- Passo 2: confirmar que a connection da VNet spoke está provisionada corretamente. Se o peering não está ativo, nenhuma rota funcionará independentemente da configuração.
- Passo 3: verificar se a Route Table associada à VNet spoke contém rotas para o prefixo do branch. Se não há rota, o hub descarta o tráfego antes de encaminhá-lo.
- Passo 1: identificar se a VPN connection está propagando para a Route Table correta. Essa é a causa mais provável se a rota estiver ausente no passo 3.
- Passo 5: verificar a rota de retorno, que é relevante para confirmar bidirecionalidade após os demais passos.
O distrator B inverte os passos 4 e 2, iniciando pela verificação da connection antes de confirmar o comportamento observado na rede, o que pode levar a conclusões precipitadas sobre a causa. O distrator D omite completamente o teste de conectividade ponta a ponta, removendo a âncora empírica do diagnóstico.
Árvore de Troubleshooting: Configure Virtual Hub Routing
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (marinho) | Sintoma inicial, ponto de entrada da investigação |
| Azul | Pergunta diagnóstica, decisão binária ou verificável |
| Vermelho | Causa identificada ou ação corretiva direta |
| Laranja | Validação ou verificação intermediária antes de concluir |
Para usar esta árvore diante de um incidente real, comece sempre pelo nó raiz descrevendo o sintoma de perda de conectividade. Responda cada pergunta com base no que você observa no portal ou via CLI, nunca com base em suposições. Cada resposta elimina um conjunto de hipóteses e conduz ao próximo nível de verificação. Quando atingir um nó vermelho, você tem a causa identificada e a ação recomendada. Quando atingir um nó laranja, execute a verificação descrita antes de concluir o diagnóstico, pois ela pode revelar um caminho diferente na árvore.