NETCONF セッションを開始

NETCONF サーバーおよびクライアント アプリケーションは、タグ要素を最初に使用して、NETCONF 仕様で定義された操作からサポートされる操作または機能を <hello> 指定します。 タグ <hello> 要素は、セッションに対してNETCONFサーバーのUNIXプロセス <capabilities> <session-id> ID(PID)を指定する要素と要素を囲います。各要素 <capabilities> 内で、 <capability> サポートされている機能を定義します。

クライアント アプリケーションは、NETCONF セッション中に他の要素を送信する前にタグ要素を送信する必要があります。また、それを 2 回よりも多 <hello> く送信していけなければならないのです。

NETCONF 仕様で定義された各機能は、要素内で統一 <capability> されたリソース名(URN)で表されます。個々のベンダーによって定義された機能は、URL または URL である一律のリソース識別子(URL)で表されます。NETCONF XML 管理プロトコルは、次のサンプル出力のような要素を送信します(一部の要素は複数の行に表示され、読み <hello> <capability> 取り専用に使用されます)。

要素の URL は、次のサポート機能を示しています。これは網羅 <hello> 的なリストではありません。

• urn:ietf:params:netconf:base:1.0—NETCONF サーバーは、基本 NETCONF 仕様で定義された基本的な操作と要素をサポートします。

• 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(URN の &options で示す)を使用して、ローカル ファイルシステム file http (URN のオプションで示される)とリモート マシンの両方からファイルを取得 ftp できます。詳細については、 NETCONFセッションでの設定データのアップロードとフォーマット を参照してください。

• http://xml.juniper.net/netconf/junos/1.0—NETCONF サーバーは、運用情報(Junos XML API 運用開発者リファレンス)のタグ要素を要求および変更する、Junos XML API で定義された操作をサポートします。NETCONF サーバーは、設定情報を要求または変更Junos XML 管理プロトコルでの操作もサポートしています。

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

• http://xml.juniper.net/dmi/system/1.0—NETCONF サーバーは、DMI(デバイス管理インターフェイス)仕様で定義された操作をサポートします。

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

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

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

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

タグ要素 <hello> の交換によって、クライアント アプリケーションと NETCONF サーバーは、同じ機能をサポートしているかどうかを判断できます。さらに、クライアント アプリケーションでは、NETCONF サーバー上で実行されているJunos OSを判断することをお勧めします。タグを取得すると <hello> 、クライアント アプリケーションはタグ要素を <get-software-information> タグ要素に <rpc> 送信します。

NETCONF サーバーはタグ要素を返します。タグ要素とタグ要素を囲み、各タグ モジュールの <software-information> <host-name> <product-name> <package-information> Junos OSします。タグ 要素内のタグ 要素は、Junos OS リリース番号(Junos OS リリース 8.2 の例では)とビルド日を <comment> <package-information> YYYYMMDD 形式で指定します(以下の例では 8.2 、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 セッションを終了して接続を閉じる を参照してください。