このページの
例: NETCONF を使用した一時的な設定データベースの設定
一時的なデータベースは、クライアント アプリケーションが Junos デバイス上の設定変更を同時にロードしてコミットし、受験者の構成データベースにデータをコミットする場合よりもはるかに高いスループットを実現する、代替設定データベースです。この例では、一時的な設定データベースのインスタンスを有効にし、NETCONF セッションでそのインスタンスを更新する方法を示しています。
要件
この例では、次のソフトウェア コンポーネントを使用しています。
一時的なデータベースの設定をサポートし、Junos OSリリース16.2R2以降またはJunos OS Evolvedリリース22.1R1以降を実行しているデバイス。
開始する前に、以下を実行します。
デバイスでNETCONF-over-SSHサービスを有効Junosします。
概要
複数の NETCONF および xml プロトコル クライアント アプリケーションJunos一時的なデータベース インスタンスを使用して、Junos デバイスに設定の変更を同時にロードしてコミットできます。この例では、一時的なデータベース インスタンスを有効 eph1 にしてから、NETCONF セッションを介してインスタンスを設定します。
クライアント アプリケーションを表示または変更するには、一時的な設定データベースのインスタンスを開く必要があります。NETCONF セッションを確立した後、Junos XML <open-configuration> <ephemeral-instance> プロトコル操作を使用して一時的なインスタンスを開き、子タグとインスタンスの名前を囲います。一時的なインスタンスを開く場合、自動的に専用のロックが取得されます。
次に、クライアントがテキスト形式で設定データを一時的なeph1インスタンスにロードします。設定データはテキスト<load-configuration>format="text"形式なので、操作には属性を含める必要があります。また、設定データを要素内で囲む必要<configuration-text>があります。
この例では、XMLプロトコル操作を実行して一時的なインスタンスの設定Junosをコミット<commit-configuration>します。属性<load-configuration>action="merge"は、設定データを一時的なデータベースのインスタンスにマージする方法のみを指定します。一時的なインスタンスへの変更をコミットすると、デバイスは、設定データを、事前設定のルールに従ってアクティブな設定にマージします。異なるeph1設定データベースに競合するデータがある場合、インスタンス内のステートメントの優先度は、デフォルトの一時的なインスタンスや静的設定データベースのステートメントよりも高くなります。他にユーザー定義[edit system configuration-database ephemeral]の一時的なインスタンスがある場合、優先度は、階層レベルの設定にインスタンスが表示される順序によって決まります。
この <close-configuration/> 操作により、オープンな一時的なインスタンスが終了し、排他的なロックが解除されます。 eph1 コミットされた一時的なデータは、デバイスが再起動されるまで保持されます。その時点で、デバイスは一時的なインスタンスの設定データと他のすべての一時的なインスタンスのデータを削除します。
構成
一時的なデータベース インスタンスを有効にする
手順
一時的なデータベース インスタンスを有効にするには、以下の方法に示します。
インスタンスの名前を設定します。
[edit] user@host# set system configuration-database ephemeral instance eph1
設定をコミットします。
[edit] user@host# commit
結果
設定モードから、 コマンドを入力して設定を確認 show system configuration-database します。出力結果に意図した設定結果が表示されない場合は、この例の手順を繰り返して設定を修正します。
[edit]
user@host# show system configuration-database
ephemeral {
instance eph1;
}
一時的なデータベース インスタンスの設定
手順
一時的なデータベース インスタンスを設定し、NETCONF セッション内から変更をコミットするには、クライアント アプリケーションで次の手順を実行します。
一時的なデータベース インスタンスを開きます。
<rpc> <open-configuration> <ephemeral-instance>eph1</ephemeral-instance> </open-configuration> </rpc> ]]>]]>設定データをオープン一時的なインスタンスにロードし、そのデータに適したタグと属性を含める。
<rpc> <load-configuration action="merge" format="text"> <configuration-text> protocols { mpls { label-switched-path to-hastings { to 192.0.2.1; } } } </configuration-text> </load-configuration> </rpc> ]]>]]>操作で
<load-configuration>エラーが生成されない場合は、設定をコミットします。<rpc> <commit-configuration/> </rpc> ]]>]]>一時的なデータベース インスタンスを閉じます。
<rpc> <close-configuration/> </rpc> ]]>]]>
結果
データベースのオープンまたは閉じるときにエラーが発生がない場合、NETCONF <rpc-reply> サーバーはリクエストに応答して空の要素を返します。NETCONF サーバーは、and および 要素内<load-configuration><ok/>に囲まれた空のタグを返して、正常な動作を<load-configuration-results>示<rpc-reply>します。同様に、NETCONF サーバーは、<commit-configuration><ok/>要素に囲まれた空のタグを返して、正常な動作を示<rpc-reply>します。
検証
コミットの検証
目的
コミット操作に対する NETCONF サーバーの応答は、コミットの成功または失敗を示す必要があります。システム ログ ファイル内の一時的なデータベースのコミット イベントを確認することで、コミットの成功も検証できます。
アクション
システム ログ ファイルを確認し、一致するイベントを表示します UI_EPHEMERAL。
user@host> show log messages | match UI_EPHEMERAL Feb 10 13:20:32 host mgd[5172]: UI_EPHEMERAL_COMMIT: User 'user' has requested commit on 'eph1' ephemeral database Feb 10 13:20:32 host mgd[5172]: UI_EPHEMERAL_COMMIT_COMPLETED: commit complete on 'eph1' ephemeral database
意味
メッセージ UI_EPHEMERAL_COMMIT_COMPLETED タグは、インスタンスでのコミット操作が正常に完了されたことを eph1 示します。
一時的なデータベース インスタンスの設定データを検証
目的
正しい設定データが一時的なインスタンスに追加されていることを検証します。
アクション
NETCONF セッション内で、一時的なデータベース インスタンスを開き、設定を取得します。
<rpc>
<open-configuration>
<ephemeral-instance>eph1</ephemeral-instance>
</open-configuration>
</rpc>
]]>]]>
<rpc>
<get-configuration format="text"/>
</rpc>
]]>]]>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/16.2R2/junos">
<configuration-text xmlns="http://xml.juniper.net/xnm/1.1/xnm">
## Last changed: 2017-02-10 13:20:32 PDT
protocols {
mpls {
label-switched-path to-hastings {
to 192.0.2.1;
}
}
}
</configuration-text>
</rpc-reply>
]]>]]>
<rpc>
<close-configuration/>
</rpc>
]]>]]>
Junos OSリリース18.2R1show ephemeral-configuration instance-name以降のリリースで動作コマンドを発行するか、以前のリリースで動作コマンドを発行することで、CLIshow ephemeral-configuration instance instance-nameからの一時的なデータベース インスタンスにコミットされた設定データを表示できます。
トラブルシューティング
一時的なインスタンスを開く際の問題のトラブルシューティング
問題
一時的なデータベースのインスタンスを開くことを試み、サーバーは開始タグのみを返 <rpc-reply> します。例えば：
<rpc>
<open-configuration>
<ephemeral-instance>eph1</ephemeral-instance>
</open-configuration>
</rpc>
]]>]]>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/16.2R2/junos">
この問題は、別のクライアントがインスタンスを特別にロックしている場合に発生する可能性があります。
ソリューション
別のユーザーが一時的なインスタンスの独占的なロックを持っている場合、クライアント アプリケーションがリモート プロシージャ コール(RPC)を発行して一時的なインスタンスを更新できますが、一時的なインスタンスでの操作は、ロックが解放されるまで処理されません。ロックが解放されると </rpc-reply> 、サーバーは閉じタグを発行し、一時的なインスタンスがロックされている間に送信された RPC を処理する必要があります。
あるいは、クライアント アプリケーションは異なる一時インスタンスを更新する代わりに、競合する設定ステートメントを解決する際に異なる一時的なインスタンスの優先度レベルが異なという点にも注意が必要です。
運用上の問題のトラブルシューティング
問題
デバイスは、コミットが正常に完了し、その一時的なインスタンスの設定データが存在すると確認した場合でも、特定の設定データを一時的なデータベース インスタンスにコミットした結果として発生する必要のある運用上の変更を実行しません。
設定データが競合し、優先度が高い別のユーザー定義の一時的なインスタンスがある場合、運用上の変更は発生しない可能性があります。一時的なインスタンスに競合するデータがある場合、優先度の高いインスタンスのステートメントで、優先度が低いインスタンス内のステートメントが優先されます。一時的な設定データベースのユーザー定義インスタンスは、デフォルトの一時的なデータベース インスタンスよりも優先度が高く、静的な設定データベースよりも優先度が高くなります。複数のユーザー定義一時インスタンスがある場合、優先度はインスタンスが設定に表示される順序によって決まります。
ソリューション
設定された一時的なインスタンスとその show configuration system configuration-database ephemeral 優先順序を検証するには、デバイスで動作コマンドを発行します。インスタンスは、高優先度から最も優先度の低い順に表示されます。優先度の高い他のインスタンスがある場合は、それらのインスタンスの設定データを参照して、競合するステートメントはないかどうかを確認します。 show ephemeral-configuration merge Junos OSリリース18.2R1 show ephemeral-configuration | display merge 以降のリリースで コマンドを発行するか、以前のリリースで コマンドを発行することで、静的および一時的な設定データベースのマージビューを表示することもできます。
一時的なインスタンスの設定データが競合し、優先度が他のユーザー定義の一時的なインスタンスよりも低く、その階層レベルの設定がデバイスで有効である必要がある場合は、もう一時的なインスタンス内の競合するデータを削除するか、設定データを上位の優先度のインスタンスに配置する必要があります。