Resolviendo problemas las rutas BGP del cambio (falla de ruteo recurrente)

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.

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

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

• Pérdida de conectividad hacia los destinos aprendidos con el BGP.

prerrequisitos

Requisitos

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.

Teoría Precedente

Consulte este diagrama de red cuando use este documento:

Refiera a estas configuraciones como usted 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 20.20.20.20 remote-as 2
 neighbor 20.20.20.20 ebgp-multihop 2
 neighbor 20.20.20.20 update-source Loopback0
!
ip route 20.20.20.0 255.255.255.0 192.168.16.2

hostname RTR-B

!
interface Loopback0
 ip address 20.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 20.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 la falla de ruteo recurrente:

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

  Observe la tabla de ruteo continuamente para los pares de los minutos para ver el cambio.

  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
  
       20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
  B       20.20.20.20/32 [20/0] via 20.20.20.20, 00:00:35
  S       20.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 20.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 la ruta de IP de la demostración | incluya, comando 00:00 para observar las rutas inestables cuando usted trata de las tablas de ruteo grandes.

  Después de que usted espere 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
  
       20.0.0.0/24 is subnetted, 1 subnets
  S       20.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 faltan 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 ruta BGP aprendida 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 20.20.20.20 00:00:16 ago
    Routing Descriptor Blocks:
    * 20.20.20.20, from 20.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 el Rtr-a, observe la ruta hacia el peer BGP 20.20.20.20. La ruta se mueve sistemáticamente entre los dos saltos siguientes cada minuto aproximadamente.

RTR-A#show ip route 20.20.20.20
Routing entry for 20.20.20.20/32
  Known via "bgp 1", distance 20, metric 0
  Tag 2, type external
  Last update from 20.20.20.20 00:00:35 ago
  Routing Descriptor Blocks:
  * 20.20.20.20, from 20.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 peer BGP es docta con BGP sí mismo; así crea una falla de ruteo recurrente.

Después aproximadamente de un minuto, los cambios de ruta a:

RTR-A#show ip route 20.20.20.20
Routing entry for 20.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

¿Qué ocasiona las fallas de ruteo recurrentes?

Estos pasos describen la causa de falla de ruteo recurrente:

1. Refiera a la configuración del Rtr-a. En esta configuración, una Static ruta 20.20.20.0/24 es el señalar configurado al Next-Hop directamente conectado 192.168.16.2. Con esta Static ruta, establecen a una sesión de BGP con el Rtr-b 20.20.20.20 del par.

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

3. El Rtr-a recibe las rutas BGP anunciadas por el Rtr-b e intenta instalar los 20.20.20.20/32. El es más específico de 20.20.20.0/24 que se configura ya en el Rtr-a como Static ruta. Porque se prefiere la ruta que corresponde con más larga, 20.20.20.20/32 se prefiere sobre 20.20.20.0/24. Consulte Selección de Rutas en Routers de Cisco para obtener más información. La ruta instalada 20.20.20.20/32 tiene Next-Hop de 20.20.20.20 (dirección IP del peering RTR-B) en la tabla de ruteo. Esto conduce a una falla de ruteo recursivo ya que la ruta hacia 20.20.20.20/32 tiene un salto siguiente propio.

   Para entender la razón detrás de porqué el ruteo recursivo falla en esta situación determinada, usted necesita entender cómo el algoritmo de ruteo trabaja. Para cualquier ruta conectada en forma indirecta en la tabla de ruteo cuyo IP Address de Next Hop no es una interfaz con conexión directa del router, el algoritmo mira recurrentemente en la tabla de ruteo hasta que encuentre una interfaz con conexión directa a la cual pueda remitir los paquetes.

   En esta situación determinada, el Rtr-a aprende una ruta a la red nondirectly-conectada 20.20.20.20/32 con un salto siguiente nondirectly-conectado de 20.20.20.20 (sí mismo). El algoritmo de ruteo se ejecuta en un error del loop del ruteo recursivo porque no puede encontrar cualquier interfaz con conexión directa a la cual enviar los paquetes destinara para 20.20.20.20/32.

4. El router detecta que esta ruta 20.20.20.20/32 no conectada directamente tiene un error de ruteo recursivo y retira 20.20.20.20/32 de la tabla de ruteo. Por lo tanto, todas las rutas BGP aprendidas con el IP Address de Next Hop 20.20.20.20 también se retiran de la tabla de ruteo.

5. Las repeticiones del proceso completo del paso 1. Usted puede confirmar esto si usted publica el comando debug ip routing.

   Nota: Antes de que usted funcione con cualquier comando debug, funcione con el comando debug contra un Access Control List (ACL) para una red específica para limitar la salida del debug. En este ejemplo, configure un ACL para limitar la salida de los debugs.

   RTR-A(config)#access-list 1 permit 20.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 20.20.20.20/32 via 20.20.20.20, bgp metric [20/0]
   00:29:50: RT: add 172.16.1.0/24 via 20.20.20.20, bgp metric [20/0]
   00:30:45: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:45: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:45: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:46: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:46: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:48: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:48: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:50: RT: del 20.20.20.20/32 via 20.20.20.20, bgp metric [20/0]
   00:30:50: RT: delete subnet route to 20.20.20.20/32
   00:30:50: RT: del 172.16.1.0/24 via 20.20.20.20, bgp metric [20/0]
   00:30:50: RT: delete subnet route to 172.16.1.0/24

6. Si la repetición de la ruta falla continuamente, después este mensaje de error aparece:

   %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 es debido a las retransmisiones de TCP ocurre en la red habilitada MPLS. Si un mensaje de keepalive BGP no se puede una vez para ser enviado al peer BGP porque el enlace de transporte está abajo, el peer BGP vecino no valida cualquier paquetes de keepalive más otra aunque el TCP retransmite el mensaje fallido a través del trayecto de backup, y lleva eventual al peer BGP abajo con la expiración del holdtime. Se considera este problema solamente cuando el MPLS se configura en Catalyst6500 o Cisco7600. Esto se discute en el Id. de bug Cisco CSCsj89544 (clientes registrados solamente).

Solución

Las soluciones a este problema se explican en éstos detalle.

Agregue una Static ruta específica en el Rtr-a para la dirección IP del peer BGP (20.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 20.20.20.20 255.255.255.255 192.168.16.2

La configuración de una Static ruta para el prefijo 20.20.20.20/32 se asegura de que una ruta BGP dinámico-docta 20.20.20.20/32 no consiga instalada en la tabla de ruteo y evita así la situación del loop del ruteo recursivo. Consulte Selección de Rutas en Routers de Cisco para obtener más información.

Nota: Cuando configuran a los pares EBGP para alcanzarse con las rutas predeterminado, la vecindad BGP no aparece. Esto se hace para evitar los loopes de la inestabilidad de ruta y de la encaminamiento.

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

Amortiguación de Routes

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 el ISP recomendado son los valores por defecto en el ^{® del} Cisco IOS y usted necesita solamente configurar este comando para habilitarlo.

router bgp <AS number>
 bgp dampening

Los valores predeterminados de humedecimiento de los commandsets BGP para los parámetros de humedecimiento tales como Halftime= 15 minutos, reutilización = 750, suprimen = 2000 y máximo suprima Time= 60. Estos valores son usuario configurable pero Cisco recomienda que permanece sin cambiar.

Información Relacionada

• Qué hace el "#%BGP-3-INSUFCHUNKS: ¿Agrupaciones de segmento insuficiente para medio del mensaje de error del aspath”?
• ¿Por qué los vecinos BGP alternan entre los estados inactivo, conectado y activo?
• Página de Soporte de BGP
• Soporte Técnico y Documentación - Cisco Systems