Laboratório de Troubleshooting: Select a Virtual WAN SKU
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede relata que duas filiais conectadas via VPN site-to-site ao mesmo hub virtual conseguem se comunicar com recursos em VNets spoke, mas não conseguem trocar tráfego diretamente entre si. O ambiente foi provisionado há três semanas e funcionou conforme esperado durante os testes iniciais com uma única filial.
Informações coletadas pelo time:
Virtual WAN SKU: Basic
Hub virtual: West Europe
Conexoes ativas:
- Branch-SP --> Hub (site-to-site, status: Connected)
- Branch-RJ --> Hub (site-to-site, status: Connected)
- VNet-Prod --> Hub (peering, status: Connected)
Latencia Branch-SP --> VNet-Prod: 18ms (OK)
Latencia Branch-RJ --> VNet-Prod: 22ms (OK)
Latencia Branch-SP --> Branch-RJ: timeout
O time observa ainda que a largura de banda configurada por túnel está abaixo do limite máximo suportado e que as rotas das filiais aparecem corretamente na tabela de rotas do hub.
Qual é a causa raiz da falha de comunicação entre as filiais?
A) As rotas das filiais não estão sendo redistribuídas corretamente; é necessário configurar BGP entre os gateways de VPN.
B) O SKU Basic não suporta roteamento transitivo entre branches; o tráfego de branch para branch não é encaminhado pelo hub nesse SKU.
C) A largura de banda por túnel está subdimensionada, causando descarte de pacotes apenas no caminho branch-to-branch por ser o caminho mais longo.
D) As conexões site-to-site estão em sub-redes sobrepostas, o que impede o roteamento entre as filiais mesmo com o hub ativo.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o Virtual WAN em produção opera com SKU Basic e a organização agora necessita de conectividade User VPN (Point-to-Site) para trabalhadores remotos, além de manter as conexões site-to-site existentes sem interrupção.
O ambiente possui as seguintes restrições:
Ambiente:
Virtual WAN SKU atual: Basic
Conexoes site-to-site ativas: 7 branches
SLA de disponibilidade exigido: 99,9%
Janela de manutencao disponivel: proximos 14 dias
Permissoes disponíveis: Network Contributor (sem Owner)
O arquiteto responsável apresenta quatro opções de ação. Qual delas é a correta?
A) Criar um novo gateway P2S no hub atual com SKU Basic, pois o portal permite a criação do recurso mesmo sem suporte nativo ao tipo de conexão.
B) Realizar o upgrade do Virtual WAN para SKU Standard dentro da janela de manutenção, pois o upgrade é suportado sem necessidade de recriar o recurso e sem impacto obrigatório nas conexões existentes.
C) Criar um segundo Virtual WAN com SKU Standard em paralelo, migrar as conexões manualmente e descomissionar o WAN Basic após a migração completa.
D) Solicitar elevação de permissão para Owner antes de qualquer ação, pois o upgrade de SKU exige permissão de Owner na subscription.
Cenário 3 — Causa Raiz
Um arquiteto reporta que, após criar um novo hub virtual em uma região adicional dentro de um Virtual WAN Standard existente, o tráfego entre VNets conectadas ao novo hub e VNets conectadas ao hub original não está fluindo. O roteamento funcionava normalmente antes da adição do novo hub.
Logs coletados via Azure Monitor:
Hub-EastUS (original):
VNet-A peering: Connected
VNet-B peering: Connected
Routing status: Active
Hub-WestEurope (novo):
VNet-C peering: Connected
Routing status: Active
Teste de conectividade:
VNet-A --> VNet-C: Falha (sem rota)
VNet-B --> VNet-C: Falha (sem rota)
VNet-A --> VNet-B: OK
VNet-C local --> recursos locais: OK
Informações adicionais: o time confirma que ambos os hubs estão na mesma instância de Virtual WAN, que o SKU Standard está ativo e que nenhuma NSG bloqueia o tráfego inter-hub. O hub West Europe foi criado há dois dias e a equipe ainda não realizou nenhuma configuração de conectividade entre hubs.
Qual é a causa raiz da falha?
A) NSGs nas VNets spoke estão bloqueando o tráfego inter-hub; a confirmação verbal do time não substitui a validação via Network Watcher.
B) O SKU Standard permite múltiplos hubs, mas o roteamento transitivo entre hubs distintos não é automático; é necessário estabelecer conectividade explícita entre os hubs dentro do Virtual WAN.
C) O hub West Europe está em estado de provisionamento incompleto; o status "Active" no portal pode ser exibido antes da conclusão total do deployment.
D) VNets spoke conectadas a hubs diferentes não podem trocar tráfego em um Virtual WAN Standard; cada hub opera como um domínio de roteamento isolado por design.
Cenário 4 — Impacto Colateral
Uma organização opera um Virtual WAN com SKU Basic e decide realizar o upgrade para SKU Standard para habilitar conectividade ExpressRoute. O upgrade é executado com sucesso durante a janela de manutenção e a conexão ExpressRoute é provisionada corretamente logo em seguida.
Três dias após o upgrade, o time de operações abre um chamado relatando que uma solicitação de rollback foi feita pela diretoria por motivos orçamentários, pedindo o retorno ao SKU Basic para reduzir custos.
O engenheiro responsável confirma que o upgrade foi concluído e que as novas conexões ExpressRoute estão em produção.
Qual é a consequência direta mais relevante dessa solicitação de rollback?
A) O downgrade pode ser executado, mas exige a remoção prévia das conexões ExpressRoute e a reconfiguração manual de todas as conexões site-to-site existentes.
B) O downgrade de Standard para Basic não é suportado pela plataforma; para retornar ao SKU Basic seria necessário recriar o Virtual WAN do zero, com impacto em todas as conexões ativas.
C) O downgrade é suportado, mas resulta na suspensão temporária das conexões site-to-site enquanto a plataforma realiza o redimensionamento interno do hub.
D) O downgrade pode ser solicitado via Azure Support, que avalia caso a caso se o ambiente atende aos pré-requisitos para reversão de SKU.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva no enunciado é o SKU Basic combinado com o sintoma específico de falha exclusivamente no caminho branch-to-branch, enquanto a comunicação com VNets funciona normalmente. Esse padrão é a assinatura exata da limitação do SKU Basic: ele encaminha tráfego de branch para VNet, mas não roteia tráfego de forma transitiva entre dois branches conectados ao mesmo hub.
A informação sobre largura de banda abaixo do limite máximo é o dado irrelevante inserido propositalmente. Ela não tem relação com o problema observado, pois o timeout ocorre de forma consistente, não intermitente, o que descarta descarte por congestionamento.
A alternativa A é o distrator mais perigoso: as rotas aparecem corretamente na tabela do hub, o que eliminaria BGP como causa. A alternativa D seria inválida porque sub-redes sobrepostas impediriam também a comunicação com VNets, o que não ocorre aqui.
Agir com base na alternativa A levaria o time a configurar BGP desnecessariamente, sem resolver o problema e consumindo tempo de manutenção.
Gabarito — Cenário 2
Resposta: B
O upgrade de Basic para Standard é suportado pela plataforma sem necessidade de recriar o Virtual WAN e sem impacto obrigatório nas conexões site-to-site existentes. A permissão Network Contributor é suficiente para executar o upgrade; Owner não é um requisito.
A alternativa A é tecnicamente impossível: o SKU Basic não suporta User VPN e o portal bloqueia a criação do recurso, não apenas oculta a opção.
A alternativa C é válida em cenários onde o upgrade in-place não é suportado, mas aqui ele é suportado; criar um WAN paralelo introduziria complexidade e risco desnecessários, além de impactar o SLA durante a migração das 7 conexões ativas.
A alternativa D é o distrator que explora a insegurança sobre permissões. Network Contributor cobre operações de rede, incluindo upgrades de SKU de Virtual WAN. Aguardar elevação de permissão atrasaria a solução sem justificativa técnica.
Gabarito — Cenário 3
Resposta: B
No Virtual WAN Standard, a existência de múltiplos hubs na mesma instância não implica conectividade automática entre eles. A conexão inter-hub deve ser estabelecida explicitamente no portal ou via API, configurando o peering entre os hubs dentro do Virtual WAN.
A pista no enunciado é a afirmação de que "nenhuma configuração de conectividade entre hubs foi realizada". Esse dado, combinado com o padrão de falha (tráfego intra-hub funciona, tráfego inter-hub falha), aponta diretamente para ausência de configuração, não para falha de recurso.
A alternativa A é o distrator que explora a tendência de desconfiar de afirmações verbais e buscar validação adicional. No entanto, o padrão de falha (todos os caminhos inter-hub falham, nenhum intra-hub falha) torna NSG uma hipótese improvável como causa raiz.
A alternativa D representa um equívoco conceitual grave: hubs no mesmo Virtual WAN Standard podem trocar tráfego, mas requerem configuração explícita. Acreditar que são isolados por design levaria à conclusão incorreta de que a arquitetura precisa ser redesenhada.
Gabarito — Cenário 4
Resposta: B
O downgrade de Standard para Basic não é suportado pela plataforma Azure. Essa é uma restrição de design, não uma limitação configurável ou reversível via suporte. A única forma de retornar ao SKU Basic seria recriar o Virtual WAN inteiramente, o que implicaria reconfigurar todas as conexões ativas, incluindo as 7 conexões site-to-site e a conexão ExpressRoute recém-provisionada.
A alternativa A é o distrator mais perigoso porque descreve um processo que parece razoável ("remover conexões e fazer downgrade"), mas a premissa é falsa: o downgrade não existe como operação suportada, com ou sem remoção prévia de conexões.
A alternativa C usa linguagem de degradação temporária para tornar o downgrade plausível. Esse é um padrão de distrator comum: sugerir que a ação existe, mas tem um custo aceitável.
A alternativa D apela para a percepção de que o suporte da Microsoft pode viabilizar operações não documentadas. Na prática, restrições de SKU como essa são de plataforma e não são alteradas por solicitação de suporte.
A consequência real de não compreender essa limitação antes do upgrade é exatamente o cenário descrito: uma decisão orçamentária posterior que se torna irreversível sem impacto operacional severo.
Árvore de Troubleshooting: Select a Virtual WAN SKU
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, identifique o sintoma observado e inicie pelo nó raiz. A cada nó de decisão, responda à pergunta com base no que é verificável diretamente no portal ou via comandos: o SKU atual, o tipo de recurso que falha, a presença de múltiplos hubs e a existência de configuração inter-hub. Siga o ramo correspondente à sua resposta até alcançar um nó de causa identificada ou de ação recomendada. Nunca pule etapas: um sintoma de branch-to-branch pode ter a mesma aparência que uma falha de roteamento inter-hub, e a distinção entre eles determina se a solução é um upgrade de SKU ou uma configuração de peering.