Troubleshooting de Rutas BGP Inestables (Falla de Ruteo Recursivo)

Introducción

Este documento describe cómo resolver un problema de inestabilidad en las rutas del Protocolo de la gateway marginal (BGP) que causa una falla recursiva de ruteo. 

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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 cómo resolver un problema de inestabilidad en las rutas del Protocolo de la gateway marginal (BGP) que causa una falla recursiva de ruteo.

Los síntomas comunes de la falla de ruteo recursivo en BGP son:

• Eliminación y reinserción constantes de rutas BGP en la tabla de ruteo.

• Pérdida de conectividad hacia los destinos detectada a través de BGP.

Consulte este diagrama de red cuando use este documento:

Diagrama de la red

Consulte estas configuraciones mientras utiliza este documento:

hostname RTR-A
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
!
interface Serial8/0
 ip address 192.168.16.1 255.255.255.252
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.20.20.20 remote-as 2
 neighbor 10.20.20.20 ebgp-multihop 2
 neighbor 10.20.20.20 update-source Loopback0
!
ip route 10.20.20.0 255.255.255.0 192.168.16.2

hostname RTR-B

!
interface Loopback0
 ip address 10.20.20.20 255.255.255.255
!
interface Ethernet0/0
 ip address 172.16.1.1 255.255.255.0
!

interface Serial8/0
 ip address 192.168.16.2 255.255.255.252
!
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 network 10.20.20.20 mask 255.255.255.255
 network 172.16.1.0 mask 255.255.255.0
 neighbor 10.10.10.10 remote-as 1
 neighbor 10.10.10.10 ebgp-multihop 2
 neighbor 10.10.10.10 update-source Loopback0
 no auto-summary
!
ip route 10.10.10.0 255.255.255.0 192.168.16.1
!

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Problema

Síntomas

Estos dos síntomas se observan con falla de ruteo recursivo:

• La inestabilidad continua de las rutas aprendidas por BGP en la tabla de IP Routing.

  Observe la tabla de ruteo continuamente durante un par de minutos para ver el aleteo.

RTR-A#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - ISIS level-1, L2 - ISIS level-2, ia - ISIS inter are
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B       10.20.20.20/32 [20/0] via 10.20.20.20, 00:00:35
S       10.20.20.0/24 [1/0] via 192.168.16.2
     172.16.0.0/24 is subnetted, 1 subnets
B       172.16.1.0 [20/0] via 10.20.20.20, 00:00:35
     10.0.0.0/32 is subnetted, 1 subnets
C       10.10.10.10 is directly connected, Loopback0
     192.168.16.0/30 is subnetted, 1 subnets
C       192.168.16.0 is directly connected, Serial8/0

Nota: Es útil utilizar el comando show ip route | include , 00:00 para observar las rutas inestables cuando se trata de tablas de ruteo grandes.

Después de esperar aproximadamente un minuto, los resultados del comando show ip route cambian a esto:

RTR-A#show ip route
[..]

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
S       10.20.20.0 [1/0] via 192.168.16.2
     10.0.0.0/32 is subnetted, 1 subnets
C       10.10.10.10 is directly connected, Loopback0
     192.168.16.0/30 is subnetted, 1 subnets
C       192.168.16.0 is directly connected, Serial8/0

Nota: Las rutas BGP no se encuentran en la tabla de ruteo anterior.

• Cuando las rutas BGP están presentes en la tabla de ruteo, la conectividad a esas redes falla.

  Para observar esto, cuando la tabla de ruteo del Rtr-A tiene la ruta aprendida BGP 172.16.1.0/24 en su tabla de ruteo, un ping al host válido 172.16.1.1 falla.

  RTR-A#show ip route 172.16.1.0
  Routing entry for 172.16.1.0/24
    Known via "bgp 1", distance 20, metric 0
    Tag 2, type external
    Last update from 10.20.20.20 00:00:16 ago
    Routing Descriptor Blocks:
    * 10.20.20.20, from 10.20.20.20, 00:00:16 ago
        Route metric is 0, traffic share count is 1
        AS Hops 1
  
  RTR-A#ping 172.16.1.1
  
  Type escape sequence to abort.
  Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
  .....
  Success rate is 0 percent (0/5)
  RTR-A#

Falla recursiva de ruteo

En Rtr-A, observe la ruta hacia el par BGP 10.20.20.20. La ruta se mueve sistemáticamente entre los dos saltos siguientes cada minuto aproximadamente.

RTR-A#show ip route 10.20.20.20
Routing entry for 10.20.20.20/32
  Known via "bgp 1", distance 20, metric 0
  Tag 2, type external
  Last update from 10.20.20.20 00:00:35 ago
  Routing Descriptor Blocks:
  * 10.20.20.20, from 10.20.20.20, 00:00:35 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

La ruta hacia la dirección IP del par BGP se aprende a través del propio BGP; por lo tanto, crea una falla de ruteo recursivo.

Después de aproximadamente un minuto, la ruta cambia a:

RTR-A#show ip route 10.20.20.20
Routing entry for 10.20.20.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.16.2
      Route metric is 0, traffic share count is 1

Causas de la Falla de Ruteo Recursivo

Estos pasos describen la causa de falla de ruteo recurrente:

1. Consulte la configuración de Rtr-A. En esta configuración, se configura una ruta estática 10.20.20.0/24 para que apunte al salto siguiente conectado directamente 192.168.16.2. Con esta ruta estática, se establece una sesión BGP con el peer Rtr-B 10.20.20.20.

2. Rtr-B anuncia las rutas BGP 172.16.1.0/24 y 10.20.20.20/32 a Rtr-A con su dirección IP de loopback 10.20.20.20 como en el siguiente salto.

3. Rtr-A recibe las rutas BGP anunciadas por Rtr-B e intenta instalar el 10.20.20.20/32. Esto es más específico que 10.20.20.0/24 que ya está configurado en Rtr-A como una ruta estática. Dado que se prefiere la ruta coincidente más larga, se prefiere 10.20.20.20/32 en lugar de 10.20.20.0/24. Consulte Selección de Rutas en Routers de Cisco para obtener más información. La ruta instalada 10.20.20.20/32 tiene el salto siguiente de 10.20.20.20 (dirección IP de iguales Rtr-B) en la tabla de ruteo. Esto conduce a una falla de ruteo recursivo ya que la ruta hacia 10.20.20.20/32 tiene un salto siguiente propio.

   Para entender la razón detrás de por qué el ruteo recursivo falla en esta situación en particular, necesita entender cómo funciona el algoritmo de ruteo. Para cualquier ruta conectada de forma no directa en la tabla de ruteo cuya dirección IP de próximo salto no sea una interfaz conectada de forma directa del router, el algoritmo busca de forma recursiva en la tabla de ruteo hasta encontrar una interfaz conectada de forma directa a la que pueda reenviar los paquetes.

   En esta situación particular, el Rtr-A aprende una ruta a la red conectada no directamente 10.20.20.20/32 con un salto siguiente conectado no directamente de 10.20.20.20 (en sí). El algoritmo de ruteo se ejecuta en una falla de loop de ruteo recursivo porque no puede encontrar ninguna interfaz conectada directamente a la cual enviar paquetes destinados a 10.20.20.20/32.

4. El router detecta que esta ruta no conectada directamente 10.20.20.20/32 tiene una falla de ruteo recursivo y retira 10.20.20.20/32 de la tabla de ruteo. En consecuencia, todas las rutas aprendidas por BGP con la dirección IP de siguiente salto 10.20.20.20 también se retiran de la tabla de ruteo.

5. La totalidad del proceso se repite desde el Paso 1. Puede confirmar esto si ejecuta el comando debug ip routing .

   Nota: Antes de ejecutar cualquier comando debug, ejecute el comando debug en una lista de control de acceso (ACL) para una red específica a fin de limitar la salida de debug. En este ejemplo, configure una ACL para limitar el resultado de la depuración.

   RTR-A(config)#access-list 1 permit 10.20.20.20
   RTR-A(config)#access-list 1 permit 172.16.1.0 
   RTR-A(config)#end
   
   
   RTR-A#debug ip routing 1 
   IP routing debugging is on for access list 1
    
   00:29:50: RT: add 10.20.20.20/32 via 10.20.20.20, bgp metric [20/0]
   00:29:50: RT: add 172.16.1.0/24 via 10.20.20.20, bgp metric [20/0]
   00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:46: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:46: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:48: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:48: RT: recursion error routing 10.20.20.20 - probable routing loop
   00:30:50: RT: del 10.20.20.20/32 via 10.20.20.20, bgp metric [20/0]
   00:30:50: RT: delete subnet route to 10.20.20.20/32
   00:30:50: RT: del 172.16.1.0/24 via 10.20.20.20, bgp metric [20/0]
   00:30:50: RT: delete subnet route to 172.16.1.0/24

6. Si la recursión de ruta falla continuamente, aparece este mensaje de error:

   %COMMON_FIB-SP-6-FIB_RECURSION: 10.71.124.25/32 has too many (8) levels of
   recursion during setting up switching info
   %COMMON_FIB-SP-STDBY-6-FIB_RECURSION: 10.71.124.25/32 has too many (8)
   levels of recursion during setting up switching info

   Esto se debe a que las retransmisiones de TCP ocurren en la red habilitada para MPLS. Si un mensaje de keepalive BGP se envía una vez al Peer BGP debido a que el link de transporte está inactivo, el Peer BGP vecino no acepta más paquetes keepalive aunque TCP retransmita el mensaje fallido a través del trayecto de respaldo, y finalmente conduce al peer BGP inactivo con vencimiento de tiempo en espera. Este problema se observa solamente cuando MPLS se configura en Catalyst6500 o Cisco7600. Esta información se incluye en el ID de bug de Cisco CSCsj89544 .

   Nota: Solo los usuarios registrados de Cisco pueden acceder a la información de errores interna y a otras herramientas.

Solución

Las soluciones a este problema se explican con estos detalles.

Agregue una ruta estática específica en Rtr-A para la dirección IP del par BGP (10.20.20.20 en este caso).

RTR-A#configure terminal        
Enter configuration commands, one per line.  End with CNTL/Z.
RTR-A(config)#ip route 10.20.20.20 255.255.255.255 192.168.16.2

La configuración de una ruta estática para el prefijo 10.20.20.20/32 garantiza que una ruta BGP aprendida dinámicamente 10.20.20.20/32 no se instale en la tabla de ruteo y, por lo tanto, evita la situación de loop de ruteo recursivo. Consulte Selección de Rutas en Routers de Cisco para obtener más información.

Nota: Cuando los peers EBGP se configuran para alcanzar a otros con rutas predeterminadas, la vecindad BGP no aparece. Esto se hace para evitar la inestabilidad de la ruta y los loops de ruteo.

Un ping a 172.16.1.1 confirma la solución.

RTR-A#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/40 ms

Dampening de ruta

El dampening de ruta es una función de BGP diseñada para minimizar la propagación de las rutas inestables a través de una conexión entre redes. Los valores recomendados por el ISP son los predeterminados en Cisco IOS^® y sólo necesita configurar este comando para habilitarlo.

router bgp <AS number>
 bgp dampening

El comando dampeningbgp establece los valores predeterminados para los parámetros de dampening como Halftime= 15 minutos, reuse = 750, Suppress = 2000 y Max Suppress Time= 60. El usuario puede configurar estos valores, pero Cisco recomienda que no se modifiquen.

Información Relacionada

• ¿Qué significa el mensaje de error "#%BGP-3-INSUFCHUNKS: agrupamientos de fragmentos insuficientes para aspath"?
• ¿Por qué los vecinos BGP alternan entre los estados inactivo, conectado y activo?
• Compatibilidad con routing IP/BGP
• Asistencia técnica y descargas de Cisco