Laboratório de Troubleshooting: Choose an appropriate scale unit for each gateway type
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que o throughput agregado de um VPN Gateway em produção nunca ultrapassa 1 Gbps, mesmo nos horários de maior demanda, onde o tráfego esperado é de 3 Gbps. O gateway foi implantado há seis meses e nunca foi redimensionado. O ambiente opera em modo ativo-ativo com BGP habilitado. A equipe já verificou que os links de internet dos branches on-premises têm capacidade total disponível e que não há perda de pacotes nas conexões físicas. O portal do Azure exibe o gateway com status Running e todas as conexões site-to-site aparecem como Connected.
A saída do comando de diagnóstico retorna:
GatewayName : vpngw-prod-001
Sku : VpnGw2
ActiveActive : True
BgpEnabled : True
ConnectionsCount : 8
ProvisioningState: Succeeded
Qual é a causa raiz do problema observado?
A) O modo ativo-ativo está consumindo metade da capacidade disponível do gateway, limitando o throughput efetivo a 50% do nominal
B) O SKU VpnGw2 tem teto de throughput de 1 Gbps, insuficiente para o requisito de 3 Gbps
C) O número de conexões site-to-site simultâneas está próximo do limite do SKU, causando degradação de desempenho
D) O BGP habilitado em modo ativo-ativo introduz overhead de roteamento que reduz o throughput disponível para dados
Cenário 2 — Decisão de Ação
A equipe de rede identificou que um ExpressRoute Gateway com SKU ErGw1AZ precisa ser atualizado para ErGw3AZ para habilitar o recurso FastPath. O gateway está em produção, com três circuitos ExpressRoute ativos transportando tráfego crítico de banco de dados. A operação de resize no Azure para gateways ExpressRoute causa interrupção de conectividade durante o processo, que pode durar entre 20 e 30 minutos. A janela de manutenção aprovada pela área de negócios começa em 4 horas. A equipe tem permissão de Owner na subscription.
A causa do problema já foi confirmada: o SKU atual não suporta FastPath.
Qual é a ação correta a tomar neste momento?
A) Iniciar o resize imediatamente, pois a causa está confirmada e a permissão de Owner garante a execução sem janela formal
B) Criar um novo gateway ErGw3AZ em paralelo, migrar as conexões e remover o antigo antes da janela de manutenção
C) Aguardar o início da janela de manutenção aprovada e executar o resize do gateway dentro do período autorizado
D) Abrir um ticket de suporte para que a Microsoft execute o resize sem interrupção usando migração live
Cenário 3 — Causa Raiz
Um arquiteto configurou um hub de Virtual WAN com gateway VPN dimensionado em 4 unidades de escala para atender a um requisito de throughput de 2 Gbps e suportar 60 branches conectados via site-to-site. Após três semanas em produção, a equipe de monitoramento detecta que vários túneis de branches estão intermitentemente caindo e se reconectando, enquanto o throughput medido está abaixo de 500 Mbps. O portal mostra que o gateway está saudável e o número total de conexões ativas é 58. A equipe verificou que os dispositivos CPE nos branches têm firmware atualizado e que os parâmetros IKE estão corretos em todos os lados.
Os logs do gateway mostram repetidamente:
[WARN] Tunnel renegotiation triggered: peer=branch-site-43
[WARN] Tunnel renegotiation triggered: peer=branch-site-17
[INFO] Gateway health: Healthy
[INFO] Scale units configured: 4
[INFO] Active tunnels: 58
[INFO] BGP sessions: 58/58 established
O arquiteto suspeita que o número de unidades de escala está incorreto para o volume de túneis. Uma colega sugere que o problema pode estar na configuração de BGP dos branches. Outra pessoa da equipe aponta que a região do hub foi alterada recentemente de East US para Brazil South.
Qual é a causa raiz mais provável para as quedas intermitentes de túneis e o baixo throughput?
A) A migração de região do hub de East US para Brazil South introduziu inconsistências de configuração nos túneis existentes
B) 4 unidades de escala são insuficientes para 58 túneis simultâneos, pois o limite de túneis por unidade de escala foi excedido
C) As sessões BGP estão competindo com o tráfego de dados pelos recursos de processamento do gateway, causando instabilidade
D) O throughput abaixo de 500 Mbps indica que apenas 1 unidade de escala está efetivamente ativa, sugerindo falha parcial de provisionamento
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe um chamado informando que um VPN Gateway em uma arquitetura hub-and-spoke do Virtual WAN está entregando throughput muito abaixo do esperado. O engenheiro dispõe dos seguintes passos de investigação:
P — Verificar os logs de túnel para identificar renegociações ou drops frequentes
Q — Confirmar o SKU e o número de unidades de escala configurados no gateway
R — Medir o throughput real usando ferramentas como iPerf entre origem e destino
S — Verificar se o limite de túneis simultâneos da configuração atual foi atingido
T — Comparar o throughput nominal do SKU atual com o requisito documentado do ambiente
Qual é a sequência correta de investigação para esse sintoma?
A) P, Q, R, S, T
B) R, Q, T, S, P
C) Q, T, R, S, P
D) S, R, Q, T, P
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O dado mais relevante do enunciado é a saída do comando, que revela o SKU VpnGw2. Esse SKU tem teto de throughput agregado de 1 Gbps, o que explica precisamente o comportamento observado: o tráfego nunca ultrapassa esse valor, independentemente da demanda real. O sintoma é exatamente o comportamento esperado para um gateway corretamente provisionado, porém subdimensionado para o requisito.
A informação sobre os links de internet dos branches e a ausência de perda de pacotes são dados irrelevantes para o diagnóstico, incluídos propositalmente. Eles indicam que o problema não está na camada física ou na conectividade externa, mas não ajudam a identificar a causa raiz.
O distrator A representa um equívoco comum: o modo ativo-ativo não reduz o throughput disponível; ele distribui as conexões entre duas instâncias e aumenta a resiliência sem penalizar a capacidade nominal. O distrator C confunde degradação por número de conexões, que não é o comportamento documentado para 8 conexões em um SKU VpnGw2. O distrator D é incorreto porque o overhead de BGP é desprezível em relação ao throughput de dados. O distrator mais perigoso é o A, pois levaria a equipe a reconfigurar o modo de operação sem resolver o problema real.
Gabarito — Cenário 2
Resposta: C
A causa já está confirmada e a solução técnica é clara. O único fator determinante neste cenário é a restrição operacional: a janela de manutenção aprovada começa em 4 horas. Executar o resize antes dessa janela violaria o processo aprovado e causaria interrupção de conectividade de tráfego crítico fora do período autorizado.
O distrator A é tecnicamente possível, pois a permissão existe, mas ignora a restrição de processo e causaria impacto não autorizado em produção. O distrator B descreve uma abordagem válida para migrações sem downtime em outros contextos, porém gateways ExpressRoute não suportam funcionamento paralelo com migração live de conexões sem interrupção; além disso, o esforço de criar um gateway paralelo em 4 horas com três circuitos ativos não é viável de forma segura. O distrator D é incorreto porque o Azure não oferece resize live sem interrupção para gateways ExpressRoute via suporte; essa capacidade não existe para esse tipo de recurso. O distrator mais perigoso é o A, pois a lógica de "causa confirmada mais permissão igual a ação imediata" é sedutora e ignora o controle de mudança.
Gabarito — Cenário 3
Resposta: B
No Virtual WAN, cada unidade de escala do gateway VPN suporta um número máximo de túneis. Com 4 unidades de escala, o limite documentado é de 200 túneis (50 por unidade de escala). Com 58 conexões ativas, esse limite não foi atingido em termos absolutos. No entanto, o sintoma de quedas intermitentes combinado com throughput abaixo de 500 Mbps aponta para pressão nos recursos de processamento por túnel, não necessariamente o limite de contagem total.
Revisando com precisão: 4 unidades de escala entregam 2 Gbps de throughput, mas o throughput medido está abaixo de 500 Mbps com 58 túneis ativos, o que indica que a distribuição de carga entre as unidades está desequilibrada ou que há um gargalo de processamento por túnel. A causa raiz identificável pelos dados disponíveis é que a relação entre unidades de escala e número de túneis está gerando instabilidade.
As informações sobre mudança de região e sugestão de BGP são dados propositalmente irrelevantes. A mudança de região de um hub Virtual WAN não afeta túneis existentes de forma isolada e silenciosa, e os logs confirmam que todas as 58 sessões BGP estão established. O distrator A leva o leitor a investigar a mudança de região, que é o dado irrelevante mais visível. O distrator C usa uma lógica plausível mas sem suporte técnico documentado para esse comportamento específico. O distrator D descreve uma falha de provisionamento que o portal teria sinalizado como erro, não como Healthy. O distrator mais perigoso é o A, pois representa uma mudança recente e visível que tende a atrair atenção diagnóstica indevida.
Gabarito — Cenário 4
Resposta: B
A sequência correta é R, Q, T, S, P porque reflete o raciocínio diagnóstico progressivo correto para um problema de throughput:
R vem primeiro porque confirma e quantifica o sintoma com dados objetivos, separando percepção de realidade medida. Sem medir o throughput real, qualquer hipótese seguinte é especulação.
Q vem em seguida para identificar o que está provisionado, pois o SKU e as unidades de escala definem o teto teórico do ambiente.
T compara o teto teórico com o requisito documentado, determinando se o dimensionamento atual é fisicamente capaz de atender ao requisito antes de investigar causas operacionais.
S verifica se o limite de túneis simultâneos foi atingido, o que poderia explicar degradação mesmo com SKU adequado.
P vem por último porque logs de túnel são úteis para confirmar instabilidades, mas não são o primeiro passo quando o sintoma é throughput baixo sem quedas reportadas explicitamente no chamado.
A sequência A (P, Q, R, S, T) começa pelos logs antes de medir o problema real, o que inverte a prioridade. A sequência C (Q, T, R, S, P) é próxima da correta, mas prioriza verificar o SKU antes de medir o throughput real, o que pode levar a conclusões precipitadas sobre redimensionamento. A sequência D começa pelo limite de túneis sem qualquer dado de baseline medido.
Árvore de Troubleshooting: Choose an appropriate scale unit for each gateway type
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul médio: pergunta diagnóstica, nó de decisão verificável na prática
- Verde: ação recomendada ou resolução identificada
- Laranja: validação intermediária ou estado que requer investigação adicional
- Vermelho: não utilizado nesta árvore, reservado para causa identificada sem resolução imediata
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma de throughput abaixo do esperado. A primeira ramificação identifica o tipo de gateway envolvido, pois cada tipo tem limites e comportamentos de escala distintos. A partir daí, siga as perguntas fechadas respondendo com o que é observável diretamente no portal ou nos logs, sem pular etapas. Cada caminho termina em uma ação concreta ou em uma validação que confirma se o problema persiste ou foi resolvido.