Solución de problemas básicos de Border Gateway Protocol
Contenido
Introducción
Este documento describe cómo resolver los problemas más comunes con el Protocolo de gateway fronterizo (BGP) y proporciona soluciones y pautas básicas.
Prerequisites
Requirements
No hay requisitos previos específicos para este documento. El conocimiento básico del protocolo BGP es útil, puede consultar la Guía de Configuración BGP para obtener más información.
Componentes Utilizados
Este documento no se limita a versiones específicas de software y hardware, pero los comandos son aplicables para Cisco IOS® y Cisco IOS® XE.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
Este documento describe una guía básica para resolver los problemas más comunes en el Protocolo de gateway fronterizo (BGP), proporciona acciones correctivas, comandos/depuraciones útiles para detectar la causa raíz de los problemas y prácticas recomendadas para evitar posibles problemas. Tenga en cuenta que no se pueden considerar todas las variables y escenarios posibles y que Cisco TAC podría requerir un análisis más profundo.
Topología
Utilice este diagrama de topología como referencia para los resultados proporcionados en este documento.
Escenarios y problemas
Adyacencia hacia abajo
Si una sesión BGP está inactiva y no se activa, ejecute el comandoshow ip bgp all summary command. Here you can find the current status of the session:
- Si la sesión no está en estado activo, puede variar entre IDLE y ACTIVE (depende del proceso de la máquina de estado finito).
- Si la sesión está activa, verá el número de prefijos recibidos.
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
Sin conectividad
El primer requisito que debe garantizarse es la conectividad entre ambos peers para que se pueda establecer la sesión TCP en el puerto 179. Están conectados directamente o no. Un simple ping es útil para este asunto. Si se establece el peering entre las interfaces de loopback, se debe realizar un loopback a un ping de loopback. Si se realiza una prueba de ping sin un loopback específico como interfaz de origen, la dirección IP de la interfaz física saliente se utiliza como dirección IP de origen del paquete en lugar de la dirección IP de loopback del router.
Si el ping no es exitoso, considere estas causas:
- Sin par de ruta conectado o sin ruta en absoluto:
show ip route peer_IP_addressse puede utilizar. - Problema de capa 1: debe tenerse en cuenta la interfaz física, el SFP (conector), el cable o el problema externo (transporte y proveedor, si procede).
- Compruebe cualquier firewall o lista de acceso que pueda bloquear la conexión.
Si el ping es exitoso, considere lo siguiente:
Problemas de configuración
- Dirección IP o AS configurados incorrectos: Si la dirección IP es incorrecta, no se muestra ningún mensaje de este tipo, pero asegúrese de que se realiza la configuración correcta. Para el AS incorrecto, debe ver un mensaje como con el
show loggingcomando.
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
Verifique la configuración BGP en ambos extremos para corregir los números AS o la dirección IP del par.
- ID de router duplicado:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
Verifique el identificador BGP en ambos extremos medianteshow ip bgp all summaryy corrija el problema duplicado. Esto se puede lograr manualmente con el comando globalbgp router-id X.X.X.Xbajo la configuración del router bgp. Como práctica recomendada, asegúrese de que el ID del router se establece manualmente en un número único.
- Origen BGP y TTL:
La mayoría de las sesiones de iBGP se configuran a través de las interfaces de loopback alcanzables a través de un IGP. Esta interfaz de loopback debe definirse explícitamente como el origen. Realice esto con el comandoneighbor ip-address update-source interface-id.
Para el peer eBGP, las interfaces conectadas directamente se utilizan generalmente para el peering, y hay una verificación para que Cisco IOS/Cisco IOS XE cumpla con este propósito, o ni siquiera intenta establecer la sesión. Si se intenta eBGP desde el loopback al loopback en los routers conectados directamente, esta verificación se puede inhabilitar para un vecino específico en ambos extremos víaneighbor ip-address disable-connected-check.
Sin embargo, si hay saltos múltiples entre los peers eBGP, se requiere un conteo de saltos adecuado, asegúrese de neighbor ip-address ebgp-multihop [hop-count]que esté configurado con el conteo de saltos correcto para que se pueda establecer la sesión.
Si no se especifica el conteo de saltos, el valor TTL predeterminado para las sesiones iBGP es 255, mientras que el valor TTL predeterminado para las sesiones eBGP es 1.
Problemas de sesión TCP
Una acción útil para probar el puerto 179 es un telnet manual de un par al otro:
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
Abrir/cerrar conexión, o la conexión rechazada por el host remoto indica que los paquetes alcanzan el extremo remoto, entonces, asegúrese de que no haya problemas con el plano de control en el extremo lejano. De lo contrario, si hay un destino inalcanzable, verifique cualquier firewall o lista de acceso que pueda bloquear el puerto TCP 179, o los paquetes BGP, o cualquier pérdida de paquetes en la trayectoria.
En caso de problema de autenticación, los mensajes que puede ver:
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
Verifique los métodos de autenticación, la contraseña y la configuración relacionada, y para resolver problemas adicionales consulte Ejemplo de Configuración de Autenticación MD5 entre Peers BGP.
Si la sesión TCP no aparece, puede utilizar los siguientes comandos para el aislamiento:
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
Rebotes de adyacencia
Si la sesión está activa o inactiva, busque show logy podrá ver algunos escenarios.
Flap de interfaz
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
Como indica el mensaje, la razón de esta falla es la situación de la interfaz inactiva, busque cualquier problema físico en el puerto/SFP, el cable o las desconexiones.
Temporizador de espera vencido
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
Es una situación muy común; significa que el router no recibió ni procesó un mensaje de señal de mantenimiento ni ningún mensaje de actualización antes de que caducara el temporizador de espera. El dispositivo envía un mensaje de notificación y cierra la sesión. Las razones más comunes para este problema se enumeran aquí:
- Problemas de interfaz: Busque errores de entrada, caídas de la cola de entrada o problemas físicos en las interfaces conectadas de ambos pares;
show interfacepuede utilizarse con este fin.
- Pérdida de paquetes en tránsito: A veces, los paquetes de saludo se pueden descartar en el tránsito, la mejor manera de asegurarse de que esto es una captura de paquetes en el nivel de interfaz.
- Puede utilizar la captura de paquetes integrada en los dispositivos Cisco IOS y Cisco IOS XE.
- En caso de que los paquetes se vean en el nivel de interfaz, debe asegurarse de que alcanzan el plano de control, EPC en el plano de control o
debug bgp [vrf name] ipv4 unicast keepaliveses útil.
- CPU alta: una condición de CPU alta puede causar caídas en el plano de control,
show processes cpu [sorted|history]es útil para identificar el problema. Según la plataforma, puede encontrar el siguiente paso para resolver problemas con el Documento de referencia de la CPU
- Cuestiones de política de CoPP: La metodología de solución de problemas varía para cada plataforma y está fuera del alcance de este documento.
- discrepancia de MTU: Si hay discrepancias de MTU en la trayectoria y si los mensajes ICMP se bloquean en la trayectoria de origen a destino, la PMTUD no funciona y puede dar lugar a inestabilidad de sesión. Las actualizaciones se envían con el valor MSS negociado y un conjunto de bits DF. Si un dispositivo en la trayectoria o incluso el destino no puede aceptar los paquetes con una MTU más alta, envía un mensaje de error ICMP de vuelta al altavoz BGP. El router de destino espera que el keepalive BGP o el paquete de actualización BGP actualice su temporizador de retención.
- Puede verificar el MSS negociado con
show ip bgp neighbors ip_address.
- Puede verificar el MSS negociado con
Una prueba de ping a un vecino específico con el conjunto df puede mostrarle si dicha MTU es válida a lo largo de la trayectoria:
ping 198.51.100.2 size max_seg_size df
Si se encuentran problemas de MTU, se debe realizar una revisión precisa de la configuración para garantizar que los valores de MTU sean consistentes en toda la red.
Problemas con AFI/SAFI
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
El identificador de familia de direcciones (AFI) es una extensión de capacidad agregada por BGP multiprotocolo (MP-BGP). Correlaciona con un protocolo de red específico, como IPv4, IPv6 y similares, y granularidad adicional a través de un identificador de familia de direcciones subsiguiente (SAFI), como unidifusión y multidifusión. MBGP logra esta separación mediante los atributos de trayectoria BGP (PA) MP_REACH_NLRI y MP_UNREACH_NLRI. Estos atributos se transportan dentro de los mensajes de actualización BGP y se utilizan para transportar información de alcance de red para diferentes familias de direcciones.
El mensaje le da los números de estos AFI/SAFI registrados por IANA:
- Números de familia de direcciones IANA
- Parámetros de identificadores de familia de direcciones (SAFI) posteriores
- Verifique la configuración BGP para las familias de direcciones que se pretenden en ambos lados para corregir cualquier familia de direcciones no deseada.
- Utilícelo
neighbor ip-address dont-capability-negotiateen ambos extremos. Para obtener más información, consulte Funciones no admitidas que causan el mal funcionamiento del par BGP
Instalación y selección de rutas
Para una mejor explicación sobre cómo funciona BGP y para seleccionar la mejor trayectoria, refiérase a Algoritmo de Selección de la Mejor Trayectoria BGP
Salto siguiente
Para que una ruta se instale en nuestra tabla de ruteo, el salto siguiente debe ser alcanzable; de lo contrario, incluso si el prefijo está en nuestra tabla de BGP Loc-RIB, no se introduce en RIB. Como regla de evitación de loop, en Cisco IOS/Cisco IOS XE, iBGP no cambia el atributo de salto siguiente y deja AS_PATH solo mientras que eBGP reescribe el salto siguiente y antepone su AS_PATH.
Puede marcar siguiente salto conshow ip bgp [prefix].Le da el siguiente salto y la palabra inaccesible. En el ejemplo, este es un prefijo anunciado por R1 vía eBGP a R2 y aprendido por R3 vía conexión iBGP desde R2.
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CSTEn la salida, el salto siguiente es la interfaz saliente de R1 que no conoce R3. Para corregir esta situación, puede anunciar el salto siguiente a través de IGP, ruta estática o utilizar el neighbor ip-address next-hop-selfcomando en el peer iBGP para modificar la IP del salto siguiente (que está conectada directamente). En el ejemplo del diagrama, esta configuración debe estar en R2; el vecino hacia R3 (neighbor 10.0.23.3 next-hop-self).
Como resultado, el salto siguiente cambia (después de una clear ip bgp 10.0.23.2 soft) a la interfaz conectada directamente (alcanzable) y se instala el prefijo.
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CSTFallo de RIB
Esto sucede cuando la ruta no se puede instalar en el RIB global, lo que resulta en una falla del RIB. La razón común es cuando el mismo prefijo ya está en RIB para otro protocolo de ruteo con una distancia administrativa menor, pero la razón exacta de una falla de RIB se observa con el comando show ip bgp rib-failure. Para obtener una explicación más detallada, puede consultar este enlace:
Condición de carrera
El problema más común observado es cuando se prefiere IGP sobre eBGP en un escenario de redistribución mutua. Cuando una ruta IGP se redistribuye en BGP, se considera generada localmente por BGP y obtiene un peso de 32768 de forma predeterminada. A todos los prefijos recibidos de un par BGP se les asigna un peso local de 0 de forma predeterminada. Por lo tanto, si se debe comparar el mismo prefijo, el prefijo con el peso más alto se instala en la tabla de ruteo según el proceso de selección de la mejor trayectoria BGP y es por esto que la ruta IGP se instala en RIB.
La solución para este problema, es establecer un peso más alto para todas las rutas recibidas del peer BGP bajo la configuración bgp del router:
neighbor ip-address weight 40000
Otros problemas
BGP Slow Peer
Es un peer que no puede mantenerse al día con la velocidad a la que el remitente genera mensajes de actualización. Hay muchas razones para que un par muestre este problema; alta CPU en uno de los peers, exceso de tráfico o pérdida de tráfico en un link, recurso de ancho de banda, entre otros.
Problemas de memoria
BGP utiliza la memoria asignada al proceso de Cisco IOS para mantener los prefijos de red, las mejores trayectorias, las políticas y toda la configuración relacionada para funcionar correctamente. Los procesos generales se observan con el comandoshow processes memory sorted:
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
Conjunto de procesadores es la memoria utilizada; alrededor de 2,1 GB en el ejemplo. A continuación, debe observar la columna Holding para identificar el subproceso que contiene la mayor parte. Luego, debe verificar las sesiones BGP que tiene, cuántas rutas se reciben y la configuración que se utiliza.
Pasos comunes para reducir la retención de memoria por BGP:
- Filtrado BGP: si no es necesario recibir una tabla BGP completa, utilice políticas para filtrar rutas e instalar solamente los prefijos que necesite.
- Reconfiguración de software: Busque neighbor ip_address soft-reconfiguration inbound bajo la configuración BGP; este comando le permite ver todos los prefijos recibidos antes que cualquier política entrante (Adj-RIB-in). Sin embargo, esta tabla necesita alrededor de la mitad de la tabla BGP Local RIB actual para almacenar esta información para que pueda evitar esta configuración a menos que se requiera obligatoriamente, o sus prefijos actuales sean pocos.
Uso elevado de la CPU
Los routers utilizan diferentes procesos para que BGP funcione. Para verificar que el proceso BGP es la causa de una alta utilización de la CPU, utilice elshow process cpu sorted comando.
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
Estos son los procesos comunes, las causas y los pasos generales para superar la alta utilización de la CPU debido a BGP:
- Router BGP: Se ejecuta una vez por segundo para proteger una convergencia más rápida. Es uno de los hilos más importantes. Lee los mensajes de actualización de bgp, valida los prefijos/redes y atributos, actualiza la tabla de red/prefijo y la tabla de atributos por AFI/SAFI, realiza el cálculo de la mejor trayectoria entre muchas otras tareas.
Una gran pérdida de rutas es un escenario muy común que lleva a esta situación. - Escáner BGP: Proceso de baja prioridad que se ejecuta cada 60 segundos de forma predeterminada. Este proceso verifica la tabla BGP completa para verificar la disponibilidad del siguiente salto y actualiza la tabla BGP en consecuencia, en caso de que haya algún cambio para una trayectoria. Se ejecuta a través de la Base de información de routing (RIB) con fines de redistribución.
Verifique la escalabilidad de la plataforma, a medida que se instalan más prefijos y rutas y se utiliza TCAM, se necesitan más recursos y, por lo general, un dispositivo sobrecargado conduce a tales situaciones.
- BGP I/O: Se ejecuta cuando se reciben los paquetes de control BGP y administra la colocación en cola y el procesamiento de los paquetes BGP. Si hay paquetes excesivos recibidos en la cola BGP durante un período largo, o si hay un problema con TCP, el router muestra síntomas de CPU alta debido al proceso de E/S BGP. (Generalmente, el router BGP también es alto en esta situación. Observe los recuentos de mensajes para identificar los pares y los paquetes de captura para identificar el origen de estos mensajes.)
- Abierto BGP: Proceso utilizado al establecer la sesión. No es un problema común de CPU alta a menos que la sesión se atasque en el estado abierto.
- Evento BGP: es responsable del procesamiento del siguiente salto. Busque los flaps next-hops en los prefijos recibidos.
Información Relacionada
- Soporte Técnico y Documentación - Cisco Systems
- Guía de configuración de BGP
- Ejemplo de Configuración de Autenticación MD5 entre Peers BGP
- Captura de paquetes integrada
- Inestabilidad de Vecino BGP con Troubleshooting de MTU
-
Parámetros de identificadores de familia de direcciones (SAFI) posteriores
- Las Funciones no Soportadas Causan el Malfuncionamiento del Peer BGP
- Algoritmo de selección del mejor trayecto BGP
- Comprensión de BGP RIB-failure and The Command bgp suppress-inactive
- Comprenda la importancia del atributo de ruta de peso BGP en situaciones de conmutación por error de red
- Utilice la Función "Slow Peer" de BGP para Resolver Problemas de Peer Lento
- Configuración de routers BGP para obtener un rendimiento óptimo y un consumo de memoria reducido
- Resolución de problemas de alta utilización de la CPU causados por el proceso del escáner o del router BGP
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
4.0 |
19-Feb-2025
|
Recertificación |
3.0 |
25-Sep-2023
|
Actualización de IOS XE (guión eliminado) y adición de marca comercial, SEO y formato. |
2.0 |
21-Feb-2023
|
Recertificación. |
1.0 |
04-Aug-2022
|
Versión inicial |
Comentarios