設定をコミット

デバイスのコンフィギュレーションは、コミットモデルを使用して保存されます。-コンフィギュレーションの候補は、必要に応じて修正され、システムにコミットされます。コンフィギュレーションがコミットされると、デバイスはコンフィギュレーションのシンタックス・エラーをチェックします。エラーが見つからなければ、コンフィギュレーションを 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 コマンドは、どの階層レベルからでも発行することができます。

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

手記：

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

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

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

• コミットしようとしている候補コンフィギュレーションは、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]

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

手記：

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

• グレースフル ルーティング エンジン スイッチオーバー(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モードで行った変更をコミットできます。

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

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

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>

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

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

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

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

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