Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

構成のコミット

設定モード コマンドを使用すると、デバイス設定の変更を設定データベースに保存し、デバイス commit で設定をアクティブ化できます。

設定のコミット モデルについて

デバイス設定はコミット モデルによって保存されます。つまり、受験者の設定は必要に応じて変更され、その後システムにコミットされます。構成がコミットされると、デバイスは構成の構文エラーをチェックし、エラーが見つからなかった場合は、設定をjuniper.conf.gz保存してアクティブ化します。以前のアクティブ構成ファイルは、最初のロールバック構成ファイル (juniper.conf.1.gz) として保存され、その他のロールバック構成ファイルは1ずつ増えていきます。たとえば、 juniper.conf.1.gzが増加しjuniper.conf.2.gz、2つ目のロールバック構成ファイルが作成されます。デバイスには、システムに保存される最大49個のロールバック構成 (番号 1 ~ 49) を設定できます。

デバイスでは、現在の設定ファイルと最初の 3 つのロールバック ファイル( juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3 )がディレクトリに存在 /config します。(残りのロールバック ファイル(4~49 件)は /var/db/config .

リカバリー設定ファイルが rescue.conf.gz システムに保存されている場合は、このファイルもディレクトリに保存する必要 /config があります。工場出荷時のデフォルトファイルは/etc/configディレクトリにあります。

デバイス内のルーティングエンジン間で設定を伝達するには、次の2つのメカニズムが使用されます。

  • Synchronization 1つのルーティングエンジンから、同じデバイスシャーシ内の2つ目のルーティングエンジンに構成を伝達します。

    構成を同期するにはcommit synchronize 、CLI コマンドを使用します。ルーティングエンジンのいずれかがロックされている場合、同期は失敗します。ロックされた設定ファイルによってcommit synchronize force同期が失敗した場合は、このコマンドを使用できます。このコマンドはロックをオーバーライドし、設定ファイルを同期します。

  • 配送マルチシャーシデバイス上でルーティングプレーン間で設定を伝達します。分散が自動的に行われます。ディストリビューションプロセスを制御するために使用できるユーザーコマンドはありません。構成の配布中に設定がロックされた場合、ロックした構成は分散された設定ファイルを受け取らないため、同期は失敗します。構成の前にロックを解除し、ルーティングプレーンを再同期する必要があります。

    注:

    マルチシャーシプラットフォームでcommit synchronize force CLI コマンドを使用した場合、設定ファイルの強制同期はルーティングプレーン全体の設定ファイルの配布に影響を与えません。コマンドが発行されたデバイスからのリモートデバイスで設定ファイルがロックされた場合、リモートデバイスでの同期は失敗します。ロックを解除して、コマンドをsynchronization再発行する必要があります。

デバイス設定のコミット

デバイス設定の変更を設定データベースに保存し、デバイスで設定をアクティブにするには、 設定モード コマンド commit を使用します。任意の階層レベルcommitからコマンドを発行できます。

このcommitコマンドを入力すると、最初にシンタックスエラー (commit check) がチェックされます。その後、構文が正しければ、設定がアクティブ化され、現在の運用デバイスの設定になります。

注:

ルーターでグレースフルルーティングエンジンスイッチオーバーが有効になっている場合、バックアップルーティングエンジンでコミット操作を実行することはお勧めできません。

設定コミットは、以下のいずれかの理由で失敗する可能性があります。

  • 構成に不正な構文が含まれているため、コミットチェックが失敗します。

  • コミットしようとしている受験者の設定は、700 MB を超えています。

  • この設定は、このconfigure exclusiveコマンドを入力したユーザーによってロックされます。

構成に構文エラーが含まれている場合は、エラーの場所を示すメッセージが表示され、構成はアクティブになりません。エラーメッセージの形式は次のとおりです。

たとえば、以下のように記述します。

設定を recommitting する前に、エラーを修正する必要があります。エラーが見つかった階層レベルにすばやく戻るには、エラーの最初の行からパスをコピーし、階層レベルの[edit]設定モードプロンプトに貼り付けます。

コミットされていない候補/var/rundb/juniper.db構成ファイルは、です。700 MB に制限されています。コミットがメッセージconfiguration database size limit exceededによって失敗した場合は、コマンドrun file list /var/rundb detailを入力して設定モードでファイルサイズを表示します。設定を簡素化し、ワイルドカードを使用して構成グループを作成したり、ファイアウォールフィルターで特定の一致しないポリシーを定義したりして、ファイルサイズを小さくすることができます。

注:

[edit interfaces]階層レベルでの設定変更に表示される CLI コミット時間警告は削除され、システムログメッセージとして記録されます。

これは、以下の階層レベルの VRRP 構成にも適用できます。

  • [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

構成をコミットすると、構成全体が現在の形式でコミットされます。

注:
  • デバイスでグレースフルルーティングエンジンスイッチオーバーが有効になっている場合、バックアップルーティングエンジンでコミット操作を実行することはお勧めできません。

  • 適切なルーティングエンジンスイッチオーバー (GRES) が有効になっているときfxp0ge-0/0/1、などの管理インターフェイスや内部インターフェイスに同じ IP アドレスを設定すると、CLI には、プライベートおよびパブリックインターフェイスで同じアドレスが検出されたことを示すコミットエラーメッセージが表示されます。このような場合は、重複するアドレスを持つ2つのインターフェイスに固有の IP アドレスを割り当てる必要があります。

複数のユーザーがソフトウェアを構成する場合のコミット操作

最大で32のユーザーが同時に設定モードになることができます。また、そのすべてが設定を変更することもできます。すべてのユーザーが行った変更をすべての編集者に表示できます。 — コマンドの最後にユーザーが Enter キーを押すとすぐに変更が表示され、 などの設定変更が行われたらすぐに変更が表示されます。 seteditdelete

設定を編集しているユーザーがcommitコマンドを実行すると、すべてのユーザーによるすべての変更がチェックされ、アクティブになります。

このconfigure privateコマンドを使用して設定モードにすると、各ユーザーは、他のユーザーから独立して編集するためのプライベート候補として設定されています。構成をコミットすると、独自の変更だけがコミットされます。他のユーザーがコミットした変更を適用した後で、構成のコピー updateを同期するには、設定モードでコマンドを実行します。また、コミット操作によって、プライベート候補のすべての構成も更新されます。たとえば、ユーザー X とユーザー Y がどちらもモードでconfigure privateあり、ユーザー x が設定変更をコミットしたとします。ユーザー Y が後続のコミット操作を実行し、その後で新しい構成を表示すると、ユーザー X が行った変更内容がその構成に含まれます。

設定モードとしてconfigure exclusiveコマンドを入力した場合は、設定モードが維持されている間、設定候補がロックされるため、他のユーザーの干渉なしに変更を加えることができます。他のユーザーは設定モードを入力して終了できますが、構成をコミットすることはできません。これは、他のユーザーがconfigure exclusiveコマンドを入力する前に設定モードにした場合にも該当します。たとえば、ユーザー X がすでにconfigure private or configureモードになっているとします。その後、ユーザー Y がconfigure exclusiveモードに入ったとします。ユーザー X は、ユーザーがログインする前に変更が行われていても、設定の変更をコミットできません。ユーザー Y が終了configure exclusiveモードになっている場合、ユーザー X はまたconfigure privateconfigureモードで行われた変更をコミットすることができます。

準備とアクティベーションのコミットの概要

Junos OS リリース 17.3 R1 以降、2つのステップでコミットプロセスを完了できます。この機能により、複数のデバイスを設定し、設定を同時にアクティブ化できます。Junos OS リリース 17.3 R1 より前では、コミットプロセスは1つのステップで完了しました。このようなコミットステージを分離する目的は、コミットがシステムに対して有効になるようにするための最適な時間ウィンドウを提供することです。コミットが準備された後にコミットモードに入ることができますが、コミットがアクティブ化待ちになっていることを通知するメッセージが表示されます。

準備段階と呼ばれる最初のステップでは、コミットが検証され、必要なファイルを含む新しいデータベースが生成されます。構成に構文エラーが含まれている場合は、適切なエラーメッセージが表示され、構成は準備されません。準備段階で障害が発生した場合は、エラーメッセージcommit check-out failedが表示されます。

2番目のステップでは、アクティブ化ステージと呼ばれ、以前に準備した構成がアクティブになります。次に、コマンドを使用clear system commit preparedして、準備された構成をクリアする必要がある場合に実行できます。保留中のコミットが正常に消去されると、ログメッセージが生成されます。

注:

準備段階とアクティブ化ステージの間で、コミット操作を実行することはできません。

この2段階のコミットプロセスは、時間が重要なコミットのためのシングルステッププロセスよりも優れています。シングルステッププロセスでは、準備にかかる時間はデバイスの既存の構成によって異なります。2段階のプロセスでは、複雑な準備作業がより効率的に処理されます。

設定コマンドを使用して、設定キャッシュを準備して構成をアクティブ化することができます。新しい設定でデバイスを準備し、それを正確なタイミングで有効にすることができます。

このcommit prepareコマンドは構成を検証し、 commit activateこのコマンドは構成をアクティブにします。これらのコマンドには、以下の設定オプションがあります。

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

commit prepareおよびcommit activateコマンドは、プライベート、排他、共有コミットでのみ使用できます。これらのコマンドは、動的モードと一時的な操作には適用されません。この機能はマルチシャーシデバイスに適用できますが、バッチコミットには適用されません。

ネットワーク構成プロトコル (NETCONF) を使用してこの機能をサポートするには、以下の新しいリモートプロシージャコール (Rpc) が用意されています。

  • <commit-configuration>< prepare/></commit-configuration>

  • <commit-configuration><activate/></commit-configuration>

  • <clear-system-commit><prepared/></clear-system-commit>

注:
  • MX シリーズバーチャルシャーシには、以下の設定が適用されます。スイッチcommit prepareオーバーの後、1つのルーティングエンジンに対して発行されると、オーバースイッチコマンドが発行されたルーティングエンジンが再起動します。そのため、そのルーティングエンジンで準備済みキャッシュはクリアされます。

  • 設定時MX シリーズ バーチャル シャーシ、VCプライマリでのみコマンド clear system commit prepared を実行する必要があります。

2 つのステップでデバイス設定をコミットする: 準備とアクティブ化

Junos OS リリース17.3 から始めて、2つのステップでコミットプロセスを完了できます。これにより、複数のデバイスを構成できるようになり、構成を同時にアクティブ化できます。準備段階と呼ばれる最初のステップでは、コミットが検証され、必要なファイルと共に新しいデータベースが生成されます。構成に構文エラーが含まれている場合は、適切なエラーメッセージが表示され、構成は準備されません。2番目のステップ (アクティブ化ステージと呼ばれる) では、すでに準備された構成がアクティブになり、現在の運用中のデバイス構成になります。

構成を準備するには、次のようにします。

  1. 構成モード[edit]の階層レベルで、設定に必要な変更を行います。

    たとえば、システムのスクリプトを設定するには、次のコマンドを実行します。

    たとえば、以下のように記述します。

  2. コマンドをcommit prepare発行します。

    メッセージcommit prepare successfulが表示されます。

    準備段階が失敗すると、エラーメッセージcommit check-out failedが表示されます。

  3. show system commitコマンドの出力を確認するにcommit prepareは、次のコマンドを使用します。

準備された構成をアクティブにするには

  1. commit activateコマンドを使用

    メッセージcommit completeが表示されます。

  2. アクティブ化されたシステム構成を確認するには、次のコマンドを使用します。

が発行された後show system commitcommit activateshow system commit revision detailおよびコマンドの出力を確認するには、以下のコマンドを発行します。

デバイス設定のアクティブ化が、確認が必要

現在の候補構成をコミットすると、コミットが永続的になるように、明示的な確認を求められるようになります。これは、構成の変更が正しく機能し、デバイスへのアクセスを妨げることがないことを確認する場合に便利です。変更によってアクセスが拒否されたり、その他のエラーが発生したりした場合、ルーターは自動的に以前の構成に戻り、ロールバックの確認タイムアウトが経過した後、アクセスを復元します。この機能は、自動ロールバックと呼ばれます。

現在の候補構成をコミットする一方で、コミットを永続的にするために明示的なcommit confirmed確認が必要になるようにするには、次のように設定モードコマンドを使用します。

変更が正しく機能確認したら、 または コマンドを 10 分以内に入力して新しい設定をアクティブ commitcommit checkcommit confirmed できます。たとえば、以下のように記述します。

特定の時間(デフォルトでは 10 分)でコミットが確認されなかった場合、オペレーティング システムは以前の設定に自動的にロール バックし、ログインしているすべてのユーザーにブロードキャスト メッセージが送信されます。

commit confirmed コマンドの後にロールバックがスケジュールされたことをshow system commit 表示するには、コマンドを入力します。たとえば、以下のように記述します。

commitコマンドと同様に、 commit confirmedこのコマンドは構成構文を確認し、エラーを報告します。エラーがない場合は、一時的に設定がアクティブになり (デフォルトでは10分)、デバイス上で実行が開始されます。

図 1: 構成の確認構成の確認

新しい構成を確認するまでの時間を変更するには、コマンドを発行する間隔を分単位で指定します。

設定モードで commit confirmed コマンドを [edit private] 使用することもできます。

コミット操作のスケジューリング

応募者の設定が有効になる時期をスケジュールできます。デバイス設定の変更を保存し、後でルーター上の設定をアクティブ化する、または再起動時に commit atreboot 、 [ edit ] 階層レベルで設定モード コマンドを使用し、

ここstringrebootは、構成の変更をアクティブにするには、以下のような時間がかかることになります。時刻は次の2つの形式で指定できます。

  • フォーム [ ] の時間値(時間、分、オプションで秒) — 設定モード コマンドが発行された日の午後 hh:mm:ss 11:59:59 以前に、指定した時刻に設定をコミットします。 commit at hh値に24時間の時間を使用します。たとえば、 04:30:00 4:30:00 AM、 20:00 8:00 PM になります。この時間は、ルーターのクロックとタイムゾーンの設定に関して解釈されます。

  • [] という形式の日付と時刻の値(年、月、日付、時間、分、および(オプションで、秒 yyyy-mm-dd hh:mm:ss ))—コマンドが発行された後の必要がある指定した日時に設定をコミットします。 commit at hh値に24時間の時間を使用します。たとえば 2018-08-2112:30:00 、2018 年 8 月 21 日の午後 12 時 30 分です。  この時間は、ルーターのクロックとタイムゾーンの設定に関して解釈されます。

値はstring引用符 ("") で囲みます。たとえば、 commit at "18:00:00"のようになります。日付と時刻については、同じ引用符のセットに両方の値を含めます。例えばcommit at "2018-03-10 14:00:00".

commit at設定モードコマンドを発行すると、直ちにコミットチェックが実行されます。チェックの結果が成功した場合、現在のユーザーは設定モードからログオフされ、構成データは読み取り専用の状態のままになります。スケジュールされたコミットが完了するまで、その他のコミットは実行できません。

注:

設定の変更がアクティブになる前にデバイス ソフトウェアに障害が発生すると、すべての設定変更が失われます。

コマンドを発行commit at した後に、設定コマンドを入力することはできません。 request system reboot

今後特定の時刻request system rebootにコミット操作をスケジュールした場合、このコマンドを入力することはできません。

スケジュールされたコミットが保留中の場合、設定をコミットすることはできません。コマンドによってスケジュールされた設定をキャンセルする方法について、詳しくは explorer clearをCLIしてください

注:

デバイスでグレースフルルーティングエンジンスイッチオーバーが有効になっている場合、バックアップルーティングエンジンでコミット操作を実行することはお勧めできません。

コミット プロセスの監視

デバイス設定コミット プロセスを監視するには、 display detail コマンドでパイプの後に コマンドを使用 commit します。

たとえば、以下のように記述します。

コミットされた構成について説明するコメントを追加する

コミットされた設定の変更について説明するコメントを含めることができます。これを行うには、 ステートメントを含 commit comment める必要があります。コメントには512バイトまでの長さを指定でき、1行に入力する必要があります。

comment-string コメントのテキストです。

注:

commit check コマンドにコメントを含めることはできません。

commitコマンドにコメントを追加するには、コマンドcommentcommit後にステートメントを指定します。

commit confirmedコマンドにコメントを追加するには、コマンドcommentcommit confirmed後にステートメントを指定します。

これらのコミットコメントを表示するにshow system commitは、運用モードコマンドを発行します。

注:

Junos OS リリース11.4 から始めて、 commit confirmed[edit private]設定モードでこのコマンドを使用することもできます。

一括コミットの概要

複数のセッションまたはユーザーからの複数の設定編集CLI一括コミットまたはマージし、それらを一括コミット キューに追加します。デバイスで実行されるバッチコミットサーバーは、1つ以上のジョブをバッチコミットキューから取得し、設定の変更を共有構成データベースに適用してから、1回のコミット操作で設定の変更をコミットします。

バッチは、ユーザーによって指定されたバッチの優先度またはバッチジョブが追加された時刻に基づいて、コミットサーバーによって優先度が決定されます。バッチのコミットが1回完了すると、次の構成変更セットが集約され、バッチコミット操作の次のセッションのためにバッチキューに読み込まれるようになります。キューディレクトリにコミットエントリが残っていない限り、バッチが作成されます。

すべてのコミットが個別にコミットされる通常のコミット操作と比較した場合、バッチコミットは、1回のコミット操作で複数の小さい構成編集をコミットすることで、時間とシステムリソースを節約します。

バッチコミットは、 [edit batch]設定モードから実行されます。コミットサーバーのプロパティは、 [edit system commit server]階層レベルで設定できます。

アグリゲーションとエラー処理

集約されたジョブの1つでロード時エラーが発生すると、エラーが発生したコミットジョブが破棄され、残りのジョブが集約され、コミット済みになります。

commit-1たとえば、5つのコミットジョブ (、 commit-2commit-3、、 commit-4、、 commit-5) が集約されていcommit-3て、読み込み中にエラー commit-3が発生しcommit-1commit-2場合commit-4は、 commit-5破棄されていることを示しています。

2つ以上のジョブの集約とコミットが実行されているときに、コミット操作中にエラーが発生した場合、アグリゲーションは破棄され、定期的なコミット操作と同様に各ジョブが個別にコミットされます。

たとえば、集約された5つのコミットcommit-1ジョブcommit-2( commit-3commit-4、、 commit-5commit-3および) がある場合に、その原因としてコミットエラーが発生した場合commit-1commit-2アグリゲーションcommit-3commit-4破棄さcommit-5れ、、、、、が個別にコミットされcommit-3、CLI が for commit エラーを報告します。

例:バッチコミットサーバーのプロパティの設定

この例では、バッチコミットサーバーのプロパティを設定してバッチのコミット操作を管理する方法について説明します。

要件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • MX シリーズ 5G ユニバーサル ルーティング プラットフォーム

  • デバイスで Junos OS リリース12.1 以降を実行している場合

概要

サーバーのプロパティを[edit system commit server]階層レベルで構成することによって、コミットサーバーによるバッチコミットキューの処理方法を制御できます。これにより、1回のバッチコミットに集約またはマージされるコミットジョブ数、キューに追加可能な最大ジョブ数、バッチコミットエラーログを保持する日数、バッチに対する操作を追跡するための期間を制御できます。運用をコミットします。

構成

CLI クイック構成

例のこのセクションを迅速に構成するには、以下のコマンドをコピーして、テキストファイルに貼り付け、改行を削除し、ネットワーク構成に一致する必要がある詳細を変更してから CLI [edit]にコマンドをコピーして貼り付けてください。階層レベル。コミットサーバーのプロパティは、通常[edit]モードと[edit batch]モードのどちらかで設定できます。

デバイス R0

コミットサーバーのプロパティの設定

順を追った手順
  1. ナ1回のコミット操作で集計またはマージするコミットトランザクション数を設定します。

    maximum-aggregate-poolデフォルト値は5です。

    注:

    maximum-aggregate-poolジョブ1を個別にコミットするように設定します。

    この例では、コミット操作が開始される前4に、4つの異なるコミットジョブを1つのコミットに集約することを示すために、commit トランザクションの数が設定されています。

  2. ナ1つのバッチで許可されるジョブ数の上限を設定します。

    これにより、キューに追加するコミットジョブの数が制限されます。

    注:

    maximum-entries1設定した場合、コミットサーバーは1つ以上のジョブをキューに追加できず、複数のジョブをコミットしようとすると、CLI が適切なメッセージを表示します。

  3. ナ次のバッチコミット操作が開始されるまで待機する時間を秒単位で設定します。

  4. ナエラーログを保持する日数を設定します。

    デフォルト値は30日です。

  5. ナバッチコミットイベントをログに記録するように、トレース操作を構成します。

    この例では、ロギングバッチのコミットイベントのファイルcommitd_nov名が、すべての traceoption フラグが設定されています。

結果

設定モードから、 show system commit serverコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

バッチ設定モードでの設定のコミット

順を追った手順

構成を[edit batch]モードからコミットするには、以下のいずれかを実行します。

  • デバイスにログインして、をcommit入力します。

  • バッチのコミットジョブにより高い優先度を割り当てるにはcommitpriorityオプションを使用してコマンドを発行します。

  • 構成の変更を、キュー内の他のコミットジョブと統合せずに構成をcommitコミットするにatomicは、オプションを使用してコマンドを発行します。

  • キューにある他のコミットジョブと設定の変更を収集せずに設定をコミットし、より高い優先度をコミットジョブにcommit発行するにatomic priorityは、このオプションを使用してコマンドを発行します。

検証

構成が正常に機能していることを確認します。

バッチコミットサーバーのステータスを確認しています

目的

バッチコミットサーバーのステータスを確認します。

アクション

デフォルトでは、コミットサーバーのステータスはにNot runningなっています。コミットサーバーは、バッチコミットジョブがキューに追加された場合にのみ実行を開始します。

バッチコミットジョブがキューに追加されると、コミットサーバーのステータスがにRunning変わります。

このJobs in processフィールドには、処理中のジョブのコミット id が表示されます。

バッチコミットステータスを確認しています

目的

コミットサーバーのキューをチェックして、バッチコミットのステータスを確認します。

アクション

Pending commitsコミットキューに追加されるコミットジョブが表示されますが、まだコミットされていません。Completed commits成功したコミットジョブのリストを表示します。Error commitsエラーが原因で失敗したコミットです。

バッチコミットジョブでのパッチファイルの表示

目的

タイムスタンプ、パッチファイル、各コミットジョブのステータスを表示します。修正プログラムファイルは、バッチコミットキューに追加される各コミット操作で発生する設定の変更を示しています。

アクション
  1. すべてのshow system commit server queue patchコミット操作のパッチを表示するには、このコマンドを使用します。

    この出力は、各コミットジョブ ID の構成の変更を示しています。

  2. 特定のコミットジョブ ID のパッチを表示するには、 show system commit server queue patch id <id-number>コマンドを発行します。

この出力は、コミットジョブ用に作成されたパッチを示しています。Or +-記号は、特定のコミットジョブの構成の変更を示します。

バッチコミット操作用のトレースファイルの表示

目的

バッチコミット操作用のトレースファイルを表示します。トラブルシューティングを目的として、トレースファイルを使用することができます。

アクション
  • このfile show /var/log/<filename>コマンドを使用して、ログファイルのすべてのエントリを表示します。

    この出力には、コミットサーバーのイベントログとバッチコミットのためのその他のログが表示されます。

  • バッチのコミット操作を成功させるためだけにログエントリfile show /var/log/<filename>を表示する| match committedには、パイプオプションを使用してコマンドを発行します。

    この出力は、コミット操作を成功させるためのバッチコミットジョブ Id を示しています。

  • 失敗したバッチコミット操作のみのログエントリを表示するfile show /var/log/<filename>には、 | match “Error while”パイプオプションを使用してコマンドを発行します。

    この出力は、失敗したコミット操作のコミットジョブ Id を示しています。

  • コミットサーバーイベントについてのみログエントリを表示するfile show /var/log/<filename>には、 | match “commit server”パイプオプションを使用してコマンドを発行します。

    この出力は、コミットサーバーのイベントログを示しています。

代替ブートドライブのコミットされた構成のバックアップ

構成を確定し、それが正常に実行されていることを確認しrequest system snapshotたら、新しいソフトウェアをバックアップするコマンドを/altconfigファイルシステムに発行する必要があります。このrequest system snapshotコマンドを発行しないと、代替ブートドライブの設定がプライマリブートドライブの設定と同期されなくなります。

このrequest system snapshotコマンドを実行する/altrootと、ルートファイルシステムが/config/altconfig、およびにバックアップされます。ルート システムとファイル システムはルーターのフラッシュ ドライブに、ファイル システムはルーターのハード ディスクに(使用可能な場合) /config/altroot/altconfig オンです。

このrequest system snapshotコマンドを発行した後は、ソフトウェアの稼働しているコピーとバックアップが同一であるため、以前のバージョンのソフトウェアに戻ることはできません。