Laboratório de Troubleshooting: Select an appropriate ExpressRoute SKU and tier
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de rede de uma empresa com sede no Brasil relata que o circuito ExpressRoute está operacional e o status de provisionamento aparece como Succeeded no portal Azure. O peering privado está configurado e ativo. No entanto, as máquinas virtuais em uma VNet na região Australia East não conseguem ser alcançadas a partir do ambiente on-premises conectado por esse circuito.
Informações coletadas pelo time:
Circuito ExpressRoute
Nome: er-corp-brasil
Status: Enabled
Provider Status: Provisioned
SKU: Standard
Largura de banda: 1 Gbps
Peering Location: São Paulo
Peering Privado: Configurado e ativo
Gateway de rede virtual: Conectado ao circuito
Região da VNet afetada: Australia East
Regiões com conectividade funcional: Brazil South, East US
O time suspeita de um problema no gateway ou na configuração de peering, pois o circuito aparece como saudável no portal.
Qual é a causa raiz da falha de conectividade com a região Australia East?
A) O gateway de rede virtual na VNet da região Australia East está mal configurado e precisa ser recriado
B) O SKU Standard restringe a conectividade ao contexto geopolítico da região do circuito, excluindo regiões como Australia East
C) A largura de banda de 1 Gbps é insuficiente para suportar conexões com regiões geograficamente distantes
D) O peering privado não propaga rotas para VNets em regiões diferentes da região do PoP
Cenário 2 — Decisão de Ação
A equipe de rede identificou que um circuito ExpressRoute com SKU Standard precisa ser atualizado para Premium para habilitar o ExpressRoute Global Reach entre dois sites on-premises. A mudança de SKU foi aprovada e está agendada para uma janela de manutenção no próximo fim de semana.
No entanto, o gestor de operações informa que um dos dois circuitos envolvidos no Global Reach já está com SKU Premium. O circuito restante, ainda em Standard, é o circuito principal de conectividade do datacenter de produção, com SLA ativo e tráfego contínuo durante o horário comercial.
A janela de manutenção é de 2 horas, iniciando às 23h de sábado. O time possui permissões de contribuidor de rede na assinatura.
Qual é a ação correta a tomar durante a janela de manutenção?
A) Recriar o circuito Standard como um novo circuito Premium, pois o upgrade in-place não é suportado pelo Azure
B) Realizar o upgrade do SKU Standard para Premium diretamente no circuito existente, pois essa operação não interrompe o tráfego em andamento
C) Aguardar até que o tráfego de produção seja zerado antes de iniciar o upgrade, pois a mudança de SKU derruba o peering privado temporariamente
D) Solicitar ao provedor de conectividade que reconfigure o circuito antes de alterar o SKU no portal Azure
Cenário 3 — Causa Raiz
Um administrador de rede está investigando por que o acesso a serviços do Microsoft 365 não está funcionando via ExpressRoute, mesmo após a configuração do peering da Microsoft. O circuito está com status Provisioned e o peering da Microsoft aparece como Enabled no portal.
Logs coletados durante a investigação:
Peering da Microsoft: Enabled
Prefixos anunciados: 40 prefixos recebidos
Rota padrão via ExpressRoute: Nao configurada
SKU do circuito: Premium
Largura de banda contratada: 500 Mbps
Utilizacao atual: 120 Mbps
Teste de conectividade - Microsoft 365:
outlook.office365.com -> Timeout
teams.microsoft.com -> Timeout
Teste de conectividade - Azure PaaS:
storage.azure.com -> OK
sql.azure.com -> OK
O administrador acredita que o problema é a largura de banda insuficiente, pois a utilização está em 120 Mbps dos 500 Mbps contratados.
Qual é a causa raiz da falha de acesso ao Microsoft 365?
A) A largura de banda de 500 Mbps está sendo saturada por tráfego de Azure PaaS, deixando capacidade insuficiente para o Microsoft 365
B) O SKU Premium não suporta o peering da Microsoft para serviços de produtividade como o Microsoft 365
C) O acesso ao Microsoft 365 via ExpressRoute requer autorização prévia da Microsoft e políticas de roteamento específicas que não foram aplicadas
D) O peering da Microsoft está configurado incorretamente, pois o número de prefixos recebidos está abaixo do mínimo exigido para o Microsoft 365
Cenário 4 — Sequência de Diagnóstico
Um time de rede recebe o seguinte relato: "Configuramos o ExpressRoute Global Reach entre dois circuitos, mas o tráfego entre os dois sites on-premises não está fluindo. Ambos os circuitos aparecem como saudáveis individualmente."
Os passos de investigação disponíveis são:
P Verificar se ambos os circuitos estão com SKU Premium
Q Confirmar se o Global Reach está disponível na região geográfica do PoP de ambos os circuitos
R Verificar se a configuração do Global Reach foi aplicada em ambos os circuitos, referenciando o ID do circuito remoto
S Testar conectividade end-to-end entre os dois sites on-premises usando traceroute
T Confirmar se os prefixos de rede on-premises de ambos os lados não se sobrepõem
Qual sequência representa a ordem correta de investigação diagnóstica?
A) S, P, Q, T, R
B) P, Q, R, T, S
C) R, P, Q, S, T
D) Q, P, T, R, S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O SKU Standard restringe o alcance do circuito ExpressRoute ao contexto geopolítico da região onde o PoP está localizado. O PoP em São Paulo pertence à região geopolítica da América do Sul e do Brasil, o que cobre regiões como Brazil South e East US (dentro da geopolítica das Américas), mas exclui regiões como Australia East, que pertence a uma geopolítica diferente. Para alcançar regiões fora do contexto geopolítico do circuito, é necessário o SKU Premium.
A pista decisiva no enunciado é o contraste explícito: Brazil South e East US funcionam, Australia East não funciona. Esse padrão de falha seletiva por região é a assinatura do limite geopolítico do SKU Standard, não de falha de gateway ou peering.
A informação sobre a largura de banda de 1 Gbps é irrelevante para o diagnóstico: a limitação é de alcance geográfico, não de capacidade de tráfego.
O distrator mais perigoso é a alternativa A, que levaria o time a recriar um gateway funcional sem resolver o problema real, gerando indisponibilidade desnecessária durante a intervenção.
Gabarito — Cenário 2
Resposta: B
O upgrade de SKU do ExpressRoute de Standard para Premium é uma operação in-place suportada pelo Azure que não interrompe o tráfego em andamento e não derruba os peerings configurados. Isso torna a operação segura para ser executada dentro da janela de manutenção, mesmo com tráfego ativo, desde que as permissões necessárias estejam disponíveis, o que foi confirmado no cenário.
A alternativa A é factualmente incorreta: o Azure suporta upgrade in-place de SKU sem necessidade de recriar o circuito. Escolher essa opção geraria interrupção total desnecessária e exigiria reconfiguração completa de todos os peerings e conexões de gateway.
A alternativa C representa um equívoco comum, onde o administrador confunde o comportamento de operações destrutivas (como recriar um circuito) com operações de upgrade não destrutivas. A alternativa D confunde a responsabilidade do provedor na fase de provisionamento inicial com uma etapa desnecessária em um upgrade de SKU.
Gabarito — Cenário 3
Resposta: C
O acesso ao Microsoft 365 via ExpressRoute não é habilitado automaticamente pela configuração do peering da Microsoft. Ele requer um processo formal de autorização com a Microsoft e, após autorizado, exige a aplicação de políticas de roteamento específicas para que os prefixos do Microsoft 365 sejam corretamente anunciados e utilizados. O fato de o peering da Microsoft estar habilitado e serviços Azure PaaS estarem acessíveis confirma que o peering em si está funcional, mas a ausência de conectividade exclusiva ao Microsoft 365 aponta para a falta dessa autorização e configuração complementar.
A informação sobre utilização de largura de banda (120 Mbps de 500 Mbps) é deliberadamente irrelevante: há 380 Mbps livres, o que descarta completamente a hipótese de saturação.
O distrator mais perigoso é a alternativa D, que induziria o time a investigar a configuração de prefixos do peering da Microsoft, um caminho que consumiria tempo sem chegar à causa real. O número de 40 prefixos recebidos é uma informação plausível que não indica problema algum por si só.
Gabarito — Cenário 4
Resposta: B
A sequência correta é P, Q, R, T, S, que segue a lógica de diagnóstico progressivo do mais restritivo ao mais operacional:
P verifica o requisito de SKU, pois sem Premium em ambos os circuitos o Global Reach é impossível de configurar. Q verifica a disponibilidade regional do recurso, pois o Global Reach não está disponível em todos os PoPs. R valida se a configuração foi aplicada corretamente nos dois lados, referenciando o ID remoto, pois uma configuração unilateral não estabelece o caminho. T verifica sobreposição de prefixos de rede, que impede o roteamento mesmo com a configuração correta. S realiza o teste end-to-end apenas ao final, quando as camadas de pré-requisito e configuração já foram validadas.
A alternativa A começa pelo teste de conectividade (S), o que é ineficiente: um teste negativo sem ter validado os pré-requisitos não fornece informação diagnóstica útil. A alternativa C começa pela verificação da configuração (R) antes de confirmar se o SKU e a disponibilidade regional permitem o recurso, invertendo a lógica de eliminação progressiva. A alternativa D inicia pela disponibilidade regional antes do SKU, o que é aceitável mas perde a prioridade lógica: sem SKU Premium, a disponibilidade regional é irrelevante.
Árvore de Troubleshooting: Select an appropriate ExpressRoute SKU and tier
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (navy) | Sintoma inicial, ponto de entrada da investigação |
| Azul médio | Pergunta diagnóstica, ponto de decisão |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou conectividade restaurada |
Para usar esta árvore diante de um problema real, parta sempre pelo nó raiz (falha de conectividade) e responda cada pergunta com base no que é diretamente observável no portal Azure ou nos testes de conectividade. A cada bifurcação, escolha o caminho correspondente ao estado verificado, sem pular etapas. As causas em vermelho indicam onde a investigação termina e a ação corretiva começa. Os nós em verde indicam que o caminho diagnóstico chegou à resolução ou à confirmação de que a configuração está correta.