Commutateurs : Commutateurs Cisco Nexus, s�rie�7000

Dépannez les questions de visserie commune et d'architecture dans des Commutateurs de gamme de Nexus 7000

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document fournit une brève explication et des solutions pour des questions de visserie commune et d'architecture pour le Commutateurs de la gamme Cisco Nexus 7000 qui exécutent le logiciel système de Cisco NX-OS.

Remarque: 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.

Contribué par Ivan Shirshin et Naveen Venkateshaiah, ingénieurs TAC Cisco.

Problème : Panne de SpineControlBus

Le test de contrôle d'épine échoue pour le superviseur de 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

Cet isue est lié à l'ID de bogue Cisco CSCuc72466. Référez-vous à la Foire aux questions de Nexus 7000 : Ce qui est l'action recommandée de prendre quand le test de SpineControlBus échoue ?.

Problème : Blocs défectueux trouvés sur NVRAM

Les erreurs NVRAM apparaissent dans des événements diagnostiques :

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

C'est un problème de matériel, une panne moteur de superviseur, ou une question passagère.

Solution

  1. Réexécutez le test NVRAM afin de voir si c'est une fausse alerte. Sélectionnez ces commandes afin de désactiver et réactiver le test de diagnostic (exemple si donné pour le module de problème 5) :
    • aucun test NVRAM du module 5 de diagnostic monitor
    • test NVRAM du module 5 de diagnostic monitor

    Sélectionnez la commande de détail du test NVRAM du show diagnostic result module 5 afin de voir les résultats de la commande de test.

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

Problème : Panne de Compact Flash du module 9

Un ou toute la ces derniers sont vus sur le superviseur 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.
  • Incapable à la save config.
  • Pannes 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 principale

Des superviseurs de Nexus 7000 de seconde génération sont expédiés avec deux flashes identiques d'eUSB pour la Redondance. Les flashes fournissent un référentiel pour le bootflash, les configurations, et d'autres informations pertinentes. Ces deux flashes sont modifiés pendant qu'une baie redondante de disques indépendants (RAID) 1 baie qui implémente la mise en miroir interne. Avec la Redondance, un superviseur peut fonctionner avec la perte d'un des flashes mais pas de chacun des deux.

Il y a quelques exemples dans le domaine où un ou chacun des deux flashes sont marqués comme mauvais par le logiciel RAID au-dessus d'une plage horaire de plusieurs mois ou années en service. Une remise/réinitialisation du panneau redécouvre ces flashes défectueux sont saines au prochain démarrage en hausse.

Solution

Terminez-vous ces étapes afin de vérifier si c'est ou n'est pas un problème de matériel :

  1. Rechargez le superviseur de problème, si possible.
  2. Si la question est vue après recharge, vous avez besoin d'un remplacement de matériel.
  3. Si la question est réparée par la recharge, la cause principale est liée à l'ID de bogue Cisco CSCus22805.

Problème : Panne de test de PortLoopback du Linecard N7K-M132XP-12

Le linecard signale une panne de diagnostics devant mettre en communication la panne de test de PortLoopback 10 fois à la suite :

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 principale

C'est un message d'avertissement et indique dans la plupart des cas un problème de matériel avec le port.

Solution

Vérifiez l'ID de bogue Cisco CSCtn81109 et l'ID de bogue Cisco CSCti95293 d'abord, car ceci pourrait être un problème logiciel.

Réinsérez le module d'abord afin de réinitialiser la carte et réexécuter des tests de validité de matériel de démarrage. Si les tests de diagnostic affichent toujours la panne pour la même carte, remplacez la carte.

Rechargez la carte à un temps commode et collectez les sorties de ces commandes :

  • log de show logging
  • show module
  • affichez à module de résultat de diagn tout le détail

Alternativement, vous pouvez réexécuter seulement ce test spécifique et n'avez pas besoin de recharger la carte. Cet exemple affiche 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 : N7K-M132XP-12 Linecard MODULE-4-MOD_WARNING

Ces erreurs apparaissent et il y a une recharge possible de 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 principale

C'est une défaillance matérielle provoquée par des erreurs de parité ou des problèmes de matériel sur la carte de fille.

Solution

  1. Vérifiez la sortie de ces commandes :
    • show version
    • module X de show system reset-reason
    • raison de la réinitialisation interne de show logging onboard
    • module interne X d'événement-historique de show module
    • show log
  2. Si votre version de Cisco NS-OX est plus tôt que la version 4.2, alors la mise à jour à une nouvelle version afin d'assurer des difficultés pour ces erreurs de logiciel sont intégrées (réduisez la possibilité d'erreurs de parité) :
    • Le D-cache de l'ID de bogue Cisco CSCso72230 L1 a activé 8541 crash CPU avec des erreurs de parité du D-cache L1
    • ID de bogue Cisco CSCsr90831 - Le D-cache L1 a activé 8541 crash CPU avec des erreurs de parité de pousser du D-cache L1
  3. Si les erreurs se produisent à plusieurs reprises, réinsérez la carte et la surveillez.
  4. Si les erreurs répètent toujours, remplacez le module de problème.

Erreur de logiciel connue supplémentaire

ID de bogue Cisco CSCtb98876

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

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 principale

Ces erreurs indiquent qu'il y a une question de perte de sync 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 plus tôt que 6.1(4) et le message n'apparaît pas continuellement, il peut être affecté par l'ID de bogue Cisco CSCud91672. La cause du défaut est que les configurations de serdes NX-OS sont différentes des configurations diagnostiques sur les deux canaux entre SKT <-->SAC.

Solution

Collectez la sortie de ces commandes :

  • show version
  • show module
  • affichez le passage
  • module interne X d'événement-historique de show module
  • module interne X d'activité de show module
  • module interne X d'exception-log de show module
  • erreurs internes d'événement-historique de show module
  • show logging last 200
  • show logging nvram

Améliorez le commutateur à la version 6.1(4) ou ultérieures NS-OX afin d'isoler la cause du défaut.

Réalisez cet essai afin de confirmer si la carte est défectueuse au lieu du xbar ou de l'emplacement de châssis :

  1. Déplacez le module de problème à un autre emplacement libre dans le châssis.
  2. Si vous avez un module supplémentaire, insérez-le dans un emplacement de problème.
  3. Si les erreurs ne sont pas vues après l'étape 1, insérez le module de retour dans l'emplacement de problème et le vérifiez.

Problème : N7K-F248XP-25 PrimaryBootROM et pannes de test de SecondaryBootROM

Le module N7K-F248XP-25 échoue dans des tests de PrimaryBootROM et de 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 principale

C'est habituellement dû vu à la corruption de fichier BIOS ou à la défaillance matérielle de linecard.

Solution

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

Dans certains cas la question est provoqué par par la corruption BIOS sur le module. Sélectionnez la commande forcée par bios du module X d'installer afin de résoudre ceci. Notez que cette commande peut potentiellement affecter le service. La recommandation est de l'exécuter seulement pendant une fenêtre de maintenance.

Terminez-vous ces étapes afin de résoudre le problème :

  1. Programmez une fenêtre de maintenance et sélectionnez la commande forcée par bios du module X d'installer comme contournement possible. Sélectionnez seulement cette commande pendant une fenêtre de maintenance afin d'éviter l'incidence potentielle de service.
  2. Si étape 1 n'aide pas ou il n'est pas possible d'avoir une fenêtre de maintenance pour cette action, remplacez le module. Cet exemple de sortie affiche un essai raté :
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 de capteur de température

Cette erreur est vue sur la plate-forme :

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

Cause principale

C'est une question intermittente avec le bloc de la température/tension dans l'ASIC dans certaines conditions dues à la synchronisation interne ASIC. L'ID de bogue Cisco CSCtw79052 décrit la cause connue pour cette question.

C'est une question de synchronisation entre l'ASIC qui verrouille la température intérieurement et le logiciel qui échantillonne le bit valide. La question est qu'elle peut frapper sur des 12 exemples l'uns des de tondeuse. Il n'y a aucun déclencheur particulier pour ce problème et il est intermittent. Ce problème n'affecte pas le service et il surgit parce que la température a lu la logique a une question qui exige plus de relances dans le gestionnaire.

Solution

Collectez la sortie de ces commandes et de contrôle contre l'ID de bogue Cisco CSCtw79052 :

  • show version
  • la température de show env
  • #> de <module de module de show sprom 
  • #> de <module d'attach module de Nexus#
  • erreurs internes d'événement-historique de capteur de matériel de <module#>#show

Problème : Xbar Error/C7010-FAB-1 dans d'alimentation l'état d'indisponibilité

Le C7010-FAB-1 est dans un état d'indisponibilité d'alimentation et ces erreurs 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

Alternativement, les erreurs xbar ASIC 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 principale

Cette question est due module xbar défectueux ou mauvais-assis, ou à un mauvais emplacement de châssis.

Solution

  1. Vérifiez la sortie de ces commandes :
    • show version
    • show module
    • show logging
    • show logging nvram
    • exception-log interne de show module
    • événement-historique interne de show module
    • affichez le noyau
    • show system reset-reason
    • show environment | dans xbar
    • l'événement-historique interne X xbar de plate-forme interne de show system est xbar #
    • erreurs internes d'événement-historique de xbar-client interne de show system
    • xbar interne tout de show system
    • erreurs xbar internes d'événement-historique de show system
  2. Exécutez un dur réinsèrent du module xbar et vérifient l'état.
  3. Si le réinsérer échoue, testez xbar dans un autre emplacement ou testez le même emplacement avec un autre module xbar afin de s'assurer que le châssis est bien.
  4. Remplacez le matériel défectueux basé sur les essais réalisés dans les étapes 2 et 3.

Problème : N7K-C7010-FAN-F a manqué module de ventilateur

Un ou plusieurs de ces symptômes de panne de ventilation 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 principale

Dans la plupart des cas c'est une panne le du thermoventilateur ou de l'emplacement de châssis.

Solution

  1. Vérifiez la sortie de ces commandes :
    • show version
    • show module
    • show inventory
    • show log
    • nvram de show log
    • thermoventilateur de show environment
  2. Testez ce N7K-C7010-FAN-F dans des autres bons châssis.
  3. Remplacez le thermoventilateur ou le châssis basé sur les résultats des étapes 1 et 2.

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

Des alarmes sont vues pour les modifications 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 principale

Cette question est due à une panne défectueux ou déconnecté câble d'alimentation, ou de bloc d'alimentation.

Solution

Vérifiez la sortie de la commande de détail d'alimentation de show env et recherchez l'état de bloc d'alimentation. Dans cet exemple de sortie, les deux cordes sont connectées mais la deuxième capacité 1200W d'expositions seulement au lieu de 3000W et de elle doit être pour le courant alternatif 220V sur le N7K-AC-6.0KW. La source d'alimentation testée CORRECT. Remplacez le bloc d'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 du bloc d'alimentation X PS_FAIL

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 principale

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

Solution

  1. Vérifiez la sortie de ces commandes :
    • détail d'alimentation de show environment
    • show power
  2. Réinsérez le bloc d'alimentation défectueux. Employez le bloc d'alimentation redondant afin de s'assurer que l'alimentation ne va pas off-line.
  3. Soumettez un RMA pour le bloc d'alimentation. Employez le bloc d'alimentation redondant afin de s'assurer que l'alimentation ne va pas off-line.

Références

Redondance d'alimentation d'énergie de gamme 7000 de Cisco Nexus

Problème : Question de bloc d'alimentation sur FEX

Ces alarmes apparaissent pour le bloc d'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 questions de matériel et d'alimentation. Si vous avez un problème logiciel, les messages d'erreur continuent même après que vous permutez le matériel.

Les méthodes pour résoudre ces problèmes incluent :

  1. Réinsérez le bloc d'alimentation FEX. Employez le bloc d'alimentation redondant afin de s'assurer que l'alimentation ne va pas off-line.
  2. Soumettez le RMA pour le bloc d'alimentation FEX. Employez le bloc d'alimentation redondant afin de s'assurer que l'alimentation ne va pas off-line.
  3. Répétez ces étapes pour le deuxième bloc d'alimentation.

Passez en revue et répondez à ces questions afin d'aider à définir les circonstances de la panne :

  1. Combien de blocs d'alimentation FEX sont affectés ?
  2. Pour une alarme mineure, avez-vous permuté la source d'entrée, et est-ce que cela a fait une différence ?
  3. Avez-vous d'autres blocs d'alimentation FEX qui ont des questions ?
  4. Avez-vous de autres cases 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 la sortie de ces commandes afin d'étudier les pannes :

  • fex 100 tous de show sprom
  • log de show logging | pas plus
  • affichez le fex 100 de tech | pas plus
  • fex 100 d'attache
  • suivi de satctrl de logiciel de show platform

Erreur de logiciel connue

ID de bogue Cisco CSCtr77620

Problème : Des blocs d'alimentation N7K-AC-6.0KW sont signalés en tant qu'échouer

Les blocs d'alimentation N7K-AC-6.0KW d'Emerson sont signalés comme l'échouer/a fermé mais le commutateur fonctionne bien et la sortie non-0 réelle est vu pour le bloc d'alimentation de problème.

Cause principale

Sur un approvisionnement avec l'active de les deux entrées, quand une entrée est déconnectée, rebranchée, et déconnectée de nouveau dans 1.5 seconde l'approvisionnement peut verrouiller un défaut de sousvoltage et NX-OS peut signaler le bloc d'alimentation comme manqué. Dans une autre variation, sur un approvisionnement avec deux entrées, retirez un entré et attendez 20 à 30 secondes. L'approvisionnement pourrait par intermittence placer l'alarme interne de défaut et NX-OS signale le bloc d'alimentation comme manqué.

L'ID de bogue Cisco CSCty78612 apporte des modifications au micrologiciel sur les blocs d'alimentation afin de réparer la question.

L'ID de bogue Cisco CSCuc86262 ajoute une amélioration logicielle afin de récupérer de ces pannes fausses. NX-OS autonome surveille maintenant l'état de bloc d'alimentation (bloc d'alimentation) et le modifie à l'état approprié si l'état signalé diffère du vrai état.

Solution

Sélectionnez la commande de détail d'alimentation de show env et vérifiez la sortie réelle afin de vérifier la panne fausse :

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'échouer erroné/état fermé est effacé quand vous actionnez off/on le bloc d'alimentation.

L'ID de bogue Cisco CSCty78612 apporte des modifications au micrologiciel sur le bloc d'alimentation. Le logiciel a été amélioré par l'ID de bogue Cisco CSCuc86262 qui récupère de l'échouer faux/des notifications fermées avec la correction des bits faux si le bloc d'alimentation dans le délai d'exécution fonctionne normalement. Les versions 5.2(9), 6.1(3), 6.2(2) et plus tard NX-OS ont le présent d'amélioration qui évite un RMA.

Problème : Pertes de paquets de logiciel

Une partie des paquets de grande taille sont abandonnées quand il y a un haut débit de paquets IP avec une longueur plus long que le MTU configuré sur l'interface de sortie du paquet.

Cause principale

C'est comportement prévu. Quand le système reçoit un paquet IP avec une longueur plus long que le MTU configuré sur l'interface de sortie du paquet, le système envoie ce paquet à l'avion de contrôle, qui prend soin de la fragmentation. Dans NX-OS 4.1.3 et plus tard, une débit-borne est appliquée à tels les paquets donnés un coup de volée. Ceci le limite à un maximum de 500 PPS par défaut.

Solution

C'est une erreur de logiciel connue dans l'ID de bogue Cisco CSCsu01048.

Problème : Erreur système d'autotest de panne PAP USER-2-SYSTEM_MSG

La panne d'autotest PAP "USER-2-SYSTEM_MSG dans DCOS_rand - affichages d'erreur de netstack ».

Cause principale

Toutes les fois qu'un nombre aléatoire est généré, l'autotest à nombre aléatoire conditionnel du générateur (CRNG) fonctionne. Si le test échoue, un message de Syslog est enregistré. Ceci est fait selon la recommandation des Normes fédérales pour le traitement de l'information (PAP). Cependant, l'incidence de ceci est inoffensive car le nombre aléatoire est généré de nouveau.

Il y a deux types de générateurs à nombre aléatoire (RNGs) dans NX-OS :

  • PAP RNG qui est mis en application dans la crypto bibliothèque d'openssl
  • Non-PAP RNG qui est le Linux RNG

Selon des PAP, tout le RNGs doit implémenter le test à nombre aléatoire conditionnel de générateur (CRNGT). Le test compare le nombre aléatoire généré par courant au précédent. Si les nombres sont identiques, alors un message de Syslog est généré et un nombre aléatoire supplémentaire est généré.

Le test est exécuté afin d'assurer cette unicité du nombre aléatoire. Il n'y a aucune incidence fonctionnelle car le nombre est régénéré.

Solution

Ce message est inoffensif à l'exploitation du système. De la version 5.2x et ultérieures de Cisco NX-OS, la sévérité du message est diminuée à partir de 2 ainsi on ne le voit plus avec la configuration de journalisation par défaut. Ceci qui se connecte se produit en tant qu'élément des autotests internes NX-OS pour différentes fonctions sur le commutateur.

C'est une erreur de logiciel connue dans l'ID de bogue Cisco CSCtn70083.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118959