Dépannage des rechargements inattendus ou des pannes sur Nexus 9000

Introduction

Ce document  ddécrit comment dépanner les rechargements inattendus ou les pannes sur les commutateurs Nexus 9000.

Conditions préalables

Il n'y a aucune exigence pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Comment le commutateur Nexus 9000 se casse

Cisco NX-OS est un système d'exploitation résilient spécialement conçu pour garantir une haute disponibilité au niveau du réseau, du système et des processus.

Trois raisons peuvent expliquer un rechargement inattendu sur le Nexus 9000 :

• Un processus dans l'espace utilisateur peut rencontrer un plantage.
• Un processus ou un composant matériel peut rencontrer un dépassement du délai d'attente ou une défaillance du heartbeat.

• Le noyau lui-même rencontre une condition irrécupérable et se bloque.

Données importantes pour le dépannage du rechargement et du blocage

• Date et heure exactes du rechargement.
• Que se passait-il avant le rechargement ? Des modifications de configuration ? Des changements d'échelle ? Des journaux sur le périphérique ? Un changement environnemental ? L'utilisation CPU/mémoire augmente-t-elle ?
• Une fois que le commutateur démarre et qu'il est stable, collectez et vérifiez la sortie. 
• Si le commutateur ne peut pas être activé, accédez à via la console, puis vérifiez si une sortie est disponible. Vérifiez également les DEL du commutateur. Vous trouverez des informations détaillées sur les DEL dans le guide d'installation du matériel. 

Raison de réinitialisation du système

N9K#show system reset-reason module 1
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 21301 usecs after Tue Jan 17 20:29:20 2023
Reason: Reset Requested due to Fatal Module Error
Service: ipfib hap reset
Version: 9.3(8)

Fichier principal

N9K#show cores
VDC  Module Instance  Process-name    PID      Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
A     B       C         D             E          2024-01-04 19:17:25
copy core://<module-number>/<process-id>[/instance-num]
copy core://B/E/C ftp://<address>/<directory>

Journaux intégrés

show logging onboard
show logging onboard kernel-trace
show logging onboard stack-trace
**************************************************************
STACK TRACE GENERATED AT Sun Sep 10 19:06:39 2023 CCT
**************************************************************
<snip>                                                                        >>>dumps kernel massages before reload
<0>[10925084.972289] [1694343998] sysServices Unexpected call in interrupt context, serviceId=824
<0>[10925084.980666] [1694343998] cctrl_set_card_offline - EOBC switch reset failed
<0>[10925084.987824] [1694343998] sysServices Unexpected call in interrupt context, serviceId=824
<0>[10925084.996200] [1694343998] cctrl_set_card_offline - EPC switch reset failed
<snip>
<4>[10925085.040600] [1694343998] Dumping interrupt statistics                >>>dump interrupt statictics
<4>[10925085.045928] [1694343998] CPU0 CPU1 
<4>[10925085.051732] [1694343998] 3: 0 0 axp_irq Armada Error Handler
<4>[10925085.059909] [1694343998] 4: 0 0 axp_irq Armada MBUS unit Error Handle
<4>[10925085.068957] [1694343998] 5: 1012335907 809985523 axp_irq axp_local_clockevent
<4>[10925085.077136] [1694343998] 8: 1260801154 0 axp_irq mv_eth
<4>[10925085.084108] [1694343998] 31: 11230 0 axp_irq mv64xxx_i2c
<4>[10925085.091508] [1694343998] 41: 7111 1 axp_irq serial
<4>[10925085.098471] [1694343998] 51: 2 0 axp_irq mv_xor.0
<4>[10925085.105602] [1694343998] 52: 2 0 axp_irq mv_xor.1
<4>[10925085.112760] [1694343998] 94: 1 0 axp_irq mv_xor.2
<4>[10925085.119890] [1694343998] 95: 1 0 axp_irq mv_xor.3
<4>[10925085.127029] [1694343998] 107: 0 0 axp_irq axp-temp
<4>[10925085.134200] [1694343998] 168: 0 0 axp_irq cctrl_mrv_nmi_irq
<4>[10925085.142134] [1694343998] 195: 29 0 axp_msi_irq cctrl_sc_msi_irq
<4>[10925085.150225] [1694343998] 196: 0 2399172865 axp_msi_irq linux-kernel-bde
<4>[10925085.158325] [1694343998] IPI0 : 0 0 Timer broadcast interrupts
<4>[10925085.166130] [1694343998] IPI1 : 1711470501 3532640372 Rescheduling interrupts
<4>[10925085.173672] [1694343998] IPI2 : 0 0 Function call interrupts
<4>[10925085.181302] [1694343998] IPI3 : 44582 118572 Single function call interrupts
<4>[10925085.189541] [1694343998] IPI4 : 0 0 CPU stop interrupts
<4>[10925085.196734] [1694343998] PMU: : 0 0 
<4>[10925085.202186] [1694343998] Err : 0

show logging onboard exception-log                               >>>Check if any exception is raised before reload

Journal des processus

N9K# show processes log details                                  >>>detail process memory usage prior to crash
Service: ethpm
Description: Test Ethernet Port Manager
Executable: /isan/bin/ethpm

Started at Wed Jun 5 18:20:46 2023 (251615 us)
Stopped at Sat Jun 8 00:08:53 2023 (661042 us)
Uptime: 2 days 5 hours 48 minutes 7 seconds

Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Last heartbeat 48.10 secs ago
System image name: 
System image version: 7.0(3)I7(6)
PID: 28914 
Exit code: signal 5 (core dumped)
CWD: /var/sysmgr/work
RLIMIT_AS: 1019819820                                             >>>limit memory usage
Virtual Memory:
CODE 1007E000 - 1068DBD4
DATA 1068E000 - 106DC3E8
BRK 1194F000 - 11CF9000
STACK FFA28650
TOTAL 576004 KB                                                   >>>memory usage before crash

Fichiers journaux de Logflash

Il y a un logflash intégré sur Nexus 9000, les fichiers journaux survivent après le rechargement.

N9K#dir logflash:log | grep messages
3714961 Jan 13 18:05:31 2024 messages
4194331 Jan 13 17:30:14 2021 messages.1
5497842 May 11 15:59:00 2021 messages.2
4194341 Jul 30 07:25:36 2022 messages.3
4194510 Feb 09 14:50:50 2023 messages.4
4194426 Jun 04 05:00:40 2023 messages.5

N9K#show file logflash:log/messages
N9K#show file logflash:log/messages.1
N9K#show file logflash:log/messages.2
N9K#show file logflash:log/messages.3
N9K#show file logflash:log/messages.4
N9K#show file logflash:log/messages.5

Raisons courantes de réinitialisation

Rechargement lié à l'alimentation

N9K#show system reset-reason 
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 280125 usecs after Fri Aug 4 02:01:14 2023
Reason: Module PowerCycled
Service: HW check by card-client
Version: 

Explication

Le commutateur Nexus 9000 prend en charge la redondance d'alimentation N+1. En cas de panne de courant sur la plupart ou la totalité des sources d'alimentation, un rechargement se produit.

Recommandé :

1. Vérifiez les cordons d'alimentation des alimentations.

2. Vérifiez si d'autres périphériques partageant le même circuit d'entrée ont également subi une panne.

3. Vérifiez si une alarme liée à l'alimentation est présente sur le Nexus 9000 ou l'unité d'alimentation.

Blocage du processus

N9K#show system reset-reason module 1
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) 
1) At 21301 usecs after Tue Jan 17 20:29:20 2023 
Reason: Reset Requested due to Fatal Module Error 
Service: ipfib hap reset                                              >>>ipfib process reset
Version: 9.3(8)

Explication

Chaque service dispose de sa propre stratégie de haute disponibilité, notamment un minuteur de pulsation, une méthode de redémarrage et un redémarrage avec état (nombre maximal de tentatives). Le logiciel Cisco NX-OS permet des redémarrages avec état de la plupart des processus et services. Le rechargement se produit si la stratégie du processus est réinitialisée (NX-OS ne peut pas fonctionner pendant le redémarrage du processus) ou si les heures de redémarrage du processus atteignent le nombre maximal de tentatives.  

Recommandé

`show cores`
VDC  Module  Instance  Process-name     PID       Date(Year-Month-Day Time)
---  ------  --------  ---------------  --------  -------------------------
1    1       1         ipfib            27446     2023-01-17 20:30:30   
copy core://1/27446/1 ftp://<address>/<directory>

La plupart des pannes de processus sont des défauts logiciels et le fichier principal est enregistré. Ouvrez un dossier de demande de service pour le confirmer. 

• Les fichiers principaux peuvent être décodés par l'ingénieur TAC. 
• Pour ouvrir la demande de service, sélectionnez Product > Unexpected Reboot > Software Failure pour ouvrir le dossier avec la bonne équipe.

Défaillance EOBC

2018 Jan 21 01:56:42.789 N9K#%KERN-0-SYSTEM_MSG: [4590707.849157] [1516460202] EMON: module 2 is not responding on EOBC path. Reloading module. - kernel
2018 Jan 21 01:56:43.071 N9K#%MODULE-2-MOD_DIAG_FAIL: Module 2 (Serial number: xxxxxxxxxx) reported failure due to EOBC heartbeat failure in device DEV_EOBC_MAC (device error 0xc0a1b137)

Explication

L'EOBC est l'abréviation d'Ethernet Out of Band Channel. Des messages de test d'activité réguliers sont échangés entre le superviseur et les cartes de ligne. Les messages d'erreur que vous avez reçus indiquent qu'une pulsation a disparu entre SUP et la carte de ligne. Si un seul battement de coeur disparaît, il peut être ignoré automatiquement. Toutefois, si plusieurs pulsations sont perdues simultanément, la carte de ligne est réinitialisée.

Il y a généralement 3 raisons à l'échec EOBC :
1. Congestion EOBC. Vous pouvez voir plus d'1 expérience de carte de ligne EOBC perdu.
2. Porte-processeur dans un ou plusieurs modules spécifiques. Le processeur de la carte de ligne/superviseur est occupé et ne peut pas traiter les messages EOBC. Une amélioration logicielle a été apportée à partir de Nexus 9000 à partir de la version 7.0(3)I7(3). 
3. Défaillance matérielle. 

Recommandé

1. Vérifiez si un CPUhog pour la carte de ligne impactée autour du rechargement.

2. Vérifiez si d'autres cartes de ligne subissent une perte EOBC lors du rechargement. 

3. Vérifiez si le BFD ou le processeur Netflow déployé a récemment consommé le service. 

4. Si cela se produit plusieurs fois sans aucune information, remplacez le matériel. 

Erreur de parité

N9K#show logging onboard stack-trace
**************************************************************
        STACK TRACE GENERATED AT Tue Sep 21 02:27:58 2021 UTC
**************************************************************
<0>[88302546.800770] [1632158876] ERROR: MACHINE: Uncorrectable
<0>[88302546.809202] [1632158876] L2CACHE ERROR: Cause 0x88
<0>[88302546.814368] [1632158876] TAG Parity Error                           >>>>>Parity error
<0>[88302546.818750] [1632158876] Kernel panic - not syncing: L2CACHE ERROR
<4>[88302546.825212] [1632158876] Cpu: 0 Pid: 0, comm:            swapper/0

Explication

Une erreur de parité se produit lorsqu'un bit d'information est basculé de 1 à 0 ou de 0 à 1.

La plupart des erreurs de parité sont causées par des conditions environnementales électrostatiques ou magnétiques. Ces événements se produisent de manière aléatoire et ne peuvent pas être évités.

Les systèmes détectent que cette erreur s'est produite et forcent le système à se bloquer pour empêcher le traitement de données incorrectes. Une occurrence ne signifie pas qu'il y a un problème matériel ou logiciel.

Recommandé

Les erreurs de parité peuvent être des perturbations ponctuelles transitoires (SEU), ou elles peuvent être causées par un matériel défectueux. Pour déterminer ce qui se produit, vous devez surveiller le périphérique pendant 48 heures pour voir s'il se reproduit.

Si aucune seconde occurrence n'a lieu dans les 48 heures, le problème est considéré comme transitoire et aucune action n'est nécessaire. 

Les erreurs de parité (matérielles) fréquentes ou reproductibles sont dues à un dysfonctionnement physique de la mémoire ou des circuits utilisés pour la lecture et l'écriture. Dans ce cas, remplacez le matériel.

Erreur PCIE

N9K#show logging onboard stack-trace
<6>[  105.196227]     CCTRL PANIC DUMP
<6>[  105.196229] =========================
<6>[  105.196231] WDT last punched at 105192052644
<6>[  105.196234] REG(0x60) = 3c
<6>[  105.196238] REG(0x64) = 0
<6>[  105.196241] REG(0x300) = baadbeef
<6>[  105.196245] REG(0x304) = baadbeef
<6>[  105.196246] =========================
<0>[  105.197303] nxos_panic: Kernel panic - not syncing: PCIE Uncorrectable error   >>>>>PCIE Uncorrectable error

Explication

Les erreurs PCIE sont classées en deux types : les erreurs corrigibles et les erreurs non corrigibles. Cette classification est basée sur l'impact de ces erreurs, qui se traduit par une dégradation des performances ou une défaillance des fonctions.

Les erreurs corrigibles n’ont aucune incidence sur la fonctionnalité de l’interface. Le protocole PCIE peut être restauré sans intervention logicielle ni perte de données. Ces erreurs sont détectées et corrigées par le matériel.

Les erreurs non corrigibles affectent le fonctionnement de l’interface. Des erreurs non corrigées peuvent rendre une transaction particulière ou une liaison PCIE particulière non fiable. En fonction de ces conditions d'erreur, les erreurs non corrigibles sont classées en erreurs non fatales et en erreurs fatales. Des erreurs non fatales entraînent la non-fiabilité de la transaction particulière, mais la liaison PCIE elle-même est entièrement fonctionnelle. En revanche, des erreurs fatales entraînent la perte de fiabilité de la liaison.

Le Nexus 9000 détecte les erreurs PCIE fatales et force le rechargement du système pour empêcher le traitement de données incorrectes. 

Recommandé

Identique avec erreur de parité. 

Si aucune seconde occurrence n'a lieu dans les 48 heures, le problème est considéré comme transitoire et aucune action n'est nécessaire. 

Les erreurs fréquentes ou répétables sont dues à un dysfonctionnement physique. Dans ce cas, remplacez le matériel.

Dépassement du délai du chien de garde

N9K#show system reset-reason
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 88659 usecs after Mon Sep 24 18:33:04 2023
   Reason: Watchdog Timeout
   Service:
   Version: 7.0(3)I7(9)

Explication

Les minuteurs de surveillance sont couramment utilisés dans les systèmes intégrés et autres équipements contrôlés par ordinateur, où les humains ne peuvent pas facilement accéder à l'équipement ou ne pourraient pas réagir aux défaillances en temps opportun.
Le Nexus 9000 déploie une fonction de temporisation de surveillance via FPGA. Cela permet de s'assurer que Nexus 9000 peut détecter le blocage logiciel et redémarrer le commutateur rapidement.

Recommandé

1. Vérifiez si des bogues logiciels connus ont un impact sur la version actuelle.

2. Si le problème se reproduit, collectez le suivi du noyau et toutes les données de journalisation supplémentaires.

3. Ouvrez un dossier de demande de service.

Rechargement manuel en raison de la CLI ou de la mise à niveau

N9K# show system reset-reason
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 343832 usecs after Sat Jan 13 17:58:53 2024
Reason: Reset Requested by CLI command reload
Service: 
Version: 10.2(5)
>
4) At 282886 usecs after Fri Jan 12 07:42:33 2024
Reason: Reset due to upgrade
Service: 
Version: 10.3(4a)                >>>>>version prior to upgrading

Explication

Par défaut, les commutateurs Nexus 9000 prennent en charge les mises à niveau et les rétrogradations logicielles. Nexus 9000 se recharge pendant la mise à niveau.

Recommandé

Comportement attendu. Consultez le journal de gestion pour plus de détails sur les sessions CLI. 

Exemple de rechargement CLI :

Sat Jan 13 17:58:40 2024:type=update:id=console0:user=admin:cmd=reload (REDIRECT)
Sat Jan 13 17:58:47 2024:type=update:id=console0:user=admin:cmd=Rebooting the switch

Exemple de rechargement de mise à niveau :

Fri Jan 12 07:35:52 2024:type=update:id=console0:user=admin:cmd=install all nxos bootflash:/nxos64-cs.10.2.5.M.bin (SUCCESS)

ID de bogue Cisco

Certains des défauts peuvent provoquer un rechargement inattendu sur les commutateurs Nexus 9000. Pour confirmer si vous avez rencontré un bogue logiciel connu, ouvrez un dossier TAC.

ID de débogage Cisco	Titre du bogue	Corriger la version
ID de bogue Cisco CSCwd53591	Recharger en raison du délai d'attente de chien de garde sans coeurs/traces	9.3(13)
ID de bogue Cisco CSCvz65993	tahoe0 désactivé, ce qui entraîne une panne de connectivité intrabande	9.3(9)
ID de bogue Cisco CSCvs00400	Panique et rechargement du noyau en raison du délai de surveillance après les battements de liaison	9.3(3) et 7.0(3)I7(8)
ID de bogue Cisco CSCvr57551	Cisco Nexus 9000 se recharge avec Kernel panic - impossible de traiter la requête de pagination du noyau	7.0(3)I7(8) et 9.3(4)
ID de bogue Cisco CSCvo86286	Panique du noyau observée sur 7.0(3)I7(x) avec les cartes de ligne Nexus 9500 1ère génération	7,0(3)I7(7)
ID de bogue Cisco CSCvx38752	Fuite de mémoire entraînant le rechargement de « ipfib » par Nexus 9k	7.0(3)I7(9) et 9.3(2)
ID de bogue Cisco CSCvh13039	Rechargements LC/FM en raison du battement de coeur EOBC en tant que minuteur de service CPU occupé	7.0(3)I4(8) et 7.0(3)I7(3)