Inicio / Notas técnicas / Resolución de problemas de vecino BGP e inestabilidad de rutas

¿El vecino BGP no se establece y las rutas se vuelven inestables? Una lista de verificación completa

Un par atascado en Idle u OpenSent, o una sesión que rebota continuamente arrastrando consigo una ruta, es una de las escaladas más comunes en el borde de una red WAN. Este es el orden de diagnóstico que distingue las pocas causas raíz detrás de la mayoría de estos casos — los comandos display exactos, los códigos de error, y dónde la iteración de rutas rompe silenciosamente una sesión que por lo demás parece normal.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué la columna de estado dice más que el síntoma

No empiezo mirando fijamente la configuración — empiezo por averiguar en cuál de los seis estados está realmente atascado el par.

Una sesión BGP recorre una secuencia fija — Idle, Connect, Active, OpenSent, OpenConfirm, Established — y casi todo caso de «el vecino no sube» es en realidad una pregunta sobre en cuál de esos estados está atascado, no un misterio que se resuelve cambiando ajustes en ambos extremos a la vez. Una sesión que llega a Established y luego cae, rebota, o envía silenciosamente el tráfico solo por una de varias rutas de costo igual es un problema distinto, con su propio orden de diagnóstico, aunque se reporte de la misma forma: «BGP está caído».

A continuación, el árbol de fallas en el que se basa este texto, las comprobaciones de cada rama con los comandos exactos, las causas que aparecen una y otra vez tras las primeras comprobaciones, y algunas respuestas de preguntas frecuentes extraídas de casos reales de campo.

Lea el árbol de fallas antes de tocar cualquier configuración

Las fallas de BGP se dividen en exactamente dos formas: el vecino nunca llega a Established, o llega y algo sigue sin estar bien.

Ubicar primero el síntoma en este árbol ahorra mucho retroceso más adelante — indica cuál de las secciones siguientes aplica realmente a lo que está viendo.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Una vez que sabe qué rama aplica, casi cada comprobación siguiente está a un solo comando display de una causa confirmada — la trampa es tratar una sesión ya Established que se vuelve inestable con la misma lista de verificación que una que nunca llegó a establecerse.La misma disciplina, aplicada a otro protocolo, está detrás de ¿El vecino OSPF está atascado o las rutas se vuelven inestables? Leer la máquina de estados para encontrar la falla, su nota hermana para las adyacencias OSPF.

Recorriendo cada estado

Seis estados, un solo comando exacto para saber en cuál está atascado — y los registros de inestabilidad se explican solos una vez que se entiende el código de error.

Etapa 0 — Confirmar que el transporte realmente conecta

Si el par nunca sale de Idle o Active, no toque todavía la configuración BGP — confirme primero que ambos extremos realmente pueden alcanzarse por TCP 179.

Haga ping entre las dos direcciones de par usando un comando que lleve una dirección de origen y un tamaño de paquete real — ping -a source-ip-address -s packetsize host — ya que una dirección de origen también confirma que la ruta de retorno es válida, y un tamaño de paquete mayor confirma que un Update BGP grande no se perderá silenciosamente en el camino.
Si el ping falla, es un problema de enrutamiento/enlace que hay que resolver por separado, no un problema de BGP.
Si el ping funciona pero la sesión sigue sin avanzar, revise en ambos extremos si hay una ACL que filtre el puerto TCP 179 — a menudo un resto de una política de seguridad o QoS no 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 — Coincidencia de Router ID, número de AS y familia de direcciones

El transporte está bien, pero el par sigue sin salir de OpenSent o muestra «No Neg» — casi siempre es un parámetro concreto que parece correcto aisladamente pero que en realidad no coincide con el otro extremo.

Revise display bgp peer en ambos extremos para el Router ID local. Dos pares que comparten el mismo Router ID — común tras una configuración clonada — bloquean directamente el establecimiento; corríjalo con router id en la vista BGP, normalmente ajustado a la dirección Loopback.
Compare el número de AS configurado con lo que realmente es el otro extremo, no con lo que usted cree que debería ser.
Si la sesión es específica de una familia de direcciones (VPNv4, IPv6, VPNv6), confirme que peer enable está configurado en esa familia de direcciones en ambos extremos — una configuración unilateral se muestra como «No Neg» en lugar de un fallo 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 vecindad por Loopback

Si cualquiera de los extremos origina la sesión desde una interfaz Loopback, hay cuatro parámetros adicionales que deben configurarse correctamente, y un quinto — el Device ID — simplemente no debe ser cero.

Confirme que peer connect-interface apunta al Loopback usado para originar la sesión — sin ello, el dispositivo origina por defecto desde la interfaz física de salida.
Para una sesión EBGP construida sobre un Loopback (o cualquier EBGP multisalto), confirme que peer ebgp-max-hop está configurado con un número de saltos que realmente cubra la ruta.
Si GTSM está en juego, confirme que peer valid-ttl-hops está configurado simétricamente en ambos extremos — debe habilitarse en los dos lados a la vez, no solo en uno.
Al emparejar con un dispositivo de otro fabricante, si la sesión se niega a reconectarse tras un reinicio aunque el handshake TCP se complete sin problemas, verifique si este dispositivo realmente tiene un Device ID BGP utilizable — si todas las interfaces con dirección IP están vinculadas dentro de una instancia VPN y no hay un Loopback independiente, el Device ID se resuelve como 0.0.0.0, que la mayoría de las implementaciones rechazan de plano.

<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 — Establecida y luego cae: lea el código de error, no adivine

Una sesión que estaba bien y luego cayó, o que rebota continuamente, deja una razón exacta registrada — no hace falta estar observando cuando ocurre.

Ejecute display bgp peer <ip> log-info para obtener el historial Up/Down con un Error Code y Error Subcode para cada transición — Cease/Administrative Shutdown significa que alguien ejecutó shutdown o peer ignore; Hold Timer Expired significa que los keepalives simplemente dejaron de llegar a tiempo; un subcódigo de cambio de configuración significa que se modificó un comando que afecta al par.
En la vista de diagnóstico, pads diagnose neighbor bgp imprime una razón de una línea en lenguaje claro por cada par, sin que tenga que reconstruirla a partir de la configuración.
Si la razón no es una acción administrativa, revise la ruta física/IGP subyacente — una ruta hacia el Loopback del par que recurre a través de una ruta estática puede redirigir silenciosamente el propio tráfico de la sesión BGP hacia un agujero negro Null0 en el instante en que cae un enlace físico ascendente, incluso mientras un simple ping (que se distribuye de forma diferente) sigue teniendo éxito.

<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áfico desigual o ruta agregada inestable

La sesión es estable — la «falla» está en cómo se usan o se reanuncian las rutas que transporta.

Si existen dos o más rutas EBGP de costo igual entre el mismo par de routers pero casi todo el tráfico va por una de ellas, confirme que maximum load-balancing está configurado con un valor de 2 o más en cada router que ve las rutas de costo igual.
Si una ruta resumida/agregada se vuelve inestable continuamente sin ningún cambio de política y sin que realmente se añada o retire ninguna ruta, compare la preferencia del protocolo BGP con la preferencia de la ruta estática o IGP que también alimenta ese agregado — la que gane actualmente decide si el agregado está «activo», y una interrupción de sesión o protocolo del lado perdedor lo hace cambiar.

[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 aparecen una y otra vez

Una vez que los estados anteriores le han indicado dónde está el problema, estas seis causas explican la mayor parte de lo que realmente está mal.

1. Una colisión de Router ID bloquea la sesión silenciosamente

SÍNTOMAEl par nunca llega a Established aunque el ping de transporte funciona perfectamente — simplemente se queda en OpenSent o cicla.

CAUSADos pares terminan con el mismo Router ID — a menudo tras una configuración clonada o basada en plantilla donde la dirección Loopback, o la selección de Router ID por defecto, no se cambió en la copia.

SOLUCIÓNConfigure un Router ID explícito y único en cada dispositivo, generalmente usando su propia dirección Loopback.

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

2. Una ACL residual bloquea el puerto TCP 179

SÍNTOMAEl ping de capa de transporte entre las dos direcciones de par funciona bien, pero la sesión nunca sale de Idle o Active.

CAUSAUna ACL configurada para un propósito no relacionado — filtrado de seguridad, clasificación de QoS — resulta que deniega el puerto de origen o destino TCP bgp en la ruta entre los dos pares.

SOLUCIÓNRevise display acl all en ambos extremos y elimine o restrinja la regla que coincide con el puerto 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. Vecindad por Loopback sin connect-interface / ebgp-max-hop, o un Device ID de 0.0.0.0

SÍNTOMAUna sesión hacia el router de otro fabricante se niega a reconectarse tras un reinicio del dispositivo, aunque la conexión TCP subyacente se completa sin problemas.

CAUSASi cada interfaz con dirección IP del dispositivo está vinculada dentro de una instancia VPN y no hay un Loopback independiente, el Device ID de BGP se resuelve como 0.0.0.0 — un valor que la mayoría de las implementaciones considera inválido, así que el dispositivo no originará ni aceptará una sesión con ese ID sin importar lo saludable que esté el transporte. Aparte, las sesiones originadas desde un Loopback necesitan peer connect-interface, y las sesiones EBGP originadas desde un Loopback o multisalto necesitan peer ebgp-max-hop — sin cualquiera de los dos, la sesión queda sin establecer sin un error evidente.

SOLUCIÓNAñada una interfaz Loopback fuera de cualquier instancia VPN (o configure router id explícitamente) para que el Device ID nunca sea 0.0.0.0, y configure connect-interface y ebgp-max-hop siempre que la sesión no sea un par EBGP directamente conectado simple.

[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. La iteración de rutas redirige silenciosamente la sesión a un agujero negro Null0

SÍNTOMAUna sesión BGP con doble enlace ascendente que funcionaba bien cae a OpenSent en el momento en que un enlace físico se cae — aunque todavía se pueda hacer ping a la dirección Loopback del par desde este dispositivo.

CAUSALas rutas estáticas hacia el Loopback del par recurren a través de otra ruta estática en lugar de apuntar a una interfaz y un siguiente salto explícitos. Cuando cae un enlace físico, el siguiente salto de la ruta sobreviviente de costo igual itera hacia una ruta Null0 configurada para un propósito de agujero negro no relacionado. Un ping sin origen se distribuye por hash hacia la ruta que aún funciona y tiene éxito, pero la sesión BGP — originada desde el Loopback — se distribuye por hash hacia la ruta que ahora itera a Null0, y cae.

SOLUCIÓNHaga que cada ruta estática apunte a una interfaz de salida y un siguiente salto explícitos en lugar de dejar que recurra a través de otra 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. Existen rutas de costo igual, pero el balanceo de carga nunca se habilitó

SÍNTOMADos o más enlaces EBGP de costo igual conectan el mismo par de routers, pero casi todo el tráfico va por uno de ellos mientras el otro permanece casi inactivo.

CAUSAPor defecto, BGP solo instala y usa una única mejor ruta por prefijo — sin importar cuántas rutas de costo igual existan realmente — a menos que el balanceo de carga esté explícitamente habilitado. Sin él, la selección de ruta BGP habitual (el Router ID más bajo entre rutas idénticas, por ejemplo) siempre recae en la misma ruta única.

SOLUCIÓNHabilite maximum load-balancing con un valor de 2 o más en cada router de la malla interconectada, dimensionado para el crecimiento futuro, y confirme qué valor admite la plataforma del fabricante del extremo remoto si no es la misma que esta.

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

6. Un tira y afloja de prioridad estática vs. dinámica hace inestable una ruta agregada

SÍNTOMAUna ruta resumida anunciada hacia el backbone se vuelve inestable continuamente — los pares aguas abajo la ven aparecer y desaparecer aunque nadie haya tocado ninguna política ni añadido o retirado una ruta.

CAUSAEl agregado se alimenta tanto de una ruta estática (a menudo un agujero negro) como de una ruta aprendida dinámicamente por IBGP o IGP con mejor preferencia que la entrada estática. Cada vez que la sesión subyacente de la ruta dinámica titubea — aunque sea brevemente — la fuente preferida del agregado cambia entre las dos, y el agregado se retira y se reanuncia aunque nada haya cambiado realmente en la red.

SOLUCIÓNConfigure la preferencia del protocolo dinámico peor (numéricamente más alta) que la de la ruta estática, para que la entrada estática siga siendo la fuente estable y permanente del 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 preguntas que surgen constantemente

Sacadas directamente del campo — las que vale la pena tener respondidas de antemano.

Mi par nunca sale de Idle o Active — ¿cuál es la forma más rápida de saber en qué estado está realmente atascado?

display bgp peer muestra directamente la columna State actual (Idle / Connect / Active / OpenSent / OpenConfirm / Established). Si no es evidente por qué no avanza más allá de ese estado, el comando de vista de diagnóstico pads diagnose neighbor establish-abnormal bgp history-record imprime una razón de una línea en lenguaje claro por cada par — «se ejecutó el comando shutdown en la vista BGP», «se configuró el comando peer ignore» — sin que tenga que reconstruirla a partir de la configuración en ejecución.

La sesión estuvo Established durante semanas y luego cayó una vez — ¿cómo averiguo por qué después de que ocurrió?

display bgp peer <ip> log-info mantiene un historial de transiciones Up/Down con el par exacto Error Code / Error Subcode para cada una. El código 6 subcódigo 2 (Administrative Shutdown) significa que alguien ejecutó shutdown o configuró peer ignore; el código 4 (Hold Timer Expired) significa que los keepalives simplemente dejaron de llegar a tiempo — revise el enlace y la carga de CPU; el código 6 subcódigo 6 significa que se modificó un comando que afecta al par, como ebgp-max-hop. Cruce la marca de tiempo con el registro de operaciones de ese mismo momento.

Dos enlaces EBGP conectan el mismo par de routers con costo idéntico, pero casi todo el tráfico va por uno de ellos — ¿por qué?

BGP solo instala una única mejor ruta por prefijo de forma predeterminada. Sin maximum load-balancing configurado con un valor de 2 o más en los routers que ven las rutas de costo igual, solo se usa una ruta sin importar cuántas rutas de costo igual existan realmente. Configúrelo en cada router del par interconectado, y verifique qué valor admite la plataforma del fabricante remoto si no es la misma que esta.

Una ruta resumida que anunciamos hacia arriba sigue siendo inestable aunque nadie cambió ninguna política ni ruta — ¿qué es lo que realmente se mueve?

Esto es un problema de prioridad más que de protocolo. Si el agregado se alimenta tanto de una ruta estática como de una ruta aprendida dinámicamente por IBGP o IGP, la que tenga actualmente la mejor preferencia decide si el agregado está «activo». Cuando la sesión detrás de la ruta dinámica titubea, aunque sea brevemente, la fuente ganadora cambia y el agregado se retira y se reanuncia — nada cambió realmente en la red. Configure la preferencia del protocolo dinámico peor que la de la ruta estática para que la entrada estática siga siendo la fuente estable.

La configuración parece idéntica en ambos extremos, pero una sesión con el router de otro fabricante sigue sin subir tras un reinicio — ¿qué me falta?

Verifique si este dispositivo realmente tiene un Device ID de BGP utilizable. Si todas las interfaces con dirección IP están vinculadas dentro de una instancia VPN y no hay un Loopback independiente, el Device ID se resuelve como 0.0.0.0, que la mayoría de las implementaciones rechaza de plano — el dispositivo no originará ni aceptará una sesión con ese ID aunque la conexión TCP en sí se complete sin problemas. Añada una interfaz Loopback fuera de cualquier instancia VPN, o configure router id explícitamente, antes de cambiar cualquier otra cosa.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se construye en torno al modelo de clasificación de fallas BGP del router Huawei serie AR y sus comandos display bgp peer / display bgp peer log-info / pads diagnose neighbor bgp, además de los casos de campo detrás de ellos. Si su router es de otro fabricante, los comandos exactos cambian, pero la lógica subyacente — coincidencia de Router ID y AS, ACL de capa de transporte, parámetros de vecindad por Loopback, iteración de rutas, balanceo de carga ausente, inestabilidad impulsada por prioridad — se traslada directamente. No cubre en profundidad BGP FlowSpec, la validación de origen RPKI, ni los escenarios de BGP integrados con SR-TE.

¿Par atascado o inestable ahora mismo?

Díganos la columna State exacta de display bgp peer, o el Error Code de display bgp peer log-info, y le ayudaremos a interpretarlo.

WhatsApp con un ingeniero →