Actualización y degradación de los controladores Catalyst 9800 : consejos y trucos

Introducción

Este documento tiene como objetivo destacar las cosas que hay que tener en cuenta al actualizar o degradar un controlador de LAN inalámbrica (WLC) Catalyst 9800 a través de varias versiones IOS-XE. Este documento no pretende reemplazar las notas de la versión que siempre deben ser el documento de acceso al actualizar. El objetivo es facilitar la actualización a través de varias versiones destacando los cambios más impactantes entre las versiones.

Antes de continuar

Este documento no reemplaza la lectura de las notas de la versión de su versión de software de destino. Realice una copia de seguridad de su configuración y tome todas las precauciones necesarias antes de continuar con una actualización.

De forma predeterminada, el servidor http del 9800 no se asigna de forma estática a un certificado/punto de confianza específico que puede llevar a cambios después de la actualización. Establezca el servidor HTTP en un punto de confianza estático (preferiblemente en un certificado emitido a tal efecto, o en el certificado MIC de otro modo) en la configuración antes de actualizar.

El caso especial de las versiones especiales de ingeniería

Las versiones especiales de ingeniería no admiten la actualización de ISSU desde ellas. Este documento solo se centra en las versiones públicas publicadas en cisco.com, por lo tanto, si está en una versión especial de ingeniería, consulte las notas de la versión que ha recibido junto con ellas para recibir soporte para todas sus preguntas de actualización.

Actualizar

Puede leer directamente las notas en la versión de software de destino a la que desea acceder. Los consejos que se aplican a través de varias versiones se repiten cada vez para su comodidad. No actualice a través de más de 3 versiones a la vez. Por ejemplo, la actualización de 16.12.1 a 17.3.2 está cubierta por este documento, sin embargo, no se actualiza de 16.12 a 17.4. En tal escenario, por favor vaya a la versión 17.3 y verifique las notas en la sección 17.3, realice la actualización y luego observe la sección 17.4 y prepare la segunda actualización. Como conclusión, las sugerencias enumeradas ya no se repiten después de 3 versiones principales, aunque sigan siendo válidas, ya que el documento supone que se pasa por versiones importantes intermedias.

Gibraltar

16.12.2

• Desde Cisco IOS XE Gibraltar 16.12.2s, se ha eliminado la asignación automática de WLAN al perfil de política predeterminado bajo la etiqueta de política predeterminada. Si está actualizando desde una versión anterior a Cisco IOS XE Gibraltar 16.12.2s y si su red inalámbrica utiliza la etiqueta de política predeterminada, se desactivará debido al cambio de asignación predeterminado. Para restaurar la operación de red, agregue la WLAN necesaria a las asignaciones de políticas bajo la etiqueta de política predeterminada.

16.12.3

• 16.12.3 es la primera versión que aplica el soporte de solamente los SFP enumerados como soportados en la documentación. Los SFP no enumerados provocan una situación de caída del puerto. Verifique la lista de SFP soportados y asegúrese de que sus SFP sean compatibles para evitar que los puertos de datos se desactiven después de la actualización
• El archivo de actualización para esta versión puede ser demasiado grande para la carga HTTP (al realizar la actualización de la interfaz de usuario web) si se encuentra en la versión 16.12.1. Utilice otro método de transferencia o vaya a través de 16.12.2, que admite archivos de mayor tamaño que se cargarán a través de la interfaz de usuario web.
• Desde Cisco IOS XE Gibraltar 16.12.2s, se ha eliminado la asignación automática de WLAN al perfil de política predeterminado bajo la etiqueta de política predeterminada. Si está actualizando desde una versión anterior a Cisco IOS XE Gibraltar 16.12.2s y si su red inalámbrica utiliza la etiqueta de política predeterminada, se desactivará debido al cambio de asignación predeterminado. Para restaurar la operación de red, agregue la WLAN necesaria a las asignaciones de políticas bajo la etiqueta de política predeterminada.

16.12.4

• 16.12.3 y 17.2.1 son las primeras versiones que aplican el soporte de solamente los SFP enumerados como soportados en la documentación. Los SFP no enumerados provocan una situación de caída del puerto. Verifique la lista de SFP soportados y asegúrese de que sus SFP sean compatibles para evitar que los puertos de datos se desactiven después de la actualización
• El archivo de actualización para esta versión puede ser demasiado grande para la carga HTTP (al realizar la actualización de la interfaz de usuario web) si se encuentra en la versión 16.12.1. Utilice otro método de transferencia o vaya a través de 16.12.2, que admite archivos de mayor tamaño que se cargarán a través de la interfaz de usuario web.
• Desde Cisco IOS XE Gibraltar 16.12.2s, se ha eliminado la asignación automática de WLAN al perfil de política predeterminado bajo la etiqueta de política predeterminada. Si está actualizando desde una versión anterior a Cisco IOS XE Gibraltar 16.12.2s y si su red inalámbrica utiliza la etiqueta de política predeterminada, se desactivará debido al cambio de asignación predeterminado. Para restaurar la operación de red, agregue la WLAN necesaria a las asignaciones de políticas bajo la etiqueta de política predeterminada.

16.12.5

• Igual que 16.12.4

Ámsterdam

17.1.1

• El archivo de actualización para esta versión puede ser demasiado grande para la carga HTTP (al realizar la actualización de la interfaz de usuario web) si se encuentra en la versión 16.12.1. Utilice otro método de transferencia o vaya a través de 16.12.2, que admite archivos de mayor tamaño que se cargarán a través de la interfaz de usuario web.
• Desde Cisco IOS XE Gibraltar 16.12.2s, se ha eliminado la asignación automática de WLAN al perfil de política predeterminado bajo la etiqueta de política predeterminada. Si está actualizando desde una versión anterior a Cisco IOS XE Gibraltar 16.12.2s y si su red inalámbrica utiliza la etiqueta de política predeterminada, se desactivará debido al cambio de asignación predeterminado. Para restaurar la operación de red, agregue la WLAN necesaria a las asignaciones de políticas bajo la etiqueta de política predeterminada.
• A partir de esta versión, se introduce una nueva comprobación de disponibilidad del gateway. Los AP envían solicitudes de eco ICMP (ping) periódicas al gateway predeterminado para comprobar la conectividad. Debe asegurarse de que el filtrado de tráfico entre los AP y el gateway predeterminado (como las ACL) permita pings ICMP entre el AP y el gateway predeterminado. Si estos pings se bloquean, incluso si la conectividad entre el controlador y el AP está activa, los AP se recargarán en un intervalo de 4 horas.

17.2.1

• 16.12.3 y 17.2.1 son las primeras versiones que aplican el soporte de solamente los SFP enumerados como soportados en la documentación. Los SFP no enumerados provocan una situación de caída del puerto. Verifique la lista de SFP soportados y asegúrese de que sus SFP sean compatibles para evitar que los puertos de datos se desactiven después de la actualización
• El archivo de actualización para esta versión puede ser demasiado grande para la carga HTTP (al realizar la actualización de la interfaz de usuario web) si se encuentra en la versión 16.12.1. Utilice otro método de transferencia o vaya a través de 16.12.2, que admite archivos de mayor tamaño que se cargarán a través de la interfaz de usuario web.
• Desde Cisco IOS XE Gibraltar 16.12.2s, se ha eliminado la asignación automática de WLAN al perfil de política predeterminado bajo la etiqueta de política predeterminada. Si está actualizando desde una versión anterior a Cisco IOS XE Gibraltar 16.12.2s y si su red inalámbrica utiliza la etiqueta de política predeterminada, se desactivará debido al cambio de asignación predeterminado. Para restaurar la operación de red, agregue la WLAN necesaria a las asignaciones de políticas bajo la etiqueta de política predeterminada.
• A partir de 17.1, se introduce una nueva comprobación de disponibilidad del gateway. Los AP envían solicitudes de eco ICMP (ping) periódicas al gateway predeterminado para comprobar la conectividad. Debe asegurarse de que el filtrado de tráfico entre los AP y el gateway predeterminado (como las ACL) permita pings ICMP entre el AP y el gateway predeterminado. Si estos pings se bloquean, incluso si la conectividad entre el controlador y el AP está activa, los AP se recargarán en un intervalo de 4 horas.

17.3.1

• 16.12.3 y 17.2.1 son las primeras versiones que aplican el soporte de solamente los SFP enumerados como soportados en la documentación. Los SFP no enumerados provocan una situación de caída del puerto. Verifique la lista de SFP soportados y asegúrese de que sus SFP sean compatibles para evitar que los puertos de datos se desactiven después de la actualización
• El archivo de actualización para esta versión puede ser demasiado grande para la carga HTTP (al realizar la actualización de la interfaz de usuario web) si se encuentra en la versión 16.12.1. Utilice otro método de transferencia o vaya a través de 16.12.2, que admite archivos de mayor tamaño que se cargarán a través de la interfaz de usuario web.
• Desde Cisco IOS XE Gibraltar 16.12.2s, se ha eliminado la asignación automática de WLAN al perfil de política predeterminado bajo la etiqueta de política predeterminada. Si está actualizando desde una versión anterior a Cisco IOS XE Gibraltar 16.12.2s y si su red inalámbrica utiliza la etiqueta de política predeterminada, se desactivará debido al cambio de asignación predeterminado. Para restaurar la operación de red, agregue la WLAN necesaria a las asignaciones de políticas bajo la etiqueta de política predeterminada.
• A partir de 17.1, se introduce una nueva comprobación de disponibilidad del gateway. Los AP envían solicitudes de eco ICMP (ping) periódicas al gateway predeterminado para comprobar la conectividad. Debe asegurarse de que el filtrado de tráfico entre los AP y el gateway predeterminado (como las ACL) permita pings ICMP entre el AP y el gateway predeterminado. Si estos pings se bloquean, incluso si la conectividad entre el controlador y el AP está activa, los AP se recargarán en un intervalo de 4 horas.
• Si ha configurado el modo FIPS, asegúrese de quitar la configuración wpa wpa1 cipher tkip de cualquier WLAN antes de actualizar Cisco IOS XE Amsterdam 17.3.x de una versión anterior. Si no lo hace, la seguridad WLAN se establecerá en TKIP, que no se soporta en el modo FIPS. Después de la actualización, es posible que tenga que volver a configurar la WLAN con AES.
• Desde Cisco IOS XE Amsterdam 17.3.1 en adelante, el controlador inalámbrico Cisco Catalyst 9800-CL requiere 16 GB de espacio en disco para nuevas implementaciones.Sólo es posible aumentar el tamaño del espacio en disco mediante una reinstalación con una imagen 17.3.
• Desde Cisco IOS XE Amsterdam 17.3.1 en adelante, el nombre AP sólo puede tener hasta 32 caracteres.
• Para la autenticación de dirección MAC local (de clientes o AP), sólo se admite el formato aaabbbcccc (sin separador) a partir de 17.3.1. Esto significa que la autenticación fallará si agrega una dirección MAC con separadores en la interfaz de usuario web o CLI.
• A partir de esta versión en adelante, los AP se recargarán después de 4 horas si no pueden unirse a un WLC, no pueden hacer ping a su gateway Y ARP a su gateway (los 3 deben fallar para que el AP se reinicie). Esta es una mejora (CSCvt89970 ) a la verificación de gateway de ICMP anterior solamente de versiones anteriores
• A partir de 17.3.1, la nueva forma de configurar el código de país para los puntos de acceso es el comando "Wireless country <1 country code>" que puede repetir varias veces con diferentes códigos de país. Esto permite aumentar la cantidad máxima de código de país por encima de 20. Los comandos "ap country" aún están presentes y seguirán funcionando, sin embargo, considere cambiarlos a los comandos "Wireless country", ya que los comandos ap country quedarán obsoletos en una versión futura

17.3.2

• 16.12.3 y 17.2.1 son las primeras versiones que aplican el soporte de solamente los SFP enumerados como soportados en la documentación. Los SFP no enumerados provocan una situación de caída del puerto. Verifique la lista de SFP soportados y asegúrese de que sus SFP sean compatibles para evitar que los puertos de datos se desactiven después de la actualización
• El archivo de actualización para esta versión puede ser demasiado grande para la carga HTTP (al realizar la actualización de la interfaz de usuario web) si se encuentra en la versión 16.12.1. Utilice otro método de transferencia o vaya a través de 16.12.2, que admite archivos de mayor tamaño que se cargarán a través de la interfaz de usuario web.
• Desde Cisco IOS XE Gibraltar 16.12.2s, se ha eliminado la asignación automática de WLAN al perfil de política predeterminado bajo la etiqueta de política predeterminada. Si está actualizando desde una versión anterior a Cisco IOS XE Gibraltar 16.12.2s y si su red inalámbrica utiliza la etiqueta de política predeterminada, se desactivará debido al cambio de asignación predeterminado. Para restaurar la operación de red, agregue la WLAN necesaria a las asignaciones de políticas bajo la etiqueta de política predeterminada.
• A partir de 17.1, se introduce una nueva comprobación de disponibilidad del gateway. Los AP envían solicitudes de eco ICMP (ping) periódicas al gateway predeterminado para comprobar la conectividad. Debe asegurarse de que el filtrado de tráfico entre los AP y el gateway predeterminado (como las ACL) permita pings ICMP entre el AP y el gateway predeterminado. Si estos pings se bloquean, incluso si la conectividad entre el controlador y el AP está activa, los AP se recargarán en un intervalo de 4 horas.
• Si ha configurado el modo FIPS, asegúrese de quitar la configuración wpa wpa1 cipher tkip de cualquier WLAN antes de actualizar Cisco IOS XE Amsterdam 17.3.x de una versión anterior. Si no lo hace, la seguridad WLAN se establecerá en TKIP, que no se soporta en el modo FIPS. Después de la actualización, es posible que tenga que volver a configurar la WLAN con AES.
• Desde Cisco IOS XE Amsterdam 17.3.1 en adelante, el controlador inalámbrico Cisco Catalyst 9800-CL requiere 16 GB de espacio en disco para nuevas implementaciones.Sólo es posible aumentar el tamaño del espacio en disco mediante una reinstalación con una imagen 17.3.
• Desde Cisco IOS XE Amsterdam 17.3.1 en adelante, el nombre AP sólo puede tener hasta 32 caracteres.
• Para la autenticación de dirección MAC local (de clientes o AP), sólo se admite el formato aaabbbcccc (sin separador) a partir de 17.3.1. Esto significa que la autenticación fallará si agrega una dirección MAC con separadores en la interfaz de usuario web o CLI.
• A partir de 17.3.1 en adelante, los AP se recargarán después de 4 horas si no pueden unirse a un WLC, no pueden hacer ping a su gateway Y ARP a su gateway (los 3 necesitan fallar para que el AP se reinicie). Esta es una mejora (CSCvt89970 ) a la verificación de gateway de ICMP anterior solamente de versiones anteriores
• A partir de 17.3.1, la nueva forma de configurar el código de país para los puntos de acceso es el comando "Wireless country <1 country code>" que puede repetir varias veces con diferentes códigos de país. Esto permite aumentar la cantidad máxima de código de país por encima de 20. Los comandos "ap country" aún están presentes y seguirán funcionando, sin embargo, considere cambiarlos a los comandos "Wireless country", ya que los comandos ap country quedarán obsoletos en una versión futura.

Bengaluru

17.4.1

• A partir de 17.4.1, los AP basados en el IOS de Wave 1 ya no son soportados (1700,2700,3700,1570) con la excepción de IW3700.
• Las WLAN se pueden cerrar después de la actualización si no son WPA (por ejemplo, invitado, abierto o SSID de CWA) y tienen FT adaptable configurado. La solución es quitar la configuración de FT adaptable antes de la actualización (CSCvx34349 ). La configuración de FT adaptable no tiene sentido en SSID que no sea WPA, por lo que no se pierde nada al quitarla.

Reducir

Las actualizaciones no son oficialmente admitidas y puede producirse una pérdida de configuración de nuevas funciones. Sin embargo, como las rebajas pueden ocurrir en el mundo real, este documento todavía enumera las trampas más comunes que se deben evitar al degradar. Para encontrar la información que necesita, vaya a la versión desde la que está realizando la actualización (es decir, la versión anterior a la actualización)

Gibraltar

16.12.2

• Nada que señalar aquí.

16.12.3

• Nada que señalar aquí.

16.12.4

• Si se rebaja de esta versión a una más baja, el WLC puede terminar en un loop de inicio si la telemetría se configuró debido a CSCvt69990 /CSCvv87417

Ámsterdam

17.1.1

• Si se rebaja de esta versión a una más baja, el WLC puede terminar en un loop de inicio si la telemetría se configuró debido a CSCvt69990 / CSCvv8741

17.2.1

• Si se rebaja de esta versión a una más baja, el WLC puede terminar en un loop de inicio si la telemetría se configuró debido a CSCvt69990 / CSCvv87417
• Si vuelve a actualizar de Cisco IOS XE Amsterdam 17.3.1 a una versión anterior, los canales de puerto configurados con un rango superior a 4 desaparecerán

17.3.1

• Si se rebaja de esta versión a una más baja, el WLC puede terminar en un loop de inicio si la telemetría se configuró debido a CSCvt69990 / CSCvv8741
• Si vuelve a actualizar de Cisco IOS XE Amsterdam 17.3.1 a una versión anterior, los canales de puerto configurados con un rango más alto desaparecerán
• Si vuelve a actualizar de Cisco IOS XE Amsterdam 17.3.1 a una versión anterior, puede volver a enfrentarse al asistente de día 0 si tenía el comando "país inalámbrico" configurado porque no existía antes de 17.3

17.3.2

• Si se rebaja de esta versión a una más baja, el WLC puede terminar en un loop de inicio si la telemetría se configuró debido a CSCvt69990 / CSCvv87417
• Si vuelve a actualizar de Cisco IOS XE Amsterdam 17.3.1 a una versión anterior, los canales de puerto configurados con un rango más alto desaparecerán
• Si vuelve a actualizar de Cisco IOS XE Amsterdam 17.3.1 a una versión anterior, puede volver a enfrentarse al asistente de día 0 si tenía el comando "país inalámbrico" configurado porque no existía antes de 17.3

17.4.1

• Si vuelve a actualizar de Cisco IOS XE Amsterdam 17.4.1 a una versión anterior antes de 17.3, puede volver a enfrentarse al asistente de día 0 si tenía el comando "país inalámbrico" configurado porque no existía antes de 17.3
• Si vuelve a actualizar de Cisco IOS XE Amsterdam 17.4.1 a una versión anterior, perderá la conexión de telemetría, ya que 17.4 utiliza un destino de telemetría denominado que no era compatible con los comandos de las versiones anteriores. Deberá volver a crear la conexión de telemetría.

Referencias

17.1 guía de actualización de AP con parches en caliente y con desplazamiento

17.3 revisión en caliente y guía de actualización de ISSU.