Les pannes de chemin de données de matrice de coup de volée de gamme 9000 ASR dépannent le guide
Contenu
Introduction
Ce document décrit des messages d'échec de chemin de données de matrice de coup de volée vus pendant l'exécution de gamme 9000 du routeur de services d'agrégation de Cisco (ASR). Le message apparaît dans ce format :
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é pour n'importe qui qui veut comprendre le message d'erreur, et les mesures qui devraient être prises si le problème est vu.
Conditions préalables
Conditions requises
Cisco recommande que vous ayez une connaissance de haut niveau de ces thèmes :
- Linecards ASR 9000
- Cartes de matrice
- Processeurs d'artère
- Architecture de châssis
Cependant, ce document n'exige pas des lecteurs d'être au courant des détails de matériel. L'information générale nécessaire est fournie avant que le message d'erreur soit expliqué. Ce document décrit l'erreur sur le Trident et les linecards basés sur Typhoon. Voir les types de linecard de gamme 9000 ASR pour une explication de ces termes.
Composants utilisés
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. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Comment utiliser ce document
Considérez ces suggestions au sujet de la façon employer ce document afin de glaner les détails essentiels et comme un guide de référence dans le processus de dépannage :
- Quand il n'y a aucune gravité à la cause principale par panne de chemin de données de matrice de coup de volée, lisez toutes les sections de ce document. Ce document établit le fond nécessaire requis afin d'isoler un composant défectueux quand une telle erreur se produit.
- Utilisez la section de Foire aux questions si vous avez une question spécifique à l'esprit pour lequel une réponse rapide est nécessaire. Si la question n'est pas incluse dans la section de Foire aux questions, alors contrôle si le document principal aborde la question.
- Utilisez toutes les sections de d'analyse des défauts en fonction afin de localiser le problème dans un composant défectueux quand un routeur éprouve un défaut ou afin de vérifier si c'est un problème connu.
Informations générales
Un paquet peut traverser ou deux sauts ou trois sauts par la matrice de commutateur basée sur le linecard tapent. Les linecards de génération de Typhoon ajoutent un élément supplémentaire de matrice de commutateur, alors que les linecards basés sur Trident commutent tout le trafic avec la matrice sur la carte processeur d'artère seulement. Ces éléments de show fabric de diagrammes pour chacun des deux types de linecard, aussi bien que Connectivité de matrice à la carte processeur d'artère :
Chemin de paquet de diagnostic de matrice de coup de volée
L'application diagnostique qui fonctionne sur la CPU de carte processeur d'artère injecte les paquets de diagnostic destinés à chaque processeur de réseau (NP) périodiquement. Le paquet de diagnostic est fait une boucle - arrière à l'intérieur du NP, et réinjecté vers la CPU de carte processeur d'artère qui originaire le paquet. Cette vérification de l'intégrité périodique du chaque NP avec un seul paquet par le NP par l'application diagnostique sur la carte processeur d'artère fournit une alerte pour toutes les erreurs fonctionnelles sur le chemin de données pendant l'exécution de routeur. Il est essentiel de noter que l'application diagnostique sur le processeur actif d'artère et le processeur de réserve d'artère injecte un paquet par le NP périodiquement et met à jour a par compte de succès ou échec du NP. Quand un seuil des paquets de diagnostic abandonnés est atteint, l'application soulève un défaut.
Vue conceptuelle de chemin diagnostique
Avant que le document décrive le chemin diagnostique sur le Trident et les linecards basés sur Typhoon, cette section fournit un contour général du chemin diagnostique de matrice des cartes processeur actives et de réserve d'artère vers le NP sur le linecard.
Chemin de paquet entre la carte processeur active d'artère et le linecard
Des paquets de diagnostic injectés du processeur actif d'artère dans la matrice vers le NP sont traités comme paquets monodiffusions par la matrice de commutateur. Avec des paquets monodiffusions, la matrice de commutateur choisit le lien sortant basé sur la charge de la circulation en cours du lien, qui aide à soumettre les paquets de diagnostic à la charge de la circulation sur le routeur. Quand il y a de plusieurs liens sortants vers le NP, la matrice ASIC de commutateur choisit un lien qui est actuellement moins chargés.
Ce diagramme dépeint le chemin de paquet diagnostique originaire du processeur actif d'artère.
Chemin de paquet entre la carte processeur de réserve d'artère et le linecard
Des paquets de diagnostic injectés du processeur de réserve d'artère dans la matrice vers le NP sont traités comme paquets de multidiffusion par la matrice de commutateur. Bien que ce soit un paquet de multidiffusion, il n'y a aucune réplication à l'intérieur de la matrice. Chaque paquet de diagnostic originaire du processeur de réserve d'artère atteint toujours le seulement un NP à la fois. Le paquet de réponse du NP vers le processeur d'artère est également un paquet de multidiffusion au-dessus de la matrice sans la réplication. Par conséquent, l'application diagnostique sur le processeur de réserve d'artère reçoit un paquet simple de réponse du NPs, un paquet à la fois. L'application de diagnostic dépiste le chaque NP dans le système, parce qu'elle injecte un paquet par le NP, et s'attend à des réponses du chaque NP, un paquet à la fois. Avec un paquet de multidiffusion, la matrice de commutateur choisit le lien sortant basé sur une valeur de champ dans l'en-tête de paquet, qui aide à injecter les paquets de diagnostic au-dessus de chaque matrice pour joindre entre la carte processeur d'artère et le linecard. Le processeur de réserve d'artère dépiste les santés du NP au-dessus de chaque lien de matrice qui se connecte entre la carte processeur d'artère et l'emplacement de carte de ligne.
Le diagramme précédent dépeint le chemin de paquet diagnostique originaire du processeur de réserve d'artère. Notez que, à la différence de la caisse active de processeur d'artère, tous les liens qui connectent le linecard au XBAR sur le processeur d'artère sont exercés. Les paquets de réponse du NP prennent le même lien de matrice qui a été utilisé par le paquet dans le processeur d'artère à la direction de linecard. Ce test s'assure que tous les liens qui connectent le processeur de réserve d'artère au linecard sont surveillés continuellement.
Chemin de paquet diagnostique de matrice de coup de volée sur le linecard basé sur Trident
Ce diagramme dépeint les paquets de diagnostic originaires de processeur d'artère destinés au NP qui est fait une boucle - arrière vers le processeur d'artère. Il est important de noter les liens de chemin de données et les ASIC qui sont communs à tout le NPs, aussi bien que les liens et les composants qui sont spécifiques à un sous-ensemble de NPs. Par exemple, la passerelle ASIC 0 (B0) est commune à NP0 et à NP1, alors que FIA0 est commun à tout le NPs. Sur l'extrémité de processeur d'artère, tous les liens, chemin de données ASIC, et le réseau prédiffusé Champ-programmable (FPGA) sont communs à tous les linecards, et par conséquent à tout le NPs dans un châssis.
Chemin de paquet diagnostique de matrice de coup de volée sur le linecard basé sur Typhoon
Ce diagramme dépeint les paquets de diagnostic originaires de carte processeur d'artère destinés au NP qui est fait une boucle - arrière vers le processeur d'artère. Il est important de noter les liens de chemin de données et les ASIC qui sont communs à tous les NPs aussi bien que liens et composants qui sont spécifiques à un sous-ensemble de NPs. Par exemple, FIA0 est commun à NP0 et à NP1. Sur l'extrémité de carte processeur d'artère, tous les liens, chemin de données ASIC, et les FGPA sont communs à tous les linecards, et par conséquent à tout le NPs dans un châssis.
La tentative à venir de sections de dépeindre le chemin de paquet au chaque NP. C'est nécessaire afin de comprendre le message d'erreur de chemin de données de matrice de coup de volée, et afin de localiser également le point de panne.
Enregistrement d'alarme diagnostique et de panne de matrice de coup de volée
Le manque d'obtenir des réponses du NP dans un routeur ASR 9000-based a comme conséquence une alarme. La décision de donner une alarme par l'application de diagnostic en direct qui exécute sur le processeur d'artère se produit quand il y a trois pannes consécutives. L'application diagnostique met à jour une fenêtre de panne de trois paquets pour le chaque NP. Le processeur actif d'artère et le processeur de réserve d'artère diagnostiquent indépendamment et en parallèle. Le processeur actif d'artère, le processeur de réserve d'artère, ou les deux cartes processeur d'artère pourraient signaler l'erreur. L'emplacement du défaut et la perte de paquets déterminent quel processeur d'artère signale l'alarme.
La fréquence par défaut du paquet de diagnostic vers le chaque NP est un paquet par 60 secondes ou une par minute.
Voici le format de 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 devrait être lu comme manque d'atteindre le NP 1, 2, 3, 4, 5, 6, et 7 sur le linecard 0/7/cpu0 du processeur 0/rsp0/cpu0 d'artère.
De la liste de tests de diagnostic en direct, vous pouvez voir les attributs du test de bouclage de matrice de coup de volée 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 affiche que la fréquence de test de PuntFabricDataPath est un paquet chaque minute, et le seuil de panne est trois, qui implique que la perte de trois paquets consécutifs n'est pas tolérée et a comme conséquence une alarme. Les attributs de test affichés sont des valeurs par défaut. Afin de changer des par défaut, sélectionnez les commandes de diagnostic monitor interval et de diagnostic monitor threshold dans le mode de configuration de gestion.
Chemin de paquet basé sur Trident de diagnostic de linecard
Panne du diagnostic NP0
Chemin diagnostique de matrice
Ce diagramme dépeint le chemin de paquet entre la CPU et le linecard NP0 de processeur d'artère. Le lien qui connecte B0 et NP0 est la seule particularité de lien à NP0. Tous les autres liens tombent dans le chemin commun.
Notez le chemin de paquet à partir du processeur d'artère vers NP0. Bien qu'il y ait quatre liens aux utiliser pour des paquets destinés vers NP0 du processeur d'artère, le premier lien entre le processeur d'artère et l'emplacement de carte de ligne est utilisé pour le paquet du processeur d'artère vers le linecard. Le paquet retourné de NP0 peut être renvoyé au processeur actif d'artère au-dessus des deux chemins l'uns des de lien de matrice entre l'emplacement de carte de ligne et le processeur actif d'artère. Le choix dont un des deux liens aux utiliser dépend du chargement de lien à ce moment-là. Le paquet de réponse de NP0 vers le processeur de réserve d'artère utilise les deux liens, mais un lien à la fois. Le choix du lien est basé sur le champ d'en-tête que l'application diagnostique remplit.
Analyse diagnostique de la panne NP0
Scénario simple de défaut
Si une alarme de panne de chemin de données de matrice de coup de volée du gestionnaire de défaut de plate-forme unique (PFM) avec seulement NP0 dans le message d'échec est détectée, le défaut est seulement sur le chemin de matrice qui connecte le processeur et le linecard NP0 d'artère. C'est un défaut simple. Si le défaut est détecté au plus d'un NP, référez-vous à la plusieurs section de scénario de défaut.
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 diagramme précédent de chemin de données, le défaut doit être dans un ou plusieurs de ces emplacements :
- Joignez qui connecte NP0 et B0
- Files d'attente B0 intérieures orientées sur NP0
- NP0 intérieur
Plusieurs scénario de défaut
Plusieurs défauts du NP
Quand d'autres défauts sont observés sur NP0 ou le défaut PUNT_FABRIC_DATA_PATH_FAILED est également signalé par l'autre NPs sur le même linecard, alors l'isolation des erreurs est faite en corrélant tous les défauts. Par exemple, si le défaut PUNT_FABRIC_DATA_PATH_FAILED et le défaut LC_NP_LOOPBACK_FAILED se produisent sur NP0, puis le NP a arrêté traiter des paquets. Référez-vous à la section de chemin de diagnostic par test de bouclage du NP afin de comprendre le défaut de bouclage. Ceci a pu être une première indication d'une panne essentielle à l'intérieur de NP0. Cependant, si seulement un des deux défauts se produit, puis le défaut est localisé au chemin de données de matrice de coup de volée ou sur la CPU de linecard au chemin du NP.
Si le plus d'un NP sur un linecard a un défaut de chemin de données de matrice de coup de volée, alors vous devez marcher vers le haut du chemin d'arborescence des liens de matrice afin d'isoler un composant défectueux. Par exemple, si NP0 et NP1 ont un défaut, puis le défaut doit être dans B0 ou le lien qui connecte B0 et FIA0. Il est moins probable que NP0 et NP1 rencontrent une erreur interne essentielle en même temps. Bien qu'il soit moins probable, il est possible à NP0 et à NP1 pour rencontrer un défaut d'erreur essentielle dû au traitement incorrect d'un type particulier de paquet ou d'un mauvais paquet.
Les deux cartes processeur d'artère signalent un défaut
Si les cartes processeur actives et de réserve d'artère signalent un défaut à l'un ou plusieurs NPs sur un linecard, alors vérifiez tous les liens et composants de terrain communal sur le chemin de données entre le NPs affecté et les les deux les cartes processeur d'artère.
Panne du diagnostic NP1
Ce diagramme dépeint le chemin de paquet entre la CPU et le linecard NP1 de carte processeur d'artère. Le lien qui connecte la passerelle ASIC 0 (B0) et le NP1 est la seule particularité de lien à NP1. Tous les autres liens tombent dans le chemin commun.
Notez le chemin de paquet à partir de la carte processeur d'artère vers NP1. Bien qu'il y ait quatre liens aux utiliser pour des paquets destinés vers NP0 du processeur d'artère, le premier lien entre le processeur d'artère et l'emplacement de carte de ligne est utilisé pour le paquet du processeur d'artère vers le linecard. Le paquet retourné de NP1 peut être renvoyé au processeur actif d'artère au-dessus des deux chemins l'uns des de lien de matrice entre l'emplacement de carte de ligne et le processeur actif d'artère. Le choix dont un des deux liens aux utiliser dépend du chargement de lien à ce moment-là. Le paquet de réponse de NP1 vers le processeur de réserve d'artère utilise les deux liens, mais un lien à la fois. Le choix du lien est basé sur le champ d'en-tête que l'application diagnostique remplit.
Chemin diagnostique de matrice
Analyse diagnostique de la panne NP1
Référez-vous à la section diagnostique d'analyse de la panne NP0, mais appliquez le même raisonnement pour NP1 (au lieu de NP0).
Panne du diagnostic NP2
Ce diagramme dépeint le chemin de paquet entre la CPU et le linecard NP2 de carte processeur d'artère. Le lien qui connecte B1 et NP2 est la seule particularité de lien à NP2. Tous les autres liens tombent dans le chemin commun.
Notez le chemin de paquet à partir de la carte processeur d'artère vers NP2. Bien qu'il y ait quatre liens aux utiliser pour des paquets destinés vers NP2 du processeur d'artère, le premier lien entre le processeur d'artère et l'emplacement de carte de ligne est utilisé pour le paquet du processeur d'artère vers le linecard. Le paquet retourné de NP2 peut être renvoyé au processeur actif d'artère au-dessus des deux chemins l'uns des de lien de matrice entre l'emplacement de carte de ligne et le processeur actif d'artère. Le choix dont un des deux liens aux utiliser dépend du chargement de lien à ce moment-là. Le paquet de réponse de NP2 vers le processeur de réserve d'artère utilise les deux liens, mais un lien à la fois. Le choix du lien est basé sur le champ d'en-tête que l'application diagnostique remplit.
Chemin diagnostique de matrice
Analyse diagnostique de la panne NP2
Référez-vous à la section diagnostique d'analyse de la panne NP0, mais appliquez le même raisonnement pour NP2 (au lieu de NP0).
Panne du diagnostic NP3
Ce diagramme dépeint le chemin de paquet entre la CPU et le linecard NP3 de carte processeur d'artère. Le lien qui connecte la passerelle ASIC 1 (B1) et le NP3 est la seule particularité de lien à NP3. Tous les autres liens tombent dans le chemin commun.
Notez le chemin de paquet à partir de la carte processeur d'artère vers NP3. Bien qu'il y ait quatre liens aux utiliser pour des paquets destinés vers NP3 du processeur d'artère, le premier lien entre le processeur d'artère et l'emplacement de carte de ligne est utilisé pour le paquet du processeur d'artère vers le linecard. Le paquet retourné de NP3 peut être renvoyé au processeur actif d'artère au-dessus des deux chemins l'uns des de lien de matrice entre l'emplacement de carte de ligne et le processeur actif d'artère. Le choix dont un des deux liens aux utiliser dépend du chargement de lien à ce moment-là. Le paquet de réponse de NP3 vers le processeur de réserve d'artère utilise les deux liens, mais un lien à la fois. Le choix du lien est basé sur le champ d'en-tête que l'application diagnostique remplit.
Chemin diagnostique de matrice
Analyse diagnostique de la panne NP3
Référez-vous à la section diagnostique d'analyse de la panne NP0, mais appliquez le même raisonnement pour NP3 (au lieu de NP0).
Chemin de paquet basé sur Typhoon de diagnostic de linecard
Cette section fournit deux exemples afin d'établir le fond pour des paquets de coup de volée de matrice avec les linecards basés sur Typhoon. Le premier exemple utilise NP1, et le deuxième exemple utilise NP3. La description et l'analyse peuvent être étendues à l'autre NPs sur n'importe quel linecard basé sur Typhoon.
Panne de diagnostic de Typhoon NP1
Le prochain diagramme dépeint le chemin de paquet entre la CPU et le linecard NP1 de carte processeur d'artère. Le lien qui connecte FIA0 et NP1 est la seule particularité de lien au chemin NP1. Tous les autres liens entre l'emplacement de carte de ligne et l'emplacement de carte processeur d'artère tombent dans le chemin commun. Les liens qui connectent la matrice XBAR ASIC sur le linecard au FIAS sur le linecard sont spécifiques à un sous-ensemble de NPs. Par exemple, des liens entre FIA0 et la matrice locale XBAR ASIC sur le linecard sont utilisés pour le trafic à NP1.
Notez le chemin de paquet à partir de la carte processeur d'artère vers NP1. Bien qu'il y ait huit liens aux utiliser pour des paquets destinés vers NP1 de la carte processeur d'artère, un chemin unique entre la carte processeur d'artère et l'emplacement de carte de ligne est utilisé. Le paquet retourné de NP1 peut être renvoyé à la carte processeur d'artère plus de huit chemins de lien de matrice entre l'emplacement de carte de ligne et le processeur d'artère. Chacun de ces huit liens est exercé un par un quand le paquet de diagnostic est destiné de nouveau à la CPU de carte processeur d'artère.
Chemin diagnostique de matrice
Panne de diagnostic de Typhoon NP3
Ce diagramme dépeint le chemin de paquet entre la CPU et le linecard NP3 de carte processeur d'artère. Le lien qui connecte FIA1 et NP3 est la seule particularité de lien au chemin NP3. Tous les autres liens entre l'emplacement de carte de ligne et l'emplacement de carte processeur d'artère tombent dans le chemin commun. Les liens qui connectent la matrice XBAR ASIC sur le linecard au FIAS sur le linecard sont spécifiques à un sous-ensemble de NPs. Par exemple, des liens entre FIA1 et la matrice locale XBAR ASIC sur le linecard sont utilisés pour le trafic à NP3.
Notez le chemin de paquet à partir de la carte processeur d'artère vers NP3. Bien qu'il y ait huit liens aux utiliser pour des paquets destinés vers NP3 de la carte processeur d'artère, un chemin unique entre la carte processeur d'artère et l'emplacement de carte de ligne est utilisé. Le paquet retourné de NP1 peut être renvoyé à la carte processeur d'artère plus de huit chemins de lien de matrice entre l'emplacement de carte de ligne et le processeur d'artère. Chacun de ces huit liens est exercé un par un quand le paquet de diagnostic est destiné de nouveau à la CPU de carte processeur d'artère.
Chemin diagnostique de matrice
Analysez les défauts
Cette section classe des défauts dans des cas durs et passagers, et répertorie par catégorie les étapes utilisées afin d'identifier si un défaut est un défaut dur ou passager. Une fois que le type de défaut est déterminé, le document spécifie les commandes qui peuvent être exécutés sur le routeur afin de comprendre le défaut et les quels actions correctives sont nécessaires.
Défaut passager
Si un message du positionnement PFM est suivi par le message clair PFM, alors un défaut s'est produit, et le routeur a corrigé le défaut lui-même. Les défauts passagers peuvent se produire en raison des conditions environnementales et des défauts réparables dans des composants matériels. Parfois il peut être difficile d'associer les défauts passagers à n'importe quel événement particulier.
Un exemple d'un défaut passager de matrice est répertorié ici pour la 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 passagères de défaut
L'approche suggérée pour des erreurs passagères est surveillent seulement pour davantage d'occurrence de telles erreurs. Si un défaut passager se produit plus d'une fois, alors traitez le défaut passager comme panne majeure, et employez les recommandations et les étapes afin d'analyser de tels défauts décrits dans la section suivante.
Panne majeure
Si un message du positionnement PFM n'est pas suivi par un message clair PFM, alors un défaut s'est produit et le routeur n'a pas corrigé le défaut lui-même par le défaut manipulant le code, ou la nature de la défaillance matérielle n'est pas réparable. Les pannes majeures peuvent se produire en raison des conditions environnementales et des défauts irrémédiables dans des composants matériels. L'approche suggérée pour les pannes majeures est d'utiliser les instructions mentionnées dans la section de pannes majeures d'analyse.
Un exemple de défaut dur de matrice est répertorié ici pour la clarté. Pour ce message d'exemple, il n'y a pas un message clair correspondant PFM.
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 de panne majeure
Sous un scénario de panne majeure, collectez toutes les commandes mentionnées dans les données pour collecter avant que section de création de demande de service, et pour ouvrir une demande de service. Dans des cas urgents, après que vous collectiez toute les sortie de commande de dépannage, initiez une carte processeur d'artère ou une recharge de linecard basée sur l'isolation des erreurs. Après que la recharge, si l'erreur n'est pas récupérée, initient une autorisation de contenu de retour (RMA).
Analysez les défauts passagers
Terminez-vous ces étapes afin d'analyser les défauts passagers.
- Écrivez le show logging | commande inc. « PUNT_FABRIC_DATA_PATH » afin de découvrir si l'erreur se produisait par le passé ou de plusieurs périodes.
- Entrez l'emplacement de pfm d'exposition toute la commande afin de déterminer l'état actuel (PLACEZ ou EFFACEZ). L'erreur est-elle exceptionnelle ou effacée ? Si les changements d'état des erreurs entre le POSITIONNEMENT et l'ESPACE LIBRE, alors un ou plusieurs défauts dans le chemin de données de matrice à plusieurs reprises se produit et est l'un ou l'autre rectifiés par le matériel ou logiciel.
- Provision les déroutements de Protocole SNMP (Simple Network Management Protocol) ou exécutez un script qui collecte l'emplacement de pfm d'exposition toute la sortie de commande, et recherchez la chaîne d'erreur périodiquement afin de surveiller la future occurrence du défaut (quand le dernier statut de l'erreur est CLAIR, et nouveau défaut ne se produit pas).
Commandes de utiliser
Sélectionnez ces commandes afin d'analyser les défauts passagers :
- show logging | inc. « PUNT_FABRIC_DATA_PATH »
- affichez l'emplacement tout de pfm
Analysez les pannes majeures
Si vous visualisez le chemin de données de matrice joint sur un linecard comme arborescence (où les détails sont décrits dans la section Informations générales), alors vous devez impliquer - basé sur le point de défaut - si un ou plusieurs NPs sont inaccessible. Quand les plusieurs défauts se produisent sur plusieurs NPs, alors utilisez les commandes répertoriées dans cette section afin d'analyser des défauts.
Commandes de utiliser
Sélectionnez ces commandes afin d'analyser les pannes majeures :
- show logging | inc. « PUNT_FABRIC_DATA_PATH »
La sortie pourrait contenir un ou plusieurs NPs (exemple : NP2, NP3). - <lc> d'emplacement de lien-état FIA de matrice de show controller
Puisque NP2 et NP3 (dans la section diagnostique de panne de Typhoon NP3) reçoivent et envoient par une FIA simple, il est raisonnable d'impliquer que le défaut est à une FIA associée sur le chemin. - emplacement <0 et 1> <LC ou RSP> d'exemple de lien-état de barre transversale de matrice de show controller
Si tout le NPs sur le linecard ne sont pas accessible pour l'application diagnostique, alors il est raisonnable d'impliquer que les liens qui connectent l'emplacement de carte de ligne à la carte processeur d'artère pourraient avoir un défaut sur les ASIC l'uns des qui le trafic en avant entre la carte processeur d'artère et le linecard.
<lc> d'emplacement de l'exemple 0 de lien-état de barre transversale de matrice de show controller
emplacement 0/rsp0/cpu0 de l'exemple 0 de lien-état de barre transversale de matrice de show controller
emplacement 0/rsp0/cpu0 de l'exemple 1 de lien-état de barre transversale de matrice de show controller
emplacement 0/rsp1/cpu0 de l'exemple 0 de lien-état de barre transversale de matrice de show controller
emplacement 0/rsp1/cpu0 de l'exemple 1 de lien-état de barre transversale de matrice de show controller - emplacement 0/rsp*/cpu0 de lien-état FIA de matrice de show controller
emplacement 0/rsp0/cpu0 de lien-état FIA de matrice de show controller
emplacement 0/rsp1/cpu0 de lien-état FIA de matrice de show controller - la FIA de matrice de show controller jettent un pont sur l'emplacement 0/rsp*/cpu0 de synchronisation-état
la FIA de matrice de show controller jettent un pont sur l'emplacement 0/rsp0/cpu0 de synchronisation-état
la FIA de matrice de show controller jettent un pont sur l'emplacement 0/rsp1/cpu0 de synchronisation-état
affichez le terminal de matrice de tech
Pannes passées
Historiquement, 99 pour cent de défauts sont réparables, et dans la plupart des cas l'action logiciel-initiée de reprise répare les défauts. Cependant, dans très des rares cas, on voit des erreurs irrémédiables qui peuvent seulement être réparées avec le RMA des cartes.
Les sections suivantes identifient quelques pannes passées produites afin de servir de conseils si on observe des erreurs semblables.
Erreur passagère due au surabonnement du NP
Affichage de ces messages si l'erreur est due au surabonnement du 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)
Il peut être plus difficiles de confirmer les défauts passagers. Une méthode pour déterminer si le NP est actuellement oversubscribed ou a été oversubscribed dans le passé est de vérifier un certain genre de baisse à l'intérieur du NP et pour des pertes de destination à la FIA. Les baisses avant de l'accès direct à la mémoire d'entrée (IFDMA) à l'intérieur du NP se produisent quand le NP est oversubscribed et ne peut pas suivre le trafic entrant. Les pertes de destination FIA se produisent quand un de sortie NP affirme le contrôle de flux (demande à la carte de ligne d'entrée pour envoyer moins de trafic). Sous le scénario de contrôle de flux, la FIA d'entrée a des pertes de destination.
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
Panne majeure due à la remise rapide du NP
Quand PUNT_FABRIC_DATA_PATH_FAILED se produit, et si la panne est due à la remise rapide du NP, alors se connecte semblable à ce qui est répertorié ici apparaît pour un linecard basé sur Typhoon. Le mécanisme de surveillance de la santé est disponible sur les linecards basés sur Typhoon, mais pas sur les linecards basés sur 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 linecards basés sur Trident, ce log est vu avec une remise rapide du NP :
LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3
Pannes entre les processeurs de l'artère RSP440 et les linecards de Typhoon
Cisco a réparé une question où rarement des liens de matrice entre le processeur de commutation routage (RSP) 440 et linecards basés sur Typhoon à travers le fond de panier sont recyclés. Des liens de matrice sont recyclés parce que la force du signal n'est pas optimale. Cette question est présente dans les versions de logiciel 4.2.1, les 4.2.2, les 4.2.3, les 4.3.0, les 4.3.1, et les 4.3.2 de base du Cisco IOS ®-XR. Une mise à jour de maintenance logicielle (SMU) pour chacune de ces releases est signalée sur le Cisco Connection Online, et dépistée avec l'ID de bogue Cisco CSCuj10837 et l'ID de bogue Cisco CSCul39674.
Quand cette question se produit sur le routeur, l'un de ces scénarios peuvent se produire :
- Le lien descend et est soulevé. (Coupure)
- Le lien descend de manière permanente.
Recyclage de matrice de l'ID de bogue Cisco CSCuj10837 entre RSP et LC (direction TX)
Afin de confirmer, collectez les sorties de ltrace du LC et le RSPs (<> d'emplacement de ltrace de barre transversale de matrice de show controller) et contrôle si cette sortie est vue dans des ltraces 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.
La direction du terme TX se rapporte à la direction du point de vue de l'interface de matrice de barre transversale de RSPs vers une interface de barre transversale de matrice sur un linecard basé sur Typhoon.
L'ID de bogue Cisco CSCuj10837 est caractérisé par la détection du linecard de Typhoon d'un problème sur le lien RX du RSP et de l'initiation d'un recyclage de lien. L'un ou l'autre de côté (LC ou RSP) peut initier l'événement de recyclage. Dans le cas de l'ID de bogue Cisco CSCuj10837, le LC initie le recyclage et peut être détecté par le xbar_trigger_link_retrain d'init : message dans les suivis 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
Quand le LC initie le recyclage, le RSP signale un link_retrain de rcvd dans les informations 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.
Recyclage de matrice de l'ID de bogue Cisco CSCul39674 entre RSP et LC (direction RX)
Afin de confirmer, collectez les sorties de ltrace du linecard et le RSPs (<> d'emplacement de ltrace de barre transversale de matrice de show controller) et contrôle si cette sortie est vue dans des ltraces 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.
La direction du terme RX se rapporte à la direction du point de vue de l'interface de matrice de barre transversale de RSPs d'une interface de barre transversale de matrice sur un linecard basé sur Typhoon.
L'ID de bogue Cisco CSCul39674 est caractérisé par la détection du RSP d'un problème sur le lien RX du linecard de Typhoon et de l'initiation d'un recyclage de lien. L'un ou l'autre de côté (LC ou RSP) peut initier l'événement de recyclage. Dans le cas de l'ID de bogue Cisco CSCul39674, le RSP initie le recyclage et peut être détecté par le xbar_trigger_link_retrain d'init : message dans les suivis 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
Quand le RSP initie le recyclage, le LC signale un événement de link_retrain de rcvd dans les informations 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 recyclage de matrice dans la version 4.3.2 et ultérieures
Le travail significatif a été effectué afin de diminuer le temps où il prend pour recycler un lien de matrice dans la version 4.3.2 et ultérieures IOS-XR. Le recyclage de matrice maintenant se produit en périodes fraction de seconde et est imperceptible à la circulation. Dans la version 4.3.2, seulement ces le message de Syslog sont vus quand un recyclage de lien de matrice s'est produit.
%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT : Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1
Panne due au dépassement FIFO de la matrice ASIC
Cisco a réparé une question où la matrice ASIC (la FIA) pourrait obtenir la remise due à une première condition de débordement (FIFO) à système premier entré, premier sorti irrémédiable. Ceci est adressé avec l'ID de bogue Cisco CSCul66510. Ce problème affecte seulement les linecards basés sur Trident et est seulement produit dans de rares cas avec l'encombrement lourd de chemin d'entrée. Si cette question est produite, ce message de Syslog est affiché avant que le linecard soit remis à l'état initial pour récupérer 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
Panne due à l'habillage lourd de la file d'attente de sortie virtuelle (VOQ) de l'encombrement de matrice
Cisco a réparé une question où l'encombrement lourd étendu pourrait mener à l'épuisement de ressource en matrice et trafiquer la perte. La perte du trafic peut même se produire sur des écoulements indépendants. Ce problème est abordé avec l'ID de bogue Cisco CSCug90300 et est résolu dans la version 4.3.2 et ultérieures IOS-XR. La difficulté est également fournie dans la version 4.2.3 CSMU#3, SMU CSCui33805. Cette question rare pourrait être produite sur le Trident ou les linecards basés sur Typhoon.
Commandes appropriées
Vous devriez recueillir ces commandes :
- show tech-support fabric
- la FIA de matrice de show controller jettent un pont sur le <=== de régulation de débit de l'emplacement <LC> obtiennent cette sortie pour tout le LCS
- emplacement <LC> de q-profondeur FIA de show controllers fabric
Voici quelques exemples de sortie :
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 nomal, il est très peu susceptible de voir un VOQ avec des paquets alignés. Cette commande est un instantané en temps réel rapide des files d'attente FIA. Il est commun pour que cette commande n'affiche aucun paquet aligné du tout.
Incidence du trafic due aux erreurs logicielles Bridge/FPGA sur les linecards basés sur Trident
Les erreurs logicielles sont des erreurs non-permanentes qui font être l'ordinateur d'état hors de sync. Ceux-ci sont vus comme contrôle de redondance cyclique (CRC), Frame Check Sequence (FCS), ou paquets errored du côté de matrice du NP ou du côté d'entrée de la FIA.
Voici quelques exemples de la façon dont cette question peut être vue :
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 recueillir pour des erreurs logicielles Bridge/FPGA sur les linecards basés sur Trident
Vous devriez recueillir ces commandes :
- show tech-support fabric
- show tech-support NP
- la FIA de matrice de show controller jettent un pont sur le <> d'emplacement de stats (obtenez plusieurs fois)
Reprise des erreurs logicielles Bridge/FPGA
La méthode de reprise est de recharger le linecard affecté.
RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload
Rapport des essais de diagnostic en direct
La commande de <node> d'emplacement de show diagnostic result [détail de <test-id> de test] fournit un résumé de toutes les tests de diagnostic en direct et pannes aussi bien que le dernier groupe date/heure quand un test a passé. Le Test-ID pour la panne de chemin de données de matrice de coup de volée est dix. Une liste de tous les tests avec la fréquence des paquets de test peut être vue avec la commande de <node> d'emplacement de show diagnostic content.
La sortie du résultat de test de chemin de données de matrice de coup de volée sera semblable à cette sortie témoin :
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 automatiques de reprise
Comme décrit dans l'ID de bogue Cisco CSCuc04493, il y a maintenant une manière de faire arrêter au routeur automatiquement tous les ports qui sont associés avec les erreurs PUNT_FABRIC_DATA_PATH.
La première méthode est dépistée par l'intermédiaire de 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 placé pour arrêter automatiquement tous les ports qui sont associés avec le NPs qui sont affecté.
Voici un exemple qui affiche comment les Syslog 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 indiquera que la raison pour l'interface étant en baisse est due à DATA_PATH_DOWN. Voici un exemple :
RP/0/RSP0/CPU0:ASR9006-E#show 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é. Il y a une nouvelle commande de config d'admin qui est utilisée afin d'accomplir ceci. Car le comportement par défaut n'est plus d'arrêter les ports, ceci doit être manuellement configuré.
RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
L'ID de bogue Cisco CSCui15435 adresse les erreurs logicielles qui sont vues sur les linecards basés sur Trident, comme décrit ici. Ceci utilise une méthode de dépistage différente que la méthode diagnostique habituelle qui est décrite dans l'ID de bogue Cisco CSCuc04493.
Cette bogue a également introduit une nouvelle commande CLI de configuration d'admin :
(admin-config)#fabric fia soft-error-monitor <1|2> location <specific>
1 = shutdown the ports
2 = reload the linecard
Default behavior: no action is taken.
Quand cette erreur est produite, on peut observer ce Syslog :
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)
Quand les ports affectés sont arrêtés, il permet à la redondance de réseau pour assurer et éviter noir-trouer du trafic. Afin de récupérer, le linecard doit être rechargé.
Forums aux questions (Foire aux questions)
Q. La carte processeur primaire ou de réserve d'artère envoie-t-elle le Keepalives ou les paquets de diagnostic en direct au chaque NP dans le système ?
R. Oui. Les deux cartes processeur d'artère envoient des paquets de diagnostic en direct au chaque NP.
Q. Le chemin est-il les mêmes quand la carte processeur une (RSP1) d'artère est en activité ?
R. Le chemin diagnostique est identique pour RSP0 ou RSP1. Le chemin dépend de l'état du RSP. Référez-vous à la section diagnostique de chemin de paquet de matrice de coup de volée de ce document pour plus de détails.
Q. Combien de fois RSPs envoient-ils les paquets de diagnostic, et combien de paquets de diagnostic doivent être manqués avant qu'une alarme soit déclenchée ?
R. Chaque RSP envoie indépendamment un paquet de diagnostic au chaque NP une fois par minute. L'un ou l'autre de RSP peut déclencher une alarme si trois paquets de diagnostic pas aknowledged.
Q. Comment déterminez-vous si le NP est ou a été oversubscribed ?
R. Une manière de vérifier si le NP est actuellement oversubscribed ou a été oversubscribed dans le passé est de vérifier un certain genre de baisse à l'intérieur du NP et pour des pertes de destination à la FIA. Les baisses avant de l'accès direct à la mémoire d'entrée (IFDMA) à l'intérieur du NP se produisent quand le NP est oversubscribed et ne peut pas suivre le trafic entrant. Les pertes de destination FIA se produisent quand un de sortie NP affirme le contrôle de flux (demande à la carte de ligne d'entrée pour envoyer moins de trafic). Sous le scénario de contrôle de flux, la FIA d'entrée a des pertes de destination.
Q. Comment déterminez-vous si le NP souffre un défaut qui exige de lui d'être remis à l'état initial ?
R. Typiquement, le NP censurent est effacé par une remise rapide. La raison pour une remise rapide est affichée dans les logs.
Q. Qu'affiche si le NP a une défaillance matérielle non-réparable ?
R. Vous voyez une panne de chemin de données de matrice de coup de volée pour le ce NP aussi bien qu'une panne de test de bouclage du NP. Le message d'échec de test de bouclage du NP est discuté dans l'annexe section de ce document.
Q. Est-ce qu'paquet de diagnostic qui est originaire d'un conduira la carte processeur revenue à la même ?
R. Puisque les paquets de diagnostic sont originaires des cartes processeur d'artère et sont dépistés sur a par base de carte processeur d'artère, un paquet de diagnostic originaire d'une carte processeur d'artère est fait une boucle - de retour à la même carte processeur d'artère par le NP.
Q. L'ID de bogue Cisco CSCuj10837 SMU fournit une difficulté pour l'événement de recyclage de lien de matrice. Est-ce que ce la cause et la solution est pour beaucoup des pannes de chemin de données de matrice de coup de volée ?
R. Oui, on l'exigera pour charger le SMU de remplacement pour l'ID de bogue Cisco CSCul39674 afin d'éviter des événements de recyclage de lien de matrice.
Q. Combien de temps rentre-t-il la commande pour recycler des liens de matrice une fois que la décision de faire ainsi est prise ?
R. La décision de recycler est prise dès qu'une panne de lien sera détectée. Avant la version 4.3.2, le recyclage pourrait prendre plusieurs secondes. Après la version 4.3.2, le temps de recyclage a été amélioré et prend de manière significative moins qu'une seconde.
Q. À quel point le recyclage de décision est-il un lien de matrice a-t-il fait ?
A. Dès que le défaut de lien sera détecté, la décision de recycler est prise par le gestionnaire de la matrice ASIC.
Q. Est-il seulement entre la FIA sur une carte processeur active d'artère et la matrice que vous utilisez le premier lien, et puis ensuite que c'est le moins lien chargé quand il y a de plusieurs liens disponibles ?
A. Correct. Le premier lien qui se connecte au premier exemple XBAR sur le processeur actif d'artère est utilisé afin d'injecter le trafic dans la matrice. Le paquet de réponse du NP peut atteindre de nouveau à la carte processeur active d'artère sur n'importe lequel de tous les liens qui se connectent à la carte processeur d'artère. Le choix du lien dépend du chargement de lien.
Q. Est-ce que pendant le recyclage, tous les paquets qui sont envoyés au-dessus de ce lien de matrice sont perdus ?
R. Oui, mais avec les améliorations dans la version 4.3.2 et ultérieures, le recyclage est pratiquement undetectible. Cependant, en code antérieur, il pourrait prendre plusieurs secondes pour recycler, qui ont eu comme conséquence les paquets perdus pour cette période.
Q. Combien fréquemment comptez-vous voir une matrice XBAR joindre l'événement de recyclage après que vous amélioriez à une release ou à un SMU avec la difficulté pour l'ID de bogue Cisco CSCuj10837 ?
R. Même avec la difficulté pour l'ID de bogue Cisco CSCuj10837 il est encore possible de voir la matrice joindre des recyclages dus à l'ID de bogue Cisco CSCul39674. Mais une fois qu'un client a la difficulté pour l'ID de bogue Cisco CSCul39674, le recyclage de lien de matrice sur les liens du fond de panier de matrice entre le RSP440 et les linecards basés sur Typhoon devrait ne jamais se produire. S'il fait, alors soulever une demande de service avec le centre d'assistance technique Cisco (TAC) afin de dépanner le problème.
Q. Les id CSCuj10837 et CSCul39674 de bogue Cisco affectent-ils le RP sur l'ASR 9922 avec les linecards basés sur Typhoon ?
R. Oui
Q. Les id CSCuj10837 et CSCul39674 de bogue Cisco affectent-ils les Routeurs ASR-9001 et ASR-9001-S ?
R. Non
Q. Si vous rencontrez la panne d'un emplacement qui n'existe pas avec ce message, "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Le seuil de coup de volée/matrice/chemin de données Test(0x2000004)|failure Set|online_diag_rsp[237686]|System est 3, (emplacement, le NP) manqué : (8, 0)," dans un châssis 10-slot, que l'emplacement a la question ?
R. Dans des releases plus anciennes, vous devez expliquer les mappages physiques et logiques comme affiché ici. Dans cet exemple, l'emplacement 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 création de demande de service
Voici les commandes minimum que vous devriez collecter avant que n'importe quelle mesure soit prise :
- Show logging
- Affichez l'emplacement tout de pfm
- détail du test 8 de l'emplacement 0/rsp0/cpu0 de résultat de diagn d'exposition d'admin
- détail du test 8 de l'emplacement 0/rsp1/cpu0 de résultat de diagn d'exposition d'admin
- détail du test 9 de l'emplacement 0/rsp0/cpu0 de résultat de diagn d'exposition d'admin
- détail du test 9 de l'emplacement 0/rsp1/cpu0 de résultat de diagn d'exposition d'admin
- détail du test 10 de l'emplacement 0/rsp0/cpu0 de résultat de diagn d'exposition d'admin
- détail du test 10 de l'emplacement 0/rsp1/cpu0 de résultat de diagn d'exposition d'admin
- détail du test 11 de l'emplacement 0/rsp0/cpu0 de résultat de diagn d'exposition d'admin
- détail du test 11 de l'emplacement 0/rsp1/cpu0 de résultat de diagn d'exposition d'admin
- <lc> d'emplacement de lien-état FIA de matrice de show controller
- rsp> de <both d'emplacement de lien-état FIA de matrice de show controller
- la FIA de matrice de show controller jettent un pont sur le rsp> de <both d'emplacement de synchronisation-état
- <lc> d'emplacement de l'exemple 0 de lien-état de barre transversale de matrice de show controller
- rsp> de <both d'emplacement de l'exemple 0 de lien-état de barre transversale de matrice de show controller
- rsp> de <both d'emplacement de l'exemple 1 de lien-état de barre transversale de matrice de show controller
- rsp> de <both d'emplacement de barre transversale de ltrace de matrice de show controller
- lc> <affected par emplacement de barre transversale de ltrace de matrice de show controller
- affichez le <fault d'emplacement de matrice de tech affichant le <path de fichier de lc> au file>
- affichez le <path de fichier de rsp> de <both d'emplacement de matrice de tech au file>
Commandes de diagnostic utiles
Voici une liste des commandes qui sont utile pour les buts diagnostiques :
- shows diagnostic ondemands settings
- emplacement < emplacement > de show diagnostic content
- emplacement < emplacement > de show diagnostic result [test {id|id_list|tous}] [détail]
- show diagnostic status
- test de < emplacement > d'emplacement de diagnostic start d'admin {id|id_list|test-suite}
- emplacement de diagnostic stop d'admin < emplacement >
- diagnostics ondemands iterations < itération-compte > d'admin
- diagnostic ondemand action-on-failure d'admin {continuez le décompte de pannes|arrêt}
- test de < emplacement > d'emplacement de diagnostic monitor d'admin-config# [non] {id | test-nom} [débronchement]
- test de < emplacement > d'emplacement de diagnostic monitor interval d'admin-config# [non] {id | heure de jour de test-nom} : minute : second.millisec
- test de < emplacement > d'emplacement de diagnostic monitor threshold d'admin-config# [non] {id | décompte de pannes de test-nom}
Conclusion
Du Logiciel Cisco IOS XR publiez la période 4.3.4, la plupart de problème lié pour donner un coup de volée des pannes de chemin de données de matrice sont adressés. Pour des Routeurs affectés par les id CSCuj10837 et CSCul39674 de bogue Cisco, chargez le SMU de remplacement pour CSCul39674 afin d'éviter des événements de recyclage de lien de matrice.
L'équipe de plate-forme a installé le défaut de pointe manipulant de sorte que le routeur récupère dans les subseconds si et quand n'importe quelle panne réparable de chemin de données se produit. Cependant, ce document est recommandé afin de comprendre ce problème, même si on n'observe aucun un tel défaut.
Annexe
Chemin de diagnostic par test de bouclage du NP
L'application diagnostique qui exécute sur la CPU de linecard dépiste les santés du chaque NP avec les contrôles périodiques de l'état fonctionnant du NP. Un paquet est injecté de la CPU de linecard destinée aux gens du pays NP, que le NP devrait loop-back et retourner à la CPU de linecard. N'importe quelle perte en de tels paquets périodiques est signalée avec un message de log de plate-forme. 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 log signifie que ce test n'a pas reçu le paquet de bouclage de NP3. Le masque de panne de lien est 0x8 (mordu 3 est placé), qui indique une panne entre la CPU de linecard pour l'emplacement 7 et NP3 sur l'emplacement 7.
Afin d'obtenir plus de détails, collectez la sortie de ces commandes :
- détail du test 9 de l'emplacement 0/<x>/cpu0 de show diagnostic result d'admin
- emplacement 0/<x>/cpu0 du compteur NP<0-3> du NP de shows controllers
Commandes de debug de matrice
Les commandes répertoriées dans cette section appliquent à tous les linecards basés sur Trident aussi bien qu'au linecard 100GE basé sur Typhoon. La passerelle FPGA ASIC n'est pas présente sur les linecards basés sur Typhoon (excepté les linecards 100GE basés sur Typhoon). Ainsi, la FIA de matrice de show controller jettent un pont sur des commandes n'appliquent pas aux linecards basés sur Typhoon, excepté les versions 100GE.
Cette représentation imagée aide à tracer chaque commande show à l'emplacement dans le chemin de données. Employez ces commandes show afin d'isoler des pertes de paquets et des défauts.
CommentairesLaissez-nous vous aider
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)