Nexus 7000 Supervisor 2/2E Compact Flash Failure Recovery

Introduzione

Questo documento descrive il problema di errore di Nexus 7000 Supervisor 2/2E Compact Flash documentato nel difetto software CSCus22805, tutti i possibili scenari di errore e le fasi di ripristino. 

Prima di qualsiasi soluzione alternativa, si consiglia di accedere fisicamente al dispositivo nel caso sia necessario un riposizionamento fisico.  Per alcuni aggiornamenti con ricaricamento, potrebbe essere necessario l'accesso alla console ed è sempre consigliabile adottare queste soluzioni con l'accesso alla console del supervisore per osservare il processo di avvio.

Se una delle procedure indicate non riesce, contattare Cisco TAC per altre opzioni di ripristino possibili. 

Sfondo

Ogni N7K supervisor 2/2E è dotato di 2 dispositivi flash eUSB in configurazione RAID1, uno primario e uno mirror. Insieme forniscono repository non volatili per le immagini di avvio, la configurazione di avvio e i dati persistenti delle applicazioni.

Ciò che può accadere è che, in un periodo di mesi o anni di servizio, uno di questi dispositivi possa essere scollegato dal bus USB, causando la perdita del software RAID dalla configurazione. Il dispositivo può ancora funzionare normalmente con 1/2 di esso. Tuttavia, quando il secondo dispositivo esce dall'array, il bootflash viene rimontato in sola lettura, ossia non è possibile salvare la configurazione o i file sul bootflash, né consentire la sincronizzazione del dispositivo in standby con il dispositivo attivo in caso di ricaricamento.

Non vi è alcun impatto operativo sui sistemi in esecuzione in stato di errore dual flash, tuttavia è necessario ricaricare il supervisore interessato per ripristinare lo stato. Inoltre, le modifiche apportate alla configurazione corrente non si rifletteranno sull'avvio e andranno perse in caso di interruzione dell'alimentazione.

Sintomi

Sono stati osservati i seguenti sintomi:

• Errore diagnostico 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--------------------------> .

• Impossibile eseguire 'avvio esecuzione copia'

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

• eUSB diventa di sola lettura o non risponde

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

• Errori ISSU, in genere quando si tenta di eseguire il failover al supervisore di standby

Diagnosi

Per diagnosticare lo stato corrente delle schede Compact Flash, è necessario utilizzare questi comandi interni. Si noti che il comando non verrà analizzato e deve essere digitato completamente:

switch# show system raid | grep -A 1 "Informazioni sullo stato RAID corrente"

switch# show system internal file /proc/mdstat

Se nello chassis sono presenti due supervisori, sarà necessario controllare lo stato del supervisore di standby e determinare lo scenario di errore da affrontare. Controllare ciò premendo il comando con la parola chiave "slot x" dove "x" è il numero di slot del supervisore di standby. Ciò consente di eseguire il comando in remoto in standby.

switch# slot 2 show system internal raid | grep -A 1 "Informazioni sullo stato RAID corrente"

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

Questi comandi forniscono molte statistiche ed eventi RAID, ma si è interessati solo alle informazioni RAID correnti. 

Nella riga "RAID data from CMOS" (Dati RAID da CMOS), si desidera esaminare il valore esadecimale dopo 0xa5.  In questo modo verrà mostrato il numero di flash che potrebbero essere attualmente interessati da un problema. 

Ad esempio:

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

Da questo output si desidera esaminare il numero accanto a 0xa5 che è 0xc3.  È quindi possibile utilizzare questi tasti per determinare se la scheda CompactFlash primaria o secondaria ha avuto esito negativo o per entrambe. L'output precedente mostra 0xc3 che ci dice che sia il flash compatto primario che quello secondario hanno fallito.

Nell'output "/proc/mdstat" verificare che tutti i dischi siano visualizzati come "U", che rappresenta "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]

In questo scenario, la memoria flash compatta primaria non è attiva [_U]. Un output integro visualizzerà tutti i blocchi come [UU].

Nota: Entrambi gli output devono essere visualizzati come integri (0xf0 e [UU]) per poter diagnosticare lo stato integro del supervisore. Pertanto, se nei dati CMOS viene visualizzato un output 0xf0 ma viene visualizzato un [_U] in /proc/mdstat, la casella non è integra.

Scenari

Per determinare lo scenario a cui ci si trova di fronte, è necessario utilizzare i comandi descritti in precedenza nella sezione "Diagnosi" per stabilire una correlazione con una lettera sullo scenario riportata di seguito.  Utilizzando le colonne, verificare il numero di flash di compattazione non riusciti su ciascun supervisor. 

Ad esempio, se si nota che il codice è 0xe1 sul supervisore Attivo e 0xd2 sullo standby, il risultato sarà "1 Fail" sul supervisore Attivo e "1 Fail" sullo standby, ovvero la lettera scenario "D".

Supervisor singolo:

Doppio supervisore:

Procedura di ripristino per ogni scenario

Scenari di errore del singolo supervisore

Scenario A (1 errore su Attivo)

Scenario di ripristino:

    1 Errore su

Passi per la risoluzione:

1. Caricare lo strumento di recupero flash per ripristinare bootflash. È possibile scaricare lo strumento di ripristino da CCO in utility per la piattaforma N7000 o utilizzare il collegamento seguente:

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

È racchiuso in un file compresso tar gz, decomprimerlo per trovare lo strumento di recupero .gbin e un file Leggimi .pdf. Esaminare il file Leggimi e caricare lo strumento .gbin su bootflash della versione N7K. Anche se il ripristino non ha alcun impatto e può essere eseguito in tempo reale, TAC consiglia di eseguire l'operazione in una finestra di manutenzione in caso di problemi imprevisti. Dopo aver caricato il file su bootflash, è possibile eseguire lo strumento di ripristino con:

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>

Scenario B (2 errori su attivo)

Scenario di ripristino:

    2 errori nel

Passi per la risoluzione:

Nota: Si verifica in genere in caso di guasto di due flash, un ricaricamento del software potrebbe non ripristinare completamente il RAID e potrebbe richiedere l'esecuzione dello strumento di ripristino o successivi ricaricamenti per il ripristino. In quasi tutti i casi, è stato risolto con un riposizionamento fisico del modulo supervisor. Pertanto, se è possibile l'accesso fisico al dispositivo, dopo aver eseguito il backup della configurazione esternamente, è possibile tentare un ripristino rapido che ha le maggiori probabilità di riuscire riposizionando fisicamente il supervisore quando è pronto a ricaricare il dispositivo. In questo modo si rimuove completamente l'alimentazione dal supervisor e si dovrebbe consentire il ripristino di entrambi i dischi nel RAID. Procedere al passo 3 se il ripristino fisico del nuovo sedile è solo parziale, o al passo 4 se non ha successo in quanto il sistema non è completamente in fase di avvio.

Scenari di errore con due supervisori

Scenario C (0 non riuscito per il sistema attivo, 1 non riuscito per il sistema in standby)

Scenario di errore:

    0 non supera il limite attivo

    1 errore in standby

Passi per la risoluzione:

Nello scenario di configurazione con due supervisori, senza errori flash sul sistema attivo e con un singolo errore sul sistema in standby, è possibile eseguire un ripristino senza impatto.


1. Poiché l'unità attiva non presenta errori e lo standby presenta un solo errore, lo strumento di recupero flash può essere caricato sull'unità attiva ed eseguito. Dopo l'esecuzione dello strumento, lo strumento si copia automaticamente in standby e tenta di risincronizzare l'array.  Lo strumento di ripristino può essere scaricato qui:

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

Una volta scaricato lo strumento, decompresso e caricato nella bootflash della scatola, sarà necessario eseguire il seguente comando per iniziare il recupero:

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

Lo strumento si avvierà e rileverà i dischi scollegati e tenterà di risincronizzarli con l'array RAID.

È possibile controllare lo stato del ripristino tramite:

# show system internal file /proc/mdstat

Verificare che il ripristino sia in corso. L'operazione di ripristino completo di tutti i dischi in stato [UU] potrebbe richiedere alcuni minuti. Di seguito è riportato un esempio di operazione di ripristino:                                                                                                       
                                        

 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>

Al termine del ripristino, dovrebbe essere visualizzato come segue:

 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>

                                                                 
Dopo che tutti i dischi sono in [UU], l'array RAID è completamente di backup con entrambi i dischi sincronizzati.

2. Se lo strumento di recupero flash non riesce, poiché il disco attivo ha entrambi i dischi attivi, lo standby dovrebbe essere in grado di sincronizzarsi con il disco attivo al ricaricamento.

Pertanto, in una finestra pianificata, eseguire un "modulo x fuori servizio" per il supervisore di standby; si consiglia di avere accesso alla console allo standby per osservare il processo di avvio nel caso si verifichino problemi imprevisti. Dopo che il supervisor è spento, attendere alcuni secondi e poi eseguire "no poweroff module x" per lo standby. Attendere che lo standby si avvii completamente nello stato "ha-standby".

Una volta ripristinato lo standby, controllare il RAID con "slot x show system internal raid" e "slot x show system internal file /proc/mdstat".

Se dopo il riavvio entrambi i dischi non sono stati completamente ripristinati, eseguire nuovamente lo strumento di ripristino.

3. Se lo strumento di ricaricamento e recupero non riesce, si consiglia di provare a riposizionare fisicamente il modulo di standby nella finestra per provare a cancellare la condizione.  Se il ricollocamento fisico non riesce, provare a eseguire un "sistema di inizializzazione" dalla modalità di avvio dello switch seguendo la procedura di recupero della password per accedere a questa modalità durante l'avvio.  Se l'operazione non riesce, contattare TAC per tentare il ripristino manuale.

Scenario D (1 errore sul sistema attivo, 0 errore sul sistema in standby)

Scenario di ripristino:

    1 Errore su

    0 non funziona in standby

Passi per la risoluzione:

Nello scenario di configurazione con due supervisori, con 1 errore flash sul dispositivo attivo e nessun errore sul dispositivo in standby, è possibile eseguire un ripristino senza impatto utilizzando lo strumento di recupero flash.


1. Poiché lo standby non ha errori e lo switch attivo ha un solo errore, lo strumento di recupero flash può essere caricato sullo switch attivo ed eseguito. Dopo l'esecuzione dello strumento, lo strumento si copia automaticamente in standby e tenta di risincronizzare l'array.  Lo strumento di ripristino può essere scaricato qui:

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

Dopo aver scaricato lo strumento, averlo decompresso e caricato nella memoria flash iniziale del dispositivo attivo, è necessario eseguire il seguente comando per avviare il ripristino:

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

Lo strumento si avvierà e rileverà i dischi scollegati e tenterà di risincronizzarli con l'array RAID.

È possibile controllare lo stato del ripristino tramite:

# show system internal file /proc/mdstat

Verificare che il ripristino sia in corso. L'operazione di ripristino completo di tutti i dischi in stato [UU] potrebbe richiedere alcuni minuti. Di seguito è riportato un esempio di operazione di ripristino:                                                                                                       
                                        

 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>

Al termine del ripristino, dovrebbe essere visualizzato come segue:

 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>

                                                                
Dopo che tutti i dischi sono in [UU], l'array RAID è completamente di backup con entrambi i dischi sincronizzati.



2. Se lo strumento di recupero flash ha esito negativo, il passo successivo consiste nell'eseguire un "passaggio al sistema" per eseguire il failover dei moduli supervisor in una finestra di manutenzione.

Pertanto, in una finestra pianificata, eseguire un "switchover di sistema"; si consiglia di disporre dell'accesso da console per osservare il processo di avvio in caso si verifichino problemi imprevisti.  Attendere che lo standby si avvii completamente nello stato "ha-standby".

Una volta ripristinato lo standby, controllare il RAID con "slot x show system internal raid" e "slot x show system internal file /proc/mdstat".

Se dopo il riavvio entrambi i dischi non sono stati completamente ripristinati, eseguire nuovamente lo strumento di ripristino.


3. Se lo strumento di ricaricamento e recupero non riesce, si consiglia di provare a riposizionare fisicamente il modulo di standby nella finestra per provare a cancellare la condizione.  Se il ricollocamento fisico non riesce, provare a eseguire un "sistema di inizializzazione" dalla modalità di avvio dello switch seguendo la procedura di recupero della password per accedere a questa modalità durante l'avvio.  Se l'operazione non riesce, contattare TAC per tentare il ripristino manuale.

Scenario E (1 errore sul sistema attivo, 1 errore sul sistema in standby)

Scenario di ripristino:

    1 Errore su

    1 errore in standby

Passi per la risoluzione:

In caso di guasto di un singolo flash sia in modalità attiva che in modalità standby, è comunque possibile implementare una soluzione alternativa senza alcun impatto.


1. Poiché nessun supervisore è in sola lettura, il primo passaggio è provare a utilizzare lo strumento di recupero flash.

Lo strumento di ripristino può essere scaricato qui:

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

Dopo aver scaricato lo strumento, averlo decompresso e caricato nella memoria flash iniziale del dispositivo attivo, è necessario eseguire il seguente comando per avviare il ripristino:

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

Rileva automaticamente i dischi disconnessi sul disco attivo e tenta di ripararli, oltre a copiarsi automaticamente in standby e rileva e corregge i guasti.

È possibile controllare lo stato del ripristino tramite:

# show system internal file /proc/mdstat

Verificare che il ripristino sia in corso. L'operazione di ripristino completo di tutti i dischi in stato [UU] potrebbe richiedere alcuni minuti. Di seguito è riportato un esempio di operazione di ripristino:                

                                                                                       
 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>

Al termine del ripristino, dovrebbe essere visualizzato come segue:

 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>

                                                                  
Dopo che tutti i dischi sono in [UU], l'array RAID è completamente di backup con entrambi i dischi sincronizzati.


Se entrambi i supervisori eseguono il ripristino nello stato [UU], il ripristino è completato.  Se il ripristino è parziale o non è riuscito, andare al passo 2.


2. Nel caso in cui lo strumento di ripristino non abbia avuto successo, identificare lo stato corrente del RAID sui moduli. Se si verifica ancora un singolo errore di flash su entrambi, tentare un "passaggio di sistema" che ricarichi la corrente attiva e imponga lo standby al ruolo attivo.

Dopo aver ricaricato il disco attivo precedente in "ha-standby", verificarne lo stato RAID in quanto dovrebbe essere ripristinato durante il ricaricamento.
Se il supervisor viene ripristinato correttamente dopo lo switchover, è possibile provare a eseguire di nuovo lo strumento di recupero flash per tentare di riparare il singolo errore del disco sul supervisor attivo corrente, o un altro "switchover di sistema" per ricaricare lo standby attivo corrente e forzare il precedente standby attivo e corrente ripristinato al ruolo attivo. Verificare che il supervisore ricaricato abbia entrambi i dischi riparati di nuovo, se necessario eseguire nuovamente lo strumento di ripristino.


3. Se durante questo processo lo switchover non sta correggendo il RAID, eseguire un "modulo fuori servizio x" per lo standby e quindi "no poweroff module x" per rimuovere completamente il modulo e riaccenderlo.

Se la modalità fuori servizio non riesce, tentare di ricollocare fisicamente lo standby.

Se dopo aver eseguito lo strumento di ripristino un supervisore ripristina il RAID e l'altro ancora presenta un guasto, forzare il supervisore con il singolo guasto a passare in standby con un "cambio di sistema", se necessario. Se il supervisore con un singolo guasto è
già in standby, eseguire un "modulo x fuori servizio" per il modulo in standby e "no poweroff module x" per rimuovere completamente il modulo e riaccenderlo. Se il ripristino non è ancora stato eseguito, provare a ricollocare fisicamente il modulo. Nel caso in cui il ricollocamento non venga corretto,
accedere al prompt di avvio dello switch con la procedura di recupero della password ed eseguire un comando "init system" per reinizializzare il bootflash. Se il problema persiste, provare a eseguire il ripristino manuale.

Nota: Se in un qualsiasi punto lo standby è bloccato in stato "acceso" e non in stato "ha-standby", se non è possibile ottenere il standby completamente attivo con i passaggi precedenti, sarà necessario ricaricare lo chassis.

Scenario F (2 errori su attivo, 0 errori su standby)

Scenario di ripristino:

    2 errori nel

    0 non funziona in standby

Passi per la risoluzione:

Con 2 errori sul supervisore attivo e 0 sul supervisore in standby, è possibile un ripristino senza impatto, a seconda della quantità di configurazione in esecuzione aggiunta dal momento che lo standby non è stato in grado di sincronizzare la configurazione in esecuzione con il supervisore attivo.

La procedura di ripristino prevede la copia della configurazione corrente in esecuzione dal supervisore attivo, il failover al supervisore in standby integro, la copia della configurazione in esecuzione mancante nella nuova configurazione attiva, la connessione manuale della configurazione attiva precedente e l'esecuzione dello strumento di ripristino.

2.  Dopo aver copiato la configurazione corrente dal supervisore attivo, è consigliabile confrontarla con la configurazione di avvio per verificare le modifiche apportate dall'ultimo salvataggio.  Questa condizione può essere rilevata con il comando "show startup-configuration".  Le differenze dipenderanno ovviamente dall'ambiente, ma è bene essere a conoscenza di ciò che potrebbe mancare quando lo standby entra in funzione come attivo.  È inoltre consigliabile copiare le differenze in un blocco note in modo che possano essere aggiunte rapidamente al nuovo supervisore attivo dopo il passaggio.

3.  Dopo aver valutato le differenze, è necessario eseguire il cambio del supervisore.  TAC consiglia di eseguire questa operazione durante un intervento di manutenzione, in quanto potrebbero verificarsi problemi imprevisti.  Il comando per eseguire il failover sullo standby sarà "system switchover".

4.  Il passaggio dovrebbe avvenire molto rapidamente e il nuovo standby inizierà a riavviarsi.  Durante questo periodo si desidera aggiungere nuovamente qualsiasi configurazione mancante alla nuova configurazione attiva.  A tale scopo, è possibile copiare la configurazione dal server TFTP (o da qualsiasi server sia stato salvato in precedenza) o semplicemente aggiungere manualmente la configurazione nella CLI.  Nella maggior parte dei casi le configurazioni mancanti sono molto brevi e l'opzione CLI sarà la più fattibile.

5.  Dopo un po' di tempo il nuovo supervisore dello standby potrebbe tornare online in uno stato "ha-standby", ma ciò che normalmente accade è che rimane bloccato in uno stato "acceso".  Lo stato può essere visualizzato con il comando "show module" e facendo riferimento alla colonna "Status" (Stato) accanto al modulo. 

Se il nuovo dispositivo di standby viene attivato in uno stato "acceso", sarà necessario riattivarlo manualmente.  A tale scopo, eseguire i comandi seguenti, dove "x" è il modulo di standby bloccato nello stato "acceso":

    (config)# modulo fuori servizio x

    (config)# no poweroff module x

6.  Una volta che lo standby è tornato online in uno stato "ha-standby", sarà necessario eseguire lo strumento di ripristino per assicurarsi che il ripristino sia completato.  Lo strumento può essere scaricato al seguente link:

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

Una volta scaricato lo strumento, decompresso e caricato nella bootflash della scatola, sarà necessario eseguire il seguente comando per iniziare il recupero:

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

Lo strumento si avvierà e rileverà i dischi scollegati e tenterà di risincronizzarli con l'array RAID.

È possibile controllare lo stato del ripristino tramite:

# show system internal file /proc/mdstat

Verificare che il ripristino sia in corso. L'operazione di ripristino completo di tutti i dischi in stato [UU] potrebbe richiedere alcuni minuti. Di seguito è riportato un esempio di operazione di ripristino:                                                                                                       
                                        

 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>

Al termine del ripristino, dovrebbe essere visualizzato come segue:

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>

                                                                  
Dopo che tutti i dischi sono in [UU], l'array RAID è completamente di backup con entrambi i dischi sincronizzati.

Scenario G (0 con errori su attivo, 2 con errori su standby)

0 non riesce sul sistema attivo, 2 sul sistema in standby

Scenario di ripristino:

    0 non supera il limite attivo

    2 errori in standby

Passi per la risoluzione:

Con 0 errori sul supervisore attivo e 2 sul supervisore in standby, è possibile un ripristino senza impatto.

La procedura di ripristino consiste nell'eseguire un ricaricamento della modalità standby.

1. In genere, nei supervisori con guasto dual flash si nota che un "reload module x" software può riparare solo parzialmente il RAID o bloccarlo dopo il riavvio.

Pertanto, si consiglia di ricollocare fisicamente il supervisor con il guasto del doppio flash per rimuovere completamente e riapplicare l'alimentazione al modulo, oppure è possibile eseguire le seguenti operazioni (x per lo slot di standby n.):

    # modulo fuori servizio x
    # no poweroff module x

Se si nota che lo stato di standby continua a bloccarsi e alla fine l'alimentazione continua a scorrere dopo i passaggi indicati, ciò è probabilmente dovuto al ricaricamento attivo dello stato di standby per non essere arrivato in tempo.

Ciò può essere dovuto al tentativo di riinizializzare il bootflash/RAID eseguito in standby di avvio, che può impiegare fino a 10 minuti, ma il ripristino viene effettuato dall'utente attivo prima di poter essere completato.

Per risolvere il problema, configurare il seguente comando utilizzando 'x' per lo slot n. di standby bloccato in stato di accensione:

    (config)# avvio manuale in standby del sistema
    (config)# reload module x force-dnld
    
    Quanto sopra lo renderà in modo che l'attivo non resetta automaticamente lo standby, quindi ricarica lo standby e lo forza a sincronizzare la sua immagine dall'attivo.
    
    Attendere 10-15 minuti per verificare se il dispositivo di standby è finalmente in grado di raggiungere lo stato di standby. Quando è in stato di standby, riattivare il riavvio automatico dello standby con:
    
    (config)# sistema senza avvio manuale in standby
    

6.  Una volta che lo standby è tornato online in uno stato "ha-standby", sarà necessario eseguire lo strumento di ripristino per assicurarsi che il ripristino sia completato.  Lo strumento può essere scaricato al seguente link:

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


Una volta scaricato lo strumento, decompresso e caricato nella bootflash della scatola, sarà necessario eseguire il seguente comando per iniziare il recupero:

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

Lo strumento si avvierà e rileverà i dischi scollegati e tenterà di risincronizzarli con l'array RAID.

È possibile controllare lo stato del ripristino tramite:

# show system internal file /proc/mdstat

Verificare che il ripristino sia in corso. L'operazione di ripristino completo di tutti i dischi in stato [UU] potrebbe richiedere alcuni minuti. Di seguito è riportato un esempio di operazione di ripristino:                                                                                                       
                                        

 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>

Al termine del ripristino, dovrebbe essere visualizzato come segue:

  
 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>

Dopo che tutti i dischi sono in [UU], l'array RAID è completamente di backup con entrambi i dischi sincronizzati.

Scenario H (2 con errori su attivo, 1 in standby)

2 errori su attivo, 1 su standby

Scenario di ripristino:

    2 errori nel

    1 errore in standby

Passi per la risoluzione:

Con 2 errori sul supervisore attivo e 1 sul supervisore in standby, è possibile un ripristino senza impatto, a seconda della quantità di configurazione in esecuzione aggiunta dal momento che lo standby non è stato in grado di sincronizzare la configurazione in esecuzione con il supervisore attivo.


La procedura di ripristino prevede il backup della configurazione corrente in esecuzione dal supervisore attivo, il failover al supervisore in standby integro, la copia della configurazione in esecuzione mancante nella nuova configurazione attiva, la connessione manuale della configurazione attiva precedente e l'esecuzione dello strumento di ripristino.


1.  Eseguire il backup esterno della configurazione corrente con il comando "copy running-config tftp: vdc-all". Si noti che in caso di errore della memoria flash doppia, le modifiche apportate alla configurazione dopo il riavvio del sistema in sola lettura non sono presenti nella configurazione di avvio. È possibile esaminare "show system internal raid" per il modulo interessato per determinare quando si è verificato un errore nel secondo disco, ovvero quando il sistema diventa di sola lettura. Da qui è possibile esaminare "show accounting log" per ogni VDC per determinare quali modifiche sono state apportate dopo l'errore del doppio flash, in modo da sapere cosa aggiungere se la configurazione di avvio persiste al momento del ricaricamento.

È possibile che la configurazione di avvio venga cancellata al ricaricamento di un supervisor con errore dual flash, motivo per cui è necessario eseguire il backup esterno della configurazione.


2.  Dopo aver copiato la configurazione corrente dal supervisore attivo, è consigliabile confrontarla con la configurazione di avvio per verificare le modifiche apportate dall'ultimo salvataggio.  Questa condizione può essere rilevata con il comando "show startup-configuration".  Le differenze dipenderanno ovviamente dall'ambiente, ma è bene essere a conoscenza di ciò che potrebbe mancare quando lo standby entra in funzione come attivo.  È inoltre consigliabile copiare le differenze in un blocco note in modo che possano essere aggiunte rapidamente al nuovo supervisore attivo dopo il passaggio.


3.  Dopo aver valutato le differenze, è necessario eseguire il cambio del supervisore.  TAC consiglia di eseguire questa operazione durante un intervento di manutenzione, in quanto potrebbero verificarsi problemi imprevisti.  Il comando per eseguire il failover sullo standby sarà "system switchover".


4.  Il passaggio dovrebbe avvenire molto rapidamente e il nuovo standby inizierà a riavviarsi.  Durante questo periodo si desidera aggiungere nuovamente qualsiasi configurazione mancante alla nuova configurazione attiva.  A tale scopo, è possibile copiare la configurazione dal server TFTP (o da qualsiasi server sia stato salvato in precedenza) o semplicemente aggiungere manualmente la configurazione nella CLI, non copiare direttamente da tftp a configurazione in esecuzione, copiare prima su bootflash e quindi su configurazione in esecuzione.  Nella maggior parte dei casi le configurazioni mancanti sono molto brevi e l'opzione CLI sarà la più fattibile.


5.  Dopo un po' di tempo il nuovo supervisore dello standby potrebbe tornare online in uno stato "ha-standby", ma ciò che normalmente accade è che rimane bloccato in uno stato "acceso".  Lo stato può essere visualizzato con il comando "show module" e facendo riferimento alla colonna "Status" accanto al modulo.


Se il nuovo dispositivo di standby viene attivato in uno stato "acceso", sarà necessario riattivarlo manualmente.  A tale scopo, eseguire i comandi seguenti, dove "x" è il modulo di standby bloccato nello stato "acceso":

    (config)# modulo fuori servizio
    (config)# no poweroff module x        
    
    
Se si nota che lo stato di standby continua a bloccarsi e alla fine l'alimentazione continua a scorrere dopo i passaggi indicati, ciò è probabilmente dovuto al ricaricamento attivo dello stato di standby per non essere arrivato in tempo.
Ciò può essere dovuto al tentativo di riinizializzare il bootflash/RAID eseguito in standby di avvio, che può impiegare fino a 10 minuti, ma il ripristino viene effettuato dall'utente attivo prima di poter essere completato.
Per risolvere il problema, configurare il seguente comando utilizzando 'x' per lo slot n. di standby bloccato in stato di accensione:

    (config)# avvio manuale in standby del sistema
    (config)# reload module x force-dnld
    
    Quanto sopra lo renderà in modo che l'attivo non resetta automaticamente lo standby, quindi ricarica lo standby e lo forza a sincronizzare la sua immagine dall'attivo.
    
    Attendere 10-15 minuti per verificare se il dispositivo di standby è finalmente in grado di raggiungere lo stato di standby. Quando è in stato di standby, riattivare il riavvio automatico dello standby con:
    
    (config)# system no standby manual-boot
   
6.  Una volta che lo standby è tornato online in uno stato "ha-standby", sarà necessario eseguire lo strumento di ripristino per assicurarsi che il ripristino sia completo e per riparare il guasto del disco singolo sul disco attivo.  Lo strumento può essere scaricato al seguente link:

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


Una volta scaricato lo strumento, decompresso e caricato nella bootflash della scatola, sarà necessario eseguire il seguente comando per iniziare il recupero:

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

Lo strumento si avvierà e rileverà i dischi scollegati e tenterà di risincronizzarli con l'array RAID.

È possibile controllare lo stato del ripristino tramite:

# show system internal file /proc/mdstat

Verificare che il ripristino sia in corso. L'operazione di ripristino completo di tutti i dischi in stato [UU] potrebbe richiedere alcuni minuti. Di seguito è riportato un esempio di operazione di ripristino:                                                                                                       

                                       
 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>

Al termine del ripristino, dovrebbe essere visualizzato come segue:

 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>
  

                                                                 
Dopo che tutti i dischi sono in [UU], l'array RAID è completamente di backup con entrambi i dischi sincronizzati.

Se la corrente attiva con un singolo errore non viene ripristinata dallo strumento di ripristino, tentare un altro "passaggio al sistema" assicurandosi che lo stato di standby corrente sia "ha-standby".  Se il problema persiste, contattare Cisco TAC

Scenario I (1 errore su attivo, 2 errori su standby)

Scenario di ripristino:

    1 Errore su

    2 errori in standby

Passi per la risoluzione:

In uno scenario con due supervisori con un guasto sul supervisore attivo e due guasti sul supervisore in standby è possibile un ripristino senza impatto, ma in molti casi potrebbe essere necessario un ricaricamento.

Il processo consisterà innanzitutto nel eseguire il backup di tutte le configurazioni in esecuzione, quindi nel tentare di ripristinare la memoria flash compatta guasta sul dispositivo attivo utilizzando lo strumento di ripristino. Se il processo ha esito positivo, sarà necessario ricaricare manualmente lo standby ed eseguire di nuovo lo strumento di ripristino.  Se il tentativo di recupero iniziale non è in grado di recuperare la memoria flash guasta sul dispositivo attivo, è necessario attivare TAC per tentare un recupero manuale utilizzando il plug-in di debug.

1.  Eseguire il backup esterno della configurazione corrente con il comando "copy running-config tftp: vdc-all".  È inoltre possibile copiare la configurazione in esecuzione su una chiave USB locale se nell'ambiente non è configurato un server TFTP.

2.  Una volta eseguito il backup della configurazione corrente in esecuzione, sarà necessario eseguire lo strumento di ripristino per tentare di ripristinare il flash guasto sul dispositivo attivo.  Lo strumento può essere scaricato al seguente link:

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

Una volta scaricato lo strumento, decompresso e caricato nella bootflash della scatola, sarà necessario eseguire il seguente comando per iniziare il recupero:

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

Lo strumento si avvierà e rileverà i dischi scollegati e tenterà di risincronizzarli con l'array RAID.

È possibile controllare lo stato del ripristino tramite:

# show system internal file /proc/mdstat

Verificare che il ripristino sia in corso. L'operazione di ripristino completo di tutti i dischi in stato [UU] potrebbe richiedere alcuni minuti. Di seguito è riportato un esempio di operazione di ripristino:                                                                                                       
                                        

 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>

Al termine del ripristino, dovrebbe essere visualizzato come segue:

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>

                                                                  
Dopo che tutti i dischi sono in [UU], l'array RAID è completamente di backup con entrambi i dischi sincronizzati.

3.  Se, dopo aver eseguito lo strumento di ripristino nel passaggio 2, non è possibile ripristinare la memoria flash compatta sul supervisore attivo, è necessario contattare TAC per tentare un ripristino manuale utilizzando il plug-in di debug Linux.

4.  Dopo aver verificato che entrambi i lampeggi siano visualizzati come "[UU]" sul lato attivo, si può procedere con il riavvio manuale del supervisore dello standby.  A tale scopo, eseguire i comandi seguenti, dove "x" è il modulo di standby bloccato nello stato "acceso":

    (config)# modulo fuori servizio x

    (config)# no poweroff module x

In questo modo, il supervisore di standby dovrebbe tornare allo stato "ha-standby" (ciò viene verificato visualizzando la colonna Status nell'output "show module").  Se l'operazione ha esito positivo, andare al passaggio 6. In caso contrario, provare la procedura descritta al passaggio 5.

5.  Se si nota che lo stato di standby continua a bloccarsi e alla fine l'alimentazione continua a scorrere dopo i passaggi indicati, ciò è probabilmente dovuto al ricaricamento attivo dello stato di standby per non essere arrivato in tempo.  Ciò può essere dovuto al tentativo di riinizializzare il bootflash/RAID eseguito in standby di avvio, che può impiegare fino a 10 minuti, ma il ripristino viene effettuato dall'utente attivo prima di poter essere completato.  Per risolvere il problema, configurare il seguente comando utilizzando 'x' per lo slot n. di standby bloccato in stato di accensione:

(config)# avvio manuale in standby del sistema
(config)# reload module x force-dnld

Quanto sopra lo renderà in modo che l'attivo non resetta automaticamente lo standby, quindi ricarica lo standby e lo forza a sincronizzare la sua immagine dall'attivo.

Attendere 10-15 minuti per verificare se il dispositivo di standby è finalmente in grado di raggiungere lo stato di standby. Quando è in stato di standby, riattivare il riavvio automatico dello standby con:

(config)# sistema senza avvio manuale in standby

6.  Una volta che lo standby è tornato online in uno stato "ha-standby", sarà necessario eseguire lo strumento di ripristino per assicurarsi che il ripristino sia completato.  È possibile eseguire lo stesso strumento che si ha sul attivo per questo passaggio, non è necessario alcun download aggiuntivo, in quanto lo strumento di ripristino viene eseguito sul attivo e sullo standby.

Scenario J (2 guasti sulla modalità attiva, 2 guasti sulla modalità standby)

Scenario di ripristino:

    2 errori nel

    2 errori in standby

Passi per la risoluzione:

Nota: Si verifica in genere in caso di guasto di due flash, un "ricaricamento" del software potrebbe non ripristinare completamente il RAID e potrebbe richiedere l'esecuzione dello strumento di ripristino o successivi ricaricamenti per il ripristino. In quasi tutti i casi, è stato risolto con un riposizionamento fisico del modulo supervisor. Pertanto, se è possibile l'accesso fisico al dispositivo, dopo aver eseguito il backup della configurazione esternamente, è possibile tentare un ripristino rapido che ha le maggiori probabilità di riuscire riposizionando fisicamente il supervisore quando è pronto a ricaricare il dispositivo. In questo modo si rimuove completamente l'alimentazione dal supervisor e si dovrebbe consentire il ripristino di entrambi i dischi nel RAID. Procedere al passo 3 se il ripristino fisico del nuovo sedile è solo parziale, o al passo 4 se non ha successo in quanto il sistema non è completamente in fase di avvio.

Riepilogo

Wireless LAN Controller serie 9800

Esiste una soluzione permanente a questo problema?

Vedere la sezione Soluzioni a lungo termine più avanti.

Perché non è possibile ripristinare un failover doppio sul server attivo e in standby ricaricando il supervisore di standby e eseguendo il failover?

Il motivo per cui ciò non è possibile è che per consentire al supervisore in standby di entrare in uno stato "ha-standby", il supervisore attivo deve scrivere diverse cose sul suo compact flash (informazioni SNMP, ecc.), cosa che non può fare se ha un doppio errore flash.

Cosa succede se l'utilità di ripristino flash non è in grado di rimontare la memoria flash compatta?

Per le opzioni di questo scenario, contattare Cisco TAC.

Il bug influisce anche su Nexus 7700 Sup2E?

Esiste un difetto separato per il modello N7700 Sup2E - CSCuv64056 .  Lo strumento di ripristino non funziona per il modello N7700.

Lo strumento di ripristino funziona per le immagini NPE?

Lo strumento di ripristino non funziona per le immagini NPE.

Il problema verrà risolto da un problema relativo a una versione risolta del codice?

No. Un ISSU utilizzerà uno switchover supervisor, che potrebbe non funzionare correttamente a causa di un errore del compact flash.

La scheda interessata è stata ripristinata. Lo stato RAID stampa 0xF0, ma i test GOLD hanno ancora esito negativo?

I bit di stato RAID vengono reimpostati dopo il reset della scheda dopo l'applicazione del ripristino automatico.
Tuttavia, non tutte le condizioni di errore possono essere recuperate automaticamente.
Se i bit di stato RAID non vengono stampati come [2/2] [UU], il ripristino è incompleto.
Seguire i passaggi di ripristino elencati

Il guasto del flash avrà un impatto sul funzionamento?

No, ma il sistema potrebbe non essere avviato in caso di interruzione dell'alimentazione. Verranno perse anche le configurazioni di avvio.

Quali sono i requisiti consigliati per un sistema in grado di funzionare correttamente dal punto di vista del cliente in termini di monitoraggio e ripristino?

Controllare lo stato del test GOLD Compact per individuare eventuali errori e tentare il ripristino non appena la prima parte flash si guasta.

È possibile correggere un errore di flash usb non riuscito eseguendo un'operazione ISSU dal codice interessato alla versione corretta?

L'utilità ISSU non correggerà eUSB guasto. L'opzione migliore consiste nell'eseguire lo strumento di ripristino in caso di guasto di un singolo EUSB sull'unità sup o nel ricaricare l'unità sup in caso di guasto di due EUSB.
Una volta risolto il problema, eseguire l'aggiornamento. La correzione per CSCus22805 consente di correggere i singoli errori di EUSB ONLY, mediante scansione del sistema a intervalli regolari e tentativi di riattivare eUSB inaccessibile o di sola lettura utilizzando lo script.
È raro vedere che un guasto del flash usb sul supervisore si verifichi contemporaneamente, quindi questa soluzione sarà efficace.

Quanto tempo impiega il problema a ripresentarsi se si correggono gli errori flash utilizzando il plug-in o il ricaricamento?

In genere è caratterizzata da tempi di attività più lunghi. Non è esattamente quantificato e può variare da un anno o più. In conclusione, maggiore è la pressione sul flash usb in termini di letture/scritture, maggiore è la probabilità che il sistema si trovi in questo scenario.

Show system internal raid (Mostra RAID interno del sistema) mostra due volte lo stato del flash in diverse sezioni. Inoltre, queste sezioni non sono coerenti
La prima sezione mostra lo stato corrente, la seconda lo stato di avvio.
Lo stato attuale è ciò che conta e dovrebbe sempre essere mostrato come UU.

Soluzioni a lungo termine

Questo difetto ha una soluzione nella versione 6.2(14), ma la correzione del firmware è stata aggiunta alla versione 6.2(16) e 7.2(x) e successive. 

Si consiglia di eseguire l'aggiornamento a una versione con la correzione del firmware per risolvere completamente il problema.

Se non è possibile eseguire l'aggiornamento a una versione fissa di NXOS, esistono due possibili soluzioni. 

La soluzione 1 consiste nell'eseguire lo strumento di recupero flash in modo proattivo ogni settimana utilizzando lo scheduler.  La seguente configurazione dell'utilità di pianificazione con lo strumento di recupero flash in bootflash:

utilità di pianificazione
nome processo utilità di pianificazione Flash_Job

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

  esci
nome pianificazione utilità di pianificazione Flash_Recovery
  nome processo Flash_Job
  orario settimanale 7

Note: 

• Il recupero flash deve avere lo stesso nome ed essere in bootflash.
• Il 7 nella configurazione "time week 7" rappresenta un giorno della settimana, sabato in questo caso.
• La frequenza massima consigliata da Cisco per l'esecuzione dello strumento di recupero flash è una volta alla settimana.

 La soluzione 2 è documentata al seguente collegamento alla nota tecnica