NX-API REST

この章は次のトピックで構成されています。

About NX-API REST

NX-API REST

In Release 7.0(3)I2(1), the NX-API REST SDK has been added.

On Cisco Nexus switches, configuration is performed using command-line interfaces (CLIs) that run only on the swtich. NX-API REST improves the accessibility of the Cisco Nexus configuration by providing HTTP/HTTPS APIs that:

  • Make specific CLIs available outside of the switch.

  • Enable configurations that would require issuing many CLI commands by combining configuration actions in relatively few HTTP/HTTPS operations.

NX-API REST supports show commands, basic and advanced switch configurations, and Linux Bash.

NX-API REST uses HTTP/HTTPS as its transport. CLIs are encoded into the HTTP/HTTPS POST body. The NX-API REST backend uses the Nginx HTTP server. The Nginx process,and all of its children processes, are under Linux cgroup protection where the CPU and memory usage is capped. The NX-API processes are part of the cgroup ext_ser_nginx, which is limited to 2,147,483,648 bytes of memory. If the Nginx memory usage exceeds the cgroup limitations, the Nginx process is restarted and the NX-API configuration (the VRF, port, and certificate configurations) is restored.

For more information about the Cisco Nexus 3000 and 9000 Series NX-API REST SDK, see https://developer.cisco.com/docs/nx-os-n3k-n9k-api-ref/.

REST Put による DME フル構成置換について

Cisco NX-OS リリース 9.3(1) 以降、Cisco NX-OS は REST PUT 操作によるモデルベースの完全な設定置換をサポートします。設定を置き換えるこの方法では、Cisco DME モデルを使用します。

DME フル コンフィギュレーションの置換機能を使用すると、REST プログラム インターフェイスを使用してスイッチの実行コンフィギュレーションを置換できます。この機能には、次の追加の利点があります。DME の完全な設定置換は、PUT 操作によって行われます。設定ツリーのすべての部分（システムレベル、サブツリー、およびリーフ）は、DME の完全な設定の置換をサポートします。

  • スイッチ設定の無停止交換をサポート

  • 自動化のサポート

  • 他の機能やその構成に影響を与えることなく、機能を選択的に変更する機能を提供します。

  • 最終的な設定結果を指定できるようにすることで、設定変更を簡素化し、人的エラーを排除します。スイッチは差分を計算し、構成ツリーの影響を受ける部分にプッシュします。


（注）  
プログラム インターフェイスを使用して実行することはできませんが、Cisco NX-OS CLI コマンドを使用して完全な設定置換を実行することもできます。config replace config-file-name

注意事項と制約事項

以下は DME フル構成置換機能の注意事項と制約事項です。

  • リリース 9.3(x) より前の Cisco NX-OS でサポートされるプラットフォームについては、プログラマビリティ機能のプラットフォーム サポート を参照してください。Cisco NX-OS リリース 9.3(x) 以降、サポートされるプラットフォームの詳細については、Nexus Switch Platform Matrixを参照してください。

  • DME は N9K-92348GC-X ではサポートされていません。

  • ツリーを確認し、構成置換が適用される場所を確認することが重要です。構成置換操作にサンドボックスを使用する場合、サンドボックスはデフォルトでサブツリーに設定されるため、構成ツリー内の正しいノードをターゲットとするように URI を変更する必要があります。

  • NX-OS サンドボックスを使用して（置換のための）変換 を行う場合、要求に status: 'replaced' 属性が存在するため、POST 操作を使用する必要があります。他の変換オプションを使用する場合は、PUT 操作を使用できます。

  • サブツリーノードでこの機能の REST PUT オプションを使用すると、構成置換操作がサブツリー全体に適用されます。ターゲットのサブツリー ノードは PUT の構成置換データで正しく変更されますが、サブツリー ノードのリーフ ノードもデフォルト値に構成されることによって影響を受けることに注意してください。

    リーフ ノードに影響が及ばないようにする必要がある場合は、PUT 操作を使用しないでください。代わりに、status:'replaced' 属性を指定した POST 操作を使用できます。

    リーフ ノードに構成置換を適用する場合、PUT 操作は期待どおりに動作します。

REST POST によるプロパティレベルの構成置換

シスコの DME モデルは、REST POST 操作による CLI ベースの機能のプロパティレベルの構成置換をサポートしています。要求ペイロードを生成し、REST POST 操作を介してスイッチに送信することにより、NX-OS サンドボックスを介して機能のプロパティの構成を置き換えることができます。NX-OS サンドボックスの詳細については、NX-API 開発者サンドボックスを参照してください。

手順

ステップ 1

HTTPS を介し、NX-OS サンドボックスを介してスイッチに接続し、ログイン情報を入力します。

ステップ 2

作業エリアで、変更する機能の CLI を入力します。

ステップ 3

作業エリアの下のフィールドで、構成する機能に対するツリー内の MO への URI を設定します。この MO レベルは Put 要求の送信先です。

ステップ 4

[方法（Method）] で、NX-API (DME) を選択します。

ステップ 5

[入力タイプ（Input Type）] で、[CLI] を選択します。

ステップ 6

[変換（Convert）] ドロップダウンリストから Convert (for replace) を選択して、[要求（Request）] ペインでペイロードを生成します。

ステップ 7

スイッチへの POST 操作を使用する要求をクリックします。

（注）  

 
プロパティレベルの構成置換は、構成がデフォルト構成の場合に失敗する可能性があります。これは、置換操作はすべての子 MOを削除し、すべてのプロパティをデフォルトにリセットしようと試みるからです。

REST PUT による機能レベルの構成置換

Cisco DME は、REST PUT 操作による機能レベルの設定の置換をサポートしています。モデルの機能レベルで PUT を送信することで、特定の機能の設定を置き換えることができます。

次の手順を使用します。

手順

ステップ 1

クライアントから、機能のモデルオブジェクト（MO）で REST PUT 操作を発行します。

  1. Put は、最上位システムレベルから機能の MO への URL を指定する必要があります。

    たとえば、BGP /api/mo/sys/bgp.json の場合

    ペイロードは有効な設定である必要があり、機能の DN で GET を発行することで、いつでもスイッチから設定を取得できる必要があります。たとえば、BGP の場合、/api/mo/sys/bgp.json?rsp-subtree=full&rsp-prop-include=set-config-only です。

  2. 機能のペイロードは、置き換える MO（たとえば、 bgp ）で始まる必要があります。

次に例を示します。
{
            "bgpInst": {
              "attributes": {
                "asn": "100",
                "rn": "inst"
              },
              "children": [

              ... content removed for brevity ...

                {
                  "bgpDom": {
                    "attributes": {
                      "name": "vrf1",
                      "rn": "dom-vrf1"
                    },
                    "children": [
                      {
                        "bgpPeer": {
                          "attributes": {
                            "addr": "10.1.1.1",
                            "inheritContPeerCtrl": "",
                            "rn": "peer-[10.1.1.1]"
                          }
                        }
                      }
                    ]
                  }
                },
                {
                  "bgpDom": {
                    "attributes": {
                      "name": "default",
                      "rn": "dom-default",
                      "rtrId": "1.1.1.1"
                    }
                  }
                }
              ]
            }
          }

ステップ 2

/api/mo/sys/bgp.json?rsp-subtree=full&rsp-prop-include=set-config-only を使用して、設定の置換に使用した DN で GET を送信します。

ステップ 3

（オプション）送信したペイロードを、置き換えた DN の GET と比較します。GET のペイロードは、送信したペイロードと同じである必要があります。

REST PUT の構成置換のトラブルシューティング

以下は、REST Put 操作による設定の置換が成功しない場合のトラブルシューティングに役立つ手順です。

手順

ステップ 1

要求が有効かどうかを確認します。

URL、操作、およびペイロードが有効である必要があります。たとえば、URL が api/mo/sys/foo.json の場合、ペイロードは foo で始まる必要があります。

ステップ 2

ペイロードが有効であり、次の構成プロパティのみが含まれていることを確認します。

  • 正常に設定されました

  • 有効なデバイス設定から取得

設定プロパティのみを取得するには、rsp-subtree=full&rsp-prop-include=set-config-only をフィルタリングする GET を使用します。

ステップ 3

ペイロードを検証するには、DME POST 操作を使用してペイロードをスイッチに送信します。

ステップ 4

エラーをチェックして、MO の名前とプロパティがあることを確認します。

ステップ 5

ペイロードに MO の名前とプロパティも含まれていることを確認します。