Guide de dépannage des pannes de chemin de données de structure de pointe de la gamme ASR 9000
Contenu
Introduction
Ce document décrit les messages d'échec de chemin de données de structure de pontage vus lors du fonctionnement de la gamme Cisco Aggregation Services Router (ASR) 9000. Le message s'affiche au format suivant :
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)
Ce document est destiné à toute personne qui souhaite comprendre le message d'erreur et les actions à entreprendre si le problème est détecté.
Conditions préalables
Conditions requises
Cisco vous recommande d'avoir une connaissance approfondie de ces sujets :
- Cartes de ligne ASR 9000
- Cartes de fabric
- Processeurs de routage
- Architecture du châssis
Cependant, ce document n'exige pas que les lecteurs connaissent les détails du matériel. Les informations d'arrière-plan nécessaires sont fournies avant l'explication du message d'erreur. Ce document décrit l'erreur sur les cartes de ligne Trident et Typhoon. Voir Types de cartes de ligne de la gamme ASR 9000 pour une explication de ces termes.
Components Used
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Comment utiliser ce document
Considérez ces suggestions sur la façon d'utiliser ce document afin d'obtenir des détails essentiels et comme guide de référence dans le processus de dépannage :
- Lorsqu'il n'y a aucune urgence à la cause d'une défaillance du chemin de données du fabric de pontage, lisez toutes les sections de ce document. Ce document crée l'arrière-plan nécessaire pour isoler un composant défectueux en cas d'erreur.
- Utilisez la section FAQ si vous avez une question spécifique en tête pour laquelle une réponse rapide est nécessaire. Si la question n'est pas incluse dans la section FAQ, vérifiez si le document principal répond à la question.
- Utilisez toutes les sections de Analyser les erreurs activées afin d'isoler le problème à un composant défectueux lorsqu'un routeur rencontre une défaillance ou pour vérifier s'il s'agit d'un problème connu.
Informations générales
Un paquet peut traverser deux ou trois sauts dans la matrice de commutation en fonction du type de carte de ligne. Les cartes de ligne de génération de typhon ajoutent un élément de matrice de commutation supplémentaire, tandis que les cartes de ligne Trident commutent tout le trafic avec la matrice sur la carte processeur de routage uniquement. Ces diagrammes présentent les éléments de fabric pour ces deux types de cartes de ligne, ainsi que la connectivité de fabric à la carte de processeur de routage :
Chemin de paquet de diagnostic de fabric unique
L'application de diagnostic qui s'exécute sur le processeur de la carte processeur de routage injecte périodiquement des paquets de diagnostic destinés à chaque processeur réseau (NP). Le paquet de diagnostic est bouclé à l’intérieur du processeur réseau et réinjecté vers le processeur de la carte processeur de processeur de routage qui a fourni le paquet. Cette vérification périodique de l'état de chaque processeur réseau avec un paquet unique par processeur réseau par l'application de diagnostic sur la carte processeur de routage fournit une alerte pour toute erreur fonctionnelle sur le chemin de données pendant le fonctionnement du routeur. Il est essentiel de noter que l’application de diagnostic sur le processeur de routage actif et le processeur de routage de secours injecte périodiquement un paquet par NP et conserve un nombre de succès ou d’échecs par NP. Lorsqu'un seuil de paquets de diagnostic abandonnés est atteint, l'application déclenche une défaillance.
Vue conceptuelle du chemin de diagnostic
Avant que le document ne décrit le chemin de diagnostic des cartes de ligne Trident et Typhoon, cette section fournit un aperçu général du chemin de diagnostic du fabric à partir des cartes de processeur de routage actif et de secours vers le NP de la carte de ligne.
Chemin d'accès du paquet entre la carte processeur de routage active et la carte de ligne
Les paquets de diagnostic injectés par le processeur de route actif dans le fabric vers le processeur réseau sont traités comme des paquets de monodiffusion par le fabric de commutation. Avec les paquets de monodiffusion, la matrice de commutation choisit la liaison sortante en fonction de la charge de trafic actuelle de la liaison, ce qui aide à soumettre les paquets de diagnostic à la charge de trafic sur le routeur. Lorsqu’il existe plusieurs liaisons sortantes vers le processeur réseau, l’ASIC de la matrice de commutation choisit une liaison actuellement la moins chargée.
Ce diagramme représente le chemin de paquet de diagnostic provenant du processeur de route actif.
Chemin de paquet entre la carte processeur de routage de secours et la carte de ligne
Les paquets de diagnostic injectés par le processeur de route de secours dans le fabric vers le processeur réseau sont traités comme des paquets de multidiffusion par le fabric de commutation. Bien qu'il s'agisse d'un paquet de multidiffusion, il n'y a pas de réplication dans le fabric. Chaque paquet de diagnostic provenant du processeur de route de secours n’atteint toujours qu’un seul processeur réseau à la fois. Le paquet de réponse de la NP vers le processeur de routage est également un paquet de multidiffusion sur le fabric sans réplication. Par conséquent, l’application de diagnostic sur le processeur de route de secours reçoit un paquet de réponse unique des NP, un paquet à la fois. L'application de diagnostic suit chaque NP du système, car elle injecte un paquet par NP et attend des réponses de chaque NP, un paquet à la fois. Avec un paquet de multidiffusion, le fabric de commutation choisit la liaison sortante en fonction d'une valeur de champ dans l'en-tête de paquet, ce qui permet d'injecter des paquets de diagnostic sur chaque liaison de fabric entre la carte processeur de routage et la carte de ligne. Le processeur de routage de secours effectue le suivi de l'intégrité NP sur chaque liaison de fabric qui se connecte entre la carte processeur de routage et le logement de la carte de ligne.
Le schéma précédent illustre le chemin de paquet de diagnostic provenant du processeur de route de secours. Notez que, contrairement au cas du processeur de routage actif, toutes les liaisons qui connectent la carte de ligne au XBAR sur le processeur de routage sont exercées. Les paquets de réponse du processeur réseau prennent la même liaison de fabric que celle utilisée par le paquet dans le processeur de routage vers la direction de la carte de ligne. Ce test garantit que toutes les liaisons qui connectent le processeur de routage de secours à la carte de ligne sont surveillées en continu.
Chemin d'accès du paquet de diagnostic de fabric Punt sur la carte de ligne Trident-Based
Ce diagramme représente les paquets de diagnostic provenant du processeur de routage destinés à un processeur réseau qui est bouclé vers le processeur de routage. Il est important de noter les liaisons de chemin de données et les circuits ASIC communs à tous les NP, ainsi que les liaisons et les composants spécifiques à un sous-ensemble de NP. Par exemple, le pont ASIC 0 (B0) est commun à NP0 et NP1, alors que FIA0 est commun à tous les NP. À l'extrémité du processeur de routage, toutes les liaisons, tous les circuits ASIC de chemin de données et le tableau de portes programmables sur site (FPGA) sont communs à toutes les cartes de ligne, et donc à tous les NP d'un châssis.
Chemin d'accès du paquet de diagnostic de fabric Punt sur la carte de ligne basée sur un typhon
Ce diagramme représente les paquets de diagnostic provenant de la carte de processeur de routage destinés à un processeur réseau qui est bouclé vers le processeur de routage. Il est important de noter les liaisons de chemin de données et les circuits ASIC communs à tous les NP, ainsi que les liaisons et les composants spécifiques à un sous-ensemble de NP. Par exemple, FIA0 est commun à NP0 et NP1. À l'extrémité de la carte processeur de routage, toutes les liaisons, tous les circuits ASIC de chemin de données et le FGPA sont communs à toutes les cartes de ligne, et donc à tous les NP d'un châssis.
Chemin de paquet de diagnostic de fabric unique sur la carte de ligne Tomahawk, Lightspeed et LightspeedPlus
Sur les cartes de ligne Tomahawk il y a une connectivité 1:1 entre la FIA et le NP.
Sur les cartes de ligne Lightspeed et LightspeedPlus, la FIA est intégrée dans la puce NP.
Les sections suivantes tentent de représenter le chemin du paquet vers chaque NP. Ceci est nécessaire pour comprendre le message d'erreur de chemin de données de la structure de pontage, ainsi que pour localiser le point d'échec.
Signalement des alarmes et des défaillances du diagnostic du fabric de pointe
L'échec d'obtention des réponses d'un NP dans un routeur ASR 9000 génère une alarme. La décision de déclencher une alarme par l'application de diagnostic en ligne qui s'exécute sur le processeur de routage se produit en cas de trois défaillances consécutives. L'application de diagnostic gère une fenêtre de défaillance de trois paquets pour chaque NP. Le processeur de routage actif et le processeur de routage de secours diagnostiquent indépendamment et en parallèle. Le processeur de routage actif, le processeur de routage de secours ou les deux cartes de processeur de routage peuvent signaler l'erreur. L’emplacement de la panne et de la perte de paquets détermine le processeur de routage qui signale l’alarme.
La fréquence par défaut du paquet de diagnostic vers chaque NP est d’un paquet par 60 secondes ou d’un paquet par minute.
Voici le format du message d'alarme :
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)
Le message doit être lu comme un échec d'accès à NP 1, 2, 3, 4, 5, 6 et 7 sur la carte de ligne 0/7/cpu0 à partir du processeur de routage 0/rsp0/cpu0.
À partir de la liste des tests de diagnostic en ligne, vous pouvez voir les attributs du test de bouclage de structure de raccordement avec cette commande :
RP/0/RSP0/CPU0:iox(admin)#show diagnostic content location 0/RSP0/CPU0
RP 0/RSP0/CPU0:
Diagnostics test suite attributes:
M/C/* - Minimal bootup level test / Complete bootup level test / NA
B/O/* - Basic ondemand test / not Ondemand test / NA
P/V/* - Per port test / Per device test / NA
D/N/* - Disruptive test / Non-disruptive test / NA
S/* - Only applicable to standby unit / NA
X/* - Not a health monitoring test / NA
F/* - Fixed monitoring interval test / NA
E/* - Always enabled monitoring test / NA
A/I - Monitoring is active / Monitoring is inactive
Test Interval Thre-
ID Test Name Attributes (day hh:mm:ss.ms shold)
==== ================================== ============ ================= =====
1) PuntFPGAScratchRegister ---------- *B*N****A 000 00:01:00.000 1
2) FIAScratchRegister --------------- *B*N****A 000 00:01:00.000 1
3) ClkCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
4) IntCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
5) CPUCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
6) FabSwitchIdRegister -------------- *B*N****A 000 00:01:00.000 1
7) EccSbeTest ----------------------- *B*N****I 000 00:01:00.000 3
8) SrspStandbyEobcHeartbeat --------- *B*NS***A 000 00:00:05.000 3
9) SrspActiveEobcHeartbeat ---------- *B*NS***A 000 00:00:05.000 3
10) FabricLoopback ------------------- MB*N****A 000 00:01:00.000 3
11) PuntFabricDataPath --------------- *B*N****A 000 00:01:00.000 3
12) FPDimageVerify ------------------- *B*N****I 001 00:00:00.000 1
RP/0/RSP0/CPU0:ios(admin)#
La sortie montre que la fréquence de test PuntFabricDataPath est d'un paquet par minute et que le seuil de défaillance est de trois, ce qui implique que la perte de trois paquets consécutifs n'est pas tolérée et donne lieu à une alarme. Les attributs de test affichés sont des valeurs par défaut. Afin de modifier les valeurs par défaut, entrez les commandes diagnostic monitor interval et diagnostic monitor threshold en mode de configuration d'administration.
Chemin d'accès du paquet de diagnostic de la carte de ligne Trident
Échec du diagnostic NP0
Chemin de diagnostic du fabric
Ce schéma représente le chemin de paquet entre le processeur du processeur de routage et la carte de ligne NP0. La liaison qui connecte B0 et NP0 est la seule liaison spécifique à NP0. Toutes les autres liaisons se trouvent dans le chemin commun.
Notez le chemin de paquet du processeur de routage vers NP0. Bien qu’il existe quatre liaisons à utiliser pour les paquets destinés à NP0 à partir du processeur de routage, la première liaison entre le processeur de routage et le logement de la carte de ligne est utilisée pour le paquet du processeur de routage vers la carte de ligne. Le paquet retourné de NP0 peut être renvoyé au processeur de routage actif via l'un des deux chemins de liaison de fabric entre le logement de carte de ligne et le processeur de routage actif. Le choix de l'une des deux liaisons à utiliser dépend de la charge de liaison à ce moment. Le paquet de réponse de NP0 vers le processeur de route de secours utilise les deux liaisons, mais une liaison à la fois. Le choix du lien est basé sur le champ d'en-tête que l'application de diagnostic remplit.
Analyse des défaillances de diagnostic NP0
Scénario de défaillance unique
Si une seule alarme de défaillance de chemin de données de matrice de pontage PFM (Platform Fault Manager) avec seulement NP0 dans le message de défaillance est détectée, la défaillance se trouve uniquement sur le chemin de matrice qui connecte le processeur de routage et la carte de ligne NP0. C'est une seule faute. Si la défaillance est détectée sur plusieurs NP, reportez-vous à la section Multiple Fault Scenario.
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 0)
Comme illustré dans le schéma de chemin de données précédent, la défaillance doit se trouver à un ou plusieurs de ces emplacements :
- Liaison reliant NP0 et B0
- Files d’attente B0 internes dirigées vers NP0
- NP0 interne
Scénario de pannes multiples
Plusieurs pannes NP
Lorsque d'autres pannes sont observées sur NP0 ou que l'erreur PUNT_FABRIC_DATA_PATH_FAILED est également signalée par d'autres pannes sur la même carte de ligne, l'isolation des pannes est effectuée en corrélant toutes les pannes. Par exemple, si la défaillance PUNT_FABRIC_DATA_PATH_FAILED et la défaillance LC_NP_LOOPBACK_FAILED se produisent toutes deux sur NP0, le processeur réseau a arrêté le traitement des paquets. Référez-vous à la section Chemin de diagnostic de boucle NP afin de comprendre la défaillance de bouclage. Ceci pourrait être une indication précoce d’une défaillance critique à l’intérieur de NP0. Cependant, si une seule des deux défaillances se produit, la défaillance est localisée soit sur le chemin de données de la matrice de raccordement, soit sur le processeur de la carte de ligne sur le chemin NP.
Si plusieurs NP d'une carte de ligne présentent une erreur de chemin de données de structure de raccordement, vous devez remonter le chemin d'arborescence des liaisons de fabric afin d'isoler un composant défectueux. Par exemple, si NP0 et NP1 ont tous deux une défaillance, la défaillance doit être dans B0 ou la liaison qui connecte B0 et FIA0. Il est moins probable que NP0 et NP1 rencontrent simultanément une erreur interne critique. Bien qu’il soit moins probable, il est possible que NP0 et NP1 rencontrent une erreur critique en raison du traitement incorrect d’un type particulier de paquet ou d’un paquet incorrect.
Les deux cartes de processeur de routage signalent une panne
Si les cartes de processeur de routage actif et de secours signalent une défaillance à un ou plusieurs NP sur une carte de ligne, vérifiez toutes les liaisons et tous les composants communs sur le chemin de données entre les NP affectés et les deux cartes de processeur de routage.
Échec du diagnostic NP1
Ce schéma représente le chemin de paquet entre le processeur de la carte processeur de routage et la carte de ligne NP1. La liaison qui relie le pont ASIC 0 (B0) et le port NP1 est la seule liaison spécifique à NP1. Toutes les autres liaisons se trouvent dans le chemin commun.
Notez le chemin du paquet de la carte processeur de routage vers NP1. Bien qu’il existe quatre liaisons à utiliser pour les paquets destinés à NP0 à partir du processeur de routage, la première liaison entre le processeur de routage et le logement de la carte de ligne est utilisée pour le paquet du processeur de routage vers la carte de ligne. Le paquet retourné de NP1 peut être renvoyé au processeur de routage actif via l'un des deux chemins de liaison de fabric entre le logement de carte de ligne et le processeur de routage actif. Le choix de l'une des deux liaisons à utiliser dépend de la charge de liaison à ce moment. Le paquet de réponse de NP1 vers le processeur de route de secours utilise les deux liaisons, mais une liaison à la fois. Le choix du lien est basé sur le champ d'en-tête que l'application de diagnostic remplit.
Chemin de diagnostic du fabric
Analyse des défaillances de diagnostic NP1
Reportez-vous à la section Analyse des défaillances de diagnostic NP0, mais appliquez le même raisonnement pour NP1 (au lieu de NP0).
Échec du diagnostic NP2
Ce schéma représente le chemin de paquet entre le processeur de la carte processeur de routage et la carte de ligne NP2. La liaison qui connecte B1 et NP2 est la seule liaison spécifique à NP2. Toutes les autres liaisons se trouvent dans le chemin commun.
Notez le chemin du paquet de la carte processeur de routage vers NP2. Bien qu’il existe quatre liaisons à utiliser pour les paquets destinés à NP2 à partir du processeur de routage, la première liaison entre le processeur de routage et le logement de la carte de ligne est utilisée pour le paquet du processeur de routage vers la carte de ligne. Le paquet retourné de NP2 peut être renvoyé au processeur de routage actif via l'un des deux chemins de liaison de fabric entre le logement de carte de ligne et le processeur de routage actif. Le choix de l'une des deux liaisons à utiliser dépend de la charge de liaison à ce moment. Le paquet de réponse de NP2 vers le processeur de route de secours utilise les deux liaisons, mais une liaison à la fois. Le choix du lien est basé sur le champ d'en-tête que l'application de diagnostic remplit.
Chemin de diagnostic du fabric
Analyse des défaillances de diagnostic NP2
Reportez-vous à la section Analyse des défaillances de diagnostic NP0, mais appliquez le même raisonnement pour NP3 (au lieu de NP0).
Échec du diagnostic NP3
Ce schéma représente le chemin de paquet entre le processeur de la carte processeur de routage et la carte de ligne NP3. La liaison qui relie le pont ASIC 1 (B1) et le NP3 est la seule liaison spécifique au NP3. Toutes les autres liaisons se trouvent dans le chemin commun.
Notez le chemin du paquet de la carte processeur de routage vers NP3. Bien qu’il existe quatre liaisons à utiliser pour les paquets destinés à NP3 à partir du processeur de routage, la première liaison entre le processeur de routage et le logement de la carte de ligne est utilisée pour le paquet du processeur de routage vers la carte de ligne. Le paquet retourné de NP3 peut être renvoyé au processeur de routage actif via l'un des deux chemins de liaison de fabric entre le logement de carte de ligne et le processeur de routage actif. Le choix de l'une des deux liaisons à utiliser dépend de la charge de liaison à ce moment. Le paquet de réponse de NP3 vers le processeur de route de secours utilise les deux liaisons, mais une liaison à la fois. Le choix du lien est basé sur le champ d'en-tête que l'application de diagnostic remplit.
Chemin de diagnostic du fabric
Analyse des défaillances de diagnostic NP3
Reportez-vous à la section Analyse des défaillances de diagnostic NP0, mais appliquez le même raisonnement pour NP3 (au lieu de NP0).
Chemin de paquet de diagnostic de carte de ligne basée sur un typhon
Cette section fournit deux exemples afin d'établir l'arrière-plan pour les paquets de raccordement de fabric avec des cartes de ligne basées sur le typhon. Le premier exemple utilise NP1 et le second, NP3. La description et l'analyse peuvent être étendues à d'autres NP sur n'importe quelle carte de ligne Typhoon.
Panne de diagnostic du typhon NP1
Le schéma suivant illustre le chemin de paquet entre le processeur de la carte processeur de routage et la carte de ligne NP1. La liaison qui connecte FIA0 et NP1 est la seule liaison spécifique au chemin NP1. Toutes les autres liaisons entre le logement de carte de ligne et le logement de carte de processeur de routage se trouvent dans le chemin commun. Les liaisons qui relient l'ASIC XBAR de la carte de ligne aux FIA de la carte de ligne sont spécifiques à un sous-ensemble de NP. Par exemple, les deux liaisons entre FIA0 et l'ASIC XBAR de la matrice locale sur la carte de ligne sont utilisées pour le trafic vers NP1.
Notez le chemin du paquet de la carte processeur de routage vers NP1. Bien qu’il existe huit liaisons à utiliser pour les paquets destinés à NP1 à partir de la carte processeur de routage, un seul chemin entre la carte processeur de routage et le logement de la carte de ligne est utilisé. Le paquet retourné de NP1 peut être renvoyé à la carte processeur de routage sur huit chemins de liaison de fabric entre le logement de la carte de ligne et le processeur de routage. Chacune de ces huit liaisons s’exerce une par une lorsque le paquet de diagnostic est renvoyé au processeur de la carte de processeur de routage.
Chemin de diagnostic du fabric
Panne de diagnostic du typhon NP3
Ce schéma représente le chemin de paquet entre le processeur de la carte processeur de routage et la carte de ligne NP3. La liaison qui relie FIA1 et NP3 est la seule liaison spécifique au chemin NP3. Toutes les autres liaisons entre le logement de carte de ligne et le logement de carte de processeur de routage se trouvent dans le chemin commun. Les liaisons qui relient l'ASIC XBAR de la carte de ligne aux FIA de la carte de ligne sont spécifiques à un sous-ensemble de NP. Par exemple, les deux liaisons entre FIA1 et l'ASIC XBAR de la matrice locale sur la carte de ligne sont utilisées pour le trafic vers NP3.
Notez le chemin du paquet de la carte processeur de routage vers NP3. Bien qu’il existe huit liaisons à utiliser pour les paquets destinés à NP3 à partir de la carte processeur de routage, un seul chemin entre la carte processeur de routage et le logement de la carte de ligne est utilisé. Le paquet retourné de NP1 peut être renvoyé à la carte processeur de routage sur huit chemins de liaison de fabric entre le logement de la carte de ligne et le processeur de routage. Chacune de ces huit liaisons s’exerce une par une lorsque le paquet de diagnostic est renvoyé au processeur de la carte de processeur de routage.
Chemin de diagnostic du fabric
Chemin de paquet de diagnostic de carte de ligne Tomahawk
En raison de la connectivité 1:1 entre la FIA et NP, le seul trafic qui traverse FIA0 est à destination/en provenance de NP0.
Chemin de paquet de diagnostic de carte de ligne Lightspeed et LightspeedPlus
Comme la FIA est intégrée dans la puce NP, le seul trafic qui traverse FIA0 est de/vers NP0.
Analyser les erreurs
Cette section classe les pannes en cas de pannes difficiles et transitoires et répertorie les étapes utilisées pour identifier si une pannes est une pannes difficile ou transitoire. Une fois le type de panne déterminé, le document spécifie les commandes qui peuvent être exécutées sur le routeur afin de comprendre la panne et les mesures correctives nécessaires.
Défaillance transitoire
Si un message PFM défini est suivi d'un message PFM effacé, une erreur s'est produite et le routeur a corrigé la défaillance elle-même. Des défaillances transitoires peuvent survenir en raison de conditions environnementales et de défaillances récupérables dans les composants matériels. Parfois, il peut être difficile d'associer des pannes transitoires à un événement particulier.
Un exemple de défaillance de structure transitoire est présenté ici pour plus de clarté :
RP/0/RSP0/CPU0:Feb 5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)
RP/0/RSP0/CPU0:Feb 5 05:05:46.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)
Actions correctives en cas de panne transitoire
L'approche suggérée pour les erreurs transitoires consiste à ne surveiller que la survenance de telles erreurs. Si une défaillance transitoire se produit plusieurs fois, traitez-la comme une défaillance matérielle et utilisez les recommandations et les étapes afin d'analyser les erreurs décrites dans la section suivante.
Défaillance matérielle
Si un message PFM défini n'est pas suivi d'un message PFM clair, une erreur s'est produite et le routeur n'a pas corrigé la défaillance elle-même par le code de gestion des pannes, ou la nature de la défaillance matérielle n'est pas récupérable. Des défaillances matérielles peuvent survenir en raison de conditions environnementales et de défaillances irrécupérables dans les composants matériels. L'approche suggérée pour les pannes dures consiste à utiliser les directives mentionnées dans la section Analyser les pannes dures.
Pour plus de clarté, vous trouverez ici un exemple de défaillance de structure dure. Pour cet exemple de message, il n'existe pas de message PFM clair correspondant.
RP/0/RSP0/CPU0:Feb 5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)
Actions correctives en cas de panne matérielle
Dans un scénario de défaillance matérielle, collectez toutes les commandes mentionnées dans la section Données à collecter avant la création de la demande de service et ouvrez une demande de service. Dans les cas urgents, une fois que vous avez collecté toutes les sorties de la commande de dépannage, lancez une carte de processeur de routage ou un rechargement de la carte de ligne en fonction de l'isolation des pannes. Après le rechargement, si l'erreur n'est pas récupérée, lancez une autorisation de retour de matériel (RMA).
Analyser les erreurs transitoires
Complétez ces étapes afin d'analyser les pannes transitoires.
- Entrez la commande show logging | inc “ commande PUNT_FABRIC_DATA_PATH » afin de détecter si l'erreur s'est produite une ou plusieurs fois.
- Entrez la commande show pfm location all afin de déterminer l'état actuel (SET ou CLEAR). L'erreur est-elle en cours ou effacée ? Si l'état de l'erreur change entre SET et CLEAR, une ou plusieurs erreurs dans le chemin de données du fabric se produisent à plusieurs reprises et sont corrigées soit par le logiciel, soit par le matériel.
- Provisionnez des déroutements SNMP (Simple Network Management Protocol) ou exécutez un script qui collecte toutes les sorties de commande show pfm location, et recherche périodiquement la chaîne d'erreur afin de surveiller l'occurrence future de l'erreur (lorsque le dernier état de l'erreur est CLEAR, et qu'aucun nouveau défaut ne se produit).
Commandes à utiliser
Entrez ces commandes afin d'analyser les pannes transitoires :
- show logging | inc “ ” PUNT_FABRIC_DATA_PATH
- show pfm location all
Analyser les défaillances matérielles
Si vous affichez les liaisons de chemin de données du fabric sur une carte de ligne en tant qu'arborescence (où les détails sont décrits dans la section Informations d'arrière-plan), vous devez déduire - en fonction du point de défaillance - si un ou plusieurs NP sont inaccessibles. Lorsque plusieurs pannes surviennent sur plusieurs NP, utilisez les commandes répertoriées dans cette section afin d'analyser les pannes.
Commandes à utiliser
Entrez ces commandes afin d'analyser les pannes dures :
- show logging | inc “ ” PUNT_FABRIC_DATA_PATH
Le résultat peut contenir un ou plusieurs NP (Exemple : NP2, NP3). - show controller fabric fia link-status location <lc>
Puisque le NP2 et le NP3 (dans la section Typhoon NP3 Diagnostic Failure) reçoivent et envoient par le biais d'une seule FIA, il est raisonnable de déduire que la faute est dans une FIA associée sur le chemin. - show controller fabric cross-bar link-status instance <0 et 1> emplacement <LC ou RSP>
Si tous les NP de la carte de ligne ne sont pas accessibles pour l'application de diagnostic, il est raisonnable de déduire que les liaisons qui connectent le logement de la carte de ligne à la carte de processeur de routage peuvent présenter une défaillance sur l'un des ASIC qui transfère le trafic entre la carte de processeur de routage et la carte de ligne.
show controller fabric cross-bar link-status instance 0 emplacement <lc>
show controller fabric cross-bar link-status instance 0 emplacement 0/rsp0/cpu0
show controller fabric cross-bar link-status instance 1 emplacement 0/rsp0/cpu0
show controller fabric cross-bar link-status instance 0 emplacement 0/rsp1/cpu0
show controller fabric cross-bar link-status instance 1 emplacement 0/rsp1/cpu0 - show controller fabric fia link-status location 0/rsp*/cpu0
show controller fabric fia link-status location 0/rsp0/cpu0
show controller fabric fia link-status location 0/rsp1/cpu0 - show controller fabric fia bridge sync-status location 0/rsp*/cpu0
show controller fabric fia bridge sync-status location 0/rsp0/cpu0
show controller fabric fia bridge sync-status location 0/rsp1/cpu0
show tech fabric terminal
Échecs passés
Historiquement, 99 % des pannes sont récupérables, et dans la plupart des cas, l'action de récupération initiée par le logiciel corrige les pannes. Cependant, dans de très rares cas, des erreurs irrécupérables sont détectées qui ne peuvent être corrigées qu'avec la RMA des cartes.
Les sections suivantes identifient certaines défaillances passées rencontrées afin de servir de guide si des erreurs similaires sont observées.
Erreur transitoire due à la sursouscription NP
Ces messages s'affichent si l'erreur est due à une sursouscription NP.
RP/0/RP1/CPU0:Jun 26 13:08:28.669 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0, 0)
RP/0/RP1/CPU0:Jun 26 13:09:28.692 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0,0)
Les erreurs transitoires peuvent être plus difficiles à confirmer. Une méthode pour déterminer si un NP est actuellement surabonné ou a déjà été surabonné dans le passé consiste à vérifier qu'il y a un certain type de chute à l'intérieur du NP et pour les chutes de queue dans la FIA. L'accès IFDMA (Front Direct Memory Access) en entrée tombe à l'intérieur du processeur réseau lorsque le processeur réseau est surabonné et ne peut pas suivre le trafic entrant. La queue de FIA tombe lorsqu'un NP de sortie affirme le contrôle de flux (demande à la carte de ligne d'entrée d'envoyer moins de trafic). Dans le scénario de contrôle de flux, la FIA d'entrée a des gouttes de queue.
Voici un exemple :
RP/0/RSP0/CPU0:RP/0/RSP0/CPU0:ASR9006-C#show controllers np counters all
Wed Feb 19 13:10:11.848 EST
Node: 0/1/CPU0:
----------------------------------------------------------------
Show global stats counters for NP0, revision v3
Read 93 non-zero NP counters:
Offset Counter FrameValue Rate (pps)
-----------------------------------------------------------------------
22 PARSE_ENET_RECEIVE_CNT 46913080435 118335
23 PARSE_FABRIC_RECEIVE_CNT 40175773071 5
24 PARSE_LOOPBACK_RECEIVE_CNT 5198971143966 0
<SNIP>
Show special stats counters for NP0, revision v3
Offset Counter CounterValue
----------------------------------------------------------------------------
524032 IFDMA discard stats counters 0 8008746088 0 <<<<<
Voici un exemple :
RP/0/RSP0/CPU0:ASR9006-C#show controllers fabric fia drops ingress location 0/1/cPU0
Wed Feb 19 13:37:27.159 EST
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 0
Tail Drop-0 0 <<<<<<<
Tail Drop-1 0 <<<<<<<
Tail Drop-2 0 <<<<<<<
Tail Drop-3 0 <<<<<<<
Tail Drop DE-0 0
Tail Drop DE-1 0
Tail Drop DE-2 0
Tail Drop DE-3 0
Hard Drop-0 0
Hard Drop-1 0
Hard Drop-2 0
Hard Drop-3 0
Hard Drop DE-0 0
Hard Drop DE-1 0
Hard Drop DE-2 0
Hard Drop DE-3 0
WRED Drop-0 0
WRED Drop-1 0
WRED Drop-2 0
WRED Drop-3 0
WRED Drop DE-0 0
WRED Drop DE-1 0
WRED Drop DE-2 0
WRED Drop DE-3 0
Mc No Rep 0
Défaillance matérielle due à NP Fast Reset
Lorsque PUNT_FABRIC_DATA_PATH_FAILED se produit et que l'échec est dû à une réinitialisation rapide NP, les journaux similaires à ceux répertoriés ici apparaissent pour une carte de ligne basée sur un typhon. Le mécanisme de surveillance de l'état de santé est disponible sur les cartes de ligne Typhoon, mais pas sur les cartes de ligne Trident.
LC/0/2/CPU0:Aug 26 12:09:15.784 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702
LC/0/2/CPU0:Aug 26 12:09:18.798 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702
LC/0/2/CPU0:Aug 26 12:09:21.812 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702
LC/0/2/CPU0:Aug 26 12:09:24.815 CEST:
prm_server_ty[303]: NP-DIAG health monitoring failure on NP0
LC/0/2/CPU0:Aug 26 12:09:24.815 CEST: pfm_node_lc[291]:
%PLATFORM-NP-0-NP_DIAG : Set|prm_server_ty[172112]|
Network Processor Unit(0x1008000)| NP diagnostics warning on NP0.
LC/0/2/CPU0:Aug 26 12:09:40.492 CEST: prm_server_ty[303]:
Starting fast reset for NP 0 LC/0/2/CPU0:Aug 26 12:09:40.524 CEST:
prm_server_ty[303]: Fast Reset NP0 - successful auto-recovery of NP
Pour les cartes de ligne Trident, ce journal est affiché avec une réinitialisation rapide d'un NP :
LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3
Échecs entre les processeurs de routage RSP440 et les cartes de ligne Typhoon
Cisco a résolu un problème dans lequel les liaisons de fabric entre le processeur de commutation de routage (RSP) 440 et les cartes de ligne basées sur un typhon sur le fond de panier sont rarement reformées. Les liaisons de fabric sont reentraînées, car la puissance du signal n'est pas optimale. Ce problème est présent dans les versions de base du logiciel Cisco IOS®-XR 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1 et 4.3.2. Une mise à jour de maintenance logicielle (SMU) pour chacune de ces versions est affichée sur Cisco Connection Online et suivie avec l'ID de bogue Cisco CSCuj10837 et l'ID de bogue Cisco CSCul39674.
Lorsque ce problème survient sur le routeur, l’un des scénarios suivants peut se produire :
- Le lien s'effondre et s'affiche. (transitoire)
- La liaison est définitivement arrêtée.
ID de bogue Cisco CSCuj10837 - Retrait de fabric entre RSP et LC (direction TX)
Afin de confirmer, collectez les sorties ltrace de LC et des deux RSP (show controller fabric cross-bar ltrace location <>) et vérifiez si cette sortie est vue dans les traces RSP :
SMU est déjà disponible
Voici un exemple :
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
Oct 1 08:22:58.999 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (1,1,0),(2,1,0),1.
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1 init xbar_trigger_link_retrain:
destslot:0 fmlgrp:3 rc:0
Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1 detail xbar_pfm_alarm_callback:
xbar_trigger_link_retrain(): (2,0,7) initiated
Oct 1 08:22:58.969 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (2,1,0),(2,2,0),0.
Le terme direction TX fait référence à la direction du point de vue de l'interface de matrice de barres transversales des RSP vers une interface de matrice sur une carte de ligne Typhoon.
L'ID de bogue Cisco CSCuj10837 se caractérise par la détection par la carte de ligne Typhoon d'un problème sur la liaison RX à partir du RSP et le lancement d'une nouvelle liaison. Chaque côté (LC ou RSP) peut déclencher l'événement de formation. Dans le cas de l'ID de bogue Cisco CSCuj10837, le LC initie la retrain et peut être détecté par l'init xbar_trigger_link_retrain : dans les traces sur le LC.
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1 init xbar_trigger_link_retrain: destslot:
0 fmlgrp:3 rc:0
Lorsque le LC initie la retrain, le RSP signale un lien rcvd link_retrain dans la sortie de suivi.
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
Oct 1 08:22:58.999 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (1,1,0),(2,1,0),1.
ID de bogue Cisco CSCul39674 - Retrait de fabric entre RSP et LC (direction RX)
Afin de confirmer, collectez les sorties ltrace de la carte de ligne et des deux RSP (show controller fabric cross-bar ltrace location <>) et vérifiez si cette sortie est vue dans les Ltrace RSP :
Voici un exemple :
RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
Jan 8 17:28:39.215 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (0,1,0),(5,1,1),0.
RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 init xbar_trigger_link_retrain:
destslot:4 fmlgrp:3 rc:0
Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 detail xbar_pfm_alarm_callback:
xbar_trigger_link_retrain(): (5,1,11) initiated
Jan 8 17:28:39.256 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (5,1,1),(0,1,0),0.
Le terme direction RX fait référence à la direction du point de vue de l'interface de matrice de barres croisées RSP à partir d'une interface de matrice de matrice sur une carte de ligne Typhoon.
L'ID de bogue Cisco CSCul39674 se caractérise par la détection par le RSP d'un problème sur la liaison RX à partir de la carte de ligne Typhoon et le lancement d'une nouvelle liaison. Chaque côté (LC ou RSP) peut déclencher l'événement de formation. Dans le cas de l'ID de bogue Cisco CSCul39674, le RSP initie la retrain et peut être détecté par l'init xbar_trigger_link_retrain : dans les traces sur le RSP.
RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 init xbar_trigger_link_retrain: destslot:4 fmlgrp:
3 rc:0
Lorsque le RSP initie la retrain, le LC signale un événement rcvd link_retrain dans la sortie de suivi.
RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
Jan 8 17:28:39.215 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (0,1,0),(5,1,1),0.
Différences de formation de fabric dans les versions 4.3.2 et ultérieures
Des travaux importants ont été effectués afin de réduire le temps nécessaire à la formation d'une liaison de fabric dans IOS-XR version 4.3.2 et ultérieures. La remise en état du fabric se produit maintenant en moins d'une seconde et est imperceptible aux flux de trafic. Dans la version 4.3.2, seuls ces messages syslog sont visibles lorsqu'une nouvelle formation de liaison de fabric s'est produite.
%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT : Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1
Défaillance due au débordement FIFO ASIC du fabric
Cisco a résolu un problème dans lequel l'ASIC de fabric (FIA) pourrait être réinitialisé en raison d'une condition de débordement FIFO (First In First Out) irrécupérable. Ceci est résolu avec l'ID de bogue Cisco CSCul66510. Ce problème n'affecte que les cartes de ligne Trident et n'est rencontré que dans de rares cas avec un encombrement important du chemin d'entrée. Si ce problème se produit, ce message syslog s'affiche avant que la carte de ligne ne soit réinitialisée pour être restaurée de la condition.
RP/0/RSP0/CPU0:asr9k-2#show log
LC/0/3/CPU0:Nov 13 03:46:38.860 utc: pfm_node_lc[284]:
%FABRIC-FIA-0-ASIC_FATAL_FAULT Set|fialc[159814]
|Fabric Interface(0x1014000)|Fabric interface asic ASIC1 encountered fatal
fault 0x1b - OC_DF_INT_PROT_ERR_0
LC/0/3/CPU0:Nov 13 03:46:38.863 utc: pfm_node_lc[284]:
%PLATFORM-PFM-0-CARD_RESET_REQ : pfm_dev_sm_perform_recovery_action,
Card reset requested by: Process ID:159814 (fialc), Fault Sev: 0, Target node:
0/3/CPU0, CompId: 0x10, Device Handle: 0x1014000, CondID: 2545, Fault Reason:
Fabric interface asic ASIC1 encountered fatal fault 0x1b - OC_DF_INT_PROT_ERR_0
Échec dû à une accumulation de files d'attente de sortie virtuelles (VOQ) lourdes suite à la congestion du fabric
Cisco a résolu un problème dans lequel un encombrement important prolongé pourrait entraîner l'épuisement des ressources du fabric et la perte de trafic. La perte de trafic peut même se produire sur des flux non liés. Ce problème est résolu avec l'ID de bogue Cisco CSCug90300 et est résolu dans IOS-XR version 4.3.2 et ultérieure. Le correctif est également fourni dans la version 4.2.3 CSMU#3, SMU CSCui33805 . Ce problème rare peut être rencontré sur les cartes de ligne Trident ou Typhoon.
Commandes pertinentes
Vous devez rassembler les commandes suivantes :
- show tech-support fabric
- show controller fabric fia bridge flow-control location <LC> <=== Obtenir cette sortie pour tous les LC
- show controllers fabric fia q-deep location <LC>
Voici quelques exemples de résultats :
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia q-depth location 0/6/CPU0
Sun Dec 29 23:10:56.307 UTC
********** FIA-0 **********
Category: q_stats_a-0
Voq ddr pri pktcnt
11 0 2 7
********** FIA-0 **********
Category: q_stats_b-0
Voq ddr pri pktcnt
********** FIA-1 **********
Category: q_stats_a-1
Voq ddr pri pktcnt
11 0 0 2491
11 0 2 5701
********** FIA-1 **********
Category: q_stats_b-1
Voq ddr pri pktcnt
RP/0/RSP0/CPU0:asr9k-1#
RP/0/RSP0/CPU0:asr9k-1#show controllers pm location 0/1/CPU0 | in "switch|if"
Sun Dec 29 23:37:05.621 UTC
Ifname(2): TenGigE0_1_0_2, ifh: 0x2000200 : <==Corresponding interface ten 0/1/0/2
iftype 0x1e
switch_fabric_port 0xb <==== VQI 11
parent_ifh 0x0
parent_bundle_ifh 0x80009e0
RP/0/RSP0/CPU0:asr9k-1#
Dans des conditions normales, il est très peu probable qu'une VOQ avec des paquets mis en file d'attente s'affiche. Cette commande est un instantané rapide en temps réel des files d'attente FIA. Il est courant que cette commande n'affiche aucun paquet mis en file d'attente.
Impact du trafic dû à des erreurs logicielles Bridge/FPGA sur les cartes de ligne Trident
Les erreurs logicielles sont des erreurs non permanentes qui font que l'ordinateur d'état n'est pas synchronisé. Ces paquets sont considérés comme des paquets CRC (Cyclic Redundancy Check), FCS (Frame Check Sequence) ou des paquets en erreur du côté fabric du processeur réseau ou du côté entrée de la FIA.
Voici quelques exemples de ce problème :
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia drops ingress location 0/3/CPU0
Fri Dec 6 19:50:42.135 UTC
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 32609856 <=== Errors
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia errors ingress location 0/3/CPU0
Fri Dec 6 19:50:48.934 UTC
********** FIA-0 **********
Category: in_error-0
DDR Rx CRC-0 0
DDR Rx CRC-1 32616455 <=== Errors
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/0/CPU0
Ingress Drop Stats (MC & UC combined)
**************************************
PriorityPacket Error Threshold
Direction Drops Drops
--------------------------------------------------
LP NP-3 to Fabric 0 0
HP NP-3 to Fabric 1750 0
RP/0/RSP1/CPU0:asr9k-1#
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/6/CPU0
Sat Jan 4 06:33:41.392 CST
********** FIA-0 **********
Category: bridge_in-0
UcH Fr Np-0 16867506
UcH Fr Np-1 115685
UcH Fr Np-2 104891
UcH Fr Np-3 105103
UcL Fr Np-0 1482833391
UcL Fr Np-1 31852547525
UcL Fr Np-2 3038838776
UcL Fr Np-3 30863851758
McH Fr Np-0 194999
McH Fr Np-1 793098
McH Fr Np-2 345046
McH Fr Np-3 453957
McL Fr Np-0 27567869
McL Fr Np-1 12613863
McL Fr Np-2 663139
McL Fr Np-3 21276923
Hp ErrFrNp-0 0
Hp ErrFrNp-1 0
Hp ErrFrNp-2 0
Hp ErrFrNp-3 0
Lp ErrFrNp-0 0
Lp ErrFrNp-1 0
Lp ErrFrNp-2 0
Lp ErrFrNp-3 0
Hp ThrFrNp-0 0
Hp ThrFrNp-1 0
Hp ThrFrNp-2 0
Hp ThrFrNp-3 0
Lp ThrFrNp-0 0
Lp ThrFrNp-1 0
Lp ThrFrNp-2 0
Lp ThrFrNp-3 0
********** FIA-0 **********
Category: bridge_eg-0
UcH to Np-0 779765
UcH to Np-1 3744578
UcH to Np-2 946908
UcH to Np-3 9764723
UcL to Np-0 1522490680
UcL to Np-1 32717279812
UcL to Np-2 3117563988
UcL to Np-3 29201555584
UcH ErrToNp-0 0
UcH ErrToNp-1 0
UcH ErrToNp-2 129 <==============
UcH ErrToNp-3 0
UcL ErrToNp-0 0
UcL ErrToNp-1 0
UcL ErrToNp-2 90359 <==========
Commandes de collecte pour les erreurs logicielles Bridge/FPGA sur les cartes de ligne Trident
Vous devez rassembler les commandes suivantes :
- show tech-support fabric
- show tech-support np
- show controller fabric fia bridge stats location <> (obtenir plusieurs fois)
Récupération à partir des erreurs logicielles Bridge/FPGA
La méthode de récupération consiste à recharger la carte de ligne affectée.
RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload
Rapport de test de diagnostic en ligne
La commande show diagnostic result location <node> [test <test-id> detail] fournit un résumé de tous les tests et échecs de diagnostic en ligne ainsi que le dernier horodatage lorsqu'un test a réussi. L'ID de test de l'échec du chemin de données du fabric de raccordement est dix. La commande show diagnostic content location <node> répertorie tous les tests ainsi que la fréquence des paquets de test.
Le résultat du test de chemin de données du fabric de pontage sera similaire à celui de cet exemple de sortie :
RP/0/RSP0/CPU0:ios(admin)#show diagnostic result location 0/rsp0/cpu0 test 10 detail
Current bootup diagnostic level for RP 0/RSP0/CPU0: minimal
Test results: (. = Pass, F = Fail, U = Untested)
___________________________________________________________________________
10 ) FabricLoopback ------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 357
Last test execution time ----> Sat Jan 10 18:55:46 2009
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> Sat Jan 10 18:55:46 2009
Total failure count ---------> 0
Consecutive failure count ---> 0
Améliorations de la récupération automatique
Comme décrit dans l'ID de bogue Cisco CSCuc04493, il existe maintenant un moyen de faire arrêter automatiquement tous les ports associés aux erreurs PUNT_FABRIC_DATA_PATH.
La première méthode est suivie via l'ID de bogue Cisco CSCuc04493. Pour la version 4.2.3, ceci est inclus dans l'ID de bogue Cisco CSCui33805. Dans cette version, il est configuré pour arrêter automatiquement tous les ports associés aux NP affectés.
Voici un exemple qui montre comment les Syslogs apparaîtraient :
RP/0/RSP0/CPU0:Jun 10 16:11:26 BKK: pfm_node_rp[359]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|System
Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
(0/1/CPU0, 0)
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
TenGigE0/1/0/0, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface TenGigE0/1/0/0, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
TenGigE0/1/0/1, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface TenGigE0/1/0/1, changed state to Down
Le contrôleur indique que la raison de l'arrêt de l'interface est due à DATA_PATH_DOWN. Voici un exemple :
RP/0/RSP0/CPU0:ASR9006-E#sh controllers gigabitEthernet 0/0/0/13 internal
Wed Dec 18 02:42:52.221 UTC
Port Number : 13
Port Type : GE
Transport mode : LAN
BIA MAC addr : 6c9c.ed08.3cbd
Oper. MAC addr : 6c9c.ed08.3cbd
Egress MAC addr : 6c9c.ed08.3cbd
Port Available : true
Status polling is : enabled
Status events are : enabled
I/F Handle : 0x04000400
Cfg Link Enabled : tx/rx enabled
H/W Tx Enable : no
UDLF enabled : no
SFP PWR DN Reason : 0x00000000
SFP Capability : 0x00000024
MTU : 1538
H/W Speed : 1 Gbps
H/W Duplex : Full
H/W Loopback Type : None
H/W FlowCtrl type : None
H/W AutoNeg Enable: Off
H/W Link Defects : (0x00080000) DATA_PATH_DOWN <<<<<<<<<<<
Link Up : no
Link Led Status : Link down -- Red
Input good underflow : 0
Input ucast underflow : 0
Output ucast underflow : 0
Input unknown opcode underflow: 0
Pluggable Present : yes
Pluggable Type : 1000BASE-LX
Pluggable Compl. : (Service Un) - Compliant
Pluggable Type Supp.: (Service Un) - Supported
Pluggable PID Supp. : (Service Un) - Supported
Pluggable Scan Flg: false
Dans les versions 4.3.1 et ultérieures, ce comportement doit être activé. Une nouvelle commande admin config est utilisée pour cela. Comme le comportement par défaut n'est plus de désactiver les ports, il doit être configuré manuellement.
RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
Sur IOS XR 64 bits, la commande de configuration est disponible dans la machine virtuelle XR (pas dans la machine virtuelle Sysadmin) :
RP/0/RSP0/CPU0:CORE-TOP(config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
L'ID de bogue Cisco CSCui15435 corrige les erreurs logicielles qui sont visibles sur les cartes de ligne Trident, comme décrit ici. Cette méthode utilise une méthode de détection différente de la méthode de diagnostic habituelle décrite dans l'ID de bogue Cisco CSCuc04493.
Ce bogue a également introduit une nouvelle commande CLI de configuration admin :
(admin-config)#fabric fia soft-error-monitor <1|2> location
1 = shutdown the ports
2 = reload the linecard
Default behavior: no action is taken.
Lorsque cette erreur est rencontrée, ce syslog peut être observé :
RP/0/RSP0/CPU0:Apr 30 22:17:11.351 : config[65777]: %MGBL-SYS-5-CONFIG_I : Configured
from console by root
LC/0/2/CPU0:Apr 30 22:18:52.252 : pfm_node_lc[283]:
%PLATFORM-BRIDGE-1-SOFT_ERROR_ALERT_1 : Set|fialc[159814]|NPU
Crossbar Fabric Interface Bridge(0x1024000)|Soft Error Detected on Bridge instance 1
RP/0/RSP0/CPU0:Apr 30 22:21:28.747 : pfm_node_rp[348]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
(0/2/CPU0, 2) (0/2/CPU0, 3)
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINK-3-UPDOWN :
Interface TenGigE0/2/0/2, changed state to Down
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINEPROTO-5-UPDOWN :
Line protocol on Interface TenGigE0/2/0/2, changed state to Down
RP/0/RSP1/CPU0:Apr 30 22:21:35.086 : pfm_node_rp[348]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED :
Set|online_diag_rsp[237646]|System Punt/Fabric/data Path Test(0x2000004)|failure
threshold is 3, (slot, NP) failed: (0/2/CPU0, 2) (0/2/CPU0, 3)
Lorsque les ports affectés sont arrêtés, cela permet à la redondance du réseau de prendre le relais et d'éviter un blocage du trafic en noir. Pour récupérer, la carte de ligne doit être rechargée.
Foire aux questions (FAQ)
Q. La carte processeur de routage principale ou de secours envoie-t-elle les paquets de test d'activité ou de diagnostic en ligne à chaque processeur réseau du système ?
A. Oui. Les deux cartes processeur de routage envoient des paquets de diagnostic en ligne à chaque processeur réseau.
Q. Le chemin est-il le même lorsque la carte processeur de routage 1 (RSP1) est active ?
A. Le chemin de diagnostic est le même pour RSP0 ou RSP1. Le chemin dépend de l'état du RSP. Référez-vous à la section Chemin de paquet de diagnostic de fabric unique de ce document pour plus de détails.
Q. À quelle fréquence les RSP envoient-ils des paquets de diagnostic et combien de paquets de diagnostic doivent être manqués avant le déclenchement d’une alarme ?
A. Chaque RSP envoie indépendamment un paquet de diagnostic à chaque NP une fois par minute. L'un ou l'autre RSP peut déclencher une alarme si trois paquets de diagnostic ne sont pas reconnus.
Q. Comment déterminer si un NP est ou a été sursouscrit ?
A. Une façon de vérifier si un NP est actuellement surabonné ou a déjà été surabonné dans le passé est de vérifier si un certain type de chute à l'intérieur du NP et pour les chutes de queue dans la FIA. L'accès IFDMA (Front Direct Memory Access) en entrée tombe à l'intérieur du processeur réseau lorsque le processeur réseau est surabonné et ne peut pas suivre le trafic entrant. La queue de FIA tombe lorsqu'un NP de sortie affirme le contrôle de flux (demande à la carte de ligne d'entrée d'envoyer moins de trafic). Dans le scénario de contrôle de flux, la FIA d'entrée a des gouttes de queue.
Q. Comment déterminer si un processeur réseau souffre d’une défaillance nécessitant sa réinitialisation ?
A. En règle générale, une défaillance NP est effacée par une réinitialisation rapide. La raison d'une réinitialisation rapide est affichée dans les journaux.
Q. Que s'affiche-t-il si un processeur réseau présente une défaillance matérielle non récupérable ?
A. Vous voyez à la fois une défaillance du chemin de données de la structure de pontage pour ce NP et une défaillance du test de bouclage NP. Le message d'échec du test de bouclage NP est traité dans la section Annexe de ce document.
Q. Un paquet de diagnostic provenant d’une carte processeur de routage reviendra-t-il au même paquet ?
A. Puisque les paquets de diagnostic proviennent des deux cartes de processeur de routage et sont suivis sur une base de carte de processeur de routage par route, un paquet de diagnostic provenant d’une carte de processeur de routage est renvoyé en boucle vers la même carte de processeur de routage par le processeur de routage.
Q. L'ID de bogue Cisco CSCuj10837 SMU fournit une correction pour l'événement de remise en forme de liaison de fabric. Est-ce la cause et la solution de nombreux échecs de chemin de données de structure de raccordement ?
A. Oui, il sera nécessaire de charger la SMU de remplacement pour l'ID de bogue Cisco CSCul39674 afin d'éviter les événements de recyclage de liaison de fabric.
Q. Combien de temps faudra-t-il pour reformer les liaisons de tissu une fois que la décision aura été prise ?
A. La décision de se recycler est prise dès qu’une défaillance de liaison est détectée. Avant la version 4.3.2, la remise à niveau peut prendre plusieurs secondes. Après la version 4.3.2, le temps de formation a été considérablement amélioré et prend moins d'une seconde.
Q. À quel moment la décision de recycler une liaison de fabric est-elle prise ?
A. Dès que la défaillance de liaison est détectée, la décision de se former de nouveau est prise par le pilote ASIC du fabric.
Q. Est-ce seulement entre la FIA sur une carte de processeur de routage active et le fabric que vous utilisez la première liaison, et ensuite c'est la liaison la moins chargée quand il y a plusieurs liaisons disponibles ?
A. Correct. La première liaison qui se connecte à la première instance XBAR sur le processeur de routage actif est utilisée afin d'injecter du trafic dans le fabric. Le paquet de réponse du processeur réseau peut revenir à la carte processeur de routage active sur l’une des liaisons qui se connectent à la carte processeur de routage. Le choix de la liaison dépend de la charge de la liaison.
Q. Au cours de la remise en forme, tous les paquets envoyés via cette liaison de fabric sont-ils perdus ?
A. Oui, mais avec les améliorations apportées à la version 4.3.2 et ultérieures, la formation est pratiquement non détectable. Cependant, dans le code précédent, il peut falloir plusieurs secondes pour se former à nouveau, ce qui entraîne la perte de paquets pour cette période.
Q. À quelle fréquence pensez-vous voir un événement de recyclage de liaison de fabric XBAR après la mise à niveau vers une version ou une SMU avec la correction du bogue Cisco ID CSCuj10837 ?
A. Même avec le correctif pour l'ID de bogue Cisco CSCuj10837 il est toujours possible de voir des rétrains de liaison de fabric en raison de l'ID de bogue Cisco CSCul39674. Mais une fois qu'un client a trouvé la solution pour l'ID de bogue Cisco CSCul39674, il ne devrait jamais y avoir de recyclage de liaison de fabric sur les liaisons de fond de panier de fabric entre les cartes de ligne RSP440 et basées sur un typhon. Si c'est le cas, envoyez une demande de service au centre d'assistance technique Cisco (TAC) afin de résoudre le problème.
Q. Les ID de bogue Cisco CSCuj10837 et CSCul39674 affectent-ils le RP sur l'ASR 9922 avec des cartes de ligne basées sur un typhon ?
A. Oui
Q. Les ID de bogue Cisco CSCuj10837 et CSCul39674 affectent-ils les routeurs ASR-9001 et ASR-9001-S ?
A. Non
Q. Si vous rencontrez une défaillance d'un emplacement qui n'existe pas avec ce message, « PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|Test de chemin d'accès du système/de la structure/des données(0x2000004)|le seuil de défaillance est 3, (emplacement, NP) a échoué : (8, 0), » dans un châssis à 10 logements, quel logement présente le problème ?
A. Dans les versions précédentes, vous devez tenir compte des mappages physiques et logiques comme indiqué ici. Dans cet exemple, le logement 8 correspond à 0/6/CPU0.
For 9010 (10 slot chassis)
L P
#0 --- #0
#1 --- #1
#2 --- #2
#3 --- #3
RSP0 --- #4
RSP1 --- #5
#4 --- #6
#5 --- #7
#6 --- #8
#7 --- #9
For 9006 (6 slot chassis)
L P
RSP0 --- #0
RSP1 --- #1
#0 --- #2
#1 --- #3
#2 --- #4
#3 --- #5
Données à collecter avant la création de la demande de service
Voici les commandes minimales à collecter avant toute action :
- Afficher la journalisation
- Afficher l'emplacement pfm dans tout
- admin show diagn result loc 0/rsp0/cpu0 test 8 detail
- admin show diagn result loc 0/rsp1/cpu0 test 8 detail
- admin show diagn result loc 0/rsp0/cpu0 test 9 detail
- admin show diagn result loc 0/rsp1/cpu0 test 9 detail
- admin show diagn result loc 0/rsp0/cpu0 test 10 detail
- admin show diagn result loc 0/rsp1/cpu0 test 10 detail
- admin show diagn result loc 0/rsp0/cpu0 test 11 detail
- admin show diagn result loc 0/rsp1/cpu0 test 11 detail
- show controller fabric fia link-status location <lc>
- show controller fabric fia link-status location <two rsp>
- show controller fabric fia bridge sync-status location <two rsp>
- show controller fabric cross-bar link-status instance 0 emplacement <lc>
- show controller fabric cross-bar link-status instance 0 emplacement <deux rsp>
- show controller fabric cross-bar link-status instance 1 location <two rsp>
- show controller fabric ltrace crossbar location <two rsp>
- show controller fabric ltrace crossbar location <lc affecté>
- show tech fabric location <défaillance montrant lc> fichier <chemin d'accès au fichier>
- show tech fabric location <two rsp> fichier <chemin vers le fichier>
Commandes de diagnostic utiles
Voici une liste de commandes utiles à des fins de diagnostic :
- show diagnostic onDemand settings
- show diagnostic content location < loc >
- show diagnostic result location < loc > [ test {id|id_list|all} ] [ détail ]
- show diagnostic status
- emplacement de démarrage du diagnostic admin < loc > test {id|id_list|test-suite}
- admin diagnostic stop location < loc >
- diagnostic admin itérations à la demande < itération-count >
- diagnostic admin onDemand action-on-fail {suite nombre d'échecs|arrêt}
- admin-config#[ no ] emplacement du moniteur de diagnostic < loc > test {id | nom_test} [désactiver]
- admin-config# [ no ] emplacement de l'intervalle du moniteur de diagnostic < loc > test {id | nom_test} heure du jour:minute:seconde.millisec
- admin-config# [ no ] emplacement du seuil du moniteur de diagnostic < loc > test {id | nom_test} nombre d'échecs
Conclusion
À partir de la version 4.3.4 du logiciel Cisco IOS-XR, la plupart des problèmes liés aux pannes de chemin de données de structure de raccordement sont traités. Pour les routeurs affectés par les ID de bogue Cisco CSCuj10837 et CSCul39674, chargez la SMU de remplacement pour CSCul39674 afin d'éviter les événements de recyclage de liaison de fabric.
L'équipe de la plate-forme a installé une gestion des pannes de pointe afin que le routeur récupère en sous-secondes si et quand une défaillance récupérable du chemin de données se produit. Cependant, ce document est recommandé afin de comprendre ce problème, même si aucune faute de ce genre n'est observée.
Annexe
Chemin de diagnostic de bouclage NP
L'application de diagnostic qui s'exécute sur le processeur de la carte de ligne effectue un suivi de l'état de chaque processeur réseau avec des vérifications périodiques de l'état de fonctionnement du processeur réseau. Un paquet est injecté à partir du processeur de la carte de ligne destiné au processeur réseau local, que le processeur réseau doit retourner en boucle et revenir au processeur de la carte de ligne. Toute perte dans de tels paquets périodiques est signalée par un message de journal de plateforme. Voici un exemple d'un tel message :
LC/0/7/CPU0:Aug 18 19:17:26.924 : pfm_node[182]:
%PLATFORM-PFM_DIAGS-2-LC_NP_LOOPBACK_FAILED : Set|online_diag_lc[94283]|
Line card NP loopback Test(0x2000006)|link failure mask is 0x8
Ce message de journal signifie que ce test n'a pas pu recevoir le paquet de bouclage de NP3. Le masque de défaillance de liaison est 0x8 (le bit 3 est défini), ce qui indique une défaillance entre le processeur de la carte de ligne pour le logement 7 et le processeur NP3 sur le logement 7.
Pour obtenir plus de détails, collectez le résultat de ces commandes :
- admin show diagnostic result location 0/<x>/cpu0 test 9 detail
- show controllers NP counter NP<0-3> emplacement 0/<x>/cpu0
Commandes de débogage de fabric
Les commandes répertoriées dans cette section s'appliquent à toutes les cartes de ligne Trident ainsi qu'à la carte de ligne 100GE Typhoon. L'ASIC Bridge FPGA n'est pas présent sur les cartes de ligne Typhoon (à l'exception des cartes de ligne 100GE Typhoon). Ainsi, les commandes show controller fabric fia bridge ne s'appliquent pas aux cartes de ligne basées sur Typhoon, à l'exception des versions 100GE.
Cette représentation graphique permet de mapper chaque commande show à l'emplacement du chemin de données. Utilisez ces commandes show afin d'isoler les pertes et les pannes de paquets.
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)