Ce document doit être utilisé comme guide pour dépanner le routage IP de monodiffusion sur les commutateurs Catalyst 6500/6000 avec Supervisor Engine 2, Policy Feature Card 2 (PFC2), Multilayer Switch Feature Card 2 (MSFC2). Le routage de monodiffusion sur le Supervisor Engine 2 s'effectue à l'aide de Cisco Express Forwarding (CEF). Ce document concerne uniquement le routage IP sur la gamme Catalyst 6500/6000 équipée de Supervisor Engine 2, PFC2, MSFC2. Ce document n'est pas valide pour un Catalyst 6500/6000 avec Supervisor Engine 1 (ou 1A) ou pour le module de commutation multicouche (MSM). Ce document n'est valide que pour les commutateurs exécutant le logiciel système Catalyst OS (CatOS) sur le Supervisor Engine, et non pour le logiciel système Cisco IOS®.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
CEF était à l'origine une technique de commutation du logiciel Cisco IOS conçue pour acheminer les paquets plus rapidement. CEF est beaucoup plus évolutif que la commutation rapide. (Il n’est pas nécessaire d’envoyer le premier paquet pour traiter la commutation.) Le Catalyst 6500 avec Supervisor Engine 2 utilise un mécanisme de transfert CEF matériel mis en oeuvre sur la carte PFC2. CEF utilise principalement deux tables pour stocker les informations nécessaires au routage : la base d'informations de transfert (FIB) et la table de contiguïté.
CEF utilise une FIB pour prendre des décisions de commutation basées sur les préfixes de destination IP (correspondance la plus longue en premier). La base de données d’identification de réseau (FIB) est conceptuellement similaire à une table de routage ou à une base d’informations. Il conserve une image miroir des informations de transfert 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. La FIB conserve les informations d’adresse de tronçon suivant en fonction des informations de la table de routage IP. En raison d’une corrélation un-à-un entre les entrées FIB et les entrées de table de routage, la FIB contient toutes les routes connues et élimine le besoin de maintenance du cache de route associé aux chemins de commutation, tels que la commutation rapide et la commutation optimale. Il y a toujours une correspondance dans la FIB, qu'il s'agisse d'une valeur par défaut ou d'un caractère générique.
Les noeuds du réseau sont considérés comme adjacents s’ils peuvent se joindre par un seul saut sur une couche liaison. Outre la FIB, CEF utilise des tables de contiguïté pour prédéfinir les informations d’adressage de couche 2 (L2). La table de contiguïté conserve les adresses de tronçon suivant L2 pour toutes les entrées FIB. Cela signifie qu'une entrée FIB complète contient un pointeur vers un emplacement dans la table de contiguïté qui contient les informations de réécriture L2 pour le tronçon suivant afin d'atteindre la destination IP finale. Pour que le CEF matériel fonctionne sur le système Catalyst 6500/Supervisor Engine 2, IP CEF doit être exécuté sur le MSFC2.
La table FIB de la carte PFC2 doit être exactement la même que la table FIB de la carte MSFC2. Sur la carte PFC2, tous les préfixes IP de la FIB sont stockés dans une mémoire TCAM (ternary content Addressable Memory) et triés par longueur de masque, en commençant par le masque le plus long. Cela signifie que vous devez d'abord trouver toutes les entrées avec un masque de 32 (entrée hôte); ensuite, vous trouverez toutes les entrées ayant une longueur de masque de 31, etc., jusqu'à ce que vous atteigniez une entrée avec une longueur de masque de 0. Il s'agit de l'entrée par défaut. La FIB est lue séquentiellement et le premier résultat est utilisé comme correspondance. Considérez cet exemple de tableau FIB sur 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 MSFC2 qui installe l'entrée est 15 ou 16, selon lequel est le MSFC2 désigné.
FIB-Type : type associé à cette entrée spécifique. Les types FIB possibles sont les suivants :
Receive : préfixe associé aux interfaces MSFC. Elle contient un préfixe avec un masque de 32 correspondant à l'adresse IP des interfaces MSFC et une adresse IP du sous-réseau de diffusion.
résolu : préfixe associé à une adresse de tronçon suivant valide. Ceci contient n'importe quel préfixe avec une contiguïté résolue pour le tronçon suivant.
connected : préfixe associé à un réseau connecté.
caractère générique : correspond à toutes les entrées (abandon ou redirection MSFC). Cette entrée n'est présente que s'il n'y a pas d'entrée par défaut et est présente avec une longueur de masque de 0.
default : route par défaut. Comme entrée générique, elle correspond à tous les sous-réseaux et est présente avec une longueur de masque de 0. Il pointe vers le tronçon suivant. Cette entrée CEF par défaut n'est présente que si une route par défaut figure dans la table de routage.
drop : tous les paquets correspondant à une entrée avec une goutte sont abandonnés.
Destination-IP : adresse IP de destination ou sous-réseau IP concerné.
Destination-Mask : masque associé à l'entrée. Comme vous pouvez le voir dans l'exemple ci-dessus, la FIB est classée en commençant par le masque le plus long (255.255.255.255) et en se terminant par le masque le plus court possible (0.0.0.0).
Next-Hop IP : affiche l'adresse IP du tronçon suivant, le cas échéant.
Vous pouvez afficher la table de contiguïté complète en entrant 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 similaire à celle de la table FIB exemple ci-dessus, pour chacune des entrées CEF résolues (ou par défaut) de la FIB.
Avant de fournir des exemples et des détails sur le dépannage, cette section récapitule les méthodes utilisées pour dépanner la connectivité ou l'accessibilité à une adresse IP spécifique. N'oubliez pas que la table CEF sur la carte PFC2 reflète la table CEF sur la carte MSFC2. Par conséquent, PFC2 ne contient les informations correctes pour atteindre une adresse IP que si les informations connues par MSFC2 sont également correctes. En tant que tel, vous devez toujours vérifier les informations ci-dessous.
Procédez comme suit :
Vérifiez que les informations contenues dans le routage IP sur la table MSFC2 sont correctes en exécutant la commande show ip route (ou la commande show ip route x.x.x.x, pour éviter de parcourir la table de routage complète), puis en vérifiant que le résultat contient le saut suivant attendu.
Si ce n'est pas le cas, vous devez vérifier votre protocole de routage, votre configuration, votre voisin de protocole de routage et tout autre dépannage pertinent au protocole de routage que vous exécutez.
Vérifiez que le saut suivant (ou la destination finale d'un réseau connecté) a une entrée ARP (Address Resolution Protocol) résolue correcte sur le MSFC2 en exécutant la commande show ip arp next_hop_ip_address, puis en vérifiant que le protocole ARP est résolu et contient l'adresse MAC correcte.
Si l'adresse MAC est incorrecte, vous devez vérifier si une autre unité possède cette adresse IP. Vous devrez éventuellement suivre le niveau du commutateur sur le port qui connecte le périphérique propriétaire de cette adresse MAC. Si l’entrée ARP est incomplète, cela signifie que vous n’avez reçu aucune réponse de cet hôte. Vous devez vérifier que l'hôte est opérationnel. Un analyseur peut être utilisé sur l’hôte pour voir s’il obtient la réponse ARP et s’il répond correctement.
Vérifiez que la table CEF sur le MSFC2 contient les informations correctes et que la contiguïté est résolue en procédant comme suit :
Exécutez la commande show ip cef destination_network pour vérifier que le saut suivant de la table CEF correspond au saut suivant de la table de routage IP (à l’étape 1 ci-dessus).
Vérifiez que la contiguïté est correcte en émettant la commande show adjacency detail | begin next_hop_ip_address commande.
Cette adresse doit contenir la même adresse MAC que celle du protocole ARP indiquée à l’étape 2 ci-dessus.
Si les étapes 1 et 2 ci-dessus fournissent des résultats corrects, mais que les étapes 3a ou 3b échouent, vous êtes confronté à un problème CEF du logiciel Cisco IOS qui n'est probablement pas lié au Catalyst 6500/6000. Vous devez essayer de supprimer la table ARP et la table de routage IP.
Procédez comme suit :
Vérifiez que les informations FIB stockées sur la carte PFC2 sont correctes et correspondent aux informations stockées dans la table CEF de la commande MSFC2 (comme indiqué à l'étape 3 ci-dessus) en émettant la commande show mls entry ip destination_ip_network/destination_subnet_mask, puis en vérifiant que l'adresse IP du tronçon suivant est celle que vous attendez.
Si les informations ne correspondent pas aux résultats de l'étape 3 ci-dessus, elles indiquent un problème de communication entre le MSFC2 et le PFC2 (interne au Catalyst 6500/6000). Vérifiez qu'il n'existe pas de bogue connu pour le CatOS de la carte PFC2 ou le logiciel Cisco IOS de la carte MSFC2 que vous exécutez. Vous pouvez restaurer l'entrée correcte en exécutant la commande clear ip route sur le MSFC2 .
Vérifiez la table de contiguïté sur la carte PFC2 en exécutant la commande show mls entry cef next_hop_ip_address/32 adjacency, puis en vérifiant qu'elle contient la même adresse MAC que celle des étapes 2 et 3b de la section From the MSFC2, ci-dessus.
Si la contiguïté dans la carte PFC2 ne correspond pas à la contiguïté du tronçon suivant de l'étape 3b, vous êtes probablement confronté à un problème de communication interne entre MSFC2 et PFC2. Vous pouvez tenter de supprimer la contiguïté pour restaurer les informations correctes.
Ce cas simple fournit une étude de la connectivité entre :
hôte 1 dans le VLAN 10 avec l’adresse IP 192.168.10.10
hôte 2 dans le VLAN 199 avec l’adresse IP 192.168.199.3
Voici un exemple du résultat de la 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 Supervisor Engine 2 et MSFC2 utilise CEF dans le matériel. Il n'y a rien à configurer. CEF ne peut pas être désactivé sur le MSFC2.
Suivez les procédures mises en évidence dans la section Méthode de dépannage de ce document pour vérifier le chemin d'accès à l'adresse IP 192.168.199.3.
Vérifiez la table de routage IP en exécutant l’une des commandes suivantes :
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 ces deux sorties de commande, vous pouvez voir que la destination se trouve dans un sous-réseau directement connecté. En tant que tel, il n'y a pas de tronçon suivant vers la destination.
Vérifiez l'entrée ARP sur le MSFC2.
Dans ce cas, vérifiez qu'il existe une entrée ARP pour l'adresse IP de destination en exécutant 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
Vérifiez le CEF et la table de contiguïté sur le MSFC2.
Vérifiez la table CEF en exécutant 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 existe une entrée CEF valide avec une longueur de masque de 32 et qu'il existe une contiguïté de cache valide.
Vérifiez la table de contiguïté en exécutant 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 le voir dans le résultat 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 ci-dessus.
Notez que les compteurs de l'étape 3b sont presque toujours 0, car les paquets sont de couche 3 (L3) commutés dans le matériel. En tant que tels, ils n'atteignent jamais le MSFC2 et ne sont pas comptés sur les compteurs CEF du MSFC2. La seule façon de voir les statistiques sur les paquets transmis à une destination donnée est de regarder les statistiques de la contiguïté trouvée sur la carte PFC2 au cours de l'étape 5.
Vérifiez du point de vue du Supervisor Engine que vous disposez de l'entrée CEF/FIB correcte.
Il existe deux entrées intéressantes dans la FIB, comme suit :
Une entrée pour l'adresse IP de destination, comme indiqué 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 hôte avec un saut suivant déjà connu (qui, dans ce cas, est la destination elle-même).
Une entrée correspondant au réseau de destination, comme indiqué 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 FIB connectée, ce qui signifie que tout paquet qui touche cette entrée est redirigé vers le MSFC2 pour un traitement ultérieur (principalement en envoyant ARP et en attendant la résolution ARP).
N’oubliez pas que la FIB est parcourue séquentiellement, en commençant par la longueur de masque la plus longue. En tant que tel, si les deux entrées répertoriées à l'étape 4 ci-dessus sont présentes, vous appuyez sur la première entrée avec le masque 32 (entrée d'hôte), et vous n'allez pas plus loin dans la table FIB. Dans le cas où l'entrée /32 n'est pas présente, vous appuyez sur la deuxième entrée, qui est l'entrée du réseau ; comme il s'agit d'une entrée connectée, vous redirigez le paquet vers le MSFC2 pour un traitement ultérieur. Il est tout à fait possible que la MSFC2 envoie une requête ARP pour le masque de destination. Une fois la réponse ARP reçue, la table ARP et la table de contiguïté sont terminées pour cet hôte sur le MSFC2.
Une fois que vous avez l'entrée FIB correcte avec la longueur de masque 32, vérifiez que la contiguïté est correctement renseignée pour cet hôte en exécutant 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 renseignée et le champ NextHop-Mac contient l'adresse MAC valide de l'hôte 2 (comme indiqué aux étapes 2 et 3b).
À ce stade, tous les résultats sont corrects, bien que le nombre de paquets transmis pour cette contiguïté soit toujours égal à 0. Dans l'exemple suivant, vous envoyez dix requêtes ping de 100 octets de l'hôte 1 à l'hôte 2 et vérifiez à nouveau la contiguïté.
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 paquets TX est 10, ce qui correspond au trafic envoyé.
Comme indiqué à l'étape 4 des étapes de dépannage ci-dessus, vous avez deux entrées FIB qui peuvent correspondre correctement, comme expliqué ci-dessous :
l'entrée réseau (dans ce cas, 192.168.199.0/24) : cette entrée est toujours présente et provient directement de la table de routage et CEF sur le MSFC. Ce réseau est toujours directement connecté dans la table de routage.
l’entrée d’hôte de destination (dans ce cas, 192.168.199.3/32) : cette entrée n’est pas nécessairement présente. Si ce n'est pas le cas, vous appuyez sur l'entrée réseau et ces éléments se produisent :
Le paquet est transféré à la carte MSFC2.
L’entrée d’hôte avec la longueur de masque 32 est ensuite créée dans la table FIB de la carte PFC. Cependant, comme vous n'avez pas encore de contiguïté complète, la contiguïté est créée avec le type frc drop (ce qui signifie force drop).
Le paquet suivant pour cette destination atteint l'entrée /32 frc drop et le paquet est abandonné.
En même temps, le paquet d'origine envoyé à la MSFC2 déclenche l'envoi d'une requête ARP par la MSFC2.
Une fois le protocole ARP résolu, l’entrée ARP est terminée. La contiguïté est terminée sur le MSFC2 et une mise à jour de contiguïté est envoyée au Supervisor Engine pour compléter la contiguïté frc drop existante.
Le Supervisor Engine modifie la contiguïté hôte pour refléter l'adresse MAC de réécriture et le type de contiguïté est modifié pour se connecter.
Ce mécanisme d'installation d'une contiguïté frc drop pendant que vous attendez que le protocole ARP soit résolu est appelé régulation ARP. La régulation ARP est utile pour éviter que tous les paquets soient transférés à la MSFC2 et générer plusieurs requêtes ARP. Seuls les premiers paquets sont envoyés au MSFC2 et les autres sont abandonnés au PFC2 jusqu'à ce que la contiguïté soit terminée.
Cela vous permet également d'abandonner le trafic dirigé vers un hôte non existant ou ne répondant pas dans un réseau directement connecté.
Lors du dépannage des connexions entre deux utilisateurs dans deux VLAN différents, il est important de toujours garder à l’esprit que vous devez regarder :
trafic de l’hôte 1 à l’hôte 2 à l’aide de la méthode de dépannage ci-dessus, pour faire de l’adresse IP de destination l’hôte 2
trafic de l’hôte 2 à l’hôte 1 en utilisant la même méthode, mais cette fois avec la destination en tant qu’hôte 1
Il est également important de se rappeler 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 à l'hôte 2 et du trafic de l'hôte 2 à l'hôte 1.
Remarque : Les compteurs de l'étape 3b des étapes de dépannage ci-dessus sont presque toujours 0, car les paquets sont commutés de couche 3 dans le matériel. En tant que tels, ils n'atteignent jamais le MSFC2 et ne sont pas comptés sur les compteurs CEF du MSFC2. La seule façon de voir les statistiques sur les paquets transmis à une destination donnée est de regarder les statistiques de la contiguïté trouvée sur la carte PFC2 au cours de l'étape 5 des étapes de dépannage, ci-dessus.
Considérez le schéma suivant, dans lequel l’hôte 1 avec l’adresse IP 192.168.10.10 envoie une requête ping à l’hôte 2 avec l’adresse IP 192.168.150.3. Cependant, cette fois, l'hôte 2 est situé à deux sauts routés au lieu d'être directement connecté à Catalyst 6500/6000-MSFC2. La même méthode est utilisée pour suivre le chemin routé CEF sur Catalyst 6500/6000-MSFC2.
Procédez comme suit :
Vérifiez la table de routage sur le MSFC2 en exécutant 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 dans le résultat ci-dessus que, pour atteindre l'hôte 2 avec l'adresse IP 192.168.150.3, vous avez une route OSPF (Open Shortest Path First). Il doit être atteint à l’aide de l’adresse IP 192.168.199.3 dans le VLAN 199 comme prochain saut.
Vérifiez la table ARP sur le MSFC2 en exécutant la commande ci-dessous.
Remarque : cochez l'entrée ARP pour le saut suivant et non pour la destination finale.
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
Vérifiez la table CEF et la table de contiguïté sur le MSFC2 en exécutant 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 existe une entrée CEF pour le réseau de destination et que les résultats du saut suivant correspondent à ceux de l’étape 1 de la table de routage.
Vérifiez la table de contiguïté du saut suivant en exécutant 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 existe une contiguïté valide pour le tronçon suivant et l’adresse MAC de destination correspond à l’entrée ARP trouvée à l’étape 2 ci-dessus.
Vérifiez la table FIB sur le Supervisor Engine (PFC2) en exécutant 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
La FIB reflète les mêmes informations que celles de l'étape 3 et vous avez le même saut suivant.
Vérifiez la contiguïté sur le Supervisor Engine (PFC2) en exécutant 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 connexion qui reflète la même adresse MAC que celle trouvée aux étapes 2 et 4 ci-dessus.
Remarque : Vous pouvez vérifier la contiguïté pour la destination finale lors de la vérification de la contiguïté sur le PFC2. Ceci n'est pas possible avec le logiciel Cisco IOS sur la MSFC2, avec lequel vous devez vérifier la contiguïté pour le prochain saut. La table de contiguïté de la carte PFC2 pour la destination finale affiche à la fois le saut suivant et la contiguïté pour le saut suivant (s'il est résolu), le tout dans une sortie de commande. Sur le MSFC2, vous devez vérifier séparément l'entrée CEF pour trouver le saut suivant, puis regarder la contiguïté du saut suivant elle-même.
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 similaires à l'exemple précédent trouvé dans la section Étude de cas 1 : Connectivité à un hôte dans un réseau connecté directement. Il y a cependant quelques différences :
Vous vérifiez la destination finale dans la table de routage IP, la table CEF et la FIB (étapes 1, 3 et 5).
Vous vérifiez les informations de tronçon suivant dans la table ARP et la table de contiguïté (étapes 2 et 4).
À l'étape 6, vous pouvez vérifier directement la contiguïté pour la destination finale. Les résultats affichent à la fois le saut suivant de la FIB et les informations de réécriture de contiguïté de la table de contiguïté.
Dans ce cas, il n'y a aucune entrée dans la FIB pour la destination finale, comme indiqué ci-dessous. (Seule l'entrée réseau avec une longueur de masque de 24 est présente.)
Cat6k> (enable) show mls entry cef ip 192.168.150.3/32 adjacency Cat6k> (enable)
Cette étude de cas explique ce qui se passe si plusieurs sauts suivants et plusieurs routes sont disponibles pour atteindre le même réseau de destination.
Dans un exemple de section de la table de routage ci-dessous, notez que trois routes différentes et trois sauts suivants différents sont disponibles pour atteindre la même adresse IP de destination 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
Vérifiez l'entrée ARP pour chacun des trois sauts suivants, en procédant comme suit :
Vérifiez la table CEF pour la destination.
Notez que la destination affiche également trois entrées différentes dans la table CEF sur MSFC2. Le logiciel Cisco IOS CEF est capable d'effectuer le partage de charge entre différentes routes.
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
Vérifiez les trois contiguïtés dans la table de contiguïté MSFC2.
Ils doivent correspondre à l’entrée ARP de l’étape 2 ci-dessus.
Notez que trois entrées FIB différentes sont installées pour la même destination.
Le CEF matériel sur la carte PFC2 peut charger jusqu'à six chemins différents pour la même destination. Vous pouvez voir le poids utilisé pour chaque saut suivant dans le champ de poids. Le partage de charge utilisé par la carte PFC2 est uniquement un partage de charge par flux. Il n'active pas le partage de charge 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
Vérifiez la contiguïté de cette entrée de destination en exécutant 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
Quelle que soit la table de routage, il y a toujours une entrée FIB dans le Supervisor Engine 2 pour transférer les paquets qui ne correspondent à aucune autre entrée précédente. Vous pouvez voir cette entrée en exécutant 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 le voir, il s'agit de la seule entrée avec une longueur de masque de 0. Cette valeur par défaut peut être de deux types, comme expliqué ci-dessous dans les sections Default Route Exists dans la table de routage MSFC2 et No Default Route dans la table de routage.
Tout d'abord, déterminez comment vérifier si une route par défaut est présente dans la table de routage MSFC2. Vous pouvez rechercher une route dont la destination est 0.0.0.0 ou consulter la table de routage. La route par défaut est marquée par un astérisque (*). (Ici, il apparaît également en caractères gras.)
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, la route par défaut est présente dans la table de routage MSFC2 et est apprise via le protocole RIP (Routing Information Protocol). Cependant, notez que le comportement CEF est le même quelle que soit la manière dont cette route par défaut est apprise (statique, OSPF, RIP, etc.).
Dans ce cas, lorsque vous avez une route par défaut, vous avez toujours une entrée CEF avec une longueur de masque de 0 et un type FIB de valeur par défaut qui est utilisé pour transférer tout trafic ne correspondant à aucun 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
Comme le FIB est parcouru séquentiellement pour chaque paquet, en commençant par la plus longue correspondance en premier, ce FIB par défaut est utilisé uniquement pour les paquets pour lesquels aucune autre correspondance n'a été trouvée.
Cat6k-MSFC2# show ip route 0.0.0.0 % Network not in table
S'il n'y a aucune route par défaut dans la table de routage, il y a toujours une entrée FIB avec la longueur de masque 0 dans le Supervisor Engine 2. Cependant, cette entrée a maintenant un type FIB de caractères génériques. Ce FIB générique supprime tous les paquets qui le touchent et correspond à tout paquet qui ne correspond à aucune autre entrée dans le FIB. Il est utile d'abandonner ces paquets, car vous n'avez aucune route par défaut. Il n'est pas nécessaire de transférer ces paquets vers la MSFC2, qui les abandonnerait de toute façon. En utilisant ce FIB générique, vous garantissez la suppression 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 cas rare où la table FIB est pleine, l'entrée générique est toujours présente mais, au lieu de supprimer les paquets qui correspondent, ils sont transférés à la MSFC2. Cela se produit uniquement si vous avez plus d'un préfixe de 256 Ko dans la FIB et si vous ne pouvez pas stocker la table de routage complète et la contiguïté ARP dans la FIB. Vous devez ensuite envoyer le mécanisme par défaut à MSFC2, car MSFC2 peut avoir une entrée de routage qui n'est pas présente dans FIB.
Lorsque le Supervisor Engine 2 reçoit un paquet, il le considère comme un paquet potentiel de couche 3 uniquement si l'adresse MAC de destination du paquet est identique à l'une des adresses MAC MSFC2. Vous pouvez vérifier que ces adresses sont du point de vue du Supervisor Engine 2 en exécutant 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 de la carte MSFC2. (Souvenez-vous que toutes les interfaces de la carte MSFC2 utilisent la même adresse MAC ; vous ne pouvez pas configurer différentes adresses MAC sur deux interfaces différentes.) Cette adresse MAC doit être identique à celle de la carte 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 show mls cef mac affiche également toutes les adresses MAC liées aux groupes HSRP (Hot Standby Router Protocol), où la carte MSFC est active. Le résultat de la commande show mls cef mac, ci-dessus, signifie que la MSFC est HSRP-active pour VLAN 10 et VLAN 100. Vous pouvez vérifier que ceci est correct en exécutant cette commande sur 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 le voir, l'état est Actif pour VLAN 10 et VLAN 100 uniquement. L'état est En veille pour tous les autres groupes HSRP configurés. Si, pour une raison quelconque, un état d'Active commence pour un autre VLAN, le résultat de la commande show mls cef mac doit indiquer que ce VLAN supplémentaire n'est pas actif.
En cas d'incohérence entre la sortie de commande show mls cef mac et ce qu'elle devrait être, vous pouvez émettre cette commande, qui fournit plus d'informations sur les adresses MAC ajoutées et supprimées dans la liste de commandes 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 supprimez une adresse MAC dans la table de commandes show mls cef mac.
Ce document explique comment vérifier la table de commandes show mls entry cef sur le Supervisor Engine 2. Cette commande ne représente pas fidèlement la programmation réelle du circuit intégré spécifique à l'application (ASIC) de la carte PFC2. Il représente uniquement un cliché instantané de ce paramètre ASIC. Il y a eu des problèmes connus dans lesquels les vrais paramètres matériels n'étaient pas d'accord avec ce qui était affiché dans le TCAM fantôme, ce qui a entraîné le transfert de certains paquets au mauvais saut suivant. Ces problèmes sont documentés dans l'ID de bogue Cisco CSCdv49956 (clients enregistrés uniquement) et CSCdu85211 (clients enregistrés uniquement) , qui sont tous deux corrigés dans les versions 6.3(3), 7.1(1) et ultérieures du logiciel CatOS.
Un bogue a été détecté dans les premières versions du code dans lequel le transfert vers la route par défaut ne fonctionnait pas avec le protocole EIGRP (Enhanced Interior Gateway Routing Protocol) ou avec OSPF. Ceci est documenté dans l'ID de bogue Cisco CSCdt54036 (clients enregistrés uniquement) et est corrigé dans le logiciel CatOS version 6.1(3) et ultérieure pour l'image du Supervisor Engine, et dans le logiciel Cisco IOS version 12.1(6)E1 pour l'image MSFC2.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
05-Jun-2008 |
Première publication |