Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Actualizar un clúster de chasis mediante la actualización de software en servicio

En este tema, se explica que la actualización de software en servicio (ISSU) permite una actualización de software de una versión de Junos OS a una versión posterior de Junos OS, a la vez que garantiza un tiempo de inactividad mínimo.

Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.

Revise la sección Comportamiento de actualización de software en servicio específico de la plataforma para ver notas relacionadas con su plataforma.

Consulte la sección Información adicional de la plataforma para obtener más información.

Descripción de ISSU para un clúster de chasis

La actualización de software en servicio (ISSU) permite una actualización de una versión de Junos OS a una versión posterior de Junos OS con poco o ningún tiempo de inactividad. ISSU solo se realiza cuando los dispositivos funcionan en modo de clúster de chasis.

El tiempo de inactividad observado durante un evento de tolerancia a fallos puede variar según el entorno de implementación y varios factores externos, incluyendo:

  • La velocidad a la que los dispositivos conectados procesan y responden a las actualizaciones ARP gratuitas (GARP).
  • Reaprendizaje de la dirección MAC y actualizaciones de la tabla de reenvío en conmutadores ascendentes y descendentes.
  • El comportamiento de la aplicación y los protocolos en uso (por ejemplo, las sesiones TCP pueden recuperarse de forma diferente del tráfico basado en UDP).

La función ISSU del clúster de chasis permite actualizar ambos dispositivos de un clúster desde versiones de Junos OS compatibles con una interrupción mínima del tráfico y sin interrupción de los servicios, mediante la coordinación del proceso de actualización en los nodos del clúster.

ISSU ofrece los siguientes beneficios:

  • Elimina el tiempo de inactividad de la red durante las actualizaciones de imagen de software

  • Reduce los costos operativos al tiempo que ofrece niveles de servicio más altos

  • Permite la rápida implementación de nuevas funciones

ISSU tiene las siguientes limitaciones:

  • ISSU solo está disponible para Junos OS versión 10.4R4 o posterior.

  • ISSU no admite degradaciones de software.

  • Si actualiza desde una versión de Junos OS que solo admite IPv4 a una versión que admite IPv4 e IPv6, el tráfico IPv4 seguirá funcionando con normalidad durante todo el proceso de actualización. Si actualiza desde una versión de Junos OS compatible con IPv4 e IPv6 a otra versión que también admita ambos protocolos, el tráfico IPv4 e IPv6 seguirá funcionando durante la actualización. Las plataformas compatibles con Junos OS admiten el procesamiento basado en flujos para el tráfico IPv6.

  • Durante una ISSU, no puede conectar ninguna PIC. No puede realizar operaciones como confirmar, reiniciar o detener.

  • Durante una ISSU, se suspenden operaciones como el monitoreo de estructura, la recuperación de vínculos de control y la preferencia de RGX.

  • Durante una ISSU, no puede confirmar ninguna configuración.

Para obtener más información sobre el estado de soporte de ISSU, consulte el artículo KB17946 de la base de conocimiento.

En la siguiente secuencia se describe el comportamiento de una ISSU para dispositivos que funcionan en un clúster de chasis. La secuencia se aplica cuando RG-0 está alojado en el nodo 0, que es el nodo principal. Debe iniciar la ISSU desde el nodo principal RG-0. Si intenta iniciar la ISSU desde el nodo 1 (el nodo secundario RG-0), el sistema mostrará un mensaje de error y la actualización no continuará.

  1. Conmutación por error inicial del grupo de redundancia

    Al inicio de una ISSU de clúster de chasis, el sistema conmuta automáticamente por error todos los grupos de redundancia RG-1 y superiores (RG-1+) que aún no son principales en el nodo desde el que se inicia la ISSU. Esta acción garantiza que todos los grupos de redundancia se activen en el nodo principal RG-0 antes de que comience la actualización de software.

    El sistema realiza la tolerancia a fallos automática de todos los grupos de redundancia RG-1+. Si ejecuta Junos OS versión 18.1R1 o anterior, debe comprobar manualmente (antes de iniciar la ISSU) que todos los grupos de redundancia RG-1+ estén activos en el nodo principal RG-0.

    Después de que todos los grupos de redundancia RG-1+ fallen, el sistema establece el bit de tolerancia a fallos manual, lo que impide el movimiento del grupo redundante durante la actualización. El sistema cambia la prioridad del nodo principal de todos los grupos de redundancia RG-1+ a 255, independientemente de si conmutaron por error al nodo principal RG-0 durante este paso.

  2. Durante una ISSU, el nodo principal (nodo 0) valida la configuración del dispositivo para asegurarse de que se pueda confirmar correctamente con la nueva versión de Junos OS. Como parte de este proceso de validación, el sistema realiza las siguientes comprobaciones en ambos nodos:

    • Disponibilidad de espacio en disco en el sistema de archivos /var

    • Instrucciones de configuración no compatibles

    • Tarjetas de interfaz física (PIC) no compatibles

    Si el espacio disponible en disco en el sistema de archivos de cualquiera de los /var motores de enrutamiento es insuficiente, se producirá un error en el proceso ISSU y se devolverá un mensaje de error y la actualización no continuará.

    Las PIC no compatibles no impiden que la ISSU continúe. Sin embargo, el software genera una advertencia que indica que estas PIC se reiniciarán durante la actualización.

    De manera similar, la presencia de una configuración de protocolo no compatible no bloquea la ISSU. En tales casos, el software emite una advertencia de que puede producirse pérdida de paquetes para el protocolo afectado durante el proceso de actualización.

  3. Cuando la validación se realiza correctamente, el daemon de sincronización de estado del kernel (ksyncd) sincroniza el kernel en el nodo secundario (nodo 1) con el nodo 0.

  4. El nodo 1 se actualiza con la nueva imagen de software. Antes de actualizarse, el nodo 1 obtiene el archivo de configuración del nodo 0 y valida la configuración para asegurarse de que se puede confirmar con la nueva versión de software. Después de actualizarse, se vuelve a sincronizar con el nodo 0.

  5. El proceso del clúster de chasis (chasisd) en el nodo 0 prepara otros procesos de software para la lSSU. Cuando todos los procesos están listos, chassisd envía un mensaje a las PIC instaladas en el dispositivo.

  6. El motor de reenvío de paquetes de cada concentrador de PIC flexible (FPC) guarda su estado y descarga la imagen de software nueva del nodo 1. A continuación, cada motor de reenvío de paquetes envía un mensaje (listo para ISSU unificado) al chasis.

  7. Después de recibir el mensaje (listo para ISSU unificado) de un motor de reenvío de paquetes, el chasis envía un mensaje de reinicio a la FPC en la que reside el motor de reenvío de paquetes. El FPC se reinicia con la nueva imagen de software. Después de reiniciar la FPC, el motor de reenvío de paquetes restaura el estado de la FPC y se establece un vínculo interno de alta velocidad con el nodo 1 que ejecuta el software nuevo. El chasis también se restablece con el nodo 0.

  8. Después de que todos los motores de reenvío de paquetes hayan enviado un mensaje listo mediante el chasis en el nodo 0, se preparan otros procesos de software para un cambio de nodo. El sistema está listo para un cambio en este momento.

  9. Se produce un cambio de nodo y el nodo 1 se convierte en el nuevo nodo principal (hasta ahora nodo secundario 1).

  10. El nuevo nodo secundario (hasta ahora nodo principal 0) ahora se actualiza a la nueva imagen de software.

Cuando ambos nodos se actualizan correctamente, la ISSU está completa.

Cuando actualice un clúster de chasis desde una versión de Junos OS que no admita cifrado a una versión que admita cifrado, realice la actualización de un nodo a la vez:

  1. Actualice el primer nodo a la nueva versión de Junos OS.

    Si el cifrado no está configurado y habilitado, la comunicación del clúster entre los dos nodos permanece intacta aunque ejecuten diferentes versiones de software y los servicios continúan sin interrupción.

  2. Actualice el segundo nodo a la misma versión nueva de Junos OS.

Una vez que ambos nodos se hayan actualizado correctamente, puede optar por configurar y habilitar el cifrado según sea necesario.

En el caso de degradaciones a una versión de Junos OS que no admita el cifrado, asegúrese de que el cifrado esté desactivado antes de iniciar la degradación. Deshabilitar el cifrado antes de la degradación evita fallas de comunicación entre:

  • un nodo que aún ejecuta una versión de Junos OS habilitada para cifrado, y
  • Un nodo que se ha degradado a una versión sin soporte de cifrado.

Al garantizar que el cifrado esté deshabilitado en ambos nodos, la comunicación del clúster permanece sin cifrar y operativa durante todo el proceso de degradación.

Las políticas del motor de enrutamiento y del motor de reenvío de paquetes deben estar sincronizadas para que se confirme la configuración. Cuando se modifican las configuraciones de las políticas y las políticas no están sincronizadas, el sistema muestra un mensaje de error.

Como solución alternativa, debe utilizar el comando request security policies resync para sincronizar la configuración de las políticas de seguridad en el motor de enrutamiento y el motor de reenvío de paquetes, por si acaso observa que las políticas de seguridad no están sincronizadas después de una actualización.

Requisitos del sistema ISSU

Puede usar ISSU para actualizar desde una versión de software compatible con ISSU a una versión posterior.

Para realizar una ISSU, el dispositivo debe ejecutar una versión de Junos OS que admita ISSU para la plataforma específica.

Consulte la sección Descripción de ISSU para un clúster de chasis para obtener más información.

Para obtener más información sobre la compatibilidad con ISSU y sus limitaciones, consulte Limitaciones de actualización de ISSU/ICU en dispositivos de la serie SRX.

A continuación se muestran las limitaciones al realizar una ISSU:

  • El proceso ISSU finaliza si la versión de Junos OS especificada para la instalación es anterior a la versión que se ejecuta actualmente en el dispositivo.

  • ISSU finaliza si la actualización especificada entra en conflicto con:

    • La configuración actual del dispositivo

    • Componentes de hardware compatibles

    • Otras dependencias de plataforma o software

  • ISSU no admite paquetes de aplicaciones de extensión desarrollados con el SDK de Junos OS.

  • ISSU no admite la degradación de versiones en todos los firewalls.

  • ISSU puede fallar bajo una carga de CPU pesada y se recomienda garantizar los recursos del sistema adecuados antes de iniciar la actualización.

Para cambiar de una versión de Junos OS compatible con ISSU a una versión anterior (sea compatible con ISSU o no), use el request system software add comando.

A diferencia de una actualización de ISSU, una degradación puede causar interrupciones en la red.

También existe el riesgo de pérdida de datos durante el proceso de degradación.

Planifique las degradaciones cuidadosamente y asegúrese de que se realicen las copias de seguridad adecuadas antes de continuar.

Recomendamos encarecidamente que realice ISSU en las siguientes condiciones:

  • Cuando los nodos primario y secundario están sanos

  • Durante el período de mantenimiento del sistema

  • Durante el período de tráfico más bajo posible

  • Cuando el uso de CPU del motor de enrutamiento es inferior al 40 por ciento

En escenarios en los que ISSU no es compatible o no se recomienda, pero aún debe minimizarse el tiempo de inactividad de la actualización del sistema, se puede usar el procedimiento de actualización con un tiempo de inactividad mínimo, consulte el artículo de la base de conocimientos pertinente KB17947.

Actualizar ambos dispositivos en un clúster de chasis mediante ISSU

Antes de comenzar con la ISSU para actualizar ambos dispositivos, tenga en cuenta las siguientes directrices:

  • Asegúrese de que se cumplan los siguientes requisitos de comprobación previa de ISSU:

    • La prioridad de todos los grupos de redundancia es mayor que 0

    • Todos los grupos de redundancia son primarios o secundarios en el estado

    • Existe suficiente espacio disponible (el doble del tamaño de la imagen) en / var/tmp

    • El uso de la CPU es inferior al 80 % en un período de 5 segundos

    Si no se cumplen los requisitos de verificación previa, ISSU terminará al principio.

  • Haga una copia de seguridad del software mediante el request system snapshot comando de cada motor de enrutamiento para realizar una copia de seguridad del software del sistema en el disco duro del dispositivo.

  • Si utiliza Junos OS versión 18.1R1 o anterior, antes de iniciar la ISSU, establezca la tolerancia a fallos para todos los grupos de redundancia, de forma que todos estén activos en un solo nodo (principal). Consulte Inicio de una conmutación por error del grupo de redundancia manual de un clúster de chasis.

    Si ejecuta Junos OS versión 18.1 o posterior, el sistema conmuta automáticamente por error todos los RG al RG0 principal.

  • Recomendamos habilitar el reinicio correcto para todos los protocolos de enrutamiento antes de iniciar una ISSU para garantizar una interrupción mínima del tráfico.

En todos los firewalls compatibles, la primera ISSU recomendada desde la versión es Junos OS versión 18.1R1.

La función ISSU del clúster de chasis permite actualizar ambos dispositivos de un clúster desde versiones de Junos OS compatibles con un impacto en el tráfico comparable al de las conmutaciones por error de grupo de redundancia.

Para realizar una ISSU desde la CLI en motor de enrutamiento2:

  1. Descargue el paquete de software desde el sitio web de soporte de Juniper Networks: https://www.juniper.net/support/downloads/
  2. Copie el paquete en el nodo principal del clúster. Le recomendamos que copie el paquete al directorio /var/tmp , que es un sistema de archivos grande en el disco duro. Tenga en cuenta que el nodo desde el que inicia la ISSU debe tener la imagen de software.

    user@host>file copy ftp://username:prompt@ftp.hostname.net/filename /var/tmp/filename

  3. Verifique la versión actual del software que se ejecuta en ambos nodos ejecutando el show version comando en el nodo principal.
  4. Inicie la ISSU desde el nodo principal para todos los grupos de redundancia introduciendo el comando siguiente:

    Espere a que ambos nodos completen la actualización (después de lo cual se cierra la sesión del dispositivo).

  5. Espere unos minutos y vuelva a iniciar sesión en el dispositivo. Verifique mediante el show version comando que ambos dispositivos del clúster están ejecutando la nueva versión de Junos OS.
  6. Compruebe que todas las políticas, zonas, grupos de redundancia y otros objetos en tiempo real (RTO) vuelven a sus estados correctos.
  7. Vuelva a convertir el nodo 0 en el nodo principal ejecutando el request chassis cluster failover node node-number redundancy-group group-number comando.

Si desea que los grupos de redundancia se reviertan automáticamente al nodo 0 como principal después de una actualización de software en servicio (ISSU), debe configurar las prioridades del grupo de redundancia para que el nodo 0 tenga la prioridad más alta y habilitar la preempt opción.

Este enfoque se aplica a todos los grupos de redundancia, excepto al grupo de redundancia 0 (RG0). Para RG0, la tolerancia a fallos se debe realizar manualmente.

Para establecer la prioridad del grupo de redundancia y activar la preempt opción, consulte Ejemplo: Configuración de grupos de redundancia de clúster de chasis.

Para establecer manualmente la tolerancia a fallos para un grupo de redundancia, consulte Inicio de una conmutación por error manual del grupo de redundancia de un clúster de chasis.

Durante la actualización, ambos dispositivos pueden experimentar conmutaciones por error de grupo de redundancia; Sin embargo, el tráfico no se interrumpe. Antes de iniciar la actualización, cada dispositivo valida el paquete de actualización y verifica la compatibilidad de la versión. Si el sistema detecta que la nueva versión del paquete no es compatible con la versión instalada actualmente, se rechaza la actualización o se le solicita que tome medidas correctivas. En algunos casos, una característica específica puede ser incompatible, en tales situaciones, el software de actualización le solicita que finalice la actualización o deshabilite la característica incompatible antes de continuar.

Si tiene previsto utilizar el firewall como un dispositivo independiente o eliminar un nodo de un clúster de chasis, asegúrese de que el procedimiento de ISSU se haya terminado por completo en ambos nodos (si se inició una ISSU).

Para iniciar el proceso de ISSU en dispositivos SRX5K con motor de enrutamiento3 y en dispositivos SRX1600, SRX2300, SRX4120 y SRX4300:

  1. Ejecute el comando siguiente para iniciar ISSU:

Ver también

revertir dispositivos en un clúster de chasis después de una ISSU

Si no se completa una ISSU y solo se actualiza un dispositivo del clúster, puede revertir a la configuración anterior solo en el dispositivo actualizado mediante la emisión de uno de los siguientes comandos en el dispositivo actualizado:

  • request chassis cluster in-service-upgrade abort

  • request system software rollback node node-id reboot

  • request system reboot

Habilitar una conmutación por recuperación automática del nodo del clúster de chasis después de una ISSU

Si desea que los grupos de redundancia vuelvan automáticamente al nodo 0 como principal después de una actualización de software en servicio (ISSU), debe configurar la prioridad del grupo de redundancia para que el nodo 0 tenga la prioridad más alta y habilitar la preempt opción.

Este mecanismo se aplica a todos los grupos de redundancia excepto al grupo de redundancia 0. El grupo de redundancia 0 no admite la preferencia automática y se debe conmutar por error manualmente.

Para establecer prioridades de grupo de redundancia y activar preempt la opción, consulte Ejemplo: Configuración de grupos de redundancia de clúster de chasis. Para iniciar manualmente la tolerancia a fallos del grupo de aredundancia, consulte Iniciar una conmutación por error del grupo de redundancia manual de un clúster de chasis.

Para completar la actualización y hacer que el nodo 0 esté disponible en el clúster de chasis después de ISSU, debe reiniciar manualmente el nodo 0. El nodo 0 no se reinicia automáticamente como parte del proceso ISSU.

Registrar mensajes de error usados para solucionar problemas relacionados con ISSU

Los siguientes problemas pueden producirse durante una actualización de ISSU. Puede identificar los errores mediante los detalles de los registros. Para obtener información detallada acerca de mensajes de registro del sistema específicos, consulte Explorador de registros del sistema.

Errores de proceso del chasis

Problema

Descripción

Errores relacionados con el chasis.

Solución

Utilice los mensajes de error para comprender los problemas relacionados con el chasis.

Cuando se inicia ISSU, se envía una solicitud a chassisd para comprobar si hay algún problema relacionado con ISSU desde la perspectiva del chasis. Si hay un problema, se crea un mensaje de registro.

Gestión de errores comunes para ISSU

Problema

Descripción

Es posible que encuentre algunos problemas en el curso de una ISSU. Esta sección proporciona detalles sobre cómo manejarlos.

Solución

Cualquier error encontrado durante una ISSU genera mensajes de registro y el proceso de ISSU continúa sin afectar al tráfico. Si se requiere una reversión a una versión anterior de Junos OS, se registra el evento o se detiene el proceso de ISSU para evitar que las versiones no coincidan entre los nodos del clúster de chasis. En la Tabla 1 se proporcionan algunas de las condiciones de error comunes y sus correspondientes soluciones alternativas. Los mensajes de registro de ejemplo que se muestran en la tabla 1 se toman del dispositivo SRX1500, pero también son aplicables a todos los firewalls compatibles.

Tabla 1: Errores y soluciones relacionados con la ISSU

Condiciones de error

Soluciones

Intento de iniciar una ISSU cuando la instancia anterior de una ISSU ya está en curso

Se muestra el siguiente mensaje:

warning: ISSU in progress

Puede anular el proceso ISSU actual e iniciar el ISSU de nuevo mediante el request chassis cluster in-service-upgrade abort comando.

Error de reinicio en el nodo secundario

No se produce ningún tiempo de inactividad del servicio, ya que el nodo principal sigue proporcionando los servicios necesarios. Se muestran mensajes detallados en la consola en los que se le solicita que borre manualmente los estados ISSU existentes y restaure el clúster de chasis.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

El nodo secundario no pudo completar la sincronización en frío

Se agota el tiempo de espera del nodo principal si el nodo secundario no logra completar la sincronización en frío. Se muestran mensajes detallados en la consola que indican que borró manualmente los estados ISSU existentes y restauró el clúster de chasis. En este caso, no se produce ningún tiempo de inactividad del servicio.

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node

Error en la conmutación por error de un secundario recién actualizado

No se produce ningún tiempo de inactividad del servicio, ya que el nodo principal sigue proporcionando los servicios necesarios. Se muestran mensajes detallados en la consola en los que se le solicita que borre manualmente los estados ISSU existentes y restaure el clúster de chasis.

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Error de actualización en la principal

No se produce ningún tiempo de inactividad del servicio, ya que el nodo secundario conmuta por error como principal y continúa proporcionando los servicios necesarios.

Error de reinicio en el nodo principal

Antes del reinicio del nodo principal, si los dispositivos están fuera de la configuración de ISSU, no se muestra ningún mensaje de error relacionado con ISSU. Se muestra el siguiente mensaje de error de reinicio si se detecta cualquier otro error:

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

Errores relacionados con la compatibilidad con ISSU

Problema

Descripción

El error de instalación se produce debido a que el software no es compatible y la configuración de las funciones.

Solución

Use los siguientes mensajes de error para comprender los problemas relacionados con la compatibilidad:

Error en las comprobaciones de validación inicial

Problema

Descripción

Las comprobaciones de validación iniciales fallan.

Solución

Las comprobaciones de validación fallan si la imagen no está presente o si el archivo de imagen está dañado. Se muestran los siguientes mensajes de error cuando se produce un error en las comprobaciones de validación iniciales cuando la imagen no está presente y se anula la ISSU:

Cuando la imagen no está presente

Cuando el archivo de imagen está dañado

Si el archivo de imagen está dañado, se muestra el siguiente resultado:

El nodo principal valida la configuración del dispositivo para asegurarse de que se pueda confirmar con la nueva versión de software. Si algo sale mal, se anulan las ISSU y se muestran los mensajes de error.

Errores relacionados con la instalación

Problema

Descripción

El archivo de imagen de instalación no existe o no se puede acceder al sitio remoto.

Solución

Utilice los siguientes mensajes de error para comprender los problemas relacionados con la instalación:

ISSU descarga la imagen de instalación como se especifica en el comando ISSU como argumento. El archivo de imagen puede ser un archivo local o estar ubicado en un sitio remoto. Si el archivo no existe o no se puede acceder al sitio remoto, se informa de un error.

Errores de conmutación por error del grupo de redundancia

Problema

Descripción

Problema con un error del grupo de redundancia automática (RG).

Solución

Use los siguientes mensajes de error para comprender el problema:

Errores de sincronización del estado del kernel

Problema

Descripción

Errores relacionados con ksyncd.

Solución

Utilice los siguientes mensajes de error para comprender los problemas relacionados con ksyncd:

ISSU comprueba si hay algún error de ksyncd en el nodo secundario (nodo 1) y muestra el mensaje de error si hay algún problema y anula la actualización.

Comportamiento de actualización de software en servicio específico de la plataforma

Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.

Utilice la siguiente tabla para revisar los comportamientos específicos de la plataforma para su plataforma.

Plataforma

Diferencia

serie SRX

  • Compatibilidad con firewalls SRX1500, SRX4100 y SRX4200 para actualizar desde Junos OS 17.4 a versiones 17.4 sucesivas y no se puede actualizar a versiones 17.4 desde versiones anteriores de Junos OS.

  • Soporte para firewalls SRX5400, SRX5600 y SRX5800 para actualizar desde Junos OS 17.3 a versiones 17.3 sucesivas y no se puede actualizar a versiones 17.3 y superiores desde versiones anteriores de Junos OS.

  • SRX1500, SRX1600, SRX2300, SRX4120, SRX4100, SRX4200, SRX4300 y SRX4600, los firewalls no admiten el request system snapshot comando.

  • Los firewalls SRX1500, SRX4100 y SRX4200 compatibles con ISSU permiten eliminar el archivo de imagen original. Incluir unlink al user@host> request system software in-service-upgrade image-name-with-full-path unlink comando.

Información adicional de la plataforma

Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.

Es posible que se admitan plataformas adicionales.

Tabla 2: Soporte de plataforma ISSU

Dispositivo

Versión de Junos OS

SRX5800 y SRX5600

10.4R4 o posterior

SRX5400

12.1X46-D20 o posterior

SRX1500

15.1X49-D70 o posterior

SRX1600 y SRX2300, SRX4120

23.4R1 o posterior

SRX4100 y SRX4200

15.1X49-D80 o posterior

SRX4300

24.2R1 o posterior

SRX4600

17.4R1 o posterior

Documentación relacionada