Resolución de problemas de actualización

Retroceso a una versión anterior

Para que VRA retroceda a una versión anterior, realice una de las acciones siguientes, dependiendo de la situación:

• Si puede acceder a su VRA utilizando la consola IPMI o SSH, utilice el mandato CLI de Vyatta para establecer una imagen de arranque predeterminada y, a continuación, rearranque. El VRA se reiniciará en la versión elegida. Por ejemplo:

  vyatta@vyatta01:~$ set system image default-boot
  Possible completions:
    1801q.09052048
    1912q.09012155
    1912r.10190551
    2012d.06101417
    2012h.04211451
    2110c.03031901
    <Enter>         Execute the current command
    <text>          <No help text available>
  
  vyatta@vyatta01:~$ set system image default-boot 2012d.06101417
  Default boot image has been set to "2012d.06101417".
  You need to reboot the system to start the new default image.
  
  vyatta@vyatta01:~$ reboot
  Proceed with reboot? (Yes/No) [No] y
  
  Broadcast message from vyatta@vyatta01 (pts/1) (Mon May 23 11:07:03 20
  
  The system is going down for reboot
  

• Si no puede acceder a su VRA utilizando SSH o la consola IPMI, rearranque el dispositivo y, a continuación, pulse la tecla Esc durante el arranque para acceder al menú de arranque Grub. Seleccione la versión a la que quiera volver.

  También puede utilizar el menú de arranque Grub para recuperar la contraseña de un usuario de Vyatta.

Si su VRA está en un estado de restablecimiento de fábrica

Si su VRA es inaccesible después de una actualización, y su contraseña no funciona en la consola IPMI, es probable que el dispositivo esté en un estado de restablecimiento de fábrica. Hay al menos dos escenarios que pueden causar este problema.

En primer lugar, es posible que haya seleccionado No en lugar de Sí cuando se le solicitó que guardara la configuración durante el proceso de actualización. Para solucionar este problema, inicie la sesión como el usuario que tenía anteriormente y, a continuación, rearranque. Después de esto, emplee uno de los dos métodos que se describen en la sección anterior para retroceder a una versión anterior. A continuación, puede volver a realizar el procedimiento de actualización, esta vez asegúrese de seleccionar Sí para guardar la configuración.

La segunda posibilidad es que haya una línea antigua en su archivo de configuración que la versión a la que está actualizando no admite. Suele ser un error y se debe informar creando un caso de soporte.

Puede solucionar este problema iniciando sesión como usuario vyatta con la contraseña vyatta desde la consola remota de IPMI. Para encontrar el archivo config.boot más reciente en el sistema de archivos VRA, ejecute el mandato linux/bash find y, a continuación, ejecute el mandato merge en ese archivo para encontrar la causa del problema de configuración durante la actualización. Si el usuario y la contraseña predeterminados de vyatta no funcionan, utilice el proceso descrito anteriormente en "Revertir a una versión anterior" para seleccionar la opción de recuperación de contraseña y restablecer la contraseña del usuario de Vyatta. Una vez que obtenga acceso, busque y fusione el archivo config.boot más reciente. Si no puede encontrar un archivo config.boot para utilizarlo, puede configurar manualmente una interfaz, una ruta estática y un puerto SSH para obtener acceso de red y SSH al sistema. Esto le permitirá copiar y pegar en (o scp) un archivo de configuración de copia de seguridad para fusionar. Si no puede ejecutar mandatos normales de Vyatta, como configure, para entrar en la modalidad de configuración, intente ejecutar el mandato bash para acceder a un shell utilizable.

En el ejemplo siguiente se ilustran los problemas cuando se actualiza de 1801ze a 1912f. Observe que el mandato find ha extraído 4 archivos config.boot que se han archivado en el sistema de archivos incluso después de la actualización. Para utilizar el mandato find, utilice el mandato su para que el usuario cambie al usuario root.

vyatta@gateway02# find / -name config.boot 2>/dev/null | grep 1801ze
/lib/live/mount/persistence/sda2/boot/1801ze.01142008/persistence/rw/mnt/config/config.boot
/lib/live/mount/persistence/sda2/boot/1801ze.01142008/persistence/rw/mnt/config/archive/config.boot
/run/live/persistence/sda2/boot/1801ze.01142008/persistence/rw/mnt/config/config.boot
/run/live/persistence/sda2/boot/1801ze.01142008/persistence/rw/mnt/config/archive/config.boot

vyatta@gateway02# merge /lib/live/mount/persistence/sda2/boot/1801ze.01142008/persistence/rw/mnt/config/config.boot

Utilizando la modalidad de configuración, ejecute el mandato merge o load, especificando uno de los archivos config.boot más recientes del ejemplo anterior y, a continuación, confirme. Los errores mostrarán la causa del problema, por lo que debería suprimir las configuraciones no válidas y añadir las válidas según sea necesario. Repita este proceso y resuelva todos los problemas hasta que la confirmación se realice correctamente y Vyatta vuelva a su estado de trabajo anterior.

Puede actualizar los otros VRA sin tener que repetir este proceso realizando los mismos cambios en esos dispositivos antes de intentar una actualización. Solucionar estos problemas antes de ejecutar la actualización permite que las actualizaciones posteriores funcionen.

Informe de todos los errores que encuentre durante este proceso abriendo un caso de soporte para que el proveedor pueda solucionar estos problemas en releases posteriores.

Solución de un problema de disco

Si un disco está dañado, es posible que la actualización del firmware no se complete correctamente. Compruebe si hay mensajes de error de hardware o compruebe la salud del disco. Para corregir el problema, ejecute una comprobación del sistema de archivos mediante el comando fsck. También puedes reiniciar para resolver un problema de disco, ya que durante el proceso de arranque se ejecuta una comprobación del sistema de archivos.

Actualización de 1801 a 1912

Es posible que encuentre estos problemas comunes al actualizar de 1801 a 1912:

Muchos mandatos de Bash ya no funcionan

En la versión 1912, se activó por defecto una característica de seguridad llamada user-isolation, que crea una sesión de shell en la que los comandos para acceder al sistema Debian subyacente están limitados. Para solucionarlo, confirme la línea set system login user-isolation disable en la configuración y, a continuación, vuelva a iniciar sesión.

Problemas con husos horarios que contienen 3 ubicaciones

Los husos horarios que contienen 3 ubicaciones, como América/Kentua/Monticello, pueden causar un error completo de la actualización, lo que da como resultado que VRA entre en una condición de restablecimiento de fábrica. Para solucionar este problema, establezca el huso horario en uno que solo tenga 2 ubicaciones.

Este problema, VRVDR-52825, se ha solucionado en la versión 1912g.

Los rangos de puertos empiezan por 0 en lugar de 1

Si configura un rango de puertos para que se inicie con 0 en lugar de 1, puede provocar un error total de la actualización, lo que da como resultado que VRA entre en una condición de restablecimiento de fábrica. Para solucionarlo, cambie los rangos de puerto para que empiecen por 1 en lugar de 0 y vuelva a realizar el proceso de actualización.

Este problema, VRVDR-52668, se ha solucionado en la versión 1912g.

Errores con la sincronización de configuración

Según las nuevas características de la versión 1908 de VRA, en la versión 1912, config-sync se reescribió para utilizar netconf. Sin nuevas configuraciones nuevas, obtendrá los siguientes errores cuando intente confirmar:

syncing configuration to remote-router 10.127.225.204 ..
config-sync error 10.127.225.204:Sync[10.127.225.204]: Remote user vyatta not in secrets group
syncing configuration to remote-router 10.127.225.223 ..
config-sync error 10.127.225.223:Remote:10.127.225.223: Connect failed:Could not open socket to 10.127.225.223:830

Para solucionar este problema, asegúrese de añadir la siguiente configuración para que config-sync continúe trabajando:

set service netconf
set service ssh port 830
set system login group secrets
set system login user vyatta group secrets

Si utiliza un usuario distinto de vyatta para config-sync, asegúrese de añadir dicho usuario al grupo de secretos.

Actualización de 1912 a 2012

Es posible que encuentre con estos problemas comunes al actualizar de 1912 a 2012:

AES-NI debe estar habilitado antes de actualizar a 2012

De forma predeterminada, algunas versiones antiguas de BIOS de 2014 inhabilitan AES-NI. Los problemas de IPsec, así como los problemas de VRRP y de sincronización de configuración pueden producir, como resultado, que se inhabilite AES-NI. Para solucionarlo, ejecute una actualización de firmware utilizando un portal de nube para el BIOS de la placa del sistema de VRA antes de actualizar a 2012.

Los túneles IPsec no se inician después de un rearranque o una migración tras error

El comando run-transition-scripts de Vyatta 5400 ha quedado obsoleto, como se indica en las notas de la versión de 2012. En su lugar, utilice la línea notify ipsec configuration en el archivo de configuración VRA que sustituyó a ese comando para el Vyatta 5600.

Este problema también puede ser debido a que AES-NI no está habilitado, según se indica en el problema anterior.

Este ejemplo ilustra la versión anterior:

set interfaces bonding dp0bond1 vrrp vrrp-group 1 run-transition-scripts backup /config/scripts/ipsec-stop
set interfaces bonding dp0bond1 vrrp vrrp-group 1 run-transition-scripts fault /config/scripts/ipsec-stop
set interfaces bonding dp0bond1 vrrp vrrp-group 1 run-transition-scripts master /config/scripts/ipsec-restart

Cambie a este tipo de configuración, asegurándose de que coincida con la interfaz externa y el grupo vrrp correctos:

set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec

Errores con múltiples túneles IPsec

Las versiones de VRA 2012h y anteriores tienen un error por el que los túneles IPsec fallan cuando hay muchos. Cuando esto ocurre, se producen errores similares a los siguientes en los registros de IPsec y del sistema:

2022-04-28T10:15:28+0000 dataplane[4551]: CRYPTODEV: rte_cryptodev_pmd_allocate() line 726: Reached maximum number of crypto devices
2022-04-28T10:15:28+0000 dataplane[4551]: CRYPTODEV: rte_cryptodev_pmd_create() line 110: Fail

Este problema se ha solucionado en la versión 2012k. Actualice a la versión 2012k o posterior.

Después de la migración tras error de Vyatta, el tráfico a través de Netscaler VPX se desactiva

Cuando se produce una migración tras error de VRRP en Vyatta, el nuevo VRRP primario envía GARP. Como especificación, cuando NetScaler VPX recibe GARP, envía una solicitud ARP para validar en lugar de actualizar la tabla ARP utilizando GARP. Borrar manualmente el ARP para la dirección IP específica en el Netscaler VPX es una solución temporal.

Este problema se solucionó en la versión 2012m.

Falta de memoria (OOM) debido a una fuga de memoria SNMP

Las interrupciones y las interrupciones pueden ser el resultado de problemas de OOM debido a fugas de memoria con SNMP.

Este problema se solucionó en la versión 2012m.

Interfaz de túnel GRE en un Vyatta secundario en estado u/u

A partir de la versión 2012, el estado del túnel GRE estará permanentemente activo para los estados State y Link en un Vyatta secundario. Si la IP local de un túnel GRE está en una interfaz activa, permitirá la transmisión (TX) y la recepción (RX) de paquetes en dicha interfaz de túnel (tun). Si el local-ip de un túnel GRE está en una interfaz inactiva, como la interfaz VRRP del Vyatta secundario, el Vyatta no permitirá la transmisión y recepción de paquetes en esa interfaz de túnel (y mantendrá dicha interfaz activa).

Antes de actualizar a 2012, si tiene un BGP activo/pasivo sobre una configuración GRE de alta disponibilidad, asegúrese de que confirma que las interfaces GRE tienen local-ip establecido en una dirección virtual VRRP en lugar de la dirección principal configurada en las interfaces dp0bond0 o dp0bond1. También debe validar que el direccionamiento no se base en que la interfaz de túnel (tun) cambie el estado a A/D o u/u en la migración tras error, ya que esto ya no ocurrirá. En estos casos, IBM puede recomendar la configuración de una política de supervisión de vía de acceso para el punto final GRE remoto. Esto utiliza una comprobación de estado de ping para validar la vía de acceso a través del túnel antes de añadir una ruta a la tabla de direccionamiento de ese túnel. Abra un caso de soporte si tiene preguntas sobre la configuración o si desea más información sobre las políticas de supervisión de vías de acceso.

Actualización de 1801 a 2012

Junto con todos los problemas listados anteriormente para 1801 a 1912 y 1912 a 2012, es posible que encuentre un problema específico al actualizar de 1801 a 2012. Después de la actualización, el Vyatta arranca, pero la configuración se borra. Para tratar este tema, como medida de precaución (y antes de actualizar) establezca el huso horario en 'UTC'. Algunos husos horarios de 1801 no funcionan en 2012, lo que puede estar causando el problema. Por ejemplo, en 1801, los husos horarios se listan como "Americas/Chicago" en lugar de "America/Chicago" en 2012.

2204 problemas con Intel X540

Los dispositivos de pasarela Vyatta que utilizan la NIC de la serie Intel X540 estaban encontrando problemas de VRRP al menos a través de la versión 2204e y posiblemente en 2204f. A partir de 2204g, estos problemas deben arreglarse. A partir de esta actualización, la imagen 2204g ha sido probada y ejecutada por el soporte en el entorno de pruebas de nube durante aproximadamente un mes. El único problema hasta ahora ha sido un caso periférico en el que las interfaces VRRP de un dispositivo secundario finalmente fallan si tanto el clúster se ejecuta en versiones diferentes y connsync (diferente a config-sync) está habilitado (inhabilitado de forma predeterminada).

El mandato lspci | grep Eth muestra el tipo de NIC en Vyatta.

Actualización de 2012 a 2204

A partir de 2204e, no hay problemas conocidos al actualizar entre estos dos releases principales. Si y cuando se conozca algún tema común, se publicarán aquí. Los arreglos de seguridad y los problemas solucionados se seguirán publicando en el sitio web de Ciena Vyatta docs y en la página parches de software de Vyatta.

Problemas de Vbash en las actualizaciones de 5.2 anteriores

De vez en cuando, después de una actualización y rearranque satisfactorios de una nueva versión del sistema operativo Vyatta, es posible que se encuentre con un problema en el que no puede emitir mandatos de usuario.

Por ejemplo:

[jmathews@shelladmindal0101 ~]$ ssh 10.115.174.6 -l vyatta
Welcome to AT&T vRouter

Welcome to AT&T vRouter
Version:      5.2R6S5
Description:  AT&T vRouter 5600 5.2R6S5
Last login: Fri Feb  2 12:42:45 2018 from 10.0.80.100
vyatta@acs-jmat-vyatta01:~$ show int
-vbash: show: command not found

En este caso, el problema no es con la propia actualización. Si hubiera errores en dicho proceso, los vería al emitir el mandato add system image. En esta instancia, el dispositivo se ha rearrancado, pero ahora tiene un espacio de directorio /home nuevo que está vacío y los usuarios que aparecen en la configuración necesitan que se vuelvan a generar sus directorios iniciales. El error se deriva de no haber copiado correctamente los "dotfiles" necesarios en el directorio de usuario vyatta:

vyatta@acs-jmat-vyatta01:~$ ls -la
total 16
drwxr-x--- 3 vyatta users 4096 Feb  2 12:44 .
drwxr-xr-x 1 root   root  4096 Feb  2 11:57 ..
-rw------- 1 vyatta users  456 Feb  2 12:44 .bash_history
-rw-r--r-- 1 vyatta users    0 Feb  2 12:43 .bash_logout
-rw-r--r-- 1 vyatta users    0 Feb  2 12:43 .bashrc
-rw-r--r-- 1 vyatta users    0 Feb  2 12:43 .profile
drwxr-x--- 2 vyatta users 4096 Feb  2 11:57 .ssh

Tenga en cuenta que hay tres archivos de longitud cero, y por lo tanto no tienen configuración. Sin los mandatos para inicializar el entorno para el usuario de VRA en el inicio de sesión, el shell actual no puede interpretar los mandatos Vyatta que se emiten. Como consecuencia, debe obtener los dotfiles anteriores de un origen diferente.

Afortunadamente, el directorio home anterior todavía existe como directorio de persistencia, que permite copiar los archivos. Para ello, vaya a /lib/live/mount/persistence/sda2/boot y liste los directorios allí:

vyatta@acs-jmat-vyatta01:/lib/live/mount/persistence/sda2/boot$ ls -la
total 20
drwxr-xr-x 5 root root 4096 Feb  2 11:54 .
drwxr-xr-x 4 root root 4096 Nov 20 05:00 ..
drwxr-xr-x 4 root root 4096 Jan 23 11:30 5.2R5S3.06301309
drwxr-xr-x 4 root root 4096 Feb  2 11:54 5.2R6S5.01261706
drwxr-xr-x 5 root root 4096 Feb  2 11:54 grub

Los ISO de la instalación inicial y el sistema operativo que está ejecutando actualmente se muestran aquí.

Si realizó más de una actualización, se mostrarán aquí también.

A continuación, cambie de directorio utilizando el sistema operativo cargado anteriormente como el directorio siguiente y vaya al directorio principal de VRA:

vyatta@acs-jmat-vyatta01:cd 5.2R5S3.06301309/persistence/rw/home/vyatta/
vyatta@acs-jmat-vyatta01:/lib/live/mount/persistence/sda2/boot/5.2R5S3.06301309/persistence/rw/home/vyatta$ ls -la
total 343084
drwxr-x--- 3 vyatta users      4096 Jan 29 16:29 .
drwxr-xr-x 3 root   root       4096 Nov 20 05:05 ..
-rw------- 1 vyatta users     10537 Feb  2 11:55 .bash_history
-rw-r--r-- 1 vyatta users       220 Nov  5  2016 .bash_logout
-rw-r--r-- 1 vyatta users      3515 Nov  5  2016 .bashrc
-rw------- 1 vyatta users        53 Dec 25 10:45 .lesshst
-rw-r--r-- 1 vyatta users       675 Nov  5  2016 .profile
drwxr-x--- 3 vyatta users      4096 Jan  9 10:34 .ssh
-rw-r----- 1 vyatta users 351272960 Jan 26 14:23 vyatta-vrouter-5.2_20180126T1706-amd64.iso

Desde este directorio, puede ver los archivos dotfiles y copiarlos:

vyatta@acs-jmat-vyatta01:/lib/live/mount/persistence/sda2/boot/5.2R5S3.06301309/persistence/rw/home/vyatta$ cp .bashrc /home/vyatta
vyatta@acs-jmat-vyatta01:/lib/live/mount/persistence/sda2/boot/5.2R5S3.06301309/persistence/rw/home/vyatta$ cp .profile /home/vyatta
vyatta@acs-jmat-vyatta01:/lib/live/mount/persistence/sda2/boot/5.2R5S3.06301309/persistence/rw/home/vyatta$ cp .bash_logout /home/vyatta
vyatta@acs-jmat-vyatta01:/lib/live/mount/persistence/sda2/boot/5.2R5S3.06301309/persistence/rw/home/vyatta$ cd /home/vyatta
vyatta@acs-jmat-vyatta01:~$ ls -la
total 28
drwxr-x--- 3 vyatta users 4096 Feb  2 12:44 .
drwxr-xr-x 1 root   root  4096 Feb  2 11:57 ..
-rw------- 1 vyatta users  456 Feb  2 12:44 .bash_history
-rw-r--r-- 1 vyatta users  220 Feb  2 12:56 .bash_logout
-rw-r--r-- 1 vyatta users 3515 Feb  2 12:56 .bashrc
-rw-r--r-- 1 vyatta users  675 Feb  2 12:56 .profile
drwxr-x--- 2 vyatta users 4096 Feb  2 11:57 .ssh

Una vez que los archivos se han copiado, cierre la sesión y vuelva a iniciar la sesión:

[jmathews@shelladmindal0101 ~]$ ssh 10.115.174.6 -l vyatta
Welcome to AT&T vRouter

Welcome to AT&T vRouter
Version:      5.2R6S5
Description:  AT&T vRouter 5600 5.2R6S5
Last login: Fri Feb  2 12:57:29 2018 from 10.0.80.100
vyatta@acs-jmat-vyatta01:~$ show version
Version:      5.2R6S5
Description:  AT&T vRouter 5600 5.2R6S5
Built on:     Fri Jan 26 17:06:52 UTC 2018
System type:  Intel 64bit
Boot via:     image
HW model:     PIO-518D-TLN4F-ST031
HW S/N:       S14073214705613
HW UUID:      00000000-0000-0000-0000-0CC47A07EF22
Uptime:       12:57:47 up 59 min,  1 user,  load average: 0.35, 0.27, 0.26
vyatta@acs-jmat-vyatta01:~$

Ahora, todos los mandatos funcionan de nuevo y puede continuar con normalidad.

También puede fallar la copia del certificado HTTPS /etc/lighttpd/server.pem durante el proceso de actualización del sistema operativo, lo que puede provocar que no se puedan sincronizar las configuraciones de alta disponibilidad (HA). Para solucionar este problema, copie el archivo antiguo server.pem además de los archivos enumerados (emita su - para llegar al nivel raíz y, a continuación, emita el mandato copy) luego emita restart https para rearrancar el archivo demon.m HTTPS (y los archivos enumerados anteriormente).