設定をコミット
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番目のルーティング・エンジンにコンフィギュレーションを伝播させます。
コンフィギュレーションを同期させるには、
commit synchronize
CLI コマンドを使用します。ルーティング・エンジンの1つがロックされている場合、同期に失敗します。コンフィギュレーション・ファイルがロックされているために同期に失敗した場合は、commit synchronize force
コマンドを使用できます。このコマンドはロックを無効にし、コンフィギュレーション・ファイルを同期させます。-
ディストリビューション:マルチシャーシ・デバイスのルーティング・プレーン全体にコンフィギュレーションを伝搬します。配信は自動的に行われます。配信処理を制御するためのユーザー・コマンドは用意されていません。コンフィギュレーションの配信中にコンフィギュレーションがロックされた場合、ロックされたコンフィギュレーションは配信されたコンフィギュレーション・ファイルを受け取らないため、同期に失敗します。コンフィギュレーションの前にロックを解除し、ルーティング・プレーンを再同期させる必要があります。
手記:マルチシャーシ・プラットフォームで
commit synchronize force
CLI コマンドを使用する場合、コンフィギュレーション・ファイルの強制同期がルーティング・プレーン全体のコンフィギュレーション・ファイルの配信に影響することはありません。コマンドを発行したデバイスから離れたデバイス上で、コンフィギュレーション・ファイルがロックされている場合、離れたデバイスでの同期に失敗します。ロックを解除して、synchronization
コマンドを再発行する必要があります。手記:Junos OS Evolvedは、以下の
commit
設定オプションをサポートしていません。-
fast-synchronize
-
peers
-
peer-synchronize
-
commit-synchronize-server
-
デバイス・コンフィグレーションのコミット
デバイス・コンフィギュレーションの変更をコンフィグレーション・データベースに保存し、デバイス上でコンフィグレーションを有効にするには、 commit
というコンフィギュレーション・モード・コマンドを使用します。 commit
コマンドは、どの階層レベルからでも発行することができます。
[edit]
user@host# commit
commit complete
[edit]
user@host#
commit
コマンドを入力すると、まずコンフィギュレーションにシンタックスエラー(commit check
)がないかチェックされます。その後、シンタックスが正しければ、コンフィギュレーションが有効になり、現在動作しているデバイスのコンフィギュレーションとなります。
ルータでグレースフルルーティングエンジンスイッチオーバーが有効になっている場合、バックアップのルーティングエンジンでコミット操作を実行することはお勧めしません。
コンフィギュレーションのコミットは、以下のいずれかの理由で失敗することがあります:
-
コンフィギュレーションに不正なシンタックスが含まれているため、コミット・チェックに失敗します。
-
コミットしようとしている候補コンフィギュレーションは、700MBより大きくなります。
-
configure exclusive
コマンドを入力したユーザーによってコンフィギュレーションがロックされています。
コンフィギュレーションにシンタックス・エラーが含まれている場合、エラーのロケーションを示すメッセージが表示され、コンフィギュレーションは有効になりません。エラーメッセージの形式は以下の通りです。
[editedit-path
] ‘offending-statement
;’error-message
例えば:
[edit firewall filter login-allowed term allowed from] ‘icmp-type [ echo-request echo-reply ];’ keyword ‘echo-reply’ unrecognized
コンフィギュレーションを再実行する前に、エラーを修正する必要があります。エラーが発生した階層レベルに素早く戻るには、エラーの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]
コンフィギュレーションをコミットすると、現在の形式でコンフィギュレーション全体がコミットされます。
-
デバイスで グレースフルルーティングエンジンスイッチオーバー が有効になっている場合、バックアップのルーティングエンジン上でコミット操作を実行することはお勧めません。
-
グレースフル ルーティング エンジン スイッチオーバー(GRES)を有効にした場合、管理インターフェイスまたは
re0:mgmt-0
などの内部インターフェイスとxe-0/0/1
などの外部物理インターフェイスに同じ IP アドレスを設定すると、プライベート インターフェイスとパブリック インターフェイスに同じアドレスが見つかったという適切なコミット エラー メッセージが CLI に表示されます。このような場合、アドレスが重複している2つのインターフェースに一意のIPアドレスを割り当てる必要があります。
複数のユーザーがソフトウェアを設定する場合のコミット操作
最大 32 人のユーザーが同時に設定モードで設定を変更することができます。すべてのユーザーによる変更はすべて、構成を編集しているすべてのユーザーに表示されます。 set
、 edit
、 delete
など、構成を変更するコマンドの最後にある 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>
準備とアクティベーションの2つのステップでデバイス設定をコミットします
2 つのステップでコミット作業を完了させることができます。これにより、複数の機器を設定することができ、その設定を同時にアクティブにすることができます。準備段階と呼ばれる最初のステップでは、コミットが検証され、必要なファイルとともに新しいデータベースが生成されます。設定に構文エラーが含まれている場合は、適切なエラーメッセージが表示され、設定は準備されません。第 2 段階は、起動段階と呼ばれ、事前に準備されたコンフィギュレーションが起動され、現在の動作可能なデバイス コンフィギュレーションとなる。
コンフィギュレーションを準備するには:
準備した設定を有効にするには:
commit activate
コマンドを使用する[edit] user@host#
commit activate
メッセージ
commit complete
が表示されます。起動したシステム構成を確認するには、次のコマンドを使用します。
user@host>
show configuration system scripts
language python;
commit activate
発行後の show system commit
コマンドおよび show system commit revision detail
コマンドの出力を確認するには、次のコマンドを発行します。
user@host> show system commit
0 2018-07-12 22:54:46 PDT by user via cli commit activate
user@host> show system commit revision detail
Revision: re0-1499925285-2214
User : user
Client : cli
Time : 2018-07-12 22:54:46 PDT
Comment : commit activate
確認付きのデバイス設定のアクティブ化
現在の候補構成をコミットする場合、コミットを恒久的なものにするための明示的な確認を要求することができます。これは、設定変更が正しく機能し、デバイスへのアクセスが妨げられないことを確認したい場合に便利です。変更によってアクセスができなくなったり、その他のエラーが発生した場合は、ロールバック設定タイムアウトが経過した後、デバイスは自動的に以前の設定に戻り、アクセスが回復します。この機能を自動ロールバックといいます。
現在の候補構成をコミットしますが、コミットを恒久的なものにするために明示的な確認を必要とする場合は、 commit confirmed
設定モードコマンドを使用します。
[edit]
user@host# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
#commit confirmed will be rolled back in 10 minutes
[edit]
user@host#
変更が正しく機能することを確認したら、commit confirmed
コマンドから 10 分以内に commit
コマンドまたは commit check
コマンドを入力することで、新しい設定を有効な状態に維持することができます。例えば:
[edit]
user@host# commit check
configuration check succeeds
一定時間(デフォルトでは 10 分)以内にコミットが確認されない場合、オペレーティングシステムは自動的に以前の設定にロールバックし、ログインしているすべてのユーザーにブロードキャストメッセージが送信されます。
commit confirmed
コマンドの実行後にロールバックが予定されている場合を表示するには、show system commit
コマンドを入力します。例えば:
user@host>show system commit
0 2018-01-05 15:00:37 PST by root via cli commit confirmed, rollback in 3mins
commit
コマンドと同様に、commit confirmed
コマンドは設定構文を検証し、エラーを報告します。エラーがなければ、設定が一時的に(デフォルトでは 10 分)有効化され、デバイス上で動作を開始します。

新しい設定を確認する前に、時間の長さを変更するには、コマンドを発行する際に分数を指定します。
[edit]
user@host# commit confirmed minutes
commit complete
[edit]
user@host#
また、[edit private]
コンフィギュレーション モードで commit confirmed
コマンドを使用することもできます。
コミット操作のスケジュール
候補の設定をいつアクティブにするかをスケジュールすることができます。デバイスの設定変更を保存し、将来の時刻にまたは再起動時にその設定をデバイス上で有効にするには、commit at
設定モード コマンドを使用し、[edit
] 階層レベルでreboot
または将来の時刻を指定します。
[edit]
user@host # commit at string
string
は、 reboot
、または将来の時刻で、設定変更を有効にします。時間を次の 2 つの形式で指定できます。
hh
:
mm
[:
ss
](時、分、場合によっては秒)形式の時間値—commit at
設定モードコマンドが発行された日の午後 11 時 59 分 59 秒より前の将来である必要があります。hh
の値には 24 時間制を採用しています。たとえば、04:30:00
は午前 4 時 30 分 00 秒、20:00
は午後 8 時 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
"1
8:00:00
"
。日付と時刻については、両方の値を同じ引用符で囲みます。例えばcommit at "2018-03-10 14:00:00".
commit at
設定モード コマンドを発行すると、コミット チェックがすぐに実行されます。チェックの結果が成功した場合、現在のユーザーは設定モードからログアウトされ、設定データは読み取り専用の状態になります。スケジュールされたコミットが完了するまで、他のコミットは実行できません。
設定変更が有効になる前にデバイスソフトウェアが故障すると、設定変更はすべて失われます。
request system reboot
コマンドを発行した後に commit at
configuration コマンドを入力することはできません。
将来的な特定の時間にコミット操作をスケジュールすると、その request system reboot
コマンドを入力できなくなります。
スケジュールされたコミットが保留されているときは、設定をコミットできません。 clear
コマンドを使用してスケジュールされた設定をキャンセルする方法については、 CLI Explorer を参照してください。
デバイスでグレースフルルーティングエンジンスイッチオーバーが有効になっている場合、バックアップのルーティングエンジン上でコミット操作を実行することはお勧めません。
コミット プロセスを監視
デバイス・コンフィギュレーションのコミット・プロセスを監視するには、commit
コマンドでパイプの後に display detail
コマンドを使用します。
user@host# commit | display detail
例えば:
[edit]
user@host# commit | display detail
2021-10-08 10:33:42.619908 PDT: Obtaining lock for commit
2021-10-08 10:42:36.341266 PDT: Obtaining lock for commit
2021-10-08 10:42:36.343401 PDT: updating commit revision
2021-10-08 10:42:36.343639 PDT: UI extensions feature is not configured
2021-10-08 10:42:36.343718 PDT: UI change-notification feature is not configured
2021-10-08 10:42:36.343877 PDT: Started running translation script
2021-10-08 10:42:36.398596 PDT: No delta input for translation
2021-10-08 10:42:36.398679 PDT: Finished running translation script
2021-10-08 10:42:36.398904 PDT: start loading commit script changes
2021-10-08 10:42:36.398944 PDT: no commit script changes
2021-10-08 10:42:36.399006 PDT: no transient commit script changes
2021-10-08 10:42:36.399046 PDT: finished loading commit script changes
2021-10-08 10:42:36.399091 PDT: No translation output from the scripts
2021-10-08 10:42:36.400007 PDT: building groups inheritance path proportional in
candidate db
2021-10-08 10:42:36.400074 PDT: finished groups inheritance path
2021-10-08 10:42:36.400112 PDT: copying juniper.db to juniper.data+
2021-10-08 10:42:36.402278 PDT: finished copying juniper.db to juniper.data+
2021-10-08 10:42:36.402357 PDT: exporting juniper.conf
2021-10-08 10:42:36.404504 PDT: expanding interface-ranges
2021-10-08 10:42:36.404566 PDT: finished expanding interface-ranges
2021-10-08 10:42:36.404598 PDT: setup foreign files
2021-10-08 10:42:36.411776 PDT: propagating foreign files
2021-10-08 10:42:36.411824 PDT: Sending constraint check command to evaluate con
straints
2021-10-08 10:42:36.580667 PDT: constraints passed in mustd - not checking const
raints in propagation
2021-10-08 10:42:36.586908 PDT: complete foreign files
2021-10-08 10:42:36.663944 PDT: Forking child for configd-streamer operation
2021-10-08 10:42:36.666585 PDT: dropping unchanged foreign files
2021-10-08 10:42:36.666768 PDT: start ffp propagate
2021-10-08 10:42:36.855945 PDT: propagate stp-portid-ffp
2021-10-08 10:42:37.120224 PDT: propagate stp-portid-ffp done
2021-10-08 10:42:37.120447 PDT: propagate interface-alias-ffp
2021-10-08 10:42:37.464777 PDT: propagate interface-alias-ffp done
2021-10-08 10:42:37.467692 PDT: finish ffp propagate
2021-10-08 10:42:37.467826 PDT: Sending command to evaluate validation hooks
2021-10-08 10:42:37.471143 PDT: daemons checking new configuration
2021-10-08 10:42:37.761146 PDT: Collecting status of mustd hooks validation, sta
tus 0
2021-10-08 10:42:37.761273 PDT: commit wrapup...
2021-10-08 10:42:37.761519 PDT: Checking status of configd-streamer child before
ffp activate
2021-10-08 10:42:37.761562 PDT: ev.ops+ file generated successfully
2021-10-08 10:42:37.761635 PDT: start ffp activate
2021-10-08 10:42:37.938324 PDT: activate stp-portid-ffp
2021-10-08 10:42:38.181781 PDT: activate stp-portid-ffp done
2021-10-08 10:42:38.181953 PDT: activate interface-alias-ffp
2021-10-08 10:42:38.373063 PDT: activate interface-alias-ffp done
2021-10-08 10:42:38.373125 PDT: activate hostname-ffp
2021-10-08 10:42:38.731220 PDT: activate hostname-ffp done
2021-10-08 10:42:38.731575 PDT: activate configd-ffp
2021-10-08 10:42:38.904529 PDT: activate configd-ffp done
2021-10-08 10:42:38.906425 PDT: activating '/var/etc/cosd.conf'
2021-10-08 10:42:38.906598 PDT: activating '/var/etc/pam.conf'
2021-10-08 10:42:38.906716 PDT: activating '/var/etc/pam_radius.conf'
2021-10-08 10:42:38.983913 PDT: activating '/var/etc/pam_tacplus.conf'
2021-10-08 10:42:38.984100 PDT: activating '/var/etc/issue'
2021-10-08 10:42:38.984202 PDT: activating '/var/etc/certs'
2021-10-08 10:42:38.991939 PDT: activating '/var/etc/motd'
2021-10-08 10:42:38.992178 PDT: activating '/var/etc/max-db-size-cfg'
2021-10-08 10:42:38.992267 PDT: activating '/var/etc/subs-mgmt-cfg'
2021-10-08 10:42:38.992342 PDT: activating '/var/etc/nc_notification'
2021-10-08 10:42:38.992464 PDT: activating '/var/etc/ephinst.conf'
2021-10-08 10:42:38.992557 PDT: activating '/var/etc/config-apps.txt'
2021-10-08 10:42:38.992674 PDT: executing foreign_commands
2021-10-08 10:42:38.992722 PDT: /bin/sh /etc/rc.ui ui_setup_users (sh)
2021-10-08 10:42:39.24126 PDT: not executing commit in cli_sysctl
2021-10-08 10:42:39.24234 PDT: finish ffp activate
2021-10-08 10:42:39.24278 PDT: db_groups_info_clear start
2021-10-08 10:42:39.419569 PDT: db_groups_info_clear done
2021-10-08 10:42:39.419653 PDT: activating '/var/rundb/juniper.data'
2021-10-08 10:42:40.14698 PDT: Rotate backup configs
2021-10-08 10:42:40.142039 PDT: ssync begins
2021-10-08 10:42:40.566324 PDT: ssync ends
2021-10-08 10:42:40.566392 PDT: ssync begins
2021-10-08 10:42:40.807541 PDT: ssync ends
2021-10-08 10:42:40.807608 PDT: notifying daemons of new configuration
2021-10-08 10:42:40.807804 PDT: ssync begins
2021-10-08 10:42:40.924440 PDT: ssync ends
2021-10-08 10:42:40.924630 PDT: mgd tracing: disabled
2021-10-08 10:42:40.924684 PDT: New database revision 're0-1633714956-29' and ol
d database revision 're0-1633714422-28'
2021-10-08 10:42:40.924709 PDT: commit complete
commit complete
コミットされたコンフィギュレーションを説明するコメントを追加する
コミットされた設定に対する変更点を説明するコメントを含めることができます。そのためには、 commit comment
ステートメントを含めます。コメントは512バイトまで可能で、1行で入力する必要があります。
[edit]
user@host# commit comment comment-string
comment-string
121はコメント本文です。
commit check
コマンドにコメントを含めることはできません。
commit
コマンドにコメントを追加するには、commit
コマンドの後に comment
ステートメントを含めます。
[edit]
user@host# commit comment "add user joe"
commit complete
[edit]
user@host#
commit confirmed
コマンドにコメントを追加するには、commit confirmed
コマンドの後に comment
ステートメントを含めます。
[edit]
user@host# commit confirmed comment "add customer to port 27"
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
[edit]
user@host#
これらのコミットコメントを表示するには、 show system commit
オペレーションモードコマンドを実行します。
また、[edit private]
コンフィギュレーション モードで commit confirmed
コマンドを使用することもできます。
Junos OSリリース24.2R1以降、Junos OSでは、コミットリクエストごとにコメントを発行する必要があります。これは、コミット時に複数のユーザーまたは管理者によって行われた変更を追跡するのに役立ちます。
commit
コマンドは、comment
引数なしでは実行されません。
コミットリクエストごとにコメントを追加するようにユーザーに強制するには、[edit system commit]
階層レベルで force-commit-log
オプションを設定します。
バッチコミットの概要
バッチコミットは、異なる CLI セッションまたはユーザーによる複数の設定編集を集約またはマージし、バッチコミットキューに追加します。デバイス上で動作するバッチコミットサーバーは、バッチコミットキューから 1 つまたは複数のジョブを受け取り、設定変更を共有設定データベースに適用した後、1 回のコミット操作で設定変更をコミットします。
ユーザーが指定したバッチの優先順位や、バッチジョブが追加された時刻に基づいて、コミットサーバーがバッチの優先順位を決定します。1 つのバッチコミットが完了した場合、次の設定変更のセットが集約され、バッチコミット操作の次のセッションのために、バッチキューにロードされます。バッチは、キューディレクトリーにコミットエントリーが残らなくなるまで作成されます。
すべてのコミットが独立して順次コミットされる通常のコミット操作と比較して、バッチコミットは、複数の小さな設定編集を 1 回のコミット操作でコミットすることにより、時間とシステムリソースを節約します。
バッチコミットは、 [edit batch]
設定モードから実行されます。コミット サーバーのプロパティは、 [edit system commit server]
階層レベルで設定できます。
集約とエラー処理
集約されたジョブの 1 つにロード時間のエラーが発生した場合、エラーが発生したコミットジョブは破棄され、残りのジョブが集約されてコミットされます。
例えば、5 つのコミット ジョブ(commit-1
、 commit-2
、 commit-3
、 commit-4
、 commit-5
)が集約されていて、 commit-3
でロード中にエラーが発生した場合、 commit-3
は破棄されて commit-1
、 commit-2
、 commit-4
、 commit-5
が集約されてコミットされます。
2 つ以上のジョブを集約してコミットする際に、コミット操作でエラーが発生した場合、集約は破棄され、それらの各ジョブは通常のコミット操作と同様に個別にコミットされます。
例えば、5 つのコミットジョブ(commit-1
、 commit-2
、 commit-3
、 commit-4
、および commit-5
)が集約され、 commit-3
が原因でコミットエラーが発生した場合、集約は破棄され、 commit-1
、 commit-2
、 commit-3
、 commit-4
、および commit-5
は個別にコミットされ、CLI は commit-3
のコミットエラーを報告します。
例: バッチ コミット サーバーのプロパティを設定する
この例では、バッチ コミット サーバーのプロパティを設定し、バッチ コミット操作を管理する方法を示します。
概要
[edit system commit server]
階層レベルでサーバーのプロパティを設定することで、コミット サーバーによるバッチ コミット キューの処理方法を制御することができます。これにより、1 つのバッチ コミットに集約またはマージされるコミット ジョブの数、キューに追加できるジョブの最大数、バッチ コミット エラー ログを保持する日数、2 つのバッチ コミットの間隔、バッチ コミット操作のトレース操作を制御することができます。
構成
CLIクイック構成
この例のセクションをすばやく設定するには、次のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、 [edit]
階層レベルの CLI にコマンドをコピーして貼り付けます。コミット サーバーのプロパティは、通常の [edit]
モードまたは [edit batch]
モードのどちらからでも設定できます。
デバイスR0
set system commit server maximum-aggregate-pool 4
set system commit server maximum-entries 500
set system commit server commit-interval 5
set system commit server days-to-keep-error-logs 30
set system commit server traceoptions file commitd_nov
set system commit server traceoptions flag all
コミット サーバーのプロパティを設定する
手順
-
(オプション)1 回のコミット操作で集約またはマージするコミット トランザクションの数を設定します。
maximum-aggregate-pool
のデフォルト値は5
です。手記:maximum-aggregate-pool
を1
に設定すると、各ジョブが個別にコミットされます。この例では、コミット トランザクションの数が
4
に設定されており、コミット操作が開始される前に 4 つの異なるコミット ジョブが 1 つのコミットに集約されることを示しています。[edit system commit server]
user@R0#set maximum-aggregate-pool 4
-
(オプション)バッチで許可されるジョブの最大数を構成します。
これは、キューに追加されるコミット ジョブの数を制限するものです。
[edit system commit server]
user@R0#set maximum-entries 500
手記:maximum-entries
を1
に設定すると、コミット サーバーは複数のジョブをキューに追加できず、複数のジョブをコミットしようとすると CLI に適切なメッセージが表示されます。 -
(オプション)次のバッチ コミット操作を開始するまでの時間(秒単位)を設定します。
[edit system commit server]
user@R0#set commit-interval 5
-
(オプション)エラー ログを保存する日数を設定します。
既定値は
30
日です。[edit system commit server]
user@R0#set days-to-keep-error-logs 30
-
(オプション)バッチ コミット イベントを記録するためのトレース操作を設定します。
この例では、バッチ コミット イベントのログを取るためのファイル名は
commitd_nov
で、すべての traceoption フラグが設定されています。[edit system commit server]
user@R0#set traceoptions commitd_nov
user@R0#set traceoptions flag all
業績
設定モードから、 show system commit server
コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@R0# show system commit server
maximum-aggregate-pool 4;
maximum-entries 500;
commit-interval 5;
days-to-keep-error-logs 30;
traceoptions {
file commitd_nov;
flag all;
}
バッチ設定モードからの設定のコミット
手順
[edit batch]
モードから設定をコミットするには、次のいずれかを実行します。
-
デバイスにログインし、「
commit
」と入力します。[edit batch]
user@R0#commit
Added to commit queue request-id: 1000 -
バッチ コミット ジョブに高い優先度を割り当てるには、
priority
オプションを付けてcommit
コマンドを実行します。[edit batch]
user@R0#commit priority
Added to commit queue request-id: 1001 -
キュー内の他のコミット ジョブと構成の変更を集約せずにコミットするには、
atomic
オプションを付けてcommit
コマンドを実行します。[edit batch]
user@R0#commit atomic
Added to commit queue request-id: 1002 -
キュー内の他のコミット ジョブとコンフィグレーションの変更を集約せず、コミット ジョブに高い優先度を発行するには、
atomic priority
オプションを付けてcommit
コマンドを実行します。[edit batch]
user@R0#commit atomic priority
Added to commit queue request-id: 1003
検証
設定が正常に機能していることを確認します。
バッチ コミット サーバーの状態を確認する
目的
バッチ コミット サーバーの状態を確認します。
アクション
user@R0> show system commit server
Commit server status : Not running
デフォルトでは、コミット サーバーのステータスは Not running
です。コミット サーバーは、バッチ コミット ジョブがキューに追加された時のみ実行を開始します。
バッチ コミット ジョブがキューに追加されると、コミット サーバーのステータスが Running
に変わります。
user@R0> show system commit server
Commit server status : Running
Jobs in process:
1003 1004 1005
意味
Jobs in process
フィールドには、処理中のジョブのコミット ID がリストされます。
バッチ コミット ステータスの確認
目的
コミット サーバーのキューで、バッチ コミットの状況を確認します。
アクション
user@R0> show system commit server queue
Pending commits:
Id: 1005
Last Modified: Tue Nov 1 23:56:43 2018
Completed commits:
Id: 1000
Last Modified: Tue Nov 1 22:46:43 2018
Status: Successfully committed 1000
Id: 1002
Last Modified: Tue Nov 1 22:50:35 2018
Status: Successfully committed 1002
Id: 1004
Last Modified: Tue Nov 1 22:51:48 2018
Status: Successfully committed 1004
Id: 1007
Last Modified: Wed Nov 2 01:08:04 2018
Status: Successfully committed 1007
Id: 1009
Last Modified: Wed Nov 2 01:16:45 2018
Status: Successfully committed 1009
Id: 1010
Last Modified: Wed Nov 2 01:19:25 2018
Status: Successfully committed 1010
Id: 1011
Last Modified: Wed Nov 2 01:28:16 2018
Status: Successfully committed 1011
Error commits:
Id: 1008
Last Modified: Wed Nov 2 01:08:18 2018
Status: Error while commiting 1008
意味
Pending commits
は、コミット キューに追加されていますが、まだコミットされていないコミット ジョブを表示します。 Completed commits
に、成功したコミット ジョブのリストが表示されます。 Error commits
は、エラーにより失敗したコミットです。
バッチ コミット ジョブのパッチ ファイルを表示する
目的
各コミット ジョブのタイムスタンプ、パッチ ファイル、ステータスを表示します。パッチ ファイルは、バッチ コミット キューに追加される各コミット操作で発生する設定変更を示します。
アクション
-
show system commit server queue patch
コマンドを使用すると、すべてのコミット操作のパッチが表示されます。user@R0>
show system commit server queue patch
Pending commits: none Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit groups] re1 { ... } + GRP-DHCP-POOL-NOACCESS { + access { + address-assignment { + pool <*> { + family inet { + dhcp-attributes { + maximum-lease-time 300; + grace-period 300; + domain-name verizon.net; + name-server { + 4.4.4.1; + 4.4.4.2; + } + } + } + } + } + } + } Id: 1002 Last Modified: Tue Nov 1 22:50:35 2018 Status: Successfully committed 1002 Patch: [edit] + snmp { + community abc; + } Id: 1010 Last Modified: Wed Nov 2 01:19:25 2018 Status: Successfully committed 1010 Patch: [edit system syslog] file test { ... } + file j { + any any; + } Error commits: Id: 1008 Last Modified: Wed Nov 2 01:08:18 2018 Status: Error while commiting 1008 Patch: [edit system] + radius-server { + 10.1.1.1 port 222; + }コミット ジョブ ID ごとの設定変更内容が出力されます。
-
特定のコミット ジョブ ID のパッチを表示するには、
show system commit server queue patch id <id-number>
コマンドを発行します。user@R0>
show system commit server queue patch id 1000
Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit system] + radius-server { + 192.168.69.162 secret teH.bTc/RVbPM; + 192.168.64.10 secret teH.bTc/RVbPM; + 192.168.60.52 secret teH.bTc/RVbPM; + 192.168.60.55 secret teH.bTc/RVbPM; + 192.168.4.240 secret teH.bTc/RVbPM; + }
意味
コミット ジョブ用に作成されたパッチが出力されます。 +
記号または -
記号は、特定のコミット ジョブに対する設定の変更を示します。
バッチ コミット操作のトレース ファイルを表示する
目的
バッチ コミット操作のトレース ファイルを表示します。トレース ファイルはトラブルシューティングのために使用することができます。
アクション
-
file show /var/log/<filename>
コマンドを使用して、ログ ファイルのすべてのエントリを表示します。user@R0>
file show/var/log/commitd_nov
バッチ コミット時のコミット サーバー イベント ログなどが出力されます。
Nov 1 22:46:43 Successfully committed 1000 Nov 1 22:46:43 pausing after commit for 0 seconds ... Nov 1 22:46:43 Done working on queue ... Nov 1 22:47:17 maximum-aggregate-pool = 5 Nov 1 22:47:17 maximum-entries= 0 Nov 1 22:47:17 asynchronous-prompt = no Nov 1 22:47:17 commit-interval = 0 Nov 1 22:47:17 days-to-keep-error-logs = -1 ... Nov 1 22:47:17 Added to commit queue request-id: 1001 Nov 1 22:47:17 Commit server status=running Nov 1 22:47:17 No need to pause ... Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:47:18 doing rollback ...
-
成功したバッチ コミット操作のログ エントリーのみを表示するには、
| match committed
パイプ オプションを付けてfile show /var/log/<filename>
コマンドを実行します。出力には、コミット操作が成功した場合のバッチ コミット ジョブ ID が表示されます。
user@R0>
file show/var/log/commitd_nov | match committed
Nov 1 22:46:43 Successfully committed 1000 Nov 1 22:50:35 Successfully committed 1002 Nov 1 22:51:48 Successfully committed 1004 Nov 2 01:08:04 Successfully committed 1007 Nov 2 01:16:45 Successfully committed 1009 Nov 2 01:19:25 Successfully committed 1010 Nov 2 01:28:16 Successfully committed 1011 -
失敗したバッチ コミット操作のログ エントリーのみを表示するには、
| match “Error while”
パイプ オプションを付けてfile show /var/log/<filename>
コマンドを実行します。失敗したコミット操作のコミット ジョブ ID が出力されます。
user@R0>
file show/var/log/commitd_nov | match “Error while”
Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:51:10 Error while commiting 1003 Nov 1 22:52:15 Error while commiting 1005 ... -
コミット サーバー イベントのログ エントリーのみを表示するには、
| match “commit server”
パイプ オプションを付けてfile show /var/log/<filename>
コマンドを実行します。コミット サーバーのイベント ログが出力されます。
user@R0>
file show/var/log/commitd_nov | match “commit server”
Nov 1 22:46:39 Commit server status=running Nov 1 22:46:39 Commit server jobs=1000 Nov 1 22:46:43 Commit server status=not running Nov 1 22:46:43 Commit server jobs= Nov 1 22:47:17 Commit server status=running Nov 1 22:47:18 Commit server jobs=1001 Nov 1 22:47:18 2 errors reported by commit server Nov 1 22:47:18 Commit server status=not running Nov 1 22:47:18 Commit server jobs= Nov 1 22:50:31 Commit server status=running Nov 1 22:50:31 Commit server jobs=1002 Nov 1 22:50:35 Commit server status=not running Nov 1 22:50:35 Commit server jobs= Nov 1 22:51:09 Commit server status=running Nov 1 22:51:10 Commit server jobs=1003 Nov 1 22:51:10 2 errors reported by commit server Nov 1 22:51:10 Commit server status=not running ...
代替ブートド ドライブへのコミット済み設定のバックアップ
設定をコミットし、正常に動作していることを確認したら、 request system snapshot
コマンドを発行して、新しいソフトウェアを /altconfig
ファイル システムにバックアップします。 request system snapshot
コマンドを発行しない場合、代替ブートドライブの構成はプライマリー ブート ドライブの構成と同期していません。
request system snapshot
コマンドは、ルート ファイル システムを /altroot
にバックアップし、/config
を /altconfig
にバックアップします。ルートおよび/config
ファイルシステムはルーターのフラッシュドライブに、/altroot
および/altconfig
ファイルシステムはルーターのハードディスクにあります(利用可能な場合)。
request system snapshot
コマンドを発行すると、実行中のソフトウェアとバックアップ コピーが同一になるため、以前のバージョンに戻すことはできません。