Recuperação de falha de Compact Flash do Nexus 7000 Supervisor 2/2E

Introduction

Este documento descreve o problema de falha de flash compacto do Nexus 7000 Supervisor 2/2E documentado no defeito de software CSCus22805, em todos os cenários de falha possíveis e nas etapas de recuperação. 

Antes de qualquer solução alternativa, é altamente recomendável ter acesso físico ao dispositivo caso seja necessário recolocar fisicamente.  Para algumas atualizações de reload, o acesso ao console pode ser necessário, e é sempre recomendável executar essas soluções alternativas com acesso ao console do supervisor para observar o processo de inicialização.

Se qualquer uma das etapas das soluções alternativas falhar, entre em contato com o TAC da Cisco para obter opções de recuperação adicionais possíveis. 

Background

Cada supervisor 2/2E N7K é equipado com 2 dispositivos flash eUSB na configuração RAID1, um primário e um espelho. Juntos, eles fornecem repositórios não voláteis para imagens de inicialização, configuração de inicialização e dados de aplicativos persistentes.

O que pode acontecer é que, durante um período de meses ou anos de serviço, um desses dispositivos pode ser desconectado do barramento USB, fazendo com que o software RAID remova o dispositivo da configuração. O dispositivo ainda pode funcionar normalmente com 1/2 dispositivos. No entanto, quando o segundo dispositivo sai da matriz, o bootflash é remontado como somente leitura, o que significa que você não pode salvar a configuração ou os arquivos no bootflash, nem permitir que o standby sincronize com o ativo caso seja recarregado.

Não há impacto operacional em sistemas executados em um estado de falha flash duplo, no entanto, é necessário recarregar o supervisor afetado para se recuperar desse estado. Além disso, qualquer alteração na configuração atual não será refletida na inicialização e será perdida no caso de uma queda de energia.

Sintomas

Estes sintomas foram observados:

• Falha de diagnóstico de flash compacto

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

• Não é possível executar 'copy run start'

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

• eUSB torna-se somente leitura ou não responde

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

• Falhas de ISSU, geralmente ao tentar fazer failover para o supervisor em standby

Diagnóstico

Para diagnosticar o estado atual das placas flash compactas, você precisa usar esses comandos internos. Observe que o comando não será analisado e deve ser digitado completamente:

switch#show system internal raid | grep -A 1 "Informações de status de RAID atual"

switch# show system internal file /proc/mdstat

Se houver dois supervisores no chassi, você também precisará verificar o status do supervisor em espera para determinar o cenário de falha que está enfrentando. Verifique isso colocando o comando no início com a palavra-chave "slot x", onde "x" é o número do slot do supervisor em standby. Isso permite executar o comando remotamente no modo de espera.

switch#slot 2 show system internal raid | grep -A 1 "Informações de status de RAID atual"

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

Esses comandos fornecerão muitas estatísticas e eventos de RAID, mas você só está preocupado com as informações de RAID atuais. 

Na linha "Dados RAID do CMOS", verifique o valor hexadecimal após 0xa5.  Isso mostrará quantas flashes podem estar enfrentando um problema no momento. 

Por exemplo:

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

Nessa saída, você deseja examinar o número ao lado de 0xa5, que é 0xc3.  Você pode usar essas teclas para determinar se a memória compact flash primária ou secundária falhou ou ambas. A saída acima mostra 0xc3, que nos informa que os flashes compacto primário e secundário falharam.

Na saída "/proc/mdstat", verifique se todos os discos estão sendo exibidos como "U", que representa "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]

Neste cenário, você vê que o flash compacto primário não está ativo [_U]. Uma saída íntegra mostrará todos os blocos como [UU].

Note: Ambas as saídas precisam aparecer como íntegras (0xf0 e [UU]) para diagnosticar o supervisor como íntegro. Portanto, se você vir uma saída 0xf0 nos dados do CMOS, mas vir um [_U] no /proc/mdstat, a caixa não está íntegra.

Cenários

Para determinar qual cenário você está enfrentando, você precisará usar os comandos acima na seção "Diagnóstico" para correlacionar com uma Carta do Cenário abaixo.  Usando as colunas, corresponda o número de flashes compactos com falha em cada supervisor. 

Por exemplo, se você viu que o código é 0xe1 no supervisor Ativo e 0xd2 no Standby, isso seria "1 Fail" no Ative e "1 Fail" no Standby, que é a letra "D" do cenário.

Supervisor único:

Supervisores duplos:

Procedimento de recuperação para cada cenário

Cenários de falha de um único supervisor

Cenário A (1 falha na ativação)

Cenário de recuperação:

    1 Falha no estado Ativo

Etapas para a resolução:

1. Carregue a ferramenta de recuperação flash para reparar o flash de inicialização. Você pode fazer o download da ferramenta de recuperação do CCO em utilitários para a plataforma N7000 ou usar o link abaixo:

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

Ele está envolvido em um arquivo compactado tar gz. Descompacte-o para encontrar a ferramenta de recuperação .gbin e um arquivo .pdf readme. Revise o arquivo readme e carregue a ferramenta .gbin no bootflash do N7K. Embora essa recuperação seja projetada para não causar impacto e possa ser executada ao vivo, o TAC recomenda que seja executada em uma janela de manutenção caso surjam problemas inesperados. Depois que o arquivo estiver no bootflash, você poderá executar a ferramenta de recuperação com:

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>

Cenário B (2 Falhas no Ativo)

Cenário de recuperação:

    2 Falha no estado Ativo

Etapas para a resolução:

Note: Geralmente, isso é visto em casos de falhas de flash duplo, uma recarga de software pode não recuperar totalmente o RAID e pode exigir a execução da ferramenta de recuperação ou recarregamentos subsequentes para a recuperação. Em quase todas as ocorrências, isso foi resolvido com uma reinstalação física do módulo supervisor. Portanto, se o acesso físico ao dispositivo for possível, depois de fazer o backup da configuração externamente, você poderá tentar uma recuperação rápida que tenha a maior chance de êxito, recolocando fisicamente o supervisor quando estiver pronto para recarregar o dispositivo. Isso removerá totalmente a alimentação do supervisor e deverá permitir a recuperação de ambos os discos no RAID. Vá para a Etapa 3 se a recuperação da reinstalação física for apenas parcial, ou para a Etapa 4 se ela não tiver êxito total, pois o sistema não está inicializando completamente.

Cenários de falha de supervisor duplo

Cenário C (0 falha no modo ativo, 1 falha no modo de espera)

Cenário de falha:

    0 falha na caixa de diálogo

    1 Falha no modo de espera

Etapas para a resolução:

No cenário de uma configuração de supervisor duplo, sem falhas de flash no ativo e uma única falha no standby, uma recuperação sem impacto pode ser executada.


1. Como o ativo não tem falhas e o standby tem apenas uma única falha, a Ferramenta de Recuperação Flash pode ser carregada no ativo e executada. Após executar a ferramenta, ela será automaticamente copiada para o standby e tentará sincronizar novamente o array.  A ferramenta de recuperação pode ser baixada aqui:

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

Depois de fazer o download da ferramenta, descompactá-la e carregá-la no flash de inicialização da caixa, você precisará executar o seguinte comando para iniciar a recuperação:

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

A ferramenta começará a ser executada e detectará discos desconectados e tentará sincronizá-los novamente com o storage RAID.

Você pode verificar o status da recuperação com:

# show system internal file /proc/mdstat

Verifique se a recuperação está em andamento; pode levar vários minutos para reparar totalmente todos os discos para um status [UU]. Um exemplo de uma recuperação em operação se parece com o seguinte:                                                                                                       
                                        

 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>

Depois que a recuperação for concluída, ele deverá ser semelhante a este:

 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>

                                                                 
Depois que todos os discos estiverem em [U], o array RAID será totalmente copiado com os dois discos sincronizados.

2. Se a Ferramenta de Recuperação Flash não for bem-sucedida, já que o ativo tem os dois discos ativos, o standby deverá ser capaz de sincronizar com êxito com o ativo durante o recarregamento.

Portanto, em uma janela programada, execute um "out-of-service module x" para o supervisor em standby. Recomenda-se ter acesso de console ao supervisor em standby para observar o processo de inicialização caso surjam problemas inesperados. Depois que o supervisor estiver inativo, aguarde alguns segundos e execute o comando "no poweroff module x" para o modo de espera. Aguarde até que o standby inicialize totalmente no status "ha-standby".

Depois que o standby estiver de volta, verifique o RAID com "slot x show system internal raid" e "slot x show system internal file /proc/mdstat".

Se os dois discos não estiverem totalmente em backup após o recarregamento, execute a ferramenta de recuperação novamente.

3. Se a ferramenta de recarregamento e recuperação não tiver êxito, seria recomendável tentar recolocar fisicamente o módulo em espera na janela para tentar limpar a condição.  Se a reinstalação física não for bem-sucedida, tente executar um "init system" a partir do modo de inicialização do switch seguindo as etapas de recuperação de senha para entrar nesse modo durante a inicialização.  Se ainda assim não tiver êxito, entre em contato com o TAC para tentar a recuperação manual.

Cenário D (1 falha na ativação, 0 falha no modo de espera)

Cenário de recuperação:

    1 Falha no estado Ativo

    0 falha no modo de espera

Etapas para a resolução:

No cenário de uma configuração de supervisor duplo, com 1 falha flash no ativo e nenhuma falha no standby, uma recuperação sem impacto pode ser executada usando a ferramenta de recuperação Flash.


1. Como o standby não tem falhas e o ativo tem apenas uma falha, a Ferramenta de Recuperação Flash pode ser carregada no ativo e executada. Após executar a ferramenta, ela será automaticamente copiada para o standby e tentará sincronizar novamente o array.  A ferramenta de recuperação pode ser baixada aqui:

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

Depois de fazer o download da ferramenta, descompactá-la e carregá-la no flash de inicialização do ativo, você precisará executar o seguinte comando para iniciar a recuperação:

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

A ferramenta começará a ser executada e detectará discos desconectados e tentará sincronizá-los novamente com o storage RAID.

Você pode verificar o status da recuperação com:

# show system internal file /proc/mdstat

Verifique se a recuperação está em andamento; pode levar vários minutos para reparar totalmente todos os discos para um status [UU]. Um exemplo de uma recuperação em operação se parece com o seguinte:                                                                                                       
                                        

 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>

Depois que a recuperação for concluída, ele deverá ser semelhante a este:

 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>

                                                                
Depois que todos os discos estiverem em [U], o array RAID será totalmente copiado com os dois discos sincronizados.



2. Se a Ferramenta de Recuperação Flash não for bem-sucedida, a próxima etapa seria executar um "switchover de sistema" para fazer failover dos módulos do supervisor em uma janela de manutenção.

Portanto, em uma janela programada, execute um "switchover de sistema"; é recomendável ter acesso de console para observar o processo de inicialização caso surjam problemas inesperados.  Aguarde até que o standby inicialize totalmente no status "ha-standby".

Depois que o standby estiver de volta, verifique o RAID com "slot x show system internal raid" e "slot x show system internal file /proc/mdstat".

Se os dois discos não estiverem totalmente em backup após o recarregamento, execute a ferramenta de recuperação novamente.


3. Se a ferramenta de recarregamento e recuperação não tiver êxito, seria recomendável tentar recolocar fisicamente o módulo em espera na janela para tentar limpar a condição.  Se a reinstalação física não for bem-sucedida, tente executar um "init system" a partir do modo de inicialização do switch seguindo as etapas de recuperação de senha para entrar nesse modo durante a inicialização.  Se ainda assim não tiver êxito, entre em contato com o TAC para tentar a recuperação manual.

Cenário E (1 falha na ativação, 1 falha no modo de espera)

Cenário de recuperação:

    1 Falha no estado Ativo

    1 Falha no modo de espera

Etapas para a resolução:

No caso de uma única falha de flash tanto no modo ativo como no modo de espera, uma solução alternativa sem impacto ainda pode ser realizada.


1. Como nenhum supervisor está em um estado somente leitura, a primeira etapa é tentar usar a Ferramenta de Recuperação Flash.

A ferramenta de recuperação pode ser baixada aqui:

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

Depois de fazer o download da ferramenta, descompactá-la e carregá-la no flash de inicialização do ativo, você precisará executar o seguinte comando para iniciar a recuperação:

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

Ele detectará automaticamente os discos desconectados no estado ativo e tentará repará-los, bem como copiará automaticamente a si mesmo para o modo de espera e detectará e corrigirá as falhas.

Você pode verificar o status da recuperação com:

# show system internal file /proc/mdstat

Verifique se a recuperação está em andamento; pode levar vários minutos para reparar totalmente todos os discos para um status [UU]. Um exemplo de uma recuperação em operação se parece com o seguinte:                

                                                                                       
 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>

Depois que a recuperação for concluída, ele deverá ser semelhante a este:

 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>

                                                                  
Depois que todos os discos estiverem em [U], o array RAID será totalmente copiado com os dois discos sincronizados.


Se ambos os supervisores recuperarem o status [U], a recuperação estará concluída.  Se a recuperação for parcial ou não tiver sido bem-sucedida, vá para a Etapa 2.


2. Caso a ferramenta de recuperação não tenha sido bem-sucedida, identifique o estado atual do RAID nos módulos. Se ainda houver uma única falha de flash em ambos, tente um "switchover de sistema" que recarregará o ativo atual e forçará o standby para a função ativa.

Depois que o ativo anterior for recarregado de volta no "ha-standby", verifique o status do RAID, pois ele deve ser recuperado durante o recarregamento.
Se o supervisor se recuperar com êxito após o switchover, você poderá tentar executar a ferramenta de recuperação flash novamente para tentar reparar a falha de disco único no supervisor ativo atual ou outro "switchover de sistema" para recarregar o ativo atual e forçar o standby anterior ativo e atual que foi reparado de volta para a função ativa. Verifique se o supervisor recarregado tem os dois discos reparados novamente e execute novamente a ferramenta de recuperação, se necessário.


3. Se durante esse processo o switchover não estiver corrigindo o RAID, execute um "módulo x fora de serviço" para o módulo de espera e depois um "módulo x sem desligamento" para remover completamente e reaplicar a alimentação ao módulo.

Se a ausência de serviço não for bem-sucedida, tente uma recolocação física do standby.

Se após executar a ferramenta de recuperação um supervisor recuperar seu RAID e o outro ainda tiver uma falha, force o supervisor com a única falha a ficar em espera com um "switchover de sistema", se necessário. Se o supervisor com uma única falha for
já em espera, faça um "out-of-service module x" para o módulo em espera e "no poweroff module x" para remover completamente e reaplicar a alimentação ao módulo. Se ainda não estiver se recuperando, tente recolocar fisicamente o módulo. No caso de uma reinstalação não corrigir,
entre no prompt de inicialização do switch usando o procedimento de recuperação de senha e execute um "init system" para reinicializar o flash de inicialização. Se ainda assim não tiver êxito, peça ao TAC para tentar a recuperação manual.

Note: Se, em algum momento, o standby estiver preso em um estado "ligado" e não em um "ha-standby", se não for possível colocar o standby totalmente funcionando de acordo com as etapas acima, será necessário recarregar o chassi.

Cenário F (2 Falhas no estado Ativo, 0 Falhas no estado de espera)

Cenário de recuperação:

    2 Falha no estado Ativo

    0 falha no modo de espera

Etapas para a resolução:

Com 2 falhas no supervisor ativo e 0 no supervisor em standby, uma recuperação sem impacto é possível, dependendo de quanto da configuração em execução foi adicionada, já que o standby não pôde sincronizar sua configuração em execução com o ativo.

O procedimento de recuperação será copiar a configuração atual em execução do supervisor ativo, fazer failover para o supervisor em standby íntegro, copiar a configuração em execução ausente para o novo ativo, colocar manualmente o ativo anterior on-line e, em seguida, executar a ferramenta de recuperação.

2.  Depois que a configuração atual for copiada do supervisor ativo, será uma boa ideia compará-la à configuração inicial para ver o que mudou desde a última gravação.  Isso pode ser visto com "show startup-configuration".  É claro que as diferenças dependerão completamente do ambiente, mas é bom estar ciente do que pode estar faltando quando o standby entra on-line como o ativo.  Também é uma boa ideia ter as diferenças já copiadas em um bloco de notas para que possam ser rapidamente adicionadas ao novo supervisor ativo após a comutação.

3.  Depois que as diferenças forem avaliadas, você precisará executar um switchover de supervisor.  O TAC recomenda que isso seja feito durante uma janela de manutenção, pois podem ocorrer problemas imprevistos.  O comando para executar o failover para o standby será "switchover de sistema".

4.  O switchover deve ocorrer muito rapidamente e o novo standby começará a ser reinicializado.  Durante esse período, você desejará adicionar qualquer configuração ausente de volta à nova configuração ativa.  Isso pode ser feito copiando-se a configuração do servidor TFTP (ou onde quer que ela tenha sido salva anteriormente) ou simplesmente adicionando manualmente a configuração na CLI.  Na maioria dos casos, as configurações ausentes são muito curtas e a opção CLI será a mais viável.

5.  Depois de algum tempo, o novo supervisor em espera pode voltar a ficar on-line em um estado "ha-standby", mas o que normalmente ocorre é que ele fica preso em um estado "ligado".  O estado pode ser visualizado usando o comando "show module" e referindo-se à coluna "Status" ao lado do módulo. 

Se o novo standby for ativado em um estado "ligado", você precisará colocá-lo on-line novamente, manualmente.  Isso pode ser feito emitindo os seguintes comandos, onde "x" é o módulo de standby preso em um estado "ligado":

    (config)# módulo x fora de serviço

    (config)# no poweroff module x

6.  Quando o standby estiver novamente on-line em um estado de "ha-standby", você precisará executar a ferramenta de recuperação para garantir que a recuperação seja concluída.  O download da ferramenta pode ser feito no seguinte link:

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

Depois de fazer o download da ferramenta, descompactá-la e carregá-la no flash de inicialização da caixa, você precisará executar o seguinte comando para iniciar a recuperação:

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

A ferramenta começará a ser executada e detectará discos desconectados e tentará sincronizá-los novamente com o storage RAID.

Você pode verificar o status da recuperação com:

# show system internal file /proc/mdstat

Verifique se a recuperação está em andamento; pode levar vários minutos para reparar totalmente todos os discos para um status [UU]. Um exemplo de uma recuperação em operação se parece com o seguinte:                                                                                                       
                                        

 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>

Depois que a recuperação for concluída, ele deverá ser semelhante a este:

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>

                                                                  
Depois que todos os discos estiverem em [U], o array RAID será totalmente copiado com os dois discos sincronizados.

Cenário G (0 falha no modo ativo, 2 falha no modo de espera)

0 falha no estado Ativo, 2 no estado de espera

Cenário de recuperação:

    0 falha na caixa de diálogo

    2 Falha no modo de espera

Etapas para a resolução:

Com 0 falhas no supervisor ativo e 2 no supervisor em standby, uma recuperação sem impacto é possível.

O procedimento de recuperação será executar uma recarga do standby.

1. É comum observar em supervisores com uma falha de flash duplo que um "módulo de recarga x" do software só possa reparar parcialmente o RAID ou ficar travado quando o roteador for reinicializado.

Portanto, é recomendável recolocar fisicamente o supervisor com falha de flash duplo para remover e reaplicar totalmente a alimentação ao módulo ou você pode executar o seguinte (x para o slot de espera #):

    # módulo x fora de serviço
    # no poweroff module x

Se você vir que o modo de espera continua travando no estado ligado e, por fim, mantém o ciclo de energia após as etapas acima, isso provavelmente ocorre devido ao recarregamento ativo do modo de espera por não ser ativado a tempo.

Isso pode ocorrer devido à tentativa de reinicializar o flash de inicialização/RAID, que pode levar até 10 minutos, mas continua sendo reinicializado pelo ativo antes de ser concluído.

Para resolver isso, configure o seguinte usando 'x' para o slot de standby # travado na inicialização:

    (config)# system standby manual-boot
    (config)# reload module x force-dnld
    
    As informações acima farão com que o ativo não reinicie automaticamente o standby, depois recarregue o standby e force-o a sincronizar sua imagem a partir do ativo.
    
    Aguarde de 10 a 15 minutos para ver se o standby finalmente consegue chegar ao status ha-standby. Depois que ele estiver no status ha-standby, reative as reinicializações automáticas do standby com:
    
    (config)# system no standby manual-boot
    

6.  Quando o standby estiver novamente on-line em um estado de "ha-standby", você precisará executar a ferramenta de recuperação para garantir que a recuperação seja concluída.  O download da ferramenta pode ser feito no seguinte link:

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


Depois de fazer o download da ferramenta, descompactá-la e carregá-la no flash de inicialização da caixa, você precisará executar o seguinte comando para iniciar a recuperação:

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

A ferramenta começará a ser executada e detectará discos desconectados e tentará sincronizá-los novamente com o storage RAID.

Você pode verificar o status da recuperação com:

# show system internal file /proc/mdstat

Verifique se a recuperação está em andamento; pode levar vários minutos para reparar totalmente todos os discos para um status [UU]. Um exemplo de uma recuperação em operação se parece com o seguinte:                                                                                                       
                                        

 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>

Depois que a recuperação for concluída, ele deverá ser semelhante a este:

  
 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>

Depois que todos os discos estiverem em [U], o array RAID será totalmente copiado com os dois discos sincronizados.

Cenário H (2 Falhas no Ativo, 1 no Standby)

2 falha no estado Ativo, 1 no estado de espera

Cenário de recuperação:

    2 Falha no estado Ativo

    1 falha no modo de espera

Etapas para a resolução:

Com 2 falhas no supervisor ativo e 1 no supervisor em standby, uma recuperação sem impacto é possível, dependendo de quanto da configuração em execução foi adicionada, já que o standby não pôde sincronizar sua configuração em execução com o ativo.


O procedimento de recuperação será fazer backup da configuração atual do supervisor ativo, failover para o supervisor em standby íntegro, copiar a configuração atual ausente para o novo ativo, colocar manualmente o ativo anterior on-line e executar a ferramenta de recuperação.


1.  Faça backup de todas as configurações em execução externamente com "copy running-config tftp: vdc-all". Observe que, em caso de falha de flash duplo, as alterações de configuração desde que o sistema foi remontado para somente leitura não estão presentes na configuração de inicialização. Você pode rever o comando "show system internal raid" para o módulo afetado a fim de determinar quando o segundo disco falhou, que é onde o sistema se torna somente leitura. A partir daí, você pode revisar "show accounting log" para cada VDC para determinar quais alterações foram feitas desde a falha de flash duplo, para que você saiba o que adicionar se a configuração de inicialização persistir no recarregamento.

Observe que é possível que a configuração de inicialização seja apagada durante o recarregamento de um supervisor com falha de flash dual, razão pela qual deve ser feito o backup da configuração externamente.


2.  Depois que a configuração atual for copiada do supervisor ativo, será uma boa ideia compará-la à configuração inicial para ver o que mudou desde a última gravação.  Isso pode ser visto com "show startup-configuration".  É claro que as diferenças dependerão completamente do ambiente, mas é bom estar ciente do que pode estar faltando quando o standby entra on-line como o ativo.  Também é uma boa ideia ter as diferenças já copiadas em um bloco de notas para que possam ser rapidamente adicionadas ao novo supervisor ativo após a comutação.


3.  Depois que as diferenças forem avaliadas, você precisará executar um switchover de supervisor.  O TAC recomenda que isso seja feito durante uma janela de manutenção, pois podem ocorrer problemas imprevistos.  O comando para executar o failover para o standby será "switchover de sistema".


4.  O switchover deve ocorrer muito rapidamente e o novo standby começará a ser reinicializado.  Durante esse período, você desejará adicionar qualquer configuração ausente de volta à nova configuração ativa.  Isso pode ser feito copiando a configuração do servidor TFTP (ou onde quer que ela tenha sido salva anteriormente) ou simplesmente adicionando manualmente a configuração na CLI, não copie diretamente do tftp para a configuração atual, copie primeiro para o bootflash e depois para a configuração atual.  Na maioria dos casos, as configurações ausentes são muito curtas e a opção CLI será a mais viável.


5.  Depois de algum tempo, o novo supervisor em espera pode voltar a ficar on-line em um estado "ha-standby", mas o que normalmente ocorre é que ele fica preso em um estado "ligado".  O estado pode ser visualizado usando o comando "show module" e fazendo referência à coluna "Status" ao lado do módulo.


Se o novo standby for ativado em um estado "ligado", você precisará colocá-lo on-line novamente, manualmente.  Isso pode ser feito emitindo os seguintes comandos, onde "x" é o módulo de standby preso em um estado "ligado":

    (config)# módulo fora de serviço
    (config)# no poweroff module x        
    
    
Se você vir que o modo de espera continua travando no estado ligado e, por fim, mantém o ciclo de energia após as etapas acima, isso provavelmente ocorre devido ao recarregamento ativo do modo de espera por não ser ativado a tempo.
Isso pode ocorrer devido à tentativa de reinicializar o flash de inicialização/RAID, que pode levar até 10 minutos, mas continua sendo reinicializado pelo ativo antes de ser concluído.
Para resolver isso, configure o seguinte usando 'x' para o slot de standby # travado na inicialização:

    (config)# system standby manual-boot
    (config)# reload module x force-dnld
    
    As informações acima farão com que o ativo não reinicie automaticamente o standby, depois recarregue o standby e force-o a sincronizar sua imagem a partir do ativo.
    
    Aguarde de 10 a 15 minutos para ver se o standby finalmente consegue chegar ao status ha-standby. Depois que ele estiver no status ha-standby, reative as reinicializações automáticas do standby com:
    
    (config)# system no standby manual-boot
   
6.  Quando o standby estiver novamente on-line em um estado de "ha-standby", você precisará executar a ferramenta de recuperação para garantir que a recuperação seja concluída e para reparar a falha de um único disco no ativo.  O download da ferramenta pode ser feito no seguinte link:

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


Depois de fazer o download da ferramenta, descompactá-la e carregá-la no flash de inicialização da caixa, você precisará executar o seguinte comando para iniciar a recuperação:

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

A ferramenta começará a ser executada e detectará discos desconectados e tentará sincronizá-los novamente com o storage RAID.

Você pode verificar o status da recuperação com:

# show system internal file /proc/mdstat

Verifique se a recuperação está em andamento; pode levar vários minutos para reparar totalmente todos os discos para um status [UU]. Um exemplo de uma recuperação em operação se parece com o seguinte:                                                                                                       

                                       
 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>

Depois que a recuperação for concluída, ele deverá ser semelhante a este:

 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>
  

                                                                 
Depois que todos os discos estiverem em [U], o array RAID será totalmente copiado com os dois discos sincronizados.

Se o ativo atual com uma única falha não for recuperado pela ferramenta de recuperação, tente outro "switchover de sistema" garantindo que seu standby atual esteja no status "ha-standby".  Se ainda não tiver êxito, entre em contato com o TAC da Cisco

Cenário I (1 falha na ativação, 2 falha no modo de espera)

Cenário de recuperação:

    1 Falha no estado Ativo

    2 Falha no modo de espera

Etapas para a resolução:

Em um cenário de supervisor duplo com 1 falha no supervisor ativo e 2 falhas no supervisor em standby, uma recuperação sem impacto pode ser possível, mas em muitos casos uma recarga pode ser necessária.

O processo será primeiro fazer backup de todas as configurações em execução, depois tentar recuperar a memória compact flash com falha no ativo usando a ferramenta de recuperação e, em seguida, se for bem-sucedido, você recarregará manualmente o standby e executará a ferramenta de recuperação novamente.  Se a tentativa de recuperação inicial não for capaz de recuperar a memória flash com falha no ativo, o TAC deve ser acionado para tentar uma recuperação manual usando o plug-in de depuração.

1.  Faça backup de toda a configuração em execução externamente com "copy running-config tftp: vdc-all".  Você também pode copiar a configuração atual para um pen drive local USB se um servidor TFTP não estiver configurado no ambiente.

2.  Depois de fazer o backup da configuração atual, você precisará executar a ferramenta de recuperação para tentar recuperar a memória flash com falha no estado ativo.  O download da ferramenta pode ser feito no seguinte link:

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

Depois de fazer o download da ferramenta, descompactá-la e carregá-la no flash de inicialização da caixa, você precisará executar o seguinte comando para iniciar a recuperação:

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

A ferramenta começará a ser executada e detectará discos desconectados e tentará sincronizá-los novamente com o storage RAID.

Você pode verificar o status da recuperação com:

# show system internal file /proc/mdstat

Verifique se a recuperação está em andamento; pode levar vários minutos para reparar totalmente todos os discos para um status [UU]. Um exemplo de uma recuperação em operação se parece com o seguinte:                                                                                                       
                                        

 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>

Depois que a recuperação for concluída, ele deverá ser semelhante a este:

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>

                                                                  
Depois que todos os discos estiverem em [U], o array RAID será totalmente copiado com os dois discos sincronizados.

3.  Se, depois de executar a ferramenta de recuperação na etapa 2, você não for capaz de recuperar o flash compacto com falha no supervisor ativo, você deve entrar em contato com o TAC para tentar uma recuperação manual usando o plug-in de depuração do linux.

4.  Depois de verificar que as duas piscadas aparecem como "[U]" no ativo, você pode continuar com a reinicialização manual do supervisor em espera.  Isso pode ser feito emitindo os seguintes comandos, onde "x" é o módulo de standby preso em um estado "ligado":

    (config)# módulo x fora de serviço

    (config)# no poweroff module x

Isso deve trazer o supervisor em espera de volta para um estado "ha-standby" (isso é verificado pela exibição da coluna Status na saída "show module").  Se isso for bem-sucedido, vá para a etapa 6; caso contrário, tente o procedimento descrito na etapa 5.

5.  Se você vir que o modo de espera continua travando no estado ligado e, por fim, mantém o ciclo de energia após as etapas acima, isso provavelmente ocorre devido ao recarregamento ativo do modo de espera por não ser ativado a tempo.  Isso pode ocorrer devido à tentativa de reinicializar o flash de inicialização/RAID, que pode levar até 10 minutos, mas continua sendo reinicializado pelo ativo antes de ser concluído.  Para resolver isso, configure o seguinte usando 'x' para o slot de standby # travado na inicialização:

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

As informações acima farão com que o ativo não reinicie automaticamente o standby, depois recarregue o standby e force-o a sincronizar sua imagem a partir do ativo.

Aguarde de 10 a 15 minutos para ver se o standby finalmente consegue chegar ao status ha-standby. Depois que ele estiver no status ha-standby, reative as reinicializações automáticas do standby com:

(config)# system no standby manual-boot

6.  Quando o standby estiver novamente on-line em um estado de "ha-standby", você precisará executar a ferramenta de recuperação para garantir que a recuperação seja concluída.  Você pode executar a mesma ferramenta que você tem no ativo para esta etapa, nenhum download adicional é necessário como a ferramenta de recuperação é executada no ativo e no standby.

Cenário J (2 Falhas no Ativo, 2 Falhas no Standby)

Cenário de recuperação:

    2 Falha no estado Ativo

    2 Falha no modo de espera

Etapas para a resolução:

Note: Geralmente, isso é visto em casos de falhas de flash duplo, uma "recarga" de software pode não recuperar totalmente o RAID e pode exigir a execução da ferramenta de recuperação ou recarregamentos subsequentes para a recuperação. Em quase todas as ocorrências, isso foi resolvido com uma reinstalação física do módulo supervisor. Portanto, se o acesso físico ao dispositivo for possível, depois de fazer o backup da configuração externamente, você poderá tentar uma recuperação rápida que tenha a maior chance de êxito, recolocando fisicamente o supervisor quando estiver pronto para recarregar o dispositivo. Isso removerá totalmente a alimentação do supervisor e deverá permitir a recuperação de ambos os discos no RAID. Vá para a Etapa 3 se a recuperação da reinstalação física for apenas parcial, ou para a Etapa 4 se ela não tiver êxito total, pois o sistema não está inicializando completamente.

Summary

Perguntas freqüentes

Há uma solução permanente para esse problema?

Consulte a seção Soluções de longo prazo abaixo.

Por que não é possível recuperar um failover duplo nos estados ativo e standby recarregando o supervisor em standby e fazendo failover?

A razão pela qual isso não é possível é que, para permitir que o supervisor em standby apareça em um estado de "ha-standby", o supervisor ativo deve gravar várias coisas em seu flash compacto (informações de SNMP, etc.), o que ele não pode fazer se tiver uma falha de flash dupla.

O que acontece se a Flash Recovery Tool não puder remontar o compact flash?

Entre em contato com o TAC da Cisco para obter opções neste cenário.

Esse bug também afeta o Nexus 7700 Sup2E?

Há um defeito separado para o N7700 Sup2E - CSCuv64056 .  A ferramenta de recuperação não funcionará para o N7700.

A ferramenta de recuperação funciona para imagens NPE?

A ferramenta de recuperação não funciona para imagens NPE.

Uma ISSU para uma versão resolvida do código resolverá esse problema?

Não. Um ISSU utilizará um switchover de supervisor, que pode não funcionar corretamente devido à falha da memória compact flash.

Reiniciamos a placa afetada. O status do RAID imprime 0xF0, mas os testes GOLD ainda falham?

Os bits de status do RAID são redefinidos após a redefinição da placa após a aplicação da recuperação automática.
No entanto, nem todas as condições de falha podem ser recuperadas automaticamente.
Se os bits de status do RAID não forem impressos como [2/2] [U], a recuperação estará incompleta.
Siga as etapas de recuperação listadas

A falha de flash terá algum impacto operacional?

Não, mas o sistema pode não inicializar novamente em caso de falta de energia. As configurações de inicialização também serão perdidas.

O que é recomendado para um sistema em funcionamento saudável da perspectiva do cliente em termos de monitoramento e recuperação?

Verifique o status do teste compacto GOLD em busca de falhas e tente a recuperação assim que a primeira peça flash falhar.

Posso corrigir uma falha de flash eusb com falha fazendo um ISSU do código afetado para a versão fixa?

O ISSU não corrigirá o eUSB com falha. A melhor opção é executar a ferramenta de recuperação para uma única falha de eusb no sup ou recarregar o sup em caso de falha dupla de eusb.
Depois que o problema for corrigido, faça o upgrade. A correção para CSCus2805 ajuda a corrigir uma única falha de eusb SOMENTE e faz isso varrendo o sistema em intervalos regulares e tenta despertar eUSB inacessível ou somente leitura usando o script.
É raro ver ambas as falhas de flash eusb no supervisor ocorrendo simultaneamente, portanto, essa solução alternativa será eficaz.

Quanto tempo leva para o problema reaparecer se você corrigir as falhas do flash usando plugin ou reload?

Geralmente, isso é visto por um tempo de atividade maior. Isso não é exatamente quantificado e pode variar de um ano ou mais. A conclusão é que quanto mais estressado o flash do eusb em termos de leitura e gravação, maior a probabilidade de o sistema enfrentar esse cenário.

Show system internal raid mostra o status da flash duas vezes em diferentes seções. Além disso, essas seções não são consistentes
A primeira seção mostra o status atual e a segunda mostra o status de inicialização.
O status atual é o que importa e deve sempre aparecer como UU.

Soluções de longo prazo

Esse defeito tem uma solução alternativa no 6.2(14), mas a correção do firmware foi adicionada ao 6.2(16) e 7.2(x) e posteriores. 

É aconselhável atualizar para uma versão com a correção de firmware para resolver completamente esse problema.

Se você não conseguir atualizar para uma versão fixa do NXOS, há duas soluções possíveis. 

A solução 1 é executar a ferramenta de recuperação flash proativamente todas as semanas usando o agendador.  A seguinte configuração do agendador com a ferramenta de recuperação flash no bootflash:

agendador de recursos
scheduler job name Flash_Job

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

  sair
scheduler schedule name Flash_Recovery
  job name Flash_Job
  tempo semanal 7

Notas: 

• A recuperação flash precisa ter o mesmo nome e estar no flash de inicialização.
• O 7 na configuração "tempo semanal 7" representa um dia da semana, sábado neste caso.
• A frequência máxima que a Cisco recomenda para executar a ferramenta de recuperação flash é de uma vez por semana.

 A solução 2 está documentada no seguinte link de nota técnica