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 cartes de ligne sur le routeur Internet de la gamme Cisco 12000.

Conditions préalables

Conditions requises

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

Components Used

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 un arrière-plan sur la façon d'identifier un plantage de carte de ligne.

Identifier un incident de carte de ligne

Afin d'identifier rapidement un plantage 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 non la carte de ligne uniquement), reportez-vous à Dépannage des pannes de routeur.

Collecte d'informations sur l'incident

Afin de collecter les données pertinentes sur le crash, 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 emplacement particulier : type de moteur, révisions matérielles, configuration de la mémoire, etc.
show context slot [slot #]	Fournit des informations contextuelles sur les incidents récents. Il s’agit souvent de la commande la plus utile pour dépanner les pannes de cartes de ligne.
core dump	Un vidage de coeur d'une carte de ligne est le contenu complet de sa mémoire au moment du crash. Ces données ne sont généralement pas nécessaires pour un dépannage initial. Il peut être nécessaire plus tard si le problème s'avère être un nouveau bogue logiciel. Dans ce cas, référez-vous à Configuration d'un vidage principal sur une carte de ligne GSR.

Si vous disposez de la sortie d'une commande show tech-support (à partir du mode enable) à partir de votre périphérique Cisco, vous pouvez utiliser pour afficher les problèmes potentiels et les correctifs. Pour 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 la sortie 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 - Rechercher l'erreur correspondant à la valeur SIG

Valeur SIG	Nom SIG	Motif de l'erreur
2	SIGNALER	Interruption matérielle inattendue.
3	SIGQUET	Abandonner en raison de la touche de coupure.
4	SIGNALER	Exception 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	SIGNALER	Exception réservée.
10	SIGBUS	Exception d'erreur de bus.
11	SIGSEGV	Exception SegV.
20	SIGCACHE	Exception de parité du cache.
21	SIGNATAIRE	Interruption de l'erreur de bus d'écriture.
22	SIGERREUR	Erreur matérielle fatale.
23	CHARGE SIGRENALE	Incendie forcé par logiciel.

Remarque : l'exception de parité du cache (SIG=20), l'exception d'erreur de bus (SIG=10) et les pannes forcées par logiciel (SIG=23) représentent plus de 95 % des pannes de cartes 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 dépanner les pannes matérielles et identifier la carte défectueuse.

L'option verbose entraîne l'affichage de la liste des tests par le routeur lors de leur exécution. Sinon, il affiche simplement un message « PASSED » ou « FAILURE ».

Remarque : L'exécution de 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 de la plate-forme logicielle Cisco IOS. Dans les versions précédentes, les diagnostics pouvaient être lancés à partir de la ligne de commande et l'image intégrée était lancée. Afin de répondre aux besoins des clients disposant de cartes mémoire Flash de 20 Mo, les diagnostics de champ de carte de ligne sont maintenant stockés et gérés comme une image distincte qui doit être disponible sur une carte mémoire Flash ou un serveur de démarrage TFTP (Trivial File Transfer Protocol) avant que les commandes de diagnostic sur site puissent être utilisées. Les diagnostics de champ du processeur de routeur et de la matrice de commutation continuent d'être regroupés et ne doivent pas ê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 de sortie de 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

Selon l'erreur rencontrée, le logement peut être rechargé automatiquement ou non. Si ce n'est pas le cas, il peut être 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 le SIG=20 dans la sortie show context [slot #].

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

Il existe deux types différents d'erreurs de parité :

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

• Erreurs de parité matérielle : ces erreurs se produisent en cas de défaillance d'une puce ou d'une carte qui provoque la corruption 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 un échange de carte. Il y a une erreur de parité difficile lorsque plusieurs erreurs de parité sont vues à 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 détectée dans une région de mémoire donnée dans un laps de temps relativement court (plusieurs semaines à plusieurs mois), cela peut être considéré comme une erreur de parité difficile.

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

Afin de dépanner ces erreurs, recherchez 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 défaillance, il est probable qu'il s'agisse d'une erreur de parité logicielle et que la carte de ligne n'a pas à être remplacée (à moins qu'elle ne tombe en panne une deuxième fois avec une erreur de parité après une courte période de temps).

Exceptions d'erreur de bus

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

Si vous disposez de la sortie d'une commande show tech-support (à partir du mode enable) à partir de votre périphérique Cisco, vous pouvez utiliser pour afficher les problèmes potentiels et les correctifs. Pour 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, il s'agit d'une toute 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.

Note : Certains bogues logiciels ont été connus pour provoquer la notification d'erreurs par la commande diag, même s'il n'y a aucun problème avec le matériel. Si une carte a déjà été remplacée, mais é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 version du logiciel Cisco IOS élimine tous les bogues corrigés qui provoquent des erreurs de bus de carte de ligne. Si le plantage 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 utiles (telles que les modifications récentes de la topologie ou une nouvelle fonctionnalité récemment implémentée) et contactez votre représentant du support Cisco.

Accidents logiciels forcés

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

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

La raison la plus courante pour les plantages forcés par logiciel est le délai d'attente du ping de la structure. Pendant le fonctionnement normal du routeur, le processeur de routage (RP) 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 (SIG=23) de la carte de ligne affecté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élais d'expiration des requêtes ping de fabric, vous devez savoir 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 CPU—ceci peut être vérifié à l'aide de la commande execute-on slot [slot #] show proc cpu. Si le CPU est très élevé (supérieur à 95 %), reportez-vous à la section Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco.

• Il y a des bogues logiciels dans IPC (Inter Process Communication) 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 série de versions du logiciel Cisco IOS élimine tous les bogues corrigés qui provoquent 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 crash), ainsi qu'une show tech-support, un état show ipc et toute information que vous pensez utile (comme une modification récente de la topologie ou une nouvelle fonctionnalité récemment implémentée) et contactez votre représentant du support 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 eu lieu, 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 affectée. Remplacer 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.Marvel de raison : TXECCERR Démarrage de la récupération automatique des erreurs

Une erreur TXECCERR/RXECCERR se produit lorsque l'interruption d'erreur ECC irrécupérable de RxFIFO ou TxFIFO survient dans MAC plus que 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 lors de 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.

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

Autres accidents

D'autres types de crash sont de loin moins courants 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 correctement le test de diagnostic, envisagez de mettre à niveau le logiciel.

Informations à collecter si vous ouvrez une demande de service TAC

Si vous avez encore besoin d'assistance après avoir suivi les étapes de dépannage ci-dessus et que vous souhaitez ouvrir une demande de service (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 le crash 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 d'un e-mail à attach@cisco.com avec votre numéro de demande de service dans la ligne d'objet de votre message. Remarque : Ne redémarrez pas manuellement le routeur ou ne le mettez pas hors tension avant de collecter les informations ci-dessus, sauf si cela est nécessaire pour résoudre un problème 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
• Support et documentation techniques - Cisco Systems