Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

コミット スクリプトを使用した永続的または一時的な設定変更の生成の概要

Junos OS コミット スクリプトは、カスタム設定ルールを適用します。 候補コンフィギュレーション に、設定に含める必要がないように決定したステートメントが含まれている場合、または候補コンフィギュレーションで決定したステートメントが省略されている場合、コミットスクリプトが設定を自動的に変更して問題を修正できます。

永続的な変更と一時的な変更の違い

コミット スクリプトによる設定変更は、 永続的 または 一時的なものがあります。

永続的な変更は候補構成に残され、変更を生成したコミット スクリプトを削除または無効にしてコマンドを再発行commitする場合でも、明示的に削除するまでルーティング操作に影響します。つまり、コミット スクリプトを削除しても、設定から永続的な変更が削除されるわけではありません。

対照的に、 一時的な変更チェックアウト構成 で行われますが、候補の構成では行いません。チェックアウト設定は、デバイス上のアクティブな設定にコピーされる直前に、標準的なJunos OS構文を検査する設定データベースです。その後変更を行い、コマンドを再発行 commit したコミットスクリプトを削除または無効化した場合、チェックアウト設定に対する変更は行われなくなり、アクティブな設定には影響しません。つまり、コミットスクリプトを削除すると、一時的な変更が設定から効果的に削除されます。

一時的な変更には、既知のポリシーを繰り返し設定して表示する必要がなくなるため、これらのポリシーを暗黙的に適用することが一般的に使用されます。たとえば、国際標準化機構(ISO)プロトコルが有効になっているすべてのインターフェイスで MPLS を有効にする必要がある場合、変更は一時的なものとなり、反復的または冗長構成データを候補の設定で転送したり表示したりする必要はありません。さらに、一時的な変更では、一連の条件が満たされた場合にのみ変更を適用するスクリプト命令を作成できます。

永続的および一時変更は、設定モード コマンドが受信設定を読み込むのload replaceと同じ方法で設定に読み込まれます。永続的または一時的な変更を生成する場合、構成要素に属性を追加replace="replace"すると、操作のload replaceタグとreplace:同じ動作が生成されます。

デフォルトでは、Junos OS は受信した設定と候補の設定をマージします。新しいステートメントと階層が追加され、競合するステートメントが上書きされます。永続的または一時的な変更を生成する場合、属性を replace="replace" 設定要素に追加すると、Junos OSは既存の構成要素を受信構成要素に置き換えます。属性が replace="replace" コンフィギュレーション・エレメントに追加されていても、現在のコンフィギュレーションに同じ名前の既存のエレメントがない場合、受信した構成要素はコンフィギュレーションに追加されます。属性を持 replace たない要素は、コンフィギュレーションにマージされます。

標準的な Junos OS 検証チェックが実行される前に、永続的および一時的な変更が読み込まれます。つまり、コミット スクリプトによって導入された設定変更はすべて、正しい構文で検証されます。構文が正しい場合、新しい設定はアクティブな動作デバイス設定になります。

設定階層内の保護された要素は、永続的または一時的な変更によって変更または削除することはできません。コミットスクリプトが保護されたステートメントや階層を変更または削除しようとすると、Junos OSは変更を行えないという警告を発行し、コミットを続行します。

永続的および一時的な変更には、 表 1 に記載されているとおり、いくつかの重要な違いがあります。

表 1:永続的な変化と一時的な変化の違い

永続的な変更

一時的な変更

SLAX および XSLT スクリプト内のテンプレートへの呼び出しまたは Python スクリプト内のメソッドの呼び出しjcs:emit-changeの中で、パラメーターを 'change' に設定されているパラメーターと組みjcs.emit_change合わせてtag使用contentすることで、コミット スクリプトの永続的な変更を表すことができます。

SLAX および XSLT コミット スクリプトは、 タグを使用して永続的な変更を <change> 表すこともできます。

SLAX および XSLT スクリプト内のテンプレートへの呼び出しまたは Python スクリプトcontent内のメソッドの呼び出しjcs:emit-change内で、一時的な変更をパラメーターに設定されているパラメーターと組み合わせてtag、コミット スクリプトで一時的な変更をjcs.emit_change表すことができます。

SLAX および XSLT コミット スクリプトは、 タグを使用して一時的な変更を <transient-change> 表すこともできます。

永続的な変更を使用して、設定のセクションのアクティブ化、 無効化、削除、挿入(並べ替え)、コメント(注釈)、置換などのJunos XMLプロトコル操作を実行できます。

永続的な変更と同様に、一時的な変更を使用して、Junos XML プロトコルの操作を実行できます。ただし、一部の Junos XML プロトコル操作は、コメントの生成や非アクティブな設定など、一時的な変更では使用しても意味がありません。

コミット スクリプトまたは標準 Junos OS の有効性チェックによってエラーが生成されない場合、コミット プロセス中に永続的な変更が常に読み込まれます。

一時変更を読み込むには、 階層レベルに ステートメントをallow-transients[edit system scripts commit]含める必要があります。一時的な変更を生成するコミットスクリプトを有効にし、設定に ステートメントをallow-transients含まない場合、CLIはエラーメッセージを生成し、コミット操作は失敗します。コミット スクリプトを使用してステートメントをallow-transients生成することはできません。

永続的な変更と同様に、一時変更は標準の Junos OS 有効性チェックに合格する必要があります。

永続的な変更は、コンフィギュレーション・モード・ load replace コマンドと同様に機能し、その変更は候補コンフィギュレーションに追加されます。

永続的な変更を生成する場合、属性を replace="replace" 設定要素に追加すると、Junos OSは候補となる設定内の既存の要素を受信構成要素に置き換えます。候補コンフィギュレーションに同じ名前の既存の要素がない場合、受信したコンフィギュレーション・エレメントがコンフィギュレーションに追加されます。属性を持 replace たない要素は、コンフィギュレーションにマージされます。

一時変更は設定モードコマンドと同様に load replace 機能し、その変更はチェックアウト設定に追加されます。

一時的な変更を生成する際、属性を replace="replace" 設定要素に追加すると、Junos OSは、チェックアウト設定内の既存の要素を受信構成要素に置き換えます。チェックアウト設定に同じ名前の既存の要素がない場合、受信した構成要素が設定に追加されます。属性を持 replace たない要素は、コンフィギュレーションにマージされます。

一時変更は候補コンフィギュレーションにコピーされません。このため、関連するコミットスクリプトが削除または無効化された場合、一時変更は設定に保存されません。

ソフトウェアは、永続的な変更がコミットされた後、候補の設定を直接編集してコミットすることで、変更と同様に処理します。

永続的な変更が候補のコンフィギュレーションにコピーされると、チェックアウト・コンフィギュレーションにコピーされます。変更が標準的なJunos OSの有効性チェックに合格した場合、変更はスイッチ、ルーター、またはセキュリティデバイスコンポーネントに反映されます。

一時的な変更がコミットされるたびに、ソフトウェアがチェックアウト設定データベースを更新します。一時変更が標準的な Junos OS の有効性チェックに合格すると、変更はデバイス コンポーネントに反映されます。

永続的な変更を生成するスクリプトをコミットした後、 設定モードコマンドを発行することで、永続的な変更を show 表示できます。

user@host# show

このコマンドは、一時的な変更ではなく、永続的な変更のみを表示します。

一時的な変更を生成するスクリプトをコミットした後、 設定モードコマンドを発行することで一時的な変更を show | display commit-scripts 表示できます。

user@host# show | display commit-scripts

このコマンドは、永続的な変更と一時的な変更の両方を表示します。

永続的な変更は、コミット スクリプトで指示されるカスタム設定設計ルールに従う必要があります。

これは、2 回目のコミット操作が行われると、現在のコミット操作でコミット スクリプト ルールによって永続的な変更が評価されないため、明白ではありません。永続的な変更が、最初のコミット操作で設定されたコミットスクリプトによって課されたルールに準拠していない場合、後続のコミット操作は失敗します。

一時的な変更はによってテストされることはありませんし、カスタムルールに準拠する必要はありません。これは、コミット スクリプトと Junos OS コミット モデルで詳細に説明されている Junos OS コミット モデルの操作順序が原因です。

変更を生成したコミット スクリプトのインストラクションを削除、無効化、または無効化した場合でも、永続的な変更は設定に残ります。

一時的な変更を生成するコミットスクリプト手順を削除、無効化、または無効化すると、次のコミット操作後に設定から変更が削除されます。つまり、関連する命令またはコミット スクリプト全体が削除された場合、一時的な変更も削除されます。

直接 CLI 設定と同様に、変更を含まない以前の設定にロール バックし、 コマンドを発行することで、永続的な変更を commit 削除できます。ただし、関連するコミット スクリプトを無効化または無効化せずに、変更の元の原因となった問題がまだ残っている場合は、別 commit のコマンドを発行したときに変更が自動的に再生成されます。

以前の設定にロールバックすることで、一時的な変更を削除することはできません。

CLIを使用して設定を編集することで、永続的な変更を直接変更できます。

Junos OS CLI を使用すると、候補の設定に変更が含まれていないため、一時的な変更を直接変更または削除することはできません。

一時変更の内容を変更するには、一時変更を生成するコミットスクリプト内のステートメントを変更する必要があります。

設定変更と設定グループの操作

Junos OS CLI(コマンドラインインターフェイス)を使用して設定を直接編集することで、設定変更をコミットスクリプトで永続的または一時的な変更として生成することもできます。これには、特定の階層レベルまたは設定グループで指定された値が含まれます。直接CLI設定と同様に、 ターゲット で指定された値は、設定グループから継承された値を上書きします。ターゲットは、 ステートメントを含めて設定グループを適用する apply-groups ステートメントです。

永続的または一時的な変更を設定グループに属するように定義した場合、設定グループはステートメントで指定した順序で apply-groups 適用されます。この順序は、最上位レベルを除く任意の階層レベルに含めることができます。また、上位レベルを除く任意の階層レベルで ステートメントを含めることで、 apply-groups-except 設定グループの継承を無効にすることができます。

注意:

各コミットスクリプトは、設定のポストheritanceビューを検査します。候補コンフィギュレーションに構成グループが含まれている場合、コミット・スクリプトを使用して関連するターゲット・コンフィギュレーションを変更する際には注意してください。その場合、構成グループからの意図した継承が変更される可能性があるためです。

また、コミット スクリプトを使用して構成グループを変更する場合は、コミット操作のたびにグループに対する操作を実行 load replace するアプリケーションによって構成グループが生成される可能性があるため、注意してください。

設定グループの詳細については、 CLIユーザーガイド を参照してください。

変更を生成するためのタグ要素とテンプレート

コミット スクリプトで永続的または一時的な変更を生成するには、SLAX スクリプトと XSLT スクリプトでテンプレートをjcs:emit-change使用し、Python スクリプトでこのメソッドをjcs.emit_change使用できます。テンプレートとメソッドにはjcs:emit-change、暗黙的におよび XML 要素が<transient-change><change>まれます。jcs.emit_changeSLAX スクリプトと XSLT スクリプトは、 および <transient-change> 要素を<change>コミット スクリプトに直接含めることで、変更を生成することもできます。jcs:emit-change SLAX スクリプトと XSLT スクリプトでテンプレートを使用すると、変更の階層コンテキストを複数回ではなく 1 回設定できます。Python スクリプトでは、このjcs.emit_changeメソッドでは、要求された変更の設定データに、XML 文字列としてフォーマットされた設定階層のすべてのレベルを表す完全な設定パスを含める必要があります。

<change>および 要素は、Junos XML 管理プロトコルで定義された操作と<transient-change>似ています<load-configuration>。および 要素の<change>可能なコンテンツは、Junos XML プロトコル操作<load-configuration>で使用されるタグ要素の<configuration>コンテンツと<transient-change>同じです。要素の<load-configuration>詳細については、 Junos XML管理プロトコル開発者ガイドを参照してください。