IP : Cisco Express Forwarding (CEF)

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

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (19 Septiembre 2015) | Comentarios


Contenido


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 solamente para el Switches que funciona con el software del sistema del Catalyst OS (CatOS) en el Supervisor Engine, y no para el software del sistema de Cisco IOS�.

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.

Convenciones

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

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 hay necesidad de enviar el primer paquete al process switching.) El Catalyst 6500 con el Supervisor Engine 2 utiliza un mecanismo de reenvío basado en hardware CEF implementado en el PFC2. El CEF utiliza principalmente dos tablas para salvar la información necesaria para rutear: 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 BOLA mantiene la información de dirección del salto siguiente basada en la información en 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 el PFC2, todos los prefijos IP en la BOLA se salvan en un Ternary Content Addressable Memory (TCAM) y son clasificados por la longitud de la máscara, empezando por la máscara más larga. Esto significa que usted primero encuentra todas las entradas con una máscara de 32 (entrada de host); después, usted encuentra todas las entradas con una longitud de la máscara de 31, y así sucesivamente, hasta que usted alcance una entrada con una longitud de la máscara de 0. Ésta es la entrada predeterminada. La FIB se lee de manera secuencial y el primer acierto se usa como coincidencia. Considere esta tabla de FIB de la muestra en el 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 — El MSFC2 que instala la entrada es 15 o 16, dependiente en cuál es el MSFC2 señalado.

  • Bola-tipo — El tipo asociado a esta entrada específica. Los Bola-tipos posibles son:

    • reciba — 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 del salto siguiente válida. Esto contiene cualquier prefijo con una adyacencia resuelta para el siguiente salto.

    • conectado — El prefijo asociado a una red conectada.

    • comodín — Esto hace juego todas las entradas (el descenso o el MSFC reorienta). Esta entrada sólo está presente si no existe una entrada predeterminada, y su longitud de máscara es 0.

    • valor por defecto — La ruta predeterminado. Como la entrada comodín, hace juego todas las subredes y está presente con una longitud de la máscara de 0. Señala al salto siguiente. Esta entrada CEF predeterminada está solamente presente si hay una ruta predeterminado presente en la tabla de ruteo.

    • descenso — Todos los paquetes que corresponden con una entrada con un descenso se caen.

  • Destino ip — El IP Address de destino o subred IP referida.

  • Destino-máscara — 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 del Next-Hop — Visualiza el IP del salto siguiente, si existe.

Usted 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 ésa encontrada en la tabla de FIB de la muestra, arriba, para cada uno (o el valor por defecto) de las entradas CEF resueltas en la BOLA.

Método de resolución de problemas

Antes de proporcionar a algunos ejemplos y detalles en el troubleshooting, esta sección resume los métodos que se siguen para resolver problemas la Conectividad o el accesibilidad 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.

Del 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 es resuelta 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 esté correcta publicando el detalle de la adyacencia de la demostración | comando begin next_hop_ip_address.

      Esto debe contener la misma dirección MAC del ARP visto en el paso 2, arriba.

Si los pasos 1 y 2, arriba, proporcionan los resultados correctos, pero los pasos 3a o 3b están fallando, usted está haciendo frente a un problema del Cisco IOS Software CEF que sea no relacionado probable al Catalyst 6500/6000. Usted 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 hace juego los resultados en el paso 3, arriba, señala a un problema de comunicación entre el MSFC2 y el PFC2 (internos 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 publicando el comando show mls entry cef ip next_hop_ip_address/32 adjacency, después verificandolo que contiene la misma dirección MAC que la que está vista en los pasos 2 y 3b de la sección MSFC2, arriba.

    Si la adyacencia en el PFC2 no hace juego la adyacencia para el salto siguiente en el paso 3b, usted está haciendo frente probablemente a una aplicación la comunicación interna entre el MSFC2 y el PFC2. Puede probar limpiando la adyacencia para restablecer la información correcta.

Caso Práctico 1: Conectividad a un host en directamente una red conectada

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 observar que el Catalyst 6500/6000 con el Supervisor Engine 2 y el MSFC2 está ruteando usando el CEF en hardware. No hay nada que configurar para él. El CEF no se puede inhabilitar en el MSFC2.

Pasos para la resolución de problemas

Siga los procedimientos resaltados en la sección del método de Troubleshooting de este documento para verificar la trayectoria para alcanzar a 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

      o

    • 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 del destino de la adyacencia está mostrando la misma información que la dirección MAC en la tabla ARP del paso 2, arriba.

      Observe que los contadores en el paso 3b son casi siempre 0, pues los paquetes son la capa 3 (L3) conmutada en hardware. Como tales, nunca alcanzan el MSFC2 y no están contadas en los contadores MSFC2 CEF. La única forma de considerar las estadísticas sobre los paquetes remitidos a un destino determinado 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 BOLA, 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 sabido (que, en este caso, sea el destino sí 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 conectada de la BOLA, así que significa que cualquier paquete que golpea esta entrada está reorientado al MSFC2 para el procesamiento adicional (que envía principalmente el ARP y que espera 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 donde no está presente la entrada de /32, usted golpea la segunda entrada, que es la entrada para la red; pues es una entrada conectada, usted reorienta el paquete al MSFC2 para el 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: Se puebla la adyacencia y el campo del NextHop-mac contiene la dirección MAC válida del host 2 (como se ve en los pasos 2 y 3b).

    En este momento, toda la salida está correcta, aunque el número de paquetes transmitidos para esta adyacencia siga 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

    Usted puede ahora ver que el número de TX-paquetes es 10, que es constante con el tráfico que fue enviado.

Observaciones y conclusiones

Como se menciona en el paso 4 de los pasos de Troubleshooting, arriba, usted tiene dos entradas de la BOLA que puedan ser una buena coincidencia, según lo explicado abajo:

  • la entrada de red (en este caso, 192.168.199.0/24) — esta entrada está siempre presente y está viniendo directamente de la encaminamiento y de la tabla CEF en el MSFC. Usted hace siempre esta red conectar directamente en la tabla de ruteo.

  • la entrada de la computadora principal de destino (en este caso, 192.168.199.3/32) — esta entrada no está necesariamente presente. Si no es, usted golpea la entrada de red, y estos elementos ocurren:

    1. El paquete se remite al MSFC2.

    2. La entrada de host con la longitud 32 de la máscara entonces se crea en la tabla de FIB del 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 la reescritura, y cambian al tipo de adyacencia para conectar.

    Este mecanismo de instalar una Adyacencia forzar caída mientras que usted espera el ARP que se resolverá se llama válvula reguladora 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:

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 en el paso 3b de los pasos de Troubleshooting, arriba, son casi siempre 0 pues los paquetes son L3 conmutado en hardware. Como tales, nunca alcanzan el MSFC2 y no están contadas en los contadores MSFC2 CEF. La única forma de considerar las estadísticas sobre los paquetes remitidos a un destino determinado es mirar las estadísticas de la adyacencia encontrada en el PFC2 durante el paso 5 de los 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, este vez, el host 2 está situado dos saltos ruteados lejos en vez directamente de la conexión con el Catalyst 6500/6000-MSFC2. Se utiliza el mismo método para seguir la ruta del CEF en el Catalyst 6500/6000-MSFC2.

128-a.gif

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

    Usted puede ver de la salida sobre eso, alcanzar el host 2 con la dirección IP 192.168.150.3, usted tiene una ruta del Open Shortest Path First (OSPF). Para llegar, se debe utilizar la dirección de IP 192.168.199.3 en VLAN 199 como el salto siguiente.

  2. Marque la tabla ARP en el MSFC2 publicando el comando abajo.

    Nota: Verifique la entrada ARP para el próximo salto y 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

    Usted puede ver que hay una entrada CEF para la red de destino, y la coincidencia de los resultados del salto siguiente qué usted 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 del destino hace juego la entrada ARP encontrada 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

    La BOLA refleja la misma información encontrada en el paso 3, y usted tiene el mismo salto siguiente.

  6. Marque la adyacencia en el Supervisor Engine (PFC2) publicando 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

    Usted puede también verificar que usted tenga una adyacencia de la conexión que refleje la misma dirección MAC como se encuentra en los pasos 2 y 4, arriba.

Nota: Usted puede marcar la adyacencia para el destino final al marcar 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

Usted puede ver en este ejemplo que los pasos de Troubleshooting usados para verificar la Conectividad en un Catalyst 6500/6000-MSFC2 para alcanzar una red remota son similares al ejemplo anterior encontrado en el caso práctico 1 de la sección: Conectividad a un host en directamente una red conectada. Sin embargo, existen algunas diferencias:

  • Usted marca el destino final en la tabla de IP Routing, la tabla CEF, y la BOLA (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, usted puede marcar 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.

      Note que el destino también está mostrando tres diversas entradas en la tabla CEF en el MSFC2. El Cisco IOS Software CEF puede hacer la carga a compartir entre diversas 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. Marque las tres adyacencias en la tabla de adyacencia MSFC2.

      Deben hacer juego 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 la parte hasta seis diversas trayectorias 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. Marque la adyacencia para esa entrada de destino publicando 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 la tabla de ruteo parece, hay siempre una entrada de la BOLA en el Supervisor Engine 2 para remitir los paquetes que no hacen juego ninguna otra entrada anterior. Usted puede ver esta entrada publicando 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 usted puede ver, ésta es la única entrada con una longitud de la máscara de 0. Este valor por defecto puede ser de dos tipos, como explicado abajo en la ruta predeterminado de las secciones existe en la tabla de ruteo MSFC2 y ninguna ruta predeterminado en la tabla de ruteo.

La ruta predeterminada existe en la tabla de ruteo de MSFC2

Primero, determine cómo verificar si una ruta predeterminado 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í, aparece en la negrilla también.)

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

Mientras que la BOLA se hojea secuencialmente para cada paquete, empezando por la coincidencia más larga primero, esta BOLA predeterminada se utiliza solamente 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 ninguna rutas predeterminado en la tabla de ruteo, todavía hay una entrada de la BOLA con la longitud 0 de la máscara en el Supervisor Engine 2. Sin embargo, esta entrada ahora tiene un Bola-tipo de comodín. Esta BOLA del comodín cae todos los paquetes que la golpean y hace juego cualquier paquete que no haga juego ninguna otra entrada en la BOLA. 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. Usando esta BOLA del comodín, usted está asegurando el descenso de estos paquetes inservibles en 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 probable en el cual la tabla de FIB es llena, la entrada comodín está todavía presente pero, en vez de los paquetes de caída que la hacen juego, se remiten al 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. Usted entonces necesita tener el mecanismo predeterminado enviado al MSFC2 puesto que el MSFC2 puede tener una entrada de ruteo que no esté presente en la BOLA.

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. Usted puede verificar que estos direccionamientos sean desde el punto de vista del Supervisor Engine 2 publicando 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

Usted puede ver la dirección MAC física del MSFC2. (Recuerde que todas las interfaces en el MSFC2 utilizan la misma dirección MAC; usted no puede configurar diversas direcciones MAC en dos diversas interfaces.) Esta dirección MAC necesita ser lo mismo que la que está en el 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 visualiza todas las direcciones MAC conectadas a los grupos del Hot Standby Router Protocol (HSRP), donde está activo el MSFC. La salida del comando show mls cef mac, arriba, significa que el MSFC es HSRP-activo para el VLAN10 y para el 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 usted puede ver, el estado es activo para solamente el VLAN10 y el VLAN 100. El estado es espera para el resto de los grupos del HSRP configurados. Si, por la razón que sea, un estado del Active comienza para otro VLA N, la salida del comando show mls cef mac debe reflejar que este VLA N adicional no es activo.

Si hay inconsistencias entre el comando show mls cef mac hecho salir y qué debe ser, usted puede publicar este comando, que proporciona más información sobre las direcciones MAC agregadas y quitadas en la lista de comando 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 usted agrega o quita una dirección MAC en la tabla del comando show mls cef mac.

TCAM de reserva

Este documento ha discutido cómo marcar la tabla del comando show mls entry cef en el Supervisor Engine 2. Este comando no representa exactamente la programación real del circuito específico de la aplicación (ASIC) del PFC2. Representa solamente una copia de la sombra de esta determinación de 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 bug Cisco CSCdv49956leavingcisco.com (clientes registrados solamente) y CSCdu85211leavingcisco.com (clientes registrados solamente), que ambos se reparan en las versiones del software CatOS 6.3(3), 7.1(1), y posterior.

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 CSCdt54036leavingcisco.com (clientes registrados solamente), y se repara en la versión 6.1(3) y posterior del software CatOS para la imagen del Supervisor Engine, y en el Cisco IOS Software Release 12.1(6)E1 para la imagen MSFC2.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 20626