Laboratório de Troubleshooting: Select an ExpressRoute Connectivity Model
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de rede de uma empresa relata que o circuito ExpressRoute provisionado há três dias aparece com status "Provider status: Not provisioned" no portal do Azure, mesmo após o parceiro de conectividade confirmar que o link físico já está estabelecido e ativo do lado deles.
O circuito utiliza o modelo Point-to-point Ethernet. A empresa está localizada em São Paulo e o peering location escolhido foi Campinas. A service key foi gerada com sucesso no portal do Azure há quatro dias. O time de operações confirma que o BGP ainda não foi configurado em nenhum dos lados.
Informações coletadas:
Circuito ExpressRoute
Status do provedor : Not provisioned
Status do circuito : Enabled
Peering location : Campinas
Largura de banda : 1 Gbps
SKU : Standard
Service key : a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx
O engenheiro responsável suspeita que o problema está na ausência de configuração BGP e abre um chamado para configurar as sessões imediatamente.
Qual é a causa raiz do status observado?
A) A ausência de configuração BGP impede que o provedor sinalize o circuito como provisionado, pois o BGP é necessário para completar o handshake de provisionamento.
B) O provedor ainda não configurou sua extremidade do circuito no sistema de provisionamento da Microsoft, o que é uma etapa obrigatória que precede qualquer configuração de roteamento pelo cliente.
C) O SKU Standard não suporta o modelo Point-to-point Ethernet no peering location de Campinas, gerando um estado inconsistente de provisionamento.
D) A service key foi gerada antes de o link físico estar disponível, tornando-a inválida e exigindo que um novo circuito seja criado.
Cenário 2 — Decisão de Ação
Uma organização financeira identificou que seu circuito ExpressRoute de 10 Gbps baseado em ExpressRoute Direct está operando consistentemente acima de 85% de utilização durante o horário comercial, causando descarte de pacotes em rajadas. A causa foi confirmada pela equipe de NOC: o volume de tráfego cresceu além da capacidade planejada originalmente.
O ambiente possui as seguintes restrições:
- O par de portas físicas no peering location é de 100 Gbps
- Há atualmente 3 circuitos lógicos provisionados sobre esse par de portas, totalizando 10 Gbps de largura de banda alocada
- O orçamento para novos circuitos foi aprovado
- Qualquer alteração que cause interrupção total do tráfego de produção precisa ser agendada com janela de manutenção de 72 horas de antecedência
- O problema está causando impacto em produção neste momento
Qual é a ação correta a tomar neste momento?
A) Solicitar ao provedor a substituição imediata do par de portas por um de maior capacidade, pois o gargalo está na infraestrutura física.
B) Provisionar um novo circuito lógico adicional sobre o mesmo par de portas físicas existente, aumentando a largura de banda disponível sem necessidade de interrupção e sem exigir janela de manutenção para o tráfego existente.
C) Aguardar a abertura da janela de manutenção de 72 horas para reconfigurar os circuitos existentes com maior largura de banda individualmente.
D) Migrar imediatamente o ambiente para o modelo Any-to-any (IPVPN), que distribui a carga entre múltiplos caminhos WAN e resolve o problema de saturação sem necessidade de janela de manutenção.
Cenário 3 — Causa Raiz
Uma empresa com equipamentos instalados em um datacenter de colocation em São Paulo tenta estabelecer conectividade com o Azure utilizando o modelo CloudExchange colocation. O provedor de Exchange confirmou que a conexão cruzada virtual foi criada entre o roteador do cliente e o MSEE. No entanto, as sessões BGP permanecem no estado Idle após 48 horas.
Informações coletadas pelo engenheiro de rede:
# Saída do roteador do cliente (IOS-XE)
show bgp summary
Neighbor AS State Up/Down Prefixes Rcvd
12.0.0.1 12076 Idle never 0
12.0.0.2 12076 Idle never 0
# Configuração de peering aplicada
neighbor 12.0.0.1 remote-as 12076
neighbor 12.0.0.1 ebgp-multihop 5
neighbor 12.0.0.2 remote-as 12076
neighbor 12.0.0.2 ebgp-multihop 5
O time de segurança informa que, durante a semana anterior, atualizou as ACLs do roteador para bloquear conexões TCP de entrada originadas de fora do AS corporativo. O engenheiro descarta essa informação por considerar que conexões BGP são iniciadas pelo próprio roteador.
O roteador consegue fazer ping nos endereços 12.0.0.1 e 12.0.0.2. A service key foi enviada ao provedor e o status do circuito é Enabled / Provisioned.
Qual é a causa raiz das sessões BGP em estado Idle?
A) O parâmetro ebgp-multihop 5 está configurado incorretamente; para conexões eBGP diretas com o MSEE, o TTL deve ser 1 (sem multihop), e esse valor impede o estabelecimento da sessão.
B) O circuito está com o peering privado ainda não configurado no portal do Azure, pois o status Provisioned reflete apenas o aprovisionamento físico do circuito, não a configuração de peering.
C) As ACLs atualizadas pelo time de segurança estão bloqueando conexões TCP de entrada na porta 179, impedindo que o MSEE inicie a sessão BGP de volta ao roteador do cliente.
D) O AS 12076 é reservado para a Microsoft e não pode ser usado como remote-as em configurações de peering privado; o cliente deve usar o ASN público atribuído ao seu circuito.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o relato de que, após uma migração de modelo de conectividade ExpressRoute de Point-to-point Ethernet para CloudExchange colocation, rotas que antes eram anunciadas corretamente pelo Azure para a rede on-premises deixaram de aparecer na tabela de roteamento dos equipamentos locais.
O engenheiro dispõe dos seguintes passos de investigação:
- Verificar se o peering privado está configurado e ativo no portal do Azure para o novo circuito
- Confirmar se a conexão cruzada virtual foi concluída pelo provedor de Exchange e se a camada física está ativa
- Verificar a tabela de roteamento BGP no roteador do cliente para identificar quais prefixos, se houver, estão sendo recebidos
- Confirmar se o circuito antigo (Point-to-point) foi desprovisionado antes de o novo circuito ser completamente validado
- Verificar se as rotas anunciadas pelo Azure estão presentes na tabela de roteamento do MSEE usando a ferramenta de verificação de rotas do portal
Qual é a sequência de diagnóstico correta?
A) 2 → 1 → 5 → 3 → 4
B) 1 → 3 → 2 → 4 → 5
C) 3 → 5 → 1 → 2 → 4
D) 4 → 2 → 1 → 5 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O status "Provider status: Not provisioned" indica especificamente que o provedor de conectividade ainda não completou a etapa de provisionamento da sua extremidade do circuito no sistema da Microsoft. No modelo Point-to-point Ethernet, após o cliente gerar a service key e compartilhá-la com o provedor, é o provedor quem deve sinalizar à Microsoft que o link físico e a configuração da sua camada estão prontos. Enquanto essa sinalização não ocorre, o status permanece "Not provisioned", independentemente do que o provedor informe verbalmente.
A pista decisiva no enunciado é que o circuito está com "Circuit status: Enabled" mas "Provider status: Not provisioned", o que é um estado intermediário documentado no ciclo de vida do circuito ExpressRoute. Esse estado específico aponta diretamente para a ação pendente do provedor no sistema de provisionamento da Microsoft, não para configurações do cliente.
A informação sobre a ausência de configuração BGP é irrelevante para esse diagnóstico. O BGP só entra em cena após o circuito estar completamente provisionado por ambos os lados. O engenheiro do cenário cometeu o erro clássico de avançar para a camada de roteamento (camada 3) antes de validar que a camada de provisionamento (operacional) estava concluída. Agir com base no distrator A e configurar BGP antes de o provisionamento estar completo não resolve nem avança o problema.
Gabarito — Cenário 2
Resposta: B
O diferencial técnico central do ExpressRoute Direct é exatamente a capacidade de criar múltiplos circuitos lógicos independentes sobre o mesmo par de portas físicas. Como o par de portas é de 100 Gbps e apenas 10 Gbps estão alocados atualmente, há capacidade física disponível. Provisionar um novo circuito lógico adicional resolve o problema de saturação sem interromper os circuitos existentes, tornando a ação possível sem necessidade de janela de manutenção de 72 horas para o tráfego em produção.
A alternativa A é incorreta porque o gargalo não está no par de portas físicas (100 Gbps com apenas 10 Gbps em uso), mas na capacidade dos circuitos lógicos provisionados sobre ele. Substituir o par de portas seria uma ação desnecessária e disruptiva.
A alternativa C representa uma ação tecnicamente válida, mas aplicada no momento errado: aguardar 72 horas enquanto há impacto em produção e a solução não disruptiva está disponível é a decisão incorreta dado o contexto de restrições.
A alternativa D é a mais perigosa: migrar o modelo de conectividade durante um incidente ativo em produção introduz risco elevado, complexidade operacional e certamente exigiria uma janela de manutenção, violando a própria restrição do cenário.
Gabarito — Cenário 3
Resposta: C
A causa raiz é o bloqueio de TCP de entrada na porta 179 pelas ACLs atualizadas. O protocolo BGP opera sobre TCP na porta 179 e, embora a sessão seja iniciada pelo roteador do cliente, o MSEE também precisa estabelecer a conexão TCP de volta (o processo de three-way handshake TCP exige tráfego bidirecional). ACLs que bloqueiam conexões TCP de entrada originadas de fora do AS corporativo efetivamente impedem que o SYN-ACK e os pacotes subsequentes do MSEE cheguem ao roteador do cliente, mantendo as sessões em estado Idle indefinidamente.
A pista decisiva é a combinação de dois fatos: o ping para os endereços do MSEE funciona (camada 3 OK, ACL não bloqueia ICMP) e as ACLs foram alteradas recentemente para bloquear TCP de entrada de fora do AS corporativo. O AS 12076 (Microsoft) é externo ao AS corporativo, portanto seus pacotes TCP seriam bloqueados.
A informação sobre ebgp-multihop 5 é a informação irrelevante propositalmente incluída. Em um CloudExchange colocation, o roteador do cliente e o MSEE estão na mesma instalação e tecnicamente na mesma camada de enlace, portanto ebgp-multihop não é necessário, mas sua presença não impede o estabelecimento da sessão BGP por si só.
O distrator mais perigoso é o A, pois o ebgp-multihop chama atenção por ser uma configuração atípica, levando o engenheiro a focar em ajuste de TTL enquanto o problema real está na política de segurança de rede. Agir com base no A geraria retrabalho sem resolver a falha.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 2 → 1 → 5 → 3 → 4, que segue a lógica de diagnóstico progressivo por camadas: física antes de lógica, plano de controle antes de plano de dados, e validação de estado atual antes de investigar ações passadas.
Passo 2 primeiro: confirmar que a conexão cruzada virtual existe e que a camada física está ativa é o pré-requisito para qualquer análise subsequente. Sem conectividade física, os demais passos são irrelevantes.
Passo 1 em seguida: verificar se o peering privado está configurado no portal do Azure para o novo circuito. Sem peering configurado, nenhuma rota será anunciada independentemente do estado físico.
Passo 5 depois: verificar as rotas na perspectiva do MSEE no portal do Azure para confirmar que o Azure está de fato anunciando os prefixos esperados. Isso isola se o problema está no lado do Azure ou no caminho até o cliente.
Passo 3 após a validação do MSEE: com a confirmação de que rotas existem no MSEE, verificar o que está chegando no roteador do cliente aponta para onde o problema está ocorrendo no caminho de retorno.
Passo 4 por último: investigar se o circuito antigo foi desprovisionado prematuramente é uma hipótese sobre uma ação passada que só faz sentido verificar depois de esgotar as causas técnicas atuais.
As sequências B, C e D cometem o erro de avançar para camadas superiores (roteamento, tabela BGP do cliente) antes de validar as fundações (camada física e configuração de peering), o que pode levar a diagnósticos incorretos ou a retrabalho por falta de visibilidade do estado real da infraestrutura.
Árvore de Troubleshooting: Select an ExpressRoute Connectivity Model
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica |
| 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, comece pelo nó raiz e identifique qual dos quatro sintomas principais descreve melhor o que foi observado. Siga as ramificações respondendo às perguntas de diagnóstico com base no que pode ser verificado diretamente no ambiente: portal do Azure, roteador do cliente, saídas de comandos BGP e confirmações do provedor. Cada caminho leva a uma causa identificada em vermelho, seguida de uma ação recomendada em verde e de um passo de validação em laranja que confirma se a correção foi efetiva antes de encerrar o diagnóstico.