Récupération des pannes de mémoire Compact Flash du Supervisor 2/2E Nexus 7000

Introduction

Ce document décrit le problème de défaillance Compact Flash du Supervisor 2/2E du Nexus 7000, documenté dans le défaut logiciel CSCus22805, tous les scénarios de défaillance possibles et les étapes de récupération. 

Avant toute solution de contournement, il est fortement recommandé d'avoir un accès physique au périphérique au cas où une réinstallation physique est nécessaire.  Pour certaines mises à niveau de rechargement, un accès à la console peut être nécessaire, et il est toujours recommandé d'effectuer ces contournements avec l'accès de console au superviseur pour observer le processus de démarrage.

Si l'une des étapes de la solution de contournement échoue, contactez le centre d'assistance technique de Cisco pour obtenir des options de récupération supplémentaires. 

Fond

Chaque superviseur N7K 2/2E est équipé de 2 périphériques Flash eUSB en configuration RAID1, d'un principal et d'un miroir. Ensemble, ils fournissent des référentiels non volatils pour les images de démarrage, la configuration de démarrage et les données d'application persistantes.

Ce qui peut se produire sur une période de mois ou d'années de service, l'un de ces périphériques peut être déconnecté du bus USB, ce qui fait que le logiciel RAID abandonne le périphérique de la configuration. Le périphérique peut toujours fonctionner normalement avec 1/2 de périphériques. Cependant, lorsque le second périphérique sort de la baie, le bootflash est remonté en lecture seule, ce qui signifie que vous ne pouvez pas enregistrer la configuration ou les fichiers dans le bootflash, ni autoriser la synchronisation en veille vers l'actif en cas de rechargement.

Il n'y a pas d'impact opérationnel sur les systèmes fonctionnant en état de défaillance double de la mémoire Flash. Cependant, un rechargement du superviseur affecté est nécessaire pour récupérer de cet état. En outre, les modifications apportées à la configuration en cours ne seront pas répercutées au démarrage et seront perdues en cas de panne de courant.

Symptômes

Ces symptômes ont été observés :

• Panne de diagnostic Compact Flash

 switch# show diagnostic result module 5

 Current bootup diagnostic level: complete
 Module 5: Supervisor module-2  (Standby)

         Test results: (. = Pass, F = Fail, I = Incomplete,
         U = Untested, A = Abort, E = Error disabled)

          1) ASICRegisterCheck-------------> .
          2) USB---------------------------> .
          3) NVRAM-------------------------> .
          4) RealTimeClock-----------------> .
          5) PrimaryBootROM----------------> .
          6) SecondaryBootROM--------------> .
          7) CompactFlash------------------> F  <=====
          8) ExternalCompactFlash----------> .
          9) PwrMgmtBus--------------------> U
         10) SpineControlBus---------------> .
         11) SystemMgmtBus-----------------> U
         12) StatusBus---------------------> U
         13) StandbyFabricLoopback---------> .
         14) ManagementPortLoopback--------> .
         15) EOBCPortLoopback--------------> .
         16) OBFL--------------------------> .

• Impossible d'exécuter un 'copy run start'

dcd02.ptfrnyfs# copy running-config startup-config
 [########################################] 100%
 Configuration update aborted: request was aborted 

• eUSB devient en lecture seule ou ne répond pas

switch %MODULE-4-MOD_WARNING: Module 2 (Serial number: JAF1645AHQT) reported warning
 due to The compact flash power test failed in device DEV_UNDEF (device error 0x0)

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

• Échecs de ISSU, généralement lors d'une tentative de basculement vers le superviseur de secours

Diagnostic

Pour diagnostiquer l'état actuel des cartes Compact Flash, vous devez utiliser ces commandes internes. Notez que la commande ne sera pas analysée et qu'elle doit être complétée :

switch# show system internal raid | grep -A 1 « Informations sur l'état RAID actuel »

switch# show system internal file /proc/mdstat

S'il y a deux superviseurs dans le châssis, vous devez également vérifier l'état du superviseur de secours pour déterminer le scénario de défaillance auquel vous êtes confronté. Pour cela, utilisez le mot-clé « slot x » avant la commande, où « x » est le numéro de logement du superviseur de secours. Cela vous permet d'exécuter la commande à distance sur la veille.

switch# slot 2 show system internal raid | grep -A 1 « Informations sur l'état RAID actuel »

switch# slot 2 show system internal file /proc/mdstat

Ces commandes donneront beaucoup de statistiques et d'événements RAID, mais vous n'êtes préoccupé que par les informations RAID actuelles. 

Dans la ligne « Données RAID de CMOS », vous voulez regarder la valeur hexadécimale après 0xa5.  Cela montre combien de clignotements peuvent actuellement faire face à un problème. 

Exemple :

 switch# show system internal raid | grep -A 1 "Current RAID status info"
 Current RAID status info:
 RAID data from CMOS = 0xa5 0xc3

À partir de cette sortie, vous voulez regarder le numéro en regard de 0xa5 qui est 0xc3.  Vous pouvez ensuite utiliser ces clés pour déterminer si le Compact Flash principal ou secondaire a échoué, ou les deux. La sortie ci-dessus montre 0xc3 qui nous indique que les flashs compacts principal et secondaire ont échoué.

Dans la sortie "/proc/mdstat », assurez-vous que tous les disques affichent la valeur « U », qui représente « U » p :

switch# slot 2 show system internal file /proc/mdstat
Personalities : [raid1]
md6 : active raid1 sdc6[0] sdb6[1]
      77888 blocks [2/1] [_U]

md5 : active raid1 sdc5[0] sdb5[1]
      78400 blocks [2/1] [_U]

md4 : active raid1 sdc4[0] sdb4[1]
      39424 blocks [2/1] [_U]

md3 : active raid1 sdc3[0] sdb3[1]
      1802240 blocks [2/1] [_U]

Dans ce scénario, vous voyez que la mémoire Compact Flash principale n'est pas activée [_U]. Une sortie saine affiche tous les blocs en tant que [UU].

Note: Les deux sorties doivent être affichées comme saines (0xf0 et [UU]) pour diagnostiquer que le superviseur est sain. Ainsi, si vous voyez une sortie 0xf0 dans les données CMOS mais que vous voyez un [_U] dans /proc/mdstat, la zone n'est pas saine.

Scénarios

Pour déterminer le scénario auquel vous faites face, vous devez utiliser les commandes ci-dessus dans la section "Diagnostic" pour établir une corrélation avec une lettre de scénario ci-dessous.  À l'aide des colonnes, faites correspondre le nombre de flashs compacts échoués sur chaque superviseur. 

Par exemple, si vous avez vu que le code est 0xe1 sur le superviseur actif et 0xd2 sur la veille, il s'agirait de "1 Échec" sur l'actif et de "1 Échec" sur la veille, qui est la lettre de scénario "D« .

Superviseur unique :

Deux superviseurs :

Procédure de récupération pour chaque scénario

Scénarios de défaillance d'un superviseur unique

Scénario A (1 échec sur l'actif)

Scénario de récupération :

    1 Échec sur l'actif

Étapes de résolution :

1. Chargez l'outil de récupération Flash pour réparer le bootflash. Vous pouvez télécharger l'outil de récupération depuis CCO sous Utilitaires pour la plate-forme N7000 ou utiliser le lien ci-dessous :

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

Il est enveloppé dans un fichier compressé tar gz, veuillez le décompresser pour trouver l'outil de récupération .gbin et un fichier readme .pdf. Examinez le fichier readme et chargez l'outil .gbin sur bootflash du N7K. Bien que cette récupération soit conçue pour ne pas avoir d'impact et puisse être effectuée en direct, le TAC recommande de l'effectuer dans une fenêtre de maintenance en cas de problème inattendu. Une fois le fichier sur bootflash, vous pouvez exécuter l'outil de récupération avec :

switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6    : active raid1 sdd6[2] sdc6[0] 
    77888 blocks [2/1] [U_]  <-- "U_" represents the broken state
        resync=DELAYED
        
md5    : active raid1 sdd5[2] sdc5[0] 
    78400 blocks [2/1] [U_]
        resync=DELAYED
        
md4    : active raid1 sdd4[2] sdc4[0] 
    39424 blocks [2/1] [U_]
        resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0] 
    1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>

switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0] 
    77888 blocks [2/2] [UU]  <-- "UU" represents the fixed state
    
md5 :active raid1 sdd5[1] sdc5[0] 
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0] 
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0] 
    1802240 blocks [2/2] [UU]
unused devices: <none>

Scénario B (2 défaillances sur l'actif)

Scénario de récupération :

    2 échoue sur l'actif

Étapes de résolution :

Note: En cas de double défaillance de la mémoire flash, il est fréquent qu'un rechargement de logiciel ne récupère pas complètement le RAID et nécessite l'exécution de l'outil de récupération ou des rechargements ultérieurs pour récupérer. Dans presque tous les cas, il a été résolu avec une réinitialisation physique du module superviseur. Par conséquent, si l'accès physique au périphérique est possible, après avoir sauvegardé la configuration en externe, vous pouvez tenter une récupération rapide qui a le plus de chances de succès en réinstallant physiquement le superviseur lorsque vous êtes prêt à recharger le périphérique. Cela supprimera complètement l'alimentation du superviseur et devrait permettre la récupération des deux disques dans le RAID. Passez à l'étape 3 si la récupération de réinstallation physique n'est que partielle ou à l'étape 4 si elle ne réussit pas entièrement car le système ne démarre pas complètement.

Scénarios de défaillance du double superviseur

Scénario C (0 échec sur l'actif, 1 échec en veille)

Scénario d'échec :

    0 échoue sur l'actif

    1 Échec en veille

Étapes de résolution :

Dans le scénario d'une configuration à deux superviseurs, sans défaillance de la mémoire Flash sur l'actif et une seule défaillance sur la veille, une récupération sans impact peut être effectuée.


1. Comme l'actif n'a pas de défaillance et que la veille n'a qu'une seule défaillance, l'outil de récupération Flash peut être chargé sur l'actif et exécuté. Après avoir exécuté l'outil, il se copie automatiquement en veille et tente de resynchroniser la baie.  L'outil de récupération peut être téléchargé ici :

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

Une fois que vous avez téléchargé l'outil, décompressé et téléchargé sur le bootflash de la boîte, vous devez exécuter la commande suivante pour commencer la récupération :

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

L'outil commence à exécuter et détecter les disques déconnectés et tente de les resynchroniser avec la baie RAID.

Vous pouvez vérifier l'état de récupération à l'aide des éléments suivants :

# show system internal file /proc/mdstat

Vérifiez que la récupération est en cours, il peut être nécessaire de plusieurs minutes pour réparer entièrement tous les disques à un état [UU]. Voici un exemple de récupération en cours :                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

Une fois la récupération terminée, il doit se présenter comme suit :

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                 
Une fois que tous les disques sont dans [UU], la baie RAID est entièrement sauvegardée avec les deux disques synchronisés.

2. Si l'outil de récupération Flash échoue, puisque l'actif a les deux disques allumés, la synchronisation en veille avec l'actif lors du rechargement doit être possible.

Par conséquent, dans une fenêtre planifiée, exécutez un module x hors service pour le superviseur de secours, il est recommandé d'avoir accès à la console pour observer le processus de démarrage en cas de problème inattendu. Une fois le superviseur hors tension, attendez quelques secondes, puis exécutez « no poweroff module x » pour la mise en veille. Attendez que la veille démarre complètement dans l'état « ha-standby ».

Une fois la sauvegarde en veille terminée, vérifiez le RAID avec "slot x show system internal raid" et "slot x show system internal file /proc/mdstat« .

Si les deux disques ne sont pas entièrement sauvegardés après le rechargement, réexécutez l'outil de récupération.

3. Si l'outil de rechargement et de récupération échoue, il est recommandé de tenter de réinstaller physiquement le module de secours dans la fenêtre pour essayer d'effacer la condition.  Si la réinstallation physique échoue, essayez d'exécuter un « système d'initialisation » à partir du mode de démarrage du commutateur en suivant les étapes de récupération de mot de passe pour passer à ce mode pendant le démarrage.  En cas d'échec, contactez le TAC pour tenter une récupération manuelle.

Scénario D (1 échec sur l'actif, 0 échec sur la veille)

Scénario de récupération :

    1 Échec sur l'actif

    0 échoue en veille

Étapes de résolution :

Dans le scénario d'une configuration à double superviseur, avec une défaillance flash sur l'actif et aucune défaillance sur la veille, une récupération sans impact peut être effectuée à l'aide de l'outil de récupération Flash.


1. Comme la veille ne présente aucune défaillance et que l'active ne présente qu'une seule défaillance, l'outil de récupération Flash peut être chargé sur l'actif et exécuté. Après avoir exécuté l'outil, il se copie automatiquement en veille et tente de resynchroniser la baie.  L'outil de récupération peut être téléchargé ici :

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

Une fois que vous avez téléchargé l'outil, décompressé et téléchargé sur le bootflash de l'outil actif, vous devez exécuter la commande suivante pour commencer la récupération :

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

L'outil commence à exécuter et détecter les disques déconnectés et tente de les resynchroniser avec la baie RAID.

Vous pouvez vérifier l'état de récupération à l'aide des éléments suivants :

# show system internal file /proc/mdstat

Vérifiez que la récupération est en cours, il peut être nécessaire de plusieurs minutes pour réparer entièrement tous les disques à un état [UU]. Voici un exemple de récupération en cours :                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

Une fois la récupération terminée, il doit se présenter comme suit :

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                
Une fois que tous les disques sont dans [UU], la baie RAID est entièrement sauvegardée avec les deux disques synchronisés.



2. Si l'outil de récupération Flash échoue, l'étape suivante consisterait à effectuer un "basculement du système » pour basculer les modules de supervision dans une fenêtre de maintenance.

Par conséquent, dans une fenêtre programmée, exécuter un "basculement système« , il est recommandé d'avoir un accès console pour observer le processus de démarrage en cas de problème inattendu.  Attendez que la veille démarre complètement dans l'état « ha-standby ».

Une fois la sauvegarde en veille terminée, vérifiez le RAID avec "slot x show system internal raid" et "slot x show system internal file /proc/mdstat« .

Si les deux disques ne sont pas entièrement sauvegardés après le rechargement, réexécutez l'outil de récupération.


3. Si l'outil de rechargement et de récupération échoue, il est recommandé de tenter de réinstaller physiquement le module de secours dans la fenêtre pour essayer d'effacer la condition.  Si la réinstallation physique échoue, essayez d'exécuter un « système d'initialisation » à partir du mode de démarrage du commutateur en suivant les étapes de récupération de mot de passe pour passer à ce mode pendant le démarrage.  En cas d'échec, contactez le TAC pour tenter une récupération manuelle.

Scénario E (1 échec sur l'actif, 1 échec en veille)

Scénario de récupération :

    1 Échec sur l'actif

    1 Échec en veille

Étapes de résolution :

En cas de défaillance d'une seule mémoire flash sur le mode actif et le mode veille, une solution de contournement sans impact peut toujours être effectuée.


1. Comme aucun superviseur n'est en lecture seule, la première étape consiste à essayer d'utiliser l'outil de récupération Flash.

L'outil de récupération peut être téléchargé ici :

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

Une fois que vous avez téléchargé l'outil, décompressé et téléchargé sur le bootflash de l'outil actif, vous devez exécuter la commande suivante pour commencer la récupération :

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

Il détecte automatiquement les disques déconnectés sur le disque actif et tente de réparer, ainsi que se copie automatiquement en veille et détecte et corrige les pannes.

Vous pouvez vérifier l'état de récupération à l'aide des éléments suivants :

# show system internal file /proc/mdstat

Vérifiez que la récupération est en cours, il peut être nécessaire de plusieurs minutes pour réparer entièrement tous les disques à un état [UU]. Voici un exemple de récupération en cours :                

                                                                                       
 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

Une fois la récupération terminée, il doit se présenter comme suit :

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                  
Une fois que tous les disques sont dans [UU], la baie RAID est entièrement sauvegardée avec les deux disques synchronisés.


Si les deux superviseurs récupèrent dans l'état [UU], la récupération est terminée.  Si la récupération est partielle ou n'a pas abouti, passez à l'étape 2.


2. Si l'outil de récupération échoue, identifiez l'état actuel du RAID sur les modules. S'il y a toujours une seule défaillance de la mémoire flash sur les deux, essayez un « basculement du système » qui rechargera l'active actuelle et forcera la veille au rôle actif.

Une fois l'actif précédent rechargé dans « ha-standby », vérifiez son état RAID tel qu'il doit être récupéré lors du rechargement.
Si le superviseur se rétablit après la commutation, vous pouvez réessayer d'exécuter l'outil de récupération Flash pour tenter de réparer la défaillance d'un seul disque sur le superviseur actif actuel, ou un autre « basculement système » pour recharger l'actif actif actuel et forcer la veille active et actuelle précédente qui a été réparée au rôle actif. Vérifiez que les deux disques du superviseur rechargé ont été réparés à nouveau, réexécutez l'outil de récupération si nécessaire.


3. Si, au cours de ce processus, la commutation ne répare pas le RAID, exécutez un module hors service x pour le module de secours, puis no poweroff module x pour retirer complètement le module et le réappliquer au module.

Si la panne n'est pas terminée, essayez de réinstaller physiquement la veille.

Si, après avoir exécuté l'outil de récupération, un superviseur récupère son RAID et que l'autre a toujours une défaillance, forcez le superviseur avec l'unique défaillance à se mettre en veille avec un « basculement système » si nécessaire. Si le superviseur avec une seule défaillance est
déjà en veille, faites un « module hors service x » pour le module de secours et « no poweroff module x » pour retirer complètement et réappliquer l'alimentation au module. S'il n'est toujours pas restauré, essayez de réinstaller physiquement le module. Dans le cas où une réinstallation ne se répare pas,
entrez dans l'invite de démarrage du commutateur à l'aide de la procédure de récupération de mot de passe et exécutez un « système init » pour réinitialiser le bootflash. Si cette opération échoue toujours, faites en sorte que le TAC tente de récupérer manuellement.

Note: Si, à un moment quelconque, la veille est bloquée dans un état de mise sous tension et non de mise en veille, si elle n'est pas en mesure d'être complètement mise en veille avec les étapes ci-dessus, un rechargement du châssis sera nécessaire.

Scénario F (2 défaillances sur l'actif, 0 défaillances en veille)

Scénario de récupération :

    2 échoue sur l'actif

    0 échoue en veille

Étapes de résolution :

Avec 2 pannes sur l'active et 0 sur le superviseur de secours, une récupération sans impact est possible, selon la quantité de configuration en cours d'exécution ajoutée puisque le superviseur de secours n'a pas pu synchroniser sa configuration en cours avec l'active.

La procédure de récupération consiste à copier la configuration en cours à partir du superviseur actif, à basculer vers le superviseur de secours en bonne santé, à copier la configuration en cours manquante dans le nouvel actif, à mettre manuellement en ligne l'active précédente, puis à exécuter l'outil de récupération.

2.  Une fois la configuration en cours copiée du superviseur actif, il est recommandé de la comparer à la configuration initiale pour voir ce qui a changé depuis le dernier enregistrement.  Ceci peut être vu avec "show startup-configuration« .  Bien sûr, les différences dépendront entièrement de l'environnement, mais il est bon de savoir ce qui peut manquer lorsque la veille est mise en ligne comme active.  Il est également recommandé de copier les différences dans un bloc-notes afin de les ajouter rapidement au nouveau superviseur actif après la commutation.

3.  Une fois les différences évaluées, vous devrez effectuer un basculement de superviseur.  Le centre d'assistance technique recommande de le faire pendant une période de maintenance, car des problèmes inattendus peuvent se produire.  La commande permettant d'effectuer le basculement vers la veille sera "basculement du système« .

4.  La commutation doit se produire très rapidement et le nouveau démarrage en veille commence.  Au cours de cette période, vous voudrez ajouter à nouveau la configuration manquante au nouvel actif.  Pour ce faire, il suffit de copier la configuration à partir du serveur TFTP (ou de l'emplacement où elle a été enregistrée précédemment) ou d'ajouter manuellement la configuration dans l'interface de ligne de commande.  Dans la plupart des cas, les configurations manquantes sont très courtes et l'option CLI sera la plus faisable.

5.  Au bout d'un certain temps, le nouveau superviseur de secours peut revenir en ligne dans un état « ha-standby », mais ce qui se passe normalement, c'est qu'il est coincé dans un état « power-up ».  L'état peut être affiché à l'aide de la commande show module et en faisant référence à la colonne « Status » en regard du module. 

Si le nouveau mode veille est mis sous tension, vous devrez le remettre manuellement en ligne.  Pour ce faire, exécutez les commandes suivantes, où « x » est le module de secours coincé dans un état de mise sous tension :

    (config)# module hors service x

    (config)# no poweroff module x

6.  Une fois que le mode veille est de nouveau en ligne dans un état « ha-standby », vous devez alors exécuter l'outil de récupération pour vous assurer que la récupération est terminée.  Vous pouvez télécharger l'outil à l'adresse suivante :

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

Une fois que vous avez téléchargé l'outil, décompressé et téléchargé sur le bootflash de la boîte, vous devez exécuter la commande suivante pour commencer la récupération :

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

L'outil commence à exécuter et détecter les disques déconnectés et tente de les resynchroniser avec la baie RAID.

Vous pouvez vérifier l'état de récupération à l'aide des éléments suivants :

# show system internal file /proc/mdstat

Vérifiez que la récupération est en cours, il peut être nécessaire de plusieurs minutes pour réparer entièrement tous les disques à un état [UU]. Voici un exemple de récupération en cours :                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

Une fois la récupération terminée, il doit se présenter comme suit :

switch# show system internal file /proc/mdstat

Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
    77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
    
md5 :active raid1 sdd5[1] sdc5[0]
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0]
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0]
    1802240 blocks [2/2] [UU]
unused devices: <none>

                                                                  
Une fois que tous les disques sont dans [UU], la baie RAID est entièrement sauvegardée avec les deux disques synchronisés.

Scénario G (0 échec sur l'actif, 2 échec sur la veille)

0 échoue sur l'actif, 2 sur la veille

Scénario de récupération :

    0 échoue sur l'actif

    2 défaillances en veille

Étapes de résolution :

Avec 0 défaillance sur le superviseur actif et 2 sur le superviseur de secours, une récupération sans impact est possible.

La procédure de récupération consiste à effectuer un rechargement de la veille.

1. Dans les superviseurs ayant une double défaillance de mémoire flash, il est courant qu'un logiciel « reload module x » ne puisse réparer que partiellement le RAID ou qu'il soit bloqué lors du redémarrage.

Par conséquent, il est recommandé de réinstaller physiquement le superviseur en cas de double défaillance de la mémoire Flash pour retirer complètement et réappliquer l'alimentation au module ou d'effectuer les opérations suivantes (x pour le logement de secours n°) :

    # module hors service x
    # aucun module de mise hors tension x

Si vous constatez que la veille reste bloquée à l'état de mise sous tension et que la mise sous tension continue à être mise hors tension après les étapes ci-dessus, cela est probablement dû au rechargement actif de la veille pour ne pas être disponible à temps.

Cela peut être dû à la tentative de réinitialisation du bootflash/RAID par le démarrage en veille, qui peut prendre jusqu'à 10 minutes, mais il reste en cours de réinitialisation par l'actif avant d'accomplir.

Pour résoudre ce problème, configurez les paramètres suivants à l'aide de 'x' pour l'emplacement de secours bloqué dans la mise sous tension :

    (config)# system standby Manual-boot
    (config)# reload module x force-dnld
    
    Les éléments ci-dessus le font de sorte que l'active ne réinitialise pas automatiquement la veille, puis recharge la veille et force la synchronisation de son image à partir de l'active.
    
    Attendez 10 à 15 minutes pour voir si la veille est enfin en mesure d'atteindre l'état ha-standby. Une fois qu'il est en état ha-standby, réactivez les redémarrages automatiques de la veille avec :
    
    (config)# système no standby Manual-boot
    

6.  Une fois que le mode veille est de nouveau en ligne dans un état « ha-standby », vous devez alors exécuter l'outil de récupération pour vous assurer que la récupération est terminée.  Vous pouvez télécharger l'outil à l'adresse suivante :

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest


Une fois que vous avez téléchargé l'outil, décompressé et téléchargé sur le bootflash de la boîte, vous devez exécuter la commande suivante pour commencer la récupération :

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

L'outil commence à exécuter et détecter les disques déconnectés et tente de les resynchroniser avec la baie RAID.

Vous pouvez vérifier l'état de récupération à l'aide des éléments suivants :

# show system internal file /proc/mdstat

Vérifiez que la récupération est en cours, il peut être nécessaire de plusieurs minutes pour réparer entièrement tous les disques à un état [UU]. Voici un exemple de récupération en cours :                                                                                                       
                                        

 switch# show system internal file /proc/mdstat
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

Une fois la récupération terminée, il doit se présenter comme suit :

  
 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

Une fois que tous les disques sont dans [UU], la baie RAID est entièrement sauvegardée avec les deux disques synchronisés.

Scénario H (2 défaillances sur l'actif, 1 en veille)

2 défaillances sur l'actif, 1 en veille

Scénario de récupération :

    2 échoue sur l'actif

    1 défaillances en veille

Étapes de résolution :

Avec 2 défaillances sur l'active et 1 sur le superviseur de secours, une récupération sans impact est possible, selon la quantité de configuration en cours d'exécution ajoutée puisque le superviseur de secours n'a pas pu synchroniser sa configuration en cours avec l'active.


La procédure de récupération consiste à sauvegarder la configuration en cours à partir du superviseur actif, à basculer vers le superviseur de secours en bonne santé, à copier la configuration en cours manquante dans le nouvel actif, à mettre manuellement en ligne l'activité précédente, puis à exécuter l'outil de récupération.


1.  Sauvegardez toutes les configurations en cours en externe avec « copy running-config tftp: vdc-all ». Veuillez noter que dans les cas de défaillance double de la mémoire Flash, les modifications de configuration depuis que le système a été remonté en lecture seule ne sont pas présentes dans la configuration de démarrage. Vous pouvez passer en revue « show system internal raid » pour le module affecté afin de déterminer quand le deuxième disque a échoué, où le système passe en lecture seule. À partir de là, vous pouvez consulter « show accounting log » pour chaque VDC afin de déterminer quelles modifications ont été apportées depuis la défaillance de la double mémoire Flash, afin de savoir quoi ajouter si la configuration de démarrage persiste lors du rechargement.

Veuillez noter qu'il est possible que la configuration de démarrage soit effacée lors du rechargement d'un superviseur avec une double défaillance de la mémoire Flash, ce qui explique pourquoi la configuration doit être sauvegardée en externe.


2.  Une fois la configuration en cours copiée du superviseur actif, il est recommandé de la comparer à la configuration initiale pour voir ce qui a changé depuis le dernier enregistrement.  Ceci peut être vu avec « show startup-configuration ».  Bien sûr, les différences dépendront entièrement de l'environnement, mais il est bon de savoir ce qui peut manquer lorsque la veille est mise en ligne comme active.  Il est également recommandé de copier les différences dans un bloc-notes afin de les ajouter rapidement au nouveau superviseur actif après la commutation.


3.  Une fois les différences évaluées, vous devrez effectuer un basculement de superviseur.  Le centre d'assistance technique recommande de le faire pendant une période de maintenance, car des problèmes inattendus peuvent se produire.  La commande permettant d'effectuer le basculement vers la veille sera « system switchover ».


4.  La commutation doit se produire très rapidement et le nouveau démarrage en veille commence.  Au cours de cette période, vous voudrez ajouter à nouveau la configuration manquante au nouvel actif.  Cela peut être fait en copiant la configuration à partir du serveur TFTP (ou où elle a été enregistrée précédemment) ou simplement en ajoutant manuellement la configuration dans l'interface de ligne de commande, ne copiez pas directement depuis tftp vers running-configuration, copiez d'abord vers bootflash, puis vers la configuration en cours.  Dans la plupart des cas, les configurations manquantes sont très courtes et l'option CLI sera la plus faisable.


5.  Au bout d'un certain temps, le nouveau superviseur de secours peut revenir en ligne dans un état « ha-standby », mais ce qui se passe normalement, c'est qu'il est coincé dans un état « power-up ».  L'état peut être affiché à l'aide de la commande « show module » et en référence à la colonne « Status » située à côté du module.


Si le nouveau mode veille est mis sous tension, vous devrez le remettre manuellement en ligne.  Pour ce faire, exécutez les commandes suivantes, où « x » est le module de secours coincé dans un état de mise sous tension :

    (config)# module hors service
    (config)# no poweroff module x        
    
    
Si vous constatez que la veille reste bloquée à l'état de mise sous tension et que la mise sous tension continue à être mise hors tension après les étapes ci-dessus, cela est probablement dû au rechargement actif de la veille pour ne pas être disponible à temps.
Cela peut être dû à la tentative de réinitialisation du bootflash/RAID par le démarrage en veille, qui peut prendre jusqu'à 10 minutes, mais il reste en cours de réinitialisation par l'actif avant d'accomplir.
Pour résoudre ce problème, configurez les paramètres suivants à l'aide de 'x' pour l'emplacement de secours bloqué dans la mise sous tension :

    (config)# system standby Manual-boot
    (config)# reload module x force-dnld
    
    Les éléments ci-dessus le font de sorte que l'active ne réinitialise pas automatiquement la veille, puis recharge la veille et force la synchronisation de son image à partir de l'active.
    
    Attendez 10 à 15 minutes pour voir si la veille est enfin en mesure d'atteindre l'état ha-standby. Une fois qu'il est en état ha-standby, réactivez les redémarrages automatiques de la veille avec :
    
    (config)# system no standby Manual-boot
   
6.  Une fois que la récupération est de nouveau en ligne dans un état « ha-standby », vous devez alors exécuter l'outil de récupération pour vous assurer que la récupération est terminée et pour réparer la défaillance d'un disque unique sur l'actif.  Vous pouvez télécharger l'outil à l'adresse suivante :

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest


Une fois que vous avez téléchargé l'outil, décompressé et téléchargé sur le bootflash de la boîte, vous devez exécuter la commande suivante pour commencer la récupération :

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

L'outil commence à exécuter et détecter les disques déconnectés et tente de les resynchroniser avec la baie RAID.

Vous pouvez vérifier l'état de récupération à l'aide des éléments suivants :

# show system internal file /proc/mdstat

Vérifiez que la récupération est en cours, il peut être nécessaire de plusieurs minutes pour réparer entièrement tous les disques à un état [UU]. Voici un exemple de récupération en cours :                                                                                                       

                                       
 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

Une fois la récupération terminée, il doit se présenter comme suit :

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>
  

                                                                 
Une fois que tous les disques sont dans [UU], la baie RAID est entièrement sauvegardée avec les deux disques synchronisés.

Si le courant actif avec une seule défaillance n'est pas récupéré par l'outil de récupération, essayez un autre « basculement système » pour vous assurer que votre veille actuelle est en état « ha-standby ».  Si vous ne réussissez toujours pas, contactez le TAC Cisco.

Scénario I (1 échec sur l'actif, 2 échecs en veille)

Scénario de récupération :

    1 Échec sur l'actif

    2 défaillances en veille

Étapes de résolution :

Dans un scénario à deux superviseurs avec une défaillance sur le superviseur actif et deux défaillances sur le superviseur de secours, une récupération sans impact peut être possible, mais dans de nombreux cas un rechargement peut être nécessaire.

Le processus consistera à sauvegarder d'abord toutes les configurations en cours, puis à tenter de récupérer la mémoire CompactFlash défectueuse sur l'outil actif à l'aide de l'outil de récupération, puis, si cette opération réussit, vous rechargerez manuellement la veille et réexécuterez l'outil de récupération.  Si la tentative de récupération initiale ne parvient pas à récupérer la mémoire Flash défectueuse sur l'actif, le TAC doit être engagé pour tenter une récupération manuelle à l'aide du plug-in de débogage.

1.  Sauvegardez toute configuration en cours en externe avec "copy running-config tftp: vdc-all« .  Vous pouvez également copier la configuration en cours dans une clé USB locale si un serveur TFTP n'est pas configuré dans l'environnement.

2.  Une fois la configuration en cours sauvegardée, vous devez exécuter l'outil de récupération pour tenter de récupérer la mémoire flash en panne sur l'active.  Vous pouvez télécharger l'outil à l'adresse suivante :

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

Une fois que vous avez téléchargé l'outil, décompressé et téléchargé sur le bootflash de la boîte, vous devez exécuter la commande suivante pour commencer la récupération :

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

L'outil commence à exécuter et détecter les disques déconnectés et tente de les resynchroniser avec la baie RAID.

Vous pouvez vérifier l'état de récupération à l'aide des éléments suivants :

# show system internal file /proc/mdstat

Vérifiez que la récupération est en cours, il peut être nécessaire de plusieurs minutes pour réparer entièrement tous les disques à un état [UU]. Voici un exemple de récupération en cours :                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

Une fois la récupération terminée, il doit se présenter comme suit :

switch# show system internal file /proc/mdstat

Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
    77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
    
md5 :active raid1 sdd5[1] sdc5[0]
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0]
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0]
    1802240 blocks [2/2] [UU]
unused devices: <none>

                                                                  
Une fois que tous les disques sont dans [UU], la baie RAID est entièrement sauvegardée avec les deux disques synchronisés.

3.  Si, après avoir exécuté l'outil de récupération à l'étape 2, vous ne pouvez pas récupérer la mémoire Compact Flash défectueuse sur le superviseur actif, vous devez contacter le TAC pour tenter une récupération manuelle à l'aide du plug-in de débogage linux.

4.  Après avoir vérifié que les deux flashs s'affichent comme "[UU]" sur l'actif, vous pouvez redémarrer manuellement le superviseur de secours.  Pour ce faire, exécutez les commandes suivantes, où « x » est le module de secours coincé dans un état de mise sous tension :

    (config)# module hors service x

    (config)# no poweroff module x

Cela devrait ramener le superviseur de secours dans un état « ha-standby » (ceci est vérifié en affichant la colonne Status dans la sortie "show module").  Si cela réussit, passez à l'étape 6, sinon, essayez la procédure décrite à l'étape 5.

5.  Si vous constatez que la veille reste bloquée à l'état de mise sous tension et que la mise sous tension continue à être mise hors tension après les étapes ci-dessus, cela est probablement dû au rechargement actif de la veille pour ne pas être disponible à temps.  Cela peut être dû à la tentative de réinitialisation du bootflash/RAID par le démarrage en veille, qui peut prendre jusqu'à 10 minutes, mais il reste en cours de réinitialisation par l'actif avant d'accomplir.  Pour résoudre ce problème, configurez les paramètres suivants à l'aide de 'x' pour l'emplacement de secours bloqué dans la mise sous tension :

(config)# system standby Manual-boot
(config)# reload module x force-dnld

Les éléments ci-dessus le font de sorte que l'active ne réinitialise pas automatiquement la veille, puis recharge la veille et force la synchronisation de son image à partir de l'active.

Attendez 10 à 15 minutes pour voir si la veille est enfin en mesure d'atteindre l'état ha-standby. Une fois qu'il est en état ha-standby, réactivez les redémarrages automatiques de la veille avec :

(config)# système no standby Manual-boot

6.  Une fois que le mode veille est de nouveau en ligne dans un état « ha-standby », vous devez alors exécuter l'outil de récupération pour vous assurer que la récupération est terminée.  Vous pouvez exécuter le même outil que celui qui est actif pour cette étape. Aucun téléchargement supplémentaire n'est nécessaire car l'outil de récupération s'exécute sur l'actif et en veille.

Scénario J (2 défaillances sur l'actif, 2 défaillances en veille)

Scénario de récupération :

    2 échoue sur l'actif

    2 défaillances en veille

Étapes de résolution :

Note: En cas de double défaillance de la mémoire flash, un rechargement du logiciel peut ne pas récupérer entièrement le RAID et nécessiter l'exécution de l'outil de récupération ou des rechargements ultérieurs pour récupérer. Dans presque tous les cas, il a été résolu avec une réinitialisation physique du module superviseur. Par conséquent, si l'accès physique au périphérique est possible, après avoir sauvegardé la configuration en externe, vous pouvez tenter une récupération rapide qui a le plus de chances de succès en réinstallant physiquement le superviseur lorsque vous êtes prêt à recharger le périphérique. Cela supprimera complètement l'alimentation du superviseur et devrait permettre la récupération des deux disques dans le RAID. Passez à l'étape 3 si la récupération de réinstallation physique n'est que partielle ou à l'étape 4 si elle ne réussit pas entièrement car le système ne démarre pas complètement.

Résumé

FAQ

Y a-t-il une solution permanente à ce problème ?

Reportez-vous à la section Solutions à long terme ci-dessous.

Pourquoi n'est-il pas possible de récupérer un double basculement sur le superviseur de secours actif et de secours en rechargeant le superviseur de secours et en échouant ?

La raison pour laquelle cela n'est pas possible est que, pour permettre au superviseur de secours de s'afficher dans un état « ha-standby », le superviseur actif doit écrire plusieurs choses dans sa mémoire Compact Flash (informations SNMP, etc.), ce qu'il ne peut pas faire s'il a lui-même une défaillance de double flash.

Que se passe-t-il si l'outil de récupération Flash ne parvient pas à remonter la mémoire Compact Flash ?

Contactez le TAC Cisco pour connaître les options de ce scénario.

Ce bogue affecte-t-il également le Nexus 7700 Sup2E ?

Il y a un défaut distinct pour le N7700 Sup2E - CSCuv64056 .  L'outil de récupération ne fonctionne pas pour le N7700.

L'outil de récupération fonctionne-t-il pour les images NPE ?

L'outil de récupération ne fonctionne pas pour les images NPE.

Un ISSU à une version résolue du code résoudra-t-il ce problème ?

Non. Un ISSU utilise un basculement de superviseur, qui peut ne pas fonctionner correctement en raison d'une défaillance de la mémoire Compact Flash.

Nous réinitialisons la carte affectée. L'état RAID imprime 0xF0, mais les tests GOLD échouent toujours ?

Les bits d'état RAID sont réinitialisés après la réinitialisation de la carte après l'application de la récupération automatique.
Cependant, toutes les conditions de défaillance ne peuvent pas être récupérées automatiquement.
Si les bits d'état RAID ne sont pas imprimés en tant que [2/2] [UU], la récupération est incomplète.
Suivez les étapes de récupération répertoriées

La défaillance de la mémoire flash aura-t-elle un impact sur le fonctionnement ?

Non, mais le système ne peut pas démarrer en cas de panne d'alimentation. Les configurations de démarrage seront également perdues.

Qu'est-ce qui est recommandé pour un système fonctionnant correctement du point de vue du client en termes de surveillance et de récupération ?

Vérifiez l'état du test compact GOLD pour détecter toute défaillance et tentez de récupérer dès que la première pièce flash échoue.

Puis-je réparer une défaillance de flash eusb en faisant un ISSU du code affecté à la version fixe ?

ISSU ne réparera pas eUSB défectueux. La meilleure option est d'exécuter l'outil de récupération pour une défaillance eusb unique sur le sup ou de recharger le sup en cas de défaillance eusb double.
Une fois le problème corrigé, effectuez la mise à niveau. Le correctif pour CSCus22805 aide à corriger une défaillance eusb unique SEULEMENT et il le fait en analysant le système à intervalles réguliers et tente de réactiver eUSB inaccessible ou en lecture seule à l'aide du script.
Il est rare que les deux défaillances de flash eusb surviennent simultanément sur le superviseur, de sorte que cette solution de contournement sera efficace.

Combien de temps faut-il pour que le problème réapparaisse si vous corrigez les pannes de flash à l'aide du plug-in ou du rechargement ?

En général, le temps de fonctionnement est plus long. Ce chiffre n'est pas exactement quantifié et peut varier d'un an ou plus. En fin de compte, plus la pression sur la mémoire flash eusb en termes d'écriture de lecture est importante, plus la probabilité que le système s'exécute dans ce scénario est élevée.

La commande show system internal raid affiche l'état de la mémoire Flash deux fois dans différentes sections. En outre, ces sections ne sont pas cohérentes
La première section présente l'état actuel et la seconde l'état de démarrage.
L'état actuel est ce qui importe et il devrait toujours apparaître comme UU.

Solutions à long terme

Ce défaut a une solution de contournement dans la version 6.2(14), mais le correctif du microprogramme a été ajouté à la version 6.2(16) et à la version 7.2(x) et ultérieures. 

Il est conseillé de passer à une version avec le correctif du microprogramme pour résoudre complètement ce problème.

Si vous ne parvenez pas à mettre à niveau vers une version fixe de NXOS, il existe deux solutions possibles. 

La solution 1 consiste à exécuter l'outil de récupération Flash de manière proactive chaque semaine à l'aide du planificateur.  Configuration du planificateur suivante avec l'outil de récupération Flash dans le bootflash :

planificateur de fonctionnalités
nom du travail du planificateur Flash_Job

  copy bootflash:/n7000-s2-flash-recovery-tool.10.0.2.gbin bootflash:/flash_recovery_tool_copy
  load bootflash:/flash_recovery_tool_copy

  sortir
nom de planification du planificateur Flash_Recovery
  nom du travail Flash_Job
  heure hebdomadaire 7

Remarques : 

• La récupération flash doit avoir le même nom et être dans le bootflash.
• Le 7 dans la configuration « time hebdomadaire 7 » représente un jour de la semaine, le samedi dans ce cas.
• La fréquence maximale recommandée par Cisco est une fois par semaine.

 La solution 2 est documentée sur le lien technique suivant