Laboratório de Troubleshooting: Create a virtual hub in Virtual WAN
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de infraestrutura criou um Virtual WAN Standard e provisionou um virtual hub na região Brazil South com o espaço de endereço 10.100.0.0/24. O hub atingiu o estado Succeeded normalmente. Em seguida, a equipe tentou conectar a VNet vnet-prod-spoke1 (range 10.100.0.0/23) ao hub via o portal do Azure. A operação falhou imediatamente com a seguinte mensagem:
Error: HubVnetConnectionFailed
Code: VnetAddressSpaceOverlapWithHubAddressSpace
Message: The virtual network address space '10.100.0.0/23' overlaps with
the hub address space '10.100.0.0/24'. Connection cannot be created.
A equipe observou que a VNet spoke em questão está na mesma assinatura do Virtual WAN, que as permissões de RBAC estão corretas e que outros hubs na mesma organização aceitam conexões sem problemas. Um colega sugeriu que o problema poderia ser o tipo do Virtual WAN, já que hubs Basic teriam restrições adicionais de VNet.
Qual é a causa raiz da falha?
A) O Virtual WAN está em uma assinatura diferente da VNet spoke, exigindo aprovação de peering entre assinaturas.
B) O espaço de endereço da VNet spoke se sobrepõe ao espaço de endereço reservado do virtual hub.
C) O tipo Standard do Virtual WAN não permite conexões com VNets cujo range seja maior que /24.
D) O hub ainda não completou a propagação interna de rotas, e a conexão falhará até que o BGP esteja ativo.
Cenário 2 — Decisão de Ação
A causa raiz já foi identificada: o virtual hub hub-eastus foi criado com o espaço de endereço 10.50.4.0/24, mas o planejamento de rede revisado exige que o hub utilize 10.50.0.0/22 para acomodar gateways adicionais e serviços de NVA previstos para os próximos 30 dias. O hub já possui duas conexões de VNet spoke ativas e um VPN Gateway no estado Succeeded. A mudança é urgente, pois a implantação do NVA está agendada para a próxima semana. A equipe tem permissão total sobre o Virtual WAN e suas dependências.
Qual é a ação correta a tomar neste momento?
A) Editar o espaço de endereço do hub diretamente pelo portal do Azure, atualizando o campo de address space para 10.50.0.0/22.
B) Excluir o VPN Gateway, alterar o espaço de endereço do hub e recriar o gateway, mantendo as conexões de VNet intactas.
C) Recriar o virtual hub com o espaço de endereço correto, reconectar as VNets spoke e reconfigurar o VPN Gateway após o novo hub atingir o estado Succeeded.
D) Criar um segundo virtual hub na mesma região com o espaço de endereço correto e migrar as conexões gradualmente.
Cenário 3 — Causa Raiz
Um engenheiro relata que criou um virtual hub na região West Europe com tipo Basic e, ao tentar adicionar um ExpressRoute Gateway pelo portal, a opção está completamente ausente na interface. O engenheiro verificou que possui o papel de Contributor na assinatura, que o Virtual WAN está no estado Succeeded e que o hub também está em estado Succeeded. O time de arquitetura informa que a empresa possui um circuito ExpressRoute ativo provisionado pelo provedor, com largura de banda de 1 Gbps e peering privado configurado. A região West Europe é suportada pelo ExpressRoute.
Qual é a causa raiz da ausência da opção de criação do ExpressRoute Gateway?
A) O papel de Contributor não tem permissão para adicionar gateways a um virtual hub; é necessário o papel de Network Contributor.
B) O circuito ExpressRoute precisa estar associado a um Resource Group no mesmo grupo de gerenciamento que o Virtual WAN antes de o gateway poder ser criado.
C) O tipo Basic do Virtual WAN não suporta ExpressRoute Gateway; essa funcionalidade está disponível apenas no tipo Standard.
D) O ExpressRoute Gateway só pode ser adicionado durante a criação inicial do hub e não está disponível como operação pós-criação.
Cenário 4 — Sequência de Diagnóstico
Um arquiteto recebe o seguinte relato: após a criação de um virtual hub Standard na região Southeast Asia, nenhuma das VNets spoke conectadas consegue se comunicar entre si, apesar de todas as conexões aparecerem com status Connected no portal. O hub foi criado há duas horas.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
[P] Verificar se o Virtual WAN é do tipo Standard (requisito para roteamento transitivo)
[Q] Confirmar que as conexoes de VNet estao no estado Connected no portal
[R] Verificar se o Routing Intent ou as route tables do hub estao propagando
as rotas corretamente para cada spoke
[S] Confirmar que os prefixos das VNets spoke aparecem na effective route table
das VMs em cada spoke
[T] Verificar se ha sobreposicao de espaco de endereco entre as VNets spoke
Qual é a sequência correta de investigação?
A) T, P, Q, R, S
B) Q, P, T, R, S
C) P, Q, T, R, S
D) Q, T, P, R, S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro é direta: VnetAddressSpaceOverlapWithHubAddressSpace. O range da VNet spoke é 10.100.0.0/23, que engloba completamente o range do hub 10.100.0.0/24. Qualquer sobreposição entre o espaço de endereço do hub e o da VNet conectada impede a criação da conexão, pois isso causaria ambiguidade de roteamento nos componentes internos do hub.
A informação sobre permissões de RBAC e sobre outros hubs funcionando corretamente é irrelevante para este diagnóstico; ela foi incluída para desviar o foco para causas operacionais quando a causa é puramente de configuração de rede.
A sugestão do colega sobre o tipo Basic é o distrator mais perigoso: o tipo do Virtual WAN não tem nenhuma relação com esse erro específico. Agir com base nessa hipótese levaria a equipe a tentar recriar o WAN como Basic, o que não resolveria nada e adicionaria downtime desnecessário.
Gabarito — Cenário 2
Resposta: C
O espaço de endereço de um virtual hub é imutável após a criação. Não existe mecanismo no portal, na CLI ou na API para alterar esse campo em um hub existente. Portanto, a única solução válida é recriar o hub com o espaço correto.
O distrator A é o mais perigoso: muitos engenheiros tentam editar o campo no portal e podem interpretar a ausência de um botão de salvar como um bug temporário, perdendo tempo. O distrator B parte de um pressuposto falso de que apenas o gateway bloqueia a alteração. O distrator D é tecnicamente possível como estratégia de migração, mas não resolve o problema do hub original e introduz complexidade desnecessária quando a solução direta é recriar.
A restrição crítica do cenário é que o hub já possui conexões ativas e um gateway: isso significa que a recriação requer planejamento de janela de manutenção, pois haverá interrupção de conectividade durante o processo.
Gabarito — Cenário 3
Resposta: C
O Virtual WAN do tipo Basic suporta apenas Site-to-Site VPN Gateway. Gateways de ExpressRoute e User VPN (Point-to-Site) são exclusivos do tipo Standard. Como o hub foi criado dentro de um Virtual WAN Basic, o portal simplesmente não exibe a opção de criação de ExpressRoute Gateway, pois ela não é uma operação válida nesse contexto.
As informações sobre o circuito ExpressRoute ativo, a largura de banda de 1 Gbps e o peering privado configurado são irrelevantes para este diagnóstico. Elas descrevem o estado do circuito no lado do provedor, que está correto, mas o problema está no lado do hub antes mesmo de chegar ao circuito.
O distrator D representa um equívoco perigoso: se o engenheiro acreditar que o gateway só pode ser criado durante a criação do hub, pode concluir que o hub precisa ser recriado, o que é parcialmente verdadeiro (por outros motivos), mas pelo motivo errado. A ação correta é atualizar o Virtual WAN para o tipo Standard.
Gabarito — Cenário 4
Resposta: B
A sequência correta é Q, P, T, R, S, que segue a lógica de eliminação progressiva do mais básico para o mais específico:
| Passo | Verificação | Razão |
|---|---|---|
| Q | Conexões estão Connected? | Valida se o problema é na camada de conexão ou de roteamento |
| P | Virtual WAN é Standard? | Confirma se o roteamento transitivo é suportado na topologia |
| T | Há sobreposição de endereços? | Elimina causa de roteamento ambíguo antes de investigar route tables |
| R | Route tables propagando rotas? | Investiga a camada de controle do hub |
| S | Effective routes nas VMs corretas? | Confirma o estado do data plane no nível da VM |
A sequência A (começando por T) não faz sentido porque verificar sobreposição antes de confirmar o estado das conexões é inverter a ordem de triagem. A sequência C começa pela verificação do tipo do WAN, que é relevante mas secundária ao estado das conexões. Iniciar pelo estado visível e observável (Q) antes de investigar causas de configuração é o princípio central do raciocínio diagnóstico progressivo.
Árvore de Troubleshooting: Create a virtual hub in Virtual WAN
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 |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, identifique o sintoma observado e localize o nó raiz. A partir daí, responda cada pergunta de diagnóstico com base no que é verificável diretamente no portal ou via ferramentas como Network Watcher e CLI do Azure. Cada resposta elimina um ramo e estreita o diagnóstico até a causa ou ação correspondente. Nunca pule uma pergunta intermediária: a ordem de verificação evita que você trate um sintoma como causa.