NETCONF エージェントには、次の注意事項と制限事項があります：

• Cisco NX-OS は、NETCONF 通知で Cisco デバイス YANG モデルと OpenConfig モデルの両方をサポートします。

• デバイス YANG モデルはエフェメラル データを定義します。これらは「// Ephemeral data」というコメントでマークされます。これらの非永続的な大容量データは、モデルの残りの部分とは異なる方法で処理されます。これらは、<get> クエリの <filter> パラメータが、コメントでマークされた特定の要素を具体的に指している場合にのみ返されます。使用方法の詳細については、エフェメラル データ サポートのドキュメントを参照してください。

• Cisco NX-OS リリース 9.3（3）以降、NETCONF は RFC 6241 に準拠していますが、次の例外があります：

  • 兄弟格納ファイル マッチ ノードは、「AND」式ではなく「OR」式で論理的に結合されます。（セクション 6.2.5）

  • 候補データストアを編集した後は、同じプロパティの実行構成を編集しないでください。

• 1 つの Get 要求でサポートされるオブジェクトの数は 250,000 です。次のエラーが表示された場合は、要求されたデータが 250,000 を超えていることを意味します。このエラーを回避するには、より狭い範囲のデータをクエリするフィルタを使用してリクエストを送信します。

  too many objects(459134 > 250000) to query the entire device model.

• NETCONF は、RFC 6536 で指定されている拡張ロールベース アクセス コントロール（RBAC）をサポートしていません。「network-admin」ロールを持つユーザーのみが NETCONF エージェントへのアクセスを許可されます。

• NX-OS 9.3(1) 以降、NETCONF クライアントからスイッチへのNETCONF get および get-config 要求には、明示的な名前空間とフィルタが含まれている必要があります。この要件は、OpenConfig YANG および NETCONF デバイス モデルへの要求に影響します。次のようなメッセージが表示された場合、要求は名前空間を伝送していません。

  Request without namespace and filter is an unsupported operation

  次の例は、この変更前の動作を使用した get 要求と応答を示しています。この例は、サポートされなくなった動作が原因で発生するエラーメッセージを示しています。

  要求:

  <get>
  </get>
  

  応答：

  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
    <rpc-error>
        <error-type>protocol</error-type>
        <error-tag>operation-not-supported</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">Request without filtering is an unsupported operation</error-message>
    </rpc-error>
  </rpc-reply>
  
  

  次に、NX-OS リリース 9.3(1) 以降での正しい動作の get 要求と応答の例を示します。

  要求:

  
  <get>
    <filter>
      <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device"> 
      </System>
    </filter>
  </get>
  
  

  応答：

  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
          <System> …
      </data>
  </rpc-reply>
  
  

• <edit-config> の「置換」操作は、影響を受けるシステム コンポーネントによって実装されている実行時デフォルト値と動作が原因で、機能しない場合があります。したがって、 NX-API 開発者サンドボックスの代わりに、<get-config> クエリによって取得した構成上で、置換を行うための構成を基礎とする方が適切です。

• Cisco NX-OS NETCONF サーバーは、最大 5 つのサブスクリプション（クライアント セッションごとに 1 つのサブスクリプション）をサポートします。

• RFC 5277 に従って、自律通知は、イベント 送信元の NETCONF、SYSLOG、および SNMP ストリームをサポートします。このリリースでは、Cisco NX-OS は NETCONF ストリームのみをサポートします。

• Cisco NX-OS は、サブスクリプションの [再生（Replay）] オプションをサポートしていません。[開始時刻（Start Time）] オプションと [終了時刻（Stop Time）] オプションは再生の一部であるため、サポートされていません。

• ストリーム サブスクリプションとフィルタリングでは、サブツリー フィルタリングのみがサポートされます。XPath フィルタリングはサポートされていません。

• Cisco NX-OS NETCONF エージェントが高負荷で動作している場合、一部のイベント通知がドロップされる可能性があります。

• Cisco NX-OS は、Cisco NX-OS リリース 9.3(1) 以降で NETCONF 通知をサポートします。Cisco NX-OS は、Cisco デバイス YANG モデルのみをサポートします。

• NATがすでに構成されている場合は、スイッチに NETCONF を構成できません。NETCONF とNATの構成には互換性がなく、同じスイッチ上で共存できません。

• Cisco NX-OS は、Cisco Device YANG モデルと OpenConfig モデルの両方をサポートします。NETCONF 通知で OpenConfig モデルをサポートするのは、Cisco NX-OS 9.3(5) リリース以降です。

• 10.2(1)F リリース以降では、操作チェックポイント、ロールバック、インストール、CA 証明書のインポート、モジュールのリロード、個々のモジュールのリロード、およびファイルのコピーがサポートされています。

• L2 MAC リーフ プロパティ値を入力として openconfig-acl NETCONF GET 操作を実行する場合は、MAC アドレスの文字を大文字フォーマット（AA:AA: AA:AA:AA:AA）で入力することをお勧めします。たとえば、source-mac: 0A:0B:0C:0D:0E:0F です。

• Cisco NX-OS リリース 10.3(1)F 以降、NETCONF は、Cisco Nexus 9808 プラットフォーム スイッチでサポートされています。

NETCONF は、クライアントとサーバー間の永続的な接続を必要とする接続指向のプロトコルです。スイッチ上の NETCONF エージェントは、管理ポート IP アドレスのポート 830 でリッスンします。クライアントは、SSH を介して NETCONF サブシステムとの接続を確立できます。クライアントが NETCONF エージェントとのセッションを確立すると、サーバーは<hello>メッセージをクライアントに送信します。同様に、クライアントは<hello>メッセージをサーバーに送信します。は、<hello>メッセージは、接続が開くとすぐに同時に交換されます。各<hello>メッセージには、送信側ピアのプロトコル バージョンと機能のリストが含まれています。これらのメッセージは、プロトコルの互換性と機能を判断するために使用されます。両方の NETCONF ピアは、共通のプロトコルバージョンが他のピアの<hello>メッセージを表示します。また、サーバーの<hello>メッセージには<session-id>一方、クライアントのメッセージを送信することはできません。

次に、ssh コマンドを使用したセッション確立の例を示します。最初の<hello>メッセージがサーバーから受信され、2 番目のメッセージがクライアントから送信されます。サーバーの<hello>メッセージに、プロトコル バージョン「urn:ietf:params:netconf:base:1.1」と、Cisco NX-OS リリース 9.3(4) でサポートされている NETCONF 基本機能が表示されます。また、サーバーの<hello>メッセージには、サポートされているデータモデルが含まれています。現在の Cisco NX-OS リリースでサポートされているモデルと一致しない場合があります。

（注）	サーバーの<hello>メッセージには、<session-id>ですが、クライアントのメッセージはそうではありません。

client-host % ssh admin@172.19.193.166 -p 830 -s netconf
User Access Verification
Password: 
<?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>
        <capability>urn:ietf:params:netconf:base:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=report-all</capability>
        <capability>http://cisco.com/ns/yang/cisco-nx-os-device?revision=2020-04-20&module=Cisco-NX-OS-device</capability>
        <capability>http://openconfig.net/yang/acl?revision=2019-11-27&module=openconfig-acl&deviations=cisco-nx-openconfig-acl-deviations</capability>
        <capability>http://openconfig.net/yang/bfd?revision=2019-10-25&module=openconfig-bfd&deviations=cisco-nx-openconfig-bfd-deviations</capability>
        ...
    </capabilities>
    <session-id>1286775422</session-id>
</hello>
]]>]]><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
  </capabilities>
</hello>
]]>]]>

コマンドで NETCONF を使用することは便利ではなく、エラーが発生しやすくなります。ssh 上記の例では、説明のみを目的として コマンドが使用されています。ssh コマンドよりも推奨される NETCONF 用に作成されたさまざまなクライアントがあります。ssh ncclient はそのような例の 1 つであり、「使用例」セクションで使用されています。

NETCONF は、セッションを終了するための 2 つの操作をサポートしています。<close-session>および<kill-session>。サーバーが<close-session>要求があった場合、セッションに関連付けられているロックとリソースを解放し、クライアントとの接続を閉じることで、セッションを正常に終了します。次に、<close-session>成功の要求と応答：

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <close-session/>
</rpc>
 
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

は、<kill-session>要求は別のセッションの終了を強制し、<session-id>要求メッセージで 。を受信すると、<kill-session>要求がある場合、サーバーは現在の操作を終了し、ロックとリソースを解放し、指定されたセッション ID に関連付けられている接続を閉じます。次に、<kill-session>成功の要求と応答：

<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <kill-session>
    <session-id>296324181</session-id>
  </kill-session>
</rpc>
 
<rpc-reply message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

に加えて、<close-session>および<kill-session>クライアントが一定時間要求を送信しない場合、セッションは自動的に終了します。デフォルトは 5 分です。アイドル タイムアウトの設定については、「NETCONF エージェントの設定」を参照してください。

このセクションでは、データストアを操作およびクエリするためにサポートされている基本プロトコル操作について説明します。クライアントは、NETCONF エージェントとのセッションを確立した後、これらの操作の RPC メッセージを送信できます。これらの操作の詳細については、基本的な使用方法の説明が記載されており、RFC 6242 を参照できます。

<get-config>

この操作により、指定したデータストアの構成データを取得します。サポートされるパラメータは次のとおりです。<filter> 。<source>は、クエリ対象のデータストアを指定します。<running/> 。現在アクティブな設定を保持します。<source>は、<filter>取得する指定されたデータストアの部分を指定します。

次に例を示します。要求および応答メッセージ。

• 全体を取得します。<System>サブツリー：

  <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get-config>
          <source>
              <running/>
          </source>
          <filter>
              <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device"/>
          </filter>
      </get-config>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
      <data>
          <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
          ...
          </System>
      </data>
  </rpc-reply>
  
  

• 特定のリスト項目を取得します。

  <rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get-config>
          <source>
              <running/>
          </source>
          <filter>
              <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
                  <bgp-items>
                      <inst-items>
                          <dom-items>
                              <Dom-list>
                                  <name>default</name>
                              </Dom-list>
                          </dom-items>
                      </inst-items>
                  </bgp-items>
              </System>
          </filter>
      </get-config>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="102">
      <data>
          <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
              <bgp-items>
                  <inst-items>
                      <dom-items>
                          <Dom-list>
                              <name>default</name>
                              ...
                              <rtctrl-items>
                                  <enforceFirstAs>enabled</enforceFirstAs>
                                  <fibAccelerate>disabled</fibAccelerate>
                                  <logNeighborChanges>enabled</logNeighborChanges>
                                  <supprRt>enabled</supprRt>
                              </rtctrl-items>
                              <rtrId>1.2.3.4</rtrId>
                          </Dom-list>
                      </dom-items>
                  </inst-items>
              </bgp-items>
          </System>
      </data>
  </rpc-reply>
  
  

<edit-config>

この操作は、指定された設定をターゲットデータストアに書き込みます。は、<target>パラメータは、編集するデータストアを指定します。<running/>または<candidate/>。候補データストアは、変更がコミットされるまで、実行中のデータストアに影響を与えることなく操作できます。詳細については、を参照してください。<commit>セクションを参照してください。は、<config>パラメータは、ターゲットデータストアに書き込まれるモデル化されたデータを指定します。モデルは「xmlns」属性で指定されます。任意の数の要素<config>サブツリーには「operation」属性を含めることができます。要素の操作は、新しい「操作」属性によってオーバーライドされるまで、その子孫要素に継承されます。サポートされている操作は、「merge」、「replace」、「create」、「delete」、および「remove」です。「削除」操作は、設定データが存在しない場合にエラーが返されないという点で「削除」とは異なります。「operation」属性が指定されていない場合は、マージ操作がデフォルトと見なされます。デフォルトの動作は、オプションの<default-operation>パラメータには、「merge」、「replace」、または「none」があります。

次に例を示します。<edit-config>要求および応答メッセージ。

• MTU 9216 と実行コンフィギュレーションの説明を使用して、「po5」という名前のポートチャネルを作成します。

  <rpc message-id="103" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <edit-config>
          <target>
              <running/>
          </target>
          <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
              <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
                  <intf-items>
                      <aggr-items>
                          <AggrIf-list xc:operation="create">
                              <id>po5</id>
                              <mtu>9216</mtu>
                              <descr>port-channel 5</descr>
                          </AggrIf-list>
                      </aggr-items>
                  </intf-items>
              </System>
          </config>
      </edit-config>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="103">
      <ok/>
  </rpc-reply>
  
  

• ポートチャネルのすべての設定を新しい設定に置き換えます。

  <rpc message-id="104" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <edit-config>
          <target>
              <running/>
          </target>
          <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
              <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
                 <intf-items>
                      <aggr-items>
                          <AggrIf-list xc:operation="replace">
                              <id>po5</id>
                              <mtu>1500</mtu>
                              <adminSt>down</adminSt>
                          </AggrIf-list>
                      </aggr-items>
                  </intf-items>
              </System>
          </config>
      </edit-config>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="104">
      <ok/>
  </rpc-reply>

• ポートチャネルを削除します：

  <rpc message-id="105" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <edit-config>
          <target>
              <running/>
          </target>
          <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
             <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
                  <intf-items>
                      <aggr-items>
                          <AggrIf-list xc:operation="delete">
                              <id>po5</id>
                          </AggrIf-list>
                      </aggr-items>
                  </intf-items>
              </System>
          </config>
      </edit-config>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="105">
      <ok/>
  </rpc-reply>
  
  

<copy-config>

この操作は、ターゲットの構成データストアを、ソース構成データストア全体のコンテンツによって置き換えます。ソースデータストアとターゲットデータストアのパラメータは次のとおりです。<target>に設定します。<source>

次に例を示します。<copy-config>要求および応答メッセージ。

• 実行構成をスタートアップ構成にコピーします。

  <rpc message-id="106" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <copy-config>
          <target>
              <startup/>
          </target>
          <source>
              <running/>
          </source>
      </copy-config>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="106">
      <ok/>
  </rpc-reply>
  
  

• 実行構成を候補構成にコピーします。

  <rpc message-id="107" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <copy-config>
          <target>
              <candidate/>
          </target>
          <source>
              <running/>
          </source>
      </copy-config>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="107">
      <ok/>
  </rpc-reply>
  
  

<lock>

は、<lock>操作を使用すると、クライアントは設定データストアをロックし、他のクライアントがデータストアをロックまたは変更するのを防ぐことができます。クライアントが保持しているロックは、<unlock>セッションの操作または終了。は、<target>パラメータを使用して、ロックするデータストアを指定します。

次に例を示します。<lock>要求および応答メッセージ。

• ロックの取得に成功した場合：

  <rpc message-id="108" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <lock>
          <target>
              <running/>
          </target>
      </lock>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="108">
      <ok/>
  </rpc-reply>
  
  

• 別のセッションですでに使用されているロックの取得に失敗しました。

  <rpc message-id="109" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <lock>
          <target>
              <candidate/>
          </target>
      </lock>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="109">
      <rpc-error>
          <error-type>protocol</error-type>
          <error-tag>lock-denied</error-tag>
          <error-severity>error</error-severity>
          <error-message xml:lang="en">Lock failed, lock is already held</error-message>
          <error-info>
              <session-id>1553704357</session-id>
          </error-info>
      </rpc-error>
  </rpc-reply>
  
  

<unlock>

<unlock> 操作は、以前に <lock> 操作によって取得した構成のロックを解除します。を発行したのと同じセッションのみ<lock>操作では、<unlock>操作を実行します。は、<target>パラメータは、ロック解除するデータストアを指定するために使用されます。

次に例を示します。<unlock>要求および応答メッセージ。

• ロック解除

  <rpc message-id="110" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <unlock>
          <target>
              <candidate/>
          </target>
      </unlock>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="110">
      <ok/>
  </rpc-reply>
  
  

<get>

<get> 操作は、実行中の構成とデバイスの状態情報を取得します。サポートされているパラメータは <filter> です。<filter> パラメータは、実行構成の動作状態データのうち、どの部分を取得するかを指定します。

次に例を示します。要求および応答メッセージ。

• リスト項目の実行コンフィギュレーションおよび動作状態データを取得します。

  <rpc message-id="111" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
          <filter>
              <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
                  <bgp-items>
                      <inst-items>
                          <dom-items>
                              <Dom-list>
                                  <name>default</name>
                              </Dom-list>
                          </dom-items>
                      </inst-items>
                  </bgp-items>
              </System>
          </filter>
      </get>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="111">
      <data>
          <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
              <bgp-items>
                  <inst-items>
                      <dom-items>
                          <Dom-list>
                              <name>default</name>
                              <always>disabled</always>
                              <bestPathIntvl>300</bestPathIntvl>
                              <clusterId>120</clusterId>
                              <firstPeerUpTs>2020-04-20T16:19:03.784+00:00</firstPeerUpTs>
                              <holdIntvl>180</holdIntvl>
                              <id>1</id>
                              <kaIntvl>60</kaIntvl>
                              <mode>fabric</mode>
                              <numEstPeers>0</numEstPeers>
                              <numPeers>0</numPeers>
                              <numPeersPending>0</numPeersPending>
                              <operRtrId>1.2.3.4</operRtrId>
                              <operSt>up</operSt>
                              <pfxPeerTimeout>90</pfxPeerTimeout>
                              <pfxPeerWaitTime>90</pfxPeerWaitTime>
                              <reConnIntvl>60</reConnIntvl>
                              <rtrId>1.2.3.4</rtrId>
                              <vnid>0</vnid>
                              ...
                          </Dom-list>
                      </dom-items>
                  </inst-items>
              </bgp-items>
          </System>
      </data>
  </rpc-reply>
  
  

<validate>

この操作では、候補データストアの設定内容を検証します。これは、実行中のデータストアにコミットする前に、候補データストアで行われた設定変更を検証するのに役立ちます。パラメータは、<candidate/> 。<source>

次に例を示します。<validate>要求および応答メッセージ。

• 候補データストアの内容を検証します：

  <rpc message-id="112" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <validate>
          <source>
              <candidate/>
          </source>
      </validate>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="112">
      <ok/>
  </rpc-reply>
  
  

<commit>

候補構成を実行構成にコミットします。パラメータのない操作は最終と見なされ、元に戻すことはできません。次の場合<commit>が発行されます。<confirmed/>パラメータを使用すると、確定されたコミットと見なされ、別のを使用しない操作パラメータを設定します。つまり、コミットの確認です。確認済みコミットでは、次の 2 つのパラメータを使用できます。<confirm-timeout>および<persist>。は、<confirm-timeout>は、確認されたコミットが元に戻されるまでの秒数です。これにより、確認コミットが発行される前の状態に実行コンフィギュレーションが復元されます。次の場合、<confirm-timeout>が指定されていない場合、デフォルトのタイムアウトは 600 秒です。また、セッションが終了すると、確認されたコミットは元に戻ります。は、<persist>パラメータを使用すると、セッションが終了しても確認されたコミットが保持されます。の値は、<persist>パラメータは、任意のセッションから確認されたコミットを識別するために使用され、<persist-id>後続の確認済みコミットまたは確認コミットのパラメータ。

次に例を示します。<commit>要求および応答メッセージ。

• 候補データストアの内容をコミットします。

  <rpc message-id="113" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <commit/>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="113">
      <ok/>
  </rpc-reply>
  
  

• タイムアウトで確定されたコミット：

  <rpc message-id="114" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <commit>
          <confirmed/>
          <confirm-timeout>120</confirm-timeout>
      </commit>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="114">
      <ok/>
  </rpc-reply>
  
  

• 永続的な確認済みコミットを開始し、永続的な確認済みコミットを確認します。

  <rpc message-id="115" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <commit>
          <confirmed/>
          <persist>ID1234</persist>
      </commit>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="115">
      <ok/>
  </rpc-reply>
  
  <!-- confirm the persistent confirmed-commit, from the same session or another session -->
  <rpc message-id="116" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <commit>
          <persist-id>ID1234</persist-id>
      </commit>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="116">
      <ok/>
  </rpc-reply>
  
  

<cancel-commit>

この操作は、進行中の確認済みコミットをキャンセルします。別のセッションからの確認済みコミットをキャンセルする必要がある場合、<persist-id>パラメータは、<persist>パラメータを設定します。

• 同じセッションから確認されたコミットをキャンセルします。

  <rpc message-id="117" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <cancel-commit/>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="117">
      <ok/>
  </rpc-reply>

<discard-changes>

この操作では、実行コンフィギュレーションの内容にリセットすることによって、候補コンフィギュレーションで行われたコミットされていない変更が破棄されます。パラメータは必要ありません。

次に例を示します。<discard-changes>要求および応答メッセージ。

• 候補データストアで行われた変更を破棄します。

  <rpc message-id="118" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <discard-changes/>
  </rpc>
  
  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="118">
      <ok/>
  </rpc-reply>
  
  

ncclient を使用した Cisco NX-OS の接続

ncclient は、NETCONF クライアント用の Python ライブラリです。次に、ncclient Manager API から Cisco NX-OS への接続を確立する方法の例を示します。

device = {
    "address": "10.10.10.10",
    "netconf_port": 830,
    "username": "admin",
    "password": "cisco"
}
with manager.connect(host = device["address"],
                         port = device["netconf_port"],
                         username = device["username"],
                         password = device["password"],
                         hostkey_verify = False) as m:
    # do your stuff

サンドボックスを使用した NETCONF ペイロードの生成

有効にするには、「NXAPI 開発者サンドボックス」セクションを参照してください。NETCONF のペイロードを生成するには、メソッドを RESTCONF（Yang）に変更し、メッセージ形式を XML に変更します。テキストウィンドウに変換する必要があるコマンドを入力し、[変換（Convert）] をクリックすると、同等のペイロードが [要求（Request）] テキストボックスに表示されます。

Cisco NX-OS からの設定データの取得

次に、ncclient を使用して Cisco NX-OS から BGP 設定を取得する方法の例を示します。

from ncclient import manager
import sys
from lxml import etree

device = {
    "address": "nexus",
    "netconf_port": 830,
    "username": "admin",
    "password": "cisco!"
}


# create a main() method
def main():
    bgp_dom = """
    <filter type="subtree">
        <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
                <bgp-items>
                    <inst-items>
                        <dom-items>
                            <Dom-list/>
                        </dom-items>
                    </inst-items>
                </bgp-items>
        </System>
    </filter>
    """

    with manager.connect(host=device["address"],
                         port=device["netconf_port"],
                         username=device["username"],
                         password=device["password"],
                         hostkey_verify=False) as m:

        # Collect the NETCONF response
        netconf_response = m.get_config(source='running', filter=bgp_dom)
        # Parse the XML and print the data
        xml_data = netconf_response.data_ele
        print(etree.tostring(xml_data, pretty_print=True).decode("utf-8"))


if __name__ == '__main__':
    sys.exit(main())

Cisco NX-OS からの実行コンフィギュレーションおよび運用データの取得

次に、Cisco NX-OS 上のすべての物理インターフェイスのインターフェイス カウンタを取得する例を示します。

from ncclient import manager
import sys
from lxml import etree

device = {
    "address": "nexus",
    "netconf_port": 830,
    "username": "admin",
    "password": "cisco"
}


def main():

    intf_ctr_filter = """
    <filter>
        <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
            <intf-items>
                <phys-items>
                <PhysIf-list>
                    <dbgIfIn-items/>
                    <dbgIfOut-items/>
                </PhysIf-list>
                </phys-items>
            </intf-items>
        </System>
    </filter>"""

    with manager.connect(host=device["address"],
                         port=device["netconf_port"],
                         username=device["username"],
                         password=device["password"],
                         hostkey_verify=False) as m:

        # Collect the NETCONF response
        netconf_response = m.get(filter=intf_ctr_filter)
        # Parse the XML and print the data
        xml_data = netconf_response.data_ele
        print(etree.tostring(xml_data, pretty_print=True).decode("utf-8"))

if __name__ == '__main__':
    sys.exit(main())

NETCONF を使用した新しい設定の作成

次に、ncclient の edit config を使用して、名前付きの VLAN 100 を作成する方法の例を示します。

from ncclient import manager
import sys
from lxml import etree

device = {
    "address": "nexus",
    "netconf_port": 830,
    "username": "admin",
    "password": "cisco"
}


def main():
    add_vlan = """
    <config>
      <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
        <bd-items>
          <bd-items>
            <BD-list>
              <fabEncap>vlan-100</fabEncap>
              <name>inb_mgmt</name>
            </BD-list>
          </bd-items>
        </bd-items>
      </System>
    </config>
    """


    with manager.connect(host=device["address"],
                         port=device["netconf_port"],
                         username=device["username"],
                         password=device["password"],
                         hostkey_verify=False) as m:

        # create vlan with edit_config
        netconf_response = m.edit_config(target="running", config=add_vlan)
        print(netconf_response)

if __name__ == '__main__':
    sys.exit(main())

NETCONF を使用した設定の削除

次に、Cisco NX-OS からループバック インターフェイスを削除する例を示します。

from ncclient import manager
import sys
from lxml import etree

device = {
    "address": "nexus",
    "netconf_port": 830,
    "username": "admin",
    "password": "cisco"
}


def main():
    remove_loopback = """
    <config>
      <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
        <intf-items>
          <lb-items>
            <LbRtdIf-list operation="delete">
              <id>lo10</id>
            </LbRtdIf-list>
          </lb-items>
        </intf-items>
      </System>
    </config>"""


    with manager.connect(host=device["address"],
                         port=device["netconf_port"],
                         username=device["username"],
                         password=device["password"],
                         hostkey_verify=False) as m:

        # create vlan with edit_config
        netconf_response = m.edit_config(target="running", config=remove_loopback)

        print(netconf_response)

if __name__ == '__main__':
    sys.exit(main())