Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
項目一覧
 

NETCONFセッション

JunosデバイスでのNETCONFセッションを理解する。

Network Configuration Protocol(NETCONF)を使用して、ネットワーク デバイスを管理できます。以下のセクションでは、JunosデバイスでのNETCONFセッションの概要を説明します。

SSHを使用したNETCONFサーバーへの接続

NETCONFサーバーに接続する最も一般的な方法は、SSHを使用することです。NETCONFクライアントがSSHを使用してNETCONFサーバーに接続する前に、 NETCONFセッションのSSH接続を確立するに記載されている要件を満たす必要があります。前提条件が満たされている場合、NETCONFクライアントは、次のいずれかの方法を使用してNETCONFサーバーに接続できます。

SSHライブラリルーチン

NETCONFクライアントは、SSHライブラリルーチンを使用して、NETCONFサーバーへのSSH接続を確立し、認証を提供し、NETCONFセッションのSSHサブシステムとして機能するチャネルを作成します。ライブラリルーチンを使用するための指示を提供することは、このドキュメントの範囲外です。

ssh 命令

専用ポートを持つSSHサブシステムとしてNETCONFセッションを確立できます。または、デフォルトのSSHポート経由でNETCONFセッションを確立し、疑似tty割り当てを使用することもできます。専用ポート経由でSSHサブシステムを使用することで、デバイスはNETCONFトラフィックを簡単に識別してフィルタリングできます。ただし、デフォルトのSSHポートを疑似tty割り当てで使用すると、たとえば show system users 運用コマンドを発行するときなどに、セッションの可視性を提供できます。

アプリケーションには、NETCONF サーバーのパスワードまたはパスフレーズの入力を求めるプロンプトをインターセプトするコードを含める必要があります。たとえば、アプリケーションは expect コマンドなどのユーティリティを使用できます。

  • デフォルトのNETCONFポート(830)を介してSSHサブシステムとしてNETCONFセッションを確立するには、クライアントアプリケーションは次のコマンドを発行します。

    -pオプションは、NETCONFサーバーがリッスンするポート番号を定義します。デフォルトポート経由でSSHへのアクセスを有効にしている場合は、このオプションを省略できます。

    -sオプションは、NETCONF セッションを SSH サブシステムとして確立します。

  • デフォルトのSSHポート(22)経由でNETCONFセッションを確立し、疑似tty割り当てを使用するには、クライアントアプリケーションは次のコマンドを発行します。

    手記：

    複数の -t オプションを使用すると、SSH にローカル tty がない場合でも、疑似 tty 割り当てが強制されます。

NETCONF セッションの開始

各NETCONFセッションは、NETCONFサーバーとクライアントアプリケーションがサポートされるNETCONF機能を指定するハンドシェイクで始まります。以下のセクションでは、NETCONF セッションの開始方法について説明します。

<hello>タグ要素の交換

NETCONFサーバーとクライアントアプリケーションは、それぞれ <hello> タグ要素を発行して、NETCONF仕様で定義された操作または 機能の中からサポートするものを指定します。クライアント アプリケーションは、他の要素よりも先に <hello> 要素を出力する必要があり、一度だけ出力する必要があります。

<hello> タグは、以下の要素を囲みます。

  • <capabilities>- サポートされている機能を定義する <capability> 要素のリスト。

  • <session-id>—セッションの NETCONF サーバーの UNIX プロセス ID(PID)。

NETCONF 仕様で定義された各機能は、 <capability> 要素では URN(Uniform Resource Name)で表されます。個々のベンダーによって定義された機能は、URNまたはURLのUniform Resource Identifier(URI)で表されます。NETCONF サーバーは、次のような <hello> 要素を出力します。

<hello> 要素の URI は、サポートされている機能を示します。表 1 は、いくつかの一般的な機能を示しています。

表 1:一般的な機能

力

形容

urn:ietf:params:netconf:base:1.0

NETCONFサーバーは、基本のNETCONF仕様で定義された基本操作と要素をサポートします。

urn:ietf:params:netconf:base:1.1

NETCONF セッションは、RFC 6242 に準拠しており、メッセージ フレーミング用のチャンク フレーミング メカニズムをサポートしています。

urn:ietf:params:netconf:capability:candidate:1.0

NETCONFサーバーは、候補の設定に対する操作をサポートします。

urn:ietf:params:netconf:capability:confirmed-commit:1.0

NETCONF サーバーは、確認されたコミット操作をサポートします。

詳細については、NETCONF を使用して確認後にのみ候補の設定をコミットするを参照してください

urn:ietf:params:netconf:capability:validate:1.0

NETCONFサーバーは、実際にコミットすることなく、設定の構文の正確性を検証する検証操作をサポートしています。

詳細については、 NETCONFを使用した候補の設定構文の検証を参照してください。

urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file

NETCONF サーバーは、ファイルに保存された設定データを受け入れます。HTTP または FTP を使用して、ローカルファイルシステムとリモートマシンの両方からファイルを取得できます。

詳細については、 NETCONF セッションでの設定データのアップロードとフォーマットを参照してください。

http://xml.juniper.net/netconf/junos/1.0

NETCONFサーバーは以下をサポートします。

  • 操作情報を要求および変更するために Junos XML API で定義された操作

  • 設定情報を要求または変更するためのJunos XMLプロトコル操作

NETCONF クライアント アプリケーションは、設定機能にネイティブの NETCONF 操作とサポートされている Junos XML プロトコル拡張のみを使用する必要があります。対応するJunos XMLプロトコル操作とNETCONFプロトコル操作のセマンティクスは必ずしも同一ではないため、文書化されたサポート対象拡張以外のJunos XMLプロトコル設定操作を使用すると、予期しない結果が生じる可能性があります。

http://xml.juniper.net/dmi/system/1.0

NETCONFサーバーは、デバイス管理インターフェイス(DMI)仕様で定義された動作をサポートします。

デフォルトでは、NETCONFサーバーは、NETCONF機能交換でサポートされているYANGモジュールをアドバタイズしません。サポートされている YANG モジュールをアドバタイズするには、 [edit system services netconf hello-message yang-module-capabilities] 階層レベルで以下のステートメントを 1 つ以上設定します。

  • advertise-custom-yang-modules—デバイスにインストールされているサードパーティ製の YANG モジュールをアドバタイズします。
  • advertise-native-yang-modules—Junos OSネイティブYANGモジュールをアドバタイズします。
  • advertise-standard-yang-modules- OpenConfig モジュールなど、デバイスがサポートする標準 YANG モジュールをアドバタイズします。

NETCONF 仕様に準拠するために、クライアント アプリケーションはサポートする機能を定義する <hello> 要素も出力します。 <session-id> 要素は含まれていません。

NETCONF セッションは、フレーミング メカニズムを使用して、NETCONF サーバーとクライアントがセッション内で送信するメッセージを分離します。デフォルトでは、JunosデバイスとのNETCONFセッションは、メッセージの区切り文字として文字シーケンス]]>]]>を使用します。ただし、RFC 6242 準拠の NETCONF セッションを設定し、両方のピアが機能交換で :base:1.1 機能をアドバタイズする場合、NETCONF セッションはセッションの残りの部分でチャンク フレーミングを使用します。チャンク フレーミングは、XML 要素内の文字シーケンスがメッセージ境界として誤って解釈されないようにする、標準化されたフレーミング メカニズムです。詳細については、 RFC準拠のNETCONFセッションの設定を参照してください。

クライアントアプリケーションがNETCONFサーバーにリクエストを送信すると、セッションは続行されます。NETCONF サーバーは、クライアント アプリケーションの要求に応答する場合を除き、セッションの初期化後に要素を出力しません。

互換性の検証

タグ要素 <hello> 交換することで、NETCONFサーバーとクライアントが同じ機能をサポートしているかどうかを判断できます。また、NETCONF サーバーで実行されている Junos OS のバージョンをクライアント アプリケーションで確認することを推奨します。 <hello> タグを発行した後、クライアントアプリケーションは <get-software-information> 要求を発行できます。

NETCONF サーバーは、Junos OS バリアントに応じて異なるタグを囲む <software-information> 要素を返します。Junos OS、 <host-name> タグ要素と <product-name> タグ要素に加えて、各ソフトウェアモジュールの <package-information> 要素を返します。 <comment> 要素は、Junos OS リリースとビルド日付を YYYYMMDD の形式で指定します。次の例では、リリースは Junos OS リリース 8.2 用に 8.2 され、ビルド日は20070112 (2007 年 1 月 12 日) です。

通常、このバージョンは、デバイスで実行されているすべての Junos OS モジュールで同じです(予測可能なルーティング パフォーマンスのために、この設定を推奨します)。したがって、通常は 1 つのモジュールのバージョン番号を確認するだけで十分です。

クライアント アプリケーションは、バージョンまたは機能の違いを処理する方法を決定する役割を担います。完全に自動化されたパフォーマンスを実現するには、NETCONFサーバーと同じ機能とJunos OSバージョンをサポートするかどうかを判断するコードをクライアントアプリケーションに含めます。相違点がある場合は、次のオプションのどれが適切かを判断し、対応する応答を実装します。

  • 相違点を無視する—機能とJunos OSバージョンの違いを無視し、NETCONFサーバーに対応するようにクライアントアプリケーションの動作を変更しません。Junos OSのバージョンが異なっていても、必ずしもサーバーとクライアントの互換性がなくなるとは限らないため、多くの場合、この方法は有効なアプローチとなります。同様に、クライアント アプリケーションがサポートしていない機能が、構成の検証やコミットの確認など、常にクライアントによって開始される操作である場合にも有効なアプローチです。その場合、クライアントは操作を開始しないことで互換性を維持します。

  • NETCONFサーバーとの互換性があるように標準動作を変更する—たとえば、クライアントアプリケーションが新しいバージョンのJunos OSを実行している場合、NETCONFサーバーのJunos OSバージョンで利用可能なソフトウェア機能を表すNETCONFおよびJunos XMLタグ要素のみを出力することを選択できます。

  • NETCONF セッションを終了し、接続を終了—NETCONF サーバーのバージョンや機能に対応することが現実的でないと判断した場合、このオプションを使用します。

NETCONFサーバーにリクエストを送信する

リクエストの送信方法

NETCONFサーバーへの要求を開始するために、クライアントアプリケーションは以下を発行します。

  • タグ <rpc> 開く

  • 特定の要求を表す 1 つ以上のタグ要素

  • 終了タグ</rpc>

アプリケーションは、各要求を独自の開始 <rpc> タグと終了タグのペアで囲み </rpc> 。各要求は、準拠し、正しく順序付けられたタグ要素のみを含めることで、整形式の XML ドキュメントを構成する必要があります。NETCONF サーバーは、タグ ストリーム内のタグ要素間で発生する改行文字、スペース、その他の空白文字はすべて無視されますが、タグ要素内の空白は保持されます。

必要に応じて、クライアント アプリケーションは、各要求の開始<rpc>タグにフォーム attribute-name="value"の 1 つ以上の属性を含めることができます。NETCONFサーバーは、応答を囲む開始<rpc-reply>タグの各属性を変更せずにエコーします。

クライアント アプリケーションは、この機能を使用して、意のを割り当てる各開始 <rpc> 要求タグに属性を含めることで、要求と応答を関連付けることができます。NETCONFサーバーは、開始 <rpc-reply> タグで属性をエコーするため、応答を開始要求に簡単にマッピングできます。NETCONF仕様では、この属性の名前 message-id が指定されています。

運用要求と設定要求は概念的には別々のクラスに属していますが、NETCONFセッションにはCLIの動作モードと設定モードに対応する個別のモードはありません。各要求タグ要素は独自の <rpc> タグで囲まれているため、クライアント アプリケーションは運用要求と構成要求を自由に切り替えることができます。クライアント アプリケーションは、運用要求、構成情報要求、および構成変更要求の 3 つのクラスの要求を行うことができます。

運用上の要求

運用要求は 、デバイスの状態に関する情報の要求です。操作要求は、Junos OS CLI 操作モード コマンドに対応します。Junos XML API は、多くの CLI コマンドの要求タグ要素を定義します。例えば、 <get-interface-information> タグ要素は show interfaces コマンドに対応し、 <get-chassis-inventory> タグ要素は show chassis hardware コマンドと同じ情報を要求します。

以下のRPCは、インターフェイスge-2/3/0に関する詳細情報を要求します。

運用上の要求の詳細については、 NETCONFを使用した運用情報の要求を参照してください。

Junos XMLリクエストタグの詳細については、 XML APIエクスプローラーを参照してください。

構成情報の要求

構成情報要求 とは、デバイスの候補構成、プライベート構成、一時的な構成、またはコミットされた(アクティブな)構成に関する情報の要求です。候補構成とコミットされた設定は、候補の構成にコミットされていない変更がある場合に分岐します。

NETCONF プロトコルは、設定情報を取得するための <get-config> 操作を定義します。Junos XML APIは、設定階層内のすべてのコンテナとリーフステートメントのタグ要素を定義します。

次の例では、候補コンフィギュレーションの [edit system login] 階層レベルから情報を要求しています。

設定情報リクエストの詳細については、 NETCONFを使用した設定データリクエストを参照してください。

使用可能な構成タグ要素の概要については、 XML API Explorer を参照してください。

構成変更リクエスト

設定変更リクエスト とは、設定を変更する要求、またはデバイス上で設定変更をコミットする要求のことです。NETCONF プロトコルは、設定情報を変更するための <edit-config> と <copy-config> 操作を定義します。Junos XML APIは、設定階層内のすべてのコンテナとリーフステートメントのタグ要素を定義します。

次の例では、候補コンフィギュレーションの[edit system login]階層レベルに admin というJunos OSユーザーアカウントを作成します。

設定変更要求の詳細については、 NETCONFを使用した設定の編集を参照してください。

使用可能な構成タグ要素の概要については、 XML API Explorer を参照してください。

NETCONF サーバーの応答を解析する

NETCONF サーバー応答の概要

NETCONFセッションでは、クライアントアプリケーションがRPCをNETCONFサーバーに送信して、情報を要求し、デバイス設定を管理します。NETCONFサーバーは、各クライアント要求に対する応答を、開始 <rpc-reply> タグと終了タグのペアで囲み </rpc-reply> 。各応答は、整形式の XML ドキュメントを構成します。

開始 <rpc-reply> タグの xmlns 属性は、名前に junos: 接頭辞を含まない、および異なる値を持つ xmlns 属性を持つ子コンテナ タグで囲まれていない、囲まれたタグ要素の名前空間を定義します。

手記：

デバイスに rfc-compliant ステートメントを設定すると、NETCONFサーバーは、 nc プレフィックスにバインドされたNETCONF名前空間を明示的に宣言し、プレフィックスで応答内のすべてのNETCONFタグを修飾します。

xmlns:junos属性は、junos: プレフィックスで修飾された、囲まれた Junos XML タグ要素のデフォルトの名前空間を定義します。URIのrelease変数は、NETCONFサーバーデバイスで実行されているJunos OSリリースを表します(例:20.4R1)。

クライアントアプリケーションには、NETCONFサーバーから送信されるレスポンスタグ要素のストリームを解析するためのコードが含まれている必要があります。要素は、到着したときに処理するか、応答が完了するまで保存するかのいずれかです。NETCONF サーバは、運用応答、設定情報応答、設定変更応答の 3 つのクラスの応答を返します。

運用上の対応

運用上の応答 は、デバイスの状態に関する情報の要求に対する応答です。これらは、CLI 操作コマンドからの出力に対応しています。

Junos XML API は、定義済みのすべての運用要求タグ要素に対して、応答タグ要素を定義します。例えば、NETCONF サーバーは、 <get-interface-information> タグが要求した情報を <interface-information> と呼ばれる応答タグで返します。同様に、サーバーは、 <get-chassis-inventory> タグによって要求された情報を、 <chassis-inventory> と呼ばれる応答タグで返します。

既定では、サーバーは操作応答を XML形式で返します。クライアントアプリケーションは、フォーマットされたASCIIまたはJSONで応答を要求することもできます。運用応答の書式設定の詳細については、 NETCONF セッションでの運用情報要求の出力形式の指定を参照してください。

以下の運用応答の例には、インターフェイスge-2/3/0に関する情報が含まれています。

xmlns属性と運用応答タグ要素のコンテンツの詳細については、NETCONFを使用した運用情報の要求を参照してください。

構成情報の応答

構成情報応答 は、デバイスの現在の構成に関する情報の要求に対する応答です。Junos XML APIは、設定階層内のすべてのコンテナとリーフステートメントのタグ要素を定義します。

次のサンプル応答には、 [edit system login] 階層レベルの構成データが含まれています。

開始 <configuration> タグの属性については、 NETCONF を使用した設定情報要求の送信元を指定するを参照してください。

構成変更の応答

構成変更応答とは、デバイス構成の状態や内容を変更する要求に対する応答です。NETCONF サーバーは、<rpc-reply> タグ要素内の <ok/> タグを返すことで、要求が正常に実行されたことを示します。

操作が失敗した場合は、代わりに <rpc-reply> タグ要素で、失敗の原因を説明する <rpc-error> 要素で囲みます。

NETCONF および Junos XML プロトコル セッションで標準 API を使用して応答タグ要素を解析する

NETCONF または Junos XML プロトコルのセッションでは、クライアント アプリケーションは、受信した XML タグ要素を、DOM(Document Object Model)や SAX(Simple API for XML)などの標準 API に基づくパーサーにフィードすることで処理できます。パーサーの実装方法と使用方法の説明は、このドキュメントの範囲外です。

DOM 内のルーチンは、受信した XML を受け取り、クライアントアプリケーションのメモリにタグ階層を構築します。また、既存の階層を操作するための DOM ルーチンもあります。DOM 実装は、C、C++、Perl、Java など、いくつかのプログラミング言語で使用できます。詳細については、World Wide Web Consortium (W3C) の Document Object Model (DOM) Level 1 Specification ( http://www.w3.org/TR/REC-DOM-Level-1/ ) を参照してください。追加情報は、 https://metacpan.org/search?q=dist:XML-DOM+dom の Comprehensive Perl Archive Network (CPAN) から入手できます。

DOM の潜在的な欠点の 1 つは、常にタグ要素の階層が構築され、非常に大きくなる可能性があることです。クライアント・アプリケーションが一度に 1 つのサブ階層のみを処理する必要がある場合は、代わりに SAX を実装するパーサーを使用できます。SAX は XML を受け入れ、タグ要素をクライアント・アプリケーションに直接フィードします。クライアント・アプリケーションは独自のタグ階層を構築する必要があります。詳細については、 SAX の公式 Web サイト (http://sax.sourceforge.net/ を参照してください。

NETCONF セッションでのエラーまたは警告の処理

クライアントアプリケーションはRPCをNETCONFサーバーに送信して、情報を要求し、デバイス設定を管理します。NETCONF サーバーは、各クライアント要求に対して応答を送信します。サーバーでエラー状態が発生すると、エラーを説明する子要素を含む <rpc-error> 要素が出力されます。

<rpc-error> 要素には、次の子要素を含めることができます。

  • <bad-element> は、エラーまたは警告が発生したときに処理されていたコマンドまたは構成ステートメントを識別します。設定ステートメントの場合、 <error-path> はステートメントの親階層レベルを指定します。

  • <error-message> は、エラーまたは警告を自然言語のテキスト文字列で記述します。

  • <error-path> は、エラーまたは警告が発生した Junos OS 設定階層レベルへのパスを指定します。

  • <error-severity> は、NETCONF サーバーが <rpc-error> タグ要素を返す原因となったイベントの重大度を示します。指定できる値は、 error と warning の 2 つです。

サーバーが次のいずれかの操作を実行しているときに、エラーが発生する可能性があります。サーバーは、それぞれのケースで子タグ要素の異なる組み合わせを送信できます。

  • クライアント・アプリケーションによってサブミットされた操作要求の処理

  • クライアントアプリケーションの要求に応じた設定のオープン、ロック、変更、コミット、またはクローズ

  • <edit-config>タグ要素内のクライアントアプリケーションによって送信された設定データの解析

クライアント アプリケーションは、いつでも <rpc-error> 要素を受信して処理できるように準備する必要があります。既に受信され、現在の要求に関連する応答タグ要素内の情報が不完全である可能性があります。クライアント アプリケーションには、情報を破棄するか保持するかを決定するロジックを含めることができます。

<error-severity> 要素の値が error の場合、通常の応答は、クライアント アプリケーションが情報を破棄して終了することです。<error-severity> タグ要素の値が warning で、問題がそれほど深刻ではないことを示す場合、通常の応答は、クライアント アプリケーションが警告をログに記録するか、ユーザーに渡し、サーバーの応答の解析を続行することです。

手記：

[edit system services netconf]階層レベルで rfc-compliant ステートメントを設定して、NETCONFサーバーによる特定の動作を強制すると、NETCONFサーバーは<rpc-error>要素と<ok/>要素の両方を含むRPC応答を返すことができません。操作は成功したが、サーバー応答に <ok/> 要素に加えて重大度レベルが warning の <rpc-error> 要素が 1 つ以上含まれている場合、警告は省略されます。

参照

候補コンフィギュレーションのロックおよびロック解除

クライアント アプリケーションが構成情報を要求または変更する場合、次のいずれかの方法を使用して候補の構成にアクセスできます。

  • 候補構成をロックします。これにより、アプリケーションがロックを解除するまで、他のユーザーやアプリケーションが共有構成データベースを変更できなくなります。これは、CLI の configure exclusive コマンドに相当します。

  • 候補コンフィギュレーションをロックせずに変更します。この方法は、共有構成データベースを同時に編集している他のアプリケーションやユーザーによる変更と競合する可能性があるため、お勧めしません。

アプリケーションが構成情報を要求するだけで、それを変更しない場合は、構成をロックする必要はありません。アプリケーションは、すぐに情報の要求を開始できます。ただし、返される情報がセッション中に変更されないことが重要な場合は、構成をロックするのが適切です。

候補コンフィギュレーションのロック

候補コンフィギュレーションをロックすると、ロックが解除されるまで、他のユーザーやアプリケーションが候補コンフィギュレーションを変更することを防ぐことができます。特に、複数のユーザーが設定の変更を許可されているデバイスでは、変更を加える前に設定をロックすることを推奨します。コミット操作は、コミットを要求したユーザーやアプリケーションによる変更だけでなく、候補となるコンフィギュレーションのすべての変更に適用されます。複数のユーザーまたはアプリケーションに同時に変更を加えさせると、予期しない結果が生じる可能性があります。

候補の構成をロックするために、クライアントアプリケーションは、次のように <target> を <candidate/> に設定して <lock> 操作を実行します。

RPC は、CLI の configure exclusive コマンドに相当します。

NETCONFサーバーは、 <ok/> タグを返して候補をロックしたことを確認します。

NETCONF サーバーが設定をロックできない場合、 <rpc-reply> は代わりに失敗の理由を説明する <rpc-error> 要素を囲みます。失敗の理由としては、次のことが考えられます。

  • 別のユーザーまたはアプリケーションが、すでに候補の構成をロックしています。エラーメッセージは、ユーザーまたはアプリケーションのNETCONFセッション識別子を報告します。

  • 候補構成には、まだコミットされていない変更がすでに含まれています。

候補構成のロックを保持できるアプリケーションは、一度に 1 つだけです。他のユーザーやアプリケーションは、候補の設定がロックされている間は、その設定を読み取ることができます。このロックは、クライアント アプリケーションが <unlock> タグ要素を発行して設定のロックを解除するか、NETCONF セッションが終了するまで持続します。

変更をコミットする前にクライアントアプリケーションが候補の設定をアンロックした場合、または変更がコミットされる前に何らかの理由でNETCONFセッションが終了した場合、変更は自動的に破棄されます。候補とコミットされた設定は変更されません。

候補コンフィギュレーションのロック解除

クライアント アプリケーションが候補の構成をロックしている限り、他のアプリケーションやユーザーは候補を変更できません。候補の構成をアンロックするために、クライアント アプリケーションは <unlock> 操作を実行します。

NETCONFサーバーは、 <ok/> タグを返すことで、候補のロックを解除したことを確認します。

NETCONF サーバーが設定のロックを解除できない場合、 <rpc-reply> は代わりに失敗の理由を説明する <rpc-error> 要素を囲みます。

NETCONF セッションの終了

NETCONF セッションでは、別のユーザーまたはアプリケーションがすでにロックを保持しているため、クライアント アプリケーションによる候補の設定のロックに失敗することがあります。この場合、NETCONF サーバーは、既存のロックを保持するエンティティのユーザー名とプロセス ID(PID)を含むエラー メッセージを返します。

クライアント アプリケーションに Junos OS maintenance アクセス許可がある場合は、 <kill-session> 操作を実行することで、ロックを保持しているセッションを終了できます。 <session-id> 要素は、エラーメッセージから取得したPIDを指定します。

NETCONFサーバーは、 <ok/> タグを返すことで、他のセッションを終了したことを確認します。

アプリケーションには、別のセッションを終了することが適切かどうかを判断するためのロジックを含めることをお勧めします。ロジックには、ロックを保持しているユーザーまたはアプリケーションの ID やアイドル時間の長さなどの要因が含まれる場合があります。

セッションが終了すると、セッションにサービスを提供している NETCONF サーバーは、セッション中に行われたコミットされていないすべての変更をロールバックします。確認されたコミットが保留中(変更がコミットされたがまだ確認されていない)の場合、NETCONF サーバーは確認されたコミット命令が発行される前の状態に設定を復元します。

次の例は、別のセッションを終了する方法を示しています。

Client application sends an XML-based rpc request to terminate a session on a NETCONF server with session-id 3250. Server responds with an rpc-reply indicating success.

NETCONF セッションを終了し、接続を閉じます

クライアントアプリケーションは、リクエストを終了すると、<rpc>要素内で空の<close-session/>タグを発行して、NETCONFセッションを終了します。

NETCONFサーバーは、 <rpc-reply> 要素と <ok/> タグを発行します。

NETCONFサーバーへの接続はSSHサブシステムであるため、NETCONFセッションが終了すると自動的に閉じます。

変更履歴

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。

解放
形容
15.1
Junos OS リリース 15.1以降、デバイスに rfc-compliant ステートメントを設定すると、NETCONFサーバーは、 nc プレフィックスにバインドされたNETCONF名前空間を明示的に宣言し、その応答内のすべてのNETCONFタグを プレフィックスで修飾します。