Laboratório de Troubleshooting: Integrate a virtual hub with a third-party NVA for cloud connectivity
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa opera um Virtual WAN hub na região East US com um NVA de terceiros integrado. O ambiente foi configurado há três semanas e funcionava normalmente. Após uma atualização de configuração realizada pela equipe de segurança na sexta-feira à noite, branches conectados via Site-to-Site VPN começaram a reportar perda total de conectividade com workloads nas VNets spoke na manhã de segunda-feira.
O time de rede verificou o seguinte:
Hub: eastus-vwan-hub
NVA Status: Running (plano de controle saudável)
VPN Gateway: Active-Active, ambas as instâncias UP
BGP Sessions (branch -> hub): Established
Spoke VNet A (10.10.0.0/16): Connected to hub
Spoke VNet B (10.20.0.0/16): Connected to hub
Routing Intent: Private Traffic -> NVA (enabled)
Teste de conectividade (branch 192.168.1.0/24 -> 10.10.1.5):
ICMP: Request timeout
Traceroute: Último hop alcançado = NVA internal IP (10.0.255.4)
Próximo hop: sem resposta
A equipe de segurança informou que a atualização envolveu revisão das Network Security Groups associados à subnet de gerenciamento do NVA e rotação das credenciais de acesso ao painel administrativo do appliance. O fabricante confirmou que o NVA está recebendo os pacotes corretamente.
Qual é a causa raiz da perda de conectividade?
A) A rotação de credenciais do painel administrativo corrompeu o estado da sessão BGP entre o NVA e o hub, derrubando as rotas anunciadas para as spokes.
B) Uma regra no NSG da subnet de gerenciamento está bloqueando o tráfego de dados que passa pelo NVA, impedindo o encaminhamento dos pacotes para as VNets spoke.
C) O NVA está recebendo os pacotes, mas uma configuração de forwarding ou política interna do appliance foi alterada durante a manutenção, impedindo que os pacotes sejam encaminhados para o próximo destino.
D) O Routing Intent foi desativado automaticamente após a atualização do hub, fazendo com que as rotas para as spokes deixassem de ser programadas nas conexões VPN.
Cenário 2 — Decisão de Ação
A causa de uma falha foi identificada com precisão: o Routing Intent de um Virtual WAN hub em produção foi configurado com a política de tráfego privado apontando para o NVA errado. Há dois NVAs integrados ao hub: o NVA-A, destinado a tráfego de branches, e o NVA-B, destinado exclusivamente a tráfego de internet. A política privada está apontando para o NVA-B.
O contexto operacional é o seguinte:
Ambiente: Produção ativa
Impacto atual: Branches conseguem alcançar as spokes, mas o tráfego
está sendo inspecionado pelo NVA errado (NVA-B),
sem perda de conectividade visível para os usuários
Janela de manutenção aprovada: Próxima sexta-feira, 23h
Tempo atual: Terça-feira, 14h
Permissão para mudança emergencial: Não concedida
Dependência crítica: NVA-B sustenta toda a inspeção de tráfego de
saída de internet de 3 aplicações de missão crítica
Qual é a ação correta a tomar neste momento?
A) Redirecionar imediatamente o Routing Intent de tráfego privado para o NVA-A, pois a configuração incorreta representa um risco de segurança que justifica mudança fora de janela.
B) Aguardar a janela de manutenção aprovada e documentar o estado atual, pois não há perda de conectividade ativa, a mudança não tem aprovação emergencial e uma reconfiguração do Routing Intent pode afetar temporariamente o NVA-B e as aplicações que dele dependem.
C) Escalar para o fabricante do NVA-B a solicitação de criação de uma política de inspeção separada dentro do appliance, para que ele trate os dois tipos de tráfego simultaneamente até a janela de manutenção.
D) Criar uma rota estática no hub apontando os prefixos das spokes diretamente para o NVA-A, contornando o Routing Intent configurado incorretamente sem modificá-lo.
Cenário 3 — Causa Raiz
Um engenheiro está integrando um NVA de terceiros recém-aprovado pelo programa de parceiros da Microsoft a um Virtual WAN hub existente na região West Europe. O provisionamento do recurso NVA no portal foi concluído com status Succeeded. No entanto, ao tentar configurar o Routing Intent para tráfego privado apontando para o novo NVA, o portal apresenta o seguinte comportamento:
Tentativa de configurar Routing Intent:
Policy: Private Traffic
Next-hop: NVA-WE-01 (recém-provisionado)
Resultado:
Erro: "The selected resource cannot be used as a next-hop
for Routing Intent. Verify the NVA infrastructure
unit configuration."
Hub existente:
Azure Firewall: Nao configurado
Routing Intent anterior: Nao configurado
NVA scale units: 0 (recentemente provisionado, sem unidades ativas)
Conexoes VPN ativas: 4 branches
Conexoes VNet: 6 spokes
O engenheiro verifica que o recurso NVA aparece na lista de recursos do hub e que o fabricante confirmou que a oferta do Marketplace está na versão mais recente. O hub foi criado há 18 meses e nunca teve Routing Intent configurado anteriormente.
Qual é a causa raiz do erro ao configurar o Routing Intent?
A) O hub foi criado há mais de 12 meses e requer uma atualização de versão de infraestrutura antes de suportar Routing Intent com NVAs de terceiros.
B) O NVA foi provisionado com zero scale units ativas, e o Routing Intent exige que o NVA tenha ao menos uma unidade de escala operacional para ser elegível como next-hop.
C) A presença de conexões VPN e VNet ativas no hub impede a ativação do Routing Intent, pois as conexões existentes precisam ser removidas e reconectadas após a configuração do intent.
D) O Routing Intent para tráfego privado só pode ser configurado quando há um Azure Firewall também presente no hub, atuando como fallback obrigatório.
Cenário 4 — Impacto Colateral
Um engenheiro identifica que o tráfego entre branches e spokes está sendo encaminhado pelo NVA integrado ao hub, mas com latência anormalmente alta (média de 180ms adicionais). Após investigação, conclui que as scale units do NVA estão subdimensionadas para o volume atual de tráfego: o hub está processando 4,2 Gbps e o NVA está configurado com 2 scale units, cada uma suportando até 1 Gbps.
Para resolver, o engenheiro aumenta as scale units de 2 para 6 diretamente no portal, durante horário comercial, sem notificar as equipes dependentes.
O aumento das scale units é aplicado com sucesso e a latência é resolvida.
Qual consequência secundária essa ação pode causar?
A) O aumento de scale units reconfigura automaticamente os ASNs BGP utilizados pelo NVA, exigindo que todas as sessões BGP com branches sejam reestabelecidas manualmente.
B) Durante o processo de adição de novas instâncias às scale units, pode ocorrer uma breve redistribuição de conexões ativas entre as instâncias, causando microinterrupções ou resets de sessões TCP em fluxos de longa duração.
C) O aumento de scale units acima de 4 unidades desabilita automaticamente o Routing Intent de tráfego privado, exigindo reconfiguração manual após a operação.
D) As novas scale units são adicionadas em uma subnet diferente dentro do hub, alterando os IPs internos do NVA e invalidando todas as rotas estáticas configuradas nas VNets spoke.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está no traceroute: os pacotes chegam ao IP interno do NVA e param ali, sem resposta do próximo hop. Isso confirma que o plano de controle do NVA está saudável (BGP estabelecido, status Running, NVA recebendo pacotes), mas o plano de dados está falhando no encaminhamento interno do appliance.
A informação sobre rotação de credenciais do painel administrativo é a pista relevante que aponta para uma alteração na configuração interna do NVA durante a manutenção: uma política de forwarding, uma ACL interna ou uma regra de roteamento dentro do appliance pode ter sido modificada ou redefinida durante o acesso administrativo.
A informação irrelevante do cenário é a revisão dos NSGs da subnet de gerenciamento: NSGs em subnets de gerenciamento controlam acesso ao plano de controle do NVA, não o fluxo de dados que passa pelo appliance. Como o BGP está estabelecido e o NVA está recebendo pacotes, o NSG claramente não é o bloqueador.
O distrator mais perigoso é a Alternativa B, que foca no NSG justamente porque ele foi mencionado na manutenção. Este é o padrão clássico de confundir o que foi alterado com o que causou o problema. Atuar com base nessa hipótese levaria a modificar NSGs sem efeito, atrasando o diagnóstico real.
Gabarito — Cenário 2
Resposta: B
A causa já está identificada e declarada no enunciado. A pergunta é exclusivamente sobre qual ação tomar dado o conjunto de restrições. As restrições críticas são: sem aprovação para mudança emergencial, sem perda de conectividade ativa para os usuários, e uma dependência real do NVA-B por aplicações de missão crítica.
Reconfigurar o Routing Intent é uma operação que momentaneamente afeta o plano de dados do hub. Executá-la sem janela aprovada e sem notificação das equipes dependentes coloca em risco as três aplicações que dependem do NVA-B para inspeção de internet, mesmo que o objetivo seja corrigir o NVA-A.
A Alternativa A representa uma decisão tecnicamente correta em termos de destino final, mas errada em termos de momento e contexto, pois ignora as restrições de governança e o risco real ao NVA-B. Este é o erro mais comum neste tipo de cenário: priorizar a correção técnica sobre a gestão de risco operacional.
A Alternativa D é tecnicamente problemática porque criar rotas estáticas que sobreponham o Routing Intent introduz inconsistência no modelo de roteamento do hub e pode gerar comportamentos imprevisíveis quando o Routing Intent for corrigido na janela de manutenção.
Gabarito — Cenário 3
Resposta: B
O erro retornado pelo portal é direto: "verify the NVA infrastructure unit configuration". A evidência confirmada no estado do hub é que as scale units estão configuradas como 0. Um NVA provisionado sem scale units ativas não tem capacidade de plano de dados e, portanto, não pode ser elegível como next-hop para Routing Intent. O provisionamento com status "Succeeded" indica apenas que o recurso foi registrado no hub, não que está operacional para encaminhamento de tráfego.
A informação irrelevante é a idade do hub (18 meses sem Routing Intent configurado). A compatibilidade com Routing Intent não é determinada pela data de criação do hub, mas pela versão de infraestrutura interna, que é gerenciada automaticamente pela Microsoft. Focar nesse detalhe levaria o engenheiro a abrir um chamado desnecessário.
O distrator mais perigoso é a Alternativa C, que implica que as conexões existentes precisariam ser removidas. Agir com base nessa hipótese causaria interrupção real de conectividade para os 4 branches e 6 spokes conectados, sem resolver o problema. A presença de conexões ativas não impede a ativação do Routing Intent em um hub existente.
Gabarito — Cenário 4
Resposta: B
Quando novas instâncias são adicionadas ao pool de scale units de um NVA integrado ao Virtual WAN hub, o balanceamento interno de carga redistribui os fluxos ativos entre as instâncias existentes e as novas. Fluxos de longa duração, como sessões TCP persistentes, transferências de arquivos em andamento ou conexões de aplicações stateful, podem experimentar microinterrupções ou resets durante essa redistribuição.
Este é o impacto colateral real e relevante para equipes que operam aplicações sensíveis a interrupções de sessão, e é exatamente o tipo de consequência que justifica notificação prévia e execução em janela de manutenção, mesmo para operações que parecem apenas "aumentar capacidade".
A Alternativa A é incorreta porque as scale units não alteram configurações de BGP nem ASNs; o plano de controle permanece estável. A Alternativa C é incorreta porque o Routing Intent não possui um limite de scale units que o desabilite automaticamente. A Alternativa D é incorreta porque as novas instâncias são adicionadas ao mesmo pool lógico gerenciado pelo hub, sem alteração de endereçamento visível para as VNets spoke.
Árvore de Troubleshooting: Integrate a virtual hub with a third-party NVA for cloud connectivity
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (nó raiz) |
| Azul | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz que descreve o sintoma observado e responda cada pergunta de diagnóstico com base no que você consegue verificar diretamente no portal, nos logs do NVA ou nos resultados de traceroute. Cada ramificação elimina uma classe de hipóteses e o conduz progressivamente até a causa ou à ação corretiva, evitando intervenções precipitadas baseadas na causa mais óbvia ou no último item alterado no ambiente.