Cisco APIC Troubleshooting Guide...ACIでのSNMP アクセスのサポート11 SNMPの設定11 GUIによるSNMPポリシーの設定11 Cisco APIC Troubleshooting Guide

Cisco APIC Troubleshooting Guide最終更新：2016年 06月 30日

シスコシステムズ合同会社〒107-6227 東京都港区赤坂9-7-1 ミッドタウン・タワーhttp://www.cisco.com/jpお問い合わせ先：シスココンタクトセンター

0120-092-255 （フリーコール、携帯・PHS含む）電話受付時間：平日 10:00～12:00、13:00～17:00http://www.cisco.com/jp/go/contactcenter/

【注意】シスコ製品をご使用になる前に、安全上の注意（ www.cisco.com/jp/go/safety_warning/ ）をご確認ください。本書は、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきま

しては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容

については米国サイトのドキュメントを参照ください。また、契約等の記述については、弊社販

売パートナー、または、弊社担当者にご確認ください。

このマニュアルに記載されている仕様および製品に関する情報は、予告なしに変更されることがあります。このマニュアルに記載されている表現、情報、および推奨

事項は、すべて正確であると考えていますが、明示的であれ黙示的であれ、一切の保証の責任を負わないものとします。このマニュアルに記載されている製品の使用

は、すべてユーザ側の責任になります。

対象製品のソフトウェアライセンスおよび限定保証は、製品に添付された『Information Packet』に記載されています。添付されていない場合には、代理店にご連絡ください。

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 versionof the UNIX operating system.All rights reserved.Copyright © 1981, Regents of the University of California.

ここに記載されている他のいかなる保証にもよらず、各社のすべてのマニュアルおよびソフトウェアは、障害も含めて「現状のまま」として提供されます。シスコお

よびこれら各社は、商品性の保証、特定目的への準拠の保証、および権利を侵害しないことに関する保証、あるいは取引過程、使用、取引慣行によって発生する保証

をはじめとする、明示されたまたは黙示された一切の保証の責任を負わないものとします。

いかなる場合においても、シスコおよびその供給者は、このマニュアルの使用または使用できないことによって発生する利益の損失やデータの損傷をはじめとする、

間接的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコまたはその供給者に知らされていても、それらに対する責任を一切負わないものと

します。

このマニュアルで使用している IPアドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。マニュアル内の例、コマンド出力、ネットワークトポロジ図、およびその他の図は、説明のみを目的として使用されています。説明の中に実際のアドレスおよび電話番号が使用されていたとしても、それは意

図的なものではなく、偶然の一致によるものです。

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: http://www.cisco.com/go/trademarks.Third-party trademarks mentioned are the property of their respective owners.The use of the word partner does not imply a partnershiprelationship between Cisco and any other company.(1110R)

© 2014-2016 Cisco Systems, Inc. All rights reserved.

http://www.cisco.com/go/trademarks

http://www.cisco.com/go/trademarks

目次

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

はじめに xi

対象読者 xi

表記法 xi

関連資料 xiii

マニュアルに関するフィードバック xiv

トラブルシューティングのツールと方法論 1

テクニカルサポート、統計情報、およびコアファイルのエクスポート 1

ファイルのエクスポートについて 1

アウトオブバンド DNS接続 2

ファイルのエクスポートに関するガイドラインと制約事項 2

ファイルエクスポート用のリモートロケーションの作成 2

オンデマンドテクニカルサポートファイルの送信 3

Syslogの使用 4

Syslogについて 4

Syslogの宛先および宛先グループの作成 5

Syslog送信元の作成 6

アトミックカウンタの使用 7

アトミックカウンタについて 7

アトミックカウンタに関する注意事項および制約事項 8

アトミックカウンタの構成 10

SNMPの使用 10

SNMPの概要 10

ACIでの SNMPアクセスのサポート 11

SNMPの設定 11

GUIによる SNMPポリシーの設定 11

Cisco APIC Troubleshooting Guide iii

GUIによる SNMPトラップ通知先の設定 13

GUIによる SNMPトラップソースの設定 14

SNMPを使用したシステムのモニタリング 14

SPANの使用 15

SPANの概要 15

SPANの注意事項と制約事項 15

SPANセッションの設定 16

トレースルートの使用 17

トレースルートの概要 17

tracerouteの注意事項および制約事項 17

エンドポイント間での tracerouteの実行 18

エンドポイント接続のトラブルシューティング 19

エンドポイント接続のトラブルシューティング 19

ステータスの確認 20

エンドポイントのステータスの確認 20

トンネルインターフェイスのステータスの確認 21

SFPモジュールの接続 21

IPベース EPGのトラブルシューティング 23

IPベース EPGのトラブルシューティング 23

IP-EPGスイッチのトラブルシューティングコマンドの使用 29

ヘルススコアを使用したトラブルシューティング 31

ヘルススコア 31

ヘルススコアのタイプ 31

ネットワーク健全性のモニタリング 31

ヘルススコアによるフィルタリング 32

テナントの健全性の表示 32

ファブリックの健全性の表示 32

VisoreでのMO健全性の表示 33

ログを使用するヘルススコアのデバッグ 33

エラーの表示 33

クラスタのトラブルシューティング 35

クラスタ管理の注意事項 35

Cisco APIC Troubleshooting Guideiv

目次

APICクラスタサイズの拡大 36

クラスタでの APICコントローラの交換 36

クラスタサイズの縮小 38

クラスタ内の Cisco APICの交換 38

クラスタのトラブルシューティングのシナリオ 39

クラスタのエラー 43

統計情報を使用したトラブルシューティング 47

GUIでの統計情報の表示 47

スイッチの統計情報コマンド 48

GUIを使用する統計情報しきい値の管理 50

統計情報に関するトラブルシューティングのシナリオ 50

統計情報の消去 52

ポートトラッキングを使用したトラブルシューティング 55

アップリンク障害検出のためのポートトラッキングポリシー 55

GUIを使用したポートトラッキング 56

NX-OS CLIを使用したポートトラッキング 57

REST APIを使用したポートトラッキング 57

設定ゾーンのトラブルシューティング 59

設定ゾーン 59

GUIを使用した設定ゾーンの作成 60

NX-OSスタイルの CLIを使用した設定ゾーンの作成 61

REST APIを使用した設定ゾーンの作成 62

設定ゾーンのサポート対象ポリシー 62

ACLの許可および拒否ログを使用したトラブルシューティング 65

GUIを使用した ACL契約許可ロギングの有効化 65

NX-OS CLIを使用した ACL契約許可ロギングの有効化 66

REST APIを使用した ACL契約許可ロギングの有効化 67

GUIを使用した禁止契約拒否ロギングの有効化 67

NX-OS CLIを使用した禁止契約拒否ロギングの有効化 68

REST APIを使用した禁止契約拒否ロギングの有効化 69

GUIを使用した ACL許可および拒否ログの表示 70

REST APIを使用した ACL許可および拒否ログ 71

Cisco APIC Troubleshooting Guide v

目次

NX-OS CLIを使用した ACL許可および拒否ログの表示 71

マルチポッドのトラブルシューティング 75

GUIを使用したマルチポッドのトラブルシューティング 75

NX-OS CLIを使用したマルチポッドのトラブルシューティング 75

REST APIを使用したマルチポッドのトラブルシューティング 75

デジタルオプティカルモニタリングを使用したトラブルシューティング 77

GUIを使用したデジタルオプティカルモニタリングの有効化 77

REST APIを使用したデジタルオプティカルモニタリングの有効化 78

GUIを使うデジタルオプティカルモニタリングを使用したトラブルシューティン

グ 80

RESTAPIを使うデジタルオプティカルモニタリングを使用したトラブルシューティ

ング 80

Cisco APICパスワードの復元およびフォールバックログインドメインの使用 83

APICパスワードの回復 83

NX-OSスタイルの CLIを使用した Cisco APIC設定を消去するレスキューユーザアカ

ウントの使用 84

フォールバックログインドメインを使用したローカルデータベースへのログイン 85

リーフ接続のトラブルシューティング 87

切断されたリーフの復旧 87

ファブリックの再構築 89

ファブリックの再構築 89

ウィザードのトラブルシューティング 91

トラブルシューティングウィザードについて 92

トラブルシューティングウィザードの使用を開始する 93

トラブルシューティングレポートの生成 96

トラブルシューティングウィザードのトポロジ 99

[Faults]トラブルシューティング画面の使用 101

[Drop/Statistics]トラブルシューティング画面の使用 103

[Contracts]トラブルシューティング画面の使用 107

[Events]トラブルシューティング画面の使用 110

[Traceroute]トラブルシューティング画面の使用 113

[Atomic Counter]トラブルシューティング画面の使用 117

Cisco APIC Troubleshooting Guidevi

目次

[SPAN]トラブルシューティング画面の使用 119

L4 - L7サービス検証シナリオ 121

エンドポイント間接続用 APIのリスト 122

interactive API 123

createsession API 124

modifysession API 125

atomiccounter API 126

traceroute API 126

span API 126

generatereport API 128

schedulereport API 128

getreportstatus API 129

getreportslist API 129

getsessionslist API 130

getsessiondetail API 130

deletesession API 130

clearreports API 131

contracts API 132

エンドポイントからレイヤ 3への外部接続用 APIのリスト 132

interactive API 133

createsession API 133

modifysession API 134

atomiccounter API 135

traceroute API 136

span API 137

generatereport API 138

schedulereport API 139

getreportstatus API 141

getreportslist API 141

getsessionslist API 141

getsessiondetail API 143

deletesession API 144

clearreports API 144

contracts API 144

ratelimit API 145

Cisco APIC Troubleshooting Guide vii

目次

13ext API 146

APICのトラブルシューティングの操作 149

APICシステムのシャットダウン 149

GUIを使用した APICコントローラのシャットダウン 150

GUIを使用した APICリロードオプションの使用 151

GUIを使用した LEDロケータの制御 152

SSL暗号方式のトラブルシューティング 153

SSL暗号化について 153

サポートされる SSL暗号化の確認 154

acidiagコマンド 155

Cisco APIC Troubleshooting Guideviii

目次

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

次の表は、この最新リリースまでのガイドでの主な変更点の概要を示したものです。ただし、こ

のリリースまでのこのガイドの変更点や新機能の中には一部、この表に記載されていないものも

あります。

説明機能Cisco APIC のリリースバージョン

アップリンク障害検出は、ファ

ブリックアクセスグローバル

ポートトラッキングポリシー

で有効にできます。ポートト

ラッキングポリシーが、リー

フスイッチとスパインスイッ

チとの間のリンクの状態を監視

します。有効なポートトラッ

キングポリシーがトリガーさ

れると、リーフスイッチは、

EPGが展開されているスイッチのすべてのアクセスインター

フェイスを停止します。リーフ

スイッチのモデルに応じて、各

リーフスイッチは、各スパイ

ンスイッチへの 6、8、または12個のアップリンク接続を持つことができます。ポートト

ラッキングポリシーは、ポリ

シーをトリガーするアップリン

ク接続の数と、指定のアップリ

ンク数を超過した後にリーフ

スイッチアクセスポートを復

旧するまでの遅延タイマーを指

定します。

アップリンク障害検出のための

ポートトラッキングポリシー

Release 1.2(2)

Cisco APIC Troubleshooting Guide 9

説明機能Cisco APIC のリリースバージョン

設定ゾーンは、ACIファブリックを、さまざまなタイミングで

実行される設定変更により更新

できる多様なゾーンに分割しま

す。これにより、トラフィック

を中断したりファブリックをダ

ウンさせたりする可能性もあ

る、障害ファブリック全体の設

定を展開してしまうリスクが制

限されます。管理者はクリティ

カルではないゾーンに設定を展

開し、それが適切であることを

確認した時点でクリティカル

ゾーンに展開できます。注：無

効にされた設定ゾーンに属する

ノードは、アップグレードまた

はダウングレードしないでくだ

さい。

設定ゾーンRelease 1.2(2)

Cisco APIC Troubleshooting Guide10

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

はじめに

この前書きは、次の項で構成されています。

• 対象読者, xi ページ

• 表記法, xi ページ

• 関連資料, xiii ページ

• マニュアルに関するフィードバック, xiv ページ

対象読者このガイドは、データシステム、ネットワーク、ストレージシステムのトラブルシューティング

に関して経歴があるシステムおよびネットワークエンジニアを対象としています。

表記法コマンドの説明には、次のような表記法が使用されます。

説明表記法

太字の文字は、表示どおりにユーザが入力するコマンドおよび

キーワードです。

bold

イタリック体の文字は、ユーザが値を入力する引数です。italic

省略可能な要素（キーワードまたは引数）は、角カッコで囲んで

示しています。

[x]

いずれか 1つを選択できる省略可能なキーワードや引数は、角カッコで囲み、縦棒で区切って示しています。

[x | y]

Cisco APIC Troubleshooting Guide xi

説明表記法

必ずいずれか1つを選択しなければならない必須キーワードや引数は、波カッコで囲み、縦棒で区切って示しています。

{x | y}

角カッコまたは波カッコが入れ子になっている箇所は、任意また

は必須の要素内の任意または必須の選択肢であることを表しま

す。角カッコ内の波カッコと縦棒は、省略可能な要素内で選択す

べき必須の要素を示しています。

[x {y | z}]

ユーザが値を入力する変数であることを表します。イタリック体

が使用できない場合に使用されます。

variable

引用符を付けない一組の文字。stringの前後には引用符を使用しません。引用符を使用すると、その引用符も含めて stringとみなされます。

string

例では、次の表記法を使用しています。

説明表記法

スイッチが表示する端末セッションおよび情報は、screenフォントで示しています。

screen フォント

ユーザが入力しなければならない情報は、太字の screenフォントで示しています。

太字の screen フォント

ユーザが値を指定する引数は、イタリック体の screenフォントで示しています。

イタリック体の screenフォント

パスワードのように出力されない文字は、山カッコ（< >）で囲んで示しています。

< >

システムプロンプトに対するデフォルトの応答は、角カッコで

囲んで示しています。

[ ]

コードの先頭に感嘆符（!）またはポンド記号（#）がある場合には、コメント行であることを示します。

!、#

このマニュアルでは、次の表記法を使用しています。

「注釈」です。役立つ情報やこのマニュアルに記載されていない参照資料を紹介しています。（注）

Cisco APIC Troubleshooting Guidexii

はじめに

表記法

「要注意」の意味です。機器の損傷またはデータ損失を予防するための注意事項が記述されて

います。

注意

IMPORTANT SAFETY INSTRUCTIONS

This warning symbol means danger.You are in a situation that could cause bodily injury.Before you workon any equipment, be aware of the hazards involved with electrical circuitry and be familiar with standardpractices for preventing accidents.Use the statement number provided at the end of each warning to locateits translation in the translated safety warnings that accompanied this device.

SAVE THESE INSTRUCTIONS

警告

関連資料

シスコアプリケーションセントリックインフラストラクチャ（ACI）のマニュアル

ACLのマニュアルは、次の URLで入手できます。http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html

シスコアプリケーションセントリックインフラストラクチャ（ACI）シミュレータのマニュアル

Cisco ACI Simulatorのマニュアルは、次の URLから入手できます。http://www.cisco.com/c/en/us/support/cloud-systems-management/application-centric-infrastructure-simulator/tsd-products-support-series-home.html。

Cisco Nexus 9000 シリーズスイッチのマニュアル

Cisco Nexus 9000シリーズスイッチのマニュアルは、次の URLで入手できます。http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/tsd-products-support-series-home.html

Cisco Application Virtual Switch のマニュアル

Cisco Application Virtual Switch（AVS）のマニュアルは、次の URLで入手できます。http://www.cisco.com/c/en/us/support/switches/application-virtual-switch/tsd-products-support-series-home.html

シスコアプリケーションセントリックインフラストラクチャ（ACI）と OpenStack の統合に関するマニュアル

Cisco ACIと OpenStackの統合に関するマニュアルは、次の URLから入手できます。http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html

Cisco APIC Troubleshooting Guide xiii

はじめに

関連資料

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html



http://www.cisco.com/c/en/us/support/cloud-systems-management/application-centric-infrastructure-simulator/tsd-products-support-series-home.html



http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/tsd-products-support-series-home.html

http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/tsd-products-support-series-home.html

http://www.cisco.com/c/en/us/support/switches/application-virtual-switch/tsd-products-support-series-home.html

http://www.cisco.com/c/en/us/support/switches/application-virtual-switch/tsd-products-support-series-home.html




マニュアルに関するフィードバックこのマニュアルに関する技術的なフィードバック、または誤りや記載もれなどお気づきの点がご

ざいましたら、[email protected]までご連絡ください。ご協力をよろしくお願いいたします。

Cisco APIC Troubleshooting Guidexiv

はじめに

マニュアルに関するフィードバック

mailto:[email protected]

第 1 章

トラブルシューティングのツールと方法論

• テクニカルサポート、統計情報、およびコアファイルのエクスポート, 1 ページ

• Syslogの使用, 4 ページ

• アトミックカウンタの使用, 7 ページ

• SNMPの使用, 10 ページ

• SPANの使用, 15 ページ

• トレースルートの使用, 17 ページ

テクニカルサポート、統計情報、およびコアファイルの

エクスポート

ファイルのエクスポートについて

管理者は、APIC内で、コアファイルとデバッグデータを処理するために、統計情報、テクニカルサポートの収集、障害およびイベントをファブリック（APICおよびスイッチ）から外部ホストにエクスポートするようエクスポートポリシーを設定できます。エクスポートはXML、JSON、Webソケット、Secure Copy Protocol（SCP）、HTTPなどのさまざまな形式にできます。ストリーミング、定期的、またはオンデマンドの各形式でエクスポートを登録できます。

管理者は、転送プロトコル、圧縮アルゴリズム、転送の頻度などポリシーの詳細を設定できます。

ポリシーは、AAAを使用して認証されたユーザによって設定できます。実際の転送のセキュリティメカニズムは、ユーザ名とパスワードに基づいています。内部的に、ポリシー要素はデータ

のトリガーを処理します。


アウトオブバンド DNS 接続

テクニカルサポートや Cisco Call Homeホームなどのアプリケーションでは、ホスト名を正しく解決するためにリーフスイッチでインバンドとアウトオブバンドの DNS接続が必要です。

（注）

ファイルのエクスポートに関するガイドラインと制約事項

• HTTPエクスポートとストリーミングAPI形式は、統計情報の場合にのみサポートされます。コア情報とテクニカルサポートデータはサポートされません。

•エクスポートされるファイルの宛先 IPは、IPv6アドレスであってはなりません。

特に、APIC、または帯域幅と計算用リソースが不足している外部サーバにエクスポートする場合は、5つを超えるノードから同時にテクニカルサポートをトリガーしないでください。

ファブリック内のすべてのノードから定期的にテクニカルサポートを収集するには、複数の

ポリシーを作成する必要があります。各ポリシーは、ノードのサブセットをカバーする必要が

あり、時間をずらしてトリガーされるようにスケジュールします（少なくとも 30分離す）。

（注）

ファイルエクスポート用のリモートロケーションの作成

この手順では、エクスポートされたファイルを受け取るリモートホストのホスト情報とファイル

転送セッティングを設定します。

ステップ 1 メニューバーで、[Admin]をクリックします。

ステップ 2 サブメニューバーで、[Import/Export]をクリックします。

ステップ 3 [Navigation]ペインで、[Export Policies]を展開します。

ステップ 4 [Remote Locations]を右クリックし、[Create Remote Path of a File]を選択します。

ステップ 5 [Create Remote Path of a File]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドに、リモートロケーションの名前を入力します。b) [Host Name/IP]フィールドに、送信先ホストの IPアドレスまたは完全修飾ドメイン名を入力します。c) [Protocol]フィールドで、必要なファイル転送プロトコルのオプションボタンをクリックします。d) [Remote Path]フィールドで、リモートホストでファイルが保存されるパスを入力します。e) リモートホストにログインするためのユーザ名とパスワードを入力し、パスワードを確認します。f) [Management EPG]ドロップダウンリストから管理 EPGを選択します。



ファイルのエクスポートに関するガイドラインと制約事項

g) [Submit]をクリックします。`

オンデマンドテクニカルサポートファイルの送信


ステップ 2 サブメニューバーで、[Import/Export]をクリックします。

ステップ 3 [Navigation]ペインで、[Export Policies]を展開します。

ステップ 4 [On-demand TechSupport]を右クリックし、[Create On-demand TechSupport]を選択します。

ステップ 5 [Create On-demand TechSupport]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドに、テクニカルサポートファイルのエクスポートポリシーの名前を入力します。b) ファイルをリモート宛先ではなくコントローラにエクスポートする場合は、[Export to Controller]を選択します。

c) [Export Destination]ドロップダウンリストから、テクニカルサポートファイルを受信する宛先ホストのプロファイルを選択します。

目的の宛先のプロファイルが表示されない場合は、[CreateRemoteLocation]を選択してここで定義します。

d) [Data Container]ドロップダウンリストから、[uni/fabric/tscont]を選択します。e) 目的の送信元デバイス（リーフまたはスパイン）が [SourceNodes]テーブルに表示されない場合は、[+]アイコンをクリックし、デバイスを選択して、[Update]をクリックします。

f) [SourceNodes]テーブルで送信元名をダブルクリックし、ドロップダウンリストの右にある青のアイコンをクリックして、ソースデバイスの [System Information]ウィンドウを開きます。ソースデバイスの情報を確認するには、タブを使用します。

g) [State]フィールドで、[triggered]オプションボタンをクリックして、ファイルを送信できるようにします。

h) [Submit]をクリックして、テクニカルサポートファイルを送信します。オンデマンドのテクニカルサポートファイルは別の APICに保存し、ストレージと CPU条件のバランスを取ることができます。場所を確認するには、[Navigation]ペインでオンデマンドのテクニカルサポートポリシーをクリックし、[Work]ペインで [OPERATIONAL]タブをクリックします。コントローラが [EXPORT LOCATION]フィールドに表示されます。

（注）

i) ポリシー名を右クリックし、[Collect Tech Support]を選択します。j) [Yes]を選択して、テクニカルサポート情報の収集を開始します。



オンデマンドテクニカルサポートファイルの送信

Syslog の使用

Syslog について稼働中、シスコアプリケーションセントリックインフラストラクチャ（ACI）システムでの障害またはイベントは、コンソール、ローカルファイル、および別のシステム上のロギングサーバへ

のシステムログ（syslog）の送信をトリガーできます。システムログメッセージには、通常、障害またはイベントに関する情報のサブセットが含まれます。システムログメッセージには、監査

ログとセッションログのエントリを含めることもできます。

APICおよびファブリックノードが生成できる syslogメッセージのリストについては、http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/syslog/guide/aci_syslog/ACI_SysMsg.htmlを参照してください。

（注）

多くのシステムログメッセージは、ユーザが実行している処理、あるいはユーザが設定または管

理しているオブジェクトに固有のものです。これらのメッセージには次のようなものがあります。

•情報メッセージ。実行している処理のヘルプおよびヒントを提供します。

•警告メッセージ。ユーザが設定または管理しているオブジェクト（ユーザアカウントやサービスプロファイルなど）に関連するシステムエラーの情報を提供します。

システムログメッセージを受信してモニタするためには、syslog宛先（コンソール、ローカルファイル、または syslogサーバを実行している 1つ以上のリモートホスト）を指定する必要があります。また、コンソールに表示されるか、ファイルまたはホストによってキャプチャされるメッ

セージの重大度の最小値を指定できます。syslogメッセージを受信するローカルファイルは/var/log/external/messagesです。

Syslog送信元は、オブジェクトモニタリングポリシーを適用できる任意のオブジェクトにすることができます。送信されるメッセージの重大度の最小値、syslogメッセージに含める項目、および syslogの宛先を指定できます。

これらのシステムメッセージを生成する障害またはイベントの詳細については、『Cisco APICFaults, Events, and SystemMessages Management Guide』で説明されており、システムログメッセージは『Cisco ACI System Messages Reference Guide』にリストされています。

システムログメッセージは、必ずしもシステムに問題があることを示しているとは限りませ

ん。単に情報を通知するだけのメッセージもありますし、通信回線、内部ハードウェア、また

はシステムソフトウェアに関する問題点の診断に役立つメッセージもあります。

（注）



Syslog の使用

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/syslog/guide/aci_syslog/ACI_SysMsg.html



Syslog の宛先および宛先グループの作成この手順では、ロギングおよび評価用の syslogデータの宛先を設定します。syslogデータは、コンソール、ローカルファイル、または宛先グループ内の 1つまたは複数の syslogサーバにエクスポートできます。


ステップ 2 サブメニューバーで、[External Data Collectors]をクリックします。

ステップ 3 [Navigation]ペインで、[Monitoring Destinations]を展開します。

ステップ 4 [Syslog]を右クリックし、[Create Syslog Monitoring Destination Group]を選択します。

ステップ 5 [Create Syslog Monitoring Destination Group]ダイアログボックスで、次の操作を実行します。a) グループおよびプロファイルの [Name]フィールドに、モニタリングの宛先グループおよびプロファイルの名前を入力します。

b) グループおよびプロファイルの [Admin State]ドロップダウンリストで、[enabled]を選択します。c) ローカルファイルへの syslogメッセージの送信を有効にするには、[Local File Destination]の [Admin

State]ドロップダウンリストから [enabled]を選択し、[Local File Destination]の [Severity]ドロップダウンリストから重大度の最小値を選択します。

syslogメッセージを受信するローカルファイルは /var/log/external/messagesです。

d) コンソールへの syslogメッセージの送信を有効にするには、[ConsoleDestination]の [Admin State]ドロップダウンリストから [enabled]を選択し、[Console Destination]の [Severity]ドロップダウンリストから重大度の最小値を選択します。

e) [Next]をクリックします。f) [Create Remote Destinations]領域で、[+]をクリックしてリモート宛先を追加します。

ステップ 6 [Create Syslog Remote Destination]ダイアログボックスで、次の操作を実行します。a) [Host]フィールドに、送信先ホストの IPアドレスまたは完全修飾ドメイン名を入力します。b) （任意） [Name]フィールドに、宛先ホストの名前を入力します。c) [Admin State]フィールドで、[enabled]オプションボタンをクリックします。d) （任意）重大度の最小値 [Severity]、[Port]番号、および syslogの [Forwarding Facility]を選択します。e) [Management EPG]ドロップダウンリストから管理エンドポイントグループを選択します。f) [OK]をクリックします。

ステップ 7 （任意）リモート宛先グループにリモート宛先を追加するには、もう一度 [+]をクリックし、[CreateSyslogRemote Destination]ダイアログボックスの手順を繰り返します。

ステップ 8 [Finish]をクリックします。



Syslog の宛先および宛先グループの作成

Syslog 送信元の作成Syslog送信元は、オブジェクトモニタリングポリシーを適用できる任意のオブジェクトにすることができます。

はじめる前に

syslogモニタリング宛先グループを作成します。

ステップ 1 メニューバーおよびナビゲーションフレームから、関心領域の [Monitoring Policies]メニューに移動します。

テナント、ファブリック、およびアクセスのモニタリングポリシーを設定できます。

ステップ 2 [Monitoring Policies]を展開し、モニタリングポリシーを選択して展開します。[Fabric] > [Fabric Policies] > [Monitoring Policies] > [Common Policy]の下に、基本モニタリングポリシーがあります。このポリシーは、すべての障害とイベントに適用され、ファブリック内のすべてのノードとコ

ントローラに自動的に導入されます。または、スコープが限定された既存のポリシーを指定することもで

きます。

ステップ 3 モニタリングポリシーの下で、[Callhome/SNMP/Syslog]をクリックします。

ステップ 4 [Work]ペインで、[Source Type]ドロップダウンリストから [Syslog]を選択します。

ステップ 5 [Monitoring Object]リストから、モニタ対象の管理対象オブジェクトを選択します。目的のオブジェクトがリストに表示されない場合は、次の手順に従います。

a) [Monitoring Object]ドロップダウンリストの右側にある [Edit]アイコンをクリックします。b) [Select Monitoring Package]ドロップダウンリストから、オブジェクトクラスパッケージを選択します。

c) モニタ対象の各オブジェクトのチェックボックスをオンにします。d) [Submit]をクリックします。`

ステップ 6 テナントモニタリングポリシーでは、[All]ではなく特定のオブジェクトを選択すると、[Scope]選択が表示されます。

[Scope]フィールドで、オプションボタンを選択して、このオブジェクトに関して送信するシステムログメッセージを指定します。

• all：このオブジェクトに関連するすべてのイベントと障害を送信します。

• specific event：このオブジェクトに関連する指定されたイベントのみを送信します。[Event]ドロップダウンリストからイベントポリシーを選択します。

• specific fault：このオブジェクトに関連する指定された障害のみを送信します。[Fault]ドロップダウンリストから障害ポリシーを選択します。

ステップ 7 [+]をクリックして syslog送信元を作成します。

ステップ 8 [Create Syslog Source]ダイアログボックスで、次の操作を実行します。



Syslog 送信元の作成

a) [Name]フィールドに、syslog送信元の名前を入力します。b) [Min Severity]ドロップダウンリストから、送信するシステムログメッセージの重大度の最小値を選択します。

c) [Include]フィールドで、送信するメッセージタイプのチェックボックスをオンにします。d) [Dest Group]ドロップダウンリストから、システムログメッセージの送信先の syslog宛先グループを選択します。

e) [Submit]をクリックします。`

ステップ 9 （任意） syslog送信元を追加するには、もう一度 [+]をクリックし、[Create Syslog Source]ダイアログボックスの手順を繰り返します。

アトミックカウンタの使用

アトミックカウンタについて

アトミックカウンタは、フロー間のトラフィックに関する統計情報を収集できます。アトミック

カウンタを使用すると、ファブリック内のドロップとルーティングミスを検出し、アプリケーショ

ン接続に関する問題の迅速なデバッグと分離が可能になります。たとえば、管理者はすべてのリー

フスイッチでアトミックカウンタを有効にして、エンドポイント 1からエンドポイント 2のパケットをトレースすることができます。送信元と宛先のリーフスイッチ以外のリーフスイッチに

ゼロ以外のカウンタがある場合、管理者はそれらのリーフにドリルダウンできます。

従来の設定では、ベアメタル NICから特定の IPアドレス（エンドポイント）または任意の IPアドレスへのトラフィックの量をモニタすることはほぼ不可能です。アトミックカウンタでは、

データパスに干渉することなく、管理者がベアメタルエンドポイントから受信されたパケット

の数を数えることができます。さらに、アトミックカウンタはエンドポイントまたはアプリケー

ショングループで送受信されるプロトコルごとのトラフィックをモニタリングできます。

リーフ間（TEP間）のアトミックカウンタは次を提供できます。

•送信パケット、受信パケット、ドロップパケット、および超過パケットのカウント

◦送信パケット：送信数は、送信元 TEP（トンネルエンドポイント）から宛先 TEPに送信されたパケット数を表します。

◦受信パケット：受信数は、宛先TEPが送信元TEPから受信したパケット数を表します。

◦ドロップパケット：ドロップ数は、伝送中にドロップされたパケット数を表します。この数値は、送信パケット量と受信パケット量の差です。

◦超過パケット：超過数は、伝送中に受信された超過パケット数を表します。この数値は、転送の不一致または間違った場所へのルーティングミスによって予期せず受信され

たパケット量です。



アトミックカウンタの使用

•最後の 30秒などの短期間のデータ収集、5分、15分、またはそれ以上の長期間のデータ収集

•スパイントラフィックごとの詳細（TEP、リーフ、または VPCの数が 64未満の場合に使用可能）

•継続的なモニタリング

リーフ間（TEP間）アトミックカウンタは累積であり、クリアできません。ただし、30秒のアトミックカウンタは 30秒間隔でリセットされるため、断続的な問題や、再発する問題の分離に使用できます。アトミックカウンタには、アクティブなファブリックネットワークタイ

ムプロトコル（NTP）ポリシーが必要です。

（注）

テナントのアトミックカウンタは次を提供できます:

•送信、受信、ドロップ、および超過パケットを含む、ファブリック全体のトラフィックのアプリケーション固有カウンタ

•モードは次を含みます。

◦ EPtoEP（エンドポイント間）

◦ EPGtoEPG（エンドポイントグループ間）

EPGtoEPGの場合、オプションには ipv4のみ、ipv6のみ、ipv4、ipv6が含まれます。ipv6オプションがある場合は必ず TCAMエントリを 2回使用します。これは、スケール数が、純粋な ipv4ポリシーの場合に予期される数より小さい可能性があることを意味します。

（注）

◦ EPGtoEP（エンドポイントグループ/エンドポイント間）

◦ EPtoAny（エンドポイントツーエニー）

◦ AnytoEP（エニーツーエンドポイント）

◦ EPGtoIP（エンドポイントグループ/IP間、外部 IPアドレスの場合にのみ使用）

◦ EPtoExternalIP（エンドポイント/外部 IPアドレス間）

アトミックカウンタに関する注意事項および制約事項

•アトミックカウンタの使用は、エンドポイントが異なるテナントまたは同じテナント内の異なるコンテキスト（VRF）にある場合はサポートされません。

• IPアドレスが学習されない純粋なレイヤ 2設定（IPアドレスは 0.0.0.0）では、エンドポイント/EPG間およびEPG/エンドポイント間のアトミックカウンタポリシーはサポートされませ




ん。この場合、エンドポイント間および EPG間のポリシーはサポートされます。外部ポリシーは学習された IPアドレスが必要なVirtual Routing and Forwarding（VRF）ベースであり、サポートされます。

•アトミックカウンタの送信元または宛先がエンドポイントである場合、そのエンドポイントはスタティックではなくダイナミックである必要があります。ダイナミックエンドポイント

（fv:CEp）とは異なり、スタティックエンドポイント（fv:StCEp）にはアトミックカウンタに必要な子オブジェクト（fv:RsCEpToPathEp）がありません。

•中継トポロジでは、リーフスイッチはすべてのスパインスイッチを使用したフルメッシュにはなく、リーフ間（TEP間）のカウンタは予期どおりに動作しません。

•リーフ間（TEP間）アトミックカウンタの場合、トンネル数がハードウェア制限を上回ると、システムはモードをトレールモードからパスモードに変更し、ユーザにはスパインご

とのトラフィックは表示されなくなります。

•アトミックカウンタはスパインプロキシトラフィックはカウントしません。

•ファブリックに入る前、またはリーフポートに転送される前にドロップされたパケット、アトミックカウンタによって無視されます。

•ハイパーバイザで切り替えられるパケット（同じポートグループとホスト）はカウントされません。

•アトミックカウンタには、アクティブなファブリックネットワークタイムプロトコル（NTP）ポリシーが必要です。

•アトミックカウンタは IPv6の送信元と宛先で動作しますが、IPv4アドレスと IPv6アドレスを混在させて送信元 IPアドレスと宛先 IPアドレスを設定することはできません。

•送信元または宛先として fvCEpを使用して設定されたアトミックカウンタポリシーでは、fvCEp管理対象オブジェクト（MO）に存在するMACアドレスおよび IPアドレスからの、または両者へのトラフィックのみがカウントされます。fvCEpMOの IPアドレスフィールドが空である場合、そのMACアドレスへの/からのすべてのトラフィックが IPアドレスに関係なくカウントされます。APICが fvCEpについて複数の IPアドレスを学習している場合、前述のように、fvCEp MO自体にある 1つの IPアドレスのみがカウントされます。特定の IPアドレスへの/からのアトミックカウンタポリシーを設定するには、送信元または宛先として fvIp MOを使用します。

• fvCEpの背後に fvIpが存在する場合は、fvCEpベースのポリシーではなく fvIPベースのポリシーを追加する必要があります。




アトミックカウンタの構成

ステップ 1 メニューバーで、[Tenants]をクリックします。

ステップ 2 サブメニューバーで、必要なテナントをクリックします。

ステップ 3 [Navigation]ペインでテナントを拡張し、[Troubleshoot Policies]を拡張します。

ステップ 4 [Troubleshoot Policies]の下で [Atomic Counter Policy]を展開し、トラフィックトポロジを選択します。エンドポイントの組み合わせ、エンドポイントグループ、外部インターフェイスおよび IPアドレス間のトラフィックを測定できます。

ステップ 5 必要なトポロジを右クリックして、[AddtopologyPolicy]を選択し、[AddPolicy]ダイアログボックスを開きます。

ステップ 6 [Add Policy]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドにポリシーの名前を入力します。b) トラフィックの送信元の識別情報を選択するか、入力します。必要な識別情報のソース（エンドポイント、エンドポイントのグループ、外部インターフェイス、ま

たは IPアドレス）によって異なります。c) トラフィックの宛先の識別情報を選択するか、入力します。d) （任意）（任意）[Filters]テーブルで +アイコンをクリックし、カウントするトラフィックのフィルタリングを指定します。

表示される [CreateAtomicCounter Filter]ダイアログボックスで、IPプロトコル番号（たとえばTCP=6）によるフィルタリング、および送信元と宛先の IPポート番号によるフィルタリングを指定できます。

e) [Submit]をクリックし、アトミックカウンタポリシーを保存します。

ステップ 7 [Navigation]ペインで、選択したトポロジの下の新しいアトミックカウンタポリシーを選択します。ポリシー設定が [Work]ペインに表示されます。

ステップ 8 [Work]ペインで [Operational]タブをクリックし、[Traffic]サブタブをクリックして、アトミックカウンタの統計情報を表示します。

SNMP の使用

SNMP の概要Cisco Application Centric Infrastructure（ACI）は、管理情報ベース（MIB）と通知（トラップ）を含む広範な SNMPv1、v2、および v3のサポートを提供します。SNMP標準では、ACIファブリックを管理しモニタするさまざまなMIBをサポートするサードパーティ製アプリケーションを使用できます。



アトミックカウンタの構成

SNMPv3はさらに広範なセキュリティ機能を提供します。各 SNMPv3デバイスで SNMPサービスを有効または無効にするように選択できます。また、各デバイスで SNMP v1および v2要求の処理方法を設定できます。

SNMPの使用方法の詳細については、『Cisco ACI MIB Quick Reference』を参照してください。

ACI での SNMP アクセスのサポートACIでの SNMPのサポートは次のとおりです。

• SNMP読み取りクエリー（Get、Next、Bulk、Walk）は、リーフおよびスパインスイッチとAPICによってサポートされます。

• SNMP書き込みコマンド（Set）は、リーフおよびスパインスイッチまたはAPICによってサポートされません。

• SNMPトラップ（v1、v2c、および v3）は、リーフおよびスパインスイッチと APICによってサポートされます。

ACIは最大 10個のトラップレシーバをサポートします。（注）

• SNMPv3は、リーフおよびスパインスイッチと APICによってサポートされます。

表 1：Cisco APIC リリースでの SNMP サポートの変更

説明リリース

SNMPトラップの宛先として IPv6サポートを追加。1.2(2)

APICコントローラの SNMPサポートを追加。以前のリリースでは、リーフおよびスパインスイッチについてのみ SNMPがサポートされています。

1.2(1)

ACIでサポートされるMIBの完全なリストについては、http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/mib/list/mib-support.htmlを参照してください。

SNMP の設定

GUI による SNMP ポリシーの設定この手順では、ACIスイッチの SNMPポリシーを設定し、有効にします。

はじめる前に

SNMP通信を有効にするには、以下の設定が必要です。



SNMP の設定

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/mib/list/mib-support.html

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/mib/list/mib-support.html

•アウトオブバンドコントラクトを設定して SNMPトラフィックを許可します。SNMPトラフィックは、通常、SNMP要求に UDPポート 161を使用します。

• 'mgmt'テナントでAPICアウトオブバンド IPアドレスを設定します。アウトオブバンドアドレスは APICセットアップ時に設定されますが、アウトオブバンドコントラクトを有効にするには 'mgmt'テナントでアドレスを明示的に設定する必要があります。

ステップ 1 メニューバーで、[Fabric]をクリックします。

ステップ 2 サブメニューバーで、[Fabric Policies]をクリックします。

ステップ 3 [Navigation]ペインで、[Pod Policies]を展開します。

ステップ 4 [Pod Policies]の下で [Policies]を展開します。

ステップ 5 [SNMP]を右クリックし、[Create SNMP Policy]を選択します。新しい SNMPポリシーを作成する代わりに、次の手順で示されるものと同じ方法で [default]ポリシーフィールドを編集できます。

ステップ 6 SNMPポリシーのダイアログボックスで、次の操作を実行します。a) [Name]フィールドに、SNMPポリシーの名前を入力します。b) [Admin State]フィールドで、[Enabled]を選択します。c) [Community Policies]テーブルで +アイコンをクリックし、名前を入力して、[Update]をクリックします。

d) （任意） [SNMP v3 Users]テーブルで +アイコンをクリックし、名前を入力して、ユーザの認証データを入力し、[Update]をクリックします。この手順は SNMPv3アクセスが必要な場合のみ実行します。

ステップ 7 許可されたSNMP管理ステーションを設定するには、SNMPポリシーのダイアログボックスで、次の操作を実行します。

a) [Client Group Policies]テーブルで +アイコンをクリックし、[Create SNMP Client Group Profile]ダイアログボックスを開きます。

b) [Name]フィールドに、SNMPクライアントグループのプロファイル名を入力します。c) [Associated Management EPG]ドロップダウンリストから管理 EPGを選択します。d) [Client Entries]テーブルで +アイコンをクリックします。e) [Name]フィールドにクライアントの名前を入力し、[Address]のフィールドにクライアントの IPアドレスを入力して、[Update]をクリックします。

ステップ 8 [OK]をクリックします。

ステップ 9 [Submit]をクリックします。`

ステップ 10 [Pod Policies]の下で [Policy Groups]を展開して、ポリシーグループを選択するか、または [Policy Groups]を右クリックし、[Create POD Policy Group]を選択します。新しいポッドポリシーグループを作成することも、既存のグループを使用することもできます。ポッド

ポリシーグループには、SNMPポリシーに加えて他のポッドポリシーを含めることができます。

ステップ 11 ポッドポリシーグループのダイアログボックスで、次の操作を実行します。



SNMP の設定

a) [Name]フィールドに、ポッドポリシーグループの名前を入力します。b) [SNMP Policy]ドロップダウンリストから、設定した SNMPポリシーを選択して、[Submit]をクリックします。

ステップ 12 [Pod Policies]の下で [Profiles]を展開し、[default]をクリックします。

ステップ 13 [Work]ペインで、[Fabric Policy Group]ドロップダウンリストから、作成したポッドポリシーグループを選択します。

ステップ 14 [Submit]をクリックします。`


GUI による SNMP トラップ通知先の設定この手順では、SNMPトラップ通知を受信する SNMPマネージャのホスト情報を設定します。

ACIは最大 10個のトラップレシーバをサポートします。10個より多く設定すると、一部では通知が受信されません。

（注）


ステップ 2 サブメニューバーで、[External Data Collectors]をクリックします。

ステップ 3 [Navigation]ペインで、[Monitoring Destinations]を展開します。

ステップ 4 [SNMP]を右クリックし、[Create SNMP Monitoring Destination Group]を選択します。

ステップ 5 [Create SNMP Monitoring Destination Group]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドに、SNMP通知先の名前を入力し、[Next]をクリックします。b) [CreateDestinations]テーブルで +アイコンをクリックし、[Create SNMPTrapDestination]ダイアログボックスを開きます。

c) [Host Name/IP]フィールドに、送信先ホストの IPアドレスまたは完全修飾ドメイン名を入力します。Cisco APIC Release 1.2(2)以降のリリースは、IPv6 SNMPトラップ宛先をサポートします。

（注）

d) 通知先のポート番号と SNMPバージョンを選択します。e) SNMP v1または v2c通知先の場合、[Security Name]として設定したコミュニティ名の 1つを入力し、

[v3 Security Level]として noauthを選択します。f) SNMP v3通知先の場合、[Security Name]として設定したユーザ名の 1つを入力し、必要な [v3 Security

Level]を選択します。g) [Management EPG]ドロップダウンリストから管理 EPGを選択します。h) [OK]をクリックします。i) [Finish]をクリックします。



SNMP の設定

GUI による SNMP トラップソースの設定この手順では、ファブリック内のソースオブジェクトを選択して有効にし、SNMPトラップ通知を生成します。


ステップ 2 サブメニューバーで、[Fabric Policies]をクリックします。

ステップ 3 [Navigation]ペインで、[Monitoring Policies]を展開します。共通ポリシー、デフォルトポリシーで SNMPソースを作成することも、または新しいモニタリングポリシーを作成することもできます。

ステップ 4 必要なモニタリングポリシーを展開し、[Callhome/SNMP/Syslog]を選択します。[CommonPolicy]を選択する場合は、[CommonPolicy]を右クリックして、[Create SNMPSource]を選択し、そのダイアログボックスで次の手順に従ってください。

ステップ 5 [Work]ペインで、[Monitoring Object]ドロップダウンリストから [ALL]を選択します。

ステップ 6 [Source Type]ドロップダウンリストから、[SNMP]を選択します。

ステップ 7 テーブルで +アイコンをクリックし、[Create SNMP Source]ダイアログボックスを開きます。

ステップ 8 [Create SNMP Source]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドに、SNMPポリシーの名前を入力します。b) [Dest Group]ドロップダウンリストから、通知を送信する既存の宛先を選択するか、または [Create

SNMP Monitoring Destination Group]を選択して、新しい宛先を作成します。SNMPの通知先グループを作成する手順は、別項で説明します。

c) [Submit]をクリックします。`

SNMP を使用したシステムのモニタリング個々のホスト（APICまたはその他のホスト）をリモートでモニタし、特定のノードの状態を確認できます。

SNMPを使用してシステムのCPUとメモリの使用状況をチェックし、CPUのスパイクが発生しているかどうかを確認できます。SNMP（ネットワーク管理システム）は、SNMPクライアントを使用して APICの情報にアクセスし、情報を取得します。

リモートでシステムにアクセスして、情報がネットワーク管理システムのコンテキストに属する

ものかどうかを確認し、CPUまたはメモリの使用量が多すぎないか、またはシステムやパフォーマンスの問題が発生しているかどうかを調べることができます。問題の原因がわかると、システ

ムの正常性をチェックし、メモリまたは CPUの使用量多すぎないかどうかを確認できます。

詳細については、『Cisco ACI MIB Quick Reference Manual』を参照してください。



SNMP の設定

SPAN の使用

SPAN の概要スイッチドポートアナライザ（SPAN）ユーティリティを使って、詳細なトラブルシューティングの実行または特定のアプリケーションホストからトラフィックのサンプルを取得し、プロアク

ティブなモニタリングと分析を行うことができます。

SPANは 1つ以上のポート、VLAN、またはエンドポイントグループ（EPG）からのトラフィックをコピーし、ネットワークアナライザによる分析のためにコピーしたトラフィックを 1つ以上の送信先に送信します。このプロセスはどの接続デバイスも中断せず、ハードウェア内で実施さ

れるので不要な CPU負荷を防ぎます。

SPANセッションはソースが受信したトラフィック（入力トラフィック）、ソースから送信したトラフィック（出力トラフィック）、またはその両方をモニタリングするように設定できます。デ

フォルトでは、SPANはすべてのトラフィックをモニタリングしますが、選択したトラフィックだけをモニタリングするようにフィルタを設定できます。

マルチノード SPAN

APICトラフィックのモニタリングポリシーは、各アプリケーショングループのメンバーとそれが接続する場所を追跡するために、適切な場所でポリシーを SPANすることが可能です。いずれかのメンバーが移動した場合、APICは新しいリーフスイッチに自動的にポリシーをプッシュします。たとえば、エンドポイントが新しいリーフスイッチに VMotionすると、SPAN設定が自動的に調整されます。

SPAN の注意事項と制約事項• SPANはトラブルシューティングのために使用します。SPANトラフィックはスイッチリソースのユーザトラフィックと競合します。負荷を最小限にするには、分析対象の特定のトラ

フィックだけをコピーするように SPANを設定します。

• SPAN送信元として l3extLIfPのレイヤ 3サブインターフェイスを指定することはできません。外部ソースからのトラフィックをモニタリングするためにはポート全体を使用します。

•テナントおよびアクセス SPANはカプセル化リモート拡張 SPAN（ERSPAN）タイプ Iを使用し、ファブリック SPANは ERSPANタイプ IIを使用します。ERSPANヘッダーについては、IETFの Internet Draft（https://tools.ietf.org/html/draft-foschiano-erspan-00）を参照してください。

• SPANは IPv6トラフィックをサポートしますが、ERSPANの宛先 IPを IPv6アドレスにすることはできません。

•アクティブな SPANセッションの最大数など、SPAN関連の制限については、『『VerifiedScalability Guide for Cisco ACI』』という資料を参照してください。



SPAN の使用

https://tools.ietf.org/html/draft-foschiano-erspan-00

SPAN セッションの設定この手順では、リモートトラフィックアナライザにレプリケートされたソースパケットを転送

するようにポリシーを設定する方法を示します。


ステップ 2 サブメニューバーで、送信元エンドポイントを含むテナントをクリックします。

ステップ 3 [Navigation]ペインでテナントを拡張し、[Troubleshooting Policies]を拡張して、[SPAN]を拡張します。

ステップ 4 [SPAN]の下で [SPAN Destination Groups]を右クリックし、[Create SPAN Destination Group]を選択します。

ステップ 5 [Create SPAN Destination Group]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドに、SPAN宛先グループの名前を入力します。b) [Create Destinations]テーブルで +アイコンをクリックし、[Create SPAN Destination]ダイアログボックスを開きます。

c) [Name]フィールドに、SPAN宛先の名前を入力します。d) [Destination EPG]ドロップダウンリストで、宛先テナント、アプリケーションプロファイル、または複製されたパケットの転送先の EPGを選択または入力します。

e) [Destination IP]フィールドで、複製されたパケットを受信するリモートサーバの IPアドレスを入力します。

f) [Source IP Prefix]フィールドに、ソースパケットの IPサブネットの基本 IPアドレスを入力します。g) （任意） [Flow ID]フィールドで、SPANパケットのフロー ID値を増分または減分します。h) （任意） [TTL]フィールドで、SPANトラフィックでのパケットの IP存続可能時間（TTL）値を増分または減分します。

i) （任意） [MTU]フィールドで、パケットのMTUトランケーションサイズを増分または減分します。j) （任意） [DSCP]フィールドで、SPANトラフィックでのパケットの IP DSCP値を増分または減分します。

k) [OK]をクリックして、SPAN送信先を保存します。l) [Submit]をクリックして、SPAN送信先グループを保存します。

ステップ 6 [SPAN]の下で [SPAN Source Groups]を右クリックし、[Create SPAN Source Group]を選択します。

ステップ 7 [Create SPAN Source Group]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドに、SPAN送信元グループの名前を入力します。b) [Destination Group]ドロップダウンリストから、以前設定した SPAN送信先グループを選択します。c) [Create Sources]テーブルで +アイコンをクリックし、[Create ERSPAN Source]ダイアログボックスを開きます。

d) [Name]フィールドに、送信元の名前を入力します。e) [Direction]フィールドで、送信元に着信するパケット、送信元から発信するパケット、または着信と発信の両方のパケットを複製および転送するかどうかに基づいて、オプションボタンを選択します。

f) [Source EPG]ドロップダウンリストから、そのパケットが SPAN送信先に複製および転送される EPG（テナント /アプリケーションプロファイル / EPGによって特定）を選択します。



SPAN セッションの設定

g) [OK]をクリックして、SPAN送信元を保存します。h) [Submit]をクリックして、SPAN送信元グループを保存します。

次の作業

SPAN送信先のトラフィックアナライザを使用して、SPAN送信元 EPGからのデータパケットを観察し、パケット形式、アドレス、プロトコルおよびその他の情報を確認できます。

トレースルートの使用

トレースルートの概要

トレースルートツールは、パケットが送信先に移動するときに実際に通るルートを検出するため

に使用されます。トレースルートでは、ホップごとに使用されるパスが識別され、双方向で各ホッ

プにタイムスタンプが付けられます。トレースルートを使用すると、発信元のデバイスと送信先

に最も近いデバイスの間のパスに沿ってポート接続をテストできます。送信先に到達できない場

合は、パス検出によってパスが障害ポイントまで追跡されます。

テナントのエンドポイントから開始された tracerouteは、入力リーフのスイッチに表示される中間ホップとしてデフォルトゲートウェイを示します。

tracerouteは、エンドポイント間やリーフ間（トンネルエンドポイント、または TEP間）など、さまざまなモードをサポートしています。トレースルートはファブリック全体のすべてのパスを

検出し、外部エンドポイントの出口を検出します。パスが妨げられているかどうかを発見するの

に役立ちます。

traceroute の注意事項および制約事項• tracerouteの送信元または宛先がエンドポイントである場合、そのエンドポイントはスタティックではなくダイナミックである必要があります。ダイナミックエンドポイント

（fv:CEp）とは異なり、スタティックエンドポイント（fv:StCEp）には tracerouteに必要な子オブジェクト（fv:RsCEpToPathEp）がありません。

• tracerouteは IPv6の送信元と宛先で動作しますが、IPv4アドレスと IPv6アドレスを混在させて送信元 IPアドレスと宛先 IPアドレスを設定することはできません。

• traceroute関連の制限については、『Verified Scalability Guide for Cisco ACI』というマニュアルを参照してください。



トレースルートの使用

エンドポイント間での traceroute の実行



ステップ 3 [Navigation]ペインでテナントを拡張し、[Troubleshoot Policies]を拡張します。

ステップ 4 [Troubleshoot Policies]の下で、[Endpoint-to-Endpoint Traceroute Policies]を右クリックし、[CreateEndpoint-to-Endpoint Traceroute Policy]を選択します。

ステップ 5 [Create Endpoint-to-Endpoint Traceroute Policy]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドに tracerouteポリシーの名前を入力します。b) [Source End Points]テーブルで +アイコンをクリックし、トレースルートの発信元を編集します。c) [Source]ドロップダウンリストから送信元エンドポイントの IPアドレスを選択または入力し、[Update]をクリックします。

d) [Destination End Points]テーブルで +アイコンをクリックし、トレースルートの発信先を編集します。e) [Destination]ドロップダウンリストから宛先エンドポイントの IPアドレスを選択または入力し、[Update]をクリックします。

f) （任意） [IP Protocol]ドロップダウンリストから、tracerouteパケット用のプロトコルを選択します。デフォルトでは、プロトコルは未定義（0）ですが、tracerouteパケットがフィルタまたはファイアウォールを通過できるようにするためにプロトコルの指定が必要な場合があります。

g) （任意） [Source Port]および [Destination Port]の各ドロップダウンリストから、tracerouteパケット用の送信元および宛先のプロトコル番号を選択します。

h) [Admin State]ドロップダウンリストから、[Start]を選択します。i) [Submit]をクリックして、トレースルートを起動します。

ステップ 6 [Navigation]ペインまたは [Traceroute Policies]テーブルで、トレースルートポリシーをクリックします。トレースルートポリシーが [Work]ペインに表示されます。

ステップ 7 [Work]ペインで [Operational]タブをクリックし、[Source End Points]タブをクリックして、[Results]タブをクリックします。

ステップ 8 [Traceroute Results]テーブルで、追跡に使用された単数または複数のパスを確認します。複数のパスが、送信元ノードから宛先ノードへの移動に使用されている場合がありま

す。

（注）

見やすくするには、[Name]列などの複数の列の幅を広げます。

（注）



エンドポイント間での traceroute の実行

第 2 章

エンドポイント接続のトラブルシューティ

ング

• エンドポイント接続のトラブルシューティング, 19 ページ

• ステータスの確認, 20 ページ

• SFPモジュールの接続, 21 ページ

エンドポイント接続のトラブルシューティング

ステップ 1 各エンドポイントの動作ステータスを調べます。

動作ステータスにはエンドポイントのエラーや設定ミスが示されます。参照先

エンドポイントのステータスの確認, （20ページ）。

ステップ 2 トンネルインターフェイスのステータスを調べます。

動作ステータスにはトンネルのエラーや設定ミスが示されます。トンネルインターフェイスのステータス

の確認, （21ページ）を参照してください。

ステップ 3 エンドポイントグループ（EPG）間でトレースルートを実行します。トレースルートでは、スパインノードなどの中間ノード、およびエンドポイント間の問題が明らかになり

ます。エンドポイント間での tracerouteの実行, （18ページ）を参照してください。

ステップ 4 エンドポイントのアトミックカウンタを設定します。

アトミックカウンタは、発信元エンドポイントがパケットを送信しているか、また送信先エンドポイント

がパケットを受信しているか、そして受信されたパケット数が送信されたパケット数に等しいかどうかを

確認します。アトミックカウンタの構成, （10ページ）を参照してください。

ステップ 5 各 EPGでコントラクトを調べます。各 EPGでのコントラクトを調べ、EPG間でのトラフィックの流れが許可されているかを確認します。テストとして一時的にコントラクトを開き、無制限のトラフィックを許可することができます。


ステップ 6 発信元パケットをモニタリングノードに転送するようにスパンポリシーを設定します。

モニタリングノードのパケットアナライザが、誤ったアドレスやプロトコルなどのパケットの問題を示

します。SPANセッションの設定, （16ページ）を参照してください。

ステータスの確認

エンドポイントのステータスの確認



ステップ 3 [Navigation]ペインでテナントを拡張し、[Application Profiles]を拡張して、エンドポイントが含まれるアプリケーションプロファイルを拡張します。

ステップ 4 [Application EPGs]を展開し、確認する EPGをクリックします。

ステップ 5 [Work]ペインで、[Endpoint]テーブルのエンドポイントのリストから送信元エンドポイントをダブルクリックし、[Client End Point]ダイアログボックスを開きます。

ステップ 6 [Client End Point]ダイアログボックスで、エンドポイントのプロパティを確認し、[Operational]タブをクリックします。

ステップ 7 [Operational]タブで、健全性、ステータスおよび障害情報を表示します。[Status]テーブルで、変更、イベント、またはエラーなどのエントリがある項目をクリックします。

ステップ 8 [Client End Point]ダイアログボックスを閉じます。

ステップ 9 [Endpoint]テーブルでエンドポイントの [Interface]エントリを表示し、ノードとトンネル IDをメモに記録します。

ステップ 10 送信先エンドポイントでこの手順を繰り返します。



ステータスの確認

トンネルインターフェイスのステータスの確認

この手順では、トンネルインターフェイスの動作ステータスを調べる方法を示します。


ステップ 2 サブメニューバーで、[Inventory]をクリックします。

ステップ 3 [Navigation]ペインでポッドを拡張し、発信元エンドポイントインターフェイスのノード IDを拡張します。

ステップ 4 ノードの下で [Interfaces]を拡張し、[Tunnel Interfaces]を拡張して、発信元エンドポイントインターフェイスのトンネル IDをクリックします。

ステップ 5 [Work]ペインで、トンネルインターフェイスのプロパティを確認し、[Operational]タブをクリックします。

ステップ 6 [Operational]タブで、健全性、ステータスおよび障害情報を表示します。[Status]テーブルで、変更、イベント、またはエラーなどのエントリがある項目をクリックします。

ステップ 7 送信先エンドポイントインターフェイスでこの手順を繰り返します。

SFP モジュールの接続SFPモジュールを新規カードに接続する場合は、カードと通信するためにモジュールのリンク速度ポリシーを作成する必要があります。リンク速度ポリシーを作成するには、次の手順に従いま

す。

ステップ 1 リンク速度を指定するインターフェイスポリシーを作成します。

例：<fabricHIfPol name=”SpeedPol” speed=”1G”/>

ステップ 2 インターフェイスポリシーグループ内のリンク速度ポリシーを参照します。

例：<infraAccPortGrp name=”myGroup”>

<infraRsHIfPol tnFabricHIfPolName=”SpeedPol”/></infraAccPortGrp>



トンネルインターフェイスのステータスの確認



SFP モジュールの接続

第 3 章

IP ベース EPG のトラブルシューティング

• IPベース EPGのトラブルシューティング, 23 ページ

• IP-EPGスイッチのトラブルシューティングコマンドの使用, 29 ページ

IP ベース EPG のトラブルシューティングアプリケーション EPGと IPベース EPGという、作成可能な 2種類のエンドポイントグループ（EPG）があります。IPベース EPGは、マイクロセグメント EPGであるという点で、通常のアプリケーション EPGとは異なっています。この手順は、IPベース EPGを正しく設定したことを確認する方法を説明します。

ステップ 1 作成した IPベース EPGが、GUIの [uSeg EPGs]フォルダの下に（次のスクリーンキャプチャに示すように）一覧表示されていることを確認します。

RESTAPIを使用して作成された「IP」という uSeg EPGの下には、1つの IPベースEPGが表示されます。

ステップ 2 各 EPG IP（IPベース EPG）について、EPG - IPの [Properties]画面（ウィンドウペインの右側）にある情報が正しいことを確認します。


画面下部に表示されている IPベース EPGと IPアドレスのリストを確認します。

ステップ 3 Webブラウザから、APICの IPアドレスと、続いて「/visore.html」を、次のように入力します。Visoreは、EPGなどの、システム内のすべてのオブジェクトを表示できるツールです。Visoreを使用して、IPベースEPGが正しく設定されていることを確認します。


IP ベース EPG のトラブルシューティングIP ベース EPG のトラブルシューティング

ステップ 4 ユーザ名とパスワードを入力して、[Login]をクリックし、Visoreにログインします。

ステップ 5 次のように、[Class or DN]の横にあるフィールドにクラスの名前を入力して（たとえば「fvAEPg」）、GUIで確認した IPベース EPGのクエリを実行します。



これは、APICの観点からのビューです。上記では [Total objects shown]が 3と表示されていますが、これはスイッチにダウンロードされたEPGが3つあるということです。GUIで前には「IP」とリストされていた IPベースEPGが、現在では「dn」の横に表示されていることを確認できます。さらに、「isAttrBasedEPg」の横に [yes]が表示されているということは、それが IPベースEPGとして適正に設定されていることを意味します。アプリケーション EPGと IPベース EPGの両方を含むすべてのオブジェクトが、Visoreを使用して正しく設定されていることを確認できます。

（注）

ステップ 6 これはスイッチの観点から見たビューです。スイッチ上で、fvEpPクラスのクエリを実行して、EPGや「crtrnEnabled」属性を確認できます。これは IPベース EPGに対しては [yes]に設定されます。



ステップ 7 適正な構成であることを確認するために、この EPGの下で、EPGの子が IPアドレスとともに表示されていることを調べます。設定されている各 IPアドレスには、次のように、トラフィックを分類するためにスイッチが使用する（「l3IpCktEp」という）1つのオブジェクトがあります。



設定が完了すると、パケットの着信時に、スイッチはパケットを分類するためにこれらのオブジェクトが

使用されます。

ステップ 8 すべてのエンドポイントの pcTagと、設定した IPアドレスが一致していることを確認します。どの EPGにも、pcTagがあります。設定した IPアドレスに一致するすべてのエンドポイントは、この pcTagに分類されます。どのエンドポイントにも、クラスのクエリを実行できる IPアドレスがあります。トラブルシューティングを行う場合には、これらのエンドポイント（サーバ）が、この IPベース EPGに適正に分類されているかどうかを確認することができます（pcTagは IPベース EPGに一致している必要があります）。



IP-EPG スイッチのトラブルシューティングコマンドの使用

トラブルシューティングのために IP-EPG（「IpCkt」とも呼ばれる）にアクセスするには、次の手順に従います。

手順の詳細

目的コマンドまたはアクション

リーフにログインします。ステップ 1

/mit/sysディレクトリに移動します。ステップ 2

/mit/sysディレクトリで、ctx（vrfコンテキストディレクトリ）を見つけます。

ステップ 3

そこには IpCktがあります。このマニュアルでは、

「IpCkt」と「IP-EPG」は置き換え可能な語として使用して

います。

（注）

VRF ctsディレクトリで、IpCktが設定されている特定の BDディレクトリに移動します。

ステップ 4

そのディレクトリに移動すると、「catsummary」から、IpCktに関する情報を取得できます。

ステップ 5

このサマリの「operSt」が「未サポート（unsupported）」ではないことを確認します。

ステップ 6

VLAN IDは、いずれかのshow vlan internal bd-infoコマンドまたは show systeminternal epm vlan allコマンドを使用して検索できます。

（注）IpCktが設定されている BDに対応する VLAN IDを検索します。

ステップ 7

ここでは、特定の sclassを持つすべての設定済み IpCktsを表示できる必要があ

BDの VLAN IDを見つけたら、「show system internalepm <vlan-id> detail」を発行します。

ステップ 8

ります（これは、/mit/sysディレクトリ内の該当する表示内容と一致している

必要があります）。

vshでの手順を vsh_lcに繰り返します。ステップ 9

BDで IpCtkに一致する IPがあるトラフィックを送信し、「show system internal epm endp ip <a.b.c.d>」を実行

ステップ 10

すると、取得した IPに、「sclass」と特定の sclass値のIPフラグがあることを確認できます。

vshでの手順を vsh_lcに繰り返します。ステップ 11


IP ベース EPG のトラブルシューティングIP-EPG スイッチのトラブルシューティングコマンドの使用

スイッチのトラブルシューティングコマンドのリストは、次のとおりです。

Cd /mits/sys/ctx-vxlan…/bd-vxlan…- cat summary

Vsh -c “show system internal epm vlan all” orVsh -c “show vlan internal bd-info”Vsh -c “show system internal epm vlan <vlan-id> detail”Vsh -c “show system internal epm endp ip <a.b.c.d>"Vsh_lc -c “show system internal epm vlan all” orVsh_lc -c “show vlan internal bd-info”Vsh_lc -c “show system internal epm vlan <vlan-id> detail”vsh_lc -c “show system internal epm endp ip <a.b.c.d>”vsh_lc -c “show system internal epm epg”


IP ベース EPG のトラブルシューティングIP-EPG スイッチのトラブルシューティングコマンドの使用

第 4 章

ヘルススコアを使用したトラブルシュー

ティング

• ヘルススコア, 31 ページ

• ヘルススコアのタイプ, 31 ページ

• ネットワーク健全性のモニタリング, 31 ページ

ヘルススコアAPICは、ポリシーモデルを使用してデータをヘルススコアに組み入れます。ヘルススコアはインフラストラクチャ、アプリケーション、またはサービスなどさまざまな領域で集約できます。

ヘルススコア、エラー、ヘルススコアの計算については、『Cisco APIC Fundamentals Guide』を参照してください。

ヘルススコアのタイプAPICは次のヘルススコアのタイプをサポートします。

•システム：ネットワーク全体の健全性を要約します。

•リーフ：ネットワークのリーフスイッチの健全性を要約します。リーフ健全性には、ファントレイ、電源、および CPUを含むスイッチのハードウェア健全性が含まれます。

•テナント：テナントとテナントのアプリケーションの健全性を要約します。

ネットワーク健全性のモニタリングヘルススコアでは、ネットワーク階層をドリルダウンして特定の管理対象オブジェクト（MO）のエラーを分離し、パフォーマンス上の問題を分離することができます。アプリケーションの（テ


ナントごとの）ヘルス、またはリーフスイッチの（ポッドごとの）ヘルスを確認することで、

ネットワークヘルスを確認できます。

ヘルススコアによるフィルタリング

次のツールを使用して、ヘルススコアをフィルタリングできます。

•ヘルススクロールバー：ヘルススクロールバーを使って、どのオブジェクトを表示するかを指定できます。スコアを下げれば、ヘルススコアの低いオブジェクトだけ見ることができ

ます。

•低いヘルススコアの表示：低いヘルススコアを表示するには、ギアアイコンをクリックし、[Show only degraded health score]を選択します。

テナントの健全性の表示

アプリケーションヘルスを表示するには、メニューバーで [Tenants] > [tenant-name]をクリックし、次に [Navigation]ペインでテナント名をクリックします。GUIがアプリケーションや EPGを含むテナントの健全性の要約を表示します。テナントの設定をドリルダウンするには、ヘルスス

コアをダブルクリックします。

健全性の要約の場合は、[Work]ペインの [Health]タブをクリックします。ネットワークのこの表示がヘルススコアとネットワーク上のMO間の関係を示すので、パフォーマンスの問題を分離し、解決することができます。たとえば、テナントのコンテクストの管理オブジェクトの共通シー

ケンスは、テナント >アプリケーションプロファイル >アプリケーション EPG > EPP >ファブリックの場所 > EPGからパスアタッチメント >ネットワークパスエンドポイント >集約インターフェイス >集約されたインターフェイス >集約されたメンバーインターフェイスとなります。

ファブリックの健全性の表示

ファブリックの健全性を表示するには、メニューバーの [Fabric]をクリックします。[Navigation]ペインで、ポッドを選択します。GUIは、ノードを含むポッドの健全性の要約を表示します。ファブリック設定の一部をドリルダウンするには、ヘルススコアをダブルクリックします。

健全性の要約の場合は、[Work]ペインの [Health]タブをクリックします。ネットワークのこの表示がヘルススコアとネットワーク上のMO間の関係を示すので、パフォーマンスの問題を分離し、解決することができます。たとえば、ファブリックのコンテキストにおける管理対象オブジェ

クトの共通シーケンスは、ポッド >リーフ >シャーシ >ファントレイスロット >回線モジュールのスロット >回線モジュール >ファブリックポート >レイヤ 1物理インターフェイス設定 >物理インターフェイス実行時間状態です。


ヘルススコアを使用したトラブルシューティング

ヘルススコアによるフィルタリング

物理ネットワークの問題などのファブリックの問題は、MOが直接関連する場合は、テナントのパフォーマンスに影響を及ぼすことがあります。

（注）

Visore での MO 健全性の表示VisoreでMOの健全性を表示するには、Hアイコンをクリックします。

次のMOを使って、健全性情報を表示します。

• health:Inst

• health:NodeInst

• observer:Node

• observer:Pod

Visoreに関する詳細情報については、『Cisco Application Centric Infrastructure Fundamentals』の資料を参照してください。

ログを使用するヘルススコアのデバッグ

次のログファイルを使用して、APICのヘルススコアをデバッグできます。

• svc_ifc_eventmgr.log

• svc_ifc_observer.log

ログを使用してヘルススコアをデバッグする場合、次の項目を確認してください。

• syslog（エラーまたはイベント）の送信元を確認します。

• syslogポリシーが APICで設定されているかどうかを確認します。

• syslogポリシータイプおよび重大度が正しく設定されているかどうかを確認します。

•コンソール、ファイル、RemoteDest、または Profの syslog宛先を指定できます。RemoteDestの場合は、syslogサーバが実行しておりアクセス可能であることを確認します。

エラーの表示

次のように、エラーの要約を表示できます。

•システムエラー：[System] > [Faults]を選択します。

•テナントエラー：[Tenants] > [tenant-name]をクリックし、左ペインでテナント名をクリックして、右ペインで [Faults]タブを選択します。



Visore での MO 健全性の表示

•ファブリックエラー：[Fabric]をクリックし、左ペインでポッドをクリックし、右ペインで[Faults]タブをクリックします。



エラーの表示

第 5 章

クラスタのトラブルシューティング

• クラスタ管理の注意事項, 35 ページ

• クラスタ内の Cisco APICの交換, 38 ページ

• クラスタのトラブルシューティングのシナリオ, 39 ページ

• クラスタのエラー, 43 ページ

クラスタ管理の注意事項APICクラスタは複数の APICコントローラで構成され、ACIファブリックに対する統合されたリアルタイムモニタリング、診断および構成管理機能がオペレータに提供されます。最適なシステ

ムパフォーマンスが得られるように、APICクラスタを変更する場合は次のガイドラインに従ってください。

クラスタへの変更を開始する前に、必ずその状態を確認してください。クラスタに対して計画

した変更を実行するときは、クラスタ内のすべてのコントローラが正常である必要がありま

す。クラスタ内の 1つ以上のAPICコントローラのヘルスステータスが「十分に正常」でない場合は、先に進む前にその状況を修復してください。また、APICに追加されたコントローラが、APICクラスタ内の他のコントローラと同じバージョンのファームウェアを実行していることを確認します。APICクラスタの健全性の問題の解決についての詳細は、『Cisco APICTroubleshooting Guide』を参照してください。

（注）

クラスタを管理する場合、次の一般的ガイドラインに従ってください。

•現在クラスタにない APICからのクラスタ情報は無視します。正確なクラスタ情報ではありません。

•クラスタスロットには、APIC シャーシ IDが含まれます。スロットを設定すると、割り当て

られたシャーシ IDの APICを解放するまでそのスロットは使用できません。


• APICファームウェアアップグレードが進行中の場合は、それが完了し、クラスタが完全に適合するまでクラスタへの他の変更はしないでください。

•電源の再投入を行う場合は、その前に必ず APICクラスタコントローラを解放し、次いでクラスタに再度追加します。このガイドラインに従わない場合、クラスタ上にある APICクラスタデータベースシャードが破壊される可能性があります。このガイドラインでは、コン

トローラの全消去の実行と、クラスタ内の他の APICコントローラから APICクラスタデータベースの有効なコピーを復元するためのクラスタ同期の実行が求められています。

APICクラスタサイズの拡大APICクラスタサイズを拡大するには、次のガイドラインに従ってください。

•クラスタの拡大がファブリックのワークロードの要求に影響しないときに、クラスタの拡大を予定します。

•クラスタ内の 1つ以上の APICコントローラのヘルスステータスが「十分に正常」でない場合は、先に進む前にその状況を修復してください。

•ハードウェアインストレーションガイドの手順に従って、新しいAPICコントローラを準備します。PINGテストでインバンド接続を確認します。

•クラスタの目標サイズを既存のクラスタサイズコントローラ数に新規コントローラ数を加えた数になるように増やします。たとえば、既存のクラスタサイズコントローラの数が 3で、3台のコントローラを追加する場合は、新しいクラスタの目標サイズを6に設定します。クラスタは、クラスタにすべての新規コントローラが含まれるまで一度にコントローラ 1台ずつ順にサイズを増やします。

既存のAPICコントローラが利用できなくなった場合、クラスタの拡大は停止します。クラスタの拡大を進める前に、この問題を解決します。

（注）

•各アプライアンスの追加時に APICが同期化しなければならないデータ量によって、拡大処理を完了するために必要な時間はアプライアンスごとに 10分を超える可能性があります。クラスタが正常に拡大すると、APICの運用サイズと目標サイズが同じになります。

APICがクラスタの拡大を完了するまでは、クラスタに追加の変更をしないようにします。

（注）

クラスタでの APICコントローラの交換APICコントローラを交換するには、次の注意事項に従ってください。



APICクラスタサイズの拡大

•クラスタ内の 1つ以上の APICコントローラのヘルスステータスが「十分に正常」でない場合は、先に進む前にその状況を修復してください。

•クラスタの同期がファブリックのワークロードの要求に影響しないときに、APICコントローラの交換を予定します。

•交換する APICコントローラの ID番号を記録します。

• APIC 1または 2にログインし、APIC3のシャットダウンを起動します。

• APIC3を解放します。

•ハードウェアインストレーションガイドの手順に従って、APICコントローラの交換を準備します。PINGテストでインバンド接続を確認します。

交換する前にAPICコントローラを解放しないと、クラスタによる交換コントローラの吸収が妨げられます。さらに、解放されたAPICコントローラを稼働状態に戻す前に、全消去を実行して工場出荷時の状態にリセットします。

（注）

• APICクラスタに交換コントローラを追加する場合、以前APICコントローラで使用したコントローラ ID番号を交換するAPICコントローラに割り当てます。APICが交換するコントローラとクラスタの同期へと進みます。

既存のAPICコントローラが使用できなくなると、クラスタの同期が停止します。クラスタの同期を進める前に、この問題を解決します。

（注）

•データ量によって APICはコントローラの交換時に同期する必要があり、交換が完了するまでに交換コントローラごとに 10分以上かかることがあります。交換コントローラとクラスタが正常に同期されると、APICの動作サイズと目標サイズは未変更のままです。

APICがクラスタの同期を完了するまで、クラスタに追加の変更を加えないでください。

（注）

•クラスタの同期がファブリックのワークロードの要求に影響しないときに、APICコントローラの交換を予定します。

• UUIDとファブリックのドメイン名は、リブートしてもAPICコントローラに保持されます。ただし、初期状態にリブートするとこの情報は削除されます。APICコントローラを 1つのファブリックから別のファブリックへ移動する場合、そのコントローラを異なるACIファブリックに追加する前に初期状態にリブートする必要があります。



クラスタでの APICコントローラの交換

クラスタサイズの縮小

APICクラスタのサイズを縮小し、クラスタから除去されるAPICコントローラアプライアンスを解放するには、以下のガイドラインに従ってください。

縮小されたクラスタに含まれる APICコントローラアプライアンスの電源を切って解放するプロセスに順次従わないと、予期しない結果を招く可能性があります。ファブリックへの接続を維持する

には、認識されない APICコントローラアプライアンスを使わないでください。

警告

クラスタサイズを縮小すると、残りの APICコントローラアプライアンスの負荷が増大します。

（注）

•クラスタの同期がファブリックのワークロードの要求に影響しないときに、APICコントローラサイズの縮小を予定します。

•クラスタの目標サイズを新たな低い値に減らします。たとえば、既存のクラスタサイズが 6で、3台のコントローラを削除する場合は、クラスタの目標サイズを 3に減らします。

•既存のクラスタの最も大きな番号が付いたコントローラアプライアンス IDから始め、新しいより小さい目標番号に到達するまで、1つずつ交換する APICコントローラアプライアンスを解放して、電源を切り、接続解除します。

各コントローラアプライアンスの解放と削除が終わると、APICがクラスタを同期します。

•既存の APICアプライアンスが使用できなくなると、クラスタの同期は停止します。クラスタの同期を進める前に、この問題を解決します。

•データ量によって APICはアプライアンスの交換時に同期する必要があり、各コントローラアプライアンスの解放が完了するまでにアプライアンスごとに 10分以上かかることがあります。

クラスタに追加の変更を行う前に、必要な解放手順全体を完了し、APICがクラスタの同期を完了できるようにしてください。

警告

クラスタ内の Cisco APIC の交換

クラスタの管理の詳細については、「クラスタ管理の注意事項」を参照してください。（注）



クラスタサイズの縮小

クラスタの拡大または縮小については、『『Cisco APIC Getting Started Guide』』を参照してください。

（注）

APICを交換すると、パスワードは必ずクラスタから同期されます。APIC 1を交換するときには、パスワードの入力を求められますが、そのパスワードはクラスタ内の既存のパスワードを

優先して無視されます。APIC 2または 3を交換するときには、パスワードの入力は求められません。

（注）

ステップ 1 交換する APICを特定します。

ステップ 2 controller controller-id decommissionコマンドを使用して、APICを解放します。APICを解放すると、APIC IDとシャーシ IDのマッピングが削除されます。通常、新しい APICには、異なる APIC IDがあるので、クラスタに新しい APICを追加するにはこのマップを削除する必要があります。

（注）

ステップ 3 同じ APICを再稼動する場合には、次の手順に従ってください。a) acidiag rebootコマンドを使用して、APICを再起動します。b) APICがエラーなしでブートされることを確認します。c) controller controller-id commissionコマンドを使用して、APICを稼働します。d) クラスタの残りの部分に新しい APIC情報が伝播するまでに数分かかります。

ステップ 4 新しい APICを稼動する場合は、次の手順に従ってください。a) ファブリックから APICを切断します。b) ファブリックに交換 APICを接続します。c) controller controller-id commissionコマンドを使用して、APICを稼働します。d) 新しい APICを起動します。e) クラスタの残りの部分に新しい APIC情報が伝播するまでに数分かかります。

クラスタのトラブルシューティングのシナリオ次の表は、Cisco APICに共通するクラスタのトラブルシューティングのシナリオを示します。



クラスタのトラブルシューティングのシナリオ

ソリューション問題

2つの解決策があります。

•目標サイズはそのままにし、APICを交換します。APICの交換の手順については、「クラスタ内の Cisco APICの交換」を参照してください。

•クラスタサイズを 4に縮小するには、コントローラ 5を解放し、APIC2として再稼動します。APICの解放および再稼働の手順については、「クラスタ内のCiscoAPICの交換」を参照してください。目標サイズは 4のままにし、再設定したAPICが実行されると動作サイズは 4になります。

交換する APICをクラスタに追加し、目標サイズと運用サイズを拡張できます。新しいAPICを追加する手順については、『Getting Started Guide for the Cisco APIC』を参照してください。

（注）

APICノードはクラスタ内でエラーが発生しま

す。たとえば、5つのAPICのクラスタのノード 2がエラーを起こすとします。

インフラストラクチャ VLANの不一致があるかを確認するには、次のコマンドを使用します。

• cat /mit/sys/lldp/inst/if-\[eth1--1\]/ctrlradj/summary：リーフスイッチ上で設定された VLANを表示します。

• cat /mit/sys/lldp/inst/if-\[eth1--1\]/ctrlradj/summary：接続された APICによってアドバタイズされるインフラストラクチャ VLANを表示します。

これらのコマンドの出力が異なるVLANを表示する場合、新しいAPICは正しいインフラストラクチャ VLANで設定されていません。この問題を解決するには、次の手順に従います。

•レスキューユーザを使用して APICにログインします。APICはファブリックの一部ではないため、管理者のクレデンシャルは機能しません。

（注）

•設定を消去し、acidiag touch setupコマンドを使って APICを再起動します。

• APICを再設定します。ファブリック名、TEPアドレス、およびクラスタの APICにマッチするインフラストラクチャ VLANを確認します。

•リーフノードをリロードします。

新しい APICはファブリックに接続し、リー

フスイッチへの接続は

失われます。





この問題は次の一連のイベントの後に発生することがあります。

• APIC1と APIC2が相互に検出する。

• APIC1がリブートし、新しいシャーシ ID（APIC1a）でアクティブになる。

• 2つの APICが通信しなくなる。

このシナリオでは、APIC1aが APIC2を検出しますが、APIC2はオフラインと見なされる APIC1があるクラスタ内に存在するので使用できません。その結果、APIC1aは APIC2からのメッセージを受け入れません。

この問題を解決するには、APIC2上の APIC1を解放し、再度 APIC1を稼働させます。

起動後に 2つの APICが通信できません。

この問題は次の一連のイベントの後に発生することがあります。

•クラスタのメンバが使用不可になるか、またはクラスタが分割されます。

• APICが解放されます。

•クラスタの復旧後には、解放されたAPICは自動的に稼働します。

問題を解決するには、クラスタの復旧後に APICを解放します。

解放された APICはクラスタに参加します。

この問題は、APICがクラスタで登録されたシャーシ IDと異なるシャーシ IDで起動したときに起こります。その結果、この APICからのメッセージが廃棄されます。

この問題を解決するには、リブートの前にAPICが解放されていることを確認してください。

再起動後のシャーシ IDの不一致。

さまざまな条件が、AdminstrativeClusterSizeに合わせたクラスタによるOperationalClusterSizeの拡張の妨げになる可能性があります。詳しくは、エラーを検査し、「クラスタのエラー」を確認してください。

APICはクラスタサイズの変更時にエラーを

表示します。

この問題は、クラスタを拡大するときに 2つのAPICが同じクラスタ IDで設定されると起こります。その結果、2つのうち 1つの APICがクラスタに参加できず、拡張競合シャーシ ID不一致のエラーが表示されます。

この問題を解決するには、新しいクラスタ IDでクラスタの外側にAPICを設定します。

APICがクラスタに参加できない。





この問題を診断するには、次の設定を確認してください。

•ファブリック検出が完了していることを確認します。

•ファブリックから欠落しているスイッチを特定します。

•スイッチが APICからの IPアドレスを要求し、受信したかどうかを確認します。

•スイッチがソフトウェアイメージをロードしたことを確認します。

•スイッチがアクティブになっている時間を確認します。

•すべてのプロセスがスイッチ上で動作していることを確認します。詳細については、acidiagコマンドを参照してください。

•欠落しているスイッチに正しい日付と時刻が設定されていることを確認します。

•スイッチが他の APICと通信できることを確認します。

APICがクラスタで到達不能。

この問題は、次の状況で発生します。

• OperationalClusterSizeが APICの数より少ない。

•展開のコンテンダがない（たとえば、adminサイズは 5ですがクラスタ IDが 4の APICがありません）

•クラスタと新しい APICの間に接続がない

•新しい APICによってハートビートメッセージが拒否される

•システムヘルスが正常でない

•使用できないアプライアンスが再配置に関するデータサブセットを伝送している

•再配置に関するデータサブセットがあるアプライアンスでサービスがダウンしている

•再ロケーションに関連するデータサブセットの不健全

クラスタが拡大しな

い。





次の点をチェックします。

•接続の問題：pingを使用して接続を確認します。

•インターフェイスタイプの不一致：すべての APICがインバンド通信になっていることを確認します。

•ファブリック接続：ファブリック接続が正常であること、およびファブリック検出が完了していることを確認します。

•拒否されたハートビート：fltInfraIICIMsgSrcOutsiderエラーを確認します。一般的なエラーには、動作クラスタサイズ、シャーシ IDの不一致、動作クラスタサイズの外の送信元 ID、承認されていない送信元、およびファブリックドメインの不一致が含まれます。

APICがダウンしている。

クラスタのエラーAPICは、クラスタの問題の診断に役立つさまざまなエラーをサポートします。ここでは、2つの主要なクラスタのエラーの種類について説明します。

エラーの破棄

APICは現在のクラスタのピアまたはクラスタ拡大候補以外からのクラスタメッセージを破棄します。APICはメッセージを破棄すると、発信元の APICのシリアル番号、クラスタ ID、およびタイムスタンプを含むエラーを生成します。次の表で、破棄されるメッセージのエラーを要約し

ます。

意味Fault

送信側 APICのシャーシ IDが拡大のためにクラスタが認識するシャーシ IDと一致しません。

expansion-contender-chassis-id-mismatch

送信側 APICのファブリック IDが拡大のためにクラスタが認識するファブリック IDと一致しません。

expansion-contender-fabric-domain-mismatch

送信側 APICに拡大に不適切なクラスタ IDがあります。値は、現在の OperationalClusterSizeよりも1大きい必要があります。

expansion-contender-id-is-not-next-to-oper-cluster-size

送信側 APICが継続的ハートビートメッセージを送信しません。

expansion-contender-message-is-not-heartbeat

送信側 APICのファブリック IDがクラスタのファブリック IDと一致しません。

fabric-domain-mismatch



クラスタのエラー

意味Fault

送信側APICに、受信側APICのものとは 1以上違う OperationalClusterSizeがあります。受信側 APICは要求を拒否します。

operational-cluster-size-distance-cannot-be-bridged

送信側 APICのシャーシ IDがクラスタに登録されたシャーシ IDと一致しません。

source-chassis-id-mismatch

送信側 APICに許可されていないクラスタ ID値があります。

source-cluster-id-illegal

送信側 APICの目標シャーシ IDが受信側 APICのシャーシ IDに一致しません。

source-has-mismatched-target-chassis-id

送信側 APICに、クラスタの OperationalClusterSize外のクラスタ IDがあります。

source-id-is-outside-operational-cluster-size

送信側 APICには、クラスタで現在解放されているクラスタ IDがあります。

source-is-not-commissioned

クラスタ変更時エラー

次のエラーは、APICのクラスタサイズの変更時のエラーがある場合に適用されます。

意味Fault

このエラーは、OperationalClusterSizeが拡張期間にわたり 2のままになると発行されます。問題を解決するには、クラス

タの目標サイズをリストアします。

cluster-is-stuck-at-size-2

クラスタ内の最後の APICが稼働中であり、それがクラスタの縮小を妨げています。

most-right-appliance-remains-commissioned

クラスタがより大きいクラスタ IDを持つ APICを検出できず、クラスタの拡張を行えません。

no-expansion-contender

移動するデータのサブセットは、障害が起きているサービス

上にコピーがあります。APICに複数のこのような障害があることを示します。

service-down-on-appliance-carrying-replica-related-to-relocation

移動するデータのサブセットは、使用できない APIC上にコピーがあります。このエラーを解決するには、使用できない

APICを復元します。

unavailable-appliance-carrying-replica-related-to-relocation

移動するデータのサブセットは、正常でないAPIC上にコピーがあります。このエラーを解決するには、障害の根本原因を

特定します。

unhealthy-replica-related-to-relocation




APICの使用不可

次のクラスタのエラーは、APICが使用できない場合に適用できます。

意味Fault

クラスタがデータのサブセットを起動できません。fltInfraReplicaReplicaState

データストアサービスの破損を示します。fltInfraReplicaDatabaseState

データのサブセットが完全には機能していないことを

示します。

fltInfraServiceHealth

APICが完全には機能していないことを示します。fltInfraWiNodeHealth







第 6 章

統計情報を使用したトラブルシューティン

グ

• GUIでの統計情報の表示, 47 ページ

• スイッチの統計情報コマンド, 48 ページ

• GUIを使用する統計情報しきい値の管理, 50 ページ

• 統計情報に関するトラブルシューティングのシナリオ, 50 ページ

• 統計情報の消去, 52 ページ

GUI での統計情報の表示アプリケーションプロファイル、物理インターフェイス、ブリッジドメイン、ファブリックノー

ドなど、APICGUIを使用して、多数のオブジェクトの統計情報を表示できます。GUIで統計情報を表示するには、[Navigation]ペインでオブジェクトを選択し、[STATS]タブをクリックします。

たとえば、インターフェイスの統計情報を表示するには、次の手順を実行します。

ステップ 1 メニューバーで、[FABRIC] > [INVENTORY]を選択します。

ステップ 2 [Navigation]ペインで、ポッドを選択します。

ステップ 3 ポッドを展開し、スイッチを展開します。

ステップ 4 [Navigation]ペインで、[Interfaces]を拡張し、eth1/1を選択します。

ステップ 5 [Work]ペインで、[STATS]タブを選択します。

APICがインターフェイスの統計情報を表示します。


次の作業

[Work]ウィンドウの次のアイコンを使って、APICでの統計情報の表示方法を管理できます。

• Refresh：統計情報を手動で更新します。

• Show Table View：表とチャートの表示を切り替えます。

• Start or Stop Stats：統計情報の自動更新を有効または無効にします。

• Select Stats：表示するカウンタとサンプルのインターバルを指定します。

• Download Object as XML：XML形式でオブジェクトをダウンロードします。

• Measurement Type（ギアアイコン）：統計情報の測定タイプを指定します。オプションとして累積値、定期値、平均値、傾向値があります。

スイッチの統計情報コマンド次のコマンドを使って、ACIリーフスイッチの統計情報を表示できます。

目的コマンド

詳細については、『Cisco Nexus 9000 SeriesNX-OS Configuration Guide』を参照してください。

レガシー Cisco Nexusの show/clearコマンド


統計情報を使用したトラブルシューティング

スイッチの統計情報コマンド

目的コマンド

スパインポートの統計情報を表示します。

• port_num：スロットのない前面ポート番号。

• [detail]：SNMP、クラス、および転送統計情報を返します。

• [nz]：非ゼロの値のみを表示します。

• internal：内部ポート統計情報を表示します。

• int_port_num：内部論理ポート番号。たとえば、BCM-0/97の場合は、97を入力します。

リンクのリセットが行われると、ス

イッチのカウンタはゼロに戻されま

す。カウンタリセットの条件には、

次のものがあります。

（注）

•偶発的なリンクのリセット

•手動で有効にしたポートがある（ポートを無効にしていた）

show platform internal counters port [port_num |detail | nz | {internal [nz | int_port_num]}]

VLAN統計情報を表示します。show platform internal counters vlan[hw_vlan_id]

TEP統計情報を表示します。show platform internal counters tep[tunnel_id]

フロー統計情報を表示します。show platform internal counters flow[rule_id |{dump [asic inst] | [slice direction |indexhw_index]}]

ポート統計情報を消去します。clear platform internal counters port[port_num |{internal [ int_port_num]}]

VLANカウンタを消去します。clear platform internal counters vlan[hw_vlan_id]

デバッグのログレベルを設定します。debug platform internal stats logging levellog_level

デバッグのロギングタイプを設定します。debug platform internal stats logging{err|trace|flow}



スイッチの統計情報コマンド

GUI を使用する統計情報しきい値の管理

ステップ 1 メニューバーで、[Fabric] > [Fabric Policies]を選択します。

ステップ 2 [Navigation]ペインで +をクリックし、[Monitoring Policies]を展開します。

ステップ 3 [Navigation]ペインで、モニタリングポリシー名（デフォルトなど）を拡張します。

ステップ 4 [Stats Collection Policies]をクリックします。

ステップ 5 [Stats Collection Policies]ウィンドウで、しきい値を設定するモニタリングオブジェクトおよび統計タイプを選択します。

ステップ 6 [Work]ペインで、[CONFIG THRESHOLDS]の下の +をアイコンをクリックします。

ステップ 7 [THRESHOLDS FOR COLLECTION]ウィンドウで +をクリックし、しきい値を追加します。

ステップ 8 [Choose a Property]ウィンドウで、統計タイプを選択します。

ステップ 9 [EDIT STATS THRESHOLD]ウィンドウで、次のしきい値を指定します。

• Normal Value：カウンタの有効値。

• Threshold Direction：しきい値が最大値または最小値かどうかを示します。

• Rising Thresholds（Critical、Major、Minor、Warning）：値がしきい値を上回った場合にトリガーされます。

• Falling Thresholds（Critical、Major、Minor、Warning）：値がしきい値を下回った場合にトリガーされます。

ステップ 10 上限および下限しきい値の設定値とリセット値を指定できます。設定値はエラーがトリガーされるタイミングを指定します。リセット値はエラーが消去されるタイミングを指定します。

ステップ 11 しきい値を保存するには、[SUBMIT]をクリックします。

ステップ 12 [THRESHOLDS FOR COLLECTION]ウィンドウで、[CLOSE]をクリックします。

統計情報に関するトラブルシューティングのシナリオ次の表で、Cisco APICに共通する統計情報に関するトラブルシューティングのシナリオを要約します。



GUI を使用する統計情報しきい値の管理


モニタリングポリシーが適用されていても、APICが統計情報の収集やトリガーしきい値に対する操作など、対応するアクションを実行しない

と問題が発生します。問題を解決するには、次の手順に従ってくださ

い。

• monPolDnが正しいモニタリングポリシーを指していることを確認します。

•セレクタが正しく設定され、エラーがないことを確認します。

•テナントのオブジェクトの場合は、モニタリングポリシーとの関係を確認します。

APICは、設定済みのモニタリングポリシーを

課すことはありませ

ん。

問題を解決するには、次の手順に従ってください。

•モニタリングポリシーおよび収集ポリシー内でデフォルトによって無効になっている統計情報を確認します。

•収集ポリシーを確認し、統計情報がデフォルトで無効になっているか、または特定のインターバルで無効になっているかを識別し

ます。

•統計ポリシーを確認し、統計情報がデフォルトで無効になっているか、または特定のインターバルで無効になっているかを識別し

ます。

ファブリックヘルスの統計情報を除き、5分間の統計情報がスイッチに保存され、スイッチがリブートされると失われま

す。

（注）

設定した一部の統計情

報が見つからない。


•収集設定を確認してください。モニタリングポリシーの最上位レベルで設定されていると、特定のオブジェクトまたは統計タイプ

では、統計情報が無効になる場合があります。

•モニタリングオブジェクトに割り当てられた収集ポリシーを確認します。ポリシーが存在するのを確認し、管理状態および履歴保

持の値を確認します。

•統計タイプが正しく設定されていることを確認します。

統計情報や履歴を設定

した期間保持できない



統計情報に関するトラブルシューティングのシナリオ


設定が履歴記録サイズの最大値を超えていないかどうか確認します。制

限事項は次のとおりです。

• 5分間の細かさでのスイッチ統計情報は 12サンプル（5分間の細かさの統計情報の 1時間分）に限られています。

• 1000サンプルの厳しい制限があります。たとえば、1時間の細かさの統計情報は 41日間まで保持できます。

設定されたインターバ

ルにわたって保持され

ない統計情報がある。


•送信先ポリシーの状態オブジェクトを確認します。

•統計をエクスポートする予定のノードでエクスポートステータスのオブジェクトをチェックし、エクスポートステータスと詳細の

プロパティを確認してください。集約されたEPG統計はAPICノードから 15分ごとにエクスポートされます。その他の統計は、送信元ノードから 5分ごとにエクスポートされます。たとえば、EPGが2つのリーフスイッチに展開され、EPG集約パートにエクスポートするように設定されていると、それらパートはノードから 5分ごとにエクスポートされます。

•設定が、統計情報エクスポートポリシーの最大数を超過しているかどうかを確認します。統計情報エクスポートポリシーの最大数

は、テナント数とほぼ同じです。

各テナントは、複数の統計情報エクスポートポリシーを

持つことができ、複数のテナントで同じエクスポートポ

リシーを共有できますが、ポリシーの総数はテナントの

概数までに制限されます。

（注）

エクスポートポリシー

は設定されるが、APICが統計情報をエクス

ポートしない。

APICは 10秒ごとに 5分間の細かさの統計情報を収集しますが、この値は一部のインターフェイスの収集インターバルと完全には一致しませ

ん。その結果、統計情報が少し長い、または短い期間を表す場合があり

ます。

5分間統計が変動する

詳しくは、「統計情報の消去」を参照してください。一部の履歴統計情報が

見つからない。

統計情報の消去APICとスイッチは次のように統計情報を消去します。

•スイッチ：スイッチは次のように統計情報を消去します。



統計情報の消去

◦スイッチの 5分間の統計情報は、5分間カウンタ値が報告されないと消去されます。この状況は、ポリシーによってオブジェクトが削除されるか、または統計情報が無効化さ

れるときに起こる場合があります。

◦より細分化された統計情報は、1時間以上統計情報がないと消去されます。これは次の場合に起きることがあります。

◦統計情報がポリシーによって無効化されている。

◦スイッチが 1時間以上 APICから切断されている。

◦スイッチは5分後に削除されたオブジェクトの統計情報を消去します。オブジェクトがこの時間内に再作成されると、統計カウントは未変更のままになります。

◦無効化されたオブジェクト統計情報は 5分後に削除されます。

◦システム状態が変化し、統計情報レポートが 5分間無効化されると、このスイッチによって統計情報が消去されます。

• APIC：APICはインターフェイス、EPG、温度センサー、およびヘルス統計情報を含むオブジェクトを、1時間後に消去します。







第 7 章

ポートトラッキングを使用したトラブル

シューティング

• アップリンク障害検出のためのポートトラッキングポリシー, 55 ページ

• GUIを使用したポートトラッキング, 56 ページ

• NX-OS CLIを使用したポートトラッキング, 57 ページ

• REST APIを使用したポートトラッキング, 57 ページ

アップリンク障害検出のためのポートトラッキングポリ

シーアップリンク障害検出は、ファブリックアクセスグローバルポートトラッキングポリシーで有

効にできます。ポートトラッキングポリシーが、リーフスイッチとスパインスイッチとの間の

リンクの状態を監視します。有効なポートトラッキングポリシーがトリガーされると、リーフ

スイッチは、EPGが展開されているスイッチのすべてのアクセスインターフェイスを停止します。

拡張 GUIでは、ポートトラッキングは、[Fabric] -> [Access Policies] -> [Port Tracking]にあります。基本 GUIでは、ポートトラッキングは、[System] -> [Port Tracking]にあります。

（注）

リーフスイッチのモデルに応じて、各リーフスイッチは、各スパインスイッチへの 6、8、または 12個のアップリンク接続を持つことができます。ポートトラッキングポリシーは、ポリシーをトリガーするアップリンク接続の数と、指定のアップリンク数を超過した後にリーフスイッチ

アクセスポートを復旧するまでの遅延タイマーを指定します。

ポートトラッキングポリシーの動作例を以下に示します。

•各リーフスイッチには、スパインスイッチへの 6個のアクティブなアップリンク接続があります。


•ポートトラッキングポリシーは、ポリシーをトリガーする各リーフスイッチへのアクティブなアップリンク接続のしきい値を 2に指定します。

•ポートトラッキングポリシーは、リーフスイッチからスパインスイッチへのアクティブなアップリンク接続の数が 2にドロップするとトリガーされます。

•各リーフスイッチはそのアップリンク接続をモニタし、ポリシーで指定されているしきい値に従ってポートトラッキングポリシーをトリガーします。

•アップリンク接続が復旧すると、リーフスイッチは遅延タイマーが満了するまで、アクセスポートの再開を待機します。これによりファブリックは、リーフスイッチアクセスポート

でトラフィックを再開する前に、再統合する時間を取ることができます。大規模なファブ

リックでは、遅延タイマーに長めの時間を設定することが必要になる場合があります。

このポリシーの設定には注意が必要です。ポートトラッキングをトリガーするアクティブス

パインリンク数に対するポートトラッキングの設定が高すぎると、すべてのリーフスイッチ

アクセスポートがダウンします。

（注）

GUI を使用したポートトラッキングこの手順では、GUIを使用したポートトラッキング機能の使用方法について説明します。

ステップ 1 [Fabric]メニューから、[Access Policies]を選択します。

ステップ 2 [Access Policies]の左側のナビゲーションウィンドウで、[Global Polices]を選択します。

ステップ 3 [Global Policies]タブの下で、[Port Tracking]タブを選択します。

ステップ 4 ポートトラッキング機能をオンにするには、[Properties]の下の [Port tracking state]の横で [on]を選択します。

ステップ 5 ポートトラッキング機能をオフにするには、[Properties]の下の [Port tracking state]の横で [off]を選択します。

ステップ 6 [Delay restore timer]を設定します。これはファブリックポートトラッキングの開始後に、ダウンリンクを回復して起動するまでの秒数を指定するために使う設定パラメータです。

ステップ 7 下回ったらこの設定をトリガーする、残りのリンクの最大数（0～12のいずれかの設定値）を入力します（デフォルトは 0です）。

ステップ 8 [Submit]をクリックして、目的のポートトラッキング設定をファブリックのすべてのスイッチにプッシュします。


ポートトラッキングを使用したトラブルシューティング

GUI を使用したポートトラッキング

NX-OS CLI を使用したポートトラッキングこの手順では、NX-OSCLIを使用したポートトラッキング機能の使用方法について説明します。

ステップ 1 ポートトラッキング機能を次のようにオンにします。

例：apic1# show porttrackConfigurationAdmin State : onBringup Delay(s) : 120Bringdown # Fabric Links up : 0

ステップ 2 ポートトラッキング機能を次のようにオフにします。

例：apic1# show porttrackConfigurationAdmin State : offBringup Delay(s) : 120Bringdown # Fabric Links up : 0

REST API を使用したポートトラッキングはじめる前に

この手順では、REST APIを使用したポートトラッキング機能の使用方法について説明します。

ステップ 1 REST APIを使用して、次のようにポートトラッキング機能をオンにします（admin state：on）。<polUni><infraInfra dn="uni/infra"><infraPortTrackPol name="default" delay="5" minlinks="4" adminSt="on">

</infraPortTrackPol></infraInfra></polUni>

ステップ 2 REST APIを使用して、次のようにポートトラッキング機能をオフにします（admin state：off）。<polUni><infraInfra dn="uni/infra"><infraPortTrackPol name="default" delay="5" minlinks="4" adminSt=“off">

</infraPortTrackPol></infraInfra></polUni>



NX-OS CLI を使用したポートトラッキング



REST API を使用したポートトラッキング

第 8 章

設定ゾーンのトラブルシューティング

• 設定ゾーン , 59 ページ

• GUIを使用した設定ゾーンの作成, 60 ページ

• NX-OSスタイルの CLIを使用した設定ゾーンの作成, 61 ページ

• REST APIを使用した設定ゾーンの作成, 62 ページ

• 設定ゾーンのサポート対象ポリシー, 62 ページ

設定ゾーン設定ゾーンは、ACIファブリックを、さまざまなタイミングで実行される設定変更により更新できる多様なゾーンに分割します。これにより、トラフィックを中断したりファブリックをダウン

させたりする可能性もある、障害ファブリック全体の設定を展開してしまうリスクが制限されま

す。管理者はクリティカルではないゾーンに設定を展開し、それが適切であることを確認した時

点でクリティカルゾーンに展開できます。

次のポリシーは、設定組織ゾーンのアクションを指定します。

• infrazone:ZonePは、システムアップグレード時に自動的に作成されます。削除したり変更したりすることはできません。

• infrazone:Zoneには、1つ以上のノードグループ（NodeGrp）が含まれます。1つのノードが属することができるのは、1つのゾーン（infrazone:Zone）のみです。NodeGrpには、名前と

展開モードの 2つの属性があります。展開モードのプロパティは、次のように指定できます。

◦ enabled：保留中の更新は即座に送信されます。

◦ disabled：新規の更新は延期されます。


無効にされた（disabled）設定ゾーンのノードは、アップグレード、ダウングレード、稼働、または解放しないでください。

（注）

◦ triggered：保留中の更新は即座に送信され、展開モードは triggeredに変更する前の値

に自動的にリセットされます。

特定の一群のノードに対するポリシーを作成、修正、または削除すると、更新はポリシーを展開

する各ノードに送信されます。ポリシークラスと infrazone設定に基づいて、以下のことが起き

ます。

• infrazone設定に従わないポリシーの場合、APICは更新をすべてのファブリックノードに即座に送信します。

• infrazone設定に従うポリシーの場合、更新は infrazone設定に応じて次のように続行しま

す。

◦ノードがinfrazone:Zoneに属している場合、ゾーンの展開モードが有効に設定されてい

れば、更新は即座に送信されます。設定されていなければ、更新は延期されます。

◦ノードが infrazone:Zoneに属していない場合、更新は即座に実行されます。これはACIファブリックのデフォルトの動作です。

GUI を使用した設定ゾーンの作成はじめる前に

この手順では、GUIを使用して設定ゾーンを作成する方法について説明します。

次の画面は、設定ゾーンの作成、その展開モードの設定、ゾーンへのノードの追加を実行できるGUIの場所を示しています。このビューで、すべての延期された更新情報を確認できます。



GUI を使用した設定ゾーンの作成

NX-OS スタイルの CLI を使用した設定ゾーンの作成この手順では、NX-OS CLIを使用して設定ゾーンを作成する方法について説明します。

NX-OS CLIを使用して設定ゾーンを作成するには、次の手順に従います。

例：

apic1# configureapic1(config)# zonesapic1(config-zones)# zone testZoneapic1(config-zone)# description testZone-Descriptionapic1(config-zone)# deployment-mode enabledapic1(config-zone)# switch 101-102 , 103apic1(config-zone)# exitapic1(config-zones)# exitapic1(config)# exit



NX-OS スタイルの CLI を使用した設定ゾーンの作成

REST API を使用した設定ゾーンの作成はじめる前に

この手順では、REST APIを使用して設定ゾーンを作成する方法について説明します。

REST APIを使用して設定ゾーンを作成するには、次の手順に従います。

例：

<infraInfra><infrazoneZoneP name="default">

<infrazoneZone name=”Group1" deplMode="disabled"><infrazoneNodeGrp name=”nodeGroup"><infraNodeBlk name=”nodeblk1" from_=101 to_=101/><infraNodeBlk name=”nodeblk2” from_=103 to_=103/></infrazoneNodeGrp></infrazoneZone><infrazoneZone name=”Group2" deplMode="enabled"><infrazoneNodeGrp name=”nodeGroup2"><infraNodeBlk name=”nodeblk" from_=102 to_=102/> </infrazoneNodeGrp></infrazoneZone></infrazoneZoneP>

</infraInfra>

設定ゾーンのサポート対象ポリシー次のポリシーが、設定ゾーン用にサポートされています。

analytics:CfgSrvbgp:InstPolcallhome:Groupcallhome:InvPcallhome:QueryGroupcdp:IfPolcdp:InstPolcomm:Polcomp:DomPcoop:Poldatetime:Poldbgexp:CorePdbgexp:TechSupPdhcp:NodeGrpdhcp:PodGrpedr:ErrDisRecoverPolep:ControlPep:LoopProtectPeqptdiagp:TsOdFabPeqptdiagp:TsOdLeafPfabric:AutoGEpfabric:ExplicitGEpfabric:FuncPfabric:HIfPolfabric:L1IfPolfabric:L2IfPolfabric:L2InstPolfabric:L2PortSecurityPol



REST API を使用した設定ゾーンの作成

fabric:LeCardPfabric:LeCardPGrpfabric:LeCardSfabric:LeNodePGrpfabric:LePortPfabric:LePortPGrpfabric:LFPortSfabric:NodeControlfabric:OLeafSfabric:OSpineSfabric:PodPGrpfabric:PortBlkfabric:ProtGEpfabric:ProtPolfabric:SFPortSfabric:SpCardPfabric:SpCardPGrpfabric:SpCardSfabric:SpNodePGrpfabric:SpPortPfabric:SpPortPGrpfc:DomPfc:FabricPolfc:IfPolfc:InstPolfile:RemotePathfvns:McastAddrInstPfvns:VlanInstPfvns:VsanInstPfvns:VxlanInstPinfra:AccBaseGrpinfra:AccBndlGrpinfra:AccBndlPolGrpinfra:AccBndlSubgrpinfra:AccCardPinfra:AccCardPGrpinfra:AccNodePGrpinfra:AccPortGrpinfra:AccPortPinfra:AttEntityPinfra:CardSinfra:ConnFexBlkinfra:ConnFexSinfra:ConnNodeSinfra:DomPinfra:FexBlkinfra:FexBndlGrpinfra:FexGrpinfra:FexPinfra:FuncPinfra:HConnPortSinfra:HPathSinfra:HPortSinfra:LeafSinfra:NodeBlkinfra:NodeGrpinfra:NodePinfra:OLeafSinfra:OSpineSinfra:PodBlkinfra:PodGrpinfra:PodPinfra:PodSinfra:PolGrpinfra:PortBlkinfra:PortPinfra:PortSinfra:PortTrackPolinfra:Profileinfra:SHPathSinfra:SHPortSinfra:SpAccGrpinfra:SpAccPortGrp



設定ゾーンのサポート対象ポリシー

infra:SpAccPortPinfra:SpinePinfra:SpineSisis:DomPoll2ext:DomPl2:IfPoll2:InstPoll2:PortSecurityPoll3ext:DomPlacp:IfPollacp:LagPollldp:IfPollldp:InstPolmcp:IfPolmcp:InstPolmgmt:NodeGrpmgmt:PodGrpmon:FabricPolmon:InfraPolphys:DomPpsu:InstPolqos:DppPolsnmp:Polspan:Destspan:DestGrpspan:SpanProvspan:SrcGrpspan:SrcTargetShadowspan:SrcTargetShadowBDspan:SrcTargetShadowCtxspan:TaskParamspan:VDestspan:VDestGrpspan:VSpanProvspan:VSrcGrpstormctrl:IfPolstp:IfPolstp:InstPolstp:MstDomPolstp:MstRegionPoltrig:SchedPvmm:DomPvpc:InstPolvpc:KAPol



設定ゾーンのサポート対象ポリシー

第 9 章

ACL の許可および拒否ログを使用したトラブルシューティング

• GUIを使用した ACL契約許可ロギングの有効化, 65 ページ

• NX-OS CLIを使用した ACL契約許可ロギングの有効化, 66 ページ

• REST APIを使用した ACL契約許可ロギングの有効化, 67 ページ

• GUIを使用した禁止契約拒否ロギングの有効化, 67 ページ

• NX-OS CLIを使用した禁止契約拒否ロギングの有効化, 68 ページ

• REST APIを使用した禁止契約拒否ロギングの有効化, 69 ページ

• GUIを使用した ACL許可および拒否ログの表示, 70 ページ

• REST APIを使用した ACL許可および拒否ログ, 71 ページ

• NX-OS CLIを使用した ACL許可および拒否ログの表示, 71 ページ

GUI を使用した ACL 契約許可ロギングの有効化次の手順は、GUIを使用して契約許可ロギングを有効にする方法を示しています。

ステップ 1 メニューバーで、[Tenants] > [<tenant name>]の順に選択します。

ステップ 2 [Navigation]ペインで、[Security Policies]を展開します。

ステップ 3 [Contracts]を右クリックし、[Create Contract]を選択します。

ステップ 4 [Create Contract]ダイアログボックスで、次の操作を実行します。a) [Name]フィールドに、契約の名前を入力します。b) [Scope]フィールドで、そのスコープ（[VRF]、[Tenant]、または [Global]）を選択しますc) オプション。契約に適用するターゲット DSCPまたは QoSクラスを設定します。


d) [Subjects]を展開します。

ステップ 5 [Create Contract Subject]ダイアログボックスで、次の操作を実行します。

ステップ 6 件名と説明（オプション）を入力します。

ステップ 7 オプション。ターゲット DSCPのドロップダウンリストから、件名に適用する DSCPを選択します。

ステップ 8 契約を両方向でなくコンシューマからプロバイダの方向にのみ適用するのでない限り、[ApplyBothDirections]はオンにしたままにしておきます。

ステップ 9 [Apply Both Directions]をオフにした場合は、[Reverse Filter Ports]をオンのままにして、レイヤ 4の送信元と宛先のポートを交換します。これによりルールはプロバイダからコンシューマに適用されます。

ステップ 10 [Filter Chain]を展開します。

ステップ 11 [Name]ドロップダウンリストで、オプションを選択します。たとえば [arp]、[default]、[est]、または [icmp]をクリックします。

ステップ 12 [Directives]ドロップダウンリストで、[log]をクリックします。

ステップ 13 [Update]をクリックします。


ステップ 15 [Submit]をクリックします。ロギングがこの契約に対して有効になります。

NX-OS CLI を使用した ACL 契約許可ロギングの有効化次の例は、NX-OS CLIを使用して契約許可ロギングを有効にする方法を示しています。

ステップ 1 契約許可ルールにより送信できたパケットまたはフローのロギングを有効にするには、次のコマンドを使

用します。configuretenant <tenantName>contract <contractName> type <permit>subject <subject Name>access-group <access-list> <in/out/both> log

例：

次に例を示します。apic1# configureapic1(config)# tenant BDMode1apic1(config-tenant)# contract Logicmp type permitapic1(config-tenant-contract)# subject icmpapic1(config-tenant-contract-subj)# access-group arp both log

ステップ 2 許可ロギングを無効にするには、no形式のaccess-groupコマンドを使用します。たとえば、no access-group

arp both logコマンドを使用します。


ACL の許可および拒否ログを使用したトラブルシューティングNX-OS CLI を使用した ACL 契約許可ロギングの有効化

REST API を使用した ACL 契約許可ロギングの有効化次の例は、REST APIを使用して契約許可ロギングを有効にする方法を示しています。

契約許可ロギングを有効にするには、次の例のようなデータを POSTします。POST https://192.0.20.123/api/node/mo/uni/tn-sgladwin_t1/brc-ICMP_Contract.json{"vzBrCP":{

"attributes":{"dn" : "uni/tn-sgladwin_t1/brc-ICMP_Contract","name" : "ICMP_Contract","rn" : "brc-ICMP_Contract",""status" : "created"},

"children":[{"vzSubj":{

"attributes":{"dn" : "uni/tn-sgladwin_t1/brc-ICMP_Contract/subj-Permit_Contract_ICMP","name" : "Permit_Contract_ICMP","rn":"subj-Permit_Contract_ICMP","status":"created"},

"children":[{"vzRsSubjFiltAtt":{

"attributes":{"status":"created,modified","tnVzFilterName":"icmp","directives":"log"},

"children":[]}}]}}]}}response: {"totalCount":"0","imdata":[]}

GUI を使用した禁止契約拒否ロギングの有効化次の手順は、GUIを使用して禁止契約拒否ロギングを有効にする方法を示しています。


ステップ 2 [Navigation]ペインで、[Security Policies]を展開します。

ステップ 3 [Taboo Contracts]を右クリックし、[Create Taboo Contract]を選択します。

ステップ 4 [Create Taboo Contract]ダイアログボックスで、次の操作を実行して禁止契約を指定します。a) [Name]フィールドに、契約の名前を入力します。b) オプション。[Description]フィールドに、禁止契約の説明を入力します。


ACL の許可および拒否ログを使用したトラブルシューティングREST API を使用した ACL 契約許可ロギングの有効化

c) [Subjects]を展開します。

ステップ 5 b. [Create Taboo Contract Subject]ダイアログボックスで、次の操作を実行します。a) [Specify Identity of Subject]領域に、名前と説明（オプション）を入力します。b) [Filters]を展開します。c) [Name]ドロップダウンリストから、<tenant_name>/arp、<tenant_name>/default、<tenant_name>/est、

<tenant_name>/icmpのいずれかの値、または [Create Filter]を選択します。

[Specify Filter Identity]領域で [Create Filter]を選択した場合、次の操作を実行して、ACL拒否ルールの基準を指定します。

（注）

1 名前とオプションの説明を入力します。

2 [Entries]を展開し、ルールの名前を入力し、ルールの ACL拒否条件を選択します。

3 [Update]をクリックします。

4 [Submit]をクリックします。`

ステップ 6 [Directives]ドロップダウンリストで、[log]をクリックします。

ステップ 7 [Update]をクリックします。


ステップ 9 [Submit]をクリックします。ロギングがこの禁止契約に対して有効になります。

NX-OS CLI を使用した禁止契約拒否ロギングの有効化次の例は、NX-OS CLIを使用して禁止契約拒否ロギングを有効にする方法を示しています。

ステップ 1 禁止契約拒否ルールのためにドロップされたパケットまたはフローのロギングを有効にするには、次のコ

マンドを使用します。configuretenant <tenantName>contract <contractName> type <deny>subject <subject Name>access-group <access-list> <both> log

例：

次に例を示します。apic1# configureapic1(config)# tenant BDMode1apic1(config-tenant)# contract dropFTP type deny


ACL の許可および拒否ログを使用したトラブルシューティングNX-OS CLI を使用した禁止契約拒否ロギングの有効化

apic1(config-tenant-contract)# subject dropftpapic1(config-tenant-contract-subj)# access-group https both log

ステップ 2 拒否ロギングを無効にするには、no形式のaccess-groupコマンドを使用します。たとえば、no access-group

https both logコマンドを使用します。

REST API を使用した禁止契約拒否ロギングの有効化次の例は、REST APIを使用して禁止契約拒否ロギングを有効にする方法を示しています。

ACL拒否ロギングを有効にするには、次の例のようなデータを POSTします。POST https://192.0.20.123/api/node/mo/uni/tn-sgladwin_t1/taboo-TCP_Taboo_Contract.json{"vzTaboo":{

"attributes":{"dn":"uni/tn-sgladwin_t1/taboo-TCP_Taboo_Contract","name":"TCP_Taboo_Contract","rn":"taboo-TCP_Taboo_Contract","status":"created"},

"children":[{"vzTSubj":{

"attributes":{"dn":"uni/tn-sgladwin_t1/taboo-TCP_Taboo_Contract/tsubj-TCP_Filter_Subject","name":"TCP_Filter_Subject","rn":"tsubj-TCP_Filter_Subject","status":"created"},

"children":[{"vzRsDenyRule":{

"attributes":{"tnVzFilterName":"TCP_Filter","directives":"log","status":"created"},

"children":[]}}]}}]}}response: {"totalCount":"0","imdata":[]}


ACL の許可および拒否ログを使用したトラブルシューティングREST API を使用した禁止契約拒否ロギングの有効化

GUI を使用した ACL 許可および拒否ログの表示次の手順は、GUIを使用して、トラフィックフローの ACL許可および拒否ログを（有効になっていれば）表示する方法を示しています。


ステップ 2 [Navigation]ペインで、[Tenant <tenant name>]をクリックします。

ステップ 3 [Tenant <tenant name>]作業ペインで、[Operational]タブをクリックします。

ステップ 4 [Operational]タブの下で、[Flows]タブをクリックします。[Flows]タブの下で、いずれかのタブをクリックして、レイヤ 2許可ログ（[L2 Permit]）、レイヤ 3許可ログ（[L3 Permit]）、レイヤ 2拒否ログ（[L2 Drop]）、またはレイヤ 3拒否ログ（[L3 Drop]）のログデータを表示します。各タブで、トラフィックがフローしていれば、ACLロギングデータを表示できます。データポイントは、ログタイプと ACLルールに応じて異なります。たとえば、[L3 Permit]ログには次のデータポイントが含まれます。

• Timestamp

• VRF

•送信元 IPアドレス

•宛先 IPアドレス

•プロトコル

•送信元ポート

•宛先ポート

•送信元MACアドレス

•宛先MACアドレス

•ノード（データ送信元のスイッチ）

•送信元インターフェイス

• VLAN

• VRFカプセル化

また、[Flows]タブの横の [Packets]タブを使用して、シグニチャ、送信元、および宛先が同じであるパケットのグループ（最大 10個）の ACLログにアクセスできます。送信されたりドロップされたりするパケットのタイプを確認できます。

（注）


ACL の許可および拒否ログを使用したトラブルシューティングGUI を使用した ACL 許可および拒否ログの表示

REST API を使用した ACL 許可および拒否ログ次の例は、REST APIを使用して、トラフィックフローの許可および拒否ログデータを表示する方法を示しています。

はじめる前に

ACL契約許可および拒否ログのデータを表示する前に、許可または拒否ロギングを有効にする必要があります。

REST APIを使用して次のクエリを送信します。GEThttps://192.0.20.123/api/node/mo/uni/tn-sgladwin_t1.json?rsp-subtree-include=stats&rsp-subtree-class=fvOverallHealthHist15min{"totalCount":"1","imdata":[{"fvTenant":{

"attributes":{"childAction":"","descr":"","dn":"uni/tn-sgladwin_t1","lcOwn":"local","modTs":"2016-06-22T15:46:30.745+00:00","monPolDn":"uni/tn-common/monepg-default","name":"sgladwin_t1","ownerKey":"","ownerTag":"","status":"","uid":"15374"

}}}]}

NX-OS CLI を使用した ACL 許可および拒否ログの表示次の手順は、NX-OS CLI show acllogコマンドを使用して ACLログの詳細を表示する方法を示しています。


ACL の許可および拒否ログを使用したトラブルシューティングREST API を使用した ACL 許可および拒否ログ

コマンドの完全な構文は、次のとおりです。show acllog {permit | drop} l3 {pkt | flow} tenant <tenantname> vrf <vrf name> srcip <source ip> dstip <destination ip> srcport <source port> dstport <destinationport> protocol <protocol> srcintf <source interface> start-time <startTime> end-time <endTime>

ステップ 1 次の例では、show acllog permit l3 pkt tenant <tenant name> vrf <vrf name> [detail]コマンドを使用して、送信された一般的な VRF ACLレイヤ 3許可パケットに関する詳細情報を表示する方法を示しています。

apic1# show acllog permit l3 pkt tenant common vrf default detailacllog permit l3 packets detail:srcIp : 10.2.0.19dstIp : 10.2.0.16protocol : udpsrcPort : 13124dstPort : 4386srcIntf : port-channel5vrfEncap : VXLAN: 2097153pktLen : 112srcMacAddr : 00:00:15:00:00:28dstMacAddr : 00:00:12:00:00:25timeStamp : 2015-03-17T21:31:14.383+00:00

ステップ 2 次の例では、show acllogコマンドを使用して、一般的なVRFレイヤ 3 UDPパケット（送信元 IPアドレス10.2.0.19、宛先 IPアドレス 10.2.0.16、送信元ポート 13124、宛先ポート 4386、送信元インターフェイスポートチャネル 15、開始時刻 2015-03-17T21:00:00、および終了時刻 2015-03-18T00:00:00）に関する情報を表示する方法を示しています。

apic1# show acllog permit l3 pkt tenant common vrf copy srcip 10.2.0.19 dstip 10.2.0.16 srcport13124 dstport 4386protocol 17 srcintf port-channel5 start-time 2015-03-17T21:00:00 end-time 2015-03-18T00:00:00acllog Permit L3 Packets

srcIp dstIp protocol srcport dstport Node srcIntf vrfEncappktLen timeStamp

------------ ----------- ----- -------- ------- ------ --------- --------------------- --------------10.2.0.19 10.2.0.16 udp 13124 4386 101 port-channel5 VXLAN:

2097153 112 2015-03-17T21:

31:14.383+00:00

ステップ 3 次の例では、 show acllog permit l2 pkt tenant <tenant name> vrf <vrf name> [detail]コマンドを使用して、送信されたデフォルトの VRFレイヤ 2パケットに関する詳細情報を表示する方法を示しています。

apic1# show acllog permit l2 pkt tenant common vrf default detail

acllog permit l2 packets detail:srcIntf : port-channel5pktLen : 1srcMacAddr : 00:00:66:00:00:66


ACL の許可および拒否ログを使用したトラブルシューティングNX-OS CLI を使用した ACL 許可および拒否ログの表示

dstMacAddr : 00:00:89:00:00:00timeStamp : 2015-03-17T21:31:14.383+00:00

ステップ 4 次の例では、show acllog permit l2 pkt tenant <tenant name> vrf <vrf name> srcintf <s interface>コマンドを使用して、インターフェイスポートチャネル 15から送信されたデフォルトのVRFレイヤ 2パケットに関する情報を表示する方法を示しています。

apic1# show acllog permit l2 pkt tenant common vrf default srcintf port-channel5acllog permit L2 Packets

Node srcIntf pktLen timeStamp-------------- -------------- -------- --------------

port-channel5 1 2015-03-17T21:31:14.383+00:00

ステップ 5 次の例では、show acllog drop l3 pkt tenant <tenant name> vrf <vrf name> [detail]コマンドを使用して、ACL拒否ルールによりドロップされたパケットに関する詳細情報を表示する方法を示しています。

apic1# show acllog drop l3 pkt tenant common vrf copy detailacllog drop l3 packets detail:srcIp : 10.2.0.19dstIp : 10.2.0.16protocol : udpsrcPort : 13124dstPort : 4386srcIntf : port-channel5vrfEncap : VXLAN: 2097153pktLen : 112srcMacAddr : 00:00:15:00:00:28dstMacAddr : 00:00:12:00:00:25timeStamp : 2015-03-17T21:31:14.383+00:00

ステップ 6 次の例は、show acllog drop l3 flow tenant <tenant name> vrf <vrf name> srcip <source ip> dstip <dst ip>srcport <src port> dstport <dst port> protocol <protocol> srcintf <src intf>コマンドの使用方法を示しています。このコマンドにより、UDPパケット（ドロップされたもの、および送信元 IPアドレス 10.2.0.19、宛先 IPアドレス 10.2.0.16、送信元ポート 13124、宛先ポート 4386、およびソースインターフェイスポートチャネル 15を持つもの）についての情報が表示されます。

apic1# show acllog drop l3 pkt tenant common vrf copy srcip 10.2.0.19 dstip 10.2.0.16 srcPort 13124dstPort 4386 protocol 17 srcintf port-channel5acllog drop L3 Packets

srcIp dstIp protocol srcPort dstPort Node srcIntfvrfEncap pktLen timeStamp-------------- -------------- -------- -------- -------- -------------- ---------------------------- -------- --------------

10.2.0.19 10.2.0.16 udp 13124 4386 port-channel5VXLAN: 2097153 112 2015-03-17T21: 31:14.383+00:00

ステップ 7 次の例は、show acllog drop l2 pkt tenant <tenant name> vrf <vrf name> [detail]コマンドの使用方法を示しています。このコマンドは、ACL拒否ルールのためにドロップされたパケットに関する詳細情報を表示します。

apic1# show acllog drop l2 pkt tenant common vrf copy detail



acllog drop l2 packets detail:srcIntf : port-channel87pktLen : 1122srcMacAddr : 00:00:11:00:00:11dstMacAddr : 11:00:32:00:00:33timeStamp : 2015-03-17T21:31:14.383+00:00

ステップ 8 次の例は、show acllog drop l2 pkt tenant <tenant name> vrf <vrf name> srcintf <srcintf name>コマンドの使用方法を示しています。このコマンドは、特定のインターフェイスから発信された、ドロップされたパ

ケットに関する情報を表示します。

apic1# show acllog drop l2 pkt tenant common vrf copy srcintf port-channel87acllog drop L2 Packets

Node srcIntf pktLen timeStamp-------------- -------------- -------- --------------

port-channel87 1122 2015-03-17T21:31:14.383+00:00



第 10 章

マルチポッドのトラブルシューティング

• GUIを使用したマルチポッドのトラブルシューティング, 75 ページ

• NX-OS CLIを使用したマルチポッドのトラブルシューティング, 75 ページ

• REST APIを使用したマルチポッドのトラブルシューティング, 75 ページ

GUI を使用したマルチポッドのトラブルシューティングTBD（Vipul Jainと Vijay Krishnanがこの機能の手順を送ることになっている SMEです）

NX-OS CLI を使用したマルチポッドのトラブルシューティング

TBD：Vipulおよび Vijayから情報を待っています。

REST API を使用したマルチポッドのトラブルシューティング

TBD



マルチポッドのトラブルシューティング

REST API を使用したマルチポッドのトラブルシューティング

第 11 章

デジタルオプティカルモニタリングを使用

したトラブルシューティング

• GUIを使用したデジタルオプティカルモニタリングの有効化, 77 ページ

• REST APIを使用したデジタルオプティカルモニタリングの有効化, 78 ページ

• GUIを使うデジタルオプティカルモニタリングを使用したトラブルシューティング, 80ページ

• REST APIを使うデジタルオプティカルモニタリングを使用したトラブルシューティング,80 ページ

GUI を使用したデジタルオプティカルモニタリングの有効化

物理インターフェイスに関するデジタルオプティカルモニタリング（DOM）統計情報を表示するには、その前にスイッチポリシーを使用し、グループポリシーに関連付けて、リーフまたはス

パインインターフェイスの DOMを有効にします。

GUIを使用して DOMを有効にするには、次の手順に従います。

ステップ 1 メニューバーで、[Fabric] > [Fabric Policies]の順に選択します。

ステップ 2 [Navigation]ペインで、[Switch Policies] > [Policies] > [Fabric Node Controls]の順に展開します。

ステップ 3 [Fabric Node Controls]を展開すると、既存のポリシーのリストが表示されます。

ステップ 4 [Work]ペインで、[ACTIONS]ドロップダウンメニューをクリックし、[Create Fabric Node Control]を選択します。

[Create Fabric Node Control]ダイアログボックスが表示されます。

ステップ 5 [Create Fabric Node Control]ダイアログボックスで、次の操作を実行します。


a) [Name]フィールドにポリシーの名前を入力します。b) オプション。[Description]フィールドに、ポリシーの説明を入力します。c) [Enable DOM]の横にあるボックスをオンにします。

ステップ 6 [SUBMIT]をクリックして、ポリシーを作成します。これでこのポリシーを、続くいくつかの手順に従って、ポリシーグループおよびプロファイルに関連付け

ることができます。

ステップ 7 [Navigation]ペインで、[Switch Policies] > [Policy Groups]の順に展開します。

ステップ 8 [Work]ペインで、[ACTIONS]ドロップダウンメニューをクリックし、[Create Leaf Switch PolicyGroup]（スパインの場合は [Create Spine Switch Policy Group]）を選択します。[Create Leaf Switch Policy Group]または [Create Spine Switch Policy Group]ダイアログボックスが表示されます。

ステップ 9 ダイアログボックスで、次の操作を実行します。

a) [Name]フィールドにポリシーグループの名前を入力します。b) [Node Control Policy]ドロップダウンメニューから、既存のポリシー（作成したばかりのポリシーなど）を選択するか、または [Create Fabric Node Control]を選択します。

c) [Submit]をクリックします。

ステップ 10 作成したポリシーグループをスイッチに次のように接続します。a) [Navigation]ペインで、[Switch Policies] > [Profiles]を展開します。b) [Work]ペインで、[ACTIONS]ドロップダウンメニューをクリックし、[Create Leaf Switch Profile]または [Create Spine Switch Profile]を選択します。

c) ダイアログボックスで、[Name]フィールドにプロファイルの名前を入力します。d) プロファイルに関連付けるスイッチの名前を、[Switch Associations]で追加します。e) [Blocks]プルダウンメニューから、該当するスイッチの横のチェックボックスをオンにします。f) [Policy Group]プルダウンメニューから、前に作成したポリシーグループを選択します。g) [UPDATE]をクリックし、[SUBMIT]をクリックします。

REST API を使用したデジタルオプティカルモニタリングの有効化

物理インターフェイスに関するデジタルオプティカルモニタリング（DOM）統計情報を表示するには、インターフェイスの DOMを有効にします。

REST APIを使用して DOMを有効にするには、次の手順に従います。

ステップ 1 次の例のように、ファブリックノード制御ポリシー（fabricNodeControlPolicy）を作成します。


デジタルオプティカルモニタリングを使用したトラブルシューティング


<fabricNodeControl dn="uni/fabric/nodecontrol-testdom" name="testdom" control="1"rn="nodecontrol-testdom" status="created" />

ステップ 2 次のように、ファブリックノード制御ポリシーをポリシーグループに関連付けます。

<?xml version="1.0" encoding="UTF-8" ?><fabricLeNodePGrp dn="uni/fabric/funcprof/lenodepgrp-nodegrp2" name="nodegrp2"rn="lenodepgrp-nodegrp2" status="created,modified" >

<fabricRsMonInstFabricPol tnMonFabricPolName="default" status="created,modified" /><fabricRsNodeCtrl tnFabricNodeControlName="testdom" status="created,modified" />

</fabricLeNodePGrp>

ステップ 3 ポリシーグループをスイッチ（次の例ではスイッチは 103）に、次のように関連付けます。

<?xml version="1.0" encoding="UTF-8" ?><fabricLeafP><attributes><dn>uni/fabric/leprof-leafSwitchProfile</dn><name>leafSwitchProfile</name><rn>leprof-leafSwitchProfile</rn><status>created,modified</status></attributes><children><fabricLeafS><attributes><dn>uni/fabric/leprof-leafSwitchProfile/leaves-test-typ-range</dn><type>range</type><name>test</name><rn>leaves-test-typ-range</rn><status>created,modified</status></attributes><children><fabricNodeBlk><attributes><dn>uni/fabric/leprof-leafSwitchProfile/leaves-test-typ-range/nodeblk-09533c1d228097da</dn>

<from_>103</from_><to_>103</to_><name>09533c1d228097da</name><rn>nodeblk-09533c1d228097da</rn><status>created,modified</status></attributes></fabricNodeBlk></children><children><fabricRsLeNodePGrp><attributes><tDn>uni/fabric/funcprof/lenodepgrp-nodegrp2</tDn><status>created</status></attributes></fabricRsLeNodePGrp></children></fabricLeafS>




</children></fabricLeafP>

GUI を使うデジタルオプティカルモニタリングを使用したトラブルシューティング

GUIを使用して DOM統計情報を表示するには、次の手順に従います。

はじめる前に

インターフェイスの DOM統計情報を表示するには、インターフェイスのデジタルオプティカルモニタリング（DOM）統計情報を事前に有効にしておく必要があります。

ステップ 1 メニューバーで、[Fabric]、[Inventory]の順に選択します。

ステップ 2 [Navigation]ペインで、調査する物理インターフェイスがあるポッドとリーフノードを展開します。

ステップ 3 [Interfaces]を展開します。

ステップ 4 [Physical Interfaces]を展開します。

ステップ 5 調査する物理インターフェイスを展開します。

ステップ 6 [DOM Stats]を選択します。DOM統計情報がインターフェイスに表示されます。

REST API を使うデジタルオプティカルモニタリングを使用したトラブルシューティング

DOM統計情報を XMLの REST APIクエリを使用して表示するには、次の手順に従います。



GUI を使うデジタルオプティカルモニタリングを使用したトラブルシューティング

はじめる前に

インターフェイスの DOM統計情報を表示するには、インターフェイスのデジタルオプティカルモニタリング（DOM）を事前に有効にしておく必要があります。

次の例は、REST APIクエリを使用して、物理インターフェイスについての DOM統計情報（node-104のeth1/25）を表示する方法を示しています。GEThttps://192.0.20.123/api/node/mo/topology/pod-1/node-104/sys/phys-[eth1/25]/phys/domstats.xml?query-target=children&target-subtree-class=ethpmDOMRxPwrStats&subscription=yes

次の応答が返されます。

response : {"totalCount":"1",

"subscriptionId":"72057611234705430","imdata":[

{"ethpmDOMRxPwrStats":{"attributes":{

"alert":"none","childAction":"","dn":"topology/pod-1/node-104/sys/phys[eth1/25]/phys/domstats/rxpower","hiAlarm":"0.158490","hiWarn":"0.079430","loAlarm":"0.001050","loWarn":"0.002630","modTs":"never","status":"","value":"0.139170"}}}]}







第 12 章

Cisco APIC パスワードの復元およびフォールバックログインドメインの使用

• APICパスワードの回復, 83 ページ

• NX-OSスタイルの CLIを使用した Cisco APIC設定を消去するレスキューユーザアカウントの使用, 84 ページ

• フォールバックログインドメインを使用したローカルデータベースへのログイン, 85 ページ

APICパスワードの回復APICのパスワードを復元するには、次の手順に従います。

ステップ 1 「aci-admin-passwd-reset.txt」という空のファイルを作成し、保存します。

ステップ 2 このファイルを USBドライブに追加します。

ステップ 3 USBドライブを Cisco APICの背面にある USBポートの 1つに接続します。

ステップ 4 Cisco Integrated Management Controller（CIMC）を使用するかまたはデバイスの電源を再投入して、APICを再起動します。

ステップ 5 [Press any key to enter the menu]というプロンプトが APICにより表示された場合は、キーを押して起動プロセスを中断します。

ステップ 6 APICは、サポートされる Linuxバージョンを表示します。システムにインストールされたバージョンを強調表示し、eを押して起動コマンドを編集します。

ステップ 7 カーネルを強調表示し、eを押してコマンドをブートシーケンスで編集します。

ステップ 8 次に示すように、コマンドの最後に空のファイルの名前を追加します。

例：[ Minimal BASH-like line editing is supported. For the first word, TABlists possible command completions. Anywhere else TAB lists the possible


completions of a device/filename. ESC at any time cancels. ENTERat any time accepts your changes.]

< rhgb quiet selinux=0 audit=1 aci-admin-passwd-reset

ステップ 9 Enterキーを押して、ファイルを保存します。

ステップ 10 bを押して APICを起動します。パスワードリセット操作をキャンセルし、デフォルトのブートパラメータに戻るには、Escキーと Enterキーを押します。

（注）

ステップ 11 APICが起動し、新しい管理者パスワードの入力を求めます。

NX-OS スタイルの CLI を使用した Cisco APIC設定を消去するレスキューユーザアカウントの使用

レスキューユーザは、APICへのアクセスを（クラスタ内にない場合でも）提供する緊急ログインです。このログインを使用して、設定の消去を含め、トラブルシューティングコマンドを実行で

きます。

APICが正常なクラスタの一部である場合、レスキューユーザアカウントは adminパスワードで保護されます。

（注）

ステップ 1 Cisco Integrated Management Controller（CIMC）コンソールを使用して APICにアクセスします。

ステップ 2 レスキューユーザとしてログインします。

adminパスワードを使用してAPICファブリックにログオンしている場合、レスキューユーザパスワードはその adminパスワードと同じです。そうでない場合、レスキューユーザパスワードはありません。

（注）

ステップ 3 acidiag touchコマンドを使用して設定をクリアします。

例：

apic1# acidiag touch setup


Cisco APIC パスワードの復元およびフォールバックログインドメインの使用NX-OS スタイルの CLI を使用した Cisco APIC設定を消去するレスキューユーザアカウントの使用

フォールバックログインドメインを使用したローカル

データベースへのログインロックアウト時にローカルユーザデータベースを使用してログインできる、「フォールバック」

という非表示のログインドメインがあります。認証方式に使用するユーザ名の形式は、

apic#fallback\\<username>です。

フォールバックログインドメインを使用して、ローカルデータベースにGUIでログインします。

または次に示すように、NX-OSCLIを使用して、フォールバックログインドメインにログインします。

apic1(config)# aaa authentication login domain fallbackapic1(config-domain)# ?group Set provider group for login domainrealm Specify server realm

または次に示すように、REST APIを使用して、フォールバックログインドメインにログインできます。

• URL：https://ifav41-ifc1/api/aaaLogin.xml

•データ：

<aaaUser name="apic#fallback\\admin"pwd="passwordhere"/>


Cisco APIC パスワードの復元およびフォールバックログインドメインの使用フォールバックログインドメインを使用したローカルデータベースへのログイン

https://ifav41-ifc1/api/aaaLogin.xml


Cisco APIC パスワードの復元およびフォールバックログインドメインの使用フォールバックログインドメインを使用したローカルデータベースへのログイン

第 13 章

リーフ接続のトラブルシューティング

• 切断されたリーフの復旧, 87 ページ

切断されたリーフの復旧リーフにプッシュされた設定により、リーフのすべてのファブリックインターフェイス（リーフ

をスパインに接続するインターフェイス）が無効になっている場合、リーフへの接続は完全に失

われます。このリーフは、ファブリックで非アクティブになります。リーフに設定をプッシュし

ようとしても、接続が失われているため実行されません。この項では、そのようなシナリオでの

接続解除リーフを復元する方法について説明します。ファブリックインターフェイスの少なくと

も 1つは、次の手順で有効にされている必要があり、残りのインターフェイスは、GUI、RESTAPI、CLIを使用して有効にできます。最初のインターフェイスを有効にするには、REST APIを使用してポリシーを POSTし、POSTしたポリシーを削除してファブリックポートを無効にします。以下のように、リーフにポリシーをPOSTして、無効のポートを有効にすることができます。

次の例では、1/49はスパインに接続しているリーフポートの 1つであると想定しています。（注）

ステップ 1 APICからブラックリストポリシーをクリアします（REST APIを使用）。

例：$APIC_Address/api/policymgr/mo/.xml<polUni>

<fabricInst><fabricOOServicePol>

<fabricRsOosPath tDn="topology/pod-1/paths-$LEAF_Id/pathep-[eth1/49]"lc="blacklist" status ="deleted" />

</fabricOOServicePol></fabricInst>

</polUni>

ステップ 2 l1EthIfSetInServiceLTaskを使用して必要なインターフェイスを起動するために、ローカルタスクをノード自体に POSTします。


例：$LEAF_Address/api/node/mo/topology/pod-1/node-$LEAF_Id/sys/action.xml<actionLSubj oDn="sys/phys-[eth1/49]"><l1EthIfSetInServiceLTask adminSt='start'/></actionLSubj>


リーフ接続のトラブルシューティング

切断されたリーフの復旧

第 14 章

ファブリックの再構築

• ファブリックの再構築, 89 ページ

ファブリックの再構築この手順により、ファブリックを再構築（再初期化）できます。これは次のいずれかの理由で実

行が必要になる場合があります。

• TEP IPを変更する

•インフラ VLANを変更する

•ファブリック名を変更する

• TACトラブルシューティングタスクを実行する

この手順は非常に破壊的です。既存のファブリックを削除して新しいファブリックを再作成す

ることになります。

注意

はじめる前に

この手順を開始する前に、次の点を確認します。

•設定のスケジュールされた定期バックアップ

•リーフとスパインへのコンソールアクセス

•設定済みで到達可能な CIMC（KVMコンソールアクセスに必要）


• Javaの問題がない

ステップ 1 現在の設定を維持したい場合は、次の手順で設定のエクスポートを実行できます。 http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_KB_Using_Import_Export_to_Recover_Config_States.html

ステップ 2 KVMコンソールに接続して >acidiag touch cleanと入力し、APICを削除します（複数のAPICの削除は任意の順序で実行できます）。APICを削除すると、APICの設定は消去され、起動スクリプト内の設定で起動します。すべての APICに対してこの手順を実行します。

acidiag touchコマンドは、起動スクリプトでAPICを起動しないため、この手順では役に立ちません。

（注）

ステップ 3 ノードを削除し、この削除がすべてのリーフ/スパインで行われるようにします。ノードがファブリック検出モードで起動することと、以前に設定されたファブリックの一部ではないことを確認します。リーフ/スパインで、コンソールポートに接続し、次のコマンドでノードを削除します。

a) >acidiag touch cleanb) >acidiag touch setupc) >acidiag reboot

前のすべてのファブリック設定が削除されたことを確認するのは非常に重要です。前のいずれ

かのファブリック設定が 1つのノードに存在しているだけでも、ファブリックは再構築できません。

ここでノードを、ファブリック検出用に再起動する必要があります。すべてのノードで、次の

手順を実行します。

（注）

ステップ 4 すべての APICに対して起動スクリプトを実行します。この時点で、上記の値、TEP、TEP Vlan、ファブリック名のいずれかまたはすべてを変更できます。これらがすべての APICで一貫していることを確認します。詳細については、http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/getting-started/b_APIC_Getting_Started_Guide/b_APIC_Getting_Started_Guide_chapter_01.html#concept_F46E2193E3134CD090B65B16038D11A9を参照してください。

ステップ 5 apic1にログインし、次のサイトに示されている手順を使用して設定インポートを実行します。http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_KB_Using_Import_Export_to_Recover_Config_States.html

ステップ 6 ノード上のファブリックを再構築するためにファブリックが前のファブリック登録ポリシーを使用してい

るため、数分待機します（ファブリックのサイズ次第では、このステップは時間がかかる可能性がありま

す）。




http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_KB_Using_Import_Export_to_Recover_Config_States.html


http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/getting-started/b_APIC_Getting_Started_Guide/b_APIC_Getting_Started_Guide_chapter_01.html#concept_F46E2193E3134CD090B65B16038D11A9






第 15 章

ウィザードのトラブルシューティング

• トラブルシューティングウィザードについて, 92 ページ

• トラブルシューティングウィザードの使用を開始する, 93 ページ

• トラブルシューティングレポートの生成, 96 ページ

• トラブルシューティングウィザードのトポロジ, 99 ページ

• [Faults]トラブルシューティング画面の使用, 101 ページ

• [Drop/Statistics]トラブルシューティング画面の使用, 103 ページ

• [Contracts]トラブルシューティング画面の使用, 107 ページ

• [Events]トラブルシューティング画面の使用, 110 ページ

• [Traceroute]トラブルシューティング画面の使用, 113 ページ

• [Atomic Counter]トラブルシューティング画面の使用, 117 ページ

• [SPAN]トラブルシューティング画面の使用, 119 ページ

• L4 - L7サービス検証シナリオ, 121 ページ

• エンドポイント間接続用 APIのリスト, 122 ページ

• interactive API, 123 ページ

• createsession API, 124 ページ

• modifysession API, 125 ページ

• atomiccounter API, 126 ページ

• traceroute API, 126 ページ

• span API, 126 ページ

• generatereport API, 128 ページ

• schedulereport API, 128 ページ


• getreportstatus API, 129 ページ

• getreportslist API, 129 ページ

• getsessionslist API, 130 ページ

• getsessiondetail API, 130 ページ

• deletesession API, 130 ページ

• clearreports API, 131 ページ

• contracts API, 132 ページ

• エンドポイントからレイヤ 3への外部接続用 APIのリスト, 132 ページ

• interactive API, 133 ページ

• createsession API, 133 ページ

• modifysession API, 134 ページ

• atomiccounter API, 135 ページ

• traceroute API, 136 ページ

• span API, 137 ページ

• generatereport API, 138 ページ

• schedulereport API, 139 ページ

• getreportstatus API, 141 ページ

• getreportslist API, 141 ページ

• getsessionslist API, 141 ページ

• getsessiondetail API, 143 ページ

• deletesession API, 144 ページ

• clearreports API, 144 ページ

• contracts API, 144 ページ

• ratelimit API, 145 ページ

• 13ext API, 146 ページ

トラブルシューティングウィザードについてトラブルシューティングウィザードにより、ネットワークの動作を理解して視覚化でき、問題が

発生した場合にネットワークの懸念事項を軽減できます。

このウィザードにより、ユーザ（管理者ユーザ）は、2つのエンドポイントを選択して指定可能な、特定の期間に発生する問題をトラブルシューティングできます。たとえば、断続的なパケッ



トラブルシューティングウィザードについて

ト損失があるものの理由がわからない2つのエンドポイントがあるとします。トラブルシューティングGUIにより、問題を評価し、このエラー動作を引き起こしていると推定される各マシンにログオンしなくても、問題を効果的に解決できます。

後からセッションを再実行する場合もあるため、セッションには一意の名前を指定してください。

また、事前設定されたテストの使用も選択できます。デバッグは、エンドポイント間、内部から

外部エンドポイントの方向、外部から内部エンドポイントの方向で実行できます。

さらに、デバッグを実行する期間を定義できます。トラブルシューティングGUIでは、検索するエンドポイントの送信元および宛先エンドポイントを入力することができます。MAC、IPv4、または IPv6アドレスを使用してこれを行い、それからテナント別に選択できます。また、TACに送信できるトラブルシューティングレポートを生成することもできます。

次の項では、トラブルシューティングウィザードのトポロジについて説明します。これは調査中

の 2つのエンドポイントに関連する要素のみを示す、ファブリックの簡易表示です。

トラブルシューティングウィザード CLIコマンドのリストについては、『Cisco APICCommand-Line InterfaceUserGuide（Cisco APICコマンド行インターフェイスユーザガイド）』を参照してください。

（注）

関連トピック

トラブルシューティングウィザードの使用を開始する, （93ページ）

トラブルシューティングウィザードのトポロジ, （99ページ）

トラブルシューティングウィザードの使用を開始するトラブルシューティングウィザードの使用を開始する前に、管理者ユーザとしてログオンする必

要があります。送信元と宛先のエンドポイント（Ep）を指定し、トラブルシューティングセッションの期間を選択します。この期間は、イベント、エラーレコード、展開レコード、監査ロ

グ、および統計情報を取得するために使用されます（説明や期間は、[Start]をクリックする前の、ウィザードの最初のページでしか編集できません）。

[GENERATE REPORT]ボタンまたは [START]ボタンを一度クリックしたら、送信元と宛先のエンドポイントは変更できません。送信元と宛先の情報を入力した後に変更するには、新しい

セッションを開始する必要があります。

（注）



トラブルシューティングウィザードの使用を開始する

トラブルシューティングウィザードの画面をナビゲートするときには、いつでもスクリーン

ショットを撮り、画面の右上にある印刷アイコン（）をクリックしてプリンタに送信す

る（または PDFとして保存する）ことができます。また、画面表示を変更できるズームイン

とズームアウトのアイコン（）もあります。

（注）

トラブルシューティングセッション情報を設定するには、次の手順を実行します。

ステップ 1 次のように、画面の上部から [OPERATIONS]を選択し、それから [VISIBILITY & TROUBLESHOOTING]を選択します。

[Visibility & Troubleshooting]画面が表示されます。

ステップ 2 既存のトラブルシューティングセッションを（ドロップダウンメニューを使用して）使用するか、また

は新しいトラブルシューティングセッションを作成するかを選択できます。新しい住所を作成するには、

[Session Name]フィールドに名前を入力します（以下では例として「tsw_session2」を使用しています）。

ステップ 3 追加情報を提供するために、[Description]フィールドに説明を入力します。（この手順は任意です）。

ステップ 4 [Source]プルダウンメニューから、MAC、IPv4、または IPv6アドレスを入力するか、あるいは既存のものを選択します。

ステップ 5 [SEARCH]をクリックします。ボックスが次のように表示され、選択に役立つ詳細情報を示す1つ以上の行が示されます。各行は、入力した IPアドレス（[IP]列）が、特定のエンドポイントグループ（[EPG]列）にあること、特定のアプリケーション（[Application]列）に属すること、特定のテナント（[Tenant]列）にあることを示します。リーフ番号、FEX番号、およびポートの詳細が、[Learned At]列に示されます。

ステップ 6 [Destination]プルダウンメニューから、MAC、IPv4、または IPv6アドレスを入力するか、あるいは既存のものを選択します。

ステップ 7 [SEARCH]をクリックします。




ボックスが表示され、選択に役立つ詳細情報を示す 1つ以上の行が示されます（前述の [Source]エンドポイント検索の説明と同じです）。

ステップ 8 外部インターネットプロトコルにエンドポイントを使用する場合は、[External IP]チェックボックスをオンにします。

エンドポイントと外部 IPに関する詳細については、『Cisco Application Centric InfrastructureFundamentals』の資料を参照してください。

（注）

理想的には、同じテナントから送信元と宛先のエンドポイントを選択する必要があります。そ

のようにしないと、このマニュアルで後述するように、一部のトラブルシューティング機能が

影響を受ける可能性があります。これらのエンドポイントを選択すると、[Faults]トラブルシューティング画面に示されている 2つのエンドポイントを接続するトポロジついて把握できます。

（注）

ステップ 9 [From]（セッション開始時刻）と [To]（セッション終了時刻）プルダウンメニューで時刻を選んで、期間を選択します。

以下に示す [TimeWindow]は、過去の特定の期間内に発生した問題のデバッグに使用されます。また、イベント、すべてのレコード、展開レコード、監査ログ、および統計情報の取得にも使用されます。すべて

のレコード用に 1つと、個々のリーフ（またはノード）用に 1つの、2セットの期間があります。期間の設定には 2つのオプションがあり、[Use fixed time]チェックボックスを使用して切り替えることができます。

（注）

•任意の「直近の分数」に基づいて（デフォルトは 240分ですが、変更可能です）、次のように繰り返しの期間を指定できます。

•または、次のように [Use fixed time]チェックボックスをオンにして、[From]および [To]フィールドにセッションの固定期間を指定することもできます。

デフォルトの期間は、セッションを作成した時刻に先立つ、デフォルトの「直近 240分」に基づいたものになります（つまり、セッションには直近 240分のデータが含まれることを意味します）。次に示すように、期間情報の設定または変更は、左側のナビゲーションウィンドウの

下部から行うこともできます。

（注）




ステップ 10 画面の右下にある [START]をクリックして、トラブルシューティングセッションを開始します。トラブルシューティングセッションのトポロジ図が読み込まれて表示されます。

トラブルシューティングウィザード CLIコマンドのリストについては、『Cisco APICCommand-Line Interface User Guide（Cisco APICコマンド行インターフェイスユーザガイド）』を参照してください。

（注）

トラブルシューティングレポートの生成トラブルシューティングレポートは、JSON、XML、PDF、および HTMLなどのいくつかの形式で生成できます。形式を選択した後は、レポートをダウンロード（またはレポートのダウンロー

ドをスケジュール）して、それをオフライン分析に使用したり、TACに送信してサポートケースを作成したりできます。



トラブルシューティングレポートの生成

トラブルシューティングレポートを生成するには、次の手順に従います。

ステップ 1 画面の右下隅から、[GENERATE REPORT]を選択します。次の手順に示されている、出力形式を選択できるボックスが表示されます。

ステップ 2 [Generate Report]ドロップダウンボックスから、出力形式（XML、HTML、JSON、または PDF）を次のように選択します。

ステップ 3 レポートのダウンロードが即座に実行されるようにスケジュールするには、[Now]ボタンを次のようにオンにして、[SUBMIT]をクリックします。

[Information]ボックス（以下に示す）が表示され、生成されたレポートの取得場所が示されます。

ステップ 4 レポートの生成が後で実行されるようにスケジュールするには、次のように [Use a scheduler]をクリックして、スケジュールを選択します。




[Scheduler]プルダウンメニューから、既存のスケジュールを選択するか、以下のように [Create Scheduler]を選択して新規スケジュールを作成します。

[CREATE TRIGGER SCHEDULE]ウィンドウが、以下のように表示されます。

ステップ 5 [Name]、[Description]（オプション）、および [Schedule Windows]の情報を入力します。[SCHEDULER]の使用方法の詳細については、オンラインヘルプを参照してください。

（注）

ステップ 6 [Submit]をクリックします。




ファブリックのサイズや存在するエラーまたはイベントの数に応じて、レポートの生成にはいく

らかの時間がかかります（数分から最大で数十分）。レポートの生成中には、次のようにステー

タスメッセージが表示されます。

トラブルシューティングレポートを取得および表示するには、[SHOW GENERATED REPORTS]を選択します。

サーバのクレデンシャル（ユーザ名とパスワード）を、[Authentication Required]ウィンドウに入力します。トラブルシューティングレポートは、システムにローカルにダウンロードされます。

以下のように [ALL REPORTS]ウィンドウが表示され、直前にトリガーしたレポートも含め、生成したすべてのレポートが一覧表示されます。そこから、リンクをクリックして、選択した出力

ファイル形式に応じてレポートをダウンロードするかまたはすぐに表示することができます（た

とえば、ファイルが PDFであれば、ブラウザですぐに開くことができます）。

トラブルシューティングウィザードのトポロジこの項では、トラブルシューティングウィザードのトポロジについて説明します。トポロジは、

送信元と宛先エンドポイント（Ep）のファブリックへの接続方法、送信元から宛先へのネットワークパス、および中間スイッチについて示します。

次のウィザードトポロジ図に示すように、送信元エンドポイントはトポロジの左側に表示され、

宛先エンドポイントは右側に表示されます。

このウィザードのトポロジは、送信元エンドポイントから宛先エンドポイントへのトラフィッ

クに関連するデバイスの、リーフ、スパイン、および FEXのみを示します。ただし、他にも多くのリーフ（何十、何百ものリーフや他の多くのスパイン）が存在する可能性があります。

（注）

このトポロジは、リンク、ポート、デバイスも示します。アイコンにカーソルを合わせる

と、EPが属しているテナント、属しているアプリケーション、および使用しているトラフィックのカプセル化（VLANなど）を表示できます。



トラブルシューティングウィザードのトポロジ

次に示すように、画面の左側には色の凡例があり、トポロジ図の各色に関連付けられている重大

度レベルが説明されています（たとえば、重大とマイナーなど）。

トポロジ内のボックスやポートなどのアイテムにカーソルを合わせると、詳細情報が表示されま

す。ポートまたはリンクに色が付いている場合は、トラブルシューティングを行うべき問題があ

ることを示しています。たとえば、色が赤またはオレンジであれば、ポートまたはリンクにエラー

があることを示しています。色が白である場合には、エラーは発生していません。リンクに円で

囲まれた番号が付いている場合、その数は、同じ 2ノード間で、円の色で示されている重大度のエラーにより影響を受けるパラレルリンクの数を示しています。ポートにカーソルを合わせる

と、どのポートが送信元 Epに接続されているかを確認できます。

リーフを右クリックすると、スイッチのコンソールにアクセスできます。そのデバイスにログイ

ンできるポップアップウィンドウが表示されます。

（注） • L4から L7のサービスがあれば（ファイアウォールとロードバランサ）、それらもトポロジに表示されます。

•ロードバランサがあるトポロジでは、宛先は VIP（仮想 IP）であると予期されます。

•エンドポイントが ESXサーバの背後にあると、ESXはトポロジに示されます。



トラブルシューティングウィザードのトポロジ

[Faults] トラブルシューティング画面の使用[Faults]トラブルシューティング画面の使用を開始するには、次のように左側ナビゲーションウィンドウの [Faults]をクリックします。

[Faults]画面には、前に選択した 2つのエンドポイントを接続するトポロジと、検出されたエラーが表示されます。指定された通信のエラーのみが表示されます。どの場所でもエラーがあれば、

重大度を伝えるために特定の色で強調表示されます。各色に関連付けられている重大度レベルを

理解するには、画面の上部にある色の凡例（以下に示す）を参照してください。このトポロジは、

トラブルシューティングセッションに関連するリーフ、スパイン、およびFEXを示します。リーフ、スパイン、およびFEXなどの項目の上にカーソルを合わせる（またはエラーをクリックしてオンにする）と、分析の詳細情報が表示されます。



[Faults] トラブルシューティング画面の使用

ホワイトのボックスは、その特定の分野でトラブルシューティングを行うべき問題がないこと

を示します。

（注）

エラーをクリックすると、2つのタブ（[FAULTS]と [RECORDS]）があるボックスが表示されます。そのタブには、[Severity]、[Affected Object]、[Creation Time]、[Last Transaction]、[Lifecycle]、および [Description]を含む、分析のための詳細情報が示されています。



[Faults] トラブルシューティング画面の使用

関連トピック

[Drop/Statistics]トラブルシューティング画面の使用, （103ページ）

[Drop/Statistics] トラブルシューティング画面の使用[Drop/Stats]トラブルシューティング画面の使用を開始するには、次のように左側ナビゲーションウィンドウの [Drop/Stats]をクリックします。

[Drop/Stats]画面には、トポロジと、ドロップからのすべての統計情報が表示され、ドロップの存在箇所（存在しない箇所）を明確に把握できます。ドロップイメージをクリックすると、分析の

詳細を表示できます。



[Drop/Statistics] トラブルシューティング画面の使用

ドロップイメージをクリックすると、[Drop/Stats]画面の上部に 3つのタブが表示され、表示される統計情報は特定のリーフまたはスイッチに合わせてローカライズされます。

次の 3つの統計情報タブがあります。

•ドロップ統計情報（DROP STATS）

このタブには、ドロップカウンタの統計情報が表示されます。ここにはさまざまなレベルで

ドロップされたパケットが表示されます。

デフォルトではゼロ値のカウンタは非表示ですが、すべての値を表示するよ

うに選択することもできます。

（注）

•契約のドロップ（CONTRACT DROPS）

このタブには、発生した契約のドロップのリストが表示されます。これは個々のパケットロ

グ（ACLログ）であり、送信元インターフェイス、送信元 IPアドレス、送信元ポート、宛先 IPアドレス、宛先ポート、およびプロトコルなどの各パケットについての情報が表示されます。

すべてのパケットがここに表示されるわけではありません。（注）

•トラフィック統計情報（TRAFFIC STATS）




このタブは、進行中のトラフィックを示す統計情報を表示します。これは転送済みのパケッ

ト数です。

デフォルトではゼロ値のカウンタは非表示ですが、すべての値を表示するよ

うに選択することもできます。

（注）

また、画面の左上隅にある [All]アイコン（）をクリックして、すべてのマネージドオブジェ

クトの全統計情報をすばやく表示できます。

また、ゼロまたはゼロ以外のドロップを選択することもできます。[Show statswith zero values]ボックス（画面の左上隅にある）をオンにすると、既存のすべてのドロップを表示できます。[Time]、[Affected Object]、[Stats]、および [Value]の各フィールドには、次のようにゼロ以外のすべての値のデータが取り込まれます。

[Show stats with zero values]ボックスをオフにすると、次のようにゼロ以外のドロップがある結果が表示されます。




[All]アイコンをクリックすると、同じ論理が適用されます。3つのタブすべて（[DROPSTATS]、[CONTRACTDROPS]、および [TRAFFIC STATS]も使用可能であり、同じタイプの情報が表示されます。以下に示すのは、[Show stats with zero values]がオンになっている [Statistics - All]画面です。

（注）




関連トピック

[Contracts]トラブルシューティング画面の使用, （107ページ）

[Contracts] トラブルシューティング画面の使用[Contracts]トラブルシューティング画面の使用を開始するには、次のように左側ナビゲーションウィンドウの [Contracts]をクリックします。



[Contracts] トラブルシューティング画面の使用

[Contracts]トラブルシューティング画面には、次のように送信元から宛先と宛先から送信元の双方に適用される契約が表示されます。




上に示す青の表見出し行はそれぞれ、フィルタを示します。特定のリーフまたはスイッチ用の複

数のフィルタエントリ（[Protocol]、[L4 Src]、[L4 Dest]、[TCP Flags]、[Action]、[Node]、および[Hits]）を示す複数の行が、各フィルタの下にあります。

証明書アイコンの上にカーソルを合わせると、次のように契約名と契約フィルタ名が表示されま

す。

青の各表見出し行（つまりフィルタ）の右側に表示されるテキストは、たとえば以下のような、

契約のタイプを示します。

• EPG間




• BD許可

• Any-to-Any

•コンテキスト拒否

これらの契約は、送信元から宛先と、宛先から送信元に分類されます。

各フィルタで示されるヒット数は累積されます（つまり、その契約ヒット、契約フィルタ、ま

たはルールの合計ヒット数は、各リーフに示されます）。統計情報は、1分ごとに自動的に更新されます。

（注）

情報（）アイコンにカーソルを合わせると、ポリシー情報を入手できます。また、どの EPGが参照されているのかを確認することもできます。

エンドポイント間に契約がない場合には、[There is no contract data]ポップアップで示されます。

（注）

関連トピック

[Events]トラブルシューティング画面の使用, （110ページ）

[Events] トラブルシューティング画面の使用[Events and Audits]トラブルシューティング画面の使用を開始するには、次のように左側ナビゲーションウィンドウの [Events and Audits]をクリックします。



[Events] トラブルシューティング画面の使用

次のように、個々のリーフまたはスパインをクリックすると、個々のイベントの詳細情報を表示

できます。

この個別イベント情報の例を次に示します。




この画面で使用できる 2つのタブは、[EVENTS]と [DEPLOYMENT RECORDS]です。

• [EVENTS]は、システム（物理インターフェイスや VLANなど）で発生したすべての変更のイベントレコードを示します。特定の各リーフについてリストされる個々のイベントがあり

ます。これらのイベントは、[Severity]、[Affected Object]、[Creation Time]、[Cause]、および[Description]に基づいて分類できます。

• [DEPLOYMENT RECORDS]は、物理インターフェイス、VLAN、VXLAN、および L3 CTXに対するポリシーの展開を示します。これらのレコードは、epgにより VLANがリーフに配置されていた時間を示します。

[All Changes]画面の [All]アイコン（）をクリックすると、指定した期間内（またはトラブ

ルシューティングセッション時）に行われた変更を示すすべてのイベントを表示できます。




[All Changes]画面には、次の 3つのタブがあります。

• AUDITS

監査はリーフと関連付けられていないため、[All Changes]画面でしか使用できません。

• EVENTS（前述）

• DEPLOYMENT RECORDS（前述）

関連トピック

[Traceroute]トラブルシューティング画面の使用, （113ページ）

[Traceroute] トラブルシューティング画面の使用[Traceroute]トラブルシューティング画面の使用を開始するには、次のように左側ナビゲーションウィンドウの [Traceroute]をクリックします。



[Traceroute] トラブルシューティング画面の使用

トラブルシューティングのために traceroute作成して実行するには、次の手順に従います。

1 [TRACEROUTE]ボックスで、[DestinationPort]プルダウンメニューから宛先ポートを選択します。

2 次のように、[Protocol]プルダウンメニューからプロトコルを選択します。

サポートされるオプションは、次のとおりです。

• icmpこのプロトコルは、送信元リーフから宛先エンドポイントへの方向のみに tracerouteを実行するという点で、単方向です。

• tcp




このプロトコルは、udpプロトコルについての前述の説明に従えば、双方向でもあります。

• udpこのプロトコルは、tracerouteを送信元リーフから宛先エンドポイントに実行し、次に宛先リーフから送信元エンドポイントに実行するという点で、双方向です。

IPv4でサポートされているプロトコルは、UDP、TCP、および ICMPのみです。IPv6では、サポートされるのは UDPのみです。

（注）

3 tracerouteを作成したら、次のように [Play]（または [Start]）ボタンをクリックして tracerouteを開始します。

[Play]ボタンを押すと、システムにポリシーが作成されます。（注）

警告メッセージは、次のように表示されます。（注）

4 [OK]をクリックして続行すると、tracerouteが実行を開始します。5 tracerouteを終了するには、[Stop]ボタンをクリックします。

[Stop]ボタンを押すと、ポリシーはシステムから削除されます。（注）




tracerouteが完了すると、起動した場所と結果を確認できます。[TracerouteResults]の横にプルダウンメニューがあり、tracerouteが起動された場所（送信元から宛先または宛先から送信元）が以下のように表示されます。

さらに、結果は [Traceroute]ボックス（上記参照）に表示されます。これには実行時間、tracerouteのステータス、宛先ポート、およびプロトコルについての情報が含まれます。

結果は、緑または赤（あるいはその両方）の矢印で示されます。緑色の矢印は、tracerouteプローブに応答した、パス内の各ノードを表すために使用しています。赤い矢印の起点は、tracerouteプローブに応答した最終ノードであり、パスの終端を表します。tracerouteを起動する方向は選択しません。そのようにしなくても、tracerouteはセッションに対して常に起動します。セッションに応じて、以下のようになります。

• EPから外部 IPまたは外部 IPから EPの場合、tracerouteは常に EPから外部 IPの方向に起動します。

• EP間であり、プロトコルが ICMPの場合、tracerouteは常に送信元から宛先の方向に起動します。

• EP間であり、プロトコルが UDP/TCPの場合、tracerouteは常に双方向です。

[TracerouteResults]ドロップダウンメニューは、上記のシナリオ #3の各方向の結果を明らかにする/可視化するために使用できます。シナリオ #1と #2では、これは常にグレー表示です。

（注）




[Traceroute Status]が未完了を示している場合は、データの一部が返されるのを引き続き待機することになります。[Traceroute Status]が [complete]を示している場合は、実際に完了しています。

（注）

関連トピック

[Atomic Counter]トラブルシューティング画面の使用, （117ページ）

[Atomic Counter] トラブルシューティング画面の使用[Atomic Counter]トラブルシューティング画面の使用を開始するには、次のように左側ナビゲーションウィンドウの [Atomic Counter]をクリックします。

[AtomicCounter]画面は、発信元と宛先の情報を取得し、それに基づくカウンタポリシーを作成するために使用されます。2つのエンドポイント間のアトミックカウンタポリシーを作成し、送信元から宛先および宛先から送信元を行き来するトラフィックをモニタできます。どの程度のトラ

フィックが行き来したかを判別できます。さらに、送信元と宛先のリーフ間で異常（ドロップま

たは超過パケット）が報告されているかどうかを特に判別します。

以下に示すとおり、画面上部には [Play]（または [Start]）および [Stop]ボタンがあり、任意の時点でアトミックカウンタポリシーを開始または停止したり、送信済みのパケット数をカウントした

りできます。



[Atomic Counter] トラブルシューティング画面の使用

[Play]ボタンを押すと、システム上にポリシーが作成され、パケットカウンタが開始されます。[Stop]ボタンを押すと、ポリシーはシステムから削除されます。

（注）

結果は 2つの異なる形式で表示されます。ポリシーは、いずれかの簡略形式（概要を含む）、または（[Expand]ボタンをクリックして）拡張形式で表示できます。簡易および拡張のどちらの形式も、両方向を表示します。拡張形式は、累積カウントと直近30秒間隔ごとのカウントを表示するのに対し、簡易形式は、累積カウントと直近の 1間隔のカウントのみを表示します。

簡易形式は、次のように表示されます。

拡張形式は、次のように表示されます。



[Atomic Counter] トラブルシューティング画面の使用

関連トピック

[SPAN]トラブルシューティング画面の使用, （119ページ）

[SPAN] トラブルシューティング画面の使用[SPAN]トラブルシューティング画面の使用を開始するには、次のように左側ナビゲーションウィンドウの [SPAN]をクリックします。



[SPAN] トラブルシューティング画面の使用

この画面を使用して、双方向トラフィックに SPAN（またはミラー）を実行したり、アナライザにリダイレクトしたりできます。SPANセッションでは、コピーを作成して、アナライザに送信します。

このコピーは、特定のホスト（アナライザの IPアドレス）に送られます。それからWiresharkなどのソフトウェアツールを使用すると、パケットを表示できます。セッション情報には、発信元

と宛先の情報、セッションタイプ、およびタイムスタンプの範囲があります。

[SPAN - Bidirectional ERSPAN]ボックスが、以下のように表示されます。



[SPAN] トラブルシューティング画面の使用

[Play]ボタンを押すと、システムにポリシーが作成されます。[Stop]ボタンを押すと、ポリシーはシステムから削除されます。

（注）

トラブルシューティングウィザード CLIコマンドのリストについては、『Cisco APICCommand-Line InterfaceUserGuide（Cisco APICコマンド行インターフェイスユーザガイド）』を参照してください。

（注）

L4 - L7 サービス検証シナリオトラブルシューティングウィザードは、2つのエンドポイントを提供し、それらのエンドポイント間の対応するトポロジを表示することができます。L4～ L7のサービスがトポロジ内の 2つのエンドポイント間に存在している場合、それらも表示できます。

この項では、このリリースで検証されたL4～L7のシナリオについて説明します。L4～L7のサービス内では、トポロジの数が非常に大きくなっています。これはつまり、それぞれのファイア

ウォール、ロードバランサ、および組み合わせが、さまざまな設定を持つ可能性があることを意

味します。ファイアウォールがトポロジ内の 2つのエンドポイント間に存在している場合、トラブルシューティングウィザードは、ファイアウォールのデータと、ファイアウォールからリーフ

への接続を取得します。ロードバランサが 2つのエンドポイント間に存在している場合、サーバまでではなく、ロードバランサまでの情報を取得して表示できます。

次の表は、トラブルシューティングウィザードで検証済みの、L4～ L7のサービスシナリオを示しています。

654321シナリオ

211211ノード数

FW、SLB（GoThrough、GoTo）

SLB-GoToFW-GoThroughGoTo、GoToFW、SLB

GoToSLB

Goto FW（vrf分割）

デバイス

222222アーム数

L3OutL3OutL3OutEPGEPGEPGコンシューマ

EPGEPGEPGEPGEPGEPGProvider

physicalphysicalphysicalVMVMVMデバイスの種類

globalコンテキス

ト

コンテキス

ト

コンテキストコンテキ

スト

テナントコントラクト範

囲



L4 - L7 サービス検証シナリオ

654321シナリオ

L3 / L2、L3L3L2、L3L2、L2L2L2ConnectorMode

通常のポー

ト

vPC通常のポー

ト

DL/PCBSWBSWサービスの付加

通常のポー

ト

通常のポー

ト

通常のポー

ト

FEXFEXFEXクライアントの

付加

通常のポー

ト

通常のポー

ト

通常のポー

ト

vPCvPCvPCサーバの付加

エンドポイント間接続用 API のリスト次に示すのは、EP間（エンドポイント間）接続に使用できるトラブルシューティングウィザードAPIのリストです。

• interactive API, （123ページ）

• createsession API, （124ページ）

• modifysession API, （125ページ）

• atomiccounter API, （126ページ）

• traceroute API, （126ページ）

• span API, （126ページ）

• generatereport API, （128ページ）

• schedulereport API, （128ページ）

• getreportstatus API, （129ページ）

• getreportslist API, （129ページ）

• getsessionslist API, （130ページ）

• getsessiondetail API, （130ページ）

• deletesession API, （130ページ）

• clearreports API, （131ページ）

• contracts API, （132ページ）



エンドポイント間接続用 API のリスト

interactive APIエンドポイント（ep）間のインタラクティブトラブルシューティングセッションを作成するには、interactiveAPIを使用します。モジュール名は troubleshoot.eptoeputils.topoで、関数は getTopoです。interactive APIの必須引数（req_args）は - sessionです。

次の表に、オプションの引数（opt_args）とそれぞれの説明を示します。

___________________構文の説明

説明オプションの引数（opt_args）

送信元エンドポイント名- srcep

宛先エンドポイント名- dstep

送信元エンドポイント IPアドレス- srcip

宛先エンドポイント IPアドレス- dstip

送信元エンドポイントMAC- srcmac

宛先エンドポイントMAC- dstmac

L3外部送信元 IPアドレス- srcextip

L3外部宛先 IPアドレス- dstextip

トラブルシューティングセッションの開始時刻- starttime

トラブルシューティングセッションの終了時刻- endtime

開始時刻から始まるトラブルシューティングセッショ

ンの期間（分単位）

- latestmin

セッションについての説明- description

レポート生成用のスケジューラ名- scheduler

Obsolete- srcepid

Obsolete- dstepid

Obsolete- include

生成されるレポートの形式- format

内部的に使用（無視）- ui



interactive API

レポートの場所- sessionurl

traceroute/atomiccounterの start/stop/statusなど-action

内部的に使用- mode

内部的に使用- _dc

内部的に使用- ctx

createsession APIエンドポイント間トラブルシューティングセッションを作成するには、createsession APIを使用します。モジュール名は troubleshoot.eptoeputils.sessionで、関数は createSessionです。

createsession APIの必須引数（req_args）は - session (session name)です。


___________________構文の説明














- latestmin




createsession API




- scheduler

ソースエンドポイントのテナントの名前- srctenant

ソースエンドポイントのアプリケーションの名前- srcapp

ソースエンドポイントのエンドポイントグループの名

前

- srcepg

宛先エンドポイントのテナントの名前- dsttenant

宛先エンドポイントのアプリケーションの名前- dstapp

宛先エンドポイントのエンドポイントグループの名前- dstepg


modifysession APIエンドポイント（ep）間のトラブルシューティングセッションを変更するには、modifysessionAPIを使用します。モジュール名は troubleshoot.eptoeputils.topoで、関数は modifySessionです。

modifysession APIの必須引数（req_args）は - session (session name)および - modeです。


___________________構文の説明






- latestmin




modifysession API

atomiccounter APIエンドポイント（ep）間のアトミックカウンタセッションを作成するには、atomiccounter APIを使用します。モジュール名は troubleshoot.eptoeputils.atomiccounterで、関数はmanageAtomicCounterPolsです。

atomiccounter APIの必須引数（req_args）には、次のものが含まれます。

• - session

• - action

• - mode

atomiccounter APIのオプションの引数（opt_args）はありません。（注）

traceroute APIAPIを使用してエンドポイント（ep）間トレースルートセッションを作成するには、tracerouteAPIを使用します。モジュール名は troubleshoot.eptoeputils.tracerouteで、関数はmanageTraceroutePolsです。

traceroute APIの必須引数（req_args）には、次のものが含まれます。

• - session (session name)

• - action (start/stop/status)

• - mode

___________________構文の説明


プロトコル名- protocol

宛先ポート名- dstport

span APIエンドポイント（ep）間のスパントラブルシューティングセッションを作成するには、spanAPIを使用します。モジュール名は troubleshoot.eptoeputils.spanで、関数は monitorです。

span APIの必須引数（req_args）には、次のものが含まれます。




atomiccounter API



___________________構文の説明












開始時刻から始まるトラブルシューティングセッ

ションの期間（分単位）

- latestmin



Obsolete- srcepid

Obsolete- dstepid

Obsolete- include





ソースエンドポイントのテナントの名前- srctenant



span API

ソースエンドポイントのアプリケーションの名

前

- srcapp

ソースエンドポイントのエンドポイントグルー

プの名前

- srcepg

宛先エンドポイントのテナントの名前- dsttenant

宛先エンドポイントのアプリケーションの名前- dstapp

宛先エンドポイントのエンドポイントグループ

の名前

- dstepg




generatereport APIAPIを使用してトラブルシューティングレポートを生成するには、generatereportAPIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は generateReportです。

generatereport APIの必須引数（req_args）は - session (session name)および - modeです。


___________________構文の説明


Obsolete- include


schedulereport APIAPIを使用してトラブルシューティングレポートの生成をスケジュールするには、schedulereportAPIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は scheduleReportです。schedulereport APIの必須引数（req_args）は - sessionです。

schedulereport APIの必須引数（req_args）には、次のものが含まれます。




generatereport API

• - scheduler (scheduler name)

• - mode


___________________構文の説明






- latestmin

Obsolete- include


traceroute/atomiccounterの start/stop/statusなど- action

getreportstatus APIAPIを使用して生成済みレポートのステータスを取得するには、getreportstatus APIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は getStatusです。

getreportstatus APIの必須引数（req_args）には、次のものが含まれます。


• - sessionurl (session URL)

• - mode

getreportstatus APIのオプションの引数（opt_args）はありません。（注）

getreportslist APIAPIを使用して生成済みレポートのリストを取得するには、getreportslist APIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は getReportsListです。

getreportslist APIの必須引数（req_args）は - session (session name)および - modeです。



getreportstatus API

getreportslist APIのオプションの引数（opt_args）はありません。（注）

getsessionslist APIAPIを使用してトラブルシューティングセッションのリストを取得するには、getsessionslist APIを使用します。モジュール名は troubleshoot.eptoeputils.sessionで、関数は getSessionsです。

getsessionlist APIの必須引数（req_args）は - modeです。

getsessionlist APIのオプションの引数（opt_args）はありません。（注）

getsessiondetail APIAPIを使用してトラブルシューティングセッションについての特定の詳細を取得するには、getsessiondetail APIを使用します。モジュール名は troubleshoot.eptoeputils.sessionで、関数はgetSessionDetailです。

getsessiondetail APIの必須引数（req_args）は - session (session name)および - modeです。

getsessiondetail APIのオプションの引数（opt_args）はありません。（注）

deletesession APIAPIを使用して特定のトラブルシューティングセッションを削除するには、deletesessionAPIを使用します。モジュール名は troubleshoot.eptoeputils.sessionで、関数は deleteSessionです。

deletesession APIの必須引数（req_args）は - session (session name)です。


___________________構文の説明








getsessionslist API









- latestmin



Obsolete- srcepid

Obsolete- dstepid

Obsolete- include








clearreports APIAPIを使用して生成済みレポートのリストをクリアするには、clearreports APIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は clearReportsです。

clearreports APIの必須引数（req_args）は - session (session name)および - modeです。



clearreports API

clearreports APIのオプションの引数（opt_args）はありません。（注）

contracts APIAPIを使用して契約情報を取得するには、contracts APIを使用します。モジュール名はtroubleshoot.eptoeputils.contractsで、関数は getContractsです。

contracts APIの必須引数（req_args）は - session (session name)および - modeです。

contracts APIのオプションの引数（opt_args）はありません。

エンドポイントからレイヤ 3 への外部接続用 API のリスト

次に示すのは、EP間（エンドポイント間）接続に使用できるトラブルシューティングウィザードAPIのリストです。

• interactive API, （133ページ）

• modifysession API, （134ページ）

• atomiccounter API, （135ページ）

• traceroute API, （136ページ）

• span API, （137ページ）

• generatereport API, （138ページ）

• schedulereport API, （139ページ）

• getreportstatus API, （129ページ）

• getreportslist API, （129ページ）

• clearreports API, （131ページ）

• createsession API, （133ページ）

• getsessionslist API, （141ページ）

• getsessiondetail API, （143ページ）

• deletesession API, （144ページ）

• contracts API, （144ページ）

• ratelimit API, （145ページ）

• 13ext API, （146ページ）



contracts API

interactive APIエンドポイント（ep）とレイヤ 3（L3）との間の外部インタラクティブトラブルシューティングセッションを作成するには、interactive APIを使用します。モジュール名はtroubleshoot.epextutils.epext_topoで、関数は getTopoです。interactiveAPIの必須引数（req_args）は、- session、- include、および - modeです。

次の表は、オプションの引数（opt_args）を示しています。

___________________構文の説明


- refresh

createsession APIAPIを使用してエンドポイント（Ep）とレイヤ3（L3）との間の外部トラブルシューティングセッションを作成するには、createsession APIを使用します。モジュール名はtroubleshoot.epextutils.epextsessionで、関数は createSessionです。createsession APIの必須引数（req_args）は - session (session name)です。


___________________構文の説明













interactive API




- latestmin



Obsolete- srcepid

Obsolete- dstepid

Obsolete- include








modifysession APIエンドポイント（Ep）とレイヤ 3（L3）との間の外部トラブルシューティングセッションを変更するには、modifysession APIを使用します。モジュール名は troubleshoot.epextutils.epextsessionで、関数はmodifySessionです。modifysessionAPIの必須引数（req_args）は - session (session name)です。


___________________構文の説明







modifysession API










- latestmin



Obsolete- srcepid

Obsolete- dstepid

Obsolete- include








atomiccounter APIエンドポイント（ep）間のアトミックカウンタセッションを作成するには、atomiccounter APIを使用します。モジュール名は troubleshoot.epextutils.epext_acで、関数はmanageAtomicCounterPolsです。



atomiccounter API

atomiccounter APIの必須引数（req_args）には、次のものが含まれます。




___________________構文の説明














- latestmin





traceroute APIAPIを使用してエンドポイント（ep）とレイヤ 3との間のトレースルートトラブルシューティングセッションを作成するには、traceroute APIを使用します。モジュール名はtroubleshoot.epextutils.epext_tracerouteで、関数は manageTraceroutePolsです。



traceroute API

traceroute APIの必須引数（req_args）には、次のものが含まれます。



___________________構文の説明


プロトコル名- protocol

宛先ポート名- dstport

送信元エンドポイント- srcep

宛先エンドポイント- dstep

送信元 IPアドレス- srcip

宛先 IPアドレス- dstip

送信元外部 IPアドレス- srcextip

宛先外部 IPアドレス- dstIp





span APIエンドポイント（Ep）とレイヤ 3（L3）との間の外部スパントラブルシューティングセッションを作成するには、spanAPIを使用します。モジュール名は troubleshoot.epextutils.epext_spanで、関数は monitorです。

span APIの必須引数（req_args）には、次のものが含まれます。



• - mode

次の表に、オプションの引数（opt_args）とそれぞれの説明を示します。___________________構文の説明




span API

ポートのリスト- portslist

宛先 APIC- dstapic

ソースエンドポイントの IPアドレスプレフィクス

- srcipprefix

フロー ID- flowid

宛先エンドポイントグループ- dstepg


???- analyser

宛先タイプ- desttype

SPAN送信元ポート- spansrcports

generatereport APIAPIを使用してトラブルシューティングレポートを生成するには、generatereportAPIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は generateReportです。

generatereport APIの必須引数（req_args）は - session (session name)です。


___________________構文の説明












generatereport API





- latestmin



Obsolete- srcepid

Obsolete- dstepid

Obsolete- include








schedulereport APIAPIを使用してトラブルシューティングレポートの生成をスケジュールするには、schedulereportAPIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は scheduleReportです。schedulereport APIの必須引数（req_args）は - sessionです。

schedulereport APIの必須引数（req_args）には、次のものが含まれます。


• - scheduler (scheduler name)


___________________構文の説明




schedulereport API

送信元エンドポイント- srcep

宛先エンドポイント- dstep











- latestmin


Obsolete- srcepid

Obsolete- dstepid

Obsolete- include










schedulereport API

getreportstatus APIAPIを使用して生成済みレポートのステータスを取得するには、getreportstatus APIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は getStatusです。

getreportstatus APIの必須引数（req_args）には、次のものが含まれます。


• - sessionurl (session URL)

• - mode

getreportstatus APIのオプションの引数（opt_args）はありません。（注）

getreportslist APIAPIを使用して生成済みレポートのリストを取得するには、getreportslist APIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は getReportsListです。

getreportslist APIの必須引数（req_args）は - session (session name)および - modeです。

getreportslist APIのオプションの引数（opt_args）はありません。（注）

getsessionslist APIAPIを使用してトラブルシューティングセッションのリストを取得するには、getsessionslist APIを使用します。モジュール名は troubleshoot.epextutils.epextsessionで、関数は getSessionsです。

この APIには必須引数はありません。（注）


___________________構文の説明


セッション名- session





getreportstatus API











- latestmin



Obsolete- srcepid

Obsolete- dstepid

Obsolete- include










getsessionslist API

getsessiondetail APIAPIを使用してトラブルシューティングセッションについての特定の詳細を取得するには、getsessiondetail APIを使用します。モジュール名は troubleshoot.epextutils.sessionで、関数はgetSessionDetailです。getsessiondetail APIの必須引数（req_args）は - session (session name)です。


___________________構文の説明














- latestmin



Obsolete- srcepid

Obsolete- dstepid

Obsolete- include





getsessiondetail API






deletesession APIAPIを使用して特定のトラブルシューティングセッションを削除するには、deletesessionAPIを使用します。モジュール名は troubleshoot.epextutils.epextsessionで、関数は deleteSessionです。

deletesession APIの必須引数（req_args）は - session (session name)および - modeです。

deletesession APIのオプションの引数（opt_args）はありません。（注）

clearreports APIAPIを使用して生成済みレポートのリストをクリアするには、clearreports APIを使用します。モジュール名は troubleshoot.eptoeputils.reportで、関数は clearReportsです。

clearreports APIの必須引数（req_args）は - session (session name)および - modeです。

clearreports APIのオプションの引数（opt_args）はありません。（注）

contracts APIAPIを使用して契約情報を取得するには、contracts APIを使用します。モジュール名はtroubleshoot.epextutils.epext_contractsで、関数は getContractsです。contracts APIの必須引数（req_args）は - session (session name)です。


___________________構文の説明





deletesession API












- latestmin

エンドポイントから外部- epext





ratelimit APIこの項では、ratelimit APIについての情報を記載しています。モジュール名はtroubleshoot.eptoeputils.ratelimitで、関数は controlです。ratelimit APIの必須引数（req_args）は、- action (start/stop/status)です。


___________________構文の説明






ratelimit API











- latestmin





13ext APIこの項では、13ext APIについての情報を記載しています。モジュール名はtroubleshoot.epextutils.l3extで、関数は executeです。13ext APIの必須引数（req_args）は、- action(start/stop/status)です。


___________________構文の説明








13ext API









- latestmin





13ext API



13ext API

第 16 章

APIC のトラブルシューティングの操作

• APICシステムのシャットダウン, 149 ページ

• GUIを使用した APICコントローラのシャットダウン, 150 ページ

• GUIを使用した APICリロードオプションの使用, 151 ページ

• GUIを使用した LEDロケータの制御, 152 ページ

APIC システムのシャットダウンこの手順では、APICシステムをシャットダウンする方法について説明します。

システムをシャットダウンしてから、移動させ（ファブリック全体の再配置）、電源を入れる

と、それに応じてタイムゾーンまたは NTPサーバ（あるいはその両方）が更新されます。（注）

1 APICは一度に 1つずつ、右クリックして、プルダウンメニューから [Shutdown]を選択してシャットダウンします。


2 新しい場所で APICを起動します。

3 クラスタが完全に統合されていることを次のように確認します。

4 次の APICに進みます。

はじめる前に

クラスタヘルスが十分に正常であることを確認します。

GUI を使用した APIC コントローラのシャットダウンこのマニュアルでは、APICコントローラをシャットダウンする方法について説明します。

この手順は、APICコントローラのみ（APICシステム全体ではない）をシャットダウンする方法を説明します。この手順を実行すると、コントローラはすぐにシャットダウンされます。コ

ントローラの再起動は実マシンから行うしか方法がないため、シャットダウンの実行には注意

が必要です。。マシンにアクセスする必要がある場合には、この章の「GUIを使用したロケータ LEDのオンへの切り替え」の項を参照してください。

（注）

単一の APICコントローラをシャットダウンするには、次の手順に従います。


APIC のトラブルシューティングの操作GUI を使用した APIC コントローラのシャットダウン

可能であれば、APICは一度に 1つずつ移動させます。オンラインのクラスタに少なくとも 2つの APICがある限り、読み取り/書き込みアクセス権があります。複数の APICを一度に再配置する必要がある場合、残りのオンラインのコントローラは 1つまたはなしという結果になり、ファブリックはシャットダウン時に読み取り専用モードになります。この間、エンドポイ

ントの移動（仮想マシンの移動）を含め、ポリシー変更はできません。APICを次の手順でシャットダウンしたら、コントローラを再配置し、新しいラックで再度電源を入れます。次

に、クラスタヘルスが十分に正常な状態に戻ったことを確認します。

（注）

1 メニューバーで、[System]をクリックします。

2 サブメニューバーで、[Controllers]をクリックします。

3 [Controllers]で、リロードする APICノード（たとえば、apic1 (Node-1)）をクリックします。

4 画面上部の右ウィンドウペインで、[General]タブをクリックします。

5 画面上部の右ウィンドウペインのタブから、[ACTIONS]プルダウンメニューをクリックします。

6 プルダウンメニューから [Shutdown]を選択すると、APICコントローラは即座にリロードされます。

この [Shutdown]オプションを使用する別の方法として、APICノード（apic1 (Node-1)など）を右クリックし、プルダウンリストから [Shutdown]を選択します。

（注）

7 コントローラを再配置して、電源を入れます。

8 クラスタヘルスが十分に正常な状態に戻ったことを確認します。

GUI を使用した APIC リロードオプションの使用このマニュアルでは、GUIを使用して APICコントローラ（APICシステム全体ではない）をリロードする方法を説明します。

APICコントローラをリロードするには、次の手順を実行します。







APIC のトラブルシューティングの操作GUI を使用した APIC リロードオプションの使用

6 プルダウンメニューから [Reload]を選択すると、APICコントローラは即座にリロードされます。

この [Reload]オプションを使用する別の方法として、APICノード（apic1 (Node-1)など）を右クリックし、プルダウンリストから [Reload]を選択します。

（注）

GUI を使用した LED ロケータの制御このマニュアルでは、GUIを使用して APICコントローラの LEDロケータをオンにする方法を説明します。

GUIを使用して APICコントローラの LEDロケータをオン（またはオフ）にするには、次の手順に従います。






6 プルダウンメニューから、[Turn On LED Locator]（または [Turn Off LED Locator]）を選択します。

このオプションを使用する別の方法として、APICノード（apic1 (Node-1)など）を右クリックし、プルダウンメニューから [Turn On LED Locator]（または [Turn Off LED Locator]）を選択します。

（注）


APIC のトラブルシューティングの操作GUI を使用した LED ロケータの制御

第 17 章

SSL 暗号方式のトラブルシューティング

• SSL暗号化について, 153 ページ

• サポートされる SSL暗号化の確認 , 154 ページ

SSL 暗号化についてシスコアプリケーションセントリックインフラストラクチャ（ACI）の Representational StateTransfer（REST）APIは、HTTPS/SSL/TLSサポートがますます厳しくなっている状況下で、そのソリューションが新しいバージョンに導入されるようになったときから進化を遂げてきました。

このマニュアルの目的は、Cisco ACI REST APIでの HTTPS、SSL、および TLSサポートの進化について説明し、クライアントが REST APIをセキュアな方法で使用するために必要な事柄の手引きを読者に提供することです。

HTTPSは、Secure Sockets Layer（SSL）または Transport Layer Security（TLS）のいずれかを使用して、HTTPセッション用のセキュア接続を確立するプロトコルです。SSLまたは TLSは、クライアントとHTTPサーバとの間のトラフィックを暗号化するために使用されます。さらに、HTTPSをサポートするサーバには、サーバの信頼性を確認するために、通常はクライアントが使用でき

る証明書があります。これはサーバ側でクライアントを認証するのとは逆です。この場合、サー

バは「わたしは server_xyzで、ここにその証明書があります」と伝えていることになります。クライアントはその証明書を使用して、サーバが「server_xyz」であることを確認できます。

SSL/TLSには他の重要な側面があり、これには各プロトコルで使用できるサポート対象の暗号化の暗号方式と、SSLまたはTLSプロトコルの継承セキュリティが関係しています。SSLは、SSLv1、SSLv2、SSLv3という3つのバージョンを経てきましたが、そのどれもが今ではセキュアではないと見なされています。TLSは、TLSv1、TLSv1.1、TLSv1.2と3つのバージョンを経てきましたが、TLSv1.1とTLSv1.2のみがセキュアと見なされています。クライアントは使用可能な最高バージョンの TLSを使用し、サーバは TLSv1.1と TLSv1.2のみをサポートするのが理想的です。ただし、ほとんどのサーバは、旧式クライアントに対応するために TLSv1のサポートを維持する必要があります。

ほぼすべての最新ブラウザは、TLSv1.1と TLSv1.2の両方をサポートします。ただし、HTTPSを使用するクライアントはブラウザではない場合もあります。クライアントがWebサーバと通信する Javaアプリケーションまたは Pythonスクリプトであるという場合があり、その場合には


HTTPS/TLSをネゴシエートする必要があります。このような状況では、サポート対象とサポート箇所についての確認ははるかに重要になります。

サポートされる SSL 暗号化の確認はじめる前に

この項では、CLIを使用して、サポートされている SSL暗号方式を判別する方法について説明します。

ステップ 1 次のように、openssl環境でサポートされている暗号方式を取得します。

例：

openssl ciphers 'ALL:eNULL'

ステップ 2 次のように、SEDなどのツールを使用して、暗号方式を分離します。

例：

openssl ciphers 'ALL:eNULL' | sed -e 's/:/\n/g'

ステップ 3 次のように、暗号方式をループ処理して、APICをポーリングし、どの暗号方式がサポートされているかを確認します。

例：openssl s_client -cipher ?<some cipher to test>? -connect <apic ipaddress>:<ssl port, usually 443>

次の暗号の例を参照してください。

例：

openssl s_client -cipher ?ECDHE-ECDSA-AES128-GCM-SHA256? -connect 10.1.1.14:443

応答に CONNECTEDが含まれていれば、その暗号方式はサポートされていま

す。

（注）


SSL 暗号方式のトラブルシューティングサポートされる SSL 暗号化の確認

付録 Aacidiag コマンド

Cisco APICでのトラブルシューティング操作では、acidiagコマンドを使用します。

このコマンドのセットは文書化を目的として公開しており、ACIの日常業務での使用は推奨しません。これらは内部コマンドとしての使用を意図しており、正しく使用しないとネットワー

クに重大な問題を引き起こす可能性があります。どの操作を実行する場合でも、実行する前に

ファブリックに対するすべての影響を理解しておくようにしてください。

注

意

クラスタコマンド

acidiag

acidiag avread

acidiag fnvread

acidiag fnvreadex


___________________構文の説明機能オプション

クラスタ内の APICを表示します。avreadの出力は次のとおりです。

• Cluster of：動作するクラスタのサイズ

• out of targeted：目的のクラスタのサイズ

• active=：APICが到達可能であるかどうかを示す

• health=：全体的な APICのヘルスの要約サービスと、低下したヘルススコアが表

示されます。

• chassisID=：特定の APICの既知のシャーシ ID

ピアのシャーシ IDは、現在クラスタ内にない APICには正しくない可能性があります。

（注）

avread

次回の起動時に、APICシステムは Linuxパーティションで現在の APICイメージを起動します。このオプションは、通常時の使用を予期し

ていません。

bootcurr

次回の起動時に、APICシステムは Linuxパーティションで前の APICイメージを起動します。このオプションは、通常時の使用を予期し

ていません。

bootother

リーフへの APIC接続の破壊的テストです。これはシスコ社内でのテスト目的のみに使用さ

れ、それ以外の使用では、ファブリックへの

APIC接続に問題を引き起こす可能性があります。

bond0test

ファブリックに登録されているスイッチノー

ドのアドレスと状態を表示します。

fnvread

ファブリックに登録されているスイッチのノー

ドの追加情報を表示します。

fnvreadex

指定の APICインターフェイスを停止して再起動します。

linkflap


acidiag コマンド

機能オプション

APICは現在のログをアーカイブします。これは通常の再起動時に自動的に実行されます。こ

のオプションは、ハードリブート前に使用で

きます。

preservelogs

選択可能な 2つのオプションは、iptables-listとlldptoolです。iptables-listは、管理テナント契約により制御される Linux iptablesを表示するために使用されます。lldptoolは、APICにより送受信される lldp情報を表示するために使用されます。

run

データ層の状態を要約します。出力は、各サー

ビス用のデータ層の状態についての要約を示し

ます。シャードビューは昇順で複製を表示し

ます。

rvread

すべてのレプリカのすべてのシャード上にあ

る、サービス用のデータ層の状態が表示されま

す。

以下に例を示します。例,（161ページ）

（注）

rvread service

すべてのレプリカの特定のシャード上にある、

サービス用のデータ層の状態が表示されます。


（注）

rvreadservice shard

特定のシャードとレプリカ上にある、サービス

用のデータ層の状態が表示されます。


（注）

rvread service shard replica

ファームウェアリポジトリにイメージをロー

ドする前に、イメージを検証することができま

す。この機能は、リポジトリに追加されるイ

メージの通常プロセスの一部として実行される

ことに注意してください。

validateimage

APIC上の生成済み nginx設定ファイルを検証して、nginxがその設定ファイルを使用して開始できることを確認します。これは nginx Webサーバが APIC上で稼働していない場合の、デバッグでの使用を意図しています。

validateenginxconf



表 2：サーバ ID

IDサービス

1cliD

2コントローラ

3eventmgr

4extXMLApi

5policyelem

6policymgr

7reader

8ae

9topomgr

10observer

11dbgr

12observerelem

13dbgrelem

14vmmmgr

15nxosmock

16bootmgr

17appliancedirector

18adrelay

19ospaagent

20vleafelem

21dhcpd

22scripthandler

23idmgr



IDサービス

24ospaelem

25osh

26opflexagent

27opflexelem

28confelem

29vtap

表 3：データ状態

ID状態

0COMATOSE

1NEWLY_BORN

2UNKNOWN

11DATA_LAYER_DIVERGED

12DATA_LAYER_DEGRADED_LEADERSHIP

111DATA_LAYER_ENTIRELY_DIVERGED

112DATA_LAYER_PARTIALLY_DIVERGED

121DATA_LAYER_ENTIRELY_DEGRADED_LEADERSHIP

122DATA_LAYER_PARTIALLY_DEGRADED_LEADERSHIP

255FULLY_FIT

システムのキーワード

acidiag [start| stop| restart] [mgmt| xinetd]

acidiag installer -u imageurl -c

acidiag reboot

acidiag touch [clean| setup]

acidiag verifyapic



___________________構文の説明機能オプション

クリーンインストールを指定します。-c

APICイメージの URLを指定します。-u

APICイメージを指定します。imageurl

APICに新しいイメージをインストールし、-cでクリーンインストールを実行します。

インストーラ

APICのすべてのサービスを指定します。mgmt

APICを再起動します。reboot

APICのサービスを再起動します。restart

APICのサービスを起動します。start

APICのサービスを停止します。stop

APICの設定をリセットします。

• cleanオプションは、APICのネットワーク設定（ファブリック名、IPアドレス、ログインなど）を保持すると同時に、すべて

のポリシーデータを削除します。

• setupオプションは、ポリシーデータとAPICネットワーク設定の両方を削除します。

touch [clean | setup]

APICソフトウェアのバージョンを表示します。verifyapic

sshおよび telnetデーモンを制御する xinetd（拡張インターネットデーモン）サービスを指定

します。

xinetd

診断キーワード

acidiag crashsuspecttracker

acidiag dbgtoken

acidiag version



___________________構文の説明機能オプション

クラッシュを示すサービスまたはデータのサブ

セットの状態を追跡します。

crashsuspecttracker

ルートパスワードの生成に使用するトークン

を生成します。これは必要に応じて TACの操作中に、指示どおりに使用します。

dbgtoken

APIC ISOソフトウェアのバージョンを表示します。

version

例

次の例は、acidiagコマンドの使用方法を示しています。admin@apic1:~> acidiag version1.0.0.414

admin@apic1:~> acidiag verifyapicopenssl_check: certificate detailssubject= CN=Insieme,O=Insieme Networks,L=SanJose,ST=CA,C=USissuer= O=Default Company Ltd,L=Default City,C=XXnotBefore=Jul 19 20:40:32 2013 GMTnotAfter=Jul 19 20:40:32 2014 GMTopenssl_check: passedssh_check: passedall_checks: passed

admin@apic1:~> acidiag avreadLocal appliance ID=1 ADDRESS=10.0.0.1 TEP ADDRESS=10.0.0.0/16CHASSIS_ID=10220833-ea00-3bb3-93b2-ef1e7e645889Cluster of 3 lm(t):1(2014-07-12T19:54:04.877+00:00) appliances(out of targeted 3 lm(t):3(2014-07-12T19:55:03.442+00:00))with FABRIC_DOMAIN name=mininet set to version=1.0(0.414)

lm(t):3(2014-07-12T19:55:13.564+00:00)appliance id=1 last mutated at 2014-07-12T19:46:06.831+00:00 address=10.0.0.1 tep

address=10.0.0.0/16oob address=192.168.10.1/24 version=1.0(0.414) lm(t):1(2014-07-12T19:54:05.146+00:00)

chassisId=10220833-ea00-3bb3-93b2-ef1e7e645889 lm(t):1(2014-07-12T19:54:05.146+00:00)

commissioned=1 registered=1 active=yes(zeroTime)health=(applnc:255 lm(t):1(2014-07-12T20:01:22.934+00:00) svc's)

appliance id=2 last mutated at 2014-07-12T19:51:10.649+00:00 address=10.0.0.2 tepaddress=10.0.0.0/16

oob address=192.168.10.2/24 version=1.0(0.414) lm(t):2(2014-07-12T19:54:05.064+00:00)

chassisId=5d74122c-2ab9-3ccb-b06d-f620d5e20ccd lm(t):2(2014-07-12T19:54:05.064+00:00)

commissioned=1 registered=1 active=yes(2014-07-12T19:51:10.651+00:00)health=(applnc:255 lm(t):2(2014-07-12T20:01:22.442+00:00) svc's)

appliance id=3 last mutated at 2014-07-12T19:54:05.028+00:00 address=10.0.0.3 tepaddress=10.0.0.0/16

oob address=192.168.10.3/24 version=1.0(0.414) lm(t):3(2014-07-12T19:54:05.361+00:00)

chassisId=71355d49-6fe7-3a78-a361-72d6c1e3360c lm(t):3(2014-07-12T19:54:05.361+00:00)

commissioned=1 registered=1 active=yes(2014-07-12T19:54:05.029+00:00)health=(applnc:255 lm(t):3(2014-07-12T20:01:22.892+00:00) svc's)

clusterTime=<diff=0 common=2014-07-14T16:52:20.343+00:00 local=2014-07-14T16:52:20.343+00:00pF=<displForm=0



offsSt=0 offsVlu=0 lm(t):3(2014-07-12T19:55:03.750+00:00)>>---------------------------------------------

admin@apic1:~> rvread 6 3 1(6,3,1) st:6 lm(t):3(2014-10-16T08:48:20.238+00:00) le: reSt:LEADER voGr:0 cuTerm:0x19lCoTe:0x18

lCoIn:0x1800000000001b2a veFiSt:0x31 veFiEn:0x31 lm(t):3(2014-10-16T08:48:20.120+00:00)

lastUpdt 2014-10-16T09:07:00.214+00:00---------------------------------------------clusterTime=<diff=65247252 common=2014-10-16T09:07:01.837+00:00local=2014-10-15T14:59:34.585+00:00

pF=<displForm=0 offsSt=0 offsVlu=0 lm(t):3(2014-10-16T04:50:08.714+00:00)>>

admin@apic1:~> rvread 6 3(6,3,1) st:6 lm(t):3(2014-10-16T08:48:20.238+00:00) le: reSt:LEADER voGr:0 cuTerm:0x19lCoTe:0x18


lastUpdt 2014-10-16T09:08:30.240+00:00(6,3,2) st:6 lm(t):1(2014-10-16T08:47:25.323+00:00) le: reSt:FOLLOWER voGr:0 cuTerm:0x19lCoTe:0x18

lCoIn:0x1800000000001b2a veFiSt:0x49 veFiEn:0x49 lm(t):1(2014-10-16T08:48:20.384+00:00)lp: clSt:2

lm(t):1(2014-10-16T08:47:03.286+00:00) dbSt:2 lm(t):1(2014-10-16T08:47:02.143+00:00)stMmt:1

lm(t):0(zeroTime) dbCrTs:2014-10-16T08:47:02.143+00:00 lastUpdt2014-10-16T08:48:20.384+00:00(6,3,3) st:6 lm(t):2(2014-10-16T08:47:13.576+00:00) le: reSt:FOLLOWER voGr:0 cuTerm:0x19lCoTe:0x18


lastUpdt 2014-10-16T09:08:30.240+00:00---------------------------------------------clusterTime=<diff=65247251 common=2014-10-16T09:08:30.445+00:00local=2014-10-15T15:01:03.194+00:00

pF=<displForm=0 offsSt=0 offsVlu=0 lm(t):3(2014-10-16T04:50:08.714+00:00)>>



索引

A

acidiagコマンド 155ACL拒否ロギング 67, 68, 69ACL許可および拒否ログ 71ACL許可ロギング 65, 66, 67

C

coreファイル 1

D

Digital Optical Monitoring 78, 80DOM 77, 78, 80

E

eventlogコマンド 123, 124, 125, 126, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 141, 143, 144, 145, 146

S

SNMP 10, 11, 13, 14トラップソースの設定 14トラップの通知先の設定 13ポリシーの設定 11概要 10

SPAN 15, 16ガイドラインおよび制約事項 15概要 15設定 16

syslog 4, 5, 6destination 5source 6

syslog (続き)概要 4

T

traceroute 17, 18ガイドラインおよび制約事項 17概要 17設定 18

あ

アトミックカウンタ 7, 8, 10, 92, 99, 121ガイドラインおよび制約事項 8概要 7, 92, 99, 121設定 10

え

エンドポイント接続 19

て

テクニカルサポートファイル 1, 3sending 3

デジタルオプティカルモニタリング 77

ふ

ファイルのエクスポート 1, 2概要 1送信先の作成 2

Cisco APIC Troubleshooting Guide IN-1

まマルチポッド 75

Cisco APIC Troubleshooting GuideIN-2

索引

Documents

Cisco APIC Troubleshooting Guide...ACIでのSNMP アクセスのサポート11 SNMPの設定11 GUIによるSNMPポリシーの設定11 Cisco APIC Troubleshooting Guide