IP : Cisco Express Forwarding (CEF)

Troubleshooting de Loops de ruteo de Cisco Express Forwarding

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


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:

prerrequisitos

Requisitos

Utilice estos recursos para entender mejor algunos de los conceptos las aplicaciones de este documento:

Componentes Utilizados

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

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Diagrama de la red

El r1 del router conecta con el R3 vía el serial 8/0, y el r2 del router conecta con el R4 vía el serial 8/0. El r1 y el r2 están conectados vía el Ethernet0/0, pues esta figura muestra.

/image/gif/paws/26083/trouble_cef_01.gif

  • R2 recibe actualizaciones del prefijo del protocolo de pasarela de frontera externa (eBGP) para 10.10.34.0/24 desde R4. El r2 propaga este prefijo al r1 vía el Internal BGP (iBGP).

  • El r2 tiene una Static Default ruta (0.0.0.0/0) esas puntas a la dirección IP 10.10.24.4 del serial 8/0 R4.

  • El r2 también tiene una ruta flotante predeterminado de la salvaguardia (Ethernet0/0 de 0.0.0.0 0.0.0.0 de la ruta de IP 10) esas puntas a las interfaces Ethernet 0/0 a los paquetes de Routes si la conexión en serie entre el r2 y el R4 falla.

  • El r1 tiene una ruta predeterminado esas puntas al serial 8/0 R3 con la dirección IP 10.10.13.3.

Problema

El tráfico IP destinado para 10.10.34.0/24 consigue colocado entre el r1 y el r2. Observe el comando traceroute hecho salir en el 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 del r1 destinado para que 10.10.34.0/24 necesidades vayan al r2 debido al iBGP aprendió el prefijo 10.10.34.0/24. Entonces, del r2, el tráfico debe rutear al R4. Sin embargo, la salida del comando traceroute confirma un Routing Loop entre el r1 y el r2.

R1
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

R2
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 
!

Troubleshooting

Puesto que los paquetes destinados para 10.10.34.4 consiguen colocados entre el r1 y el r2, comience a resolver problemas. En primer lugar controle el Routing IP en el r1. La salida de comando de 10.10.34.0 de la ruta de IP de la demostración confirma el salto siguiente de 192.168.12.2 para los paquetes destinados a 10.10.34.0/24. Esto hace juego con el comando traceroute primero salta, donde los paquetes se envían al salto siguiente 192.168.12.2, que confirma que los paquetes están conmutados correctamente en el 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 esta salida de comando de 10.10.34.0 de la ruta de IP de la demostración muestra, los paquetes destinados a 10.10.34.0 se deben rutear hacia fuera al salto siguiente 10.10.24.4 en el serial 8/0. Sin embargo, el comando traceroute muestra los paquetes conmutados de nuevo al r1 a la dirección IP 192.168.12.1. La investigación adicional es necesaria en porqué los paquetes destinados a 10.10.34.0 se conmutan en el r2 al salto siguiente 192.168.12.1 (como en la salida del comando traceroute) en vez 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 entender que en una red Expedición-conmutada expresa de Cisco, una decisión de reenvío de paquetes consiste en:

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

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

Puesto que se verifica la tabla de ruteo, mire la BOLA del Cisco Express Forwarding. En los resultados del comando detail de 10.10.34.4 del cef del IP de la demostración, observe que el Cisco Express Forwarding conmuta el Ethernet0/0 de 10.10.34.4 hacia fuera en vez del serial 8/0 de 10.10.24.4 del salto siguiente hacia fuera (tal y como se muestra en de la salida de comando de 10.10.34.0 de la ruta de IP de la demostración). Esta discrepancia crea los loopes 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 mirar la tabla de adyacencia del Cisco Express Forwarding y considerar cómo el Cisco Express Forwarding aprende conmutar el Ethernet0/0 de los paquetes hacia fuera. Note que la adyacencia está construida debido al 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

Esta salida del comando show ip arp es 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

Después, descubra porqué esta entrada ARP fue creada cuando hay una ruta de IP en la tabla de ruteo. Mire la tabla de ruteo otra vez.

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 en serie falla entre el r2 y el R4, todo el tráfico se rutea con el uso de un Ethernet0/0 de las Rutas estáticas flotantes hacia fuera porque el r2 tiene las Rutas estáticas flotantes que señalan a las interfaces Ethernet multiaccesas 0/0, y no al Ethernet IP Address 192.168.12.1 del r1. Por lo tanto, para todos los destinos desconocidos, el r2 del router envía un pedido ARP a través de la interfaz del Ethernet0/0. En este caso, el r2 ha perdido la ruta más específica a la red de 10.10.34.0. Por lo tanto, cuando el paquete de datos llega para los host en esta red, genera un pedido ARP vía la interfaz de Ethernet. Puesto que el proxy ARP se habilita por abandono en la interfaz de Ethernet R1 y tiene una ruta predeterminado que señale al R3, responde detrás con una contestación del proxy ARP con su propia dirección MAC. Por lo tanto, el r2 envía todo el tráfico al r1, y el r1 adelante todo el tráfico con el uso de su ruta predeterminado (0.0.0.0/0) hacia fuera COMO a 12, y por lo tanto a 10.10.34.4 vía Internet.

Cuando el r2 recibe la contestación del proxy ARP del r1, crea una adyacencia válida del Cisco Express Forwarding de /32 que señale las interfaces Ethernet 0/0. Esta entrada del Cisco Express Forwarding no envejece hacia fuera hasta que el r1 del router del proxy ARP esté presente en el segmento Ethernet. Así, la entrada del Cisco Express Forwarding de /32 continúa siendo utilizada al Expedición-Switch expreso de Cisco los paquetes, incluso después la conexión en serie entre el r2 y el R4 es la salvaguardia y la ruta predeterminado de la tabla de ruteo señala el serial 8/0 hacia el AS10. El resultado es un loop de ruteo.

Finalmente, mire los registros y vea si el link serial (s8/0) está inestable. Esto hace las Rutas estáticas flotantes ser instalada en la tabla de ruteo que entonces lleva al proxy ARP y a los resultados en la instalación de una entrada del Cisco Express Forwarding de 10.10.34.4/32 en la BOLA del Cisco Express Forwarding.

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. El r2 tiene un paquete destinado a 10.10.34.4.

  3. El r2 sigue la ruta predeterminado de reserva señalada directamente al Ethernet0/0.

  4. El r2 envía un pedido ARP para 10.10.34.4.

  5. El r1 (proxy) contesta al pedido ARP con su propia dirección MAC al r2.

  6. El r2 ahora tiene una entrada ARP para 10.10.34.4 con la dirección MAC del r1.

  7. El r2 crea una adyacencia del Cisco Express Forwarding para 10.10.34.4, y una entrada 10.10.34.4/32 está instalada en la tabla del Cisco Express Forwarding (BOLA) para este destino vía el Ethernet0/0. Esta entrada del Cisco Express Forwarding se mantiene para mientras la entrada ARP sea válida o hasta que el 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. El r1 aprende el prefijo 10.10.34.0/24 vía el iBGP del r2 y lo instala en la tabla de IP Routing.

  11. El r1 tiene un paquete destinado para 10.10.34.4.

  12. El r1 mira en su tabla de ruteo, hace juego las rutas del prefijo del iBGP al r2, y las rutas al r2.

  13. El r2 recibe un paquete destinado para 10.10.34.4. Puesto que tiene ya una entrada del Cisco Express Forwarding para 10.10.34.4/32 que señale al Ethernet0/0 en su tabla de FIB con la dirección MAC del r1, envía el paquete de nuevo al r1 sin la mirada de la tabla de ruteo. Esto crea un loop.

Solución

Substituya las Rutas estáticas flotantes esas puntas directamente al Ethernet0/0 por uno esas puntas a una dirección del 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 usted tiene una Static ruta que señale al IP Address de Next Hop en vez de una interfaz Ethernet multiaccesa 0/0, para el r2 de enviar los pedidos ARP para todos los destinos. Los paquetes se rutean y se conmutan sobre la base del salto siguiente 192.168.12.1. Por lo tanto, se evitan cualesquiera entradas del Cisco Express Forwarding ARP y loop.

Observe la entrada del Cisco Express Forwarding en el r2 esas puntas al serial correcto 8/0 de la interfaz.

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


Document ID: 26083