BGP estabelecido, rota ausente: um guia prático de diagnóstico em Huawei e Juniper

Diagnóstico de BGP em Huawei NE40E e Juniper MX: 24 consultas para investigar políticas, next-hop, RIB, FIB e anúncios sem alterar a rede.

Por Lucas Vinicius Santos | LVNetwork

O estado Established confirma que a sessão BGP chegou à fase de troca de mensagens. Para explicar por que um prefixo não aparece onde deveria, é preciso acompanhar o caminho da rota: recebimento, política de importação, elegibilidade, seleção, instalação e anúncio. Reiniciar a sessão antes dessa coleta pode eliminar evidências e ampliar o incidente.

Este guia organiza esse diagnóstico em Huawei NE40E com VRP e Juniper MX com Junos. O foco é IPv4 unicast, com consultas a um prefixo específico e atenção ao contexto de tabela. Ao final, você terá um roteiro para apontar em qual etapa a evidência diverge do comportamento esperado e qual verificação faz sentido em seguida.

Escopo de segurança: todos os blocos de CLI deste artigo são de consulta. Não há mudanças de BGP, roteamento, filtros, RPKI, autenticação ou permissões; também não há limpeza de sessão, soft reset ou route refresh disparado manualmente. Mesmo consultas devem respeitar o volume da tabela, a carga do equipamento e o acesso autorizado.

Base documental e limites: fontes oficiais consultadas em 7 de outubro de 2026. A referência Huawei é NE40E V800R023C10SPC500, complementada pelas páginas de comando identificadas ao final. A referência Juniper é a documentação contínua do Junos OS, com páginas específicas para cada comando. Não houve execução em NE40E, MX, emulador ou equipamento de cliente. Os exemplos e resultados descritos são ilustrativos; a sintaxe foi revisada contra documentação, sem certificação de compatibilidade com todos os releases.

1 Localize a ausência antes de procurar a causa

“A rota sumiu” precisa virar uma pergunta verificável. O prefixo está ausente na visão de rotas recebidas? Foi rejeitado? Permanece em BGP, mas perdeu a seleção? Existe na RIB de outra instância? Está ativo e ainda assim não aparece no anúncio ao próximo vizinho?

O RFC 4271 descreve três estruturas conceituais: Adj-RIB-In, com informações aprendidas dos pares; Loc-RIB, com rotas escolhidas pelo processo de decisão; e Adj-RIB-Out, com informações selecionadas para anúncio a cada par. Uma implementação não precisa materializá-las como três cópias físicas independentes. [1]

Na operação, também precisamos da RIB do sistema, onde protocolos e preferências concorrem pela rota ativa, e da FIB, usada no encaminhamento. Uma CLI de “tabela BGP” pode exibir vários candidatos. Por isso, não a trate automaticamente como uma fotografia literal da Loc-RIB.

Figura 1. Caminho conceitual do prefixo: recepção, admissão, seleção BGP e as verificações de encaminhamento e anúncio.

Use estes termos com precisão durante a investigação:

Recebida: o vizinho anunciou a rota, dentro do que a coleta consegue observar. Retenção local e filtros da consulta podem limitar essa visibilidade.
Aceita: passou pela política de importação considerada. Ainda pode haver motivo para não se tornar utilizável ou preferida.
Elegível: atende às condições para participar da seleção, incluindo resolução de next-hop conforme o contexto.
Melhor caminho BGP: venceu entre os candidatos BGP aplicáveis. Isso não encerra a competição com outros protocolos na RIB.
Ativa ou instalada: a RIB e a visão de encaminhamento precisam ser verificadas separadamente. Os rótulos e flags variam entre fabricantes.
Anunciada: aparece na visão de anúncio para um vizinho específico, depois das regras de exportação aplicáveis. Confirme a observação no receptor quando necessário.

Esses estados não devem ser deduzidos apenas de contadores agregados. Uma sessão com milhares de rotas pode estar saudável para outros prefixos e ainda bloquear exatamente o /24 investigado.

2 Fixe o contexto e use uma bancada identificável

Nos exemplos, R1 é o equipamento sob análise, no AS 64496. O vizinho R2, no AS 64497, usa 192.0.2.2; a interface de R1 usa 192.0.2.1. O prefixo procurado é 203.0.113.0/24. Cada fabricante representa uma alternativa para R1 no mesmo cenário.

Os blocos 192.0.2.0/24 e 203.0.113.0/24 são reservados para documentação; os ASNs 64496 e 64497 pertencem à faixa documental do RFC 5398. Não anuncie esses identificadores na Internet. O artigo não depende de endereços, ASNs ou informações de equipamentos reais. [3][4]

Figura 2. Bancada fictícia com endereços e ASNs reservados para documentação.

Antes da primeira consulta, registre equipamento, horário, release, vizinho, ASN local/remoto, prefixo com máscara, direção esperada e tabela. Tenha uma conta com autorização de leitura e acesso à documentação do release. Os comandos estão sem o prompt do equipamento para facilitar a cópia.

O roteiro principal usa a tabela global. Em Junos, ela é inet.0; uma instância pode usar CLIENTE_A.inet.0. Em Huawei, é necessário selecionar a vpn-instance correspondente. O mesmo IPv4 pode existir em instâncias diferentes com caminhos e políticas distintos. Uma rota em outra VRF não satisfaz a consulta da VRF investigada.

Confirme também a família de endereços operacional. O transporte da sessão e as famílias de rotas que ela carrega são dimensões diferentes. IPv4 unicast, VPNv4, IPv6 unicast e FlowSpec têm significados e tabelas próprios; uma sessão estabelecida para uma família não comprova troca útil para outra. [2]

Consulta exata e encaminhamento respondem a perguntas diferentes. Para saber se o anúncio /24 existe, procure esse prefixo e sua máscara. Para saber qual rota um pacote utiliza, examine o destino concreto e a correspondência mais específica. Uma rota default ou um agregado pode permitir encaminhamento mesmo sem o /24; um prefixo mais específico pode desviar parte do tráfego.

3 Huawei NE40E com VRP

O guia NE40E V800R023C10SPC500 confirma as consultas básicas abaixo e os exemplos de VPN instance. As referências de troubleshooting da família NE complementam a consulta por prefixo e a interpretação do next-hop, mas não identificam release. Essa diferença de cobertura está preservada aqui: há revisão documental, sem alegação de teste em equipamento.

3.1 Comece pela sessão e pelo inventário do peer

display bgp peer
display bgp routing-table peer 192.0.2.2 received-routes

Procure: peer correto, ASN, estado Established e o prefixo 203.0.113.0/24 entre as rotas visíveis. Confirme a família e as políticas na visão detalhada suportada pela versão. A listagem recebida pode ser extensa; use o filtro de prefixo documentado no release quando disponível. [5]

Limite: “received” não significa automaticamente aceito, melhor ou instalado. A visibilidade de rejeições depende do que é retido. Referências Huawei distinguem consultas a rotas aceitas, não aceitas e atributos originais, com condições de retenção. Não use uma saída vazia como prova única de que R2 nunca anunciou o /24. Tampouco habilite retenção ou solicite reanúncio apenas para preencher essa lacuna. [6]

3.2 Compare a tabela BGP com a RIB

As formas básicas documentadas no guia são:

display bgp routing-table
display ip routing-table

Procure: o /24 e sua máscara na primeira saída; depois, na RIB, protocolo selecionado, preferência, next-hop e interface. Use essas formas amplas apenas quando o tamanho da tabela permitir uma coleta controlada, como na bancada fictícia. [5]

Para uma investigação por prefixo, a referência oficial de troubleshooting NE documenta:

display bgp routing-table 203.0.113.0 24

Cobertura desta linha: sintaxe documentada para a família NE, sem release identificado na página. Confirme a ajuda e a referência do release instalado antes de usá-la como procedimento padronizado. O endereço e a máscara foram substituídos pelos dados documentais do exemplo. [9]

O detalhe permite relacionar validade, seleção e next-hop. Diferencie o next-hop original carregado pela rota do next-hop resolvido usado para alcançá-lo. Se o original não tiver resolução utilizável, a rota pode não avançar para a seleção/instalação esperada. Leia as flags pela legenda e pela documentação da versão; não traduza “valid”, “best” e “select” como se fossem o mesmo estado. [9]

Na RIB, a preferência entre protocolos também importa. Um caminho BGP existente pode perder para outra fonte de rota do mesmo prefixo. Essa preferência não é o atributo LOCAL_PREF usado na seleção BGP. [8]

3.3 Siga a política até a família e o peer

A referência de troubleshooting NE usa esta consulta de configuração:

display current-configuration configuration bgp

Cobertura desta linha: referência NE sem release identificado. Ela serve para localizar associação de import/export, peer, grupo e família; não substitui confirmar a sintaxe na versão instalada. Siga os nomes de políticas e seus objetos por consultas somente leitura compatíveis com o release. Evite extrair apenas uma linha, perdendo a família ou a configuração do grupo. [7]

Confira se o critério realmente inclui 203.0.113.0/24, se a máscara está dentro do intervalo aceito e se uma ação anterior encerra a avaliação. Para a ausência no recebimento de R1, compare a exportação de R2 com a importação de R1. Uma política correta, aplicada a outro peer ou outra família, não responde ao caso investigado.

3.4 Repita a investigação dentro da VPN instance

Para o contexto fictício CLIENTE_A, o guia do release traz as formas equivalentes:

display bgp vpnv4 vpn-instance CLIENTE_A peer
display bgp vpnv4 vpn-instance CLIENTE_A routing-table 203.0.113.0 24
display ip routing-table vpn-instance CLIENTE_A 203.0.113.1 verbose

Procure: sessão e rota da instância selecionada. A consulta BGP especifica o /24; a consulta IP usa um endereço de destino. Nesta última, confira qual prefixo foi retornado: um agregado ou uma default não comprova a presença exata do /24. [5]

Para conferir anúncio ao peer dessa instância:

display bgp vpnv4 vpn-instance CLIENTE_A routing-table peer 192.0.2.2 advertised-routes

Essa é uma consulta de exportação, com direção explícita. Se R2 é a origem do prefixo no cenário, não espere concluir o diagnóstico verificando apenas se R1 o anuncia de volta. No anunciante, consulte o peer que representa o receptor investigado. [5]

Encaminhamento: depois da RIB, consulte a FIB compatível com modelo, release e placa. As fontes examinadas não permitiram fixar uma sintaxe FIB específica do NE40E deste guia; por isso, não há uma linha genérica para copiar. Registre essa lacuna se a investigação depender de comprovar a instalação no encaminhamento. A presença em BGP ou na RIB não preenche essa evidência.

4 Juniper MX com Junos OS

A documentação Junos consultada é contínua. Os comandos abaixo estão no modo operacional. As formas básicas evitam depender de combinações de filtros que não foram demonstradas integralmente nas fontes. Quando uma consulta listar todo o peer, localize o /24 e confira o cabeçalho da tabela. Em uma full table, use os filtros por prefixo e tabela aceitos pela ajuda da versão antes de ampliar a coleta.

4.1 Confira a sessão e a família operacional

show bgp summary
show bgp neighbor 192.0.2.2

Procure: estado, ASN, grupo/instância, família inet-unicast, tabelas e contadores recebidos, aceitos e ativos. Os nomes e campos mudam entre releases. Um número de rotas maior que zero informa sobre a sessão, sem identificar o prefixo investigado. [11][12]

Observe também limites aplicados. No MX, as opções de excesso drop-excess e hide-excess foram introduzidas no Junos OS 21.2R1. Elas permitem comportamentos distintos de simplesmente derrubar a sessão, portanto Established não exclui a hipótese de limite de prefixos. Verifique se o release e a configuração realmente utilizam esse recurso. [26]

4.2 Consulte o que foi recebido e o que está oculto

show route receive-protocol bgp 192.0.2.2 detail
show route receive-protocol bgp 192.0.2.2 detail hidden

Procure: o prefixo, o peer de origem e os atributos. A primeira consulta mostra os atributos como recebidos, sem as mudanças da política de importação. Isso não significa que sua saída padrão seja um inventário completo de todas as atualizações recebidas. A segunda mostra somente as rotas ocultas retidas. [13][27]

A política de retenção importa: keep none pode descartar rejeições por import policy e verificações específicas de BGP. Ainda assim, uma rota com next-hop de protocolo não resolvido pode permanecer hidden. Portanto, nem “hidden vazio” inocenta a política, nem “há hidden” permite deduzir como a retenção está configurada. Não altere a retenção para transformar a consulta em um teste. [22]

4.3 Examine o prefixo exato e a resolução

show route exact 203.0.113.0/24 extensive
show route hidden extensive
show route resolution unresolved

Procure: a tabela correta, protocolo, preferência, estado, motivo de inatividade, origem do caminho e Protocol next hop. exact distingue o /24 de um agregado ou de uma rota mais específica. hidden identifica um caminho inutilizável; um caminho apenas inativo pode ter perdido para outra rota. [14][23][24]

A consulta show route hidden extensive pode ser volumosa e mostra detalhes dos caminhos ocultos. Localize o prefixo e a tabela; use filtros adicionais apenas quando confirmados na versão. A consulta de resolução mostra entradas não resolvidas. Correlacione-as com o next-hop do prefixo; não atribua qualquer entrada não resolvida ao incidente. A resolução pode envolver outra RIB, conforme o desenho. Confirme a origem da resolução nos detalhes disponíveis. [15]

Se o next-hop observado for 192.0.2.2, uma consulta de destino complementar é:

show route 192.0.2.2 extensive

Confira a tabela e o prefixo efetivamente impresso. Não exija uma rota /32: uma rede conectada ou aprendida pelo IGP pode fornecer a resolução. Consultar rotas que usam um next-hop é diferente de consultar uma rota para alcançar esse endereço. O endereço do peer também não é necessariamente o next-hop anunciado para cada NLRI. [15][28]

4.4 Corrobore o encaminhamento e o anúncio

show route forwarding-table destination 203.0.113.0/24 table default extensive

Procure: destino, tipo de next-hop, interface e flags, verificando o prefixo apresentado. Este comando mostra a tabela de encaminhamento da Routing Engine. A documentação separa essa visão da tabela no Packet Forwarding Engine. Logo, a consulta não certifica a programação correta em cada PFE nem a entrega fim a fim. [16]

Para a direção de anúncio ao peer especificado:

show route advertising-protocol bgp 192.0.2.2 detail

Localize o /24 e confira a tabela. O comando mostra a visão preparada para anúncio após a política de exportação; ele não demonstra que o outro lado aceitou ou instalou a rota. Para investigar o recebimento de R1, faça a consulta equivalente em R2, direcionada ao endereço de R1, se houver acesso autorizado. [17]

4.5 Leia a política efetiva e ajuste o contexto da VRF

show configuration protocols bgp | display set
show configuration policy-options | display set

Essas consultas leem a configuração committed. display set apenas muda a apresentação da saída; os set impressos não devem ser colados de volta na CLI. Siga as políticas de import/export até os termos que se aplicam ao prefixo. Se houver apply-groups, confira a herança e os overrides com a visão apropriada da configuração, sem assumir que o trecho isolado de um neighbor contém tudo. [18][25]

Para a instância fictícia, estas leituras ajudam a confirmar o escopo:

show route table CLIENTE_A.inet.0
show configuration routing-instances CLIENTE_A protocols bgp | display set

A primeira pode ser volumosa. Use-a para confirmar a tabela em uma bancada pequena; em produção, restrinja a consulta com as opções suportadas no release. Na visão de RIB, o nome inclui .inet.0. No comando de forwarding-table, o argumento de tabela designa a instância; não transporte automaticamente o nome da RIB para esse argumento. [16][19]

5 Interprete a primeira divergência

O vizinho está estabelecido e o prefixo não aparece nas consultas locais

Primeiro, confira tabela, família, máscara e retenção. Se a visão local não conserva rejeições, a ausência isolada não distingue “nunca recebido” de “recebido e descartado”. Use a visão de anúncio do vizinho, dentro do acesso autorizado, e compare coletas próximas no tempo. Um anúncio observado em outro horário não exclui um withdrawal posterior.

Se o vizinho também não apresenta o prefixo na exportação, avance para a origem da rota e a política daquele lado. Prefix-list, route-filter, AS-path, community, ordem de termos e ação final precisam ser avaliados em conjunto. Uma lista que contém o prefixo pode nem estar associada à família ou ao peer em questão.

A rota aparece em BGP e não se torna ativa

Leia a causa disponível antes de comparar atributos de preferência. Next-hop não resolvido é uma falha de elegibilidade; aumentar LOCAL_PREF não produz conectividade para esse next-hop. Quando a rota é utilizável, compare os caminhos concorrentes e a preferência efetiva de outros protocolos na mesma tabela. [9][14]

Considere uma variante iBGP da bancada: R1 recebe 203.0.113.0/24 com next-hop 198.51.100.9, mas sua instância não dispõe de resolução válida para esse endereço. A sessão pode permanecer estabelecida com o vizinho. Esse é um exemplo conceitual independente da sessão eBGP diretamente conectada da Figura 2; não é uma saída medida.

Na outra direção, uma rota estática para o mesmo /24 pode vencer a rota BGP na RIB. A observação correta é “há um candidato BGP e outro protocolo está ativo”. Excluir a estática ou mudar preferências já seria uma intervenção e precisa de avaliação e aprovação próprias.

A RIB está correta e o tráfego continua divergente

Verifique a visão de encaminhamento, o next-hop resolvido e o prefixo mais específico aplicável ao destino. Depois, delimite o que ainda não foi observado: programação no hardware, adjacência, interface de saída, instância de entrada e caminho de retorno. Uma entrada em uma consulta de software não comprova sozinha a saúde completa do plano de dados. [16]

Este roteiro termina na coleta de controle e encaminhamento disponível. Testes de tráfego, captura de pacotes, diagnóstico de hardware e alterações em filtros devem seguir o procedimento autorizado para aquele ambiente.

O prefixo existe localmente e não é anunciado

Verifique elegibilidade para exportação, política efetiva, família e peer de destino. Comunidades como NO_EXPORT e regras de propagação iBGP podem restringir o anúncio. Route reflection, add-path, advertise-inactive e mecanismos equivalentes mudam as condições; não generalize o comportamento de uma rede para outra. [17][20][29]

Import e export são vistos do roteador consultado. A exportação de R2 participa do que R1 pode receber; a importação de R1 decide o tratamento local. Para investigar o anúncio de R1 a um terceiro peer, a consulta precisa apontar para esse terceiro peer. “R1 não anuncia de volta a R2” pode ser comportamento esperado de prevenção de loops.

6 Examine políticas e origem sem ampliar o incidente

A revisão deve preservar a intenção do desenho. Para cada política, anote a hierarquia em que está aplicada, os critérios de correspondência, a ação e os atributos alterados. Um termo permissivo depois de uma rejeição que já encerrou o processamento não recupera a rota. Confira também se o filtro exige prefixo exato, permite comprimentos específicos ou aceita mais específicos.

Na origem, confirme que o prefixo pretendido existe pelo mecanismo previsto: conectado, estático, agregado ou aprendido de outro protocolo. Em Huawei, a origem por network depende de correspondência exata de prefixo e máscara com uma rota já existente na tabela de roteamento. Em Junos, anunciar rotas não BGP depende da política de exportação aplicável e das condições de seleção. Uma declaração de intenção na configuração não substitui observar a rota e o anúncio. [10][17]

RPKI entra na investigação quando há validação e política associada. Os estados de validação de origem são Valid, Invalid e NotFound. Eles dependem da cobertura por registros validados, do ASN de origem e do comprimento máximo autorizado. A ação de aceitar ou rejeitar é uma decisão de política. Valid não valida todo o AS_PATH nem prova a legitimidade de cada trânsito; NotFound não equivale a Invalid. [21]

No Junos, Unknown corresponde ao NotFound; Unverified indica que a origem não foi verificada naquele contexto. Não trate esses dois rótulos como equivalentes. [30]

Se houver rejeição ligada à validação, correlacione o estado da rota com a política e a disponibilidade/atualidade do validador já utilizado. Não desative ROV, não amplie filtros e não altere ROAs como tentativa de diagnóstico. O prefixo documental deste artigo não fornece um teste público real de RPKI.

VRFs exigem contexto explícito. A rota deve ser consultada na VRF correta, enquanto o next-hop pode resolver por outra RIB ou pelo underlay global, conforme o desenho. Identifique a tabela de resolução efetivamente utilizada antes de interpretar uma ausência. Em cenários VPN, diferencie a presença na tabela VPN da importação para a VRF, incluindo route targets e políticas. Não faça leaking entre tabelas apenas para que uma consulta passe a retornar o prefixo. [5][19]

7 Feche o diagnóstico com evidência e um próximo passo

Figura 3. Fluxo de diagnóstico e registro de evidências por etapa.

Uma conclusão útil permite que outro profissional repita a investigação sem precisar adivinhar o contexto. Registre:

Equipamento, versão, horário e origem da coleta.
Prefixo e máscara, peer, direção, família e tabela.
Comandos usados e trechos mínimos relevantes, preservando o estado observado.
Última etapa comprovada e primeira divergência.
Limitações de retenção, acesso, sincronismo ou visibilidade do hardware.
Hipótese compatível com os fatos e consulta necessária para confirmá-la.
Correção proposta, abrangência, risco, aprovação e critérios de sucesso, se já houver diagnóstico suficiente.

Exemplo de registro ilustrativo: “Na instância CLIENTE_A, o /24 aparece como hidden e aponta next-hop sem resolução utilizável. A sessão com o peer está estabelecida. A política de importação consultada não explica a inatividade. A próxima verificação é identificar a RIB de resolução efetivamente usada e o caminho para esse next-hop.” Isso ainda não autoriza adicionar rota, mudar next-hop ou alterar política.

O critério de encerramento precisa corresponder ao incidente. Para um problema de anúncio, confirme o prefixo no peer receptor e na direção correta. Para um problema de encaminhamento, complemente a rota ativa com a evidência de plano de dados prevista no procedimento da rede. Um contador maior ou uma sessão novamente estabelecida não basta para demonstrar correção do prefixo investigado.

Antes de qualquer mudança, apresente a ação exata, os prefixos e peers afetados, os riscos de indisponibilidade ou vazamento de rotas e a forma de reversão. Preserve a configuração anterior, defina uma janela quando necessária e estabeleça critérios objetivos de rollback. Obtenha aprovação antes de executar. Este artigo não fornece comandos de mudança nem pressupõe autorização para aplicá-los.

8 O que foi verificado neste artigo

Revisão documental: sintaxe e interpretação confrontadas com fontes oficiais Huawei, Juniper e RFCs. As páginas Huawei identificadas por produto/release foram separadas das referências conceituais.
Não executado: comandos em hardware, testes em emulador, medições de convergência, inspeção de tráfego e validação do PFE. Nenhuma captura de CLI apresentada é de um equipamento real.
Resultado esperado: orientação sobre o campo ou condição a procurar, sem promessa de texto idêntico entre versões.
Limite deliberado: a etapa de FIB Huawei requer a referência específica do modelo, placa e release quando a sintaxe não estiver confirmada no conjunto documental deste guia.
Publicação segura: ao adaptar o roteiro, remova endereços de clientes, nomes de peers, descrições internas e material de autenticação das evidências que forem compartilhadas.

A investigação fica mais precisa quando cada comando responde a uma pergunta e cada conclusão preserva o alcance da evidência. Comece pelo prefixo, mantenha o contexto constante e avance até encontrar a primeira diferença entre o que foi observado e o que a rede deveria fazer.

Referências oficiais

Consulta em 7 de outubro de 2026. Os links apontam às páginas de origem. A documentação Huawei do release indicado foi confirmada em exemplos e trechos indexados do domínio oficial; algumas aberturas diretas apresentaram restrição HTTP 403. As páginas complementares sem release identificado estão rotuladas abaixo. Nenhuma fonte de outro modelo foi usada para afirmar homologação em NE40E.

[1] RFC 4271 · A Border Gateway Protocol 4 · estruturas de RIB e processo de decisão

[2] RFC 4760 · Multiprotocol Extensions for BGP 4 · famílias de endereços

[3] RFC 5737 · IPv4 Address Blocks Reserved for Documentation

[4] RFC 5398 · Autonomous System Number Reservation for Documentation Use

[5] Huawei · NE40E V800R023C10SPC500 Configuration Guide · exemplos BGP e VPN instance

[6] Huawei · display bgp routing-table · referência CLI sem release identificado na página

[7] Huawei · Checking that Routing Policies Are Configured Correctly · troubleshooting NE sem release identificado

[8] Huawei · What Is IP Routing · interpretação de preferência e tabelas

[9] Huawei · Verificação da atividade da rota e next-hop · troubleshooting NE em chinês sem release identificado

[10] Huawei · network BGP · correspondência exata na RIB · referência sem release identificado

[11] Juniper · show bgp summary · referência contínua Junos OS

[12] Juniper · show bgp neighbor · referência contínua Junos OS