- play_arrow 概要
- play_arrow 今すぐ始めてみませんか
- play_arrow 設定の管理
- play_arrow 運用コマンドを使用したデバイスの監視
- play_arrow 設定ステートメントと運用コマンド
設定をコミット
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番目のルーティング・エンジンにコンフィギュレーションを伝播させます。
コンフィギュレーションを同期させるには、というC
commit synchronizeLIコマンドを使用します。ルーティング・エンジンの1つがロックされている場合、同期に失敗します。コンフィギュレーション・ファイルがロックされているために同期に失敗した場合、commit synchronize forceというコマンドを使用することができます。このコマンドはロックを無効にし、コンフィギュレーション・ファイルを同期させます。配信：マルチシャーシ・デバイスのルーティング・プレーン全体にコンフィギュレーションを伝搬します。配信は自動的に行われます。配信処理を制御するためのユーザー・コマンドは用意されていません。コンフィギュレーションの配信中にコンフィギュレーションがロックされた場合、ロックされたコンフィギュレーションは配信されたコンフィギュレーション・ファイルを受け取らないため、同期に失敗します。コンフィギュレーションの前にロックを解除し，ルーティング・プレーンを再同期させる必要があります。
注:マルチシャーシ・プラットフォームで
commit synchronize forceというCLIコマンドを使用する場合，コンフィギュレーション・ファイルの強制同期がルーティング・プレーン全体のコンフィギュレーション・ファイルの配信に影響することはありません。コマンドを発行したデバイスから離れたデバイス上で、コンフィギュレーション・ファイルがロックされている場合、離れたデバイスでの同期に失敗します。ロックを解除して、synchronizationというコマンドを再発行する必要があります。
関連項目
デバイス・コンフィグレーションのコミット
デバイス・コンフィギュレーションの変更をコンフィグレーション・データベースに保存し、デバイス上でコンフィグレーションを有効にするには、commitというコンフィギュレーション・モード・コマンドを使用します。どの階層からでもコマcommitンドを発行することができます：
[edit]
user@host# commit
commit complete
[edit]
user@host#
commitというコマンドを入力すると、まずコンフィギュレーションにシンタックスエラー（commit check）がないかチェックされます。その後、シンタックスが正しければ、コンフィギュレーションが有効になり、現在動作しているデバイスのコンフィギュレーションとなります。
ルータでGraceful Routing Engine Switchoverが有効な場合、バックアップのルーティング・エンジンにコミット操作を行うことはお勧めしません。
コンフィギュレーション・コミットは、以下のいずれかの理由で失敗することがあります：
コンフィギュレーションに不正なシンタックスが含まれているため、コミット・チェックに失敗します。
コミットしようとしている候補コンフィギュレーションは、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]
コンフィギュレーションをコミットすると、現在の形式でコンフィギュレーション全体がコミットされます。
Graceful Routing Engine Switchoverが有効なデバイスでは、バックアップのルーティング・エンジンにコミット操作を行うことはお勧めしません。
Graceful Routing Engine Switchover（GRES）を有効にした場合、
fxp0という管理インタフェースまたは内部インタフェースおよびge-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-quitno-synchronizepeers-synchronizesynchronize
この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 段階は、起動段階と呼ばれ、事前に準備されたコンフィギュレーションが起動され、現在の動作可能なデバイス コンフィギュレーションとなる。
コンフィギュレーションを準備するため。
用意したコンフィギュレーションを有効にする。
コマ
commit activateンドを使用するcontent_copy zoom_out_map[edit] user@host#
commit activateメッセージ
commit completeが表示されます。起動したシステム構成を確認するには、次のコマンドを使用します。
content_copy zoom_out_mapuser@host>
show configuration system scriptslanguage 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#
変更が正しく機能することを確認したら、コマンドから 10 分以内にコcommit confirmedマンド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コマンドを使用することも可能です。
コミット操作のスケジュール
候補の設定をいつアクティブにするかをスケジュールすることができます。rebootデバイスの設定変更を保存し、将来の時刻にまたは再起動時にその設定をデバイス上で有効にするには、commit at設定モードコマンドを使用し、または将来の時刻を [edit] 階層レベルで指定します。
[edit]
user@host # commit at string
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-2112: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コマンドを使用します。
user@host# commit | display detail
たとえば、以下のように表示されます。
[edit]
user@host# commit | display detail
2018-09-22 15:39:39 PDT: exporting juniper.conf
2018-09-22 15:39:39 PDT: setup foreign files
2018-09-22 15:39:39 PDT: propagating foreign files
2018-09-22 15:39:39 PDT: complete foreign files
2018-09-22 15:39:40 PDT: copying configuration to juniper.data+
2018-09-22 15:39:40 PDT: dropping unchanged foreign files
2018-09-22 15:39:40 PDT: daemons checking new configuration
2018-09-22 15:39:41 PDT: commit wrapup...
2018-09-22 15:39:42 PDT: activating '/var/etc/ntp.conf'
2018-09-22 15:39:42 PDT: activating '/var/etc/kmd.conf'
2018-09-22 15:39:42 PDT: activating '/var/db/juniper.data'
2018-09-22 15:39:42 PDT: notifying daemons of new configuration
2018-09-22 15:39:42 PDT: signaling 'Firewall daemon', pid 24567, signal 1,
status 0
2018-09-22 15:39:42 PDT: signaling 'Interface daemon', pid 24568, signal 1,
status 0
2018-09-22 15:39:43 PDT: signaling 'Routing protocol daemon', pid 25679,
signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'MIB2 daemon', pid 24549, signal 1,
status 0
2018-09-22 15:39:43 PDT: signaling 'NTP daemon', pid 37863, signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'Sonet APS daemon', pid 24551, signal 1,
status 0
2018-09-22 15:39:43 PDT: signaling 'VRRP daemon', pid 24552, signal 1,
status 0
2018-09-22 15:39:43 PDT: signaling 'PFE daemon', pid 2316, signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'Traffic sampling control daemon', pid 24553
signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'IPsec Key Management daemon', pid
24556, signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'Forwarding UDP daemon', pid 2320,
signal 1, status 0
commit complete
コミットされたコンフィギュレーションを説明するコメントを追加する
コミットされた設定に対する変更点を説明するコメントを含めることができます。そのためには、commit commentの文言を入れる。コメントは512バイトまで可能で、1行で入力する必要があります。
[edit]
user@host# commit comment comment-string
comment-string121はコメント本文です。
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 Release 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のコミットエラーを報告します。
例：バッチ コミット サーバーのプロパティを設定する
この例では、バッチ コミット サーバーのプロパティを設定し、バッチ コミット操作を管理する方法を示します。
要件
この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。
MX シリーズ 5G ユニバーサル ルーティング プラットフォーム
概要
[edit system commit server] 階層レベルでサーバーのプロパティを設定することで、コミット サーバーによるバッチ コミット キューの処理方法を制御することができます。これにより、1 つのバッチ コミットに集約またはマージされるコミット ジョブの数、キューに追加できるジョブの最大数、バッチ コミット エラー ログを保持する日数、2 つのバッチ コミットの間隔、バッチ コミット操作のトレース操作を制御することができます。
設定
CLIクイック構成
この例のセクションをすばやく設定するには、次のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit] 階層レベルの CLI にコマンドをコピーして貼り付けます。コミット サーバーのプロパティは、通常の [edit] モードと [edit batch] モードのどちらからでも設定可能です。
デバイスR0
set system commit server maximum-aggregate-pool 4set system commit server maximum-entries 500set system commit server commit-interval 5set system commit server days-to-keep-error-logs 30set system commit server traceoptions file commitd_novset system commit server traceoptions flag all
コミット サーバーのプロパティを設定する
ステップバイステップでの手順
（オプション）1 つのコミット操作で集約またはマージするコミット トランザクションの数を設定します。
maximum-aggregate-poolのデフォルト値は5です。注:maximum-aggregate-poolを1に設定すると、各ジョブが個別にコミットされます。この例では、コミット トランザクションの数が
4に設定されており、コミット操作が開始される前に 4 つの異なるコミット ジョブが 1 つのコミットに集約されることが示されています。content_copy zoom_out_map[edit system commit server]user@R0#set maximum-aggregate-pool 4（オプション）バッチで許可されるジョブの最大数を設定します。
これは、キューに追加されるコミット ジョブの数を制限するものです。
content_copy zoom_out_map[edit system commit server]user@R0#set maximum-entries 500注:maximum-entriesを1に設定した場合、コミット サーバーは複数のジョブをキューに追加できず、複数のジョブをコミットしようとすると CLI に適切なメッセージが表示されます。（オプション）次のバッチ コミット操作を開始するまでの時間（秒単位）を設定します。
content_copy zoom_out_map[edit system commit server]user@R0#set commit-interval 5（オプション）エラー ログを保存する日数を設定します。
初期値は
30日です。content_copy zoom_out_map[edit system commit server]user@R0#set days-to-keep-error-logs 30（オプション）バッチ コミット イベントを記録するためのトレース操作を設定します。
この例では、バッチ コミット イベントのログを取るためのファイル名は
commitd_novで、すべての traceoption フラグが設定されています。content_copy zoom_out_map[edit system commit server]user@R0#set traceoptions commitd_novuser@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。content_copy zoom_out_map[edit batch]user@R0#commitAdded to commit queue request-id: 1000バッチ コミット ジョブに高い優先度を割り当てるには、 コマ
commitンドを オpriorityプション付きで実行します。content_copy zoom_out_map[edit batch]user@R0#commit priorityAdded to commit queue request-id: 1001キュー内の他のコミット ジョブと構成の変更を集約せずにコミットするには、 コマ
commitンドを オatomicプション付きで実行します。content_copy zoom_out_map[edit batch]user@R0#commit atomicAdded to commit queue request-id: 1002キュー内の他のコミット ジョブとコンフィグレーションの変更を集約せず、コミット ジョブに高い優先度を発行するには、
atomic priorityオプションを付けてcommitコマンドを実行します。content_copy zoom_out_map[edit batch]user@R0#commit atomic priorityAdded 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コマンドを使用すると、すべてのコミット操作のパッチが表示されます。content_copy zoom_out_mapuser@R0>
show system commit server queue patchPending 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>コマンドを実行します。content_copy zoom_out_mapuser@R0>
show system commit server queue patch id 1000Completed 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>ンドを使用します。content_copy zoom_out_mapuser@R0>
file show/var/log/commitd_novバッチ コミット時のコミット サーバー イベント ログなどが出力されます。
content_copy zoom_out_mapNov 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 ...
成功したバッチ コミット操作のログ エントリーのみを表示するには、
file show /var/log/<filename>コマンドを| match committedパイプ オプション付きで実行します。出力には、コミット操作に成功したバッチ コミット ジョブ ID が表示されます。
content_copy zoom_out_mapuser@R0>
file show/var/log/commitd_nov | match committedNov 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失敗したバッチ コミット操作のログ エントリーのみを表示するには、 コマ
file show /var/log/<filename>ンドを パイ| match “Error while”プ オプション付きで実行します。失敗したコミット操作のコミット ジョブ ID が出力されます。
content_copy zoom_out_mapuser@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 ...コミット サーバー イベントのログ エントリーのみを表示するには、
file show /var/log/<filename>コマンドを| match “commit server”パイプ オプション付きで実行します。コミット サーバーのイベント ログが出力されます。
content_copy zoom_out_mapuser@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 コマンドを発行すると、実行中のソフトウェアとバックアップコピーが同一になるため、以前のバージョンに戻すことはできません。
