Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

<commit-configuration>

使用

説明

NETCONF または Junos XML プロトコル サーバーに、候補構成、候補構成のプライベート コピー、または一時的な構成データベースのオープン インスタンスに対して、コミット操作のバリエーションの 1 つを実行することを要求します。

候補コンフィギュレーションのプライベート・コピーと一時的な構成データベースのコミット操作には、いくつかの制限が適用されます。例えば、通常の候補構成が別のユーザーまたはアプリケーションによってロックされている場合、またはプライベート・コピーの作成以降にコミットされていない変更が含まれている場合、プライベート・コピーのコミット操作は失敗します。また、一時的な設定データベースのインスタンスに対するコミット操作は、 <synchronize/> オプションのみをサポートします。

適切なタグを tag 要素で <commit-configuration> 囲み、コミット操作のタイプを指定します。

  • 設定を直ちにコミットし、デバイス上でアクティブな設定にするには、空 <commit-configuration/> のタグを発行します。

  • 実際にコミットせずに候補の設定またはプライベートコピーの構文の正しさを確認するには、タグを <check/> タグ要素で <commit-configuration> 囲みます。

  • 関連するコミット操作が成功したときにコミット履歴ログにメッセージを記録するには、タグ要素でログメッセージ文字列を <log> 定義し、タグ要素でタグ要素を <commit-configuration> 囲みます。タグ要素は <log> 、他のタグ要素と組み合わせることができます。 <log> tag 要素が単独で発行されると、関連付けられたコミット操作がすぐに開始されます。

  • 候補の設定をコミットするが、コミットが恒久的なものになるために明示的な確認が必要な場合は、タグを <confirmed/> <commit-configuration> タグ要素で囲みます。

    コミットが確認されない場合、設定は短時間で前の設定にロールバックします。デフォルトでは、ロールバックは10分後に行われます。別のロールバック遅延を設定するには、タグ要素を<confirm-timeout>含め、1~65,535分の範囲で値を指定します。ロールバックを再び(元のロールバック期限を過ぎて)遅らせるには、deadlineが通過する前にタグ(タグ要素に<commit-configuration>同封)を発行<confirmed/>し、オプションでデフォルトとは異なる遅延を指定する要素を含めます<confirm-timeout>。この方法では、ロールバックを繰り返し遅らせることができます。

    タグを発行した直後から恒久的に設定を <confirmed/> コミットするには、ロールバック期限が過ぎる前に空 <commit-configuration/><commit-configuration><check/><commit-configuration> タグまたはタグを発行します。デバイスは候補の設定をコミットし、ロールバックをキャンセルします。候補コンフィギュレーションが現在のコミットされたコンフィギュレーションと同じであれば、その効果は現在のコミットされたコンフィギュレーションの再コミットと同じです。

    メモ:

    設定のプライベートコピーまたは一時的な設定データベースのオープンインスタンスをコミットする場合、確認されたコミット操作は使用できません。

  • 2つのルーティングエンジンを搭載したデバイスで、両方のルーティングエンジンのローカルルーティングエンジンに保存されている候補設定、プライベートコピー、または一時的なデータベースインスタンスをコミットします。以下に示すようにタグ要素を組み合わせます(一時的なデータベースは、 オプションのみをサポート <synchronize/> します)。

    • ローカルルーティングエンジンに格納されているオープン一時的なインスタンス内の候補構成または設定データを他のルーティングエンジンにコピーするには、設定の構文の正しさを確認し、両方のルーティングエンジンで直ちにコミットし、タグをタグ要素で<commit-configuration>囲みます<synchronize/>

    • ローカル ルーティング エンジンに格納された候補構成を他のルーティング エンジンにコピーし、候補の構文の正しさを確認し、将来定義された時刻に両方のルーティング エンジンでコミットするには、または <force-synchronize/> タグ要素を <at-time> タグ要素で<commit-configuration>囲みます<synchronize/>。で値を設定、 <at-time> tag 要素の単独での使用<at-time>について説明したように、 tag 要素です。

    • ローカルルーティングエンジンに格納された候補設定を他のルーティングエンジンにコピーし、各ルーティングエンジンで候補の構文の正しさを確認するには、または <force-synchronize/> および <check/> タグ要素を<synchronize/><commit-configuration>タグ要素で囲みます。

    • ローカルルーティングエンジンに格納された候補構成を他のルーティングエンジンにコピーするには、候補の構文の正しさを確認し、両方のルーティングエンジンでコミットしますが、確認が必要です。タグ要素と<confirmed/>タグ要素、オプションでタグ要素を<commit-configuration><confirm-timeout>タグ要素で囲みます<synchronize/>。タグ要素と<confirm-timeout>タグ要素の単独使用について説明したように、tag 要素の値<confirm-timeout><confirmed/>設定します。

    • タグによって<synchronize/>呼び出されたのと同じ同期コミット操作を強制するには、リモートマシンで開いている設定セッションやコミットされていない設定変更がある場合でも、タグを<force-synchronize/><commit-configuration>タグ要素で囲みます。

  • 将来のコミットの候補設定をスケジュールするには、タグ要素を <at-time> タグ要素で <commit-configuration> 囲みます。有効な時間指定子は 3 種類あります。

    • 文字列 rebootは、次回デバイスを再起動するときに設定をコミットします。

    • タグmm要素が発行された日<commit-configuration>の午後 11 時 59 分 59 秒より前に、指定された時刻に設定をコミットする:[:ss] 形式hhの時間値(時間、分、オプションで秒)。値には 24 時間の時間をhh使用します。例えば、04:30:00 は午前 4:30:00、20:00 は午後 8:00 を意味します。時間は、デバイスのクロックとタイムゾーンの設定に関して解釈されます。

    • 形式 yyyyの日付と時刻の値 -mm-dd hh:mm[:ss] (年、月、日付、時間、分、およびオプションで秒)は、タグ要素が発行された後である必要がある、指定された日時に設定を <commit-configuration> コミットします。この値には 24 時間の時間を使用します hh 。例えば、2005-08-21 15:30:00 は、2005 年 8 月 21 日の午後 3:30 を意味します。時間は、デバイスのクロックとタイムゾーンの設定に関して解釈されます。

      メモ:

      指定する時間は、デバイスの現在の時刻より 1 分以上後でなければなりません。

      設定は直ちにチェックされ、構文が正しいかどうかチェックされます。チェックに成功した場合、指定された時刻にコミットする設定がスケジュールされます。チェックが失敗した場合、コミット操作はスケジュールされません。

内容

<at-time>

指定した将来の時刻にコミット操作をスケジュールします。

<check>

設定が構文的に正しいことを検証しますが、実際にはコミットしません。

<confirmed>

候補構成のコミットを要求し、コミットが恒久的なものになるため、明示的な確認を必要とします。コミットが確認されない場合は、短い時間でデフォルトで 10 分後に以前の設定にロール バックします。tag 要素を <confirm-timeout> 使用して、異なる時間を指定します。

<confirm-timeout>

タグがタグ要素に同封されている場合に、コンフィギュレーションが <confirmed/> アクティブなままである分数を <commit-configuration> 指定します。

  • 範囲: 1~65,535分

  • デフォルト: 10 分

<log>

コミット操作に成功した場合、コミット履歴ログにメッセージを記録します。

<synchronize>

デュアルコントロールプレーンシステムでは、1つのコントロールプレーン上の設定を他のコントロールプレーンにコピーし、正しい構文を確認し、両方のルーティングエンジンでコミットするように要求します。

<force-synchronize>

デュアルコントロールプレーンシステムでは、1つのコントロールプレーン上の候補設定を強制的にもう一方の制御プレーンにコピーします。

リリース情報

これは、Junos XML 管理プロトコルの操作です。Junos XML プロトコル セッションでサポートされ、機能交換で http://xml.juniper.net/netconf/junos/1.0 URI を識別する Junos OS を実行するデバイス上の NETCONF セッションで、ジュニパーネットワークス独自の拡張機能としてサポートされています。