Troubleshooting de Unicast IP Routing con CEF en Catalyst 6500/6000 Series Switches con Supervisor Engine 2 y ejecutando CatOS System Software.

Introducción

Este documento debe ser usado como una guía para resolver problemas del Unicast IP Routing en los Catalyst 6500/6000 Switches con Supervisor Engine 2, Policy Feature Card 2 (PFC2), Multilayer Switch Feature Card 2 (MSFC2). El ruteo de unidifusión en Supervisor Engine 2 se realiza mediante (CEF). Este documento sólo describe el IP Routing en la serie Catalyst 6500/6000 con Supervisor Engine 2, PFC2, MSFC2. Este documento no es válido para Catalyst 6500/6000 con Supervisor Engine 1 (o 1A) o para el Módulo de conmutación de capas múltiples (MSM). Este documento es válido sólo para los switches que ejecutan el software de sistema Catalyst OS (CatOS) en el Motor supervisor y no para el software de sistema Cisco IOS®.

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.

Convenciones

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

Información general sobre CEF

CEF era originalmente una técnica de conmutación del software Cisco IOS diseñada para enlutar los paquetes con mayor velocidad. CEF es mucho más escalable que fast switching. (No es necesario enviar el primer paquete para procesar la conmutación.) El Catalyst 6500 con Supervisor Engine 2 utiliza un mecanismo de reenvío CEF basado en hardware implementado en el PFC2. CEF utiliza principalmente dos tablas para almacenar la información necesaria para el ruteo: la Base de información de reenvío (FIB) y la tabla de adyacencia.

Base de información de reenvío (FIB)

CEF utiliza una FIB para tomar decisiones de conmutación basadas en prefijos para un destino IP (primero la coincidencia más larga). El FIB es conceptualmente similar a una tabla de ruteo o base de información. Mantiene una imagen réplica de la información de transmisión contenida en la tabla de IP Routing Cuando se producen cambios de ruteo o de topología en la red, se actualiza la tabla de IP Routing y dichos cambios se reflejan en la FIB. La FIB mantiene la información de la dirección del salto siguiente basada en la información de la tabla de IP Routing. Dado que existe correlación “uno a uno” entre las entradas de la FIB (base de reenvío de información) y las entradas de la tabla de ruteo, la FIB comprende todos los trayectos conocidos y elimina la necesidad de mantenimiento de la memoria caché del router que está asociada con los trayectos de switching, tales como fast switching y optimum switching. Siempre hay una coincidencia en la FIB, ya sea un valor predeterminado o comodín.

Tabla de adyacencia

Se dice que los nodos de la red son adyacentes si pueden alcanzarse entre sí con un solo salto a través de una capa de link. Además de FIB, CEF utiliza tablas de adyacencia para añadir información de direccionamiento de Capa 2 (L2). La tabla de adyacencia mantiene las direcciones del salto siguiente de L2 para todas las entradas de FIB. Esto significa que la entrada FIB completa contiene un puntero hacia una ubicación en la tabla de adyacencia que tiene la información de reescritura de L2 para que el salto siguiente llegue al destino IP final. Para que funcione el hardware CEF en el sistema Catalyst 6500/Supervisor Engine 2, la IP CEF debe ejecutarse en la MSFC2.

Cómo leer la tabla de FIB y de adyacencia en PFC2

La tabla de FIB de PFC2 debe ser exactamente igual a la de MSFC2. En la PFC2, todos los prefijos IP de la FIB se almacenan en una memoria direccionable de contenido ternario (TCAM) y se ordenan por longitud de máscara, comenzando por la máscara más larga. Esto significa que primero encuentra todas las entradas con una máscara de 32 (entrada de host); a continuación, encontrará todas las entradas con una longitud de máscara de 31, y así sucesivamente, hasta que alcance una entrada con una longitud de máscara de 0. Esta es la entrada predeterminada. La FIB se lee de manera secuencial y el primer acierto se usa como coincidencia. Considere esta tabla FIB de muestra en PFC2:

Cat6k> (enable) show mls entry cef
Mod FIB-Type  Destination-IP  Destination-Mask NextHop-IP      Weight 
--- --------- --------------- ---------------- --------------- ------ 
15 receive   0.0.0.0         255.255.255.255  

!--- This is the first entry with mask length 32.
 
15 receive   255.255.255.255 255.255.255.255 
15 receive   192.168.254.254 255.255.255.255 
15 receive   10.48.72.237    255.255.255.255 
15 receive   10.48.72.0      255.255.255.255 
15 receive   10.48.72.255    255.255.255.255 
15 receive   192.168.222.7   255.255.255.255 
15 receive   192.168.100.254 255.255.255.255 
15 receive   192.168.10.254  255.255.255.255 
15 resolved  192.168.199.3   255.255.255.255  192.168.199.3        1 
15 resolved  192.168.222.2   255.255.255.255  192.168.222.2        1 
15 resolved  192.168.199.2   255.255.255.255  192.168.199.2        1 
15 resolved  192.168.254.252 255.255.255.255  192.168.199.3        1  

!--- This is the last entry with mask length 32.

15 connected 192.168.222.0   255.255.255.252  

!--- This is the only entry with mask length 30.

15 receive   224.0.0.0       255.255.255.0 

!--- This is the first entry with mask length 24.

15 connected 10.48.72.0      255.255.255.0 
15 connected 192.168.10.0    255.255.255.0 
15 connected 192.168.11.0    255.255.255.0 
15 connected 192.168.100.0   255.255.255.0 
15 connected 192.168.101.0   255.255.255.0 
15 connected 192.168.199.0   255.255.255.0 

!--- This is the last entry with mask length 24.

15 connected 127.0.0.0       255.0.0. 0 

!--- This is the entry with mask length 8.

15 wildcard  0.0.0.0         0.0.0. 0  

!--- This is the entry with mask length 0.

Cada entrada contiene los siguientes campos:

• Mod: la MSFC2 que instala la entrada es 15 ó 16, dependiendo de cuál sea la MSFC2 designada.

• Tipo FIB: el tipo asociado a esta entrada específica. Los posibles tipos FIB son:

  • receive: El prefijo asociado a las interfaces MSFC. Esto contiene un prefijo con una máscara de 32 correspondiente a la dirección IP de las interfaces MSFC y una dirección IP de la subred de difusión.

  • resuelto: el prefijo asociado a una dirección de salto siguiente válida. Esto contiene cualquier prefijo con una adyacencia resuelta para el siguiente salto.

  • connected: el prefijo asociado a una red conectada.

  • comodín: coincide con todas las entradas (drop o MSFC redirect). Esta entrada sólo está presente si no existe una entrada predeterminada, y su longitud de máscara es 0.

  • default: la ruta predeterminada. Como entrada comodín, coincide con todas las subredes y está presente con una longitud de máscara de 0. Señala al salto siguiente. Esta entrada CEF predeterminada sólo está presente si hay una ruta predeterminada presente en la tabla de ruteo.

  • drop: se descartan todos los paquetes que coinciden con una entrada con una caída.

• Destination-IP: la dirección IP de destino o subred IP de que se trate.

• Máscara de destino: la máscara asociada a la entrada. Como puede observar en el ejemplo anterior, el FIB está ordenado desde la máscara más extensa (255.255.255.255) y hasta con la máscara más breve posible (0.0.0.0).

• IP de salto siguiente: muestra la IP de salto siguiente, si existe.

Puede ver la tabla de adyacencia completa ingresando este comando:

Cat6k> (enable) show mls entry cef adjacency
Mod:15  
Destination-IP : 192.168.98.2 Destination-Mask : 255.255.255.255  
FIB-Type :resolved  
AdjType NextHop-IP      NextHop-Mac       VLAN Encp Tx-Packets   Tx-Octets  
-------- --------------- ----------------- ---- ---- ------------ ---------- 
connect  192.168.98.2    00-90-21-41-c5-57   98 ARPA        0             0

Nota: Esta salida contiene una entrada similar a la que se encuentra en la tabla FIB de ejemplo, anterior, para cada una de las entradas CEF resueltas (o predeterminadas) en la FIB.

Método de resolución de problemas

Antes de proporcionar algunos ejemplos y detalles sobre la resolución de problemas, esta sección resume los métodos que se siguen para resolver problemas de conectividad o alcance a una dirección IP específica. Recuerde que la tabla CEF en PCF2 es una réplica de la tabla CEF en MSFC2. Es por ello que PFC2 sólo retiene información correcta para llegar a una dirección IP si la información conocida por MSFC2 también es correcta. Por lo tanto, siempre es necesario verificar la información ubicada debajo.

Desde MSFC2:

Complete estos pasos:

1. Verifique que la información contenida en el IP Routing de la tabla MSFC2 sea correcta mediante la ejecución del comando show ip route (o el comando show ip route x.x.x.x, para no evitar navegar por toda la tabla de ruteo), cuyo resultado debería contener el salto siguiente esperado.

   Si no es así, necesita verificar su protocolo de ruteo, configuración, vecino del protocolo de ruteo y cualquier otro problema que sea inherente al protocolo de ruteo que está ejecutando.

2. Verifique que el próximo salto (o el destino final de una red conectada) tenga una entrada de Protocolo de resolución de direcciones (ARP) resuelta correctamente en MSFC2 al utilizar el comando show ip arp next_hop_ip_address, luego verifique que el ARP esté resuelto y que incluya la dirección MAC adecuada.

   Si la dirección MAC es incorrecta, debe verificar si otro dispositivo tiene asignada esa dirección IP. Eventualmente, deberá rastrear el nivel de conmutación en el puerto que conecta al dispositivo que posee la dirección MAC. Si la entrada ARP está incompleta, significa que usted no obtuvo ninguna respuesta de ese host. Debe verificar que el host esté activo y en funcionamiento. Es posible utilizar un sabueso en el host para ver si recibe la respuesta ARP y si responde correctamente.

3. Verifique que la tabla CEF en el MSFC2 contenga la información correcta y que la adyacencia se resuelva realizando estos pasos:

   1. Ejecute el comando show ip cef destination_network para verificar que el próximo salto en la tabla CEF coincida con el próximo salto en la tabla de IP Routing (desde el Paso 1 anterior).

   2. Verifique que la adyacencia sea correcta ejecutando el comando show adjacency detail | comience el comando next_hop_ip_address.

      Esto debe contener la misma dirección MAC del ARP que se ve en el Paso 2, arriba.

Si los pasos 1 y 2 anteriores proporcionan resultados correctos, pero los pasos 3a o 3b fallan, se enfrenta a un problema de Cisco IOS Software CEF que probablemente no esté relacionado con Catalyst 6500/6000. Debe intentar borrar la tabla ARP y la tabla de IP Routing.

Desde la PFC2:

Complete estos pasos:

1. Verifique que la información de FIB almacenada en el PFC2 sea correcta y coincida con la información almacenada en la tabla CEF de la MSFC2 (como se vio antes en el Paso 3). Para hacer esto, ejecute el comando show mls entry cef ip destination_ip_network/destination_subnet_mask y después verifique que la dirección de IP del salto siguiente sea la que usted esperaba.

   Si la información no coincide con los resultados del Paso 3, arriba, señala un problema de comunicación entre la MSFC2 y la PFC2 (interna al Catalyst 6500/6000). Verifique que no haya un error de funcionamiento conocido para el CatOS del PFC2 o para el software Cisco IOS del MSFC2 que está ejecutando. Puede restaurar la entrada correcta al ejecutar el comando clear ip route en MSFC2.

2. Verifique la tabla de adyacencia en el PFC2 ejecutando el comando show mls entry cef ip next_hop_ip_address/32 adjacency, luego verificando que contiene la misma dirección MAC que la que se ve en los pasos 2 y 3b de la sección From the MSFC2, arriba.

   Si la adyacencia en el PFC2 no coincide con la adyacencia para el salto siguiente en el Paso 3b, probablemente esté enfrentando un problema de comunicación interna entre MSFC2 y PFC2. Puede probar limpiando la adyacencia para restablecer la información correcta.

Caso Práctico 1: Conectividad a un Host en una Red Conectada Directamente

Esta caso simple proporciona un estudio de la conectividad entre:

• host 1 en VLAN 10 con una dirección IP de 192.168.10.10

• host 2 en la VLAN 199 con una dirección IP de 192.168.199.3

Éste es un ejemplo del resultado de la configuración MSFC2:

interface VLAN 10 
description Server VLAN
ip address 192.168.10.1 255.255.255.0 
no ip redirects 
!  
interface VLAN 199 
ip address 192.168.199.1 255.255.255.0

Nota: Es importante tener en cuenta que Catalyst 6500/6000 con Supervisor Engine 2 y MSFC2 está ruteando usando CEF en hardware. No hay nada que configurar para él. CEF no se puede inhabilitar en MSFC2.

Pasos para la resolución de problemas

Siga los procedimientos resaltados en la sección Método de resolución de problemas de este documento para verificar la trayectoria para alcanzar la dirección IP 192.168.199.3.

1. Verifique la tabla de IP Routing mediante cualquiera de estos comandos:

   • Cat6k-MSFC2# show ip route 192.168.199.3
     Routing entry for 192.168.199.0/24 
     Known via "connected", distance 0, metric 0 (connected, via interface) 
     Routing Descriptor Blocks: 
     * directly connected, via VLAN 199 
     Route metric is 0, traffic share count is 1

     or

   • Cat6k-MSFC2# show ip route | include 192.168.199.0
     C 192.168.199.0/24 is directly connected, VLAN 199

   En estos dos resultados de comando, puede ver que el destino está en una subred directamente conectada. Como tal, no existe ningún salto siguiente hacia el destino.

2. Verifique la entrada ARP en MSFC2.

   En este caso, verifique que haya una entrada ARP para la dirección IP de destino a través de este comando:

   Cat6k-MSFC2# show ip arp 192.168.199.3
   Protocol Address       Age (min) Hardware        Addr Type Interface
   Internet 192.168.199.3 176       0030.7150.6800  ARPA VLAN 199

3. Verifique el CEF y la tabla de adyacencia en el MSFC2.

   1. Verifique la tabla CEF a través de este comando:

      Cat6k-MSFC2# show ip cef 192.168.199.3
      192.168.199.3/32, version 281, connected, cached adjacency 192.168.199.3
      0 packets, 0 bytes
      via 192.168.199.3, VLAN 199, 0 dependencies 
      next-hop 192.168.199.3, VLAN 199 
      valid cached adjacency

      Puede ver que existe una entrada CEF válida con una extensión de máscara de 32 y una adyacencia de caché válida.

   2. Verifique la tabla de adyacencia a través de este comando:

      Cat6k-MSFC2# show adjacency detail | begin 192.168.199.3
      IP VLAN 199192.168.199.3(7)
      0 packets, 0 bytes
      003071506800  
      
      !--- This is the destination MAC address.
      
      00D0003F8BFC0800 
      ARP00:58:35

      Como puede observar en el resultado de arriba, hay una adyacencia. La dirección MAC de destino de la adyacencia muestra la misma información que la dirección MAC en la tabla ARP del Paso 2, arriba.

      Tenga en cuenta que los contadores del Paso 3b son casi siempre 0, ya que los paquetes son conmutados de Capa 3 (L3) en hardware. Como tales, nunca alcanzan el MSFC2 y no están contadas en los contadores MSFC2 CEF. La única manera de ver las estadísticas de los paquetes reenviados a un destino dado es mirar las estadísticas de la adyacencia encontrada en el PFC2 durante el Paso 5.

4. Verifique a partir del punto de vista del Supervisor Engine que tenga la entrada CEF/FIB correcta.

   Hay dos entradas interesantes en la FIB, como sigue:

   1. Una entrada para la dirección IP de destino, como se detalla aquí:

      Cat6k> (enable) show mls entry cef ip 192.168.199.3/32
      Mod FIB-Type   Destination-IP Destination-Mask  NextHop-IP      Weight  
      --- ---------  --------------- ----------------  --------------- ------ 
      15  resolved   192.168.199.3   255.255.255.255 192.168.199.3       1  

      Esta entrada es una entrada de host con un salto siguiente ya conocido (que, en este caso, es el destino mismo).

   2. Una entrada que corresponde a la red de destino, como se muestra a continuación:

      Cat6k> (enable) show mls entry cef ip 192.168.199.0/24 
      Mod FIB-Type  Destination-IP  Destination-Mask NextHop-IP      Weight 
      --- --------- --------------- ---------------- --------------- ------  
      15  connected 192.168.199.0   255.255.255.0

      Esta entrada es una entrada FIB conectada, lo que significa que cualquier paquete que llegue a esta entrada se redirige a la MSFC2 para un procesamiento adicional (principalmente enviando ARP y esperando la resolución ARP).

   Recuerde que el FIB se explora secuencialmente. Se comienza con la mayor longitud de máscara. Como tal, si ambas entradas listadas en el Paso 4, anterior, se encuentran presentes, usted acierta la primera con la máscara 32 (entrada del host) y no sigue descendiendo por la tabla FIB. En el caso en que la entrada /32 no esté presente, usted pulsa la segunda entrada, que es la entrada para la red; como se trata de una entrada conectada, se redirige el paquete a la MSFC2 para un procesamiento adicional. Es muy posible para la MSFC2 enviar una petición ARP para la máscara de destino. Una vez recibida la respuesta ARP; la tabla ARP y la tabla de adyacencia se completan para ese host en MSFC2.

5. Una vez que dispone de la entrada FIB correcta con la longitud de máscara 32, compruebe que la adyacencia del host se ha completado correctamente mediante la ejecución de este comando:

   Cat6k> (enable) show mls entry cef ip 192.168.199.3/32 adjacency 
   Mod:15 
   Destination-IP : 192.168.199.3 Destination-Mask : 255.255.255.255  
   FIB-Type : resolved 
   AdjType  NextHop-IP      NextHop-Mac       VLAN Encp TX-Packets   TX-Octets 
   -------- --------------- ----------------- ---- ---- ------------ ------------- 
   connect  192.168.199.3   00-30-71-50-68-00 199  ARPA     0                0 

   Nota: La adyacencia se llena y el campo NextHop-Mac contiene la dirección MAC válida del host 2 (como se ve en los Pasos 2 y 3b).

   En este punto, todo el resultado es correcto, aunque el número de paquetes transmitidos para esta adyacencia sigue siendo 0. En el siguiente ejemplo, se envían diez pings de 100 bytes desde el host 1 al host 2 y se verifica la adyacencia nuevamente.

   Cat6k> (enable) show mls entry cef ip 192.168.199.3/32 adjacency  
   Mod:15 
   Destination-IP : 192.168.199.3 Destination-Mask : 255.255.255.255  
   FIB-Type : resolved 
   AdjType  NextHop-IP      NextHop-Mac       VLAN Encp TX-Packets   TX-Octets 
   -------- --------------- ----------------- ---- ---- ------------ ------------- 
   connect  192.168.199.3   00-30-71-50-68-00  199 ARPA       10         1000

   Ahora puede ver que el número de TX-Packets es 10, lo que es consistente con el tráfico enviado.

Observaciones y conclusiones

Como se mencionó en el Paso 4 de Pasos de Troubleshooting, anteriormente, tiene dos entradas FIB que pueden ser una buena coincidencia, como se explica a continuación:

• la entrada de red (en este caso, 192.168.199.0/24): esta entrada siempre está presente y proviene directamente de la tabla de ruteo y CEF en la MSFC. Esta red siempre está conectada directamente en la tabla de ruteo.

• la entrada de host de destino (en este caso, 192.168.199.3/32): esta entrada no está necesariamente presente. Si no es así, se accede a la entrada de red y se producen estos elementos:

  1. El paquete se reenvía al MSFC2.

  2. La entrada de host con longitud de máscara 32 se crea luego en la tabla FIB de la PFC. Sin embargo, como todavía no posee una adyacencia completa, la adyacencia se crea con un tipo frc drop (que significa forzar caída).

  3. El siguiente paquete para ese destino llega a la entrada de caída /32 frc y el paquete se elimina.

  4. Al mismo tiempo, el paquete original enviado a MSFC2 hace que MSFC2 envíe un pedido de ARP.

  5. Una vez que se resuelve el ARP, se completa el acceso del ARP. La adyacencia se completa en el MSFC2, y una actualización de adyacencia se envía al Supervisor Engine para completar la adyacencia de caídas de frecuencia.

  6. El Supervisor Engine cambia la adyacencia del host para reflejar la dirección MAC de reescritura y el tipo de adyacencia se cambia para conectar.

  Este mecanismo de instalación de una adyacencia frc drop mientras espera a que se resuelva el ARP se denomina acelerador ARP. El acelerador ARP es útil para evitar reenviar todos los paquetes a la MSFC2 y generar requerimientos ARP múltiples. Sólo los primeros paquetes se envían al MSFC2 y el resto se deja caer en el PFC2 hasta que se complete la adyacencia.

  Esto también le permite dar de baja el tráfico dirigido a un host inexistente o que no responde en una red conectada en forma directa.

Cuando se están tratando de resolver problemas de conexión entre dos usuarios en dos VLAN diferentes, es importante tener siempre en cuenta que debe observarse:

• el tráfico del host 1 al host 2 mediante el Método de solución de problemas, más arriba, para hacer que la dirección IP de destino sea el host 2

• tráfico del host 2 al host 1 usando el mismo método, pero esta vez con el destino como host 1

También es importante recordar que el resultado necesita tomarse de la gateway predeterminada del origen, que no es necesariamente el mismo tráfico desde el host 1 al host 2 y el tráfico desde el host 2 al host 1.

Nota: Los contadores del Paso 3b de Pasos de Troubleshooting, arriba, son casi siempre 0, ya que los paquetes se conmutan L3 en hardware. Como tales, nunca alcanzan el MSFC2 y no están contadas en los contadores MSFC2 CEF. La única manera de ver las estadísticas de los paquetes reenviados a un destino dado es mirar las estadísticas de la adyacencia encontrada en el PFC2 durante el Paso 5 de Pasos de Troubleshooting, arriba.

Caso Práctico 2: Conectividad con una red remota

Tenga en cuenta el diagrama siguiente, en el que el host 1 con una dirección IP de 192.168.10.10 realiza un ping al host 2 con una dirección IP de 192.168.150.3. Sin embargo, esta vez, el host 2 se encuentra a dos saltos enrutados en lugar de estar conectado directamente a Catalyst 6500/6000-MSFC2. Se utiliza el mismo método para seguir la ruta del CEF en el Catalyst 6500/6000-MSFC2.

Pasos para la resolución de problemas

Complete estos pasos:

1. Consulte la tabla de ruteo en la MSFC2 al ejecutar este comando:

   Cat6k-MSFC2# show ip route 192.168.150.3
   Routing entry for 192.168.150.0/24
   Known via "ospf 222", distance 110, metric 2, type intra area
   Last update from 192.168.199.3 on VLAN 199, 00:12:43 ago 
   Routing Descriptor Blocks: 
   * 192.168.199.3, from 192.168.254.252, 00:12:43 ago, via VLAN 199 
   Route metric is 2, traffic share count is 1 
   Cat6k-MSFC2#sh ip route | include 192.168.150.0 
   O 192.168.150.0/24 [110/2] via 192.168.199.3, 00:13:00, VLAN 199

   Puede ver a partir del resultado anterior que, para alcanzar el host 2 con la dirección IP 192.168.150.3, tiene una ruta OSPF (Open Shortest Path First). Para llegar, se debe utilizar la dirección de IP 192.168.199.3 en VLAN 199 como el salto siguiente.

2. Verifique la tabla ARP en el MSFC2 ejecutando el siguiente comando.

   Nota: Verifique la entrada ARP para el salto siguiente, no para el destino final.

   Cat6k-MSFC2# show ip arp 192.168.199.3
   Protocol Address        Age (min) Hardware       Addr Type  Interface
   Internet 192.168.199.3  217       0030.7150.6800 ARPA      VLAN 199

3. Verifique la tabla CEF y la tabla de adyacencia en el MSFC2 mediante la ejecución de este comando:

   Cat6k-MSFC2# show ip cef 192.168.150.0 
   192.168.150.0/24, version 298, cached adjacency 192.168.199.3 
   0 packets, 0 bytes 
   via 192.168.199.3, VLAN 199, 0 dependencies 
   next-hop 192.168.199.3, VLAN 199 
   valid cached adjacency

   Puede ver que hay una entrada CEF para la red de destino, y los resultados del siguiente salto coinciden con lo que tiene en el Paso 1 de la tabla de ruteo.

4. Verifique la tabla de adyacencia para el salto siguiente mediante este comando:

   Cat6k-MSFC2# show adjacency detail | begin 192.168.199.3
   IP VLAN 199 192.168.199.3(9) 
   0 packets, 0 bytes 
   003071506800 
   00D0003F8BFC0800 
   ARP 00:17:48

   Hay una adyacencia válida para el salto siguiente, y la dirección MAC de destino coincide con la entrada ARP que se encuentra en el Paso 2, arriba.

5. Controle la tabla FIB en el Supervisor Engine (PFC2) mediante la ejecución de este comando:

   Cat6k> (enable) show mls entry cef ip 192.168.150.0/24
   Mod FIB-Type  Destination-IP  Destination-Mask NextHop-IP      Weight
   --- --------- --------------- ---------------- --------------- ------
   15  resolved  192.168.150.0   255.255.255.0    192.168.199.3       1

   El FIB refleja la misma información que se encuentra en el Paso 3 y tiene el mismo salto siguiente.

6. Verifique la adyacencia en Supervisor Engine (PFC2) mediante la ejecución de este comando:

   Cat6k> (enable) show mls entry cef ip 192.168.150.0/24 adjacency
   Mod:15
   Destination-IP : 192.168.150.0 Destination-Mask : 255.255.255.0
   FIB-Type : resolved 
   AdjType  NextHop-IP      NextHop-Mac       VLAN Encp TX-Packets   TX-Octets 
   -------- --------------- ----------------- ---- ---- ------------ ------------ 
   connect  192.168.199.3   00-30-71-50-68-00  199 ARPA           0            0

   También puede verificar que tiene una adyacencia de conexión que refleja la misma dirección MAC que se encuentra en los pasos 2 y 4 anteriores.

Nota: Puede verificar la adyacencia para el destino final cuando verifique la adyacencia en el PFC2. No es posible hacerlo con el software del IOS de Cisco en la MSFC2, con la cual se necesita verificar la adyacencia para el siguiente salto. La tabla de adyacencia en la PFC2 para el destino final muestra el próximo salto y la adyacencia para el próximo salto (si está resulta), todo en un resultado de comando. En MSFC2, debe comprobar por separado la entrada CEF para buscar el salto siguiente y luego observar la adyacencia del salto siguiente.

Observaciones y conclusiones

En este ejemplo, puede ver que los pasos de resolución de problemas utilizados para verificar la conectividad en un Catalyst 6500/6000-MSFC2 para alcanzar una red remota son similares al ejemplo anterior encontrado en la sección Caso práctico 1: Conectividad a un Host en una Red Conectada Directamente. Sin embargo, existen algunas diferencias:

• Verifique el destino final en la tabla de IP Routing, la tabla CEF y FIB (pasos 1, 3 y 5).

• Controle la información del salto siguiente en la tabla del ARP y en la tabla de adyacencia (Pasos 2 y 4)

• En el Paso 6, puede verificar directamente la adyacencia para el destino final. Los resultados presentan tanto el próximo salto desde el FIB como la información de reescritura de adyacencia de la tabla de adyacencia.

En este caso no existe una entrada en FIB para el destino final, según se muestra a continuación. (Sólo está presente la entrada de red con una longitud de máscara de 24).

Cat6k> (enable) show mls entry cef ip 192.168.150.3/32 adjacency 
Cat6k> (enable)

Caso Práctico 3: Equilibrio de carga para varios saltos siguientes

En este caso práctico se trata lo que ocurre en caso de que varios saltos siguientes y varias rutas estén disponibles para llegar a la misma red de destino.

1. En la siguiente sección de muestra de la tabla de ruteo, observe que existen tres rutas diferentes y tres saltos siguientes diferentes que están disponibles para alcanzar la misma dirección IP de destino 192.168.254.253.

   O 192.168.254.253 [110/2] via 192.168.222.6, 00:42:45, POS8/2
   [110/2] via 192.168.222.2, 00:42:45, VLAN 222
   [110/2] via 192.168.199.2, 00:42:45, VLAN 199

2. Siga los siguientes pasos para verificar la entrada ARP para cada uno de los tres saltos próximos:

   1. Revise la tabla de CEF para el destino.

      Observe que el destino también muestra tres entradas diferentes en la tabla CEF en MSFC2. El Cisco IOS Software CEF es capaz de compartir la carga entre diferentes rutas.

      cat6k-MSFC2# show ip cef 192.168.254.253
      192.168.254.253/32, version 64, per-destination sharing
      0 packets, 0 bytes 
      via 192.168.222.6, POS8/2, 0 dependencies 
      traffic share 1 
      next-hop 192.168.222.6, POS8/2 
      valid adjacency 
      via 192.168.222.2, VLAN 222, 0 dependencies 
      traffic share 1 
      next-hop 192.168.222.2, VLAN 222 
      valid adjacency 
      via 192.168.199.2, VLAN 199, 0 dependencies 
      traffic share 1 
      next-hop 192.168.199.2, VLAN 199 
      valid adjacency 
      0 packets, 0 bytes switched through the prefix

   2. Verifique las tres adyacencias en la tabla de adyacencia MSFC2.

      Deben coincidir con la entrada ARP en el Paso 2, arriba.

3. Tenga en cuenta que hay instaladas tres entradas FIB diferentes para el mismo destino.

   El hardware CEF en el PFC2 puede cargar hasta seis trayectos diferentes para el mismo destino. Puede ver el peso empleado para cada salto siguiente en el campo de peso. La distribución de carga utilizada por el PFC2 sólo es una distribución de carga por flujo. No habilita la distribución de la carga por paquete.

   Cat6k> (enable) show mls entry cef ip 192.168.254.253/32
   Mod FIB-Type  Destination-IP  Destination-Mask  NextHop-IP      Weight
   --- --------- --------------- ----------------  --------------- ------
   15  resolved  192.168.254.253 255.255.255.255   point2point        1 
   
   192.168.222.2      1  
   
   192.168.199.2      1

4. Verifique la adyacencia para esa entrada de destino ejecutando este comando:

   cat6k> (enable) show mls entry cef ip 192.168.254.253/32 adjacency
   Mod : 15
   Destination-IP : 192.168.254.253 Destination-Mask : 255.255.255.255 
   FIB-Type : resolved 
   AdjType  NextHop-IP      NextHop-Mac       VLAN Encp TX-Packets TX-Octets 
   -------- --------------- ----------------- ---- ---- ------------ ------------ 
   connect  point2point     00-00-08-00-04-00 1025 ARPA  0 0  
   connect  192.168.222.2 00-90-21-41-c4-07  222 ARPA 0       0 
   connect  192.168.199.2   00-90-21-41-c4-17  199 ARPA            0       0

Caso Práctico 4: Ruteo Predeterminado

Sea cual sea el aspecto de la tabla de ruteo, siempre hay una entrada FIB en el Supervisor Engine 2 para reenviar paquetes que no coinciden con ninguna otra entrada anterior. Puede ver esta entrada ejecutando este comando:

Cat6k> (enable) show mls entry cef ip 0.0.0.0/0
Mod FIB-Type  Destination-IP  Destination-Mask NextHop-IP Weight 
--- --------- --------------- ---------------- --------------- ------ 
15  default   0.0.0.0         0.0.0.0          192.168.98.2        1

Como puede ver, esta es la única entrada con una longitud de máscara de 0. Este valor predeterminado puede ser de dos tipos, como se explica a continuación en las secciones La ruta predeterminada existe en la tabla de ruteo MSFC2 y Ninguna ruta predeterminada en la tabla de ruteo.

La ruta predeterminada existe en la tabla de ruteo de MSFC2

Primero, determine cómo verificar si una ruta predeterminada está presente en la tabla de ruteo MSFC2. Puede buscar una ruta con un destino 0.0.0.0 o examinar la tabla de ruteo. La ruta predeterminada se marca con un asterisco (*). (Aquí, también aparece en negrita.)

Cat6k-MSFC2# show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet 
Known via "rip", distance 120, metric 1, candidate default path 
Redistributing via rip 
Last update from 192.168.98.2 on VLAN 98, 00:00:14 ago 
Routing Descriptor Blocks: 
* 192.168.98.2, from 192.168.98.2, 00:00:14 ago, via VLAN 98 
Route metric is 1, traffic share count is 1 
Cat6k-MSFC2#sh ip ro | include 0.0.0.0  
R* 0.0.0.0/0 [120/1] via 192.168.98.2, 00:00:22, VLAN 98

En este caso, la ruta predeterminada está presente en la tabla de ruteo MSFC2 y se aprende a través del Protocolo de información de ruteo (RIP). Sin embargo, recuerde que el comportamiento de CEF no varía sin importar como se conozca esta ruta predeterminada (static, OSPF, RIP y así sucesivamente).

En este caso, en que hay una ruta predeterminada, siempre posee una entrada CEF con una longitud de máscara igual a 0 y tipo de valor predeterminado FIB que se utiliza para reenviar todo el tráfico que no coincida con otro prefijo.

Cat6k> (enable) show mls entry cef ip 0.0.0.0/0 
Mod FIB-Type  Destination-IP  Destination-Mask NextHop-IP      Weight 
--- --------- --------------- ---------------- --------------- ------ 
15  default 0.0.0.0         0.0.0.0          192.168.98.2         1 
Cat6k< (enable) show mls entry cef ip 0.0.0.0/0 adjacency 
Mod : 15 
Destination-IP : 0.0.0.0 Destination-Mask : 0.0.0.0 
FIB-Type : default 
AdjType  NextHop-IP      NextHop-Mac       VLAN Encp TX-Packets   TX-Octets 
-------- --------------- ----------------- ---- ---- ------------ ------------- 
connect  192.168.98.2     00-90-21-41-c5-57  98 ARPA    10433743     3052325803

Como la FIB se explora secuencialmente para cada paquete, comenzando primero con la coincidencia más larga, esta FIB predeterminada sólo se utiliza para los paquetes para los cuales no se encontró ninguna otra coincidencia.

No hay ruta predeterminada en la tabla de ruteo

Cat6k-MSFC2# show ip route 0.0.0.0
% Network not in table

Si no hay rutas predeterminadas en la tabla de ruteo, todavía hay una entrada FIB con longitud de máscara 0 en Supervisor Engine 2. Sin embargo, esta entrada ahora tiene un tipo FIB de comodín. Este comodín FIB descarta todos los paquetes que lo golpean y coincide con cualquier paquete que no coincida con ninguna otra entrada en la FIB. Es útil descartar estos paquetes, ya que no tiene rutas predeterminadas. No hay necesidad de reenviar estos paquetes a la MSFC2, de todas formas los dejará de transmitir. Al utilizar este comodín FIB, está asegurando la caída de estos paquetes inútiles en el hardware.

Cat6k> (enable) show mls entry cef ip 0.0.0.0/0 
Mod FIB-Type  Destination-IP  Destination-Mask NextHop-IP      Weight 
--- --------- --------------- ---------------- --------------- ------ 
15  wildcard  0.0.0.0         0.0.0.0

Nota: En el caso poco común en que la tabla FIB está llena, la entrada comodín sigue presente pero, en lugar de descartar paquetes que coincidan con ella, se reenvían a la MSFC2. Esto únicamente ocurre si tiene más de un prefijo de 256K en el FIB y si puede almacenar la tabla de ruteo completa y la adyacencia ARP en el FIB. A continuación, debe enviar el mecanismo predeterminado a MSFC2, ya que MSFC2 puede tener una entrada de ruteo que no está presente en la FIB.

Otros consejos sobre la resolución de problemas y dificultades conocidas.

Ejecutar el comando show mls cef mac

Cuando el Supervisor Engine 2 recibe un paquete, sólo lo considera un paquete L3 potencial si la dirección MAC de destino de éste es la misma que una de las direcciones MSFC2 MAC. Puede verificar que estas direcciones se encuentran desde el punto de vista de Supervisor Engine 2 mediante la ejecución de este comando:

Cat6k> (enable) show mls cef mac
Module 15 : Physical MAC-Address  00-d0-00-3f-8b-fc
VLAN Virtual MAC-Address(es) 
---- ----------------------- 
10   00-00-0c-07-ac-0a 
100  00-00-0c-07-ac-64 
Module 15 is the designated MSFC for installing CEF entries

Puede ver la dirección MAC física de la MSFC2. (Recuerde que todas las interfaces en el MSFC2 utilizan la misma dirección MAC; no puede configurar diferentes direcciones MAC en dos interfaces diferentes.) Esta dirección MAC debe ser la misma que la de la MSFC2.

Cat6k-MSFC2# show interface 
VLAN1 is up, line protocol is up  
Hardware is Cat6k RP Virtual Ethernet, address is 00d0.003f.8bfc (bia 00d0.003f.8bfc) 
?..

El comando show mls cef mac también muestra todas las direcciones MAC vinculadas a los grupos de protocolo de router en espera activa (HSRP), donde la MSFC está activa. El resultado del comando show mls cef mac, anterior, significa que la MSFC está HSRP-activa para VLAN 10 y para VLAN 100. Se puede verificar que esto sea correcto mediante la ejecución de este comando en la MSFC2:

Cat6k-MSFC2# show standby brief 
P indicates configured to preempt. 
| 
Interface   Grp Prio P State    Active addr     Standby addr    Group addr 
Vl10        10  200  P Active   local           192.168.10.2    192.168.10.254 
Vl11        11  100  P Standby  192.168.11.1    local           192.168.11.254 
Vl98        98  200    Standby  192.168.98.2    local           192.168.98.5 
Vl99        99  200    Standby  192.168.99.2    local           192.168.99.5 
Vl100       100 200  P Active   local           192.168.100.2   192.168.100.254 
Vl101       101 100  P Standby  192.168.101.2   local           192.168.101.254

Como puede ver, el estado es Activo sólo para VLAN 10 y VLAN 100. El estado es En espera para todos los demás grupos HSRP configurados. Si, por la razón que sea, un estado de Active comienza para otra VLAN, el resultado del comando show mls cef mac debería reflejar que esta VLAN adicional no está activa.

Si hay inconsistencias entre la salida del comando show mls cef mac y lo que debería ser, puede ejecutar este comando, que proporciona más información sobre las direcciones MAC agregadas y removidas en la lista de comandos show mls cef mac:

Cat6k-MSFC2#Cat6k> (enable) show mls rlog l2 
SWLOG at 82a7f410: magic 1008, size 51200, cur 82a81ca4, end 82a8bc20 
Current time is: 12/28/01,17:09:15 
1781 12/28/01,11:40:05:(RouterConfig)Router_cfg: router_add_mac_to_earl 00-d0-00-3f-8b-
 fcadded for mod 15/1 VLAN 99 Earl AL =0 
1780 12/28/01,11:40:05:(RouterConfig)Router_Cfg: process add(3) router intf for mNo 15/1 
 VLAN 99 
1779 12/28/01,11:40:05:(RouterConfig)Router_cfg: router_add_mac_to_earl 00-d0-00-3f-8b-
 fcadded for mod 15/1 VLAN 99 Earl AL =0 
1778 12/28/01,11:40:05:(RouterConfig)Router_Cfg: process add(3) router intf for mNo 15/1 
 VLAN 99 
1777 12/28/01,11:40:05:(RouterConfig)Router_cfg: router_add_mac_to_earl 00-d0-00-3f-8b-
 fcadded for mod 15/1 VLAN 99 Earl AL =0 
1776 12/28/01,11:40:05:(RouterConfig)Router_Cfg: Process add mls entry for mod 15/1 
 VLAN 99 i/f 1, proto 3, LC 0 
1775 12/28/01,11:40:05:(RouterConfig)Router_cfg: router_add_mac_to_earl 00-d0-00-3f-8b-
 fcadded for mod 15/1 VLAN 99 Earl AL =0 
1774 12/28/01,11:40:05:(RouterConfig)Router_Cfg: Process add mls entry for mod 15/1 
 VLAN 99 i/f 1, proto 2, LC 0

Este comando proporciona un mensaje cada vez que agrega o quita una dirección MAC en la tabla de comandos show mls cef mac.

TCAM de reserva

Este documento ha discutido cómo verificar la tabla de comandos show mls entry cef en Supervisor Engine 2. Este comando no representa con precisión la programación real del circuito integrado específico de la aplicación (ASIC) del PFC2. Solo representa una copia central de esta configuración ASIC. Ha habido algunos problemas conocidos en los que las configuraciones de hardware reales no coincidían con lo que aparecía en la TCAM de reserva, la que hizo que algunos paquetes fueran reenviados al salto siguiente incorrecto. Estos problemas se documentan en el Id. de error de Cisco CSCdv49956 (sólo clientes registrados) y CSCdu85211 (sólo clientes registrados) , ambos fijos en las versiones de software CatOS 6.3(3), 7.1(1) y posteriores.

Ruteo Predeterminado Dañado

Se encontró un error en versiones anteriores del código en las que el reenvío a la ruta predeterminada no funcionó con Protocolo de ruteo de puerta de enlace interior mejorado (EIGRP) ni con OSPF. Esto se documenta en el Id. de bug Cisco CSCdt54036 (sólo clientes registrados) y se corrige en la versión 6.1(3) y posterior del software CatOS para la imagen Supervisor Engine, y en la Versión 12.1(6)E1 del software Cisco IOS para la imagen MSFC2.

Información Relacionada

• Configuración y resolución de problemas de IP MLS en switches Catalyst 6000 con una MSFC
• Páginas de Soporte de Productos de LAN
• Página de Soporte de LAN Switching
• Herramientas y utilidades
• Soporte Técnico - Cisco Systems