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

Introduction

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

Conditions préalables

Il n'y a aucune condition requise 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écifiquement conçu pour la haute disponibilité (HA) au niveau du réseau, du système et des processus. Il existe 3 raisons pour lesquelles un rechargement inattendu peut se produire sur un commutateur 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 s'est-il passé 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 démarrer, accédez à via la console, puis vérifiez s'il y a une sortie. 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 la 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 le 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.

Recommandation

1. Vérifiez les cordons d'alimentation de toutes les 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 la PDU.

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 a sa propre stratégie de haute disponibilité, y compris un minuteur de pulsation, une méthode de redémarrage et une tentative maximale de redémarrage avec état. 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 de haute disponibilité du processus est réinitialisée (NX-OS ne peut pas fonctionner pendant un redémarrage du processus) ou si le redémarrage du processus atteint son nombre maximal de tentatives.  

Recommandation

`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 de base est enregistré. Ouvrez un dossier de demande de service pour le confirmer. 

• Les fichiers principaux peuvent être décodés par un ingénieur TAC. 
• Pour ouvrir la demande de service, choisissez Product > Unexpected Reboot > Software Failure pour vous assurer que le dossier est ouvert 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

Les keepalives réguliers EOBC (Ethernet Out of Band Channel) sont placés entre le superviseur et les cartes de ligne. Les messages d'erreur que vous recevez 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 existe généralement trois raisons à l'échec d'un EOBC :

1. Congestion EOBC. Vous voyez plus d'1 carte de ligne EOBC perdue.
2. Logement du 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. 

Recommandation

1. Vérifiez si le processeur contient une carte de ligne affectée lors du rechargement.
2. Vérifiez si une autre carte de ligne subit une perte EOBC lors du rechargement.
3. Vérifiez si un déploiement vers le processeur BFD ou Netflow utilise des services récemment.
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 cette erreur 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.

Recommandation

Les erreurs de parité peuvent être des perturbations ponctuelles transitoires (SEU) ou être dues à un matériel défectueux. Pour déterminer de quel type il s'agit, vous devez surveiller le périphérique pendant 48 heures pour voir s'il se reproduit.

S'il n'y a pas de deuxième occurrence dans les 48 heures, le problème est considéré comme transitoire et aucune action n'est requise. Les erreurs de parité (matérielles) fréquentes ou reproductibles sont causées par un dysfonctionnement physique de la mémoire ou des circuits utilisés pour lire et écrire. 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 : erreurs corrigibles et 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 corrigables entraînent la perte de fiabilité d'une transaction particulière ou d'une liaison PCIE particulière. 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. 

Recommandation

C'est la même chose avec les erreurs de parité. S'il n'y a pas de deuxième occurrence dans les 48 heures, le problème est considéré comme transitoire, aucune action n'est requise. Des erreurs fréquentes ou reproductibles sont causées par des dysfonctionnements physiques. Dans ce cas, remplacez le matériel.

Délai de surveillance

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 chien de garde se trouvent généralement dans les systèmes intégrés et autres équipements contrôlés par ordinateur, où les utilisateurs ne peuvent pas facilement accéder à l'équipement ou ne seraient pas en mesure de réagir aux pannes en temps voulu. Le Nexus 9000 déploie une fonction de minuteur de chien de garde via FPGA. Cela permet de s'assurer que Nexus 9000 peut détecter le blocage logiciel et redémarrer le commutateur rapidement.

Recommandation

1. Vérifiez si des bogues logiciels connus ont un impact sur la version actuelle.
2. Si le problème se reproduit, collectez une trace 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. Le Nexus 9000 se recharge lors d'une mise à niveau.

Recommandation

Comportement attendu ; consultez le journal de gestion pour plus de détails sur la session 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 défauts peuvent provoquer un rechargement inattendu sur les commutateurs Nexus 9000. Pour vérifier si vous avez rencontré un bogue logiciel connu, ouvrez un dossier TAC.

ID de bogue Cisco	Titre du bogue	Corriger la version
ID de bogue Cisco CSCwd53591	Recharger en raison du délai d'attente Watchdog 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)

Historique de révision

Révision	Date de publication	Commentaires
2.0	05-Jun-2026	Mise à jour de l'orthographe, de la grammaire, de la structure des phrases et de l'espacement
1.0	07-Feb-2024	Première publication