Contents

Introduction

Background

Sintomas

Diagnóstico

Cenários

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 B (2 Falhas no Ativo)

Cenários de falha de supervisor duplo

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

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

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

Cenário F (2 Falha no Ative, 0 Falha no Standby)

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

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

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

Cenário J (2 Falha no Ative, 2 Falha no Standby)

Summary

Perguntas freqüentes

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

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

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

Esse bug também afeta o Nexus 7700 Sup2E?

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

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

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

A falha de flash terá algum impacto operacional?

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?

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

Soluções de longo prazo

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.

0xf0

Nenhuma falha relatada

0xe1

Falha na memória flash principal

0xd2

Falha no flash alternativo (ou espelho)

0xc3

Falha tanto no primário como no alternativo

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:

Carta de Cenário

Supervisor ativo

Código de Supervisor Ativo

R

1 Falha

0xe1 ou 0xd2

B

2 Falhas

0xc3

Supervisores duplos:

Carta de Cenário

Supervisor ativo

supervisor em espera

Código de Supervisor Ativo

Código de Supervisor em Espera

C

0 Falha

1 Falha

0xf0

0xe1 ou 0xd2

D

1 Falha

0 Falha

0xe1 ou 0xd2

0xf0

E

1 Falha

1 Falha

0xe1 ou 0xd2

0xe1 ou 0xd2

F

2 Falhas

0 Falha

0xc3

0xf0

G

0 Falha

2 Falhas

0xf0

0xc3

H

2 Falhas

1 Falha

0xc3

0xe1 ou 0xd2

I

1 Falha

2 Falha

0xe1 ou 0xd2

0xc3

J

2 Falhas

2 Falhas

0xc3

0xc3

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:

Com um único chassi de supervisor em um cenário de aprovado/reprovado, uma recuperação sem impacto pode ser executada. Siga as etapas abaixo na ordem de menor impacto para maior impacto na recuperaçã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:

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

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 tiver sido bem-sucedida na etapa 1, a próxima etapa seria coletar logs e fazer com que o TAC tente recuperar manualmente os discos usando o plug-in de depuração; observe que isso pode não ser bem-sucedido se a ferramenta de recuperação não tiver sido bem-sucedida.

Coletar:

show version

show module

show accounting log

show logging logfile

show system internal raid (Comando oculto)

show system internal kernel messages

show logging onboard

3. Se a recuperação manual não estiver funcionando e houver apenas um único supervisor, provavelmente será necessário recarregar o chassi para fazer a recuperação.

*Entretanto*, se você tiver um supervisor sobressalente em um dispositivo de laboratório, poderá tentar carregá-lo no slot de espera (em uma janela de manutenção) para ver se ele pode ser totalmente sincronizado com o status ativo no HA (High Availability, alta disponibilidade).

Como o RAID é apenas um único disco com falha, a sincronização de espera para o ativo deve ser possível. Se essa for uma opção, verifique se o standby está totalmente sincronizado com o ativo com "show module" e "show system redundancy status" para verificar se o standby está no status "ha-standby". Isso indica que um Stateful Switchover (SSO) deve ser possível usando o comando "system switchover". Depois que o standby estiver ativado, certifique-se de que a configuração esteja salva externamente, "copy run tftp: vdc-all" e, em seguida, salve totalmente na inicialização com "copy run start vdc-all". Depois disso, você poderá tentar a "comutação do sistema", que irá recarregar o estado ativo atual e irá forçar o estado de vigília atual a ficar ativo. Após o ativo ser recarregado no modo de espera, ele deve recuperar automaticamente seu storage RAID. Você pode verificar isso depois que o supervisor recarregado estiver de volta no status "ha-standby" e executar um "slot x show system internal raid" para verificar se todos os discos estão [UU]. Se o backup dos discos ainda não estiver completo, tente executar a ferramenta de recuperação novamente para tentar eliminar os problemas remanescentes. Se ainda não tiver êxito, tente um "módulo x fora de serviço" para o módulo afetado, seguido por um "módulo x sem desligamento". Se ainda assim não conseguir, tente recolocar fisicamente o módulo afetado. Se ainda não estiver recuperado, isso pode ser uma falha legítima de HW e exigir uma RMA, no entanto, você pode tentar recarregar no modo de inicialização do switch usando o procedimento de recuperação de senha e executar um "init system" como uma tentativa final de recuperação.

Se nenhum supervisor sobressalente estiver disponível, uma recarga completa será necessária com o comando "reload". Nesse caso, é recomendável ter acesso físico ao dispositivo caso seja necessário recolocar fisicamente o dispositivo. Faça backup de todas as configurações em execução externamente e é recomendável tê-las presentes em um disco USB junto com o sistema e iniciar as imagens para garantir a segurança. Depois que o recarregamento for executado e o dispositivo estiver ativado, verifique se o status do RAID é [UU] e execute a ferramenta de recuperação se ela não parecer totalmente reparada. Se o sistema não estiver sendo ativado ou se a ferramenta de recuperação ainda não estiver funcionando, recoloque fisicamente o módulo supervisor e observe o processo de inicialização através do console. Se uma reinstalação física não se recuperar, entre no carregador usando o procedimento de recuperação de senha, entre no modo de inicialização do switch inicializando a imagem kickstart e execute um "init system" para tentar reinicializar o bootflash. Isso apagaria os arquivos no bootflash, portanto, é crucial ter todos os arquivos e configurações necessários em backup antes dessas etapas.

Se tudo mais falhar, é provável que seja um caso raro de falha de hardware real, e o supervisor precisaria ser RMA e possivelmente EFA. É por isso que deve ser feito o backup externo de toda a configuração antes das etapas de recuperação. Caso seja necessária uma RMA de emergência, você terá toda a configuração necessária para ativar o sistema rapidamente.

Cenário B (2 Falhas no Ativo)

Cenário de recuperação:

2 Falha no estado Ativo

Etapas para a resolução:

No cenário de um único supervisor com falha de flash duplo, uma recarga com interrupções deve ser executada para a recuperação.

1. Faça backup de toda a configuração em execução externamente com "copy run 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 revisar "show run diff | i \+" para determinar quais alterações foram feitas desde a falha da flash dupla, para que você saiba o que adicionar se a configuração de inicialização for diferente da configuração de execução após o 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. Recarregue o dispositivo; é altamente recomendável ter acesso ao console e o acesso físico poderá ser necessário. O supervisor deve recarregar e reparar seu flash de inicialização. Depois que o sistema estiver em funcionamento, verifique se ambos os discos estão em funcionamento com o status [UU] em "show system internal file /proc/mdstat" e "show system internal raid". Se ambos os discos estiverem ativos e em execução, a recuperação estará concluída e você poderá trabalhar para restaurar todas as configurações anteriores. Se a recuperação não tiver sido bem-sucedida ou tiver sido parcialmente bem-sucedida, vá para a etapa 3.

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.

3. No caso de uma recuperação parcial, significando que após recarregar um disco está ativo e o outro ainda está inativo com o status [U_], a próxima etapa recomendada seria tentar executar a Flash Recovery Tool para ressincronizar o outro disco. Se a ferramenta de recuperação não for bem-sucedida, entre em contato com o TAC para tentar as etapas de recuperação manual. Também é possível tentar a recolocação física do supervisor.

Se o recarregamento não resultar na inicialização completa do supervisor, execute uma reinstalação física do módulo supervisor. Observe que geralmente é visto em uma condição de falha de flash duplo que uma "recarga" de software não recupera totalmente os dois discos, pois a alimentação não é totalmente removida do módulo, o que é realizado com uma reinstalação física. Se a recolocação física não for bem-sucedida, vá para a etapa 4.

4. No caso de uma reinstalação física não ser bem-sucedida, a próxima etapa seria entrar no prompt do carregador usando as etapas de recuperação de senha, carregar o kickstart no modo de inicialização do switch e executar um "init system", que limpará o flash de inicialização e tentará reparar o storage. Se o sistema init for concluído ou falhar e ainda detectar um problema, tente outra recolocação física.

Se tudo mais falhar, é provável que seja um caso raro de falha de hardware real, e o supervisor precisaria ser RMA e possivelmente EFA. É por isso que deve ser feito o backup externo de toda a configuração antes das etapas de recuperação. Caso seja necessária uma RMA de emergência, você terá toda a configuração necessária para ativar o sistema rapidamente.

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.

1.  Faça backup de toda a configuração 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 "show system internal raid" para o módulo afetado para 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-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:

Em um supervisor duplo com falha de flash duplo, uma recarga com interrupções deve ser executada para a recuperação. Siga as seguintes etapas para resolver:

1. Faça backup de toda a configuração atual 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 "show system internal raid" para o módulo afetado para 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. Recarregue o dispositivo; é altamente recomendável ter acesso ao console e o acesso físico poderá ser necessário. O supervisor deve recarregar e reparar seu flash de inicialização. Depois que o sistema estiver em funcionamento, verifique se ambos os discos estão em funcionamento com o status [UU] em "show system internal file /proc/mdstat" e "show system internal raid". Se ambos os discos estiverem ativos e em execução, a recuperação estará concluída e você poderá trabalhar para restaurar todas as configurações anteriores. Se a recuperação não tiver sido bem-sucedida ou tiver sido parcialmente bem-sucedida, vá para a etapa 3.

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.

3. No caso de uma recuperação parcial, significando que após recarregar um disco está ativo e o outro ainda está inativo com o status [U_], a próxima etapa recomendada seria tentar executar a Flash Recovery Tool para ressincronizar o outro disco. Se a ferramenta de recuperação não for bem-sucedida, entre em contato com o TAC para tentar as etapas de recuperação manual. Também é possível tentar a recolocação física do supervisor.  A ferramenta de recuperação pode ser baixada no seguinte link:

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

Se o recarregamento não resultar na inicialização completa de ambos os supervisores, execute uma recolocação física do módulo supervisor. Observe que geralmente é visto em uma condição de falha de flash duplo que uma "recarga" de software não recupera totalmente os dois discos, pois a alimentação não é totalmente removida do módulo, o que é realizado com uma reinstalação física. Se a recolocação física não for bem-sucedida, vá para a etapa 4.

4. No caso de uma reinstalação física não ser bem-sucedida, a próxima etapa seria entrar no prompt do carregador usando as etapas de recuperação de senha, carregar o kickstart no modo de inicialização do switch e executar um "init system", que limpará o flash de inicialização e tentará reparar o storage. Se o sistema init for concluído ou falhar e ainda detectar um problema, tente outra recolocação física.

Se após concluir todas as etapas acima a recuperação não for bem-sucedida, é provável que seja um caso raro de falha real de hardware e o supervisor precisará ser substituído via RMA. É por isso que deve ser feito o backup externo de toda a configuração antes das etapas de recuperação. Caso seja necessária uma RMA de emergência, você terá toda a configuração necessária para ativar o sistema rapidamente.

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