Dépannage des problèmes matériels et d'architecture courants dans les commutateurs Nexus 7000

Introduction

Ce document fournit une brève explication et des solutions pour les problèmes matériels et architecturaux courants pour les commutateurs Cisco Nexus 7000 qui exécutent le logiciel système Cisco NX-OS.

Note: Le format précis des messages syslog et des messages d'erreur décrits dans ce document peut varier légèrement. La variation dépend de la version de logiciel qui fonctionne sur Supervisor Engine.

Problème : Échec de SpineControlBus

Le test de contrôle de colonne vertébrale échoue pour le superviseur Nexus 7000 :

Nexus7000# show module internal exceptionlog module 5
...
System Errorcode  : 0x418b0022 Spine control test failed
Error Type        : Warning
PhyPortLayer      : 0x0
Port(s) Affected  : none
Error Description : Module 10 Spine Control Bus test Failed
...
         11) SpineControlBus E
                Error code ------------------> DIAG TEST ERR DISABLE
                Total run count -------------> 1597800
                Last test execution time ----> Mon May 27 21:57:17 2013
                First test failure time -----> Sun Nov 20 00:30:55 2011
                Last test failure time ------> Mon May 27 21:57:17 2013
                Last test pass time ---------> Mon May 27 21:56:47 2013
                Total failure count ---------> 33
                Consecutive failure count ---> 1
                Last failure reason ---------> Spine control test failed

Solution

Ce problème est lié à l'ID de bogue Cisco CSCuc72466. Reportez-vous à la FAQ Nexus 7000 : Quelle est l'action recommandée lorsque le test SpineControlBus échoue ?.

Problème : Blocs incorrects trouvés sur la mémoire NVRAM

Les erreurs NVRAM apparaissent dans les événements de diagnostic :

Nexus7000#show diagnostic events
1) Event:E_DEBUG, length:97, at 9664 usecs after Wed Dec  5 01:03:42 2012
    [103] Event_ERROR: TestName->NVRAM TestingType->health monitoring module->5 
Result->fail Reason->
#show diagnostic result module 5 test NVRAM detail
 4) NVRAM-------------------------> E
                Error code ------------------> DIAG TEST ERR DISABLE
                Total run count -------------> 52596
                Last test execution time ----> Wed Dec  5 01:03:41 2012
                First test failure time -----> Tue Dec  4 23:28:45 2012
                Last test failure time ------> Wed Dec  5 01:03:42 2012
                Last test pass time ---------> Tue Dec  4 23:23:41 2012
                Total failure count ---------> 20
                Consecutive failure count ---> 20
                Last failure reason ---------> Bad blocks found on nvram

Il s'agit d'un problème matériel, d'une défaillance du Supervisor Engine ou d'un problème temporaire.

Solution

1. Réexécutez le test NVRAM afin de voir s'il s'agit d'une fausse alarme. Entrez ces commandes afin de désactiver et réactiver le test de diagnostic (par exemple, si indiqué pour le module de problème 5) :
   • Pas de mémoire NVRAM de test du module 5 du moniteur de diagnostic
   • diagnostic monitor module 5 test NVRAM

   Entrez la commande show diagnostic result module 5 test NVRAM detail afin de voir les résultats de la commande test.

2. Si le test NVRAM échoue à nouveau, réinsérez le module 5. Observez le résultat des commandes show diagnostic result module 5 et show module.
3. Si le module échoue à nouveau, lancez une demande d'autorisation de retour de matériel (RMA) pour le superviseur dans l'emplacement du problème.

Problème : Panne de mémoire Compact Flash du module 9

L'une ou l'autre de ces options est visible sur le Supervisor 2/Supervisor 2E :

• Message d'erreur :

  DEVICE_TEST-2-COMPACT_FLASH_FAIL: Module 5 has failed test CompactFlash 
  20 times on device Compact Flash due to error The compact flash power test failed.

• Impossible d'enregistrer la configuration.
• Échecs de test de diagnostic :

         Test results: (. = Pass, F = Fail, I = Incomplete,
         U = Untested, A = Abort, E = Error disabled) 
         7) CompactFlash E 
                 Error code ------------------> DIAG TEST ERR DISABLE
                 Total run count -------------> 23302
                 Last test execution time ----> Sun Apr 13 10:07:30 2014
                 First test failure time -----> Sun Apr 13 00:37:41 2014
                 Last test failure time ------> Sun Apr 13 10:07:40 2014
                 Last test pass time ---------> Sun Apr 13 00:07:41 2014
                 Total failure count ---------> 20
                 Consecutive failure count ---> 20
                 Last failure reason ---------> The compact flash power test
                                                 failed
                 Next Execution time ---------> Sun Apr 13 10:37:30 2014

Cause première

Les superviseurs Nexus 7000 de deuxième génération sont livrés avec deux flashs eUSB identiques pour la redondance. Les flashs fournissent un référentiel pour bootflash, les configurations et d'autres informations pertinentes. Ces deux flashs sont reconfigurés comme une baie RAID (Redundant Array of Independent Disks) 1 qui implémente la mise en miroir interne. Avec la redondance, un superviseur peut fonctionner avec la perte d'un des flashs, mais pas les deux.

Il y a quelques cas dans le champ où l'un ou les deux de ces flashs sont marqués comme défectueux par le logiciel RAID sur une période de plusieurs mois ou années de service. Une réinitialisation/redémarrage de la carte redécouvre que ces clignotements défaillants sont sains au prochain démarrage.

Solution

Complétez ces étapes afin de vérifier s'il s'agit ou non d'un problème matériel :

1. Rechargez le superviseur du problème, si possible.
2. Si le problème est détecté après le rechargement, vous devez remplacer le matériel.
3. Si le problème est résolu par reload, la cause racine est liée à l'ID de bogue Cisco CSCus22805.

Problème : Échec du test de bouclage de port de carte de ligne N7K-M132XP-12

La carte de ligne signale un échec de diagnostic en raison d'un échec de test PortLoopback 10 fois consécutif :

DIAG_PORT_LB-2-PORTLOOPBACK_TEST_FAIL  Module:16 Test:PortLoopback
 failed 10 consecutive times. Faulty module:Module 16 affected ports:5,7  
Error:Loopback test failed. Packets lost on the LC at the Queueing engine ASIC

MODULE-4-MOD_WARNING  Module 16 (serial: XXXX) reported warning on 
ports 16/5-16/5 (Ethernet) due to Loopback test failed.  
Packets lost on the LC at the Queueing engine ASIC in device 78 
(device error 0x41830059)

Cause première

Il s'agit d'un message d'avertissement et, dans la plupart des cas, indique un problème matériel avec le port.

Solution

Vérifiez d'abord l'ID de bogue Cisco CSCtn81109 et l'ID de bogue Cisco CSCti95293, car il peut s'agir d'un problème logiciel.

Réinitialisez d'abord le module afin de réinitialiser la carte et réexécutez les tests de bon fonctionnement du matériel de démarrage. Si les tests de diagnostic indiquent toujours une défaillance pour la même carte, remplacez la carte.

Rechargez la carte à un moment opportun et collectez les sorties de ces commandes :

• show logging log
• show module
• show diagn result module all detail

Vous pouvez également réexécuter uniquement ce test spécifique et ne pas avoir besoin de recharger la carte. Cet exemple montre le module 16 :

show diagnostic result module 16
diagnostic clear result module all
(config)# no diagnostic monitor module 16 test 5
(config)# diagnostic monitor module 16 test 5
diagnostic start module 16 test 5
show diagnostic result module 16 test 5

Problème : MODULE N7K-M132XP-12 Carte de ligne-4-MOD_WARNING

Ces erreurs apparaissent et il est possible de recharger le module :

2013 Mar 27 00:40:23 DC3-7000-PRODD2-A23  MODULE-4-MOD_WARNING  
Module 9 (serial: XXX) reported warning on ports 9/1-9/3 (Unknown) 
due to BE2 Arbiter experienced an error in device 65 (device error 0xc410f613)

Cause première

Il s'agit d'une défaillance matérielle causée par des erreurs de parité ou des problèmes matériels sur la carte fille.

Solution

1. Vérifiez le résultat de ces commandes :
   • show version
   • show system reset-Raison module X
   • show logging onboard internal reset-Raison
   • show module internal event-history module X
   • show log
2. Si votre version de Cisco NS-OX est antérieure à la version 4.2, mettez à niveau vers une nouvelle version afin de s'assurer que les correctifs de ces défauts logiciels sont intégrés (minimisant la possibilité d'erreurs de parité) :
   • ID de bogue Cisco CSCso72230 L1 D-cache activé 8541 pannes de CPU avec les erreurs de parité de D-cache L1
   • ID de bogue Cisco CSCsr90831 - L1 D-cache activé 8541 pique le processeur avec les erreurs de parité de poussée de la mémoire cache D L1
3. Si les erreurs se produisent à plusieurs reprises, réinsérez la carte et le moniteur.
4. Si les erreurs se répètent, remplacez le module de problème.

Défaut logiciel supplémentaire connu

ID de bogue Cisco CSCtb98876

Problème : Erreur de perte de synchronisation de N7K-M224XP-23L chico serdes

Ces erreurs apparaissent sur le module :

%MODULE-4-MOD_WARNING: Module # (Serial number: XXXX) reported warning 
Ethernet#/# due to chico serdes sync loss in device DEV_SKYTRAIN 
(device error 0xc9003600)

Cause première

Ces erreurs indiquent qu'il existe un problème de perte de synchronisation entre le module # et le Xbar/ASIC. Dans la plupart des cas, la cause est une défaillance matérielle du module.

Si votre version de Cisco NS-OX est antérieure à la version 6.1(4) et que le message n'apparaît pas en permanence, il peut être affecté par l'ID de bogue Cisco CSCud91672. La cause du défaut est que les paramètres des serdes NX-OS sont différents des paramètres de diagnostic sur les deux canaux entre SKT <—>SAC.

Solution

Collectez les résultats de ces commandes :

• show version
• show module
• Commande show run
• show module internal event-history module X
• show module internal Activity Module X
• show module internal exception-log module X
• show module internal event-history errors
• show logging last 200
• show logging nvram

Mettez à niveau le commutateur vers NS-OX Version 6.1(4) ou ultérieure afin d'isoler la cause du défaut.

Effectuez ce test afin de confirmer si la carte est défectueuse au lieu du logement xbar ou du châssis :

1. Déplacez le module problématique vers un autre emplacement libre dans le châssis.
2. Si vous disposez d'un module de rechange, insérez-le dans un logement défectueux.
3. Si les erreurs ne sont pas détectées après l'étape 1, réinsérez le module dans l'emplacement du problème et vérifiez.

Problème : Échecs des tests N7K-F248XP-25 PrimaryBootROM et SecondaryBootROM

Le module N7K-F248XP-25 échoue dans les tests PrimaryBootROM et SecondaryBootROM :

show module internal exceptionlog module 1 | i Error|xception
********* Exception info for module 1 ********
exception information --- exception instance 1 ----
Error Description : Secondary BootROM test failed
 
exception information --- exception instance 2 ----
Error Description : Primary BootROM test failed

Cause première

Ceci est généralement observé en raison d'une corruption de fichiers BIOS ou d'une défaillance matérielle de la carte de ligne.

Solution

L'ID de bogue Cisco CSCuf82089 ajoute du code pour afficher des informations plus descriptives sur de telles défaillances pour de meilleurs diagnostics. Par exemple, il affiche un composant en échec au lieu d'une valeur actuellement nulle.

Dans certains cas, le problème est causé par une corruption du BIOS sur le module. Entrez la commande install module X bios forcée afin de résoudre ceci. Notez que cette commande peut avoir un impact potentiel sur le service. Il est recommandé de l'exécuter uniquement pendant une période de maintenance.

Complétez ces étapes afin de résoudre le problème :

1. Programmez une fenêtre de maintenance et entrez la commande install module X bios forcée comme solution de contournement possible. Entrez cette commande uniquement lors d'une fenêtre de maintenance afin d'éviter tout impact potentiel sur le service.
2. Si l'étape 1 n'aide pas ou s'il n'est pas possible d'avoir une fenêtre de maintenance pour cette action, remplacez le module. Cet exemple de sortie montre une tentative échouée :

Nexus7000# install module 1 bios forced
Warning: Installing Bios forcefully...!
Warning: Please do not remove or power off the module at this time
Upgrading primary bios
Started bios programming .... please wait
[#                            0%                             ]
BIOS install failed for module 1, Error=0x40710027(BIOS flash-type verify failed)
BIOS is OK ...
Please try the command again... 

Problème : Panne du capteur de température

Cette erreur est visible sur la plate-forme :

%PLATFORM-4-MOD_TEMPFAIL: Module-2 temperature sensor 7 failed

Cause première

Il s'agit d'un problème intermittent avec le bloc température/tension de l'ASIC dans certaines conditions en raison de la synchronisation interne de l'ASIC. L'ID de bogue Cisco CSCtw79052 décrit la cause connue de ce problème.

Il s'agit d'un problème de synchronisation entre l'ASIC qui verrouille la température en interne et le logiciel qui échantillonne le bit valide. Le problème est qu'il peut frapper n'importe laquelle des 12 instances Clipper. Il n'y a pas de déclencheur particulier pour ce problème et il est intermittent. Ce problème n'a pas d'impact sur le service et il survient parce que la logique de lecture de la température a un problème qui nécessite plus de tentatives dans le pilote.

Solution

Récupérez les résultats de ces commandes et vérifiez l'ID de bogue Cisco CSCtw79052 :

• show version
• show env therm
• show sprom module <module n°> 
• Nexus# module d'attachement <module #>
• <module#>#show hardware internal capteur event-history errors

Problème : Erreur Xbar/C7010-FAB-1 en état de mise hors tension

Le C7010-FAB-1 est hors tension et les erreurs suivantes apparaissent :

%PLATFORM-3-EJECTOR_STAT_CHANGED: Ejectors' status in slot 13 has changed, 
Left Ejector is OPEN, Right Ejector is CLOSE

%PLATFORM-3-EJECTOR_STAT_CHANGED: Ejectors' status in slot 13 has changed,
 Left Ejector is OPEN, Right Ejector is OPEN

%PLATFORM-2-XBAR_REMOVE: Xbar 3 removed (Serial number XXX)
 
Xbar Ports  Module-Type                         Model              Status
---  -----  ----------------------------------- ------------------ ----------
3    0      Fabric Module                       N/A                powered-dn
?
Xbar Power-Status  Reason
---  ------------  ---------------------------
3    powered-dn     failure(powered-down) since maximum number of bringups were exceeded

Sinon, des erreurs ASIC xbar apparaissent :

%MODULE-4-MOD_WARNING: Module 15 (serial: XXX) reported warning due to 
X-bar Interface ASIC Error in device 70 (device error 0xc4600248)

%OC_USD-SLOT15-2-RF_CRC: OC2 received packets with CRC error from MOD 15 
through XBAR slot 3/inst 2

Cause première

Ce problème est dû à un module xbar défectueux ou mal installé, ou à un logement de châssis défectueux.

Solution

1. Vérifiez le résultat de ces commandes :
   • show version
   • show module
   • show logging
   • show logging nvram
   • show module internal exception-log
   • show module internal event-history
   • show core
   • show system reset-Raison
   • show environment | dans xbar
   • show system internal platform internal event-history xbar X est xbar #
   • show system internal xbar-client internal event-history errors
   • show system internal xbar all
   • show system internal xbar event-history errors
2. Réinstallez le module xbar et vérifiez son état.
3. Si la réinstallation échoue, testez xbar dans un autre logement ou testez le même logement avec un autre module xbar afin de vous assurer que le châssis est correct.
4. Remplacez le matériel défectueux en fonction des tests effectués aux étapes 2 et 3.

Problème : Module de ventilation défaillant N7K-C7010-FAN-F

Un ou plusieurs de ces symptômes de défaillance de ventilateur sont observés :

%PLATFORM-5-FAN_STATUS: Fan module 3 (Serial number XXX) 
Fan3(fab_fan1) current-status is  FAN_FAIL
 
Nexus 7000#show environment fan
Fan3(fab_fan1)  N7K-C7010-FAN-F    1.1     Failure (Failed Fanlets: 2 6 7 8 9 10 14 15 )
Fan4(fab_fan2)  N7K-C7010-FAN-F    1.1     Ok 
...
 
#show hardware
----------------------------------
Chassis has 4 Fan slots
----------------------------------
Fan3(fab_fan1) failed
  Model number is N7K-C7010-FAN-F
...

Cause première

Dans la plupart des cas, il s'agit d'une défaillance du ventilateur ou du logement du châssis.

Solution

1. Vérifiez le résultat de ces commandes :
   • show version
   • show module
   • show inventaire
   • show log
   • show log nvram
   • show environment fan
2. Testez ce N7K-C7010-FAN-F dans un autre châssis correct.
3. Remplacez le ventilateur ou le châssis en fonction des résultats des étapes 1 et 2.

Problème : Alarme du bloc d'alimentation %PLATFORM-2-PS_CAPACITY_CHANGE

Des alarmes sont visibles pour les changements de capacité, parfois très fréquemment.

%PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS2 changed its capacity. 
possibly due to On/Off or power cable removal/

2013 Oct 17 17:06:40 ... last message repeated 14 times

 

Cause première

Ce problème est dû à un câble d'alimentation défectueux ou déconnecté, ou à une panne d'alimentation.

Solution

Vérifiez le résultat de la commande show env power detail et recherchez l'état de l'alimentation. Dans cet exemple de sortie, les deux accords sont connectés, mais le second montre seulement une capacité de 1 200 W au lieu de 3 000 W et doit être pour le 220 V CA sur le N7K-AC-6.0KW. La source d'alimentation a été testée sur OK. Remplacer l'alimentation.

PS_2 total capacity:    4200 W   Voltage:50Vchord 1    capacity:    3000 W chord 1    
connected to 110v AC chord 2    capacity:    1200 W chord 2    connected to 220v AC

Problème : %PLATFORM-5-PS_STATUS : Alarme PS_FAIL de l'alimentation X

Cette alerte apparaît sur la plate-forme :

%PLATFORM-5-PS_STATUS: PowerSupply 3 current-status is PS_FAIL

%PLATFORM-2-PS_FAIL: Power supply 3 failed or shut down (Serial number xxxxx)

Cause première

Cette alerte est due à un câble d'alimentation défectueux ou déconnecté, ou à une panne d'alimentation.

Solution

1. Vérifiez le résultat de ces commandes :
   • show environment power detail
   • show power
2. Réinsérez l'alimentation défectueuse. Utilisez l'alimentation redondante afin de vous assurer que l'alimentation ne se déconnecte pas.
3. Envoyez une RMA pour l'alimentation. Utilisez l'alimentation redondante afin de vous assurer que l'alimentation ne se déconnecte pas.

Références

Redondance des modules d'alimentation de la gamme Cisco Nexus 7000

Problème : Problème d'alimentation sur FEX

Ces alarmes s'affichent pour l'alimentation FEX :

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 Module 1: Runtime diag detected major event:
Voltage failure on power supply: 1
%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 System minor alarm on power 
supply 1: failed

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 Recovered: System minor alarm 
on power supply 1: failed 

Solution

Vérifiez les problèmes de matériel et d'alimentation. Si vous rencontrez un problème logiciel, les messages d'erreur continuent même après l'échange du matériel.

Les méthodes permettant de résoudre ces problèmes sont les suivantes :

1. Réinsérez l'alimentation FEX. Utilisez l'alimentation redondante afin de vous assurer que l'alimentation ne se déconnecte pas.
2. Envoyez la RMA pour l'alimentation FEX. Utilisez l'alimentation redondante afin de vous assurer que l'alimentation ne se déconnecte pas.
3. Répétez ces étapes pour le deuxième bloc d'alimentation.

Examinez et répondez à ces questions afin de définir les circonstances de l'échec :

1. Combien d'alimentations FEX sont affectées ?
2. Pour une alarme mineure, avez-vous échangé la source d'entrée, et cela a-t-il fait une différence ?
3. Avez-vous d'autres alimentations FEX qui présentent des problèmes ?
4. Avez-vous d'autres boîtiers de la même source d'alimentation ?
5. Avez-vous remplacé le cordon d'alimentation ?
6. Y avait-il une surtension ou un problème dans l'environnement ?

Recueillez les résultats de ces commandes afin d'étudier les échecs :

• show sprom fex 100 all
• show logging log | plus
• show tech fex 100 | plus
• joindre fex 100
• show platform software satctrl trace

Défaillance logicielle connue

ID de bogue Cisco CSCtr77620

Problème : Les alimentations N7K-AC-6.0KW sont signalées comme défectueuses

Les blocs d'alimentation Emerson N7K-AC-6.0KW sont signalés comme Fail / Shut mais le commutateur fonctionne correctement et la sortie réelle non 0 est visible pour le bloc d'alimentation défectueux.

Cause première

Sur un module d'alimentation avec les deux entrées actives, lorsqu'une entrée est déconnectée, reconnectée et déconnectée à nouveau dans les 1,5 secondes qui suivent, le module d'alimentation peut verrouiller une panne de sous-tension et NX-OS peut marquer le module d'alimentation comme défaillant. Dans une autre variante, sur un module d'alimentation avec deux entrées, supprimez une entrée et attendez 20 à 30 secondes. Le module d'alimentation peut définir l'alarme de panne interne de façon intermittente et NX-OS signale l'échec du module d'alimentation.

L'ID de bogue Cisco CSCty78612 modifie le micrologiciel des unités d'alimentation afin de résoudre le problème.

L'ID de bogue Cisco CSCuc86262 ajoute une amélioration logicielle afin de récupérer de ces fausses erreurs. NX-OS contrôle désormais de manière autonome l'état de l'unité d'alimentation (PSU) et le modifie en fonction de l'état indiqué si l'état indiqué diffère de l'état réel.

Solution

Entrez la commande show env power detail et vérifiez le résultat réel afin de vérifier la fausse panne :

Nexus7000# show env power
Power Supply:
Voltage: 50 Volts
Power Actual Total
Supply Model Output Capacity Status
 (Watts ) (Watts )
------- ------------------- ----------- ----------- --------------
1 N7K-AC-6.0KW 0 W 0 W Shutdown
2 N7K-AC-6.0KW 3888 W 6000 W Fail/Shut

L'état Échec/Arrêt erroné est effacé lorsque vous mettez le bloc d'alimentation hors tension/sous tension.

L'ID de bogue Cisco CSCty78612 modifie le micrologiciel sur le bloc d'alimentation. Le logiciel a été amélioré grâce à l'ID de bogue Cisco CSCuc86262 qui récupère des notifications de faux échec/arrêt avec la correction des faux bits si l'alimentation au moment de l'exécution fonctionne normalement. Les versions 5.2(9), 6.1(3), 6.2(2) et ultérieures de NX-OS présentent une amélioration qui évite une RMA.

Problème : Pertes de paquets logiciels

Une partie des paquets de grande taille est abandonnée lorsqu'il y a un taux élevé de paquets IP d'une longueur supérieure à la MTU configurée sur l'interface de sortie du paquet.

Cause première

C’est un comportement attendu. Lorsque le système reçoit un paquet IP d'une longueur supérieure à la MTU configurée sur l'interface de sortie du paquet, il envoie ce paquet au plan de contrôle, qui prend en charge la fragmentation. Dans NX-OS 4.1.3 et versions ultérieures, un limiteur de débit est appliqué à ces paquets punis. Cela le limite à un maximum de 500 pps par défaut.

Solution

Il s'agit d'un défaut logiciel connu dans l'ID de bogue Cisco CSCsu01048.

Problème : Erreur système USER-2-SYSTEM_MSG FIPS Self-test Failure

L'erreur « USER-2-SYSTEM_MSG FIPS self-test échec dans DCOS_rand - netstack » s'affiche.

Cause première

Chaque fois qu'un nombre aléatoire est généré, l'auto-test CRNG (Conditional Random Number Generator) s'exécute. Si le test échoue, un message syslog est enregistré. Cela se fait conformément à la recommandation des Normes fédérales de traitement de l'information (EPFI). Cependant, l'impact de ceci est inoffensif car le nombre aléatoire est généré à nouveau.

Il existe deux types de générateurs de nombres aléatoires (RNG) dans NX-OS :

• FIPS RNG mis en oeuvre dans la bibliothèque de chiffrement openssl
• RNG non FIPS qui est le RNG Linux

Conformément à la norme FIPS, tous les RNG doivent mettre en oeuvre le test de génération de nombres aléatoires conditionnels (CRNGT). Le test compare le nombre aléatoire généré en cours avec le nombre précédent. Si les numéros sont identiques, un message syslog est généré et un nombre aléatoire supplémentaire est généré.

Le test est exécuté afin de s'assurer que le caractère unique du nombre aléatoire. Il n'y a pas d'impact fonctionnel car le nombre est régénéré.

Solution

Ce message est inoffensif pour le fonctionnement du système. À partir de Cisco NX-OS version 5.2x et ultérieures, la gravité du message est réduite par rapport à 2, de sorte qu'il n'est plus visible avec la configuration de journalisation par défaut. Cette journalisation se produit dans le cadre des auto-tests internes de NX-OS pour diverses fonctions sur le commutateur.

Il s'agit d'un défaut logiciel connu dans l'ID de bogue Cisco CSCtn70083.