<commit-configuration>

使用

説明

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

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

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

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

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

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

• 候補構成をコミットするが、コミットが永続的になるには明示的な確認が必要な場合は、タグを <confirmed/> タグ要素に <commit-configuration> 囲みます。

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

  タグの発行後すぐに永続的に設定を <confirmed/> コミットするには、ロールバック期限が過ぎる前に空 <commit-configuration/> の <commit-configuration><check/><commit-configuration> タグまたはタグを発行します。デバイスは、受験者の設定をコミットし、ロールバックをキャンセルします。候補構成がまだ現在のコミット済み構成と同じ場合、その効果は現在コミットされた構成の再コミットと同じです。

  メモ：

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

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

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

  • ローカル ルーティング エンジンに保存されている候補構成を他のルーティング エンジンにコピーするには、受験者の構文の正しさを検証し、将来定義された時点で両方のルーティング エンジンでコミットし、or <force-synchronize/> タグ要素を<at-time>タグ要素に<commit-configuration>囲みます<synchronize/>。タグ要素を単独で使用するために<at-time>前述したように、タグ要素の値を<at-time>設定します。

  • ローカル ルーティング エンジンに保存されている候補構成を他のルーティング エンジンにコピーし、各ルーティング エンジンで受験者の構文の正しさを検証するには、タグ要素の or <force-synchronize/> 要素と<check/>タグ要素を<commit-configuration>囲みます<synchronize/>。

  • ローカル ルーティング エンジンに保存されている候補構成を他のルーティング エンジンにコピーするには、受験者の構文の正しさを検証し、両方のルーティング エンジンでコミットしますが、確認が必要です。タグ要素と<confirmed/>タグ要素を囲み、必要に<confirm-timeout>応じてタグ要素を<commit-configuration>タグ要素に囲みます<synchronize/>。タグと<confirm-timeout>タグ要素を<confirm-timeout>単独で使用するために前述したように、タグ要素の値を<confirmed/>設定します。

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

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

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

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

  • 形式 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 分後に以前の設定にロール バックします。タグ要素を <confirm-timeout> 使用して、異なる時間を指定します。
<confirm-timeout>	タグがタグ要素に囲まれている場合に、設定が <confirmed/> アクティブなままの分数を <commit-configuration> 指定します。 範囲: 1~65,535 分 デフォルト: 10 分
<log>	コミット操作が成功したときに、コミット履歴ログにメッセージを記録します。
<synchronize>	デュアルコントロールプレーンシステムでは、1つの制御プレーン上の設定を他の制御プレーンにコピーし、正しい構文をチェックし、両方のルーティングエンジンでコミットするように要求します。
<force-synchronize>	デュアル制御プレーン システムでは、1 つの制御プレーン上の候補構成を他の制御プレーンにコピーするように強制します。

リリース情報

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