NX-API REST

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

NX-API REST について

NX-API REST

リリース 7.0(3)I2(1) では、NX-API REST SDK が追加されました。

Cisco Nexus スイッチでは、構成はコマンドライン インターフェイス（CLI）を使用して実施します。CLI は、当該スイッチ上でしか実行できません。NX-API REST は、HTTP/HTTPS API を提供することにより、Cisco Nexus 構成のアクセシビリティを向上させます。

  • 特定の CLI コマンドをスイッチの外部から実行可能です。

  • 比較的少数の HTTP/HTTPS 操作で設定アクションを組み合わせることで、多数の CLI コマンドを発行する必要がある設定を有効にします。

NX-API REST は、show コマンド、基本および詳細スイッチ構成と Linux Bash をサポートします。

NX-API REST は HTTP/HTTPS をトランスポートとして使用します。CLI は、HTTP / HTTPS POST 本文にエンコードされます。NX-API REST バックエンドは Nginx HTTP サーバーを使用します。Nginx プロセスとそのすべての子プロセスは、CPU とメモリの使用量の上限が定められている Linux cgroup の保護下に置かれます。NX-API プロセスは、cgroup ext_ser_nginx の一部であり、2,147,483,648 バイトのメモリに制限されています。Nginx のメモリ使用量が cgroup の制限を超えると、Nginx プロセスは再起動されて、NX-API 構成（VRF、ポート、証明書構成）が復元されます。

Cisco Nexus 3000 および 9000 シリーズ NX-API REST SDK の詳細については、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 の名前とプロパティも含まれていることを確認します。