Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

NETCONF XML 管理プロトコルについて

ネットワーク構成プロトコル(NETCONF)と、NETCONFを使用してネットワークデバイスを管理するメリットについて説明します。

NETCONFのメリット

  • NETCONFは、ネットワークデバイスの管理のために特別に開発されたスタンダードベースのプロトコルです。

  • NETCONFは、認証、データの整合性、機密性を提供するセキュアな接続指向のセッションを使用します。

  • NETCONFはベンダーに依存しないため、同じNETCONFベースオペレーションを使用して、異なるベンダーのデバイスを管理できます。

NETCONF XML 管理プロトコルの概要

NETCONF XML 管理プロトコルは、ネットワーク デバイスとの通信および管理用に特別に調整されたスタンダードベースのプロトコルです。NETCONFは、クライアント/サーバーモデルとリモートプロシージャコール(RPC)ベースの通信を使用します。NETCONFクライアントは、NETCONFサーバーとの接続とNETCONFセッションを確立し、デバイス上で操作を実行します。JunosデバイスはNETCONFサーバーをOSに統合するため、サーバーはプロセスリストに個別のエントリとして表示されません。

NETCONFでは、RPCと設定データにXMLベースのデータエンコーディングを使用します。NETCONF プロトコルは、CLI 設定モード コマンドに相当する基本操作を定義します。管理者が CLI 設定モード コマンドを使用してこれらの操作を実行するのと同じように、クライアント アプリケーションは、プロトコル操作を使用して設定データの表示、編集、コミット(特に他の操作)を行います。NETCONFセッション内では、クライアントアプリケーションは、Junos OSの動作モードコマンドと同等のRPCを実行することもできます。

概念的には、NETCONF は 4 つのレイヤーに分割できます。 表1は 、レイヤーについて説明しています。

表1:NETCONFレイヤー
NETCONFレイヤー の説明

輸送

トランスポート層は、さまざまなプロトコルを使用してクライアントとサーバー間のセッションの作成を容易にします。

メッセージ

メッセージ層は、RPC と通知をエンコードするためのトランスポートに依存しないフレーミング メカニズムです。タグには以下が含まれます。
  • <rpc>—NETCONFサーバーに送信されたRPCをカプセル化します。

  • <rpc-reply>—NETCONFサーバーから受信したRPC応答をカプセル化します。これには、データ、 <ok/> タグ、エラーや警告を含めることができます。

  • <notification>—通知メッセージをカプセル化します。これは、NETCONFサーバーが通知を購読するNETCONFクライアントに非同期に送信する一方向メッセージです。NETCONFイベント通知の詳細については、 NETCONFイベント通知を参照してください。

運用

操作層は、ネットワークデバイス上で実行できるプロトコル操作を定義します。操作には、 <get-config><edit-config><commit>などの基本プロトコル操作と、ベンダー固有の操作が含まれます。クライアントアプリケーションは、操作をRPCとして呼び出し、XMLエンコードされたパラメーターを提供します。特定の操作の詳細については、このガイドの「 NETCONFプロトコルの操作と属性 」セクションを参照してください。

コンテンツ

コンテンツ層には、XML 形式の RPC リクエストとレスポンス ペイロードが含まれています。この層は、設定データと通知データを定義します。

NETCONFサーバーとクライアントアプリケーション間の通信はセッションベースです。サーバーとクライアントは、データを交換する前に、接続とセッションを明示的に確立します。トランスポート層で定義されているように、NETCONFは必要な要件を満たす任意のセキュアトランスポートプロトコルを使用できます。Junosデバイスは、SSH、アウトバウンドSSH、TLS、アウトバウンドHTTPSを介したNETCONFセッション、およびアウトバウンドSSHを介したNETCONF Call Homeセッションをサポートします。

各NETCONFセッションは、サーバーとクライアントがサポートされているNETCONF機能を含む <hello> タグを交換するハンドシェイクで始まります。NETCONFセッション内では、クライアントとサーバーは、RPC、RPC応答、または通知を含むメッセージを交換します。NETCONF操作層は、クライアントアプリケーションがデバイスを管理するために使用できるプロトコル操作を定義します。コンテンツ層には、RPCに含まれるエンコードされたパラメータとデータを記述します。コンテンツ層については、 NETCONFとJunos XML APIの概要 に詳しく説明しています。クライアントアプリケーションは要求を終了すると、NETCONFセッションと接続を閉じます。

NETCONFクライアントは、RPCをNETCONFサーバーに送信して、情報を要求したり、操作コマンドを実行したり、デバイスの設定を変更したりします。NETCONFサーバーはRPCを処理し、RPC応答をクライアントに送信します。要求に応じて、RPC の応答は要求された情報を返すか、要求された操作の成功または失敗を示します。

NETCONFの詳細については、以下のRFCSを参照してください。

  • RFC 6241、 ネットワーク設定プロトコル(NETCONF)

  • RFC 6242、 SSH(NETCONF Protocol over Secure Shell)の使用

NETCONFとJunos XML APIの概要

Junos XML APIは、Junos OS設定ステートメントと動作モードコマンドのXML表現です。Junos XML APIは、Junos OS設定階層内のすべてのステートメントと、CLI動作モードで発行する多くのコマンドに相当するXMLを定義します。Junos XMLに対応する各動作モードコマンドは、リクエストタグ要素と、必要に応じてレスポンスタグ要素にマッピングされます。Junos XML リクエストタグは、CLI の対応する動作モード コマンドと機能的に同等です。

NETCONFクライアントアプリケーションは、Junosデバイス上で情報を要求したり、操作コマンドを実行したり、設定を変更したりできます。クライアントアプリケーションは、リクエストをNETCONFおよびJunos XML APIタグ要素でエンコードし、デバイス上のNETCONFサーバーに送信します。NETCONFサーバーは、リクエストを適切なソフトウェアモジュールに送信し、応答をNETCONFとJunos XML APIタグ要素でエンコードして、結果をクライアントアプリケーションに返します。

NETCONF クライアントが Junos OS 設定を変更すると、RPC コンテンツには Junos XML 設定データが含まれます。また、NETCONFクライアントは、適切なリクエストタグを持つ運用RPCを送信して、運用コマンドを実行したり、情報を取得したりすることもできます。サーバーは、対応する応答タグ要素内に囲まれた Junos XML API 要素を使用して応答を返します。

たとえば、デバイスのインターフェイスのステータスに関する情報をリクエストするために、クライアントアプリケーションはJunos XML API <get-interface-information/> リクエストタグを送信します。

NETCONFサーバーは、インターフェイスプロセスから情報を収集し、Junos XML API <interface-information> 応答タグ要素に返します。

Junos XML APIのコンテンツは、いくつかの方法で決定できます。ジュニパーネットワークス XML APIエクスプローラ では、Junos XML API要素を参照できます。特定のOSおよびリリースでサポートされている設定要素と運用リクエストおよびレスポンスタグを表示できます。

さらに、Junosデバイスでは、CLIのパイプ(|)運用担当者を使用して、Junos XML APIコンテンツを表示できます。例えば、特定のコマンドの運用リクエストタグを取得するには、CLIで command | display xml rpc を発行します。以下の例では、 show interfaces コマンドのリクエストタグが <get-interface-information>であることを示しています。

同様に、XML 形式で設定データを取得するには、 show configuration | display xml コマンドを使用します。

NETCONF と Junos XML API を使用して、Junos デバイスを管理できます。NETCONFサーバーと対話するクライアントアプリケーションを作成できます。また、NETCONFを使用して、Webブラウザベースのインターフェイスなど、設定や情報の取得や表示のためのカスタムエンドユーザーインターフェイスを構築することもできます。

NETCONFとJunos XML APIを使用するメリット

NETCONFとJunos XML APIは、サポートされているすべてのJunos OS運用リクエストのすべてのオプションと、すべてのJunos OS 設定ステートメントのすべての要素を完全に文書化しています。タグ名は、運用上の要求や設定ステートメントにおける要素の機能を明確に示しています。

意味のあるタグ名と DTD の構造ルールの組み合わせにより、XML タグ付きデータ・セットの内容と構造を理解しやすくなります。NETCONFとJunos XMLタグ要素により、次のセクションで説明するように、クライアントアプリケーションがデバイス出力を解析して特定の情報を検索して表示することが簡単になります。

デバイス出力の解析

次の例は、Junos XML API を使用すると、デバイス出力の解析と必要な情報の抽出がいかに容易になるかを示しています。この例では、Junos OSを実行するデバイスからのフォーマットされたASCIIとXMLタグ付きの出力を比較しています。フォーマットされたASCII出力は次のとおりです。

対応するXMLタグ付きバージョンは次のとおりです。

クライアントアプリケーションがフォーマットされたASCII出力から特定の値を抽出する必要がある場合、絶対的に、または隣接するフィールドのラベルや値に関して表現される値の位置に依存する必要があります。クライアントアプリケーションがインターフェイスインデックスを抽出したいとします。正規表現照合ユーティリティを使用して特定の文字列を検索できますが、インターフェイスインデックスの桁数は必ずしも予測可能ではありません。クライアントアプリケーションは、 Interface index: ラベルの後の特定の文字数を読み取ることはできません。代わりに、ラベルと後続のラベルの間のすべてを抽出する必要があります。

Junos OSの新しいバージョンで出力の形式や順序が変更された場合、問題が発生します。例えば、出力では、インターフェイスインデックス番号の後に Logical index フィールドが追加される場合があります。

Interface index:SNMP ifIndexラベルで区切られたインターフェイスインデックス番号を抽出するアプリケーションでは、誤った結果が取得されるようになりました。この場合は、代わりに次のラベルを手動で検索するようにアプリケーションを更新する必要があります。

対照的に、XMLタグ付きの出力の構造化された性質により、クライアントアプリケーションは、開始 <local-index> タグ内のすべてを抽出し、 </local-index> タグを閉じることで、インターフェイスインデックスを取得できます。アプリケーションは、出力文字列内の要素の位置に依存する必要はありません。その結果、NETCONFサーバーは、 <physical-interface> 要素内で任意の順序で子タグ要素を出力できます。新しい <logical-index> 要素を追加しても、 <local-index> 要素を見つけてその内容を抽出するアプリケーションの機能には影響しません。

デバイスの出力を表示する

XML タグ付きの出力は、さまざまな表示形式に変換するのも簡単です。例えば、特定のデバイスコンポーネントについて、異なる時間に異なる量の詳細を表示することができます。デバイスがフォーマットされた ASCII 出力を返す場合は、アプリケーションに特別なルーチンとデータ構造を記述して、特定の詳細レベルに必要な情報を抽出する必要があります。対照的に、XML 出力の固有の構造は、表示プログラム自体の構造の理想的な基礎となります。同じ抽出ルーチンを複数の詳細レベルに使用し、表示する詳細度が低い場合は不要なタグ要素を無視するだけです。