IP : Technologie Cisco Express Forwarding (CEF)

Dépannage de routage IP monodiffusion impliquant CEF sur commutateur Catalyst 6500/6000 sous CatOS avec un Supervisor Engine 2

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (19 septembre 2015) | Commentaires


Contenu


Introduction

Ce document devrait être utilisé comme guide pour dépanner le Routage IP d'unicast sur des Commutateurs du Catalyst 6500/6000 avec le Supervisor Engine 2, la carte de fonctionnalité de stratégie 2 (PFC2), la carte de commutation multicouche 2 (MSFC2). Le routage d'Unicast sur le Supervisor Engine 2 est fait utilisant le Technologie Cisco Express Forwarding (CEF). Ce document concerne seulement le Routage IP sur la gamme Catalyst 6500/6000 équipée du Supervisor Engine 2, PFC2, MSFC2. Ce document est non valide pour un Catalyst 6500/6000 avec l'engine de superviseur 1 (ou 1A) ou pour le module de commutateur multicouche (MSM). Ce document est valide seulement pour des Commutateurs exécutant le logiciel système de SYSTÈME D'EXPLOITATION de Catalyst (CatOS) sur l'engine de superviseur, et pas pour le logiciel système de Cisco IOSÝ.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Aperçu de CEF

Le CEF était initialement une technique de commutation de logiciel de Cisco IOS conçue pour conduire des paquets plus rapides. Le CEF est beaucoup plus extensible que la commutation rapide. (Il n'y a aucun besoin d'envoyer le premier paquet pour traiter la commutation.) Le Catalyst 6500 avec le Supervisor Engine 2 utilise un mécanisme de transfert réalisé par matériel de CEF mis en application sur le PFC2. Le CEF emploie principalement deux tables pour stocker les informations requises pour l'acheminement : le Forwarding Information Base (FIB) et la table de juxtaposition.

Base d'informations de transfert (Forwarding Information Base [FIB]).

Le CEF emploie un FIB pour prendre à destination IP des décisions de commutation basées sur préfixe (correspondance plus longue d'abord). Le FIB est conceptuellement semblable à une table ou à une base d'informations de routage. Il met à jour une image retournée des informations d'expédition contenues dans la table de Routage IP. Lorsque des modifications de routage ou de topologie se produisent dans le réseau, la table de routage IP est mise à jour, et ces modifications sont reflétées dans la table FIB. Le FIB met à jour l'information en fonction d'adresse du prochain saut sur les informations dans la table de Routage IP. En raison d'une corrélation linéaire entre les entrées de FIB et les entrées de table de routage, le FIB contient toutes les artères connues et élimine le besoin d'entretien de la cache de route qui est associé avec des chemins de commutation, tels que la commutation rapide et la commutation d'optimum. Il y a toujours une correspondance dans le FIB, si ce soit par défaut ou masque.

Table de contiguïté

Les Noeuds dans le réseau sont dits adjacents s'ils peuvent s'atteindre avec un saut simple à travers une couche de liaison. En plus du FIB, tables de juxtaposition d'utilisations de CEF pour ajouter les informations d'adressage au début de la couche 2 (L2). La table de juxtaposition met à jour les adresses du prochain saut L2 pour toutes les entrées de FIB. Ceci signifie qu'une entrée complète de FIB contient un pointeur à un emplacement dans la table de juxtaposition qui tient les informations de la réécriture L2 pour que le prochain saut atteigne la destination IP finale. Pour que le CEF de matériel travaille sur le système d'Engine 2 du Catalyst 6500/Supervisor, l'IP CEF doit fonctionner sur le MSFC2.

Comment lire le FIB et la table de juxtaposition sur le PFC2

La table FIB du PFC2 devrait être exactement identique que la table FIB sur le MSFC2. Sur le PFC2, tous les préfixes IP dans le FIB sont enregistrés dans une mémoire associative ternaire (TCAM) et sont triés par la longueur de masque, commençant par le plus long masque. Ceci signifie que vous trouvez d'abord toutes les entrées avec un masque de 32 (entrée de hôte) ; ensuite, vous trouvez toutes les entrées avec une longueur de masque de 31, et ainsi de suite, jusqu'à ce que vous atteigniez une entrée avec une longueur de masque de 0. C'est l'entrée par défaut. Le FIB est lu séquentiellement, et le premier hit est utilisé comme correspondance. Considérez cette table FIB témoin sur le 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.

Chaque entrée comprend les champs suivants :

  • Modèle — Le MSFC2 qui installe l'entrée est 15 ou 16, dépendant de ce qui est le MSFC2 indiqué.

  • FIB-type — Le type associé avec cette entrée spécifique. Les FIB-types possibles sont :

    • recevez — Le préfixe associé avec des interfaces MSFC. Ceci contient un préfixe avec un masque de 32 correspondant à l'adresse IP des interfaces MSFC et à une adresse IP du sous-réseau d'émission.

    • résolu — Le préfixe associé avec une adresse du prochain saut valide. Ceci contient n'importe quel préfixe avec une contiguïté résolue pour le prochain saut.

    • connecté — Le préfixe associé avec un réseau connecté.

    • masque — Ceci apparie toutes les entrées (la baisse ou les MSFC réorientent). Cette entrée est seulement présente s'il n'y a aucune entrée par défaut, et est présente avec une longueur de masque de 0.

    • par défaut — Le default route. Comme entrée générique, il apparie tous les sous-réseaux et est présent avec une longueur de masque de 0. Il indique le prochain saut. Cette entrée CEF par défaut est seulement présente s'il y a un default route actuel dans la table de routage.

    • baisse — Tous les paquets appariant une entrée avec une baisse sont lâchés.

  • DESTINATION-IP — L'adresse IP ou IP de sous-réseau de destination concerné.

  • Destination-masque — Le masque associé avec l'entrée. Comme vous pouvez voir dans l'exemple ci-dessus, le FIB est commencer rangé par le plus long masque (255.255.255.255), et finir avec le masque le plus court possible (0.0.0.0).

  • IP de Prochain-saut — Affiche le prochain IP de saut, s'il existe.

Vous pouvez visualiser la table de juxtaposition complète en écrivant cette commande :

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

Remarque: Cette sortie contient une entrée semblable à cela trouvée dans la table FIB témoin, en haut, pour chacune (ou par défaut) des entrées CEF résolues dans le FIB.

Dépannage de la méthode

Avant de fournir quelques exemples et détails sur le dépannage, cette section récapitule les méthodes qui sont suivies pour dépanner la Connectivité ou l'accessibilité à une adresse IP spécifique. Maintenez dans l'esprit que la table CEF sur le PFC2 reflète la table CEF sur le MSFC2. Par conséquent, le PFC2 tient seulement les informations correctes pour atteindre une adresse IP si les informations connues par le MSFC2 sont également correctes. En soi, vous devez toujours vérifier les informations ci-dessous.

Du MSFC2 :

Procédez comme suit :

  1. Vérifiez que les informations tenues dans le Routage IP sur la table MSFC2 sont correctes en émettant la commande de show ip route (ou la commande de show ip route x.x.x.x, d'éviter de parcourir la table de routage complète), puis en vérifiant que la sortie contient le prochain saut prévu.

    Sinon, vous devez vérifier votre protocole de routage, configuration, voisin de protocole de routage, et n'importe quel autre dépannage qui est approprié au protocole de routage que vous vous exécutez.

  2. Vérifiez que le prochain saut (ou la destination définitive pour un réseau connecté) a une entrée résolue correcte de Protocole ARP (Address Resolution Protocol) sur le MSFC2 en émettant la commande de next_hop_ip_address de show ip arp, puis en vérifiant que l'ARP est résolu et contient l'adresse MAC correcte.

    Si l'adresse MAC est incorrecte, vous devez vérifier si un autre périphérique possède cette adresse IP. Par la suite, vous devez dépister le niveau de commutateur sur le port qui connecte le périphérique qui possède cette adresse MAC. Si l'entrée d'ARP est inachevée, il signifie que vous n'avez obtenu aucune réponse de cet hôte. Vous devez vérifier que l'hôte est en service. Un renifleur peut être utilisé sur l'hôte pour voir s'il obtient la réponse d'ARP et s'il répond correctement.

  3. Vérifiez que la table CEF sur le MSFC2 contient les informations correctes et que la contiguïté est résolue en exécutant ces étapes :

    1. Émettez la commande de destination_network de show ip cef de vérifier que le prochain saut dans la table CEF apparie le prochain saut dans la table de Routage IP (d'étape 1, ci-dessus).

    2. Vérifiez que la contiguïté est correcte en émettant le détail de show adjacency | commencez la commande de next_hop_ip_address.

      Ceci devrait contenir la même adresse MAC de l'ARP vu dans l'étape 2, en haut.

Si étapes 1 et 2, en haut, fournissent des résultats corrects, mais les étapes 3a ou 3b manquent, vous faites face à une question de CEF de logiciel de Cisco IOS qui est non connexe probable au Catalyst 6500/6000. Vous devez essayer d'effacer la table ARP et la table de Routage IP.

Du PFC2 :

Procédez comme suit :

  1. Vérifiez que l'information enregistrée de FIB sur le PFC2 est correcte et apparie l'information enregistrée dans la table CEF sur le MSFC2 (comme vu dans étape 3, ci-dessus) en émettant la commande de destination_ip_network/destination_subnet_mask d'IP de cef de show mls entry, puis en vous vérifiant que la prochaine adresse IP de saut est celle prévoyez.

    Si les informations n'apparient pas les résultats dans l'étape 3, en haut, elles indiquent un problème de communication entre le MSFC2 et le PFC2 (internes au Catalyst 6500/6000). Vérifiez qu'il n'y a pas une bogue connu pour le CatOS du PFC2 ou le logiciel de Cisco IOS du MSFC2 que vous vous exécutez. Vous pouvez restaurer l'entrée correcte en émettant la commande de clear ip route sur le MSFC2.

  2. Vérifiez la table de juxtaposition sur le PFC2 en émettant la commande de contiguïté de l'IP next_hop_ip_address/32 de cef de show mls entry, puis vérifier ce il contient la même adresse MAC que celle vue dans les étapes 2 et 3b du de la section MSFC2, en haut.

    Si la contiguïté dans le PFC2 n'apparie pas la contiguïté pour le prochain saut dans l'étape 3b, vous faites face probablement à une question de communication interne entre le MSFC2 et le PFC2. Vous pouvez essayer effacer la contiguïté pour restaurer les informations correctes.

Étude de cas 1 : Connectivité à un hôte dans directement un réseau connecté

Ce cas simple fournit une étude de la Connectivité entre :

  • hébergez 1 dans le VLAN 10 avec une adresse IP de 192.168.10.10

  • hôte 2 dans VLAN 199 avec une adresse IP de 192.168.199.3

C'est un échantillon de la sortie de configuration 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

Remarque: Il est important de noter que le Catalyst 6500/6000 avec le Supervisor Engine 2 et le MSFC2 conduit utilisant le CEF dans le matériel. Il n'y a rien à configurer pour lui. Le CEF ne peut pas être désactivé sur le MSFC2.

Étapes de dépannage

Suivez les procédures mises en valeur dans la section de méthode de dépannage de ce document pour vérifier le chemin pour atteindre l'adresse IP 192.168.199.3.

  1. Vérifiez la table de Routage IP en émettant l'un ou l'autre de ces commandes :

    • 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

      ou

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

    Dans chacun des deux sorties de commande, vous pouvez voir que la destination est dans un sous-réseau directement connecté. En soi, il n'y a aucun prochain saut à la destination.

  2. Vérifiez l'entrée d'ARP sur le MSFC2.

    Dans ce cas, vérifiez qu'il y a une entrée d'ARP pour l'adresse IP de destination en émettant cette commande :

    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. Vérifiez le CEF et la table de juxtaposition sur le MSFC2.

    1. Vérifiez la table CEF en émettant cette commande :

      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

      Vous pouvez voir qu'il y a une entrée CEF valide avec une longueur de masque de 32 et qu'il y a de contiguïté valide de cache.

    2. Vérifiez la table de juxtaposition en émettant cette commande :

      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

      Comme vous pouvez voir de la sortie ci-dessus, il y a une contiguïté. L'adresse MAC de destination de la contiguïté affiche les mêmes informations que l'adresse MAC dans la table ARP de l'étape 2, en haut.

      Notez que les compteurs dans l'étape 3b sont presque toujours 0, car les paquets sont la couche 3 (L3) commutée dans le matériel. En soi, ils n'atteignent jamais le MSFC2 et ne sont pas comptés sur les compteurs du CEF MSFC2. La seule manière de voir des statistiques sur des paquets expédiés à une destination donnée est de regarder des statistiques de la contiguïté trouvée sur le PFC2 pendant l'étape 5.

  4. Vérifiez du point de vue d'engine de superviseur que vous avez l'entrée correcte CEF/FIB.

    Il y a deux entrées intéressantes dans le FIB, comme suit :

    1. Une entrée pour l'adresse IP de destination, comme affiché ici :

      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Ý 

      Cette entrée est une entrée de hôte avec un prochain saut déjà connu (qui, dans ce cas, est la destination elle-même).

    2. Une entrée correspondant au réseau de destination, comme affiché ici :

      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

      Cette entrée est une entrée connectée de FIB, ainsi il signifie que n'importe quel paquet frappant cette entrée est réorienté au MSFC2 pour une transformation plus ultérieure (principalement envoyant l'ARP et attendant la résolution d'ARP).

    Souvenez-vous que le FIB est parcouru séquentiellement, commençant par la plus longue longueur de masque. En soi, si les les deux les entrées répertoriées dans l'étape 4, en haut, sont présentes, vous avez frappé le premier avec le masque 32 (entrée de hôte), et vous ne descendez pas plus loin la table FIB. Dans le cas où l'entrée de /32 n'est pas présente, vous frappez la deuxième entrée, qui est l'entrée pour le réseau ; car c'est une entrée connectée, vous réorientez le paquet au MSFC2 pour une transformation plus ultérieure. Il est tout à fait possible que le MSFC2 envoie une demande d'ARP du masque de destination. Une fois que la réponse d'ARP est reçue, la table ARP et la table de juxtaposition sont terminées pour cet hôte sur le MSFC2.

  5. Une fois que vous avez l'entrée correcte de FIB avec la longueur 32 de masque, vérifiez que la contiguïté est correctement remplie pour cet hôte en émettant cette commande :

    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 

    Remarque: La contiguïté est remplie et le gisement de NextHop-MAC contient l'adresse MAC valide de l'hôte 2 (comme vu dans étapes 2 et 3b).

    En ce moment, toute la sortie est correcte, bien que le nombre de paquets transmis pour cette contiguïté soit toujours 0. Dans l'exemple suivant, vous envoyez dix pings de 100 octets de l'hôte 1 pour héberger 2 et pour vérifier la contiguïté de nouveau.

    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

    Vous pouvez maintenant voir que le nombre de TX-paquets est 10, qui est compatible au trafic qui a été envoyé.

Remarques et conclusions

Comme mentionné dans l'étape 4 des étapes de dépannage, en haut, vous avez deux entrées de FIB qui peuvent être une bonne correspondance, comme expliqué ci-dessous :

  • l'entrée de réseau (dans ce cas, 192.168.199.0/24) — cette entrée est toujours présente et est livré directement du routage et de la table CEF sur le MSFC. Vous faites toujours connecter directement ce réseau dans la table de routage.

  • l'entrée de destination host (dans ce cas, 192.168.199.3/32) — cette entrée n'est pas nécessairement présente. S'il n'est pas, vous frappez l'entrée de réseau, et ces éléments se produisent :

    1. Le paquet est expédié au MSFC2.

    2. L'entrée de hôte avec la longueur 32 de masque est alors créée dans la table FIB du PFC. Cependant, car vous n'avez pas encore une contiguïté complète, la contiguïté est créée avec le type étant ARC relâchent (qui veut dire la baisse de force).

    3. Le paquet suivant pour cette destination frappe l'entrée de baisse ARC de /32, et le paquet est lâché.

    4. En même temps, le paquet d'origine envoyé au MSFC2 déclenche le MSFC2 pour envoyer une demande d'ARP.

    5. Une fois que l'ARP est résolu, l'entrée d'ARP est terminée. La contiguïté est terminée sur le MSFC2, et une mise à jour de contiguïté est envoyée à l'engine de superviseur pour se terminer ARC existant relâchent la contiguïté.

    6. L'engine de superviseur change la contiguïté d'hôte pour refléter l'adresse MAC de réécriture, et le type de contiguïté est changé pour se connecter.

    Ce mécanisme d'installer ARC relâchent la contiguïté tandis que vous attendez l'ARP à résoudre s'appelle la commande de puissance d'ARP. Il est utile éviter commande de puissance d'ARP d'avoir tous les paquets expédiés au MSFC2 et de générer de plusieurs demandes d'ARP. Seulement les paquets premiers sont envoyés au MSFC2, et le repos sont abandonnés au PFC2 jusqu'à ce que la contiguïté soit complète.

    Ceci te permet également pour relâcher le trafic dirigé vers un hôte nonexisting ou non répondant dans directement un réseau connecté.

Des connexions de pour le dépannage entre deux utilisateurs dans deux VLAN différents, il est important de maintenir toujours dans l'esprit qui vous devez regarder :

  • trafiquez de l'hôte 1 pour héberger 2 suivre la méthode de dépannage, en haut, pour faire l'hôte 2 d'adresse IP de destination

  • trafiquez de l'hôte 2 pour héberger 1 suivre la même méthode, mais de cette fois avec la destination en tant qu'hôte 1

Il est également important de se souvenir que la sortie doit être prise sur la passerelle par défaut de la source, qui n'est pas nécessairement le même trafic de l'hôte 1 pour héberger 2 et à trafiquer de l'hôte 2 pour héberger 1.

Remarque: Les compteurs dans l'étape 3b des étapes de dépannage, en haut, sont presque toujours 0 car les paquets sont L3 commutés dans le matériel. En soi, ils n'atteignent jamais le MSFC2 et ne sont pas comptés sur les compteurs du CEF MSFC2. La seule manière de voir des statistiques sur des paquets expédiés à une destination donnée est de regarder des statistiques de la contiguïté trouvée sur le PFC2 pendant l'étape 5 des étapes de dépannage, en haut.

Étude de cas 2 : Connectivité à un réseau distant

Considérez le diagramme suivant, dans lequel l'hôte 1 avec une adresse IP des pings de 192.168.10.10 hébergent 2 avec une adresse IP de 192.168.150.3. Cependant, cette fois, l'hôte 2 se trouve deux sauts conduits loin au lieu d'être directement connecté au Catalyst 6500/6000-MSFC2. La même méthode est utilisée pour suivre le chemin conduit par CEF sur le Catalyst 6500/6000-MSFC2.

128-a.gif

Étapes de dépannage

Procédez comme suit :

  1. Vérifiez la table de routage sur le MSFC2 en émettant cette commande :

    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

    Vous pouvez voir de la sortie au-dessus de cela, pour atteindre l'hôte 2 avec l'adresse IP 192.168.150.3, vous avez une artère de Protocole OSPF (Open Shortest Path First). Il doit être atteint utilisant l'adresse IP 192.168.199.3 dans VLAN 199 comme prochain saut.

  2. Vérifiez la table ARP sur le MSFC2 en émettant la commande ci-dessous.

    Remarque: Vérifiez l'entrée d'ARP pour le prochain saut, pas pour la destination définitive.

    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. Vérifiez la table CEF et la table de juxtaposition sur le MSFC2 en émettant cette commande :

    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

    Vous pouvez voir qu'il y a une entrée CEF pour le réseau de destination, et le prochain saut résulte correspondance ce que vous avez dans l'étape 1 de la table de routage.

  4. Vérifiez la table de juxtaposition pour le prochain saut en émettant cette commande :

    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

    Il y a une contiguïté valide pour le prochain saut, et l'adresse MAC de destination apparie l'entrée d'ARP trouvée dans l'étape 2, en haut.

  5. Vérifiez la table FIB sur l'engine de superviseur (PFC2) en émettant cette commande :

    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

    Le FIB reflète les mêmes informations trouvées dans l'étape 3, et vous prenez le même prochain saut.

  6. Vérifiez la contiguïté sur l'engine de superviseur (PFC2) en émettant cette commande :

    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

    Vous pouvez également vérifier que vous avez une contiguïté de connecter qui reflète la même adresse MAC que trouvée dans les étapes 2 et 4, en haut.

Remarque: Vous pouvez vérifier la contiguïté pour la destination définitive en vérifiant la contiguïté sur le PFC2. Ce n'est pas possible avec le logiciel de Cisco IOS sur le MSFC2, avec lequel vous devez vérifier la contiguïté pour le prochain saut. La table de juxtaposition sur le PFC2 pour la destination définitive affiche le prochain saut et la contiguïté pour le prochain saut (si elle est résolue), tous dans une sortie de commande. Sur le MSFC2, vous devez vérifier séparément l'entrée CEF pour trouver le prochain saut et puis pour regarder à la prochaine contiguïté de saut elle-même.

Remarques et conclusions

Vous pouvez voir dans cet exemple que les étapes de dépannage utilisées pour vérifier la Connectivité sur un Catalyst 6500/6000-MSFC2 pour atteindre un réseau distant sont semblables à l'exemple précédent trouvé dans l'étude de cas 1 de section : Connectivité à un hôte dans directement un réseau connecté. Il y a, cependant, quelques différences :

  • Vous vérifiez le destination in définitif la table, la table CEF, et le FIB de Routage IP (étapes 1, 3, et 5).

  • Vous vérifiez les prochaines informations de saut dans la table ARP et la table de juxtaposition (étapes 2 et 4).

  • Dans l'étape 6, vous pouvez directement vérifier la contiguïté pour la destination définitive. Les résultats affichent le prochain saut du FIB et la contiguïté réécrivent les informations de la table de juxtaposition.

Dans ce cas, il n'y a aucune entrée dans le FIB pour la destination définitive, comme affiché ci-dessous. (Seulement l'entrée de réseau en présence de la longueur de masque de 24 est.)

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

Étude de cas 3 : Équilibrage de charge à plusieurs prochains sauts

Cette étude de cas discute ce qui se produit au cas où plusieurs prochains sauts et plusieurs artères seraient disponibles pour atteindre le même réseau de destination.

  1. Dans une section témoin de la table de routage ci-dessous, notez qu'il y a trois routes différentes et trois prochains sauts différents disponibles pour atteindre la même adresse IP de destination de 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. Vérifiez l'entrée d'ARP pour chacun des trois prochains sauts, en suivant ces étapes :

    1. Vérifiez la table CEF pour la destination.

      Notez que la destination affiche également trois entrées différentes dans la table CEF sur le MSFC2. Le CEF de logiciel de Cisco IOS peut faire le chargement partageant entre les routes différentes.

      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. Vérifiez les trois contiguïtés dans la table de juxtaposition MSFC2.

      Ils devraient apparier l'entrée d'ARP dans l'étape 2, en haut.

  3. Notez que trois entrées différentes de FIB sont installées pour la même destination.

    Le CEF de matériel sur le PFC2 peut charger le partage jusqu'à six différents chemins pour la même destination. Vous pouvez voir le poids utilisé pour chaque prochain saut dans le poids pour mettre en place. Partager de chargement utilisé par le PFC2 est seulement partager de chargement de par-écoulement. Il n'active pas partager de chargement de par-paquet.

    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. Vérifiez la contiguïté pour cette entrée de destination en émettant cette commande :

    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

Étude de cas 4 : Routage par défaut

Celui qui la table de routage ressemble à, il y a toujours une entrée de FIB dans le Supervisor Engine 2 pour expédier les paquets qui ne font pas match any l'autre entrée précédente. Vous pouvez voir cette entrée en émettant cette commande :

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

Comme vous pouvez voir, c'est la seule entrée avec une longueur de masque de 0. Ce par défaut peut être de deux types, comme expliqué ci-dessous dans le default route de sections existe dans le Tableau de routage MSFC2 et aucun default route dans le Tableau de routage.

Le default route existe dans le Tableau de routage MSFC2

D'abord, déterminez comment vérifier si un default route est présent dans la table du routage MSFC2. Vous pouvez rechercher une artère avec une destination de 0.0.0.0 ou regarder dans la table de routage. Le default route est identifié par un astérisque (*). (Ici, il apparaît en caractères gras également.)

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

Dans ce cas, le default route est présent dans la table du routage MSFC2 et est appris par l'intermédiaire du Protocole RIP (Routing Information Protocol). Cependant, notez que le comportement de CEF est identique n'importe comment ce default route est appris (charge statique, OSPF, RIP, et ainsi de suite).

Dans ce cas, où vous avez un default route, vous avez toujours une entrée CEF avec une longueur de masque de 0 et un FIB-type de par défaut qui est utilisé pour expédier tout le trafic n'appariant pas n'importe quel autre préfixe.

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

Pendant que le FIB est parcouru séquentiellement pour chaque paquet, commençant par la correspondance plus longue d'abord, ce FIB par défaut est seulement utilisé pour les paquets pour lesquels aucune autre correspondance n'a été trouvée.

Aucun default route dans le Tableau de routage

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

S'il n'y a pas aucun default route dans la table de routage, il y a toujours une entrée de FIB avec la longueur 0 de masque dans le Supervisor Engine 2. Cependant, cette entrée a maintenant un FIB-type de masque. Ce FIB de masque relâche tous les paquets le frappant et apparie n'importe quel paquet qui ne fait pas match any l'autre entrée dans le FIB. Il est utile de relâcher ces paquets, car vous n'avez aucun default route. Il n'y a aucun besoin d'expédier ces paquets au MSFC2, qui les relâcherait de toute façon. À l'aide de ce FIB de masque, vous assurez la baisse de ces paquets inutiles dans le matériel.

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

Remarque: Dans le rare cas en lequel la table FIB est pleine, l'entrée générique est encore présente mais, au lieu des paquets de baisse qui l'apparient, ils sont expédiés au MSFC2. Ceci se produit seulement si vous avez plus qu'un préfixe 256K dans le FIB et si vous ne pouvez pas enregistrer la table de routage et la contiguïté complètes d'ARP dans le FIB. Vous devez alors avoir le mécanisme par défaut envoyé au MSFC2 puisque le MSFC2 peut avoir une entrée de routage qui n'est pas présente dans le FIB.

D'autres conseils et problèmes connus de dépannage

Émettre la commande de show mls cef mac

Quand le Supervisor Engine 2 obtient un paquet, il le considère seulement un paquet du potentiel L3 si l'adresse MAC de destination du paquet est identique qu'une des adresses MAC MSFC2. Vous pouvez vérifier que ces adresses sont du point de vue de Supervisor Engine 2 en émettant cette commande :

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

Vous pouvez voir l'adresse MAC physique du MSFC2. (Souvenez-vous que toutes les interfaces sur le MSFC2 utilisent la même adresse MAC ; vous ne pouvez pas configurer des adresses de MAC différent sur deux interfaces différentes.) Cette adresse MAC doit être identique que celle sur le 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) 
?..

La commande de show mls cef mac affiche également toutes les adresses MAC jointes aux groupes de Protocole HSRP (Hot Standby Router Protocol), où le MSFC est en activité. La sortie de la commande de show mls cef mac, en haut, signifie que le MSFC est Hsrp-actif pour le VLAN 10 et pour VLAN 100. Vous pouvez vérifier que c'est correct en émettant cette commande sur le 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

Comme vous pouvez voir, l'état est en activité pour seulement VLAN 10 et VLAN 100. L'état est de réserve pour tous autres groupes de HSRP configurés. Si, pour quelque raison que ce soit, un état d'Active commence pour un autre VLAN, la sortie de la commande de show mls cef mac devrait refléter que ce VLAN supplémentaire n'est pas en activité.

S'il y a des incohérences entre la sortie de commande de show mls cef mac et ce qui être elle devrait, vous pouvez émettre cette commande, qui fournit plus d'informations sur les adresses MAC ajoutées et retirées dans la liste de commandes de 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

Cette commande fournit un message chaque fois que vous ajoutez ou retirez une adresse MAC dans la table de commande de show mls cef mac.

Shadow TCAM

Ce document a discuté comment vérifier la table de commande de cef de show mls entry sur le Supervisor Engine 2. Cette commande ne représente pas exactement la vraie programmation de circuit intégré spécifique (ASIC) du PFC2. Il représente seulement une copie de shadow de cette configuration ASIC. Il y a eu quelques problèmes connus dans lesquels les vraies configurations matérielles n'étaient pas conformes à ce qui a été affiché dans le shadow TCAM, qui a causé quelques paquets d'être expédiés au prochain saut faux. Ces questions sont documentées dans l'ID de bogue Cisco CSCdv49956leavingcisco.com (clients enregistrés seulement) et CSCdu85211leavingcisco.com (clients enregistrés seulement), qui chacun des deux sont réparés dans des versions de logiciel de CatOS 6.3(3), 7.1(1), et plus tard.

Routage par défaut cassé

Il y avait une bogue trouvée dans les versions tôt du code dans lesquelles l'expédition au default route n'a pas fonctionné avec le Protocole EIGPR (Enhanced Interior Gateway Routing Protocol) ou avec l'OSPF. Ceci est documenté dans l'ID de bogue Cisco CSCdt54036leavingcisco.com (clients enregistrés seulement), et est réparé dans la version de logiciel de CatOS 6.1(3) et plus tard pour l'image d'engine de superviseur, et dans le Logiciel Cisco IOS version 12.1(6)E1 pour l'image MSFC2.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 20626