Laboratório de Troubleshooting: Choose between Azure private peering only, Microsoft peering only, or both
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa configurou um circuito ExpressRoute de 1 Gbps com Azure private peering há três semanas. O ambiente on-premises possui conectividade física confirmada com o provedor de circuito, e o status do circuito no portal do Azure aparece como Provisioned. O time de redes relata que as sessões BGP do private peering estão estabelecidas e estáveis.
Na última semana, a equipe de segurança habilitou um novo conjunto de regras no firewall on-premises para bloquear tráfego de saída nas portas 443 e 80 para faixas de IP não catalogadas internamente. Nenhuma mudança foi feita no Azure.
Os engenheiros de aplicação reportam o seguinte comportamento:
Teste 1: Ping de servidor on-premises para VM Azure (10.10.1.4) -> SUCESSO
Teste 2: Acesso RDP de servidor on-premises para VM Azure (10.10.1.4) -> SUCESSO
Teste 3: Acesso ao portal Azure Storage (storage-account.blob.core.windows.net) -> FALHA
Teste 4: Acesso ao Exchange Online (outlook.office365.com) -> FALHA
Teste 5: Acesso a outro blob storage via endpoint privado (10.10.2.8) -> SUCESSO
O gestor de infraestrutura sugere que o problema é intermitência no circuito ExpressRoute, pois "alguns acessos funcionam e outros não".
Qual é a causa raiz das falhas observadas nos Testes 3 e 4?
A) Intermitência no circuito ExpressRoute causando perda seletiva de pacotes para destinos específicos
B) As regras de firewall estão bloqueando o tráfego, pois os IPs públicos dos serviços Microsoft não estão catalogados internamente
C) O circuito não possui Microsoft peering configurado, portanto os prefixos de serviços públicos da Microsoft não são anunciados por esse domínio de roteamento
D) O Azure private peering não suporta tráfego para endpoints com nomes DNS públicos, exigindo resolução DNS privada para todos os destinos
Cenário 2 — Decisão de Ação
A equipe de engenharia de uma empresa identificou a causa de um problema de conectividade: o circuito ExpressRoute está configurado apenas com Microsoft peering, mas a arquitetura exige acesso privado a VMs em múltiplas VNets do Azure. O ambiente de produção está ativo e o circuito está sendo utilizado por dezenas de usuários que acessam o Microsoft 365 pelo ExpressRoute neste momento.
O time possui as seguintes restrições documentadas:
- Janela de manutenção disponível: próxima sexta-feira, das 22h às 02h
- Circuito ExpressRoute: provisionado e em uso ativo
- VNet Gateway: ainda não criado no Azure
- BGP communities para Microsoft peering: configuradas e em uso
- Impacto aceitável fora da janela de manutenção: nenhum
Qual é a ação correta a tomar neste momento?
A) Reconfigurar o Microsoft peering existente para operar como private peering, aproveitando a sessão BGP já estabelecida e evitando qualquer interrupção
B) Habilitar o Azure private peering imediatamente, pois ele opera em um domínio de roteamento independente e sua configuração não afeta o Microsoft peering em uso
C) Aguardar a janela de manutenção, pois embora o private peering possa ser adicionado de forma independente, a criação do VNet Gateway e a associação ao circuito podem causar impacto na conectividade existente
D) Solicitar ao provedor de conectividade a criação de um segundo circuito ExpressRoute dedicado ao private peering, pois os dois tipos de peering não podem coexistir no mesmo circuito
Cenário 3 — Causa Raiz
Uma empresa de manufatura possui um circuito ExpressRoute com Azure private peering e Microsoft peering configurados. O time de redes acabou de migrar o ambiente on-premises para um novo bloco de endereços IP: de 192.168.0.0/16 para 172.20.0.0/14. A migração foi concluída e os equipamentos on-premises estão operacionais.
Após a migração, o seguinte comportamento é observado:
BGP private peering status : Established
BGP Microsoft peering status : Established
Rotas anunciadas ao Azure : 172.20.0.0/14 (novo bloco)
Rotas recebidas do Azure : 10.10.0.0/16 (VNet principal)
Teste: VM Azure (10.10.1.5) -> servidor on-premises (172.20.10.1) : FALHA
Teste: Servidor on-premises (172.20.10.1) -> VM Azure (10.10.1.5) : SUCESSO
Teste: Servidor on-premises -> Exchange Online : SUCESSO
O técnico responsável verifica que o firewall on-premises não possui regras bloqueando o tráfego de retorno. Ele também confirma que o novo bloco 172.20.0.0/14 não tem sobreposição com nenhum endereço no Azure. A largura de banda do circuito está abaixo de 10% de utilização.
Qual é a causa raiz da falha no primeiro teste?
A) O circuito ExpressRoute está com problema de capacidade e está descartando pacotes de retorno seletivamente
B) A VNet do Azure ainda possui rotas apontando para o bloco antigo 192.168.0.0/16, e o tráfego de retorno está sendo descartado por ausência de rota válida para 172.20.0.0/14
C) O Microsoft peering está interferindo com o private peering ao anunciar rotas sobrepostas ao gateway da VNet
D) O firewall on-premises está bloqueando o tráfego iniciado a partir do Azure, mesmo sem regras explícitas configuradas para o novo bloco
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "Configuramos o Microsoft peering hoje e esperávamos acessar os serviços do Microsoft 365 pelo ExpressRoute, mas o tráfego ainda está saindo pela internet."
O engenheiro tem disponíveis os seguintes passos de investigação, listados fora de ordem:
Passo P: Verificar se as rotas recebidas via Microsoft peering estão sendo
instaladas na tabela de roteamento dos equipamentos on-premises
Passo Q: Confirmar que o status BGP do Microsoft peering está como Established
no portal do Azure e no equipamento on-premises
Passo R: Verificar se existe uma politica de roteamento on-premises (route policy
ou route map) que esta aceitando e preferindo as rotas recebidas via
ExpressRoute em relacao a rota padrao da internet
Passo S: Confirmar se os prefixos IP publicos dos servicos Microsoft 365 estao
sendo anunciados pela sessao BGP do Microsoft peering
Passo T: Verificar se o circuito ExpressRoute esta no status Provisioned e se
o provedor concluiu o provisionamento do lado deles
Qual é a sequência correta de diagnóstico progressivo?
A) T -> Q -> S -> P -> R
B) Q -> T -> R -> S -> P
C) S -> P -> Q -> T -> R
D) T -> S -> Q -> P -> R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está nos resultados dos testes: os acessos que funcionam (Testes 1, 2 e 5) têm um elemento em comum: todos os destinos são endereços IP privados, seja uma VM diretamente ou um serviço acessado via Private Endpoint. Os Testes 3 e 4 falham porque seus destinos possuem endereços IP públicos, cujos prefixos são anunciados exclusivamente pelo Microsoft peering. Como apenas o private peering está configurado, esses prefixos simplesmente não existem na tabela de roteamento BGP disponível para o tráfego on-premises.
A informação sobre as regras de firewall é irrelevante para os Testes 3 e 4 neste diagnóstico: o tráfego não chega sequer a ser encaminhado pelo ExpressRoute para esses destinos, pois a rota não existe. A ausência de rota é anterior à filtragem de pacotes.
O erro de diagnóstico do gestor (intermitência no circuito) é o distrator mais perigoso: ele desvia o time para investigar o provedor e o hardware, atrasando a identificação de uma lacuna de configuração simples e objetiva. A alternativa D é tecnicamente incorreta: o private peering roteia com base em endereços IP, não em nomes DNS.
Gabarito — Cenário 2
Resposta: C
A causa está identificada e a solução técnica é clara: adicionar o Azure private peering ao circuito. O ponto crítico do cenário é a restrição de impacto zero fora da janela de manutenção.
Embora a sessão BGP do private peering possa ser configurada de forma independente sem interromper o Microsoft peering, a criação do VNet Gateway e sua associação ao circuito ExpressRoute envolvem operações no plano de dados da VNet que podem impactar a conectividade existente. Como o circuito está em uso ativo por dezenas de usuários, a ação correta é planejar a execução completa para a janela de manutenção disponível.
A alternativa B é o distrator mais perigoso: ela está parcialmente correta (o private peering é independente do Microsoft peering) mas ignora que a etapa do VNet Gateway é parte necessária da solução e não é sem risco em produção ativa. A alternativa A é tecnicamente inválida: os dois peerings são domínios distintos e um não pode ser reconvertido no outro. A alternativa D é falsa: ambos os peerings coexistem normalmente no mesmo circuito.
Gabarito — Cenário 3
Resposta: B
O sintoma é assimétrico: o tráfego de on-premises para o Azure funciona, mas o tráfego do Azure para on-premises falha. Essa assimetria é a pista diagnóstica central.
O tráfego iniciado no Azure busca uma rota na tabela de roteamento efetiva da VNet para alcançar 172.20.0.0/14. Se essa rota não foi atualizada após a migração de endereçamento on-premises (ainda aponta para 192.168.0.0/16 ou simplesmente não existe para o novo bloco), os pacotes de retorno são descartados no Azure antes de chegar ao circuito. O fato de o BGP mostrar que o novo bloco está sendo anunciado pelo on-premises não garante que a VNet já atualizou suas rotas efetivas ou que o gateway propagou corretamente.
A informação sobre a largura de banda (abaixo de 10%) é irrelevante e foi incluída para induzir investigação de capacidade, que não tem relação com o padrão assimétrico observado. O distrator mais perigoso é o D: ele parece plausível porque envolve firewall e tráfego iniciado remotamente, mas o próprio enunciado confirma que não há regras bloqueando tráfego de retorno.
Gabarito — Cenário 4
Resposta: A
A sequência correta é T -> Q -> S -> P -> R, seguindo a lógica de diagnóstico progressivo do mais fundamental para o mais específico:
| Ordem | Passo | Razão |
|---|---|---|
| 1 | T | Sem circuito provisionado, nenhuma outra verificação faz sentido |
| 2 | Q | Sem sessão BGP estabelecida, nenhuma rota é trocada |
| 3 | S | Confirma se os prefixos corretos estão sendo anunciados pela sessão ativa |
| 4 | P | Verifica se as rotas chegaram e foram instaladas na tabela local |
| 5 | R | Só após confirmar que as rotas existem, verifica se o equipamento as está preferindo sobre a rota padrão da internet |
O erro representado pelas alternativas incorretas é pular etapas de validação de infraestrutura e ir direto para configurações de política de roteamento (R) antes de confirmar que o plano de controle está funcional. Executar o Passo R antes do Passo Q, por exemplo, seria investigar políticas de roteamento em uma sessão BGP que talvez nem esteja estabelecida, consumindo tempo sem possibilidade de conclusão válida.
Árvore de Troubleshooting: Choose between Azure private peering only, Microsoft peering only, or both
Legenda de cores:
- Azul escuro: sintoma inicial ou ponto de entrada do diagnóstico
- Azul médio: pergunta diagnóstica objetiva com resposta sim ou não
- Vermelho: causa identificada
- Verde: ação recomendada ou resolução
Para utilizar esta árvore diante de um problema real, comece pelo nó raiz descrevendo a falha de conectividade via ExpressRoute. Responda cada pergunta diagnóstica com base no que é observável no ambiente: status do portal do Azure, saída dos comandos BGP no equipamento on-premises e resultados de testes de conectividade. Siga o caminho correspondente à sua resposta até alcançar um nó vermelho de causa identificada, que aponta diretamente para a ação de resolução no nó verde subsequente. O diagrama cobre tanto cenários de private peering quanto de Microsoft peering, e também falhas que envolvem ambos simultaneamente.