NETCONF プロトコルの概要
データ モデルの概要:プログラムによる設定と各種の標準規格に準拠した設定
ネットワーク デバイスを管理する従来の方法は、階層的データ(設定コマンド)および運用データ(show コマンド)用のコマンドライン インターフェイス(CLI)を使用することです。ネットワーク管理の場合、特にさまざまなネットワーク デバイス間で管理情報を交換するために、Simple Network Management Protocol(SNMP)が広く使用されています。頻繁に使用されている CLI と SNMP ですが、これにはいくつかの制約事項があります。CLI は非常に独自的であり、テキスト ベースの仕様を理解し、解釈するには人間の介入が必要です。SNMP は、階層的データと運用データを区別しません。
これを解決するには、手作業で設定作業を行うのではなく、プログラムを使用したり、各種の標準規格に準拠してネットワーク デバイスの設定を記述します。Cisco IOS XE で動作するネットワーク デバイスは、データ モデルを使用するネットワーク上の複数のデバイスの設定の自動化をサポートしています。データ モデルは、業界で定義された標準的な言語で開発され、ネットワークの設定とステータス情報を定義できます。
Cisco IOS XE は、Yet Another Next Generation(YANG)データ モデリング言語をサポートしています。YANG をネットワーク設定プロトコル(NETCONF)で使用すると、自動化されたプログラミング可能なネットワーク操作の望ましいソリューションが実現します。NETCONF(RFC 6241)は、クライアント アプリケーションがデバイスからの情報を要求してデバイスに設定変更を加えるために使用する XML ベースのプロトコルです。YANG は主に、NETCONF 操作で使用される設定とステート データをモデル化するために使用されます。
Cisco IOS XE では、モデル ベースのインターフェイスは、既存のデバイス CLI、Syslog、および SNMP インターフェイスと相互運用します。必要に応じて、これらのインターフェイスは、ネットワーク デバイスからノースバウンドに公開されます。YANG は、RFC 6020 に基づいて各プロトコルをモデル化するために使用されます。
(注) |
開発者に分かりやすい方法で Cisco YANG モデルにアクセスするには、GitHub リポジトリを複製し、vendor/cisco サブディレクトリに移動します。ここでは、IOS XE、IOS-XR、および NX-OS プラットフォームのさまざまなリリースのモデルを使用できます。 |
NETCONF
NETCONF は、ネットワーク デバイスの設定をインストール、操作、削除するためのメカニズムです。
コンフィギュレーション データとプロトコル メッセージに Extensible Markup Language(XML)ベースのデータ符号化を使用します。
NETCONF はシンプルなリモート プロシージャ コール(RPC)ベースのメカニズムを使用してクライアントとサーバ間の通信を促進します。クライアントはネットワーク マネージャの一部として実行されているスクリプトやアプリケーションです。通常、サーバはネットワーク デバイス(スイッチまたはルータ)です。サーバは、ネットワーク デバイス全体のトランスポート層としてセキュア シェル(SSH)を使用します。SSH ポート番号 830 をデフォルトのポートとして使用します。ポート番号は、設定可能なオプションです。
NETCONF は、機能の検出およびモデルのダウンロードもサポートしています。サポート対象のモデルは、ietf-netconf-monitoring モデルを使用して検出されます。各モデルに対する改定日付は、機能の応答に示されています。データ モデルは、get-schema RPC を使用して、デバイスからオプションのダウンロードとして入手できます。これらの YANG モデルを使用して、データ モデルを理解したりエクスポートしたりできます。NETCONF の詳細については、RFC 6241 を参照してください。
Cisco IOS XE Fuji 16.8.1 よりも前のリリースでは、運用データ マネージャ(ポーリングに基づく)が個別に有効になっていました。Cisco IOS XE Fuji 16.8.1 以降のリリースでは、運用データは、NETCONF を実行しているプラットフォームで動作し(設定データの仕組みと同様)、デフォルトで有効になっています。運用データのクエリまたはストリーミングに対応するコンポーネントの詳細については、GitHub リポジトリで命名規則の *-oper を参照してください。
NETCONF プロトコルの制約事項
-
NETCONF 機能は、デュアル IOSd 設定またはソフトウェア冗長性を実行中のデバイスではサポートされていません。
-
no ip pim rp-address コマンドを使用して NETCONF データストアから RP アドレスを削除すると、パーサーの制限により、データストアに不整合が生じる可能性があります。NETCONF データストアから RP アドレスエントリを削除するには、RPC を使用します。
NETCONF RESTCONF IPv6 のサポート
データ モデル インターフェイス(DMI)は IPv6 プロトコルの使用をサポートしています。DMI による IPv6 のサポートは、クライアント アプリケーションが、IPv6 アドレスを使用するサービスと通信する場合に役に立ちます。外部向けインターフェイスは、IPv4 と IPv6 の両方についてデュアルスタックをサポートします。
DMI は、ネットワーク要素の管理を容易にする一連のサービスです。NETCONF や RESTCONF などのアプリケーション層プロトコルは、ネットワークを介してこれらの DMI にアクセスします。
IPv6 アドレスが設定されていない場合でも、外部向けアプリケーションは IPv6 ソケットをリッスンし続けますが、これらのソケットは到達不能になります。
NETCONF グローバル セッションのロック
NETCONF プロトコルは、デバイス設定を管理し、デバイスの状態情報を取得するための一連の操作を提供します。NETCONF はグローバル ロックをサポートしており、NETCONF では応答しなくなったセッションを kill する機能が導入されています。
複数の同時セッションの全体にわたって一貫性を確保し、設定の競合を防ぐために、セッションのオーナーは NETCONF セッションをロックできます。NETCONF lock RPC は、コンフィギュレーション パーサーと実行コンフィギュレーション データベースをロックします。その他のすべての NETCONF セッション(ロックを所有していない)は、編集操作を実行できません。ただし、読み取り操作は実行できます。これらのロックは存続時間が短いことを意図しており、オーナーは、他の NETCONF クライアント、NETCONF 以外のクライアント(SNMP、CLI スクリプトなど)、および人間のユーザとやり取りをせずに変更を加えることができます。
アクティブ セッションによって保持されているグローバル ロックは、関連付けられたセッションが kill されたときに無効になります。ロックによって、ロックを保持しているセッションが、設定に対して排他的な書き込みアクセスを行えるようになります。グローバル ロックにより設定の変更が拒否された場合は、エラー メッセージによって、NETCONF グローバル ロックが原因で設定の変更が拒否されたことが示されます。
<lock> 操作は必須パラメータ <target> を受け取ります。これは、ロックしようとするコンフィギュレーション データストアの名前です。ロックがアクティブな場合、<edit-config> 操作と <copy-config> 操作は許可されません。
NETCONF のグローバル ロックの保持中に clear configuration lock コマンドが指定された場合は、設定の完全な同期がスケジュールされ、警告の syslog メッセージが生成されます。このコマンドは、パーサー コンフィギュレーション ロックのみをクリアします。
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
NETCONF Kill セッション
セッションの競合時、またはクライアントによるグローバル ロックの誤用が生じたときは、show netconf-yang sessions コマンドを使用して NETCONF セッションをモニタできます。また、clear netconf-yang session コマンドを使用して応答しなくなったセッションをクリアすることもできます。clear netconf-yang session コマンドは、NETCONF ロックとコンフィギュレーション ロックの両方をクリアします。
<kill-session> 要求は、NETCONF セッションを強制的に終了します。NETCONF エンティティは、オープン セッションの <kill-session> 要求を受信すると、プロセス内のすべての操作を停止し、セッションに関連付けられているすべてのロックとリソースを解放して、関連付けられた接続をすべて閉じます。
<kill-session> 要求には、終了する NETCONF セッションのセッション ID が必要です。セッション ID の値が現在のセッション ID と同じ場合は、無効な値を示すエラーが返されます。NETCONF セッションのトランザクションがまだ進行中に NETCONF セッションが終了した場合は、データ モデル インフラストラクチャによってロールバックが要求され、ネットワーク要素にロールバックが適用されて、すべての YANG モデルの同期がトリガーされます。
セッションの kill が失敗し、グローバル ロックが保持されている場合は、コンソールまたは vty を使用して clear configuration lock コマンドを入力します。この時点で、データ モデルを停止して再起動することができます。
NETCONF-YANG SSH サーバのサポート
NETCONF-YANG はパスワードベースの認証に代わる方法として、IOS セキュアシェル(SSH)リベスト、シャミア、エーデマル(RSA)公開キーを使用したユーザの認証をサポートします。
NETCONF-YANG で公開キー認証を機能させるには、IOS SSH サーバを設定する必要があります。SSH サーバに対してユーザを認証するには、ip ssh pubkey-chain および user コマンドを使用して設定された RSA キーのいずれかを使用します。
NACM は、グループベースのアクセス制御メカニズムです。ユーザが認証されると、設定された権限レベルに基づいて、NACM 権限グループに自動的に配置されます。ユーザを他のユーザ定義グループに手動で配置することもできます。デフォルトの特権レベルは 1 です。PRIV00 〜 PRIV15 の 16 の特権レベルがあります。
ユーザが公開キーを介して認証する場合、対応する認証、許可、アカウンティング(AAA)設定がないと、このユーザは拒否されます。ユーザが公開キーを介して認証する場合、NETCONF の AAA 設定がローカル以外の AAA ソースを使用していると、このユーザも拒否されます。ローカルおよび TACACS + AAA 認証がサポートされます。
トークンベースの RESTCONF 認証はサポートされていません。SSH ユーザ証明書はサポートされていません。
候補コンフィギュレーションのサポート
候補コンフィギュレーション機能を使用すると、シンプルなコミットオプションを使用して RFC 6241 を実装することによって、候補機能をサポートできます。
候補データストアは、デバイスの実行コンフィギュレーションのコピーを保存する一時的な作業領域となります。実行コンフィギュレーションをデバイスにコミットする前に、実行コンフィギュレーションを作成して変更することができます。候補機能は、NETCONF 機能 urn:ietf:params:netconf:capability:candidate:1.0 により示されます。この NETCONF 機能は、デバイスが候補データストアをサポートしていることを示します。
ユーザはこの共有データストアを使用して、デバイスの実行コンフィギュレーションに影響を与えることなく、デバイスのコンフィギュレーションを作成、追加、削除、変更できます。コミット操作では、デバイスのコンフィギュレーションが候補から実行のコンフィギュレーションにプッシュされます。候補データストアが有効になっていると、実行のデータストアには NETCONF セッションを介して書き込むことができず 、すべてのコンフィギュレーションは候補を通じてのみコミットされます。つまり、稼働中の設定を直接変更できる NETCONF 機能は、候補コンフィギュレーションでは有効になりません。
(注) |
候補データストアは共有データ ストアであることに留意してください。複数の NETCONF セッションが内容を同時に変更する可能性があります。したがって、内容を変更する前にデータストアをロックして、コミットが競合しないようにし、最終的にコンフィギュレーションの変更が失われる可能性を防ぐことが重要になります。 |
候補の NETCONF 操作
候補データストアでは次の操作を実行できます。
(注) |
この項の情報は RFC 6241 の 8.3.4 項を参考にしています。詳細と正確な RPC については、RFC を参照してください。 |
ロック
<lock> RPC は、ターゲットのデータストアをロックするために使用します。これにより、他のユーザはロックされたデータストアのコンフィギュレーションを変更できなくなります。ロック操作では候補データと実行データの両方をロックできます。
(注) |
候補データストアのロックは、Cisco IOS のコンフィギュレーションのロックや実行コンフィギュレーションのロックに影響を与えません。逆も同様です。 |
コミット
<commit> RPC は、候補コンフィギュレーションをデバイスの実行コンフィギュレーションにコピーします。「コミット」操作は、候補コンフィギュレーションを更新してコンフィギュレーションをデバイスにプッシュした後に実行する必要があります。
実行または候補のデータストアのいずれかが別の NETCONF セッションによってロックされている場合、<commit> RPC は RPC エラー応答で失敗します。<error-tag> は <in-use> となり、<error-info> にはロックを保持している NETCONF セッションのセッション ID が示されます。conf t lock モードに移行してグローバルロックを使用し、「実行」コンフィギュレーションをロックすることもできますが、コミット操作は RPC エラー応答で失敗し、error-tag の値は <in-use>、セッション ID は「0」になります。
コンフィギュレーション編集
候補コンフィギュレーションは、コンフィギュレーションを変更するための edit-config(コンフィギュレーション編集)操作のターゲットとして使用できます。デバイスの実行コンフィギュレーションに影響を与えることなく、候補コンフィギュレーションを変更できます。
廃棄
候補コンフィギュレーションに加えられた変更を削除するには、discard(廃棄)操作を実行して候補コンフィギュレーションを実行コンフィギュレーションに戻します。
たとえば、NETCONF セッション A によって候補データストアの内容が変更されている場合、セッション B が候補データストアをロックしようとするとロックは失敗します。NETCONF セッション B では候補をロックする前に、他の NETCONF セッションから候補データストアの未解決のコンフィギュレーションの変更を削除するために <discard> 操作を実行する必要があります。
ロック解除
ロック、edit-config(コンフィギュレーション編集)、コミットなどで候補コンフィギュレーションを操作した後、ロック解除 RPC でターゲットとして candidate を指定することによって、データストアをロック解除できます。これで、他のセッションでのすべての操作に候補データストアを使用できるようになります。
候補データストアに対する未解決の変更で不具合が発生した場合、コンフィギュレーションの回復が困難になり、他のセッションで問題が生じる可能性があります。問題を回避するため、未解決の変更は、「NETCONF セッションの障害」で暗黙的にロックが解除されたとき、またはロック解除操作を使用して明示的にロックが解除されたときに廃棄される必要があります。
コンフィギュレーション取得、コンフィギュレーション コピー、コンフィギュレーション検証
候補データストアは、get-config(コンフィギュレーション取得)、copy-config(コンフィギュレーション コピー)、または validate(コンフィギュレーション検証)のどの操作でも、ソースまたはターゲットとして使用できます。候補データストアの変更をデバイスにコミットせずに、コンフィギュレーションの検証のみを行う場合は、<validate> RPC の後に discard の操作を付けることで使用できます。
候補データストアの変更
次の図は、候補データストアを介してデバイス コンフィギュレーションを変更する場合に推奨されるベスト プラクティスを示しています。
-
実行データストアをロックします。
-
候補データストアをロックします。
-
edit-config RPC とターゲットの候補を使用して、候補コンフィギュレーションを変更します。
-
候補コンフィギュレーションを、実行コンフィギュレーションにコミットします。
-
候補データストアと実行データストアをロック解除します。
確認済み候補コンフィギュレーションのコミット
候補コンフィギュレーションは、confirmed-commit 機能をサポートします。この実装では、confirmed-commit 機能に関する RFC 6241 で指定されているとおり、発行されると、実行コンフィギュレーションが候補コンフィギュレーションの現在の内容に設定され、confirmed-commit タイマーが開始されます。commit がタイムアウト期間内に発行されない場合、confirmed-commit 操作はロールバックされます。デフォルトのタイムアウト期間は 600 秒(10分)です。
候補コンフィギュレーションをコミットする場合、コミットを永続的にするための明示的な確認を要求できます。確認済みコミット操作は、コンフィギュレーションの変更が正しく機能し、デバイスへの管理アクセスを妨げないことを確認するのに役立ちます。変更によってアクセスが妨げられたり、その他のエラーが発生したりすると、ロールバックの期限が過ぎた後、以前のコンフィギュレーションへの自動ロールバックによってアクセスが復元されます。指定した時間内にコミットが確認されない場合、デバイスはデフォルトで、以前にコミットされたコンフィギュレーションを自動的に取得してコミット(ロールバック)します。
(注) |
RESTCONF は確認済みコミットをサポートしていません。 |
<rpc>
<commit>
<confirmed/>
</commit>
</rpc>
<rpc>
<commit>
<confirmed/>
<confirm-timeout>nnn</confirm-timeout> !nnn is the rollback-delay in seconds.
</commit>
</rpc>
<rpc-reply xmlns="URN" xmlns:junos="URL">
<ok/>
</rpc-reply>
NETCONF サーバが候補コンフィギュレーションをコミットできない場合、<rpc-reply> 要素で失敗の理由を説明する <rpc-error> 要素を囲みます。最も一般的な原因は、候補コンフィギュレーションのセマンティックまたは構文エラーです。
ロールバックを現在のロールバックタイマーよりも後の時間に遅らせるために、クライアント アプリケーションは、期限が切れる前に <commit> タグ要素内にある <confirmed/> タグを再度送信します。オプションで、<confirm-timeout> 要素を含めることで、次のロールバックを遅らせる時間を指定します。クライアント アプリケーションは、<confirmed/> タグを繰り返し送信することでロールバックを無制限に遅らせることができます。
コンフィギュレーションを永続的にコミットするには、ロールバック期限が過ぎる前に、クライアント アプリケーションが <rpc> タグ要素で囲まれた <commit/> タグを送信します。ロールバックがキャンセルされ、候補コンフィギュレーションがただちにコミットされます。候補コンフィギュレーションが、一時的にコミットされたコンフィギュレーションと同じ場合、一時的にコミットされたコンフィギュレーションが再コミットされます。
別のアプリケーションが <kill-session/> タグ要素を使用して、確認済みコミットが保留中の間にこのアプリケーションのセッションを終了する場合(このアプリケーションは変更をコミットしましたが、まだ確認していません)、このセッションを使用している NETCONF サーバは、確認済みコミット命令が発行される前の状態にコンフィギュレーションを復元します。
候補データストアは、 no netconf-yang feature candidate-datastore コマンドを使用することで無効になります。候補データストアが有効の場合に候補データストアの確認済みコミットが有効になるため、候補データストアが無効の場合は確認済みコミットが無効になります。進行中のすべてのセッションが終了し、confd プログラムが再起動されます。
候補サポートの設定
候補データストア機能は、 netconf-yang feature candidate-datastore コマンドを使用して有効にすることができます。データストアの状態が「実行」から「候補」、またはその逆に変わると、変更を有効にするために NETCONF または RESTCONF の再起動が行われることをユーザに通知する警告メッセージが表示されます。
NETCONF-YANG または RESTCONF confd プロセスの開始時に候補または実行のデータストアの選択がコンフィギュレーションで指定されている場合は、次のような警告が表示されます。
Device(config)# netconf-yang feature candidate-datastore
netconf-yang initialization in progress - datastore transition not allowed, please try again after 30 seconds
NETCONF-YANG または RESTCONF confd プロセスの開始後に候補または実行の選択が行われた場合は、次のように適用されます。
-
netconf-yang feature candidate-datastore コマンドが設定されている場合は、コマンドによって候補データストアが有効になり、次の警告が出力されます。
“netconf-yang and/or restconf is transitioning from running to candidate netconf-yang and/or restconf will now be restarted, and any sessions in progress will be terminated”.
-
netconf-yang feature candidate-datastore コマンドが削除された場合は、コマンドによって候補データストアが無効になり、実行データストアが有効になり、次の警告が出力されます。
netconf-yang and/or restconf is transitioning from candidate to running netconf-yang and/or restconf will now be restarted, and any sessions in progress will be terminated”.
-
NETCONF-YANG または RESTCONF が再起動すると、進行中のセッションは失われます。
コンフィギュレーション データベースの副次的同期
データ モデル インターフェイス(DMI)の設定変更中に、コマンドまたは RPC の設定時にトリガーされる変更の部分的な同期が行われます。これは副次的同期と呼ばれ、同期時間と NETCONF のダウンタイムを短縮します。副次的同期の前に、コンフィギュレーション データベースの時間のかかる完全な同期をトリガーするため、設定変更が使用されます。
副次的同期は、netconf-yang feature side-effect-sync コマンドによって有効になります。
hostname device123
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"/>
</native>
hostname Switch
ここで、NETCONF edit-config RPC の副作用は、RPC が直接意図していない実行コンフィギュレーションへの変更です。edit-config 要求はホスト名を削除することになっていますが、ホスト名は削除されずに Switch に戻ります。副次的同期では、設定全体を同期することなく、この設定変更を NETCONF データベースと同期するため、パフォーマンスが向上します。
副次的同期は CLI モードツリーの概念に基づいており、コマンドはモードとサブモード構造で維持されます。この CLI モードツリーのデータ構造は、次の 3 つのメインノードで構成されています。
-
同じレベルのノード:このノードは、同じ親に属し、同じレベルにある CLI ノードのリストを指します。
-
親ノード:このノードは、CLI ノードの親、そのモード、およびサブモードノードを指します。
-
子ノード:このノードは子 CLI(現在のモードまたはサブモードでの CLI)を指します。ノードに複数の子ノードがある場合、それらの子ノードは同じレベルのノードポインタの一部としてリンクされます。