XML 管理インターフェイス

ここでは、次の内容について説明します。

XML 管理インターフェイスについて

XML 管理インターフェイスについて

XML 管理インターフェイスを使用してデバイスを構成できます。インターフェイスは XML ベースのネットワーク構成プロトコル（NETCONF）を使用します。これにより、デバイスを管理し、インターフェイスを介して XML 管理ツールまたはプログラムと通信できます。NETCONF の Cisco NX-OS 導入では、デバイスとの通信に Secure Shell（SSH）セッションを使用する必要があります。

NETCONF は、リモート プロシージャ コール（RPC）メッセージ内にデバイス構成要素を含めることができる XML Schema（XSD）を使用して導入されます。RPC メッセージ内から、デバイスに実行させたいコマンドのタイプに一致する NETCONF 操作の 1 つを選択します。NETCONF を使用して、デバイスで CLI コマンドのセット全体を設定できます。NETCONF の使用については、NETCONF XML インスタンスの作成 と RFC 4741 を参照してください。

SSH を介した NETCONF の使用の詳細については、RFC 4742 を参照してください。

このセクションは、次のトピックで構成されています。

NETCONF レイヤ

NETCONF レイヤは次のとおりです：

Table 1. NETCONF レイヤ

レイヤ

例

トランスポート プロトコル

SSHv2

RPC

<rpc>、<rpc-reply>

運用者

<get-config>、<edit-config>

コンテンツ

show または 構成 コマンド

以下は、4 つの NETCONF レイヤの説明です。

  • SSH トランスポート プロトコル — クライアントとサーバ間の安全な暗号化接続を提供します。
  • RPC タグ：リクエスタからの構成コマンドと、それに対応する XML サーバからの応答を導入します。
  • NETCONF 操作タグ：構成コマンドのタイプを示します。
  • 格納ファイル — 構成する機能の XML 表現を示します。

SSH xmlagent

デバイス ソフトウェアは、SSH バージョン 2 を介した NETCONF をサポートする xmlagent と呼ばれる SSH サービスを提供します。


Note
xmlagent サービスは、Cisco NX-OS ソフトウェアでは XML サーバと呼ばれます。

NETCONF over SSH は、クライアントと XML サーバ間の hello メッセージの交換から始まります。最初の交換の後、クライアントは XML 要求を送信し、サーバは XML 応答で応答します。クライアントとサーバは、文字シーケンス > で要求と応答を終了します。この文字シーケンスは XML では有効ではないため、クライアントとサーバはメッセージがいつ終了するかを解釈でき、通信の同期が維持されます。

この NETCONF XML インスタンスの作成 セクションでは、使用できる XML 構成インスタンスを定義する XML スキーマについて説明します。

XML 管理インターフェイスのライセンス要件

製品

製品

Cisco NX-OS

XML 管理インターフェースにはライセンスは必要ありません。ライセンス パッケージに含まれていない機能は Cisco NX-OS イメージにバンドルされており、無料で提供されます。NX-OS ライセンス方式の詳細については、『Cisco NX-OS Licensing Guide』を参照してください。

XML 管理インターフェイスを使用するための前提条件

XML 管理インターフェイスには、次の前提条件があります。

  • クライアント PC に SSHv2 をインストールする必要があります。
  • クライアント PC に NETCONF over SSH をサポートする XML 管理ツールをインストールする必要があります。
  • デバイスの XML サーバに適切なオプションを設定する必要があります。

XML 管理インターフェイスを使用

このセクションでは、XML 管理インターフェイスを手動で構成して使用する方法について説明します。デバイスのデフォルト設定で XML 管理インターフェイスを使用します。

SSH および XML サーバ オプションの構成

デバイス上デフォルトで SSH サーバがイネーブル化されています。SSH を無効にする場合は、クライアント PC で SSH セッションを開始する前に有効にする必要があります。

XML サーバ オプションを構成して、同時セッションの数とアクティブ セッションのタイムアウトを制御できます。XML ドキュメントの検証を有効にして、XML セッションを終了することもできます。


Note
XML サーバ タイムアウトはアクティブ セッションだけに適用できます。

SSH の構成の詳細については、ご使用のプラットフォームの Cisco NX-OS セキュリティ構成ガイドを参照してください。

XML コマンドの詳細については、ご使用のプラットフォームの Cisco NX-OS システム マネジメント 構成ガイドを参照してください。

SSH セッションを開始

次のようなコマンドを使用して、クライアント PC で SSHv2 セッションを開始できます。 


ssh2 username@ip-address -s xmlagent

ログイン ユーザー名、デバイスの IP アドレス、接続するサービスを入力します。xmlagent サービスは、デバイス ソフトウェアでは XML サーバと呼ばれます。


Note
SSH コマンドの構文は、クライアント PC の SSH ソフトウェアによって異なることがあります。

XML サーバから hello メッセージを受信しない場合は、次の条件を確認してください。

  • デバイスで SSH サーバがイネーブルになっています。
  • XML サーバの max-sessions オプションは、デバイスへの SSH 接続の数をサポートするのに十分です。
  • デバイス上の現用系 XML サーバ セッションの一部が使用されていません。

Hello メッセージを送信

XML サーバーへの SSH セッションを開始すると、サーバはすぐに hello メッセージで応答し、サーバーの機能をクライアントに通知しますサーバーが他の要求を処理する前に、hello メッセージを使用してサーバーに機能をアドバタイズする必要があります。XML サーバーは基本機能のみをサポートし、クライアントからの基本機能のみのサポートを想定しています。

以下は、サーバーとクライアントからのサンプルの hello メッセージです。


Note
すべての XML ドキュメントは、]]>]]> で終了して、SSH 経由の NETCONF で同期がサポートされるようにする必要があります。

サーバーからの hello メッセージ

<?xml version="1.0"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
  <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
  </capabilities>
  <session-id>25241</session-id>
</hello>]]>]]>

クライアントからの hello メッセージ



<?xml version="1.0"?>
<nc:hello xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <nc:capabilities>
  <nc:capability>urn:ietf:params:xml:ns:netconf:base:1.0</nc:capability>
  </nc:capabilities>
</nc:hello>]]>]]>

XSD ファイルの取得

Procedure

Step 1

ブラウザから、次の URL にあるシスコ ソフトウェア ダウンロード サイトに移動します。

http://www.cisco.com/cisco/web/support/JP/loc/download/index.html

ソフトウェア ダウンロード ページが開きます。

Step 2

[製品の選択] リストで、Switches > Data Center Switches > [プラットフォーム（platform）] > [モデル（model）]を選択します。

Step 3

登録済みの Cisco ユーザーとしてまだログインしていない場合は、ここでログインするようにプロンプトします。

Step 4

ソフトウェア タイプの選択リストから、 NX-OS XML Schema Definition. を選択します。

Step 5

目的のリリースを見つけて Download. をクリックします

Step 6

リクエストをされたら、強力な暗号化ソフトウェアイメージをダウンロードするための資格を適用するには、次の手順を実行します。

Cisco エンド ユーザー使用許諾契約書が開きます。

Step 7

次の手順に従って、Agree をクリックしてファイルを PC にダウンロードします。

XML ドキュメントを XML サーバに送信する

コマンド シェルで開いた SSH セッションを介して XML ドキュメントを XML サーバに送信するには、エディターから XML テキストをコピーして、SSH セッションに貼り付けます。通常、自動化されたメソッドを使用して XML ドキュメントを XML サーバに送信しますが、この方法で XML サーバへの SSH 接続を確認できます。

このメソッドの注意事項に従ってください：

  • コマンド シェル出力で hello メッセージ テキストを検索して、SSH セッションを開始した直後に XML サーバが hello メッセージを送信したことを確認します。
  • XML 要求を送信する前に、クライアントの hello メッセージを送信します。XML サーバは hello 応答をすぐに送信するため、クライアント hello メッセージを送信した後、追加の応答は送信されません。
  • XML ドキュメントは常に文字シーケンス ]]>]]> で終了します。

NETCONF XML インスタンスの作成

RPC タグおよび NETCONF 操作タグ内に XML デバイス要素を囲むことにより、NETCONF XML インスタンスを作成できます。XML デバイス要素は、使用可能な CLI コマンドを XML フォーマットで囲む機能ベースの XML スキーマ定義（XSD）ファイルで定義されます。

以下は、フレームワーク コンテキストの NETCONF XML リクエストで使用されるタグです。タグ ラインは次のレター コードでマークキングされています：

  • X — XML 宣言
  • R — RPC リクエスト タグ
  • N — NETCONF 操作タグ
  • D — デバイス タグ

NETCONF XML フレームワークのコンテキスト

X <?xml version="1.0"?>
R <nc:rpc message-id="1" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" R xmlns="http://www.cisco.com/nxos:1.0:nfcli”> N <nc:get> N <nc:filter type="subtree">
D <show>
D <xml>
D <server>
D <status/>
D </server>
D </xml>
D </show>
N </nc:filter>
N </nc:get>
R </nc:rpc>]]>]]>

Note
任意の XML エディタまたは XML 管理インターフェイス ツールを使用して、XML インスタンスを作成する必要があります。

RPC リクエスト タグ rpc

すべての NETCONF XML インスタンスは、RPC リクエスト タグ <rpc> で開始する必要があります。RPC リクエスト タグ<rpc> の例は、<rpc> 要素を必須の message-id 属性と共に示しています。message-id 属性は、<rpc-reply>リクエストと返信を関連付けるために使用できます。<rpc> ノードもまた、次の XML 名前空間宣言も含まれています。

  • NETCONF 名前空間宣言：「urn:ietf:params:xml:ns:netconf:base:1.0」名前空間で定義されている <rpc> と NETCONF タグは、netconf.xsd スキーマ ファイルに存在します。
  • デバイスの名前空間宣言：<rpc> と NETCONF タグによってカプセル化されたデバイス タグは、他の名前空間で定義されています。デバイスの名前空間は機能指向です。Cisco NX-OS 機能タグは、さまざまな名前空間で定義されています。RPC リクエスト タグ <rpc> は、nfcli 機能を使用する例です。デバイスの名前空間が「xmlns=http://www.cisco.com/nxos:1.0:nfcli」であることを宣言しています。 nfcli.xsd には、この名前空間の定義が含まれています。詳細については、「XSD ファイルの取得」に関するセクションを参照してください。
RPC タグ リクエスト
<nc:rpc message-id="315" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns=http://www.cisco.com/nxos:1.0:nfcli">
...
</nc:rpc>]]>]]>
構成リクエスト

以下は、構成リクエストの例です。 

<?xml version="1.0"?>
<nc:rpc message-id="16" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"   xmlns="http://www.cisco.com/nxos:1.0:if_manager">
  <nc:edit-config>
    <nc:target>
      <nc:running/>
    </nc:target>
    <nc:config>
      <configure>
        <__XML__MODE__exec_configure>
          <interface>
            <ethernet>
              <interface>2/30</interface>
              <__XML__MODE_if-ethernet>
                <__XML__MODE_if-eth-base>
                  <description>
                    <desc_line>Marketing Network</desc_line>
                  </description>
                </__XML__MODE_if-eth-base>
              </__XML__MODE_if-ethernet>
            </ethernet>
          </interface>
        </__XML__MODE__exec_configure>
      </configure>
    </nc:config>
  </nc:edit-config>
</nc:rpc>]]>]]>

__XML__MODE タグは、NETCONF エージェントによって内部的に使用されます。一部のタグは、特定の __XML__MODE の子としてのみ存在します。スキーマ ファイルを調べると、XML で CLI コマンドを表すタグにつながる正しいモード タグを見つけることができます。

NETCONF 動作タグ

NETCONF は、次の構成動作を提供します。

Table 2. Cisco NX-OS の NETCONF 動作

NETCONF 動作

説明

例

close-session

XML サーバー セッションを閉じます。

NETCONF クロース セッション インスタンス

commit

候補構成の現在のコンテンツに、実行構成を設定します。

NETCONF コミット インスタンス - 候補構成機能

confirmed-commit

指定された時間に構成をコミットするためのパラメータを提供します。確認タイムアウト期間内にこの操作の後にコミット操作が行われない場合、構成は確認済みコミット操作の前の状態に戻ります。

NETCONF Confirmed-commit インスタンス

copy-config

送信元構成データストアのコンテンツをターゲット データストアにコピーします。

NETCONF copy-config インスタンス

delete-config

操作がサポートされていません。

—

edit-config

デバイスの実行構成の機能を構成します。この動作は、構成コマンドに使用します。

NETCONF edit-config インスタンス

NETCONF rollback-on-error インスタンス

get

デバイスから構成情報を受信します。この操作は show コマンドに使用します。データのソースは実行コンフィギュレーションです。

NETCONF XML インスタンスの作成

get-config

構成の全体または一部を取得する

NETCONF get-config インスタンス

kill-session

指定した XML サーバー セッションを閉じます。自分のセッションを閉じることはできません。close-session NETCONF 動作を参照してください。

NETCONF キルセッション インスタンス

ロック

クライアントがデバイスの構成システムをロックすることができます

NETCONF ロック インスタンス

unlock

セッションが発行した構成ロックを解放します。

NETCONF ロック解除インスタンス

検証

構成をデバイスに適用する前に、構成候補のシンタックス エラーおよびセマンティクス エラーをチェックします。

NETCONF 検証機能インスタンス

デバイスタグ

XML デバイス要素は、使用可能な CLI コマンドを XML フォーマットで表します。機能固有のスキーマ ファイルには、その特定の機能の CLI コマンドの XML タグが含まれています。「XSD ファイルの取得」の項を参照してください。

このスキーマを使用して、XML インスタンスを構築することができます。次の例では、ビルド NETCONF XML インスタンスの作成 に使用された nfcli.xsd スキーマ ファイルの関連部分が示されています。

次の例は、XML デバイス タグを示しています。

xml デバイス タグを表示します。
<xs:element name="show" type="show_type_Cmd_show_xml"/>
<xs:complexType name="show_type_Cmd_show_xml">
<xs:annotation>
<xs:documentation>to display xml agent information</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice maxOccurs="1">
<xs:element name="xml" minOccurs="1" type="xml_type_Cmd_show_xml"/>
<xs:element name="debug" minOccurs="1" type="debug_type_Cmd_show_debug"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="xpath-filter" type="xs:string"/>
<xs:attribute name="uses-namespace" type="nxos:bool_true"/>
</xs:complexType>

次の例は、サーバ ステータス デバイス タグを示しています。

サーバ ステータス デバイス タグ
<xs:complexType name="xml_type_Cmd_show_xml">
<xs:annotation>
<xs:documentation>xml agent</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="server" minOccurs="1" type="server_type_Cmd_show_xml"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="server_type_Cmd_show_xml">
<xs:annotation>
<xs:documentation>xml agent server</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice maxOccurs="1">
<xs:element name="status" minOccurs="1" type="status_type_Cmd_show_xml"/>
<xs:element name="logging" minOccurs="1" type="logging_type_Cmd_show_logging_facility"/>
</xs:choice>
</xs:sequence>
</xs:complexType>

次の例は、デバイス タグの応答を示しています。

デバイスタグの応答
<xs:complexType name="status_type_Cmd_show_xml">
<xs:annotation>
<xs:documentation>display xml agent information</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="__XML__OPT_Cmd_show_xml___readonly__" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="og_Cmd_show_xml___readonly__" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:group name="og_Cmd_show_xml___readonly__">
<xs:sequence>
<xs:element name="__readonly__" minOccurs="1" type="__readonly___type_Cmd_show_xml"/>
</xs:sequence>
</xs:group>
<xs:complexType name="__readonly___type_Cmd_show_xml">
<xs:sequence>
<xs:group ref="bg_Cmd_show_xml_operational_status" maxOccurs="1"/>
<xs:group ref="bg_Cmd_show_xml_maximum_sessions_configured" maxOccurs="1"/>
<xs:group ref="og_Cmd_show_xml_TABLE_sessions" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>

Note
「__XML__OPT_Cmd_show_xml___readonly__」はオプションです。このタグは応答を表します。応答の詳細については、RPC 応答タグ のセクションを参照してください。

<get> を実行するために使用できるタグを見つけるための | XML オプション を使用できます。以下は | XML オプションの例です。

XML の例 
Switch#> show xml server status | xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:nfcli">
<nf:data>
<show>
<xml>
<server>
<status>
<__XML__OPT_Cmd_show_xml___readonly__>
<__readonly__>
<operational_status>
<o_status>enabled</o_status>
</operational_status>
<maximum_sessions_configured>
<max_session>8</max_session>
</maximum_sessions_configured>
</__readonly__>
</__XML__OPT_Cmd_show_xml___readonly__>
</status>
</server>
</xml>
</show>
</nf:data>
</nf:rpc-reply>
]]>]]>

この応答から、このコンポーネントで操作を実行するタグを定義する名前空間は http://www.cisco.com/nxos:1.0:nfcli であり、nfcli.xsd ファイルを使用してこの機能の要求を作成できることがわかります。

NETCONF 操作タグとデバイス タグを RPC タグで囲むことができます。</rpc>end-tag の後に XML 終了文字シーケンスが続きます。

拡張された NETCONF の操作

Cisco NX-OS は、<exec-command> という名前の<rpc> 操作をサポートします。この操作により、クライアント アプリケーションは CLI 構成と表示コマンドを送信し、それらのコマンドへの応答を XML タグとして受信できます。

以下は、インターフェイスの構成に使用されるタグの例です。タグ回線は、次の文字コードでマークされます。

  • X — XML 宣言
  • R — RPC リクエスト タグ
  • EO — 拡張操作

<exec-command> を通して送信される構成 CLI コマンド 


X <?xml version="1.0"?>
R <nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="3">
EO <nxos:exec-command>
EO <nxos:cmd>conf t ; interface ethernet 2/1 </nxos:cmd>
EO <nxos:cmd>channel-group 2000 ; no shut; </nxos:cmd>
EO </nxos:exec-command>
R </nf:rpc>]]>]]>

操作に対する応答は次のとおりです。

<exec-command>を通して送信された CLI コマンドへの応答 


<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="3">
<nf:ok/>
</nf:rpc-reply>
]]>]]>

次の例は、<exec-command> データの取得に使用できます。

<exec-command> を通して送信される表示 CLI コマンド


<?xml version="1.0"?>
<nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110">
<nxos:exec-command>
<nxos:cmd>show interface brief</nxos:cmd>
</nxos:exec-command>
</nf:rpc>]]>]]>

以下は操作に対する反応です。

<exec-command> を通して送信された show CLI コマンドへの応答 


<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" xmlns:mod="http://www.cisco.com/nxos:1.0:if_manager" message-id="110">
<nf:data>
<mod:show>
<mod:interface>
<mod:__XML__OPT_Cmd_show_interface_brief___readonly__>
<mod:__readonly__>
<mod:TABLE_interface>
<mod:ROW_interface>
<mod:interface>mgmt0</mod:interface>
<mod:state>up</mod:state>
<mod:ip_addr>172.23.152.20</mod:ip_addr>
<mod:speed>1000</mod:speed>
<mod:mtu>1500</mod:mtu>
</mod:ROW_interface>
<mod:ROW_interface>
<mod:interface>Ethernet2/1</mod:interface>
<mod:vlan>--</mod:vlan>
<mod:type>eth</mod:type>
<mod:portmode>routed</mod:portmode>
<mod:state>down</mod:state>
<mod:state_rsn_desc>Administratively down</mod:state_rsn_desc>
<mod:speed>auto</mod:speed>
<mod:ratemode>D</mod:ratemode>
</mod:ROW_interface>
</mod:TABLE_interface>
</mod:__readonly__>
</mod:__XML__OPT_Cmd_show_interface_brief___readonly__>
</mod:interface>
</mod:show>
</nf:data>
</nf:rpc-reply>
]]>]]>

次の表に、操作タグの詳細な説明を示します。

Table 3. タグ

タグ

説明

<exec-command>

CLI コマンドの実行

<cmd>

CLI コマンドが含まれています。コマンドは、show または構成コマンドです。複数の構成コマンドは、セミコロン「;」を使用して区切ります。複数の show コマンドはサポートされていません。複数の構成コマンドを異なる <cmd> タグを同じリクエストの一部として送信できます。詳細については、[<exec-command>を通して送信される構成 CLI コマンド（Configuration CLI Commands Sent Through <exec-command>）] の例を参照してください。

を介して送信される構成コマンドへの応答 <cmd> タグは次のとおりです。

  • <nf:ok>：すべての構成コマンドが正常に実行されました。
  • <nf:rpc-error>：一部のコマンドが機能不全になりました。操作は最初のエラーで停止し、<nf:rpc-error> サブツリー は、機能不全になった構成に関する詳細情報を提供します。機能不全になったコマンドの前に実行された構成は、実行中の構成に適用されていることに注意してください。

次の例は、機能不全になった構成を示しています：

機能不全の構成 


<?xml version="1.0"?>
<nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="3">
<nxos:exec-command>
<nxos:cmd>configure terminal ; interface ethernet2/1 </nxos:cmd>
<nxos:cmd>ip address 1.1.1.2/24 </nxos:cmd>
<nxos:cmd>no channel-group 2000 ; no shut; </nxos:cmd>
</nxos:exec-command>
</nf:rpc>]]>]]>
<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="3">
<nf:rpc-error>
<nf:error-type>application</nf:error-type>
<nf:error-tag>invalid-value</nf:error-tag>
<nf:error-severity>error</nf:error-severity>
<nf:error-message>Ethernet2/1: not part of port-channel 2000
</nf:error-message>
<nf:error-info>
<nf:bad-element>cmd</nf:bad-element>
</nf:error-info>
</nf:rpc-error>
</nf:rpc-reply>
]]>]]>

コマンドの実行により、インターフェイスの IP アドレスは設定されますが、管理状態は変更されません（no shut コマンドは実行されません）。管理状態が変更されない理由は、no port-channel 2000 コマンドがエラーになるためです。

は <rpc-reply> を介して送信される show コマンドの結果 <cmd> show コマンドの XML 出力を含むタグ。

構成コマンドと表示コマンドを同じに組み合わせることはできません<exec-command> インスタンス。次の例は、同じインスタンスで組み合わされた構成と show コマンドを示しています。

構成コマンドと show コマンドの組み合わせ


<?xml version="1.0"?>
<nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110">
<nxos:exec-command>
<nxos:cmd>conf t ; interface ethernet 2/1 ; ip address 1.1.1.4/24 ; show xml
server status </nxos:cmd>
</nxos:exec-command>
</nf:rpc>]]>]]>
<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110">
<nf:rpc-error>
<nf:error-type>application</nf:error-type>
<nf:error-tag>invalid-value</nf:error-tag>
<nf:error-severity>error</nf:error-severity>
<nf:error-message>Error: cannot mix config and show in exec-command. Config cmds
before the show were executed.
Cmd:show xml server status</nf:error-message>
<nf:error-info>
<nf:bad-element>cmd</nf:bad-element>
</nf:error-info>
</nf:rpc-error>
</nf:rpc-reply>
]]>]]>

show コマンドは、それ自体で送信する必要があります <exec-command> 次の例に示すようなインスタンス。

送信された CLI コマンドを表示 <exec-command>


<?xml version="1.0"?>
<nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110">
<nxos:exec-command>
<nxos:cmd>show xml server status ; show xml server status </nxos:cmd>
</nxos:exec-command>
</nf:rpc>]]>]]>
<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nxos="http://www.cisco.com/nxos:1.0" message-id="110">
<nf:rpc-error>
<nf:error-type>application</nf:error-type>
<nf:error-tag>invalid-value</nf:error-tag>
<nf:error-severity>error</nf:error-severity>
<nf:error-message>Error: show cmds in exec-command shouldn't be followed by anything
</nf:error-message>
<nf:error-info>
<nf:bad-element><cmd></nf:bad-element>
</nf:error-info>
</nf:rpc-error>
</nf:rpc-reply>
]]>]]>

NETCONF 応答

クライアントによって送信されるすべての XML 要求に対して、XML サーバーは RPC 応答タグ <rpc-reply> で囲まれた XML 応答を送信します。

ここでは、次の内容について説明します。

RPC 応答タグ

次の例は、RPC 応答タグ <rpc-reply> を表示しています。

RPC 応答エレメント
<nc:rpc-reply message-id=”315” xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns=http://www.cisco.com/nxos:1.0:nfcli">
<ok/>
</nc:rpc-reply>]]>]]>

<ok> 、<data> 、そして <rpc-error> の要素は RPC 応答に表示される可能性があります。次の表は、<rpc-reply> タグ。

Table 4. RPC 応答エレメント

要素

説明

<ok>

RPC 要求は正常に完了しました。この要素は、応答でデータが返されない場合に使用されます。

<data>

RPC 要求は正常に完了しました。RPC リクエストに関連するデータは、<data> 要素。

<rpc-error>

RPC 要求が失敗しました。エラー情報は、<rpc-error> 要素。

データタグにカプセル化されたタグの解釈

によってカプセル化されたデバイス タグ <data> タグには、リクエストとそれに続くレスポンスが含まれます。クライアント アプリケーションは、<readonly> タグ。次に、例を示します。

RPC 応答データ
<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:if_manager">
<nf:data>
<show>
<interface>
<__XML__OPT_Cmd_show_interface_brief___readonly__>
<__readonly__>
<TABLE_interface>
<ROW_interface>
<interface>mgmt0</interface>
<state>up</state>
<ip_addr>xx.xx.xx.xx</ip_addr>
<speed>1000</speed>
<mtu>1500</mtu>
</ROW_interface>
<ROW_interface>
<interface>Ethernet2/1</interface>
<vlan>--</vlan>
<type>eth</type>
<portmode>routed</portmode>
<state>down</state>
<state_rsn_desc>Administratively down</state_rsn_desc>
<speed>auto</speed>
<ratemode>D</ratemode>
</ROW_interface>
</TABLE_interface>
</__readonly__>
</__XML__OPT_Cmd_show_interface_brief___readonly__>
</interface>
</show>
</nf:data>
</nf:rpc-reply>
]]>]]>

<__XML__OPT.*> と <__XML__BLK.*> はレスポンスに表示され、リクエストで使用されることもあります。これらのタグは NETCONF エージェントによって使用され、<__readonly__> タグの後の応答に存在します。これらは要求で必要であり、CLI コマンドを表す XML タグに到達するためにスキーマ ファイルに従って追加する必要があります。

サンプル XML インスタンスに関する情報

XML インスタンスの例

このセクションでは、次の XML インスタンスの例を示します：

NETCONF クロース セッション インスタンス

次の例は、セッション終了要求とそれに続くセッション終了応答を表示しています。

クローズ セッション リクエスト

<?xml version="1.0"?>
<nc:rpc message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0">
<nc:close-session/>
</nc:rpc>]]>]]>

クローズ セッションの応答

<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0" message-id="101">
<nc:ok/>
</nc:rpc-reply>]]>]]>

NETCONF キルセッション インスタンス

次の例は、キルセッション要求とそれに続く kill-session レスポンスを示しています。

キルセッション要求

<nc:rpc message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0">
<nc:kill-session>
<nc:session-id>25241</nc:session-id>
</nc:kill-session>
</nc:rpc>]]>]]>

キルセッション要求

<nc:rpc message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0">
<nc:kill-session>
<nc:session-id>25241</nc:session-id>
</nc:kill-session>
</nc:rpc>]]>]]>

NETCONF copy-config インスタンス

次の例は、copy-config 要求とそれに続く copy-config 応答を示しています。

copy-config リクエスト


<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<running/>
</target>
<source>
<url>https://user@example.com:passphrase/cfg/new.txt</url>
</source>
</copy-config>
</rpc>

copy-config の応答

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

NETCONF edit-config インスタンス

次の例は、NETCONF edit-config の使用を示しています。

edit-config リクエスト


<?xml version="1.0"?>
<nc:rpc message-id="16" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:if_manager">
<nc:edit-config>
<nc:target>
<nc:running/>
</nc:target>
<nc:config>
<configure>
<__XML__MODE__exec_configure>
<interface>
<ethernet>
<interface>2/30</interface>
<__XML__MODE_if-ethernet>
<__XML__MODE_if-eth-base>
<description>
<desc_line>Marketing Network</desc_line>
</description>
</__XML__MODE_if-eth-base>
</__XML__MODE_if-ethernet>
</ethernet>
</interface>
</__XML__MODE__exec_configure>
</configure>
</nc:config>
</nc:edit-config>
</nc:rpc>]]>]]>

edit-config 応答


<?xml version="1.0"?>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:if_manager" message-id="16">
<nc:ok/>
</nc:rpc-reply>]]>]]>

edit-config の operation 属性は、指定された操作が実行される構成のポイントを識別します。操作属性が指定されていない場合、構成は既存の構成データ ストアにマージされます。操作属性には、次の値を指定できます。

  • create
  • merge
  • delete

次の例は、実行中の構成からインターフェイス Ethernet0/0 の構成を削除する方法を示しています。

edit-config: 削除操作の要求


xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://example.com/schema/1.2/config">
<interface xc:operation="delete">
<name>Ethernet0/0</name>
</interface>
</top>
</config>
</edit-config>
</rpc>]]>]]>

edit-config への応答: 削除操作


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

NETCONF get-config インスタンス

次の例は、NETCONF get-config の使用を示しています。

サブツリー全体を取得するための Get-config リクエスト

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
</get-config>
</rpc>]]>]]>

クエリの結果を含む Get-config 応答

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>root</name>
<type>superuser</type>
<full-name>Charlie Root</full-name>
<company-info>
<dept>1</dept>
<id>1</id>
</company-info>
</user>
<!-- additional <user> elements appear here... -->
</users>
</top>
</data>
</rpc-reply>]]>]]>

NETCONF ロック インスタンス

次の例は、NETCONF ロック操作の使用を示しています。

次の例は、ロック要求、成功の応答、および失敗した試行への応答を示しています。

ロック要求


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

ロック取得成功時の応答

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <!-- lock succeeded -->
</rpc-reply>]]>]]>

ロックの取得に失敗した場合の応答

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error> <!-- lock failed -->
<error-type>protocol</error-type>
<error-tag>lock-denied</error-tag>
<error-severity>error</error-severity>
<error-message>
Lock failed, lock is already held
</error-message>
<error-info>
<session-id>454</session-id>
<!-- lock is held by NETCONF session 454 -->
</error-info>
</rpc-error>
</rpc-reply>]]>]]>

NETCONF ロック解除インスタンス

次の例は、NETCONF ロック解除操作の使用を示しています。

ロック解除要求 


<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>

ロック解除要求への応答


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

NETCONF コミット インスタンス - 候補構成機能

次の例は、操作をコミットと返信をコミットを示しています。

操作をコミット


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

返信をコミット

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

NETCONF Confirmed-commit インスタンス

次の例は、confirmed-commit 操作とconfirmed-commit 応答を表示しています。

確認されたコミット リクエスト


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

確認されたコミット 応答


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

NETCONF rollback-on-error インスタンス

次の例は、エラー機能での NETCONF ロールバックの使用を示しています。文字列 urn:ietf:params:netconf:capability:rollback-on-error:1.0 は、機能を識別します。

次の例は、エラー時のロールバックとこの要求への応答を構成する方法を示しています。

Rollback-on-error 機能


<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>100000</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>]]>]]>

Rollback-on-error リスポンス


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

NETCONF 検証機能インスタンス

次の例は、NETCONF 検証機能の使用を示しています。文字列 urn:ietf:params:netconf:capability:validate:1.0 は機能を識別します。

リクエストの検証


xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>]]>]]>

リクエストの検証への応答


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

その他の参考資料

ここでは、XML 管理インターフェイスの実装に関する追加情報について説明します。

標準

標準

タイトル

この機能がサポートする新しい規格または変更された規格はありません。既存の規格のサポートは、この機能によって変更されていません。

—

RFC

RFC

タイトル

RFC 4741

NETCONF Configuration Protocol

RFC 4742

セキュアシェル（SSH）経由の NETCONF 構成プロトコルの使用