NETCONF と YANG#

NETCONF#

NETCONF（NETwork CONFiguration に由来）は YANG データモデルと共に使用される現在の主要なトランスポートプロトコルです。これによって、マネージャ（クライアント）とエージェント（サーバ）間の標準的な通信方法が定義されます。

重要なポイントは次のとおりです。 - 2006 年に RFC4741 で最初に標準化されました - 最新の規格は 2011 年の RFC6241 です - コンテンツの明示的な定義は行いません。それは YANG によって提供されるものです。

NETCONF にはトランスポートプロトコルとしての階層化アプローチがあります。これはマネージャ（クライアント）とエージェント（サーバ）が通信する方法を定義するものです。

SSH をベースとした通信#

NETCONF は、ネットワーク上での通信の基盤として SSH を利用します。 NETCONF の認証オプションは SSH 通信と同じです。CLI 通信で SSH を使用する場合と同じように、ユーザ名とパスワードまたは証明書を使用できます。 SSH クライアントを使用した NETCONF の例を次に示します。

SSH と NETCONF を使用してを出力させる#

ssh コマンドラインユーティリティを使用して、サンドボックスが常に動作している IOS-XE ルータへの基本的な NETCONF セッションを開始します。

bash ターミナルを開きます。
ssh -oHostKeyAlgorithms=+ssh-dss root@ios-xe-mgmt.cisco.com -p 10000 -s netconfと入力します。
-oHostKeyAlgorithms=+ssh-dss:必要な SSH キーアルゴリズムが有効になります
-p 10000:NETCONF エージェントがリッスンするポートを指定します
SSL 証明書を承認し、パスワード（D_Vay!_10&）を入力します。

下記のように、画面上で多くのコンテンツがスクロールされていきます。これが、「hello」を表示するルータです。コンテンツの大半は、ルータの「capabilities」と呼ばれるものを表しています。詳細については後ほど説明します。

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <capabilities>
   <capability>urn:ietf:params:netconf:base:1.1</capability>
   <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
   <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</capability>
   <capability>urn:ietf:params:xml:ns:yang:ietf-interfaces</capability>
   [output omitted and edited for clarity]
 </capabilities>
 <session-id>19150</session-id></hello>]]>]]>

次に、「hello」を送り返しましょう。それを実行するためには、マネージャがサポートする「capabilities」を送り返します。ターミナルに次のテキストを貼り付けます。応答は表示されませんが、デバイスへのアクティブな NETCONF 接続が作成されています。
```
 <?xml version="1.0" encoding="UTF-8"?>
 <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <capabilities>
   <capability>urn:ietf:params:netconf:base:1.0</capability>
 </capabilities>
   </hello>]]>]]>
```
セッションを終了するには、<close-session> 操作を送信します。それを実行するために、次のテキストをすべてペーストします
```
 <?xml version="1.0" encoding="UTF-8"?>
 <rpc message-id="1239123" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <close-session />
 </rpc>
 ]]>]]>
```

通常の NETCONF の利用方法#

上記の例のように、SSH チャネルで直接 NETCONF とやりとりを行うのは、最適な方法とは言えません。 XML や RPC を手動で作成すると、エラーが起こりやすい上、手間に見合うほどの成果が得られません。代わりに、接続の処理をすべて行ってくれるツールやコードライブラリを利用するほうが得策です。 Python で ncclient を使用すれば、上記と同じ動作をはるかに簡単に実行することができます。その方法については後ほど説明します。

NETCONF の機能#

NETCONF はトランスポートプロトコルですが、基本的なプロトコルの一部としてデバイス情報の設定や取得を実行することはできません。 NETCONF は、YANG（および非 YANG）データモデルを利用し、デバイスがどの「capabilities」を提供するのかを詳述します。これらの「capabilities」のリストは、「hello」フェーズの一部として、マネージャとエージェント間における最初の通信中にやりとりされます。次に基本的な SSH の例を示します。<capabilities> のリストに注目してください。

$ ssh admin@192.168.0.1 -p 830 -s netconf
admin@192.168.0.1's password:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
  <capability>urn:ietf:params:netconf:base:1.1</capability>
  <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
  <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</capability>
  <capability>urn:ietf:params:xml:ns:yang:ietf-interfaces</capability>
  [output omitted and edited for clarity]
</capabilities>
<session-id>19150</session-id></hello>]]>]]>

リモートプロシージャコール（RPC）#

NETCONF で送信されるメッセージには、リモートプロシージャコール（RPC）が使用されます。 RPC は、クライアントがサーバにリクエストを送信し、何らかのアクションを行って結果を取得するための標準的なフレームワークです。 NETCONF の場合、マネージャが XML 形式のメッセージをサーバに送信し、<rpc> XML 要素内にリクエストを入れ込みます。サーバは、結果を <rpc-reply> 要素に入れて戻します。 <rpc> メッセージには、一意の値を持つ message-id 属性が含まれます。<rpc-reply> メッセージは、この属性と値を繰り返すことで、どのリクエストに応答するのかを識別します。たとえば、次のような例が挙げられます。

<rpc-reply message-id="urn:uuid:7db557ee-ed4c-456c-a058-2d69bd4228c4">
...
...
...
</rpc-reply>

XML のペイロードを手動で作成する場合には、message-id などの RPC 情報を自ら追跡する必要が生じます。一方、ncclient やその他の類似の NETCONF クライアントを使用すれば、これらの RPC 要素はそれらのツールが処理してくれます。

データストア#

SNMP に取って代わるものを IETF が検討する際に、主要な要件となっていたのは、次のような内容でした。 - 統合的な設定検証方法 - エラーチェック/処理 - ロールバック

これらのニーズに対応するため、NETCONF には、個別の operation イベントのターゲットを提供する「データストア」が備わっています。各コンテナは、アクティブなコンフィギュレーションにコミットする前に事前検証が可能な、設定データのコピーを保持します。

最後の例では、このコードラインの「running」データストアに注目します。

result = m.get_config('running', hostname_filter)

データストアのもう 1 つの利点は、複数のネットワークデバイスの一連の変更をコミットする前に、ネットワーク管理システムがそれらのデバイスの設定をデータストア内で確認して、整合性がとれているか検証できることにあります。

データストアの重要なポイント - コンテナは設定の全部または一部を保持します。 - すべてのデータストアがすべてのデバイスでサポートされるわけではありません。 - 「running」は唯一の必須データストアです。 - すべてのデータストアが書き込み可能なわけではありません。 - 「URL」のデータストアはを有効にするため IOS によってサポートされます。 - すべての NETCONF のメッセージはデータストアをターゲットにする必要があります。

NETCONF Operations#

NETCONF RPC リクエストは、次の XML 要素のいずれかを使用して、要求するアクションを指定します。

Operation	説明
`<get>`	実行コンフィギュレーションおよびデバイスの状態情報を取得。
`<get-config>`	指定した設定データストアの全部または一部を取得。
`<edit-config>`	指定した設定データストアに設定の全部または一部を読み込む。
`<copy-config>`	設定データストア全体を別の設定データストアと交換。
`<delete-config>`	設定データストアを削除。
`<commit>`	実行中のデータストアに候補データストアをコピー。
`<lock> / <unlock>`	設定データストアコンピュータ全体をロックまたはロック解除。
`<close-session>`	NETCONF セッションを通常の手順で終了。
`<kill-session>`	NETCONF セッションを強制的に終了。