Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
Aucune spécification déterminée n'est requise pour ce document.
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.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Cette section fournit un arrière-plan sur la façon d'identifier un plantage 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.
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 crashCommande | 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é.
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 SIGValeur 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 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.
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).
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.
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.
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.
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.
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 : |
---|
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. |
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
23-Apr-2007 |
Première publication |