Descripción de la actualización de software sin interrupciones en un chasis virtual y un chasis virtual mixto

Beneficios de NSSU

• Sin interrupciones en el plano de control: NSSU usa un cambio de motor de enrutamiento ( GRES) (y un enrutamiento activo sin interrupciones (NSR) en las plataformas aplicables) para garantizar que no se produzcan interrupciones en el plano de control. Durante el proceso de actualización, Virtual Chassis conserva la información de la interfaz, el kernel y el protocolo de enrutamiento.

• Interrupción mínima del tráfico de red: NSSU minimiza la interrupción del tráfico de red al actualizar los conmutadores miembro de uno en uno, lo que permite que los miembros principales y de respaldo mantengan sus roles principal y de respaldo (aunque el rol principal cambiará) sin interrumpir el tráfico y permitiendo que el tráfico continúe fluyendo a través de los miembros en el rol de tarjeta de línea que no se están actualizando.

Requisitos para realizar una NSSU

Los requisitos para realizar NSSU para un chasis virtual incluyen:

• Todos los miembros de Virtual Chassis y todos los motores de enrutamiento deben ejecutar la misma versión de Junos OS.

• Debe habilitar el cambio de motor de enrutamiento correcto (GRES).

• Debe habilitar el enrutamiento activo sin interrupciones (NSR) para las plataformas aplicables.

  Aunque no se requiere un puente sin interrupción (NSB) para realizar una NSSU, también recomendamos habilitar NSB antes de realizar una NSSU en las plataformas aplicables. NSB garantiza que todos los protocolos de capa 2 compatibles con NSB funcionen sin problemas cuando el motor de enrutamiento cambie durante NSSU. Consulte Configuración de puentes ininterrumpidos en conmutadores (procedimiento de CLI).

• Para minimizar la interrupción del tráfico, debe configurar los grupos de agregación de vínculos (LAG) de manera que los vínculos de miembro de cada LAG residan en diferentes miembros del Virtual Chassis, y configurar el Protocolo de control de agregación de vínculos (LACP) para supervisar los estados de los vínculos de los miembros del LAG. Cuando un enlace miembro de un GAL está inactivo, los vínculos restantes están activos y el tráfico sigue fluyendo a través del LAG. Para obtener más información sobre la configuración de LAG y LACP, consulte Configuración de agregación de vínculos y Configuración de LACP de Ethernet agregada (procedimiento de CLI).

  Nota:

  Cuando se actualiza un conmutador de la serie EX en un Virtual Chassis mixto a Junos OS versión 15.1 o posterior desde una versión anterior a la versión 15.1, es posible que se produzca una caída del tráfico durante un máximo de 60 segundos.

  Nota:

  Durante una operación de NSSU, si intenta ver el estado de la interfaz LAG en el miembro principal del motor de enrutamiento mediante el comando de la show interfaces ae-ae-interface-number CLI, es posible que vea recuentos de tráfico incorrectos o nulos. Para evitar este problema, ejecute el comando en el miembro del motor de enrutamiento de reserva en su lugar si ese miembro ya está cargado y en ejecución.

Requisitos para los miembros del Virtual Chassis o Virtual Chassis mixtos que se actualizan mediante NSSU:

• Los conmutadores miembro deben estar conectados en una topología de anillo para que ningún miembro quede aislado como resultado de que se reinicie otro miembro. Esta topología impide que el chasis virtual se divida durante una NSSU.

• Los conmutadores miembro principal y de reserva deben ser adyacentes entre sí en la topología de anillo. La ubicación adyacente garantiza que la función principal y la copia de seguridad estén siempre sincronizadas mientras se reinician los roles de tarjeta de línea.

• El chasis virtual está preaprovisionado y usted ha asignado explícitamente la función de tarjeta de línea a los conmutadores miembro que actúan en una función de tarjeta de línea. Los conmutadores miembro principal y de respaldo de Virtual Chassis cambian de rol principal mientras uno u otro se actualiza durante NSSU, pero deben mantener sus roles de motor de enrutamiento principal y de respaldo, y los conmutadores restantes deben mantener sus roles de tarjeta de línea.

• Un Virtual Chassis de dos miembros debe estar no-split-detection configurado para que el Virtual Chassis no se divida cuando una NSSU actualice a un miembro. Consulte Descripción de la división y combinación en un chasis virtual.

Cómo funciona una NSSU en un chasis virtual y un chasis virtual mixto

Cuando solicite una NSSU en un Virtual Chassis o Virtual Chassis mixto:

1. El chasis virtual verifica principalmente que:

   • La copia de seguridad está en línea y ejecuta la misma versión de software.

   • Habilitó el cambio de motor de enrutamiento elegante (GRES) y, si corresponde, el enrutamiento activo sin paradas (NSR).

   • Utilizó una configuración aprovisionada previamente para configurar el Virtual Chassis.

2. La principal copia la nueva imagen de software en la copia de seguridad y en los miembros restantes del rol de tarjeta de línea en secuencia mediante rcp.

   (Solo para QFX5100 Virtual Chassis) A partir de Junos OS versión 14.1X53-D40, para optimizar el tiempo necesario para completar una operación NSSU para un Virtual Chassis, el principal utiliza sesiones paralelas rcp para copiar el nuevo software a varios miembros a la vez (en lugar de esperar a que se complete la operación de copia para cada miembro antes de comenzar a copiar la imagen del software al siguiente miembro). El principal utiliza un algoritmo predeterminado para determinar el número de operaciones de copia paralela en función del número de miembros del Virtual Chassis, o puede configurar un número específico mediante la instrucción configuration rcp-count . Consulte rcp-count para obtener más información.

   Nota:

   Si se produce un error al copiar el nuevo software en cualquier miembro, NSSU finaliza el proceso de actualización de todo el Virtual Chassis sin reiniciar ningún miembro y registra la condición de error. A partir de Junos OS versión 14.1X53-D40, si se produce un error en una operación de copia NSSU a un miembro, el principal realiza una medida de recuperación de errores adicional para eliminar el nuevo software de los miembros a los que ya se transfirió.

3. La principal reinicia el conmutador del miembro de copia de seguridad con el nuevo software y la copia de seguridad se vuelve a sincronizar con la principal.

4. El principal carga y reinicia los conmutadores miembro que están en el rol de tarjeta de línea, uno a la vez. El principal espera a que cada miembro esté en línea y activo ejecutando el nuevo software antes de reiniciar al siguiente miembro.

   • Si configuró grupos de actualización, los miembros de Virtual Chassis del primer grupo de actualización cargan la nueva imagen y reinician. Cuando los miembros de ese grupo de actualización vuelvan a estar en línea, los miembros del siguiente grupo de actualización cargarán la nueva imagen y reiniciarán. (NSSU actualiza los grupos en el orden en que aparecen en la configuración).

   • El tráfico continúa fluyendo a través de los otros miembros durante este proceso.

5. El reinicio continúa hasta que todos los miembros activos se hayan reiniciado con el nuevo software.

   Nota:

   Si algún miembro de la función de tarjeta de línea no se reinicia correctamente, NSSU finaliza el proceso de actualización y registra la condición de error. En este caso, para evitar la inestabilidad del chasis virtual, debe retroceder la actualización parcial restaurando el software antiguo y reiniciando los miembros que ya se reiniciaron con el nuevo software, o intentar reiniciar manualmente todos los miembros con el nuevo software que se les copió, para que todos los miembros vuelvan a conectarse ejecutando la misma versión del software.

   A partir de Junos OS versión 14.1X53-D40, NSSU invoca automáticamente medidas de recuperación si se produce un error en el reinicio en cualquier miembro de la función de tarjeta de línea, deteniendo el proceso de reinicio secuencial y desactivando y reiniciando todo el Virtual Chassis. Luego, el chasis virtual muestra limpiamente todos los miembros al mismo tiempo que ejecutan el nuevo software, lo que recupera la estabilidad del chasis virtual más rápidamente que tener un chasis virtual inestable que ejecuta diferentes versiones del software que intentan converger.

6. Después de que la principal ha actualizado a todos los miembros en el rol de tarjeta de línea, realiza un cambio de motor de enrutamiento elegante y el conmutador miembro de reserva actualizado se convierte en el nuevo principal.

7. El nuevo primario actualiza el software en el primario original y lo reinicia automáticamente. Después de que el principal original se haya vuelto a unir al Virtual Chassis, opcionalmente puede revertir la función principal a ese conmutador solicitando explícitamente otro cambio correcto del motor de enrutamiento.

Limitaciones de NSSU

No puede usar NSSU para degradar el software, es decir, para instalar una versión anterior del software que la que se está ejecutando actualmente en el conmutador. Para instalar una versión anterior del software, utilice el request system software add comando.

No puede revertir a la versión anterior del software después de realizar una actualización con NSSU. Si necesita revertir a la versión de software anterior, puede reiniciar desde la partición raíz alternativa si aún no ha copiado la nueva versión de software en la partición raíz alternativa.

Soporte de lanzamiento de NSSU y Junos OS

NSSU solo funciona en algunos chasis virtuales con versiones particulares desde y hacia Junos OS. Comuníquese con el Centro de asistencia técnica de Juniper Networks (JTAC) para confirmar las versiones compatibles desde y hacia si está considerando actualizar su chasis virtual mediante NSSU.

Si el Virtual Chassis ejecuta una versión de software que no admite NSSU o no admite la combinación de versiones desde y hacia con NSSU, utilice el request system software add comando para actualizar los conmutadores miembro del Virtual Chassis individualmente.

También puede consultar este ejemplo de configuración de red sobre cómo actualizar manualmente un chasis virtual de la serie QFX de dos miembros con un impacto mínimo en el flujo de tráfico cuando no se admite NSSU:

• Procedimiento de actualización del chasis virtual de la serie QFX de dos miembros

Descripción general de la configuración y el funcionamiento de NSSU

Para que NSSU se realice correctamente, el chasis virtual y los conmutadores miembro deben cumplir los requisitos descritos en Requisitos para realizar una NSSU. NSSU solo requiere esos pasos de configuración.

Si su Virtual Chassis cumple con los requisitos de NSSU, simplemente ingrese el request system software nonstop-upgrade comando para iniciar NSSU. Consulte Actualización de software en un chasis virtual y Chasis virtual mixto mediante actualización de software sin interrupciones para obtener más información.