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

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 con un tiempo de inactividad mínimo. Para obtener más información, consulte los temas siguientes:

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

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 con poco o ningún tiempo de inactividad. ISSU se realiza cuando los dispositivos solo funcionan en el modo de clúster de chasis.

La función ISSU del clúster de chasis permite que ambos dispositivos de un clúster se actualicen desde las versiones compatibles de Junos OS con una interrupción mínima del tráfico y sin interrupción del servicio.

A partir de Junos OS versión 15.1X49-D80, los dispositivos SRX4100 y SRX4200 admiten ISSU.

A partir de Junos OS versión 15.1X49-D70, los dispositivos SRX1500 admiten ISSU.

  • En dispositivos SRX1500, SRX4100 y SRX4200, ISSU no se admite para actualizar a 17.4 versiones de versiones anteriores de Junos OS. ISSU es compatible con la actualización de Junos OS 17.4 a versiones sucesivas 17.4.

  • En dispositivos SRX5400, SRX5600 y SRX5800, ISSU no se admite para actualizar a versiones 17.3 y posteriores de versiones anteriores de Junos OS. ISSU es compatible con la actualización de Junos OS 17.3 a junos 17.4 versiones.

  • Los dispositivos serie SRX300, los dispositivos SRX550M y vSRX no son compatibles con ISSU.

Puede usar los comandos de actualización de clústeres en banda (ICU) en dispositivos SRX4100 y SRX4200 para actualizar las siguientes versiones de Junos OS:

  • Junos OS versión 15.1X49-D65 a Junos OS versión 15.1X49-D70

  • Junos OS versión 15.1X49-D70 a Junos OS versión 15.1X49-D80.

Debe usar los comandos de actualización de clúster en banda (ICU) en el dispositivo SRX1500 para actualizar las siguientes versiones de Junos OS:

  • Junos OS versión 15.1X49-D50 a Junos OS versión 15.1X49-D60

  • Junos OS versión 15.1X49-D60 a Junos OS versión 15.1X49-D70

  • Junos OS versión 15.1X49-D50 a Junos OS versión 15.1X49-D70

ISSU ofrece los siguientes beneficios:

  • Elimina el tiempo de inactividad de la red durante las actualizaciones de imágenes de software

  • Reduce los costos operativos, a la vez que ofrece niveles de servicio más altos

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

ISSU tiene las siguientes limitaciones:

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

  • ISSU no admite versiones anteriores de software.

  • Si actualiza desde una versión de Junos OS que solo admita IPv4 a una versión que admita IPv4 e IPv6, el tráfico IPv4 seguirá funcionando durante el proceso de actualización. Si actualiza desde una versión de Junos OS compatible con IPv4 e IPv6 a una versión compatible con IPv4 e IPv6, el tráfico IPv4 e IPv6 seguirá funcionando durante el proceso de actualización. La versión 10.2 y las versiones posteriores de Junos OS admiten el procesamiento basado en flujos para el tráfico IPv6.

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

  • Durante un ISSU, se suspenden las operaciones como la supervisión de la estructura, la recuperación de vínculos de control y la preferencia de RGX.

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

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

El siguiente proceso se produce durante un ISSU para dispositivos en un clúster de chasis. Las secuencias que se indican a continuación son aplicables cuando RG-0 es el nodo 0 (nodo principal). Tenga en cuenta que debe iniciar un ISSU desde RG-0 principal. Si inicia la actualización en el nodo 1 (RG-0 secundario), aparecerá un mensaje de error.

  1. Al principio de un ISSU del clúster de chasis, el sistema falla automáticamente en todos los grupos de redundancia RG-1+ que no son primarios en el nodo desde el que se inicia el ISSU. Esta acción garantiza que todos los grupos de redundancia estén activos solo en el nodo principal RG-0.

    La conmutación por error automática de todos los grupos de redundancia RG-1+ está disponible en la versión 12.1 o posterior de Junos OS. Si usa la versión 11.4 o anterior de Junos OS, antes de iniciar EL ISSU, asegúrese de que todos los grupos de redundancia estén activos solo en el nodo principal RG-0.

    Después de que el sistema falla en todos los grupos de redundancia RG-1+, establece el bit de conmutación por error manual y cambia todas las prioridades del nodo principal RG-1+ a 255, independientemente de si el grupo de redundancia falló en el nodo principal RG-0.

  2. El nodo principal (nodo 0) valida la configuración del dispositivo para garantizar que se pueda confirmar con la nueva versión de software. Se realizan comprobaciones de la disponibilidad de espacio en disco para el sistema de archivos /var en ambos nodos, configuraciones no compatibles y tarjetas de interfaz física (PIC) no compatibles.

    Si el espacio en disco disponible en cualquiera de los motores de enrutamiento es insuficiente, el proceso ISSU falla y devuelve un mensaje de error. Sin embargo, las PIC no compatibles no impiden el ISSU. El software emite una advertencia para indicar que estas PIC se reiniciarán durante la actualización. De manera similar, una configuración de protocolo no compatible no impide el ISSU. Sin embargo, el software emite una advertencia de que puede producirse una pérdida de paquetes para el protocolo durante la actualización.

  3. Cuando la validación tiene éxito, el demonio 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 ser actualizado, el nodo 1 obtiene el archivo de configuración del nodo 0 y valida la configuración para garantizar que se pueda confirmar con la nueva versión de software. Después de la actualización, se vuelve a sincronizar con el nodo 0.

  5. El proceso de clúster de chasis (chassisd) en el nodo 0 prepara otros procesos de software para la lISSU. 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 nueva imagen de software del nodo 1. A continuación, cada motor de reenvío de paquetes envía un mensaje (unified-ISSU ready) al chasis.

  7. Después de recibir el mensaje (unified-ISSU ready) de un motor de reenvío de paquetes, el chasis envía un mensaje de reinicio a la FPC en el que reside el motor de reenvío de paquetes. La 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 nuevo software. 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 de listo usando el chasis en el nodo 0, otros procesos de software se preparan para un cambio de nodo. El sistema está listo para un cambio en este punto.

  9. Se produce la conmutación de nodos 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) se ha actualizado a la nueva imagen de software.

Cuando ambos nodos se actualizan correctamente, el ISSU se completa.

Cuando actualice un clúster de versión que no admite el cifrado a una versión que admita el cifrado, actualice el primer nodo a la nueva versión. Sin el cifrado configurado y habilitado, dos nodos con diferentes versiones aún pueden comunicarse entre sí y el servicio no está roto. Después de actualizar el primer nodo, actualice el segundo nodo a la nueva versión. Los usuarios pueden decidir si activar la función de cifrado después de completar la actualización. El cifrado debe desactivarse antes de degradar a una versión que no admita el cifrado. Esto garantiza que no se rompa la comunicación entre un nodo de versión de cifrado habilitado y un nodo degradado, ya que ambos ya no están cifrados.

Requisitos del sistema ISSU

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

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

Tabla 1: Soporte de plataforma ISSU

Dispositivo

Versión de Junos OS

SRX5800

10.4R4 o posterior

SRX5600

10.4R4 o posterior

SRX5400

12.1X46-D20 o posterior

SRX1500

15.1X49-D70 o posterior

SRX4100

15.1X49-D80 o posterior

SRX4200

15.1X49-D80 o posterior

SRX4600

17.4R1 o posterior

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

Tenga en cuenta las siguientes limitaciones relacionadas con un ISSU:

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

  • El proceso ISSU termina si la actualización especificada entra en conflicto con la configuración actual, los componentes compatibles, etc.

  • ISSU no admite los paquetes de aplicaciones de extensión desarrollados con junos OS SDK.

  • ISSU no admite la degradación de versión en todos los dispositivos de la serie SRX compatibles.

  • ISSU ocasionalmente falla bajo una fuerte carga de CPU.

Para degradar de una versión compatible con ISSU a una versión anterior (compatible con ISSU o no), utilice el request system software add comando. A diferencia de una actualización mediante el proceso ISSU, una degradación mediante el comando puede causar interrupciones de la request system software add red y pérdida de datos.

Recomendamos encarecidamente que realice ISSU bajo las siguientes condiciones:

  • Cuando los nodos principal y secundario están en buen estado

  • Durante el período de mantenimiento del sistema

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

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

En los casos en que ISSU no sea compatible o recomendado, aunque se debe minimizar el tiempo de inactividad durante la actualización del sistema, se puede utilizar el procedimiento de inactividad mínimo. Consulte el artículo de la base de conocimientosKB17947.

Actualización de ambos dispositivos en un clúster de chasis mediante ISSU

Antes de comenzar el ISSU para actualizar ambos dispositivos, tenga en cuenta las siguientes instrucciones:

  • Asegúrese de que se cumplen los siguientes requisitos de verificación previa ISSU:

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

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

    • Hay 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 finalizará al principio.

  • Respalde el software mediante el request system snapshot comando de cada motor de enrutamiento para hacer una copia de seguridad del software del sistema en el disco duro del dispositivo. El request system snapshot comando no se admite en las plataformas SRX1500, SRX4100, SRX4200 y SRX4600.

  • Si usa la versión 11.4 o anterior de Junos OS, antes de iniciar el ISSU, establezca la conmutación por error para todos los grupos de redundancia de modo que todos estén activos en un solo nodo (principal). Consulte Conmutación por error del grupo de redundancia manual de inicio de un clúster de chasis.

    Si está usando Junos OS versión 12.1 o posterior, Junos OS falla automáticamente en todas las RG al RG0 principal.

  • Recomendamos que habilite el reinicio con gracia para los protocolos de enrutamiento antes de iniciar un ISSU.

En todos los dispositivos de la serie SRX compatibles, el primer ISSU recomendado de la versión es Junos OS versión 10.4R4.

La función ISSU del clúster de chasis permite que ambos dispositivos de un clúster se actualicen desde las versiones compatibles de Junos OS con un impacto de tráfico similar al de las conmutaciónes por error del grupo de redundancia.

A partir de Junos OS versión 15.1X49-D70, los dispositivos SRX1500 admiten ISSU.

A partir de Junos OS versión 15.1X49-D80, los dispositivos SRX4100 y SRX4200 admiten ISSU.

A partir de Junos OS versión 17.4R1, los dispositivos SRX4600 son compatibles con ISSU.

Para realizar un ISSU desde la CLI en el motor de enrutamiento2:

  1. Descargue el paquete de software del sitio web de soporte de Juniper Networks: https://www.juniper.net/support/downloads/
  2. Copie el paquete en el nodo principal del clúster. Recomendamos que copie el paquete en el directorio/var/tmp , que es un sistema de archivos de gran tamaño en el disco duro. Tenga en cuenta que el nodo desde el que inicia el 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 de software actual que se ejecuta en ambos nodos mediante la emisión del show version comando en el nodo principal.
  4. Inicie EL ISSU desde el nodo principal para todos los grupos de redundancia mediante el siguiente comando:

    Para los dispositivos SRX1500, SRX4100 y SRX4200, opcionalmente puede eliminar el archivo de imagen original incluyéndolo unlink en el comando.

    Espere a que ambos nodos completen la actualización (Después de lo cual ha cerrado la sesión del dispositivo).

  5. Espere unos minutos e inicie sesión de nuevo en el dispositivo. Mediante el show version comando, compruebe que ambos dispositivos del clúster ejecutan la nueva versión de Junos OS.
  6. Verifique que todas las políticas, zonas, grupos de redundancia y otros objetos en tiempo real (RTO) vuelvan a sus estados correctos.
  7. Haga que el nodo 0 sea el nodo principal nuevamente mediante la emisión del request chassis cluster failover node node-number redundancy-group group-number comando.

Si desea que los grupos de redundancia vuelvan automáticamente al nodo 0 como el principal después de una actualización de software en servicio (ISSU), debe establecer la prioridad del grupo de redundancia de modo que el nodo 0 sea principal y habilitar la preempt opción. Tenga en cuenta que este método funciona para todos los grupos de redundancia, excepto para el grupo de redundancia 0. Debe establecer manualmente la conmutación por error para el grupo de redundancia 0.

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

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

Durante la actualización, es posible que ambos dispositivos experimenten conmutación por error de grupo de redundancia, pero el tráfico no se interrumpe. Cada dispositivo valida el paquete y comprueba la compatibilidad de la versión antes de comenzar la actualización. Si el sistema descubre que la nueva versión del paquete no es compatible con la versión instalada actualmente, el dispositivo rechaza la actualización o le solicita que tome medidas correctivas. A veces, una sola función no es compatible, en cuyo caso, el software de actualización le solicita que finalice la actualización o que desactive la función antes de comenzar la actualización.

Si desea volver a operar el dispositivo serie SRX como un dispositivo independiente o quitar un nodo de un clúster de chasis, asegúrese de que ha terminado el procedimiento ISSU en ambos nodos (en caso de que se inicie el procedimiento ISSU)

Para iniciar el proceso ISSU en enrutamiento Engine3 para dispositivos SRX 5K:

  1. Ejecute el siguiente comando para iniciar ISSU:

Ver también

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

Si un ISSU no se completa y solo se actualiza un dispositivo del clúster, puede volver 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

Habilitación por error de un nodo automático del clúster de chasis después de un ISSU

Si desea que los grupos de redundancia vuelvan automáticamente al nodo 0 como el principal después de una actualización de software en servicio (ISSU), debe establecer la prioridad del grupo de redundancia de modo que el nodo 0 sea principal y habilitar la preempt opción. Tenga en cuenta que este método funciona para todos los grupos de redundancia, excepto para el grupo de redundancia 0. Debe establecer manualmente la conmutación por error para un grupo de redundancia 0. Para establecer la prioridad del grupo de redundancia y habilitar la preempt opción, consulte Ejemplo: Configuración de grupos de redundancia de clúster de chasis. Para establecer manualmente la conmutación por error para un grupo de redundancia, consulte Iniciar una conmutación por error del grupo de redundancia manual de un clúster de chasis.

Para actualizar el nodo 0 y hacerlo disponible en el clúster de chasis, reinicie manualmente el nodo 0. El nodo 0 no se reinicia automáticamente.

Mensajes de error de registro utilizados para solucionar problemas relacionados con ISSU

Es posible que se produzcan los siguientes problemas durante una actualización 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 de chasis

Problema

Descripción

Errores relacionados con 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 una perspectiva de chasis. Si hay un problema, se crea un mensaje de registro.

Descripción del manejo común de errores para ISSU

Problema

Descripción

Es posible que encuentre algunos problemas en el curso de un ISSU. En esta sección, se proporcionan detalles sobre cómo manejarlos.

Solución

Los errores encontrados durante un ISSU dan como resultado la creación de mensajes de registro, y ISSU sigue funcionando sin afectar el tráfico. Si es necesario revertir a versiones anteriores, el evento se registra o se detiene EL ISSU, para no crear versiones no coincidentes en ambos nodos del clúster de chasis. En la tabla 2 , se proporcionan algunas de las condiciones de error comunes y las soluciones para ellas. Los mensajes de ejemplo utilizados en la tabla 2 proceden del dispositivo SRX1500 y también se aplican a todos los dispositivos de la serie SRX compatibles.

Tabla 2: Errores y soluciones relacionados con ISSU

Condiciones de error

Soluciones

Intentar iniciar un ISSU cuando la instancia anterior de un ISSU ya está en curso

Se muestra el siguiente mensaje:

warning: ISSU in progress

Puede abortar 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 ofreciendo los servicios necesarios. Se muestran mensajes detallados de la consola en los que se solicita que despeje los estados ISSU existentes manualmente 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

A partir de Junos OS versión 17.4R1, el temporizador de espera para el reinicio inicial del nodo secundario durante el proceso ISSU se extiende de 15 minutos (900 segundos) a 45 minutos (2700 segundos) en clústeres de chasis en dispositivos SRX1500, SRX4100, SRX4200 y SRX4600.

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

El tiempo de espera del nodo principal si el nodo secundario no completa la sincronización en frío. Se muestran mensajes detallados de la consola en los que borra los estados ISSU existentes manualmente y restaura 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 del secundario recién actualizado

No se produce ningún tiempo de inactividad del servicio, ya que el nodo principal sigue ofreciendo los servicios necesarios. Se muestran mensajes detallados de la consola en los que se solicita que despeje los estados ISSU existentes manualmente 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 el sistema principal

No se produce ningún tiempo de inactividad del servicio, ya que el nodo secundario falla como principal y sigue ofreciendo los servicios necesarios.

Error de reinicio en el nodo principal

Antes del reinicio del nodo principal, los dispositivos que están fuera de la configuración ISSU, no se muestran mensajes de error relacionados con ISSU. El siguiente mensaje de error de reinicio se muestra si se detecta cualquier otra falla:

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 el soporte ISSU

Problema

Descripción

El error de instalación se produce debido a software no compatible y a la configuración de funciones no compatibles.

Solución

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

Error de 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. Los siguientes mensajes de error se muestran cuando las comprobaciones iniciales de validación fallan cuando la imagen no está presente y se anula el ISSU:

Cuando la imagen no está presente

Cuando el archivo de imagen está dañado

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

El nodo principal valida la configuración del dispositivo para garantizar que se pueda confirmar con la nueva versión de software. Si algo sale mal, el ISSU se aborta 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 el sitio remoto no es accesible.

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 ubicado en un sitio remoto. Si el archivo no existe o el sitio remoto no es accesible, se informa de un error.

Errores de conmutación por error del grupo de redundancia

Problema

Descripción

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

Solución

Utilice 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 errores ksyncd en el nodo secundario (nodo 1) y muestra el mensaje de error si hay algún problema y anula la actualización.

Documentación relacionada

Tabla de historial de versiones
Lanzamiento
Descripción
17.4R1
A partir de Junos OS versión 17.4R1, los dispositivos SRX4600 son compatibles con ISSU.
17.4R1
A partir de Junos OS versión 17.4R1, el temporizador de espera para el reinicio inicial del nodo secundario durante el proceso ISSU se extiende de 15 minutos (900 segundos) a 45 minutos (2700 segundos) en clústeres de chasis en dispositivos SRX1500, SRX4100, SRX4200 y SRX4600.
15.1X49-D80
A partir de Junos OS versión 15.1X49-D80, los dispositivos SRX4100 y SRX4200 admiten ISSU.
15.1X49-D80
A partir de Junos OS versión 15.1X49-D80, los dispositivos SRX4100 y SRX4200 admiten ISSU.
15,1X49-D70
A partir de Junos OS versión 15.1X49-D70, los dispositivos SRX1500 admiten ISSU.
15,1X49-D70
A partir de Junos OS versión 15.1X49-D70, los dispositivos SRX1500 admiten ISSU.