NETCONF または Junos XML プロトコルを使用した一時的な設定データのコミットと同期

一時的なデータベースは、代替の構成データベースです。NETCONF および Junos XML プロトコル クライアント アプリケーションは、Junos デバイスで設定変更を同時に読み込んでコミットでき、受験者の構成データベースにデータをコミットする場合よりも大幅に高いスループットを実現します。クライアント アプリケーションは、一時的な構成データベースのオープン インスタンスで設定データをコミットして、デバイス上のアクティブな構成の一部にすることができます。デバイス上の一時的な設定データをコミットすると、デバイスのアクティブな設定は、静的および一時的な設定データベースのマージされたビューになります。

注意：

一時的なコミットモデルは、一時的なデータベースにコミットされた設定データのセマンティクス(制約)ではなく、構文を検証します。一時的なデータベースに読み込んでデバイスにコミットする前に、すべての設定データを検証する必要があります。無効な設定データをコミットすると、Junos プロセスが再起動したり、クラッシュしたりして、システムやネットワークが中断する可能性があります。

クライアント アプリケーションが一時的なインスタンスをコミットすると、デバイスは構成データを一時的なデータベースにマージします。影響を受けるシステム プロセスは、設定を解析し、一時的なデータをアクティブなコンフィギュレーション内のデータとマージします。静的および一時的な構成データベースに相反するステートメントがある場合、特定の優先度設定ルールに従ってデータがマージされます。データベースの優先度は、最大から最小までを以下の通りです。

1. 一時的な設定データベースのユーザー定義インスタンス内のステートメント。

   複数のユーザー定義一時的なインスタンスがある場合、優先度は、優先度が最高から最も低い順に実行され、 階層レベルで [edit system configuration-database ephemeral] インスタンスが設定された順序によって決定されます。

2. デフォルトの一時的なデータベースインスタンスのステートメント。

3. 静的な設定データベース内のステートメント。

メモ：

アプリケーションは、静的な設定データベースに加えて、異なる一時的なデータベース インスタンスに同時にデータを読み込み、コミットできます。ただし、デバイスはコミットを順次処理します。その結果、処理順序に応じて、特定のデータベースへのコミットが遅れる場合があります。

メモ：

一時的な設定データが無効または望ましくないネットワーク中断を引き起こす場合は、問題のあるデータをデータベースから削除するか、必要に応じてデバイスを再起動する必要があります。これにより、一時的な設定データベースのすべてのインスタンスの設定データが削除されます。

アクティブなデバイス構成は、静的および一時的な構成データベースの統合ビューです。ただし、 運用モードコマンドを使用してCLIで設定を show configuration 表示する場合、出力には一時的な設定データは含まれません。CLI では、 コマンドのバリエーションを使用して、一時的なデータベースの特定のインスタンスでデータを表示したり、静的および一時的な構成データベースのマージされたビューを show ephemeral-configuration 表示したりできます。

クライアント アプリケーションは、Junos XML プロトコル セッションでの操作または <commit-configuration/> <commit/> NETCONF セッションでの 操作を使用<commit-configuration/>して、一時的な構成データベースのオープン インスタンスで設定データをコミットして、デバイス上のアクティブな構成の一部にすることができます。

Junos XML プロトコル セッションでは、クライアント アプリケーションは(候補 の設定と同様に)タグ要素にタグを囲むことで <commit-configuration/> 、一時的な <rpc> 設定データベースのオープン インスタンスで設定データをコミットします。

Junos XML プロトコル サーバーは、 、 <commit-results>、および タグ要素での<rpc-reply>コミット操作の結果を<routing-engine>報告します。コミット操作が成功した場合、タグ要素は<routing-engine>、ターゲットルーティングエンジンを<commit-success/><name>指定するタグとタグ要素を囲みます。

NETCONF セッションでは、クライアント アプリケーションは、(候補 の構成と同様に)または <commit-configuration/> タグをタグ要素に囲み<commit/>、一時的な<rpc>構成データベースのオープン インスタンスで構成データをコミットします。

NETCONF サーバーは、タグ要素内<rpc-reply>のタグを返すことで、<ok/>コミット操作が成功したことを確認します。

コミット操作に失敗した場合、NETCONF サーバーはエラーの原因を <rpc-reply> 説明する要素と <rpc-error> 子要素を返します。

一時的なデータベースでサポートされるコミット操作の唯一の変種は、一時的なインスタンスの同期の概要で説明されているように、他のルーティング エンジンで設定 を同期することです。

一時的なインスタンスでコミット操作を実行しても、デュアルルーティングエンジンデバイスとMXシリーズバーチャルシャーシは、一時的な設定データをバックアップのルーティングエンジンに自動的に同期しません。一時的なインスタンスのデータは、コミットごとまたはセッションごとに同期することも、一時的なインスタンスを設定して、インスタンスをコミットするたびにデータを同期することもできます。デュアルルーティングエンジンを搭載したデバイスでは、デバイスは一時的なインスタンスをバックアップのルーティングエンジンに同期します。MXシリーズバーチャルシャーシ構成では、システムは一時的なインスタンスのみをバックアップデバイスのプライマリルーティングエンジンに同期します。

メモ：

マルチシャーシ環境では、一時的な設定データベースを他のルーティング エンジンに同期することはできません。

一時的なインスタンスの同期手順については、以下のセクションを参照してください。

• GRES 対応デバイスを設定して一時的な設定データを同期する方法

• 一時的なインスタンスをコミット単位で同期する方法

• セッションごとに一時的なインスタンスを同期する方法

• コミット時に一時的なインスタンスを自動的に同期する方法

• 一時的なデータベースのフェイルオーバー設定同期を設定する方法

既定では、一時的なコミット モデルはコミット操作を非同期で同期します。NETCONF または Junos XML プロトコル サーバーは、ローカル ルーティング エンジンで設定をコミットし、その設定をリモート ルーティング エンジンにコピーしてコミットします。要求するルーティングエンジンは一時的な設定をコミットし、他のルーティングエンジンが最初に設定を同期してコミットするのを待つことなく、コミット完了通知を発行します。

サポートされているデバイスでは、一時的なデータベースを設定して、同期コミット モデルを使用してコミット同期操作を実行することもできます。このモデルでは、プライマリ ルーティング エンジンは、他のルーティング エンジンでのコミットが成功した場合にのみ、そのコミット操作を完了します。同期コミット操作は、非同期コミット操作よりも遅くなりますが、信頼性が高くなります。同期モデルを使用するには、静的設定 commit-synchronize-model synchronous データベースの [edit system configuration-database ephemeral] 階層レベルで ステートメントを設定します。

一時的なインスタンスを同期すると、Junos XML プロトコル サーバーは、 、 <commit-results>、および のタグ要素で<rpc-reply>ローカル ルーティング エンジンのコミット操作の結果を<routing-engine>報告します。コミット操作が成功した場合、タグ要素は<routing-engine>、ターゲットルーティングエンジンを<commit-success/><name>指定するタグとタグ要素を囲みます。

サーバーの応答には、データベースで使用されるコミット同期モデルに依存する追加のタグが含まれています。

• 一時的なデータベースがコミット同期操作に同期モデルを使用する場合、サーバーの応答には、他のルーティング エンジンでのコミット操作に 2 番目 <routing-engine> の要素が含まれます。

• 一時的なデータベースがコミット同期操作に非同期モデルを使用する場合、サーバーにはタグ要素が含まれています <commit-synchronize-server-success> 。これは、同期操作が他のルーティング エンジンでスケジュールされていることを示し、操作の完了に必要な推定時間を秒単位で提供します。

例えば：

同期コミット同期同期操作に対する RPC 応答は、他のルーティング エンジンでのコミット操作の成功または失敗を示します。デバイスは、指定されたファシリティおよび重大度レベルのイベントを記録するようにデバイスが構成されている場合、非同期コミットの成功または失敗をシステム ログ ファイルで同期操作を記録します。ログ記録に必要な一時的なデータベース イベントとファシリティおよび重大度レベルについては、 システム ログ エクスプローラー を参照してください。

同様に、NETCONF セッションでは、サーバーはタグ要素内<rpc-reply>のタグを<ok/>返すことで、コミット操作が成功したことを確認します。応答には、<commit-results>同期コミット同期操作の要素、または非同期コミット同期操作の<commit-synchronize-server-success>要素も含まれます。例えば：

メモ：

静的構成データベースで コマンドを発行しても、デバイスは一時的な設定データベースを commit synchronize 他のルーティング エンジンに同期しません。

デフォルトでは、一時的なデータベースはコミット操作を非同期で同期し、グレースフルルーティングエンジンスイッチオーバー(GRES)が有効になっているデバイス上のバックアップルーティングエンジンに一時的な設定データを同期しません。一時的なデータベースが非同期コミット同期モデルを使用する場合、GRES 対応デバイスが allow-commit-synchronize-with-gres コミット同期操作を実行できるように ステートメントを設定する必要があります。または、サポートされているデバイスでは、代わりに一時的なデータベースを設定して、同期コミット モデルを使用してコミット同期操作を実行することもできます。同期コミット操作は、非同期コミット操作よりも遅くなりますが、信頼性が高くなります。GRES が有効になっているデバイスでは、同期コミット モデルを使用することをお勧めします。

GRES が設定されたデバイスが一時的な設定データを同期できるようにする方法:

そのインスタンスに対する特定のコミット操作に対して、一時的なインスタンスを他のルーティングエンジンに同期させることができます。

一時的なインスタンスをコミットごとに他のルーティング エンジンに同期するには、次の手順に従います。

一時的なインスタンスが開いている間に実行されるすべてのコミット操作に対して、一時的なインスタンスを他のルーティングエンジンに同期することができます。これは、セッションとルーズ呼ばれます。これは、NETCONF または Junos XML プロトコル セッションと混同しないでください。セッション単位でインスタンスを同期することで、複数の負荷とコミット操作を実行し、各コミット操作がインスタンスが閉じられるまで、インスタンスを他のルーティング エンジンに自動的に同期することができます。

インスタンスが開いている間に実行されるすべてのコミット操作に対して一時的なインスタンスを同期するには、以下を行います。

Junos OSリリース22.1R1以降を実行するデバイスとJunos OS Evolvedを実行しているデバイスでは、一時的なインスタンスを設定して、インスタンスをコミットするたびにその設定を他のルーティングエンジンに同期させることができます。

インスタンスをコミットするたびに同期するように一時的なインスタンスを設定するには:

MXシリーズバーチャルシャーシおよびデュアルルーティングエンジンデバイスは、一時的なデータベースのフェイルオーバー設定同期をサポートしており、ルーティングエンジンのスイッチオーバーが発生した場合に、ルーティングエンジン間で設定データベースを確実に同期するのに役立ちます。これは、静的設定データベースで commit synchronize 階層レベルで ステートメントを [edit system] 設定する場合に実現されます。

静的設定データベースに ステートメントを設定 commit synchronize すると、次のような効果があります。

• コミット操作中に、デバイスは静的設定データベースを他のルーティング エンジンに同期します。

• Junos OS リリース 20.2R1 以降、バックアップ ルーティング エンジンは、プライマリ ルーティング エンジンと同期する際に、静的構成データベースと一時的な設定データベースの両方を同期します。以前のリリースでは、バックアップルーティングエンジンは静的設定データベースのみを同期します。

メモ：

静的設定データベースで ステートメントを commit synchronize 設定しても、静的設定データベースをコミットするときやインスタンスをコミットする際に、一時的なインスタンスはバックアップのルーティングエンジンに同期されません。

プライマリおよびバックアップのルーティングエンジンで ステートメントを設定 commit synchronize すると、バックアップルーティングエンジンは、以下のシナリオでプライマリルーティングエンジンと設定を同期します。

• バックアップルーティングエンジンが削除され、再度挿入されます。

• バックアップルーティングエンジンが再起動されます

• デバイスは、グレースフルルーティングエンジンスイッチオーバーを実行し、

• 役割は手動で変更される

• ステートメントが設定されている新しいバックアップルーティングエンジンが挿入 commit synchronize されている

デュアル ルーティング エンジン システムでは、バックアップ のルーティング エンジンは、その設定データベースをプライマリ ルーティング エンジンと同期します。MXシリーズバーチャルシャーシでは、バックアップデバイス上のプライマリルーティングエンジンが、プライマリデバイス上のプライマリルーティングエンジンと設定データベースを同期します。

Junos OS リリース 20.2R1 以降を実行しているサポート対象デバイスまたはJunos OS Evolvedを実行しているデバイスで、静的データベースと一時的なデータベースの両方でフェイルオーバー設定同期を有効にするには、