Consideraciones generales acerca de la actualización

Antes de realizar una actualización de vSRX, tenga en cuenta las consideraciones siguientes:

• Es posible que se produzcan interrupciones en la red al actualizar la versión de vSRX. Para evitar las interrupciones, realice la actualización en una ventana de mantenimiento que dé soporte al tiempo de inactividad de red potencial. La migración tras error no está disponible hasta que finaliza la actualización, y puede tardar varias horas. Para los entornos de alta disponibilidad (HA), se migran los valores de configuración de vSRX; sin embargo, se recomienda exportar los valores antes de la actualización.

• En el caso de un entorno autónomo, la configuración anterior no se restaura, por lo que debe exportar e importar la configuración. Para obtener más información, consulte Importación y exportación de una configuración vSRX.

• Para conseguir una recarga satisfactoria en un vSRX de alta disponibilidad, la contraseña de raíz de la pasarela vSRX suministrada debe coincidir con la contraseña raíz definida en el portal de vSRX. Además, debe habilitar el inicio de sesión raíz de SSH en la IP privada de vSRX.

  La contraseña se ha definido en el portal cuando se ha suministrado la pasarela. Es posible que no coincida con la contraseña de pasarela actual. Si se ha cambiado la contraseña después del suministro, utilice SSH para conectarse a la pasarela vSRX y cambie la contraseña raíz para que coincida. La comprobación de preparación falla si hay una discrepancia de contraseñas.

• No modifique la configuración de vSRX durante una recarga del SO. El proceso de actualización captura una instantánea de la configuración de clúster vSRX actual al principio del proceso. Por lo tanto, modificar la configuración de vSRX durante el proceso de actualización puede provocar anomalías o consecuencias imprevistas. Por ejemplo, agentes de software automáticos que intentan modificar uno o ambos nodos de vSRX. Los cambios de configuración pueden corromper el proceso de recarga de SO. Además, estos cambios de configuración no se conservan si se inicia una retrotracción.

• Antes de realizar una actualización de recarga de SO, ejecute el mandato show chassis cluster status. Los nodos deben agruparse en un clúster, designando uno de ellos como primario y el otro como secundario. Asegúrese de que no haya monitor failures. Si el clúster no se encuentra en buen estado antes de la actualización, esta podría fallar, lo que provocaría una interrupción prolongada del tráfico.

  Ejemplo de un clúster en buen estado:

   root@asloma-19-10g-ha1-vsrx-vSRX-Node0> show chassis cluster status
   Monitor Failure codes:
     CS  Cold Sync monitoring        FL  Fabric Connection monitoring
     GR  GRES monitoring             HW  Hardware monitoring
     IF  Interface monitoring        IP  IP monitoring
     LB  Loopback monitoring         MB  Mbuf monitoring
     NH  Nexthop monitoring          NP  NPC monitoring
     SP  SPU monitoring              SM  Schedule monitoring
     CF  Config Sync monitoring      RE  Relinquish monitoring
     IS  IRQ storm
  
   Cluster ID: 2
   Node   Priority Status               Preempt Manual   Monitor-failures
  
   Redundancy group: 0 , Failover count: 1
   node0  100      primary              no      no       None
   node1  1        secondary            no      no       None
  
   Redundancy group: 1 , Failover count: 1
   node0  100      primary              no      no       None
   node1  1        secondary            no      no       None
  
   {primary:node0}
  

  Ejemplo de un clúster en mal estado con errores de supervisor:

    root@asloma-tc11-15-10g-pubpriv-ha1-vsrx-vSRX-Node1> show chassis cluster status
    Monitor Failure codes:
      CS  Cold Sync monitoring        FL  Fabric Connection monitoring
      GR  GRES monitoring             HW  Hardware monitoring
      IF  Interface monitoring        IP  IP monitoring
      LB  Loopback monitoring         MB  Mbuf monitoring
      NH  Nexthop monitoring          NP  NPC monitoring
      SP  SPU monitoring              SM  Schedule monitoring
      CF  Config Sync monitoring
    Cluster ID: 3
    Node   Priority Status         Preempt Manual   Monitor-failures
  
    Redundancy group: 0 , Failover count: 1
    node0  0        lost           n/a     n/a      n/a
    node1  1        primary        no      no       None
  
    Redundancy group: 1 , Failover count: 1
    node0  0        lost           n/a     n/a      n/a
    node1  0        primary        no      no       CS
  
    {primary:node1}
  

• Si la cuenta de IBM Cloud tiene varias instancias de pasarela vSRX en el mismo pod, asegúrese de que solamente se actualice una pasarela cada vez. La actualización de más de una vSRX a la vez puede provocar conflictos de IP, interrumpir el proceso de actualización y potencialmente provocar anomalías.

• Si configura su clúster de alta disponibilidad (HA) para que utilice políticas de detección de intrusiones (IDP) y una base de datos de firmas, se recomienda que actualice la base de datos de firmas una vez completada la actualización. Esto se debe a que la base de datos podría estar obsoleta. Para obtener información sobre las actualizaciones de la base de datos en línea y fuera de línea, consulte «Detección y prevención de intrusiones» en IBM Cloud

• El proceso de actualización no realiza copias de seguridad ni restaura ningún certificado de vSRX almacenado localmente en la máquina virtual ( VM ) que se está actualizando. El proceso de actualización elimina el directorio « VM » existente y crea uno nuevo, que sustituye al sistema de archivos « JunOS ». Por ejemplo, se debe realizar una copia de seguridad de un certificado local como IKE_POLICY_CERT antes de la actualización y se debe restaurar manualmente después de que se complete.

set security ike policy MY_VPN_IKE_POLICY certificate local-certificate IKE_POLICY_CERT

apt update
apt list --upgradable
apt upgrade