Actualización de software en alta disponibilidad de múltiples nodos
Lea este tema para aprender a realizar actualizaciones de software en firewalls en la configuración de alta disponibilidad multinodo.
Descripción general
Para obtener una lista de las funciones compatibles con las diferentes plataformas y versiones de software, consulte el Explorador de características.
Los firewalls de Junos implementados en una configuración MNHA se pueden actualizar con una interrupción mínima mediante la actualización secuencial de cada dispositivo. Dependiendo de la arquitectura de su dispositivo, use uno de los siguientes comandos de CLI para iniciar la actualización request system software add de Junos o request vmhost software add .
| Desde la versión de Junos OS | A la versión de Junos OS | Usar el método de actualización de software |
|---|---|---|
| 20.4 | Cualquier versión posterior a 20.4 | No |
| 22.3 | Próxima versión de la versión de Junos OS | Sí |
-
Las versiones 22.4R1 y posteriores no son compatibles con versiones anteriores de Junos OS para sincronizar sesiones durante una actualización regular. Utilice el procedimiento de actualización de nodos aisladosen tales casos.
-
En los despliegues de alta disponibilidad multinodo (MNHA) que utilizan direcciones IPv6 para el cifrado de vínculos de interchasis (ICL) (vínculo de alta disponibilidad), la actualización desde una versión anterior de Junos OS a una que admite el cifrado ICL basado en IPv6 requiere usar el procedimiento de actualización de nodos aislados para garantizar una transición exitosa. Este es un requisito único al pasar a la primera versión compatible; Las actualizaciones posteriores no requieren el procedimiento de actualización de nodo aislado.
-
La actualización de la versión 22.3 a la siguiente puede causar una breve interrupción del tráfico.
-
Es posible que lo vea
Peer Hardware Incompatible: SPU SLOT MISMATCHdurante las actualizaciones a partir de la versión 21.4R1. -
Las sesiones de TDR no se sincronizan durante las etapas de actualización intermedias en versiones anteriores a 23.4R2.
-
Actualice siempre ambos nodos a la misma versión de Junos OS.
Para obtener información sobre la compatibilidad de actualización y degradación para versiones de Junos OS, consulte Política de soporte de actualización y degradación para versiones de Junos OS y versiones extendidas de fin de vida útil en las notas de la versión.
Cuando actualice firewalls en alta disponibilidad multinodo a la versión 22.4R1 de Junos OS o a una versión superior, desde una versión anterior de Junos OS, puede utilizar el procedimiento de actualización de nodos aislados. La versión 22.4R1 y superiores de Junos OS no son compatibles con versiones anteriores de Junos OS para sincronizar sesiones durante una actualización regular.
Antes de empezar
Antes de realizar una actualización en un firewall en la configuración MNHA), se recomienda redirigir el tráfico fuera del dispositivo de forma controlada. Esto se puede hacer utilizando uno de los siguientes métodos:
-
Conmutación por tolerancia a fallos manual: active una conmutación por tolerancia a fallos manual para desplazar el tráfico al dispositivo emparejado.
-
Modo de actualización de software: configure temporalmente el dispositivo con el siguiente comando:
user@host# set chassis high-availability software-upgrade
Este comando introduce un error de dispositivo con el código de error usuario único (SU) (actualización de software). Como resultado, los grupos de redundancia de servicios (SRG) 1 y superiores pasarán a un estado No apto (en lugar de Activo o Copia de respaldo) en el dispositivo que se está actualizando. Esto hace que el tráfico asociado conmute automáticamente al otro miembro del clúster de MNHA.
Nota: Si el clúster de MNHA está configurado solo con SRG0 e incluye la opción, aún puede redirigir elinstall-on-failure-routetráfico mediante laset chassis high-availability software-upgradeconfiguración para mover el tráfico fuera del dispositivo con elegancia.
Actualización de Software
Lista de verificación de preparación
Tenga en cuenta las siguientes prácticas recomendadas al planificar la actualización de su software:
- Asegúrese de que ambos nodos estén en línea y que ejecuten la misma versión de Junos OS. Compruebe la versión actual del software Junos OS en el dispositivo mediante el comando show version.
- Verifique la disponibilidad de almacenamiento:
show system storage - Comprobar el estado del hardware:
show chassis fpc pic-statusshow chassis alarms
- Asegúrese de que no haya cambios sin confirmar.
- Configuración de respaldo y claves de licencia.
- Descargue la imagen de Junos OS en /var/tmp en ambos dispositivos.
- Asegúrese de que su configuración de alta disponibilidad sea saludable, funcional y que el vínculo de interchasis (ICL) esté activo.
show chassis high-availability information - Prepare sus firewalls para una actualización utilizando la lista de verificación disponible en .
Para obtener más información sobre cómo preparar el dispositivo para una actualización, consulte Preparación para la instalación y actualización de software (Junos OS).
Descargar software
Descargue la imagen de Junos OS de la página de soporte de Juniper Networks en ambos firewalls y guárdela en la ubicación /var/tmp . Ejemplo:
user@host> request system software add /var/tmp/junos-install-vsrx3-x86-64-22.3R1.3.tgz no-copy
Procedimiento de actualización
Siga los pasos de este procedimiento para actualizar los firewalls configurados en una configuración de alta disponibilidad multinodo (MNHA). En este ejemplo, el clúster consta de dos dispositivos: Firewall-01 (actualmente activo) y Firewall-02 (actualmente copia de seguridad). El proceso de actualización comienza con el nodo de respaldo (Firewall-02), seguido del nodo activo (Firewall-01), lo que garantiza una interrupción mínima del servicio.
Asegúrese de que su configuración de alta disponibilidad multinodo sea correcta, funcional y que el vínculo de interchasis (ICL) esté activo.
En el dispositivo Firewall-01
user@Firewall-01> show chassis high-availability informationNode failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: ONLINE Local-id: 1 Local-IP: 10.22.0.1 HA Peer Information: Peer Id: 2 IP address: 10.22.0.2 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 2 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: ACTIVE Activeness Priority: 200 Preemption: ENABLED Process Packet In Backup State: NO Control Plane State: READY System Integrity Check: N/A Failure Events: NONE Peer Information: Peer Id: 2 Status : BACKUP Health Status: HEALTHY Failover Readiness: READYEn el dispositivo Firewall-02
user@Firewall-02> show chassis high-availability informationNode failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: ONLINE Local-id: 2 Local-IP: 10.22.0.2 HA Peer Information: Peer Id: 1 IP address: 10.22.0.1 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 1 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: BACKUP Activeness Priority: 1 Preemption: DISABLED Process Packet In Backup State: NO Control Plane State: READY System Integrity Check: COMPLETE Failure Events: NONE Peer Information: Peer Id: 1 Status : ACTIVE Health Status: HEALTHY Failover Readiness: N/A- Inicie el proceso de actualización de software en el nodo de respaldo (Firewall-02) y confirme la configuración
user@Firewall-02# set chassis high-availability software-upgrade
Este comando desencadena una tolerancia a fallos local para SRG0 y marca SRG1 (si está presente) como NO elegible, lo que permite que el nodo par tome o conserve el rol activo
- Verifique el estado de Alta disponibilidad multinodo. El resultado muestra Estado del nodo: OFFLINE [ usuario único ], lo que indica que el nodo está listo para la actualización del software. Puede ver que el estado del SRG1 cambió a INELEGIBLE.
user@Firewall-02> show chassis high-availability information Node failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: OFFLINE [ SU ] Local-id: 1 Local-IP: 10.22.0.1 HA Peer Information: Peer Id: 2 IP address: 10.22.0.2 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 2 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: INELIGIBLE Activeness Priority: 200 Preemption: ENABLED Process Packet In Backup State: NO Control Plane State: N/A System Integrity Check: IN PROGRESS Failure Events: NONE Peer Information: Peer Id: 2 Status : ACTIVE Health Status: HEALTHY Failover Readiness: N/A Confirme que el otro dispositivo (Firewall-01) esté en una función activa y funcione normalmente.
user@Firewall-01> show chassis high-availability informationNode failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: ONLINE Local-id: 2 Local-IP: 10.22.0.2 HA Peer Information: Peer Id: 1 IP address: 10.22.0.1 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 1 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: ACTIVE Activeness Priority: 1 Preemption: DISABLED Process Packet In Backup State: NO Control Plane State: READY System Integrity Check: N/A Failure Events: NONE Peer Information: Peer Id: 1 Status : INELIGIBLE Health Status: UNHEALTHY Failover Readiness: NOT READYEl resultado del comando muestra que el estado de SRG1 es ACTIVE.
Tenga en cuenta que en la
Peer Informationsección del SRG1, el estado esINELIGIBLEel que indica que el otro nodo está en estado no elegible.- Instale el software de Junos OS en el dispositivo Firewall-02.
user@Firewall-02> request system software add /var/tmp/junos-install-vsrx3-x86-64-22.3R1.3.tgz no-copy
- Reinicie el dispositivo con el comando después de una
request system rebootinstalación exitosa. - Compruebe la versión de Junos OS después de reiniciar.
user@Firewall-02> show versionHostname: Firewall-02 Model: vSRX Junos: 22.3R1.3El resultado confirma que el dispositivo se actualizó a la versión correcta de Junos OS.
- Compruebe el estado de la alta disponibilidad multinodo en el dispositivo.
user@Firewall-02> show chassis high-availability informationNode failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: OFFLINE [ SU ] Local-id: 1 Local-IP: 10.22.0.1 HA Peer Information: Peer Id: 2 IP address: 10.22.0.2 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 2 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: INELIGIBLE Activeness Priority: 200 Preemption: ENABLED Process Packet In Backup State: NO Control Plane State: N/A System Integrity Check: COMPLETE Failure Events: NONE Peer Information: Peer Id: 2 Status : ACTIVE Health Status: HEALTHY Failover Readiness: N/AEl resultado sigue mostrando el estado del nodo como
OFFLINE [ SU ]y el estado de SRG1 comoINELIGIBLE. - Quite la
software-upgradeinstrucción y confirme la configuración.user@Firewall-02# delete chassis high-availability software-upgrade
Cuando se quita la
software-upgradeinstrucción, se borran el estado de tolerancia a fallos del nodo y las rutas instaladas. Hasta que se quite esta instrucción, el nodo permanece sin conexión y todos los SRG permanecen en el estado INELEGIBLE. Esto aísla eficazmente al nodo del tráfico de manejo durante la actualización, siempre y cuando el par permanezca en buen estado. -
Vuelva a comprobar el estado de alta disponibilidad multinodo para confirmar que el dispositivo está en línea y que el estado general es correcto y funcional.
user@srx02> show chassis high-availability information Node failure codes: HW Hardware monitoring LB Loopback monitoring MB Mbuf monitoring SP SPU monitoring CS Cold Sync monitoring SU Software Upgrade Node Status: ONLINE Local-id: 1 Local-IP: 10.22.0.1 HA Peer Information: Peer Id: 2 IP address: 10.22.0.2 Interface: ge-0/0/2.0 Routing Instance: default Encrypted: YES Conn State: UP Cold Sync Status: COMPLETE Services Redundancy Group: 0 Current State: ONLINE Peer Information: Peer Id: 2 SRG failure event codes: BF BFD monitoring IP IP monitoring IF Interface monitoring CP Control Plane monitoring Services Redundancy Group: 1 Deployment Type: ROUTING Status: BACKUP Activeness Priority: 200 Preemption: ENABLED Process Packet In Backup State: NO Control Plane State: READY System Integrity Check: IN PROGRESS Failure Events: NONE Peer Information: Peer Id: 2 Status : ACTIVE Health Status: HEALTHY Failover Readiness: N/AEl resultado muestra
Node Status: ONLINEy el estado de SRG1 comoBACKUP, lo que indica que el nodo está de nuevo en línea y funciona normalmente en función de respaldo. -
Compruebe las interfaces, los protocolos de enrutamiento, las rutas anunciadas, etc., para confirmar que la configuración funciona con normalidad.
Ahora puede proceder a actualizar el otro dispositivo (Firewall-01) utilizando el mismo procedimiento.
(Opcional) En caso de que tenga algún problema y no pueda completar la actualización, puede revertir el software en el dispositivo y, a continuación, reiniciar el sistema. Utilice el request system software rollback comando para restaurar la versión de software instalada anteriormente.
Actualice el software mediante la ruta de instalación en caso de falla
En el caso de las configuraciones que utilizan solo SRG0 (sin compatibilidad con el estado A/B), se recomienda configurar la ruta de instalación en caso de error. Se puede hacer referencia a esta ruta en las políticas de ruta para anunciar rutas menos preferidas durante situaciones de actualización de software o fallas de nodos. En este método, puede desviar el tráfico cambiando la ruta. Aquí, el tráfico aún puede pasar por el nodo y la interfaz permanece activa.
-
Cree un enrutador virtual personalizado dedicado para la ruta utilizada para desviar el tráfico durante la actualización.
set routing-instances MNHA-signal-routes instance-type virtual-router
- Configure la
install-on-failure-routeinstrucción para SRG0. Aquí, ha configurado la ruta con la dirección IP 10.39.1.3 como la ruta que se va a instalar cuando el nodo falla.set routing-instances MNHA-signal-routes instance-type virtual-router set chassis high-availability services-redundancy-group 0 install-on-failure-route 10.39.1.3 routing-instance MNHA-signal-routes set chassis high-availability services-redundancy-group 1 active-signal-route 10.39.1.1 routing-instance MNHA-signal-routes set chassis high-availability services-redundancy-group 1 backup-signal-route 10.39.1.2 routing-instance MNHA-signal-routes
La tabla de enrutamiento instala la ruta mencionada en la instrucción cuando se produce un error en el nodo.
- Configure una política de enrutamiento coincidente y defina una condición de política basada en la existencia de rutas. Aquí incluye la ruta 10.39.1.3 como condición de coincidencia de ruta para el
if-route-existsarchivo .set policy-options condition active_route_exists if-route-exists address-family inet 10.39.1.1/32 set policy-options condition active_route_exists if-route-exists address-family inet table MNHA-signal-routes.inet.0 set policy-options condition backup_route_exists if-route-exists address-family inet 10.39.1.2/32 set policy-options condition backup_route_exists if-route-exists address-family inet table MNHA-signal-routes.inet.0 set policy-options condition failure_route_exists if-route-exists address-family inet 10.39.1.3/32 set policy-options condition failure_route_exists if-route-exists address-family inet table MNHA-signal-routes.inet.0
Cree la instrucción de política para hacer referencia a la condición como uno de los términos coincidentes.
set policy-options policy-statement mnha-route-policy term 4 from protocol static set policy-options policy-statement mnha-route-policy term 4 from protocol direct set policy-options policy-statement mnha-route-policy term 4 from condition failure_route_exists set policy-options policy-statement mnha-route-policy term 4 then metric 100 set policy-options policy-statement mnha-route-policy term 4 then accept
- Inicie la actualización de software como se mencionó en los pasos anteriores (Actualización de software).
Método obsoleto (interfaz de apagado en caso de error)
A partir de la versión 24.3R1 de Junos OS, la shutdown-on-failure funcionalidad está en desuso, en lugar de eliminarse inmediatamente, para proporcionar compatibilidad con versiones anteriores y una oportunidad para que su configuración cumpla con la nueva configuración. Como parte de este cambio, la instrucción de configuración [set chassis high-availability services-redundancia-group 0 shutdown-on-failure interface-name] quedó obsoleta.
Anteriormente, el tráfico tenía que desviarse manualmente cerrando las interfaces. Ahora puede usar el comando software-upgrade para mantener el nodo sin conexión y todos los SRG en el estado INELEGIBLE mientras dure la actualización. Esto aísla eficazmente al nodo del manejo del tráfico.
Si utiliza Junos OS 22.4 o anterior, le recomendamos que utilice los métodos heredados para desviar el tráfico durante la actualización.