Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

Junos XML プロトコルを使用した冗長制御プレーンでの設定のコミットと同期

ルーティング エンジンはコントロール プレーン内に存在します。単一シャーシ構成の場合、1 つの制御プレーンがあります。冗長システムには、プライマリ プレーンとバックアップ プレーンの 2 つの制御プレーンがあります。マルチシャーシ構成では、制御プレーンには、同じルーティング エンジン指定を持つすべてのルーティング エンジンが含まれます。例えば、すべてのプライマリルーティングエンジンは プライマリ コントロールプレーン内に存在し、すべてのバックアップルーティングエンジンは バックアップ コントロールプレーン内に存在します。

設定をコミットすると、新しい設定がデバイス エンジンに適用されます。マルチシャーシ構成では、設定への変更がシステムにコミットされると、この変更は分散機能を使用して制御プレーン全体に反映されます。

冗長アーキテクチャでは、 コマンドを synchronize 発行して、プライマリとバックアップの両方の制御プレーンに新しい設定をコミットできます。発行された場合、このコマンドは、両方のデバイスルーティングエンジンに現在の設定を保存し、両方の制御プレーンに新しい設定をコミットします。マルチシャーシ システムでは、両方のプレーンで設定がコミットされると、分散機能によって新しい設定が両方のプレーンに分散されます。ルーティングエンジンの冗長性の詳細については、 Junos OS高可用性ユーザーガイドを参照してください。

メモ：

冗長制御プレーンを備えたマルチシャーシ アーキテクチャでは、2 つのプレーンを同期することと、各プレーン全体に設定を分配することには違いがあります。同期は、同じシャーシ内のルーティング エンジン間でのみ行われます。この同期が完了すると、新しい設定は別の分散機能として他のシャーシのコントロール プレーン内の他のすべてのルーティング エンジンに配布されます。

同期は 2 つの独立した制御プレーン間で行われるので、同期設定は冗長ルーティング エンジン アーキテクチャでのみ有効です。さらに、re0 および re1 設定グループは、各ルーティング、スイッチング、またはセキュリティ プラットフォームで定義する必要があります。設定グループの詳細については、 CLIユーザーガイドを参照してください。

メモ：

非冗長ルーティング エンジン システムで コマンドを発行 synchronize した場合、Junos XML プロトコル サーバーは 1 つのコントロール プレーンで設定をコミットします。

一時的な設定データベースの同期については、 NETCONF または Junos XML プロトコルを使用した一時的な設定データのコミットと同期を参照してください。候補構成の同期の詳細については、以下のセクションを参照してください。

両方のルーティング エンジンでの候補構成の同期

冗長ルーティングエンジンシステムで候補の設定またはプライベートコピーを同期するために、クライアントアプリケーションは空 <synchronize/> のタグを で <commit-configuration> 囲み、 <rpc> タグ要素を囲みます。

Junos XMLプロトコルサーバーは、タグが <synchronize/> 発行されるルーティングエンジン(ローカルルーティングエンジンと呼ばれる)で設定の構文の正しさを検証し、設定をリモートルーティングエンジンにコピーして、そこに構文の正しさを検証してから、両方のルーティングエンジンで設定を コミットします。

Junos XML プロトコル サーバーは、 および <commit-results> のタグ要素で<rpc-reply>応答を囲みます。各ルーティング エンジン上の各操作に対して、個別<routing-engine>のタグ要素を出力します。

  • 構文チェックがルーティングエンジンで成功した場合、<routing-engine>タグ要素はタグと<name>タグ要素を<commit-check-success/>囲み、チェックが成功したルーティングエンジンの名前(re0またはre1)を報告します。

    設定が正しくない場合、タグ要素は <xnm:error> エラーの記述を囲みます。

  • ルーティング エンジンでコミット操作が成功した場合、<routing-engine>tag 要素はタグとタグ要素を<commit-success/><name>囲み、コミット操作 が成功したルーティング エンジンの名前を報告します。

    コミット操作に失敗した場合、タグ要素は <xnm:error> エラーの説明を囲みます。障害の最も一般的な原因は、設定におけるセマンティックエラーまたは構文エラーです。

次の例は、両方のルーティング エンジンで候補の設定をコミットして同期する方法を示しています。

同期されたコミット操作を強制する

2 番目のルーティング エンジンの候補構成がロックされている場合、同期操作は失敗します。同期エラーが発生した場合は、障害の原因を判断し、是正措置を講じた後、2 つのルーティング エンジンを再度同期するのが最適です。ただし、必要に応じて、 コマンドを <force-synchronize/> 使用してロックされた設定を上書きし、同期を強制することができます。

メモ：

コマンドを force-synchronize 使用すると、コミットされていない設定の変更は失われます。

同期を強制するには、空<synchronize/>のと<force-synchronize/>タグを および <commit-configuration> タグの要素で<rpc>囲みます。

メモ：

マルチシャーシ環境では、同じシャーシ上のルーティング エンジン間で同期が発生します。同期が行われると、設定変更は分散機能を使用して各制御プレーン全体に反映されます。設定の配信中に 1 つ以上のルーティング エンジンがロックされた場合、その配信は失敗します。リモート シャーシのエラーをクリアし、もう一度コマンドを実行する synchronize 必要があります。

次の例は、両方のルーティング エンジン プレーン間で同期を強制する方法を示しています。

クライアント アプリケーション

Junos XML プロトコル サーバー

 
<rpc>
    <commit-configuration>
        <synchronize/>
        <force-synchronize/>
    </commit-configuration>
</rpc>
  
<rpc-reply xmlns:junos=
             "http://xml.juniper.net/junos/9.010/junos">
    <commit-results>
       <routing-engine junos:style="show-name">
            <name>re0</name>
            <commit-check-success/>
        </routing-engine>
       <routing-engine junos:style="show-name">
            <name>re1</name>
            <commit-success/>
        </routing-engine>
       <routing-engine junos:style="show-name">
            <name>re0</name>
            <commit-success/>
        </routing-engine>
    </commit-resuls>
</rpc-reply>

候補構成を他の操作と同時に同期する

タグは <synchronize/> 、タグ要素内で発生する可能性のある他の <commit-configuration> タグ要素と組み合わせることができます。Junos XML プロトコル サーバーは、設定をチェック、コピー、コミットし、タグが自身で使用されている場合と同じ応答タグ要素を <synchronize/> 発行します。可能な組み合わせは、以下のセクションで説明します。

両方のルーティング エンジンでの設定の検証

コミットせずに両方のルーティング エンジンでローカル設定の構文の正しさを確認するには、アプリケーションで、 および <check/> タグ要素を <synchronize/> で<commit-configuration><rpc>囲み、 タグ要素を囲みます。

タグを <force-synchronize/> タグ要素と <check/> 組み合わせることはできません。

設定の検証の詳細については、 Junos XMLプロトコルを使用した設定構文の検証を参照してください。

指定時間の同期のスケジューリング

将来的に指定された時刻に両方のルーティング エンジンで設定をコミットするために、アプリケーションは、 および <at-time> タグ要素を で<commit-configuration>囲み、<rpc>タグ要素を<synchronize/>囲みます。

<at-time>タグ要素がそれ自体から発行されたときと同様に、Junos XMLプロトコルサーバーは直ちに構文の正しさを検証し、各ルーティングエンジンでコミット操作を実際に実行しても追加のタグ要素を発行しません。

設定の同期と確認が必要

両方のルーティング エンジンで候補の設定をコミットするが、コミットを恒久的なものにするために確認が必要な場合、アプリケーションは、 および (オプションで) <confirm-timeout> タグ要素を および <rpc> タグ要素で<commit-configuration>囲みます<synchronize/><confirmed/>。

同じロールバック期限が両方のルーティングエンジンに適用され、タグ要素が初めて発行 <synchronize/>されたルーティングエンジンで、 、 <confirmed/>、および(オプション) <confirm-timeout> タグ要素を再び発行することで、両方で一度に拡張できます。

タグを <force-synchronize/> および タグ要素と<confirmed/><confirm-timeout>組み合わせることはできません。

確認されたコミット操作の詳細については、 Junos XMLプロトコルを使用した確認後にのみ受験者の設定をコミットするを参照してください。

同期された設定に関するメッセージのロギング

各ルーティング エンジンでコミットが成功したときに設定を同期し、ログ メッセージを記録するために、アプリケーションは、 および <log/> タグ要素を で囲み、要素を<synchronize/>タグ要素で<commit-configuration><rpc>囲みます。

コミット操作は、 または <force-synchronize/> タグの説明で<synchronize/>前述したように続行されます。各ルーティング エンジンのメッセージは、そのルーティング エンジンが維持するコミット履歴ログに記録されます。ロギングの詳細については、「 Junos XMLプロトコルを使用したコミット操作に関するメッセージのロギング」を参照してください。

関連ドキュメント