Laboratório de Troubleshooting: Configure Microsoft Peering
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de rede de uma empresa reporta que o circuito ExpressRoute foi provisionado com sucesso pela operadora e que o Microsoft peering consta como Provisioned no portal do Azure. Um Route Filter foi criado e associado ao peering há três dias. O circuito opera na largura de banda de 1 Gbps e o link físico está estável, sem perdas de pacote reportadas pelo provedor.
Apesar disso, o roteador on-premises não recebe nenhuma rota BGP da Microsoft via o circuito. O engenheiro executa o seguinte comando no roteador:
show bgp neighbors 192.0.2.1 routes
BGP neighbor is 192.0.2.1, remote AS 8075
BGP state = Established, up for 2d 04:11:32
Prefixes received: 0
Prefixes advertised: 2
O engenheiro observa que a sessão BGP está estabelecida e que o roteador está anunciando 2 prefixos para a Microsoft. O provedor confirmou que não há filtros aplicados do lado deles.
Qual é a causa raiz do problema?
A) A sessão BGP está estabelecida, mas o AS remoto 8075 indica que a conexão foi feita com o peer errado; o Microsoft peering requer conexão com um AS diferente.
B) O Route Filter está associado ao peering, mas não contém nenhuma regra de BGP community, portanto a Microsoft não anuncia rotas para o circuito.
C) O roteador está anunciando apenas 2 prefixos, quando o Microsoft peering exige um mínimo de 5 prefixos anunciados para ativar o recebimento de rotas.
D) O circuito de 1 Gbps não suporta Microsoft peering; essa funcionalidade requer circuitos de pelo menos 2 Gbps.
Cenário 2 — Decisão de Ação
O time de operações identificou que o Microsoft peering de um circuito ExpressRoute em produção está no estado ValidationNeeded desde a manhã. O circuito é responsável pelo acesso ao Exchange Online e ao SharePoint Online de aproximadamente 3.000 usuários que estão atualmente usando a internet pública como caminho alternativo, com degradação de desempenho perceptível.
A investigação confirmou que o prefixo anunciado no campo AdvertisedPublicPrefixes não possui um route object registrado no IRR declarado sob o ASN do cliente. O engenheiro responsável tem acesso ao portal do IRR e pode registrar o prefixo imediatamente. Ele também tem permissão para editar a configuração do peering no portal do Azure.
Um colega sugere recriar o peering do zero para forçar uma nova validação mais rápida. Outro sugere abrir um chamado de suporte com a Microsoft para solicitar aprovação manual.
Qual é a ação correta a tomar neste momento?
A) Recriar o peering do zero, pois a recriação força um novo ciclo de validação imediato e resolve o problema mais rapidamente do que corrigir o registro no IRR.
B) Registrar o prefixo no IRR sob o ASN correto e, após a propagação do registro, editar a configuração do peering para acionar um novo ciclo de validação.
C) Abrir chamado de suporte com a Microsoft solicitando aprovação manual do prefixo, pois é o único mecanismo disponível quando o IRR não está configurado corretamente.
D) Alterar o campo RoutingRegistryName para RADB no peering existente, pois o RADB tem propagação mais rápida e resolverá o problema sem necessidade de registrar o prefixo.
Cenário 3 — Causa Raiz
Uma organização configurou o Microsoft peering em um circuito ExpressRoute há seis meses e o ambiente funciona corretamente para o Exchange Online. Esta semana, a equipe adicionou uma nova regra ao Route Filter existente para incluir o Azure SQL Database de uma região específica. Após a alteração, o engenheiro verifica a tabela BGP no roteador on-premises:
show ip bgp
Network Next Hop Metric LocPrf Weight Path
40.64.0.0/10 192.0.2.1 0 100 0 8075 i
13.96.0.0/13 192.0.2.1 0 100 0 8075 i
104.40.0.0/13 192.0.2.1 0 100 0 8075 i
O engenheiro confirma que os prefixos acima correspondem às rotas do Exchange Online recebidas anteriormente. Nenhuma rota nova relacionada ao Azure SQL Database aparece na tabela. O Route Filter no portal mostra o seguinte estado:
Route Filter: RF-PROD
Status : Active
Rules:
- Community: 12076:5010 (Exchange Online) [Active]
- Community: 12076:5021 (Azure SQL - East US) [Provisioning]
O circuito e o peering estão no estado Provisioned. O link físico está estável. A operadora não realizou nenhuma manutenção recente.
Qual é a causa raiz da ausência das novas rotas?
A) O prefixo 12076:5021 não é uma BGP community válida para o Azure SQL Database; o valor correto exige um número de community diferente para serviços PaaS.
B) A nova regra do Route Filter ainda está em estado Provisioning e as rotas correspondentes ainda não foram anunciadas pela Microsoft para o circuito.
C) O roteador on-premises está aplicando um filtro de entrada que bloqueia prefixos não listados explicitamente na configuração local, impedindo o recebimento das novas rotas.
D) O Route Filter com múltiplas regras ativas requer que o peering seja desprovisionado e reprovisionado para que as novas regras entrem em vigor.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o relato de que o tráfego para o Microsoft 365 não está passando pelo circuito ExpressRoute, embora o Microsoft peering estivesse funcionando corretamente na semana anterior. Nenhuma manutenção programada foi realizada no circuito. O tráfego está fluindo pela internet pública como caminho alternativo.
Os passos de investigação disponíveis são:
- Passo P: Verificar se o Route Filter associado ao peering ainda contém as regras de BGP community esperadas.
- Passo Q: Verificar o estado atual do peering no portal do Azure (se está
Provisioned,ValidationNeededou outro). - Passo R: Verificar na tabela BGP do roteador on-premises se as rotas do Microsoft 365 estão sendo recebidas pelo circuito.
- Passo S: Verificar se há anúncio de rota padrão (
0.0.0.0/0) ou rota mais específica via internet que esteja sobrepondo as rotas do ExpressRoute no roteador. - Passo T: Confirmar com a operadora se o circuito físico e os links primário e secundário estão operacionais.
Qual sequência representa o raciocínio diagnóstico correto, do mais abrangente para o mais específico?
A) T, Q, R, P, S
B) R, P, Q, T, S
C) Q, T, P, R, S
D) P, R, Q, S, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída do comando: Prefixes received: 0, com a sessão BGP no estado Established. Uma sessão BGP estabelecida significa que a conectividade e a autenticação entre os peers estão funcionando. O problema é exclusivamente de política de anúncio: a Microsoft não está enviando rotas.
Quando um Route Filter é associado ao peering mas não contém nenhuma regra de BGP community, o comportamento da Microsoft é não anunciar nenhum prefixo. O filtro existe, mas está vazio de regras, resultando em exatamente zero rotas recebidas, que é o sintoma observado.
A informação irrelevante no cenário é a largura de banda de 1 Gbps, incluída propositalmente para induzir a alternativa D. A capacidade do circuito não tem qualquer relação com o suporte ao Microsoft peering.
A alternativa A representa um erro clássico de confundir o AS 8075 com algo errado: esse é o ASN legítimo da Microsoft usado nas sessões de Microsoft peering e não indica configuração incorreta. A alternativa C é um distrator inventado; não existe requisito mínimo de prefixos anunciados para receber rotas. O distrator mais perigoso é o A, porque leva o engenheiro a procurar um problema inexistente na conectividade com o peer correto, gastando tempo valioso.
Gabarito — Cenário 2
Resposta: B
A causa foi identificada com precisão: ausência do route object no IRR. O caminho correto é corrigir exatamente o que está errado, na ordem lógica: primeiro registrar o prefixo no IRR, aguardar a propagação do registro entre os servidores do IRR, e depois acionar um novo ciclo de validação editando a configuração do peering no portal.
A alternativa A representa uma ação correta em contexto errado: recriar o peering não acelera a validação se o prefixo ainda não estiver registrado no IRR. A recriação sem corrigir o registro resultaria no mesmo estado ValidationNeeded. Além disso, em produção, recriar o peering causaria interrupção do serviço durante o reprovisioning.
A alternativa C ignora a disponibilidade de uma solução direta e controlável pelo cliente. A aprovação manual pela Microsoft é um caminho de último recurso, não o procedimento padrão. A alternativa D é tecnicamente incorreta: mudar o IRR declarado sem registrar o prefixo naquele IRR não resolve o problema; apenas desloca o ponto de falha.
Gabarito — Cenário 3
Resposta: B
A evidência está visível no próprio enunciado: o estado da nova regra no Route Filter é Provisioning, não Active. Quando uma regra é adicionada a um Route Filter existente, ela precisa ser provisionada pela plataforma do Azure antes de se tornar efetiva. Durante esse intervalo, a Microsoft ainda não anuncia os prefixos correspondentes à nova community.
As rotas do Exchange Online continuam chegando normalmente porque a regra 12076:5010 está com estado Active, confirmando que o mecanismo de Route Filter funciona corretamente.
A informação irrelevante neste cenário é o fato de o link físico estar estável e a operadora não ter feito manutenção. Esses dados desviam a atenção para a infraestrutura física quando o problema está inteiramente na camada de política de roteamento.
A alternativa C representa um erro de diagnóstico grave: atribuir a causa a um filtro no roteador on-premises sem qualquer evidência de que esse filtro existe ou foi alterado. O distrator mais perigoso é o D, porque poderia levar o engenheiro a desprovisionar e reprovisionar o peering em produção desnecessariamente, causando interrupção real de serviço.
Gabarito — Cenário 4
Resposta: A
A sequência correta é T, Q, R, P, S, que segue o princípio de diagnóstico progressivo: confirmar as camadas mais fundamentais antes de investigar camadas superiores.
T verifica a camada física com a operadora, pois sem conectividade física nenhuma outra investigação faz sentido. Q verifica o estado do peering no plano de controle do Azure, estabelecendo se o problema está na plataforma. R examina a tabela BGP do roteador, determinando se as rotas estão sendo recebidas pelo circuito. P inspeciona as regras do Route Filter, verificando se a política de anúncio está correta. S verifica se há um problema de preferência de rota no roteador local que esteja sobrepondo as rotas do ExpressRoute, o que seria a causa mais sutil e específica.
A alternativa B começa pela tabela BGP (R) antes de confirmar se o circuito físico e o peering estão operacionais, o que inverte a lógica de eliminação progressiva. A alternativa C começa pelo estado do peering antes de confirmar a camada física, perdendo a oportunidade de descartar rapidamente uma falha de infraestrutura. A alternativa D começa pelo Route Filter, que é um detalhe de configuração investigado apenas depois de confirmar que as camadas inferiores estão funcionais.
Árvore de Troubleshooting: Configure Microsoft Peering
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão baseada em observação) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz (azul escuro) e responda cada pergunta dos nós azuis com base no que for observado diretamente no ambiente: portal do Azure, saída de comandos no roteador e confirmações com a operadora. Cada resposta elimina um ramo de hipóteses e direciona para o próximo nível de especificidade. Ao atingir um nó vermelho, a causa está identificada. O nó verde imediatamente abaixo indica a ação corretiva correspondente. Nós laranjas sinalizam que uma verificação adicional é necessária antes de concluir o diagnóstico daquele ramo.