Dépannage en cas de blocage de carte de ligne sur le routeur Internet de la gamme Cisco 12000

 

Introduction

Ce document fournit des informations sur la façon dont dépanner des crash de linecard sur le Routeur Internet de la série Cisco 12000.

Conditions préalables

Exigences

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

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Tous les Routeur Internet de la série Cisco 12000, y compris les 12008, 12012, 12016, 12404, 12406, 12410, et les 12416.

• Toutes les versions de logiciel de Cisco IOS® qui prennent en charge le Routeur Internet de la série Cisco 12000.

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.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Cette section fournit un fond sur la façon dont identifier un crash de linecard.

Identifiez un crash de linecard

Afin d'identifier rapidement un crash de linecard, employez la commande récapitulative de show context :

   Router#show context summary 
       CRASH INFO SUMMARY 
         Slot 0 : 0 crashes 
         Slot 1 : 0 crashes 
         Slot 2 : 0 crashes 
         Slot 3 : 0 crashes 
         Slot 4 : 1 crashes 
           1 - crash at 04:28:56 EDT Tue Apr 20 1999 
         Slot 5 : 0 crashes 
         Slot 6 : 0 crashes 
         Slot 7 : 0 crashes 
         Slot 8 : 0 crashes 
         Slot 9 : 0 crashes 
         Slot 10: 0 crashes 
         Slot 11: 0 crashes

Si le crash affecte le routeur lui-même (et pas le linecard seulement), référez-vous aux crash de routeur de dépannage.

Informations de rassemblement sur le crash

Afin de collecter les données appropriées au sujet du crash, utilisez les commandes affichées dans le tableau 1.

Tableau 1 – Commandes de utiliser pour collecter des données au sujet du crash

Commande	Description
show version	Fournit les informations générales au sujet du matériel et des configurations du logiciel de système.
show logging	Affiche les logs généraux du routeur.
show diag [emplacement #]	Fournit des informations spécifiques au sujet d'un emplacement particulier : type d'engine, révisions de matériel, configuration de mémoire, et ainsi de suite.
emplacement de show context [emplacement #]	Fournit les informations contextuelles au sujet des crash récents. C'est souvent la commande la plus utile pour dépannage des crash de linecard.
core dump	Un vidage de mémoire d'un linecard est le plein contenu de sa mémoire au moment du crash. Ces données ne sont normalement pas nécessaires pour un premier dépannage. Il peut exiger plus tard si le problème s'avère être une nouvelle erreur de programmation. Dans ce cas, référez-vous à configurer un vidage de mémoire sur un linecard GSR.

Si vous avez la sortie d'une commande de show tech-support (du mode enable) de votre périphérique de Cisco, vous pouvez utiliser pour afficher des éventuels problèmes et des difficultés. Afin d'utiliser , vous devez être un client enregistré, être ouvert une session, et faire activer le Javascript.

Analysez les données collectées

Vérifiez la valeur du champ de sig= dans l'emplacement de show context [slot#] sorti :

       Router#show context slot 4 
       CRASH INFO: Slot 4, Index 1, Crash at 04:28:56 EDT Tue Apr 20 1999 

       VERSION: 
       GS Software (GLC1-LC-M), Version 11.2(15)GS1a, EARLY DEPLOYMENT RELEASE 
       SOFTWARE (fc1) 
       Compiled Mon 28-Dec-98 14:53 by tamb 
       Card Type: 1 Port Packet Over SONET OC-12c/STM-4c, S/N CAB020500AL 
       System exception: SIG=20, code=0xA414EF5A, context=0x40337424 

       Traceback Using RA 
       STACK TRACE: 
         traceback 4014CFC0 40141AB8 40143944 4014607C 4014A7EC 401499D4 40149BB4 
       40149FD4 40080118 40080104 
       CONTEXT: 
       $0 : 00000000, AT : 40330000, v0 : 00000000, v1 : 00000038 
       a0 : 4094EF58, a1 : 00000120, a2 : 00000002, a3 : 00000001 
       t0 : 00000010, t1 : 3400BF01, t2 : 34008D00, t3 : FFFF00FF 
       t4 : 400A1410, t5 : 00000002, t6 : 00000000, t7 : 4041783C 
       s0 : 4093F980, s1 : 4093F980, s2 : 4094EEF0, s3 : 4094EF00 
       s4 : 00000000, s5 : 00000001, s6 : 00000000, s7 : 00000000 
       t8 : 34008000, t9 : 00000000, k0 : 404D1860, k1 : 400A2F68 
       gp : 402F3070, sp : 4082BFB0, s8 : 00000000, ra : 400826FC 
       EPC : 0x40098824, SREG : 0x3400BF04, Cause : 0x00000000 
       ErrorEPC : 0x4015B7E4

Voir le tableau 2 pour découvrir quelle raison d'erreur apparie la valeur de SIG que vous avez enregistrée.

Tableau 2 – Trouvez l'erreur qui apparie la valeur de SIG

Valeur de SIG	Nom de SIG	Raison d'erreur
2	Renseignement sur les transmissions	Interruption matérielle inattendue.
3	SIGQUIT	Arrêt dû à la touche d'interruption.
4	SIGILL	Exception de code d'opération illégal.
5	SIGTRAP	Abandonnez en raison du point d'arrêt ou d'une exception arithmétique.
8	SIGFPE	Exception de l'unité de virgule flottante (FPU).
9	SIGKILL	Exception réservée.
10	SIGBUS	Exception d'erreur de bus.
11	SIGSEGV	Exception de SegV.
20	SIGCACHE	Exception de parité en cache.
21	SIGWBERR	Écrivez l'interruption d'erreur de bus.
22	SIGERROR	Erreur matérielle fatale.
23	SIGRELOAD	Incident logiciel.

Remarque: L'exception de parité en cache (SIG=20), l'exception d'erreur de bus (SIG=10), et les incidents logiciels (SIG=23) expliquent plus de 95% de crash de linecard.

La commande EXEC de diag

La gamme Cisco 12000 prend en charge la commande de diag [slot#] pour tester les différents composants de la carte. Cette commande est utile pour dépanner des crash liés au matériel, et pour identifier la carte défectueuse.

L'option bavarde fait afficher le routeur la liste de tests pendant qu'ils sont exécutés. Autrement, il affiche simplement un message « PASSÉ » ou de « PANNE ».

Remarque: Exécuter ce diagnostics stop toutes les activités du linecard pour la durée des tests (habituellement environ cinq minutes).

Commençant par le Logiciel Cisco IOS version 12.0(22)S, Cisco a séparé l'image de carte de ligne de diagnostics sur site de Routeur Internet de la série Cisco 12000 de l'image de logiciel Cisco IOS. Dans les versions antérieures, des diagnostics pourraient être lancés de la ligne de commande et l'image incluse serait lancée. Afin de rendre service à des clients avec 20 cartes de mémoire flash de Mo, des diagnostics sur site de linecard sont maintenant enregistrés et mis à jour comme image distincte qui doit être disponible sur une carte de mémoire flash ou un serveur de démarrage de Protocole TFTP (Trivial File Transfer Protocol) avant que les commandes de diagnostics sur site puissent être utilisées. Des diagnostics sur site de matrice de processeur du routeur et de commutateur continuent à être empaquetés et n'ont pas besoin d'être lancés d'une image distincte. Vous pouvez trouver plus d'informations aux diagnostics sur site pour le Routeur Internet de la série Cisco 12000.

Voici un exemple d'une sortie de commande de diag [slot#] :

Router#diag 3 verbose 
Running DIAG config check 
Running Diags will halt ALL activity on the requested slot. 
[confirm] 
CR1.LND10# 
Launching a Field Diagnostic for slot 3 
Downloading diagnostic tests to slot 3 (timeout set to 400 sec.) 
Field Diag download COMPLETE for slot 3 
FD 3> ***************************************************** 
FD 3> GSR Field Diagnostics V3.0 
FD 3> Compiled by award on Tue Aug 3 15:58:13 PDT 1999 
FD 3> view: award-bfr_112.FieldDiagRelease 
FD 3> ***************************************************** 
FD 3> BFR_CARD_TYPE_OC48_1P_POS testing... 
FD 3> running in slot 3 (128 tests) 

Executing all diagnostic tests in slot 3 
(total/indiv. timeout set to 600/200 sec.) 
FD 3> Verbosity now (0x00000001) TESTSDISP 

FDIAG_STAT_IN_PROGRESS: test #1 R5K Internal Cache 
FDIAG_STAT_IN_PROGRESS: test #2 Burst Operations 
FDIAG_STAT_IN_PROGRESS: test #3 Subblock Ordering 
FDIAG_STAT_IN_PROGRESS: test #4 Dram Marching Pattern 
FDIAG_STAT_DONE_FAIL test_num 4, error_code 6 
Field Diagnostic: ****TEST FAILURE**** slot 3: last test run 4, 
Dram Marching Pattern, error 6 
Field Diag eeprom values: run 2 fail mode 1 (TEST FAILURE) slot 3 
last test failed was 4, error code 6 
Shutting down diags in slot 3 

slot 3 done, will not reload automatically

Selon l'erreur rencontrée, l'emplacement pourrait ou ne pourrait pas être automatiquement rechargé. S'il n'est pas, il pourrait être dans collé ou un état incohérent (contrôle avec la commande de show diag [emplacement #]) jusqu'à ce que manuellement rechargé. C'est normal. Afin de recharger manuellement la carte, employez la commande de recharge de hw-module slot [slot#].

Exceptions de parité en cache

Vous pouvez identifier des exceptions de parité en cache par le SIG=20 dans le show context [emplacement #] sorti.

Si vous avez la sortie d'une commande de show tech-support (du mode enable) de votre périphérique de Cisco, vous pouvez utiliser pour afficher des éventuels problèmes et des difficultés. Afin d'utiliser , vous devez être un client enregistré, être ouvert une session, et faire activer le Javascript.

Il y a deux genres différents d'erreurs de parité :

• Erreurs de parité logicielle — Celles-ci se produisent quand une force dans la puce (par exemple, celle ou un zéro) change. En cas d'erreur de parité logicielle, il n'y a aucun besoin de permuter le panneau ou les composants l'uns des.

• Erreurs de parité matérielle — Celles-ci se produisent quand il y a une puce ou une défaillance de carte qui causent des données d'être corrompues. Dans ce cas, vous devriez réinsérer ou remplacer le composant affecté, habituellement un échange de puces mémoire ou un échange de panneau. Il y a une erreur de parité matérielle quand des plusieurs erreurs de parité sont vues à la même adresse. Il y a des cas plus compliqués il est plus difficile de l'identifier que mais, généralement si plus d'une erreur de parité est vue en zone mémoire particulière dans relativement une courte période (plusieurs semaines aux mois), ceci peut être considéré une erreur de parité matérielle.

Les études ont prouvé que les erreurs de parité logicielle sont 10 à 100 fois plus fréquentes que des erreurs de parité matérielle.

Afin de dépanner ces erreurs, trouvez une fenêtre de maintenance pour exécuter la commande de diag pour cet emplacement.

• Si le diagnostic a comme conséquence une panne, remplacez le linecard.

• S'il n'y a aucune panne, il est susceptible d'être une erreur de parité logicielle, et le linecard ne doit pas être remplacé (à moins qu'il tombe en panne une deuxième fois avec l'erreur de parité après une courte période).

Exceptions d'erreur de bus

Vous pouvez identifier des exceptions d'erreur de bus par le SIG=10 dans le show context [emplacement #] sorti.

Si vous avez la sortie d'une commande de show tech-support (du mode enable) de votre périphérique de Cisco, vous pouvez utiliser pour afficher des éventuels problèmes et des difficultés. Afin d'utiliser , vous devez être un client enregistré, être ouvert une session, et faire activer le Javascript.

Ce type de crash est normalement lié au logiciel, mais si pour quelque raison (par exemple, c'est une carte toute neuve, ou le début de crash après qu'une panne de courant) vous pensez le problème pourrait être lié au matériel, exécutent la commande de diag pour cet emplacement.

Remarque: Quelques erreurs de programmation ont été connues pour entraîner la commande de diag de signaler des erreurs, quoiqu'il n'y ait aucun problème avec le matériel. Si une carte a été déjà remplacée, mais échoue toujours au même test dans le diagnostic, vous pourriez être affecté par cette question. Dans ce cas, traitez le crash comme problème logiciel.

L'évolution à la dernière version de votre logiciel Cisco IOS série de version élimine toutes les bogues fixes entraînant des erreurs sur le bus de linecard. Si le crash est encore présent après que la mise à jour, collectent les informations pertinentes (voir les informations de rassemblement sur le crash), avec un show tech-support, et n'importe quelles informations que vous pensez pourrait être utile (comme le changement de topologie récent, ou une nouvelle caractéristique récemment mise en application) et entrez en contact avec votre représentant de l'assistance technique Cisco.

Incidents logiciels

Vous pouvez identifier des incidents logiciels par le SIG=23 dans le show context [emplacement #] sorti. En dépit du nom, ces crash ne sont pas toujours liés au logiciel.

Si vous avez la sortie d'une commande de show tech-support (du mode enable) de votre périphérique de Cisco, vous pouvez utiliser pour afficher des éventuels problèmes et des difficultés. Afin d'utiliser , vous devez être un client enregistré, être ouvert une session, et faire activer le Javascript.

La raison la plus commune pour des incidents logiciels est le « test ping de matrice ». Pendant l'exécution normale de routeur, le processeur d'artère (RP) cingle continuellement les linecards. Si un linecard ne répond pas, le processeur d'artère décide de le remettre à l'état initial. Ceci a comme conséquence un incident logiciel (SIG=23) du linecard affecté, et vous devriez voir ces erreurs dans les logs du routeur :

Mar 12 00:42:48: %GRP-3-FABRIC_UNI: 
Unicast send timed out (4) 
Mar 12 00:42:50: %GRP-3-COREDUMP: Core dump incident on slot 4, error: Fabric ping failure

Afin de dépanner des tests pings de matrice, vous devez découvrir pourquoi le linecard n'a pas répondu au ping. Il peut y avoir de plusieurs causes :

• Le linecard éprouve l'utilisation du CPU élevé — Ceci peut être vérifié utilisant la commande CPU de show proc d'emplacement d'execute-on [emplacement #]. Si la CPU est vraiment élevée (au-dessus de 95%), référez-vous à l'utilisation du CPU élevé de dépannage sur des Routeurs de Cisco.

• Il y a des erreurs de programmation dans la transmission de processus inter (IPC) ou le linecard s'exécute hors des mémoires tampons IPC. Le plus souvent ces recharges logiciel-forcées sont provoqué par par des erreurs de programmation.

  L'évolution à la dernière version de votre logiciel Cisco IOS série de version élimine toutes les bogues fixes entraînant des tests pings de matrice. Si le crash est encore présent après que la mise à jour, collectent les informations pertinentes (voyez obtenir des informations sur le crash), avec un show tech-support, un état de show ipc, et n'importe quelles informations que vous pensez peut être utile (comme le changement de topologie récent, ou une nouvelle caractéristique récemment mise en application) et entrez en contact avec votre représentant de l'assistance technique Cisco.

• Défaillance matérielle — Si la carte a été bon courant pendant longtemps et aucune topologie récente, le logiciel, ou les modifications de caractéristique ont eu lieu, ou si les problèmes commencés après qu'un mouvement ou une panne de courant, matériel défectueux puisse être la cause. Exécutez la commande de diag sur le linecard affecté. Remplacez le linecard, si défectueux. Si les plusieurs linecards sont affectés ou le diag est bien, remplacez la matrice.

%GSRSPA-6-ERRORRECOVER : Une erreur matérielle ou logicielle s'est produite sur la merveille du subslot 0.Reason : Initié automatique de correction d'erreur TXECCERR

L'erreur TXECCERR/RXECCERR se produit quand l'interruption d'erreur irrémédiable de RxFIFO ou de TxFIFO ECC se produit dans le MAC davantage que la valeur seuil dans l'intervalle de temps. Des erreurs irrémédiables ECC ne peuvent pas être corrigées par la logique ECC. Quand une erreur irrémédiable se produit pendant le RxFIFO lisez, le paquet auquel les données appartiennent sont identifiées par EOP/Abort sur le SPI4 reçoivent l'interface et sont jetées par les couches supérieures.

C'est dû au matériel et est corrigé une fois que nous rechargeons le SIP/SPA. La solution permanente est de remplacer le SIP/SPA afin d'éviter les erreurs.

Autre tombe en panne

D'autres types de crash sont, de loin, moins communs que les deux mentionnés ci-dessus. Dans la plupart des cas, la commande de diag devrait indiquer si la carte doit être remplacée ou pas. Si la carte passe le test de diagnostic correctement, envisagez d'améliorer le logiciel.

Informations à collecter si vous ouvrez une demande de service TAC

Si vous avez besoin d'assistance après avoir suivi les étapes de dépannage ci-dessus et voulez toujours ouvrir une demande de service (clients enregistrés seulement) avec Cisco TAC, soyez sûr d'inclure les informations suivantes :

Dépannage exécuté avant d'ouvrir la demande de service. affichez la sortie de Soutien technique (dans le mode enable si possible). Sortie de la commande show log ou captures de console si disponibles. tech d'exposition d'emplacement d'execute-on [emplacement #] pour l'emplacement qui a éprouvé le crash de linecard. Reliez les données collectées à votre demande de service dans non-fermé la fermeture éclair, le format de texte brut (.txt). Vous pouvez joindre des informations à votre demande de service en les téléchargeant à l'aide de l'outil TAC Service Request (clients enregistrés uniquement). Si vous ne pouvez pas accéder à l'outil de demande de service, vous pouvez envoyer les informations dans une pièce jointe à un courriel à attach@cisco.com avec votre nombre de demande de service dans le champ objet de votre message. Remarque: Ne rechargez pas manuellement ou arrêt et redémarrage le routeur avant de collecter les informations ci-dessus à moins que requis pour dépanner un crash de linecard sur le Routeur Internet de la série Cisco 12000, en tant que ceci peut causer les informations importantes d'être perdu qui sont nécessaires pour déterminer l'origine du problème.

Informations connexes

• Résolution des problèmes de blocage de routeurs
• Configuration d'un core dump (image de mémoire) sur une carte de ligne GSR
• Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco
• Support et documentation techniques - Cisco Systems