Chapter1. 新機能および変更された機能に関する情報

この章では、Cisco Nexus 9000 シリーズ NX-OS プログラマビリティ ガイド、リリース 7.x に記載されている、新機能および変更された機能に関するリリース固有の情報について説明します。

- 新機能および変更された機能に関する情報

新機能および変更された機能に関する情報

次の表は、[Cisco Nexus 9000 シリーズ NX-OS プログラマビリティ ガイド リリース 7.x（Cisco Nexus 9000 Series NX-OS Programmability Guide, Release 7.x）] に記載されている新機能および変更機能を要約したものです。それぞれの説明が記載されている箇所も併記されています。

新機能および変更された機能

特長

説明

変更が行われたリリース

参照先

モデル駆動型テレメトリ

エンコーディング、コレクション、トランスポート、およびストリーミングに関する詳細を表示するようにshow telemetry control database sensor-paths 拡張されました。

7.0（3）I7（7）

テレメトリの構成と統計情報の表示

NETCONF の CLI コマンド出力

NX-OS CLI コマンドのネットワーク設定フォーマットへの変換のサポートが文書化されています。

7.0(3)I7(5)

CLI コマンドのネットワーク構成フォーマットへの変換

XML 管理インターフェイス

XML ベースのネットワーク構成プロトコル（NETCONF）を介した XML ベースのツールを使用した Cisco Nexus 9000 スイッチの管理のサポートが文書化されています。

7.0(3)I7(5)

XML 管理インターフェイス

NX-API 入力要求フォーマットとしての JSON-RPC

JSON-RPC が受け入れられる NX-API 入力要求フォーマットになりました。

7.0(3)I7(4)

NX-API CLI

ロールバック NX-API リクエスト要素

ロールバック NX-API 要求要素は、XML、JSON、および JSON-RPC 入力要求フォーマットで使用できるようになりました。

7.0(3)I7(4)

NX-API CLI

パッチ RPM のサポート

パッチ RPM を管理するための手順を追加しました。

7.0(3)I7(3)

bash

UDP テレメトリ

UDP テレメトリに関する情報を追加しました。

7.0(3)I7(3)

モデル駆動型テレメトリ

Nexus 9508 Bash シェルのサポート

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

注意事項と制約事項

Nexus 9508 Python API のサポート

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

注意事項と制約事項

Nexus 9508 iPXE のサポート

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

注意事項と制約事項

Nexus 9508 カーネル スタックのサポート

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

Guidelines and Limitations

サードパーティ製アプリケーションをサポートする Nexus 9508 RPM

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

サードパーティ製アプリケーションについて

Nexus 9508 Puppet エージェントのサポート

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

Puppet Agent

Nexus 9508 Chef クライアントのサポート

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

Cisco NX-OS と一緒にシェフ クライアントを使用

Nexus 9508 NX-API REST サポート

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

注意事項と制約事項

Nexus 9508 ゲスト シェルのサポート

NX-OS 7.0（3）F3（1）を実行している Nexus 9508 のサポートが追加されました。

7.0(3)F3(1)

Guest Shell について

ゲスト シェルの rootfs を複数のデバイスにエクスポートします。

特定のゲスト シェル rootfs をエクスポートし、複数のデバイスに展開するサポート。

7.0(3)I7(1)

ゲスト シェルの複製

UDP およびセキュア UDP（DTLS）プロトコルのテレメトリ サポート

UDP およびセキュア UDP（DTLS）プロトコルのテレメトリ サポートが追加されました

7.0(3)I7(1)

テレメトリ コンポーネントとプロセス

自己署名 SSL 証明書による認証

自己署名 SSL 証明書による認証のサポートが追加されました。

7.0(3)I7(1)

テレメトリの注意事項と制約事項

テレメトリの VRF サポート

追加のテレメトリの VRF サポート。

7.0(3)I7(1)

テレメトリの注意事項と制約事項

gRPC トランスポートのテレメトリ圧縮

gRPC トランスポートのテレメトリ圧縮の追加サポート。

7.0(3)I7(1)

テレメトリの注意事項と制約事項

NX-OS プログラマブル インターフェイス コンポーネント RPM パッケージ

NX-OS イメージに含まれる NX-OS プログラマブル インターフェイス コンポーネント RPM パッケージ。

7.0(3)I7(1)

コンポーネント RPM パッケージについて

コンテナ トラッカー

Kubernetes API サーバーとの通信のサポートが追加されました。

7.0(3)I6(1)

コンテナ トラッカーのサポート

NX-SDK

ネイティブ NX-OS アプリケーションを作成するための SDK。

7.0(3)I6(1)

NX-SDK

NETCONF 候補

ユーザーは NETCONF 構成を変更し、それらの変更をいつコミットするかを選択できます。

7.0(3)I6(1)

NETCONF エージェント

ダイナミック ロガー

スイッチを再起動せずに構成を更新できるようになりました

7.0(3)I6(1)

ダイナミック ロガー

モデル駆動型テレメトリ

フロー テレメトリは、以下をサポートします：

- HTTP 経由の JSON

- gRPC 経由の SSL/TLS 証明書

7.0(3)I6(1)

モデル駆動型テレメトリ

NX-API 開発者サンドボックス

サンドボックスは、REST JSON ペイロードを同等の CLI コマンドに変換できます。

7.0(3)I6(1)

NX-API 開発者サンドボックス

ゲスト シェル

バージョンが 2.1 から 2.2 に更新されました。ゲスト シェルには、次の機能が含まれるようになりました。

- ユーザー アカウントには、スイッチへのログインに使用したものと同じ名前が付けられます。

- dohost ユーティリティは、NX-API 接続を介してログインしているユーザー名を送信します。

- ネットワーク管理者は、ゲスト シェル内で管理者以外のアカウントを構成できます。

7.0(3)I5(2)

ゲスト シェル

NX-API 開発者サンドボックス

サンドボックスは、YANG および NX-API REST ペイロードの生成をサポートするようになりました。

7.0(3)I5(1)

NX-API 開発者サンドボックス

モデル駆動型プログラマビリティ

データ モデリングでは、プログラムを使用した標準ベースの方法でネットワーク デバイスの構成を記述します。

7.0(3)I5(1)

モデル駆動型プログラマビリティ

モデル駆動型テレメトリ

ストリーミング ネットワーク データのプッシュ モデルを有効にし、モニタリング データへのほぼリアルタイムのアクセスを提供します。

7.0(3)I5(1)

モデル駆動型テレメトリ

XML 管理インターフェイス

デバイスを構成するための XML 管理インターフェイスの追加の使用法

7.0(3)I4(1)

以降のリリースでモデル駆動型プログラマビリティに置き換えられました。

Nexus アプリケーション開発

Cisco SDK は、Yocto 1.2 に基づく開発キットです。Cisco Nexus スイッチで実行するアプリケーションを構築するために必要なすべてのツールが含まれています。

7.0（3）i2（1）

カーネル スタック

既知の Linux API を使用して、ルートと前面パネルポートを管理します。

7.0(3)I2(1)

カーネル スタック

ISO

ISO イメージは、Cisco Nexus スイッチ上でネイティブに実行するサードパーティ製アプリケーションを構築し、RPM パッケージ化するために必要なツール、ライブラリ、およびヘッダーを含むブート可能な WindRiver 5 環境です。

7.0（3）i2（1）

Nexus アプリケーション開発：ISO

iPXE

オープン ソースのネットワーク ブート ファームウェア。

7.0（3）i2（1）

iPXE

Chef

Chef は、Chef Software, Inc. によって開発されたオープンソース ソフトウェア パッケージです。

7.0（3）i2（1）

Cisco NX-OS と一緒にシェフ クライアントを使用

Puppet

Puppet Labs によって開発された Puppet ソフトウェア パッケージは、構成設定などのデバイス状態を適用してサーバーやその他の技術情報を管理するためのオープン ソースの自動化ツールセットです。

7.0（3）i2（1）

Puppet Agent

サードパーティ製アプリケーション

オープンソース アプリケーションを追加しました。

7.0（3）i2（1）

サードパーティ製アプリケーション

ゲスト シェル

ゲストシェル 2.0 に更新

7.0（3）i2（1）

ゲスト シェル

iPXE

オープン ソースのネットワーク ブート ファームウェア。

7.0（3）i2（1）

iPXE

カーネル スタック

既知の Linux API を使用して、ルートと前面パネルポートを管理します。

7.0（3）i2（1）

カーネル スタック

リリース 6.x 以降の更新なし

7.0(3)I1(1)

Chapter2. 概要

- プログラマビリティの概要

- サポートされるプラットフォーム

- 標準的なネットワーク管理機能

- 高度な自動化機能

- プログラマビリティのサポート

プログラマビリティの概要

Cisco Nexus 9000 シリーズ スイッチ上で動作する Cisco NX-OS ソフトウェアには、次のような特徴があります。

- 耐障害性

クリティカルなビジネスクラスの可用性を確保します。

- モジュラ型

ビジネス ニーズに対応する拡張機能があります。

- 高度なプログラム性

アプリケーション プログラミング インターフェイス（API）を介した迅速な自動化とオーケストレーションを可能にします。

- セキュア

データと運用を保護し維持します。

- 柔軟性

新しいテクノロジーを統合して有効にします。

- 優れた拡張性

ビジネスと要件に対応して拡大できます。

- 使いやすさ

必要な学習量が少なく、展開がシンプルで、管理が容易です。

Cisco NX-OS オペレーティング システムでは、デバイスはユニファイド ファブリック モードで機能し、プログラムによる自動化機能を備えたネットワーク接続を提供します。

Cisco NX-OS には、オープン ソース ソフトウェア（OSS）と商用テクノロジーが含まれており、これらは自動化、オーケストレーション、プログラマビリティ、モニタリング、コンプライアンスをサポートします。

オープンな NX-OSの詳細については、https://developer.cisco.com/site/nx-os/を参照してください。

サポートされるプラットフォーム

Cisco NX-OS リリース 7.0(3)I7(1) 以降、「Nexus スイッチ プラットフォーム サポート マトリクス 」を使用して、選択した機能をサポートするさまざまな Cisco Nexus 9000 および 3000 スイッチのリリース元である Cisco NX-OS を知ることができます。

標準的なネットワーク管理機能

- SNMP（V1、V2、V3）

- Syslog

- RMON

- NETCONF

- CLI および CLI スクリプト

高度な自動化機能

デバイスでの機能が強化された Cisco NX-OS は、自動化をサポートします。プラットフォームには、電源投入時自動プロビジョニング（POAP）のサポートが含まれています。

デバイスでの機能が強化された Cisco NX-OS は、自動化をサポートします。プラットフォームには、自動化をサポートする次の機能が含まれています：

- 電源オン自動プロビジョニング（POAP）サポート

- Chef と Puppetの統合

- OpenStack の統合

- OpenDaylight の統合と OpenFlow のサポート

プログラマビリティのサポート

スイッチ上の Cisco NX-OS ソフトウェアは、プログラマビリティを支援する複数の機能をサポートしています。

- NX-API のサポート

- Python スクリプティング

- Tcl スクリプティング

- Broadcom シェル

- bash

- bash シェルへのアクセスと Linux コンテナのサポート

- ゲスト シェル

- コンテナ トラッカーのサポート

NX-API のサポート

Cisco NX-API を使用すると、HTTP ベースのプログラムによってスイッチにアクセスすることが可能になります。このサポートは、オープンソースの Web サーバーである NX-API によって提供されています。NX-API では、Web ベース API を通じて Cisco NX-OS CLI のすべての構成機能および管理機能を提供しています。デバイスは、XML または JSON フォーマットで API 呼び出しの出力を公開するように設定できます。この API により、スイッチでの迅速な開発が可能になります。

Python スクリプティング

Cisco NX-OS は、Python v2.7.5 を、インタラクティブ モードと非インタラクティブ（スクリプト）モードの両方でサポートしています。

Cisco NX-OS リリース 9.3(5) 以降 、Python 3 もサポートされています。

デバイスの Python スクリプト機能は、さまざまなタスクを実行するためのスイッチの CLI と、Power On Auto Provisioning（POAP）または Embedded Event Manager（EEM）アクションへのプログラムによるアクセスを提供します。Cisco NX-OS CLI を呼び出す Python コールへの応答は、テキストまたは JSON 出力を返します。

Python インタープリタは Cisco NX-OS ソフトウェアに含まれています。

Tcl スクリプティング

Cisco Nexus 9000 シリーズ スイッチは、Tcl（ツール コマンド言語）をサポートします。Tcl は、スイッチで CLI コマンドを柔軟に使用できるようにするスクリプト言語です。Tcl を使用して show コマンドの出力の特定の値を抽出したり、スイッチを設定したり、Cisco NX-OS コマンドをループで実行したり、スクリプトで EEM ポリシーを定義したりすることができます。

Broadcom シェル

Cisco Nexus 9000 シリーズ スイッチの前面パネルおよびファブリック モジュールのライン カードには Broadcom のネットワーク転送エンジン（NFE）が搭載されています。これらの NFE から Broadcom コマンドライン シェル（bcm-shell）にアクセスすることができます。

bash

Cisco Nexus スイッチは、Bourne-Again Shell（Bash）への直接アクセスをサポートします。Bash では、デバイス上の基盤となる Linux システムにアクセスし、システムを管理できます。

bash シェルへのアクセスと Linux コンテナのサポート

Cisco Nexus スイッチは、Linux シェルへの直接アクセスと Linux コンテナをサポートしています。Linux シェルへのアクセスでは、スイッチ上の基盤となっている Linux システムにアクセスして、基盤システムを管理できます。また、Linux コンテナを使用して、独自のソフトウェアを安全にインストールし、Cisco Nexus スイッチの機能を強化することもできます。たとえば、Cobbler などのベアメタル プロビジョニング ツールを Cisco Nexus スイッチにインストールして、トップオブラック スイッチからベアメタル サーバーを自動的にプロビジョニングすることができます。

ゲスト シェル

Cisco Nexus 9000 シリーズ スイッチは、ホスト Cisco Nexus 9000 NX-OS ソフトウェアから分離されたホスト システム上の Linux 実行スペースへの Bash アクセスを提供するゲスト シェルをサポートします。ゲスト シェルを使用すると、ホスト システム ソフトウェアに影響を与えることなく、必要に応じてソフトウェア パッケージを追加し、ライブラリを更新できます。

コンテナ トラッカーのサポート

Cisco NX-OS は、特定のスイッチ ポートの背後にあるコンテナの機能を理解するため、Kubernetes API サーバーと通信するように構成されます。

次のコマンドにより、Kubernetes API サーバーと通信します。

- show containers kubernetes コマンドは、HTTP 経由の API コールを使用して kube-apiserver からデータを取得します。

- kubernetes watch resource コマンドは、デーモンを使用して要求されたリソースにサブスクライブし、kube-apiserver からのストリーミング データを処理します。

- watch コマンドで割り当てられた action は、事前定義されたトリガーにより実行されます。（たとえば、ポッドの追加または削除）。

PartI. シェルとスクリプト化

- bash

- ゲスト シェル

- Broadcom シェル

- Python API

- tcl によるスクリプティング

- iPXE

- カーネル スタック

Chapter3. bash

- Bash について

- 注意事項と制約事項

- Bash へのアクセス

- 権限をルートにエスカレーションする

- Bash コマンドの例

- SDK または ISO で構築されたサード パーティ プロセスの永続的なデーモン化

- ネイティブ Bash シェルからのアプリケーションの永続的な起動

- ネイティブ Bash シェルのアプリケーション例

Bash について

Cisco NX-OS CLI に加えて、Cisco Nexus 9000 シリーズ スイッチは Bourne-Again SHell（Bash）へのアクセスをサポートします。Bash は、ユーザーが入力したコマンドまたはシェル スクリプトから読み取られたコマンドを解釈します。Bash を使用すると、デバイス上の基盤となる Linux システムにアクセスしてシステムを管理できます。

注意事項と制約事項

Bash シェルには、次の注意事項と制約事項があります。

- NX-OS 7.0（3）F3（1）以降、Bash シェルは Cisco Nexus 9508 スイッチでサポートされます。

- /isan フォルダにあるバイナリは、 run bash コマンドから入力されたシェルとは異なる設定の環境で実行するためのものです。Bash シェルからこれらのバイナリを使用しないことをお勧めします。その環境内での動作は予測できないからです。

- Cisco Python モジュールをインポートする場合は、Bash シェルから Python を使用しないでください。代わりに NX-OS VSH 内で、より新しい Python を使用します。

Bash へのアクセス

Cisco NX-OS では、Cisco NX-OS dev-ops ロールまたは Cisco NX-OS network-admin ロールに関連付けられたユーザ アカウントから Bash にアクセスできます。

次の例は、dev-ops ロールと network-admin ロールの権限を示しています。

switch# show role name dev-ops

Role: dev-ops
Description: Predefined system role for devops access. This role
cannot be modified.
Vlan policy: permit (default)
Interface policy: permit (default)
Vrf policy: permit (default)
-------------------------------------------------------------------
Rule    Perm    Type        Scope               Entity
-------------------------------------------------------------------
4       permit  command                         conf t ; username *
3       permit  command                         bcm module *
2       permit  command                         run bash *
1       permit  command                         python *

switch# show role name network-admin

Role: network-admin
Description: Predefined network admin role has access to all commands
on the switch
-------------------------------------------------------------------
Rule    Perm    Type        Scope               Entity
-------------------------------------------------------------------
1       permit  read-write
switch#

feature bash-shell コマンドを実行すると、Bash が有効になります。

この run bash コマンドは Bash を読み込み、ユーザーのホーム ディレクトリから開始します。

次の例は、Bash シェル機能を有効にする方法と、Bash を実行する方法を示しています。

switch# configure terminal
switch(config)# feature bash-shell

switch# run?
run         Execute/run program
run-script  Run shell scripts

switch# run bash?
bash  Linux-bash

switch# run bash
bash-4.2$ whoami
admin
bash-4.2$ pwd
/bootflash/home/admin
bash-4.2$

（注）

run bash コマンド で Bash コマンドを実行することもできます。

たとえば、run bash コマンド を使用して whoami を実行することもできます。

run bash whoami

ユーザー shelltype を構成して Bash を実行することもできます。

username foo shelltype bash

このコマンドにより、ログイン時に Bash シェルを直接実行できるようになります。この場合、feature bash-shell を有効にする必要はありません。

権限をルートにエスカレーションする

管理者ユーザーの特権は、ルート アクセスの特権をエスカレーションできます。

以下は、権限をエスカレーションするためのガイドラインです：

- 管理者権限ユーザー（network-admin/vdc-admin）は、NX-OS における、Linux の root 権限ユーザーに相当します。

- 認証された管理者ユーザーのみが権限を root に昇格できます。認証された管理者権限ユーザーにパスワードは必要ありません。

- 権限をエスカレーションする前に、Bash を有効にする必要があります。

- 非管理インターフェイスを介した root ユーザー名を使用したスイッチへの SSH では、root ユーザーの Linux Bash シェル タイプ アクセスがデフォルトになります。NX-OS シェル アクセスに戻るために vsh を入力します。

NX-OS ネットワーク管理者ユーザーは、次の場合に root にエスカレーションして、構成コマンドを NX-OS VSH に渡す必要があります。

- NX-OS ユーザはシェルタイプの Bash を使用しており、シェルタイプの Bash を使用してスイッチにログインしています。

- Bash でスイッチにログインした NX-OS ユーザは、引き続きスイッチで Bash を使用します。

sudo su 'vsh -c "<configuration commands>"' または sudo bash -c 'vsh -c "<configuration commands>"' を実行します。

次の例は、デフォルトのシェルタイプが Bash であるネットワーク管理者ユーザー MyUser が、sudo を使用して構成コマンドを NX-OS に渡す方法を示しています。

ssh -l MyUser 1.2.3.4
-bash-4.2$ sudo vsh -c "configure terminal ; interface eth1/2 ; shutdown ; sleep 2 ; show interface eth1/2 brief"

--------------------------------------------------------------------------------
Ethernet      VLAN    Type Mode   Status  Reason                   Speed     Port
Interface                                                                    Ch #
--------------------------------------------------------------------------------
Eth1/2        --      eth  routed down    Administratively down      auto(D) --

次の例は、デフォルトのシェルタイプが Bash であるネットワーク管理者ユーザー MyUser が、NX-OS に入り、NX-OS で Bash を実行する方法を示しています。

ssh -l MyUser 1.2.3.4
-bash-4.2$ vsh -h
Cisco NX-OS Software
Copyright (c) 2002-2016, Cisco Systems, Inc. All rights reserved.
Nexus 9000v software ("Nexus 9000v Software") and related documentation,
files or other reference materials ("Documentation") are
the proprietary property and confidential information of Cisco
Systems, Inc. ("Cisco") and are protected, without limitation,
pursuant to United States and International copyright and trademark
laws in the applicable jurisdiction which provide civil and criminal
penalties for copying or distribution without Cisco's authorization.

Any use or disclosure, in whole or in part, of the Nexus 9000v Software
or Documentation to any third party for any purposes is expressly
prohibited except as otherwise authorized by Cisco in writing.
The copyrights to certain works contained herein are owned by other
third parties and are used and distributed under license. Some parts
of this software may be covered under the GNU Public License or the
GNU Lesser General Public License. A copy of each such license is
available at
http://www.gnu.org/licenses/gpl.html and
http://www.gnu.org/licenses/lgpl.html
***************************************************************************
*  Nexus 9000v is strictly limited to use for evaluation, demonstration      *
*  and NX-OS education. Any use or disclosure, in whole or in part of     *
*  the Nexus 9000v Software or Documentation to any third party for any      *
*  purposes is expressly prohibited except as otherwise authorized by     *
*  Cisco in writing.                                                      *
***************************************************************************
switch# run bash
bash-4.2$ vsh -c "configure terminal ; interface eth1/2 ; shutdown ; sleep 2 ; show interface eth1/2 brief"

--------------------------------------------------------------------------------
Ethernet      VLAN    Type Mode   Status  Reason                   Speed     Port
Interface                                                                    Ch #
--------------------------------------------------------------------------------
Eth1/2        --      eth  routed down    Administratively down      auto(D) --

（注）

sudo su - は使用しないでください。使用すると、システムがハングします。

次の例は、特権を root にエスカレーションする方法と、エスカレーションを確認する方法を表示しています。

switch# run bash
bash-4.2$ sudo su root
bash-4.2# whoami
root
bash-4.2# exit
exit

Bash コマンドの例

このセクションには、Bash コマンドと出力の例が含まれています。

- システム統計情報の表示

- CLI からの Bash の実行

システム統計情報の表示

次の例は、システム統計情報の表示方法を示しています：

switch# run bash
bash-4.2$ cat /proc/meminfo
<snip>
MemTotal:       16402560 kB
MemFree:        14098136 kB
Buffers:           11492 kB
Cached:          1287880 kB
SwapCached:            0 kB
Active:          1109448 kB
Inactive:         717036 kB
Active(anon):     817856 kB
Inactive(anon):   702880 kB
Active(file):     291592 kB
Inactive(file):    14156 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                32 kB
Writeback:             0 kB
AnonPages:        527088 kB
Mapped:            97832 kB
<\snip>

CLI からの Bash の実行

次に、run bashコマンド を使用して Bash から ps を実行する例を示します。

switch# run bash ps -el
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 S     0     1     0  0  80   0 -   528 poll_s ?        00:00:03 init
1 S     0     2     0  0  80   0 -     0 kthrea ?        00:00:00 kthreadd
1 S     0     3     2  0  80   0 -     0 run_ks ?        00:00:56 ksoftirqd/0
1 S     0     6     2  0 -40   - -     0 cpu_st ?        00:00:00 migration/0
1 S     0     7     2  0 -40   - -     0 watchd ?        00:00:00 watchdog/0
1 S     0     8     2  0 -40   - -     0 cpu_st ?        00:00:00 migration/1
1 S     0     9     2  0  80   0 -     0 worker ?        00:00:00 kworker/1:0
1 S     0    10     2  0  80   0 -     0 run_ks ?        00:00:00 ksoftirqd/1

RPM インストールの前提条件

RPM をインストールまたは追加する前に、次の手順によりシステムの準備ができていることを確認します。

手順

ステップ 1

switch# show logging logfile | grep -i "System ready"

Bash を実行する前に、この手順によって、RPM をインストールまたは追加する前のシステムの準備ができていることを確認します。

以下のような出力が表示されれば、続行します。

2018 Mar 27 17:24:22 switch %ASCII-CFG-2-CONF_CONTROL: System ready

ステップ 2

switch# run bash sudo su

例:

switch# run bash sudo su

bash-4.2#

Bash をロードします。

Bash からの機能 RPM のインストール

手順

ステップ 1

sudo yum installed | grep platform

スイッチにインストールされている NX-OS 機能 RPM のリストを表示します。

ステップ 2

yum list available

使用可能な RPM のリストを表示します。

ステップ 3

sudo yum -y install rpm

使用可能な RPM をインストールします。

例

次に、bfd RPM をインストールする例を示します。

bash-4.2$ yum list installed | grep n9000
base-files.n9000                        3.0.14-r74.2                   installed
bfd.lib32_n9000                         1.0.0-r0                       installed
core.lib32_n9000                        1.0.0-r0                       installed
eigrp.lib32_n9000                       1.0.0-r0                       installed
eth.lib32_n9000                         1.0.0-r0                       installed
isis.lib32_n9000                        1.0.0-r0                       installed
lacp.lib32_n9000                        1.0.0-r0                       installed
linecard.lib32_n9000                    1.0.0-r0                       installed
lldp.lib32_n9000                        1.0.0-r0                       installed
ntp.lib32_n9000                         1.0.0-r0                       installed
nxos-ssh.lib32_n9000                    1.0.0-r0                       installed
ospf.lib32_n9000                        1.0.0-r0                       installed
perf-cisco.n9000_gdb                    3.12-r0                        installed
platform.lib32_n9000                    1.0.0-r0                       installed
shadow-securetty.n9000_gdb              4.1.4.3-r1                     installed
snmp.lib32_n9000                        1.0.0-r0                       installed
svi.lib32_n9000                         1.0.0-r0                       installed
sysvinit-inittab.n9000_gdb              2.88dsf-r14                    installed
tacacs.lib32_n9000                      1.0.0-r0                       installed
task-nxos-base.n9000_gdb                1.0-r0                         installed
tor.lib32_n9000                         1.0.0-r0                       installed
vtp.lib32_n9000                         1.0.0-r0                       installed
bash-4.2$ yum list available
bgp.lib32_n9000                         1.0.0-r0
bash-4.2$ sudo yum -y install bfd

（注）

起動時のスイッチのリロード時に、永続的な RPM のため、yum の代わりに rpm コマンドを使用します。そうしなかった場合、最初に yum bash または install cli を使用してインストールされた RPM は、インストール済み としてではなく、リポジトリ名またはファイル名で表示されます。

機能 RPM のアップグレード

始める前に

yum リポジトリに RPM の上位バージョンが存在する必要があります。

手順

sudo yum -y upgrade rpm

インストールされている RPM をアップグレードします。

例

次に、bfd RPM のアップグレードの例を示します。

bash-4.2$ sudo yum -y upgrade bfd

機能 RPM のダウングレード

手順

sudo yum -y downgrade rpm

いずれかの dnf リポジトリに下位バージョンの RPM がある場合に、RPM をダウングレードします。

例

次に、bfd RPM をダウングレードする例を示します。

bash-4.2$ sudo yum -y downgrade bfd

機能 RPM の消去

（注）

SNMP RPM および NTP RPM は保護されており、消去できません。

これらの RPM をアップグレードまたはダウングレードすることはできます。アップグレードまたはダウングレードを有効にするには、システムのリロードが必要です。

保護された RPM のリストについては、/etc/yum/protected.d/protected_pkgs.conf を参照してください。

手順

sudo yum -y erase rpm

RPM を消去します。

例

次の例は、bfd RPM を消去する方法を示しています。

bash-4.2$ sudo yum -y erase bfd

RPM インストールの前提条件

RPM をインストールまたは追加する前に、次の手順によりシステムの準備ができていることを確認します。

手順

ステップ 1

switch# show logging logfile | grep -i "System ready"

Bash を実行する前に、この手順によって、RPM をインストールまたは追加する前のシステムの準備ができていることを確認します。

以下のような出力が表示されれば、続行します。

2018 Mar 27 17:24:22 switch %ASCII-CFG-2-CONF_CONTROL: System ready

ステップ 2

switch# run bash sudo su

例:

switch# run bash sudo su

bash-4.2#

Bash をロードします。

Bash からのパッチ RPM の追加

手順

ステップ 1

yum list --patch-only

スイッチに存在するパッチ RPM のリストを表示します。

ステップ 2

sudo yum install --add URL_of_patch

リポジトリにパッチを追加します。ここで URL_of_patch は、標準的な Linux 形式の /bootflash/patch などではなく、bootflash:/patch などの明確に定義された形式です。

ステップ 3

yum list --patch-only available

リポジトリに追加されているものの非アクティブ状態のパッチのリストを表示します。

例

次に、nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 RPM をインストールする例を示します。

bash-4.2# yum list --patch-only
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                              | 1.1 kB     00:00 ...
localdb                                                  |  951 B     00:00 ...
patching                                                 |  951 B     00:00 ...
thirdparty                                               |  951 B     00:00 ...
bash-4.2#
bash-4.2# sudo yum install --add bootflash:/nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000.rpm
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
[##############      ] 70%Install operation 135 completed successfully at Tue Mar 27 17:45:34 2018.

[####################] 100%
bash-4.2#

パッチ RPM がインストールされたら、正しくインストールされたことを確認します。次のコマンドは、リポジトリに追加され、非アクティブ状態のパッチのリストを表示します。

bash-4.2# yum list --patch-only available
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
nxos.CSCab00001-n9k_ALL.lib32_n9000    1.0.0-7.0.3.I7.3    patching
bash-4.2#

RPM がバンドルされている tar ファイルを使用して、tar ファイルからリポジトリにパッチを追加することもできます。次に、nxos.CSCab00002_CSCab00003-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 tar ファイルに含まれる 2 つの RPM をパッチ リポジトリに追加する例を示します。

bash-4.2# sudo yum install --add bootflash:/nxos.CSCab00002_CSCab00003-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000.tar
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
[##############      ] 70%Install operation 146 completed successfully at Tue Mar 27 21:17:39 2018.

[####################] 100%
bash-4.2#
bash-4.2# yum list --patch-only
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
patching/primary                                            |  942 B     00:00 ...
patching                                                                       2/2
thirdparty                                                  |  951 B     00:00 ...
nxos.CSCab00003-n9k_ALL.lib32_n9000    1.0.0-7.0.3.I7.3    patching
nxos.CSCab00002-n9k_ALL.lib32_n9000    1.0.0-7.0.3.I7.3    patching
bash-4.2#

パッチ RPM のアクティブ化

始める前に

Bash からのパッチ RPM の追加 の手順に従って、必要なパッチ RPM がリポジトリに追加されていることを確認します。

手順

sudo yum install patch_RPM --nocommit

パッチ RPM をアクティブにします。ここで、patch_RPM はリポジトリにあるパッチです。この手順では、パッチの場所を指定しないでください。

（注）

--nocommit フラグをコマンドに追加すると、パッチ RPM がこの手順でアクティブになりますが、コミットされません。パッチ RPM をアクティブ化した後にコミットする手順については、パッチ RPM のコミット を参照してください。

例

次に、nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 パッチ RPM をアクティブにする例を示します。

bash-4.2# sudo yum install nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 --nocommit
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package nxos.CSCab00001-n9k_ALL.lib32_n9000 0:1.0.0-7.0.3.I7.3 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================
Package                    Arch           Version               Repository   Size
===================================================================================
Installing:
nxos.CSCab00001-n9k_ALL    lib32_n9000    1.0.0-7.0.3.I7.3      patching     28 k

Transaction Summary
===================================================================================
Install       1 Package

Total download size: 28 k
Installed size: 82 k
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000            1/1
[##################  ] 90%error: reading /var/sysmgr/tmp/patches/CSCab00001-n9k_ALL/isan/bin/sysinfo manifest, non-printable characters found

Installed:
nxos.CSCab00001-n9k_ALL.lib32_n9000 0:1.0.0-7.0.3.I7.3

Complete!
Install operation 140 completed successfully at Tue Mar 27 18:07:40 2018.

[####################] 100%
bash-4.2#

次のコマンドを入力して、パッチ RPM が正常にアクティブ化されたことを確認します。

bash-4.2# yum list --patch-only
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
nxos.CSCab00001-n9k_ALL.lib32_n9000    1.0.0-7.0.3.I7.3    installed
bash-4.2#

パッチ RPM のコミット

手順

sudo yum install patch_RPM --commit

パッチ RPM をコミットします。パッチ RPM は、リロード後もアクティブな状態を維持するためにコミットする必要があります。

例

次に、nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 パッチ RPM をコミットする例を示します。

bash-4.2# sudo yum install nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 --commit
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
Install operation 142 completed successfully at Tue Mar 27 18:13:16 2018.

[####################] 100%
bash-4.2#

次のコマンドを入力して、パッチ RPM が正常にコミットされたことを確認します。

bash-4.2# yum list --patch-only committed
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
nxos.CSCab00001-n9k_ALL.lib32_n9000    1.0.0-7.0.3.I7.3    installed
bash-4.2#

パッチ RPM の非アクティブ化

手順

ステップ 1

sudo yum erase patch_RPM --nocommit

パッチ RPM を非アクティブ化します。

（注）

コマンドに --nocommit フラグを追加すると、パッチ RPM はこの手順でのみ非アクティブ化されます。

ステップ 2

sudo yum install patch_RPM --commit

パッチ RPM をコミットします。パッチ RPM をコミットしないまま削除しようとすると、エラーメッセージが表示されます。

例

次に、nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 パッチ RPM を非アクティブにする例を示します。

bash-4.2# sudo yum erase nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 --nocommit
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package nxos.CSCab00001-n9k_ALL.lib32_n9000 0:1.0.0-7.0.3.I7.3 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================
Package                    Arch           Version              Repository    Size
===================================================================================
Removing:
nxos.CSCab00001-n9k_ALL    lib32_n9000    1.0.0-7.0.3.I7.3     @patching     82 k

Transaction Summary
===================================================================================
Remove        1 Package

Installed size: 82 k
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
[######              ] 30%error: reading /var/sysmgr/tmp/patches/CSCab00001-n9k_ALL/isan/bin/sysinfo manifest, non-printable characters found
Erasing    : nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000            1/1
[##################  ] 90%
Removed:
nxos.CSCab00001-n9k_ALL.lib32_n9000 0:1.0.0-7.0.3.I7.3

Complete!
Install operation 143 completed successfully at Tue Mar 27 21:03:47 2018.

[####################] 100%
bash-4.2#

パッチ RPM は、非アクティブ化した後にコミットする必要があります。パッチ RPM を非アクティブ化した後にコミットしなかった場合に、パッチ RPM の削除 の手順を使用してパッチ RPM を削除しようとすると、エラー メッセージが表示されます。

bash-4.2# sudo yum install nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 --commit
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
Install operation 144 completed successfully at Tue Mar 27 21:09:28 2018.

[####################] 100%
bash-4.2#

次のコマンドを入力して、パッチ RPM が正常にコミットされたことを確認します。

bash-4.2# yum list --patch-only
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
nxos.CSCab00001-n9k_ALL.lib32_n9000    1.0.0-7.0.3.I7.3    patching
bash-4.2#

パッチ RPM の削除

手順

sudo yum install --remove patch_RPM

非アクティブなパッチ RPM を削除します。

例

次に、nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000 パッチ RPM を削除する例を示します。

bash-4.2# sudo yum install --remove nxos.CSCab00001-n9k_ALL-1.0.0-7.0.3.I7.3.lib32_n9000
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
[##########          ] 50%Install operation 145 completed successfully at Tue Mar 27 21:11:05 2018.

[####################] 100%
bash-4.2#

（注）

パッチ RPM を削除しようとした後に、次のエラーメッセージが表示されたとします。

Install operation 11 "failed because patch was not committed". at Wed Mar 28 22:14:05 2018

これは、削除を試みる前にパッチ RPM をコミットしていなかったことを意味しています。パッチ RPM を削除する前にコミットする手順については、パッチ RPM の非アクティブ化 を参照してください。

次のコマンドを入力して、非アクティブなパッチ RPM が正常に削除されたことを確認します。

bash-4.2# yum list --patch-only
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
groups-repo                                                 | 1.1 kB     00:00 ...
localdb                                                     |  951 B     00:00 ...
patching                                                    |  951 B     00:00 ...
patching/primary                                            |  197 B     00:00 ...
thirdparty                                                  |  951 B     00:00 ...
bash-4.2#

SDK または ISO で構築されたサード パーティ プロセスの永続的なデーモン化

アプリケーションには、/etc/init.d/application_name にインストールされる起動 Bash スクリプトが必要です。この起動 Bash スクリプトは、次の一般的な形式にする必要があります（この形式の詳細については、http://linux.die.net/man/8/chkconfigを参照してください）。

#!/bin/bash
#
# <application_name> Short description of your application
#
# chkconfig: 2345 15 85
# description: Short description of your application
#
### BEGIN INIT INFO
# Provides: <application_name>
# Required-Start: $local_fs $remote_fs $network $named
# Required-Stop: $local_fs $remote_fs $network
# Description: Short description of your application
### END INIT INFO
# See how we were called.
case "$1" in
start)
# Put your startup commands here
# Set RETVAL to 0 for success, non-0 for failure
;;
stop)
# Put your stop commands here
# Set RETVAL to 0 for success, non-0 for failure
;;
status)
# Put your status commands here
# Set RETVAL to 0 for success, non-0 for failure
;;
restart|force-reload|reload)
# Put your restart commands here
# Set RETVAL to 0 for success, non-0 for failure
;;
*)
echo $"Usage: $prog {start|stop|status|restart|force-reload}"
RETVAL=2
esac

exit $RETVAL

ネイティブ Bash シェルからのアプリケーションの永続的な起動

手順

ステップ 1

作成したアプリケーション起動 Bash スクリプトを/etc/init.d/application_name にインストールします。

ステップ 2

/etc/init.d/application_name start でアプリケーションを開始します

ステップ 3

chkconfig --add application_name を入力します

ステップ 4

chkconfig --level 3 application_name on を入力します

実行レベル 3 は、標準のマルチユーザー実行レベルであり、スイッチが通常実行されるレベルです。

ステップ 5

chkconfig --list application_name を実行して、アプリケーションがレベル 3 で実行されるようにスケジュールされていることを確認し、レベル 3 が on に設定されていることを確認します。

ステップ 6

アプリケーションが /etc/rc3.d に記述されていることを確認します。次のような表示になるはずです。「S」の後に数字が続き、アプリケーション名（この例では tcollector）が続きます。../init.d/application_name には Bash 起動スクリプトへのリンクが表示されます。

bash-4.2# ls -l /etc/rc3.d/tcollector
lrwxrwxrwx 1 root root 20 Sep 25 22:56 /etc/rc3.d/S15tcollector -> ../init.d/tcollector

bash-4.2#

ネイティブ Bash シェルのアプリケーション例

次の例は、ネイティブ Bash シェルのアプリケーションを示しています。

bash-4.2# cat /etc/init.d/hello.sh
#!/bin/bash

PIDFILE=/tmp/hello.pid
OUTPUTFILE=/tmp/hello

echo $$ > $PIDFILE
rm -f $OUTPUTFILE
while true
do
echo $(date) >> $OUTPUTFILE
echo 'Hello World' >> $OUTPUTFILE
sleep 10
done
bash-4.2#
bash-4.2#
bash-4.2# cat /etc/init.d/hello
#!/bin/bash
#
# hello Trivial "hello world" example Third Party App
#
# chkconfig: 2345 15 85
# description: Trivial example Third Party App
#
### BEGIN INIT INFO
# Provides: hello
# Required-Start: $local_fs $remote_fs $network $named
# Required-Stop: $local_fs $remote_fs $network
# Description: Trivial example Third Party App
### END INIT INFO

PIDFILE=/tmp/hello.pid

# See how we were called.
case "$1" in
start)
/etc/init.d/hello.sh &
RETVAL=$?
;;
stop)
kill -9 `cat $PIDFILE`
RETVAL=$?
;;
status)
ps -p `cat $PIDFILE`
RETVAL=$?
;;
restart|force-reload|reload)
kill -9 `cat $PIDFILE`
/etc/init.d/hello.sh &
RETVAL=$?
;;
*)
echo $"Usage: $prog {start|stop|status|restart|force-reload}"
RETVAL=2
esac

exit $RETVAL
bash-4.2#
bash-4.2# chkconfig --add hello
bash-4.2# chkconfig --level 3 hello on
bash-4.2# chkconfig --list hello
hello           0:off   1:off   2:on    3:on    4:on    5:on    6:off
bash-4.2# ls -al /etc/rc3.d/*hello*
lrwxrwxrwx 1 root root 15 Sep 27 18:00 /etc/rc3.d/S15hello -> ../init.d/hello
bash-4.2#
bash-4.2# reboot

リロード後

bash-4.2# ps -ef | grep hello
root      8790     1  0 18:03 ?        00:00:00 /bin/bash /etc/init.d/hello.sh
root      8973  8775  0 18:04 ttyS0    00:00:00 grep hello
bash-4.2#
bash-4.2# ls -al /tmp/hello*
-rw-rw-rw- 1 root root 205 Sep 27 18:04 /tmp/hello
-rw-rw-rw- 1 root root   5 Sep 27 18:03 /tmp/hello.pid
bash-4.2# cat /tmp/hello.pid
8790
bash-4.2# cat /tmp/hello
Sun Sep 27 18:03:49 UTC 2015
Hello World
Sun Sep 27 18:03:59 UTC 2015
Hello World
Sun Sep 27 18:04:09 UTC 2015
Hello World
Sun Sep 27 18:04:19 UTC 2015
Hello World
Sun Sep 27 18:04:29 UTC 2015
Hello World
Sun Sep 27 18:04:39 UTC 2015
Hello World
bash-4.2#

Chapter4. ゲスト シェル

- Guest Shell について

- 注意事項と制約事項

- Guest Shell へのアクセス

- ゲスト シェルに使用されるリソース

- ゲストシェルの機能

- 仮想サービス のセキュリティ ポスチャ

- ゲスト ファイル システムのアクセス制限

- ゲスト シェルの管理

- 仮想サービスと Guest Shell 情報の検証

- ゲスト シェルからのアプリケーションの永続的な起動

- Guest Shell からアプリケーションを永続的に起動する手順

- ゲスト シェルでのサンプル アプリケーション

Guest Shell について

基盤となる Linux 環境での NX-OS CLI および Bash アクセスに加えて、スイッチは、「ゲスト シェル」と呼ばれる Linux コンテナ（LXC）内で実行される分離された実行スペースへのアクセスをサポートします。

ゲスト シェル内から、network-admin には次の機能があります。

- Linux ネットワーク インターフェイスを介したネットワークへのアクセス。

- スイッチのブートフラッシュへのアクセス。

- スイッチの揮発性 tmpfs へのアクセス。

- スイッチの CLI へのアクセス。

- スイッチのホスト ファイル システムへのアクセス。

- Cisco NX-API REST へのアクセス。

- Python スクリプトをインストールして実行する機能。

- 32 ビットおよび 64 ビットの Linux アプリケーションをインストールして実行する機能。

コンテナ技術によって実行空間を切り離すことで、他の Linux コンテナで実行されているホスト システムやアプリケーションに影響を与えずに、アプリケーションのニーズに合わせて Linux 環境をカスタマイズすることができます。

NX-OS デバイスでは、Linux Containers は virtual-service コマンドでインストールと管理されます。Guest Shell は、virtual-service show コマンドの出力に表示されます。

（注）

デフォルトでは、ゲスト シェルは、有効にすると約 5 MB の RAM と 200 MB のブートフラッシュを占有します。Cisco NX-OS リリース 7.0（3）I2（1）以降、Guest Shell は約 35 MB の RAM を占有します。Guest Shell が使用されていない場合は、guestshell destroy コマンドを使用してリソースを再利用します。

（注）

Cisco NX-OS 7.0(3)F3(1)以降、Guest Shell は Cisco Nexus 9508 スイッチでサポートされます。

注意事項と制約事項

Guest Shell には、次の注意事項と制限事項があります。

すべてのリリースに共通の注意事項

重要

Guest Shell のインストール内でカスタム作業を実行した場合は、アップグレードを実行する前に、ブートフラッシュ、オフボックス ストレージ、またはゲスト シェル ルート ファイル システムの外部に変更を保存します。

guestshell upgrade コマンドは、本質的に、guestshell destroyとguestshell enableを連続して実行します。

- run guestshell CLI コマンドを使用して、Cisco Nexus デバイスのゲスト シェルにアクセスします。run guestshell コマンドは、ホスト シェルにアクセスするために使用される run bash コマンドに相当します。このコマンドを使用すると、Guest Shell にアクセスして bash プロンプトを取得したり、ゲスト シェルのコンテキスト内でコマンドを実行したりできます。このコマンドは、パスワードなしの SSH を使用して、デフォルトのネットワーク名前空間にある localhost の使用可能なポートに接続します。

- sshd ユーティリティは、localhost でリッスンして、ネットワーク外からの接続試行を回避することにより、Guest Shell への事前構成された SSH アクセスを保護できます。sshd には次の機能があります。

- これは、パスワードにフォールバックしないキーベースの認証用に構成されています。

- Guest Shell の再起動後にゲスト シェルにアクセスするために使用されるキーを読み取ることができるのは root だけです。

- root のみがホスト上のキーを含むファイルを読み取ることができ、ホスト bash アクセスを持つ非特権ユーザーがキーを使用して Guest Shell に接続できないようにします。ネットワーク管理者ユーザーは、Guest Shell で sshd の別のインスタンスを開始して、Guest Shell に直接リモート アクセスできるようにすることができますが、Guest Shell にログインするすべてのユーザーには、ネットワーク管理者権限も与えられます。

（注）

ゲスト シェル 2.2（0.2）で導入されたキー ファイルは、ユーザー アカウントが作成されたユーザーに対して読み取り可能です。

さらに、Guest Shell アカウントは自動的に削除されないため、不要になったときにネットワーク管理者が削除する必要があります。

Cisco Nexus リリース 7.0(3)I5(2) を使用した 2.2（0.2）より前の Guest Shell インストールでは、個々のユーザー アカウントが動的に作成されません。

- すぐに使用できる新しい Cisco Nexus スイッチに Cisco Nexus シリーズ スイッチ ソフトウェア リリースをインストールすると、Guest Shell が自動的に有効になります。その後の Cisco Nexus シリーズ スイッチ ソフトウェアへのアップグレードでは、Guest Shell は自動的にアップグレードされません。

- Guest Shell のリリースでは、配布または配布のバージョンが変更されると、メジャー番号が増分されます。

- Guest Shell のリリースでは、CVE が解決されるとマイナー番号が増分されます。Guest Shell は、CentOS が公開した場合にのみ CVE を更新します。

- yum update を使用して、CentOS リポジトリからサードパーティのセキュリティ脆弱性修正を直接取得することをお勧めします。これにより、Cisco NX-OS ソフトウェアのアップデートを待つことなく、更新が利用可能になったときに入手できる柔軟性が得られます。

または、guestshell update コマンドを使用すると、既存のゲスト シェル rootfs が置き換えられます。カスタマイズとソフトウェア パッケージのインストールは、この新しいゲスト シェル rootfs のコンテキスト内で再度実行する必要があります。

Guest Shell 1.0 からゲスト シェル 2.x へのアップグレード

Guest Shell 2.x は、CentOS 7 ルート ファイル システムに基づいています。コンテンツを Guest Shell 1.0 にプルダウンした .conf ファイルやユーティリティのオフボックス リポジトリがある場合は、Guest Shell 2.x で同じ展開手順を繰り返す必要があります。CentOS 7 の違いを考慮して、展開スクリプトを調整する必要がある場合があります。

Guest Shell 2.x

Cisco NX-OS は、デフォルトで自動的に Guest Shell のインストールおよび有効化を行います。ただし、Guest Shell をサポートしない Cisco NX-OS イメージでデバイスがリロードされる場合、既存の Guest Shell が自動的に削除され、%VMAN-2-INVALID_PACKAGE が発行されます。

（注）

4GB の RAM を搭載したシステムでは、デフォルトでは Guest Shell が有効になりません。guestshell enable コマンドを使用して、Guest Shell をインストールして有効にします。

install all コマンドは、現在の Cisco NX-OS イメージとターゲットの Cisco NX-OS イメージとの互換性を検証します。

互換性のないイメージをインストールした場合の出力例を次に示します。

switch#
Installer will perform compatibility check first. Please wait.
uri is: /
2014 Aug 29 20:08:51 switch %$ VDC-1 %$ %VMAN-2-ACTIVATION_STATE:
Successfully activated virtual service 'guestshell+'
Verifying image bootflash:/n9kpregs.bin for boot variable "nxos".
[####################] 100% -- SUCCESS
Verifying image type.
[####################] 100% -- SUCCESS
Preparing "" version info using image bootflash:/.
[####################] 100% -- SUCCESS
Preparing "bios" version info using image bootflash:/.
[####################] 100% -- SUCCESS
Preparing "" version info using image bootflash:/.
[####################] 100% -- SUCCESS
Preparing "" version info using image bootflash:/.
[####################] 100% -- SUCCESS
Preparing "nxos" version info using image bootflash:/.
[####################] 100% -- SUCCESS
Preparing "" version info using image bootflash:/.
[####################] 100% -- SUCCESS
Preparing "" version info using image bootflash:/.
[####################] 100% -- SUCCESS
"Running-config contains configuration that is incompatible with the new image (strict
incompatibility).
Please run 'show incompatibility-all nxos <image>' command to find out which feature
needs to be disabled.".
Performing module support checks.
[####################] 100% -- SUCCESS
Notifying services about system upgrade.
[# ] 0% -- FAIL.
Return code 0x42DD0006 ((null)).
"Running-config contains configuration that is incompatible with the new image (strict
incompatibility).
Please run 'show incompatibility-all nxos <image>' command to find out
which feature needs to be disabled."
Service "vman" in vdc 1: Guest shell not supported, do 'guestshell destroy' to remove
it and then retry ISSU
Pre-upgrade check failed. Return code 0x42DD0006 ((null)).
switch#

（注）

ベスト プラクティスとして、Guest Shell をサポートしていない古い Cisco Nexos イメージをリロードする前に、guestshell destroy コマンドを使用して Guest Shell を削除します。

事前設定された SSHD サービス

Guest Shell は、起動時に OpenSSH サーバーを開始します。サーバーは、localhost IP アドレス インターフェイス 127.0.0.1 でランダムに生成されたポートでのみリスンします。これにより、guestshell キーワードが入力されたときに、NX-OS vegas-shell から Guest Shell へのパスワードなしの接続が提供されます。このサーバーが強制終了されるか、その構成 (/etc/ssh/sshd_config-cisco にある) が変更された場合、NX-OS CLI からの Guest Shell へのアクセスが機能しない可能性があります。

次の手順では、Guest Shell 内で root として OpenSSh サーバーをインスタンス化します。

1. SSH 接続を確立するネットワーク名前空間または VRF を決定します。

2. OpenSSH がリスンするポートを決定します。すでに使用されているポートを表示するには、NX-OS コマンドの show socket connection を使用します。

（注）

パスワードなしのアクセス用の Guest Shell sshd サービスは、17680 から 49150 までのランダム化されたポートを使用します。ポートの競合を避けるには、この範囲外のポートを選択してください。

次の手順では、OpenSSH サーバーを起動します。例では、IP アドレス 10.122.84.34:2222 で管理 netns の OpenSSH サーバーを起動します。

1. 次のファイルを作成します: /usr/lib/systemd/systm/sshd-mgmt.service および /etc/ssh/sshd-mgmt_config。ファイルには次の構成が必要です。

-rw-r--r-- 1 root root 394 Apr 7 14:21 /usr/lib/systemd/system/sshd-mgmt.service
-rw------- 1 root root 4478 Apr 7 14:22 /etc/ssh/sshd-mgmt_config

2. Unit と Service の内容を /usr/lib/systemd/system/ssh.service ファイルから sshd-mgmt.service にコピーします。

3. sshd-mgmt.service ファイルを次のように編集します。

[Unit]
Description=OpenSSH server daemon
After=network.target sshd-keygen.service
Wants=sshd-keygen.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/sbin/ip netns exec management /usr/sbin/sshd -f /etc/ssh/sshd-mgmt_config -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target

4. /etc/ssh/sshd-config の内容を /etc/ssh/sshd-mgmt_config にコピーします。必要に応じて、ListenAddress IP とポートを変更します。

Port 2222
ListenAddress 10.122.84.34

5. 次のコマンドを使用して、systemctl デーモンを開始します。

sudo systemctl daemon-reload
sudo systemctl start sshd-mgmt.service
sudo systemctl status sshd-mgmt.service -l

6. （オプション）構成を確認します。

ss -tnldp | grep 2222

7. ゲスト シェルへの SSH：

ssh -p 2222 guestshell@10.122.84.34

8. 複数の Guest Shell またはスイッチの再起動にまたがって構成を保存します。

sudo systemctl enable sshd-mgmt.service

9. パスワードなしの SSH/SCP およびリモート実行の場合、ssh-keygen -t dsa コマンドを使用して、SSH/SCP に使用するユーザー ID の公開鍵と秘密鍵を生成します。

その後、キーは /.ssh ディレクトリの id_rsa および id_rsa.pub ファイルに保存されます。

[root@node01 ~]# cd ~/.ssh
[root@node02 .ssh]# ls -l
total 8
-rw-------. 1 root root 1675 May 5 15:01 id_rsa
-rw-r--r--. 1 root root 406 May 5 15:01 id_rsa.pub

10. 公開キーを SSH で接続するマシンにコピーし、アクセス許可を修正します。

cat id_rsa.pub >> /root/.ssh/authorized_keys
chmod 700 /root/.ssh
chmod 600 /root/.ssh/*

11. パスワードなしでリモート スイッチに SSH または SCP：

ssh -p <port#> userid@hostname [<remote command>]
scp -P <port#> userid@hostname/filepath /destination

localtime

Guest Shell は、ホスト システムと /etc/localtime を共有します。

（注）

ホストと同じ localtime を共有したくない場合は、このシンボリック リンクを切断して、ゲスト シェル固有の /etc/localtime を作成できます。

switch(config)# clock timezone PDT -7 0
switch(config)# clock set 10:00:00 27 Jan 2017
Fri Jan 27 10:00:00 PDT 2017
switch(config)# show clock
10:00:07.554 PDT Fri Jan 27 2017
switch(config)# run guestshell
guestshell:~$ date
Fri Jan 27 10:00:12 PDT 2017

Guest Shell へのアクセス

Cisco NX-OS のデフォルトでは、network-admin ユーザーのみが Guest Shell にアクセスできます。 これはシステムで自動的に有効になっており、run guestshell コマンドを使用してアクセスできます。run bash コマンドと一致して、これらのコマンドは、NX-OS CLI コマンドの run guestshell コマンド 形式を使用して Guest Shell 内で発行できます。

（注）

Guest Shell は、4 GB を超える RAM を搭載したシステムで自動的に有効になります。

switch# run guestshell ls -al /bootflash/*.ova
-rw-rw-rw- 1 2002 503 83814400 Aug 21 18:04 /bootflash/pup.ova
-rw-rw-rw- 1 2002 503 40724480 Apr 15 2012 /bootflash/red.ova

（注）

2.2(0.2) 以降の Guest Shell は、スイッチにログインしているユーザーと同じユーザー アカウントを動的に作成します。ただし、他のすべての情報は、スイッチと Guest Shell のユーザー アカウント間で共有されません。

さらに、Guest Shell アカウントは自動的に削除されないため、不要になったときにネットワーク管理者が削除する必要があります。

ゲスト シェルに使用されるリソース

デフォルトでは、ゲスト シェルのリソースは、通常のスイッチ操作に使用できるリソースに小さな影響を与えます。ネットワーク管理者がゲスト シェルに追加のリソースを必要とする場合、guestshell resize {cpu | memory | rootfs} コマンドは、これらの制限を変更します

リソース

デフォルト

最小/最大

CPU

1 %

1/20%

メモリ

400 MB

256/3840 MB

ストレージ

200 MB

200/2000 MB

CPU 制限は、システム内の他のコンピューティング負荷との競合がある場合に、ゲスト シェル内で実行されているタスクに与えられるシステム コンピューティング キャパシティのパーセンテージです。CPU リソースの競合がない場合、ゲスト シェル内のタスクは制限されません。

（注）

リソース割り当てを変更した後は、ゲスト シェルの再起動が必要です。そのために、guestshell reboot コマンドを使用できます。

ゲストシェルの機能

Guestshell には、デフォルトで利用可能な多くのユーティリティと機能があります。

ゲストシェルは CentOS 7 Linux 環境であり、この流通向けにビルドされたソフトウェア パッケージを、 dnfインストールすることができます。Guestshell には、net-tools 、iproute 、tcpdump とOpenSSH などのネットワーキング デバイスで自然に期待される多くの一般的なツールが事前に入力されています。Guestshell 2.x の場合、追加の python パッケージをインストールするための PIP と同様に、python 2.7.5 がデフォルトで含まれています。Guestshell 2.11 では、デフォルトで python 3.6 も含まれています。

デフォルトでは、ゲストシェルは 64 ビットの実行スペースです。32 ビットのサポートが必要な場合は、glibc.i686 パッケージを dnf でインストールできます。

Guestshell は、スイッチの管理ポートとデータ ポートを表すために使用される Linux ネットワーク インターフェイスにアクセスできます。ifconfig と ethtool などの典型的な Linux のメソッドとユーティリティは、カウンターの収集に使用できます。インターフェイスが NX-OS CLI で VRF に配置されると、Linux ネットワーク インターフェイスはその VRF のネットワーク名前空間に配置されます。名前空間は /var/run/netns で見ることができ、ip netns ユーティリティを使用してさまざまな名前空間のコンテキストで実行できます。いくつかのユーティリティ、chvrf と vrfinfo は、別の名前空間で実行し、プロセスが実行されている名前空間 /vrf に関する情報を取得するために提供されています。

systemd は、ゲストシェルを含む CentOS 8 環境でサービスを管理するために使用されます。

- Guest Shell の NX-OS CLI

- Guest Shell でのネットワーク アクセス

- ゲスト シェルでのブートフラッシュへのアクセス

- Guest Shell の Python

- Guest Shell バージョン 2.10 までの Python 3（CentOS 7）

- Installing RPMs in the Guest Shell

Guest Shell の NX-OS CLI

ゲスト シェルは、ユーザーがゲスト シェル環境からホスト ネットワーク要素に NX-OS コマンドを発行できるようにするアプリケーションを提供します。dohost アプリケーションは、有効な NX-OS 構成または exec コマンドを受け入れ、それらをホスト ネットワーク要素に発行します。

dohost コマンドを呼び出すときは、各 NX-OS コマンドを一重引用符または二重引用符で囲むことができます：

dohost "<NXOS CLI>"

NX-OS CLI は連鎖させることができます：

[guestshell@guestshell ~]$ dohost "sh lldp time | in Hold" "show cdp global"
Holdtime in seconds: 120
Global CDP information:
CDP enabled globally
Refresh time is 21 seconds
Hold time is 180 seconds
CDPv2 advertisements is enabled
DeviceID TLV in System-Name(Default) Format
[guestshell@guestshell ~]$

NX-OS CLI は、各コマンドの間にセミコロンを追加することにより、NX-OS スタイルのコマンド チェーン技術を使用して一緒にチェーンすることもできます。（セミコロンの両側にスペースが必要です。）：

[guestshell@guestshell ~]$ dohost "conf t ; cdp timer 13 ; show run | inc cdp"
Enter configuration commands, one per line. End with CNTL/Z.
cdp timer 13
[guestshell@guestshell ~]$

（注）

を使用するリリース 7.0(3)I5(2) の場合、dohost コマンドを介してホストで発行されたコマンドは、ゲスト シェル ユーザの有効なロールに基づく特権で実行されます。

以前のバージョンのゲスト シェルは、ネットワーク管理者レベルの権限でコマンドを実行します。

NX-API への UDS 接続の数が最大許容数に達すると、dohost コマンドは機能不全になります。

Guest Shell でのネットワーク アクセス

NX-OS スイッチ ポートは、Guest Shell では Linux ネットワーク インターフェイスとして表されます。ifconfig または ethtool を使用して、/proc/net/dev の表示統計などの一般的な Linux メソッドはすべてサポートされています。

Guest Shell には、多くの一般的なネットワーク ユーティリティがデフォルトで含まれており、 chvrf vrf command コマンドを使用してさまざまな VRF で使用できます。

[guestshell@guestshell bootflash]$ ifconfig Eth1-47
Eth1-47: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 13.0.0.47 netmask 255.255.255.0 broadcast 13.0.0.255
ether 54:7f:ee:8e:27:bc txqueuelen 100 (Ethernet)
RX packets 311442 bytes 21703008 (20.6 MiB)
RX errors 0 dropped 185 overruns 0 frame 0
TX packets 12967 bytes 3023575 (2.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Guest Shell 内では、ネットワーク状態をモニタリングできますが、変更することはできません。ネットワーク状態を変更するには、ホストの bash シェルで NX-OS CLI または適切な Linux ユーティリティを使用します。

この tcpdump コマンドはGuest Shell にパッケージ化されており、管理ポートまたはスイッチ ポートでパントされたトラフィックのパケット トレースを可能にします。

この sudo ip netns exec management ping ユーティリティは、指定されたネットワーク名前空間のコンテキストでコマンドを実行するための一般的な方法です。これはGuest Shell 内で実行できます。

[guestshell@guestshell bootflash]$ sudo ip netns exec management ping 10.28.38.48
PING 10.28.38.48 (10.28.38.48) 56(84) bytes of data.
64 bytes from 10.28.38.48: icmp_seq=1 ttl=48 time=76.5 ms

chvrf ユーティリティは便宜のために提供されています。

guestshell@guestshell bootflash]$ chvrf management ping 10.28.38.48
PING 10.28.38.48 (10.28.38.48) 56(84) bytes of data.
64 bytes from 10.28.38.48: icmp_seq=1 ttl=48 time=76.5 ms

（注）

コマンドなしで実行される chvrf コマンドは、現在の VRF / ネットワーク名前空間で実行されます。

たとえば、管理 VRF 経由で IP アドレス 10.0.0.1 を ping するには、コマンドは「chvrf management ping 10.0.0.1 」です。 scp または ssh などの他のユーティリティも同様です。

例：

switch# guestshell
[guestshell@guestshell ~]$ cd /bootflash
[guestshell@guestshell bootflash]$ chvrf management scp foo@10.28.38.48:/foo/index.html index.html
foo@10.28.38.48's password:
index.html 100% 1804 1.8KB/s 00:00
[guestshell@guestshell bootflash]$ ls -al index.html
-rw-r--r-- 1 guestshe users 1804 Sep 13 20:28 index.html
[guestshell@guestshell bootflash]$
[guestshell@guestshell bootflash]$ chvrf management curl cisco.com
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.cisco.com/">here</a>.</p>
</body></html>
[guestshell@guestshell bootflash]$

システム上の VRF のリストを取得するには、NX-OS からネイティブに、show vrf または dohost コマンドを介してコマンドを使用します。

例：

[guestshell@guestshell bootflash]$ dohost 'sh vrf'
VRF-Name   VRF-ID  State     Reason
default    1       Up        --
management 2       Up        --
red        6       Up        --

Guest Shell 内では、VRF に関連付けられたネットワーク名前空間が実際に使用されます。どのネットワーク名前空間が存在するかを確認する方が便利な場合があります。

[guestshell@guestshell bootflash]$ ls /var/run/netns
default management red
[guestshell@guestshell bootflash]$

Guest Shell 内からドメイン名を解決するには、リゾルバーを構成する必要があります。Guest Shell で /etc/resolv.conf ファイルを編集して、ネットワークに適した DNS ネームサーバとドメインを含めます。

例：

nameserver 10.1.1.1
domain cisco.com

ネームサーバーとドメインの情報は、NX-OS 構成で構成されたものと一致する必要があります。

例：

switch(config)# ip domain-name cisco.com
switch(config)# ip name-server 10.1.1.1
switch(config)# vrf context management
switch(config-vrf)# ip domain-name cisco.com
switch(config-vrf)# ip name-server 10.1.1.1

スイッチが HTTP プロキシ サーバーを使用するネットワーク内にある場合、http_proxy および https_proxy 環境変数も Guest Shell 内で設定する必要があります。

例：

export http_proxy=http://proxy.esl.cisco.com:8080
export https_proxy=http://proxy.esl.cisco.com:8080

これらの環境変数は、.bashrc ファイルまたは適切なスクリプトで設定して、永続的であることを確認する必要があります。

ゲスト シェルでのブートフラッシュへのアクセス

ネットワーク管理者は、NX-OS CLI コマンドの使用に加えて、Linux コマンドとユーティリティを使用してファイルを管理できます。ゲスト シェル環境の /bootflash にシステム ブートフラッシュをマウントすることにより、network-admin は Linux コマンドを使用してこれらのファイルを操作できます。

例：

find . –name “foo.txt”
rm “/bootflash/junk/foo.txt”

Guest Shell の Python

Python はインタラクティブに使用できますが、python スクリプトをゲスト シェルで実行することもできます。

例：

guestshell:~$ python
Python 2.7.5 (default, Jun 24 2015, 00:41:19)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
guestshell:~$

ネットワーク管理者が新しい Python パッケージをインストールできるように、ゲスト シェルには pip python パッケージ マネージャが含まれています。

例：

[guestshell@guestshell ~]$ sudo su
[root@guestshell guestshell]# pip install Markdown
Collecting Markdown
Downloading Markdown-2.6.2-py2.py3-none-any.whl (157kB)
100% |################################| 159kB 1.8MB/s
Installing collected packages: Markdown
Successfully installed Markdown-2.6.2
[root@guestshell guestshell]# pip list | grep Markdown
Markdown (2.6.2)
[root@guestshell guestshell]#

（注）

pip install コマンドを入力する前に、sudo su コマンドを入力する必要があります。

Guest Shell バージョン 2.10 までの Python 3（CentOS 7）

ゲスト シェル 2.X は、デフォルトで Python 3 がインストールされていない CentOS 7.1 環境を提供します。CentOS 7.1 に Python 3 をインストールするには、サードパーティのリポジトリを使用する、送信元からビルドするなど、複数の方法があります。別のオプションは、同じシステム内に複数のバージョンの Python のインストールをサポートする Red Hat Software Collections を使用することです。

Red Hat Software Collections（SCL）ツールをインストールするには:

1. scl-utils パッケージをインストールします。

2. CentOS SCL リポジトリを有効にして、提供されている Python 3 RPM のいずれかをインストールします。

[admin@guestshell ~]$ sudo su
[root@guestshell admin]# yum install -y scl-utils | tail
Running transaction test
Transaction test succeeded
Running transaction
Installing : scl-utils-20130529-19.el7.x86_64                             1/1
Verifying  : scl-utils-20130529-19.el7.x86_64                             1/1

Installed:
scl-utils.x86_64 0:20130529-19.el7

Complete!

[root@guestshell admin]# yum install -y centos-release-scl | tail
Verifying  : centos-release-scl-2-3.el7.centos.noarch                     1/2
Verifying  : centos-release-scl-rh-2-3.el7.centos.noarch                  2/2

Installed:
centos-release-scl.noarch 0:2-3.el7.centos

Dependency Installed:
centos-release-scl-rh.noarch 0:2-3.el7.centos

Complete!

[root@guestshell admin]# yum install -y rh-python36 | tail
warning: /var/cache/yum/x86_64/7/centos-sclo-rh/packages/rh-python36-2.0-1.el7.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID f2ee9d55: NOKEY
http://centos.sonn.com/7.7.1908/os/x86_64/Packages/groff-base-1.22.2-8.el7.x86_64.rpm: [Errno 12] Timeout on http://centos.sonn.com/7.7.1908/os/x86_64/Packages/groff-base-1.22.2-8.el7.x86_64.rpm: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')
Trying other mirror.
Importing GPG key 0xF2EE9D55:
Userid     : "CentOS SoftwareCollections SIG (https://wiki.centos.org/SpecialInterestGroup/SCLo) <security@centos.org>"
Fingerprint: c4db d535 b1fb ba14 f8ba 64a8 4eb8 4e71 f2ee 9d55
Package    : centos-release-scl-rh-2-3.el7.centos.noarch (@extras)
From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-SCLo
rh-python36-python-libs.x86_64 0:3.6.9-2.el7
rh-python36-python-pip.noarch 0:9.0.1-2.el7
rh-python36-python-setuptools.noarch 0:36.5.0-1.el7
rh-python36-python-virtualenv.noarch 0:15.1.0-2.el7
rh-python36-runtime.x86_64 0:2.0-1.el7
scl-utils-build.x86_64 0:20130529-19.el7
xml-common.noarch 0:0.6.3-39.el7
zip.x86_64 0:3.0-11.el7

Complete!

SCL を使用すると、Python 3 の環境変数を自動的に設定して、インタラクティブな bash セッションを作成できます。

（注）

SCL Python インストールを使用するためにルート ユーザーは必要ありません。

[admin@guestshell ~]$ scl enable rh-python36 bash
[admin@guestshell ~]$ python3
Python 3.6.9 (default, Nov 11 2019, 11:24:16)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Python SCL のインストールでは、pip ユーティリティも提供されます。

[admin@guestshell ~]$ pip3 install requests --user
Collecting requests
Downloading https://files.pythonhosted.org/packages/51/bd/23c926cd341ea6b7dd0b2a00aba99ae0f828be89d72b2190f27c11d4b7fb/requests-2.22.0-py2.py3-none-any.whl (57kB)
100% |################################| 61kB 211kB/s
Collecting idna<2.9,>=2.5 (from requests)
Downloading https://files.pythonhosted.org/packages/14/2c/cd551d81dbe15200be1cf41cd03869a46fe7226e7450af7a6545bfc474c9/idna-2.8-py2.py3-none-any.whl (58kB)
100% |################################| 61kB 279kB/s
Collecting chardet<3.1.0,>=3.0.2 (from requests)
Downloading https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl (133kB)
100% |################################| 143kB 441kB/s
Collecting certifi>=2017.4.17 (from requests)
Downloading https://files.pythonhosted.org/packages/b9/63/df50cac98ea0d5b006c55a399c3bf1db9da7b5a24de7890bc9cfd5dd9e99/certifi-2019.11.28-py2.py3-none-any.whl (156kB)
100% |################################| 163kB 447kB/s
Collecting urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 (from requests)
Downloading https://files.pythonhosted.org/packages/e8/74/6e4f91745020f967d09332bb2b8b9b10090957334692eb88ea4afe91b77f/urllib3-1.25.8-py2.py3-none-any.whl (125kB)
100% |################################| 133kB 656kB/s
Installing collected packages: idna, chardet, certifi, urllib3, requests
Successfully installed certifi-2019.11.28 chardet-3.0.4 idna-2.8 requests-2.22.0 urllib3-1.25.8
You are using pip version 9.0.1, however version 20.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
[admin@guestshell ~]$ python3
Python 3.6.9 (default, Nov 11 2019, 11:24:16)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> requests.get("https://cisco.com")
<Response [200]>

デフォルトの Python 2 インストールは、SCL Python インストールと一緒に使用できます。

[admin@guestshell ~]$ which python3
/opt/rh/rh-python36/root/usr/bin/python3
[admin@guestshell ~]$ which python2
/bin/python2
[admin@guestshell ~]$ python2
Python 2.7.5 (default, Aug  7 2019, 00:51:29)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print 'Hello world!'
Hello world!

Software Collections を使用すると、同じ RPM の複数のバージョンをシステムにインストールできます。この場合、Python 3.6 に加えて Python 3.5 をインストールすることが可能です。

[admin@guestshell ~]$ sudo yum install -y rh-python35 | tail
Dependency Installed:
rh-python35-python.x86_64 0:3.5.1-13.el7
rh-python35-python-devel.x86_64 0:3.5.1-13.el7
rh-python35-python-libs.x86_64 0:3.5.1-13.el7
rh-python35-python-pip.noarch 0:7.1.0-2.el7
rh-python35-python-setuptools.noarch 0:18.0.1-2.el7
rh-python35-python-virtualenv.noarch 0:13.1.2-2.el7
rh-python35-runtime.x86_64 0:2.0-2.el7

Complete!

[admin@guestshell ~]$ scl enable rh-python35 python3
Python 3.5.1 (default, May 29 2019, 15:41:33)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

（注）

複数の Python バージョンが SCL にインストールされているときに新しいインタラクティブ bash セッションを作成すると、libpython 共有オブジェクト ファイルをロードできないという問題が発生する可能性があります。source scl_source enable python-installation コマンドを使用して、現在の bash セッションで環境を適切にセットアップできる回避策があります。

デフォルトの Guest Shell ストレージのキャパシティが、Python 3 をインストールするのに十分ではありません。guestshell resize rootfs size-in-MB コマンドを使用して、ファイル システムのサイズを増やします。通常、rootfs のサイズを 550 MB に設定すれば十分です。

Installing RPMs in the Guest Shell

The /etc/yum.repos.d/CentOS-Base.repo file is set up to use the CentOS mirror list by default. Follow instructions in that file if changes are needed.

Yum can be pointed to one or more repositories at any time by modifying the yumrepo_x86_64.repo file or by adding a new .repo file in the repos.d directory.

For applications to be installed inside Guest Shell 2.x, go to the CentOS 7 repo at http://mirror.centos.org/centos/7/os/x86_64/Packages/.

Yum resolves the dependencies and installs all the required packages.

[guestshell@guestshell ~]$ sudo chvrf management yum -y install glibc.i686
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: bay.uchicago.edu
* extras: pubmirrors.dal.corespace.com
* updates: mirrors.cmich.edu
Resolving Dependencies
"-->" Running transaction check
"--->" Package glibc.i686 0:2.17-78.el7 will be installed
"-->" Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.17-78.el7.i686
"-->" Processing Dependency: libfreebl3.so for package: glibc-2.17-78.el7.i686
"-->" Running transaction check
"--->" Package nss-softokn-freebl.i686 0:3.16.2.3-9.el7 will be installed
"-->" Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================================================
Package Arch Version Repository Size
============================================================================================================================================================================
Installing:
glibc i686 2.17-78.el7 base 4.2 M
Installing for dependencies:
nss-softokn-freebl i686 3.16.2.3-9.el7 base 187 k

Transaction Summary
============================================================================================================================================================================
Install 1 Package (+1 Dependent package)

Total download size: 4.4 M
Installed size: 15 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
(1/2): nss-softokn-freebl-3.16.2.3-9.el7.i686.rpm | 187 kB 00:00:25
(2/2): glibc-2.17-78.el7.i686.rpm | 4.2 MB 00:00:30
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 145 kB/s | 4.4 MB 00:00:30
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : nss-softokn-freebl-3.16.2.3-9.el7.i686 1/2
Installing : glibc-2.17-78.el7.i686 2/2
error: lua script failed: [string "%triggerin(glibc-common-2.17-78.el7.x86_64)"]:1: attempt to compare number with nil
Non-fatal "<"unknown">" scriptlet failure in rpm package glibc-2.17-78.el7.i686
Verifying : glibc-2.17-78.el7.i686 1/2
Verifying : nss-softokn-freebl-3.16.2.3-9.el7.i686 2/2

Installed:
glibc.i686 0:2.17-78.el7

Dependency Installed:
nss-softokn-freebl.i686 0:3.16.2.3-9.el7

Complete!

Note

When more space is needed in the Guest Shell root file system for installing or running packages, the guestshell resize roofs size-in-MB command is used to increase the size of the file system.

Note

Some open source software packages from the repository might not install or run as expected in the Guest Shell as a result of restrictions that have been put into place to protect the integrity of the host system.

仮想サービス のセキュリティ ポスチャ

スイッチでのゲスト シェルと仮想サービスの使用は、ネットワーク管理者がシステムの機能を管理または拡張できる多くの方法のうちの 2 つにすぎません。これらのオプションは、ネイティブ ホスト コンテキストから切り離された実行環境を提供することを目的としています。この分離により、ネイティブの実行環境と互換性がない可能性のあるソフトウェアをシステムに導入できます。また、システムの動作、パフォーマンス、またはスケールに影響を与えない環境でソフトウェアを実行することもできます。

- [デジタル署名されたアプリケーション パッケージ（Digitally Signed Application Packages）]

- [カーネル脆弱性パッチ（Kernel Vulnerability Patches）]

- [ASLR および X-Space のサポート（ASLR and X-Space Support）]

- 名前空間の分離

- ルートユーザーの制限

- リソース管理

[デジタル署名されたアプリケーション パッケージ（Digitally Signed Application Packages）]

デフォルトでは、Cisco ネットワーク要素は、アプリケーションのランタイムに有効な Cisco デジタル署名を提供することを要求します。Cisco のデジタル署名により、Cisco が開発したパッケージとアプリケーションの完全性が保証されます。

Cisco Nexus 9000 シリーズ スイッチは、署名されていない OVA ソフトウェア パッケージを許可する署名レベル ポリシーの構成をサポートしています。署名されていないパッケージと Cisco 署名されたパッケージで仮想サービスを作成できるようにするために、ネットワーク管理者は次を構成できます。

virtual-service
signing level unsigned

（注）

ゲスト シェル ソフトウェア パッケージには Cisco の署名があり、この構成は必要ありません。

[カーネル脆弱性パッチ（Kernel Vulnerability Patches）]

シスコは、既知の脆弱性に対処するプラットフォーム アップデートで、関連する Common Vulnerabilities and Exposures（CVE）に対応します。

[ASLR および X-Space のサポート（ASLR and X-Space Support）]

Cisco 9000 NX-OS は、ランタイム ディフェンスのためのアドレス空間 Layout Randomization（ASLR）と Executable Space Protection（X-Space）の使用をサポートしています。Cisco が署名したパッケージのソフトウェアは、この機能を利用します。システムに他のソフトウェアがインストールされている場合は、これらのテクノロジをサポートするホスト OS と開発ツールチェーンを使用して構築することをお勧めします。これにより、ソフトウェアが潜在的な侵入者に提示する潜在的な攻撃対象領域が減少します。

名前空間の分離

ホストと仮想サービスは、別々の名前空間に分けられます。これは、仮想サービスの実行スペースをホストから分離する基礎を提供します。名前空間の分離は、信頼境界間の偶発的または意図的なデータの上書きによるデータの損失やデータの破損から保護するのに役立ちます。また、機密データ漏洩を防止することにより、機密データの完全性を確保するのにも役立ちます。ある仮想サービスのアプリケーションは、別の仮想サービスのデータにアクセスできません。

ルートユーザーの制限

安全なコードを開発するためのベスト プラクティスとして、割り当てられたタスクを実行するために必要な最小限の特権でアプリケーションを実行することを推薦します。意図しないアクセスを防ぐために、Guest Shell に追加されたソフトウェアは、このベスト プラクティスに従う必要があります。

仮想サービス は Linux の機能が低下したことによる制限の対象となります。アプリケーションで root 権限を必要とする操作を実行する必要がある場合は、root アカウントの使用を、root アクセスが絶対に必要な最小限の操作セットに制限し、そのモードでアプリケーションを実行できる時間のハード制限などの他の制御を課します。

内のルートに対してドロップされる一連の Linux 機能は次のとおりです。

CAP_SYS_BOOT

CAP_MKNOD

CAP_SYS_PACCT

CAP_SYS_MODULE

CAP_MAC_OVERRIDE

CAP_SYS_RESOURCE

CAP_SYS_TIME

CAP_SYS_RAWIO

CAP_AUDIT_WRITE

CAP_AUDIT_CONTROL

CAP_SYS_NICE

CAP_NET_ADMIN

CAP_MAC_ADMIN

CAP_SYS_PTRACE

仮想サービス内のルートとして、tmpfs と ramfs マウントだけでなくバインド マウントも使用できます。他のマウントは防止されます。

リソース管理

DDoS 攻撃は、攻撃対象のユーザがマシンやネットワーク 技術情報を使用できないようにする試みます。不適切な動作または悪意のあるアプリケーション コードは、接続帯域幅、ディスク容量、メモリ、およびその他のリソースの過剰消費の結果として DoS を引き起こす可能性があります。ホストは、で技術情報を公平に割り当てる技術情報管理機能を提供します。

ゲスト ファイル システムのアクセス制限

仮想サービス内のファイルの完全性を維持するために、仮想サービスのファイル システムには NX-OS CLI からアクセスできません。特定の仮想サービスがファイルの変更を許可している場合、これを実行できる代替手段 (つまりyum install、 scp 、ftp など) を提供する必要があります。

ホストの [ブートフラッシュ：（bootflash:）] と [揮発性：（volatile:）] は、ゲスト シェル内で [ / ブートフラッシュ（/bootflash）] および [ / 揮発性（/volatile）] としてマウントされます。ネットワーク管理者は、ホストから NX-OS exec コマンドを使用するか、ゲスト シェル内から Linux コマンドを使用して、このメディア上のファイルにアクセスできます。

ゲスト シェルの管理

以下は、ゲスト シェルを管理するためのコマンドです。

ゲスト シェル CLI コマンド

コマンド

説明

guestshell enable {package [guest shell OVA file | rootfs-file-URI]}

- [ゲストシェルOVAファイル（guest shell OVA file）] 指定時：

システム イメージに組み込まれている OVA を使用して、ゲスト シェルをインストールしてアクティブ化します。

指定されたソフトウェア パッケージ（OVA ファイル）またはシステム イメージからの組み込みパッケージ（パッケージが指定されていない場合）を使用して、ゲスト シェルをインストールしてアクティブ化します。当初、ゲスト シェル パッケージは、システム イメージに埋め込むことによってのみ利用できます。

ゲスト シェルがすでにインストールされている場合、このコマンドはインストールされているゲスト シェルを有効にします。通常、これは guestshell disable コマンドの後に使用されます。

- rootfs-file-URI が指定されている場合：

ゲスト シェルが破棄された状態のときに、ゲスト シェル rootfs をインポートします。このコマンドは、指定されたパッケージでゲスト シェルを起動します。

guestshell export rootfs package destination-file-URI

ゲスト シェルの rootfs ファイルをローカル URI（ブートフラッシュ、USB1 など）にエクスポートします。[（7.0（3）I7（1）以降のリリース）]

guestshell disable

シャット ダウンとゲスト シェルの無効化

guestshell upgrade {package [guest shell OVA file | rootfs-file-URI]}

- [ゲストシェルOVAファイル（guest shell OVA file）] 指定時：

指定されたソフトウェア パッケージ（OVA ファイル）またはシステム イメージからの組み込みパッケージ（パッケージが指定されていない場合）を使用して、ゲスト シェルを非アクティブ化してアップグレードします。当初、ゲスト シェル パッケージは、システム イメージに埋め込むことによってのみ利用できます。

ゲスト シェルの現在の rootfs は、ソフトウェア パッケージの rootfs に置き換えられます。ゲスト シェルは、アップグレード後も持続するセカンダリ ファイル システムを利用しません。永続的なセカンダリ ファイルシステムがない場合、guestshell destroy コマンドに続けてguestshell enable コマンドを使用して rootfs を置き換えることもできます。アップグレードが成功すると、ゲスト シェルがアクティブ化されます。

アップグレード コマンドを実行する前に、確認を求めるプロンプトが表示されます。

- rootfs-file-URI が指定されている場合：

ゲスト シェルがすでにインストールされている場合、ゲスト シェルの rootfs ファイルをインポートします。このコマンドは、既存のゲスト シェルを削除します。

指定されたパッケージにインストールします。

guestshell reboot

ゲスト シェルを非アクティブ化してから、再度アクティブ化します。

リブート コマンドを実行する前に、確認を求めるプロンプトが表示されます。

（注）

これは、exec モードで guestshell disable コマンドの後に guestshell enable コマンドが続くのと同じです。

これは、ゲスト シェル内のプロセスが停止しており、再起動する必要がある場合に役立ちます。この run guestshell コマンドは、ゲスト シェルで実行されている sshd に依存しています。

コマンドが機能しない場合は、sshd プロセスが誤って停止した可能性があります。NX-OS CLI からゲスト シェルの再起動を実行すると、再起動してコマンドを復元できます。

guestshell destroy

ゲスト シェル サービスを非アクティブ化して、アンインストールします。ゲスト シェルに関連付けられているすべての技術情報がシステムに返されます。この show virtual-service global コマンドは、これらの技術情報がいつ利用可能になるかを示します。

このコマンドを発行すると、destroy コマンドを実行する前に確認を求めるプロンプトが表示されます。

guestshell

run guestshell

シェル プロンプトですでに実行されているゲスト シェルに接続します。必要なユーザー名 / パスワード

guestshell run command

run guestshell command

ゲスト シェル環境のコンテキスト内で Linux / UNIX コマンドを実行します。

コマンドの実行後、スイッチ プロンプトに戻ります。

guestshell resize[cpu |memory |rootfs]

ゲスト シェルに割り当てられた使用可能な技術情報を変更します。変更は、次にゲスト シェルが有効化または再起動されたときに有効になります。

（注）

サイズ変更の値は、guestshell destroy コマンドを使用するとクリアされます。

guestshell sync

アクティブ スーパーバイザとスタンバイ スーパーバイザがあるシステムでは、このコマンドはゲスト シェルの格納ファイルをアクティブ スーパーバイザからスタンバイ スーパーバイザに同期します。network-admin は、スタンバイ スーパーバイザが現用系スーパーバイザになったときに同じ rootfs を使用するようにゲスト シェル rootfs が設定されているときに、このコマンドを発行します。このコマンドを使用しない場合、スタンバイ スーパーバイザがそのスーパーバイザで利用可能なゲスト シェル パッケージを使用してアクティブ ロールに移行するときに、ゲスト シェルが新たにインストールされます。

virtual-service reset force

ゲストシェルまたは仮想サービスを管理できない場合は、システムのリロード後でも、reset コマンドを使用してゲスト シェルとすべての仮想サービスを強制的に削除します。クリーンアップを実行するには、システムを再ロードする必要があります。このコマンドを発行した後は、システムがリロードされるまで、ゲスト シェルまたは追加の仮想サービスをインストールまたは有効にすることはできません。

リセットを開始する前に確認を求められます。

（注）

ゲスト シェル環境を有効化 / 無効化し、アクセスするには、管理者権限が必要です。

（注）

ゲスト シェルは、ホスト システム上の Linux コンテナ（LXC）として導入されます。NX-OS デバイスでは、LXC は virtual-service コマンドでインストールと管理されます。ゲスト シェルは、virtual-service コマンドに guestshell+ という名前の仮想サービスとして表示されます。

- Guest Shell の無効化

- ゲスト シェルの破棄

- Guest Shell の有効化

- ゲスト シェルの複製

Guest Shell の無効化

guestshell disable コマンドはシャットダウンして、Guest Shell を無効化します。

Guest Shell が無効化された状態でシステムをリロードすると、Guest Shell は無効化されたままになります。

例：

switch# show virtual-service list
Virtual Service List:
Name                    Status          Package Name
-----------------------------------------------------------
guestshell+             Activated        guestshe11.ova
switch# guestshell disable
You will not be able to access your guest shell if it is disabled. Are you sure you want to disable the guest shell? (y/n) [n) y

2014 Jul 30 19:47:23 switch %$ VDC-1 %$ %VMAN-2-ACTIVATION_STATE: Deactivating virtual service 'guestshell+'
2014 Jul 30 18:47:29 switch %$ VDC-1 %$ %VMAN-2-ACTIVATION_STATE: Successfully deactivated virtual service 'guestshell+'
switch# show virtual-service list
Virtual Service List:
Name                    Status                   Package Name
guestshell+             Deactivated              guestshell.ova

（注）

guestshell enable コマンドで Guest Shell が再アクティブ化されます。

ゲスト シェルの破棄

guestshell destroy コマンドは、ゲスト シェルとそのアーティファクトをアンインストールします。このコマンドでは、ゲスト シェル OVA は削除されません。

ゲスト シェルが破棄された状態でシステムをリロードすると、ゲスト シェルは破棄されたままになります。

switch# show virtual-service list
Virtual Service List:
Name               Status          Package Name
-------------------------------------------------
guestshell+        Deactivated     guestshell.ova

switch# guestshell destroy

You are about to destroy the guest shell and all of its contents. Be sure to save your work. Are you sure you want to continue? (y/n) [n] y
2014 Jul 30 18:49:10 switch %$ VDC-1 %$ %VMAN-2-INSTALL_STATE: Destroying virtual service
'guestshell+'
2014 Jul 30 18:49:10 switch %$ VDC-1 %$ %VMAN-2-INSTALL_STATE: Successfully destroyed
virtual service 'guestshell +'

switch# show virtual-service list
Virtual Service List:

（注）

guestshell enable コマンドを使用して、ゲスト シェルを再度有効にすることができます。

（注）

ゲスト シェルを使用しない場合は、guestshell destroy コマンドで削除できます。ゲスト シェルが削除されると、その後のリロードのために削除されたままになります。つまり、ゲスト シェル コンテナが削除され、スイッチが再ロードされても、ゲスト シェル コンテナは自動的に開始されません。

Guest Shell の有効化

この guestshell enable コマンドは、Guest Shell ソフトウェア パッケージから Guest Shell をインストールします。デフォルトでは、システム イメージに埋め込まれたパッケージがインストールに使用されます。Guest Shell が無効化されている場合は、このコマンドを使用して、Guest Shell を再アクティブ化することもできます。

Guest Shell が有効化された状態でシステムをリロードすると、Guest Shell は有効化されたままになります。

例：

switch# show virtual-service list
Virtual Service List:
switch# guestshell enable
2014 Jul 30 18:50:27 switch %$ VDC-1 %$ %VMAN-2-INSTALL_STATE: Installing virtual service 'guestshell+'
2014 Jul 30 18;50;42 switch %$ VDC-1 %$ %VMAN-2-INSTALL_STATE: Install success virtual service 'guestshell+'; Activating

2014 Jul 30 18:50:42 switch %$ VDC-1 %$ %VMAN-2-ACTIVATION_STATE: Activating virtual service 'guestshell+'
2014 Jul 30 18:51:16 switch %$ VDC-1 %$ %VMAN-2-ACTIVATION_STATE: Successfully activated
virtual service 'guestshell+'

switch# show virtual-service list
Virtual Service List:
Name                    Status             Package Name
guestshell+             Activated          guestshell.ova

ゲスト シェルの複製

Cisco NX-OS リリース 7.0（3）I7（1）以降、1 つのスイッチでカスタマイズされたゲスト シェル rootfs を複数のスイッチに展開できます。

アプローチは、ゲスト シェル rootfs をカスタマイズしてからエクスポートし、ファイル サーバに保存することです。POAP スクリプトは、ゲスト シェル rootfs を他のスイッチにダウンロード (インポート) し、特定のゲスト シェルを多数のデバイスに同時にインストールできます。

- ゲスト シェル rootfs のエクスポート

- Guest Shell rootfs のインポート

- YAML ファイルのインポート

- show guestshell コマンド

ゲスト シェル rootfs のエクスポート

ゲスト シェル rootfs をエクスポートするには、guestshell export rootfs packagedestination-file-URI コマンドを使用します。

destination-file-URI パラメータは、ゲスト シェル rootfs のコピー先のファイルの名前です。このファイルでは、ローカル URI オプション（ブートフラッシュ、USB1 など）が可能です。

guestshell export rootfs package コマンドでは、次の処理が行われます。

- ゲスト シェルを無効にします（すでに有効になっている場合）。

- ゲスト シェル インポート YAML ファイルを作成し、rootfs ext4 ファイルの /cisco ディレクトリに挿入します。

- rootfs ext4 ファイルをターゲット URI の場所にコピーします。

- ゲスト シェルが以前に有効になっていた場合は、再度有効にします。

Guest Shell rootfs のインポート

Guest Shell rootfs をインポートする場合、考慮すべき 2 つの状況があります。

- Guest Shell が破棄された状態の場合は、 guestshell enable package rootfs-file-URI コマンドを使用して、Guest Shell rootfs をインポートします。このコマンドは、指定されたパッケージで Guest Shell を起動します。

- Guest Shell がすでにインストールされている場合は、 guestshell upgrade package rootfs-file-URI コマンドを使用して、Guest Shell rootfs をインポートします。このコマンドは、既存のGuest Shell を削除し、指定されたパッケージをインストールします。

rootfs-file-URI パラメータは、ローカル ストレージ（ブートフラッシュ、USB など）に保存されている rootfs ファイルです。

ブートフラッシュにあるファイルでこのコマンドを実行すると、ファイルはブートフラッシュのストレージ プールに移動されます。

ベスト プラクティスとして、 guestshell upgrade package rootfs-file-URI コマンドを使用する前に、ファイルをブートフラッシュにコピーし、md5sum を検証する必要があります。

（注）

guestshell upgrade package rootfs-file-URI コマンドは、Guest Shell 内から実行

（注）

rootfs ファイルはシスコの署名付きパッケージではありません。例に示すように、有効にする前に、署名されていないパッケージを許可するように設定する必要があります。

(config-virt-serv-global)# signing level unsigned
Note: Support for unsigned packages has been user-enabled. Unsigned packages are not endorsed by Cisco. User assumes all responsibility.

（注）

rootfs の組み込みバージョンを復元するには：

- Guest Shell が既にインストールされている場合は、 guestshell upgrade コマンドを（追加のパラメーターなしで）使用します。

- Guest Shell が破棄されたときに、 guestshell enable コマンドを（追加パラメータなしで）使用します。

（注）

Guest Shell 内から、または NX-API を使用してスイッチの外部からこのコマンドを実行する場合は、プロンプトをスキップするように設定する必要があります。terminal dont-ask

guestshell enable package rootfs-file-URI コマンド：

- rootfs ファイルの基本的な検証を実行します。

- rootfs をストレージ プールに移動します。

- rootfs をマウントして、/cisco ディレクトリから YAML ファイルを抽出します。

- YAML ファイルを解析して VM 定義（リソース要件を含む）を取得します。

- Guest Shell をアクティブにします。

guestshell enable のワークフローの例：

switch# copy scp://user@10.1.1.1/my_storage/gs_rootfs.ext4 bootflash: vrf management
switch# guestshell resize cpu 8
Note: System CPU share will be resized on Guest shell enable
switch# guestshell enable package bootflash:gs_rootfs.ext4
Validating the provided rootfs
switch# 2017 Jul 31 14:58:01 switch %$ VDC-1 %$ %VMAN-2-INSTALL_STATE: Installing virtual service 'guestshell+'
2017 Jul 31 14:58:09 switch %$ VDC-1 %$ %VMAN-2-INSTALL_STATE: Install success virtual service 'guestshell+'; Activating
2017 Jul 31 14:58:09 switch %$ VDC-1 %$ %VMAN-2-ACTIVATION_STATE: Activating virtual service 'guestshell+'
2017 Jul 31 14:58:33 switch %$ VDC-1 %$ %VMAN-2-ACTIVATION_STATE: Successfully activated virtual service 'guestshell+'

（注）

guestshell upgrade のワークフローの前に、既存の Guest Shell が破棄されます。

（注）

サイズ変更の値は、 guestshell upgrade コマンドを使用するとクリアされます。

YAML ファイルのインポート

Guest Shell のユーザーが変更可能ないくつかの特性を定義する YAML ファイルは、エクスポート操作の一部として自動的に作成されます。これは、/cisco ディレクトリの Guest Shell rootfs に組み込まれています。これは、Guest Shell コンテナの完全な記述子ではありません。ユーザーが変更できるパラメータの一部のみが含まれています。

Guest Shell インポート YAML ファイルの例：

---
import-schema-version: "1.0"
info:
name: "GuestShell"
version: "2.2(0.3)"
description: "Exported GuestShell: 20170216T175137Z"
app:
apptype: "lxc"
cpuarch: "x86_64"
resources:
cpu: 3
memory: 307200
disk:
- target-dir: "/"
capacity: 250
...

guestshell export rootfs package コマンドを実行すると、YAML ファイルが生成されます。このファイルは、現在実行中の Guest Shell の値をキャプチャします。

情報セクションには、Guest Shell の識別に役立つ非運用データが含まれています。show guestshell detail コマンドの出力に一部の情報が表示されます。

説明の値は、YAML ファイルが作成されたときの UTC 時間のエンコーディングです。時刻文字列のフォーマットは、RFC5545（iCal）の DTSTAMP と同じです。

リソース セクションでは、Guest Shell をホストするために必要な情報技術について説明します。この例の target-dir の値「/」は、ディスクを rootfs として識別します。

（注）

Guest Shell が破棄されたときにサイズ変更された値が指定された場合、 guestshell enable package コマンドの使用時にそれらの値がインポート YAML ファイルの値よりも優先されます。

cpuarch 値は、コンテナの実行が予想される CPU アーキテクチャを示します。

エクスポート操作が完了した後、YAML ファイルを変更できます（説明などを変更したり、必要に応じて技術情報パラメータを増やしたりできます）。

Cisco は、JSON スキーマを使用して変更された YAML ファイルを検証するために実行できる Python スクリプトを提供しています。完全なテストではありませんが（たとえば、デバイス固有のリソース制限はチェックされません）、一般的なエラーにフラグを付けることができます。例を含む Python スクリプトは、[Guest Shell インポート エクスポート（Guest Shell Import Export）]https://github.com/datacenter/opennxos/tree/master/guestshell_import_export にあります。 次の JSON ファイルは、Guest Shell インポート YAML のバージョン 1.0 のスキーマを記述しています。

{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "Guest Shell import schema",
"description": "Schema for Guest Shell import descriptor file - ver 1.0",
"copyright": "2017 by Cisco systems, Inc. All rights reserved.",
"id": "",
"type": "object",
"additionalProperties": false,
"properties": {
"import-schema-version": {
"id": "/import-schema-version",
"type": "string",
"minLength": 1,
"maxLength": 20,
"enum": [
"1.0"
]
},
"info": {
"id": "/info",
"type": "object",
"additionalProperties": false,
"properties": {
"name": {
"id": "/info/name",
"type": "string",
"minLength": 1,
"maxLength": 29
},
"description": {
"id": "/info/description",
"type": "string",
"minLength": 1,
"maxLength": 199
},
"version": {
"id": "/info/version",
"type": "string",
"minLength": 1,
"maxLength": 63
},
"author-name": {
"id": "/info/author-name",
"type": "string",
"minLength": 1,
"maxLength": 199
},
"author-link": {
"id": "/info/author-link",
"type": "string",
"minLength": 1,
"maxLength": 199
}
}
},
"app": {
"id": "/app",
"type": "object",
"additionalProperties": false,
"properties": {
"apptype": {
"id": "/app/apptype",
"type": "string",
"minLength": 1,
"maxLength": 63,
"enum": [
"lxc"
]
},
"cpuarch": {
"id": "/app/cpuarch",
"type": "string",
"minLength": 1,
"maxLength": 63,
"enum": [
"x86_64"
]
},
"resources": {
"id": "/app/resources",
"type": "object",
"additionalProperties": false,
"properties": {
"cpu": {
"id": "/app/resources/cpu",
"type": "integer",
"multipleOf": 1,
"maximum": 100,
"minimum": 1
},
"memory": {
"id": "/app/resources/memory",
"type": "integer",
"multipleOf": 1024,
"minimum": 1024
},
"disk": {
"id": "/app/resources/disk",
"type": "array",
"minItems": 1,
"maxItems": 1,
"uniqueItems": true,
"items": {
"id": "/app/resources/disk/0",
"type": "object",
"additionalProperties": false,
"properties": {
"target-dir": {
"id": "/app/resources/disk/0/target-dir",
"type": "string",
"minLength": 1,
"maxLength": 1,
"enum": [
"/"
]
},
"file": {
"id": "/app/resources/disk/0/file",
"type": "string",
"minLength": 1,
"maxLength": 63
},
"capacity": {
"id": "/app/resources/disk/0/capacity",
"type": "integer",
"multipleOf": 1,
"minimum": 1
}
}
}
}
},
"required": [
"memory",
"disk"
]
}
},
"required": [
"apptype",
"cpuarch",
"resources"
]
}
},
"required": [
"app"
]
}

show guestshell コマンド

show guestshell detail コマンドの出力には、ゲスト シェルがインポートされたか、OVA からインストールされたかを示す情報が含まれます。

rootfsをインポートした後の show guestshell detail コマンドの例。

switch# show guestshell detail
Virtual service guestshell+ detail
State                 : Activated
Package information
Name                : rootfs_puppet
Path                : usb2:/rootfs_puppet
Application
Name              : GuestShell
Installed version : 2.3(0.0)
Description       : Exported GuestShell: 20170613T173648Z
Signing
Key type          : Unsigned
Method            : Unknown
Licensing
Name              : None
Version           : None

仮想サービスと Guest Shell 情報の検証

次のコマンドを使用して、仮想サービスとゲスト シェルの情報を検証できます。

コマンド

説明

show virtual-service global

switch# show virtual-service global

Virtual Service Global State and Virtualization Limits:

Infrastructure version : 1.11
Total virtual services installed : 1
Total virtual services activated : 1

Machine types supported : LXC
Machine types disabled : KVM

Maximum VCPUs per virtual service : 1

Resource virtualization limits:
Name Quota Committed Available
-----------------------------------------------------------------------
system CPU (%) 20 1 19
memory (MB) 3840 256 3584
bootflash (MB) 8192 200 7992
switch#

仮想サービスのグローバル状態と制限を表示します。

show virtual-service list

switch# show virtual-service list *

Virtual Service List:

Name                    Status         Package Name
------------------------------------------------------------------
guestshell+             Activated      guestshell.ova
chef                    Installed      chef-0.8.1-n9000-spa-k9.ova

仮想サービスの概要、仮想サービスのステータス、およびインストールされているソフトウェア パッケージを表示します。

show guestshell detail

switch# show guestshell detail
Virtual service guestshell+ detail
State                 : Activated
Package information
Name                : guestshell.ova
Path                : /isan/bin/guestshell.ova
Application
Name              : GuestShell
Installed version : 2.2(0.2)
Description       : Cisco Systems Guest Shell
Signing
Key type          : Cisco key
Method            : SHA-1
Licensing
Name              : None
Version           : None
Resource reservation
Disk                : 400 MB
Memory              : 256 MB
CPU                 : 1% system CPU

Attached devices
Type              Name        Alias
---------------------------------------------
Disk              _rootfs
Disk              /cisco/core
Serial/shell
Serial/aux
Serial/Syslog                 serial2
Serial/Trace                  serial3

guestshell パッケージに関する詳細（バージョン、署名リソース、デバイスなど）を表示します。

ゲスト シェルからのアプリケーションの永続的な起動

アプリケーションには、 /usr/lib/systemd/system/application_name.service にインストールされる systemd / systemctl サービス ファイルが必要です。 このサービス ファイルは、次の一般的なフォーマットにする必要があります。

[Unit]
Description=Put a short description of your application here

[Service]
ExecStart=Put the command to start your application here
Restart=always
RestartSec=10s

[Install]
WantedBy=multi-user.target

（注）

特定のユーザーとして systemd を実行するには、サービスの [サービス（Service）] セクションに User=<username> を追加します。

Guest Shell からアプリケーションを永続的に起動する手順

手順

ステップ 1

上記で作成したアプリケーション サービス ファイルを /usr/lib/systemd/system/application_name にインストールします。サービス

ステップ 2

systemctl start application_name でアプリケーションを開始します

ステップ 3

アプリケーションが systemctl status -l application_name で実行されていることを確認します

ステップ 4

systemctl enable application_name でリロード時にアプリケーションを再起動できるようにします

ステップ 5

アプリケーションが systemctl status -l application_name で実行されていることを確認します

ゲスト シェルでのサンプル アプリケーション

次の例は、ゲスト シェルのアプリケーションを示しています。

root@guestshell guestshell]# cat /etc/init.d/hello.sh
#!/bin/bash

OUTPUTFILE=/tmp/hello

rm -f $OUTPUTFILE
while true
do
echo $(date) >> $OUTPUTFILE
echo 'Hello World' >> $OUTPUTFILE
sleep 10
done
[root@guestshell guestshell]#
[root@guestshell guestshell]#
[root@guestshell system]# cat /usr/lib/systemd/system/hello.service
[Unit]
Description=Trivial "hello world" example daemon

[Service]
ExecStart=/etc/init.d/hello.sh &
Restart=always
RestartSec=10s

[Install]
WantedBy=multi-user.target
[root@guestshell system]#
[root@guestshell system]# systemctl start hello
[root@guestshell system]# systemctl enable hello
[root@guestshell system]# systemctl status -l hello
hello.service - Trivial "hello world" example daemon
Loaded: loaded (/usr/lib/systemd/system/hello.service; enabled)
Active: active (running) since Sun 2015-09-27 18:31:51 UTC; 10s ago
Main PID: 355 (hello.sh)
CGroup: /system.slice/hello.service
##355 /bin/bash /etc/init.d/hello.sh &
##367 sleep 10

Sep 27 18:31:51 guestshell hello.sh[355]: Executing: /etc/init.d/hello.sh &
[root@guestshell system]#
[root@guestshell guestshell]# exit
exit
[guestshell@guestshell ~]$ exit
logout
switch# reload
This command will reboot the system. (y/n)?  [n] y

リロード後

[root@guestshell guestshell]# ps -ef | grep hello
root        20     1  0 18:37 ?        00:00:00 /bin/bash /etc/init.d/hello.sh &
root       123   108  0 18:38 pts/4    00:00:00 grep --color=auto hello
[root@guestshell guestshell]#
[root@guestshell guestshell]# cat /tmp/hello
Sun Sep 27 18:38:03 UTC 2015
Hello World
Sun Sep 27 18:38:13 UTC 2015
Hello World
Sun Sep 27 18:38:23 UTC 2015
Hello World
Sun Sep 27 18:38:33 UTC 2015
Hello World
Sun Sep 27 18:38:43 UTC 2015
Hello World
[root@guestshell guestshell]#

systemd / systemctl で実行すると、アプリケーションが停止した場合（または強制終了した場合）、アプリケーションは自動的に再起動されます。プロセス 識別子 はもともと 226 です。アプリケーションを強制終了すると、プロセス 識別子 257 で自動的に再起動されます。

[root@guestshell guestshell]# ps -ef | grep hello
root       226     1  0 19:02 ?        00:00:00 /bin/bash /etc/init.d/hello.sh &
root       254   116  0 19:03 pts/4    00:00:00 grep --color=auto hello
[root@guestshell guestshell]#
[root@guestshell guestshell]# kill -9 226
[root@guestshell guestshell]#
[root@guestshell guestshell]# ps -ef | grep hello
root       257     1  0 19:03 ?        00:00:00 /bin/bash /etc/init.d/hello.sh &
root       264   116  0 19:03 pts/4    00:00:00 grep --color=auto hello
[root@guestshell guestshell]#

Chapter5. Broadcom シェル

- Broadcom シェルについて

- Broadcom シェル（bcm-shell）へのアクセス

- Broadcom シェル コマンドの例

Broadcom シェルについて

Cisco Nexus 9000 シリーズ デバイスの前面パネルおよびファブリック モジュール ライン カードには、Broadcom ネットワーク転送エンジン（NFE）が搭載されています。NFE の数は、前面パネル ライン カード（LC）またはファブリック モジュール（FM）のモデルによって異なります。

ガイドラインと制約事項

T2 ASIC の情報は、制限なくアクセスして読み取ることができます。ただし、Cisco は T2 の構成設定の変更を推奨していません。Broadcom シェルにアクセスする場合は注意してください。

Broadcom シェル（bcm-shell）へのアクセス

次のセクションでは、Broadcom シェル（bcm-shell）にアクセスする方法について説明します。

- CLI API を使用した bcm-shell へのアクセス

- ファブリック モジュールのネイティブ bcm-shell へのアクセス

- ラインカードの bcm シェルへのアクセス

CLI API を使用した bcm-shell へのアクセス

bcm-shell コマンドは、Cisco NX-OS CLI から特定の T2 ASIC インスタンスに直接渡されます。T2 ASIC インスタンスは、ファブリック モジュールまたは前面パネル ライン カード上に配置できます。

コマンドの構文は、次のとおりです。

bcm-shell module module_number [instance_number:command]

場所

module_number

シャーシのモジュール番号。

instance_number

T2 インスタンス番号

- 指定しなかった場合、T2 インスタンス番号はデフォルトで 0 に設定されます。

- ワイルドカード（「*」）を指定すると、すべての T2 インスタンスが処理されます。

command

Broadcom コマンド

（注）

「pipe include」や「redirect output to file」などの Cisco NX-OS コマンド拡張を使用して、コマンド出力を管理できます。

（注）

CLI API を使用してコマンドを入力すると、監査目的でシステム アカウンティング ログに記録されます。bcm-shell から直接入力されたコマンドは、アカウンティング ログに記録されません。

次に、T2 インスタンス番号を入力しなかった場合の例を示します。

switch# bcm-shell module 26 "ports"
Executing ports on bcm shell on module 26
ena/ speed/ link auto STP lrn inter max loop
port link duplex scan neg? state pause discrd ops face frame back
hg0 !ena 42G FD HW No Forward None FA XGMII 16360
hg1 !ena 42G FD HW No Forward None FA XGMII 16360
hg2 !ena 42G FD HW No Forward None FA XGMII 16360
hg3 !ena 42G FD HW No Forward None FA XGMII 16360
hg4 !ena 42G FD HW No Forward None FA XGMII 16360
<snip>

次に、モジュール 26、T2 インスタンス 1 の bcm-shell の「ports」表示にアクセスし、パイプを使用して「up」状態のポートのみを表示する例を示します。

switch# bcm-shell module 26 "1:ports" | inc up
port link duplex scan neg? state pause discrd ops face frame back
hg9 up 42G FD HW No Forward None FA XGMII 16360
hg10 up 42G FD HW No Forward None FA XGMII 16360
hg11 up 42G FD HW No Forward None FA XGMII 16360

次に、T2 インスタンス番号をワイルドカード（「*」）で指定した場合の例を示します。

出力の最初のセットは、T2 インスタンス 0 の結果です。2 番目のセットは、ファブリック モジュールのインスタンス 1 の結果です。

switch# bcm-shell module 26 "*:ports" | inc up

port link duplex scan neg? state pause discrd ops face frame back
hg9 up 42G FD HW No Forward None FA XGMII 16360
hg10 up 42G FD HW No Forward None FA XGMII 16360
hg11 up 42G FD HW No Forward None FA XGMII 16360

port link duplex scan neg? state pause discrd ops face frame back
hg9 up 42G FD HW No Forward None FA XGMII 16360
hg10 up 42G FD HW No Forward None FA XGMII 16360
hg11 up 42G FD HW No Forward None FA XGMII 16360

（注）

または、スーパーバイザからモジュール（LC または FM）の bcm-shell に直接アクセスできます。次に、スーパーバイザから bcm-shell にアクセスする方法の例を示します。

switch# bcm-shell module 3
Entering bcm shell on module 3
Available Unit Numbers: 0 1
bcm-shell.0>

ファブリック モジュールのネイティブ bcm-shell へのアクセス

8 スロット ライン カード（LC）シャーシは、最大 6 つのファブリック モジュール（FM）をホストできます。これらのスロットには 21 ～ 26 の番号が付けられており、bcm-shell にアクセスする FM を指定する必要があります。

次に、スロット 24 の FM の bcm シェルにアクセスし、コンテキスト ヘルプにアクセスし、bcm シェルを終了する例を示します。

- show module コマンドを使用して FM を表示します。

switch# show module
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
3 36 36p 40G Ethernet Module N9k-X9636PQ ok
4 36 36p 40G Ethernet Module N9k-X9636PQ ok
21 0 Fabric Module Nexus-C9508-FM ok
22 0 Fabric Module Nexus-C9508-FM ok
23 0 Fabric Module Nexus-C9508-FM ok
24 0 Fabric Module Nexus-C9508-FM ok
25 0 Fabric Module Nexus-C9508-FM ok
26 0 Fabric Module Nexus-C9508-FM ok
27 0 Supervisor Module Nexus-SUP-A active *
29 0 System Controller Nexus-SC-A active

- モジュール 24 に接続して、スロット 24 の FM のコマンド ラインにアクセスします。

switch# attach module 24
Attaching to module 24 ...
To exit type 'exit', to abort type '$.'

- コマンドを入力して、ファブリック モジュール ソフトウェアへの root アクセスを取得します。

module-24# test hardware internal bcm-usd bcm-diag-shell
Available Unit Numbers: 0 1
bcm-shell.0> 1

この時点で、スロット 24、T2 ASIC インスタンス 1 のファブリック モジュールの Broadcom シェルが表示されます。入力するすべてのコマンドは、この特定の ASIC インスタンスに固有のものです。

- 「?」と入力すると、コンテキスト ヘルプが表示され、使用可能なコマンドが表示されます。

help: "??" or "help" for summary
Commands common to all modes:
?        ??        ASSert     BackGround  BCM
BCMX     break     BroadSync  CASE        CD
cint     CONFig    CONSole    CoPy        CPUDB
CTEcho   CTInstall CTSetup    DATE        DBDump
DBParse  DeBug     DeBugMod   DELAY       DEVice

（注）

大文字はコマンドの省略形を示します。

（注）

TAB を使用してコマンド入力を補完する Cisco CLI 機能は使用できません。

- コマンドの省略形を入力します。

bcm-shell.1> conf ?
Usage (CONFig): Parameters: show <substring> | refresh |
save [filename=<filename>] [pattern=<substring>] |
add [<var>=<value>] | delete <var>
If no parameters are given, displays the current config vars.
show              display current config vars.
Next parameter (optional) maybe a substring to match
refresh           reload config vars from non-volatile storage
save              save config vars to non-volatile storage.
it can optionally save current config to any given file
providing the optional <pattern> will only save variables matching the pattern
<var>=<value>     change the value of a config var
add <var>=<value> create a new config var
delete <var>      deletes a config var
clear             deletes all config vars
=                 prompt for new value for each config var
NOTE: changes are not retained permanently unless saved

- bcm シェルを終了し、FM から切り離すには、exit コマンドを使用します。

bcm-shell.1> exit
module-24# exit
rlogin: connection closed.

ラインカードの bcm シェルへのアクセス

ライン カード（LC）の T2 ASIC に接続する場合は、まずモジュールに接続し、root モードを開始し、shell access exec を実行して、接続する ASIC インスタンスを選択します。使用可能な ASIC の数は、接続しているライン カードのモデルによって異なります。

次に、スロット 2 の LC の ASIC インスタンス 1 の bcm シェルにアクセスし、3 つの T2 インスタンスを含む LC の bcm シェルを終了する例を示します。

- モジュール 2 に接続して、スロット 2 の LC のコマンドラインにアクセスします。

switch# attach module 2
Attaching to module 2 ...
To exit type 'exit', to abort type '$.'
Last login: Wed Aug 7 14:13:15 UTC 2013 from sup27 on ttyp0

- コマンドを入力して、ラインカード ソフトウェアへの root アクセスを取得します。

switch-2# test hardware internal bcm-usd bcm-diag-shell
Available Unit Numbers: 0 1 2
bcm-shell.0> 1
bcm-shell.1>

この時点で、スロット 2、T2 ASIC インスタンス 1 のライン カード モジュールの Broadcom シェルを使用している状態になっています。

- exit コマンドを使用して bcm シェルを終了し、FM から切り離します。

bcm-shell.1> exit
module-2# exit
rlogin: connection closed.

Broadcom シェル コマンドの例

このセクションには、Broadcom シェル コマンドと出力の例が含まれています。

- L2 エントリの表示

- FM および LC ASIC インスタンスからのルーティング情報の表示

- スパニング ツリー グループ エントリの表示

- インターフェイス xe0 の T2 カウンタの表示

- L3 情報の表示

L2 エントリの表示

FM と LC 上の L2 エントリを比較するには、T2 インスタンスの L2 エントリを表示します。

- シャーシ内の LC 上の T2 インスタンスにアタッチし、show the l2_mem_entries コマンドを入力します。

switch# bcm-shell module 2 “config show l2_mem_entries”
l2_mem_entries=163840

- シャーシ内の FM 上の T2 インスタンスにアタッチし、show the l2_mem_entries コマンドを入力します。

switch# bcm-shell module 24 “config show l2_mem_entries”
l2_mem_entries=32768

この例では、T2 ASIC の動作モード設定が LC と FM で異なるため、ASIC には L2 エントリに異なる値が設定されています。

FM および LC ASIC インスタンスからのルーティング情報の表示

次に、FM インスタンスおよび LC ASIC インスタンスからのルーティング情報を表示する方法を示します。

（注）

- FM モジュール ASIC インスタンスは、最長プレフィックス一致（LPM）エントリを維持します。

- LC モジュール ASIC インスタンスは、ホスト ルートを維持します。

- いずれかの FM ASIC インスタンスの bcm シェルに接続し、l3 defip show コマンドを入力します。

switch# bcm-shell module 22 “l3 defip show”
Unit 0, Total Number of DEFIP entries: 16385
#  VRF  Net addr        Next Hop Mac       INTF  MODID PORT PRIO CLASS HIT VLAN
0  1    192.168.1.0/24  00:00:00:00:00:00  10000 4     0    0    0     0    n
0  1    192.168.2.0/24  00:00:00:00:00:00  10000 4     0    0    0     0    n

- いずれかの LC ASIC インスタンスの bcm シェルに接続し、l3 defip show コマンドを入力します。

switch# bcm-shell module 2 “l3 defip show”
Unit 2, Total Number of DEFIP entries: 8193
#     VRF       Net addr   Next Hop Mac      INTF  MODID PORT PRIO CLASS HIT VLAN
2048  Override  0.0.0.0/0  00:00:00:00:00:00 10000 4     0    0    0     0   n

スパニング ツリー グループ エントリの表示

次に、スパニング ツリー グループ（STG）エントリを表示する方法を示します。

switch# bcm-shell module 2 “stg show”
STG 0: contains 7 VLANs (4032-4035,4042,4044,4095)
Forward: xe,hg
STG 1: contains 1 VLAN (4043)
Disable: xe
Forward: hg
STG 4: contains 1 VLAN (1)
Block: xe
Forward: hg
STG 5: contains 1 VLAN (100)
Block: xe
Forward: hg

インターフェイス xe0 の T2 カウンタの表示

次に、前面パネル ポートにマッピングされるインターフェイス xe0 の T2 カウンタを表示する方法を示します。

switch# bcm-shell module 2 “show counters xe0”
RDBGC1.xe0 : 38,169  +4
R127.xe0   : 37,994  +4
R511.xe0   : 16,562  +2
RPKT.xe0   : 55,046  +6
RMCA.xe0   : 54,731  +6
<snip>

（注）

出力の右端に「+」で示されている数字は、最後の show コマンドが実行されてからのカウンタ値の変化を示しています。

L3 情報の表示

次に、T2 から L3 情報を表示する方法を示します。.

switch# bcm-shell module 2 “l3 l3table show”
Unit 0, free L3 table entries: 147448
Entry  VRF  IP address     Mac Address       INTF    MOD PORT CLASS HIT
1      1    10.100.100.2   00:00:00:00:00:00 100006  0   0    0     n
2      1    10.101.101.2   00:00:00:00:00:00 100006  0   0    0     y
3      1    10.101.101.1   00:00:00:00:00:00 149151  0   0    0     y (LOCAL ROUTE)
4      1    10.100.100.1   00:00:00:00:00:00 149151  0   0    0     n (LOCAL ROUTE)
5      1    10.101.101.0   00:00:00:00:00:00 100000  0   0    0     n (LOCAL ROUTE)
6      1    10.100.100.0   00:00:00:00:00:00 100000  0   0    0     n (LOCAL ROUTE)
7      1    10.101.101.255 00:00:00:00:00:00 149150  0   0    0     n
8      1    10.100.100.255 00:00:00:00:00:00 149150  0   0    0     n

Chapter6. Python API

- [Python API について（About the Python API）]

- Python の使用

[Python API について（About the Python API）]

Python は簡単に習得できる強力なプログラミング言語です。効率的で高水準なデータ構造を持ち、オブジェクト指向プログラミングに対してシンプルで効果的なアプローチを取っています。Python は、簡潔な構文、動的な型指定、インタープリタ型という特長を持っており、ほとんどのプラットフォームのさまざまな分野でスクリプティングと高速アプリケーション開発が可能な理想的な言語です。

Python インタープリタと広範な標準規格ライブラリが Python Web サイトで送信元形式またはバイナリ形式で自由に利用できます：

http://www.python.org/

また、このサイトには、サードパーティが無償で提供している多数の Python モジュール、プログラム、ツールのディストリビューションとそれらへのリンク、さらに追加のドキュメンテーションが掲載されています。

Cisco Nexus 9000 Series デバイスは、インタラクティブ モードと非インタラクティブ（スクリプト）モードの両方で Python v2.7.5 をサポートし、ゲスト シェルで使用できます。

Python スクリプト機能は、さまざまなタスクを実行するためにデバイスのコマンドライン インターフェイス（CLI）Power On Auto Provisioning（POAP）または Embedded Event Manager（EEM）アクションへのプログラムによるアクセスを提供します。Python は Bash シェルからもアクセスできます。

Python インタプリタは Cisco NX-OS ソフトウェアで利用できます。

Cisco Nexus デバイスでの Python の使用については、https://developer.cisco.com/site/nx-os/docs/apis/python/ の URL にあるCisco Nexus 9000 Series Python SDK User Guide and API Referenceを参照してください。

Python の使用

ここでは、Python スクリプトの作成と実行の方法について説明します。

- Cisco Python パッケージ

- 注意事項と制約事項

- CLI コマンド API の使用

- CLI からの Python インタープリタの呼び出し

- 表示フォーマット

- 非インタラクティブ Python

- Embedded Event Manager でのスクリプトの実行

- Cisco NX-OS ネットワーク インターフェイスとの Python 統合

- Python による Cisco NX-OS セキュリティ

Cisco Python パッケージ

Cisco NX-OS は、インターフェイス、VLAN、VRF、ACL、ルートなど、多くのコア ネットワーク デバイス モジュールへのアクセスを可能にする Cisco Python パッケージを提供します。help() コマンドを入力すると、Cisco Python パッケージの詳細を表示できます。モジュール内のクラスとメソッドに関する追加情報を取得するには、特定のモジュールに対して help コマンドを実行します。たとえば、help（cisco.interface） は、cisco.interface モジュールのプロパティを表示します。

次の例は、Cisco Python パッケージに関する情報を表示する方法を示します。

>>> import cisco
>>> help(cisco)
Help on package cisco:

NAME
cisco

FILE
/isan/python/scripts/cisco/__init__.py

PACKAGE CONTENTS
acl
bgp
cisco_secret
cisco_socket
feature
interface
key
line_parser
md5sum
nxcli
ospf
routemap
routes
section_parser
ssh
system
tacacs
vrf

CLASSES
__builtin__.object
cisco.cisco_secret.CiscoSecret
cisco.interface.Interface
cisco.key.Key

注意事項と制約事項

Python API には、次の注意事項と制限事項があります。

- NX-OS 7.0（3）F3（1）以降、Python API は Cisco Nexus 9508 スイッチでサポートされます。

CLI コマンド API の使用

Python プログラミング言語は、CLI コマンドを実行できる 3 つの API を使用します。API は Python CLI モジュールから利用できます。

これらの API については、次の表で説明します。* from cli import コマンドを使用して API を有効にする必要があります。これらの API の引数は CLI コマンドの文字列です。Python インタープリタ経由で CLI コマンドを実行するには、次の API のいずれかの引数文字列として CLI コマンドを入力します。

CLI コマンド API

API

説明

cli()
例：

string = cli (“cli-command”)

制御文字または特殊文字を含む CLI コマンドの未処理の出力を返します。

（注）

インタラクティブな Python インタープリタは、制御文字または特殊文字を「エスケープ」して出力します。改行は 「\n」として出力され、結果が読みにくい場合があります。clip() API は、判読性が高い結果を出力します。

clid()
例：

json_string = clid (“cli-command”)

コマンドに XML サポートが存在する場合は、cli-command の JSON 出力を返します。それ以外の場合は、例外がスローされます。

（注）

この API は、show コマンドの出力の検索時に使用すると便利な場合があります。

clip()
例：

clip (“cli-command”)

CLI コマンドの出力を直接 stdout に出力し、Python には何も返されません。

（注）

clip (“cli-command”)
と同等です（is equivalent to）

r=cli(“cli-command”)
print r

2 つ以上のコマンドを個別に実行すると、その状態は 1 つのコマンドから後続のコマンドまで持続しません。

次の例では、最初のコマンドの状態が 2 番目のコマンドで持続しないため、2 番目のコマンドが失敗します。

>>> cli("conf t")
>>> cli("interface eth4/1")

2 つ以上のコマンドを同時に実行すると、その状態は 1 つのコマンドから後続のコマンドまで持続します。

次の例では、2 番目と 3 番目のコマンドの状態が持続するため、2 番目のコマンドは成功しています。

>>> cli("conf t ; interface eth4/1 ; shut")

（注）

例に示すように、コマンドは「;」で区切られます。セミコロン ( ; ) は、単一のブランク文字で囲む必要があります。

CLI からの Python インタープリタの呼び出し

次に、CLI から Python 2 を呼び出す方法を表示します：

（注）

Python インタープリタのプロンプトは「>>>」または「…」で表示されます。

switch# python
switch# python

Warning: Python 2.7 is End of Support, and future NXOS software will deprecate
python 2.7 support. It is recommended for new scripts to use 'python3' instead.
Type "python3" to use the new shell.

Python 2.7.11 (default, Jun  4 2020, 09:48:24)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> from cli import *
>>> import json
>>> cli('configure terminal ; interface loopback 1 ; no shut')
''
>>> intflist=json.loads(clid('show interface brief'))
>>> i=0
>>> while i < len(intflist['TABLE_interface']['ROW_interface']):
...     intf=intflist['TABLE_interface']['ROW_interface'][i]
...     i=i+1
...     if intf['state'] == 'up':
...         print intf['interface']
...
mgmt0
loopback1
>>>

表示フォーマット

次に、Python API を使用したさまざまな表示フォーマットを示します：

例 1：

>>> from cli import *
>>> cli("conf ; interface loopback 1")
''
>>> clip('where detail')
mode:
username:            admin
vdc:                 switch
routing-context vrf: default

例 2：

>>> from cli import *
>>> cli("conf ; interface loopback 1")
''
>>> cli('where detail')
'  mode:                \n  username:            admin\n  vdc:
switch\n  routing-context vrf: default\n'
>>>

例 3：

>>> from cli import *
>>> cli("conf ; interface loopback 1")
''
>>> r = cli('where detail') ; print r
mode:
username:            admin
vdc:                 EOR-1
routing-context vrf: default
>>>

例 4：

>>> from cli import *
>>> import json
>>> out=json.loads(clid('show version'))
>>> for k in out.keys():
...   print "%30s = %s" % (k, out[k])
...
kern_uptm_secs = 21
kick_file_name = bootflash:///nxos.9.2.1.bin.S246
rr_service = None
module_id = Supervisor Module
kick_tmstmp = 07/11/2018 00:01:44
bios_cmpl_time = 05/17/2018
bootflash_size = 20971520
kickstart_ver_str = 9.2(1)
kick_cmpl_time = 7/9/2018 9:00:00
chassis_id = Nexus9000 C9504 (4 Slot) Chassis
proc_board_id = SAL171211LX
memory = 16077872
manufacturer = Cisco Systems, Inc.
kern_uptm_mins = 26
bios_ver_str = 05.31
cpu_name = Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz
kern_uptm_hrs = 2
rr_usecs = 816550
rr_sys_ver = 9.2(1)
rr_reason = Reset Requested by CLI command reload
rr_ctime = Wed Jul 11 20:44:39 2018
header_str = Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (C) 2002-2018, Cisco and/or its affiliates.
All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under their own
licenses, such as open source. This software is provided "as is," and unless
otherwise stated, there is no warranty, express or implied, including but not
limited to warranties of merchantability and fitness for a particular purpose.
Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or
GNU General Public License (GPL) version 3.0 or the GNU
Lesser General Public License (LGPL) Version 2.1 or
Lesser General Public License (LGPL) Version 2.0.
A copy of each such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://opensource.org/licenses/gpl-3.0.html and
http://www.opensource.org/licenses/lgpl-2.1.php and
http://www.gnu.org/licenses/old-licenses/library.txt.
host_name = switch
mem_type = kB
kern_uptm_days = 0
>>>

非インタラクティブ Python

Python スクリプト名を引数として Python CLI コマンドで使用することで、Python スクリプトを非インタラクティブ モードで実行できます。Python スクリプトは、ブートフラッシュまたは揮発性スキームの下に配置する必要があります。Python CLI コマンドでは、Python スクリプトの最大 32 個のコマンド ライン引数を使用できます。

スイッチは、Python スクリプトを実行するためのソース CLI コマンドもサポートしています。bootflash:scripts ディレクトリは、ソース CLI コマンドのデフォルトのスクリプト ディレクトリです。

この例では、最初にスクリプトを表示してから実行します。保存は、任意のファイルをブートフラッシュに持ってくるようなものです。

switch# show file bootflash:deltaCounters.py
#!/isan/bin/python

from cli import *
import sys, time

ifName = sys.argv[1]
delay = float(sys.argv[2])
count = int(sys.argv[3])
cmd = 'show interface ' + ifName + ' counters'

out = json.loads(clid(cmd))
rxuc = int(out['TABLE_rx_counters']['ROW_rx_counters'][0]['eth_inucast'])
rxmc = int(out['TABLE_rx_counters']['ROW_rx_counters'][1]['eth_inmcast'])
rxbc = int(out['TABLE_rx_counters']['ROW_rx_counters'][1]['eth_inbcast'])
txuc = int(out['TABLE_tx_counters']['ROW_tx_counters'][0]['eth_outucast'])
txmc = int(out['TABLE_tx_counters']['ROW_tx_counters'][1]['eth_outmcast'])
txbc = int(out['TABLE_tx_counters']['ROW_tx_counters'][1]['eth_outbcast'])
print 'row rx_ucast rx_mcast rx_bcast tx_ucast tx_mcast tx_bcast'
print '========================================================='
print '    %8d %8d %8d %8d %8d %8d' % (rxuc, rxmc, rxbc, txuc, txmc, txbc)
print '========================================================='

i = 0
while (i < count):
time.sleep(delay)
out = json.loads(clid(cmd))
rxucNew = int(out['TABLE_rx_counters']['ROW_rx_counters'][0]['eth_inucast'])
rxmcNew = int(out['TABLE_rx_counters']['ROW_rx_counters'][1]['eth_inmcast'])
rxbcNew = int(out['TABLE_rx_counters']['ROW_rx_counters'][1]['eth_inbcast'])
txucNew = int(out['TABLE_tx_counters']['ROW_tx_counters'][0]['eth_outucast'])
txmcNew = int(out['TABLE_tx_counters']['ROW_tx_counters'][1]['eth_outmcast'])
txbcNew = int(out['TABLE_tx_counters']['ROW_tx_counters'][1]['eth_outbcast'])
i += 1
print '%-3d %8d %8d %8d %8d %8d %8d' % \
(i, rxucNew - rxuc, rxmcNew - rxmc, rxbcNew - rxbc, txucNew - txuc, txmcNew - txmc, txbcNew - txbc)

switch# python bootflash:deltaCounters.py Ethernet1/1 1 5
row rx_ucast rx_mcast rx_bcast tx_ucast tx_mcast tx_bcast
=========================================================
0      791        1        0   212739        0
=========================================================
1          0        0        0        0       26        0
2          0        0        0        0       27        0
3          0        1        0        0       54        0
4          0        1        0        0       55        0
5          0        1        0        0       81        0
switch#

次の例は、送信元コマンドでコマンドライン引数を指定する方法を表示しています。この例では、policy-map は cgrep python スクリプトへの引数です。この例は、送信元コマンドがパイプ演算子 (「|」) の後に続くことも示しています。

switch# show running-config | source sys/cgrep policy-map

policy-map type network-qos nw-pfc
policy-map type network-qos no-drop-2
policy-map type network-qos wred-policy
policy-map type network-qos pause-policy
policy-map type qos foo
policy-map type qos classify
policy-map type qos cos-based
policy-map type qos no-drop-2
policy-map type qos pfc-tor-port

Embedded Event Manager でのスクリプトの実行

Embedded Event Manager（EEM）のポリシーは、Python スクリプトをサポートします。

次の例は、EEM アクションとして Python スクリプトを実行する方法を示しています。

- アクション コマンドを使用することで、EEM アプレットに Python スクリプトを含めることができます。

switch# show running-config eem

!Command: show running-config eem
!Running configuration last done at: Thu Jun 25 15:29:38 2020
!Time: Thu Jun 25 15:33:19 2020

version 9.3(5) Bios:version 07.67
event manager applet a1
event cli match "show clock"
action 1 cli python bootflash:pydate.py

switch# show file logflash:vdc_1/event_archive_1 | last 33

eem_event_time:06/25/2020,15:34:24 event_type:cli event_id:24 slot:active(1) vdc
:1 severity:minor applets:a1
eem_param_info:command = "exshow clock"
Starting with policy a1
stty: standard input: Inappropriate ioctl for device
Executing the following commands succeeded:
python bootflash:pydate.py
Completed executing policy a1
Event Id:24 event type:10241 handling completed

- show file logflash:event_archive_1 コマンドを実行して、ログ ファイル内のイベントによってトリガーされたアクションを検索できます。

switch# show file logflash:event_archive_1 | last 33

eem_event_time:05/01/2011,19:40:28 event_type:cli event_id:8 slot:active(1)
vdc:1 severity:minor applets:a1
eem_param_info:command = "exshow clock"
Starting with policy a1
Python

2011-05-01 19:40:28.644891
Executing the following commands succeeded:
python bootflash:pydate.py

PC_VSH_CMD_TLV(7679) with q

Cisco NX-OS ネットワーク インターフェイスとの Python 統合

Cisco Nexus スイッチでは、Python が基盤となる Cisco NX-OS ネットワーク インターフェイスと統合されています。cisco.vrf.set_global_vrf（）API を介してコンテキストを設定することにより、ある仮想ルーティング コンテキストから別の仮想ルーティング コンテキストに切り替えることができます。

次の例は、デバイスの管理インターフェイスを介して HTML ドキュメントを取得する方法を示しています。目的の仮想ルーティング コンテキストに切り替えることにより、帯域内インターフェイスを介して外部エンティティへの接続を確立することもできます。

switch# python
Python 2.7.5 (default, Oct  8 2013, 23:59:43)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> from cisco.vrf import *
>>> set_global_vrf('management')
>>> page=urllib2.urlopen('http://172.23.40.211:8000/welcome.html')
>>> print page.read()
Hello Cisco Nexus 9000

>>>
>>> import cisco
>>> help(cisco.vrf.set_global_vrf)
Help on function set global vrf in module cisco.vrf:

set global vrf(vrf)
Sets the global vrf. Any new sockets that are created (using socket.socket)
will automatically get set to this vrf (including sockets used by other
python libraries).

Arguments:
vrf: VRF name (string) or the VRF ID (int).

Returns: Nothing

>>>

Python による Cisco NX-OS セキュリティ

Cisco NX-OS 情報技術は、ソフトウェアの Cisco NX-OS サンドボックス レイヤおよび CLI ロールベース アクセス コントロール（RBAC）によって保護されます。

Cisco NX-OS network-admin または dev-ops ロールに関連付けられているすべてのユーザは、特権ユーザです。カスタム ロールで Python へのアクセスが許可されているユーザーは、非特権ユーザーと見なされます。非特権ユーザは、ファイル システム、ゲスト シェル、Bash コマンドなどの Cisco NX-OS 情報技術へのアクセスが制限されています。特権ユーザは、Cisco NX-OS のすべての情報技術へのアクセスが向上します。

- セキュリティとユーザー権限の例

- スケジューラでスクリプトを実行する例

セキュリティとユーザー権限の例

次の例は、特権ユーザーがコマンドを実行する方法を示しています：

switch# python
Python 2.7.5 (default, Oct  8 2013, 23:59:43)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system('whoami')
admin
0
>>> f=open('/tmp/test','w')
>>> f.write('hello from python')
>>> f.close()
>>> r=open('/tmp/test','r')
>>> print r.read()
hello from python
>>> r.close()

Python 3 の例。

次の例は、アクセスを拒否されている非特権ユーザーを示しています：

switch# python
Python 2.7.5 (default, Oct  8 2013, 23:59:43)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system('whoami')
system(whoami): rejected!
-1
>>> f=open('/tmp/test','r')
Permission denied. Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied: '/tmp/test'
>>>

RBAC は、ログイン ユーザー権限に基づいて CLI アクセスを制御します。ログイン ユーザーの ID は、CLI シェルまたは Bash から呼び出される Python に与えられます。Python は、Python から呼び出されたサブプロセスにログイン ユーザーの ID を渡します。

以下は、特権ユーザーの例です：

>>> from cli import *
>>> cli('show clock')
'Warning: No NTP peer/server configured. Time may be out of sync.\n15:39:39.513 UTC Thu Jun 25 2020\nTime source is NTP\n'
>>> cli('configure terminal ; vrf context myvrf')
''
>>> clip('show running-config l3vm')

!Command: show running-config l3vm
!Running configuration last done at: Thu Jun 25 15:39:49 2020
!Time: Thu Jun 25 15:39:55 2020

version 9.3(5) Bios:version 07.67

interface mgmt0
vrf member management
vrf context blue
vrf context management
vrf context myvrf

以下は、非特権ユーザーの例です：

>>> from cli import *
>>> cli('show clock')
'11:18:47.482 AM UTC Sun May 08 2011\n'
>>> cli('configure terminal ; vrf context myvrf2')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/isan/python/scripts/cli.py", line 20, in cli
raise cmd_exec_error(msg)
errors.cmd_exec_error: '% Permission denied for the role\n\nCmd exec error.\n'

次の例は、RBAC 構成を示しています：

switch# show user-account
user:admin
this user account has no expiry date
roles:network-admin
user:pyuser
this user account has no expiry date
roles:network-operator python-role
switch# show role name python-role

スケジューラでスクリプトを実行する例

次の例は、スケジューラ機能を使用してスクリプトを実行する Python スクリプトを示しています。

#!/bin/env python
from cli import *
from nxos import *
import os

switchname = cli("show switchname")
try:
user = os.environ['USER']
except:
user = "No user"
pass

msg = user + " ran " + __file__ + " on : " + switchname
print msg
py_syslog(1, msg)
# Save this script in bootflash:///scripts

Python 3 の例。

Chapter7. tcl によるスクリプティング

- Tcl について

- Tclsh コマンドの実行

- Tclsh コマンドからの Cisco NX-OS モード間の移動

- tcl の参照

Tcl について

Tcl (「ティックル」と発音) は、CLI コマンドの柔軟性を高めるスクリプト言語です。Tcl を使用して show コマンドの出力の特定の値を抽出したり、スイッチを設定したり、Cisco NX-OS コマンドをループで実行したり、スクリプトで Embedded Event Manager（EEM）ポリシーを定義したりすることができます。

このセクションでは、Tcl スクリプトを実行する方法、またはスイッチで Tcl を対話的に実行する方法について説明します。

- tclsh コマンドのヘルプ

- tclsh コマンドの履歴

- tclsh のタブ補完

- tclsh の CLI コマンド

- tclsh コマンドの区切り

- tcl 変数

- tclquit

- Tclsh セキュリティ

tclsh コマンドのヘルプ

Tcl コマンドでは、コマンドのヘルプは使用できません。インタラクティブ tcl シェル内から Cisco NX-OS コマンドのヘルプ機能に引き続きアクセスできます。

次に、インタラクティブ Tcl シェルで Tcl コマンドのヘルプがない場合の例を示します。

switch# tclsh
switch-tcl# set x 1
switch-tcl# puts ?
^
% Invalid command at '^' marker.
switch-tcl# configure ?
<CR>
session   Configure the system in a session
terminal  Configure the system from terminal input

switch-tcl#

（注）

上の例では、Cisco NX-OS コマンドのヘルプ機能が引き続き使用できますが、Tcl の puts コマンドはヘルプ機能からのエラーを返します。

tclsh コマンドの履歴

端末で矢印キーを使用して、以前にインタラクティブ Tcl シェルで入力したコマンドにアクセスできます。

（注）

インタラクティブ Tcl シェルを終了すると、 tclsh コマンドの履歴は保存されません。

tclsh のタブ補完

インタラクティブ Tcl シェルを実行している場合は、Cisco NX-OS コマンドのタブ補完を使用できます。Tcl コマンドでは、タブ補完は使用できません。

tclsh の CLI コマンド

インタラクティブ tcl シェル内から直接 Cisco NX-OS コマンドにアクセスできますが、 Tcl cli コマンドにより付加される場合のみ tcl スクリプト内で Cisco NX-OS コマンドを実行できます。

インタラクティブ Tcl シェルでは、次のコマンドは同じであり、正しく実行されます：

switch-tcl# cli show module 1 | incl Mod
switch-tcl# cli "show module 1 | incl Mod"
switch-tcl# show module 1 | incl Mod

Tcl スクリプトで、次の例のように、Cisco NX-OS コマンドに Tcl cli コマンドを付加する必要があります：

set x 1
cli show module $x | incl Mod
cli "show module $x | incl Mod"

スクリプトで次のコマンドを使用すると、そのスクリプトは機能不全になり、Tcl シェルにエラーが表示されます：

show module $x | incl Mod
"show module $x | incl Mod"

tclsh コマンドの区切り

セミコロン（; ）は、Cisco NX-OS と Tcl の両方でのコマンド区切りです。Tcl コマンドで複数の Cisco NX-OS コマンドを実行するには、各 Cisco NX-OS コマンドを引用符（"" ）で囲む必要があります。

双方向性 Tcl シェルでは、次のコマンドは同じであり、正しく実行されます。

switch-tcl# cli "configure terminal ; interface loopback 10 ; description loop10"
switch-tcl# cli configure terminal ; cli interface loopback 10 ; cli description loop10
switch-tcl# cli configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.

switch(config-tcl)# cli interface loopback 10
switch(config-if-tcl)# cli description loop10
switch(config-if-tcl)#

双方向性 Tcl シェルでは、Tcl cli コマンドを付加せずに、直接 Cisco NX-OS コマンドを実行することもできます。

switch-tcl# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.

switch(config-tcl)# interface loopback 10
switch(config-if-tcl)# description loop10
switch(config-if-tcl)#

tcl 変数

Tcl 変数を Cisco NX-OS コマンドへの引数として使用できます。また、Tcl スクリプトに引数を渡すこともできます。tcl 変数は永続的ではありません。

次の例は、Cisco NX-OS コマンドの引数として Tcl 変数を使用する方法を表示しています。

switch# tclsh
switch-tcl# set x loop10
switch-tcl# cli "configure terminal ; interface loopback 10 ; description $x"
switch(config-if-tcl)#

tclquit

tclquit コマンドは、どの Cisco NX-OS コマンド モードが現在現用系であるかには関係なく Tcl シェルを終了します。また、Ctrl+C を押して Tcl シェルを終了することもできます。exit と end Cisco NX-OS コマンドは、コマンド モードを変更します。exit コマンドは、EXEC コマンド モードからのみ Tcl シェルを終了します。

Tclsh セキュリティ

tcl シェルは、Cisco NX-OS システムの特定の部分への不正アクセスを防止するために、サンドボックスで実行されます。システムは、無限ループや過剰なメモリ使用率などのイベントを検出するために、tcl シェルによって使用されている CPU、メモリ、ファイルなどのシステム リソースをモニタリングします。

初期の tcl 環境は、scripting tcl init init-file コマンドで設定します。

scripting tcl recursion-limit iterations コマンドを使用して、tcl 環境のループ制限を定義できます。デフォルトの再帰制限は 1000 回の繰り返しです。

Tclsh コマンドの実行

tclsh コマンドを使用すると、スクリプトまたはコマンド ラインから tcl コマンドを実行できます。

（注）

CLI プロンプトの状態で tcl スクリプト ファイルを作成することはできません。スクリプト ファイルをリモート デバイスで作成して、Cisco NX-OS デバイスの bootflash: ディレクトリにコピーすることができます。

手順

tclsh [ bootflash:filename [ argument ... ]]

例:

switch# tclsh ?
<CR>
bootflash:  The file to run

tcl シェルを開始します。

引数を指定せずに tclsh コマンドを実行すると、シェルは対話形式で実行され、標準入力から tcl コマンドを読み込んで、コマンドの結果とエラー メッセージを標準出力に出力します。tclquit を入力するか、Ctrl-C を押すとインタラクティブ tcl シェルが終了します。

引数を指定して tclsh コマンドを実行すると、最初の引数は、tcl コマンドが記述されたスクリプト ファイルの名前になり、他の引数をスクリプトで変数として使用できます。

例

次の例は、インタラクティブな Tcl シェルを示しています。

switch# tclsh
switch-tcl# set x 1
switch-tcl# cli show module $x | incl Mod
Mod  Ports  Module-Type                         Model              Status
1    36     36p 40G Ethernet Module             N9k-X9636PQ        ok
Mod  Sw              Hw
Mod  MAC-Address(es)                         Serial-Num

switch-tcl# exit
switch#

次に、Tcl スクリプトを実行する方法の例を示します。

switch# show file bootflash:showmodule.tcl
set x 1
while {$x < 19} {
cli show module $x | incl Mod
set x [expr {$x + 1}]
}

switch# tclsh bootflash:showmodule.tcl
Mod  Ports  Module-Type                         Model              Status
1    36     36p 40G Ethernet Module             N9k-X9636PQ        ok
Mod  Sw              Hw
Mod  MAC-Address(es)                         Serial-Num

switch#

Tclsh コマンドからの Cisco NX-OS モード間の移動

インタラクティブ Tcl シェルの実行中に Cisco NX-OS のモードを変更できます。

手順

ステップ 1

tclsh

例:

switch# tclsh
switch-tcl#

インタラクティブ Tcl シェルを開始します。

ステップ 2

configure terminal

例:

switch-tcl# configure terminal
switch(config-tcl)#

Tcl シェルで Cisco NX-OS のコマンドを実行して、モードを変更します。

（注）

Tcl プロンプトが変化して、Cisco NX-OS コマンド モードになったことが示されます。

ステップ 3

tclquit

例:

switch-tcl# tclquit
switch#

Tcl シェルを終了し、始めのモードに戻ります。

例

次の例は、対話型 Tcl シェルから Cisco NX-OS モードを変更する方法を示しています：

switch# tclsh
switch-tcl# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config-tcl)# interface loopback 10
switch(config-if-tcl)# ?
description  Enter description of maximum 80 characters
inherit      Inherit a port-profile
ip           Configure IP features
ipv6         Configure IPv6 features
logging      Configure logging for interface
no           Negate a command or set its defaults
rate-limit   Set packet per second rate limit
shutdown     Enable/disable an interface
this         Shows info about current object (mode's instance)
vrf          Configure VRF parameters
end          Go to exec mode
exit         Exit from command interpreter
pop          Pop mode from stack or restore from name
push         Push current mode to stack or save it under name
where        Shows the cli context you are in

switch(config-if-tcl)# description loop10
switch(config-if-tcl)# tclquit
Exiting Tcl
switch#

tcl の参照

次のタイトルは、参照のために示されています。

- Mark Harrison (ed)、『Tcl/Tk Tools』、O'Reilly Media、ISBN 1-56592-218-2、1997 年

- Mark Harrison および Michael McLennan、『Effective Tcl/Tk Programming』、Addison-Wesley、Reading、MA、USA、ISBN 0-201-63474-0、1998 年

- Brent B. Ousterhout、『Tcl and the Tk Toolkit』、Addison-Wesley、Reading、MA、USA、ISBN 0-201-63337-X、1994 年

- Brent B. Welch、『Practical Programming in Tcl and Tk』、Prentice Hall、Upper Saddle River、NJ、USA、ISBN 0-13-038560-3、2003 年

- J Adrian Zimmer、『Tcl/Tk for Programmers』、IEEE Computer Society、John Wiley and Sons により出版、ISBN 0-8186-8515-8、1998 年

Chapter8. iPXE

この章は、次の内容で構成されています。

- iPXE について

- ネットブート要件

- 注意事項と制約事項

- ブート モードの構成

- ブート順の構成の確認

iPXE について

iPXE は、オープンソースのネットワークブート ファームウェアです。 iPXE は、Etherboot から派生したオープンソースの PXE クライアントファームウェアおよびブートローダーである gPXE に基づいています。標準の PXE クライアントは TFTP を使用してデータを転送しますが、gPXE はより多くのプロトコルをサポートします。

標準 PXE の機能以外に iPXE が提供している追加機能のリストを次に示します。

- HTTP、iSCSI SAN、FCoE などを介した Web サーバーからのブート

- IPv4 と IPv6 の両方をサポート

- Netboot は HTTP/TFTP、IPv4、および IPv6 をサポート

- イメージへの埋め込みスクリプトや、HTTP/TFTP によって提供されるスクリプトなどをサポート

- DHCPv6 のステートレス アドレス自動設定（SLAAC）と、ステートフル IP 自動構成バリアントをサポート。 iPXE は、ブート URI と DHCPv6 オプションのパラメータをサポート。これは、IPv6 ルータ アドバタイズメントに依存します。

さらに、セキュリティ上の理由から、次のような iPXE の既存の機能の一部を無効にしています。

- bzImage+initramfs/initrd、または ISO などの標準 Linux イメージ形式のブートのサポート

- FCoE、iSCSI SAN、ワイヤレスなどの未使用のネットワーク ブート オプション

- サポートされていない NBP（syslinux/pxelinux など）のロード。これは適切にコード署名されていないシステム イメージを起動できるためです。

ネットブート要件

主要な要件は次のとおりです。

- 適切に構成された DHCP サーバー。

- TFTP/HTTP サーバー。

- デバイスが PXE ブートされるときに NX-OS がイメージをダウンロードするため、デバイスのブートフラッシュに十分なスペースがあること。

- IPv4/IPv6 サポート：導入の柔軟性を向上

注意事項と制約事項

PXE に関する注意事項と制限事項は次のとおりです。

- NX-OS 7.0（3）F3（1）以降、iPXE は Cisco Nexus 9508 スイッチでサポートされます。

- iPXE による自動ブート中は、Ctrl+B を入力して PXE ブートを終了できる 3 秒間のウィンドウがあります。次のオプションのプロンプトが表示されます。

Please choose a bootloader shell:
1). GRUB shell
2). PXE shell
Enter your choice:

- HTTP イメージのダウンロードと TFTP：TFTP は UDP ベースであるため、パケット損失が発生し始めた場合に問題が発生する可能性があります。TCP はウィンドウベースのプロトコルであり、帯域幅の共有/損失をより適切に処理します。その結果、Cisco Nexus イメージのサイズが 250 M バイトを超える場合、TCP ベースのプロトコルのサポートの方が適しています。

- iPXE は、Cisco の署名付き NBI イメージのみを許可/ブートします。その他の標準イメージ フォーマットのサポートは、セキュリティ上の理由から無効になっています。

ブート モードの構成

VSH CLI

switch# configure terminal
switch(conf)# boot order bootflash|pxe [bootflash|pxe]
switch(conf)# end

（注）

キーワード bootflash は、Grub ベースのブートであることを示します。

たとえば、PXE ブート モードのみを実行する場合、構成コマンドは次のようになります。

switch(conf)# boot order pxe

最初に Grub を起動し、次に PXE を起動する場合、次のようになります。

switch(conf)# boot order bootflash pxe

最初に PXE を起動し、次に Grub を起動する場合、次のようになります。

switch(conf)# boot order pxe bootflash

boot order コマンドを使用しない場合、デフォルトのブート順序は Grub です。

（注）

次のセクションでは、Grub と iPXE を切り替える方法について説明します。

Grub CLI

bootmode [-g|-p|-p2g|-g2p]

キーワード

機能

-g

Grub のみ

-p

PXE のみ

-p2g

最初に PXE、PXE が失敗した場合には Grub

-g2p

最初に Grub、Grub が失敗した場合には PXE

Grub CLI は、フルバージョンの Cisco NX-OS イメージを起動せず、シリアル コンソールからブート モードを切り替える場合に役立ちます。また、すぐに継続的な PXE ブート状態に移行する場合にも使用できます。

iPXE CLI

bootmode [-g|--grub] [-p|--pxe] [-a|--pxe2grub] [-b|--grub2pxe]

キーワード

機能

– – grub

Grub のみ

– – pxe

PXE のみ

– – pxe2grub

最初に PXE、PXE が失敗した場合には Grub

– – grub2pxe

最初に Grub、Grub が失敗した場合には PXE

iPXE CLI は、フルバージョンの Cisco NX-OS イメージを起動せず、シリアル コンソールからブート モードを切り替える場合に役立ちます。また、すぐに継続的な PXE ブート状態に移行する場合にも使用できます。

ブート順の構成の確認

ブート順の構成情報を表示するには、次のコマンドを入力します。

コマンド

目的

show boot order

実行構成からの現在のブート順と、スタートアップ構成から取得した、次のリロード時のブート順の値を表示します。

Chapter9. カーネル スタック

この章は、次の内容で構成されています。

- カーネル スタックについて

- Guidelines and Limitations

- ポート範囲の変更

カーネル スタックについて

カーネル スタック（kstack）は、既知の Linux API を使用してルートとフロント パネル ポートを管理します。

オープン コンテナは、ゲスト シェルと同様に、ホスト ソフトウェアから分離された Linux 環境です。ホスト ソフトウェア パッケージに影響を与えることなく、その環境内でソフトウェアをインストールまたは変更できます。

Guidelines and Limitations

Using the Kernel Stack has the following guidelines and limitations:

- Starting with NX-OS 7.0(3)F3(1), the Kernel Stack is supported on the Cisco Nexus 9508 switch.

- Guest Shell, other open containers, and the host Bash Shell use Kernel Stack (kstack).

- Open containers start in the host default namespace

- Other network namespaces might be accessed by using the setns system call

- The nsenter and ip netns exec utilities can be used to execute within the context of a different network namespace.

- The PIDs and identify options for the ip netns command do not work without modification because of the file system device check. A vrfinfo utility is provided to give the network administrator the same information.

- Open containers may read the interface state from /proc/net/dev or use other normal Linux utilities such as netstat or ifconfig without modification. This provides counters for packets that have initiated / terminated on the switch.

- Open containers may use ethtool –S to get extended statistics from the net devices. This includes packets switched through the interface.

- Open containers may run packet capture applications like tcpdump to capture packets initiated from or terminated on the switch.

- There is no support for networking state changes (interface creation/deletion, IP address configuration, MTU change, etc.) from the Open containers

- IPv4 and IPv6 are supported

- Raw PF_PACKET is supported

- Well-known ports (0-15000) may only be used by one stack (Netstack or kstack) at a time, regardless of the network namespace.

- There is no IP connectivity between Netstack and kstack applications. This is a host limitation which also applies to open containers.

- Open containers are not allowed to send packets directly over an Ethernet out-of-band channel (EOBC) interface to communicate with the linecards or standby Sup.

- From within an open container, direct access to the EOBC interface used for internal communication with linecards or the standby supervisor. The host bash shell should be used if this access is needed.

- The management interface (mgmt0) is represented as eth1 in the kernel netdevices.

- Use of the VXLAN overlay interface (NVE x) is not supported for applications utilizing the kernel stack. NX-OS features, including CLI commands, are able to use this interface via netstack.

For more information about the NVE interface, see the Cisco Nexus 9000 Series NX-OS VXLAN Configuration Guide.

ポート範囲の変更

Netstack と kstack は、それらの間のポート範囲を分割します。デフォルトのポート範囲は次のとおりです：

- Kstack：15001 ～ 58000

- Netstack：58001 ～ 65535

（注）

この範囲内で、63536 ～ 65535 は NAT 用に予約されています。

（注）

nxapi use-vrf management で構成されたポートは kstack を使用し、アクセス可能です。

手順

[no] sockets local-port-range start-port end-port

このコマンドは、kstack のポート範囲を変更します。このコマンドは、Netstack の範囲を変更しません。

例

次に、kstack ポート範囲を設定する例を示します：

switch# sockets local-port-range 15001 25000

次のタスク

コマンドを入力した後は、次の点に注意してください：

- コマンドを入力した後には、スイッチをリロードします。

- Netstack で使用される 7000 以上のポートを、未割り当てのままにします。

- ポート範囲に抜けが生じるのを回避するには、start-port を 15001 に指定するか、end-port を 65535 に指定します。

PartII. アプリケーション

- サードパーティ製アプリケーション

- Ansible

- Puppet Agent

- Cisco NX-OS と一緒にシェフ クライアントを使用

- Nexus アプリケーション開発：ISO

- Nexus アプリケーション開発 SDK

- NX-SDK

Chapter10. サードパーティ製アプリケーション

この章は、次の内容で構成されています。

- サードパーティ製アプリケーションについて

- 注意事項と制約事項

- サードパーティのネイティブ RPM/パッケージのインストール

- 永続的なサードパーティ RPM

サードパーティ製アプリケーションについて

サードパーティ製アプリケーションの RPM は、https://devhub.cisco.com/artifactory/open-nxos/7.0-3-I2-1/x86_64/ のリポジトリで入手できます。これらのアプリケーションは、Bash シェルで yum コマンドを使用するか、NX-OS CLI を介してネイティブホストにインストールされます。

yum install rpm コマンドを入力すると、Cisco YUM プラグインが実行されます。このプラグインは、RPM を表示されない場所にコピーします。スイッチのリロード時に、システムは RPM を再インストールします。

構成が /etc に置かれている場合、Linux プロセス、incrond は、ディレクトリで作成されたアーティファクトをモニターし、それらを表示されない場所にコピーし、この場所から /etc にコピーし直します。

注意事項と制約事項

サードパーティ製アプリケーションの RPM には、次の注意事項と制約事項があります。

- NX-OS 7.0（3）F3（1）以降、サードパーティ アプリケーションの RPM は Cisco Nexus 9508 スイッチでサポートされます。

サードパーティのネイティブ RPM/パッケージのインストール

パッケージのインストールの詳しいワークフローは次のとおりです。

手順

エージェントが保存されているシスコのリポジトリを指すように、スイッチのリポジトリを構成します。

bash-4.2# cat /etc/yum/repos.d/open-nxos.repo
[open-nxos]
name=open-nxos
baseurl=https://devhub.cisco.com/artifactory/open-nxos/7.0-3-I2-1/x86_64/

enabled=1
gpgcheck=0
sslverify=0

yum を使用した RPM のインストールの例と、詳しいインストール ログです。

例:

bash-4.2# yum install splunkforwarder
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching, protect-packages
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package splunkforwarder.x86_64 0:6.2.3-264376 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================
Package              Arch                 Version           Repository             Size
=============================================================================================
Installing:
splunkforwarder       x86_64               6.2.3-264376      open-nxos              13 M

Transaction Summary
=============================================================================================
Install       1 Package

Total size: 13 M
Installed size: 34 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : splunkforwarder-6.2.3-264376.x86_64                                                                                                                      1/1
complete

Installed:
splunkforwarder.x86_64 0:6.2.3-264376

Complete!
bash-4.2#

パッケージが正常にインストールされたかどうかをスイッチに問い合わせ、そのプロセスまたはサービスが稼働していることを確認する例です。

例:

bash-4.2# yum info splunkforwarder
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching, protect-packages
Fretta              |  951 B     00:00 ...
groups-repo         | 1.1 kB     00:00 ...
localdb             |  951 B     00:00 ...
patching            |  951 B     00:00 ...
thirdparty          |  951 B     00:00 ...
Installed Packages
Name        : splunkforwarder
Arch        : x86_64
Version     : 6.2.3
Release     : 264376
Size        : 34 M
Repo        : installed
From repo   : open-nxos
Summary     : SplunkForwarder
License     : Commercial
Description : The platform for machine data.

永続的なサードパーティ RPM

次に、永続的なサードパーティ RPM の背後にあるロジックを示します。

- ローカル yum リポジトリは、永続的なサードパーティ RPM 専用です。/etc/yum/repos.d/ thirdparty.repo は /bootflash/.rpmstore/ thirdparty を指しています。

- yum install third-party.rpm コマンドを入力するたびに、RPM のコピーが //bootflash/.rpmstore/ thirdparty に保存されます。

- リブート中に、サードパーティ リポジトリ内のすべての RPM がスイッチに再インストールされます。

- /etc 構成ファイルの変更は、/bootflash/.rpmstore/config/etc の下に保持され、/etc での起動時に再生されます。

- /etc ディレクトリに作成されたスクリプトは、リロード後も保持されます。たとえば、/etc/init.d/ の下に作成されたサードパーティのサービス スクリプトは、リロード中にアプリケーションを起動します。

（注）

iptables のルールは、bash シェルで変更された場合、再起動後に保持されません。

変更した iptables を永続化するには、リロード間で Iptable を永続化するを参照してください。

パッケージの追加

NX-OS 機能 RPM は、VSH CLI を使用してインストールすることもできます。

手順

ステップ 1

show install package

すでに存在するパッケージとバージョンを表示します。

ステップ 2

install add ?

サポートされている URI を確認します。

ステップ 3

install add rpm-packagename

The install add コマンドは、ローカル ストレージ デバイスまたは、ネットワーク サーバーへパッケージ ファイルをコピーします。

例

次に、Chef RPM をアクティブにする例を示します：

switch# show install package
switch# install add ?
WORD        Package name
bootflash:  Enter package uri
ftp:        Enter package uri
http:       Enter package uri
modflash:   Enter package uri
scp:        Enter package uri
sftp:       Enter package uri
tftp:       Enter package uri
usb1:       Enter package uri
usb2:       Enter package uri
volatile:   Enter package uri
switch# install add bootflash:chef-12.0.0alpha.2+20150319234423.git.1608.b6eb10f-1.el5.x86_64.rpm
[####################] 100%
Install operation 314 completed successfully at Thu Aug  6 12:58:22 2015

次のタスク

パッケージをアクティブ化する準備ができたら、パッケージのアクティブ化 に移動します。

（注）

RPM パッケージの追加とアクティブ化は、次の 1 つのコマンドで実行できます。

switch#
install add bootflash:chef-12.0.0alpha.2+20150319234423.git.1608.b6eb10f-1.el5.x86_64.rpm activate

パッケージのアクティブ化

始める前に

RPM は事前に追加しておく必要があります。

手順

ステップ 1

show install inactive

追加されていても、アクティブ化されていないパッケージのリストを表示します。

ステップ 2

install activate rpm-packagename

パッケージをアクティブ化します。

例

次に、パッケージをアクティブ化する例を示します。

switch# show install inactive
Boot image:
NXOS Image: bootflash:///yumcli6.bin

Inactive Packages:
sysinfo-1.0.0-7.0.3.x86_64
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
Available Packages
chef.x86_64       12.0.0alpha.2+20150319234423.git.1608.b6eb10f-1.el5 thirdparty
eigrp.lib32_n9000 1.0.0-r0                                            groups-rep
o
sysinfo.x86_64    1.0.0-7.0.3                                         patching
switch# install activate chef-12.0-1.el5.x86_64.rpm
[####################] 100%
Install operation completed successfully at Thu Aug  6 12:46:53 2015

パッケージの非アクティブ化

手順

install deactivate package-name

RPM パッケージを非アクティブ化します。

例

次に、Chef RPM パッケージを非アクティブ化する例を示します：

switch# install deactivate chef

パッケージの削除

始める前に

パッケージを削除する前に非アクティブ化します。非アクティブ化された RPM パッケージのみ削除できます。

手順

install remove package-name

RPM パッケージを削除します。

例

次に、Chef RPM パッケージを削除する例を示します。

switch# install remove chef-12.0-1.el5.x86_64.rpm

インストール済みパッケージの表示

手順

show install packages

インストールされているパッケージのリストを表示します。

例

次に、インストールされているパッケージのリストを表示する例を示します。

switch# show install packages

詳細ログの表示

手順

show tech-support install

詳細ログを表示します。

例

次の例は、詳細ログを表示する方法を示しています。

switch# show tech-support install

パッケージのアップグレード

手順

install add package-name activate upgrade

パッケージをアップグレードします。

例

次の例は、パッケージをアップグレードする方法を示しています。

switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate ?
downgrade  Downgrade package
forced     Non-interactive
upgrade    Upgrade package
switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate upgrade
[####################] 100%
Install operation completed successfully at Thu Aug  6 12:46:53 2015

パッケージのダウングレード

手順

install add package-name activate downgrade

パッケージをダウングレードします。

例

次の例は、パッケージをダウングレードする方法を示しています。

switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate ?
downgrade  Downgrade package
forced     Non-interactive
upgrade    Upgrade package
switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate downgrade
[####################] 100%
Install operation completed successfully at Thu Aug  6 12:46:53 2015

NX-OS

NX-API REST API オブジェクト モデルの仕様の詳細については、https://developer.cisco.com/media/dme/index.html を参照してください。

DevOps 構成管理ツール

DevOps 構成管理ツールについては、次のリンクを参照してください。

- Ansible 2.0 リリース（Nexus サポート）、Ansible リリース インデックス

- Ansible NX-OS サンプル モジュール、Ansible NX-OS サンプル モジュール

- Puppet、Puppet Forge Cisco Puppet

- Cisco Puppet モジュール（Git）Cisco Network Puppet モジュール

- Chef、Chef Supermarket Cisco クックブック

- Cisco Chef クックブック（Git）Cisco Network Chef クックブック

V9K

[/reference/titlealts/navtitle {"- topic/navtitle "}) 自動化アプリケーション統合のテストとモデリング (navtitle]

ESX5.1/5.5、VirtualBox、Fusion、および KVM の場合、仮想 Nexus 9000 スイッチをダウンロードするには、https://software.cisco.com/portal/pub/download/portal/select.html?&mdfid=286312239&flowid=81422&softwareid=282088129に移動します。

Automation Tool Educational Content

For a free book on Open NX-OS architecture and automation, see http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/nexus9000/sw/open_nxos/programmability/guide/Programmability_Open_NX-OS.pdf

collectd

collectd は、システム パフォーマンスの統計情報を定期的に収集し、RRD ファイルなどの値を保存する複数の手段を提供するデーモンです。これらの統計情報を使用して、現在のパフォーマンスのボトルネックを見つけたり（パフォーマンス分析など）、将来のシステム負荷を予測したりできます（つまり、キャパシティ プランニング）。

詳細については、https://collectd.org を参照してください。

Ganglia

Ganglia は、クラスタやグリッドなどのハイパフォーマンス コンピューティング システム向けのスケーラブルな分散モニタリング システムです。これは、クラスタのフェデレーションを対象とした階層設計に基づいています。データ表現のための XML、コンパクトでポータブルなデータ転送のための XDR、データストレージと可視化のための RRDtool など、広く使用されているテクノロジーを活用しています。設計されたデータ構造とアルゴリズムを使用して、ノードあたりのオーバーヘッドを低く抑え、同時実行性を高めます。この実装は堅牢で、広範なオペレーティングシステムとプロセッサアーキテクチャに移植されており、現在、世界中の何千ものクラスタで使用されています。世界中の大学キャンパス間でクラスタをリンクするために使用されており、2000 ノードのクラスタを処理するように拡張できます。

詳細については、http://ganglia.info を参照してください。

Iperf

Iperf は、TCP および UDP の最大帯域幅パフォーマンスを測定するために NLANR/DAST によって開発されました。Iperf を使用すると、さまざまなパラメータと UDP 特性を調整できます。Iperf は、帯域幅、遅延ジッターとデータグラム損失を報告します。

詳細については、http://sourceforge.net/projects/iperf/またはhttp://iperf.sourceforge.netを参照してください。

LLDP

リンク層検出プロトコル（LLDP）は、EDP や CDP などの独自のリンク層プロトコルに代わるように設計された業界標準プロトコルです。LLDP の目的は、隣接するネットワーク デバイスにリンク層通知を配信するための、ベンダー間互換性のあるメカニズムを提供することです。

詳細については、https://vincentbernat.github.io/lldpd/index.html を参照してください。

Nagios

Nalios は、Nadios Remote Plug-in Executor（NRPE）および SSH または SSL トンネルを介して以下をモニターするオープンソースソフトウェアです。

- ICMP、SNMP、SSH、FTP、HTTP などによるネットワーク サービス

- CPU 負荷、ディスク使用率、システム ログなどのホスト リソース

- サーバー、スイッチ、アプリケーションのアラート サービス

- [サービス（Services）]

詳細については、https://www.nagios.org/ を参照してください。

OpenSSH

OpenSSH は、盗聴、接続ハイジャック、およびその他の攻撃を排除するために、すべてのトラフィック（パスワードを含む）を暗号化する SSH 接続ツールのオープンソース バージョンです。OpenSSH は、セキュアなトンネリング機能と複数の認証方式を提供し、すべての SSH プロトコル バージョンをサポートします。

詳細については、http://www.openssh.com を参照してください。

Quagga

Quagga は、さまざまなルーティング プロトコルを実装するネットワーク ルーティング ソフトウェア スイートです。Quagga デーモンは、ネットワーク アクセス可能 CLI（「vty」という）を使用して構成できます。

（注）

Quagga BGP のみが検証されています。

詳細については、http://www.nongnu.org/quagga/ を参照してください。

Splunk

Splunk is a web-based data collection, analysis, and monitoring tool that has search, visualization, and prepackaged content for use-cases. The raw data is sent to the Splunk server using the Splunk Universal Forwarder. Universal Forwarders provide reliable, secure data collection from remote sources and forward that data into the Splunk Enterprise for indexing and consolidation. They can scale to tens of thousands of remote systems, collecting terabytes of data with a minimal impact on performance.

For additional information, see http://www.splunk.com/en_us/download/universal-forwarder.html.

tcollector

tcollector は、ローカル コレクタからデータを収集し、そのデータをオープン時系列データベース（OpenTSDB）にプッシュするクライアント側プロセスです。

tcollector には次の機能があります。

- データ コレクタを実行し、データを照合します。

- 時系列データベース（TSD）への接続を管理します。

- コレクタに TSD コードを埋め込む必要がなくなります。

- 繰り返される値の重複を排除します。

- ワイヤ プロトコル作業を処理します。

詳細については、http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html を参照してください。

tcpdump

tcpdump は、ネットワーク インターフェイス上の Boolean 式に一致するパケットの内容に関する説明を出力する CLI アプリケーションです。説明の前にタイムスタンプが表示されます。デフォルトでは、午前 0 時からの時間、分、秒、および小数点以下の秒として出力されます。

tcpdump は、次のフラグを使用して実行できます。

- -w：後で分析するためにパケット データをファイルに保存します。

- -r：ネットワーク インターフェイスからパケットを読み取るのではなく、保存されたパケット ファイルから読み取ります。

- -V：保存されたパケット ファイルのリストを読み取ります。

いずれの場合も、tcpdump は式にマッチするパケットだけを処理します。

詳細については、http://www.tcpdump.org/manpages/tcpdump.1.html を参照してください。

TShark

TShark は、CLI のネットワーク プロトコル アナライザです。Tshark を使用すると、ライブネットワークからパケットデータをキャプチャしたり、以前に保存したキャプチャファイルからパケットを読み取ったりできます。これらのパケットのデコードされた形式を標準出力に出力するか、パケットをファイルに書き込むことができます。TShark のネイティブ キャプチャ ファイル フォーマットは、pcap です。このフォーマットは、 tcpdump と他のツールに使用されています。TShark は、cap_net_admin ファイル機能を削除した後、ゲストシェル内で使用できます。

setcap
cap_net_raw=ep /sbin/dumpcap

（注）

このコマンドは、ゲストシェル内で実行する必要があります。

詳細については、https://www.wireshark.org/docs/man-pages/tshark.html を参照してください。

Chapter11. Ansible

- 前提条件

- アンシブルについて

- Cisco Ansible モジュール

前提条件

サポートされている制御環境のインストール要件については、https://docs.ansible.com/ansible/latest/getting_started/index.html を参照してください。

アンシブルについて

Ansible は、クラウド プロビジョニング、構成管理、アプリケーションの展開、サービス内オーケストレーション、およびその他の IT ニーズを自動化するオープンソースの IT 自動化エンジンです。

Ansible は、Ansible モジュールと呼ばれる小さなプログラムを使用してノードへの API 呼び出しを行い、Playbook で定義された構成を適用します。

デフォルトでは、Ansible は、すべての管理対象マシンを独自に選択したグループに入れる単純な INI ファイルを使用して、管理対象のマシンを表します。

詳細については、Ansible から入手できます。

Ansible

https://www.ansible.com/

Ansible 自動化ソリューションインストール手順、プレイブックの手順と例、モジュール リストなどが含まれます。

https://docs.ansible.com/

Cisco Ansible モジュール

次のリンクの表に示すように、Ansible には複数の Cisco NX-OS でサポートされるモジュールとプレイブックがあります。

NX-OS デベロッパーのランディング ページ。

構成管理ツール

Ansible NX-OS プレイブックの例

Ansible nxos Playbook のリポジトリ

Ansible NX-OS ネットワーク モジュール

nxos ネットワーク モジュール

Chapter12. Puppet Agent

この章は、次の項で構成されています。

- Puppet について

- 前提条件

- Puppet エージェント NX-OS 環境

- ciscopuppet モジュール

Puppet について

Puppet Labs によって開発された Puppet ソフトウェア パッケージは、サーバやその他の技術情報を管理するためのオープン ソースの自動化ツールセットです。Puppet ソフトウェアは、構成設定などのデバイス状態を適用することにより、サーバとリソースの管理を実現します。

Puppet コンポーネントには、管理対象デバイス（ノード）および Puppet Primary（サーバ）上で動作する Puppet エージェントが含まれます。通常、Puppet Primary は個別の専用サーバ上で実行され、複数のデバイスにサービスを提供します。Puppet エージェントの操作では、Puppet Primary に定期的に接続する必要があります。そして、Puppet Primary は構成マニフェストをコンパイルしてエージェントに送信します。エージェントは、ノードの現在の状態でこのマニフェストを調整し、相違点に基づいて状態を更新します。

Puppet マニフェストは、デバイスの状態を設定するためのプロパティ定義の集合です。これらのプロパティ状態の確認および設定の詳細は抽象化されているため、マニフェストは複数のオペレーティングシステムまたはプラットフォームで使用できます。マニフェストは、通常、構成時の設定を定義するために使用されますが、ソフトウェアパッケージのインストール、ファイルのコピー、およびサービスの開始にも使用できます。

詳細については、Puppet Labs を参照してください。

Puppet Labs

https://puppetlabs.com

Puppet Labs FAQ

https://puppet.com/blog/how-get-started-puppet-enterprise-faq/

Puppet Labs ドキュメント

https://puppet.com/docs

前提条件

Puppet エージェントの前提条件は次のとおりです。

- インストールをサポートする Cisco Nexus スイッチおよびオペレーティング システム ソフトウェア リリースが必要です。

- Cisco Nexus 9300 シリーズ スイッチ。

- Cisco Nexus 9500 シリーズ スイッチ。

- Cisco NX-OS リリース 7.0（3）I2（5）以降。

- 仮想サービスのインストールと Puppet Agent の展開に必要なディスク ストレージをデバイスで使用できる必要があります。

- ブートフラッシュに最低 450MB の空きディスク容量。

- Puppet 4.0 以降の Puppet プライマリ サーバーが必要です。

- Puppet エージェント 4.0 以降が必要です。

Puppet エージェント NX-OS 環境

Puppet Agent ソフトウェアは、ゲスト シェル（CentOS を実行する Linux コンテナ環境）のスイッチにインストールする必要があります。ゲスト シェルは、ホストから切り離された安全でオープンな実行環境を提供します。

Cisco NX-OS リリース 9.2（1）以降、Puppet Agent の Bash-shell（Cisco NX-OS の基盤となるネイティブ WindRiver Linux 環境）インストールはサポートされなくなりました。

次に、エージェント ソフトウェアのダウンロード、インストール、およびセットアップに関する情報を示します：

Puppet Agent：Cisco Nexus スイッチでのインストールとセットアップ （手動セットアップ）

https://github.com/cisco/cisco-network-puppet-module/blob/develop/docs/README-agent-install.md

ciscopuppet モジュール

ciscopuppet モジュールは、Cisco が開発したオープン ソース ソフトウェア モジュールです。これは、Puppet マニフェストの抽象技術情報構成と、Cisco NX-OS オペレーティング システムおよびプラットフォームの特定の実装の詳細との間のインターフェイスとなります。このモジュールは Puppet プライマリにインストールされ、Cisco Nexus スイッチでの Puppet エージェントの操作に必要です。

ciscopuppet モジュールは、Puppet Forge で利用できます。

ここでは、ciscopuppet モジュール インストール手順についての追加情報を提供します：

ciscopuppet モジュールの場所

（Puppet Forge）

Puppet Forge

リソースの種類のカタログ

[Cisco Puppet 技術情報の参照先（Cisco Puppet Resource Reference）]

ciscopuppet モジュール：送信元 コード リポジトリ

[Cisco Network Puppet モジュール（Cisco Network Puppet Module）]

ciscopuppet モジュール：セットアップと使用法

Cisco Puppet モジュール::README.md

Puppet Labs: モジュールのインストール

https://puppet.com/docs/puppet/7/modules_installing.html

Puppet NX-OS マニフェストの例

[Cisco Network Puppet モジュールの例（Cisco Network Puppet Module Examples）]

NX-OS デベロッパーのランディング ページ。

構成管理ツール

Chapter13. Cisco NX-OS と一緒にシェフ クライアントを使用

この章は、次の項で構成されています。

- シェフについて

- 前提条件

- Chef クライアント NX-OS 環境

- cisco-cookbook

シェフについて

Chef は、Chef Software、 Inc. によって開発されたオープンソース ソフトウェア パッケージです。ソフトウェアパッケージは、インフラストラクチャのサイズに関係なく、物理、仮想、またはクラウドの場所にサーバーとアプリケーションを導入する、システムおよびクラウド インフラストラクチャの自動化フレームワークです。各組織は、1 つ以上のワークステーション、単一サーバー、Chef クライアントが設定されていて、維持されているすべてのノードで構成されます。各ノードの設定方法について Chef クライアントに指示するために、クックブックとレシピが使用されます。すべてのノードにインストールされている Chef クライアントが、実際の設定を行います。

Chef クックブックは、設定とポリシーの配布の基本単位です。クックブックではシナリオを定義します。また、そのシナリオをサポートするために必要なすべての内容（ライブラリ、レシピ、ファイルなど）が含まれています。Chef レシピは、デバイスの状態を設定するためのプロパティ定義の集合です。これらのプロパティ状態の確認および設定の詳細は抽象化されているため、レシピは複数のオペレーティングシステムまたはプラットフォームで使用できます。レシピは、通常、構成時の設定を定義するために使用されますが、ソフトウェアパッケージのインストール、ファイルのコピー、およびサービスの開始などにも使用できます。

次のリファレンスは、Chef からの詳細情報を提供します。

トピック

リンク

Chef ホーム

https://www.chef.io

Chef の概要

https://docs.chef.io/chef_overview.html

Chef のドキュメント（すべて）

https://docs.chef.io/

前提条件

シェフの前提条件は次のとおりです：

- インストールをサポートする Cisco デバイスおよびオペレーティング システム ソフトウェア リリースが必要です。

- Cisco Nexus 9500 シリーズ スイッチ

- Cisco Nexus 9300 シリーズ スイッチ

- Cisco NX-OS リリース 7.0（3）I2（5）以降

- シェフの展開に必要なディスク ストレージがデバイス上に用意されている必要があります：

- ブートフラッシュに最低 500 MB の空きディスク容量

- シェフ 12.4.1 以降のシェフ サーバが必要です。

- シェフ クライアント 12.4.1 以降が必要です。

Chef クライアント NX-OS 環境

chef-client ソフトウェアは、ゲスト シェル（CentOS を実行する Linux コンテナ環境）のスイッチにインストールする必要があります。このソフトウェアは、ホストから切り離された安全でオープンな実行環境を提供します。

Cisco NX-OS リリース 9.2(1) 以降、chef-client の Bash-shell（NX-OS の基盤となるネイティブ WindRiver Linux 環境）インストールはサポートされなくなりました。

次のドキュメントには、エージェント ソフトウェアのダウンロード、インストール、および手順ごとのガイダンスが記載されています。

トピック

リンク

Chef クライアント：Cisco Nexus プラットフォームでのインストールとセットアップ（手動セットアップ）

cisco-cookbook::README-install-agent.md

Chef クライアント：Cisco Nexus プラットフォームでのインストールとセットアップ（Chef プロビジョナを使用した自動インストール）

cisco-cookbook::README-chef-provisioning.md

cisco-cookbook

cisco-cookbook は、Chef レシピの抽象リソース構成と、Cisco Nexus スイッチの特定の実装の詳細との間の、シスコが開発したオープン ソース インターフェイスです。このクックブックは Chef Server にインストールされ、Cisco Nexus スイッチでの Chef Client の適切な動作に必要です。

cisco-cookbook は、Chef Supermarket にあります。

次のドキュメントには、cisco-cookbook および一般的なクックブックのインストール手順の詳細が記載されています。

トピック

リンク

cisco-cookbook の場所

Chef Supermarket Cisco クックブック

リソースの種類のカタログ

リソース カタログ（テクノロジー別）

cisco-cookbook: ソース コード リポジトリ

Cisco Network Chef クックブック

cisco-cookbook: セットアップと使用法

Chef クックブックのセットアップと使用方法

Chef Supermarket

Chef Supermarket

Chef NX-OS マニフェストの例

Cisco Network Chef クックブックのレシピ

Chapter14. Nexus アプリケーション開発：ISO

この章は、次の内容で構成されています。

- ISO について

- ISO のインストール

- ISO を使用したアプリケーションの構築

- RPM を使用したアプリケーションのパッケージ化

ISO について

ISO イメージは、サードパーティ製アプリケーションを構築し、スイッチ上でネイティブに実行するために必要なツール、ライブラリ、およびヘッダーを含み、RPM パッケージ化されたブート可能な Wind River 5 環境です。

格納ファイルはすべてを網羅しているわけではなく、特定のアプリケーションに必要な依存関係をユーザーがダウンロードして構築する必要がある場合があります。

（注）

一部のアプリケーションは、Cisco devhub Web サイトからダウンロードしてすぐに使用できるようになっていて、構築する必要はありません。

ISO のインストール

ISO イメージは、次の URL からダウンロードできます：http://devhub.cisco.com/artifactory/simple/open-nxos/7.0-3-I2-1/x86_64/satori-vm-intel-xeon-core.iso。

ISO は、仮想マシンとしてインストールすることを目的としています。仮想化ベンダーの指示に従って、ISO をインストールします。

手順

ステップ 1

（任意） VMware ベースのインストール。

VMWare 仮想マシンに ISO イメージをインストールするには、仮想ディスクを SCSI ではなく SATA として構成する必要があります。

ステップ 2

（任意） QEMU ベースのインストール。

次のコマンドを入力します。

bash$ qemu-img create satori.img 10G
bash$ qemu-system-x86_64 -cdrom ./satori-vm-intel-xeon-core.iso -hda ./satori.img -m 8192

ISO の起動が開始されると、メニューが表示されます。[グラフィック コンソールのインストール（Graphics Console Install）] オプションを選択します。これにより、仮想 HD にインストールされます。インストールが完了したら、仮想マシンを再起動する必要があります。

次のタスク

システムにログインするには、ログインとして root を、パスワードとして root を入力します。

ISO を使用したアプリケーションの構築 SDK および一般的な Linux で動作するほとんどの構築手順は、ISO 環境にも適用されます。ただし、実行するシェル環境スクリプトはありません。インストールされているツールを使用するには、デフォルトのパスで問題ありません。アプリケーションの送信元コードは、送信元 tar ファイルや git リポジトリなどの通常のメカニズムを使用して取得する必要があります。

送信元コードを構築します。

bash$ tar --xvzf example-lib.tgz
bash$ mkdir example-lib-install
bash$ cd example-lib/
bash$ ./configure --prefix=/path/to/example_lib_install
bash$ make

bash$ make install

ISO を使用したアプリケーションの構築

SDK および一般的な Linux で動作するビルド手順のほとんどは、ISO 環境にも適用されます。ただし、実行するシェル環境スクリプトはありません。インストールされているツールを使用するには、デフォルトのパスで問題ありません。アプリケーションの送信元コードは、送信元 tar ファイルや git リポジトリなどの通常のメカニズムを使用して取得する必要があります。

手順

送信元コードを構築ドします。

1. tar –xvzf example-lib.tgz

2. mkdir example-lib-install

3. cd example-lib/

4. ./configure –prefix=path_to_example-lib-install

5. make

6. make install

手順は通常の Linux です。

例:

次に、送信元コードを構築する例を示します。

bash$  tar –xvzf  example-lib.tgz
bash$  mkdir  example-lib-install
bash$  cd example-lib/
bash$  ./configure –prefix=<path_to_example-lib-install>
bash$  make
bach$ make install

RPM を使用したアプリケーションのパッケージ化

「make」を使用してアプリケーションが正常にビルドされたら、RPM にパッケージ化できます。

（注）

RPM および spec ファイル
RPM パッケージ フォーマットは、特定のアプリケーションの完全なインストールに必要なすべてのファイル（バイナリ、ライブラリ、構成、ドキュメントなど）をパッケージ化するように設計されています。したがって、RPM ファイルを作成するプロセスにはいくらかの手間がかかります。RPM ビルドプロセスを支援するために、ビルドプロセスに関するすべてを制御する .spec ファイルが使用されます。

（注）

多くのサードパーティ製アプリケーションは、パッケージ化されたソース コードを tarball にした形式で、インターネットから入手できます。多くの場合、これらの tarball には RPM ビルドプロセスに役立つ .spec ファイルが含まれています。残念ながら、これらの .spec ファイルの多くは、送信元コード自体ほど頻繁には更新されていません。さらに悪いことに、spec ファイルがまったくない場合もあります。このような場合、RPM を構築できるように、spec ファイルを編集するか、最初から作成する必要があります。

Chapter15. Nexus アプリケーション開発 SDK

この章は、次の内容で構成されています。

- Cisco SDK について

- SDK のインストール

- インストールと環境の初期化の手順

- SDK を使用したアプリケーションの構築

- RPM を使用したアプリケーションのパッケージ化

- RPM ビルド環境の作成

- 一般的な RPM ビルド手順の使用

- オプションのプラグインを使用しない collectd RPM の構築例

- オプションの Curl プラグインを使用した collectd の RPM のビルド例

Cisco SDK について

Cisco SDK は、Yocto 1.2 に基づく開発キットです。Cisco NX-OS リリース 7.0(3)I2(1) 以降を実行するスイッチで実行するアプリケーションを構築するために必要なすべてのツールが含まれています。基本コンポーネントは、多くのアプリケーションで一般的に使用される C クロスコンパイラ、リンカ、ライブラリ、およびヘッダー ファイルです。リストはすべてを網羅しているわけではなく、特定のアプリケーションに必要な依存関係をダウンロードして構築する必要がある場合があります。一部のアプリケーションは、Cisco devhub Web サイトからダウンロードして使用する準備ができており、構築を必要としないことに注意してください。SDK は、スイッチに直接インストールできる RPM パッケージをビルドするために使用できます。

SDK のインストール

以下にシステム要件を示します。

- SDK は、ほとんどの最新の 64 ビット x86_64 Linux システムで実行できます。CentOS 7 および Ubuntu 14.04 で検証済みです。Bash シェルで SDK をインストールして実行します。

- SDK には、32 ビット アーキテクチャと 64 ビット アーキテクチャの両方のバイナリが含まれているため、32 ビット ライブラリもインストールされている x86_64 Linux システムで実行する必要があります。

手順

32 ビットライブラリがインストールされているかどうかを確認します。

例:

bash$ ls /lib/ld-linux.so.2

このファイルが存在する場合は、32 ビットライブラリがすでにインストールされています。それ以外の場合は、次のように 32 ビット ライブラリをインストールします。

- CentOS 7 の場合：

bash$ sudo yum install glibc.i686

- Ubuntu 14.04 の場合：

bash$ sudo apt-get install gcc-multilib

インストールと環境の初期化の手順

SDK は https://devhub.cisco.com/artifactory/open-nxos/10.0.1/nx-linux-x86_64-nxos-rootfs-n9k-sup-toolchain-1.1.0.sh からダウンロードできます。

このファイルは自己解凍アーカイブで、SDK を任意のディレクトリにインストールできます。SDK のインストール ディレクトリへのパスの入力が求められます。

bash$ ./wrlinux-8.0.0.25-glibc-x86_64-n9000-nxos-image-rpm-sdk-sdk.sh
Wind River Linux SDK installer version 8.0-n9000
================================================
Enter target directory for SDK (default: /opt/windriver/wrlinux/8.0-n9000):
You are about to install the SDK to "/opt/windriver/wrlinux/8.0-n9000". Proceed[Y/n]? Y
Extracting SDK...............................................................................done
Setting it up...done
SDK has been successfully set up and is ready to be used.

. environment-setup-corei7-64-nxos-linux
. environment-setup-corei7-32-nxosmllib32-linux

source environment-setup-corei7-64-nxos-linux
source environment-setup-corei7-32-nxosmllib32-linux
=============================

source environment-setup-x86_64-wrs-linux コマンドを使用して、SDK 固有のパスをシェル環境に追加します。これは、SDK で使用するシェルごとに実行する必要があります。これは、ビルド ツールとライブラリの正しいバージョンを使用するために SDK を設定するためのキーです。

手順

ステップ 1

インストール先ディレクトリを参照します。

ステップ 2

Bash プロンプトで次のコマンドを入力します。

bash$ source environment-setup-x86_64-wrs-linux

SDK を使用したアプリケーションの構築

一般的な Linux でのビルド プロセスの多くは、このシナリオで機能します。状況に最適な方法を使用してください。
アプリケーション パッケージのソースコードは、さまざまな方法で取得できます。たとえば、tar ファイル フォーマットで、またはパッケージが存在する git リポジトリからダウンロードして、ソースコードを取得できます。

次は最も一般的なケースの一例です。

（オプション）アプリケーション パッケージが標準の configure/make/make install を使用してビルドできるかどうかを確認します。

bash$ tar --xvzf example-app.tgz
bash$ mkdir example-lib-install
bash$ cd example-app/
bash$ ./configure --prefix=/path/to/example-app-install
bash$ make
bash$ make install

場合によっては、./configure スクリプトに追加のオプションを渡す必要があります。たとえば、必要なオプションのコンポーネントと依存関係を指定する場合などです。追加オプションを渡すかどうかは、構築するアプリケーションに完全に依存します。

例：Ganglia とその依存関係の構築

この例では、ganglia と、必要なサードパーティ ライブラリ（libexpat、libapr、および libconfuse）を作成します。

libexpat

bash$ wget 'http://downloads.sourceforge.net/project/expat/expat/2.1.0/expat-2.1.0.tar.gz'
bash$ mkdir expat-install
bash$ tar xvzf expat-2.1.0.tar.gz
bash$ cd expat-2.1.0
bash$ ./configure --prefix=/home/sdk-user/expat-install
bash$ make
bash$ make install
bash$ cd ..

libapr

bash$ wget 'http://www.eu.apache.org/dist/apr/apr-1.5.2.tar.gz'
bash$ mkdir apr-install
bash$ tar xvzf apr-1.5.2.tar.gz
bash$ cd apr-1.5.2
bash$ ./configure --prefix=/home/sdk-user/apr-install
bash$ make
bash$ make install
bash$ cd ..

libconfuse

（注）

confuse には、./configure に追加の --enable-shared オプションが必要です。そうしないと、必要な共有ライブラリの代わりに静的にリンクされたライブラリがビルドされます。

bash$ wget 'http://savannah.nongnu.org/download/confuse/confuse-2.7.tar.gz'
bash$ mkdir confuse-install
bash$ tar xvzf confuse-2.7.tar.gz
bash$ cd confuse-2.7
bash$ ./configure --prefix=/home/sdk-user/confuse-install --enable-shared
bash$ make
bash$ make install
bash$ cd ..

ganglia

（注）

必要なすべてのライブラリの場所が ./configure に渡されます。

bash$ wget 'http://downloads.sourceforge.net/project/ganglia/ganglia%20monitoring%20core/3.7.2/ganglia-3.7.2.tar.gz'
bash$ mkdir ganglia-install
bash$ tar xvzf ganglia-3.7.2.tar.gz
bash$ cd ganglia-3.7.2
bash$ ./configure --with-libexpat=/home/sdk-user/expat-install --with-libapr=/home/sdk-user/apr-install/bin/apr-1-config --with-libconfuse=/home/sdk-user/confuse-install --prefix=/home/sdk-user/ganglia-install
bash$ make
bash$ make install
bash$ cd ..

RPM を使用したアプリケーションのパッケージ化

「make」を使用してアプリケーションが正常にビルドされたら、RPM にパッケージ化できます。

（注）

RPM および spec ファイル
RPM パッケージ フォーマットは、特定のアプリケーションの完全なインストールに必要なすべてのファイル（バイナリ、ライブラリ、構成、ドキュメントなど）をパッケージ化するように設計されています。したがって、RPM ファイルを作成するプロセスにはいくらかの手間がかかります。RPM ビルドプロセスを支援するために、ビルドプロセスに関するすべてを制御する .spec ファイルが使用されます。

（注）

多くのサードパーティ製アプリケーションは、パッケージ化されたソース コードを tarball にした形式で、インターネットから入手できます。多くの場合、これらの tarball には RPM ビルドプロセスに役立つ .spec ファイルが含まれています。残念ながら、これらの .spec ファイルの多くは、送信元コード自体ほど頻繁には更新されていません。さらに悪いことに、spec ファイルがまったくない場合もあります。このような場合、RPM を構築できるように、spec ファイルを編集するか、最初から作成する必要があります。

RPM ビルド環境の作成

SDK を使用して RPM をビルドする前に、RPM ビルド ディレクトリ構造を作成し、いくつかの RPM マクロを設定する必要があります。

手順

ステップ 1

ディレクトリ構造を作成します：

bash$ mkdir rpmbuild
bash$ cd rpmbuild
bash$ mkdir BUILD RPMS SOURCES SPECS SRPMS

ステップ 2

上で作成したディレクトリ構造を指すように topdir マクロを設定します：

bash$ echo "_topdir ${PWD}" > ~/.rpmmacros

（注）

この手順は、現在のユーザーがすでに設定されている .rpmmacros ファイルを持っていないことを前提としています。既存の .rpmmacros ファイルを変更するのが不便な場合は、すべての rpmbuild コマンドラインに次を追加できます：

--define "_topdir ${PWD}"

ステップ 3

RPM DB を更新します：

bash$ rm /path/to/sdk/sysroots/x86_64-wrlinuxsdk-linux/var/lib/rpm/__db.*
bash$ rpm --rebuilddb

（注）

SDK の rpm および rpmbuild ツールは、RPM データベースとして通常の /var/lib/rpm の代わりに /path/to/sdk/sysroots/x86_64-wrlinuxsdk-linux/var/lib/rpm を使用するように変更されました。この変更により、SDK を使用していない場合にホストの RPM データベースと競合することが回避され、root アクセスの必要性がなくなります。SDK のインストール後、この手順に従って SDK RPM データベースを再構築する必要があります。

一般的な RPM ビルド手順の使用

一般的な RPM ビルド手順は次のとおりです。

bash$ wget --no-check-certificate --directory-prefix=SOURCES http://<URL of example-app tarball>
bash$ # determine location of spec file in tarball:
bash$ tar tf SOURCES/example-app.tar.bz2 | grep '.spec$'
bash$ tar xkvf SOURCES/example-app.tar.bz2 example-app/example-app.spec
bash$ mv example-app/example-app.spec SPECS/
bash$ rm -rf example-app
bash$ rpmbuild -v --bb SPECS/example-app.spec

結果は RPMS/ に作成されるバイナリ RPM で、スイッチにコピーしてインストールできます。アプリケーションのインストール方法と構成には様々なバリエーションがあり得ます。これらの手順については、アプリケーションのドキュメントを参照してください。

この rpm ビルドとスイッチへのインストールは、アプリケーションをサポートするために必要なすべてのソフトウェアパッケージで必要です。SDK にまだ含まれていないソフトウェアの依存関係を満たすことが必要な場合は、ソースコードを取得して、依存関係のあるソフトウェアもビルドする必要があります。ビルド用のマシンでは、パッケージを手動でビルドして、依存関係を検証することができます。次に、最も一般的な手順の例を示します。

bash$ tar xkzf example-lib.tgz
bash$ mkdir example-lib-install
bash$ cd example-lib/
bash$ ./configure --prefix=/path/to/example-lib-install
bash$ make
bash$ make install

これらのコマンドは、ビルド ファイル（バイナリ、ヘッダー、ライブラリなど）をインストール ディレクトリに配置します。ここから、標準のコンパイラとリンカのフラグを使用して、依存関係を満たすための新しい場所を選択できます。ライブラリなどのランタイム コードがあれば、それらもスイッチにインストールする必要があるため、必要なランタイム コードを RPM にパッケージ化しなければなりません。

（注）

Cisco devhub の Web サイトには、すでに RPM 形式にまとめられているサポート ライブラリが多数あります。

オプションのプラグインを使用しない collectd RPM の構築例

ソース tarball をダウンロードし、spec ファイルを抽出します。

bash$ wget --no-check-certificate --directory-prefix=SOURCES https://collectd.org/files/collectd-5.5.0.tar.bz2
bash$ tar tf SOURCES/collectd-5.5.0.tar.bz2 | grep '.spec$'
collectd-5.5.0/contrib/redhat/collectd.spec
collectd-5.5.0/contrib/aix/collectd.spec
collectd-5.5.0/contrib/sles10.1/collectd.spec
collectd-5.5.0/contrib/fedora/collectd.spec
bash$ tar xkvf SOURCES/collectd-5.5.0.tar.bz2 collectd-5.5.0/contrib/redhat/collectd.spec
bash$ mv collectd-5.5.0/contrib/redhat/collectd.spec SPECS/
bash$ rm -rf collectd-5.5.0

この tarball には 4 つの spec ファイルがあります。Red Hat の spec ファイルは最も包括的であり、正しい collectd バージョンを含む唯一のファイルです。これを例として使用します。

この仕様ファイルは、/sbin/chkconfig を使用して collectd をインストールするように RPM を設定します。ただし、スイッチでは、代わりに /usr/sbin/chkconfig を使用します。spec ファイルで以下のように編集します。

bash$ sed -r -i.bak 's%(^|\s)/sbin/chkconfig%\1/usr/sbin/chkconfig%' SPECS/collectd.spec

collectd には多数のオプション プラグインがあります。この spec ファイルは、デフォルトで多くのプラグインを有効にします。多くのプラグインには外部依存関係があるため、これらのプラグインを無効にするオプションを rpmbuild コマンド ラインに渡す必要があります。1 つの長いコマンド ラインを入力する代わりに、次のように Bash 配列でオプションを管理できます。

bash$ rpmbuild_opts=()
bash$ for rmdep in \
> amqp apache ascent bind curl curl_xml dbi ipmi java memcachec mysql nginx \
> notify_desktop notify_email nut openldap perl pinba ping postgresql python \
> rrdtool sensors snmp varnish virt write_http write_riemann
> do
>  rpmbuild_opts+=("--without")
>  rpmbuild_opts+=(${rmdep})
> done
bash$ rpmbuild_opts+=(--nodeps)
bash$ rpmbuild_opts+=(--define)
bash$ rpmbuild_opts+=("_unpackaged_files_terminate_build 0")

その後、次のように rpmbuild に渡され、ビルドおよび RPM パッケージ プロセス全体が開始されます。

bash$ rpmbuild "${rpmbuild_opts[@]}" -bb SPECS/collectd.spec

結果として、RPMS ディレクトリに、collectd 用に作成された RPM ができています。

これらの RPM ファイルをスイッチにコピーし、スイッチの Bash シェルからインストールすることができます：

bash$ rpm --noparentdirs -i /bootflash/collectd-5.5.0-1.ia32e.rpm

オプションの Curl プラグインを使用した collectd の RPM のビルド例

collectd curl プラグインには、依存関係として libcurl があります。

RPM ビルド プロセス中にこのリンクの依存関係を満たすには、SDK で curl をダウンロードしてビルドする必要があります。

bash$ wget --no-check-certificate http://curl.haxx.se/download/curl-7.24.0.tar.gz
bash$ tar xkvf curl-7.24.0.tar.gz
bash$ cd curl-7.24.0
bash$ ./configure --without-ssl --prefix /path/to/curl-install
bash$ make
bash$ make install
bash$ cd ..

（注）

curl バイナリとライブラリは、/path/to/curl-install にインストールされます。このディレクトリが存在しない場合は作成されるため、現在のユーザーの書き込み権限が必要です。次に、ソース tarball をダウンロードし、spec ファイルを抽出します。この手順は、プラグインがない場合の collectd の例とまったく同じです。

bash$ wget --no-check-certificate --directory-prefix=SOURCES https://collectd.org/files/collectd-5.5.0.tar.bz2
bash$ tar tf SOURCES/collectd-5.5.0.tar.bz2 | grep '.spec$'
collectd-5.5.0/contrib/redhat/collectd.spec
collectd-5.5.0/contrib/aix/collectd.spec
collectd-5.5.0/contrib/sles10.1/collectd.spec
collectd-5.5.0/contrib/fedora/collectd.spec
bash$ tar xkvf SOURCES/collectd-5.5.0.tar.bz2 collectd-5.5.0/contrib/redhat/collectd.spec
bash$ mv collectd-5.5.0/contrib/redhat/collectd.spec SPECS/
bash$ rm -rf collectd-5.5.0

この仕様ファイルは、/sbin/chkconfig を使用して collectd をインストールするように RPM をセットアップします。ただし、スイッチでは、代わりに /usr/sbin/chkconfig を使用する必要があるため、spec ファイルで次のように編集します。

（注）

この tarball には 4 つの spec ファイルがあります。Red Hat の spec ファイルは最も包括的であり、正しい collectd バージョンを含む唯一のファイルです。これを例として使用します。

bash$ sed -r -i.bak 's%(^|\s)/sbin/chkconfig%\1/usr/sbin/chkconfig%' SPECS/collectd.spec

この点は、前の例と違っています。collectd rpmbuild プロセスは、libcurl の場所を認識する必要があります。collectd の spec ファイルを編集して、以下を追加します。

SPECS/collectd.spec で文字列 %configure を検索します。この行とそれに続く行は、rpmbuild が ./configure スクリプトに渡すオプションを定義します。

次のオプションを追加します。

--with-libcurl=/path/to/curl-install/bin/curl-config \

次に、rpmbuild コマンド オプションを含む Bash アレイが再度構築されます。次の違いに留意してください。

- curl をビルドされないプラグインのリストから削除

- --with curl=force の追加

bash$ rpmbuild_opts=()
bash$ for rmdep in \
> amqp apache ascent bind curl_xml dbi ipmi java memcachec mysql nginx \
> notify_desktop notify_email nut openldap perl pinba ping postgresql python \
> rrdtool sensors snmp varnish virt write_http write_riemann
> do
>  rpmbuild_opts+=("--without")
>  rpmbuild_opts+=(${rmdep})
> done
bash$ rpmbuild_opts+=("--with")
bash$ rpmbuild_opts+=("curl=force")bash$ rpmbuild_opts+=(--nodeps)
bash$ rpmbuild_opts+=(--define)
bash$ rpmbuild_opts+=("_unpackaged_files_terminate_build 0")

それからこれは次のように rpmbuild に渡され、ビルドおよび RPM パッケージ プロセス全体が開始されます：

bash$ rpmbuild "${rpmbuild_opts[@]}" -bb SPECS/collectd.spec

RPMs ディレクトリ内の結果の RPM には、collectd-curl も含まれるようになりました。これらの RPM ファイルをスイッチにコピーし、スイッチの Bash シェルからインストールすることができます：

bash$ rpm --noparentdirs -i /bootflash/collectd-5.5.0-1.ia32e.rpm
bash$ rpm --noparentdirs -i /bootflash/collectd-curl-5.5.0-1.ia32e.rpm

Chapter16. NX-SDK

- NX-SDK について

- NX-SDK のインストール

- C++ アプリケーションの構築とパッケージ化

- カスタム アプリケーションのインストールと実行

NX-SDK について

Cisco NX-OS SDK（NX-SDK）は、自動化およびカスタム アプリケーションの作成（カスタムの生成など）のためのインフラストラクチャへのアクセスを合理化する C++ 抽象化およびプラグイン ライブラリ レイヤです。

- CLI

- Syslog

- イベント マネージャとエラー マネージャ

- アプリケーション間通信

- ハイ アベイラビリティ（HA）

- ルート マネージャ

NX-SDK を使用したアプリケーション開発には、C++、Python、または Go を使用できます。

要件

NX-SDK では次の要件があります。

- Docker

- Linux 環境（Ubuntu 14.04 または Centos 6.7 のいずれか）。提供されている NX-SDK Docker コンテナを使用することをお勧めします。詳細については、「Cisco DevNet NX-SDK」を参照してください。

関連情報

Cisco NX-SDK の詳細については、次にアクセスしてください。

- Cisco DevNet NX-SDK。サポートされるリリースごとの機能と詳細については、versions.md リンク（https://github.com/CiscoDevNet/NX-SDK/blob/master/versions.md） を参照してください。

NX-SDK のインストール

手順

ステップ 1

（任意） スイッチのリロード時およびスタンバイモードから永続化する Cisco SDK RPM を構築します。

（注）

Cisco SDK は、VSH で起動されるアプリケーションに必要です。

Cisco SDK は、Bash で起動されたアプリケーションではオプションです。

1. https://hub.docker.com/r/dockercisco/nxsdkから Ubuntu 14.04 以降または Centos 6.7 以降の Docker イメージをプルします。

2. 32 ビット環境の送信元：

例:

export ENXOS_SDK_ROOT=/enxos-sdk
cd $ENXOS_SDK_Root
source environment-setup-x86-linux

ステップ 2

https://github.com/CiscoDevNet/NX-SDK.git から NX-SDK ツールキットのクローンを作成します。

例:

git clone  https://github.com/CiscoDevNet/NX-SDK.git

次のタスク

API への次の参照は、$PWD/nxsdk にあり、次のものが含まれます：

- NX-SDK パブリック C++ クラスおよび API、

- アプリケーション例と

- Python アプリケーションの例。

C++ アプリケーションの構築とパッケージ化

次の手順では、カスタム C++ NX-OS アプリケーションを構築およびパッケージ化する方法について説明します。

手順

ステップ 1

アプリケーション ファイルの構築

1. C++ アプリケーションを構築するには、送信元ファイルを Makefile に追加する必要があります。

例:

次の例では、/examples の customCliApp.cpp ファイルを使用します。

...
##Directory Structure
...
EXNXSDK_BIN:= customCliApp
...

2. make コマンドを使用して C++ アプリケーションを構築します。

例:

$PWD/nxsdk# make clean
$PWD/nxsdk# make all

ステップ 2

（任意） アプリケーションをパッケージします。

[RPM パッケージの自動生成（Auto-generate RPM package）]

アプリケーションのカスタム RPM パッケージは VSH で実行する必要があり、特定のアプリケーションがスイッチのリロードまたはシステム スイッチオーバーで保持されるかどうかを指定できます。以下を使用して、アプリケーションのカスタム仕様ファイルを作成します。

（注）

RPM パッケージ化は、提供されている ENXOS Docker イメージ内で実行する必要があります。

1. rpm_gen.py スクリプトを使用して、カスタムアプリケーションの RPM パッケージを自動生成します。

例:

スクリプトの使用状況を表示するには、スクリプトの -h オプションを指定します。

/NX-SDK# python scripts/rpm_gen.py -h

2. デフォルトでは、NXSDK_ROOT は /NX-SDK に設定されます。NX-SDK がデフォルト以外の別の場所にインストールされている場合は、スクリプトが正しく実行されるように NXSDK_ROOT 環境を適切な場所に設定する必要があります。

例:

export NXSDK_ROOT=<absolute-path-to-NX-SDK>

C++ アプリケーション用の RPM パッケージの自動生成の例 example/customCliApp.cpp

/NX-SDK/scripts# python rpm_gen.py CustomCliApp
#########################################################################################################

Generating rpm package...

Executing(%prep): /bin/sh -e /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/var/tmp/rpm-tmp.49266
+ umask 022
+ cd /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../src/rpm/BUILD
+ exit 0
Executing(%build): /bin/sh -e /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/var/tmp/rpm-tmp.49266
+ umask 022
+ cd /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../src/rpm/BUILD
+ exit 0
Executing(%install): /bin/sh -e /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/var/tmp/rpm-tmp.49266
+ umask 022
+ cd /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../src/rpm/BUILD
+ /bin/rm -rf /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/customCliApp-root
+ /bin/mkdlr -p /enxos-sdk/sysrOOts/x86_64-wrIinuxsdk-linux/usr/lib/rpm/../../../var/tmp/customCliApp-root//isan/bin
+ cp -R /NX-SDK/bin /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/.. /../../var/tmp/customCliApp-root//isan/bin
+ exit 0
Processing files: customCliApp-1.0-7.03.I6.1.x86_64
Requires: libc.so.6 libc.so.6(GLIBC 2.0) 3.0) Libc.so.6(GLIBC_2.1.3) libdl.so.2 libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libm.so.6 libnxsdk.so libstdc++.so.6 libstdc++.so.6 (CXXAB1 1.3) libstdc++.so.6(GLIBCXX 3.4) libstdc++.so.6(GLIBCXX_3.4.14) rt1d(GNU HASH)
Checking for unpackaged file(s): /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/check-files /enos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/customCliApp-root
Wrote: /enxos-sdk/sysrootS/X86_64-wrlinuxsdk-linux/usr/src/rpm/SRPMS/customCliApp-1.0-7.0.3.I6.1.src-rpm
Wrote: /enxos-sdk/sysrootS/X86_64-wrlinuxsdk-linux/usr/src/rpm/RPMS/x86_64/customCliApp-1.0-7.0.3.I6.1.x86_64.rpm
Executing($clean): /bin/sh -e /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/var/tmp/rpm-tmp.49266
+ umask 022
+ cd /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../src/rpm/BUILD
+ / bin/rm -rf /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/customCliApp-root
RPM package has been built
#########################################################################################################

SPEC file: /NX-SDK/rpm/SPECS/customCliApp.spec
RPM file : /NX-SDK/rpm/RPMS/customCliApp-1.0-7.0.3.I6.1.x86_64.rpm

[RPM パッケージの手動生成（Manually-generate RPM Package）]

アプリケーションのカスタム RPM パッケージは VSH で実行する必要があり、特定のアプリケーションがスイッチのリロードまたはシステム スイッチオーバーで保持されるかどうかを指定できます。次の手順を使用して、アプリケーションのカスタム仕様ファイル（*.spec ）を作成します。

1. Cisco SDK RPM 送信元を $RPM_ROOT にエクスポートします。

例:

export RPM_ROOT = $ENXOS_SDK_ROOT/sysroots/x86_64-wrlinuxsdk-linux/usr/src/rpm

2. $RPM_ROOT ディレクトリに移動します。

例:

ls $RPM_ROOT（BUILD RPMS SOURCES SPECS SRPMS）

3. アプリケーション固有の *.spec ファイルを作成/編集します。

仕様ファイルの例については、/rpm/SPECS ディレクトリの customCliApp.spec ファイルを参照してください。

（注）

customCliApp.spec ファイルの例に従って、アプリケーション ファイルをスイッチの /isan/bin/nxsdk にインストールすることを推奨します。

例:

vi $RPM_ROOT/SPECS/<application> .spec

4. RPM パッケージを構築します。

例:

rpm -ba $RPM_ROOT/SPECS/<application> .spec

構築を成功させることで$RPMS_ROOT/RPMS/x86_64/ に RPM ファイルが生成されます。

カスタム アプリケーションのインストールと実行

バイナリをスイッチにコピーするか、または RPM パッケージからバイナリを解凍してインストールすることで、アプリケーションをインストールできます。

（注）

RPM パッケージからインストールされたカスタム アプリケーションだけが、スイッチのリロードまたはシステムのスイッチオーバー時に保持できます。単純なテストの目的で、スイッチへのバイナリのコピーを予約することを推奨します。

スイッチ（オンボックス）内で NX-SDK アプリケーションを実行するには、Cisco SDK ビルド環境がインストールされている必要があります。

（注）

VSH でアプリケーションを起動するには、Cisco SDK が必要です：VSH では、すべてのアプリケーションを RPM を介してインストールする必要があります。そのためには、Cisco SDK に組み込まれている必要があります。

Python アプリケーションには Cisco SDK は必要ありません。

Cisco SDK は C++ アプリケーションには必要ありませんが、推奨されます：g++ を使用してアプリケーションを構築し、構築されたファイルをスイッチにコピーすると、g++ がサポートされていないため、安定性が低下する可能性があります。

スイッチにカスタム アプリケーションをインストールまたは実行するには、次の手順を実行します。

始める前に

カスタム アプリケーションを実行する前に、スイッチで NX-SDK を有効にする必要があります。スイッチ上でfeature nxsdk を実行します。

手順

ステップ 1

VSH または Bash を使用してアプリケーションをインストールします。

VSH を使用してアプリケーションをインストールするには、次の手順を実行します。

1. インストーラに RPM パッケージを追加します。

例:

switch(config)# install add bootflash:<app-rpm-package>.rpm

2. インストール後、RPM が非アクティブとしてリストされているかどうかを確認します。

例:

switch(config)# show install inactive

3. RPM パッケージを現用系にします。

例:

switch(config)# install activate <app-rpm-package>

4. アクティブ化後、RPM が現用系としてリストされているかどうかを確認します。

例:

switch(config)# show install active

Bash を使用してアプリケーションをインストールするには、次のコマンドを実行します。

switch(config)# run bash sudo su
bash# yum install /bootflash/<app-rpm-package>.rpm

ステップ 2

アプリケーションを起動します。

C++ アプリケーションは、VSH または Bash から実行できます。

- VSH で C++ アプリケーションを実行するには、次の nxsdk コマンドを実行します。

switch(config)# nxsdk service-name /<install directory>/<application>

（注）

アプリケーションが /isan/bin/nxsdk にインストールされている場合、完全なファイルパスは必要ありません。コマンド nxsdk service-name app-name 形式を使用できます。

- Bash で C++ アプリケーションを実行するには、Bash を起動してからアプリケーションを起動します。

switch(config)# run bash sudo su
bash# <app-full-path> &

Python アプリケーションは、VSH または Bash から実行できます。

- VSH から Python アプリケーションを実行するには、次のnxsdk コマンドを実行します：

switch(config)# nxsdk service-name <app-full-path>

（注）

VSH から起動するには、Python アプリケーションを実行可能にする必要があります：

- chmod +x app-full-path を実行します。

- #!/isan/bin/nxpython を Python アプリケーションの最初のリンクに追加します。

- Bash から Python アプリケーションを実行するには、

switch(config)# run bash sudo su
bash# /isan/bin/nxsdk <app-full-path>

（注）

デフォルトでは、NX-SDK は /isan/bin/nxsdk を使用して Bash で Python アプリケーションを実行しますが、必要に応じて別のインストールディレクトリを指定できます。

ステップ 3

show nxsdk internal service を実行して、アプリケーションが実行していることを確認します

例:

switch(config)# show nxsdk internal service

switch(config)# show nxsdk internal service

NXSDK total services (Max Allowed) : 2 (32)
NXSDK Default App Path         : /isan/bin/nxsdk
NXSDK Supported Versions       :  1.0

Service-name              Base App        Started(PID)    Version    RPM Package
------------------------- --------------- ------------    ---------- --------------------
/isan/bin/capp1           nxsdk_app2      VSH(25270)      1.0        capp1-1.0-7.0.3.I6.1.x86_64
/isan/bin/TestApp.py      nxsdk_app3      BASH(27823)     -          -

ステップ 4

アプリケーションを停止します。

次の方法でアプリケーションを停止できます。

- すべての NX-SDK アプリケーションを停止するには、no feature nxsdk を実行します。

- VSH で特定のアプリケーションを停止するには、 no nxsdk service-name /install directory/application を実行します。

- Bash で特定のアプリケーションを停止するには、application stop-event-loop を実行します。

ステップ 5

アプリケーションをアンインストールします。

VSH を使用してスイッチから RPM をアンインストールするには、次の手順を実行します。

1. アクティブな RPM パッケージを非アクティブ化します。

例:

switch# install deactive <app-rpm-package>

2. パッケージが非アクティブ化されていることを確認します。

例:

switch# show install inactive

3. RPM パッケージを削除します。

例:

switch# install remove <app-rpm-package>

Bash を使用してスイッチから RPM をアンインストールするには、yum remove app-full-path を実行します。

PartIII. NX-API

- NX-API CLI

- NX-API REST

- NX-API 開発者サンドボックス

Chapter17. NX-API CLI

- NX-API CLI について

- NX-API CLI の使用

- NX-API 応答コードの表

NX-API CLI について

NX-API CLI は、XML 出力をサポートする Cisco NX-OS CLI システムの拡張機能です。NX-API CLI は、特定のコマンドの JSON 出力フォーマットもサポートしています。

Cisco Nexus スイッチでは、コマンドライン インターフェイス（CLI）はスイッチ上でのみ実行されます。NX-API CLI は HTTP / HTTPS を使ってスイッチの外部で CLI を使用できるようにすることで、これらの CLI のユーザー補助を改善します。この拡張機能をスイッチの既存の Cisco NX-OS CLI システムに使用できます。NX-API CLI は show コマンド、構成と Linux Bash をサポートします。

NX-API CLI は JSON-RPC をサポートしています。

- 転送

- メッセージ形式

- セキュリティ

転送

NX-APIは、転送のように HTTP または HTTPS を使用します。CLI は、HTTP / HTTPS POST 本文にエンコードされます。

NX-API は、ホスト上でネイティブに、またはゲスト シェル内で実行されるアプリケーションの、UNIX ドメイン ソケットを介してサポートされます。

NX-API バックエンドは Nginx HTTP サーバを使用します。Nginx プロセスとそのすべての子プロセスは、CPU とメモリの使用量が制限されている Linux cgroup 保護下にあります。Nginx のメモリ使用量が cgroup の制限を超えると、Nginx プロセスは再起動されて、NX-API 構成（VRF、ポート、証明書構成）が復元されます。

メッセージ形式

NX-API は、XML 出力をサポートする Cisco NX-OS CLI システムの拡張機能です。NX-API は、特定のコマンドの JSON 出力フォーマットもサポートしています。

（注）

- NX-API XML 出力は、情報を使いやすいフォーマットで表示します。

- NX-API XML は、Cisco NX-OS NETCONF 導入に直接マッピングされません。

- NX-API XML 出力は、JSON に変換できます。

セキュリティ

- NX-API は HTTPS をサポートします。HTTPS を使用すると、デバイスへのすべての通信が暗号化されます。

NX-API は、デバイスの認証システムに統合されています。ユーザーは、NX-API を介してデバイスにアクセスするための適切なアカウントを持っている必要があります。NX-API では HTTP basic 認証が使用されます。すべてのリクエストには、HTTP ヘッダーにユーザー名とパスワードが含まれている必要があります。

（注）

ユーザーのログイン資格情報を保護するには、HTTPS の使用を検討する必要があります。

[機能（feature）] マネージャ CLI コマンドを使用して、NX-API を有効にすることができます。NX-API はデフォルトで無効になっています。

NX-API は、ユーザーが最初に認証に成功したときに、セッション ベースの Cookie、nxapi_auth を提供します。セッション Cookie を使用すると、デバイスに送信される後続のすべての NX-API 要求にユーザー名とパスワードが含まれます。ユーザー名とパスワードは、完全な認証プロセスの再実行をバイパスするために、セッション Cookie で使用されます。セッション Cookie が後続の要求に含まれていない場合は、別のセッション Cookie が必要であり、認証プロセスによって提供されます。認証プロセスの不必要な使用を避けることで、デバイスのワークロードを軽減できます。

（注）

nxapi_auth cookie は 600 秒（10 分）で期限切れになります。この値は固定されており、調整できません。

（注）

NX-API は、スイッチ上の Programmable Authentication Module（PAM）を使用して認証を行います。cookie を使用して PAM の認証数を減らし、PAM の負荷を減らします。

NX-API CLI の使用

Cisco Nexus 9000 シリーズ スイッチのコマンド、コマンド タイプ、および出力タイプは、CLI を HTTP/HTTPS POST の本文にエンコードすることにより、NX-API を使用して入力されます。要求に対する応答は、XML または JSON 出力形式で返されます。

（注）

NX-API 応答コードの詳細については、NX-API 応答コードの表を参照してください。

NX-API CLI は、ローカル アクセスに対してはデフォルトで有効になっています。リモート HTTP アクセスに対してはデフォルトで無効になっています。

次の例は、NX-API CLI を構成して起動する方法を示しています。

- 管理インターフェイスを有効にします。

switch# conf t
Enter configuration commands, one per line.
End with CNTL/Z.
switch(config)# interface mgmt 0
switch(config-if)# ip address 10.126.67.53/25
switch(config-if)# vrf context managment
switch(config-vrf)# ip route 0.0.0.0/0 10.126.67.1
switch(config-vrf)# end
switch#

- NX-API nxapi 機能を有効にします。

switch# conf t
switch(config)# feature nxapi

次の例は、リクエストとそのレスポンスを XML 形式で示しています。

要求:

<?xml version="1.0" encoding="ISO-8859-1"?>
<ins_api>
<version>0.1</version>
<type>cli_show</type>
<chunk>0</chunk>
<sid>session1</sid>
<input>show switchname</input>
<output_format>xml</output_format>
</ins_api>

応答：

<?xml version="1.0"?>
<ins_api>
<type>cli_show</type>
<version>0.1</version>
<sid>eoc</sid>
<outputs>
<output>
<body>
<hostname>switch</hostname>
</body>
<input>show switchname</input>
<msg>Success</msg>
<code>200</code>
</output>
</outputs>
</ins_api>

次の例は、JSON 形式の要求とその応答を示しています。

要求:

{
"ins_api": {
"version": "0.1",
"type": "cli_show",
"chunk": "0",
"sid": "session1",
"input": "show switchname",
"output_format": "json"
}
}

応答：

{
"ins_api": {
"type": "cli_show",
"version": "0.1",
"sid": "eoc",
"outputs": {
"output": {
"body": {
"hostname": "switch"
},
"input": "show switchname",
"msg": "Success",
"code": "200"
}
}
}
}

（注）

ユーザーを削除しようとすると失敗し、次のようなエラー メッセージが約 12 時間ごとに表示されるという既知の問題があります。

user delete failed for username:userdel: user username is currently logged in - securityd

この問題は、NX-API を介してスイッチにログインしているユーザーを削除しようとした場合に発生する可能性があります。この場合、次のコマンドを入力して、最初にユーザーのログアウトを試行します。

switch(config)# clear user username

その後、ユーザーの削除を再試行します。回避策を試みても問題が解決しない場合は、Cisco TAC へお問い合わせください。

- NX-API で権限を root にエスカレーションする

- サンプル NX-API スクリプト

- NX-API 管理コマンド

- NX-API を使用したインタラクティブ コマンドの操作

- NX-API リクエスト要素

- NX-API 応答要素

- NX-API へのアクセスの制限

NX-API で権限を root にエスカレーションする

NX-API では、管理者ユーザーの権限を root アクセスの権限にエスカレーションできます。

以下は、権限をエスカレーションするためのガイドラインです：

- 特権を root にエスカレーションできるのは管理者ユーザーのみです。

- root へのエスカレーションはパスワードで保護されています。

次の例は、管理者の権限を root にエスカレーションする方法と、エスカレーションを確認する方法を示しています。root になっても、whoami コマンドを実行すると admin として表示されることに注意してください。ただし、admin アカウントにはすべての root 権限があります。

最初の例：

<?xml version="1.0"?>
<ins_api>
<version>1.0</version>
<type>bash</type>
<chunk>0</chunk>
<sid>sid</sid>
<input>sudo su root ; whoami</input>
<output_format>xml</output_format>
</ins_api>

<?xml version="1.0" encoding="UTF-8"?>
<ins_api>
<type>bash</type>
<version>1.0</version>
<sid>eoc</sid>
<outputs>
<output>
<body>admin </body>
<code>200</code>
<msg>Success</msg>
</output>
</outputs>
</ins_api>

2 番目の例：

<?xml version="1.0"?>
<ins_api>
<version>1.0</version>
<type>bash</type>
<chunk>0</chunk>
<sid>sid</sid>
<input>sudo cat path_to_file </input>
<output_format>xml</output_format>
</ins_api>

<?xml version="1.0" encoding="UTF-8"?>
<ins_api>
<type>bash</type>
<version>1.0</version>
<sid>eoc</sid>
<outputs>
<output>
<body>[Contents of file]</body>
<code>200</code>
<msg>Success</msg>
</output>
</outputs>
</ins_api>

サンプル NX-API スクリプト

ユーザーは NX-API でスクリプトを使用する方法を示すサンプル スクリプトにアクセスできます。サンプル スクリプトにアクセスするには、次のリンクをクリックして、必要なソフトウェア リリースに対応するディレクトリを選択します：Cisco Nexus 9000 NX-OS NX-API

NX-API 管理コマンド

次の表にリストされている CLI コマンドを使用して、NX-API を有効にして管理できます。

NX-API 管理コマンド

NX-API 管理コマンド

説明

feature nxapi

NX-API を有効化します。

no feature nxapi

NX-API を無効化します。

nxapi {http | https} port port

ポートを指定します。

no nxapi {http | https}

HTTP / HTTPS を無効化します。

show nxapi

ポートと証明書情報を表示します。

nxapi certificate {httpscrt certfile | httpskey keyfile} filename

次のアップロードを指定します：

- httpscrt が指定されている場合の HTTPS 証明書。

- httpskey が指定されている場合の HTTPS キー。

HTTPS 証明書の例：

nxapi certificate httpscrt certfile bootflash:cert.crt

HTTPS キーの例：

nxapi certificate httpskey keyfile bootflash:privkey.key

nxapi certificate enable

証明書を有効化します。

nxapi certificate sudi

この CLI は、Secure Unique Device Identifier（SUDI）を使用してデバイスを安全に認証する方法を提供します。

nginx の SUDI ベースの認証は、CISCO SUDI 準拠のコントローラによって使用されます。

SUDI は、X.509v3 証明書に含まれる IEEE 802.1AR 準拠のセキュア デバイス識別子で、Cisco デバイスの製品識別子とシリアル番号を維持します。ID は製造時に実装され、公的に識別可能なルート認証局につながれます。

（注）

NX-API が SUDI 証明書を使用している場合、ブラウザ、curl などのサードパーティ アプリケーションからはアクセスできません。

（注）

「nxapi certificate sudi」は、構成されるとカスタム証明書/キーを上書きします。カスタム証明書/キーを元に戻す方法はありません。

（注）

「nxapi certificate sudi」と「nxapi certificate trustpoint」と「nxapi certificate enable」は排他的であり、いずれかを構成すると他の構成は削除されます。

（注）

NX-API は、SUDI 証明書ベースのクライアント証明書認証をサポートしていません。クライアント証明書認証が必要な場合は、アイデンティティ証明書を使用する必要があります。

（注）

NX-API 証明書 CLI は show run の出力に存在しないため、現在の CR/ロールバックでは、「nxapi certificate sudi」オプションで上書きした場合、カスタム証明書に戻せません。

nxapi use-vrf vrf

デフォルト VRF、管理 VRF、または名前付き VRF を指定します。

（注）

Cisco NX-OS リリース 7.0(3)I2(1) では、NGINX は 1 つの VRF でのみリッスンします。

ip netns exec management iptables

アクセス制限を実装したうえで、管理 VRF で実行できます。

（注）

feature bash-shell を有効にしてから、Bash シェルからコマンドを実行する必要があります。Bash シェルの詳細については、Bash の章を参照してください。

Iptables は、ポリシー チェーンを使用してトラフィックを許可または阻止するコマンドライン ファイアウォール ユーティリティであり、ほとんどの Linux ディストリビューションにプリインストールされています。

（注）

iptables を bash シェルで変更した後、リロード後も iptables を永続化する方法の詳細については、リロード間で Iptable を永続化するを参照してください。

以下は、HTTPS 証明書の正常なアップロードの例です：

switch(config)# nxapi certificate httpscrt certfile certificate.crt
Upload done. Please enable. Note cert and key must match.
switch(config)# nxapi certificate enable
switch(config)#

（注）

証明書を有効にする前に、証明書とキーを構成する必要があります。

以下は、HTTPS キーの正常なアップロードの例です：

switch(config)# nxapi certificate httpskey keyfile bootflash:privkey.key
Upload done. Please enable. Note cert and key must match.
switch(config)# nxapi certificate enable
switch(config)#

NX-API を使用したインタラクティブ コマンドの操作

対話型コマンドの確認プロンプトを無効にし、エラー コード 500 によるタイムアウトを回避するには、対話型コマンドの前に[端末の dont-ask（terminal dont-ask）] を追加します。 を使用。複数の対話型コマンドを区切るには、それぞれが 。は単一のブランク文字で囲まれています。

エラー コード 500 でのタイムアウトを回避するために端末の dont-ask を使用する対話型コマンドの例をいくつか次に示します：

terminal dont-ask ; reload module 21

terminal dont-ask ; system mode maintenance

NX-API リクエスト要素

NX-API リクエスト要素は、XML フォーマットまたは JSON フォーマットでデバイスに送信されます。リクエストの HTTP ヘッダーは、リクエストのコンテンツ タイプを識別する必要があります。

次の表にリストされている NX-API 要素を使用して、CLI コマンドを指定します。

（注）

ユーザーには、「configure terminal」コマンドを実行する権限が必要です。JSON-RPC が入力リクエスト フォーマットの場合、「configure terminal」コマンドは、常に、ペイロード内のコマンドが実行される前に実行されます。

XML または JSON フォーマットの NX-API リクエスト要素

NX-API リクエスト要素

説明

version

NX-API バージョンを指定します。

type

実行するコマンドのタイプを指定します。

次のタイプのコマンドがサポートされています。

- cli_show

構造化された出力が必要な CLI show コマンド。コマンドが XML 出力をサポートしていない場合は、エラー メッセージが返されます。

- cli_show_array

構造化された出力が必要な CLI show コマンド。show コマンド専用です。cli_show に似ていますが、cli_show_array を使用すると、データは角括弧（[ ]）で囲まれた 1 つの要素のリスト、つまり配列として返されます。

- cli_show_ascii

ASCII 出力が必要な CLI show コマンド。これは、ASCII 出力を解析する既存のスクリプトと一致します。ユーザーは、最小限の変更で既存のスクリプトを使用できます。

- cli_conf

CLI 構成コマンド

- bash

Bash コマンド。ほとんどの非対話型 Bash コマンドは、NX-API でサポートされています。

（注）

- 各コマンドは、現在のユーザーの権限でのみ実行可能です。

- メッセージ タイプが ASCII の場合、出力でパイプ操作がサポートされます。出力が XML 形式の場合、パイプ操作はサポートされていません。

- 最大 10 の連続する show コマンドがサポートされています。show コマンドの数が 10 を超える場合、11 番目以降のコマンドは無視されます。

- 対話型コマンドはサポートされていません。

チャンク

一部の show コマンドは、大量の出力を返す場合があります。コマンド全体が完了する前に NX-API クライアントが出力の処理を開始するために、NX-API は show コマンドの出力チャンクをサポートしています。

次の設定を有効または無効にできます。

（注）

0

チャンク出力しません。

1

チャンク出力。

（注）

- チャンクをサポートするのは show コマンドだけです。一連の show コマンドが入力されると、最初のコマンドだけがチャンクされて返されます。

- XML 出力メッセージ形式の場合（XML がデフォルトです。）< または > などの特殊文字は、有効な XML メッセージを形成するために変換されます（< は < に変換されます > は &gt に変換されます）。

XML SAX を使用して、チャンクされた出力を解析できます。

（注）

チャンクが有効な場合、メッセージ形式は XML に制限されます。チャンクが有効な場合、JSON 出力形式はサポートされません。

ロールバック

構成 CLI に対してのみ有効であり、show コマンドに対しては有効ではありません。構成ロールバック オプションを指定します。次のいずれかのオプションを指定します。

- Stop-on-error：最初に失敗した CLI で停止します。

- Continue-on-error：エラーを無視して他の CLI を続行します。

- Rollback-on-error：システム構成を以前の状態にロールバックします。

（注）

入力リクエスト フォーマットが XML または JSON の場合、ロールバック要素は cli_conf モードで使用できます。

sid

セッション ID 要素は、応答メッセージがチャンクされている場合にのみ有効です。メッセージの次のチャンクを取得するには、前の応答メッセージの sid と一致する sid を指定する必要があります。

input

入力は 1 つのコマンドまたは複数のコマンドです。ただし、異なるメッセージ タイプに属するコマンドを混在させてはなりません。たとえば、show コマンドは cli_show メッセージ タイプであり、cli_conf モードではサポートされません。

（注）

bash を除き、複数のコマンドは「;」で区切ります。（; は、単一のブランク文字で囲む必要があります。）

エラーコード 500 でタイムアウトしないように、コマンドの前に terminal dont-ask を付加します。次に例を示します。

terminal dont-ask ; cli_conf ; interface Eth4/1 ; no shut ; switchport

bash の場合、複数のコマンドは「;」で区切ります。（; は単一のブランク文字で囲まれていません。）

以下は、複数のコマンドの例です。

（注）

cli_show

show version ; show interface brief ; show vlan

cli_conf

interface Eth4/1 ; no shut ; switchport

bash

cd /bootflash;mkdir new_dir

output_format

使用可能な出力メッセージ形式は次のとおりです。

（注）

xml

XML 形式を指定します。

json

JSON 形式で出力を指定します。

（注）

Cisco NX-OS CLI は XML 出力をサポートしています。つまり、JSON 出力は XML から変換されます。変換はスイッチで処理されます。

計算のオーバーヘッドを管理するために、JSON 出力は出力の量によって決定されます。出力が 1 MB を超える場合、出力は XML 形式で返されます。出力がチャンクされている場合、XML 出力のみがサポートされます。

HTTP/HTTPS ヘッダーの content-type ヘッダーは、応答形式（XML または JSON）のタイプを示します。

JSON-RPC が入力リクエスト形式である場合、次の表にリストされている NX-API 要素を使用して、CLI コマンドを指定します。

JSON-RPC フォーマットの NX-API リクエスト要素

NX-API リクエスト要素

説明

jsonrpc

JSON-RPC プロトコルのバージョンを指定する文字列。

バージョンは 2.0 であることが必要です。

method

呼び出されるメソッドの名前を含む文字列。

NX-API は、次のいずれかをサポートします。

- cli：show または構成コマンド

- cli_ascii：show または構成コマンド。フォーマットせずに出力

- cli_array：show コマンド専用。cli に似ていますが、cli_array はデータを角括弧（[ ]）で囲まれた 1 つの要素のリスト、つまり配列として返します。

params

メソッドの呼び出し中に使用されるパラメータ値を保持する構造化された値。

以下が含まれている必要があります。

- cmd：CLI コマンド

- version：NX-API リクエストのバージョン識別子

ロールバック

構成 CLI に対してのみ有効であり、show コマンドに対しては有効ではありません。構成ロールバック オプション次のいずれかのオプションを指定できます。

- Stop-on-error：最初に失敗した CLI で停止します。

- Continue-on-error：失敗した CLI を無視して他の CLI を続行します。

- Rollback-on-error：システム構成を以前の状態にロールバックします。

id

クライアントによって確立されるオプションの識別子。指定されている場合は、文字列、数値、または null 値を含む必要があります。値は null にならないはずです。数値には小数部を含めません。ユーザーが id パラメータを指定しなかった場合、サーバーはリクエストが単なる通知であるとみなし、応答はしません。パラメータはid: 1 などのように指定します。

NX-API 応答要素

CLI コマンドに応答する NX-API 要素を次の表に示します。

NX-API 応答要素

NX-API 応答要素

説明

version

NX-API バージョン。

type

実行するコマンドのタイプ。

sid

応答のセッション識別子。この要素は、応答メッセージがチャンクされている場合にのみ有効です。

outputs

すべてのコマンド出力を囲むタグ。

複数のコマンドが cli_show または cli_show_ascii にある場合、各コマンド出力は単一の出力タグで囲まれます。

メッセージ タイプが cli_conf または bash の場合、cli_conf および bash コマンドにはコンテキストが必要なため、すべてのコマンドに単一の出力タグがあります。

出力

単一のコマンド出力の出力を囲むタグ。

cli_conf と bash メッセージ タイプの場合、この要素にはすべてのコマンドの出力が含まれます。

input

リクエストで指定された 1 つのコマンドを囲むタグ。この要素は、要求入力要素を適切な応答出力要素に関連付けるのに役立ちます。

本文

コマンド応答の本文。

コード

コマンドの実行から返された原因コード。

NX-API は、ハイパーテキスト転送プロトコル（HTTP）ステータス コード レジストリ（http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml）で説明されている標準規格の HTTP原因コードを使用します。

msg

返された原因コードに関連付けられたエラー メッセージ。

NX-API へのアクセスの制限

デバイスへの HTTP および HTTPS アクセスを制限するには、ACL と iptable の 2 つの方法があります。使用する方法は、nxapi use-vrf<vrf-name> CLI コマンドを使用して、NX-API 通信の VRF を構成していたかどうかに応じて決まります。

特定の VRF を使用するように NXAPI を構成していない場合にのみ、ACL を使用してデバイスへの HTTP または HTTPS アクセスを制限します。ACL の構成の詳細については、使用しているスイッチ ファミリの Cisco Nexus シリーズ NX-OS セキュリティ構成ガイドを参照してください。

ただし、NX-API 通信用に VRF を設定した場合、ACL は HTTP または HTTPS アクセスを制限しません。代わりに、iptable のルールを作成します。ルールの作成の詳細については、iptable の更新を参照してください。

- iptable の更新

- リロード間で Iptable を永続化する

iptable の更新

iptable を使用すると、VRF が NX-API 通信用に構成されている場合に、デバイスへの HTTP または HTTPS アクセスを制限できます。このセクションでは、既存の iptable に HTTP および HTTPS アクセスをブロックするルールを追加、確認、削除する方法を示します。

手順

ステップ 1

HTTP アクセスをブロックするルールを作成するには、次の手順を実行します。

bash-4.3# ip netns exec management iptables -A INPUT -p tcp  --dport 80 -j DROP

ステップ 2

HTTPS アクセスをブロックするルールを作成するには、次の手順を実行します。

bash-4.3# ip netns exec management iptables -A INPUT -p tcp  --dport 443 -j DROP

ステップ 3

適用されたルールを確認するには、次の手順を実行します。

bash-4.3# ip netns exec management iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  anywhere             anywhere             tcp dpt:http
DROP       tcp  --  anywhere             anywhere             tcp dpt:https

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

ステップ 4

10.155.0.0/24 サブネットのポート 80 へのすべてのトラフィックをブロックするルールを作成して確認するには、次の手順を実行します。

bash-4.3# ip netns exec management iptables -A INPUT -s 10.155.0.0/24 -p tcp --dport 80 -j DROP
bash-4.3# ip netns exec management iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  10.155.0.0/24        anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

ステップ 5

以前に適用したルールを削除して確認するには、次の手順を実行します。

この例では、最初のルールを INPUT から削除します。

bash-4.3# ip netns exec management iptables -D INPUT 1
bash-4.3# ip netns exec management iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

次のタスク

iptables のルールを bash シェルで変更した場合、リロード後は保持されません。ルールを永続的にするには、リロード間で Iptable を永続化するを参照してください。

リロード間で Iptable を永続化する

iptable のルールを bash シェルで変更した場合、リロード後は保持されません。このセクションでは、リロード後も変更された iptable を永続化する方法について説明します。

始める前に

iptable を変更したとします。

手順

ステップ 1

iptables_init.log という名前のファイルを /etc ディレクトリに作成します。

bash-4.3# touch /etc/iptables_init.log; chmod 777 /etc/iptables_init.log

ステップ 2

iptable の変更を保存する /etc/sys/iptables ファイルを作成します。

bash-4.3# ip netns exec management iptables-save > /etc/sysconfig/iptables

ステップ 3

次の一連のコマンドを使用して、/etc/init.d ディレクトリに「iptables_init」という起動スクリプトを作成します。

#!/bin/sh
### BEGIN INIT INFO
# Provides:          iptables_init
# Required-Start:
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: init for iptables
# Description:       sets config for iptables
#                    during boot time
### END INIT INFO

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
start_script() {
ip netns exec management iptables-restore < /etc/sysconfig/iptables
ip netns exec management iptables
echo "iptables init script executed" > /etc/iptables_init.log
}
case "$1" in
start)
start_script
;;
stop)
;;
restart)
sleep 1
$0 start
;;
*)
echo "Usage: $0 {start|stop|status|restart}"
exit 1
esac
exit 0

ステップ 4

起動スクリプトに適切な権限を設定します。

bash-4.3# chmod 777 /etc/init.d/iptables_int

ステップ 5

chkconfig ユーティリティを使用して、「iptables_int」起動スクリプトを「オン」に設定します。

bash-4.3# chkconfig iptables_init on

「iptables_init」起動スクリプトは、リロードを実行するたびに実行されます。これで iptable ルールを永続的にすることができました。

NX-API 応答コードの表

次に、NX-API 応答の考えられる NX-API エラー、エラー コード、およびメッセージを示します。

（注）

標準の HTTP エラー コードは、ハイパーテキスト転送プロトコル (HTTP) ステータス コード レジストリ (http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml) にあります。

NX-API 応答コード

[NX-API 応答（NX-API Response）]

コード

メッセージ

成功

200

成功。

CUST_OUTPUT_PIPED

204

要求により、出力は別の場所にパイプされます。

BASH_CMD_ERR

400

Bash コマンド エラー

CHUNK_ALLOW_ONE_CMD_ERR

400

チャンクは、1 つのコマンドだけを受け入れます。

CLI_CLIENT_ERR

400

CLI の実行エラー

CLI_CMD_ERR

400

CLI コマンド エラーの入力。

IN_MSG_ERR

400

着信メッセージが無効です。

NO_INPUT_CMD_ERR

400

入力コマンドがありません。

PERM_DENY_ERR

401

権限が拒否されました。

CONF_NOT_ALLOW_SHOW_ERR

405

構成モードは [表示（show）] を許可しません。

SHOW_NOT_ALLOW_CONF_ERR

405

表示モードでは構成できません。

EXCEED_MAX_SHOW_ERR

413

連続する show コマンドの最大数を超えました。最大値は 10 です。

MSG_SIZE_LARGE_ERR

413

応答サイズが大きすぎます。

BACKEND_ERR

500

バックエンド処理エラー。

FILE_OPER_ERR

500

システム内部ファイル操作エラー。

LIBXML_NS_ERR

500

システムの内部 LIBXML NS エラー。これは要求フォーマットのエラーです。

LIBXML_PARSE_ERR

500

システムの内部 LIBXML 解析エラー。これは要求フォーマットのエラーです。

LIBXML_PATH_CTX_ERR

500

システムの内部 LIBXML パス コンテキスト エラー。これは要求フォーマットのエラーです。

MEM_ALLOC_ERR

500

システムの内部メモリ割り当てエラー。

USER_NOT_FOUND_ERR

500

入力またはキャッシュからユーザーが見つかりません。

XML_TO_JSON_CONVERT_ERR

500

XML から JSON への変換エラー。

BASH_CMD_NOT_SUPPORTED_ERR

501

Bash コマンドはサポートされていません。

CHUNK_ALLOW_XML_ONLY_ERR

501

チャンクは XML 出力のみを許可します。

JSON_NOT_SUPPORTED_ERR

501

大量の出力の可能性があるため、JSON はサポートされていません。

MSG_TYPE_UNSUPPORTED_ERR

501

メッセージ タイプはサポートされていません

PIPE_XML_NOT_ALLOWED_IN_INPUT

501

このコマンドへのパイプ XML は入力では許可されていません。

STRUCT_NOT_SUPPORTED_ERR

501

構造化出力はサポートされていません。

ERR_UNDEFINED

600

不明なエラー。

Chapter18. NX-API REST

- 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 コマンドをスイッチの外部から実行可能です。

- 多数の CLI コマンドを発行する必要がある構成を、比較的少数の HTTP/HTTPS 操作の構成アクションを組み合わせることで実現します。

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

NX-API REST は HTTP/HTTPS をトランスポートとして使用します。CLI は、HTTP / HTTPS POST 本文にエンコードされます。NX-API REST バックエンドは Nginx HTTP サーバーを使用します。Nginx プロセスとそのすべての子プロセスは、CPU とメモリの使用量の上限が定められている Linux cgroup の保護下に置かれます。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/ を参照してください。

注意事項と制約事項

NX-API REST には、次の注意事項と制限事項があります。

- NX-OS 7.0（3）F3（1）以降、NX-API REST は Cisco Nexus 9508 スイッチでサポートされます。

Chapter19. NX-API 開発者サンドボックス

- About the NX-API デベロッパー サンドボックス

- デベロッパー サンドボックスの注意事項と制約事項

- メッセージ フォーマットとコマンド タイプの構成

- デベロッパー サンドボックスを使用して CLI コマンドを REST ペイロードに変換する

- デベロッパー サンドボックスを使用した REST ペイロードから CLI コマンドへの変換

About the NX-API デベロッパー サンドボックス

NX-API Developer Sandbox は、スイッチでホストされる Web フォームです。NX-OS CLI コマンドを同等の XML または JSON ペイロードに変換し、NX-API REST ペイロードを同等の CLI に変換します。

図に示すように、Web フォームは 3 つのペイン（コマンド（上部ペイン）、要求、および応答）を持つ 1 つの画面です。

リクエストと出力応答の例を含む NX-API デベロッパー サンドボックス

コマンド ペインのコントロールを使用すると、サポートされている API のメッセージフォーマット（NX-API REST など）とコマンド タイプ（XML や JSON など）を選択できます。使用可能なコマンド タイプ オプションは、選択したメッセージ フォーマットによって異なります。

コマンド ペインに 1 つ以上の CLI コマンドを入力するか貼り付けると、Web フォームはコマンドを API ペイロードに変換し、構成エラーをチェックし、結果のペイロードを要求ペインに表示します。次に、コマンド ペインの POST ボタンを使用して、ペイロードをサンドボックスからスイッチに直接送信することを選択した場合、応答ペインに API 応答が表示されます。

逆に、コマンド ペインに NX-API REST 指定名 (DN) とペイロードを入力し、nx-api rest メッセージ フォーマットと[モデル（model）] コマンド タイプを選択すると、デベロッパー サンドボックスはペイロードの構成エラーをチェックし、応答ペインに同等の CLI が表示されます。

デベロッパー サンドボックスの注意事項と制約事項

- サンドボックスで POST をクリックすると、コマンドがスイッチにコミットされ、構成または状態が変更される可能性があります。

- 一部の機能構成コマンドは、関連する機能が有効になるまで使用できません。

メッセージ フォーマットとコマンド タイプの構成

[メッセージ フォーマット（Message Format）]と[コマンド タイプ（Command Type）]は、コマンド ペイン（上部ペイン）の右上隅で構成されます。[メッセージ フォーマット（Message Format）] で、使用する API プロトコルのフォーマットを選択します。開発者サンドボックスは、次の API プロトコルをサポートしています。

NX-OS API プロトコル

プロトコル

説明

json-rpc

JSON ペイロードで NX-OS CLI コマンドを配信するために使用できる標準の軽量リモート プロシージャ コール（RPC）プロトコル。JSON-RPC 2.0 仕様は、jsonrpc.org によって概説されています。

xml

XML ペイロードで NX-OS CLI または bash コマンドを配信するための Cisco NX-API 独自のプロトコル。

json

JSON ペイロードで NX-OS CLI または bash コマンドを配信するための Cisco NX-API 独自のプロトコル。

nx-api rest

内部 NX-OS データ管理エンジン（DME）モデルで管理対象オブジェクト（MO）とそのプロパティを操作および読み取るための Cisco NX-API 独自のプロトコル。Cisco Nexus 3000 および 9000 シリーズ NX-API REST SDK の詳細については、https://developer.cisco.com/site/cisco-nexus-nx-api-references/ を参照してください。

nx yang

構成および状態データ用の YANG（「Yet Another Next Generation」）データ モデリング言語。

[メッセージ フォーマット（Message Format）] を選択すると、[コマンド タイプ（Command Type）] オプションのセットが[メッセージ フォーマット（Message Format）] コントロールのすぐ下に表示されます。[コマンド タイプ（Command Type）] の設定は、入力 CLI を制限でき、[要求（Request）]と[応答（Response）]のフォーマットを決定できます。オプションは、選択した[メッセージ フォーマット（Message Format）] によって異なります。各[メッセージ フォーマット（Message Format）] について、次の表で [コマンド タイプ（Command Type）] オプションについて説明します。

コマンド タイプ

メッセージ形式

コマンド タイプ

json-rpc

- cli — show または構成コマンド

- cli_ascii — show または構成コマンド、フォーマットせずに出力

xml

- cli_show — コマンドを表示します。コマンドが XML 出力をサポートしていない場合、エラー メッセージが返されます。

- cli_show_ascii — コマンドを表示、フォーマットせずに出力

- cli_conf — 構成 コマンド。対話型の構成コマンドはサポートされていません。

- bash — bash コマンド。ほとんどの非対話型 bash コマンドがサポートされています。

（注）

スイッチで bash シェルを有効にする必要があります。

json

- cli_show — コマンドを表示します。コマンドが XML 出力をサポートしていない場合、エラー メッセージが返されます。

- cli_show_ascii — コマンドを表示、フォーマットせずに出力

- cli_conf — 構成 コマンド。対話型の構成コマンドはサポートされていません。

- bash — bash コマンド。ほとんどの非対話型 bash コマンドがサポートされています。

（注）

スイッチで bash シェルを有効にする必要があります。

nx-api rest

- cli — 構成コマンド

- モデル — DN および対応するペイロード。

nx yang

- json — ペイロードに JSON 構造が使用されます

- xml — XML 構造がペイロードに使用されます

出力チャンク

大量の show コマンド出力を処理するために、一部の NX-API メッセージ フォーマットでは、show コマンドの出力チャンクがサポートされています。この場合、[チャンク モードを有効にする（Enable chunk mode）]チェックボックスが、セッション ID (SID ) 入力ボックスとともに[コマンド タイプ（Command Type）] コントロールの下に表示されます。

チャンクが有効な場合、応答は複数の「チャンク」で送信され、最初のチャンクが即時のコマンド応答で送信されます。応答メッセージの次のチャンクを取得するには、前の応答メッセージのセッション ID に設定された SID を使用して NX-API 要求を送信する必要があります。

デベロッパー サンドボックスを使用して CLI コマンドを REST ペイロードに変換する

ヒント

オンライン ヘルプは、サンドボックス ウィンドウの右上隅にある [クイック スタート（Quick Start）] をクリックすると利用できます。

レスポンス コードやセキュリティ メソッドなどの詳細については、「NX-API CLI」の章を参照してください。

構成コマンドはサポートされていません。

手順

ステップ 1

使用する API プロトコルの[メッセージ形式（Message Format）]と[コマンド タイプ（Command Type）]を構成します。

詳細な手順については、メッセージ フォーマットとコマンド タイプの構成を参照してください。

ステップ 2

上部ペインのテキスト エントリ ボックスに、NX-OS CLI 構成コマンドを 1 行に 1 つずつ入力するか貼り付けます。

上部ペインの下部にある [リセット（Reset）] をクリックすると、テキスト エントリ ボックス (および [要求（Request）] ペインと [応答（Response）] ペイン) の内容を消去できます。

ステップ 3

トップ ペインの最下部にある [変換（Convert）] をクリックします。

CLI コマンドに構成エラーが含まれていない場合、ペイロードは [要求（Request）] ペインに表示されます。エラーが存在する場合は、説明のエラー メッセージが [応答（Response）] ペインに表示されます。

ステップ 4

[リクエスト（Request）] ペインに有効なペイロードが表示されている場合は、POST をクリックして、ペイロードを API 呼び出しとしてスイッチに送信できます。

スイッチからのレスポンスは [Response（応答）] ペインに表示されます。

警告

POST をクリックすると、コマンドがスイッチにコミットされ、構成または状態が変更される可能性があります。

ステップ 5

ペインで [コピー（Copy）] をクリックすると、[要求（Request）] ペインまたは [応答（Response）] ペインの格納ファイルをクリップボードにコピーできます。

ステップ 6

[リクエスト（Request）] ペインで Python をクリックすると、クリップボード上のリクエストの Python 導入を取得できます。

デベロッパー サンドボックスを使用した REST ペイロードから CLI コマンドへの変換

ヒント

オンライン ヘルプは、サンドボックス ウィンドウの右上隅にある [クイック スタート（Quick Start）] をクリックすると利用できます。

レスポンス コードやセキュリティ メソッドなどの詳細については、「NX-API CLI」の章を参照してください。

手順

ステップ 1

メッセージ フォーマットとして nx-api rest を選択し、コマンド タイプとして model を選択します。

例:

ステップ 2

上部ペインのテキスト入力ボックスに DN とペイロードを入力します。次に、上部ペインの下にある [変換（Convert）] ボタンをクリックします。

例:

この例では、DN は /api/mo/sys.json であり、NX-API REST ペイロードは次のとおりです：

{
"topSystem": {
"attributes": {
"name": "REST2CLI"
}
}
}

[変換（Convert）] ボタンをクリックすると、次の図に示すように、同等の CLI が CLI ペインに表示されます。

（注）

デベロッパー サンドボックスは、サンドボックスが CLI を NX-API REST ペイロードに変換した場合でも、すべてのペイロードを同等の CLI に変換することはできません。以下は、ペイロードが CLI コマンドに完全に変換するのを妨げる可能性のあるエラーの原因のリストです。

REST2CLI エラーの原因

ペイロードの問題

結果

ペイロードに、MO に存在しない属性が含まれています。

例：

api/mo/sys.json
{
"topSystem": {
"children": [
{
"interfaceEntity": {
"children": [
{
"l1PhysIf": {
"attributes": {
"id": "eth1/1",
"fakeattribute": "totallyFake"
}
}
}
]
}
}
]
}
}

[エラー（Error）] ペインは、属性に関連するエラーを返します。

例：

CLI

要素「l1PhysIf」の不明な属性「fakeattribute」の[エラー（Error）]

ペイロードには、変換がまだサポートされていない MO が含まれています。

例：

api/mo/sys.json
{
"topSystem": {
"children": [
{
"dhcpEntity": {
"children": [
{
"dhcpInst": {
"attributes": {
"SnoopingEnabled": "yes"
}
}
}
]
}
}
]
}
}

[エラー（Error）] ペインは、サポートされていない MO に関連するエラーを返します。

例：

CLI

[エラー（Error）] [「sys/dhcp」のサブツリー全体が変換されていません。（The entire subtree of "sys/dhcp" is not converted.）]

PartIV. モデル駆動型プログラマビリティ

- インフラストラクチャの概要

- コンポーネント管理

- NETCONF エージェント

- CLI コマンドのネットワーク構成フォーマットへの変換

- RESTConf エージェント

- gRPC エージェント

- ダイナミック ロガー

- モデル駆動型テレメトリ

Chapter20. インフラストラクチャの概要

- モデル駆動型プログラマビリティについて

- プログラム可能なインターフェイス インフラストラクチャについて

モデル駆動型プログラマビリティについて

NX-OS デバイスのモデル駆動型プログラマビリティにより、デバイスの構成と制御を自動化できます。

データモデリング

データ モデリングでは、手作業の構成プロセスの代わりに、プログラムを使用した標準ベースの方法でネットワーク デバイスの構成を記述します。データ モデルは、業界で定義された標準言語で記述されます。CLI を使用した設定のほうがわかりやすいですが、データモデルを使用して設定を自動化すると拡張性が向上します。

Cisco NX-OS デバイスは YANG データ モデリング言語をサポートしています。YANG は、ネットワーク デバイスの構成データと運用データ、リモート プロシージャ呼び出し、および通知を記述するために用いられるデータ モデリング 言語です。

プログラム可能なインターフェイス

NX-OS では、データ モデルでの操作のために 3 つの標準ベースのプログラマブル インターフェイス（NETCONF、RESTConf、および gRPC）がサポートされています。

プログラム可能なインターフェイス インフラストラクチャについて

ここでは、NX-OS プログラマブル インターフェイス インフラストラクチャの概要について説明します。

NETCONF、RESTConf または、 gRPC 経由でのいずれかの方法で受信されても要求は、抽象メッセージ オブジェクトに変換されます。そのメッセージオブジェクトは、要求内の名前空間に基づいて基盤となるモデルインフラストラクチャに配布されます。名前空間を使用すると、適切なモデルが選択され、要求は処理のために渡されます。モデルインフラストラクチャは、デバイスデータストアで要求（読み取りまたは書き込み）を実行します。結果は要求元のエージェントに返され、要求元のクライアントに応答が送信されます。

NX-OS プログラマブル インターフェイス エージェント

エージェントは、デバイスとクライアント間のインターフェイスを提供します。デバイスとの通信のトランスポート、プロトコル、およびエンコーディングを指定します。NX-OS プログラマブル インターフェイスは、NETCONF、RESTConf、および gRPC の 3 つのエージェントをサポートします。それぞれが YANG モデルを介してデバイスの構成管理に異なるインターフェイスを提供します。

（注）

各 Cisco NX-OS リリースでサポートされている YANG モデルについては、https://devhub.cisco.com/artifactory/open-nxos-agents を参照してください。

NX-OS プログラマブル インターフェイス エージェント

Agent

トランスポート

Protocol

エンコーディング

NETCONF

SSH

XML

RESTConf

HTTP

draft-ietf-netconf-restconf-10[1

XML または JSON

gRPC

HTTP

gRPC Protocol Spec[2]

Google Protobuf

プロトコルの仕様については、次のドキュメントを参照してください。

- [1] RESTCONF Protocol draft-ietf-netconf-restconf-10 https://tools.ietf.org/html/draft-ietf-netconf-restconf-10

- [2] Cisco NX-OS gRPC Protocol Specification

モデル インフラストラクチャ

モデル インフラストラクチャは、エージェントから受信した要求を受け取り、要求内の YANG モデルに関連付けられている名前空間を決定し、名前空間に一致するモデル コンポーネントを選択して要求を処理します。選択したモデル コンポーネントが要求処理を完了すると、処理結果が要求元のエージェントに送信され、クライアントに送り返されます。モデル インフラストラクチャは、エージェント プロトコルの指定に従って、認証、ハンドシェイクなどを含むプロトコル開始要求の処理も行います。

デバイス YANG モデル

デバイス構成は、デバイスモデルと呼ばれる YANG モデルで記述されます。デバイス モデルは、デバイス名前空間を持つ別のモデル コンポーネントとしてモデル インフラストラクチャに明示されます。

共通 YANG モデル

共通モデルは、同等のデバイスモデル要素への YANG パスを要素内に含む、別の種類のモデル コンポーネントです。これら同等のデバイス モデル要素は、デバイス YANG コンテキストでデバイス モデル データの読み取りと書き込みに使用されます。

その他の YANG 関連資料

YANG の詳細については、YANG Central Wiki https://handwiki.org/wiki/YANG（M. Bjorklund, Ed.）を参照してください。

Chapter21. コンポーネント管理

- コンポーネント RPM パッケージについて

- インストールの準備

- Cisco Artifactory からのコンポーネントのダウンロード

コンポーネント RPM パッケージについて

（注）

Cisco Nexus NX-OS 7.0(3)I7(1)以降、NX-OS プログラマブル インターフェイス ベース コンポーネント RPM パッケージ（エージェント、Cisco ネイティブ モデル、その他の必要なモデルの大部分、およびインフラストラクチャ）が NX- OS イメージに含められています。そのため、イメージがロードされると、必要なソフトウェアのほぼすべてが自動的にインストールされます。これは、Cisco Artifactory から大量のソフトウェアをダウンロードしてインストールする必要がないことを意味します。例外は、必須の OpenConfig モデルです。Cisco Artifactory から OpenConfig モデルを明示的にダウンロードする必要があります。

ただし、Cisco Nexus NX-OS 7.0(3)I6(1) 以前のリリースの場合、またはアップグレードする場合は、次のセクションで説明している、パッケージのダウンロードとインストールが必要です。

NX-OS プログラマブル インターフェイス コンポーネント RPM パッケージは、Cisco Artifactory からダウンロードできます。次の 3 種類のコンポーネント RPM パッケージが必要です。

- NX-OS プログラマブル インターフェイス インフラストラクチャ コンポーネント

- 共通モデル コンポーネント

- エージェント コンポーネント

NX-OS プログラマブル インターフェイス インフラストラクチャ コンポーネント

NX-OS プログラマブル インターフェイス インフラストラクチャは、次の 2 つの RPM パッケージで構成されています：

- mtx-infra：この RPM はプラットフォームに依存しません。

- mtx-device-model：この RPM はプラットフォームに依存しますします。そして、Cisco Artifactory のダウンロード時にインストールされている NX-OS イメージと一致するように選択する必要があります。

共通モデル コンポーネント

共通モデル コンポーネント RPM は、Openconfig および IETF 定義モデルのサポートを提供します。必要な 1 つ以上の共通モデルのサポートを有効にするには、関連する共通モデル コンポーネント RPM をダウンロードしてインストールする必要があります。mtx-device-model RPM と同様に、共通モデルコンポーネントもプラットフォームに依存します。そのため、Cisco Artifactory のダウンロード時に、インストールされている NX-OS イメージと一致するように選択する必要があります。

次に、サポートされている RPM のリストを示します。

- mtx-openconfig-bgp

- mtx-openconfig-bgp-multiprotocol

- mtx-openconfig-if-ip

- mtx-openconfig-interfaces

- mtx-openconfig-local-routing

- mtx-openconfig-routing-policy

- mtx-openconfig-vlan

エージェント コンポーネント

NETCONF、RESTConf、gRPC の 3 つのエージェントパッケージを使用できます。モデル化された NX-OS インターフェイスにアクセスするには、少なくとも 1 つのエージェントをインストールする必要があります。

（注）

Cisco Nexus NX-OS 7.0（3）I7（3）以降では、feature netconf コマンドと feature restconf コマンドを使用してエージェントを有効にできます。ただし、これらのコマンドは以前のリリースには含まれていないため、Cisco Nexus NX-OS 7.0(3)I7(1) から 7.0(3)I7(3) のリリースでは、インストールの準備の「デバイス上の bash シェルを開く」セクションの指示に従って bash シェルに入ってから、netconfctl start および restconfctl start コマンドを実行する必要があります。

インストールの準備

ここでは、インストールの準備と、NX-OS プログラマブル インターフェイス コンポーネントを管理するためのその他の有用な情報について説明します。

デバイスで Bash シェルを開く

スイッチへの RPM のインストールは、bash シェルで実行されます。デバイスで [機能 bash（feature bash）] が構成されていることを確認します。

Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# feature bash-shell
Switch(config)# end
Switch# run bash sudo su
bash-4.2#

bash からデバイスの CLI プロンプトに戻るには、exit または Ctrl-D を入力します。

デバイスの準備状況の確認

RPM をインストールする前に、次の CLI show コマンドを使用してデバイスの準備状況を確認できます。

- show module：すべてのモジュールが稼働しているかどうかを示します。

Switch# show module

- show system redundancy status：スタンバイ デバイスが稼働しており、HA モードになっているかどうかを示します。スタンバイ同期が進行中の場合、RPM のインストールが失敗する可能性があります。

Switch# show system redundancy status

ライン カードが起動しない場合は、bash シェルで createrepo /rpms コマンドを入力します。

bash-4.2# createrepo /rpms

デバイスへのファイルのコピー

SCP を使用すると、次の形式のコマンドを使用してファイルをデバイスにコピーできます。

copy scp://username@source_ip/path_to_agent_rpm bootflash: vrf management
例:

Switch# copy scp://jdoe@192.0.20.123//myrpms/mtx-infra.1.0.0.r082616.x86_64.rpm bootflash: vrf management

インストールされている NX-OS プログラマブル インターフェイス RPM の表示

インストールされているすべての NXOS プログラマブル インターフェイス RPM を表示するには、デバイスで次のコマンドを実行します。

bash-4.2# yum list installed | grep mtx

Cisco Artifactory からのコンポーネントのダウンロード

NX-OS プログラマブル インターフェイス コンポーネント RPM は、次の URL の Cisco Artifactory からダウンロードできます：

https://devhub.cisco.com/artifactory/open-nxos-agents

NX-OS プログラマブル インターフェイス コンポーネント RPM は、次の命名規則に従っています：

mtx-name.ma.mi.ma.rYYYYYY.x86_64.rpm

または

mtx-name-XXXX.ma.mi.ma.rYYYYYY.x86_64.rpm

説明：

- name ：MTX コンポーネント名（infra、device-model、openconfig-interface、netconf など）

- ma.mi.ma ：RPM のバージョン番号（major.minor.maintenance）

- XXXX ：NX-OS イメージ ID

- rYYYYYY ：RPM ビルド ID

次のセクションの説明に従って、目的の NX-OS プログラマブル インターフェイス コンポーネント RPM パッケージを選択し、デバイスにインストールするためにローカル サーバーにダウンロードします。

プログラマブル インターフェイス インフラストラクチャ RPM パッケージのインストール

始める前に

- Cisco Artifactory から、次のパッケージをダウンロードします。

- mtx-infra.ma.mi.ma.rYYYYYY.x86_64.rpm（インフラストラクチャ）

- mtx-device-XXXX.ma.mi.ma.rYYYYYY.x86_64.rpm RPM（デバイスモデル）

- デバイスの準備状況の確認 の CLI コマンドを使用して、現用系デバイスとスタンバイ デバイスのすべてのラインカードが稼働していることを確認します。

手順

ステップ 1

ダウンロードした RPM をデバイスにコピーします。

例:

Switch# copy scp://jdoe@192.0.20.123//myrpms/mtx-infra.1.0.0.r082616.x86_64.rpm bootflash: vrf management
Switch# copy scp://jdoe@192.0.20.123//myrpms/mtx-device.1.0.0.r082616.x86_64.rpm bootflash: vrf management

ステップ 2

bash シェルから、MTX インフラ RPM をインストールします。

例:

bash-4.2# cd /bootflash
bash-4.2# yum install mtx-infra.1.0.0.r082616.x86_64.rpm

ステップ 3

bash シェルから、MTX デバイス モデル RPM をインストールします。

例:

bash-4.2# cd /bootflash
bash-4.2# yum install mtx-device.1.0.0.r082616.x86_64.rpm

ステップ 4

bash シェルから、インストールを確認します。

例:

bash-4.2# yum list installed | grep mtx

次のタスク

1 つ以上の共通モデル RPM パッケージをインストールします。

共通モデル RPM パッケージのインストール

始める前に

- プログラマブル インターフェイス インフラストラクチャ RPM パッケージをインストールします。

- Cisco Artifactory から共通モデル RPM パッケージをダウンロードします。

手順

ステップ 1

ダウンロードした共通モデル RPM をデバイスにコピーします。

例:

bash-4.2# copy scp://jdoe@192.0.20.123//myrpms/mtx-openconfig_interfaces.1.0.0.r082616.x86_64.rpm bootflash: vrf management

ステップ 2

bash シェルから、各共通モデル RPM をインストールします。

例:

bash-4.2# cd /bootflash
bash-4.2# yum install mtx-openconfig_interfaces.1.0.0.r082616.x86_64.rpm

ステップ 3

bash シェルから、インストールを確認します。

例:

bash-4.2# yum list installed | grep mtx

次のタスク

1 つ以上の NX-OS プログラマブル インターフェイス エージェント RPM パッケージをインストールします。

RPM エージェント パッケージのインストール

始める前に

- プログラマブル インターフェイス インフラストラクチャ RPM パッケージをインストールします。

- 1 つ以上の共通モデル RPM パッケージをインストールします。

- Cisco Artifactory からエージェント RPM パッケージをダウンロードします。

手順

ステップ 1

ダウンロードしたエージェント RPM をデバイスにコピーします。

例:

bash-4.2# copy scp://jdoe@192.0.20.123//myrpms/myrpms/mtx-netconf.1.0.0.r082616.x86_64.rpm bootflash: vrf management

ステップ 2

bash シェルから、エージェント RPM をインストールします。

例:

bash-4.2# cd /bootflash
bash-4.2# yum install mtx-netconf.1.0.0.r082616.x86_64.rpm

ステップ 3

bash シェルから、インストールを確認します。

例:

bash-4.2# yum list installed | grep mtx

次のタスク

エージェントを構成します。

Chapter22. NETCONF エージェント

- NETCONF エージェントについて

- 注意事項と制約事項

- NETCONF エージェントの構成

- NETCONF エージェントの使用

- NETCONF エージェントのトラブルシューティング

NETCONF エージェントについて

Cisco NX-OS NETCONF エージェントは、クライアント要求とサーバー応答を XML でエンコードされた YANG モデルの形式でセキュアに転送するクライアント側インターフェイスです。

NETCONF エージェントは、候補構成機能をサポートしています。候補構成データストアは、候補構成と、実行構成を変更せずに行った変更を一時的に保持します。候補構成をコミットおよび確認する時にには、候補構成でデバイスをいつアップデートするかを選択できます。

変更を確認しなかった場合、非永続的 NETCONF クライアント セッションを終了した場合、または変更をコミットした後にコミットをキャンセルした場合は、変更を確認しないと、システム タイマーがタイムアウトし、変更がロールバックされます。

永続トークンを使用して確認コミット操作を開始すると、NETCONF クライアント セッションは永続プロセスになります。永続プロセスでは、NETCONF クライアントセッションを終了しても自動ロールバックは呼び出されず、一致する永続トークンがなければ変更をロールバックできません。

Cisco NX-OS NETCONF は、次の構成機能をサポートします：

- 書き込み可能実行機能

urn:ietf:params:netconf:capability:writable-running:1.0

- エラー時ロールバック機能

urn:ietf:params:netconf:capability:rollback-on-error:1.0

- ⁪候補構成機能

urn:ietf:params:netconf:capability:candidate:1.0

- 検証機能

urn:ietf:params:netconf:capability:validate:1.1

- 確認済みコミット機能

urn:ietf:params:netconf:capability:confirmed-commit:1.1

新しいセッションが開始されると、NETCONF エージェントは <hello>メッセージを送信し、その機能をアドバタイズします。次の例では、NETCONF エージェントが <hello> メッセージをクライアントに送信します。

<?xml version="1.0" encoding="UTF-8"?>
<hello>

<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>http://cisco.com/ns/yang/cisco-nx-os-device?revision=2017-04-06&module=cisco-nx-os-device&deviations=cisco-nx-os-device-deviations</capability>
</capabilities>

<session-id>1438752697</session-id>
</hello>

Cisco NX-OS NETCONF エージェントは、次の NETCONF プロトコル操作をサポートしています。

- get

- get-config

- edit-config

- close-session

- kill-session

候補構成は、次の NETCONF プロトコル操作をサポートします。

- <source> または <target> としての候補構成の操作。

- get-config

- edit-config

- copy-config

- ロック

- unlock

- 検証

- <source> または <target> として候補構成を明示的に指定する必要のない候補構成の操作。

- commit

- cancel-commit

- discard-changes

（注）

delete-config 操作は許可されません。

注意事項と制約事項

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

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

- NETCONF では、RPM がポート 830 でインストールされている必要があります。

NETCONF エージェントの構成

NETCONF エージェントは、構成ファイル（/etc/mtx.conf）の [netconf] セクションで、次のオプションの構成パラメータをサポートします。

パラメータ

説明

idle_timeout

（オプション）アイドル状態のクライアント セッションが切断されるまでのタイムアウトを分単位で指定します。

デフォルト値は 5 分です。

値を 0 に設定するとタイムアウトが無効になります。

limit

（オプション）同時クライアント セッションの最大数を指定します。

デフォルト値は 5 セッションです。

指定できる範囲は 1 ～ 10 です。

次に、構成ファイルの [netconf] セクションの例を示します。

[netconf]
mtxadapter=/opt/mtx/lib/libmtxadapternetconf.1.0.1.so
idle_timeout=10
limit=1

変更した構成ファイルを有効にするには、CLI コマンド[no] feature netconf を使用して NETCONF エージェントを再起動し、無効にしてから再度有効にする必要があります。

NETCONF エージェントの使用

一般的なコマンド

NETCONF エージェントは、コマンド [no] feature netconf. で有効または無効にします。

候補構成データストアの初期化

候補構成は、実行構成の内容でのみ初期化できます。候補の構成データストアを初期化するには、candidate をターゲット、running を送信元として、SSH で Copy-Config 要求を送信します。

候補構成での読み取りと書き込みの実行

候補構成から読み取るには、candidateを送信元として、SSH で Get-Config 要求を送信します。

候補構成の内容を書き込むには、candidateを送信元として、SSH で Edit-Config 要求を送信します。

NETCONF 候補構成ワークフロー

候補構成ワークフローは次のとおりです。

- 候補構成ファイルを編集します。

- 候補構成を検証します。

- 実行構成に変更をコミットします。

例：SSH セッション

この例では、SSH クライアントを使用してセッションを開始し、SSH クライアントを使用して Edit-Config および Get 要求を送信します。

client-host % ssh -s admin@172.19.193.152 -p 830 netconf
client-host % ssh -s admin@172.19.193.152 -p 830 netconf
User Access Verification
Password:
<?xml version="1.0" encoding="UTF-8"?>
<hello>
<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>http://cisco.com/ns/yang/cisco-nx-os-device?revision=2017-04-06&module=cisco-nx-os-device&deviations=cisco-nx-os-device-deviations</capability>
</capabilities>
<session-id>1912037714</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>
]]>]]>
#794
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device">
<bgp-items>
<inst-items>
<dom-items>
<Dom-list>
<name>default</name>
<rtrId>2.2.2.2</rtrId>
</Dom-list>
</dom-items>
</inst-items>
</bgp-items>
</System>
</config>
</edit-config>
</rpc>
##

#190
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>

##

#511
<rpc message-id="109"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<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>
</get-config>
</rpc>
##

#996
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="109"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<System>
<bgp-items>
<inst-items>
<dom-items>
<Dom-list>
<name>default</name>
<always>disabled</always>
<bestPathIntvl>300</bestPathIntvl>
<holdIntvl>180</holdIntvl>
<kaIntvl>60</kaIntvl>
<maxAsLimit>0</maxAsLimit>
<pfxPeerTimeout>30</pfxPeerTimeout>
<pfxPeerWaitTime>90</pfxPeerWaitTime>
<reConnIntvl>60</reConnIntvl>
<rtrId>2.2.2.2</rtrId>
</Dom-list>
</dom-items>
</inst-items>
</bgp-items>
</System>
</data>
</rpc-reply>

##

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

- create

- merge

- delete

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

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>]]>]]>

- エラー メッセージ

エラー メッセージ

要求がエラーになった場合、応答ペイロードにはエラーが含まれます。

シスコが定義したエラー

シスコによって定義されているエラーは次のとおりです。

シスコが定義したエラー

説明

unknown-error-cond（不明なエラー条件）

不明なエラーが発生しました。

n-y-i

要求された操作はサポートされていません。（not-yet-implemented、未実装）。

namespace-not-found（名前空間が見つからない）

要求ペイロードでのエラー。

namespace-already-exists（名前空間がすでに存在する）

要求ペイロードでのエラー。

object-not-found（オブジェクトが見つからない）

要求ペイロードでのエラー。

object-not-container（オブジェクトはコンテナではない）

要求ペイロードでのエラー。

object-not-property（オブジェクトはプロパティではない）

要求ペイロードでのエラー。

no-property-in-object（オブジェクトにプロパティがない）

要求ペイロードでのエラー。

invalid-dn（無効な dn）

内部エラーが発生しました。

invalid-arg（無効な引数）

内部エラーが発生しました。

already-exists（すでに存在）

要求ペイロードでのエラー。

container-not-found（コンテナが見つからない）

要求ペイロードでのエラー。

container-already-exists（コンテナはすでに存在する）

要求ペイロードでのエラー。

property-not-found（プロパティが見つからない）

要求ペイロードでのエラー。

property-already-exists（プロパティはすでに存在する）

要求ペイロードでのエラー。

形式異常

要求ペイロードでのエラー。

alloc-failed（割り当てに失敗）

内部エラーが発生しました。

sigint（秘密情報収集）

内部エラーが発生しました。

not-initialized（未初期化）

内部エラーが発生しました。

inappropriate（不適切）

内部エラーが発生しました。

次に、無効な IP アドレス値を報告する NETCONF エラー応答ペイロードの例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="320" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>Protocol</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>Error</error-severity>
<error-message xml:lang="en">Property Merge (set property) Failed: operation-failed value=500.500.500.500</error-message>
<error-path>/config/System/bgp-items/inst-items/dom-items/Dom-list/rtrId</error-path>
</rpc-error>
</rpc-reply>

NETCONF エージェントのトラブルシューティング

接続のトラブルシューティング

- クライアント システムから、スイッチの管理ポートに ping を実行して、スイッチが到達可能であることを確認します。

- スイッチの bash シェルで、 service netconf status コマンドを実行してエージェントのステータスを確認します。

- XML 管理インターフェイス（xmlagent とも呼ばれる）というものがあります。これは NETCONF エージェントとはまったく異なりますが、よく混同されます。サーバーが正しい NETCONF メッセージで応答しない場合は、正しいポート 830 に接続していて、サーバーから正しい <hello> メッセージ（「NETCONF セッションの確立」セクションに示されているものと同様）を受信していることを確認します。

- /volatile/netconf-internal-log ファイルの内容を表示することで、Bash シェルからの NETCONF エージェントのデバッグ情報を表示できます。Bash シェルを有効にするには、feature bash コマンドを使用します。Bash シェルを有効にした後、run bash コマンドを使用して Bash シェルを開始します。詳細については、このドキュメントの Bash の章を参照してください。

注：debug netconf コマンドは、NETCONF エージェント動作のデバッグには使用できません。これらのデバッグコマンドは、NETCONF エージェント関連のログを出力しません。

Chapter23. CLI コマンドのネットワーク構成フォーマットへの変換

- XMLIN に関する情報

- XMLIN のライセンス要件

- XMLIN ツールのインストールおよび使用

- show コマンド出力の XML への変換

- XMLIN の構成例

XMLIN に関する情報

XMLIN ツールは、CLI コマンドをネットワーク構成（NETCONF）プロトコル形式に変換します。NETCONF は、ネットワーク デバイスの構成をインストール、処理、削除する機能を提供するネットワーク管理プロトコルです。これは、構成データとプロトコル メッセージに XML ベースのエンコーディングを使用します。NETCONF プロトコルの NX-OS 実装は、<get>、<edit-config>、<close-session>、<kill-session>、および <exec-command> のプロトコル操作をサポートします。

XMLIN ツールは、show、EXEC、および構成コマンドを対応する NETCONF <get>、<exec-command>、および <edit-config> リクエストに変換します。複数の構成コマンドを単一の NETCONF <edit-config> インスタンスにまとめることができます。

XMLIN ツールはまた、show コマンドの出力を XML 形式に変換します。

XMLIN のライセンス要件

XMLIN ライセンス要件

製品

ライセンス要件

Cisco NX-OS

XMLIN にはライセンスは必要ありません。ライセンス パッケージに含まれていない機能はすべて Cisco NX-OS システム イメージにバンドルされており、追加費用は一切発生しません。NX-OS ライセンス方式の詳細については、『Cisco NX-OS Licensing Guide』を参照してください。

XMLIN ツールのインストールおよび使用

XMLIN ツールをインストールして、構成 コマンドを NETCONF フォーマットに変換するために使用できます。

始める前に

XMLIN ツールは、対応する機能セットまたは必要なハードウェア機能がデバイスで利用できない場合でも、コマンドの NETCONF インスタンスを生成できます。ただし、xmlin コマンドを入力する前に、いくつかの機能セットをインストールする必要がある場合があります。

手順

ステップ 1

switch# xmlin

ステップ 2

switch(xmlin)# configure terminal

グローバル コンフィギュレーション モードを開始します

ステップ 3

コンフィギュレーション コマンド

構成 コマンドを NETCONF フォーマットに変換します。

ステップ 4

（任意） switch(config)(xmlin)# end

対応する <edit-config> 要求を生成します。

（注）

show コマンドに対して XML インスタンスを生成する前に、end コマンドを入力して現在の XML 構成を終了する必要があります。

ステップ 5

（任意） switch(config-if-verify)(xmlin)# show commands

show コマンドを NETCONF フォーマットに変換します。

ステップ 6

（任意） switch(config-if-verify)(xmlin)# exit

EXEC モードに戻ります。

show コマンド出力の XML への変換

show コマンドの出力を XML に変換できます。

始める前に

変換するコマンドのすべての機能がインストールされ、デバイス上で有効になっていることを確認します。そうしない場合、コマンドは機能不全になります。

terminal verify-only コマンドを使用すると、デバイスに入力しなくても機能が有効になっていることを確認できます。

コマンドに対するすべての必須ハードウェアがデバイス上に存在することを確認します。そうしない場合、コマンドは機能不全になります。

XMLIN ツールがインストールされていることを確認します。

手順

switch# show-command | xmlin

グローバル コンフィギュレーション モードを開始します

（注）

構成 コマンドと一緒にこのコマンドを使用することはできません。

XMLIN の構成例

次の例は、XMLIN ツールがデバイス上にどのようにインストールされ、一連の構成コマンドを <edit-config> インスタンスに変換するためにどのように使用されるかを示しています。

switch# xmlin
******************************************
Loading the xmlin tool. Please be patient.
******************************************
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright ©) 2002-2013, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php

switch(xmlin)# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)(xmlin)# interface ethernet 2/1
% Success
switch(config-if-verify)(xmlin)# cdp enable
% Success
switch(config-if-verify)(xmlin)# end
<?xml version="1.0"?>
<nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns="http://www.cisco.com/nxos:6.2.2.:configure_"
xmlns:m="http://www.cisco.com/nxos:6.2.2.:_exec"
xmlns:m1="http://www.cisco.com/nxos:6.2.2.:configure__if-eth-base" message-id="1">
<nf:edit-config>
<nf:target>
<nf:running/>
</nf:target>
<nf:config>
<m:configure>
<m:terminal>
<interface>
<__XML__PARAM__interface>
<__XML__value>Ethernet2/1</__XML__value>
<m1:cdp>
<m1:enable/>
</m1:cdp>
</__XML__PARAM__interface>
</interface>
</m:terminal>
</m:configure>
</nf:config>
</nf:edit-config>
</nf:rpc>
]]>]]>

次の例は、show コマンドに対して XML インスタンスを生成する前に現在の XML 構成を終了するために end コマンドを入力する方法を表示しています。

switch(xmlin)# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)(xmlin)# interface ethernet 2/1
switch(config-if-verify)(xmlin)# show interface ethernet 2/1
********************************************************
Please type "end" to finish and output the current XML document before building a new one.
********************************************************
% Command not successful

switch(config-if-verify)(xmlin)# end
<?xml version="1.0"?>
<nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns="http://www.cisco.com/nxos:6.2.2.:configure_"
xmlns:m="http://www.cisco.com/nxos:6.2.2.:_exec" message-id="1">
<nf:edit-config>
<nf:target>
<nf:running/>
</nf:target>
<nf:config>
<m:configure>
<m:terminal>
<interface>
<__XML__PARAM__interface>
<__XML__value>Ethernet2/1</__XML__value>
</__XML__PARAM__interface>
</interface>
</m:terminal>
</m:configure>
</nf:config>
</nf:edit-config>
</nf:rpc>
]]>]]>

switch(xmlin)# show interface ethernet 2/1
<?xml version="1.0"?>
<nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns="http://www.cisco.com/nxos:6.2.2.:if_manager" message-id="1">
<nf:get>
<nf:filter type="subtree">
<show>
<interface>
<__XML__PARAM__ifeth>
<__XML__value>Ethernet2/1</__XML__value>
</__XML__PARAM__ifeth>
</interface>
</show>
</nf:filter>
</nf:get>
</nf:rpc>
]]>]]>
switch(xmlin)# exit
switch#

次の例は、show interface brief コマンドの出力を XML に変換する方法を示しています。

switch# show interface brief | xmlin
<?xml version="1.0"?>
<nf:rpc xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns="http://www.cisco.com/nxos:6.2.2.:if_manager"

message-id="1">
<nf:get>
<nf:filter type="subtree">
<show>
<interface>
<brief/>
</interface>
</show>
</nf:filter>
</nf:get>
</nf:rpc>
]]>]]>

Chapter24. RESTConf エージェント

- RESTCONF エージェントについて

- 注意事項と制約事項

- RESTCONF エージェントの使用方法

- RESTCONF エージェントのトラブルシューティング

RESTCONF エージェントについて

Cisco NX-OS RESTCONF は、NETCONF で定義されたデータストアを使用して、YANG バージョン 1 で定義されたデータを構成するための HTTP ベースのプロトコルです。

NETCONF は、構成データストアと、これらのデータストアへのアクセスに使用できる一連の作成、取得、更新、および削除（CRUD）操作を定義します。YANG 言語は、データストア格納ファイル、運用データ、プロトコル操作、イベント通知の構文とセマンティクスを定義します。

Cisco NX-OS RESTCONF は、HTTP 操作を使用して、YANG 定義のデータを含む概念データストアでの CRUD 操作を可能にします。このデータは、NETCONF データストアを実装するサーバーと互換性があります。

RESTCONF プロトコルは、XML と JSON の両方のペイロード エンコーディングをサポートします。ユーザー認証は、HTTP 基本認証によって行われます。

次の表に、Cisco NX-OS RESTCONF エージェントがサポートするプロトコル操作を示します。

RESTCONF

同等の NETCONF

オプション

NETCONF：なし

HEAD

NETCONF：なし

GET

NETCONF: <get-config>, <get>

POST

NETCONF: <edit-config> (operation="create")

PUT

NETCONF: <edit-config> (operation="create/replace")

PATCH

NETCONF: <edit-config> (operation="merge")

DELETE

NETCONF: <edit-config> (operation="delete")

注意事項と制約事項

RESTCONF エージェントには、次の注意事項と制約事項があります。

- Cisco NX-OS RESTCONF は、RESTCONF Protocoldraft-ietf-netconf-restconf-10 (https://tools.ietf.org/html/draft-ietf-netconf-restconf-10) という RFC ドラフトに基づいています。

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

RESTCONF エージェントの使用方法

一般的なコマンド

- HTTP または HTTPS アクセスを有効にするには、次のコマンドを構成します。

- feature nxapi

- nxapi http port 80

- nxapi https port 443

一般的な制御コマンド

RESTCONF エージェントの [no] feature restconf コマンドを有効または無効にできます。

エージェント ステータスの表示

RESTCONF エージェントのステータスを表示するには、show feature コマンドを使用し、式 restconf を含めます。

switch-1# show feature | grep restconf
restconf               1          enabled
switch-1#

Curl を使用したサーバーへの POST 要求の送信

client-host % curl -X POST -H "Authorization: Basic YWRtaW46Y2lzY28=" -H "Content-Type: application/yang.data+xml" -d '<always>enabled</always><rtrId>2.2.2.2</rtrId>' "http://192.0.20.123/restconf/data/Cisco-NX-OS-device:System/bgp-items/inst-items/dom-items/Dom-list=default" -i

HTTP/1.1 201 Created
Server: nginx/1.7.10
Date: Tue, 27 Sep 2016 20:25:31 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: nxapi_auth=admin:147500853169574134
Status: 201 Created
Location: /System/bgp-items/inst-items/dom-items/Dom-list=default/always/rtrId/

Curl を使用したサーバーへの GET 要求の送信

client-host % curl -X GET -H "Authorization: Basic YWRtaW46Y2lzY28=" -H "Accept: application/yang.data+xml" "http://192.0.20.123/restconf/data/Cisco-NX-OS-device:System/bgp-items/inst-items/dom-items/Dom-list?content=config" -i

HTTP/1.1 200 OK
Server: nginx/1.7.10
Date: Tue, 27 Sep 2016 20:26:03 GMT
Content-Type: application/yang.data+xml
Content-Length: 395
Connection: keep-alive
Set-Cookie: nxapi_auth=admin:147500856185650327
Status: 200 OK

<Dom-list>
<name>default</name>
<always>enabled</always>
<bestPathIntvl>300</bestPathIntvl>
<holdIntvl>180</holdIntvl>
<kaIntvl>60</kaIntvl>
<maxAsLimit>0</maxAsLimit>
<pfxPeerTimeout>30</pfxPeerTimeout>
<pfxPeerWaitTime>90</pfxPeerWaitTime>
<reConnIntvl>60</reConnIntvl>
<rtrId>2.2.2.2</rtrId>
</Dom-list>
client-host %

RESTCONF エージェントのトラブルシューティング

接続のトラブルシューティング

- feature nxapi コマンドを発行して、Web サーバーを有効にします。

- HTTP 用にポートを開くように nxapi http port 80 コマンドが構成されていることを確認します。

- HTTPS 用にポートを開くように nxapi https port 443 コマンドが構成されていることを確認します。

- スイッチの管理ポートに ping を実行して、スイッチが到達可能であることを確認します。

Chapter25. gRPC エージェント

- gRPC エージェントについて

- 注意事項と制約事項

- Cisco NX-OS リリース 9.3（2）以前の gRPC エージェントの構成

- gRPC エージェントの使用

- gRPC エージェントのトラブルシューティング

- gRPC Protobuf ファイル

gRPC エージェントについて

Cisco NX-OS gRPC プロトコルは、ネットワーク デバイスを管理し、その構成データを取得してインストールするためのメカニズムを定義します。プロトコルは、クライアントがデバイス構成を管理するために使用できる完全で正式なアプリケーション プログラミング インターフェイス（API）を公開します。

Cisco NX-OS gRPC プロトコルは、リモート プロシージャ コール（RPC）パラダイムを使用します。このパラダイムでは、外部クライアントが、Google プロトコル バッファ（GPB）で定義された API コールとそのサービス固有の引数を使用してデバイス設定を操作します。これらの GPB 定義 API は、同じ GPB 定義 API コンテキストで応答を返すデバイスへの RPC コールを透過的に引き起こします。

gRPC エージェントは、TLS によるセキュアな転送と、AAA によるユーザー認証と認可を提供します。

Cisco NX-OS gRPC プロトコルの機能上の目的は、特にステートレスとステートフルの両方の構成操作に関して、NETCONF によって提供されるプロトコルをミラーリングして、運用の柔軟性を最大限に高めることです。

Cisco NX-OS gRPC エージェントは、次のプロトコル操作をサポートしています。

- 結果

- GetConfig

- GetOper

- edit-config

- start-session

- CloseSession

- kill-session

gRPC エージェントは、次の 2 種類の操作をサポートしています：

- ステートレス操作は、セッションを作成せずに単一のメッセージ内で完全に実行されます。

- ステートフル操作は、複数のメッセージを使用して実行されます。実行される動作のシーケンスは、次のとおりです：

1. セッションを開始します。このアクションは、一意のセッション ID を取得します。

2. セッション ID を使用してセッションタスクを実行します。

3. セッションを終了します。このアクションにより、セッション ID が無効になります。

次にあるのは、サポートされている操作です。gRPC エージェントによってエクスポートされる .proto ファイルの RPC 定義については、付録を参照してください。

動作

説明

start-session

クライアントとサーバー間の新しいセッションを開始し、一意のセッション ID を取得します。

edit-config

指定された YANG データ サブセットをターゲット データストアに書き込みます。

GetConfig

送信元データストアから指定された YANG 構成データのサブセットを取得します。

GetOper

送信元データストアから指定された YANG 動作データを取得します。

結果

指定された YANG 構成および動作データを送信元データストアから取得します。

KillSession

セッションを強制終了します。

CloseSession

セッションの適切な終了を要求します。

GetConfig、GetOper、および Get はステートレス操作であるため、セッション ID は必要ありません。

EditConfig は、ステートレスまたはステートフルのいずれかです。ステートレス操作の場合は、SessionID を 0 に指定します。ステートフル操作の場合、有効な（ゼロ以外の）SessionID が必要です。

gRPC エージェントは、セッションのタイムアウトをサポートします。セッションのアイドル タイムアウトはデバイスで構成できます。アイドル セッションは終了して削除されます。

注意事項と制約事項

gRPC エージェントには、次のガイドラインと制限があります。

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

Cisco NX-OS リリース 9.3（2）以前の gRPC エージェントの構成

gRPC エージェントは、構成ファイル（ /etc/mtx.conf ）の [grpc] セクションで次の構成パラメータをサポートします。

パラメータ

説明

idle_timeout

（オプション）アイドル状態のクライアント セッションが切断されるまでのタイムアウトを分単位で指定します。

デフォルトのタイムアウトは 5 分です。

値を 0 に設定するとタイムアウトが無効になります。

limit

（オプション）同時クライアント セッションの最大数を指定します。

デフォルト制限値は 5 セッションです。

範囲は 1 ～ 50 です。

lport

（任意） gRPC エージェントがリッスンするポート番号を指定します。

デフォルトのポートは 50051 です。

key

TLS 認証のキー ファイルの場所を指定します。

デフォルトの場所は /opt/mtx/etc/grpc.key です。

cert

TLS 認証の認定ファイルの場所を指定します。

デフォルトの場所は /opt/mtx/etc/grpc.pem です。

security

セキュアな接続のタイプを指定します。

有効な選択肢は、次のとおりです。

- TLS の TLS

- セキュアでない接続の場合は NONE

gRPC エージェントの使用

一般的なコマンド

gRPC エージェントを有効または無効にするには、 [no] feature grpc コマンドを発行します。

例：JSON フォーマットの基本的な YANG パス

client-host % cat payload.json
{
"namespace": "http://cisco.com/ns/yang/cisco-nx-os-device",
"System": {
"bgp-items": {
"inst-items": {
"dom-items": {
"Dom-list": {
"name": "default",
"rtrId": "7.7.7.7",
"holdIntvl": "100"
}
}
}
}
}
}

（注）

JSON 構造は、読みやすいように整形されています。

サーバーへの EditConfig 要求の送信

client-host % ./grpc_client -username=admin -password=cisco -operation=EditConfig -e_oper=Merge -def_op=Merge -err_op=stop-on-error -infile=payload.json -reqid=1 -source=running -tls=true -serverAdd=192.0.20.123 -lport=50051

######################################################
Starting the client service
######################################################
TLS set true for client requests1ems.cisco.com
TLS FLAG:1
192.0.20.123:50051
All the client connections are secured
Sending EditConfig request to the server
sessionid is
0
reqid:1
{"rpc-reply":{"ok":""}}

サーバーへの GetConfig 要求の送信

client-host % ./grpc_client -username=admin -password=cisco -operation=GetConfig -infile=payload.json -reqid=1 -source=running -tls=true -serverAdd=192.0.20.123 -lport=50051

######################################################
Starting the client service
######################################################
TLS set true for client requests1ems.cisco.com
TLS FLAG:1
192.0.20.123:50051
All the client connections are secured
Sending GetConfig request to the server
in get config
Got the response from the server
#########################################
Yang Json is:
#########################################
{"rpc-reply":{"data":{"System":{"bgp-items":{"inst-items":{"dom-items":{"Dom-list":{"name":"default","rtrId":"7.7.7.7","holdIntvl":"100"}}}}}}}}
#########################################
client-host %

gRPC エージェントのトラブルシューティング

接続のトラブルシューティング

- クライアント システムから、エージェントがポートでリッスンしていることを確認します。次に例を示します。

client-host % nc –z 192.0.20.222 50051
Connection to 192.0.20.222 50051 port [tcp/*] succeeded!
client-host % echo $?
0
client-host %

- NX-OS で、 を発行して gRPC エージェントのステータスを確認します show feature | grep grpc。

gRPC Protobuf ファイル

gRPC エージェントは、/opt/mtx/etc/nxos_grpc.proto にある proto 定義ファイルでサポートされている操作とデータ構造をエクスポートします。ファイルは、gRPC エージェント RPM に含まれています。次に、定義を示します。

// Copyright 2016, Cisco Systems Inc.
// All rights reserved.

syntax = "proto3";

package NXOSExtensibleManagabilityService;

// Service provided by Cisco NX-OS gRPC Agent
service gRPCConfigOper {

// Retrieves the specified YANG configuration data subset from the
// source datastore
rpc GetConfig(GetConfigArgs) returns(stream GetConfigReply) {};

// Retrieves the specified YANG operational data from the source datastore
rpc GetOper(GetOperArgs) returns(stream GetOperReply) {};

// Retrieves the specified YANG configuration and operational data
// subset from the source datastore
rpc Get(GetArgs) returns(stream GetReply){};

// Writes the specified YANG data subset to the target datastore
rpc EditConfig(EditConfigArgs) returns(EditConfigReply) {};

// Starts a new session between the client and server and acquires a
// unique session ID
rpc StartSession(SessionArgs) returns(SessionReply) {};

// Requests graceful termination of a session
rpc CloseSession(CloseSessionArgs) returns (CloseSessionReply) {};

// Forces the termination of a session
rpc KillSession(KillArgs) returns(KillReply) {};

// Unsupported; reserved for future
rpc DeleteConfig(DeleteConfigArgs) returns(DeleteConfigReply) {};

// Unsupported; reserved for future
rpc CopyConfig(CopyConfigArgs) returns(CopyConfigReply) {};

// Unsupported; reserved for future
rpc Lock(LockArgs) returns(LockReply) {};

// Unsupported; reserved for future
rpc UnLock(UnLockArgs) returns(UnLockReply) {};

// Unsupported; reserved for future
rpc Commit(CommitArgs) returns(CommitReply) {};

// Unsupported; reserved for future
rpc Validate(ValidateArgs) returns(ValidateReply) {};

// Unsupported; reserved for future
rpc Abort(AbortArgs) returns(AbortReply) {};

}

message GetConfigArgs
{
// JSON-encoded YANG data to be retrieved
string YangPath = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;

// (Optional) Specifies the source datastore; only "running" is supported.
// Default is "running".
string Source = 3;
}

message GetConfigReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// JSON-encoded YANG data that was retrieved
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message GetOperArgs
{
// JSON-encoded YANG data to be retrieved
string YangPath = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;
}

message GetOperReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// JSON-encoded YANG data that was retrieved
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message GetArgs
{
// JSON-encoded YANG data to be retrieved
string YangPath=1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;
}

message GetReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// JSON-encoded YANG data that was retrieved
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message EditConfigArgs
{
// JSON-encoded YANG data to be edited
string YangPath = 1;

// Specifies the operation to perform on teh configuration datastore with
// the YangPath data.  Possible values are:
//   create
//   merge
//   replace
//   delete
//   remove
// If not specified, default value is "merge".
string Operation = 2;

// A unique session ID acquired from a call to StartSession().
// For stateless operation, this value should be set to 0.
int64 SessionID = 3;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 4;

// (Optional) Specifies the target datastore; only "running" is supported.
// Default is "running".
string Target = 5;

// Specifies the default operation on the given object while traversing
// the configuration tree.
// The following operations are possible:
//   merge:     merges the configuration data with the target datastore;
//              this is the default.
//   replace:   replaces the configuration data with the target datastore.
//   none:      target datastore is unaffected during the traversal until
//              the specified object is reached.
string DefOp = 6;

// Specifies the action to be performed in the event of an error during
// configuration.  Possible values are:
//   stop
//   roll-back
//   continue
// Default is "roll-back".
string ErrorOp = 7;
}

message EditConfigReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// If EditConfig is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message DeleteConfigArgs
{
// A unique session ID acquired from a call to StartSession().
// For stateless operation, this value should be set to 0.
int64 SessionID = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;

// (Optional) Specifies the target datastore; only "running" is supported.
// Default is "running".
string Target = 3;
}

message DeleteConfigReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// If DeleteConfig is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message CopyConfigArgs
{
// A unique session ID acquired from a call to StartSession().
// For stateless operation, this value should be set to 0.
int64 SessionID = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;

// (Optional) Specifies the source datastore; only "running" is supported.
// Default is "running".
string Source = 3;

// (Optional) Specifies the target datastore; only "running" is supported.
// Default is "running".
string Target = 4;
}

message CopyConfigReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// If CopyConfig is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message LockArgs
{
// A unique session ID acquired from a call to StartSession().
int64 SessionID = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID=2;

// (Optional) Specifies the target datastore; only "running" is supported.
// Default is "running".
string Target = 3;
}

message LockReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// If Lock is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message UnLockArgs
{
// A unique session ID acquired from a call to StartSession().
int64 SessionID = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;

// (Optional) Specifies the target datastore; only "running" is supported.
// Default is "running".
string Target = 3;
}

message UnLockReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// If UnLock is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message SessionArgs
{
// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 1;
}

message SessionReply
{
// The request ID specified in the request.
int64 ReqID = 1;
int64 SessionID = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message CloseSessionArgs
{
// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 1;

// A unique session ID acquired from a call to StartSession().
int64 SessionID = 2;
}

message CloseSessionReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// If CloseSession is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message KillArgs
{
// A unique session ID acquired from a call to StartSession().
int64 SessionID = 1;

int64 SessionIDToKill = 2;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 3;
}

message KillReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// If Kill is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message ValidateArgs
{
// A unique session ID acquired from a call to StartSession().
int64 SessionID = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;
}

message ValidateReply
{
// The request ID specified in the request.
int64 ReqID = 1;

// If Validate is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message CommitArgs
{
// A unique session ID acquired from a call to StartSession().
int64 SessionID = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;
}

message CommitReply
{
// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 1;

// If Commit is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

message AbortArgs
{
// A unique session ID acquired from a call to StartSession().
int64 SessionID = 1;

// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 2;
}

message AbortReply
{
// (Optional) Specifies the request ID.  Default value is 0.
int64 ReqID = 1;

// If Abort is successful, YangData contains a JSON-encoded "ok" response.
string YangData = 2;

// JSON-encoded error information when request fails
string Errors = 3;
}

Chapter26. ダイナミック ロガー

- 前提条件

- 参照先

前提条件

ダイナミック ロギングを使用する前に、スイッチに次のものが存在することを確認します。

- libmtxlogmgr*.so ライブラリが /opt/mtx/lib/ にインストールされていること。libmtxlogmgr*.so ライブラリは、mtx_infra RPM の一部です。

- mtx.conf ファイルが /etc/ にあること。

[mtxlogger]
config=/opt/mtx/conf/mtxlogger.cfg

- mtxlogger.cfg ファイルが /opt/mtx/conf/ にあること。

参照先

構成ファイルの構造は次のとおりです。

<config name="nxos-device-mgmt">
<container name="mgmtConf">
<container name="logging">
<leaf name="enabled" type="boolean" default="false"></leaf>
<leaf name="allActive" type="boolean" default="false"></leaf>
<container name="format">
<leaf name="content" type="string" default="$DATETIME$ $COMPONENTID$ $TYPE$: $MSG$"></leaf>
<container name="componentID">
<leaf name="enabled" type="boolean" default="true"></leaf>
</container>
<container name="dateTime">
<leaf name="enabled" type="boolean" default="true"></leaf>
<leaf name="format" type="string" default="%y%m%d.%H%M%S"></leaf>
</container>
<container name="fcn">
<leaf name="enabled" type="boolean" default="true"></leaf>
<leaf name="format" type="string" default="$CLASS$::$FCNNAME$($ARGS$)@$LINE$"></leaf>
</container>
</container>
<container name="dest">
<container name="console">
<leaf name="enabled" type="boolean" default="false"></leaf>
</container>
<container name="file">
<leaf name="enabled" type="boolean" default="false"></leaf>
<leaf name="name" type="string" default="mtx-internal.log"></leaf>
<leaf name="location" type="string" default="./mtxlogs"></leaf>
<leaf name="mbytes-rollover" type="uint32" default="10"></leaf>
<leaf name="hours-rollover" type="uint32" default="24"></leaf>
<leaf name="startup-rollover" type="boolean" default="false"></leaf>
<leaf name="max-rollover-files" type="uint32" default="10"></leaf>
</container>
</container>
<list name="logitems" key="id">
<listitem>
<leaf name="id" type="string"></leaf>
<leaf name="active" type="boolean" default="true"></leaf>
</listitem>
</list>
</container>
</container>
</config>

<list> タグは、<componentID> によるログ フィルタを定義します。

次の表では、コンテナとそのリーフの一部について説明します。

コンテナとリーフの説明

コンテナ

コンテナの説明

含まれるコンテナ

含まれるリーフと説明

logging

すべてのロギング データ タイプが含まれます。

形式

dest

ファイル

（注）

リストタグ「logitems」も含まれます

enabled：ロギングがオンかオフかを決定するブール値です。デフォルトはオフです。

allActive：ロギング用に定義されたすべてのロギング項目をアクティブにするブール値です。デフォルトはオフです。

形式

ログ メッセージの形式情報を格納します。

componentID

dateTime

type

fcn

content：ログ メッセージに含まれるデータ型をリストする文字列です。内容：

- $DATETIME$：ログ メッセージに日付または時刻を含めます。

- $COMPONENTID$：ログ メッセージにコンポーネント名を含めます。

- $TYPE$：メッセージタイプ（""、INFO、WARNING、ERROR）を含めます。

- $SRCFILE$：ソース ファイルの名前を含めます。

- $SRCLINE$：ソース ファイルの行番号を含めます。

- $FCNINFO$ ソース ファイルからの class::関数名を含めます。

- $MSG$：実際のログ メッセージ テキストを含めます。

componentID

ログが記録されたコンポーネントの名前です。

該当なし

enabled：ログ メッセージにコンポーネント ID を含めるかどうかを決定するブール値です。デフォルトは「true」です。値を「false」にすると、ログ メッセージに "" 文字列を返します。

dateTime

ログ メッセージの日付または時刻です

該当なし

enabled：ログ メッセージに日付または時刻の情報を含めるかどうかのブール値です。デフォルトはイネーブルです。

format：ログ メッセージに含める値を示す文字列です。フォーマットは %y%m%d.%H%M%Sです。

dest

接続先ロガーの構成設定を保持します。

console：接続先コンソールです。許可されるのは 1 つだけです。

file：接続先ファイルです。複数ファイルが許可されます。

該当なし

コンソール

接続先コンソール

該当なし

enabled：コンソールのロギングが有効かどうかを決定するブール値です。デフォルトは「false」です。

ファイル

接続先ファイルの設定を決定します。

該当なし

enabled：接続先が有効にされているかどうかを決定するブール値です。デフォルトは「false」です。

name：接続先ログ ファイルを示す文字列です。デフォルトは「mtx-internal.log」です。

location：接続先ファイル パスを示す文字列です。デフォルトは「./mtxlogs」です。

mbytes-rollover：システムが最も古いデータを上書きするまでのログファイルの長さを決定する uint32 値です。デフォルトは 10 M バイトです。

hours-rollover：時間単位でのログファイルの長さを決定する uint32 値です。デフォルトは 24 時間です。

startup-rollover：エージェントの起動時または再起動時にログファイルをロールオーバーするかどうかを決定するブール値です。デフォルト値は「false」です。

max-rollover-files：ロールオーバー ファイルの最大数を決定する uint32 値です。 max-rollover-files の値を超えると、最も古いファイルが削除されます。デフォルト値は 10 です。

例

次に、デフォルトでインストールされている設定を含む設定ファイルを示します。

<config name="nxos-device-mgmt">
<container name="mgmtConf">
<container name="logging">
<leaf name="enabled" type="boolean" default="false">true</leaf>
<leaf name="allActive" type="boolean" default="false">false</leaf>
<container name="format">
<leaf name="content" type="string" default="$DATETIME$ $COMPONENTID$ $TYPE$: $MSG$">$DATETIME$ $COMPONENTID$ $TYPE$ $SRCFILE$ @ $SRCLINE$ $FCNINFO$:$MSG$</leaf>
<container name="componentID">
<leaf name="enabled" type="boolean" default="true"></leaf>
</container>
<container name="dateTime">
<leaf name="enabled" type="boolean" default="true"></leaf>
<leaf name="format" type="string" default="%y%m%d.%H%M%S"></leaf>
</container>
<container name="fcn">
<leaf name="enabled" type="boolean" default="true"></leaf>
<leaf name="format" type="string" default="$CLASS$::$FCNNAME$($ARGS$)@$LINE$"></leaf>
</container>
</container>
<container name="dest">
<container name="console">
<leaf name="enabled" type="boolean" default="false">true</leaf>
</container>
<container name="file">
<leaf name="enabled" type="boolean" default="false">true</leaf>
<leaf name="name" type="string" default="mtx-internal.log"></leaf>
<leaf name="location" type="string" default="./mtxlogs">/volatile</leaf>
<leaf name="mbytes-rollover" type="uint32" default="10">50</leaf>
<leaf name="hours-rollover" type="uint32" default="24">24</leaf>
<leaf name="startup-rollover" type="boolean" default="false">true</leaf>
<leaf name="max-rollover-files" type="uint32" default="10">10</leaf>
</container>
</container>
<list name="logitems" key="id">
<listitem>
<leaf name="id" type="string">*</leaf>
<leaf name="active" type="boolean" default="false">false</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">SYSTEM</leaf>
<leaf name="active" type="boolean" default="true">true</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">LIBUTILS</leaf>
<leaf name="active" type="boolean" default="true">true</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">MTX-API</leaf>
<leaf name="active" type="boolean" default="true">true</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">Model-*</leaf>
<leaf name="active" type="boolean" default="true">true</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">Model-Cisco-NX-OS-device</leaf>
<leaf name="active" type="boolean" default="true">false</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">Model-openconfig-bgp</leaf>
<leaf name="active" type="boolean" default="true">false</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">INST-MTX-API</leaf>
<leaf name="active" type="boolean" default="true">false</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">INST-ADAPTER-NC</leaf>
<leaf name="active" type="boolean" default="true">false</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">INST-ADAPTER-RC</leaf>
<leaf name="active" type="boolean" default="true">false</leaf>
</listitem>
<listitem>
<leaf name="id" type="string">INST-ADAPTER-GRPC</leaf>
<leaf name="active" type="boolean" default="true">false</leaf>
</listitem>
</list>
</container>
</container>
</config>

Chapter27. モデル駆動型テレメトリ

- テレメトリについて

- テレメトリのライセンス要件

- テレメトリの注意事項と制約事項

- その他の参考資料

テレメトリについて

分析やトラブルシューティングのためのデータ収集は、ネットワークの健全性をモニタリングする上で常に重要な要素であり続けています。

Cisco NX-OS は、ネットワークからデータを収集するための、SNMP、CLI や Syslog といった複数のメカニズムを提供します。これらのメカニズムには、自動化や拡張に対する制約があります。ネットワーク要素からのデータの最初の要求がクライアントから出された場合、プル モデルの使用が制限されることもその制約の 1 つです。プル モデルは、ネットワーク内に複数のネットワーク管理ステーション（NMS）がある場合は拡張しません。このモデルを使用すると、クライアントが要求した場合に限り、サーバーがデータを送信します。このような要求を開始するには、手動による介入を続けて行う必要があります。このような手動による介入を続けると、プル モデルの効率が失われます。

プッシュ モデルは、ネットワークからデータを継続的にストリーミングし、クライアントに通知します。テレメトリはプッシュ モデルをイネーブルにし、モニタリング データにほぼリアルタイムでアクセスできるようにします。

- テレメトリ コンポーネントとプロセス

- テレメトリ プロセスの高可用性

テレメトリ コンポーネントとプロセス

テレメトリは、次の 4 つの主要な要素で構成されます。

- データ収集：テレメトリ データは、識別名（DN）パスを使用して指定されたオブジェクト モデルのブランチにあるデータ管理エンジン（DME）データベースから収集されます。データは定期的に取得されるか（頻度ベース）、指定したパスのオブジェクトで変更があった場合にのみ取得できます（イベント ベース）。NX-API を使用して、頻度ベースのデータを収集できます。

- データ エンコーディング：テレメトリ エンコーダが、収集されたデータを目的の形式で転送できるようにカプセル化します。

NX-OS は、テレメトリ データを Google Protocol Buffers（GPB）および JSON 形式でエンコードします。

- データ トランスポート：NX-OS は、JSON エンコードに HTTP を使用してテレメトリ データを転送し、GPB エンコードに Google リモート プロシージャ コール (gRPC) プロトコルを使用します。gRPC レシーバーは、4 MB を超えるメッセージ サイズをサポートします。（証明書が構成されている場合は、HTTPS を使用したテレメトリ データもサポートされます。）

Cisco NX-OS リリース 7.0(3)I7(1) 以降、UDP およびセキュア UDP（DTLS）がテレメトリ トランスポート プロトコルとしてサポートされています。UDP を受信する接続先を追加できます。UDP およびセキュア UDP のエンコーディングは、GPB または JSON にすることができます。

次のコマンドを使用して、JSON または GPB のデータグラム ソケットを使用してデータをストリーミングするように UDP トランスポートを構成します。

destination-group num
ip address xxx.xxx.xxx.xxx port xxxx protocol UDP encoding {JSON | GPB }

IPv4 接続先の例:

destination-group 100
ip address 171.70.55.69 port 50001 protocol UDP encoding GPB

UDP テレメトリには次のヘッダーがあります。

typedef enum tm_encode_ {
TM_ENCODE_DUMMY,
TM_ENCODE_GPB,
TM_ENCODE_JSON,
TM_ENCODE_XML,
TM_ENCODE_MAX,
} tm_encode_type_t;

typedef struct tm_pak_hdr_ {
uint8_t version; /* 1 */
uint8_t encoding;
uint16_t msg_size;
uint8_t secure;
uint8_t padding;
}__attribute__ ((packed, aligned (1))) tm_pak_hdr_t;

次のいずれかの方法で、ペイロードの最初の 6 バイトを使用して、UDP を使用してテレメトリ データを処理します。

- 受信側が複数のエンドポイントから異なるタイプのデータを受信することになっている場合は、ヘッダーの情報を読んで、データのデコードに使用するデコーダー（JSON または GPB）を決定します。

- 1 つのデコーダー（JSON または GPB）が必要で、もう 1 つのデコーダーは必要ない場合は、ヘッダーを削除します。

（注）

UDPプロトコルを使用した場合、受信側のOSやネットワークの負荷によってはパケットドロップが発生する場合があります。

- テレメトリ レシーバー：テレメトリ レシーバーは、テレメトリ データを保存するリモート管理システムです。

GPB エンコーダーは、汎用キーと値の形式でデータを格納します。また、データを GPB 形式に変換するには、コンパイルされた .proto ファイル形式のメタデータが GPB エンコーダに必要です。

データ ストリームを正しく受信してデコードするには、受信側でエンコードとトランスポート サービスを記述した .proto ファイルが必要です。エンコードは、バイナリ ストリームをキー値の文字列のペアにデコードします。

GPB エンコーディングと gRPC トランスポートを記述する telemetry .proto ファイルは、Cisco の GitLab で入手できます。 https://github.com/CiscoDevNet/nx-telemetry-proto

テレメトリ プロセスの高可用性

テレメトリ プロセスの高可用性は、次の動作でサポートされています。

- [システムのリロード（System Reload）] — システムのリロード中に、テレメトリ構成とストリーミング サービスが復元されます。

- [スーパーバイザ フェールオーバー（Supervisor Failover）] — テレメトリはホット スタンバイではありませんが、テレメトリ構成とストリーミング サービスは、新しい現用系スーパーバイザが実行されているときに復元されます。

- [プロセスの再起動（Process Restart）] — なんらかの理由でテレメトリ プロセスがフリーズまたは再起動した場合、テレメトリが再開されると、構成およびストリーミング サービスが復元されます。

テレメトリのライセンス要件

製品

ライセンス要件

Cisco NX-OS

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

テレメトリの注意事項と制約事項

テレメトリ 構成時の注意事項および制約事項は、次のとおりです。

- テレメトリは、7.0（3）I5（1）を始めとするデータ管理エンジン（DME）ネイティブ モデルをサポートするリリースをCisco NX-OS リリースでサポートします。

- リリース 7.0（3）I6（1）が DME データ収集、NX-API データ 送信元、Google リモート プロシージャ コール（gRPC）トランスポート経由の Google プロトコル バッファ（GPB）エンコーディングと HTTP 経由の JSON エンコーディングをサポートします。

- サポートされている最小の送信間隔（ケイデンス）は、深さが 0 の場合の 5 秒です。0 より大きい深度値の最小ケイデンス値は、ストリーミングされるデータのサイズによって異なります。最小値未満のケイデンスでもを構成すると、望ましくないシステム動作が発生する可能性があります。

- 最大 5 つの遠隔管理受信者（接続先）がサポートされます。5 つ以上の遠隔受信者を構成すると、システムが望ましくない動作をする可能性があります。

- テレメトリ 受信者がダウンした場合、その他の受信者にはデータ フローが中断したことが表示されます。障害が発生したレシーバーは再起動する必要があります。次に、接続先グループの下にある障害受信者の IP アドレスを構成解除してから再構成することにより、スイッチとの新しい接続を開始します。

- テレメトリは、CPU 技術情報の最大 20% を消費する可能性があります。

- SSL 証明書ベースの認証とストリーミング データの暗号化を構成するには、certificate ssl cert path hostname "CN" コマンドで自己署名 SSL 証明書を提供します。（NX-OS 7.0（3）I7（1）以降）。

- QoS 明示的輻輳通知（ECN）統計は、Cisco Nexus 9364C、9336C-FX、および 93240YC-FX スイッチでのみサポートされます。

古いリリースにダウングレードした後の構成コマンド

古いリリースにダウングレードした後、古いリリースではサポートされていない可能性があるため、一部の構成コマンドまたはコマンド オプションが機能不全になる可能性があります。古いリリースにダウングレードするときのベスト プラクティスとして、サポートされていないコマンドまたはコマンド オプションの失敗を回避するために、新しいイメージが起動した後にテレメトリ機能を構成解除して再構成します。

次の例は、この手順を表示しています。

- テレメトリ構成をファイルにコピーします。

switch# show running-config | section telemetry
feature telemetry
telemetry
destination-group 100
ip address 1.2.3.4 port 50004 protocol gRPC encoding GPB
sensor-group 100
path sys/bgp/inst/dom-default depth 0
subscription 600
dst-grp 100
snsr-grp 100 sample-interval 7000
switch# show running-config | section telemetry > telemetry_running_config
switch# show file bootflash:telemetry_running_config
feature telemetry
telemetry
destination-group 100
ip address 1.2.3.4 port 50004 protocol gRPC encoding GPB
sensor-group 100
path sys/bgp/inst/dom-default depth 0
subscription 600
dst-grp 100
snsr-grp 100 sample-interval 7000
switch#

- ダウングレード操作を実行します。イメージが表示され、スイッチの準備ができたら、テレメトリ構成をスイッチにコピーして戻します：

switch# copy telemetry_running_config running-config echo-commands
`switch# config terminal`
`switch(config)# feature telemetry`
`switch(config)# telemetry`
`switch(config-telemetry)# destination-group 100`
`switch(conf-tm-dest)# ip address 1.2.3.4 port 50004 protocol gRPC encoding GPB `
`switch(conf-tm-dest)# sensor-group 100`
`switch(conf-tm-sensor)# path sys/bgp/inst/dom-default depth 0`
`switch(conf-tm-sensor)# subscription 600`
`switch(conf-tm-sub)# dst-grp 100`
`switch(conf-tm-sub)# snsr-grp 100 sample-interval 7000`
`switch(conf-tm-sub)# end`
Copy complete, now saving to disk (please wait)...
Copy complete.
switch#

gRPC エラーの動作

gRPC レシーバーが 20 のエラーを送信した場合、スイッチ クライアントは gRPC レシーバーへの接続を無効化します。gRPC レシーバーを有効にするには、接続先グループの下のレシーバーの IP アドレスの構成を解除して再構成する必要があります。一部のエラーの内容は、次のとおりです。

- gRPC クライアントがセキュアな接続に対して誤った証明書を送信している。

- gRPC レシーバでのクライアント メッセージの処理に時間がかかりすぎて、タイムアウトが発生する。別のメッセージ処理スレッドを使用してメッセージを処理することで、タイムアウトを回避している。

gRPC トランスポートのテレメトリ圧縮

Cisco NX-OS 7.0（3）I7（1）以降、gRPC トランスポートでは、圧縮のサポートが利用できます。use-compression gzip コマンドを使用して、圧縮を有効にすることができます。（no use-compression gzip コマンドで圧縮を無効にします。）

次の例では、圧縮を有効にします。

switch(config)# telemetry
switch(config-telemetry)# destination-profile
switch(config-tm-dest-profile)# use-compression gzip

次の例は、圧縮が有効になっていることを表示しています。

switch(conf-tm-dest)# show telemetry transport 0 stats

Session Id:                    0
Connection Stats
Connection Count            0
Last Connected:             Never
Disconnect Count            0
Last Disconnected:          Never
Transmission Stats
Compression:                gzip

Transmit Count:             0
Last TX time:               None
Min Tx Time:                0                   ms
Max Tx Time:                0                   ms
Avg Tx Time:                0                   ms
Cur Tx Time:                0                   ms

switch2(config-if)# show telemetry transport 0 stats

Session Id: 0
Connection Stats
Connection Count 0
Last Connected: Never
Disconnect Count 0
Last Disconnected: Never
Transmission Stats
Compression: disabled
Source Interface: loopback1(1.1.3.4)
Transmit Count: 0
Last TX time: None
Min Tx Time: 0 ms
Max Tx Time: 0 ms
Avg Tx Time: 0 ms
Cur Tx Time: 0 ms
switch2(config-if)#

以下は、POST ペイロードとしての use-compression の例です。

{
"telemetryDestProfile": {
"attributes": {
"adminSt": "enabled"
},
"children": [
{
"telemetryDestOptCompression": {
"attributes": {
"name": "gzip"
}
}
}
]
}
}

NX-API センサー パスの制限

NX-API は、show コマンドを使用して、DME にまだ存在しないスイッチ情報を収集してストリーミングできます。ただし、DME からデータをストリーミングする代わりに NX-API を使用すると、次に示すように、固有の拡張制限があります。

- スイッチ バックエンドは、show コマンドなどの NX-API 呼び出しを動的に処理します。

- NX-API は、CPU の最大 20% を消費する可能性のあるいくつかのプロセスを生成します。

- NX-API データは、CLI から XML、JSON に変換されます。

以下は、過度の NX-API センサー パス帯域幅消費を制限するのに役立つ推奨ユーザー フローです。

1. show コマンドが NX-API をサポートしているかどうかを確認します。パイプ オプションを使用して、NX-API が VSH からのコマンドをサポートしているかどうかを確認できます：<command> | json または<command> | json pretty。

（注）

スイッチが JSON 出力を返すまでに 30 秒以上かかるコマンドは避けてください。

2. フィルタまたはオプションを含めるように show コマンドを調整します。

- 個々の出力に対して同じコマンドを列挙することは避けてください。つまり、show vlan 識別子 100、show vlan 識別子 101 などです。代わりに、CLI 範囲オプションを使用してください。つまり、パフォーマンスを向上させるために可能な限り、VLAN 識別子 100-110、204 を表示します。

サマリー / カウンターのみが必要な場合は、show コマンド出力全体をダンプして、データ収集に必要な帯域幅とデータ ストレージを制限しないようにします。

3. NX-API をデータ送信元として使用するセンサー グループでテレメトリを構成します。show コマンドをセンサー パスとして追加する

4. CPI の使用を制限するために、それぞれの show コマンドの処理時間の 5 倍の周期でテレメトリを構成します。

5. ストリーミングされた NX-API 出力を既存の DME コレクションの一部として受信して処理します。

テレメトリの VRF サポート

Cisco NX-OS 7.0（3）I7（1）以降、テレメトリ VRF サポートにより、トランスポート VRF を指定できます。これは、テレメトリ データ ストリームがフロント パネルのポートを介して送信され、SSH / NGINX 制御セッション間の競合の可能性を回避できることを意味します。

use-vrf vrf-name コマンドを使用して、トランスポート VRF を指定できます。

次の例では、トランスポート VRF を指定しています。

switch(config)# telemetry
switch(config-telemetry)# destination-profile
switch(config-tm-dest-profile)# use-vrf test_vrf

以下は、POST ペイロードとしての use-vrf の例です。

{
"telemetryDestProfile": {
"attributes": {
"adminSt": "enabled"
},
"children": [
{
"telemetryDestOptVrf": {
"attributes": {
"name": "default"
}
}
}
]
}
}

NX-OS CLI を使用したテレメトリの構成

次の手順では、ストリーミング テレメトリを有効にし、データ ストリームの送信元と接続先を構成します。これらの手順には、SSL/TLS 証明書と GPB エンコーディングを有効にして構成するオプションの手順も含まれています。

始める前に

スイッチは、Cisco NX-OS リリース 7.3(0)I5(1) 以降のリリースを実行している必要があります。

手順

ステップ 1

（任意） openssl argument

データを受信するサーバー上に SSL または TLS 証明書を作成します。ここで、private.key ファイルは秘密キーであり、public.crt は公開キーです。

例:

次のような特定の引数を使用して、SSL/TLS 証明書を生成します。

- RSA 秘密キーを生成するには： openssl genrsa -cipher -out filename.key cipher-bit-length

例：

switch# openssl genrsa -des3 -out server.key 2048

- RSA キーを作成するには：openssl rsa -in filename.key -out filename.key

例：

switch# openssl rsa -in server.key -out server.key

- 公開キーまたは秘密キーを含む証明書を作成するには、次の手順を実行します：openssl req

-encoding-standard filename.key filename.csr -new -new -out -subj '/CN=localhost'

例：

switch# openssl req -sha256 -new -key server.key -out server.csr
-subj '/CN=localhost'

- 公開キーを作成するには：openssl x509 -req -encoding-standard -days timeframe -in filename.csr -signkey filename.key -out filename.csr

例：

switch# openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key
-out server.crt

ステップ 2

configure terminal

グローバル構成モードを開始します。

例:

switch# configure terminal
switch(config)#

ステップ 3

feature telemetry

ストリーミング テレメトリ機能を有効にします。

ステップ 4

feature nxapi

NX-API を有効にします。

ステップ 5

nxapi use-vrf management

NX-API 通信に使用する VRF 管理を有効にします。

（注）

ACL はネットスタックパケットのみをフィルタ処理できるため、10.2（3）F より前のリリースでは次の意味の警告が表示されます：

「警告：構成された管理 ACL は、HTTP サービスでは有効になりません。iptables を使用してアクセスを制限してください」。

（注）

10.2(3)F 以降、ACL は、管理 vrf に着信する netstack パケットと kstack パケットの両方をフィルタリングできます。次の意味の警告が表示されます：

「警告：非管理 VRF で構成された ACL は、その VRF の HTTP サービスでは有効になりません」。

例:

switch(config)#
switch(config)# nxapi use-vrf management
switch(config)#

ステップ 6

telemetry

ストリーミング テレメトリの構成モードに入ります。

例:

switch(config)# telemetry
switch(config-telemetry)#

ステップ 7

（任意） certificate certificate_path host_URL

既存の SSL/TLS 証明書を使用します。

EOR デバイスの場合、証明書もスタンバイ SUP にコピーする必要があります。

例:

switch(config-telemetry)# certificate /bootflash/server.key localhost

ステップ 8

（任意） トランスポート VRF を指定するか、gRPC トランスポートのテレメトリ圧縮を有効にします。

- destination-profile コマンドを入力して、デフォルトの接続先プロファイルを指定します。

- 次のコマンドを任意で入力します。

- use-vrf vrf で接続先 VRF を指定します。

- use-compression gzip を使用して、接続先の圧縮方法を指定します。

（注）

use-vrf コマンドを構成した後、新しい VRF 内に新しい接続先 IP アドレスを構成する必要があります。ただし、接続先を構成解除して再構成することにより、同じ接続先 IP アドレスを再利用できます。このアクションにより、テレメトリ データは新しい VRF でも同じ接続先 IP アドレスにストリーミングされます。

例:

switch(config-telemetry)# destination-profile
switch(conf-tm-dest-profile)# use-vrf default
switch(conf-tm-dest-profile)# use-compression gzip

ステップ 9

sensor-group sgrp_id

ID srgp_id を持つセンサー グループを作成し、センサー グループ構成モードを開始します。

現在は、数字の ID 値のみサポートされています。センサー グループでは、テレメトリ レポートのモニタリング対象ノードを定義します。

例:

switch(config-telemetry)# sensor-group 100
switch(conf-tm-sensor)#

ステップ 10

（任意） data-source data-source-type

データ ソースを選択します。データ ソースとして DME または NX-API のいずれかを選択します。

（注）

DME はデフォルトのデータ ソースです。

例:

switch(config-telemetry)# data-source NX-API

ステップ 11

path sensor_path depth unbounded [filter-condition filter] [alias path_alias]

ここでの制限なしとは、出力に子管理対象オブジェクト（MO）を含めることを意味します。したがって、POLL テレメトリ ストリームの場合、そのパスと EVENT のすべての子 MO が子 MO で行われた変更を取得します。

（注）

これは、データ送信元 DME パスにのみ適用されます。

センサー グループにセンサー パスを追加します。

- depth 設定では、センサー パスの取得レベルを指定します。0 - 32 、unbounded の深さ設定がサポートされています。

（注）

depth 0 デフォルトの深さです。

NX-API ベースのセンサー パスは、depth 0 のみを使用できます。

イベント収集のパスがサブスクライブされている場合、深さは 0 とバウンドなしのみをサポートします。その他の値は 0 として扱われます。

- オプションの filter-condition パラメータを指定して、イベントベースのサブスクリプション用の特定のフィルタを作成できます。

状態ベースのフィルタ処理の場合、フィルタ処理は、状態が変化したときと、指定された状態でイベントが発生したときの両方を返します。つまり、eq(l2Bd.operSt, "down") の DN sys/bd/bd-[vlan] のフィルタ条件は、operSt が変更されたとき、および operSt が down である間に DN のプロパティが変更されたとき（VLAN が動作上 down である間に no shutdown コマンドが発行された場合など）にトリガーされます。

（注）

query-condition パラメータ — DME の場合、DN に基づいて、次の構文で MOTL および一時データをフェッチするために query-condition パラメータを指定できます。クエリ条件「rsp-foreign-subtree=ephemeral」。

例:

- 次のコマンドは、NX-API ではなく、DME に適用されます：

switch(conf-tm-sensor)# path sys/bd/bd-[vlan-100] depth 0
filter-condition eq(l2BD.operSt, "down")

以下の構文を使用し、状態ベースのフィルタリングを使用して、operSt が up から down に変化したときにのみトリガーするようにします。MO が変化しても通知しません。

switch(conf-tm-sensor)# path sys/bd/bd-[vlan-100] depth 0
filter-condition and(updated(l2BD.operSt),eq(l2BD.operSt,"down"))

- 次のコマンドは、DME ではなく、NX-API に適用されます：

switch(conf-tm-sensor)# path "show interface" depth 0

ステップ 12

destination-group dgrp_id

接続先グループを作成して、接続先グループ構成モードを開始します。

現在、dgrp_id は、数字の ID 値のみをサポートしています。

例:

switch(conf-tm-sensor)# destination-group 100
switch(conf-tm-dest)#

ステップ 13

（任意） ip address ip_address port port protocol procedural-protocol encoding encoding-protocol

エンコードされたテレメトリ データを受信する IPv4 IP アドレスとポートを指定します。

（注）

gRPC はデフォルトのトランスポート プロトコルです。

GPB がデフォルトのエンコーディングです。

例:

switch(conf-tm-sensor)# ip address 171.70.55.69 port 50001 protocol gRPC encoding GPB
switch(conf-tm-sensor)# ip address 171.70.55.69 port 50007 protocol HTTP encoding JSON

switch(conf-tm-sensor)# ip address 171.70.55.69 port 50009 protocol UDP encoding JSON

ステップ 14

ip_version address ip_address port portnum

発信データの接続先プロファイルを作成します。

接続先グループがサブスクリプションにリンクされている場合、テレメトリ データは、このプロファイルで指定されている IP アドレスとポートに送信されます。

例:

- IPv4 の場合：

switch(conf-tm-dest)# ip address 1.2.3.4 port 50003

ステップ 15

subscription sub_id

ID を持つサブスクリプション ノードを作成し、サブスクリプション構成モードを開始します。

現在、sub_id は、数字の ID 値のみをサポートしています。

（注）

DN にサブスクライブする場合は、イベントが確実にストリーミングされるように、その DN が REST を使用して DME でサポートされているかどうかを確認します。

例:

switch(conf-tm-dest)# subscription 100
switch(conf-tm-sub)#

ステップ 16

snsr-grp sgrp_id sample-interval interval

ID sgrp_id のセンサー グループを現在のサブスクリプションにリンクして、データのサンプリング間隔（ミリ秒単位）を設定します。

間隔の値が 0 の場合、イベント ベースのサブスクリプションが作成され、テレメトリ データは、指定された MO での変更時にのみ送信されます。0 より大きい間隔値の場合、テレメトリ データが指定された間隔で定期的に送信される頻度に基いたサブスクリプションが作成されます。たとえば、間隔値が 15000 の場合、テレメトリ データは 15 秒ごとに送信されます。

例:

switch(conf-tm-sub)# snsr-grp 100 sample-interval 15000

ステップ 17

dst-grp dgrp_id

ID dgrp_id を持つ接続先グループをこのサブスクリプションにリンクします。

例:

switch(conf-tm-sub)# dst-grp 100

CLI を使用したテレメトリの構成例

次の手順では、GPB エンコーディングを使用して 10 秒のリズムで単一のテレメトリ DME ストリームを構成する方法について説明します。

switch# configure terminal
switch(config)# feature telemetry
switch(config)# telemetry
switch(config-telemetry)# destination-group 1
switch(config-tm-dest)# ip address 171.70.59.62 port 50051 protocol gRPC encoding GPB
switch(config-tm-dest)# exit
switch(config-telemetry)# sensor group sg1
switch(config-tm-sensor)# data-source DME
switch(config-tm-dest)# path interface depth unbounded query-condition keep-data-type
switch(config-tm-dest)# subscription 1
switch(config-tm-dest)# dst-grp 1
switch(config-tm-dest)# snsr grp 1 sample interval 10000

この例では、sys/bgp ルート MO のデータを宛先 IP 1.2.3.4 ポート 50003 に 5 秒ごとにストリーミングするサブスクリプションを作成します。

switch(config)# telemetry
switch(config-telemetry)# sensor-group 100
switch(conf-tm-sensor)# path sys/bgp depth 0
switch(conf-tm-sensor)# destination-group 100
switch(conf-tm-dest)# ip address 1.2.3.4 port 50003
switch(conf-tm-dest)# subscription 100
switch(conf-tm-sub)# snsr-grp 100 sample-interval 5000
switch(conf-tm-sub)# dst-grp 100

次に、sys/intf のデータを 5 秒ごとに、宛先 IP 1.2.3.4 ポート 50003 にストリーミングし、test.pem を使用して検証された GPB エンコーディングを使用してストリームを暗号化するサブスクリプションの作成例を示します。

switch(config)# telemetry
switch(config-telemetry)# certificate /bootflash/test.pem foo.test.google.fr
switch(conf-tm-telemetry)# destination-group 100
switch(conf-tm-dest)# ip address 1.2.3.4 port 50003 protocol gRPC encoding GPB
switch(config-dest)# sensor-group 100
switch(conf-tm-sensor)# path sys/bgp depth 0
switch(conf-tm-sensor)# subscription 100
switch(conf-tm-sub)# snsr-grp 100 sample-interval 5000
switch(conf-tm-sub)# dst-grp 100

この例では、sys/cdp のデータを接続先 IP 1.2.3.4 ポート 50004 に 15 秒ごとにストリーミングするサブスクリプションを作成します。

switch(config)# telemetry
switch(config-telemetry)# sensor-group 100
switch(conf-tm-sensor)# path sys/cdp depth 0
switch(conf-tm-sensor)# destination-group 100
switch(conf-tm-dest)# ip address 1.2.3.4 port 50004
switch(conf-tm-dest)# subscription 100
switch(conf-tm-sub)# snsr-grp 100 sample-interval 15000
switch(conf-tm-sub)# dst-grp 100

この例では、750 秒ごとに show コマンド データのケイデンス ベースのコレクションを作成します。

switch(config)# telemetry
switch(config-telemetry)# destination-group 1
switch(conf-tm-dest)# ip address 172.27.247.72 port 60001 protocol gRPC encoding GPB
switch(conf-tm-dest)# sensor-group 1
switch(conf-tm-sensor# data-source NX-API
switch(conf-tm-sensor)# path "show system resources" depth 0
switch(conf-tm-sensor)# path "show version" depth 0
switch(conf-tm-sensor)# path "show environment power" depth 0
switch(conf-tm-sensor)# path "show environment fan" depth 0
switch(conf-tm-sensor)# path "show environment temperature" depth 0
switch(conf-tm-sensor)# path "show process cpu" depth 0
switch(conf-tm-sensor)# path "show nve peers" depth 0
switch(conf-tm-sensor)# path "show nve vni" depth 0
switch(conf-tm-sensor)# path "show nve vni 4002 counters" depth 0
switch(conf-tm-sensor)# path "show int nve 1 counters" depth 0
switch(conf-tm-sensor)# path "show policy-map vlan" depth 0
switch(conf-tm-sensor)# path "show ip access-list test" depth 0
switch(conf-tm-sensor)# path "show system internal access-list resource utilization" depth 0
switch(conf-tm-sensor)# subscription 1
switch(conf-tm-sub)# dst-grp 1
switch(conf-tm-dest)# snsr-grp 1 sample-interval 750000

この例では、sys/fm のイベント ベースのサブスクリプションを作成します。sys/fm MO に変更がある場合にのみ、データは接続先にストリーミングされます。

switch(config)# telemetry
switch(config-telemetry)# sensor-group 100
switch(conf-tm-sensor)# path sys/fm depth 0
switch(conf-tm-sensor)# destination-group 100
switch(conf-tm-dest)# ip address 1.2.3.4 port 50005
switch(conf-tm-dest)# subscription 100
switch(conf-tm-sub)# snsr-grp 100 sample-interval 0
switch(conf-tm-sub)# dst-grp 100

動作中に、サンプル間隔を変更することで、センサー グループを周波数ベースからイベント ベースに変更したり、イベント ベースから周波数ベースに変更したりできます。この例では、センサー グループを前の例から頻度ベースに変更します。次のコマンドの後、テレメトリ アプリケーションは 7 秒ごとに sys/fm データの接続先へのストリーミングを開始します。

switch(config)# telemetry
switch(config-telemetry)# subscription 100
switch(conf-tm-sub)# snsr-grp 100 sample-interval 7000

複数のセンサー グループと接続先を 1 つのサブスクリプションにリンクできます。この例のサブスクリプションは、イーサネット ポート 1 / 1 のデータを 4 つの異なる接続先に 10 秒ごとにストリーミングします。

switch(config)# telemetry
switch(config-telemetry)# sensor-group 100
switch(conf-tm-sensor)# path sys/intf/phys-[eth1/1] depth 0
switch(conf-tm-sensor)# destination-group 100
switch(conf-tm-dest)# ip address 1.2.3.4 port 50004
switch(conf-tm-dest)# ip address 1.2.3.4 port 50005
switch(conf-tm-sensor)# destination-group 200
switch(conf-tm-dest)# ip address 5.6.7.8 port 50001 protocol HTTP encoding JSON
switch(conf-tm-dest)# ip address 1.4.8.2 port 60003
switch(conf-tm-dest)# subscription 100
switch(conf-tm-sub)# snsr-grp 100 sample-interval 10000
switch(conf-tm-sub)# dst-grp 100
switch(conf-tm-sub)# dst-grp 200

次に、センサー グループに複数のパスを含め、接続先グループに複数の接続先プロファイルを含め、サブスクリプションを複数のセンサー グループと宛先グループにリンクできる例を表示します。

switch(config)# telemetry
switch(config-telemetry)# sensor-group 100
switch(conf-tm-sensor)# path sys/intf/phys-[eth1/1] depth 0
switch(conf-tm-sensor)# path sys/epId-1 depth 0
switch(conf-tm-sensor)# path sys/bgp/inst/dom-default depth 0

switch(config-telemetry)# sensor-group 200
switch(conf-tm-sensor)# path sys/cdp depth 0
switch(conf-tm-sensor)# path sys/ipv4 depth 0

switch(config-telemetry)# sensor-group 300
switch(conf-tm-sensor)# path sys/fm depth 0
switch(conf-tm-sensor)# path sys/bgp depth 0

switch(conf-tm-sensor)# destination-group 100
switch(conf-tm-dest)# ip address 1.2.3.4 port 50004
switch(conf-tm-dest)# ip address 4.3.2.5 port 50005

switch(conf-tm-dest)# destination-group 200
switch(conf-tm-dest)# ip address 5.6.7.8 port 50001

switch(conf-tm-dest)# destination-group 300
switch(conf-tm-dest)# ip address 1.2.3.4 port 60003

switch(conf-tm-dest)# subscription 600
switch(conf-tm-sub)# snsr-grp 100 sample-interval 7000
switch(conf-tm-sub)# snsr-grp 200 sample-interval 20000
switch(conf-tm-sub)# dst-grp 100
switch(conf-tm-sub)# dst-grp 200

switch(conf-tm-dest)# subscription 900
switch(conf-tm-sub)# snsr-grp 200 sample-interval 7000
switch(conf-tm-sub)# snsr-grp 300 sample-interval 0
switch(conf-tm-sub)# dst-grp 100
switch(conf-tm-sub)# dst-grp 300

この例に示すように、show running-config telemetry コマンドを使用してテレメトリ構成を確認できます。

switch(config)# telemetry
switch(config-telemetry)# destination-group 100
switch(conf-tm-dest)# ip address 1.2.3.4 port 50003
switch(conf-tm-dest)# ip address 1.2.3.4 port 50004
switch(conf-tm-dest)# end
switch# show run telemetry

!Command: show running-config telemetry
!Time: Thu Oct 13 21:10:12 2016

version 7.0(3)I5(1)
feature telemetry

telemetry
destination-group 100
ip address 1.2.3.4 port 50003 protocol gRPC encoding GPB
ip address 1.2.3.4 port 50004 protocol gRPC encoding GPB

この例に示すように、use-vrf コマンドと use-compression gzip コマンドを使用して、gRPC のトランスポート VRF とテレメトリ データ圧縮を指定できます。

switch(config)# telemetry
switch(config-telemetry)# destination-profile
switch(conf-tm-dest-profile)# use-vrf default
switch(conf-tm-dest-profile)# use-compression gzip
switch(conf-tm-dest-profile)# sensor-group 1
switch(conf-tm-sensor)# path sys/bgp depth unbounded
switch(conf-tm-sensor)# destination-group 1
switch(conf-tm-dest)# ip address 1.2.3.4 port 50004
switch(conf-tm-dest)# subscription 1
switch(conf-tm-sub)# dst-grp 1
switch(conf-tm-sub)# snsr-grp 1 sample-interval 10000

テレメトリの構成と統計情報の表示

次の NX-OS CLI show コマンドを使用して、テレメトリの構成、統計情報、エラー、およびセッション情報を表示します。

show telemetry control database

次に、テレメトリの構成を反映している内部データベースのコマンドを表示します。

switch# show telemetry control database ?
<CR>
>                   Redirect it to a file
>>                  Redirect it to a file in append mode
destination-groups  Show destination-groups
destinations        Show destinations
sensor-groups       Show sensor-groups
sensor-paths        Show sensor-paths
subscriptions       Show subscriptions
|                   Pipe command output to filter

switch# show telemetry control database

Subscription Database size = 1

--------------------------------------------------------------------------------
Subscription ID      Data Collector Type
--------------------------------------------------------------------------------
100                  DME NX-API

Sensor Group Database size = 1

--------------------------------------------------------------------------------
Sensor Group ID  Sensor Group type  Sampling interval(ms)  Linked subscriptions
--------------------------------------------------------------------------------
100              Timer              10000(Running)         1

Sensor Path Database size = 1

--------------------------------------------------------------------------------
Subscribed Query Filter  Linked Groups  Sec Groups  Retrieve level  Sensor Path
--------------------------------------------------------------------------------
No                       1              0           Full            sys/fm

Destination group Database size = 2

--------------------------------------------------------------------------------
Destination Group ID  Refcount
--------------------------------------------------------------------------------
100                   1

Destination Database size = 2

--------------------------------------------------------------------------------
Dst IP Addr     Dst Port   Encoding   Transport  Count
--------------------------------------------------------------------------------
192.168.20.111       12345      JSON       HTTP       1
192.168.20.123    50001      GPB        gRPC       1

show telemetry control stats

このコマンドは、テレメトリの構成についての内部データベースの統計を表示します。

switch# show telemetry control stats
show telemetry control stats entered

--------------------------------------------------------------------------------
Error Description                                            Error Count
--------------------------------------------------------------------------------
Chunk allocation failures                                    0
Sensor path Database chunk creation failures                 0
Sensor Group Database chunk creation failures                0
Destination Database chunk creation failures                 0
Destination Group Database chunk creation failures           0
Subscription Database chunk creation failures                0
Sensor path Database creation failures                       0
Sensor Group Database creation failures                      0
Destination Database creation failures                       0
Destination Group Database creation failures                 0
Subscription Database creation failures                      0
Sensor path Database insert failures                         0
Sensor Group Database insert failures                        0
Destination Database insert failures                         0
Destination Group Database insert failures                   0
Subscription insert to Subscription Database failures        0
Sensor path Database delete failures                         0
Sensor Group Database delete failures                        0
Destination Database delete failures                         0
Destination Group Database delete failures                   0
Delete Subscription from Subscription Database failures      0
Sensor path delete in use                                    0
Sensor Group delete in use                                   0
Destination delete in use                                    0
Destination Group delete in use                              0
Delete destination(in use) failure count                     0
Failed to get encode callback                                0
Sensor path Sensor Group list creation failures              0
Sensor path prop list creation failures                      0
Sensor path sec Sensor path list creation failures           0
Sensor path sec Sensor Group list creation failures          0
Sensor Group Sensor path list creation failures              0
Sensor Group Sensor subs list creation failures              0
Destination Group subs list creation failures                0
Destination Group Destinations list creation failures        0
Destination Destination Groups list creation failures        0
Subscription Sensor Group list creation failures             0
Subscription Destination Groups list creation failures       0
Sensor Group Sensor path list delete failures                0
Sensor Group Subscriptions list delete failures              0
Destination Group Subscriptions list delete failures         0
Destination Group Destinations list delete failures          0
Subscription Sensor Groups list delete failures              0
Subscription Destination Groups list delete failures         0
Destination Destination Groups list delete failures          0
Failed to delete Destination from Destination Group          0
Failed to delete Destination Group from Subscription         0
Failed to delete Sensor Group from Subscription              0
Failed to delete Sensor path from Sensor Group               0
Failed to get encode callback                                0
Failed to get transport callback                             0
switch#  Destination Database size = 1

--------------------------------------------------------------------------------
Dst IP Addr     Dst Port   Encoding   Transport  Count
--------------------------------------------------------------------------------
192.168.20.123    50001      GPB        gRPC       1

show telemetry data collector brief

このコマンドは、データ収集に関する簡略化した統計情報を表示します。

switch# show telemetry data collector brief

----------------------------------------------------------------------
Collector Type       Successful Collections     Failed Collections
----------------------------------------------------------------------
DME                   143                        0

show telemetry data collector details

このコマンドは、すべてのセンサー パスの詳細を含む、データ収集に関する詳細な統計情報を表示します。

switch# show telemetry data collector details

--------------------------------------------------------------------------------
Succ Collections      Failed Collections     Sensor Path
--------------------------------------------------------------------------------
150                   0                      sys/fm

show telemetry event collector errors

このコマンドは、イベント収集に関するエラー統計情報を表示します。

switch# show telemetry event collector errors

--------------------------------------------------------------------------------
Error Description                                  Error Count
--------------------------------------------------------------------------------
APIC-Cookie Generation Failures                    - 0
Authentication Failures                            - 0
Authentication Refresh Failures                    - 0
Authentication Refresh Timer Start Failures        - 0
Connection Timer Start Failures                    - 0
Connection Attempts                                - 3
Dme Event Subscription Init Failures               - 0
Event Data Enqueue Failures                        - 0
Event Subscription Failures                        - 0
Event Subscription Refresh Failures                - 0
Pending Subscription List Create Failures          - 0
Subscription Hash Table Create Failures            - 0
Subscription Hash Table Destroy Failures           - 0
Subscription Hash Table Insert Failures            - 0
Subscription Hash Table Remove Failures            - 0
Subscription Refresh Timer Start Failures          - 0
Websocket Connect Failures                         - 0

show telemetry event collector stats

このコマンドは、すべてのセンサー パスの内訳を含むイベント収集に関する統計情報を表示します。

switch# show telemetry event collector stats

--------------------------------------------------------------------------------
Collection Count  Latest Collection Time    Sensor Path
--------------------------------------------------------------------------------

show telemetry control pipeline stats

このコマンドは、テレメトリ パイプラインの統計情報を表示します。

switch# show telemetry pipeline stats
Main Statistics:
Timers:
Errors:
Start Fail        =     0

Data Collector:
Errors:
Node Create Fail  =     0

Event Collector:
Errors:
Node Create Fail  =     0    Node Add Fail     =     0
Invalid Data      =     0

Memory:
Allowed Memory Limit                = 1181116006 bytes
Occupied Memory                     = 93265920 bytes

Queue Statistics:
Request Queue:
High Priority Queue:
Info:
Actual Size       =    50    Current Size      =     0
Max Size          =     0    Full Count        =     0

Errors:
Enqueue Error     =     0    Dequeue Error     =     0

Low Priority Queue:
Info:
Actual Size       =    50    Current Size      =     0
Max Size          =     0    Full Count        =     0

Errors:
Enqueue Error     =     0    Dequeue Error     =     0

Data Queue:
High Priority Queue:
Info:
Actual Size       =    50    Current Size      =     0
Max Size          =     0    Full Count        =     0

Errors:
Enqueue Error     =     0    Dequeue Error     =     0

Low Priority Queue:
Info:
Actual Size       =    50    Current Size      =     0
Max Size          =     0    Full Count        =     0

Errors:
Enqueue Error     =     0    Dequeue Error     =     0

show telemetry transport

次に、構成されているすべての転送セッションの例を表示します。

switch# show telemetry transport

Session Id      IP Address      Port       Encoding   Transport  Status
-----------------------------------------------------------------------------------
0               192.168.20.123   50001      GPB        gRPC       Connected

show telemetry transport の構文の説明

構文

説明

show

実行中のシステム情報を表示します。

telemetry

テレメトリ情報を表示します

トランスポート

テレメトリのトランスポート情報を表示します。

session_id

（オプション）セッション ID

stats

（オプション）すべてのテレメトリ統計情報を表示します。

errors

（オプション）すべてのテレメトリ エラー情報を表示します。

読み取り専用

（オプション）

TABLE_transport_info

（オプション）トランスポート情報

session_idx

（オプション）セッション ID

ip_address

（オプション）トランスポート IP アドレス

port

（任意）トランスポート ポート

dest_info

（オプション）接続先情報

encoding_type

（オプション）エンコーディング タイプ

transport_type

（オプション）トランスポート タイプ

transport_status

（オプション）トランスポート ステータス

transport_security_cert_fname

（オプション）トランスポート セキュリティ ファイル名

transport_last_connected

（オプション）最後に接続されたトランスポート

transport_last_disconnected

（オプション）この宛先構成が最後に削除された時刻

transport_errors_count

（オプション）トランスポート エラー数

transport_last_tx_error

（オプション）トランスポートの最後の送信エラー

transport_statistics

（オプション）トランスポート統計情報

t_session_id

（オプション）トランスポート セッション ID

connect_statistics

（オプション）接続統計情報

connect_count

（オプション）接続数

last_connected

（オプション）最終接続のタイムスタンプ

Disconnect_count

（オプション）切断数

last_disconnected

（オプション）この宛先構成が最後に削除された時刻

trans_statistics

（オプション）トランスポート統計情報

compression

（オプション）圧縮ステータス

source_interface_name

（オプション）送信元インターフェイス名

source_interface_ip

（オプション）送信元インターフェイス IP

transmit_count

（オプション）送信数

last_tx_time

（オプション）最終送信時刻

min_tx_time

（オプション）最小送信時間

max_tx_time

（オプション）最大送信時間

avg_tx_time

（オプション）平均送信時間

cur_tx_time

（オプション）現在の送信時間

transport_errors

（オプション）トランスポート エラー

connect_errors

（オプション）接続エラー

connect_errors_count

（オプション）接続エラー数

trans_errors

（オプション）トランスポート エラー

trans_errors_count

（オプション）トランスポート エラー数

last_tx_error

（オプション）最後のトランスポート エラー

last_tx_return_code

（オプション）最後の送信戻りコード

transport_retry_stats

（オプション）再試行統計情報

ts_event_retry_bytes

（オプション）イベント再試行バッファ サイズ

ts_timer_retry_bytes

（オプション）タイマー再試行バッファ サイズ

ts_event_retry_size

（オプション）イベント再試行メッセージ数

ts_timer_retry_size

（オプション）タイマー再試行メッセージ数

ts_retries_sent

（オプション）送信された再試行回数

ts_retries_dropped

（オプション）ドロップされた再試行回数

event_retry_bytes

（オプション）イベント再試行バッファ サイズ

timer_retry_bytes

（オプション）タイマー再試行バッファ サイズ

retries_sent

（オプション）送信された再試行回数

retries_dropped

（オプション）ドロップされた再試行回数

retry_buffer_size

（オプション）再試行バッファ サイズ

show telemetry transport <session-id>

次のコマンドでは、特定の転送セッションの詳細なセッション情報が表示されます。

switch# show telemetry transport 0

Session Id:          0
IP Address:Port      192.168.20.123:50001
Transport:           gRPC
Status:              Disconnected
Last Connected:      Fri Sep 02 11:45:57.505 UTC
Last Disconnected:   Never
Tx Error Count:      224
Last Tx Error:       Fri Sep 02 12:23:49.555 UTC

switch# show telemetry transport 1

Session Id:          1
IP Address:Port      10.30.218.56:51235
Transport:           HTTP
Status:              Disconnected
Last Connected:      Never
Last Disconnected:   Never
Tx Error Count:      3
Last Tx Error:       Wed Apr 19 15:56:51.617 PDT

show telemetry transport <session-id> stats

次に、特定の転送セッションの詳細のコマンドを示します。

Session Id:                    0
Transmission Stats
Compression:                disabled
Source Interface:           not set()
Transmit Count:             319297
Last TX time:               Fri Aug 02 03:51:15.287 UTC
Min Tx Time:                1                   ms
Max Tx Time:                3117                ms
Avg Tx Time:                3                   ms
Cur Tx Time:                1                   ms

show telemetry transport <session-id> errors

次のコマンドでは、特定の転送セッションの詳細なエラーの統計情報が表示されます。

switch# show telemetry transport 0 errors
Session Id:                 0
Connection Errors
Connection Error Count:     0
Transmission Errors
Tx Error Count:             30
Last Tx Error:              Thu Aug 01 04:39:47.083 UTC
Last Tx Return Code:        No error

テレメトリ ログとトレース情報の表示

ログとトレース情報を表示するには、次の NX-OS CLI コマンドを使用します。

テクニカル サポート テレメトリを表示

この NX-OS CLI コマンドは、テクニカル サポート ログからテレメトリ ログの内容を収集します。この例では、コマンド出力がブートフラッシュのファイルにリダイレクトされます。

switch# show tech-support telemetry > bootflash:tmst.log

tmtrace.bin

この BASH シェル コマンドは、テレメトリ トレースを収集して出力します。

switch# configure terminal
switch(config)# feature bash
switch(config)# run bash
bash-4.2$ tmtrace.bin -d tm-errors
bash-4.2$ tmtrace.bin -d tm-logs
bash-4.2$ tmtrace.bin -d tm-events

例：

bash-4.2$ tmtrace.bin -d tm-logs
[01/25/17 22:52:24.563 UTC 1 29130] [3944724224][tm_ec_dme_auth.c:59] TM_EC: Authentication refresh url http://127.0.0.1/api/aaaRefresh.json
[01/25/17 22:52:24.565 UTC 2 29130] [3944724224][tm_ec_dme_rest_util.c:382] TM_EC: Performed POST request on http://127.0.0.1/api/aaaRefresh.json
[01/25/17 22:52:24.566 UTC 3 29130] [3944724224][tm_mgd_timers.c:114] TM_MGD_TIMER: Starting leaf timer for leaf:0x11e17ea4 time_in_ms:540000
[01/25/17 22:52:45.317 UTC 4 29130] [3944724224][tm_ec_dme_event_subsc.c:790] TM_EC: Event subscription database size 0
[01/25/17 22:52:45.317 UTC 5 29130] [3944724224][tm_mgd_timers.c:114] TM_MGD_TIMER: Starting leaf timer for leaf:0x11e17e3c time_in_ms:50000
bash-4.2#

（注）

tm-logs オプションは冗長であるため、デフォルトでは有効になっていません。

tmtrace.bin -LD tm-logs コマンドで tm-logs を有効にします。

tmtrace.bin -LW tm-logs コマンドを使用して tm-logs を無効にします。

show system internal telemetry trace

show system internal telemetry trace [tm-events | tm-errors |tm-logs | all] コマンドは、システムの内部テレメトリ トレース情報を表示します。

switch# show system internal telemetry trace all
Telemetry All Traces:
Telemetry Error Traces:
[07/26/17 15:22:29.156 UTC 1 28577] [3960399872][tm_cfg_api.c:367] Not able to destroy dest profile list for config node rc:-1610612714 reason:Invalid argument
[07/26/17 15:22:44.972 UTC 2 28577] [3960399872][tm_stream.c:248] No subscriptions for destination group 1
[07/26/17 15:22:49.463 UTC 3 28577] [3960399872][tm_stream.c:576] TM_STREAM: Subscriptoin 1 does not have any sensor groups

3 entries printed
Telemetry Event Traces:
[07/26/17 15:19:40.610 UTC 1 28577] [3960399872][tm_debug.c:41] Telemetry xostrace buffers initialized successfully!
[07/26/17 15:19:40.610 UTC 2 28577] [3960399872][tm.c:744] Telemetry statistics created successfully!
[07/26/17 15:19:40.610 UTC 3 28577] [3960399872][tm_init_n9k.c:97] Platform intf: grpc_traces:compression,channel
switch#

switch# show system internal telemetry trace tm-logs
Telemetry Log Traces:
0 entries printed
switch#
switch# show system internal telemetry trace tm-events
Telemetry Event Traces:
[07/26/17 15:19:40.610 UTC 1 28577] [3960399872][tm_debug.c:41] Telemetry xostrace buffers initialized successfully!
[07/26/17 15:19:40.610 UTC 2 28577] [3960399872][tm.c:744] Telemetry statistics created successfully!
[07/26/17 15:19:40.610 UTC 3 28577] [3960399872][tm_init_n9k.c:97] Platform intf: grpc_traces:compression,channel
[07/26/17 15:19:40.610 UTC 4 28577] [3960399872][tm_init_n9k.c:207] Adding telemetry to cgroup
[07/26/17 15:19:40.670 UTC 5 28577] [3960399872][tm_init_n9k.c:215] Added telemetry to cgroup successfully!

switch# show system internal telemetry trace tm-errors
Telemetry Error Traces:
0 entries printed
switch#

Configuring Telemetry Using the NX-API

In the object model of the switch DME, the configuration of the telemetry feature is defined in a hierarchical structure of objects as shown in the section "Telemetry Model in the DME." Following are the main objects to be configured:

- fmEntity — Contains the NX-API and Telemetry feature states.

- fmNxapi — Contains the NX-API state.

- fmTelemetry — Contains the Telemetry feature state.

- telemetryEntity — Contains the telemetry feature configuration.

- telemetrySensorGroup — Contains the definitions of one or more sensor paths or nodes to be monitored for telemetry. The telemetry entity can contain one or more sensor groups.

- telemetryRtSensorGroupRel — Associates the sensor group with a telemetry subscription.

- telemetrySensorPath — A path to be monitored. The sensor group can contain multiple objects of this type.

- telemetryDestGroup — Contains the definitions of one or more destinations to receive telemetry data. The telemetry entity can contain one or more destination groups.

- telemetryRtDestGroupRel — Associates the destination group with a telemetry subscription.

- telemetryDest — A destination address. The destination group can contain multiple objects of this type.

- telemetrySubscription — Specifies how and when the telemetry data from one or more sensor groups is sent to one or more destination groups.

- telemetryRsDestGroupRel — Associates the telemetry subscription with a destination group.

- telemetryRsSensorGroupRel — Associates the telemetry subscription with a sensor group.

- telemetryCertificate — Associates the telemetry subscription with a certificate and hostname.

To configure the telemetry feature using the NX-API, you must construct a JSON representation of the telemetry object structure and push it to the DME with an HTTP or HTTPS POST operation.

Note

For detailed instructions on using the NX-API, see the Cisco Nexus 3000 and 9000 Series NX-API REST SDK User Guide and API Reference.

Before you begin

Your switch must be running Cisco NX-OS Release 7.3(0)I5(1) or a later release.

Your switch must be configured to run the NX-API from the CLI:

switch(config)# feature nxapi

NX-API sends telemetry data over management VRF:

switch(config)# nxapi use-vrf management

Procedure

Step 1

Enable the telemetry feature.

The root element is fmTelemetry and the base path for this element is sys/fm. Configure the adminSt attribute as enabled.

Example:

{
"fmEntity" : {
"children" : [{
"fmTelemetry" : {
"attributes" : {
"adminSt" : "enabled"
}
}
}
]
}
}

Step 2

Create the root level of the JSON payload to describe the telemetry configuration.

The root element is telemetryEntity and the base path for this element is sys/tm. Configure the dn attribute as sys/tm.

Example:

{
"telemetryEntity": {
"attributes": {
"dn": "sys/tm"
},
}
}

Step 3

Create a sensor group to contain the defined sensor paths.

A telemetry sensor group is defined in an object of class telemetrySensorGroup . Configure the following attributes of the object:

- id — An identifier for the sensor group. Currently only numeric ID values are supported.

- rn — The relative name of the sensor group object in the format: sensor-id .

- dataSrc — Selects the data source from DEFAULT , DME , or NX-API .

Children of the sensor group object will include sensor paths and one or more relation objects (telemetryRtSensorGroupRel ) to associate the sensor group with a telemetry subscription.

Example:

"telemetrySensorGroup": {
"attributes": {
"id": "10",
"rn": "sensor-10"
"dataSrc": "NX-API"
},  "children": [{
}]
}

Step 4

(Optional) Add an SSL/TLS certificate and a host.

The telemetryCertificate defines the location of the SSL/TLS certificate with the telemetry subscription/destination.

Example:

{
"telemetryCertificate": {
"attributes": {
"filename": "root.pem"
"hostname": "c.com"
}
}
}

Step 5

Define a telemetry destination group.

A telemetry destination group is defined in telemetryEntity . Configure the id attribute.

Example:

{
"telemetryDestGroup": {
"attributes": {
"id": "20"
}
}
}

Step 6

Define a telemetry destination profile.

A telemetry destination profile is defined in telemetryDestProfile .

- Configure the adminSt attribute as enabled.

- Under telemetryDestOptSourceInterface , configure the name attribute with an interface name to stream data from the configured interface to a destination with the source IP address.

Example:

{
"telemetryDestProfile": {
"attributes": {
"adminSt": "enabled"
},
"children": [
{
"telemetryDestOptSourceInterface": {
"attributes": {
"name": "lo0"
}
}
}
]
}
}

Step 7

Define one or more telemetry destinations, consisting of an IP address and port number to which telemetry data will be sent.

A telemetry destination is defined in an object of class telemetryDest . Configure the following attributes of the object:

- addr — The IP address of the destination.

- port — The port number of the destination.

- rn — The relative name of the destination object in the format: path-[path] .

- enc — The encoding type of the telemetry data to be sent. NX-OS supports:

- Google protocol buffers (GPB) for gRPC.

- JSON for C.

- GPB or JSON for UDP and secure UDP (DTLS).

- proto — The transport protocol type of the telemetry data to be sent. NX-OS supports:

- gRPC

- HTTP

- VUDP and secure UDP (DTLS)

Example:

{
"telemetryDest": {
"attributes": {
"addr": "1.2.3.4",
"enc": "GPB",
"port": "50001",
"proto": "gRPC",
"rn": "addr-[1.2.3.4]-port-50001"
}
}
}

Step 8

Create a telemetry subscription to configure the telemetry behavior.

A telemetry subscription is defined in an object of class telemetrySubscription . Configure the following attributes of the object:

- id — An identifier for the subscription. Currently only numeric ID values are supported.

- rn — The relative name of the subscription object in the format: subs-id .

Children of the subscription object will include relation objects for sensor groups (telemetryRsSensorGroupRel ) and destination groups (telemetryRsDestGroupRel ).

Example:

"telemetrySubscription": {
"attributes": {
"id": "30",
"rn": "subs-30"
},  "children": [{
}]
}

Step 9

Add the sensor group object as a child object to the telemetrySubscription element under the root element (telemetryEntity ).

Example:

{
"telemetrySubscription": {
"attributes": {
"id": "30"
}
"children": [{
"telemetryRsSensorGroupRel": {
"attributes": {
"sampleIntvl": "5000",
"tDn": "sys/tm/sensor-10"
}
}
}
]
}
}

Step 10

Create a relation object as a child object of the subscription to associate the subscription to the telemetry sensor group and to specify the data sampling behavior.

The relation object is of class telemetryRsSensorGroupRel and is a child object of telemetrySubscription . Configure the following attributes of the relation object:

- rn — The relative name of the relation object in the format: rssensorGroupRel-[sys/tm/sensor-group-id] .

- sampleIntvl — The data sampling period in milliseconds. An interval value of 0 creates an event-based subscription, in which telemetry data is sent only upon changes under the specified MO. An interval value greater than 0 creates a frequency-based subscription, in which telemetry data is sent periodically at the specified interval. For example, an interval value of 15000 results in the sending of telemetry data every 15 seconds.

- tCl — The class of the target (sensor group) object, which is telemetrySensorGroup .

- tDn — The distinguished name of the target (sensor group) object, which is sys/tm/sensor-group-id .

- rType — The relation type, which is mo for managed object.

- tType — The target type, which is mo for managed object.

Example:

"telemetryRsSensorGroupRel": {
"attributes": {
"rType": "mo",
"rn": "rssensorGroupRel-[sys/tm/sensor-10]",
"sampleIntvl": "5000",
"tCl": "telemetrySensorGroup",
"tDn": "sys/tm/sensor-10",
"tType": "mo"
}
}

Step 11

Define one or more sensor paths or nodes to be monitored for telemetry.

A sensor path is defined in an object of class telemetrySensorPath . Configure the following attributes of the object:

- path — The path to be monitored.

- rn — The relative name of the path object in the format: path-[path]

- depth — The retrieval level for the sensor path. A depth setting of 0 retrieves only the root MO properties.

- filterCondition — (Optional) Creates a specific filter for event-based subscriptions. The DME provides the filter expressions. For more information regarding filtering, see the Cisco APIC REST API Usage Guidelines on composing queries: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-x/rest_cfg/2_1_x/b_Cisco_APIC_REST_API_Configuration_Guide/b_Cisco_APIC_REST_API_Configuration_Guide_chapter_01.html#d25e1534a1635

Example:

Single sensor path

{
"telemetrySensorPath": {
"attributes": {
"path": "sys/cdp",
"rn": "path-[sys/cdp]",
"excludeFilter": "",
"filterCondition": "",
"path": "sys/fm/bgp",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
}

Example:

Single sensor path for NX-API

{
"telemetrySensorPath": {
"attributes": {
"path": "show interface",
"path": "show bgp",
"rn": "path-[sys/cdp]",
"excludeFilter": "",
"filterCondition": "",
"path": "sys/fm/bgp",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
}

Example:

Multiple sensor paths

{
"telemetrySensorPath": {
"attributes": {
"path": "sys/cdp",
"rn": "path-[sys/cdp]",
"excludeFilter": "",
"filterCondition": "",
"path": "sys/fm/bgp",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
},
{
"telemetrySensorPath": {
"attributes": {
"excludeFilter": "",
"filterCondition": "",
"path": "sys/fm/dhcp",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
}

Example:

Single sensor path filtering for BGP disable events:

{
"telemetrySensorPath": {
"attributes": {
"path": "sys/cdp",
"rn": "path-[sys/cdp]",
"excludeFilter": "",
"filterCondition": "eq(fmBgp.operSt.\"disabled\")",
"path": "sys/fm/bgp",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
}

Step 12

Add sensor paths as child objects to the sensor group object (telemetrySensorGroup ).

Step 13

Add destinations as child objects to the destination group object (telemetryDestGroup ).

Step 14

Add the destination group object as a child object to the root element (telemetryEntity ).

Step 15

Create a relation object as a child object of the telemetry sensor group to associate the sensor group to the subscription.

The relation object is of class telemetryRtSensorGroupRel and is a child object of telemetrySensorGroup . Configure the following attributes of the relation object:

- rn — The relative name of the relation object in the format: rtsensorGroupRel-[sys/tm/subscription-id] .

- tCl — The target class of the subscription object, which is telemetrySubscription .

- tDn — The target distinguished name of the subscription object, which is sys/tm/subscription-id .

Example:

"telemetryRtSensorGroupRel": {
"attributes": {
"rn": "rtsensorGroupRel-[sys/tm/subs-30]",
"tCl": "telemetrySubscription",
"tDn": "sys/tm/subs-30"
}
}

Step 16

Create a relation object as a child object of the telemetry destination group to associate the destination group to the subscription.

The relation object is of class telemetryRtDestGroupRel and is a child object of telemetryDestGroup . Configure the following attributes of the relation object:

- rn — The relative name of the relation object in the format: rtdestGroupRel-[sys/tm/subscription-id] .

- tCl — The target class of the subscription object, which is telemetrySubscription .

- tDn — The target distinguished name of the subscription object, which is sys/tm/subscription-id .

Example:

"telemetryRtDestGroupRel": {
"attributes": {
"rn": "rtdestGroupRel-[sys/tm/subs-30]",
"tCl": "telemetrySubscription",
"tDn": "sys/tm/subs-30"
}
}

Step 17

Create a relation object as a child object of the subscription to associate the subscription to the telemetry destination group.

The relation object is of class telemetryRsDestGroupRel and is a child object of telemetrySubscription . Configure the following attributes of the relation object:

- rn — The relative name of the relation object in the format: rsdestGroupRel-[sys/tm/destination-group-id] .

- tCl — The class of the target (destination group) object, which is telemetryDestGroup .

- tDn — The distinguished name of the target (destination group) object, which is sys/tm/destination-group-id .

- rType — The relation type, which is mo for managed object.

- tType — The target type, which is mo for managed object.

Example:

"telemetryRsDestGroupRel": {
"attributes": {
"rType": "mo",
"rn": "rsdestGroupRel-[sys/tm/dest-20]",
"tCl": "telemetryDestGroup",
"tDn": "sys/tm/dest-20",
"tType": "mo"
}
}

Step 18

Send the resulting JSON structure as an HTTP/HTTPS POST payload to the NX-API endpoint for telemetry configuration.

The base path for the telemetry entity is sys/tm and the NX-API endpoint is:

{{URL}}/api/node/mo/sys/tm.json

Example

The following is an example of all the previous steps collected into one POST payload (note that some attributes may not match):

{
"telemetryEntity": {
"children": [{
"telemetrySensorGroup": {
"attributes": {
"id": "10"
}
"children": [{
"telemetrySensorPath": {
"attributes": {
"excludeFilter": "",
"filterCondition": "",
"path": "sys/fm/bgp",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
}
]
}
},
{
"telemetryDestGroup": {
"attributes": {
"id": "20"
}
"children": [{
"telemetryDest": {
"attributes": {
"addr": "10.30.217.80",
"port": "50051",
"enc": "GPB",
"proto": "gRPC"
}
}
}
]
}
},
{
"telemetrySubscription": {
"attributes": {
"id": "30"
}
"children": [{
"telemetryRsSensorGroupRel": {
"attributes": {
"sampleIntvl": "5000",
"tDn": "sys/tm/sensor-10"
}
}
},
{
"telemetryRsDestGroupRel": {
"attributes": {
"tDn": "sys/tm/dest-20"
}
}
}
]
}
}
]
}
}

NX-API を使用したテレメトリの構成例

宛先へのストリーミング パス

この例では、パス sys/cdp および sys/ipv4 を接続先 1.2.3.4 ポート 50001 に 5 秒ごとにストリーミングするサブスクリプションを作成します。

POST https://192.168.20.123/api/node/mo/sys/tm.json

Payload:
{
"telemetryEntity": {
"attributes": {
"dn": "sys/tm"
},
"children": [{
"telemetrySensorGroup": {
"attributes": {
"id": "10",
"rn": "sensor-10"
},  "children": [{
"telemetryRtSensorGroupRel": {
"attributes": {
"rn": "rtsensorGroupRel-[sys/tm/subs-30]",
"tCl": "telemetrySubscription",
"tDn": "sys/tm/subs-30"
}
}
}, {
"telemetrySensorPath": {
"attributes": {
"path": "sys/cdp",
"rn": "path-[sys/cdp]",
"excludeFilter": "",
"filterCondition": "",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
}, {
"telemetrySensorPath": {
"attributes": {
"path": "sys/ipv4",
"rn": "path-[sys/ipv4]",
"excludeFilter": "",
"filterCondition": "",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
}]
}
}, {
"telemetryDestGroup": {
"attributes": {
"id": "20",
"rn": "dest-20"
},
"children": [{
"telemetryRtDestGroupRel": {
"attributes": {
"rn": "rtdestGroupRel-[sys/tm/subs-30]",
"tCl": "telemetrySubscription",
"tDn": "sys/tm/subs-30"
}
}
}, {
"telemetryDest": {
"attributes": {
"addr": "1.2.3.4",
"enc": "GPB",
"port": "50001",
"proto": "gRPC",
"rn": "addr-[1.2.3.4]-port-50001"
}
}
}]
}
}, {
"telemetrySubscription": {
"attributes": {
"id": "30",
"rn": "subs-30"
},
"children": [{
"telemetryRsDestGroupRel": {
"attributes": {
"rType": "mo",
"rn": "rsdestGroupRel-[sys/tm/dest-20]",
"tCl": "telemetryDestGroup",
"tDn": "sys/tm/dest-20",
"tType": "mo"
}
}
}, {
"telemetryRsSensorGroupRel": {
"attributes": {
"rType": "mo",
"rn": "rssensorGroupRel-[sys/tm/sensor-10]",
"sampleIntvl": "5000",
"tCl": "telemetrySensorGroup",
"tDn": "sys/tm/sensor-10",
"tType": "mo"
}
}
}]
}
}]
}
}

BGP 通知のフィルタ条件

次のペイロードの例では、telemetrySensorPath MO の filterCondition 属性に従って BFP 機能が無効になっているときにトリガーされる通知を有効にします。データは 10.30.217.80 ポート 50055 にストリーミングされます。

POST  https://192.168.20.123/api/node/mo/sys/tm.json

Payload:
{
"telemetryEntity": {
"children": [{
"telemetrySensorGroup": {
"attributes": {
"id": "10"
}
"children": [{
"telemetrySensorPath": {
"attributes": {
"excludeFilter": "",
"filterCondition": "eq(fmBgp.operSt,\"disabled\")",
"path": "sys/fm/bgp",
"secondaryGroup": "0",
"secondaryPath": "",
"depth": "0"
}
}
}
]
}
},
{
"telemetryDestGroup": {
"attributes": {
"id": "20"
}
"children": [{
"telemetryDest": {
"attributes": {
"addr": "10.30.217.80",
"port": "50055",
"enc": "GPB",
"proto": "gRPC"
}
}
}
]
}
},
{
"telemetrySubscription": {
"attributes": {
"id": "30"
}
"children": [{
"telemetryRsSensorGroupRel": {
"attributes": {
"sampleIntvl": "0",
"tDn": "sys/tm/sensor-10"
}
}
},
{
"telemetryRsDestGroupRel": {
"attributes": {
"tDn": "sys/tm/dest-20"
}
}
}
]
}
}
]
}
}

テレメトリ構成のための Postman コレクションの使用

Postman コレクションの例は、テレメトリ機能の構成を開始する簡単な方法であり、1 つのペイロードですべてのテレメトリ CLI に相当するものを実行できます。好みのテキスト エディターを使用して前述のリンクのファイルを変更し、ペイロードをニーズに合わせて更新してから、Postman でコレクションを開いてコレクションを実行します。

DME のテレメトリ モデル

テレメトリ アプリケーションは、次の構造を持つ DME でモデル化されます。

model
|----package [name:telemetry]
|  @name:telemetry
|----objects
|----mo [name:Entity]
|    @name:Entity
|      @label:Telemetry System
|--property
|    @name:adminSt
|      @type:AdminState
|
|----mo [name:SensorGroup]
|    |    @name:SensorGroup
|    |      @label:Sensor Group
|    |--property
|    |    @name:id [key]
|    |      @type:string:Basic
|    |    @name:dataSrc
|    |      @type:DataSource
|    |
|    |----mo [name:SensorPath]
|         |   @name:SensorPath
|         |     @label:Sensor Path
|         |--property
|         |    @name:path [key]
|         |      @type:string:Basic
|         |    @name:filterCondition
|         |      @type:string:Basic
|         |    @name:excludeFilter
|         |      @type:string:Basic
|         |    @name:depth
|         |      @type:RetrieveDepth
|
|----mo [name:DestGroup]
|    |    @name:DestGroup
|    |      @label:Destination Group
|    |--property
|    |    @name:id
|    |      @type:string:Basic
|    |
|    |----mo [name:Dest]
|         |   @name:Dest
|         |     @label:Destination
|         |--property
|         |    @name:addr [key]
|         |      @type:address:Ip
|         |    @name:port [key]
|         |      @type:scalar:Uint16
|         |    @name:proto
|         |      @type:Protocol
|         |    @name:enc
|         |      @type:Encoding
|
|----mo [name:Subscription]
|    @name:Subscription
|      @label:Subscription
|--property
|    @name:id
|      @type:scalar:Uint64
|----reldef
|    |  @name:SensorGroupRel
|    |    @to:SensorGroup
|    |    @cardinality:ntom
|    |    @label:Link to sensorGroup entry
|    |--property
|         @name:sampleIntvl
|           @type:scalar:Uint64
|
|----reldef
|  @name:DestGroupRel
|    @to:DestGroup
|    @cardinality:ntom
|    @label:Link to destGroup entry

テレメトリで使用可能な DN

テレメトリ機能で使用できる DN のリストについては、モデル駆動型テレメトリ を参照してください。

その他の参考資料

- 関連資料

関連資料

関連項目

マニュアル タイトル

VXLAN EVPN のテレメトリ展開の構成例。

[VXLAN EVPN ソリューションのテレメトリ展開（Telemetry Deployment for VXLAN EVPN Solution）]

PartV. XML 管理インターフェイス

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

- XML 管理インターフェイス

Chapter28. XML 管理インターフェイス

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

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

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

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

- その他の参考資料

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

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

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

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

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

- NETCONF レイヤ

- SSH xmlagent

NETCONF レイヤ

次のテーブルは NETCONF レイヤのリストです：

NETCONF レイヤ

レイヤ

例

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

SSHv2

RPC

RPC、RPC-reply

操作

get-config、edit-config

コンテンツ

show または configuration コマンド

以下は、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 では有効ではないため、クライアントとサーバはメッセージがいつ終了するかを解釈でき、通信の同期が維持されます。

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

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

製品

ライセンス要件

Cisco NX-OS

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

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

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

- クライアント PC に SSHv2 をインストールする必要があります。

- クライアント PC に NETCONF over SSH をサポートする XML 管理ツールをインストールする必要があります。

- デバイスの XML サーバに適切なオプションを設定する必要があります。

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

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

Note

デバイスのデフォルト設定で XML 管理インターフェイスを使用します。

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

- SSHv2 セッションの開始

- hello メッセージの送信

- XML スキーマ定義（XSD）ファイルの取得

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

- NETCONF XML インスタンスの作成

- 拡張された NETCONF の操作

- NETCONF 応答

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

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

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

Note

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

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

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

Procedure

Step 1

グローバル コンフィギュレーション モードを開始します。

configure terminal

Step 2

（オプション）XML サーバー構成およびアクティブ XML サーバー セッションに関する情報を表示します。コマンド出力でセッション番号を確認できます。

show xml server status

Step 3

指定されたサーバー セッションの XML ドキュメントを検証します。

xml server validate all

Step 4

指定した XML サーバ セッションを終了します。

xml server terminate session

Step 5

（オプション）キーを生成できるように SSH サーバーを無効にします。

no feature ssh

Step 6

SSH サーバをイネーブルにします。（デフォルトでは有効になっています。）

feature ssh

Step 7

（オプション）SSH サーバーのステータスを表示します。

show ssh server

Step 8

許容される XML サーバーのセッション数を設定します。

xml server max-session sessions

有効な範囲は 1 ～ 8 です。デフォルト値は 8 です。

Step 9

XML サーバー セッションを終了するまでに待機する秒数を設定します。

xml server timeout seconds

範囲は 1～1200 です。デフォルトは 1200 秒です。

Step 10

（オプション）XML サーバー設定およびアクティブ XML サーバー セッションに関する情報を表示します。

show xml server status

Step 11

（任意）実行コンフィギュレーションをスタートアップ コンフィギュレーションに保存します。

copy running-config startup-config

Example

次の例は、CLI を通して SSH と XML サーバー オプションを構成する方法の例を示しています：

switch# configure terminal
switch(config)# xml server validate all
switch(config)# xml server terminate 8665
switch(config)# no feature ssh
switch(config)# feature ssh server
switch(config)# xml server max-session 6
switch(config)# xml server timeout 2400
switch(config)# copy running-config startup-config

SSHv2 セッションの開始

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

ssh2 username@ip-address -s xmlagent

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

Note

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

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

- デバイスで SSH サーバがイネーブルになっています。

- XML サーバの max-sessions オプションは、デバイスへの SSH 接続の数をサポートするのに十分です。

- デバイス上の現用系 XML サーバ セッションの一部が使用されていません。

hello メッセージの送信

サーバーが他の要求を処理する前に、hello メッセージを使用して、サーバーに自分の機能をアドバタイズする必要があります。XML サーバーへの SSH セッションを開始すると、サーバはすぐに 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>]]>]]>

XML スキーマ定義（XSD）ファイルの取得

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

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

XML ドキュメントを XML サーバに送信する場合のガイドラインは次のとおりです。

- コマンド シェル出力で Hello メッセージ テキストを検索して、SSH セッションを開始した直後に XML サーバが Hello メッセージを送信したことを確認します。

- XML 要求を送信する前に、クライアントの Hello メッセージを送信します。クライアントが Hello メッセージを送信すると、XML サーバは Hello 応答を直ちに送信し、追加の応答は送信しないことに注意してください。

- XML ドキュメントは常に文字シーケンス ]]>]]> で終了します。

NETCONF XML インスタンスの作成

NETCONF XML インスタンスは、RPC タグおよび 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 リクエスト タグ

- NETCONF 動作タグ

- デバイスタグ

RPC リクエスト タグ

すべての NETCONF XML インスタンスは、RPC リクエスト タグ <rpc> で開始する必要があります。<rpc> 要素には、メッセージ ID（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 には、この名前空間の定義が含まれています。詳細については、XML スキーマ定義（XSD）ファイルの取得を参照してください。

例

RPC リクエスト タグ <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>]]>]]>

Note

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

NETCONF 動作タグ

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

Cisco NX-OS の NETCONF 動作

NETCONF 動作

説明

例

close-session

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

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

commit

候補構成の現在の内容を実行構成として設定します。

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

confirmed-commit

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

NETCONF 確認済みコミット インスタンス

copy-config

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

NETCONF での構成インスタンスのコピー

delete-config

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

—

edit-config

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

NETCONF Edit Config インスタンス

NETCONF Rollback-On-Error インスタンス

get

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

NETCONF XML インスタンスの作成

get-config

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

NETCONF XML インスタンスの作成

kill-session

指定した XML サーバー セッションを閉じます。自分のセッションを閉じることはできません。

NETCONF 強制終了セッション インスタンス

ロック

クライアントがデバイスの構成システムをロックできるようにします。

NETCONF ロック インスタンス

unlock

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

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

検証

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

NETCONF 検証機能インスタンス

デバイスタグ

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

このスキーマを使用して、XML インスタンスを構築することができます。NETCONF インスタンスのビルドに使用された nfcli.xsd スキーマ ファイルの関連部分です。（NETCONF 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 応答タグ を参照してください。

XML の例

<get> 操作を実行するために使用できるタグを見つけるための | XML オプション を使用できます。以下は | XML オプションの例です。この例では、このデバイスで操作を実行するための名前空間定義タグが http://www.cisco.com/nxos:1.0:nfcli であり、要求のビルドのためにnfcli.xsd ファイルを使用できることがわかります。

NETCONF 操作タグとデバイス タグを RPC タグで囲むことができます。</rpc> 終了タグの後に 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>
]]>]]>

拡張された NETCONF の操作

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

以下は、インターフェイスの構成に使用されるタグの例です。タグ ラインは次のレター コードでマークキングされています：

- X — XML 宣言

- R — RPC リクエスト タグ

- EO — 拡張操作

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

操作タグ

タグ

説明

<exec-command>

CLI コマンドの実行

<cmd>

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

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

- <nf:ok>：すべての configuration コマンドが正常に実行されました。

- <nf:rpc-error>：一部のコマンドが失敗しました。操作は最初のエラーで停止します。<nf:rpc-error> サブツリーは、失敗した構成について詳細情報を提供します。失敗したコマンドの前に実行された構成は、実行構成に適用されていることに注意してください。

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

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

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> を通して送信された表示 CLI コマンド

次の例は、<exec-command> を通して送信される show 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> を通して送信された表示 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>192.0.2.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>
]]>]]>

機能不全の構成

<?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 192.0.2.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 コマンドが、その show コマンドの XML 出力を含む <cmd> タグによって送信された結果です。

構成コマンドと表示コマンドを同じに組み合わせることはできません<exec-command> インスタンス。次は、同じインスタンスで config コマンドと 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>
]]>]]>

<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 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 応答タグ <rpc-reply> を示しています。

RPC 応答タグ<rpc-reply>

<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>]]>]]>

RPC 応答エレメント

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

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>
]]>]]>

Note

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

XML インスタンスの例

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

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

- NETCONF 強制終了セッション インスタンス

- NETCONF での構成インスタンスのコピー

- NETCONF Edit Config インスタンス

- NETCONF の Get Config インスタンス

- NETCONF ロック インスタンス

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

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

- NETCONF 確認済みコミット インスタンス

- NETCONF Rollback-On-Error インスタンス

- NETCONF 検証機能インスタンス

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

- NETCONF 強制終了セッション インスタンス

- NETCONF での構成インスタンスのコピー

- NETCONF Edit Config インスタンス

- NETCONF の Get Config インスタンス

- NETCONF ロック インスタンス

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

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

- NETCONF 確認済みコミット インスタンス

- NETCONF Rollback-On-Error インスタンス

- NETCONF 検証機能インスタンス

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

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

クローズ セッション要求

<?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 強制終了セッション インスタンス

次の例は、強制終了セッション要求と、 強制終了セッション応答を示しています。

強制終了セッション要求

<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>]]>]]>

強制終了セッション応答

<?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" message-id="101">
<nc:ok/>
</nc:rpc-reply>]]>]]>

NETCONF での構成インスタンスのコピー

次に、構成コピーの要求と、それに続く構成コピーの応答の例を示します。

構成コピーの要求

<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>

構成コピーの応答

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

Edit Config：削除操作要求

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

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 応答：削除操作

次の例は、実行構成のインターフェイス Ethernet 0/0 の構成を編集する方法を示しています。

<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 ロック インスタンス

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

ロック要求

<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 確認済みコミット インスタンス

次の例は、確認済みのコミット操作と確認済みのコミット返答を示しています。

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

<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 インスタンス

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

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:rollback-on-error:1.0 は、NETCONF 検証機能を指定します。

検証要求

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 構成プロトコルの使用

ストリーミング テレメトリの送信元

- ストリーミング テレメトリについて

- 注意事項と制約事項

- テレメトリで利用可能なデータ

ストリーミング テレメトリについて

Cisco Nexus スイッチのストリーミング テレメトリ機能は、ネットワークからデータを継続的にストリーミングしてクライアントに通知し、モニタリング データへのほぼリアルタイムのアクセスを提供します。

注意事項と制約事項

ストリーミング テレメトリのガイドラインと制限は次のとおりです。

- テレメトリ機能は、Cisco Nexus 3000 と 9000 スイッチで使用できます。

- メモリが 8 GB 未満のスイッチは、テレメトリをサポートしていません。

- ソフトウェア ストリーミング テレメトリは TCP プロトコルをサポートしていません。tcp オプションはヘルプ テキストに表示されますが、構成中は使用できません。

テレメトリで利用可能なデータ

コンポーネント グループごとに、NX-API DME モデル リファレンスの付録にある識別名（DN）は、一覧表示されたプロパティをテレメトリのデータとして提供できます。

はじめに

この前書きは、次の項で構成されています。

- 対象読者

- 表記法

- Cisco Nexus 9000 シリーズ スイッチの関連資料

- マニュアルに関するフィードバック

- 通信、サービス、およびその他の情報

対象読者

このマニュアルは、Cisco Nexus スイッチの設置、設定、および維持に携わるネットワーク管理者を対象としています。

表記法

コマンドの説明には、次のような表記法が使用されます。

表記法

説明

bold

太字の文字は、表示どおりにユーザが入力するコマンドおよびキーワードです。

italic

イタリック体の文字は、ユーザが値を指定する引数です。

[x]

省略可能な要素（キーワードまたは引数）は、角かっこで囲んで示しています。

[x | y]

いずれか 1 つを選択できる省略可能なキーワードや引数は、角かっこで囲み、縦棒で区切って示しています。

{x | y}

必ずいずれか 1 つを選択しなければならない必須キーワードや引数は、波かっこで囲み、縦棒で区切って示しています。

[x {y | z}]

角かっこまたは波かっこが入れ子になっている箇所は、任意または必須の要素内の任意または必須の選択肢であることを表します。角かっこ内の波かっこと縦棒は、省略可能な要素内で選択すべき必須の要素を示しています。

variable

ユーザが値を入力する変数であることを表します。イタリック体が使用できない場合に使用されます。

string

引用符を付けない一組の文字。string の前後には引用符を使用しないでください。引用符を使用すると、その引用符も含めて string と見なされます。

例では、次の表記法を使用しています。

表記法

説明

screen フォント

スイッチが表示する端末セッションおよび情報は、スクリーン フォントで示しています。

太字の screen フォント

ユーザが入力しなければならない情報は、太字の screen フォントで示しています。

イタリック体の screen フォント

ユーザが値を指定する引数は、イタリック体の screen フォントで示しています。

< >

パスワードのように出力されない文字は、山カッコ（< >）で囲んで示しています。

[ ]

システム プロンプトに対するデフォルトの応答は、角カッコで囲んで示しています。

!、#

コードの先頭に感嘆符（!）またはポンド記号（#）がある場合には、コメント行であることを示します。

Cisco Nexus 9000 シリーズ スイッチの関連資料

Cisco Nexus 9000 シリーズ スイッチ全体のマニュアル セットは、次の URL にあります。

http://www.cisco.com/en/US/products/ps13386/tsd_products_support_series_home.html

マニュアルに関するフィードバック

このマニュアルに関する技術的なフィードバック、または誤りや記載もれなどお気づきの点がございましたら、HTML ドキュメント内のフィードバック フォームよりご連絡ください。ご協力をよろしくお願いいたします。

通信、サービス、およびその他の情報

- シスコからタイムリーな関連情報を受け取るには、Cisco Profile Manager でサインアップしてください。

- 重要な技術によりビジネスに必要な影響を与えるには、シスコサービス [英語] にアクセスしてください。

- サービス リクエストを送信するには、シスコサポート [英語] にアクセスしてください。

- 安全で検証済みのエンタープライズクラスのアプリケーション、製品、ソリューション、およびサービスを探して参照するには、Cisco Marketplace にアクセスしてください。

- 一般的なネットワーク、トレーニング、認定関連の出版物を入手するには、Cisco Press にアクセスしてください。

- 特定の製品または製品ファミリの保証情報を探すには、Cisco Warranty Finder にアクセスしてください。

Cisco バグ検索ツール

Cisco バグ検索ツール（BST）は、シスコ製品とソフトウェアの障害と脆弱性の包括的なリストを管理する Cisco バグ追跡システムへのゲートウェイとして機能する、Web ベースのツールです。BST は、製品とソフトウェアに関する詳細な障害情報を提供します。

Full Cisco Trademarks with Software License

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.

Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.

The documentation set for this product strives to use bias-free language. For purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on standards documentation, or language that is used by a referenced third-party product.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)