还原到先前版本

要将 VRA 还原为先前版本，请根据您的情况执行下列其中一项操作:

• 如果可以使用 IPMI 控制台或 SSH 访问 VRA，请使用 Vyatta CLI 命令设置缺省引导映像，然后重新引导。 这会将 VRA 重新引导到所选版本。 例如：

  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
  

• 如果无法使用 SSH 或 IPMI 控制台访问 VRA，请重新引导设备，然后在引导期间按 Esc 键以到达 Grub 引导菜单。 选择您想要还原到的版本。

  您还可以使用 Grub 引导菜单来恢复 Vyatta 用户的密码。

如果 VRA 处于出厂重置状态

如果 VRA 在更新后变为不可访问，并且您的密码在 IPMI 控制台中不起作用，那么该设备很可能处于出厂重置状态。 至少有两种方案会导致此问题。

首先，在升级过程中提示您保存配置时，可能选择了 否 而不是 是。 要解决此问题，请以您先前拥有的用户身份登录，然后重新引导。 在此之后，请使用上一节中概述的两种方法之一来还原为先前版本。 然后，您可以再次执行升级过程，这次确保选择 是 以保存配置。

第二种可能是配置文件中存在您要升级到的版本不支持的旧行。 这通常是一个错误，应该通过创建 支持案例 来报告。

您可以通过使用密码 vyatta 从 IPMI 远程控制台以用户 vyatta 身份登录来解决此问题。 通过运行 linux/bash find 命令在 VRA 文件系统中查找最新的 config.boot 文件，然后对该文件运行 merge 命令以查找在升级期间导致配置问题的原因。 如果缺省 vyatta 用户和密码不起作用，请使用上述“还原到先前版本”中描述的过程来选择密码恢复选项并重置 Vyatta 用户的密码。 获取访问权后，查找并合并最新的 config.boot 文件。 如果找不到要使用的 config.boot 文件，那么可以手动配置接口，静态路由和 SSH 端口以获取对系统的网络和 SSH 访问权。 这将允许您复制并粘贴要合并的备份配置文件 (或 scp)。 如果无法运行常规 Vyatta 命令 (例如 configure) 以进入“配置”方式，请尝试运行 bash 命令以访问可用 shell。

以下示例说明了从 1801ze 更新到 1912f时的问题。 请注意，即使在升级之后，find 命令也会拉取在文件系统中归档的 4 config.boot 文件。 要使用 find 命令，请使用 su 命令将用户更改为 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

使用“配置”方式，运行 merge 或 load 命令，指定上述示例中的一个最新 config.boot 文件，然后落实。 这些错误将显示问题的原因，因此您应该删除任何无效配置并根据需要添加有效配置。 重复此过程并解决所有问题，直到落实成功并且 Vyatta 恢复到其先前的工作状态为止。

您可以升级其他 VRA，而不必在尝试更新之前通过在这些设备上进行相同的更改来重复此过程。 在运行升级之前修正这些问题将允许后续更新起作用。

通过打开 支持案例 来报告在此过程中发现的所有错误，以便供应商可以在以后的发行版中解决这些问题。

解决磁盘问题

如果磁盘损坏，固件升级可能无法成功完成。 检查硬件错误信息或检查磁盘的健康状况。 要解决这个问题，请使用 fsck 命令运行文件系统检查。 您也可以重启以解决磁盘问题，因为在启动过程中会运行文件系统检查。

从 1801 升级到 1912

从 1801 升级到 1912 时，您可能会迂到以下常见问题:

许多 Bash 命令不再工作

通过 V1912，缺省情况下启用了名为 user-isolation 的安全功能，这将创建一个 shell 会话，其中用于访问底层 Debian 系统的命令受到限制。 要解决此问题，请落实配置中的行 set system login user-isolation disable，然后重新登录。

包含 3 位置的时区存在问题

包含 3 位置的时区 (例如，America/Kentucky/Monticello) 可能会导致升级完全失败，这将导致 VRA 进入出厂重置条件。 要解决此问题，请将时区设置为仅具有 2 个位置的时区。

此问题 VRVDR-52825 在 V 1912g中已修正。

以 0 (而不是 1) 开头的端口范围

如果将端口范围配置为以 0 而不是 1 开头，那么可能会导致升级完全失败，这将导致 VRA 进入出厂重置条件。 要解决此问题，请更改端口范围以从 1 (而不是 0) 开始，然后再次执行升级过程。

此问题 VRVDR-52668 在 V 1912g中已修正。

配置同步失败

根据 VRA V1908 到 V1912 的新功能，config-sync 已重写为使用 netconf。 如果没有新配置，那么尝试落实时将看到以下错误:

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

要解决此问题，请确保添加以下配置，以便 config-sync 继续工作:

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

如果将不同于 vyatta 的用户用于 config-sync，请确保将该用户添加到密钥组中。

从 1912 年升级到 2012 年

从 1912 升级到 2012 时，您可能会迂到以下常见问题:

必须先启用 AES-NI，然后才能更新到 2012 年

缺省情况下，2014 年的某些旧 BIOS 版本将禁用 AES-NI。 IPsec 问题以及 VRRP 和 config-sync 问题可能是禁用 AES-NI 的结果。 要解决此问题，请在升级到 2012 之前使用云门户网站对 VRA 的主板 BIOS 运行固件更新。

IPsec 隧道在重新引导或故障转移后不会启动

如 2012 年发行说明所述，不推荐使用 Vyatta 5400 的 run-transition-scripts 命令。 请改为使用 VRA 配置文件中替换 Vyatta 5600 的该命令的 notify ipsec configuration 行。

此问题也可能是由于未启用 AES-NI (根据先前的问题) 而导致的。

此示例说明旧版本:

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

切换到此类型的配置，确保与正确的外部接口和 vrrp-group 匹配:

set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec

多个 IPsec 隧道发生故障

VRA 版本 2012h 和更低版本有一个错误，其中存在许多 IPsec 隧道时发生故障。 发生此情况时，将在 IPsec 和系统日志中发生类似于以下内容的错误:

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

此问题在 V 2012k中已修正。 更新为 V 2012k 或更高版本。

Vyatta 故障转移后，通过 Netscaler VPX 的流量会停止

在 Vyatta 上发生 VRRP 故障转移时，新的 VRRP 主节点将发送 GARP。 作为规范，当 NetScaler VPX 接收到 GARP 时，它会发送 ARP 请求以进行验证，而不是使用 GARP 来更新 ARP 表。 手动清除 Netscaler VPX 上特定 IP 地址的 ARP 是临时变通方法。

此问题在 V 2012m中已修正。

由于 SNMP 内存泄漏而导致内存不足 (OOM)

由于 SNMP 的内存泄漏，OOM 问题可能导致崩溃和中断。

此问题在 V 2012m中已修正。

处于 u/u 状态的辅助 Vyatta 上的 GRE 隧道接口

从 2012 版开始，对于辅助 Vyatta 上的 State 和 Link 状态，GRE 隧道状态将永久启动。 如果 GRE 隧道的本地 IP 位于活动接口上，那么它将允许在该隧道 (tun) 接口上传输 (TX) 和接收 (RX) 包。 如果 GRE 隧道的 local-ip 位于不活动接口 (例如辅助 Vyatta 的 VRRP 接口) 上，那么 Vyatta 将不允许在该隧道接口上传输和接收包 (并且将使该接口保持运行状态)。

在更新到 2012 年之前，如果您具有基于高可用性 GRE 设置的主动/被动 BGP，请确保确认 GRE 接口已 local-ip 设置为 VRRP 虚拟地址，而不是 dp0bond0 或 dp0bond1 接口上配置的主地址。 您还应该验证路由是否不依赖于隧道 (tun) 接口在故障转移时将状态更改为 A/D 或 u/u，因为这将不再发生。 在这些情况下，IBM 可能建议为远程 GRE 端点设置路径监视策略。 这将利用 ping 运行状况检查来验证隧道上的路径，然后再将路径添加到该隧道的路由表。 如果您对配置有疑问或需要有关路径监视策略的更多信息，请打开 支持案例。

从 1801 升级到 2012

与先前列出的 1801 到 1912 以及 1912 到 2012 的所有问题一样，您在从 1801 升级到 2012 时可能会迂到特定问题。 更新后，Vyatta 会引导，但会擦除配置。 要处理此问题，请作为预防措施 (在更新之前) 将时区设置为 "UTC"。 从 1801 年开始的一些时区在 2012 年不起作用，这可能是造成问题的原因。 例如，在 1801 年，时区被列为“美国/芝加哥”，而不是 2012 年的“美国/芝加哥”。

2204 Intel X540 问题

使用 Intel X540 系列 NIC 的 Vyatta 网关设备至少在版本 2204e 以及可能在 2204f上迂到 VRRP 问题。 从 2204g起，应解决这些问题。 截至此更新，2204g 映像已由支持人员在云测试环境中进行了大约一个月的测试和运行。 到目前为止，唯一的问题是辅助设备的 VRRP 接口最终发生故障的边缘情况，如果两个集群都在不同版本上运行，并且已启用 connsync (不同于 config-sync) (缺省情况下禁用)。

lspci | grep Eth 命令显示 Vyatta 上 NIC 的类型。

从 2012 年升级到 2204

从 2204e开始，在这两个主要发行版之间进行更新时没有已知问题。 如果发现任何常见问题，将在此处发布这些问题。 将继续在 Ciena Vyatta 文档 Web 站点和 Vyatta 软件补丁 页面上发布安全修订和修复问题。

较旧的 5.2 升级中的 Vbash 问题

有时，在成功升级并重启新版Vyatta操作系统后，您可能会遇到无法发出用户命令的问题。

例如：

[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

对于这种情况，问题不在升级本身。 如果在升级过程中发生错误，那么发出 add system image 命令时会看到这些错误。 在这种情况下，设备重新启动，但此时 /home 目录空间为空，且配置中出现的任何用户都需要重新生成其主目录。 错误的根源在于未能将所需的“dot 文件”正确复制到 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

请注意，有三个文件的长度为零，因此说明这些文件不包含配置。 如果在登录时未通过命令为 VRA 用户初始化环境，那么当前 shell 无法解释您发出的 Vyatta 命令。 因此，您必须从其他来源获取旧的 dot 文件。

幸运的是，以前的 home 目录仍然存在，作为持久性目录，您可以将文件复制过去。 请发送邮件至 /lib/live/mount/persistence/sda2/boot，并在邮件中列出目录：

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

此处提供了初始安装的 ISO 以及当前正在运行的操作系统。

如果您进行了多次升级，这些也会显示在这里。

接下来，使用之前加载的操作系统作为下一个目录，更改目录，进入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

你可以从这个目录中看到这些点文件，并复制过来：

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

复制文件后，注销，然后重新登录:

[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:~$

现在，您的所有命令都可以正常执行了，您可以继续正常操作了。

在操作系统升级过程中 HTTPS /etc/lighttpd/server.pem 也可能无法复制，从而导致高可用性（HA）配置无法同步。 要解决这个问题，除了列出的文件外，还要复制旧的 server.pem 文件（发送 su - 到达根级别，然后发送 copy 命令），然后发送 restart https 重新启动 HTTPS demon.m 文件（以及之前列出的文件）。