Validar y recuperar los puntos de acceso Catalyst en 17.12 afectados por un fallo de actualización

Introducción

Este documento describe el procedimiento de recuperación cuando los AP se ven afectados por el ID de bug de Cisco CSCwf25731 y CSCwf37271.

Contexto

Las actualizaciones o las APSPs aplicadas a los sistemas que ejecutan actualmente 17.12.4/5/6/6a o que ejecutaron previamente estas versiones durante una cantidad considerable de tiempo pueden causar que los modelos de AP afectados (verifique la lista de puntos de acceso afectados a continuación) entren en un loop de inicio bajo ciertas condiciones, desencadenadas por una falla de instalación de la imagen debido a un espacio de disco insuficiente en el almacenamiento de AP. Aunque esto no afecta a las operaciones diarias ni a las SMU, es un riesgo crítico durante las actualizaciones de código de controlador completo ISSU o las instalaciones de APSP, ya que estos procedimientos implican actualizaciones de imagen de puntos de acceso.

Es necesario seguir procesos adicionales que requieren pasos obligatorios de comprobación previa de actualizaciones mencionados en este documento, ya que no existe una solución alternativa de configuración.

Para resolver esto, debe instalar la corrección específica de la versión de APSP (que se muestra en la tabla de códigos fijos a continuación) en el WLC antes de que los AP intenten actualizar, o utilizar la limpieza de APSP (disponible para 17.15.4d y 17.18.2) si ya se ha movido a una versión posterior pero ejecutó cualquiera de las versiones afectadas. Incluso si no está seguro del historial de su sistema, se recomienda realizar comprobaciones de almacenamiento antes de cualquier actualización o instalación de APSP si las versiones afectadas estuvieron presentes en su entorno.

Detalles de la causa raíz

Los AP que ejecutan 17.12.4 a 17.12.6a se ven afectados por un bug de biblioteca que genera un archivo de registro persistente: /storage/cnssdaemon.log. Este archivo crece 5 MB al día y no se borra mediante reinicios, agotando eventualmente el espacio de almacenamiento del dispositivo. Por consiguiente, si el AP se está ejecutando desde la partición de arranque 1 (Part1), y la partición de arranque 2 (Part2) está llena debido al archivo de registro, el proceso de actualización fallará porque no puede almacenar la nueva imagen en la partición de arranque 2, lo que potencialmente conduce a un loop de arranque. Para evitar esto, debe borrar el almacenamiento o asegurarse de que el AP se haya iniciado desde la partición 2 antes de intentar cualquier actualización adicional siguiendo las instrucciones de este documento.

Códigos y puntos de acceso afectados

Puntos de acceso afectados

Los siguientes modelos de puntos de acceso son los únicos susceptibles a este problema. Si su red no utiliza ninguno de estos modelos específicos, su entorno no se verá afectado y no será necesario realizar ninguna otra acción.

• Catalyst 9124 (I/D/E)
• Catalyst 9130 (E/S)
• Catalyst 9136I
• Catalyst 9162I
• Catalyst 9163E
• Catalyst 9164I
• Catalyst 9166 (I/D1)
• Catalyst IW9167 (E/S)

Códigos afectados

Para verificar esto a través de su red, ejecute el siguiente comando de todos los WLCs y verifique si el código presente en sus WLCs se enumera en la tabla abajo.

#show version | in Version

Alternativamente, puede hacer lo mismo desde los AP. Verifique el resultado para ver si la imagen principal o de respaldo está ejecutando una imagen afectada de las enumeradas en la tabla.

#show version | in Image

Nota: Nota: En general, si la red no se está ejecutando y no ha ejecutado 17.12.4, 17.12.5, 17.12.6/6a en el pasado, el problema no es aplicable.

Códigos fijos

La siguiente tabla enumera las versiones de software WLC y sus correspondientes APSPs (Access Point Service Packs) que contienen la corrección para este bug. Tenga en cuenta que, para las versiones que se enumeran a continuación, la corrección solo está disponible actualmente a través de la instalación de APSP en el momento de escribir este documento.

Ruta de actualización y aplicabilidad de errores

Utilice la tabla a continuación para determinar si sus versiones actuales del software del WLC y AP se aplican para este bug y qué pasos de upgrade tomar. Si su implementación actual coincide con cualquiera de estas versiones en la tabla Bug applicable y upgrade path, debe realizar las comprobaciones previas de almacenamiento explicadas en la sección Comprobaciones previas de actualización antes de intentar realizar actualizaciones adicionales.

Error no aplicable y ruta de actualización

La siguiente tabla muestra si sus WLC y AP no se aplican para este bug:

Error aplicable y ruta de actualización

La siguiente tabla muestra si sus WLC y AP se aplican para este bug:

Comprobaciones previas de actualización

Si su entorno se ve afectado por este error, siga estos pasos obligatorios para garantizar una recuperación y actualización segura:

1. Identificar: Ejecute las comprobaciones previas manuales o automatizadas para identificar qué puntos de acceso específicos son aplicables para el error. Se recomienda encarecidamente realizar una comprobación previa automatizada.
2. Recuperar: Para cualquier AP marcado, siga los procedimientos de recuperación mencionados en la sección Recuperación.
3. Controle lo siguiente: Vuelva a ejecutar las comprobaciones previas para confirmar que todos los dispositivos están en buen estado y que se ha resuelto el problema de almacenamiento.
4. Actualizar: Continúe con la actualización a los APSPs fijos enumerados en la Tabla de Versiones Fijas.

Comprobación previa manual

1. Desde el WLC, puede verificar las columnas de imagen principal y de respaldo para confirmar si sus puntos de acceso están ejecutando alguna de las versiones afectadas (verifique la sección Códigos afectados más arriba).

9800-l#show ap image
Total number of APs  : 4

Number of APs
        Initiated                  : 0
        Downloading                : 0
        Predownloading             : 0
        Completed downloading      : 0
        Completed predownloading   : 0
        Not Supported              : 0
        Failed to Predownload      : 0
        Predownload in progress    : No

AP Name             Primary Image          Backup Image            Predownload Status   Predownload Version  Next Retry Time   Retry Count   Method
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ap117.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap217.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap317.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A
Ap417.12.5.41        17.12.4.201                None                  0.0.0.0             N/A                 0           N/A

También puede realizar una verificación similar directamente en el nivel de AP ejecutando el siguiente comando para verificar ambas particiones de imagen:

AP# show version
AP Running Image     :17.12.5.41
Primary Boot Image   : 17.12.5.41
Backup Boot Image    : 17.12.5.209
Primary Boot Image Hash: 93ef1e703a5e7c5a4f97b8f59b220f52d94dd17c527868582c0048caad6397a9f3526c644f94a52bb70a104385690065ad0d652aa3fed607f24920d7e5ed5b5c
Backup Boot Image Hash: 4bbe4a0d9edc3cad938a7de399d3c2e08634643a2623bae65973ef00deb154b8eb7c7917eeecdd46e3e2ddc7be80139475e19fb3040b08aa715de196a733252b
1 Multigigabit Ethernet interfaces

Verifique la partición de inicio activa para asegurarse de que la imagen de respaldo esté en part2. Utilice el comando "show boot" y confirme que "BOOT path-list" apunte a part1; esto indica que el AP se está ejecutando actualmente desde la partición primaria e intenta actualizar a la parte secundaria, lo que podría desencadenar el problema.

AP# show boot
--- Boot Variable Table ---
BOOT path-list: part1
Console Baudrate: 9600 Enable Break:

2. Verifique el uso actual del sistema de archivos comprobando la partición /dev/ubivol/part2. Si "Use%" está cerca del 100%, la partición se agota, lo que hará que la actualización falle y potencialmente desencadene un loop de inicio.

AP# show filesystems
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                880.9M         0    880.9M   0% /dev
/sysroot                883.8M    219.6M    664.1M  25% /
tmpfs                     1.0M     56.0K    968.0K   5% /dev/shm
tmpfs                   883.8M         0    883.8M   0% /run
tmpfs                   883.8M         0    883.8M   0% /sys/fs/cgroup
/dev/ubivol/part1       372.1M     79.7M    292.4M  21% /part1
/dev/ubivol/part2       520.1M    291.3M    228.9M  56% /part2

3. Verifique la integridad de la imagen para ambas particiones para asegurarse de que no estén dañadas. Todos los campos de las imágenes principal y de copia de seguridad deben mostrar el estado "Correcto"; si algún campo muestra lo contrario, detenga el proceso y abra un caso TAC inmediatamente.

AP# show image integrity
/part1(Backup) 17.12.5.209
    part.bin : Good
    ramfs_data_cisco.squashfs : Good
    iox.tar.gz : Good
/part2(primary) 17.12.5.41
    part.bin : Good
    ramfs_data_cisco.squashfs : Good
    iox.tar.gz : Good

Comprobación previa automatizada

Para la comprobación previa automatizada, utilice la herramienta de sondeo WLAN. Esta herramienta le permite ejecutar los comandos necesarios en todos sus puntos de acceso simultáneamente para identificar los puntos de acceso afectados; puede descargarlo directamente desde el siguiente enlace: https://developer.cisco.com/docs/wireless-troubleshooting-tools/wlan-poller-wlan-poller/

Pasos:

1. Extracción - Extraiga los archivos del sondeador WLAN a su directorio preferido.

2. Configuration - Actualice el archivo "config.ini" con los siguientes parámetros, asegurándose de ingresar sus credenciales específicas y la dirección IP del controlador.

wlc_type: 2
mode: ssh
ap_mode: ssh

; set global WLC credentials
wlc_user: 
wlc_pasw: 
wlc_enable: 

; set global AP credentials
ap_user: 
ap_pasw: 
ap_enable: 

[WLC-1]
active: True
ipaddr: 
mode: ssh

3. Preparación de la Lista de Comandos - Haga un comentario (agregue el símbolo de hash "#") sobre el contenido predeterminado en "cmdlist_cos" y "cmdlist_cos_qca", luego agregue los siguientes comandos a ambos archivos.

# snippet to download the Debug image on COS APs
# show version | in Compiled
# archive download-sw /reload tftp:///
# 
show clock
show version
show flash
show flash | i cnssdaemon.log
show boot
show filesystems
show image integrity

4. Ejecución: ejecute la herramienta mediante ".\wlanpoller.exe". La herramienta conectará SSH a todos los puntos de acceso y recopilará los resultados de los comandos.

5. Recuperación de datos: una vez completada, desplácese a la carpeta /data recién creada. Siga los subdirectorios a la carpeta final que contiene los archivos de salida AP individuales.

6. Análisis - Descargue el "ap_detection_script.py" desde el enlace oficial de la caja, colóquelo en la carpeta "data", y ejecútelo.

7. Resultados de la revisión: abra el "Status_check_results.log" generado para ver la lista de AP en un estado problemático. Estos dispositivos requieren pasos de recuperación (explicados en la sección Recuperación a continuación) antes de continuar con la actualización, aquí una explicación de cómo interpretar los resultados:

Por diseño, los AP pueden arrancar desde la Partición 1 o la Partición 2. Cuando una partición está activa, la otra se utiliza para descargas de imágenes o APSP. La partición de almacenamiento lógico está asignada permanentemente a la partición 2 y no se puede cambiar. Este problema sólo afecta a los puntos de acceso que se están iniciando actualmente desde la partición 1. Puede verificarlo comprobando la columna "current_boot_partition_check" para verificar cuál es la partición actual utilizada por los AP. Ejemplo:

Del ejemplo anterior podemos concluir que de los 3 APs:

• Nombre de AP: Prueba AP1 (acción requerida): Si un AP muestra part1 "True Susceptible" en la columna "current_boot_partition_check", debe verificar la columna "part2_mem_utilization_check". Si esa columna también muestra "True Susceptible", el AP se ve afectado.

  • Ejemplo: El AP1 de prueba se ve afectado (arranque en la parte 1 y el espacio disponible en la parte 2: 51,9 MB) y requiere recuperación.

• Nombre de AP: Prueba AP2 (Partición 1): Si un AP muestra part1 "True Susceptible" pero "part2_mem_utilization_check" muestra "False Not Susceptible", el AP es seguro.

  • Ejemplo: El AP2 de prueba no se ve afectado, ya que tiene suficiente espacio en la partición 2 (parte 2); sin embargo, se recomienda instalar el APSP para ocuparse de futuros problemas, ya que el archivo cnssdaemon.log continúa existiendo en el AP.

• Nombre de AP: Prueba AP3 (Partición 2): Si un AP muestra part2 "False Not Susceptible" en la columna "current_boot_partition_check", no se verá afectado. No es necesario realizar más comprobaciones.

Nota: Nota: El valor numérico que aparece en la columna "part2_mem_utilization_check" junto al estado "True/False Susceptible" representa la cantidad de espacio disponible en la partición 2.

• Cualquier punto de acceso: Si algún AP muestra "Image Integrity Check: Error" en la columna "image_integration_check". Continúe con la apertura de un caso TAC.

Recuperación

Según el estado específico de cada AP, el script recomendará el método de recuperación más eficiente. Siga los pasos detallados a continuación para los AP afectados identificados:

Intercambio de partición de imagen AP

1. Aislar APs - asegúrese de que los APs no tienen conectividad con el WLC:
   1. Asegúrese de que SSH esté habilitado en el perfil de unión de los AP y de que los AP sean accesibles a SSH (o utilice la consola)
   2. Asegúrese de que los AP no tengan conectividad con el WLC, pero, usted todavía tiene acceso SSH a los AP. Esto se puede lograr al tener una ACL en el gateway o al mover los AP a una VLAN aislada. Si los AP consiguen el acceso al WLC, el AP podría volver a iniciar Part1 y volverá al estado afectado.

2. Configure Boot Path - En los AP afectados, establezca la trayectoria de arranque en la partición 2:

AP# config boot path 2

3. Reboot - Reinicie el AP para cargar la imagen desde la partición 2:

AP# reload

4. Upgrade - Instale en el WLC el APSP necesario en su código actual, o, si usted iba a actualizar el código, mueva a un nuevo código y asegúrese de que el APSP esté instalado también.

5. Reconnect - Una vez que la actualización del controlador se completa, quite el tope de la comunicación entre el AP y el WLC. El AP se unirá al WLC y descargará automáticamente la nueva imagen fija en el inicio Part1.

6. Doble comprobación - Después de actualizar a una versión fija, verifique ambas particiones de los AP para asegurarse de que la ranura de copia de seguridad no contenga todavía la imagen de error.

7. Mantenimiento: para mantener la estabilidad a largo plazo y evitar futuros loops de inicio, recomendamos sobrescribir la partición de respaldo con una imagen de buena calidad conocida. Para grupos más pequeños, utilice el archivo "download-sw" directamente en el AP; para implementaciones más grandes, realice una predescarga de WLC AP para actualizar la partición de respaldo sin accionar la activación de la imagen AP.

Recuperación de acceso al shell AP

El Centro de Asistencia Técnica (TAC) puede realizar la recuperación manual borrando el archivo cnssdaemon.log directamente desde el shell en los puntos de acceso afectados. Dependiendo de la escala del impacto, hay dos métodos que se mencionan a continuación:

• Número pequeño de AP afectados: Para una pequeña cantidad de AP afectados, el TAC puede continuar utilizando uno de dos enfoques:

  • Acceso manual al shell: Acceda a cada punto de acceso individualmente a través del shell para borrar manualmente el archivo de registro.

  • Acceso (masivo) automatizado al shell: Utilice la herramienta RADKit para automatizar el proceso de limpieza a todos los AP afectados.

• Gran número de AP afectados: TAC utilizará la herramienta Radkit, que permite el acceso masivo a todos los AP afectados simultáneamente para ejecutar el proceso de limpieza de manera eficiente.

Nota: Recomendamos utilizar RADKit para el procedimiento de recuperación de acceso al shell AP para garantizar la eficiencia y la consistencia.

Nota: Para descargar Radkit, utilice este enlace: Radkit Descargue y descargue la última versión. Para instalar Radkit, siga este vídeo: Instalación del Radkit

Cuándo abrir un caso de TAC

Abra un caso del TAC inmediatamente si se produce alguna de las siguientes condiciones:

• Recuperación fallida: El procedimiento AP Image AP Image Partition Swap falla o no se puede implementar en su entorno.
• Problemas de integridad: Las comprobaciones previas manuales o automatizadas devuelven una "Comprobación de integridad de la imagen: Error" para cualquier AP.
• Agotamiento del almacenamiento: Si después de actualizar/APSP instalar la partición "/dev/ubivol/part2" muestra todavía un uso críticamente alto.

Cisco TAC puede acceder al shell del AP para borrar manualmente el archivo cnssdaemon.log y realizar acciones de recuperación avanzadas para restaurar sus dispositivos.

Preguntas más Frecuentes

A: ¿Este problema se aplica sólo a las actualizaciones de código completo o también afecta a las instalaciones de APSP?

R: Este problema afecta a ambos escenarios. Si su entorno cumple los criterios para este error, el problema puede ocurrir durante una actualización completa del código o la instalación de APSP (incluyendo el APSP con la corrección del error). Complete la sección Comprobaciones previas de actualización para determinar si debe seguir los pasos de recuperación antes de aplicar cualquier actualización o APSP.

A: Mi WLC y los AP están en 17.9.x (o anterior) y necesito actualizar a 17.12.x, ¿Qué debo hacer?

R: Puede realizar una actualización directa de 17.9.x a 17.12.x. Sin embargo, si sus modelos AP son susceptibles a este bug, asegúrese de instalar el APSP recomendado inmediatamente después de la actualización.

A: Mi WLC y los AP están en 17.9.x (o anterior) y necesito actualizar a 17.15.x o superior.

R: Hay dos escenarios posibles:

• Actualización directa: Si su entorno permite una actualización directa (verifíquela mediante las notas de la versión del código de destino), continúe con la actualización y, a continuación, instale el APSP para ese código de destino.
• Actualización intermedia: Si debe seguir una ruta de actualización (por ejemplo, 17.9.x → 17.12.x → 17.15.x), le recomendamos completar toda la secuencia a 17.15.x en el mismo día. Debido a que el archivo cnssdaemon.log crece 5 MB al día, completar la actualización evita que el archivo alcance un tamaño crítico. Si no es posible realizar una actualización en el mismo día, debe instalar el APSP en la etapa 17.12.x antes de continuar finalmente con 17.15.x e instalar su APSP respectivo.

A: Ya estoy en 17.15.x. ¿Significa eso que no me afecta este error?

R: No necesariamente. Si sus AP ejecutaron previamente la versión 17.12.4, 17.12.5 o 17.12.6/6a (en 9800-L/40/80/CL), es posible que el archivo de registro problemático ya se haya generado y permanezca en almacenamiento. Se recomienda seguir la sección Comprobaciones previas de actualización para asegurarse de que se limpien todos los archivos residuales.

A: Utilizo las plataformas 9800-M, 9800-H1 o 9800-H2, que se admitieron por primera vez en la versión 17.15, ¿me afectan?

R: Hay dos escenarios posibles:

• Primera vez que se unió al WLC: Si sus AP se unieron a un 9800-M/H1/H2 como su primer controlador, usted no se ve afectado.
• WLC anteriores unidos: Si esos AP se unieron previamente a un controlador diferente que ejecuta una versión afectada (17.12.4/5/6/6a) antes de pasar al 9800-M/H1/H2, aún pueden llevar el archivo problemático. En este caso, siga la sección Comprobaciones previas de actualización.

A: Tenemos WLC separados para pruebas de laboratorio y actualizaciones escalonadas, ¿cómo debemos manejarlos?

R: Asegúrese de que todos los WLC en su entorno estén ejecutando el APSP apropiado. Debido a que el archivo cnssdaemon.log crece en 5 MB diarios, cualquier AP que se una a un WLC que ejecuta el código afectado, incluso temporalmente para probar, será potencialmente susceptible a este bug.