Início / Notas técnicas / Solução de problemas de vizinho BGP e instabilidade de rotas

O vizinho BGP não se estabelece e as rotas ficam instáveis? Uma lista de verificação completa

Um peer travado em Idle ou OpenSent, ou uma sessão que fica caindo e voltando arrastando uma rota junto, é uma das escaladas mais comuns na borda de uma rede WAN. Esta é a ordem de diagnóstico que separa as poucas causas raiz por trás da maioria desses chamados — os comandos display exatos, os códigos de erro, e onde a iteração de rota quebra silenciosamente uma sessão que, de resto, parece normal.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que a coluna de estado diz mais do que o sintoma

Eu não começo encarando a configuração — começo perguntando em qual dos seis estados o peer está realmente travado.

Uma sessão BGP percorre uma sequência fixa — Idle, Connect, Active, OpenSent, OpenConfirm, Established — e quase todo chamado de «o vizinho não sobe» é, na verdade, uma questão de em qual desses estados ele está travado, não um mistério a resolver mudando configurações dos dois lados ao mesmo tempo. Uma sessão que chega a Established e depois cai, oscila, ou envia silenciosamente o tráfego só por um de vários caminhos de custo igual é um problema diferente, com sua própria ordem de diagnóstico, mesmo que seja relatado da mesma forma: «o BGP caiu».

A seguir está a árvore de falhas na qual isto se baseia, as verificações de cada ramo com os comandos exatos, as causas que aparecem repetidamente depois das primeiras verificações, e algumas respostas de perguntas frequentes tiradas de casos reais de campo.

Leia a árvore de falhas antes de mexer em qualquer configuração

As falhas de BGP se dividem em exatamente duas formas: o vizinho nunca chega a Established, ou chega e algo ainda não está certo.

Colocar primeiro o sintoma nesta árvore evita muito retrabalho depois — ela indica qual das seções abaixo realmente se aplica ao que você está vendo.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Depois de saber qual ramo se aplica, quase toda verificação abaixo está a um único comando display de uma causa confirmada — a armadilha é tratar uma sessão já Established que está oscilando com a mesma lista de verificação de uma que nunca chegou a se estabelecer.A mesma disciplina, aplicada a outro protocolo, está por trás de O vizinho OSPF está travado ou as rotas oscilam? Lendo a máquina de estados para encontrar a falha, sua nota irmã para adjacências OSPF.

Percorrendo cada estado

Seis estados, um único comando exato para saber em qual você está travado — e os logs de oscilação se explicam sozinhos assim que você entende o código de erro.

Etapa 0 — Confirmar se o transporte realmente conecta

Se o peer nunca sai de Idle ou Active, ainda não mexa na configuração do BGP — confirme primeiro se os dois lados realmente conseguem se alcançar via TCP 179.

Faça ping entre os dois endereços de peer usando um comando que carregue um endereço de origem e um tamanho de pacote real — ping -a source-ip-address -s packetsize host — já que um endereço de origem também confirma que o caminho de retorno é válido, e um tamanho de pacote maior confirma que um Update BGP grande não será silenciosamente descartado no meio do caminho.
Se o ping falhar, isso é um problema de roteamento/enlace a ser resolvido separadamente, não um problema de BGP.
Se o ping funcionar mas a sessão ainda não avançar, verifique nos dois lados se há uma ACL que filtre a porta TCP 179 — muitas vezes um resquício de uma política de segurança ou QoS não relacionada.

<HUAWEI> display acl all
Basic ACL 3001, 2 rules
ACL's step is 5
ACL's match-order is config
  rule 5 deny tcp source-port eq bgp
  rule 10 deny tcp destination-port eq bgp
// undo rule 5 destination-port / undo rule 10 source-port removes the block

Etapa 1 — Correspondência de Router ID, número de AS e família de endereços

O transporte está bem, mas o peer ainda não sai de OpenSent ou mostra «No Neg» — quase sempre é um parâmetro específico que parece correto isoladamente mas que, na verdade, não coincide com o outro lado.

Verifique display bgp peer nos dois lados para o Router ID local. Dois peers com o mesmo Router ID — comum após uma configuração clonada — bloqueiam totalmente o estabelecimento; corrija com router id na visão do BGP, geralmente definido como o endereço Loopback.
Compare o número de AS configurado com o que o outro lado realmente é, não com o que você acha que deveria ser.
Se a sessão for específica de uma família de endereços (VPNv4, IPv6, VPNv6), confirme se peer enable está configurado nessa família de endereços nos dois lados — uma configuração unilateral aparece como «No Neg» em vez de uma falha evidente.

<HUAWEI> display bgp peer
BGP local router ID : 1.1.1.1
 Local AS number : 41976
 Total number of peers : 12                Peers in established state : 4
  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
  10.9.0.8        4         100     1601     1443     0 23:21:56 Established   10000
  10.10.0.10      4         200     1565     1799     0 23:15:30 Established    9999
// Router ID and AS both compared directly against the peer's own values

Etapa 2 — Parâmetros de vizinhança via Loopback

Se qualquer um dos lados originar a sessão a partir de uma interface Loopback, quatro parâmetros extras precisam estar configurados corretamente, e um quinto — o Device ID — simplesmente não pode ser zero.

Confirme se peer connect-interface aponta para o Loopback usado para originar a sessão — sem isso, o dispositivo assume por padrão a interface física de saída como origem.
Para uma sessão EBGP construída sobre um Loopback (ou qualquer EBGP multi-hop), confirme se peer ebgp-max-hop está configurado com um número de saltos que realmente cubra o caminho.
Se o GTSM estiver em uso, confirme se peer valid-ttl-hops está configurado simetricamente nos dois lados — precisa ser habilitado nos dois lados juntos, não apenas em um.
Ao parear com um dispositivo de outro fabricante, se a sessão se recusa a reconectar após uma reinicialização mesmo com o handshake TCP concluído sem problemas, verifique se este dispositivo realmente tem um Device ID de BGP utilizável — se toda interface com endereço IP está vinculada dentro de uma instância de VPN e não há um Loopback independente, o Device ID resolve para 0.0.0.0, que a maioria das implementações rejeita de imediato.

<Huawei> display bgp vpnv4 vpn-instance VPN1 peer
BGP local Device ID : 0.0.0.0        // invalid -- session will not originate or accept
...
// after adding a Loopback interface outside any VPN instance:
BGP local Device ID : 192.168.1.2
VPN-Instance VPN1, Device ID 192.168.1.2:
Total number of peers : 1  Peers in established state : 1
Peer         V AS     MsgRcvd  MsgSent  OutQ  Up/Down     State       PrefRcv
10.83.255.2  4 39651  10       22       0     02:59:49    Established 1

Etapa 3 — Estabelecida e depois cai: leia o código de erro, não adivinhe

Uma sessão que estava bem e depois caiu, ou que fica oscilando, deixa um motivo exato registrado — você não precisa estar observando no momento em que acontece.

Execute display bgp peer <ip> log-info para obter o histórico Up/Down com um Error Code e Error Subcode para cada transição — Cease/Administrative Shutdown significa que alguém executou shutdown ou peer ignore; Hold Timer Expired significa que os keepalives simplesmente pararam de chegar a tempo; um subcódigo de mudança de configuração significa que um comando que afeta o peer foi modificado.
Na visão de diagnóstico, pads diagnose neighbor bgp imprime um motivo em uma linha, em linguagem clara, para cada peer, sem que você precise reconstruí-lo a partir da configuração.
Se o motivo não for uma ação administrativa, verifique o caminho físico/IGP por baixo — uma rota até o Loopback do peer que recorre a outra rota estática pode redirecionar silenciosamente o próprio tráfego da sessão BGP para um buraco negro Null0 no instante em que um uplink físico cai, mesmo que um ping simples (que faz hash de forma diferente) ainda funcione.

<HUAWEI> display bgp peer 10.8.200.26 log-info
 Date/Time     : 2021-02-06 18:34:31+00:00
 State         : Down
 Error Code    : 4(Hold Timer Expired)
 Error Subcode : 0(UnSpecific)
 Notification  : Send Notification

[~HUAWEI-diagnose] pads diagnose neighbor establish-abnormal bgp history-record
NBR-Peer-IP    Last-Detect-Time State       Reason
1.1.1.1        01-27 20:23:49   OpenConfirm The shutdown command is run in the BGP view.
2.2.2.2        01-27 20:23:49   Idle        The peer ignore command is configured for the BGP peer.

Etapa 4 — Tráfego desigual ou rota agregada instável

A sessão é estável — a «falha» está em como as rotas que ela carrega estão sendo usadas ou reanunciadas.

Se existirem duas ou mais rotas EBGP de custo igual entre o mesmo par de roteadores, mas quase todo o tráfego passar por uma delas, confirme se maximum load-balancing está configurado com um valor de 2 ou mais em todo roteador que enxerga as rotas de custo igual.
Se uma rota resumida/agregada oscilar continuamente sem nenhuma mudança de política e sem que nenhuma rota seja realmente adicionada ou retirada, compare a preferência do protocolo BGP com a preferência da rota estática ou IGP que também alimenta esse agregado — a que estiver vencendo no momento decide se o agregado está «ativo», e uma instabilidade de sessão ou protocolo do lado perdedor inverte isso.

[Device] bgp 65001
[Device-bgp] maximum load-balancing 4
// configure identically on every router in the cross-connected mesh

[Device-bgp] preference 65
// set BGP's preference lower (worse) than the static route feeding the same aggregate (default static preference 60)

6 causas que aparecem repetidamente

Depois que os estados acima indicarem onde está o problema, essas seis causas explicam a maior parte do que realmente está errado.

1. Colisão de Router ID bloqueia a sessão silenciosamente

SINTOMAO peer nunca chega a Established mesmo que o ping de transporte funcione perfeitamente — ele simplesmente fica em OpenSent ou entra em ciclo.

CAUSADois peers acabam com o mesmo Router ID — geralmente depois de uma configuração clonada ou baseada em modelo em que o endereço Loopback, ou a seleção padrão de Router ID, não foi alterado na cópia.

SOLUÇÃOConfigure um Router ID explícito e único em cada dispositivo, geralmente usando seu próprio endereço Loopback.

[Device] bgp 65001
[Device-bgp] router id 2.2.2.2

2. Uma ACL esquecida bloqueia a porta TCP 179

SINTOMAO ping da camada de transporte entre os dois endereços de peer funciona bem, mas a sessão nunca sai de Idle ou Active.

CAUSAUma ACL configurada para um propósito não relacionado — filtragem de segurança, classificação de QoS — acaba negando a porta de origem ou destino TCP bgp no caminho entre os dois peers.

SOLUÇÃOVerifique display acl all nos dois lados e remova ou restrinja a regra que corresponde à porta TCP 179.

<HUAWEI> display acl all
Basic ACL 3001, 2 rules
  rule 5 deny tcp source-port eq bgp
  rule 10 deny tcp destination-port eq bgp
[HUAWEI] acl 3001
[HUAWEI-acl-basic-3001] undo rule 5 destination-port
[HUAWEI-acl-basic-3001] undo rule 10 source-port

3. Vizinhança via Loopback sem connect-interface / ebgp-max-hop, ou Device ID 0.0.0.0

SINTOMAUma sessão com o roteador de outro fabricante se recusa a reconectar após uma reinicialização do dispositivo, mesmo que a conexão TCP subjacente seja concluída sem problemas.

CAUSASe cada interface com endereço IP do dispositivo estiver vinculada dentro de uma instância de VPN e não houver um Loopback independente, o Device ID de BGP resolve para 0.0.0.0 — um valor que a maioria das implementações trata como inválido, então o dispositivo não vai originar nem aceitar uma sessão com esse ID, não importa quão saudável esteja o transporte. Separadamente, sessões originadas em Loopback precisam de peer connect-interface, e sessões EBGP originadas em Loopback ou multi-hop precisam de peer ebgp-max-hop — sem qualquer um dos dois, a sessão fica sem se estabelecer sem erro aparente.

SOLUÇÃOAdicione uma interface Loopback fora de qualquer instância de VPN (ou defina router id explicitamente) para que o Device ID nunca seja 0.0.0.0, e configure connect-interface e ebgp-max-hop sempre que a sessão não for um peer EBGP diretamente conectado simples.

[Device] interface loopback 1
[Device-LoopBack1] ip address 192.168.1.2 32
[Device] bgp 64512
[Device-bgp] peer 10.83.255.2 ebgp-max-hop 2
[Device-bgp] peer 10.83.255.2 connect-interface LoopBack1

4. A iteração de rota redireciona silenciosamente a sessão para um buraco negro Null0

SINTOMAUma sessão BGP com uplink duplo que estava normal cai para OpenSent no instante em que um uplink físico cai — mesmo que ainda seja possível fazer ping no endereço Loopback do peer a partir deste dispositivo.

CAUSAAs rotas estáticas em direção ao Loopback do peer recorrem por meio de outra rota estática em vez de apontar para uma interface e próximo salto explícitos. Quando um enlace físico cai, o próximo salto da rota sobrevivente de custo igual itera para uma rota Null0 configurada para um propósito de buraco negro não relacionado. Um ping sem origem definida faz hash para o caminho que ainda funciona e tem sucesso, mas a sessão BGP — originada do Loopback — faz hash para o caminho que agora itera para Null0, e cai.

SOLUÇÃOFaça cada rota estática apontar para uma interface de saída e próximo salto explícitos, em vez de deixá-la recorrer a outra entrada estática.

[Device] undo ip route-static 10.0.0.1 255.255.255.255 192.168.0.1
[Device] ip route-static 10.0.0.1 255.255.255.255 10GE0/0/2 192.168.0.1
<Device> display bgp peer
// the peer at 10.0.0.1 returns to Established once the recursive path is removed

5. Existem caminhos de custo igual, mas o balanceamento de carga nunca foi habilitado

SINTOMADois ou mais enlaces EBGP de custo igual conectam o mesmo par de roteadores, mas quase todo o tráfego passa por um deles enquanto o outro fica quase ocioso.

CAUSAPor padrão, o BGP instala e usa apenas um único melhor caminho por prefixo — não importa quantas rotas de custo igual realmente existam — a menos que o balanceamento de carga esteja explicitamente habilitado. Sem isso, a seleção de caminho normal do BGP (o menor Router ID entre rotas idênticas, por exemplo) sempre recai sobre o mesmo caminho único.

SOLUÇÃOHabilite maximum load-balancing com um valor de 2 ou mais em cada roteador da malha interconectada, dimensionado para crescimento futuro, e confirme qual valor a plataforma do fabricante do lado remoto suporta, se não for a mesma que esta.

[Device] bgp 65001
[Device-bgp] maximum load-balancing 4

6. Uma disputa de prioridade estática vs. dinâmica faz uma rota agregada oscilar

SINTOMAUma rota resumida anunciada em direção ao backbone oscila continuamente — os peers a jusante a veem aparecer e desaparecer mesmo que ninguém tenha mexido em nenhuma política nem adicionado ou retirado uma rota.

CAUSAO agregado é alimentado tanto por uma rota estática (geralmente um buraco negro) quanto por uma rota aprendida dinamicamente via IBGP ou IGP com preferência melhor que a entrada estática. Toda vez que a sessão subjacente da rota dinâmica oscila — mesmo que brevemente — a fonte preferida do agregado alterna entre as duas, e o agregado é retirado e reanunciado mesmo que nada tenha realmente mudado na rede.

SOLUÇÃODefina a preferência do protocolo dinâmico como pior (numericamente mais alta) do que a da rota estática, para que a entrada estática permaneça como a fonte estável e permanente do agregado.

[Device] bgp 65001
[Device-bgp] preference 65
// static route default preference is 60 -- keep it better than BGP/IGP for this aggregate's source

Cinco perguntas que surgem constantemente

Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.

Meu peer nunca sai de Idle ou Active — qual é a forma mais rápida de saber em qual estado ele realmente está travado?

display bgp peer mostra diretamente a coluna State atual (Idle / Connect / Active / OpenSent / OpenConfirm / Established). Se não estiver claro por que ele não avança além desse estado, o comando da visão de diagnóstico pads diagnose neighbor establish-abnormal bgp history-record imprime um motivo em uma linha, em linguagem clara, para cada peer — «o comando shutdown foi executado na visão do BGP», «o comando peer ignore está configurado» — sem que você precise reconstruí-lo a partir da configuração em execução.

A sessão estava Established há semanas e caiu uma vez — como descubro o motivo depois do fato?

display bgp peer <ip> log-info mantém um histórico de transições Up/Down com o par exato Error Code / Error Subcode para cada uma. O código 6 subcódigo 2 (Administrative Shutdown) significa que alguém executou shutdown ou configurou peer ignore; o código 4 (Hold Timer Expired) significa que os keepalives simplesmente pararam de chegar a tempo — verifique o enlace e a carga de CPU; o código 6 subcódigo 6 significa que um comando que afeta o peer, como ebgp-max-hop, foi alterado. Cruze o timestamp com o log de operações daquele mesmo momento.

Dois enlaces EBGP conectam o mesmo par de roteadores com custo idêntico, mas quase todo o tráfego passa por um deles — por quê?

O BGP instala apenas um único melhor caminho por prefixo por padrão. Sem maximum load-balancing configurado com um valor de 2 ou mais nos roteadores que enxergam os caminhos de custo igual, apenas um caminho é usado, não importa quantas rotas de custo igual realmente existam. Configure em cada roteador do par interconectado, e verifique qual valor a plataforma do fabricante remoto suporta, se não for a mesma que esta.

Uma rota resumida que anunciamos a montante continua oscilando mesmo que ninguém tenha mudado nenhuma política ou rota — o que realmente está mudando?

Isso é mais um problema de prioridade do que de protocolo. Se o agregado é alimentado tanto por uma rota estática quanto por uma rota aprendida dinamicamente via IBGP ou IGP, a que tiver atualmente a melhor preferência decide se o agregado está «ativo». Quando a sessão por trás da rota dinâmica oscila, mesmo que brevemente, a fonte vencedora se inverte e o agregado é retirado e reanunciado — nada mudou de fato na rede. Configure a preferência do protocolo dinâmico como pior do que a da rota estática para que a entrada estática permaneça como a fonte estável.

A configuração parece idêntica nos dois lados, mas uma sessão com o roteador de outro fabricante ainda não sobe depois de uma reinicialização — o que estou deixando passar?

Verifique se este dispositivo realmente tem um Device ID de BGP utilizável. Se toda interface com endereço IP estiver vinculada dentro de uma instância de VPN e não houver um Loopback independente, o Device ID resolve para 0.0.0.0, que a maioria das implementações rejeita de imediato — o dispositivo não vai originar nem aceitar uma sessão com esse ID mesmo que a conexão TCP em si seja concluída sem problemas. Adicione uma interface Loopback fora de qualquer instância de VPN, ou defina router id explicitamente, antes de mudar qualquer outra coisa.

Limites honestos desta nota

Limites honestos desta nota

Esta nota é construída em torno do modelo de classificação de falhas de BGP do roteador Huawei da série AR e de seus comandos display bgp peer / display bgp peer log-info / pads diagnose neighbor bgp, além dos casos de campo por trás deles. Se o seu roteador for de outro fabricante, os comandos exatos mudam, mas a lógica subjacente — correspondência de Router ID e AS, ACLs de camada de transporte, parâmetros de vizinhança via Loopback, iteração de rota, balanceamento de carga ausente, oscilação causada por prioridade — se aplica diretamente. Não cobre em profundidade BGP FlowSpec, validação de origem RPKI, ou cenários de BGP integrados a SR-TE.

Peer travado ou oscilando agora?

Diga-nos a coluna State exata de display bgp peer, ou o Error Code de display bgp peer log-info, e ajudaremos você a interpretar.

WhatsApp com um engenheiro →