前バージョンへの復帰

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 コンソールで機能しない場合は、デバイスが工場出荷時のリセット状態になっている可能性があります。 この問題の原因となる可能性のあるシナリオが少なくとも 2 つあります。

まず、アップグレード・プロセス中に構成の保存を求めるプロンプトが出されたときに、**「はい」ではなく「いいえ」を選択した可能性があります。 この問題を修正するには、以前に使用していたユーザーとしてログインし、リブートします。 その後、前のセクションで概説した 2 つの方法のいずれかを使用して、前のバージョンに戻します。 その後、アップグレード手順を再度実行できます。今回は、必ず「はい」**を選択して構成を保存してください。

2 番目の可能性は、アップグレード先のバージョンがサポートしていない古い行が構成ファイルにあることです。 これは通常バグであり、サポート・ケースを作成することによって報告する必要があります。

この問題を修正するには、IPMI リモート・コンソールからユーザー vyatta としてパスワード vyatta を使用してログインします。 linux/bash find コマンドを実行して VRA ファイル・システム内の最新の config.boot ファイルを見つけ、そのファイルに対して merge コマンドを実行して、アップグレード中に構成の問題の原因を見つけます。 デフォルトの vyatta ユーザーとパスワードが機能しない場合は、上記の「前のバージョンに戻す」で説明されているプロセスを使用して、パスワード・リカバリー・オプションを選択し、Vyatta ユーザーのパスワードをリセットします。 アクセスできるようになったら、最新の config.boot ファイルを見つけてマージします。 使用する config.boot ファイルが見つからない場合は、ネットワークとシステムへの SSH アクセスを取得するために、インターフェース、静的経路、および SSH ポートを手動で構成できます。 これにより、マージするバックアップ構成ファイル (または scp) をコピーして貼り付けることができます。 通常の Vyatta コマンド ( configure など) を実行して構成モードに入ることができない場合は、 bash コマンドを実行して、使用可能なシェルにアクセスしてみてください。

以下の例は、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

構成モードを使用して、上記の例の最新のconfig.bootファイルのいずれかを指定してmergeコマンドまたはloadコマンドを実行してから、コミットします。 エラーには問題の原因が示されるため、無効な構成を削除し、必要に応じて有効な構成を追加する必要があります。 コミットが成功し、Vyatta が以前の動作状態に戻るまで、このプロセスを繰り返し、すべての問題を解決します。

更新を試行する前に、これらのデバイスで同じ変更を行うことにより、このプロセスを繰り返すことなく他の VRA をアップグレードできます。 アップグレードを実行する前にこれらの問題を修正すると、後続の更新が機能するようになります。

このプロセス中に見つかったすべてのバグをサポート・ケースを開いて報告し、ベンダーが今後のリリースでこれらの問題を修正できるようにします。

ディスクの問題に対処する

ディスクが破損している場合、ファームウェアのアップグレードが正常に完了しない可能性があります。 ハードウェアのエラーメッセージがないか確認するか、ディスクの健全性を確認します。 この問題を修正するには、 fsck コマンドを使用してファイルシステムチェックを実行してください。 また、起動プロセス中にファイルシステムチェックが実行されるため、ディスクの問題を解決するために再起動することもできます。

1801 から 1912 へのアップグレード

1801 から 1912 へのアップグレード時に、以下の一般的な問題が発生することがあります。

多くの Bash コマンドが機能しなくなりました

バージョン1912では、 user-isolation と呼ばれるセキュリティ機能がデフォルトで有効化され、 Debianへのアクセスコマンドが制限されたシェルセッションが作成されるようになりました。 これを修正するには、構成内の行 set system login user-isolation disable をコミットしてから、再度ログインします。

3 つのロケーションを含むタイム・ゾーンの問題

アメリカ/ケンタッキー州/モンティチェロなどの 3 つのロケーションを含むタイム・ゾーンは、アップグレードの完全な失敗の原因となる可能性があります。その結果、VRA は工場出荷時リセット状態になります。 この問題を修正するには、タイム・ゾーンを 2 つのロケーションのみを持つタイム・ゾーンに設定します。

この問題 (VRVDR-52825) は、バージョン 1912g で修正されました。

1 ではなく 0 で始まるポート範囲

ポート範囲を 1 ではなく 0 で開始するように構成すると、アップグレードが完全に失敗し、VRA が工場出荷時リセット状態になる可能性があります。 これを修正するには、ポート範囲を 0 ではなく 1 から開始するように変更し、アップグレード・プロセスを再度実行します。

この問題 (VRVDR-52668) は、バージョン 1912g で修正されました。

config-sync の失敗

VRAバージョン1908の新機能により、バージョン1912までに、 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

`config-sync`に`vyatta`以外のユーザーを使用する場合は、必ずそのユーザーをシークレット・グループに追加してください。

1912 から 2012 へのアップグレード

1912 から 2012 にアップグレードするときに、以下の一般的な問題が発生することがあります。

2012 に更新する前に AES-NI を有効にする必要があります

デフォルトでは、2014 以降の一部の古い BIOS バージョンでは AES-NI が無効になっています。 IPsec の問題、および VRRP と config-sync の問題は、AES-NI が無効になった結果である可能性があります。 これを修正するには、2012 にアップグレードする前に、VRA のシステム・ボード BIOS のクラウド・ポータルを使用してファームウェア更新を実行します。

リブートまたはフェイルオーバー後に IPsec トンネルが開始していません

Vyatta 5400の run-transition-scripts コマンドは、2012年のリリースノートに記載されているように、非推奨となりました。 代わりに、Vyatta 5600 のためにそのコマンドを置き換えた VRA 構成ファイル内の 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

この問題は、バージョン 2012kで修正されました。 バージョン 2012k 以降に更新してください。

Vyatta のフェイルオーバー後に、Netscaler VPX を介したトラフィックがダウンする

Vyatta で VRRP フェイルオーバーが発生すると、新しい VRRP 1 次は GARP を送信します。 仕様として、 NetScaler VPX は GARP を受信すると、GARP を使用して ARP 表を更新するのではなく、ARP 要求を送信して検証します。 Netscaler VPX 上の特定の IP アドレスの ARP を手動でクリアすることは、一時的な回避策です。

この問題は2012m で修正されました。

SNMP メモリー・リークによるメモリー不足 (OOM)

SNMP のメモリー・リークによる OOM の問題が原因で、異常終了および障害が発生することがあります。

この問題は2012m で修正されました。

u/u 状況の 2 次 Vyatta 上の GRE トンネル・インターフェース

バージョン 2012 以降、2 次 Vyatta の State と Link の両方の状況について、GRE トンネルの状況が永続的にアップになります。 GRE トンネルのローカル IP がアクティブ・インターフェース上にある場合、そのトンネル (tun) インターフェース上のパケットの送信 (TX) と受信 (RX) を許可します。 GRE トンネルの local-ip が非アクティブなインターフェース (2 次 Vyatta の VRRP インターフェースなど) にある場合、Vyatta はそのトンネル・インターフェースでのパケットの送受信を許可しません (そのインターフェースは保持されます)。

2012 に更新する前に、高可用性 GRE セットアップでアクティブ/パッシブ BGP を使用している場合は、GRE インターフェースの local-ip が、 dp0bond0 または dp0bond1 インターフェースで構成されたメイン・アドレスではなく、VRRP 仮想アドレスに設定されていることを確認してください。 また、ルーティングがトンネル (tun) インターフェースの状況を、フェイルオーバー時に A/D または u/u に変更することに依存していないことも確認する必要があります。これは、この状況が発生しなくなるためです。 このような場合、 IBM は、リモート GRE エンドポイントのパス・モニター・ポリシーをセットアップすることを推奨する場合があります。 これは、 ping ヘルス・チェックを使用して、トンネルのルーティング・テーブルに経路を追加する前に、そのトンネルを通るパスを検証します。 構成について質問がある場合、またはパス・モニター・ポリシーについてさらに情報が必要な場合は、 サポート Case を開きます。

1801から2012へのアップグレード

前述の 1801 から 1912 および 1912 から 2012 までのすべての問題に加えて、1801 から 2012 へのアップグレード時に特定の問題が発生する可能性があります。 更新後、Vyatta はブートしますが、構成は消去されます。 この問題に対処するには、予防措置として (および更新前に) タイム・ゾーンを「UTC」に設定します。 1801 年の一部のタイム・ゾーンは 2012 年に機能しないため、問題が発生している可能性があります。 例えば、1801 年には、2012 年にタイム・ゾーンが「America/Chicago」ではなく「Americas/Chicago」としてリストされます。

Intel X540 での 2204 の問題

Intel X540 シリーズ NIC を使用する Vyatta ゲートウェイ・アプライアンスでは、少なくともバージョン 2204e および場合によっては 2204fで VRRP の問題が発生していました。 2204gでは、これらの問題を修正する必要があります。 この更新の時点で、 2204g イメージは、約 1 カ月間、クラウド・テスト環境でサポートによってテストおよび実行されています。 これまでの唯一の問題は、クラスターが異なるバージョンで実行され、connsync (config-sync とは異なる) が有効になっている (デフォルトで無効になっている) 場合に、2 次デバイスの VRRP インターフェースに最終的に障害が発生するというエッジ・ケースです。

lspci | grep Eth コマンドは、Vyatta 上の NIC のタイプを表示します。

2012 から 2204 へのアップグレード

2204e以降、これら 2 つのメジャー・リリース間で更新を行っても既知の問題はありません。 一般的な問題が判明した場合は、ここで公開されます。 セキュリティー修正および修正された問題は、引き続き Ciena Vyatta 資料の Web サイトおよび Vyatta ソフトウェア・パッチ のページで公開されます。

5.2 より古いアップグレードでの Vbash の問題

Vyatta OS の新バージョンを正常にアップグレードしてリブートした後、ユーザー・コマンドを実行できないという問題が発生することがあります。

以下に例を示します。

[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ディレクトリー・スペースがあり、構成に表示されるすべてのユーザーはホーム・ディレクトリーを再生成する必要があります。 このエラーは、必要な「dotfiles」を 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

3 つのファイルの長さがゼロであり、したがって構成を含んでいないことに注目してください。 ログイン時に VRA ユーザーの環境を初期化するコマンドがないと、現行シェルは発行される Vyatta コマンドを解釈できません。 結果として、別のソースから古い dotfiles を取得する必要があります。

幸い、以前の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 と、現在実行中の OS について説明します。

複数のアップグレードを行った場合は、それらもここに表示されます。

次に、前にロードした OS を次のディレクトリーとして使用してディレクトリーを変更し、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

このディレクトリーから、dotfile を表示してコピーすることができます。

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

これで、すべてのコマンドが再び機能するようになり、正常に処理を進めることができます。

OS アップグレード処理中に HTTPS 証明書 /etc/lighttpd/server.pem のコピーも失敗することがあり、それが原因で高可用性 (HA) 構成の同期化が失敗する可能性があります。 この問題を修正するには、リストされたファイルに加えて、古い server.pem ファイルをコピーし (su - を実行してルート・レベルに移動してから、copy コマンドを実行します)、その後、restart https を実行して HTTPS demon.m ファイル (および上記のリストされたファイル) を再始動します。