El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
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.
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.
Se han observado los siguientes síntomas:
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--------------------------> .
dcd02.ptfrnyfs# copy running-config startup-config
[########################################] 100%
Configuration update aborted: request was aborted
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
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.
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 |
Escenario de recuperación:
1 Fallo en el activo
Pasos para la resolución:
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:
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:
switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the fixed state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
Escenario de recuperación:
2 Fallos en el activo
Pasos para la resolución:
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.
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í:
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.
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í:
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 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í:
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.
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.
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:
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.
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.
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 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:
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.
Escenario de recuperación:
2 Fallos en el activo
2 Fallos en espera
Pasos para la resolución:
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.
Consulte la sección Soluciones a largo plazo más abajo.
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í.
Póngase en contacto con el TAC de Cisco para conocer las opciones de esta situación.
Hay un defecto separado para N7700 Sup2E - CSCuv64056 . La herramienta de recuperación no funcionará para N7700.
La herramienta de recuperación no funciona para las imágenes NPE.
No. Un ISSU utilizará un switchover de supervisor, que puede no funcionar correctamente debido a la falla de la memoria Compact Flash.
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
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.
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.
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.
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 solución 2 se documenta en el siguiente enlace de nota técnica