Troubleshooting de Loops de ruteo de Cisco Express Forwarding

Introducción

Este documento ayuda a resolver problemas de loops de ruteo de Cisco Express Forwarding (CEF) y el ruteo por debajo del nivel óptimo causado por una adyacencia válida almacenada en memoria caché de Cisco Express Forwarding que apunta a la interfaz incorrecta. Estas son las razones por las que se crea una adyacencia con una interfaz incorrecta:

• Una ruta estática apunta directamente a una interfaz de acceso múltiple.

• Una adyacencia Cisco Express Forwarding válida se genera como resultado de las respuestas del Protocolo de resolución de direcciones proxy (ARP).

Prerequisites

Requirements

Utilice estos recursos para comprender mejor algunos de los conceptos que este documento utiliza:

• Descripción General de Cisco Express Forwarding

• Selección de Ruta en Routers de Cisco

Componentes Utilizados

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

Convenciones

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Diagrama de la red

El router R1 se conecta a R3 a través del Serial 8/0 y el router R2 se conecta a R4 a través del Serial 8/0. R1 y R2 están conectados a través de Ethernet 0/0, como muestra esta figura.

• R2 recibe actualizaciones del prefijo del protocolo de pasarela de frontera externa (eBGP) para 10.10.34.0/24 desde R4. R2 propaga este prefijo a R1 a través de BGP interno (iBGP).

• R2 tiene una ruta estática predeterminada (0.0.0.0/0) que apunta a la dirección IP serial 8/0 de R4 10.10.24.4.

• R2 también tiene una ruta predeterminada flotante de respaldo (IP route 0.0.0.0 0.0.0 Ethernet0/0 10) que apunta a la interfaz Ethernet 0/0 para rutear paquetes si falla la conexión serial entre R2 y R4.

• R1 tiene una ruta predeterminada que apunta al Serial 8/0 de R3 con la dirección IP 10.10.13.3.

Problema

El tráfico IP destinado a 10.10.34.0/24 recibe un loop entre R1 y R2. Observe el resultado del comando traceroute en R1.

R1#traceroute 10.10.34.4 
 
Type escape sequence to abort. 
Tracing the route to 10.10.34.4 
 
  1 192.168.12.2 20 msec 20 msec 20 msec 
  2 192.168.12.1 8 msec 12 msec 8 msec 
  3 192.168.12.2 8 msec 8 msec 12 msec 
  4 192.168.12.1 12 msec ...

Tenga en cuenta que el tráfico destinado para 10.10.34.4 salta entre Ethernet 0/0 de R1 (dirección IP 192.168.12.1) y Ethernet 0/0 de R2 (dirección IP 192.168.12.2). Idealmente, el tráfico de R1 destinado a 10.10.34.0/24 debe ir a R2 debido al prefijo aprendido iBGP 10.10.34.0/24. Luego, desde R2, el tráfico debe rutear a R4. Sin embargo, el resultado del comando traceroute confirma un loop de ruteo entre R1 y R2.

hostname R1 
! 
ip subnet-zero 
! 
ip cef 
! 
interface Ethernet0/0 
 ip address 192.168.12.1 255.255.255.0 
! 
interface Serial8/0 
 ip address 10.10.13.1 255.255.255.0 
! 
router bgp 11 
 no synchronization 
 bgp log-neighbor-changes 
 neighbor 10.10.13.3 remote-as 12
 neighbor 192.168.12.2 remote-as 11 
 no auto-summary 
!  
ip route 0.0.0.0 0.0.0.0 10.10.13.3

hostname  R2 
! 
ip cef 
! 
interface Ethernet0/0 
  ip address 192.168.12.2 255.255.255.0 
! 
interface Serial8/0 
 ip address 10.10.24.2 255.255.255.0 
! 
router bgp 11 
 no synchronization 
bgp log-neighbor-changes 
 network 192.168.12.0 
 neighbor 10.10.24.4 remote-as 10 
 neighbor 192.168.12.1 remote-as 11 
 neighbor 192.168.12.1 next-hop-self 
 no auto-summary 
! 
ip route 0.0.0.0 0.0.0.0 10.10.24.4 
ip route 0.0.0.0 0.0.0.0 Ethernet0/0 10 
!

Troubleshoot

Dado que los paquetes destinados a 10.10.34.4 tienen un loop entre R1 y R2, comience a resolver problemas. Primero verifique el IP Routing en R1. La salida del comando show ip route 10.10.34.0 confirma el salto siguiente de 192.168.12.2 para los paquetes destinados a 10.10.34.0/24. Esto coincide con el primer salto del comando traceroute, donde los paquetes se envían al salto siguiente 192.168.12.2, que confirma que los paquetes se conmutan correctamente en R1.

R1#show ip route 10.10.34.0 
Routing entry for 10.10.34.0/24
  Known via "bgp 11", distance 200, metric 0
  Tag 10, type internal
  Last update from 192.168.12.2 00:22:59 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 192.168.12.2, 00:22:59 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

El próximo paso es verificar la tabla de IP Routing de R2. Como se muestra en la salida del comando show ip route 10.10.34.0, los paquetes destinados a 10.10.34.0 deben ser enrutados al salto siguiente 10.10.24.4 en Serial 8/0. Sin embargo, el comando traceroute muestra los paquetes conmutados nuevamente a R1 a la dirección IP 192.168.12.1. Se necesita una investigación adicional sobre por qué los paquetes destinados a 10.10.34.0 se conmutan en R2 al salto siguiente 192.168.12.1 (como en la salida del comando traceroute) en lugar de a 10.10.24.4.

R2#show ip route 10.10.34.0
Routing entry for 10.10.34.0/24
  Known via "bgp 11", distance 20, metric 0
  Tag 10, type external
  Last update from 10.10.24.4 00:42:32 ago
  Routing Descriptor Blocks:
  * 10.10.24.4, from 10.10.24.4, 00:42:32 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

En este momento, es importante comprender que en una red conmutada por Cisco Express Forwarding, una decisión de reenvío de paquetes consta de:

• Una búsqueda en la tabla de ruteo de la coincidencia con el prefijo de máxima longitud.

• Una búsqueda de la base de información de reenvío (FIB).

Dado que se verifica la tabla de ruteo, observe la FIB de Cisco Express Forwarding. En los resultados del comando show ip cef 10.10.34.4 detail, observe que Cisco Express Forwarding conmuta 10.10.34.4 fuera Ethernet 0/0 en lugar del salto siguiente 10.10.24.4 fuera Serial 8/0 (como se muestra en show ip route 10.10.34 .0). Esta discrepancia crea loops en la red.

R2#show ip cef 10.10.34.4 detail
10.10.34.4/32, version 19, cached adjacency 10.10.34.4
0 packets, 0 bytes
  via 10.10.34.4, Ethernet0/0, 0 dependencies
    next hop 10.10.34.4, Ethernet0/0
    valid cached adjacency

El siguiente paso es observar la tabla de adyacencia de Cisco Express Forwarding y ver cómo Cisco Express Forwarding aprende a conmutar paquetes por Ethernet 0/0. Observe que la adyacencia se genera debido a ARP.

R2#show adjacency ethernet 0/0 detail | begin  10.10.34.4 
IP       Ethernet0/0               10.10.34.4(5)
                                   50 packets, 2100 bytes
                                   AABBCC006500AABBCC0066000800
                                   ARP        03:02:00

Este resultado del comando show ip arp es una confirmación.

R2#show ip arp 10.10.34.4
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.34.4             60   aabb.cc00.6500  ARPA   Ethernet0/0

A continuación, averigüe por qué se creó esta entrada ARP cuando hay una ruta IP en la tabla de ruteo. Vuelva a observar la tabla de ruteo.

R2#show run | include ip route 0.0.0.0
ip route 0.0.0.0 0.0.0.0 10.10.24.4
ip route 0.0.0.0 0.0.0.0 Ethernet0/0 10

Si la conexión serial falla entre R2 y R4, todo el tráfico se rutea con el uso de una ruta estática flotante fuera de Ethernet 0/0 porque R2 tiene una ruta estática flotante que apunta a la interfaz de acceso múltiple Ethernet 0/0 y no a la dirección IP Ethernet 192.168.12.1 de R1. Por lo tanto, para todos los destinos desconocidos, el Router R2 envía una solicitud ARP a través de la interfaz Ethernet0/0. En este caso, R2 ha perdido la ruta más específica a la red 10.10.34.0. Por lo tanto, cuando el paquete de datos llega para los hosts en esta red, genera una solicitud ARP a través de la interfaz Ethernet. Dado que Proxy ARP está habilitado de forma predeterminada en la interfaz Ethernet de R1 y tiene una ruta predeterminada que apunta a R3, responde con una respuesta ARP proxy con su propia dirección MAC. Por lo tanto, R2 envía todo el tráfico a R1, y R1 reenvía todo el tráfico con el uso de su ruta predeterminada (0.0.0.0/0) a AS 12, y consecuentemente a 10.10.34.4 a través de Internet.

Cuando R2 recibe la respuesta ARP proxy de R1, crea una adyacencia válida de Cisco Express Forwarding /32 que señala la interfaz Ethernet 0/0. Esta entrada de Cisco Express Forwarding no caduca hasta que el router ARP proxy R1 esté presente en el segmento Ethernet. Por lo tanto, la entrada /32 de Cisco Express Forwarding continúa siendo utilizada para Cisco Express Forwarding-switch los paquetes, incluso después de que la conexión serial entre R2 y R4 esté de respaldo y la ruta predeterminada de la tabla de ruteo señale Serial 8/0 hacia AS 10. El resultado es un loop de ruteo.

Finalmente, mire los registros y vea si el link serial (s8/0) está inestable. Esto hace que se instale una ruta estática flotante en la tabla de ruteo que luego conduce a ARP proxy y da como resultado la instalación de una entrada Cisco Express Forwarding de 10.10.34.4/32 en Cisco Express Forwarding FIB.

R2#show log | beg Ethernet0/0
[..]
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0, changed state to down
%BGP-5-ADJCHANGE: neighbor 10.10.24.4 Down Interface flap
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0, changed state to up
%BGP-5-ADJCHANGE: neighbor 10.10.24.4 Up

Los registros confirman la causa. En resumen, estos pasos muestran la secuencia de eventos:

1. Serial 8/0 en R2 deja de funcionar.

2. R2 tiene un paquete destinado a 10.10.34.4.

3. R2 sigue la ruta predeterminada de respaldo dirigida directamente a Ethernet 0/0.

4. R2 envía una solicitud ARP para 10.10.34.4.

5. R1 (Proxy) responde a la solicitud ARP con su propia dirección MAC a R2.

6. R2 ahora tiene una entrada ARP para 10.10.34.4 con la dirección MAC de R1.

7. R2 crea una adyacencia de Cisco Express Forwarding para 10.10.34.4, y una entrada 10.10.34.4/32 se instala en la tabla Cisco Express Forwarding (FIB) para este destino a través de Ethernet 0/0. Esta entrada de Cisco Express Forwarding se mantiene mientras la entrada ARP sea válida o hasta que R1 esté presente en el segmento Ethernet.

8. Aparece en R2 el Serial 8/0.

9. R2 aprende la ruta eBGP 10.10.34.0/24 del R4 con el siguiente salto 10.10.24.4 e instala la ruta en la tabla de IP Routing.

10. R1 aprende el prefijo 10.10.34.0/24 a través de iBGP desde R2 e lo instala en la tabla de IP Routing.

11. R1 tiene un paquete destinado a 10.10.34.4.

12. R1 busca en su tabla de ruteo, coincide con las rutas de prefijo iBGP a R2 y las rutas a R2.

13. R2 recibe un paquete destinado a 10.10.34.4. Dado que ya tiene una entrada de Cisco Express Forwarding para 10.10.34.4/32 que apunta a Ethernet 0/0 en su tabla FIB con la dirección MAC de R1, envía el paquete nuevamente a R1 sin mirar la tabla de ruteo. De esta forma, se crea un bucle.

Solución

Reemplace la ruta estática flotante que apunta directamente a Ethernet 0/0 por una que apunte a una dirección de salto siguiente.

R2(config)#no ip route 0.0.0.0 0.0.0.0 ethernet 0/0 10
R2(config)# ip route 0.0.0.0 0.0.0.0 192.168.12.1 10

Cuando tiene una ruta estática que apunta a la dirección IP del siguiente salto en lugar de una interfaz de acceso múltiple Ethernet 0/0, detiene el R2 de enviar solicitudes ARP para todos los destinos. Los paquetes se rutean y conmutan según el salto siguiente 192.168.12.1. Por lo tanto, se evitan las entradas y loops de ARP Cisco Express Forwarding.

Observe la entrada Cisco Express Forwarding en R2 que señala a la interfaz serial 8/0 correcta.

R2#show ip cef 10.10.34.4
10.10.34.0/24, version 32, cached adjacency to Serial8/0
0 packets, 0 bytes
  via 10.10.24.4, 0 dependencies, recursive
    next hop 10.10.24.4, Serial8/0 via 10.10.24.0/24
    valid cached adjacency

Información Relacionada

• Resolución de problemas de equilibrio de carga sobre enlaces paralelos por medio de Cisco Express Forwarding
• Cómo Verificar Cisco Express Forwarding Switching
• Resolución de problemas de inconsistencias de prefijos con Cisco Express Forwarding
• Resolución de problemas de adyacencias incompletas con Cisco Express Forwarding
• Página de soporte de Cisco Express Forwarding
• Páginas de Soporte de IP Routing Protocols
• Soporte Técnico y Documentación - Cisco Systems