Contenido

Introducción

Background

Síntomas

Diagnóstico

Escenarios

Procedimiento de recuperación para cada escenario

Escenarios de fallos de supervisor único

Escenario A (1 fallo en el activo)

Escenario B (fallo de 2 en el activo)

Escenarios de falla de supervisor dual

Escenario C (0 falla en activo, 1 falla en espera)

Situación D (1 fallo en el activo, 0 fallo en el modo de espera)

Escenario E (1 fallo en el activo, 1 fallo en el modo de espera)

Escenario F (2 Fallos en el Activo, 0 Fallos en el Standby)

Escenario G (0 falla en activo, 2 falla en espera)

Escenario H (2 Fallos en el Activo, 1 en el Standby)

Escenario I (1 fallo en el activo, 2 fallo en el modo de espera)

Escenario J (2 Fallos en el Activo, 2 Fallos en el Standby)

Summary

Preguntas más Frecuentes

¿Existe una solución permanente para este problema?

¿Por qué no es posible recuperar un failover dual en el activo y en espera recargando el supervisor en espera y fallando?

¿Qué sucede si la herramienta de recuperación de Flash no puede volver a montar la memoria flash compacta?

¿Este error también afecta al Nexus 7700 con motor supervisor 2E?

¿Funciona la herramienta de recuperación para imágenes NPE?

¿Resolverá este problema un ISSU a una versión de código resuelta?

Reiniciamos la placa afectada. ¿El estado de Raid imprime 0xF0, pero las pruebas GOLD siguen fallando?

¿Afectará la falla de la memoria flash a la operación?

¿Qué se recomienda para un sistema de funcionamiento saludable desde la perspectiva del cliente en términos de supervisión y recuperación?

Verifique el estado de la prueba compacta GOLD para detectar cualquier falla e intente la recuperación tan pronto como falle la primera parte flash. ¿Puedo corregir una falla de flash eusb fallida al hacer un ISSU desde el código afectado a la versión corregida?

¿Cuánto tiempo tarda el problema en reaparecer si corrige las fallas de flash usando el plugin o recarga?

Soluciones a largo plazo

Introducción

Este documento describe el problema de falla de Compact Flash de Nexus 7000 Supervisor 2/2E documentado en el defecto de software CSCus2805, todos los escenarios de falla posibles y los pasos de recuperación.

Antes de cualquier solución alternativa, se recomienda encarecidamente tener acceso físico al dispositivo en caso de que se requiera un reacomodo físico.  Para algunas actualizaciones de recarga, puede ser necesario el acceso a la consola, y siempre se recomienda realizar estas soluciones alternativas con acceso a la consola al supervisor para observar el proceso de arranque.

Si cualquiera de los pasos de las soluciones alternativas falla, póngase en contacto con el TAC de Cisco para obtener más opciones de recuperación posibles.

Background

Cada supervisor 2/2E N7K está equipado con 2 dispositivos flash eUSB con configuración RAID1, uno principal y un espejo. Juntos proporcionan repositorios no volátiles para imágenes de arranque, configuración de inicio y datos de aplicaciones persistentes.

Lo que puede suceder es que, durante un período de meses o años de servicio, uno de estos dispositivos se desconecte del bus USB, lo que provoca que el software RAID elimine el dispositivo de la configuración. El dispositivo todavía puede funcionar normalmente con 1/2 dispositivos. Sin embargo, cuando el segundo dispositivo se cae de la matriz, la memoria flash de inicialización se vuelve a montar como de solo lectura, lo que significa que no puede guardar la configuración o los archivos en la memoria flash de inicialización, ni permitir que la memoria en espera se sincronice con la activa en caso de que se vuelva a cargar.

No hay impacto operativo en los sistemas que se ejecutan en un estado de falla de flash dual; sin embargo, se necesita una recarga del supervisor afectado para recuperarse de este estado. Además, cualquier cambio en la configuración en ejecución no se reflejará en el inicio y se perderá en caso de un corte de energía.

Síntomas

Se han observado los siguientes síntomas:

- Fallo de diagnóstico de Compact Flash

switch# show diagnostic result module 5

Current bootup diagnostic level: complete

Module 5: Supervisor module-2  (Standby)

Test results: (. = Pass, F = Fail, I = Incomplete,

U = Untested, A = Abort, E = Error disabled)

1) ASICRegisterCheck-------------> .

2) USB---------------------------> .

3) NVRAM-------------------------> .

4) RealTimeClock-----------------> .

5) PrimaryBootROM----------------> .

6) SecondaryBootROM--------------> .

7) CompactFlash------------------> F  <=====

8) ExternalCompactFlash----------> .

9) PwrMgmtBus--------------------> U

10) SpineControlBus---------------> .

11) SystemMgmtBus-----------------> U

12) StatusBus---------------------> U

13) StandbyFabricLoopback---------> .

14) ManagementPortLoopback--------> .

15) EOBCPortLoopback--------------> .

16) OBFL--------------------------> .

- No se puede realizar un 'copy run start'

dcd02.ptfrnyfs# copy running-config startup-config

[########################################] 100%

Configuration update aborted: request was aborted

- eUSB pasa a ser de solo lectura o no 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

- Fallos de ISSU, generalmente al intentar conmutar por error al supervisor en espera

Diagnóstico

Para diagnosticar el estado actual de las tarjetas Compact Flash debe utilizar estos comandos internos. Observe que el comando no se analizará y debe escribirse completamente:

switch# show system internal raid | grep -A 1 "Current RAID status info"

switch# show system internal file /proc/mdstat

Si hay dos supervisores en el chasis, también deberá comprobar el estado del supervisor en espera para determinar a qué escenario de error se enfrenta. Verifique esto anteponiendo el comando con la palabra clave "slot x" donde "x" es el número de slot del supervisor en espera. Esto le permite ejecutar el comando de forma remota en el modo de espera.

switch# slot 2 show system internal raid | grep -A 1 "Current RAID status info"

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

Estos comandos proporcionarán muchas estadísticas y eventos RAID, pero sólo le preocupa la información RAID actual.

En la línea "RAID data from CMOS" (Datos RAID de CMOS), desea ver el valor hexadecimal después de 0xa5.  Esto mostrará cuántos flashes pueden estar enfrentando un problema actualmente.

Por ejemplo:

switch# show system internal raid | grep -A 1 "Current RAID status info"

Current RAID status info:

RAID data from CMOS = 0xa5 0xc3

Desde esta salida, desea ver el número al lado de 0xa5 que es 0xc3.  Puede utilizar estas claves para determinar si la memoria Compact Flash principal o secundaria ha fallado, o ambas. El resultado anterior muestra 0xc3 que nos dice que los flashes compactos primarios y secundarios han fallado.

0xf0

No se notificaron fallos

0xe1

Fallo de flash principal

0xd2

Fallo de flash alternativo (o espejo)

0xc3

Error en primario y alternativo

En la salida "/proc/mdstat" asegúrese de que todos los discos se muestren 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]

En este escenario, verá que la memoria Compact Flash principal no está activa [_U]. Un resultado correcto mostrará todos los bloques como [UU].

Nota: Ambas salidas deben mostrarse como correctas (0xf0 y [UU]) para diagnosticar el supervisor como correcto. Por lo tanto, si ve un resultado 0xf0 en los datos CMOS pero ve un [_U] en /proc/mdstat, el cuadro no es correcto.

Escenarios

Para determinar a qué escenario se enfrenta, necesitará utilizar los comandos anteriores en la sección "Diagnóstico" para correlacionarse con una Carta de escenario a continuación.  Con las columnas, haga coincidir el número de flashes compactos fallidos en cada supervisor.

Por ejemplo, si ha visto que el código es 0xe1 en el supervisor activo y 0xd2 en el modo en espera, sería "1 Fail" en el activo y "1 Fail" en el modo en espera, que es la letra de escenario "D".

Supervisor único:

Carta de escenario

Supervisor activo

Código de supervisor activo

R

1 Fallo

0xe1 o 0xd2

B

2 Fallos

0xc3

Supervisores duales:

Carta de escenario

Supervisor activo

supervisor en espera

Código de supervisor activo

Código de supervisor en espera

C

0 Fallo

1 Fallo

0xf0

0xe1 o 0xd2

D

1 Fallo

0 Fallo

0xe1 o 0xd2

0xf0

E

1 Fallo

1 Fallo

0xe1 o 0xd2

0xe1 o 0xd2

F

2 Fallos

0 Fallo

0xc3

0xf0

G

0 Fallo

2 Fallos

0xf0

0xc3

H

2 Fallos

1 Fallo

0xc3

0xe1 o 0xd2

I

1 Fallo

2 Fallo

0xe1 o 0xd2

0xc3

J

2 Fallos

2 Fallos

0xc3

0xc3

Procedimiento de recuperación para cada escenario

Escenarios de fallos de supervisor único

Escenario A (1 fallo en el activo)

Escenario de recuperación:

1 Fallo en el activo

Pasos para la resolución:

Con un único chasis de supervisor en un escenario de aprobado/suspenso, se puede realizar una recuperación sin impacto. Siga los pasos a continuación para pasar de la recuperación que menos impacta a la que más impacta.

1. Cargar herramienta de recuperación de flash para reparar bootflash. Puede descargar la herramienta de recuperación de CCO en Utilidades para la plataforma N7000 o utilizar el siguiente enlace:

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

Está envuelto en un archivo comprimido tar gz, por favor descomprimir para encontrar la herramienta de recuperación .gbin y un archivo .pdf readme. Revise el archivo Léame y cargue la herramienta .gbin en la memoria de inicialización del N7K. Aunque esta recuperación está diseñada para que no tenga impacto y se puede realizar en tiempo real, TAC recomienda realizar la recuperación en una ventana de mantenimiento en caso de que surjan problemas inesperados. Después de que el archivo esté en bootflash, puede ejecutar la herramienta de recuperación con:

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

La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.

Puede comprobar el estado de recuperación con:

# show system internal file /proc/mdstat

Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:

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>

Una vez finalizada la recuperación, debe verse de la siguiente manera:

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>

Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.

2. Si la herramienta de recuperación de Flash no fue exitosa en el paso 1, el siguiente paso sería recopilar registros y hacer que TAC intente recuperar manualmente los discos usando el plugin de depuración, tenga en cuenta que esto puede no ser exitoso si la herramienta de recuperación no fue exitosa.

Recopilar:

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. Si la recuperación manual no funciona y solo hay un supervisor, es probable que sea necesario volver a cargar el chasis para recuperarlo.

*Sin embargo*, si tiene un supervisor de repuesto en un dispositivo de laboratorio, puede intentar cargarlo en la ranura en espera (en una ventana de mantenimiento) para ver si puede sincronizarse completamente con el estado activo en HA (alta disponibilidad).

Dado que RAID es sólo un único disco fallido, debería ser posible la sincronización en espera con el activo. Si esta es una opción, vea si el modo de espera se sincroniza completamente con el activo con "show module" y "show system redundancy status" para verificar que el modo de espera esté en estado "ha-standby". Esto indica que debería ser posible un Stateful Switchover (SSO) usando el comando "system switchover". Después de que el modo de espera esté activo, asegúrese de que la configuración se guarde externamente, "copy run tftp: vdc-all" y, a continuación, guarde completamente para iniciar con "copy run start vdc-all". Después de esto puede intentar "switchover del sistema", que recargará el activo actual y forzará el standby actual a activo. Después de que el activo se recargue en modo de espera, debería recuperar automáticamente su matriz RAID. Puede verificar esto después de que el supervisor recargado vuelva a estar en estado "ha-standby" y realice un "slot x show system internal raid" para verificar que todos los discos sean [UU]. Si los discos aún no están completamente respaldados, intente ejecutar la herramienta de recuperación nuevamente para intentar resolver cualquier problema persistente. Si esto sigue sin tener éxito, puede probar un "módulo fuera de servicio x" para el módulo afectado, seguido de un "módulo no poweroff x". Si esto sigue sin funcionar, intente volver a instalar físicamente el módulo afectado. Si todavía no se recupera, esto podría ser una falla de HW legítima y requerir una RMA; sin embargo, puede intentar volver a cargar en el modo de inicio del switch usando el procedimiento de recuperación de contraseña y realizar un "sistema de inicialización" como un intento final de recuperación.

Si no hay un supervisor de repuesto disponible, una recarga completa se realiza necesariamente con el comando "reload". En este caso, se recomienda tener acceso físico al dispositivo en caso de que se requiera un reacomodo físico. Haga copias de seguridad externas de todas las configuraciones en ejecución, y se recomienda tenerlas presentes en un disco USB junto con el sistema y las imágenes de inicio para estar seguros. Después de que se realice la recarga y el dispositivo esté activo, verifique que el estado de RAID sea [UU] y ejecute la herramienta de recuperación si no parece completamente reparada. Si el sistema no está funcionando o la herramienta de recuperación sigue sin funcionar, vuelva a colocar físicamente el módulo supervisor y observe el proceso de arranque a través de la consola. Si un reinicio físico no se recupera, entre en el cargador usando el procedimiento de recuperación de contraseña, ingrese al modo de inicio del switch iniciando la imagen kickstart, luego realice un "sistema de inicialización" para intentar reiniciar la memoria de inicialización. Esto borraría los archivos en la memoria flash de inicialización, por lo que es crucial tener todos los archivos y la configuración necesarios respaldados antes de estos pasos.

Si todo lo demás falla, es probable que se trate de un caso poco común de fallo de hardware real, y el supervisor tendría que estar autorizado mediante RMA y posiblemente EFA. Por este motivo, se debe realizar una copia de seguridad externa de toda la configuración antes de realizar los pasos de recuperación. En caso de que se requiera una RMA de emergencia, tendrá toda la configuración necesaria para realizar una copia de seguridad del sistema rápidamente.

Escenario B (fallo de 2 en el activo)

Escenario de recuperación:

2 Fallos en el activo

Pasos para la resolución:

En el caso de un solo supervisor con falla de flash dual, debe realizarse una recarga disruptiva para recuperarse.

1. Copia de seguridad de toda la configuración en ejecución externamente con "copy run tftp: vdc-all". Tenga en cuenta que en caso de falla de flash dual, los cambios de configuración desde que el sistema se remontó a solo lectura no están presentes en la configuración de inicio. Puede revisar "show run diff | i \+" para determinar qué cambios se realizaron desde la falla de flash dual para que sepa qué agregar si la configuración de inicio es diferente de la configuración en ejecución al recargar.

Tenga en cuenta que es posible que la configuración de inicio se elimine al recargar un supervisor con falla de flash dual, por lo que se debe realizar una copia de seguridad de la configuración externamente.

2. Recargue el dispositivo, se recomienda tener acceso a la consola y el acceso físico puede ser necesario. El supervisor debe recargar y reparar su memoria de inicialización. Después de que el sistema esté activo, verifique que ambos discos estén activos y funcionando con el estado [UU] en "show system internal file /proc/mdstat" y "show system internal raid". Si ambos discos están en funcionamiento, la recuperación ha finalizado y puede trabajar para restaurar toda la configuración anterior. Si la recuperación no se ha realizado correctamente o se ha realizado parcialmente correctamente, vaya al paso 3.

Nota: Se observa comúnmente en casos de fallas de flash duales, una recarga de software podría no recuperar completamente el RAID y podría requerir la ejecución de la herramienta de recuperación o recargas subsiguientes para recuperarse. En casi todos los casos, se ha resuelto con una reinstalación física del módulo supervisor. Por lo tanto, si es posible el acceso físico al dispositivo, después de realizar una copia de seguridad de la configuración externamente, puede intentar una recuperación rápida que tenga más posibilidades de éxito volviendo a colocar físicamente al supervisor cuando esté listo para recargar el dispositivo. Esto eliminará completamente la energía del supervisor y debería permitir la recuperación de ambos discos en el RAID. Vaya al paso 3 si la recuperación física de la reinstalación es sólo parcial, o al paso 4 si no es totalmente satisfactoria porque el sistema no se está iniciando por completo.

3. En el caso de una recuperación parcial, lo que significa que después de la recarga un disco está activo y el otro sigue inactivo con el estado [U_], el siguiente paso recomendado sería intentar ejecutar la herramienta de recuperación de Flash para resincronizar el otro disco. Si la herramienta de recuperación no funciona, póngase en contacto con el TAC para intentar realizar pasos de recuperación manuales. También se puede intentar una reinstalación física del supervisor.

Si la recarga no da como resultado que el supervisor se inicie por completo, realice un reinicio físico del módulo supervisor. Tenga en cuenta que se observa comúnmente en una condición de falla de flash dual que una "recarga" de software no recupera completamente ambos discos ya que la energía no se elimina por completo del módulo, lo que se logra con una reinstalación física. Si la reinstalación física no se realiza correctamente, vaya al paso 4.

4. En el caso de que un reinicio físico no sea exitoso, el siguiente paso sería interrumpir el mensaje del cargador usando los pasos de recuperación de contraseña, cargar el kickstart al modo de inicio del switch y realizar un "sistema de inicialización", que borrará la memoria flash de inicialización e intentará reparar la matriz. Si el sistema de inicialización se completa o falla y aún así ve un problema, intente volver a colocar físicamente.

Si todo lo demás falla, es probable que se trate de un caso poco común de fallo de hardware real, y el supervisor tendría que estar autorizado mediante RMA y posiblemente EFA. Por este motivo, se debe realizar una copia de seguridad externa de toda la configuración antes de realizar los pasos de recuperación. En caso de que se requiera una RMA de emergencia, tendrá toda la configuración necesaria para realizar una copia de seguridad del sistema rápidamente.

Escenarios de falla de supervisor dual

Escenario C (0 falla en activo, 1 falla en espera)

Escenario de falla:

0 Fallos en el activo

1 Fallo en espera

Pasos para la resolución:

En el escenario de una configuración de supervisor dual, sin fallas de flash en el activo y una sola falla en el modo en espera, se puede realizar una recuperación que no afecte.

1. Como el activo no tiene fallas y el modo de espera solo tiene una falla, la Herramienta de Recuperación de Flash se puede cargar en el activo y ejecutarse. Después de ejecutar la herramienta, se copiará automáticamente en el modo de espera e intentará sincronizar la matriz.  La herramienta de recuperación se puede descargar aquí:

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

Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización de la caja, deberá ejecutar el siguiente comando para comenzar la recuperación:

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

La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.

Puede comprobar el estado de recuperación con:

# show system internal file /proc/mdstat

Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:

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>

Una vez finalizada la recuperación, debe verse de la siguiente manera:

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>

Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.

2. Si la herramienta de recuperación de Flash no funciona, ya que el activo tiene ambos discos activados, el modo en espera debe poder sincronizarse correctamente con el activo durante la recarga.

Por lo tanto, en una ventana programada, realice una "x de módulo fuera de servicio" para el supervisor en espera, se recomienda tener acceso de consola al modo en espera para observar el proceso de inicio en caso de que surjan problemas inesperados. Después de que el supervisor esté inactivo, espere unos segundos y luego ejecute "no poweroff module x" para el modo de espera. Espere hasta que el modo de espera se inicie completamente en el estado "ha-standby".

Una vez que el modo de espera esté activo, verifique el RAID con "slot x show system internal raid" y "slot x show system internal file /proc/mdstat".

Si no se realiza una copia de seguridad completa de ambos discos después de la recarga, ejecute de nuevo la herramienta de recuperación.

3. Si la herramienta de recarga y recuperación no tiene éxito, se recomienda intentar volver a colocar físicamente el módulo en espera en la ventana para intentar borrar la condición.  Si la reinstalación física no es exitosa, intente realizar un "sistema de inicialización" desde el modo de inicio del switch siguiendo los pasos de recuperación de contraseña para entrar en este modo durante el arranque.  Si sigue sin tener éxito, póngase en contacto con el TAC para intentar la recuperación manual.

Situación D (1 fallo en el activo, 0 fallo en el modo de espera)

Escenario de recuperación:

1 Fallo en el activo

0 Fallos en espera

Pasos para la resolución:

En el escenario de una configuración de supervisor dual, con 1 falla de flash en el activo y sin fallas en el modo de espera, se puede realizar una recuperación sin impacto mediante la herramienta de recuperación de Flash.

1. Como el modo de espera no tiene fallas y el activo solo tiene una falla, la herramienta de recuperación de Flash se puede cargar en el activo y ejecutarse. Después de ejecutar la herramienta, se copiará automáticamente en el modo de espera e intentará sincronizar la matriz.  La herramienta de recuperación se puede descargar aquí:

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

Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización del activo, deberá ejecutar el siguiente comando para iniciar la recuperación:

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

La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.

Puede comprobar el estado de recuperación con:

# show system internal file /proc/mdstat

Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:

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>

Una vez finalizada la recuperación, debe verse de la siguiente manera:

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>

Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.

2. Si la herramienta de recuperación de Flash no funciona, el siguiente paso sería realizar un "switchover del sistema" para conmutar por error los módulos supervisores en una ventana de mantenimiento.

Por lo tanto, en una ventana programada, realice un "switchover del sistema", se recomienda tener acceso a la consola para observar el proceso de arranque en caso de que surjan problemas inesperados.  Espere hasta que el modo de espera se inicie completamente en el estado "ha-standby".

Una vez que el modo de espera esté activo, verifique el RAID con "slot x show system internal raid" y "slot x show system internal file /proc/mdstat".

Si no se realiza una copia de seguridad completa de ambos discos después de la recarga, ejecute de nuevo la herramienta de recuperación.

3. Si la herramienta de recarga y recuperación no tiene éxito, se recomienda intentar volver a colocar físicamente el módulo en espera en la ventana para intentar borrar la condición.  Si la reinstalación física no es exitosa, intente realizar un "sistema de inicialización" desde el modo de inicio del switch siguiendo los pasos de recuperación de contraseña para entrar en este modo durante el arranque.  Si sigue sin tener éxito, póngase en contacto con el TAC para intentar la recuperación manual.

Escenario E (1 fallo en el activo, 1 fallo en el modo de espera)

Escenario de recuperación:

1 Fallo en el activo

1 Fallo en espera

Pasos para la resolución:

En el caso de que se produzca un único fallo de flash tanto en el modo activo como en el modo en espera, se puede lograr una solución alternativa que no afecte a la capacidad.

1. Como ningún supervisor está en estado de solo lectura, el primer paso es intentar utilizar la herramienta de recuperación de Flash.

La herramienta de recuperación se puede descargar aquí:

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

Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización del activo, deberá ejecutar el siguiente comando para iniciar la recuperación:

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

Detectará automáticamente discos desconectados en el activo e intentará repararlos, así como se copiará automáticamente al modo de espera y detectará y corregirá los fallos allí.

Puede comprobar el estado de recuperación con:

# show system internal file /proc/mdstat

Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:

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>

Una vez finalizada la recuperación, debe verse de la siguiente manera:

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>

Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.

Si ambos supervisores recuperan el estado [UU], la recuperación se completa.  Si la recuperación es parcial o no se realizó correctamente, vaya al paso 2.

2. En caso de que la herramienta de recuperación no funcionara, identifique el estado actual del RAID en los módulos. Si todavía hay una falla de flash en ambos, intente un "switchover del sistema" que recargará el activo actual y forzará el modo de espera al rol activo.

Después de que el activo anterior se vuelva a cargar en "ha-standby", verifique su estado de RAID, ya que debe recuperarse durante la recarga.

Si el supervisor se recupera correctamente después del switchover, puede intentar ejecutar la herramienta de recuperación de flash de nuevo para intentar reparar el fallo de disco único en el supervisor activo actual, o bien otro "switchover del sistema" para volver a cargar el activo actual y forzar el activo anterior y el en espera actual que se reparó de nuevo en el rol activo. Verifique que el supervisor recargado tenga ambos discos reparados nuevamente, vuelva a ejecutar la herramienta de recuperación si es necesario.

3. Si durante este proceso el switchover no está reparando el RAID, ejecute un "módulo fuera de servicio x" para el modo de espera y luego "no poweroff module x" para retirar completamente y volver a aplicar la energía al módulo.

Si el estado fuera de servicio no es correcto, intente volver a colocar físicamente el modo en espera.

Si después de ejecutar la herramienta de recuperación un supervisor recupera su RAID y el otro aún tiene una falla, fuerce al supervisor con la falla única a estar en espera con un "switchover del sistema" si es necesario. Si el supervisor con una única falla es

ya en espera, realice un "módulo fuera de servicio x" para el módulo en espera y un "módulo sin apagado x" para retirar por completo y volver a aplicar la alimentación al módulo. Si aún no se está recuperando, intente volver a colocar físicamente el módulo. En el caso de que no se corrija la reinstalación,

entre en la indicación de inicio del switch mediante el procedimiento de recuperación de contraseña y haga un "sistema de inicialización" para reiniciar la memoria flash de inicio. Si esto sigue sin tener éxito, solicite a TAC que intente la recuperación manual.

Nota: Si en algún momento el modo de espera se mantiene en un estado de "encendido" y no de "espera en espera", si no se puede activar completamente el modo de espera con los pasos anteriores, se requerirá una recarga del chasis.

Situación F (2 fallos en el activo, 0 fallos en el espera)

Escenario de recuperación:

2 Fallos en el activo

0 Fallos en espera

Pasos para la resolución:

Con 2 fallas en el supervisor activo y 0 en el supervisor en espera, es posible una recuperación sin impacto, dependiendo de la cantidad de la configuración en ejecución que se ha agregado ya que el standby no pudo sincronizar su configuración en ejecución con el activo.

El procedimiento de recuperación consistirá en copiar la configuración en ejecución actual del supervisor activo, realizar una conmutación por error al supervisor en espera correcto, copiar la configuración en ejecución que falta en el nuevo supervisor activo, poner en línea manualmente el activo anterior y, a continuación, ejecutar la herramienta de recuperación.

1.  Haga una copia de seguridad de toda la configuración en ejecución externamente con "copy running-config tftp: vdc-all". Tenga en cuenta que en caso de falla de flash dual, los cambios de configuración desde que el sistema se remontó a solo lectura no están presentes en la configuración de inicio. Puede revisar "show system internal raid" para el módulo afectado para determinar cuándo falló el segundo disco, que es donde el sistema pasa a ser de solo lectura. Desde allí, puede revisar "show accounting log" para cada VDC para determinar qué cambios se hicieron desde la falla de flash dual, de modo que sepa qué agregar si la configuración de inicio persiste luego de la recarga.

Tenga en cuenta que es posible que la configuración de inicio se elimine al recargar un supervisor con falla de flash dual, por lo que se debe realizar una copia de seguridad de la configuración externamente.

2.  Una vez que se haya copiado la configuración en ejecución del supervisor activo, será una buena idea compararla con la configuración de inicio para ver qué ha cambiado desde la última vez que se guardó.  Esto se puede ver con "show startup-configuration".  Por supuesto, las diferencias dependerán completamente del entorno, pero es bueno ser consciente de lo que puede faltar cuando el modo de espera se conecta como activo.  También es una buena idea tener las diferencias ya copiadas en un bloc de notas para que se puedan agregar rápidamente al nuevo supervisor activo después del cambio.

3.  Una vez evaluadas las diferencias, deberá realizar un switchover de supervisor.  TAC recomienda que esto se realice durante una ventana de mantenimiento, ya que pueden ocurrir problemas imprevistos.  El comando para realizar el failover al standby será "system switchover".

4.  El switchover debe ocurrir muy rápidamente y el nuevo modo de espera comenzará a reiniciarse.  Durante este tiempo, deseará volver a agregar cualquier configuración que falte al nuevo activo.  Esto se puede hacer copiando la configuración desde el servidor TFTP (o donde se haya guardado anteriormente) o simplemente agregando manualmente la configuración en la CLI.  En la mayoría de los casos, las configuraciones que faltan son muy cortas y la opción CLI será la más factible.

5.  Después de un tiempo, el nuevo supervisor en espera puede volver a estar en línea en un estado de "espera ha", pero lo que ocurre normalmente es que se bloquea en un estado de "encendido".  El estado se puede ver usando el comando "show module" y haciendo referencia a la columna "Status" junto al módulo.

Si el nuevo modo de espera aparece en estado "encendido", tendrá que volver a conectarlo manualmente.  Esto se puede hacer ejecutando los siguientes comandos, donde "x" es el módulo en espera atascado en un estado "encendido":

(config)# out-of-service module x

(config)# no poweroff module x

6.  Una vez que el modo de espera vuelva a estar en línea en un estado "ha-standby", tendrá que ejecutar la herramienta de recuperación para asegurarse de que la recuperación se ha completado.  La herramienta se puede descargar en el siguiente enlace:

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

Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización de la caja, deberá ejecutar el siguiente comando para comenzar la recuperación:

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

La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.

Puede comprobar el estado de recuperación con:

# show system internal file /proc/mdstat

Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:

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>

Una vez finalizada la recuperación, debe verse de la siguiente manera:

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>

Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.

Escenario G (0 falla en activo, 2 falla en espera)

0 Falla en el Activo, 2 en el Standby

Escenario de recuperación:

0 Fallos en el activo

2 Fallos en espera

Pasos para la resolución:

Con 0 fallas en el supervisor activo y 2 en el supervisor en espera, es posible una recuperación sin impacto.

El procedimiento de recuperación consistirá en realizar una recarga del modo en espera.

1. Se observa comúnmente en supervisores con una falla de flash dual que un software "reload module x" solo puede reparar parcialmente el RAID o que se atasque encendido al reiniciar.

Por lo tanto, se recomienda volver a colocar físicamente el supervisor con falla de flash dual para remover por completo y volver a aplicar la energía al módulo, o puede realizar lo siguiente (x para la ranura en espera #):

# out-of-service module x

# no poweroff module x

Si observa que el modo en espera se mantiene atascado en el estado encendido y, en última instancia, mantiene el ciclo de alimentación después de los pasos anteriores, es probable que esto se deba a la recarga activa del modo en espera por no estar encendido a tiempo.

Esto puede deberse a que el arranque en espera intenta reiniciar su bootflash/RAID, lo que puede tardar hasta 10 minutos, pero el activo lo reinicia antes de que pueda lograr.

Para resolver esto, configure lo siguiente usando 'x' para el nº de ranura en espera bloqueado en encendido:

(config)# system standby manual-boot

(config)# reload module x force-dnld

Lo anterior hará que el activo no reinicie automáticamente el modo de espera, y luego recargue el modo de espera y fuerce la sincronización de su imagen del modo activo.

Espere de 10 a 15 minutos para ver si el modo de espera finalmente puede alcanzar el estado de espera en espera. Una vez que se encuentre en estado de espera, vuelva a habilitar los reinicios automáticos del modo de espera con:

(config)# system no standby manual-boot

6.  Una vez que el modo de espera vuelva a estar en línea en un estado "ha-standby", tendrá que ejecutar la herramienta de recuperación para asegurarse de que la recuperación se ha completado.  La herramienta se puede descargar en el siguiente enlace:

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

Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización de la caja, deberá ejecutar el siguiente comando para comenzar la recuperación:

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

La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.

Puede comprobar el estado de recuperación con:

# show system internal file /proc/mdstat

Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:

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>

Una vez finalizada la recuperación, debe verse de la siguiente manera:

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>

Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.

Escenario H (2 fallos en el activo, 1 en el en espera)

2 Fallos en el Activo, 1 en el Standby

Escenario de recuperación:

2 Fallos en el activo

1 Falla en espera

Pasos para la resolución:

Con 2 fallas en el supervisor activo y 1 en el supervisor en espera, es posible una recuperación sin impacto, dependiendo de la cantidad de la configuración en ejecución que se ha agregado ya que el standby no pudo sincronizar su configuración en ejecución con el activo.

El procedimiento de recuperación consistirá en realizar una copia de seguridad de la configuración en ejecución actual desde el supervisor activo, realizar una conmutación por error al supervisor en espera en buen estado, copiar la configuración en ejecución que falta en la nueva configuración activa, poner en línea manualmente la configuración activa anterior y, a continuación, ejecutar la herramienta de recuperación.

1.  Realice una copia de seguridad externa de toda la configuración en ejecución con "copy running-config tftp: vdc-all". Tenga en cuenta que en caso de falla de flash dual, los cambios de configuración desde que el sistema se remontó a solo lectura no están presentes en la configuración de inicio. Puede revisar "show system internal raid" para el módulo afectado para determinar cuándo falló el segundo disco, que es donde el sistema pasa a ser de solo lectura. Desde allí puede revisar "show accounting log" para cada VDC para determinar qué cambios se hicieron desde la falla de flash dual para que sepa qué agregar si la configuración de inicio persiste luego de la recarga.

Tenga en cuenta que es posible que la configuración de inicio se elimine al recargar un supervisor con falla de flash dual, por lo que se debe realizar una copia de seguridad de la configuración externamente.

2.  Una vez que se haya copiado la configuración en ejecución del supervisor activo, será una buena idea compararla con la configuración de inicio para ver qué ha cambiado desde la última vez que se guardó.  Esto se puede ver con "show startup-configuration".  Por supuesto, las diferencias dependerán completamente del entorno, pero es bueno ser consciente de lo que puede faltar cuando el modo de espera se conecta como activo.  También es una buena idea tener las diferencias ya copiadas en un bloc de notas para que se puedan agregar rápidamente al nuevo supervisor activo después del cambio.

3.  Una vez evaluadas las diferencias, deberá realizar un switchover de supervisor.  TAC recomienda que esto se realice durante una ventana de mantenimiento, ya que pueden ocurrir problemas imprevistos.  El comando para realizar el failover al standby será "system switchover".

4.  El switchover debe ocurrir muy rápidamente y el nuevo modo de espera comenzará a reiniciarse.  Durante este tiempo, deseará volver a agregar cualquier configuración que falte al nuevo activo.  Esto se puede hacer copiando la configuración desde el servidor TFTP (o donde se guardó anteriormente) o simplemente agregando manualmente la configuración en la CLI, no copie directamente desde tftp a running-configuration, copie primero a bootflash y luego a la configuración en ejecución.  En la mayoría de los casos, las configuraciones que faltan son muy cortas y la opción CLI será la más factible.

5.  Después de un tiempo, el nuevo supervisor en espera puede volver a estar en línea en un estado de "espera ha", pero lo que ocurre normalmente es que se bloquea en un estado de "encendido".  El estado se puede ver usando el comando "show module" y haciendo referencia a la columna "Status" junto al módulo.

Si el nuevo modo de espera aparece en estado "encendido", tendrá que volver a conectarlo manualmente.  Esto se puede hacer ejecutando los siguientes comandos, donde "x" es el módulo en espera atascado en un estado "encendido":

(config)# módulo fuera de servicio

(config)# no poweroff module x

Si observa que el modo en espera se mantiene atascado en el estado encendido y, en última instancia, mantiene el ciclo de alimentación después de los pasos anteriores, es probable que esto se deba a la recarga activa del modo en espera por no estar encendido a tiempo.

Esto puede deberse a que el arranque en espera intenta reiniciar su bootflash/RAID, lo que puede tardar hasta 10 minutos, pero el activo lo reinicia antes de que pueda lograr.

Para resolver esto, configure lo siguiente usando 'x' para el nº de ranura en espera bloqueado en encendido:

(config)# system standby manual-boot

(config)# reload module x force-dnld

Lo anterior hará que el activo no reinicie automáticamente el modo de espera, y luego recargue el modo de espera y fuerce la sincronización de su imagen del modo activo.

Espere de 10 a 15 minutos para ver si el modo de espera finalmente puede alcanzar el estado de espera en espera. Una vez que se encuentre en estado de espera, vuelva a habilitar los reinicios automáticos del modo de espera con:

(config)# system no standby manual-boot

6.  Una vez que el modo de espera vuelva a estar en línea en un estado "ha-standby", tendrá que ejecutar la herramienta de recuperación para asegurarse de que la recuperación se ha completado y para reparar la falla de disco único en el activo.  La herramienta se puede descargar en el siguiente enlace:

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

Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización de la caja, deberá ejecutar el siguiente comando para comenzar la recuperación:

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

La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.

Puede comprobar el estado de recuperación con:

# show system internal file /proc/mdstat

Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:

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>

Una vez finalizada la recuperación, debe verse de la siguiente manera:

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>

Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.

Si la herramienta de recuperación no recupera el activo actual con una única falla, intente otro "switchover del sistema" asegurándose de que su espera actual esté en estado "ha-standby".  Si sigue sin tener éxito, póngase en contacto con Cisco TAC

Escenario I (1 fallo en el activo, 2 fallo en el modo de espera)

Escenario de recuperación:

1 Fallo en el activo

2 Fallos en espera

Pasos para la resolución:

En un escenario de supervisor dual con 1 falla en el supervisor activo y 2 fallas en el supervisor en espera, puede ser posible una recuperación sin impacto, pero en muchos casos puede ser necesaria una recarga.

El proceso consistirá en realizar primero una copia de seguridad de todas las configuraciones en ejecución, luego intentar recuperar la memoria Compact Flash fallida en el activo mediante la herramienta de recuperación y, a continuación, si tiene éxito, volverá a cargar manualmente el modo de espera y ejecutar la herramienta de recuperación de nuevo.  Si el intento de recuperación inicial no puede recuperar la memoria flash fallida en el activo, TAC debe participar para intentar una recuperación manual mediante el plugin de depuración.

1.  Haga una copia de seguridad de toda la configuración en ejecución externamente con "copy running-config tftp: vdc-all".  También puede copiar running-config en una memoria USB local si un servidor TFTP no está configurado en el entorno.

2.  Una vez que se realiza una copia de seguridad de la configuración en ejecución actual, tendrá que ejecutar la herramienta de recuperación para intentar una recuperación de la flash fallida en el activo.  La herramienta se puede descargar en el siguiente enlace:

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

Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización de la caja, deberá ejecutar el siguiente comando para comenzar la recuperación:

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

La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.

Puede comprobar el estado de recuperación con:

# show system internal file /proc/mdstat

Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:

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>

Una vez finalizada la recuperación, debe verse de la siguiente manera:

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>

Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.

3.  Si, después de ejecutar la Herramienta de recuperación en el paso 2, no puede recuperar la memoria Compact Flash fallida en el supervisor activo, debe comunicarse con el TAC para intentar una recuperación manual mediante el plugin de depuración de linux.

4.  Después de verificar que ambos destellos se muestren como "[UU]" en el activo, puede continuar con el reinicio manual del supervisor en espera.  Esto se puede hacer ejecutando los siguientes comandos, donde "x" es el módulo en espera atascado en un estado "encendido":

(config)# out-of-service module x

(config)# no poweroff module x

Esto debería llevar al supervisor en espera de nuevo a un estado "ha-standby" (esto se verifica al ver la columna Status en la salida "show module").  Si el resultado es correcto, vaya al paso 6; de lo contrario, intente el procedimiento descrito en el paso 5.

5.  Si observa que el modo en espera se mantiene atascado en el estado encendido y, en última instancia, mantiene el ciclo de alimentación después de los pasos anteriores, es probable que esto se deba a la recarga activa del modo en espera por no estar encendido a tiempo.  Esto puede deberse a que el arranque en espera intenta reiniciar su bootflash/RAID, lo que puede tardar hasta 10 minutos, pero el activo lo reinicia antes de que pueda lograr.  Para resolver esto, configure lo siguiente usando 'x' para el nº de ranura en espera bloqueado en encendido:

(config)# system standby manual-boot

(config)# reload module x force-dnld

Lo anterior hará que el activo no reinicie automáticamente el modo de espera, y luego recargue el modo de espera y fuerce la sincronización de su imagen del modo activo.

Espere de 10 a 15 minutos para ver si el modo de espera finalmente puede alcanzar el estado de espera en espera. Una vez que se encuentre en estado de espera, vuelva a habilitar los reinicios automáticos del modo de espera con:

(config)# system no standby manual-boot

6.  Una vez que el modo de espera vuelva a estar en línea en un estado "ha-standby", tendrá que ejecutar la herramienta de recuperación para asegurarse de que la recuperación se ha completado.  Puede ejecutar la misma herramienta que tiene en el activo para este paso, no se necesita ninguna descarga adicional ya que la herramienta de recuperación se ejecuta en el activo y en espera.

Situación J (2 Fallos en el Activo, 2 Fallos en el Standby)

Escenario de recuperación:

2 Fallos en el activo

2 Fallos en espera

Pasos para la resolución:

En un supervisor dual con falla de flash dual, debe realizarse una recarga disruptiva para recuperarse. Siga los siguientes pasos para la resolución:

1. Haga una copia de seguridad de toda la configuración en ejecución externamente con "copy running-config tftp: vdc-all". Tenga en cuenta que en caso de falla de flash dual, los cambios de configuración desde que el sistema se remontó a solo lectura no están presentes en la configuración de inicio. Puede revisar "show system internal raid" para el módulo afectado para determinar cuándo falló el segundo disco, que es donde el sistema pasa a ser de solo lectura. Desde allí, puede revisar "show accounting log" para cada VDC para determinar qué cambios se hicieron desde la falla de flash dual, de modo que sepa qué agregar si la configuración de inicio persiste luego de la recarga.

Tenga en cuenta que es posible que la configuración de inicio se elimine al recargar un supervisor con falla de flash dual, por lo que se debe realizar una copia de seguridad de la configuración externamente.

2. Recargue el dispositivo, se recomienda tener acceso a la consola y el acceso físico puede ser necesario. El supervisor debe recargar y reparar su memoria de inicialización. Después de que el sistema esté activo, verifique que ambos discos estén activos y funcionando con el estado [UU] en "show system internal file /proc/mdstat" y "show system internal raid". Si ambos discos están en funcionamiento, la recuperación ha finalizado y puede trabajar para restaurar toda la configuración anterior. Si la recuperación no se ha realizado correctamente o se ha realizado parcialmente correctamente, vaya al paso 3.

Nota: Se observa comúnmente en casos de fallas de flash duales, una "recarga" de software puede no recuperar completamente el RAID y puede requerir la ejecución de la herramienta de recuperación o recargas subsiguientes para recuperarse. En casi todos los casos, se ha resuelto con una reinstalación física del módulo supervisor. Por lo tanto, si es posible el acceso físico al dispositivo, después de realizar una copia de seguridad de la configuración externamente, puede intentar una recuperación rápida que tenga más posibilidades de éxito volviendo a colocar físicamente al supervisor cuando esté listo para recargar el dispositivo. Esto eliminará completamente la energía del supervisor y debería permitir la recuperación de ambos discos en el RAID. Vaya al paso 3 si la recuperación física de la reinstalación es sólo parcial, o al paso 4 si no es totalmente satisfactoria porque el sistema no se está iniciando por completo.

3. En el caso de una recuperación parcial, lo que significa que después de la recarga un disco está activo y el otro sigue inactivo con el estado [U_], el siguiente paso recomendado sería intentar ejecutar la herramienta de recuperación de Flash para resincronizar el otro disco. Si la herramienta de recuperación no funciona, póngase en contacto con el TAC para intentar realizar pasos de recuperación manuales. También se puede intentar una reinstalación física del supervisor.  La herramienta de recuperación se puede descargar desde el siguiente enlace:

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

Si la recarga no da como resultado que ambos supervisores se inicien completamente, realice un reinicio físico del módulo supervisor. Tenga en cuenta que se observa comúnmente en una condición de falla de flash dual que una "recarga" de software no recupera completamente ambos discos ya que la energía no se elimina por completo del módulo, lo que se logra con una reinstalación física. Si la reinstalación física no se realiza correctamente, vaya al paso 4.

4. En el caso de que un reinicio físico no sea exitoso, el siguiente paso sería interrumpir el mensaje del cargador usando los pasos de recuperación de contraseña, cargar el kickstart al modo de inicio del switch y realizar un "sistema de inicialización", que borrará la memoria flash de inicialización e intentará reparar la matriz. Si el sistema de inicialización se completa o falla y aún así ve un problema, intente volver a colocar físicamente.

Si después de completar todos los pasos anteriores la recuperación no tiene éxito, es probable que se trate de un caso excepcional de fallo de hardware real y el supervisor tendrá que ser sustituido a través de RMA. Por este motivo, se debe realizar una copia de seguridad externa de toda la configuración antes de realizar los pasos de recuperación. En caso de que se requiera una RMA de emergencia, tendrá toda la configuración necesaria para realizar una copia de seguridad del sistema rápidamente.

Summary

Preguntas más Frecuentes

¿Existe una solución permanente para este problema?

Consulte la sección Soluciones a largo plazo más abajo.

¿Por qué no es posible recuperar un failover dual en el activo y en espera recargando el supervisor en espera y fallando?

La razón por la que esto no es posible es porque para permitir que el supervisor en espera aparezca en un estado "ha-standby", el supervisor activo debe escribir varias cosas en su compact flash (información SNMP, etc.), lo que no puede hacer si tiene una falla de flash dual en sí.

¿Qué sucede si la herramienta de recuperación de Flash no puede volver a montar la memoria flash compacta?

Póngase en contacto con el TAC de Cisco para conocer las opciones de esta situación.

¿Este error también afecta al Nexus 7700 con motor supervisor 2E?

Hay un defecto separado para N7700 Sup2E - CSCuv64056 .  La herramienta de recuperación no funcionará para N7700.

¿Funciona la herramienta de recuperación para imágenes NPE?

La herramienta de recuperación no funciona para las imágenes NPE.

¿Resolverá este problema un ISSU a una versión de código resuelta?

No. Un ISSU utilizará un switchover de supervisor, que puede no funcionar correctamente debido a la falla de la memoria Compact Flash.

Reiniciamos la placa afectada. ¿El estado de Raid imprime 0xF0, pero las pruebas GOLD siguen fallando?

Los bits de estado de RAID se restablecen después del restablecimiento de la placa después de aplicar la recuperación automática.

Sin embargo, no todas las condiciones de falla se pueden recuperar automáticamente.

Si los bits de estado RAID no se imprimen como [2/2] [UU], la recuperación está incompleta.

Siga los pasos de recuperación enumerados

¿Afectará la falla de la memoria flash a la operación?

No, pero es posible que el sistema no se inicie en caso de fallo de alimentación. Las configuraciones de inicio también se perderán.

¿Qué se recomienda para un sistema de funcionamiento saludable desde la perspectiva del cliente en términos de supervisión y recuperación?

Verifique el estado de la prueba compacta GOLD para detectar cualquier falla e intente la recuperación tan pronto como falle la primera parte flash.

¿Puedo corregir una falla de flash eusb fallida al hacer un ISSU desde el código afectado a la versión corregida?

ISSU no corregirá eUSB fallido. La mejor opción es ejecutar la herramienta de recuperación para un solo fallo de eusb en el sup o volver a cargar el sup en caso de fallo de eusb dual.

Una vez corregido el problema, realice la actualización. La corrección para CSCus2805 ayuda a corregir SOLO la falla de eusb individual y lo hace escaneando el sistema a intervalos regulares e intenta reactivar eUSB inaccesible o de solo lectura usando el script.

Es raro ver que ambos fallos de flash eusb en el supervisor se producen simultáneamente, por lo que esta solución alternativa será eficaz.

¿Cuánto tiempo tarda el problema en reaparecer si corrige las fallas de flash usando el plugin o recarga?

Por lo general, se ve por un tiempo de actividad más largo. Esto no se cuantifica exactamente y puede oscilar entre un año o más. La conclusión es que cuanto mayor sea la tensión en la flash eusb en términos de lectura y escritura, mayor será la probabilidad de que el sistema se encuentre con este escenario.

Show system internal raid muestra el estado de flash dos veces en diferentes secciones. Además, estas secciones no son coherentes

La primera sección muestra el estado actual y la segunda sección muestra el estado de inicio.

El estado actual es lo que importa y siempre debe aparecer como UU.

Soluciones a largo plazo

Este defecto tiene una solución alternativa en 6.2(14), pero la corrección del firmware se añadió a 6.2(16) y 7.2(x) y posteriores.

Se recomienda actualizar a una versión con la corrección del firmware para resolver completamente este problema.

Si no puede actualizar a una versión fija de NXOS, existen dos soluciones posibles.

La solución 1 es ejecutar la herramienta de recuperación de flash de forma proactiva cada semana mediante el planificador.  La siguiente configuración del planificador con la herramienta de recuperación de flash en la memoria de inicialización:

programador de características

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

salir

scheduler schedule name Flash_Recovery

job name Flash_Job

tiempo semanal 7

Notas:

- La recuperación de flash debe tener el mismo nombre y estar en la memoria de inicialización.

- El 7 en la configuración "time weekly 7" representa un día de la semana, el sábado en este caso.

- La frecuencia máxima que recomienda Cisco para ejecutar la herramienta de recuperación de flash es una vez a la semana.

La solución 2 se documenta en el siguiente enlace de nota técnica