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つのメカニズムが使用されます:

  • 同期:あるルーティング・エンジンから、同じデバイス・シャーシ内の2番目のルーティング・エンジンにコンフィギュレーションを伝播させます。

    コンフィギュレーションを同期させるには、というCcommit synchronizeLIコマンドを使用します。ルーティング・エンジンの1つがロックされている場合、同期に失敗します。コンフィギュレーション・ファイルがロックされているために同期に失敗した場合、commit synchronize forceというコマンドを使用することができます。このコマンドはロックを無効にし、コンフィギュレーション・ファイルを同期させます。

  • 配信:マルチシャーシ・デバイスのルーティング・プレーン全体にコンフィギュレーションを伝搬します。配信は自動的に行われます。配信処理を制御するためのユーザー・コマンドは用意されていません。コンフィギュレーションの配信中にコンフィギュレーションがロックされた場合、ロックされたコンフィギュレーションは配信されたコンフィギュレーション・ファイルを受け取らないため、同期に失敗します。コンフィギュレーションの前にロックを解除し,ルーティング・プレーンを再同期させる必要があります。

    注:

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

デバイス・コンフィグレーションのコミット

デバイス・コンフィギュレーションの変更をコンフィグレーション・データベースに保存し、デバイス上でコンフィグレーションを有効にするには、commitというコンフィギュレーション・モード・コマンドを使用します。どの階層からでもコマcommitンドを発行することができます:

commitというコマンドを入力すると、まずコンフィギュレーションにシンタックスエラー(commit check)がないかチェックされます。その後、シンタックスが正しければ、コンフィギュレーションが有効になり、現在動作しているデバイスのコンフィギュレーションとなります。

注:

ルータでGraceful Routing Engine Switchoverが有効な場合、バックアップのルーティング・エンジンにコミット操作を行うことはお勧めしません。

コンフィギュレーション・コミットは、以下のいずれかの理由で失敗することがあります:

  • コンフィギュレーションに不正なシンタックスが含まれているため、コミット・チェックに失敗します。

  • コミットしようとしている候補コンフィギュレーションは、700MBより大きくなります。

  • というコマconfigure exclusiveンドを入力したユーザーによってコンフィギュレーションがロックされています。

コンフィギュレーションにシンタックス・エラーが含まれている場合、エラーのロケーションを示すメッセージが表示され、コンフィギュレーションは有効になりません。エラーメッセージの形式は以下の通りです:

たとえば、以下のように表示されます。

コンフィギュレーションを再実行する前に、エラーを修正する必要があります。エラーが発生した階層レベルに素早く戻るには、エラーの1行目からパスをコピーし、そのパスをという階[edit]層レベルのコンフィギュレーション・モード・プロンプトに貼り付けてください。

コミットされていない、候補のコンフィギュレーション・ファイルは、/var/rundb/juniper.dbです。700MBに制限されています。コミットに失敗して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]

コンフィギュレーションをコミットすると、現在の形式でコンフィギュレーション全体がコミットされます。

注:
  • Graceful Routing Engine Switchoverが有効なデバイスでは、バックアップのルーティング・エンジンにコミット操作を行うことはお勧めしません。

  • Graceful Routing Engine Switchover(GRES)を有効にした場合、fxp0という管理インタフェースまたは内部インタフェースおよびge-0/0/1という外部物理インタフェースに、同じIPアドレスを設定すると,プライベート・インタフェースとパブリック・インタフェースに同じアドレスが見つかったという適切なコミット・エラー・メッセージがCLIに表示されます。このような場合、アドレスが重複している2つのインターフェースに一意のIPアドレスを割り当てる必要があります。

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

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

設定を編集しているユーザーのいずれかがcommitコマンドを発行すると、CLI はすべてのユーザーによるすべての変更をチェックして有効にします。

そのconfigure privateコマンドで設定モードに入ると、各ユーザーはプライベートな候補設定を持ち、他のユーザーとは多少独立して編集することができます。設定をコミットすると、CLI は自己の変更のみをコミットします。他のユーザーが変更をコミットした後に自分の設定のコピーを同期させるには、設定モードでそのupdateコマンドを実行します。また、コミット操作は、すべてのプライベート候補の設定を更新します。例えば、ユーザー X とユーザー Y がともにconfigure privateモードで、ユーザー X が設定変更をコミットしたとします。ユーザー Y が後続のコミット操作を行い、新しい設定を表示した場合、ユーザー Y が見る新しい設定には、ユーザー X が行った変更が含まれています。

そのconfigure exclusiveコマンドで設定モードに入ると、設定モードにいる限り、候補の設定がロックされます。これにより、他のユーザーの干渉を受けずに変更を行うことができます。他のユーザーは設定モードに入ったり出たりすることはできますが、設定をコミットすることはできません。これは、そのconfigure exclusiveコマンドを入力する前に、他のユーザーが設定モードに入っていても同様です。例えば、ユーザー X がすでにconfigure privateまたはconfigureモードに入っているとします。その後、ユーザー Y がそのconfigure exclusiveモードに入ったとします。ユーザー Y がログインする前にユーザー X が設定変更を入力したとしても、ユーザー X は設定変更をコミットできません。ユーザー Y がconfigure exclusiveモードを終了すると、ユーザー X はconfigure privateモードやconfigureモードで行った変更をコミットすることができます。

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

2 つのステップでコミット作業を完了させることができます。二段階のコミット機能で、複数のデバイスを設定し、同時に設定を有効にすることができます。二段階のコミットでは、コミットがシステム上で有効である明確な時間を表示するウィンドウを準備します。コミットが準備された後に、コミット・モードを入力することができますが、その際には、コミットがアクティベーションを保留しているというメッセージが表示されます。

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

第 2 の段階であるアクティベーションステージでは、先に準備された設定を有効にします。次に、準備した設定をクリアする必要があります。その方法は、そのコマclear system commit preparedンドを使用して行うことができます。保留中のコミットのクリアに成功したすると、ログメッセージが作成されます。

注:

準備段階とアクティベーション段階では、コミット操作を実行することはできません。

タイムクリティカルなコミットでは、シングルステップのプロセスよりも、二段階コミットプロセスのほうが優れています。シングルステップのプロセスでは、デバイス上の既存の設定に応じて、準備時間が変わる可能性があります。二段階のプロセスでは、複雑な準備作業をより効率的に処理することができます。

設定キャッシュの準備や設定のアクティブ化を行うための、設定コマンドが用意されています。新しい設定でデバイスを準備し、必要なタイミングでアクティブ化することができます。

この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 シリーズの仮想シャーシ設定では、以下のような適用されます:1 つのルーティングエンジンでcommit prepareが発行された後、スイッチオーバーする場合、スイッチオーバーのコマンドを発行したルーティングエンジンが再起動します。そのため、そのルーティングエンジンでは、準備されたキャッシュはクリアされます。

  • MX シリーズの仮想シャーシの設定では、clear system commit preparedコマンドをVCプライマリでのみ実行することをお勧めします。

2 つのステップでデバイスの設定をコミットします。準備と起動

2 つのステップでコミット作業を完了させることができます。これにより、複数の機器を設定することができ、設定した内容を同時に起動することができます。準備段階と呼ばれる最初のステップでは、コミットを検証し、必要なファイルとともに新しいデータベースを生成する。設定に構文エラーが含まれている場合は、適切なエラーメッセージが表示され、設定は準備されません。第 2 段階は、起動段階と呼ばれ、事前に準備されたコンフィギュレーションが起動され、現在の動作可能なデバイス コンフィギュレーションとなる。

コンフィギュレーションを準備するため。

  1. コンフィギュレーションモードの[edit]階層レベルで、コンフィギュレーションに必要な変更を行う。

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

    たとえば、以下のように表示されます。

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

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

    準備段階が失敗した場合は、エラーメッセージが表示commit check-out failedされます。

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

用意したコンフィギュレーションを有効にする。

  1. コマcommit activateンドを使用する

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

  2. 起動したシステム構成を確認するには、次のコマンドを使用します。

commit activate発行後のshow system commitshow system commit revision detailコマンドの出力を確認するために、以下のコマンドを発行します。

確認しながら、機器構成を有効化

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

現在の候補構成をコミットしますが、コミットを恒久的なものにするために明示的な確認を必要とする場合は、commit confirmed設定モードコマンドを使用します。

変更が正しく機能することを確認したら、コマンドから 10 分以内にコcommit confirmedマンドcommitまたはコマcommit checkンドを入力することで、新しい設定を有効な状態に維持することができますたとえば、以下のように表示されます。

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

このcommit confirmed コマンドの後にロールバックが予定されている場合を表示するには、show system commit コマンドを入力します。たとえば、以下のように表示されます。

そのコマcommitンドと同様に、コマンドcommit confirmedは設定構文を検証し、エラーを報告します。エラーがなければ、設定が一時的に(デフォルトでは 10 分)有効化され、デバイス上で動作を開始します。

図 1: 設定を確認設定を確認

新しい設定を確認する前に、時間の長さを変更するには、コマンドを発行する際に分数を指定します。

また、のコンフィ[edit private]グレーションモードでcommit confirmedンドを使用することも可能です。

コミット操作のスケジュール

候補の設定をいつアクティブにするかをスケジュールすることができます。rebootデバイスの設定変更を保存し、将来の時刻にまたは再起動時にその設定をデバイス上で有効にするには、commit at設定モードコマンドを使用し、または将来の時刻を [edit] 階層レベルで指定します。

string は、設定変更を有効にするための rebootまたは将来の時刻です。時間を 2 つのフォーマットで指定できます:

  • commit at 形式の時間値 hh:mm[:ss] (時、分、場合によっては秒)—設定モードコマンドが発行された日の午後 11 時 59 分 59 秒より前の将来である必要があります。hh04:30:00 そのの値には 24 時間制を採用しています。例えば、は午前 4 時 30 分 00 秒、は午後 8 時 00 分 20:00です。時間は、ルーターの時計とタイムゾーンの設定を基準にして解釈されます。

  • 形式の日付と時刻の値 yyyy-mm-dd hh:mm[:ss] (年、月、日付、時間、分、場合によっては秒)—指定された日時に設定をコミットします。commit at コマンドを発行した後でなければなりません。そのhhの値には 24 時間表示を使用します。例えば、2018-08-21 12:30:00 は 2018 年 8 月 21 日時点で午後 12:30 です。時間は、ルーターの時計とタイムゾーンの設定を基準にして解釈されます。

そのstringの値を引用符(「」)で囲みます。例えば、commit at "18:00:00"。日付と時刻については、両方の値を同じ引用符で囲みます。例えば、commit at "2018-03-10 14:00:00".

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

注:

設定変更が有効になる前にデバイスソフトウェアが故障すると、設定変更はすべて失われます。

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

将来的な特定の時間にコミット操作をスケジュールすると、そのrequest system rebootコマンドを入力できなくなります。

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

注:

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

コミット プロセスを監視

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

たとえば、以下のように表示されます。

コミットされたコンフィギュレーションを説明するコメントを追加する

コミットされた設定に対する変更点を説明するコメントを含めることができます。そのためには、commit commentの文言を入れる。コメントは512バイトまで可能で、1行で入力する必要があります。

comment-string121はコメント本文です。

注:

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

コマcommitンドにコメントを追加するには、コマcommitンドの後にステートcommentメントを含めます。

コマcommit confirmedンドにコメントを追加するには、コマcommit confirmedンドの後にステートcommentメントを含めます。

これらのコミットメントを表示するには、show system commitオペレーションモードコマンドを実行します。

注:

また、のコンフィ[edit private]グレーションモードでcommit confirmedンドを使用することも可能です。

バッチコミットの概要

バッチコミットは、異なる CLI セッションまたはユーザーによる複数の設定編集を集約またはマージし、バッチコミットキューに追加します。デバイス上で動作するバッチコミットサーバーは、バッチコミットキューから 1 つまたは複数のジョブを受け取り、設定変更を共有設定データベースに適用した後、1 回のコミット操作で設定変更をコミットします。

ユーザーが指定したバッチの優先順位や、バッチジョブが追加された時刻に基づいて、コミットサーバーがバッチの優先順位を決定します。1 つのバッチコミットが完了した場合、次の設定変更のセットが集約され、バッチコミット操作の次のセッションのために、バッチキューに装備されます。バッチは、キューディレクトリーにコミットエントリーが残らなくなるまで作成されます。

すべてのコミットが独立して順次コミットされる通常のコミット操作と比較して、バッチコミットは、複数の小さな設定編集を 1 回のコミット操作でコミットすることにより、時間とシステムリソースを節約します。

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

集約とエラー処理

集約されたジョブの 1 つにロード時間のエラーが発生した場合、エラーが発生したコミットジョブは破棄され、残りのジョブが集約されてコミットされます。

例えば、5 つのコミットジョブ(commit-1commit-2commit-3commit-4、およびcommit-5)が集約され、commit-3には、ロード時のエラーが発生し、commit-3が破棄され、commit-1commit-2commit-4commit-5が集約、コミットされます。

2 つ以上のジョブを集約してコミットする際に、コミット操作でエラーが発生した場合、集約は破棄され、それらの各ジョブは通常のコミット操作と同様に個別にコミットされます。

例えば、5 つのコミットジョブ(commit-1commit-2commit-3commit-4、およびcommit-5)が集約され、commit-3が原因でコミットエラーが発生した場合、その集約は破棄され、commit-1commit-2commit-3commit-4、およびcommit-5が個別にコミットされ、CLI はcommit-3のコミットエラーを報告します。

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

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

要件

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

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

概要

[edit system commit server] 階層レベルでサーバーのプロパティを設定することで、コミット サーバーによるバッチ コミット キューの処理方法を制御することができます。これにより、1 つのバッチ コミットに集約またはマージされるコミット ジョブの数、キューに追加できるジョブの最大数、バッチ コミット エラー ログを保持する日数、2 つのバッチ コミットの間隔、バッチ コミット操作のトレース操作を制御することができます。

設定

CLIクイック構成

この例のセクションをすばやく設定するには、次のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit] 階層レベルの CLI にコマンドをコピーして貼り付けます。コミット サーバーのプロパティは、通常の [edit] モードと [edit batch] モードのどちらからでも設定可能です。

デバイスR0

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

ステップバイステップでの手順
  1. (オプション)1 つのコミット操作で集約またはマージするコミット トランザクションの数を設定します。

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

    注:

    maximum-aggregate-pool1 に設定すると、各ジョブが個別にコミットされます。

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

  2. (オプション)バッチで許可されるジョブの最大数を設定します。

    これは、キューに追加されるコミット ジョブの数を制限するものです。

    注:

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

  3. (オプション)次のバッチ コミット操作を開始するまでの時間(秒単位)を設定します。

  4. (オプション)エラー ログを保存する日数を設定します。

    初期値は 30 日です。

  5. (オプション)バッチ コミット イベントを記録するためのトレース操作を設定します。

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

結果

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

バッチ コンフィグレーション モードからコンフィグレーションをコミットする

ステップバイステップでの手順

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

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

  • バッチ コミット ジョブに高い優先度を割り当てるには、 コマcommitンドを オpriorityプション付きで実行します。

  • キュー内の他のコミット ジョブと構成の変更を集約せずにコミットするには、 コマcommitンドを オatomicプション付きで実行します。

  • キュー内の他のコミット ジョブとコンフィグレーションの変更を集約せず、コミット ジョブに高い優先度を発行するには、atomic priority オプションを付けて commit コマンドを実行します。

検証

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

バッチ コミット サーバーの状態を確認する

目的

バッチ コミット サーバーの状態を確認します。

対処

デフォルトでは、コミット サーバーのステータスは 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> コマンドを実行します。

意味

コミット ジョブ用に作成されたパッチが出力されます。+ または - の記号は、特定のコミット ジョブに対する設定の変更を示します。

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

目的

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

対処
  • ログ ファイルのすべてのエントリーを表示するには、 コマ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 コマンドを発行すると、実行中のソフトウェアとバックアップコピーが同一になるため、以前のバージョンに戻すことはできません。