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 de dépanner les pannes de carte de ligne sur le routeur Internet de la gamme Cisco 12000.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à 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 routeurs Internet de la gamme Cisco 12000, y compris les modèles 12008, 12012, 12016, 12404, 12406, 12410 et 12416.

• Toutes les versions du logiciel Cisco IOS® qui prennent en charge le routeur Internet de la gamme Cisco 12000.

The information in this document was created from the devices in a specific lab environment. 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.

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 des informations générales sur l'identification d'une panne de carte de ligne.

Identification d'une panne de carte de ligne

Afin d'identifier rapidement une panne de carte de ligne, utilisez la commande show context summary :

   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 la panne affecte le routeur lui-même (et pas seulement la carte de ligne), reportez-vous à la section Dépannage des pannes de routeur.

Collecte d'informations sur le crash

Afin de collecter les données pertinentes sur la panne, utilisez les commandes indiquées dans le Tableau 1.

Tableau 1 - Commandes à utiliser pour collecter des données sur le crash

Commande	Description
show version	Fournit des informations générales sur les configurations matérielles et logicielles du système.
show logging	Affiche les journaux généraux du routeur.
show diag [slot #]	Fournit des informations spécifiques sur un logement particulier : type de moteur, révisions matérielles, configuration de la mémoire, etc.
show context slot [slot #]	Fournit des informations contextuelles sur le ou les incidents récents. Il s'agit souvent de la commande la plus utile pour le dépannage des pannes de carte de ligne.
core dump	Une image mémoire d'une carte de ligne correspond au contenu complet de sa mémoire au moment de la panne. Ces données ne sont normalement pas nécessaires pour un dépannage initial. Il peut être nécessaire ultérieurement si le problème s'avère être un nouveau bogue logiciel. Dans ce cas, référez-vous à Configuration d'un Core Dump sur une carte de ligne GSR.

Si vous avez la sortie d'une commande show tech-support (à partir du mode enable) de votre périphérique Cisco, vous pouvez utiliser pour afficher les problèmes potentiels et les correctifs. Afin d'utiliser , vous devez être un client enregistré, être connecté et avoir JavaScript activé.

Analyser les données collectées

Vérifiez la valeur du champ sig= dans le résultat de la commande show context slot [slot#] :

       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

Reportez-vous au Tableau 2 pour savoir quel motif d'erreur correspond à la valeur SIG que vous avez enregistrée.

Tableau 2 - Recherche de l'erreur correspondant à la valeur SIG

Valeur SIG	Nom SIG	Motif de l'erreur
2	SIGNAL	Interruption matérielle inattendue.
3	SIGQUIT	Abandonner en raison d'une touche d'interruption.
4	SIGNAL	Exception d'opcode non autorisée.
5	SIGTRAP	Abandonner en raison d'un point d'arrêt ou d'une exception arithmétique.
8	SIGFPE	Exception FPU (Floating Point Unit).
9	SIGKILL	Exception réservée.
10	SIGBUS	Exception d'erreur de bus.
11	SIGSEGV	Exception SegV.
20	SIGCACHE	Exception de parité du cache.
21	SIGWBERR	Interruption d'erreur du bus d'écriture.
22	SIGERROR	Erreur matérielle irrécupérable.
23	CHARGE EN SIGNAUX	Blocage forcé du logiciel.

Remarque : les exceptions de parité du cache (SIG=20), les exceptions d'erreur de bus (SIG=10) et les pannes logicielles forcées (SIG=23) représentent plus de 95 % des pannes de carte de ligne.

La commande diag Exec

La gamme Cisco 12000 prend en charge la commande diag [slot#] pour tester les différents composants de la carte. Cette commande est utile pour le dépannage des pannes matérielles et pour identifier la carte défectueuse.

L'option verbose fait que le routeur affiche la liste des tests en cours d'exécution. Sinon, il affiche simplement un message "PASSED" ou "FAILURE".

Remarque : ce diagnostic arrête toutes les activités de la carte de ligne pendant la durée des tests (généralement environ cinq minutes).

À partir de la version 12.0(22)S du logiciel Cisco IOS, Cisco a dégroupé l'image de la carte de ligne de diagnostic du routeur Internet de la gamme Cisco 12000 de l'image du logiciel Cisco IOS. Dans les versions antérieures, les diagnostics pouvaient être lancés à partir de la ligne de commande et l'image intégrée était lancée. Afin de prendre en charge les clients disposant de cartes mémoire Flash de 20 Mo, les diagnostics de champ de carte de ligne sont désormais stockés et gérés comme une image distincte qui doit être disponible sur une carte mémoire Flash ou un serveur d'amorçage TFTP (Trivial File Transfer Protocol) avant que les commandes de diagnostic de champ puissent être utilisées. Les diagnostics de champ de matrice de commutation et de processeur de routeur continuent à être regroupés et n'ont pas besoin d'être lancés à partir d'une image distincte. Pour plus d'informations, consultez Diagnostics sur site pour les routeurs Internet de la gamme Cisco 12000.

Voici un exemple du résultat d'une commande 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

En fonction de l'erreur rencontrée, le logement peut être rechargé ou non automatiquement. Si ce n'est pas le cas, il peut être dans un état bloqué ou incohérent (vérifiez avec la commande show diag [slot #]) jusqu'à ce qu'il soit rechargé manuellement. This is normal. Afin de recharger manuellement la carte, utilisez la commande hw-module slot [slot#] reload.

Exceptions de parité du cache

Vous pouvez identifier les exceptions de parité de cache par SIG=20 dans la sortie show context [slot #].

Si vous avez la sortie d'une commande show tech-support (à partir du mode enable) de votre périphérique Cisco, vous pouvez utiliser pour afficher les problèmes potentiels et les correctifs. Afin d'utiliser , vous devez être un client enregistré, être connecté et avoir JavaScript activé.

Il existe deux types d'erreurs de parité :

• Erreurs de parité logicielle : ces erreurs se produisent lorsqu'un niveau d'énergie dans la puce (par exemple, un un ou un zéro) change. En cas d'erreur de parité logicielle, il n'est pas nécessaire d'échanger la carte ou l'un des composants.

• Erreurs de parité matérielle : ces erreurs se produisent en cas de défaillance d'une puce ou d'une carte qui entraîne l'altération des données. Dans ce cas, vous devez réinstaller ou remplacer le composant concerné, généralement un échange de puce mémoire ou de carte. Une erreur de parité matérielle se produit lorsque plusieurs erreurs de parité sont détectées à la même adresse. Il y a des cas plus compliqués qui sont plus difficiles à identifier mais, en général, si plus d'une erreur de parité est constatée dans une région mémoire particulière dans un laps de temps relativement court (plusieurs semaines à plusieurs mois), cela peut être considéré comme une erreur de parité dure.

Des études ont montré que les erreurs de parité souple sont 10 à 100 fois plus fréquentes que les erreurs de parité matérielle.

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

• Si le diagnostic entraîne une défaillance, remplacez la carte de ligne.

• En l'absence de panne, il s'agit probablement d'une erreur de parité logicielle et la carte de ligne n'a pas besoin d'être remplacée (sauf si elle tombe en panne une deuxième fois avec une erreur de parité après un court laps de temps).

Exceptions d'erreurs de bus

Vous pouvez identifier les exceptions d'erreur de bus par SIG=10 dans la sortie de show context [slot #].

Si vous avez la sortie d'une commande show tech-support (à partir du mode enable) de votre périphérique Cisco, vous pouvez utiliser pour afficher les problèmes potentiels et les correctifs. Afin d'utiliser , vous devez être un client enregistré, être connecté et avoir JavaScript activé.

Ce type de panne est normalement lié au logiciel, mais si pour une raison quelconque (par exemple, s'il s'agit d'une nouvelle carte ou si les pannes commencent après une panne de courant) vous pensez que le problème peut être lié au matériel, exécutez la commande diag pour ce logement.

Remarque : certains bogues logiciels sont connus pour entraîner la commande diag à signaler des erreurs, même s'il n'y a aucun problème avec le matériel. Si une carte a déjà été remplacée, mais qu'elle échoue toujours au même test dans le diagnostic, ce problème peut vous affecter. Dans ce cas, traitez la panne comme un problème logiciel.

La mise à niveau vers la dernière version de votre train de versions du logiciel Cisco IOS élimine tous les bogues corrigés causant des erreurs de bus de carte de ligne. Si le crash est toujours présent après la mise à niveau, collectez les informations pertinentes (voir Collecte d'informations sur le crash), ainsi qu'une show tech-support, et toutes les informations que vous pensez être utiles (telles qu'une modification de topologie récente, ou une nouvelle fonctionnalité récemment implémentée) et contactez votre représentant du support technique Cisco.

Blocages logiciels forcés

Vous pouvez identifier les plantages forcés par le logiciel en utilisant SIG=23 dans la sortie show context [slot #]. Malgré le nom, ces pannes ne sont pas toujours liées au logiciel.

Si vous avez la sortie d'une commande show tech-support (à partir du mode enable) de votre périphérique Cisco, vous pouvez utiliser pour afficher les problèmes potentiels et les correctifs. Afin d'utiliser , vous devez être un client enregistré, être connecté et avoir JavaScript activé.

La raison la plus courante des pannes logicielles est le « délai d'attente de la requête ping du fabric ». Pendant le fonctionnement normal du routeur, le processeur de routage envoie continuellement des requêtes ping aux cartes de ligne. Si une carte de ligne ne répond pas, le processeur de routage décide de la réinitialiser. Cela entraîne une panne logicielle forcée (SIG=23) de la carte de ligne concernée, et vous devriez voir ces erreurs dans les journaux 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 les dépassements de délai d'attente de ping de fabric, vous devez découvrir pourquoi la carte de ligne n'a pas répondu à la requête ping. Il peut y avoir plusieurs causes :

• La carte de ligne connaît une utilisation élevée du processeur ; vous pouvez le vérifier à l'aide de la commande execute-on slot [slot #] show proc cpu. Si le CPU est vraiment élevé (au-dessus de 95%), référez-vous à Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco.

• Il y a des bogues logiciels dans la communication inter-processus (IPC) ou la carte de ligne est à court de tampons IPC. La plupart du temps, ces rechargements forcés par logiciel sont causés par des bogues logiciels.

  La mise à niveau vers la dernière version de votre train de versions du logiciel Cisco IOS élimine tous les bogues corrigés causant des délais d'expiration des requêtes ping de fabric. Si le plantage est toujours présent après la mise à niveau, collectez les informations pertinentes (voir Obtention d'informations sur le plantage), ainsi qu'un show tech-support, un show ipc status, et toutes les informations que vous pensez être utiles (telles qu'une modification de topologie récente, ou une nouvelle fonctionnalité récemment implémentée) et contactez votre représentant du support technique Cisco.

• Défaillance matérielle : si la carte fonctionne correctement depuis longtemps et qu'aucune modification récente de la topologie, du logiciel ou des fonctionnalités n'a été effectuée, ou si les problèmes ont commencé après un déplacement ou une panne de courant, un matériel défectueux peut être la cause. Exécutez la commande diag sur la carte de ligne concernée. Remplacez la carte de ligne si elle est défectueuse. Si plusieurs cartes de ligne sont affectées ou si le diagnostic est correct, remplacez le fabric.

%GSRSPA-6-ERRORRECOVER : Une erreur matérielle ou logicielle s'est produite sur le sous-logement 0.Motif Marvel : TXECCERR Automatic Error recovery initio

L'erreur TXECCERR/RXECCERR se produit lorsque l'interruption d'erreur ECC irrécupérable RxFIFO ou TxFIFO se produit dans MAC au-delà de la valeur de seuil dans l'intervalle de temps. Les erreurs ECC irrécupérables ne peuvent pas être corrigées par la logique ECC. Lorsqu'une erreur irrécupérable se produit pendant la lecture RxFIFO, le paquet auquel les données appartiennent est marqué avec EOP/Abort sur l'interface de réception SPI4 et est rejeté par les couches supérieures.

Cela est dû au matériel et est corrigé une fois que nous avons rechargé le SIP/SPA. La solution permanente consiste à remplacer le SIP/SPA afin d'éviter les erreurs.

Autres plantages

D'autres types d'accidents sont, de loin, moins fréquents que les deux mentionnés ci-dessus. Dans la plupart des cas, la commande diag doit indiquer si la carte doit être remplacée ou non. Si la carte réussit le test de diagnostic correctement, pensez à mettre à niveau le logiciel.

Informations à collecter si vous ouvrez une demande de service TAC

Si vous avez toujours besoin d'aide après avoir suivi les étapes de dépannage ci-dessus et que vous souhaitez ouvrir une demande de service (pour les clients enregistrés uniquement) auprès du TAC Cisco, veillez à inclure les informations suivantes :

Dépannage exécuté avant d'ouvrir la demande de service. show technical-support output (en mode enable si possible). Sortie de la commande show log ou captures de console si disponibles. execute-on slot [slot # ] show tech pour le slot qui a subi la panne de la carte de ligne. Joignez les données collectées à votre demande de service au format texte brut (.txt) non compressé. 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 e-mail à attach@cisco.com avec votre numéro de demande de service dans la ligne d'objet de votre message. Remarque : ne rechargez pas manuellement le routeur ou ne le mettez pas hors tension puis sous tension avant de collecter les informations ci-dessus, sauf si cela est nécessaire pour dépanner une panne de carte de ligne sur le routeur Internet de la gamme Cisco 12000, car cela peut entraîner la perte d'informations importantes nécessaires pour déterminer la cause première 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
• Assistance et documentation techniques - Cisco Systems