Cisco Data Center Assurance Program（DCAP）
6.0 第 2 巻
テスト
Cisco Data Center Assurance Program (DCAP) 6.0 Volume 2
Testing
【注意】シスコ製品をご使用になる前に、安全上の注意
（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 version of the UNIX operating system.All rights reserved.Copyright © 1981, Regents of the University of California.
ここに記載されている他のいかなる保証にもよらず、各社のすべてのマニュアルおよびソフトウェアは、障害も含めて「現状のまま」として提供されます。シスコシステ
ムズおよびこれら各社は、商品性の保証、特定目的への準拠の保証、および権利を侵害しないことに関する保証、あるいは取引過程、使用、取引慣行によって発生する保
証をはじめとする、明示されたまたは黙示された一切の保証の責任を負わないものとします。
いかなる場合においても、シスコシステムズおよびその供給者は、このマニュアルの使用または使用できないことによって発生する利益の損失やデータの損傷をはじめと
する、間接的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコシステムズまたはその供給者に知らされていても、それらに対する責任を一切負
わないものとします。
Cisco Data Center Assurance Program（DCAP）6.0 第 2 巻 テスト
© 2009 Cisco Systems, Inc.
All rights reserved.
Copyright © 2009–2010, シスコシステムズ合同会社 .
All rights reserved.
CONTENTS
概要
ix
スコープ
x
高レベルのトポロジ表示
xii
テスト トラフィック プロファイル
DCAP 6.0 スイート
CHAPTER
1
xiv
DCAP Catalyst 6500 テスト
設定例
xiii
1-1
1-1
テスト結果の要約
1-1
テスト ケース
1-3
ベースライン
1-3
定常ステート
1-3
1-3
IOS ベースライン定常ステート
IOS 簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）ウォー
ク
1-5
SSHv2 ログインの繰り返し
Telnet ログインの繰り返し
ネガティブ
1-5
1-6
1-6
ハードウェア障害
1-7
スーパーバイザ フェールオーバー集約
1-7
アクセスでのスーパーバイザ フェールオーバー
1-8
スーパーバイザ障害コア Rendevous Point（RP; ランデブー ポイント）
リンク障害
1-9
1-10
dcap-6k-agg-1 と dcap-4k-acc-1 の間の 10G L2 リンクの障害
dcap-6k-agg-1 と dcap-6k-acc-1 の間の 10G L2 リンクの障害
dcap-6k-agg-2 と dcap-4k-acc-1 の間の 10G L2 リンクの障害
dcap-6k-agg-2 と dcap-6k-acc-1 の間の 10G L2 リンクの障害
dcap-6k-core-1 と dcap-6k-agg-1 の間の 10G L3 リンクの障害
dcap-6k-core-1 と dcap-6k-agg-2 の間の 10G L3 リンクの障害
1-10
1-12
1-13
1-14
1-16
1-17
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
iii
Contents
1-18
dcap-6k-core-1 と dcap-6k-core-2 の間の 10G L3 リンクの障害
1-20
dcap-6k-core-2 と dcap-6k-agg-1 の間の 10G L3 リンクの障害
1-21
dcap-6k-core-2 と dcap-6k-agg-2 の間の 10G L3 リンクの障害
1-22
dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害
1-24
dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害
1-26
dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害
1-27
dcap-6k-agg-1 と dcap-6k-agg-2 の間の L2 ポートチャネルの障害
1-28
dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害
1-30
dcap-6k-agg-1 から dcap-6k-agg-2 への L2 バンドル リンクの障害
CHAPTER
2
DCAP Nexus 7000 テスト
設定例
2-1
2-1
テスト結果の要約
テスト ケース
2-6
ベースライン
機能
2-1
2-6
2-6
dcap-7k-agg-1 に対する連続的な IGMP Join および Leave
2-7
IGMP ソース オンリー フラッディング
2-8
Nexus 7000 の OSPF データベースの検証
2-10
Nexus 7000 の OSPF NSSA 動作の検証
ポート セキュリティ機能の動作の検証
2-11
スパニング ツリー BPDU フィルタ機能の動作の検証
2-12
スパニング ツリー BPDU ガード機能の動作の検証
2-13
スパニング ツリー ループ ガード機能の動作の検証
2-14
スパニング ツリー PortFast 機能の動作の検証
定常ステート
2-15
2-16
ベースライン定常ステート
システム管理
2-6
2-16
2-18
2-18
Catalyst 4948-10G のアップグレード
2-19
CLI を使用した Nexus 5000 のダウングレード
2-20
CLI を使用した Nexus 5000 のアップグレード
2-21
CLI を使用した Nexus 7000 アクセス ISSU のダウングレード
2-22
CLI を使用した Nexus 7000 アクセス ISSU のアップグレード
CLI を使用した Nexus 7000 アグリゲーション ISSU のアップグレード
2-25
CLI を使用した Nexus 7000 ISSU コアのアップグレード
2-26
Nexus 7000 プロセス再起動性
2-27
SSHv2 ログインの繰り返し
2-28
Telnet ログインの繰り返し
2-23
Cisco Data Center Assurance Program（DCAP）6.0
iv
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
Contents
SNMP MIB ウォーク
トラフィック処理
2-29
2-29
2-30
Nexus 7000 のハードウェア レート リミッタ
dcap-4k-acc-2 での各種フレーム サイズの処理の検証
dcap-7k-acc-1 での各種フレーム サイズの処理の検証
dcap-5k-acc-1 での各種フレーム サイズの処理の検証
2-33
Nexus 7000 の uRPF の検証
ネガティブ
2-31
2-32
2-34
ハードウェア障害
2-34
dcap-7k-acc-1 でのアクティブ スーパーバイザ障害
dcap-7k-agg-1 でのアクティブ スーパーバイザ障害
dcap-7k-core-1 でのアクティブ スーパーバイザ障害
2-38
dcap-7k-acc-1 でのラインカード障害
2-40
dcap-7k-agg-1 でのラインカード障害
2-41
dcap-7k-core-1 でのラインカード障害
dcap-7k-acc-1 でのラインカード フラップの繰り返し
2-44
dcap-7k-agg-1 での電源モジュール障害
2-45
dcap-7k-agg-1 でのスパイン カード障害
dcap-7k-agg-1 でのスタンバイ スーパーバイザ障害
2-47
dcap-7k-agg-1 でのシステム障害
2-50
dcap-7k-core-1 でのシステム障害
リンク障害
2-30
2-35
2-36
2-37
2-43
2-46
2-51
2-52
dcap-7k-agg-2 と dcap-4k-acc-2 の間の 10G L2 リンクの障害
2-56
dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 リンクの障害
2-59
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害
2-63
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 ポートチャネルの障害
2-67
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害
2-70
dcap-7k-agg-1 と dcap-7k-agg-2 の間の L2 ポートチャネルの障害
2-74
dcap-7k-agg-2 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害
2-78
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害
2-79
dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害
2-81
dcap-7k-core-1 と dcap-7k-core-2 の間の L3 バンドル リンクの障害
2-83
dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害
2-85
dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害
2-87
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害
2-89
dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害
2-91
dcap-7k-core-1 と dcap-7k-core-2 の間の L3 ポートチャネルの障害
2-92
dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
v
Contents
2-94
dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害
2-96
dcap-7k-agg-1 と dcap-5k-acc-1 の間のレイヤ 2 バンドル リンクの障害
2-98
dcap-7k-agg-1 と dcap-6k-acc-1 の間のレイヤ 2 バンドル リンクの障害
2-100
dcap-7k-agg-1 と dcap-7k-acc-1 の間のレイヤ 2 バンドル リンクの障害
2-102
dcap-7k-agg-1 と dcap-7k-agg-2 の間のレイヤ 2 バンドル リンクの障害
dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 バンドル リンクのフラップの繰り返
し
2-104
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクのフラップの繰り返
し
2-105
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 バンドル リンクのフラップの繰り返
し
2-106
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 バンドル リンクのフラップの繰り返
し
2-107
2-108
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 チャネルのフラップの繰り返し
2-109
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 チャネルのフラップの繰り返し
2-110
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 チャネルのフラップの繰り返し
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクのフラップの繰り返
し
2-111
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 チャネルのフラップの繰り返
し
2-112
システム イベント
2-113
dcap-4k-acc-2 でのラント フレームまたはジャイアント フレームの処理
dcap-5k-acc-1 でのラント フレームまたはジャイアント フレームの処理
dcap-6k-acc-1 でのラント フレームまたはジャイアント フレームの処理
dcap-7k-acc-1 でのラント フレームまたはジャイアント フレームの処理
異常な SNMP プロトコル テスト
2-117
2-118
SSHv2 ログイン失敗試行の繰り返し
2-119
Telnet ログイン失敗試行の繰り返し
APPENDIX
A
DCAP 6.0 のバグ
Nexus 5000 のバグ
A-2
Nexus 7000 のバグ
A-2
トラフィック プロファイルの詳細
2-116
A-2
B-1
Catalyst 6500 のトラフィック プロファイルの詳細
ホスト
2-115
A-1
Catalyst 4948-10G のバグ
B
2-114
A-1
Catalyst 6500 のバグ
APPENDIX
2-113
B-1
B-2
ユニキャスト トラフィック プロファイル
B-3
Cisco Data Center Assurance Program（DCAP）6.0
vi
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
Contents
マルチキャスト トラフィック プロファイル
B-3
Nexus 7000 のトラフィック プロファイルの詳細
ホスト
B-4
B-5
ユニキャスト トラフィック プロファイル
マルチキャスト トラフィック プロファイル
B-5
B-5
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
vii
Contents
Cisco Data Center Assurance Program（DCAP）6.0
viii
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
概要
データセンター スイッチ Nexus ファミリを導入すると、データセンター環境を準備して、データセン
ター コンピューティングの次の進化段階に備えることができます。
さまざまな Nexus ファミリ製品をデータセンター トポロジに追加していく場合、現行の Catalyst 6500
ベースの環境から新しいプラットフォームに円滑に移行できることが重要です。たとえば、お客様は次
のような問題に直面したり、次のような情報が必要となる場合があります。
• Catalyst ファミリと Nexus ファミリの機能にはどのような類似性があるのか。
• 2 つのプラットフォーム間で機能が同等である場合、設定時と実装時にどのような違いがあるか。
• Native IOS と NX-OS のプロトコル実装にはどのような違いがあるか。
• Catalyst プラットフォームと Nexus プラットフォームの相互運用性に関して、どのような問題が発
生するか。
• スケーラビリティおよびパフォーマンスの点で、2 つのプラットフォーム間にどのような性能の違
いがあるか。
• ネガティブなシステム イベントに対応するシステム / ネットワークの復旧に関して、動作およびパ
フォーマンスにどのような違いがあるか。
このマニュアルでは、これらの問題に対処する方法について説明します。Catalyst 6500 ベースと
Nexus 7000 ベースのデータセンター テスト トポロジを並べて構築および設定することによって、テス
ト チームは設定を比較し、プロトコルや復旧動作の違いについて知ることができます。
このマニュアルは、3 巻セットで配布されます。第 1 巻では、テスト中に気付く設定ガイドラインの要
約と、テスト トポロジおよび方法論の詳細について説明します。
続いて第 2 巻ではテスト計画のコピーを提供し、第 3 巻ではテスト中に使用したシステム構成のコピー
を提供します。このマニュアルは、独自の Nexus ベースのデータセンターを設定する際の参考資料と
して利用できます。テスト結果はここには提供されていませんが、担当者を通じて入手可能です。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
ix
概要
スコープ
このテストでは、次のハードウェア プラットフォームとそれぞれのソフトウェア バージョンを使用し
ました。
• NX-OS 4.0(4) を実行している Nexus 7000
• Native IOS 12.2(33)SXH3a を実行している Catalyst 6500
• NX-OS 4.0(1a)N1(1) を実行している Nexus 5000
• Native IOS 12.2(46)SG を実行している Catalyst 4948-10G
テストで使用したハードウェアの詳細なリストについては、このマニュアルの第 3 巻『Cisco Data
Center Assurance Program（DCAP）6.0 第 3 巻：コンフィギュレーション』、または上記のインタラク
ティブ ツールで参照できます。
実行されたテストの大部分は、ネガティブ イベントに使用されたシステムの応答特性を明らかにする
ことに重点を置いています。ネガティブ テストはすべてのプラットフォームで実施されましたが、こ
の特性解析の中心となったシステムは Catalyst 6500 と Nexus 7000 です。ネガティブ テストは、ス
イッチ間リンクの破損、ラインカードまたはスーパーバイザの障害、プロセスのリセットなどの有害な
イベントで構成されています。ネガティブ イベントに対するシステムからの応答は、観測されたトラ
フィック損失の量で測定されます。
テストの大部分はこのネガティブ イベントの処理に費やされていますが、テスト トポロジ内で有効に
なっているさまざまな機能の基本機能検証テストも実施されています。この機能テストは主に Nexus
7000 プラットフォームで実施されています。Catalyst 6500 の拡張機能テストおよびプラットフォーム
検証は、すでに Safe Harbor Native IOS テストのスコープに含まれています。このテストの Catalyst
6500 で使用された Native IOS リリース 12.2(33)SXH3a では、Data Center Assurance Program
（DCAP）6.0 のテストが開始されたときには、すでに Safe Harbor のテストが完了していました。
Catalyst 6500 の機能テストについて詳しい情報が必要な場合は、お客様向けの Safe Harbor ページ
（http://www.cisco.com/go/safeharbor）を参照してください。
正式にはスケーラビリティとパフォーマンスはこのテストのスコープに含まれていませんが、VLAN
または VLAN Switch Virtual Interface（SVI; スイッチ仮想インターフェイス）の数、Hot Standby
Router Protocol（HSRP; ホットスタンバイ ルータ プロトコル）グループの数、マルチキャスト グルー
プの数など、特定の領域の特定のスケーラビリティを調べる機会がありました。このようなスケーリン
グの詳細については、次のセクションで説明します。
次の表は、テストに使用したプラットフォームで有効化または設定されている機能の要約を示していま
す。上記のとおり、これらの機能のすべてが、このテストの一部としてすべてのプラットフォームで慎
重にテストされたわけではありません。1 つ以上のネガティブ テスト ケースの一部として監視された
機能もあれば、Safe Harbor リリース テストに含まれていた機能もあります。
表 1
DCAP 6.0 で有効になった機能
Catalyst
6500
Nexus
5000
Catalyst
4948-10G
セキュア シェル（SSH） x
x
x
x
Telnet
x
x
x
x
簡易ネットワーク管理プ x
ロトコル（SNMP）
x
x
x
x
x
x
x
機能
rPVST+ スパニング ツ
Nexus
7000
リー
Cisco Data Center Assurance Program（DCAP）6.0
x
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
概要
表 1
DCAP 6.0 で有効になった機能 （続き）
x
x
x
x
x
x
x
x
BPDU ガード
x
x
x
x
ループ ガード
x
x
x
x
x
x
x
x
IGMP スヌーピング
x
x
x
x
ポート セキュリティ
x
x
Open Shortest Path First x
x
スパニング ツリー プロ
トコル（STP）Portfast
ブリッジ プロトコル
データ ユニット
（BPDU）フィルタ
インターネット グルー
プ管理プロトコル
（IGMP ）
x
（OSPF）
Link Aggregation
Control Protocol
（LACP）
x
x
x
ネットワーク タイム プ
ロトコル（NTP）
x
x
x
x
Protocol Independent
Multicast-Sparse Mode
（PIM-SM）
Multicast Source
Discovery Protocol
（MSDP）
x
x
x
x
自動ランデブー ポイン
ト（RP）
x
x
スタティック RP
x
x
エニーキャスト RP
x
x
HSRP
x
x
802.1q Trunking
x
x
x
x
プロセス再起動性
x
ジャンボ フレーム
x
x
x
x
ハードウェア レート リ
ミット
x
Unicast Reverse Path
Forwarding（uRPF）
x
x
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
xi
概要
高レベルのトポロジ表示
このテストでは、図 1 に示すように 2 つのデータセンターを使用しています。いずれも標準のコア / ア
グリゲーション / アクセス レイヤ モデルを使用して構成されています。一方のデータセンターでは、
コア レイヤおよびアグリゲーション レイヤで Catalyst 6500 を使用しています。もう一方のデータセン
ターでは、これらのレイヤを Nexus 7000 スイッチで構成しています。各データセンターのアクセス レ
イヤには、Catalyst 6500、Catalyst 4948-10G、および Nexus 5000 スイッチが含まれています。Nexus
7000 ベースのデータ センターでは、Nexus 7000 もアクセス レイヤに含まれています。
図 1
高レベルのテスト トポロジ
ࠦࠕ
㓸⚂
269434
ࠕࠢ࠮ࠬ
（注）
2 つのデータセンター トポロジは、論理的にはいかなる形でも接続されていません。
（注）
2 つのデータセンター トポロジのアクセス レイヤは、同じ物理スイッチを使用することによって、物
理的に接続されています。ただし、論理的には、各データセンターに異なる VLAN ドメインを使用す
ることによって 2 つが分離されています。
Cisco Data Center Assurance Program（DCAP）6.0
xii
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
概要
各データセンターのアクセス レイヤはレイヤ 2 です。図 1 では、レイヤ 2 とレイヤ 3 の区分が点線で
示されています。
Catalyst 6500 ベースのトポロジでは、すべてのスイッチ間リンクが 10 ギガビット イーサネットです。
ただし、2 つのアグリゲーション レイヤ スイッチ間のリンク、および 2 つのアグリゲーション レイヤ
スイッチと Nexus 5000 アクセス レイヤ スイッチの間のリンクは例外です。これらのリンクは 2x10 ギ
ガビット イーサネット LACP チャネルです。
Nexus 7000 ベースのトポロジでは、一部の例外を除き、スイッチ間リンクの大部分が 2x10 ギガビッ
ト イーサネット LACP チャネルです。Catalyst 4948-10G アクセス レイヤ スイッチからのアップリン
クは、単一の 10 ギガビット イーサネット リンク（このプラットフォームのキャパシティ）です。
Nexus 5000 アクセス レイヤ スイッチからのアップリンクは、4x10 ギガビット イーサネット LACP
チャネルです。
2 つのトポロジのそれぞれで、ループフリーのレイヤ 2 ドメインをイネーブルにするために、Rapid
Per-VLAN Spanning-Tree plus（PVST+）スパニング ツリーが使用されています。BPDU フィルタ、
BPDU ガード、ループ ガードなど、個々のドメインを強固にするためにさまざまなスパニング ツリー
拡張が使用されています。サーバのエンドポイント（IXIA テスト ツールでエミュレート）に接続して
いるアクセス レイヤ スイッチの各ポートは、スパニング ツリー Portfast およびポート セキュリティで
構成されています。
HSRP はゲートウェイ冗長機能を提供するために使用され、アグリゲーション レイヤで実装されてい
ます。OSPF は Interior Gateway Protocol（IGP）として使用されています。マルチキャストは
Protocol Independent Multicast（PIM）sparse モード プロトコルを使用することで容易に実現できま
す。各トポロジの 2 つのコア レイヤ デバイスは、自動 RP を使用するように設定され、さらにデバイ
ス間では MSDP が実行されます。2 つの RP は、冗長性を高めるためにエニーキャスト アドレスを共
有します。
テスト トラフィック プロファイル
2 つのトポロジのそれぞれで、トラフィック生成に 2 つの IXIA 10 ギガビット イーサネット テスト
ポートを使用します。1 つはトポロジの北側に、もう 1 つは南側にトラフィックを送信します。また、
各トポロジでは、個々の接続ホストをエミュレートするために、別々の Catalyst 6500 を使用して、ア
クセス レイヤに入ってくるトラフィックを個々のアクセス ポートに展開します。このファンアウト ス
イッチを使用すると、単一の IXIA テスト ツール ポートで、それぞれのアクセス レイヤ スイッチに接
続された 10 個の固有のサーバをエミュレートできます。
テスト トラフィック プロファイルは、ユニキャストとマルチキャストの両方のトラフィックで構成さ
れています。1000 パケット / 秒（pps）の平均レートでトポロジを通過するユニキャスト フローが 300
～ 400 個程度あります。フレーム サイズは 512 バイトに設定され、大部分のテストで、合計 8 Gbps の
ユニキャスト トラフィックがネットワーク上に送信されます。
マルチキャストは同じレートで送信され、同じく約 8 Gbps のトラフィックがネットワーク上に送信さ
れます。各アクセス レイヤ スイッチに接続されている 10 個のホストのそれぞれから、コア レイヤの
北側にある 50 個のマルチキャスト レシーバーのそれぞれにトラフィックを送信します。コア レイヤの
北側にある 10 個のホストのそれぞれから、各アクセス レイヤ スイッチで受信されている 50 グループ
にトラフィックを送信します（合計 150 ～ 200 個の固有の IGMP レポートがアクセス レイヤ ホストに
よって送信されます）。北側と南側の両方での送信側と受信側の組み合せによって、マルチキャスト グ
ループの RP として機能するコア レイヤ スイッチで最大 4000（S,G）エントリのスケーリングが提供
されます。
テスト トラフィック プロファイルの詳細については、このマニュアルの付録 B を参照してください。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
xiii
概要
DCAP 6.0 スイート
Cisco Data Center Assurance Program（DCAP）6.0 スイートは 3 巻で構成されています。
1. 第 1 巻
データセンター環境に配置された異なるプラットフォーム間における、レイヤ 2 およびレイヤ 3 の
設計と構成機能の違い、および警告について重点的に説明しています。
2. 第 2 巻
この DCAP リリースでテストされた、グローバル企業に重要な機能について説明しています。
3. 第 3 巻：コンフィギュレーション
この DCAP リリースで使用した Catalyst および Nexus のハードウェアとソフトウェアの設定ファ
イルについて説明しています。
Cisco Data Center Assurance Program（DCAP）6.0
xiv
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
C H A P T E R
1
DCAP Catalyst 6500 テスト
Data Center Assurance Program（DCAP）のベース ラボ トポロジは、次のセクションに定義されてお
り、テスト トポロジに図示されています。
ラボに設定されているエンタープライズ ネットワーク環境には、次のハードウェアおよびイメージが
含まれています。
テストに使用されるイメージ
• NX-OS 4.0(4) を実行している Nexus 7000
• Native IOS 12.2(33)SXH3a を実行している Catalyst 6500
• NX-OS 4.0(1a)N1(1) を実行している Nexus 5000
• Native IOS 12.2(46)SG を実行している Catalyst 4948-10G
設定例
Device Under Test（DUT; テスト対象デバイス）のトポロジ コンフィギュレーションの一覧について
は、
『Cisco Data Center Assurance Program（DCAP）6.0 第 3 巻：コンフィギュレーション』を参照し
てください。
テスト結果の要約
表 1-1 に、完了したすべてのテスト結果を示します。表 1-1 には、テストされたフィーチャまたは機
能、そのフィーチャまたは機能が属するフィーチャ セットについて説明しているセクション、各
フィーチャまたは機能のコンポーネント テスト、およびテスト中に検出された関連バグが記載されて
います。
（注）
テスト結果は、対象テクノロジーおよびテストが行われた実際のシナリオに固有のものです。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-1
第1章
DCAP Catalyst 6500 テスト
テスト結果の要約
表 1-1
DCAP Catalyst 6500 のテスト結果の要約
テスト スイート フィーチャ / 機能 テスト
結果
「ベースライン」「定常ステート」 1. IOS ベースライン定常ステート
（P.1-3）
（P.1-3）
2. IOS 簡易ネットワーク管理プロトコル（SNMP）管理情報ベース
（MIB）ウォーク
3. SSHv2 ログインの繰り返し
4. Telnet ログインの繰り返し
「ネガティブ」 「ハードウェア障 1. スーパーバイザ フェールオーバー集約
（P.1-6）
害」（P.1-7）
2. アクセスでのスーパーバイザ フェールオーバー
3. スーパーバイザ障害コア Rendevous Point（RP; ランデブー ポイント）
「ネガティブ」 「リンク障害」
（P.1-6）
（P.1-10）
1. dcap-6k-agg-1 と dcap-4k-acc-1 の間の 10G L2 リンクの障害
2. dcap-6k-agg-1 と dcap-6k-acc-1 の間の 10G L2 リンクの障害
3. dcap-6k-agg-2 と dcap-4k-acc-1 の間の 10G L2 リンクの障害
4. dcap-6k-agg-2 と dcap-6k-acc-1 の間の 10G L2 リンクの障害
5. dcap-6k-core-1 と dcap-6k-agg-1 の間の 10G L3 リンクの障害
6. dcap-6k-core-1 と dcap-6k-agg-2 の間の 10G L3 リンクの障害
7. dcap-6k-core-1 と dcap-6k-core-2 の間の 10G L3 リンクの障害
8. dcap-6k-core-2 と dcap-6k-agg-1 の間の 10G L3 リンクの障害
9. dcap-6k-core-2 と dcap-6k-agg-2 の間の 10G L3 リンクの障害
10. dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害
11. dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害
12. dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害
13. dcap-6k-agg-1 と dcap-6k-agg-2 の間の L2 ポートチャネルの障害
14. dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害
15. dcap-6k-agg-1 から dcap-6k-agg-2 への L2 バンドル リンクの障害
Cisco Data Center Assurance Program（DCAP）6.0
1-2
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
テスト ケース
テスト ケース
この DCAP リリースに対してテストされている、グローバル企業にとって重要な機能については、次
のセクションで説明します。
• 「ベースライン」（P.1-3）
• 「ネガティブ」（P.1-6）
ベースライン
ベースライン テストでは、テスト開始前にネットワークが正常に稼動していることを確認し、定常ス
テートでのネットワーク パフォーマンスを定量化します。
ここでは、次の内容について説明します。
• 「定常ステート」（P.1-3）
定常ステート
ベースライン テストでは、テスト開始前にネットワークが正常に稼動していることを確認し、定常ス
テートでのネットワーク パフォーマンスを定量化します。
ここでは、次の内容について説明します。
• 「IOS ベースライン定常ステート」（P.1-3）
• 「IOS 簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）ウォーク」（P.1-5）
• 「SSHv2 ログインの繰り返し」（P.1-5）
• 「Telnet ログインの繰り返し」（P.1-6）
IOS ベースライン定常ステート
このテストでは、定常ステート時のネットワーク動作を検証します。すべてのバックグラウンド トラ
フィックとバックグラウンド ルートが実行されているときに、他の影響を受けずネットワークを実行
して、各デバイスのベースラインとなる CPU およびメモリを定量化できます。
また、このテスト ケースでは、テスト トポロジ内で実行されている数多くのプロトコルの機能も検証
できます。対象となるプロトコルは次のとおりです。
• Link Aggregation Control Protocol（LACP）
• Network Time Protocol（NTP; ネットワーク タイム プロトコル）
• Rapid PVST+ Spanning Tree
• Protocol Independent Multicast（PIM）
• Open Shortest Path First （OSPF）
• IEEE 802.1q Trunking
• Multicast Source Discovery Protocol（MSDP）
• Hot Standby Router Protocol（HSRP; ホットスタンバイ ルータ プロトコル）
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-3
第1章
DCAP Catalyst 6500 テスト
ベースライン
テスト手順
IOS ベースライン定常ステート テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia テスト ツールを使用してテスト トラフィック プロファイルを開始します。このトラフィックは、
このテスト期間中、継続して実行されます。
ステップ 3
正しいバンドル インターフェイス セットで指定され、LACP プロトコルが実行されている設定済みの
ポートチャネルを使用して、トポロジ内のすべてのデバイスで show port-channel summary コマンド
または show etherchannel summary コマンドを実行します。
ステップ 4
show ntp peer-status コマンドまたは show ntp status コマンドを使用して、トポロジ内の各デバイス
と有効な NTP サーバとの間にピアリングが確立されていることを確認します。
ステップ 5
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメイン内のスイッチ間リンク
が適切な VLAN について正しい spanning-tree ステートになっていることを確認します。
ステップ 6
show ip pim neighbor コマンドを使用して、トポロジ内の適切なデバイス間に正しい PIM ピア関係が
確立されていることを確認します。
ステップ 7
show ip ospf neighbor コマンドを使用して、トポロジ間に正しい近接関係が確立されていることを確
認します。
ステップ 8
show interface interface switchport コマンドを使用して、トポロジのレイヤ 2 ドメイン内のスイッチ
間リンクが、正しい VLAN セットをトランキングしていること、および正しいカプセル化方式を使用
していることを確認します。
ステップ 9
show ip msdp summary コマンドを使用して、dcap-6k-core-1 と dcap-6k-core-2 が MSDP 機能を正し
くピアリングしていることを確認します。
ステップ 10
dcap-6k-agg-1 と dcap-6k-agg-2 に対して show hsrp brief コマンドを使用して、共有 HSRP ゲート
ウェイ コンフィギュレーションが正しいステートになっていることをすべての VLAN について確認し
ます。
ステップ 11
トラフィックを最低でも 60 時間実行し、トポロジがその期間中に 1 つの定常ステートに留まるように
します。
ステップ 12
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 13
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• このテストのアクティビティが原因でネットワークの安定性が損なわれることがない。
• テスト トポロジで使用されているプロトコルが予期されたとおりに機能する。
• CPU やメモリに問題が発生しない。
結果
IOS ベースライン定常ステート テストに合格しました。
Cisco Data Center Assurance Program（DCAP）6.0
1-4
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ベースライン
IOS 簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）ウォーク
このテストでは、定常ステート時のネットワーク動作を検証します。すべてのバックグラウンド トラ
フィックとバックグラウンド ルートが実行されているときに、他の影響を受けずネットワークを実行
して、各デバイスのベースラインとなる CPU およびメモリを定量化できます。
テスト手順
IOS SNMP MIB ウォーク テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
サーバの Command Line Interface（CLI; コマンドライン インターフェイス）で snmpwalk ユーティリ
ティを使用して、DUT 上で SNMP ウォークを同時に 6 つ実行します。
ステップ 4
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 5
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• CPU やメモリに問題が発生しない。
結果
IOS SNMP MIB ウォーク テストは正常に終了しました。
SSHv2 ログインの繰り返し
このテストでは、Supervisor 720 システムに対する Secure Shell（SSH; セキュア シェル）ログインの
繰り返しがメモリまたはシステムの安定性に影響しないことを確認します。DUT の SSH サーバとクラ
イアントは、両方でサポートしている最新のバージョンにネゴシエートします。IOS SSHv2 は、
12.1(19)E で導入されました。テスト対象デバイスは、HSRP のアクティブなアグリゲーション スイッ
チです。
テスト手順
SSHv2 ログインの繰り返しテストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
テスト スクリプトの繰り返しを 6 つ同時に開始します。SSH バージョン 2 を使用して、各繰り返しで
連続 2000 回 dcap-6k-agg-1 にログインを試行します。
ステップ 3
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-5
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ステップ 4
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• CPU やメモリに問題が発生しない。
結果
SSHv2 ログインの繰り返しテストは正常に終了しました。
Telnet ログインの繰り返し
このテストでは、Supervisor 720 システムに対する Telnet ログインの繰り返しがメモリまたはシステ
ムの安定性に影響しないことを確認します。テスト対象デバイスは、HSRP のアクティブなアグリゲー
ション スイッチです。
テスト手順
Telnet ログインの繰り返しテストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
テスト スクリプトの繰り返しを 6 つ同時に開始します。SSH バージョン 2 を使用して、各繰り返しで
連続 2000 回 dcap-6k-agg-1 にログインを試行します。
ステップ 3
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 4
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• CPU やメモリに問題が発生しない。
結果
Telnet ログインの繰り返しテストは正常に終了しました。
ネガティブ
このテスト群では、ネガティブなシナリオを実行します。スイッチやリンクの障害などが該当します。
Cisco Data Center Assurance Program（DCAP）6.0
1-6
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ここでは、次の内容について説明します。
• 「ハードウェア障害」（P.1-7）
• 「リンク障害」（P.1-10）
ハードウェア障害
ネガティブなハードウェア障害として、アクティブ スーパーバイザ、スタンバイ スーパーバイザ、
個々のラインカード、スイッチ全体の障害など、各種システム コンポーネントの障害に焦点を当てて
います。
ここでは、次の内容について説明します。
• 「スーパーバイザ フェールオーバー集約」（P.1-7）
• 「アクセスでのスーパーバイザ フェールオーバー」（P.1-8）
• 「スーパーバイザ障害コア Rendevous Point （RP; ランデブー ポイント）」（P.1-9）
スーパーバイザ フェールオーバー集約
このテストでは、システムの安定性に関する機能およびテスト対象デバイスのトラフィック コンバー
ジェンス タイムを検証します。
このテストでは、HSRP のアクティブなアグリゲーション スイッチで障害が発生します。スイッチは、
マルチキャスト（Designated Router（DR; 指定ルータ）として）、およびユニキャスト トラフィックの
両方を渡しています。トラフィック コンバージェンス タイムは障害とデバイス回復の両方について測
定されます。
テスト手順
スーパーバイザ フェールオーバー集約テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
show interface interface および show interface interface counters コマンドを実行して、DUT がテス
ト トラフィックを渡していることを確認します。
ステップ 4
PIM 指定ルータ（DR）の役割も果たしている HSRP アクティブ ルータで障害を発生させます。
ステップ 5
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
ステップ 6
トラフィック ストリームを停止して、再開します。
ステップ 7
障害の発生したデバイスをオンラインに戻します。
ステップ 8
show interface interface および show interface interface counters コマンドを実行して、DUT がテス
ト トラフィックを渡していることを確認します。
ステップ 9
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
ステップ 10
今度は、イベントを強制的に発生させるために reload コマンドを使用して、シナリオを繰り返します。
障害と回復の両方に関するトラフィック コンバージェンス タイムをレポートします。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-7
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• コア スーパーバイザ障害の後にネットワーク コンバージェンスが適切に発生する。
• トラフィック損失が許容基準の範囲内である。
• CPU やメモリに問題が発生しない。
結果
スーパーバイザ フェールオーバー集約テストが失敗しました。検出された障害は CSCsx05365 です。
アクセスでのスーパーバイザ フェールオーバー
このテストでは、システムの安定性に関する機能およびテスト対象デバイスのトラフィック コンバー
ジェンス タイムを検証します。
このテストでは、アクセス レイヤ デバイスで障害が発生します。トラフィック コンバージェンス タイ
ムは障害とデバイス回復の両方について測定されます。
テスト手順
アクセスでのスーパーバイザ フェールオーバー テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
show interface interface および show interface interface counters コマンドを実行して、DUT がテス
ト トラフィックを渡していることを確認します。
ステップ 4
show redundancy state コマンドを実行して、スイッチの冗長ステートを確認します。
ステップ 5
redundancy force-switchover コマンドを実行して、スイッチオーバーを強制的に発生させます。
ステップ 6
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、ダウンタイムを計
算します。
ステップ 7
シナリオを繰り返します。障害と回復の両方に関するトラフィック コンバージェンス タイムをレポー
トします。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
Cisco Data Center Assurance Program（DCAP）6.0
1-8
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
予期される結果
予期されるテスト結果は次のとおりです。
• コア スーパーバイザ障害の後にネットワーク コンバージェンスが適切に発生する。
• トラフィック損失が許容基準の範囲内である。
• CPU やメモリに問題が発生しない。
結果
アクセスでのスーパーバイザ フェールオーバー テストは正常に終了しました。
スーパーバイザ障害コア Rendevous Point（RP; ランデブー ポイント）
このテストでは、システムの安定性に関する機能およびテスト対象デバイスのトラフィック コンバー
ジェンス タイムを検証します。
このテストでは、トラフィックの通過にアクティブに含まれるコア スイッチで障害が発生します。ス
イッチは、マルチキャスト（RP として）およびユニキャスト トラフィックの両方を渡しています。ト
ラフィック コンバージェンス タイムは障害とデバイス回復の両方について測定されます。
テスト手順
スーパーバイザ障害コア RP テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
show interface interface および show interface interface counters コマンドを実行して、DUT がテス
ト トラフィックを渡していることを確認します。
ステップ 4
ランデブー ポイント（RP）で障害を発生させます。
ステップ 5
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
ステップ 6
トラフィック ストリームを停止して、再開します。
ステップ 7
障害の発生したデバイスをオンラインに戻します。
ステップ 8
show interface interface および show interface interface counters コマンドを実行して、DUT がテス
ト トラフィックを渡していることを確認します。
ステップ 9
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
ステップ 10
今度は、イベントを強制的に発生させるために reload コマンドを使用して、シナリオを繰り返します。
障害と回復の両方に関するトラフィック コンバージェンス タイムをレポートします。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-9
第1章
DCAP Catalyst 6500 テスト
ネガティブ
予期される結果
予期されるテスト結果は次のとおりです。
• コア スーパーバイザ障害の後にネットワーク コンバージェンスが適切に発生する。
• トラフィック損失が許容基準の範囲内である。
• CPU やメモリに問題が発生しない。
結果
スーパーバイザ障害コア RP テストは正常に終了しました。
リンク障害
ネガティブなリンク障害テストでは、単発のリンク障害および繰り返し発生するリンク障害にテスト対
象デバイスが正しく対応する機能と能力に焦点を当てています。
ここでは、次の内容について説明します。
• 「dcap-6k-agg-1 と dcap-4k-acc-1 の間の 10G L2 リンクの障害」（P.1-10）
• 「dcap-6k-agg-1 と dcap-6k-acc-1 の間の 10G L2 リンクの障害」（P.1-12）
• 「dcap-6k-agg-2 と dcap-4k-acc-1 の間の 10G L2 リンクの障害」（P.1-13）
• 「dcap-6k-agg-2 と dcap-6k-acc-1 の間の 10G L2 リンクの障害」（P.1-14）
• 「dcap-6k-core-1 と dcap-6k-agg-1 の間の 10G L3 リンクの障害」（P.1-16）
• 「dcap-6k-core-1 と dcap-6k-agg-2 の間の 10G L3 リンクの障害」（P.1-17）
• 「dcap-6k-core-1 と dcap-6k-core-2 の間の 10G L3 リンクの障害」（P.1-18）
• 「dcap-6k-core-2 と dcap-6k-agg-1 の間の 10G L3 リンクの障害」（P.1-20）
• 「dcap-6k-core-2 と dcap-6k-agg-2 の間の 10G L3 リンクの障害」（P.1-21）
• 「dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害」（P.1-22）
• 「dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害」（P.1-24）
• 「dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害」（P.1-26）
• 「dcap-6k-agg-1 と dcap-6k-agg-2 の間の L2 ポートチャネルの障害」（P.1-27）
• 「dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害」（P.1-28）
• 「dcap-6k-agg-1 から dcap-6k-agg-2 への L2 バンドル リンクの障害」（P.1-30）
dcap-6k-agg-1 と dcap-4k-acc-1 の間の 10G L2 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-1 と dcap-4k-acc-1 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
Cisco Data Center Assurance Program（DCAP）6.0
1-10
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
テスト手順
dcap-6k-agg-1 と dcap-4k-acc-1 の間の 10G L2 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te3/1、Te6/2、および Te8/1 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-4k-acc-1 の間を直接通過するか、またはインターフェイス
Te8/1 を経由して通過します。
ステップ 4
dcap-6k-agg-1 で shutdown コマンドを実行して、dcap-6k-agg-1 と dcap-4k-acc-1 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-agg-1 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te3/1、Te6/2、および Te8/1 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-4k-acc-1 の間を直接通過するか、またはインターフェイス
Te8/1 を経由して通過します。
ステップ 9
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-11
第1章
DCAP Catalyst 6500 テスト
ネガティブ
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-1 と dcap-4k-acc-1 の間の 10G L2 リンクの障害テストは正常に終了しました。
dcap-6k-agg-1 と dcap-6k-acc-1 の間の 10G L2 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-1 と dcap-6k-acc-1 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
テスト手順
dcap-6k-agg-1 と dcap-6k-acc-1 の間の 10G L2 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te3/1、Te6/2、および Te1/9 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-6k-acc-1 の間を直接通過するか、またはインターフェイス
Te1/9 を経由して通過します。
ステップ 4
dcap-6k-agg-1 で shutdown コマンドを実行して、dcap-6k-agg-1 と dcap-6k-acc-1 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-agg-1 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te3/1、Te6/2、および Te1/9 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-6k-acc-1 の間を直接通過するか、またはインターフェイス
Te1/9 を経由して通過します。
ステップ 9
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
Cisco Data Center Assurance Program（DCAP）6.0
1-12
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-1 と dcap-6k-acc-1 の間の 10G L2 リンクの障害テストは正常に終了しました。
dcap-6k-agg-2 と dcap-4k-acc-1 の間の 10G L2 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-2 と dcap-4k-acc-1 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
テスト手順
dcap-6k-agg-2 と dcap-4k-acc-1 の間の 10G L2 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te3/1、Te6/2、および Te8/1 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-2 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-2 と dcap-4k-acc-1 の間を直接通過するか、またはインターフェイス
Te8/1 を経由して通過します。
ステップ 4
dcap-6k-agg-2 で shutdown コマンドを実行して、dcap-6k-agg-2 と dcap-4k-acc-1 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-13
第1章
DCAP Catalyst 6500 テスト
ネガティブ
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-agg-2 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te3/1、Te6/2、および Te8/1 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-2 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-2 と dcap-4k-acc-1 の間を直接通過するか、またはインターフェイス
Te8/1 を経由して通過します。
ステップ 9
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-2 と dcap-4k-acc-1 の間の 10G L2 リンクの障害テストは正常に終了しました。
dcap-6k-agg-2 と dcap-6k-acc-1 の間の 10G L2 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-2 と dcap-6k-acc-1 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
Cisco Data Center Assurance Program（DCAP）6.0
1-14
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
テスト手順
dcap-6k-agg-2 と dcap-6k-acc-1 の間の 10G L2 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te3/1、Te6/2、および Te1/9 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-2 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-2 と dcap-6k-acc-1 の間を直接通過するか、またはインターフェイス
Te1/9 を経由して通過します。
ステップ 4
dcap-6k-agg-2 で shutdown コマンドを実行して、dcap-6k-agg-2 と dcap-6k-acc-1 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-agg-2 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te3/1、Te6/2、および Te1/9 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-2 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-2 と dcap-6k-acc-1 の間を直接通過するか、またはインターフェイス
Te1/9 を経由して通過します。
ステップ 9
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-15
第1章
DCAP Catalyst 6500 テスト
ネガティブ
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-2 と dcap-6k-acc-1 の間の 10G L2 リンクの障害テストは正常に終了しました。
dcap-6k-core-1 と dcap-6k-agg-1 の間の 10G L3 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-core-1 と dcap-6k-agg-1 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
テスト手順
dcap-6k-core-1 と dcap-6k-agg-1 の間の 10G L3 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-1 がテスト ト
ラフィックを渡していることを確認します。
トラフィックは、dcap-6k-core-1 と dcap-6k-agg-1 の間を直接通過するか、またはインターフェイス
Te1/1 を経由して通過します。
ステップ 4
dcap-6k-core-1 で shutdown コマンドを実行して、dcap-6k-core-1 と dcap-6k-agg-1 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-core-1 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-1 がテスト ト
ラフィックを渡していることを確認します。
トラフィックは、再び、dcap-6k-core-1 と dcap-6k-agg-1 の間を直接通過するか、またはインターフェ
イス Te1/1 を経由して通過します。
ステップ 9
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
Cisco Data Center Assurance Program（DCAP）6.0
1-16
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-core-1 と dcap-6k-agg-1 の間の 10G L3 リンクの障害テストは正常に終了しました。
dcap-6k-core-1 と dcap-6k-agg-2 の間の 10G L3 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-core-1 と dcap-6k-agg-2 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
テスト手順
dcap-6k-core-1 と dcap-6k-agg-2 の間の 10G L3 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-1 がテスト ト
ラフィックを渡していることを確認します。
トラフィックは、dcap-6k-core-1 と dcap-6k-agg-2 の間を直接通過するか、またはインターフェイス
Te2/2 を経由して通過します。
ステップ 4
dcap-6k-core-1 で shutdown コマンドを実行して、dcap-6k-core-1 と dcap-6k-agg-2 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-17
第1章
DCAP Catalyst 6500 テスト
ネガティブ
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-core-1 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-1 がテスト ト
ラフィックを渡していることを確認します。
トラフィックは、再び、dcap-6k-core-1 と dcap-6k-agg-2 の間を直接通過するか、またはインターフェ
イス Te2/2 を経由して通過します。
ステップ 9
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-core-1 と dcap-6k-agg-2 の間の 10G L3 リンクの障害テストは正常に終了しました。
dcap-6k-core-1 と dcap-6k-core-2 の間の 10G L3 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-core-1 と dcap-6k-core-2 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
Cisco Data Center Assurance Program（DCAP）6.0
1-18
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
テスト手順
dcap-6k-core-1 と dcap-6k-core-2 の間の 10G L3 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-1 がテスト ト
ラフィックを渡していることを確認します。
dcap-6k-core-1 と dcap-6k-core-2 の間を直接通過するか、またはインターフェイス Te1/3 を経由して
通過するトラフィックはありません。
ステップ 4
dcap-6k-core-1 で shutdown コマンドを実行して、dcap-6k-core-1 と dcap-6k-core-2 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-core-1 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-1 がテスト ト
ラフィックを渡していることを確認します。
dcap-6k-core-1 と dcap-6k-core-2 の間を直接通過するか、またはインターフェイス Te1/3 を経由して
通過するトラフィックはありません。
ステップ 9
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-19
第1章
DCAP Catalyst 6500 テスト
ネガティブ
• CPU やメモリに問題が発生しない。
結果
dcap-6k-core-1 と dcap-6k-core-2 の間の 10G L3 リンクの障害テストは正常に終了しました。
dcap-6k-core-2 と dcap-6k-agg-1 の間の 10G L3 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-core-2 と dcap-6k-agg-1 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
テスト手順
dcap-6k-core-2 と dcap-6k-agg-1 の間の 10G L3 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-2 がテスト ト
ラフィックを渡していることを確認します。
トラフィックは、dcap-6k-core-2 と dcap-6k-agg-1 の間を直接通過するか、またはインターフェイス
Te2/2 を経由して通過します。
ステップ 4
dcap-6k-core-2 で shutdown コマンドを実行して、dcap-6k-core-2 と dcap-6k-agg-1 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-core-2 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-2 がテスト ト
ラフィックを渡していることを確認します。
トラフィックは、再び、dcap-6k-core-2 と dcap-6k-agg-1 の間を直接通過するか、またはインターフェ
イス Te2/2 を経由して通過します。
ステップ 9
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
Cisco Data Center Assurance Program（DCAP）6.0
1-20
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-core-2 と dcap-6k-agg-1 の間の 10G L3 リンクの障害テストは正常に終了しました。
dcap-6k-core-2 と dcap-6k-agg-2 の間の 10G L3 リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-core-2 と dcap-6k-agg-2 の間の 10 ギガビット イーサネット リンクは、プロジェクト トラ
フィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。トラ
フィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウンタ
イムを取得するために、シーケンスは 3 回実行されます。
テスト手順
dcap-6k-core-2 と dcap-6k-agg-2 の間の 10G L3 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-2 がテスト ト
ラフィックを渡していることを確認します。
トラフィックは、dcap-6k-core-2 と dcap-6k-agg-2 の間を直接通過するか、またはインターフェイス
Te1/1 を経由して通過します。
ステップ 4
dcap-6k-core-2 で shutdown コマンドを実行して、dcap-6k-core-2 と dcap-6k-agg-2 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-21
第1章
DCAP Catalyst 6500 テスト
ネガティブ
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-core-2 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te1/3、Te2/2、Te1/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-core-2 がテスト ト
ラフィックを渡していることを確認します。
トラフィックは、再び、dcap-6k-core-2 と dcap-6k-agg-2 の間を直接通過するか、またはインターフェ
イス Te1/1 を経由して通過します。
ステップ 9
最も悪いユニキャストおよびマルチキャスト トラフィック ペアの実行に基づいて、トラフィック ダウ
ンタイムを計算します。
関連する OSPF タイマーが 1 秒で設定されている場合、測定されたダウンタイムは 2 秒未満である必要
があります。
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェンスが 2
秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-core-2 と dcap-6k-agg-2 の間の 10G L3 リンクの障害テストは正常に終了しました。
dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-1 と dcap-5k-acc-1 の間にあるポートチャネルのバンドル インターフェイスは、プロジェ
クト トラフィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。
トラフィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウ
ンタイムを取得するために、シーケンスは各バンドル インターフェイスごとに 1 回実行されます。
Cisco Data Center Assurance Program（DCAP）6.0
1-22
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
テスト手順
dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
dcap-6k-agg-1 で show etherchannel summary コマンドを実行し、dcap-5k-acc-1 で show
port-channel summary コマンドを実行して、適切なインターフェイスが正しいポートチャネルにバン
ドルされ、オンラインになっていることを確認します。
dcap-6k-agg-1 で実行したコマンドの出力に、インターフェイス Te2/2 と Te3/4 が Po201 にバンドルさ
れ、オンラインになっていることが示されます。
dcap-5k-acc-1 で実行したコマンドの出力に、インターフェイス Te1/1 と Te1/3 が Po201 にバンドルさ
れ、オンラインになっていることが示されます。
ステップ 4
Te2/2 および Te3/4 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテスト トラ
フィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-5k-acc-1 の間を直接通過するか、またはバンドル インター
フェイス Te2/2 および Te3/4 を経由して通過します。
ステップ 5
dcap-6k-agg-1 で shutdown コマンドを実行して、dcap-6k-agg-1 と dcap-5k-acc-1 の間の 1 番目のバ
ンドル インターフェイスをディセーブルにします。
ステップ 6
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 7
ステップ 8
Ixia トラフィック ストリームを停止して、再開します。
dcap-6k-agg-1 で no shutdown コマンドを実行して、障害の発生したインターフェイスをオンライン
に戻します。
ステップ 9
dcap-6k-agg-1 および dcap-5k-acc-1 で show etherchannel summary コマンドを実行して、適切なイ
ンターフェイスが正しいポートチャネルにバンドルされ、オンラインになっていることを確認します。
dcap-6k-agg-1 で実行したコマンドの出力に、インターフェイス Te2/2 と Te3/4 が Po201 にバンドルさ
れ、オンラインになっていることが示されます。
dcap-5k-acc-1 で実行したコマンドの出力に、インターフェイス Te1/1 と Te1/3 が Po201 にバンドルさ
れ、オンラインになっていることが示されます。
ステップ 10
Te3/1、Te6/2、Te2/2、および Te3/4 インターフェイスで、インターフェイス カウンタを消去してから
show interface interface および show interface interface counters コマンドを実行して、
dcap-6k-agg-1 がテスト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-5k-acc-1 の間を直接通過するか、またはバンドル インター
フェイス Te2/2 および Te3/4 を経由して通過します。
ステップ 11
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-23
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ステップ 12
2 番目のバンドル インターフェイスに対してトラフィック開始、shutdown、no shutdown、トラ
フィック停止のシーケンスをもう 1 回繰り返し、Ixia ツールや CLI コマンドを使用するインターフェ
イスの適切な機能を使用してトラフィック ダウンタイムを分析します。
ステップ 13
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 14
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェ
ンスが 1 秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害テストは正常に終了しました。
dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-2 と dcap-5k-acc-1 の間にあるポートチャネルのバンドル インターフェイスは、プロジェ
クト トラフィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。
トラフィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウ
ンタイムを取得するために、シーケンスは各バンドル インターフェイスごとに 1 回実行されます。
テスト手順
dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
dcap-6k-agg-2 で show etherchannel summary コマンドを実行し、dcap-5k-acc-1 で show
port-channel summary コマンドを実行して、適切なインターフェイスが正しいポートチャネルにバン
ドルされ、オンラインになっていることを確認します。
dcap-6k-agg-2 で実行したコマンドの出力に、インターフェイス Te2/2 と Te3/4 が Po202 にバンドルさ
れ、オンラインになっていることが示されます。
dcap-5k-acc-1 で実行したコマンドの出力に、インターフェイス Te1/2 と Te1/4 が Po202 にバンドルさ
れ、オンラインになっていることが示されます。
Cisco Data Center Assurance Program（DCAP）6.0
1-24
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ステップ 4
Te3/1、Te6/2、Te2/2、および Te3/4 インターフェイスで、インターフェイス カウンタを消去してから
show interface interface および show interface interface counters コマンドを実行して、
dcap-6k-agg-2 がテスト トラフィックを渡していることを確認します。
マルチキャスト トラフィックは、dcap-6k-agg-2 と dcap-5k-acc-1 の間を直接通過するか、またはバン
ドル インターフェイス Te2/2 および Te3/4 を経由して通過します。
ステップ 5
dcap-6k-agg-2 で shutdown コマンドを実行して、dcap-6k-agg-2 と dcap-5k-acc-1 の間の 1 番目のバ
ンドル インターフェイスをディセーブルにします。
ステップ 6
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 7
ステップ 8
Ixia トラフィック ストリームを停止して、再開します。
dcap-6k-agg-2 で no shutdown コマンドを実行して、障害の発生したインターフェイスをオンライン
に戻します。
ステップ 9
dcap-6k-agg-2 で show etherchannel summary コマンドを実行し、dcap-5k-acc-1 で show
port-channel summary コマンドを実行して、適切なインターフェイスが正しいポートチャネルにバン
ドルされ、オンラインになっていることを確認します。
dcap-6k-agg-2 で実行したコマンドの出力に、インターフェイス Te2/2 と Te3/4 が Po202 にバンドルさ
れ、オンラインになっていることが示されます。
dcap-5k-acc-1 で実行したコマンドの出力に、インターフェイス Te1/2 と Te1/4 が Po202 にバンドルさ
れ、オンラインになっていることが示されます。
ステップ 10
Te3/1、Te6/2、Te2/2、および Te3/4 インターフェイスで、インターフェイス カウンタを消去してから
show interface interface および show interface interface counters コマンドを実行して、
dcap-6k-agg-2 がテスト トラフィックを渡していることを確認します。
マルチキャスト トラフィックは、dcap-6k-agg-2 と dcap-5k-acc-1 の間を直接通過するか、またはバン
ドル インターフェイス Te2/2 および Te3/4 を経由して通過します。
ステップ 11
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 12
2 番目のバンドル インターフェイスに対してトラフィック開始、shutdown、no shutdown、トラ
フィック停止のシーケンスをもう 1 回繰り返し、Ixia ツールや CLI コマンドを使用するインターフェ
イスの適切な機能を使用してトラフィック ダウンタイムを分析します。
ステップ 13
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 14
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェ
ンスが 1 秒以内に発生する。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-25
第1章
DCAP Catalyst 6500 テスト
ネガティブ
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 バンドル リンクの障害テストは正常に終了しました。
dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-1 と dcap-5k-acc-1 の間のポートチャネルは、プロジェクト トラフィック プロファイルが
実行している間に、ディセーブルにされ、イネーブルにされます。トラフィック損失は、ディセーブル
イベントとイネーブル イベントの両方で評価されます。平均ダウンタイムを取得するために、シーケ
ンスは 3 回実行されます。
テスト手順
dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te2/2、Te3/4、および Po201 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-5k-acc-1 の間を直接通過するか、またはインターフェイス
Po201 を経由して通過します。
ステップ 4
dcap-6k-agg-1 で shutdown コマンドを実行して、dcap-6k-agg-1 と dcap-5k-acc-1 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-agg-1 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te3/1、Te6/2、および Po202 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-5k-acc-1 の間を直接通過するか、またはインターフェイス
Po202 を経由して通過します。
ステップ 9
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
Cisco Data Center Assurance Program（DCAP）6.0
1-26
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ポートチャネルのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェ
ンスが 2 秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害テストは正常に終了しました。
dcap-6k-agg-1 と dcap-6k-agg-2 の間の L2 ポートチャネルの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-1 と dcap-6k-agg-2 の間のポートチャネルは、プロジェクト トラフィック プロファイルが
実行している間に、ディセーブルにされ、イネーブルにされます。トラフィック損失は、ディセーブル
イベントとイネーブル イベントの両方で評価されます。平均ダウンタイムを取得するために、シーケ
ンスは 3 回実行されます。
テスト手順
dcap-6k-agg-1 と dcap-6k-agg-2 の間の L2 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te1/1、Te2/1、および Po1 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-6k-agg-2 の間を直接通過するか、またはインターフェイス
Po1 を経由して通過します。
ステップ 4
dcap-6k-agg-1 で shutdown コマンドを実行して、dcap-6k-agg-1 と dcap-6k-agg-2 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-27
第1章
DCAP Catalyst 6500 テスト
ネガティブ
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-agg-1 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te1/1、Te2/1、および Po1 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテ
スト トラフィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-6k-agg-2 の間を直接通過するか、またはインターフェイス
Po1 を経由して通過します。
ステップ 9
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ポートチャネルのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェ
ンスが 2 秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-1 と dcap-6k-agg-2 の間の L2 ポートチャネルの障害テストは正常に終了しました。
dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-2 と dcap-5k-acc-1 の間のポートチャネルは、プロジェクト トラフィック プロファイルが
実行している間に、ディセーブルにされ、イネーブルにされます。トラフィック損失は、ディセーブル
イベントとイネーブル イベントの両方で評価されます。平均ダウンタイムを取得するために、シーケ
ンスは 3 回実行されます。
Cisco Data Center Assurance Program（DCAP）6.0
1-28
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
テスト手順
dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
Te2/2、Te3/4、および Po202 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-2 がテ
スト トラフィックを渡していることを確認します。
マルチキャスト トラフィックは、dcap-6k-agg-2 と dcap-5k-acc-1 の間を直接通過するか、またはイン
ターフェイス Po202 を経由して通過します。
ステップ 4
dcap-6k-agg-2 で shutdown コマンドを実行して、dcap-6k-agg-2 と dcap-5k-acc-1 の間のリンクを
ディセーブルにします。
ステップ 5
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 6
Ixia トラフィック ストリームを停止して、再開します。
ステップ 7
dcap-6k-agg-2 で no shutdown コマンドを実行して、障害の発生したリンクをオンラインに戻します。
ステップ 8
Te2/2、Te3/4、および Po202 インターフェイスで、インターフェイス カウンタを消去してから show
interface interface および show interface interface counters コマンドを実行して、dcap-6k-agg-2 がテ
スト トラフィックを渡していることを確認します。
マルチキャスト トラフィックは、dcap-6k-agg-2 と dcap-5k-acc-1 の間を直接通過するか、またはイン
ターフェイス Po202 を経由して通過します。
ステップ 9
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 10
トラフィック開始、shutdown、no shutdown、トラフィック停止のシーケンスをさらに 2 回繰り返し、
1 回ごとに Ixia ツールや CLI コマンドを使用するインターフェイスの適切な機能を使用してトラ
フィック ダウンタイムを分析します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ポートチャネルのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェ
ンスが 2 秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-29
第1章
DCAP Catalyst 6500 テスト
ネガティブ
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-2 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害テストは正常に終了しました。
dcap-6k-agg-1 から dcap-6k-agg-2 への L2 バンドル リンクの障害
このテストでは、テスト対象システムのコンバージェンス動作を検証します。実際のフェールオーバー
（またはコンバージェンス）タイムが、このテストの焦点になります。
dcap-6k-agg-1 と dcap-6k-agg-2 の間にあるポートチャネルのバンドル インターフェイスは、プロジェ
クト トラフィック プロファイルが実行している間に、ディセーブルにされ、イネーブルにされます。
トラフィック損失は、ディセーブル イベントとイネーブル イベントの両方で評価されます。平均ダウ
ンタイムを取得するために、シーケンスは各バンドル インターフェイスごとに 1 回実行されます。
テスト手順
dcap-6k-agg-1 から dcap-6k-agg-2 への L2 バンドル リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia で生成したユニキャストおよびマルチキャスト トラフィック ストリームを開始します。
ステップ 3
dcap-6k-agg-1 および dcap-6k-agg-2 で show etherchannel summary コマンドを実行して、適切なイ
ンターフェイスが正しいポートチャネルにバンドルされ、オンラインになっていることを確認します。
dcap-6k-agg-1 で実行したコマンドの出力に、インターフェイス Te1/1 と Te2/1 が Po1 にバンドルさ
れ、オンラインになっていることが示されます。
dcap-6k-agg-2 で実行したコマンドの出力に、インターフェイス Te1/1 と Te2/1 が Po1 にバンドルさ
れ、オンラインになっていることが示されます。
ステップ 4
Te1/1 および Te2/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテスト トラ
フィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-6k-agg-2 の間を直接通過するか、またはバンドル インター
フェイス Te1/1 および Te2/1 を経由して通過します。
ステップ 5
dcap-6k-agg-1 で shutdown コマンドを実行して、dcap-6k-agg-1 と dcap-6k-agg-2 の間の 1 番目のバ
ンドル インターフェイスをディセーブルにします。
ステップ 6
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 7
ステップ 8
Ixia トラフィック ストリームを停止して、再開します。
dcap-6k-agg-1 で no shutdown コマンドを実行して、障害の発生したインターフェイスをオンライン
に戻します。
ステップ 9
dcap-6k-agg-1 および dcap-6k-agg-2 で show etherchannel summary コマンドを実行して、適切なイ
ンターフェイスが正しいポートチャネルにバンドルされ、オンラインになっていることを確認します。
dcap-6k-agg-1 で実行したコマンドの出力に、インターフェイス Te1/1 と Te2/1 が Po1 にバンドルさ
れ、オンラインになっていることが示されます。
Cisco Data Center Assurance Program（DCAP）6.0
1-30
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第1章
DCAP Catalyst 6500 テスト
ネガティブ
dcap-6k-agg-2 で実行したコマンドの出力に、インターフェイス Te1/1 と Te2/1 が Po1 にバンドルさ
れ、オンラインになっていることが示されます。
ステップ 10
Te1/1 および Te2/1 インターフェイスで、インターフェイス カウンタを消去してから show interface
interface および show interface interface counters コマンドを実行して、dcap-6k-agg-1 がテスト トラ
フィックを渡していることを確認します。
トラフィックは、dcap-6k-agg-1 と dcap-6k-agg-2 の間を直接通過するか、またはバンドル インター
フェイス Te1/1 および Te2/1 を経由して通過します。
ステップ 11
Ixia インターフェイスで示されたとおりに、最も悪いユニキャストおよびマルチキャスト トラフィッ
ク ペアの実行に基づいて、トラフィック ダウンタイムを計算します。
高速スパンニング ツリー プロトコルが使用されている場合、測定されたダウンタイムは 2 秒未満であ
る必要があります。
ステップ 12
2 番目のバンドル インターフェイスに対してトラフィック開始、shutdown、no shutdown、トラ
フィック停止のシーケンスをもう 1 回繰り返し、Ixia ツールや CLI コマンドを使用するインターフェ
イスの適切な機能を使用してトラフィック ダウンタイムを分析します。
ステップ 13
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 14
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのディセーブルまたはイネーブル イベントに応じて、ネットワーク コンバージェ
ンスが 1 秒以内に発生する。
• フラップされたインターフェイスが、再度イネーブルにされた後、再びトラフィックを正しく渡す
ようになる。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-agg-1 から dcap-6k-agg-2 への L2 バンドル リンクの障害テストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
1-31
第1章
DCAP Catalyst 6500 テスト
ネガティブ
Cisco Data Center Assurance Program（DCAP）6.0
1-32
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
C H A P T E R
2
DCAP Nexus 7000 テスト
Data Center Assurance Program（DCAP）のベース ラボ トポロジは、次のセクションに定義されてお
り、テスト トポロジに図示されています。
ラボに設定されているエンタープライズ ネットワーク環境には、次のハードウェアおよびイメージが
含まれています。
テストに使用されるイメージ
• NX-OS 4.0(4) を実行している Nexus 7000
• Native IOS 12.2(33)SXH3a を実行している Catalyst 6500
• NX-OS 4.0(1a)N1(1) を実行している Nexus 5000
• Native IOS 12.2(46)SG を実行している Catalyst 4948-10G
設定例
Device Under Test（DUT; テスト対象デバイス）のトポロジ コンフィギュレーションの一覧について
は、
『Cisco Data Center Assurance Program（DCAP）6.0 第 3 巻：コンフィギュレーション』を参照し
てください。
テスト結果の要約
表 2-1（P.2-2）に、完了したすべてのテスト結果を示します。表 2-1（P.2-2）には、テストされた
フィーチャまたは機能、そのフィーチャまたは機能が属するフィーチャ セットについて説明している
セクション、各フィーチャまたは機能のコンポーネント テスト、および Safe Harbor テスト中に検出さ
れた関連バグが記載されています。
（注）
テスト結果は、対象テクノロジーおよびテストが行われた実際のシナリオに固有のものです。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-1
第2章
DCAP Nexus 7000 テスト
テスト結果の要約
表 2-1
DCAP Nexus 7000 のテスト結果の要約
テスト スイート
「ベースライン」
（P.2-6）
フィーチャ / 機能
「機能」（P.2-6）
テスト
結果
1. dcap-7k-agg-1 に対する連続的な IGMP Join および
Leave
CSCsx03783
2. IGMP ソース オンリー フラッディング
3. Nexus 7000 の OSPF データベースの検証
4. Nexus 7000 の OSPF NSSA 動作の検証
5. ポート セキュリティ機能の動作の検証
6. スパニング ツリー BPDU フィルタ機能の動作の検証
7. スパニング ツリー BPDU ガード機能の動作の検証
8. スパニング ツリー ループ ガード機能の動作の検証
9. スパニング ツリー PortFast 機能の動作の検証
「ベースライン」
（P.2-6）
「定常ステート」
（P.2-16）
1. ベースライン定常ステート
「ベースライン」
（P.2-6）
「システム管理」
（P.2-18）
1. Catalyst 4948-10G のアップグレード
2. CLI を使用した Nexus 5000 のダウングレード
CSCsv31204
CSCsu66282
3. CLI を使用した Nexus 5000 のアップグレード
4. CLI を使用した Nexus 7000 アクセス ISSU のダウング
レード
5. CLI を使用した Nexus 7000 アクセス ISSU のアップグ
レード
6. CLI を使用した Nexus 7000 アグリゲーション ISSU の
アップグレード
7. CLI を使用した Nexus 7000 ISSU コアのアップグレー
ド
8. Nexus 7000 プロセス再起動性
9. SSHv2 ログインの繰り返し
10. Telnet ログインの繰り返し
11. SNMP MIB ウォーク
「ベースライン」
（P.2-6）
「トラフィック処理」
（P.2-29）
1. Nexus 7000 のハードウェア レート リミッタ
2. dcap-4k-acc-2 での各種フレーム サイズの処理の検証
3. dcap-7k-acc-1 での各種フレーム サイズの処理の検証
4. dcap-5k-acc-1 での各種フレーム サイズの処理の検証
5. Nexus 7000 の uRPF の検証
Cisco Data Center Assurance Program（DCAP）6.0
2-2
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
テスト結果の要約
表 2-1
テスト スイート
「ネガティブ」
（P.2-34）
DCAP Nexus 7000 のテスト結果の要約 （続き）
フィーチャ / 機能
「ハードウェア障害」
（P.2-34）
テスト
結果
1. dcap-7k-acc-1 でのアクティブ スーパーバイザ障害
CSCsx24076
CSCsx15006
2. dcap-7k-agg-1 でのアクティブ スーパーバイザ障害
3. dcap-7k-core-1 でのアクティブ スーパーバイザ障害
4. dcap-7k-acc-1 でのラインカード障害
5. dcap-7k-agg-1 でのラインカード障害
6. dcap-7k-core-1 でのラインカード障害
7. dcap-7k-acc-1 でのラインカード フラップの繰り返し
8. dcap-7k-agg-1 での電源モジュール障害
9. dcap-7k-agg-1 でのスパイン カード障害
10. dcap-7k-agg-1 でのスタンバイ スーパーバイザ障害
11. dcap-7k-agg-1 でのシステム障害
12. dcap-7k-core-1 でのシステム障害
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-3
第2章
DCAP Nexus 7000 テスト
テスト結果の要約
表 2-1
DCAP Nexus 7000 のテスト結果の要約 （続き）
テスト スイート
「ネガティブ」
（P.2-34）
フィーチャ / 機能
「リンク障害」（P.2-51）
テスト
結果
1. dcap-7k-agg-2 と dcap-4k-acc-2 の間の 10G L2 リンク
CSCsu66282
の障害
2. dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 リンクの障害
3. dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネ
ルの障害
4. dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 ポートチャネ
ルの障害
5. dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 ポートチャネ
ルの障害
6. dcap-7k-agg-1 と dcap-7k-agg-2 の間の L2 ポートチャ
ネルの障害
7. dcap-7k-agg-2 と dcap-7k-acc-1 の間の L2 ポートチャネ
ルの障害
8. dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リ
ンクの障害
9. dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 バンドル リ
ンクの障害
10. dcap-7k-core-1 と dcap-7k-core-2 の間の L3 バンドル リ
ンクの障害
11. dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 バンドル リ
ンクの障害
12. dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 バンドル リ
ンクの障害
13. dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 ポートチャ
ネルの障害
14. dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 ポートチャ
ネルの障害
15. dcap-7k-core-1 と dcap-7k-core-2 の間の L3 ポートチャ
ネルの障害
16. dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 ポートチャ
ネルの障害
17. dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 ポートチャ
ネルの障害
18. dcap-7k-agg-1 と dcap-5k-acc-1 の間のレイヤ 2 バンド
ル リンクの障害
19. dcap-7k-agg-1 と dcap-6k-acc-1 の間のレイヤ 2 バンド
ル リンクの障害
20. dcap-7k-agg-1 と dcap-7k-acc-1 の間のレイヤ 2 バンド
ル リンクの障害
Cisco Data Center Assurance Program（DCAP）6.0
2-4
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
テスト結果の要約
表 2-1
テスト スイート
「ネガティブ」
（P.2-34）
DCAP Nexus 7000 のテスト結果の要約 （続き）
フィーチャ / 機能
「リンク障害」（P.2-51）
テスト
結果
21. dcap-7k-agg-1 と dcap-7k-agg-2 の間のレイヤ 2 バンド
CSCsu66282
ル リンクの障害
22. dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 バンドル リ
ンクのフラップの繰り返し
23. dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リ
ンクのフラップの繰り返し
24. dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 バンドル リ
ンクのフラップの繰り返し
25. dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 バンドル リ
ンクのフラップの繰り返し
26. dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 チャネルのフ
ラップの繰り返し
27. dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 チャネルのフ
ラップの繰り返し
28. dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 チャネルのフ
ラップの繰り返し
29. dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リ
ンクのフラップの繰り返し
30. dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 チャネルの
フラップの繰り返し
「ネガティブ」
（P.2-34）
「システム イベント」
（P.2-113）
1. dcap-4k-acc-2 でのラント フレームまたはジャイアント
フレームの処理
2. dcap-5k-acc-1 でのラント フレームまたはジャイアント
フレームの処理
3. dcap-6k-acc-1 でのラント フレームまたはジャイアント
フレームの処理
4. dcap-7k-acc-1 でのラント フレームまたはジャイアント
フレームの処理
5. 異常な SNMP プロトコル テスト
6. SSHv2 ログイン失敗試行の繰り返し
7. Telnet ログイン失敗試行の繰り返し
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-5
第2章
DCAP Nexus 7000 テスト
テスト ケース
テスト ケース
この DCAP リリースに対してテストされている、グローバル企業にとって重要な機能については、次
のセクションで説明します。
• 「ベースライン」（P.2-6）
• 「ネガティブ」（P.2-34）
ベースライン
ベースライン テストでは、テスト開始前にネットワークが正常に稼動していることを確認し、定常ス
テートでのネットワーク パフォーマンスを定量化します。
ここでは、次の内容について説明します。
• 「機能」（P.2-6）
• 「定常ステート」（P.2-16）
• 「システム管理」（P.2-18）
• 「トラフィック処理」（P.2-29）
機能
ベースライン機能テストでは、ネットワークのさまざまな側面を検証します。
ここでは、次の内容について説明します。
• 「dcap-7k-agg-1 に対する連続的な IGMP Join および Leave」（P.2-6）
• 「IGMP ソース オンリー フラッディング」（P.2-7）
• 「Nexus 7000 の OSPF データベースの検証」（P.2-8）
• 「Nexus 7000 の OSPF NSSA 動作の検証」（P.2-10）
• 「ポート セキュリティ機能の動作の検証」（P.2-11）
• 「スパニング ツリー BPDU フィルタ機能の動作の検証」（P.2-12）
• 「スパニング ツリー BPDU ガード機能の動作の検証」（P.2-13）
• 「スパニング ツリー ループ ガード機能の動作の検証」（P.2-14）
• 「スパニング ツリー PortFast 機能の動作の検証」（P.2-15）
dcap-7k-agg-1 に対する連続的な IGMP Join および Leave
このテストでは、Internet Group Management Protocol（IGMP; インターネット グループ管理プロトコ
ル）の Join および Leave を Nexus 7000 スイッチに対して 1,000 pps で送信します。Join および Leave
は 100 個のホストから送信します。ixia ストリームを設定して、まず Join を送信し、次に Leave を送
信します。これを 12 時間繰り返します。
Cisco Data Center Assurance Program（DCAP）6.0
2-6
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
テスト手順
dcap-7k-agg-1 に対する連続的な IGMP Join および Leave テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
通常のトラフィック プロファイルに加えて 25 個のホストをシミュレートしているため、L2 ポートの
ポート セキュリティ設定を一時的に増やして、MAC アドレスが 10 個という現在の設定より多く許可
されるようにします。個数を 30 に変更します。
ステップ 3
Join と Leave を送信する ixia ストリームを開始します。
ステップ 4
ストリームを開始したら、show ip igmp interface vlanvlan コマンドを使用して、Join がアグリゲー
ション スイッチによって正しく認識されているかどうかを確認します。
ステップ 5
12 時間のストリーム送信が完了したら、ポート セキュリティ コンフィギュレーションをベースライン
に戻します。まず、clear port-security dynamic interface interface を使用して、ダイナミック ポート
セキュリティ アドレスをクリアします。
ステップ 6
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 7
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 に対する連続的な IGMP Join および Leave テストは正常に終了しました。
IGMP ソース オンリー フラッディング
このテストでは、IGMP スヌーピング用に構成されたスイッチのソース オンリー動作を検証します。
デフォルトで、スイッチの IGMP フラッディングはイネーブルです。つまり、トラフィックが開始さ
れると、短時間のうちに送信元の トラフィックが送信側 VLAN でフラッディングする可能性がありま
す。このテストでは、ソース オンリーのマルチキャスト トラフィックが開始されたときに、同じ
VLAN に対するフラッディングがわずかの間しか発生しないことを確認します。
テスト手順
IGMP ソース オンリー フラッディング テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
clear counter コマンドを発行して、スイッチのカウンタをクリアします。
ステップ 3
IGMP スヌーピング用に構成された各 L2 スイッチに直接接続されているホストから、ソース オンリー
マルチキャスト トラフィックの送信を開始します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-7
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 4
両方のポートが Vlan1133（受信 VLAN）のフォワーディングを行っていることを確認します。
ステップ 5
送信元と同じ VLAN のポートのカウンタをチェックして、開始直後にフラッディングしたトラフィッ
クがあった場合でも、その量が少なかったことを確認します。これらのポートに対するトラフィックの
フラッディングは、継続的に発生してはいけません。
（注）
SafeHarber テスト計画より、SO vlan にはレシーバーがあってはいけないと思われます。ま
た、トラフィックが実際にレシーバー宛に送信されているかどうかの確認も必要です。
ステップ 6
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 7
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• IGMP スヌーピングがイネーブルの状態でソース オンリー トラフィックが開始されると、トラ
フィックがわずかの間フラッディングする。
• CPU やメモリに問題が発生しない。
結果
IGMP ソース オンリー フラッディング テストは正常に終了しました。
Nexus 7000 の OSPF データベースの検証
このテストでは、Open Shortest Path First（OSPF）トポロジ データベース機能が正しく動作すること
を確認します。OSPF データベースには、ルータで生成された Link State Advertisement（LSA; リンク
ステート アドバタイズメント）およびネイバーから学習した LSA が含まれています。このテストで
は、LSA のタイプ 1 ～ 5 を検証します。
テスト手順
Nexus 7000 の OSPF データベースの検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show ip ospf interface、show ip interface、および show running-configuration | begin "router ospf
process-id" の各コマンドを使用して、ネットワーク内の各ルータ、および各テスト デバイスから、
OSPF インターフェイスと実行中の OSPF プロセスに関する情報を収集します。
ステップ 3
show ip ospf database database-summary コマンドおよび show ip ospf database コマンドを使用し
て、ネットワーク内の各 Area Border Router（ABR; エリア ボーダ ルータ）から、エリアごとに維持
されている OSPF データベースに関する情報を収集します。
ステップ 4
ルータ LSA を検証します。エリアごとに、そのエリアのルータにつきルータ LSA が 1 つデータベース
にあることを確認します。エリアごとにルータの数をカウントし、データベース サマリーと一致する
ことを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-8
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 5
ネットワーク LSA を検証します。OSPF ルータが複数存在するマルチアクセス ネットワークごとに、
Designated Router（DR; 指定ルータ）および Backup Designated Router（BDR; バックアップ指定ルー
タ）が選択され、DR でこのサブネットのネットワーク LSA が生成されます。ただし、他の OSPF
ルータがないマルチアクセス ネットワークへのインターフェイスを持つ OSPF ルータは DR として表
示されますが、サブネット上に OSPF ルータが他にないため、ネットワーク LSA は生成されません。
このため、生成されたネットワーク LSA を持つ必要があるマルチアクセス サブネットがいずれである
かを判断するには、サブネットに BDR が存在しているかどうかを確認します。show ip ospf interface
の出力で、エリアごとに、各 BDR インターフェイスにつきネットワーク LSA が 1 つあることを確認
します。
ステップ 6
エリアごとに、データベース サマリーのサマリー ネットワーク LSA カウントを検証します。エリアご
とに、DR インターフェイスとループバック インターフェイス 。[*] の数をカウントします。これら
は、show ip ospf interface の出力で up/up ステートになっています。次に、ルータの設定でセカンダリ
IP アドレスを探します。セカンダリ IP ネットワークの数をカウントし、それを先の合計に加算しま
す。次に、ルータの設定でパッシブ インターフェイスを探します。同じインターフェイス上でパッシ
ブである複数のルータが、いずれも DR として示されます。つまり、このネットワークは 1 回だけカウ
ントされるべきであるが、複数回カウントされていることを示しています。したがって、同じネット
ワーク上の重複している DR を合計から引きます。また、エニーキャスト コンフィギュレーションで
は、複数のルータが同じループバック アドレスを共有する必要があります。各ループバックはすでに
カウントされていますが、全体で 1 つのネットワークを表します。したがって、重複するループバック
ネットワークを合計から引きます。この結果、エリアごとのネットワークの数が得られます。必要な計
算はもう 1 つあります。これらのネットワークそれぞれについて、ネットワーク サマリー LSA が
ABR によって生成されます。エリア X とエリア Y の間の ABR が Y に、各ネットワークのネットワー
ク サマリー LSA が X に、各ネットワーク サマリーのネットワーク サマリー LSA が X に、それぞれ
生成されます。エリア X とエリア Y の間のすべての ABR でこの処理が行われます。サマリー ネット
ワーク LSA の数が、（その他の各エリアのネットワーク カウントの合計）×（このようなルータをこ
のエリアにアドバタイズする ABR の数）になっていることを、エリアごとに確認します。
ステップ 7
サマリー Autonomous System Boundary Router（ASBR; 自律システム境界ルータ）を検証します。
ASBR は、再配布またはルータ OSPF コンフィギュレーションに基づくデフォルト情報を持ちます。
エリア X とエリア Y の間の ABR は、Y に存在する ASBR のサマリー ASBR を X に生成します。た
だし、ASBR である ABR は、ABR 自体をアドバタイズしません。
ステップ 8
外部 LSA を検証します。OSPF に再配布される各外部ルートの外部 LSA を検証します。
ステップ 9
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 10
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• 使用されているトポロジについて各種 LSA の数が OSPF データベースに正しく入力されている。
• CPU やメモリに問題が発生しない。
結果
Nexus 7000 の OSPF データベースの検証テストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-9
第2章
DCAP Nexus 7000 テスト
ベースライン
Nexus 7000 の OSPF NSSA 動作の検証
このテストでは、OSPF Not-So-Stubby-Areas（NSSA）機能が正しく動作することを確認します。
NSSA は独自仕様ではない機能拡張であり、既存のスタブ エリア機能を拡張します。この機能を使用
すると、制限のある形式で外部ルートをスタブ エリアに注入できます。
NSSA エリアへの再配布により、タイプ 7 として知られている特別なタイプのリンク ステート アドバ
タイズメント（LSA）が作成されます。タイプ 7 は、NSSA エリアにだけ存在できます。NSSA 自律
システム境界ルータ（ASBR）によってこの LSA が生成され、NSSA エリア ボーダ ルータ（ABR）に
よってこの LSA がタイプ 5 LSA に変換されます。その後、この LSA は OSPF ドメインに伝播されま
す。ネットワーク ダイアグラムには、この原則が反映されています。
テスト手順
Nexus 7000 の OSPF NSSA 動作の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
ネットワーク内のルータごと、およびテスト デバイスごとに、show running-configuration | begin
"router ospf process-id" コマンドを使用して、OSPF コンフィギュレーションを収集します。
ステップ 3
NSSA エリア内のアグリゲーション ルータごとに、sh ip ospf database external コマンドを使用して、
タイプ 5 LSA がないことを確認します。
ステップ 4
show ip ospf database nssa-external コマンドを使用して、コア ABR によって注入されたデフォルト
のルートが、両方のアグリゲーション ルータによってタイプ 7 LSA として認識されていることを確認
します。
ステップ 5
バックボーン エリア（0）のリンクに障害を発生させます。dcap-7k-core-1 とその OSPF ピア
（Ethernet1/10）を、shutdown コマンドを使用してシャットダウンします。
ステップ 6
正しい LSA が dcap-7k-core-1 によって送信されたこと、および OSPF データベースとトポロジに含ま
れるすべての OSPF ルータのルーティング テーブルからこのリンクが削除されたことを確認します。
show ip ospf database | include network コマンドと show ip route network コマンドを使用します。
ステップ 7
no shutdown コマンドを使用して、dcap-7k-core-1 上のリンクを復元します。
ステップ 8
正しい LSA が dcap-7k-core-1 によって送信されたこと、および OSPF データベースとトポロジに含ま
れるすべての OSPF ルータのルーティング テーブルにこのリンクが再度追加されたことを確認します。
show ip ospf database | include network コマンドと show ip route network コマンドを使用します。
ステップ 9
次に、アグリゲーション ルータとのリンクをシャットダウンするときに、正しい LSA が送出されるこ
と、およびルートがルーティング テーブルから正しく削除されることを確認します。シャットダウン
するリンクは、dcap-7k-agg-1 のインターフェイス vlan 500 です。これを行う前に、アグリゲーション
ルータから取得したルータ LSA カウントをすべての OSPF ルータについて確認すること、およびこの
ネットワークのルーティング テーブル エントリを確認することが必要です。これを行うには、show ip
ospf database router area area-id コマンドと show ip route network コマンドを使用します。
ステップ 10
インターフェイス コンフィギュレーション モードで shutdown コマンドを使用して、dcap-7k-agg-1
のインターフェイス vlan 500 をシャットダウンします。
ステップ 11
正しい LSA が送出されたこと、およびルーティング テーブルからルートが正しく削除されたことを確
認します。この確認にも、show ip ospf database router area area-id コマンドと show ip route
network コマンドを使用します。リンクがシャットダウンされたルータの LSA カウントが 1 だけ減少
すれば正常です。また、このネットワークへのパスが dcap-7k-agg-1 ルータ経由だった場合は、そのパ
スがルーティング テーブルから削除されていれば正常です。
ステップ 12
次に、dcap-7k-agg-1 ルータのインターフェイスを元に戻します。
Cisco Data Center Assurance Program（DCAP）6.0
2-10
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 13
dcap-7k-agg-1 の LSA カウントが 1 だけ増え、他のルータからこのネットワークへのパスがこのルー
タ経由で再び認識できることを確認します。
ステップ 14
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 15
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• NSSA 機能が仕様どおりに動作する。
• リンクに障害が発生した場合に、正しい LSA がルータにより送信され、他の各 OSPF ルータの
データベースが正しく更新される。
• CPU やメモリに問題が発生しない。
結果
Nexus 7000 の OSPF NSSA 動作の検証テストは正常に終了しました。
ポート セキュリティ機能の動作の検証
このテストでは、ポート セキュリティが設定されているインターフェイスが、設定された数の MAC
アドレスからのトラフィックだけを許可すること、および設定された数を超えた場合に err-disabled ス
テートになることを確認します。
テスト手順
ポート セキュリティ機能の動作の検証テストの実行手順は次のとおりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ポート セキュリティがアクセスレイヤ スイッチに v を使用して設定されていることを確認します
（Catalyst 4000、Catalyst 6000、Nexus 7000）。
ステップ 3
すべてのポートについて、アドレス数の上限は 10 個に設定されています。10 個以下の送信元 MAC ア
ドレスを使用してトラフィックを各スイッチポートに送信するように ixia を構成します。
ステップ 4
トラフィックが宛先ポートで受信されること、およびインターフェイスがまだアップになっていること
を確認します。
ステップ 5
各 ixia ストリームの送信元 MAC アドレス カウントを 11 個に増やします。
ステップ 6
ポートが err-disabled ステートに移行し、トラフィックが伝送されないことを確認します。
ステップ 7
10 個の送信元 MAC アドレスを使用して送信するように ixia を再設定します。
ステップ 8
各スイッチポートに対して shutdown コマンドと no shutdown コマンドを発行して、接続を復元しま
す。
ステップ 9
show interface interface コマンドを使用してインターフェイスのステータスを確認し、show
port-security interface interface コマンドを使用してポート セキュリティ ステータスを確認します。
また、宛先の ixia ポートでトラフィックが受信されていることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-11
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 10
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 11
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ポートで学習された送信元 MAC アドレス数が、設定された上限値を超えると、ポートが
err-disabled ステートに移行する。
• CPU やメモリに問題が発生しない。
結果
ポート セキュリティ機能の動作の検証テストは正常に終了しましたが、例外が発生しました。検出さ
れた例外は CSCsx03783 です。
スパニング ツリー BPDU フィルタ機能の動作の検証
このテストでは、Bridge Protocol Data Unit（BPDU; ブリッジ プロトコル データ ユニット）フィルタ
リングが設定されているインターフェイスが BPDU を送信しないことを確認します。BPDU フィルタ
リングを使用すると、エンド システムに接続された PortFast 対応ポートで BPDU の送信を回避できま
す。
テスト手順
スパニング ツリー BPDU フィルタ機能の動作の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセスレイヤ ポートごとに PortFast BPDU フィルタを設定します。
ステップ 3
DUT に接続される別のスイッチでデバッグ コマンド debug spanning-tree bpdu receive を実行しま
す。
ステップ 4
各 DUT スイッチポートで shutdown、no shutdown の順に実行して、ポートがオンラインになったとき
に BPDU フレームが送出されないようにします。
ステップ 5
機能を検証した後、コンフィギュレーションを削除して、システムをテスト前の設定に戻します。
ステップ 6
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 7
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• 各アクセスレイヤ ポートで BPDU フィルタが構成されると、BPDU フレームの送信が停止する。
Cisco Data Center Assurance Program（DCAP）6.0
2-12
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
• CPU やメモリに問題が発生しない。
結果
スパニング ツリー BPDU フィルタ機能の動作の検証テストは正常に終了しました。
スパニング ツリー BPDU ガード機能の動作の検証
このテストでは、BPDU ガードが設定されているインターフェイスが、BPDU を受信すると
err-disabled ステートに移行することを確認します。スパニング ツリー BPDU ガードを使用すると、
ポートがスパニング ツリー PortFast に設定されている場合に、レイヤ 2 ループに保護レイヤが追加さ
れます。スパニング ツリー PortFast は、トランク リンクに対してはサポートされません。また、
VLAN に対してスパニング ツリーがディセーブルになっている場合もサポートされません。
BPDU は、各アクセス デバイス（dcap-7k-acc-1、dcap-5k-acc-1、dcap-4k-acc-2）の forwarding ス
テートのインターフェイス宛に送信されます。各インターフェイスをチェックし、BPDU の受信時に
err-disabled ステートになることを確認します。
テスト手順
スパニング ツリー BPDU ガード機能の動作の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
DUT スイッチポート上でのスパニング ツリー BPDU フィルタリングをディセーブルにして、BPDU
フレームが受信されるようにします。これは、BPDU ガード機能をテストするために必要です。イン
ターフェイス コンフィギュレーション モードで spanning-tree bpdufilter disable コマンドを発行しま
す。
ステップ 3
show spanning-tree vlanvlaninterface interface detail コマンドを発行して、各インターフェイスで
BPDU ガードがイネーブルになっていることを確認します。DCAP テスト ネットワークのデフォルト
コンフィギュレーションでは、BPDU ガードはイネーブルです。
ステップ 4
show interface trunk コマンドと show spanning-tree vlanvlandetail コマンドを発行して、各 VLAN
をサポートしているポートチャネル インターフェイスで BPDU ガードがイネーブルになっていないこ
とを確認します。show spanning-tree vlanvlandetail の出力で、ポートチャネル上の各 VLAN を許可
していると表示されるインターフェイスで、BPDU ガードがイネーブルになっていなければ正常です。
ステップ 5
show interface interface コマンドを発行して、各インターフェイスがイネーブルになっていることを
確認します。各インターフェイスのステータスが not-trunking で、対応する各 VLAN が forwarding ス
テートになっていれば正常です。
ステップ 6
terminal monitor コマンドを発行して、各アクセス レイヤ デバイスへのロギングをイネーブルにしま
す。
ステップ 7
spanning-tree bpdufilter disable コマンドを使用して、リモート スイッチの BPDU フィルタをディ
セーブルにし、BPDU フレームを別のスイッチから各アクセスレイヤ ポートに送信します。
ステップ 8
検出されレポートされた各アクセスレイヤ デバイスが BPDU フレームを受信していることを確認しま
す。DUT のコンソールとシステム ログに %SPANTREE-SP-2-BLOCK_BPDUGUARD メッセージと
%PM-SP-4-ERR_DISABLE メッセージが出力されていれば正常です。
ステップ 9
show interface interface status コマンドを発行して、BPDU フレームの受信後に、各デバイスで受信
インターフェイスが err-disabled ステートになっていることを確認します。
ステップ 10
各インターフェイスで spanning-tree bpdufilter enable コマンドを使用して、リモート スイッチの
BPDU フィルタを再びイネーブルにします。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-13
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 11
shutdown コマンドと no shutdown コマンドを発行して、各インターフェイスをフラップし、
connected ステートに戻します。
ステップ 12
show interface interface status コマンドを発行して、各インターフェイスが connected ステートに
なっていることを確認します。
ステップ 13
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 14
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• スパニング ツリー BPDU パケットを受信すると、BPDU ガードによってポートがディセーブルに
なる。
• CPU やメモリに問題が発生しない。
結果
スパニング ツリー BPDU ガード機能の動作の検証テストは正常に終了しました。
スパニング ツリー ループ ガード機能の動作の検証
ループ ガードは、ブリッジング ループを防ぐのに役立ちます。ブリッジング ループは、ポイントツー
ポイント リンクでの単一方向リンク障害によって発生する可能性があります。このテストでは、代替 /
バックアップ ルート ポートが BPDU を受信するかどうかをループ ガードで設定できるかどうかを確認
します。以前 BPDU を受信していたポートが現在は BPDU を受信していない場合、ポートが BPDU の
受信を再び開始するまで、ループ ガードによってポートが inconsistent ステート（ブロッキング）にな
ります。ポートが BPDU を再び受信すると、ポート / リンクが再び利用可能になったと見なされます。
Spanning-Tree Protocol（STP; スパニング ツリー プロトコル）によってポートの loop-inconsistent 状
態が解消します。このような復元は自動で行われるため、ポートのステートは STP によって設定され
ます。
テスト手順
スパニング ツリー ループ ガード機能の動作の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アグリゲーション スイッチ dcap-7k-agg-2 のすべてのアクセスレイヤ スイッチ アップリンクと非指定
ポートでループ ガードが設定されていることを確認します。show running-configuration interface
interface コマンドの下にリストされている spanning-tree guard loop コマンドを探します。
ステップ 3
dcap-7k-agg-2 へのアップリンク ポートの spanning-tree ステートがブロックされていることを確認し
ます。
ステップ 4
障害をシミュレートするために、アクセスレイヤ ブロッキング ポートへの BPDU の送信を停止する必
要があります。dcap-7k-agg-2 にスパニング ツリー BPDU フィルタを設定します。
ステップ 5
ポートが forwarding ステートに移行するのをループ ガードが阻止していることを示す syslog メッセー
ジに注意します。ループ ガード転送後のポートの STP ステータスを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-14
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 6
ステップ 7
dcap-7k-agg-2 のコンフィギュレーションをベースラインに復元します。
dcap-7k-agg-2 へのアップリンク ポートの spanning-tree ステートが再びブロックされていることを確
認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ループ ガードによって、冗長トポロジ内の STP ブロッキング ポートが誤って forwarding ステート
に移行することが検出され、このポートが forwarding に移行することを防ぐことによって、STP
ループの発生を防ぐ。
• CPU やメモリに問題が発生しない。
結果
スパニング ツリー ループ ガード機能の動作の検証テストは正常に終了しました。
スパニング ツリー PortFast 機能の動作の検証
このテストでは、スパニング ツリー プロトコルの PortFast 機能を検証します。スイッチ ポートにスパ
ニング ツリー PortFast を設定すると、接続時にポートが forwarding ステートに直接移行できるように
なります。通常のスパニング ツリー手順であるリスニング / ラーニングを行う必要がなく、これに伴う
遅延がなくなります。
このテストでは、まず各アクセス スイッチが Spanning Tree Rapid pVST+ で動作していること、およ
び各アクセス ポートが PortFast を使用するよう設定されていることを確認します。アクセス ポートが
フラップされ、スパニング ツリー ステータスがただちに forwarding に移行したかどうかが検証されま
す。そのときに、トラフィックの転送が開始されたかどうかがカウンタをチェックして確認されます。
テスト手順
スパニング ツリー PortFast 機能の動作の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show spanning-tree summary コマンドを発行して、各テスト スイッチで Spanning-Tree Rapid
pVST+ がイネーブルになっていることを確認します。
ステップ 3
show running-config コマンドを発行して、各スイッチのアクセス ポートで PortFast が設定されてい
ることを確認します。ポートの設定が必要な場合、IOS では spanning-tree portfast コマンドを発行
し、NX-OS では spanning-tree port type edge コマンドを発行します。
ステップ 4
テスト トラフィック プロファイルを開始します。
ステップ 5
先に設定したポートに対して shutdown コマンドと clear counters コマンドを発行して、各アクセス
インターフェイスをダウンさせ、カウンタをクリアします。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-15
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 6
次のコマンドを発行して、インターフェイスを 1 つずつアップさせ、それがただちに forwarding ス
テートに戻ることを確認します。
no shutdown
show clock
show spanning-tree interface
interface
show interface
interface
counters
Pause 10s
show clock
show spanning-tree interface
interface
show interface
interface
counters
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• PortFast が設定されたインターフェイスは、アップされるとただちに forwarding ステートに移行
する。
• インターフェイスがアップされた後、トラフィックは予期されたとおりに伝送される。
• CPU やメモリに問題が発生しない。
結果
スパニング ツリー PortFast 機能の動作の検証テストは正常に終了しました。
定常ステート
ベースライン テストでは、テスト開始前にネットワークが正常に稼動していることを確認し、定常ス
テートでのネットワーク パフォーマンスを定量化します。
ここでは、次の内容について説明します。
• 「ベースライン定常ステート」（P.2-16）
ベースライン定常ステート
このテストでは、定常ステート時のネットワーク動作を検証します。すべてのバックグラウンド トラ
フィックとバックグラウンド ルートが実行されているときに、他の影響を受けずネットワークを実行
して、各デバイスのベースラインとなる CPU およびメモリを定量化できます。
また、このテスト ケースでは、テスト トポロジ内で実行されている数多くのプロトコルの機能も検証
できます。対象となるプロトコルは次のとおりです。
Cisco Data Center Assurance Program（DCAP）6.0
2-16
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
• Link Aggregation Control Protocol（LACP）
• Network Time Protocol（NTP; ネットワーク タイム プロトコル）
• Rapid PVST+ Spanning Tree
• Protocol Independent Multicast（PIM）
• Open Shortest Path First （OSPF）
• IEEE 802.1q Trunking
• Multicast Source Discovery Protocol（MSDP）
• Hot Standby Router Protocol（HSRP; ホットスタンバイ ルータ プロトコル）
テスト手順
ベースライン定常ステート テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia テスト ツールを使用してテスト トラフィック プロファイルを開始します。このトラフィックは、
このテスト期間中、継続して実行されます。
ステップ 3
トポロジ内のすべてのデバイスで show port-channel summary コマンドと show etherchannel
summary コマンドを使用して、設定済みのポートチャネルに正しいバンドル インターフェイス セッ
トが指定されていること、および LACP プロトコルが実行されていることを確認します。
ステップ 4
show ntp peer-status コマンドまたは show ntp status コマンドを使用して、トポロジ内の各デバイス
と有効な NTP サーバとの間にピアリングが確立されていることを確認します。
ステップ 5
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメイン内のスイッチ間リンク
が適切な VLAN について正しい spanning-tree ステートになっていることを確認します。
ステップ 6
show ip pim neighbor コマンドを使用して、トポロジ内の適切なデバイス間に正しい PIM ピア関係が
確立されていることを確認します。
ステップ 7
show ip ospf neighbor コマンドを使用して、トポロジ間に正しい近接関係が確立されていることを確
認します。
ステップ 8
show interface interface trunk コマンドを使用して、トポロジのレイヤ 2 ドメイン内のスイッチ間リ
ンクが、正しい VLAN セットをトランキングしていること、および正しいカプセル化方式を使用して
いることを確認します。
ステップ 9
show ip msdp summary コマンドを使用して、dcap-7k-core-1 と dcap-7k-core-2 が MSDP 機能を正し
くピアリングしていることを確認します。
ステップ 10
dcap-7k-agg-1 と dcap-7k-agg-2 に対して show hsrp brief コマンドを使用して、共有 HSRP ゲート
ウェイ コンフィギュレーションが正しいステートになっていることをすべての VLAN について確認し
ます。
ステップ 11
トラフィックを最低でも 60 時間実行し、トポロジがその期間中に 1 つの定常ステートに留まるように
します。
ステップ 12
定常ステートが 60 時間継続したら、テスト トラフィックを停止し、パケット損失を記録します。
ステップ 13
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-17
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 14
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• このテストのアクティビティが原因でネットワークの安定性が損なわれることがない。
• テスト トポロジで使用されているプロトコルが予期されたとおりに機能する。
• CPU やメモリに問題が発生しない。
結果
ベースライン定常ステート テストは正常に終了しました。
システム管理
システム管理のベースライン機能には、アップグレード、ダウングレード、ログイン、SNMP などが
あります。
ここでは、次の内容について説明します。
• 「Catalyst 4948-10G のアップグレード」（P.2-18）
• 「CLI を使用した Nexus 5000 のダウングレード」（P.2-19）
• 「CLI を使用した Nexus 5000 のアップグレード」（P.2-20）
• 「CLI を使用した Nexus 7000 アクセス ISSU のダウングレード」（P.2-21）
• 「CLI を使用した Nexus 7000 アクセス ISSU のアップグレード」（P.2-22）
• 「CLI を使用した Nexus 7000 アグリゲーション ISSU のアップグレード」（P.2-23）
• 「CLI を使用した Nexus 7000 ISSU コアのアップグレード」（P.2-25）
• 「Nexus 7000 プロセス再起動性」（P.2-26）
• 「SSHv2 ログインの繰り返し」（P.2-27）
• 「Telnet ログインの繰り返し」（P.2-28）
• 「SNMP MIB ウォーク」（P.2-29）
Catalyst 4948-10G のアップグレード
このテストでは、コードをテスト対象コードのバージョンにアップグレードする機能を検証します。ア
クセス レイヤ デバイス dcap-4k-acc-1 を 12.2(31)SGA3 Native IOS から 12.2(46)SG Native IOS にアッ
プグレードし、アクセス レイヤのすべてのハードウェアとコンフィギュレーションが問題なくアップ
グレードされることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-18
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
テスト手順
Catalyst 4948-10G のアップグレード テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show clock コマンドを使用して、このテストの開始時刻を記録します。
ステップ 3
show version コマンドを使用して、dcap-4k-acc-1 が古い Native Cisco IOS イメージを実行しているこ
とを確認します。
ステップ 4
dir bootflash: コマンドを使用して、テスト対象イメージが dcap-4k-acc-1 の適切なファイル デバイス
上にあることを確認します。
ステップ 5
dcap-4k-acc-1 で reload コマンドを発行して、システムをリブートします。リロード中に発生したエ
ラー メッセージをレポートします。
ステップ 6
show module コマンドと show version コマンドを使用して、dcap-4k-acc-1 が正常にオンラインに
なったこと、および新しいイメージが実行されていることを確認します。
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• 4948-10GE プラットフォームでの 12.2(31)SGA3 Native IOS から 12.2(46)SG Native IOS への
アップグレードが円滑に行われ、エラーは発生しない。
結果
Catalyst 4948-10G のアップグレード テストは正常に終了しました。
CLI を使用した Nexus 5000 のダウングレード
このテストでは、アクセス スイッチ dcap-5k-acc-1 に対する最新バージョンのコードから以前のバー
ジョンのコードへのコード ダウングレードが正常に行われることを確認します。ユニキャスト トラ
フィックとマルチキャスト トラフィックを双方向で送信し、スイッチでダウングレードを行います。
ダウングレード後、トラフィックがダウングレード前と同様に伝送されることを確認します。すべての
設定と確認には、Command Line Interface（CLI; コマンド ライン インターフェイス）を使用します。
テスト手順
CLI を使用した Nexus 5000 のダウングレード テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセス スイッチ dcap-5k-acc-1 を使用して双方向トラフィックを生成します。show interface
interface counters コマンドを発行して、エラーやパケットの損失がなくトラフィックが双方向で各ア
グリゲーション スイッチに伝送されることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-19
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 3
アクティブ スーパーバイザで show version コマンドと show module コマンドを実行して、現在の
バージョンを確認します。
ステップ 4
デバイスのブートフラッシュに新しいイメージ ファイルをコピーします。
ステップ 5
install all コマンドを実行して、アクセス スイッチの NX-OS コードをダウングレードします。
ステップ 6
アクティブ スーパーバイザで show version、show module、show install all status の各コマンドを実
行して、ダウングレードが成功したこと、および status コマンドの出力に新しいバージョンが反映され
ていることを確認します。
ステップ 7
アクセス スイッチ dcap-5k-acc-1 を使用して双方向トラフィックを生成します。show interface
interface counters コマンドを発行して、エラーやパケットの損失がなくトラフィックが双方向で各ア
グリゲーション スイッチに伝送されることを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アクセス スイッチのダウングレードによりトラフィックが中断される。
• すべてのシステムがこの手順から完全に回復する。
• ダウングレードが成功し、status コマンドにより正しくレポートされる。
• CPU やメモリに問題が発生しない。
結果
CLI を使用した Nexus 5000 のダウングレード テストは失敗しました。検出された障害は CSCsv31204
です。
CLI を使用した Nexus 5000 のアップグレード
このテストでは、使用可能な以前のバージョンのコードからアクセス スイッチ dcap-5k-acc-1 へのコー
ド アップグレードが正常に行われることを確認します。ユニキャスト トラフィックとマルチキャスト
トラフィックを双方向で送信し、スイッチでアップグレードを行います。アップグレード後、トラ
フィックがアップグレード前と同様に伝送されることを確認します。すべての設定と確認には、CLI を
使用します。
テスト手順
CLI を使用した Nexus 5000 のアップグレード テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセス スイッチ dcap-5k-acc-1 を使用して双方向トラフィックを生成します。show interface
interface counters コマンドを発行して、エラーやパケットの損失がなくトラフィックが双方向で各ア
グリゲーション スイッチに伝送されることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-20
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 3
アクティブ スーパーバイザで show version コマンドと show module コマンドを実行して、現在の
バージョンを確認します。
ステップ 4
デバイスのブートフラッシュに新しいイメージ ファイルをコピーします。
ステップ 5
install all コマンドを実行して、アクセス スイッチの NX-OS コードをアップグレードします。
ステップ 6
アクティブ スーパーバイザで show version 、show module、show install all status の各コマンドを実
行して、アップグレードが成功したこと、および status コマンドの出力に新しいバージョンが反映され
ていることを確認します。
ステップ 7
アクセス スイッチ dcap-5k-acc-1 を使用して双方向トラフィックを生成します。show interface
interface counters コマンドを発行して、エラーやパケットの損失がなくトラフィックが双方向で各ア
グリゲーション スイッチに伝送されることを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アクセス スイッチのアップグレードによりトラフィックが中断する。
• すべてのシステムがこの手順から完全に回復する。
• アップグレードが成功し、status コマンドにより正しくレポートされる。
• CPU やメモリに問題が発生しない。
結果
CLI を使用した Nexus 5000 のアップグレード テストは失敗しました。検出された障害は CSCsv31204
です。
CLI を使用した Nexus 7000 アクセス ISSU のダウングレード
このテストでは、アクセス スイッチのコード ダウングレードによって、アクティブなサービスやトラ
フィックに悪影響が及ばないことを確認します。ユニキャスト トラフィックとマルチキャスト トラ
フィックを双方向で送信します。スイッチのアップグレードには ISSU 機能を使用します。すべての設
定と確認には、CLI を使用します。
テスト手順
CLI を使用した Nexus 7000 アクセス ISSU のダウングレード テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセス スイッチ dcap-7k-acc-1 を使用して双方向トラフィックを生成します。show interface
interface コマンドと show interface interface counters コマンドを発行して、エラーやパケットの損失
がなくトラフィックが双方向で各アクセス スイッチに伝送されることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-21
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 3
アクティブ スーパーバイザで show version コマンドと show module コマンドを実行して、現在の
バージョンを確認します。
ステップ 4
デバイスのブートフラッシュに新しいイメージ ファイルをコピーします。
ステップ 5
show install all impact コマンドを発行して、ダウングレードで中断が伴わないことを確認します。
ステップ 6
install all コマンドを実行して、アクセス スイッチの NX-OS コードをアップグレードします。
ステップ 7
アクティブ スーパーバイザで show version、show module、show install all status の各コマンドを実
行して、アップグレードが成功したこと、および status コマンドの出力に新しいバージョンが反映され
ていることを確認します。
/p>
ステップ 8
reload cmp modulemodule コマンドを発行して、Connectivity Management Processor（CMP）ダウン
グレード プロセスを完了します。show version コマンドを発行して、ダウングレードが成功したこと
を確認します。
ステップ 9
トラフィックが損失なく流れていることを確認します。
ステップ 10
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 11
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アクセス スイッチのダウングレードによりトラフィックが中断されない。
• すべてのシステムがこの手順から完全に回復する。
• アップグレードが成功し、status コマンドにより正しくレポートされる。
• CPU やメモリに問題が発生しない。
結果
CLI を使用した Nexus 7000 アクセス ISSU のダウングレード テストは失敗しました。検出された障害
は CSCsx35498 です。
CLI を使用した Nexus 7000 アクセス ISSU のアップグレード
このテストでは、アクセス スイッチのコード アップグレードによって、アクティブなサービスやトラ
フィックに悪影響が及ばないことを確認します。ユニキャスト トラフィックとマルチキャスト トラ
フィックを双方向で送信します。スイッチのアップグレードには ISSU 機能を使用します。すべての設
定と確認には、CLI を使用します。
テスト手順
CLI を使用した Nexus 7000 アクセス ISSU のアップグレード テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
Cisco Data Center Assurance Program（DCAP）6.0
2-22
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 2
アクセス スイッチ dcap-7k-acc-1 を使用して双方向トラフィックを生成します。show interface
interface コマンドと show interface interface counters コマンドを発行して、エラーやパケットの損失
がなくトラフィックが双方向で各アクセス スイッチに伝送されることを確認します。
ステップ 3
アクティブ スーパーバイザで show version コマンドと show module コマンドを実行して、現在の
バージョンを確認します。
ステップ 4
デバイスのブートフラッシュに新しいイメージ ファイルをコピーします。
ステップ 5
show install all impact コマンドを発行して、アップグレードで中断が伴わないことを確認します。
ステップ 6
install all コマンドを実行して、アクセス スイッチの NX-OS コードをアップグレードします。
ステップ 7
アクティブ スーパーバイザで show version 、show module、show install all status の各コマンドを実
行して、アップグレードが成功したこと、および status コマンドの出力に新しいバージョンが反映され
ていることを確認します。
ステップ 8
reload cmp module 5 コマンドと reload cmp module 6 コマンドを発行して、両方のスーパーバイザ
上の CMP をアップグレードします。show version コマンドを発行して、バージョンを確認します。
ステップ 9
トラフィックが損失なく流れていることを確認します。
ステップ 10
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 11
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アクセス スイッチのアップグレードによりトラフィックが中断されない。
• すべてのシステムがこの手順から完全に回復する。
• アップグレードが成功し、status コマンドにより正しくレポートされる。
• CPU やメモリに問題が発生しない。
結果
CLI を使用した Nexus 7000 アクセス ISSU のアップグレード テストは失敗しました。検出された障害
は CSCsx35498 です。
CLI を使用した Nexus 7000 アグリゲーション ISSU のアップグレード
このテストでは、アグリゲーション スイッチのコード アップグレードによって、アクティブなサービ
スやトラフィックに悪影響が及ばないことを確認します。ユニキャスト トラフィックとマルチキャス
ト トラフィックを双方向で送信します。スイッチのアップグレードには ISSU 機能を使用します。PIM
DR としても機能するアクティブな HSRP アグリゲーション スイッチをアップグレードし、ISSU アッ
プグレードで中断が発生しないこと、およびシステムの安定性に影響がないことを確認します。すべて
の設定と確認には、CLI を使用します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-23
第2章
DCAP Nexus 7000 テスト
ベースライン
テスト手順
CLI を使用した Nexus 7000 アグリゲーション ISSU のアップグレード テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アグリゲーション スイッチ dcap-7k-agg-1 を使用して双方向トラフィックを生成します。show
interface interface コマンドと show interface interface counters コマンドを発行して、エラーやパ
ケットの損失がなくトラフィックが双方向で予期されたインターフェイス間を伝送されることを確認し
ます。
ステップ 3
show ip pim neighbor コマンドと show ip ospf neighbors コマンドを発行して、アップグレード前の
PIM ネイバー関係と OSPF ネイバー関係を確認します。
ステップ 4
アクティブ スーパーバイザ上で show version、show module 、show version internal build-identifier
の各コマンドを実行して、現在のバージョンを確認します。
ステップ 5
デバイスのブートフラッシュに新しいイメージ ファイルをコピーします。
ステップ 6
show install all impact コマンドを発行して、アップグレードで中断が伴わないことを確認します。
ステップ 7
install all コマンドを実行して、アクセス スイッチの NX-OS コードをアップグレードします。
ステップ 8
アクティブ スーパーバイザで show version、show module、show version internal build-identifier、
show install all status の各コマンドを実行して、アップグレードが成功したこと、および status コマ
ンドの出力に新しいバージョンが反映されていることを確認します。
ステップ 9
show ip pim neighbor コマンドと show ip ospf neighbors コマンドを発行し、アップグレード前の初
期スナップショットで取得した値と比較して、PIM ネイバー関係と OSPF ネイバー関係の動作時間が
減少していないことを確認します。
ステップ 10
トラフィックが損失なく流れていることを確認します。
ステップ 11
reload cmp module 5 コマンドと reload cmp module 6 コマンドを発行して、両方のスーパーバイザ
上の CMP をアップグレードします。
ステップ 12
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 13
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アグリゲーション スイッチのアップグレードによりトラフィックが中断されない。
• すべてのシステムがこの手順から完全に回復する。
• アップグレードが成功し、status コマンドにより正しくレポートされる。
• アップグレード プロセス中に PIM または OSPF のフラップが発生しない。
• CPU やメモリに問題が発生しない。
Cisco Data Center Assurance Program（DCAP）6.0
2-24
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
結果
CLI を使用した Nexus 7000 アグリゲーション ISSU のアップグレード テストは正常に終了しました、
例外が発生しました。検出された例外は CSCsv49550 です。
CLI を使用した Nexus 7000 ISSU コアのアップグレード
このテストでは、コア スイッチのコード アップグレードによって、アクティブなサービスやトラ
フィックに悪影響が及ばないことを確認します。ユニキャスト トラフィックとマルチキャスト トラ
フィックを双方向で送信します。スイッチのアップグレードには ISSU 機能を使用します。PIM Root
Processor（RP）コア スイッチをアップグレードして、ISSU アップグレードにより中断が発生しない
こと、およびシステムの安定性に影響が及ばないことを確認します。すべての設定と確認には、CLI を
使用します。
テスト手順
CLI を使用した Nexus 7000 ISSU コアのアップグレード テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
コア スイッチ dcap-7k-core-1 を経由する双方向トラフィックを生成します。show interface interface
コマンドと show interface interface counters コマンドを発行して、エラーやパケットの損失がなくト
ラフィックが双方向で予期されたインターフェイス間を伝送されることを確認します。
ステップ 3
show ip pim neighbor コマンドと show ip ospf neighbors コマンドを発行して、アップグレード前の
PIM ネイバー関係と OSPF ネイバー関係を確認します。
ステップ 4
アクティブ スーパーバイザ上で show version、show module 、show version internal build-identifier
の各コマンドを実行して、現在のバージョンを確認します。
ステップ 5
デバイスのブートフラッシュに新しいイメージ ファイルをコピーします。
ステップ 6
show install all impact コマンドを発行して、アップグレードで中断が伴わないことを確認します。
ステップ 7
install all コマンドを実行して、アクセス スイッチの NX-OS コードをアップグレードします。
ステップ 8
アクティブ スーパーバイザで show version 、show module、show install build-identifier、show
install all status の各コマンドを実行して、アップグレードが成功したこと、および status コマンドの
出力に新しいバージョンが反映されていることを確認します。
ステップ 9
show ip pim neighbor コマンドと show ip ospf neighbors コマンドを発行し、アップグレード前の初
期スナップショットで取得した値と比較して、PIM ネイバー関係と OSPF ネイバー関係の動作時間が
減少していないことを確認します。
ステップ 10
トラフィックが損失なく流れていることを確認します。
ステップ 11
reload cmp module 5 コマンドと reload cmp module 6 コマンドを発行して、両方のスーパーバイザ
上の CMP をアップグレードします。
ステップ 12
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 13
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-25
第2章
DCAP Nexus 7000 テスト
ベースライン
予期される結果
予期されるテスト結果は次のとおりです。
• コア スイッチのアップグレードによりトラフィックが中断されない。
• すべてのシステムがこの手順から完全に回復する。
• アップグレードが成功し、status コマンドにより正しくレポートされる。
• アップグレード プロセス中に PIM または OSPF のフラップが発生しない。
• CPU やメモリに問題が発生しない。
結果
CLI を使用した Nexus 7000 ISSU コアのアップグレード テストは失敗しました。検出された障害は
CSCsx35498 です。
Nexus 7000 プロセス再起動性
このテストでは、NX-OS のプロセス再起動性を検証します。
このテストでは、PIM、OSPF、IGMP、MSDP の各プロセスを再起動して、再起動後にネイバー関係
が予期されるとおりに回復することを確認します。
テスト手順
Nexus 7000 プロセス再起動性テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show ip pim neighbor コマンドを発行して、dcap-7k-agg-1 の PIM ネイバーを確認します。
ステップ 3
show processes コマンドを発行して、PIM プロセスの start_count を確認します。
ステップ 4
restart pim コマンドを発行して、PIM プロセスを再起動します。
ステップ 5
show processes コマンドを発行して、PIM プロセスの start_count が 1 だけ増えていることを確認しま
す。
ステップ 6
show ip pim neighbor コマンドを発行して、ネイバー関係が再形成されていることを確認します。
ステップ 7
show ip ospf neighbor コマンドを発行して、dcap-7k-agg-1 の OSPF ネイバーを確認します。
ステップ 8
show processes コマンドを発行して、OSPF プロセスの start_count を確認します。
ステップ 9
restart ospf コマンドを発行して、OSPF プロセスを再起動します。
ステップ 10
show processes コマンドを発行して、OSPF プロセスの start_count が 1 だけ増えていることを確認し
ます。
ステップ 11
show ip ospf neighbor コマンドを発行して、ネイバー関係が再形成されていることを確認します。
ステップ 12
show ip msdp peer コマンドを発行して、dcap-7k-core-1 の MSDP ネイバーを確認します。
ステップ 13
show processes コマンドを発行して、MSDP プロセスの start_count を確認します。
ステップ 14
restart msdp コマンドを発行して、MSDP プロセスを再起動します。
ステップ 15
show processes コマンドを発行して、MSDP プロセスの start_count が 1 だけ増えていることを確認し
ます。
ステップ 16
show ip msdp peer コマンドを発行して、ネイバー関係が再形成されていることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-26
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 17
show ip igmp groups コマンドを発行して、dcap-7k-agg-1 の IGMP グループを確認します。
ステップ 18
show processes コマンドを発行して、IGMP プロセスの start_count を確認します。
ステップ 19
restart igmp コマンドを発行して、MSDP プロセスを再起動します。
ステップ 20
show processes コマンドを発行して、IGMP プロセスの start_count が 1 だけ増えていることを確認し
ます。
ステップ 21
show ip igmp groups コマンドを発行して、dcap-7k-agg-1 の IGMP グループを確認します。
ステップ 22
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 23
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• PIM ネイバー関係がプロセスの再起動後に再形成される。
• MSDP ネイバー関係がプロセスの再起動後に再形成される。
• OSPF ネイバー関係がプロセスの再起動後に再形成される。
• IGMP ネイバー関係がプロセスの再起動後に再形成される。
• CPU やメモリに問題が発生しない。
結果
Nexus 7000 プロセス再起動性テストは失敗しました。検出された障害は CSCsu66282 です。
SSHv2 ログインの繰り返し
このテストでは、dcap-7k-agg-1 に対する Secure Shell（SSH; セキュア シェル）ログインの繰り返し
がメモリやシステムの安定性に影響を与えないことを確認します。DUT の SSH サーバとクライアント
は、両方でサポートしている最新のバージョンにネゴシエートします。スクリプトを使用して、デバイ
スに対する正常な SSHv2 ログインを 1,000 回生成します。CPU とメモリの使用率を追跡し、トラ
フィックを監視して、ログインの繰り返しにより損失がないことを確認します。
テスト手順
SSHv2 ログインの繰り返しテストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
ログインが成功する有効なユーザ名とパスワードの組み合せを使用して、dcap-7k-agg-1 に対する
SSHv2 ログインを 1,000 回繰り返します。
ステップ 3
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-27
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 4
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• すべてのログインが正常に完了する。
• ログインの繰り返しによりトラフィックの損失は発生しない。
• CPU やメモリに問題が発生しない。
結果
SSHv2 ログインの繰り返しテストは正常に終了しました。
Telnet ログインの繰り返し
このテストでは、dcap-7k-agg-2 に対する Telnet ログインの繰り返しがメモリやシステムの安定性に影
響を与えないことを確認します。スクリプトを使用して、デバイスに対する正常な Telnet ログインを
1,000 回生成します。CPU とメモリの使用率を追跡し、トラフィックを監視して、ログインの繰り返
しにより損失がないことを確認します。
テスト手順
Telnet ログインの繰り返しテストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
ログインが成功する有効なユーザ名とパスワードの組み合せを使用して、dcap-7k-agg-2 に対する
Telnet ログインを 1,000 回繰り返します。
ステップ 3
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 4
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• すべてのログインが正常に完了する。
• ログインの繰り返しによりトラフィックの損失は発生しない。
• CPU やメモリに問題が発生しない。
結果
Telnet ログインの繰り返しテストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
2-28
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
SNMP MIB ウォーク
Simple Network Management Protocol（SNMP; 簡易ネットワーク管理プロトコル）は、ネットワーク
管理者が使用するツールとして随所に用意されており、ネットワーク パフォーマンスの管理、ネット
ワーク問題の発見と解決、およびネットワークの拡張計画に使用されます。
このテストでは、テスト対象 NX-OS バージョンの MIB に対する SNMP ウォークによって、メモリ損
失、トレースバック、またはクラッシュが発生しないことを確認します。サーバから、6 時間のバー
ジョン 2c SNMP ウォークを実行します。
テスト手順
SNMP MIB ウォーク テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show running-config コマンドを使用して、DUT の SNMP コンフィギュレーションを確認します。
ステップ 3
サーバの CLI で snmpwalk ユーティリティを使用して、DUT 上で 6 時間の SNMP ウォークを実行し
ます。
ステップ 4
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 5
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• DUT にトレースバックやクラッシュが発生しない。
• CPU やメモリに問題が発生しない。
結果
SNMP MIB ウォーク テストは正常に終了しました。
トラフィック処理
ベースライン トラフィック処理では、さまざまなパケット サイズ、ハードウェア レート リミッタ、お
よび Unicast Reverse Path Forwarding （uRPF; ユニキャスト RPF）機能が正しく処理されることを確
認します。
ここでは、次の内容について説明します。
• 「Nexus 7000 のハードウェア レート リミッタ」（P.2-30）
• 「dcap-4k-acc-2 での各種フレーム サイズの処理の検証」（P.2-30）
• 「dcap-7k-acc-1 での各種フレーム サイズの処理の検証」（P.2-31）
• 「dcap-5k-acc-1 での各種フレーム サイズの処理の検証」（P.2-32）
• 「Nexus 7000 の uRPF の検証」（P.2-33）
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-29
第2章
DCAP Nexus 7000 テスト
ベースライン
Nexus 7000 のハードウェア レート リミッタ
このテストでは、Nexus 7000 のハードウェア レート リミッタの動作を検証します。
テスト手順
Nexus 7000 のハードウェア レート リミッタ テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Agg2 で sh hardware rate-limit コマンドを実行し、レート リミッタのコンフィギュレーションを記録
します。
ステップ 3
IP アドレス 101.1.101.201/24 を IXIA ポートに設定し、Vlan 1401 の Agg2 に接続します。
ステップ 4
clear hardware rate-limit all コマンドを使用してレート リミッタのカウンタをクリアし、clear ip
traffic コマンドを使用して IP トラフィックをクリアします。
ステップ 5
100,000 個の Time-to-Live（TTL; 存続可能時間）1 パケットを IXIA から 400 pps で送信します。この
トラフィックは、デフォルト値が 500 に設定されている TTL レート リミッタによって処理されます。
ステップ 6
sh hardware rate-limit layer-3 ttl を発行し、レート リミッタによるドロップがないことを確認しま
す。sh ip traffic の出力でパケット数が 100,000 個になっていれば正常です。
ステップ 7
ステップ 4 を繰り返して、カウンタをクリアします。
ステップ 8
100,000 個の TTL 1 パケットを 800 pps で送信します。ステップ 6 のコマンドを実行し、設定レートを
超えるパケットをレート リミッタがドロップしていることを確認します。
ステップ 9
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 10
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• システムでは設定レートである 500 pps を超える TTL 1 パケットがドロップされる。
• CPU やメモリに問題が発生しない。
結果
Nexus 7000 のハードウェア レート リミッタ テストは正常に終了しました。
dcap-4k-acc-2 での各種フレーム サイズの処理の検証
このテストでは、サイズが 64 ～ Maximum Transmission Unit（MTU; 最大伝送ユニット）（9198）で
あるすべてのフレームがデバイスを通じて送信されるときの、アクセスレイヤ デバイス dcap-4k-acc-2
の機能を検証します。この範囲のサイズのパケットがすべて転送されれば正常です。
Cisco Data Center Assurance Program（DCAP）6.0
2-30
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
テスト手順
dcap-4k-acc-2 での各種フレーム サイズの処理の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセスレイヤ デバイス上にジャンボ MTU が設定されていることを確認します。コンフィギュレー
ションの確認には show running-configuration interface interface コマンドを使用します。
ステップ 3
1 種類のストリームを送信するよう ixia を設定します。ストリームは、長さが 64 ～ 9198 バイトのフ
レームで構成します。
ステップ 4
clear counters コマンドを発行して、デバイスのカウンタをクリアします。
ステップ 5
ixia ストリームを開始します。ストリームのすべてのパケットが宛先 ixia ポートで受信されていること
を確認します。
ステップ 6
show interface interface コマンドと show interface interface counters コマンドを発行して、デバイス
の show interface counters 出力を確認します。送信されるパケット数とほとんど同じ数ずつカウンタが
増加していれば正常です。
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• 範囲が 64 バイト ～ インターフェイスの MTU（9198）であるフレームのストリームが受信 ixia
ポートに転送される。
• CPU やメモリに問題が発生しない。
結果
dcap-4k-acc-2 での各種フレーム サイズの処理の検証テストは正常に終了しました。
dcap-7k-acc-1 での各種フレーム サイズの処理の検証
このテストでは、サイズが 64 ～ MTU（9216）であるすべてのフレームがデバイスを通じて送信され
るときの、アクセスレイヤ デバイス dcap-7k-acc-1 の機能を検証します。この範囲のサイズのパケット
がすべて転送されれば正常です。
テスト手順
dcap-7k-acc-1 での各種フレーム サイズの処理の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセスレイヤ デバイス上にジャンボ MTU が設定されていることを確認します。コンフィギュレー
ションの確認には show running-configuration interface interface コマンドを使用します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-31
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 3
1 種類のストリームを送信するよう ixia を設定します。最初のストリームは、長さが 64 ～ 9216 バイト
のフレームで構成されます。
ステップ 4
clear counters コマンドを発行して、デバイスのカウンタをクリアします。
ステップ 5
ixia ストリームを開始します。ストリームのすべてのパケットが宛先 ixia ポートで受信されていること
を確認します。
ステップ 6
show interface interface コマンドと show interface interface counters コマンドを発行して、デバイス
の show interface counters 出力を確認します。送信されるパケット数とほとんど同じ数ずつカウンタが
増加していれば正常です。
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• 範囲が 64 バイト ～ インターフェイスの MTU（9216）であるフレームのストリームが受信 ixia
ポートに転送される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-acc-1 での各種フレーム サイズの処理の検証テストは正常に終了しました。
dcap-5k-acc-1 での各種フレーム サイズの処理の検証
このテストでは、サイズが 64 ～ MTU（9216）であるすべてのフレームがデバイスを通じて送信され
るときの、アクセスレイヤ デバイス dcap-5k-acc-1 の機能を検証します。この範囲のサイズのパケット
がすべて転送されれば正常です。
テスト手順
dcap-5k-acc-1 での各種フレーム サイズの処理の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセスレイヤ デバイス上にジャンボ MTU が設定されていることを確認します。コンフィギュレー
ションの確認には、show running-configuration コマンドを使用します。
MTU にはポートごとのコンフィギュレーションがないため、次のサービス ポリシーを作成する必要が
あります。
system jumbomtu 9216
policy-map jumbo
class class-default
mtu 9216
system qos
service-policy jumbo
Cisco Data Center Assurance Program（DCAP）6.0
2-32
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ベースライン
ステップ 3
1 種類のストリームを送信するよう ixia を設定します。ストリームは、長さが 64 ～ 9198 バイトのフ
レームで構成します。
ステップ 4
clear counters コマンドを発行して、デバイスのカウンタをクリアします。
ステップ 5
ixia ストリームを開始します。ストリームのすべてのパケットが宛先 ixia ポートで受信されていること
を確認します。
ステップ 6
show interface interface コマンドと show interface interface counters コマンドを発行して、デバイス
の show interface counters 出力を確認します。送信されるパケット数とほとんど同じ数ずつカウンタが
増加していれば正常です。
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• 範囲が 64 バイト ～ インターフェイスの MTU（9216）であるフレームのストリームが受信 ixia
ポートに転送される。
• CPU やメモリに問題が発生しない。
結果
dcap-5k-acc-1 での各種フレーム サイズの処理の検証テストは正常に終了しました。
Nexus 7000 の uRPF の検証
このテストでは、Nexus7000 のユニキャスト RPF 機能を検証します。インターフェイスでユニキャス
ト RPF がイネーブルになると、ルータはそのインターフェイスで入力として受信したすべてのパケッ
トを検証し、送信元アドレスと送信元インターフェイスがルーティング テーブルに存在すること、お
よびパケットが受信されたインターフェイスと一致していることを確認します。ユニキャスト RPF は、
ルータ インターフェイスで受信されたパケットが、パケットの送信元への最適なリターン パス（戻り
ルート）を経由して到着したかどうかをチェックします。これを実行するために、ユニキャスト RPF
は Forwarding Information Base（FIB; 転送情報ベース）テーブルを逆ルックアップします。ユニキャ
スト RPF がパケットの戻りルートを見つけられなかった場合、そのパケットはドロップされます。
テスト手順
Nexus 7000 の uRPF の検証テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show run interface vlan500 コマンドを発行して、dcap-7k-agg-2 の Vlan500 インターフェイスで
uRPF がイネーブルになっていないことを確認します。
ステップ 3
dcap-7k-agg-1 の loopback202 インターフェイスの IP アドレスを 202.1.1.1 に設定し、show ip route
202.1.1.1 コマンドを発行して、ルートが dcap-7k-agg-2 にアドバタイズされないようにします。
ステップ 4
dcap-7k-agg-2 の ICMP デバッグをオンにします。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-33
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 5
拡張 ping を、送信元アドレス 202.1.1.1 で 172.30.1.22（dcap-7k-agg-2 の Vlan500 のアドレス）宛に
実行します。dcap-7k-agg-2 の Echo 応答デバッグ メッセージおよび dcap-7k-agg-1 に対する失敗 ping
を確認します。
ステップ 6
ip verify unicast source reachable-via any コマンドを発行して、dcap-7k-agg-2 の uRPF を設定しま
す。次のコマンドを発行して、Vlan500 の uRPF コンフィギュレーションを確認します。sh ip fib
interfaces mod 1 | inc Vlan500sh ip fib interfaces mod 2 | inc Vlan500 。次のコマンドを使用して、
ハードウェア カウンタをクリアします。clear statistics module-all device all
ステップ 7
再度、拡張 ping を、送信元アドレス 202.1.1.1 で 172.30.1.22（dcap-7k-agg-2 の Vlan500 のアドレス）
宛に実行します。dcap-7k-agg-2 の Echo 応答デバッグ メッセージは表示されず、dcap-7k-agg-1 に対
する ping が失敗したら正常です。
ステップ 8
dcap-7k-agg-2 に対して次のコマンドを実行して、uRPF ドロップを表示します。10 パケットがドロッ
プしていたら正常です。sh hardware internal statistics module-all device l3lu errors | i RPF
ステップ 9
ICMP デバッグをオフにし、dcap-7k-agg-2 の uRPF コンフィギュレーションを削除します。
dcap-7k-agg-1 の loopback202 インターフェイスを削除します。
ステップ 10
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 11
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• uRPF がディセーブルの場合、ping テストは正常に終了する。uRPF がイネーブルの場合、ping テ
ストは失敗し、uRPF のドロップ カウンタは 10 パケットを示す。
• CPU やメモリに問題が発生しない。
結果
Nexus 7000 の uRPF の検証テストは正常に終了しました。
ネガティブ
このテスト群では、ネガティブなシナリオを実行します。スイッチやリンクの障害などが該当します。
ここでは、次の内容について説明します。
• 「ハードウェア障害」（P.2-34）
• 「リンク障害」（P.2-51）
• 「システム イベント」（P.2-113）
ハードウェア障害
ネガティブなハードウェア障害として、アクティブ スーパーバイザ、スタンバイ スーパーバイザ、
個々のラインカード、スイッチ全体の障害など、各種システム コンポーネントの障害に焦点を当てて
います。
Cisco Data Center Assurance Program（DCAP）6.0
2-34
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ここでは、次の内容について説明します。
• 「dcap-7k-acc-1 でのアクティブ スーパーバイザ障害」（P.2-35）
• 「dcap-7k-agg-1 でのアクティブ スーパーバイザ障害」（P.2-36）
• 「dcap-7k-core-1 でのアクティブ スーパーバイザ障害」（P.2-37）
• 「dcap-7k-acc-1 でのラインカード障害」（P.2-38）
• 「dcap-7k-agg-1 でのラインカード障害」（P.2-40）
• 「dcap-7k-core-1 でのラインカード障害」（P.2-41）
• 「dcap-7k-acc-1 でのラインカード フラップの繰り返し」（P.2-43）
• 「dcap-7k-agg-1 での電源モジュール障害」（P.2-44）
• 「dcap-7k-agg-1 でのスパイン カード障害」（P.2-45）
• 「dcap-7k-agg-1 でのスタンバイ スーパーバイザ障害」（P.2-46）
• 「dcap-7k-agg-1 でのシステム障害」（P.2-47）
• 「dcap-7k-core-1 でのシステム障害」（P.2-50）
dcap-7k-acc-1 でのアクティブ スーパーバイザ障害
このテストでは、アクセス レイヤ NX-OS デバイスのスーパーバイザ High Availability（HA; ハイ ア
ベイラビリティ）機能を検証します。
このテストでは、dcap-7k-acc-1 でスーパーバイザを強制的に切り替えます。スイッチの安定性を監視
し、トラフィックが損失していないことを確認します。
テスト手順
dcap-7k-acc-1 でのアクティブ スーパーバイザ障害テストの実行手順は次のとおりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
show spanning-tree interface interface コマンドを発行して、dcap-7k-acc-1 の spanning-tree ステータ
スを確認します。
ステップ 3
ixia トラフィック ストリームを開始します。
ステップ 4
show redundancy status コマンドを発行して、デバイスの redundancy ステートを確認します。
ステップ 5
system switchover コマンドを使用して、強制的に切り替えます。
ステップ 6
新しいスタンバイが完全にブートするまで待機し、show redundancy status コマンドを発行して、シ
ステムが再びアクティブ - スタンバイの HA モードになっていることを確認します。
ステップ 7
show spanning-tree summary コマンドを発行して、spanning-tree ステータスを再度確認します。
ステップ 8
この切り替えによってユニキャスト トラフィックが損失していないことを確認します。マルチキャス
ト トラフィックについては、わずかな量の損失が予期されています。この原因が数秒のダウンタイム
だけであることを確認します。
ステップ 9
ここまでのステップを繰り返し、動作をもう一度確認します。
ステップ 10
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-35
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 11
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アクティブ スーパーバイザの切り替えによるユニキャスト トラフィック損失は発生しない。
• アクティブ スーパーバイザの切り替えによってマルチキャスト トラフィックがわずかな量損失す
る。
• システム エラーは発生しない。
• システムはフェールオーバーから完全に回復する。
• テスト対象デバイスの CPU またはメモリに対する許容できない影響は発生しない。
結果
dcap-7k-acc-1 でのアクティブ スーパーバイザ障害テストは失敗しました。検出された障害は
CSCsx32476 です。
dcap-7k-agg-1 でのアクティブ スーパーバイザ障害
このテストでは、アグリゲーション レイヤ NX-OS デバイスのスーパーバイザ HA 機能を検証します。
このテストでは、dcap-7k-agg-1 でスーパーバイザを強制的に切り替えます。スイッチの安定性を監視
し、トラフィックが損失していないことを確認します。
テスト手順
dcap-7k-agg-1 でのアクティブ スーパーバイザ障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show spanning-tree interface interface、show hsrp brief、show ip pim neighbor、show ip ospf
neighbor の各コマンドを発行して、dcap-7k-agg-1 の L2 および L3 プロトコルのステートを確認しま
す。
ステップ 3
ixia トラフィック ストリームを開始します。
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 5
show redundancy status コマンドを発行して、デバイスの redundancy ステートを確認します。
ステップ 6
system switchover コマンドを使用して、強制的に切り替えます。
ステップ 7
新しいスタンバイが完全にブートするまで待機し、show redundancy status コマンドを発行して、シ
ステムが再びアクティブ - スタンバイの HA モードになっていることを確認します。
ステップ 8
show spanning-tree interface interface、show hsrp brief、show ip pim neighbor、show ip ospf
neighbor の各コマンドを発行して、dcap-7k-agg-1 の L2 および L3 プロトコルのステートを確認しま
す。
ステップ 9
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-36
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 10
この切り替えによってトラフィックが損失していないことを確認します。
ステップ 11
ここまでのステップを繰り返し、動作をもう一度確認します。
ステップ 12
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 13
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アクティブ スーパーバイザの切り替えによるトラフィック損失は発生しない。
• システム エラーは発生しない。
• システムはフェールオーバーから完全に回復する。
• テスト対象デバイスの CPU またはメモリに対する許容できない影響は発生しない。
結果
dcap-7k-agg-1 でのアクティブ スーパーバイザ障害テストは失敗しました。検出された障害は
CSCsx32476 です。
dcap-7k-core-1 でのアクティブ スーパーバイザ障害
このテストでは、コア レイヤ NX-OS デバイスのスーパーバイザ HA 機能を検証します。
このテストでは、dcap-7k-core-1 でスーパーバイザを強制的に切り替えます。スイッチの安定性を監視
し、トラフィックが損失していないことを確認します。
テスト手順
dcap-7k-core-1 でのアクティブ スーパーバイザ障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show ip pim neighbor コマンドと show ip ospf neighbor コマンドを発行して、dcap-7k-core-1 の L3
プロトコルのステートを確認します。
ステップ 3
ixia トラフィック ストリームを開始します。
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 5
show redundancy status コマンドを発行して、デバイスの redundancy ステートを確認します。
ステップ 6
system switchover コマンドを使用して、強制的に切り替えます。
ステップ 7
新しいスタンバイが完全にブートするまで待機し、show redundancy status コマンドを発行して、シ
ステムが再びアクティブ - スタンバイの HA モードになっていることを確認します。
ステップ 8
show spanning-tree interface interface、show hsrp brief、show ip pim neighbor、show ip ospf
neighbor の各コマンドを発行して、dcap-7k-agg-1 の L3 プロトコルのステートを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-37
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 9
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 10
この切り替えによってトラフィックが損失していないことを確認します。
ステップ 11
ここまでのステップを繰り返し、動作をもう一度確認します。
ステップ 12
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 13
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アクティブ スーパーバイザの切り替えによるトラフィック損失は発生しない。
• システム エラーは発生しない。
• システムはフェールオーバーから完全に回復する。
• テスト対象デバイスの CPU またはメモリに対する許容できない影響は発生しない。
結果
dcap-7k-core-1 でのアクティブ スーパーバイザ障害テストは失敗しました。検出された障害は
CSCsx32476 です。
dcap-7k-acc-1 でのラインカード障害
このテストでは、dcap-7k-acc-1 のラインカードの障害による影響を確認します。テスト トラフィック
プロファイルの実行中に、ラインカードを取り外します。この障害に起因するトラフィック損失を測定
します。ラインカードを元に戻し、カードがオンラインになったら、トラフィック損失がないかどうか
を再度測定します。また、チャネル メンバの再構築が LACP を使用して正常に行われることを確認し
ます。動作の一貫性を確認するために、ラインカード フラップ シーケンスをもう一回繰り返します
（合計 2 回）。
テスト手順
dcap-7k-acc-1 でのラインカード障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show port-channel summary コマンドを使用して、dcap-7k-acc-1、dcap-7k-agg-1、および
dcap-7k-agg-2 の Portchannel ステータスを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスとそのすべてのメン
バでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po4 インターフェ
イスではユニキャスト トラフィックだけを受信していることを確認します。ダウンストリーム モ
ジュールがトラフィックを Eth4/13 経由でホストに伝送していることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-38
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 5
デバイスの L2 Portchannel 間のトラフィック伝送に関わっているモジュール 1 を物理的に取り外しま
す。
ステップ 6
モジュールを取り外したことによるトラフィックのダウンタイムを測定します。
ステップ 7
dcap-7k-acc-1、dcap-7k-agg-1、および dcap-7k-agg-2 に対して show port-channel summary コマン
ドを発行して、デバイスの Portchannel のステータスを確認します。
ステップ 8
Ixia テスト プロファイル トラフィックを再開します。
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が引き続き Po2 インターフェイスとそのすべ
てのメンバでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po4 イン
ターフェイスではユニキャスト トラフィックだけを受信していることを確認します。
ステップ 10
モジュール 1 を挿入し、show module コマンドを発行して、モジュール 1 がオンラインに戻ったこと
を確認します。
ステップ 11
トラフィックを停止し、モジュールの Online Insertion and Removal（OIR; 活性挿抜、ホットスワッ
プ）によるダウンタイムを測定します。
ステップ 12
dcap-7k-acc-1、dcap-7k-agg-1、および dcap-7k-agg-2 に対して show port-channel summary コマン
ドを発行して、デバイスの Portchannel のステータスを確認します。
ステップ 13
Ixia テスト プロファイル トラフィックを再開します。
ステップ 14
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスとそのすべてのメン
バでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po4 インターフェ
イスではユニキャスト トラフィックだけを受信していることを確認します。
ステップ 15
インターフェイス Eth4/13 のカウンタを確認します。clear counters コマンドを使用してインターフェ
イス カウンタをクリアした後、show interface interface counters コマンドを使用して、dcap-7k-acc-1
がユニキャスト トラフィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 16
トラフィックの伝送に関わっているモジュール 4 を物理的に取り外し、シャーシに挿入して戻します。
ステップ 17
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が再度 Eth4/13 インターフェイスでユニキャス
ト トラフィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 18
動作を再度確認するために、ここまでのステップを繰り返します。
ステップ 19
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 20
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アグリゲーション レイヤへのアップリンクを含むラインカードの障害により、2 秒未満のトラ
フィック損失が発生する。
• アグリゲーション レイヤへのアップリンクを含むラインカードのオンライン復旧に伴い、2 秒未満
のトラフィック損失が発生する。
• ラインカードがリブートされるときに、ポートチャネルが正しく再設定される。
• ホスト ダウンリンクを持つラインカードは、OIR イベント後も引き続きトラフィックを転送する。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-39
第2章
DCAP Nexus 7000 テスト
ネガティブ
• CPU やメモリに問題が発生しない。
結果
dcap-7k-acc-1 でのラインカード障害テストは失敗しました。検出された障害は CSCsx24076 です。
dcap-7k-agg-1 でのラインカード障害
このテストでは、dcap-7k-agg-1 のラインカードの障害による影響を確認します。テスト トラフィック
プロファイルの実行中に、システムの複数のラインカードを取り外します。ラインカードを戻し、カー
ドがオンラインになったら、チャネル メンバの再構築が LACP を使用して正常に行われることを確認
します。複数の L3 Portchannel ポートを持つラインカードと複数の L2 Portchannel ポートを持つライ
ンカードを別々に OIR し、両カードの挿抜によるトラフィックへの影響を測定します。
テスト手順
dcap-7k-agg-1 でのラインカード障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show port-channel summary コマンドを発行して、dcap-7k-agg-1 の Portchannel のステータスを確認
します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-agg-1 が接続されている各インターフェイスでユニ
キャスト トラフィックとマルチキャスト トラフィックを予期されるとおりに受信していることを確認
します。
ステップ 5
デバイスの L3 Portchannel 間のトラフィック伝送に関わっているモジュール 1 を物理的に取り外しま
す。
ステップ 6
モジュールを取り外したことによるトラフィックのダウンタイムを測定します。
ステップ 7
show port-channel summary コマンドを発行して、デバイスの Portchannel のステータスを確認しま
す。
ステップ 8
Ixia テスト プロファイル トラフィックを再開します。
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-agg-1 が接続されている各インターフェイスでユニ
キャスト トラフィックとマルチキャスト トラフィックを予期されるとおりに受信していることを確認
します。
ステップ 10
モジュール 1 を挿入し、show module コマンドを発行して、モジュール 1 がオンラインに戻ったこと
を確認します。
ステップ 11
モジュールの OIR によるトラフィックのダウンタイムを測定します。
ステップ 12
show port-channel summary コマンドを発行して、デバイスの Portchannel のステータスを確認しま
す。
ステップ 13
Ixia テスト プロファイル トラフィックを再開します。
ステップ 14
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-agg-1 が接続されている各インターフェイスでユニ
キャスト トラフィックとマルチキャスト トラフィックを予期されるとおりに受信していることを確認
します。
Cisco Data Center Assurance Program（DCAP）6.0
2-40
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 15
デバイスの L2 Portchannel 間のトラフィック伝送に関わっているモジュール 7 を物理的に取り外しま
す。
ステップ 16
モジュールを取り外したことによるトラフィックのダウンタイムを測定します。
ステップ 17
show port-channel summary コマンドを発行して、デバイスの Portchannel のステータスを確認しま
す。
ステップ 18
Ixia テスト プロファイル トラフィックを再開します。
ステップ 19
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-agg-1 が接続されている各インターフェイスでユニ
キャスト トラフィックとマルチキャスト トラフィックを予期されるとおりに受信していることを確認
します。
ステップ 20
モジュール 7 を挿入し、show module コマンドを発行して、モジュール 1 がオンラインに戻ったこと
を確認します。
ステップ 21
モジュールの OIR によるトラフィックのダウンタイムを測定します。
ステップ 22
show port-channel summary コマンドを発行して、デバイスの Portchannel のステータスを確認しま
す。
ステップ 23
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-agg-1 が接続されている各インターフェイスでユニ
キャスト トラフィックとマルチキャスト トラフィックを予期されるとおりに受信していることを確認
します。
ステップ 24
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 25
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ラインカードがリブートされるときに、ポートチャネルが正しく再設定される。
• 各ラインカードのリブート後にトラフィックが再開される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 でのラインカード障害テストは失敗しました。検出された障害は CSCsx15006 および
CSCsx24076 です。
dcap-7k-core-1 でのラインカード障害
このテストでは、dcap-7k-core-1 のラインカードの障害による影響を確認します。テスト トラフィッ
ク プロファイルの実行中に、ラインカードを取り外します。この障害に起因するトラフィック損失を
測定します。ラインカードを元に戻し、カードがオンラインになったら、トラフィック損失がないかど
うかを再度測定します。また、チャネル メンバの再構築が LACP を使用して正常に行われることを確
認します。動作の一貫性を確認するために、ラインカード フラップ シーケンスをもう一回繰り返しま
す（合計 2 回）。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-41
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-7k-core-1 でのラインカード障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show port-channel summary コマンドを使用して、dcap-7k-core-1、dcap-7k-core-2、dcap-7k-agg-1、
および dcap-7k-agg-2 の Portchannel ステータスを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-core-1 が Po1、Po3、Po5 の各インターフェイスとそ
のバンドル メンバでユニキャスト トラフィックとマルチキャスト トラフィックを予期されるように送
信していることを確認します。
ステップ 5
デバイスの L3 Portchannel 間のトラフィック伝送に関わっているモジュール 2 を物理的に取り外しま
す。
ステップ 6
モジュールを取り外したことによるトラフィックのダウンタイムを測定します。
ステップ 7
show port-channel summary コマンドを使用して、dcap-7k-core-1、dcap-7k-core-2、dcap-7k-agg-1、
および dcap-7k-agg-2 の Portchannel ステータスを確認します。
ステップ 8
Ixia テスト プロファイル トラフィックを再開します。
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-core-1 が Po1、Po3、Po5 の各インターフェイスとそ
のバンドル メンバでユニキャスト トラフィックとマルチキャスト トラフィックを予期されるように送
信していることを確認します。
ステップ 10
モジュール 1 を挿入し、show module コマンドを発行して、モジュール 1 がオンラインに戻ったこと
を確認します。
ステップ 11
トラフィックを停止し、モジュールの OIR によるダウンタイムを測定します。
ステップ 12
dcap-7k-core-1、dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 に対して show port-channel
summary コマンドを発行して、デバイスの Portchannel のステータスを確認します。
ステップ 13
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-core-1 が Po1、Po3、Po5 の各インターフェイスとそ
のバンドル メンバでユニキャスト トラフィックとマルチキャスト トラフィックを予期されるように送
信していることを確認します。
ステップ 14
この障害シナリオを繰り返し、動作の一貫性を確認します。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アグリゲーション レイヤへのアップリンクを含むラインカードの障害により、2 秒未満のトラ
フィック損失が発生する。
Cisco Data Center Assurance Program（DCAP）6.0
2-42
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• アグリゲーション レイヤへのアップリンクを含むラインカードのオンライン復旧に伴い、2 秒未満
のトラフィック損失が発生する。
• ラインカードがリブートされるときに、ポートチャネルが正しく再設定される。
• ホスト ダウンリンクを持つラインカードは、OIR イベント後も引き続きトラフィックを転送する。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 でのラインカード障害テストは正常に終了しました。
dcap-7k-acc-1 でのラインカード フラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-7k-acc-1 の各ラインカードを繰り返しフラップし、ネットワークへの影響を監視します。
dcap-7k-acc-1 の各ラインカードを 20 回フラップします。各モジュールの電源をオフにしてから、オ
ンに戻します。カードがオンラインになったら、このプロセスを繰り返します。所定の回数フラップを
行った後、ポートチャネルが正しく再構築されること、およびトラフィックが正しく伝送されることを
確認します。
テスト手順
dcap-7k-acc-1 でのラインカード フラップの繰り返しテストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-7k-acc-1 の間のリンクのス
テートを確認します。また、show interface interface status コマンドを発行して、ダウンストリーム
ホスト リンクを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 がアップストリーム インターフェイスでユニ
キャスト トラフィックとマルチキャスト トラフィックを受信していること、およびダウンストリーム
インターフェイスでアクセス ホストへのトラフィックを送信していることを確認します。
ステップ 5
poweroff modulemodule コマンドの発行、poweron modulemodule コマンドの発行、5 秒間の待機の
順序で、デバイスの各ラインカードを繰り返しフラップします。
ステップ 6
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-7k-acc-1 の間のリンクのス
テートを確認します。また、show interface interface status コマンドを発行して、ダウンストリーム
ホスト リンクを確認します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 がアップストリーム インターフェイスでユニ
キャスト トラフィックとマルチキャスト トラフィックを受信していること、およびダウンストリーム
インターフェイスでアクセス ホストへのトラフィックを送信していることを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-43
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークでラインカード障害の繰り返しが適切に処理される。
• ラインカード障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-acc-1 でのラインカード フラップの繰り返しテストは失敗しました。検出された障害は
CSCsu77624 です。
dcap-7k-agg-1 での電源モジュール障害
このテストでは、dcap-7k-agg-1 の電源モジュール障害による影響を確認します。テスト トラフィック
プロファイルの実行中に、各電源モジュールを取り外してから、再び挿入します。この障害に起因する
トラフィック損失を測定します。電源モジュールを元に戻し、オンラインになったら、トラフィック損
失がないかどうかを再度測定します。動作の一貫性を確認するために、電源モジュールの OIR シーケ
ンスをもう一回繰り返します（合計 2 回）。
テスト手順
dcap-7k-agg-1 での電源モジュール障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show environment power コマンドを発行して、dcap-7k-agg-1 の電源モジュールのステータスを確認
します。
デバイスがリダンダント電源の冗長モードで実行されていることを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
デバイス背面のスロット 1 から電源モジュールを物理的に取り外します。show environment power コ
マンドを使用して、取り外したデバイスがシステムに存在していないことを確認します。
ステップ 5
この障害によるトラフィック ダウンタイムを測定します。
ステップ 6
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 7
電源モジュールをスロット 1 に物理的に挿入します。
ステップ 8
show environment status コマンドを発行して、挿入した電源モジュールがオンラインに戻ったことを
確認します。
ステップ 9
トラフィックを停止し、電源モジュール障害により発生したトラフィック ダウンタイムを測定します。
ステップ 10
システム内の電源モジュールごとに OIR を繰り返します。各 OIR イベントによるトラフィック損失を
計算します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
2-44
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• 電源モジュール障害によるトラフィック損失は発生しない。
• いずれの電源モジュール障害が発生した後も、システムとそのすべてのモジュールの電源はオンの
ままである。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 での電源モジュール障害テストは正常に終了しました。
dcap-7k-agg-1 でのスパイン カード障害
このテストでは、dcap-7k-agg-1 のスパインの障害による影響を確認します。テスト トラフィック プ
ロファイルの実行中に各スパインを取り外してから、再び挿入します。この障害に起因するトラフィッ
ク損失を測定します。スパインを元に戻し、オンラインになったら、トラフィック損失を再度測定しま
す。動作の一貫性を確認するために、スパインの OIR シーケンスをもう一回繰り返します（合計 2
回）。
テスト手順
dcap-7k-agg-1 でのスパイン障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show module xbar コマンドを発行して、dcap-7k-agg-1 の Xbar スパイン モジュールのステータスを
確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
デバイス背面のスロット 1 からスパインを物理的に取り外します。
ステップ 5
この障害によるトラフィック ダウンタイムを測定します。
ステップ 6
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 7
スパイン カード モジュールをスロット 1 に物理的に挿入します。
ステップ 8
show module xbar コマンドを発行して、挿入したモジュールがオンラインに戻ったことを確認しま
す。
ステップ 9
トラフィックを停止し、スパイン カード障害により発生したトラフィック ダウンタイムを測定します。
ステップ 10
システムの各スパイン カードにつき OIR を繰り返します。各 OIR イベントによるトラフィック損失を
計算します。
ステップ 11
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-45
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 12
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• スパイン カード障害により最小限のトラフィック損失が発生する。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 でのスパイン カード障害テストは正常に終了しました。
dcap-7k-agg-1 でのスタンバイ スーパーバイザ障害
このテストでは、アグリゲーション レイヤ NX-OS デバイスのシステム安定性を検証します。
テスト手順
dcap-7k-agg-1 でのスタンバイ スーパーバイザ障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show spanning-tree interface interface、show hsrp brief、show ip pim neighbor、show ip ospf
neighbor の各コマンドを発行して、dcap-7k-agg-1 の L2 および L3 プロトコルのステートを確認しま
す。
ステップ 3
ixia トラフィック ストリームを開始します。
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 5
show redundancy status コマンドを発行して、デバイスの redundancy ステートを確認します。
ステップ 6
reload modulemodule コマンドを発行して、スタンバイ スーパーバイザをリロードします。
ステップ 7
新しいスタンバイが完全にブートするまで待機し、show redundancy status コマンドを発行して、シ
ステムが再びアクティブ - スタンバイの HA モードになっていることを確認します。
ステップ 8
show spanning-tree interface interface、show hsrp brief、show ip pim neighbor、show ip ospf
neighbor の各コマンドを発行して、dcap-7k-agg-1 の L2 および L3 プロトコルのステートを確認しま
す。
ステップ 9
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 10
スタンバイのリロードによるトラフィック損失がないことを確認します。
ステップ 11
ここまでのステップを繰り返し、動作をもう一度確認します。
ステップ 12
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
2-46
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 13
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• スタンバイ スーパーバイザのリロードによるトラフィック損失は発生しない。
• システム エラーは発生しない。
• システムはフェールオーバーから完全に回復する。
• テスト対象デバイスの CPU またはメモリに対する許容できない影響は発生しない。
結果
dcap-7k-agg-1 でのスタンバイ スーパーバイザ障害テストは正常に終了しました。
dcap-7k-agg-1 でのシステム障害
このテストでは、アグリゲーション レイヤ NX-OS デバイスのセットによって実現されるネットワーク
HA 機能を検証します。
このテストでは、DR である dcap-7k-agg-1 に障害を発生させて、dcap-7k-agg-2 が DR を引き継ぐよ
うに強制します。リブート時のスイッチの安定性と障害中のネイバーの安定性を監視し、トラフィック
損失が予期された範囲内に収まることを確認します。dcap-7k-agg-1 ボックスをオンラインに戻し、こ
れが DR として復旧してトラフィックを再び伝送することを確認します。
テスト手順
dcap-7k-agg-1 でのシステム障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-47
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 3
show ip pim neighbor コマンドと show ip ospf neighbor コマンドを発行して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 の L3 プロトコルのステートを確認します。
ステップ 4
ixia トラフィック ストリームを開始します。
ステップ 5
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 6
デバイスの電源を物理的にオフにして、DR 障害を強制的に発生させます。
ステップ 7
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
Cisco Data Center Assurance Program（DCAP）6.0
2-48
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 8
show ip pim neighbor コマンドと show ip ospf neighbor コマンドを発行して、dcap-7k-core-2、
dcap-7k-agg-1、および dcap-7k-agg-2 の L3 プロトコル ステートを確認します。
ステップ 9
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 10
トラフィックを停止し、障害に伴うトラフィック ダウンタイムを解析します。
ステップ 11
トラフィック ストリームを開始します。
ステップ 12
デバイスの電源を物理的にオンにします。
ステップ 13
デバイスがオンラインに戻ったら、show spanning-tree interface interface コマンドを使用して、レイ
ヤ 2 ドメインのデバイスの spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-49
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 14
show ip pim neighbor コマンドと show ip ospf neighbor コマンドを発行して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 の L3 プロトコル ステートを確認します。
ステップ 15
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 16
トラフィックを停止し、障害に伴うトラフィック ダウンタイムを解析します。
ステップ 17
ここまでのステップを繰り返し、動作をもう一度確認します。
ステップ 18
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 19
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• アグリゲーション DR 障害により最小限のトラフィック損失が発生する。
• システム エラーは発生しない。
• システムはフェールオーバーから完全に回復する。
• テスト対象デバイスの CPU またはメモリに対する許容できない影響は発生しない。
結果
dcap-7k-agg-1 でのシステム障害テストは失敗しました。検出された障害は CSCsx24076 です。
dcap-7k-core-1 でのシステム障害
このテストでは、コア レイヤ NX-OS デバイスのセットによって実現されるネットワーク HA 機能を検
証します。
このテストでは、RP である dcap-7k-core-1 に障害を発生させて、dcap-7k-core-2 が RP を引き継ぐよ
うに強制します。リブート時のスイッチの安定性と障害中のネイバーの安定性を監視し、トラフィック
損失が予期された範囲内に収まることを確認します。dcap-7k-core-1 ボックスをオンラインに戻し、こ
れが RP として復旧してトラフィックを再び伝送することを確認します。
テスト手順
dcap-7k-core-1 でのシステム障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show ip pim neighbor、show ip ospf neighbor、show ip msdp peer の各コマンドを発行して、
dcap-7k-core-1、dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 の L3 プロトコルのステート
を確認します。
ステップ 3
ixia トラフィック ストリームを開始します。
Cisco Data Center Assurance Program（DCAP）6.0
2-50
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 5
デバイスの電源を物理的にオフにして、RP 障害を強制的に発生させます。
ステップ 6
dcap-7k-core-1 のリブート中に、show ip pim neighbor、show ip ospf neighbor、show ip msdp peer
の各コマンドを発行して、dcap-7k-core-2 、dcap-7k-agg-1、および dcap-7k-agg-2 の L3 プロトコルの
ステートを確認します。
ステップ 7
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 8
トラフィックを停止し、障害に伴うトラフィック ダウンタイムを解析します。
ステップ 9
トラフィック ストリームを開始します。
ステップ 10
デバイスの電源を物理的にオンにします。
ステップ 11
デバイスがオンラインに戻ったら、show ip pim neighbor、show ip ospf neighbor、show ip msdp
peer の各コマンドを発行して、dcap-7k-core-1、dcap-7k-core-2、dcap-7k-agg-1、および
dcap-7k-agg-2 の L3 プロトコル ステートを確認します。
ステップ 12
show ip mroute summary count コマンドと show ip mroute コマンドを発行して、mroute ステートを
確認します。
ステップ 13
ここまでのステップを繰り返し、動作をもう一度確認します。
ステップ 14
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 15
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• コア RP 障害により最小限のトラフィック損失が発生する。
• システム エラーは発生しない。
• システムはフェールオーバーから完全に回復する。
• テスト対象デバイスの CPU またはメモリに対する許容できない影響は発生しない。
結果
dcap-7k-core-1 でのシステム障害テストは失敗しました。検出された障害は CSCsx24076 です。
リンク障害
ネガティブなリンク障害テストでは、単発のリンク障害および繰り返し発生するリンク障害にテスト対
象デバイスが正しく対応する機能と能力に焦点を当てています。
ここでは、次の内容について説明します。
• 「dcap-7k-agg-2 と dcap-4k-acc-2 の間の 10G L2 リンクの障害」（P.2-52）
• 「dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 リンクの障害」（P.2-56）
• 「dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害」（P.2-59）
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-51
第2章
DCAP Nexus 7000 テスト
ネガティブ
• 「dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 ポートチャネルの障害」（P.2-63）
• 「dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害」（P.2-67）
• 「dcap-7k-agg-1 と dcap-7k-agg-2 の間の L2 ポートチャネルの障害」（P.2-70）
• 「dcap-7k-agg-2 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害」（P.2-74）
• 「dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害」（P.2-78）
• 「dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害」（P.2-79）
• 「dcap-7k-core-1 と dcap-7k-core-2 の間の L3 バンドル リンクの障害」（P.2-81）
• 「dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害」（P.2-83）
• 「dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害」（P.2-85）
• 「dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害」（P.2-87）
• 「dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害」（P.2-89）
• 「dcap-7k-core-1 と dcap-7k-core-2 の間の L3 ポートチャネルの障害」（P.2-91）
• 「dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害」（P.2-92）
• 「dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害」（P.2-94）
• 「dcap-7k-agg-1 と dcap-5k-acc-1 の間のレイヤ 2 バンドル リンクの障害」（P.2-96）
• 「dcap-7k-agg-1 と dcap-6k-acc-1 の間のレイヤ 2 バンドル リンクの障害」（P.2-98）
• 「dcap-7k-agg-1 と dcap-7k-acc-1 の間のレイヤ 2 バンドル リンクの障害」（P.2-100）
• 「dcap-7k-agg-1 と dcap-7k-agg-2 の間のレイヤ 2 バンドル リンクの障害」（P.2-102）
• 「dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 バンドル リンクのフラップの繰り返し」（P.2-104）
• 「dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクのフラップの繰り返し」（P.2-105）
• 「dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 バンドル リンクのフラップの繰り返し」（P.2-106）
• 「dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 バンドル リンクのフラップの繰り返し」（P.2-107）
• 「dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 チャネルのフラップの繰り返し」（P.2-108）
• 「dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 チャネルのフラップの繰り返し」（P.2-109）
• 「dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 チャネルのフラップの繰り返し」（P.2-110）
• 「dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクのフラップの繰り返し」（P.2-111）
• 「dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 チャネルのフラップの繰り返し」（P.2-112）
dcap-7k-agg-2 と dcap-4k-acc-2 の間の 10G L2 リンクの障害
このテストでは、dcap-7k-agg-2 と dcap-4k-acc-2 の間のリンクの障害による影響を確認します。
テスト トラフィック プロファイルの実行中に、インターフェイスをシャットダウンします。トラ
フィック損失を測定し、スパニング ツリーの適切な再コンバージェンスが行われることを確認します。
インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、スパニング ツリーの再
コンバージェンスを再度確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
Cisco Data Center Assurance Program（DCAP）6.0
2-52
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-7k-agg-2 と dcap-4k-acc-2 の間の 10G L2 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
各 DUT で show interface interface status コマンドを使用して、dcap-7k-agg-2 と dcap-4k-acc-2 を接
続するリンクのステータスを確認します。
ステップ 3
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 4
dcap-7k-agg-1、dcap-7k-agg-2、および dcap-4k-acc-2 で show interface interface trunk コマンドを使
用して、この 3 つのスイッチを接続しているインターフェイスが正しくトランキングしていることを確
認します。
各インターフェイスで STP Forwarding としてリストされている VLAN に注目します。各インター
フェイスの VLAN のリストに、上記ステップ 3 のステートが反映されていれば正常です。
ステップ 5
Ixia テスト プロファイル トラフィックの送信を開始します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-53
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 6
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-4k-acc-2 が Te1/49 インターフェイスでユニキャスト ト
ラフィックとマルチキャスト トラフィックを受信しているが、Te1/50 インターフェイスでは受信して
いないことを確認します。
ステップ 7
shutdown コマンドを使用して、dcap-7k-agg-2 と dcap-4k-acc-2 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 8
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：なし
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-4k-acc-2 が引き続き Te1/49 インターフェイスでユニ
キャスト トラフィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 10
トラフィックを停止し、リンク切断により発生したトラフィック ダウンタイムを測定します。
ステップ 11
テスト トラフィック フローを再開します。
ステップ 12
no shutdown コマンドを使用して、dcap-7k-agg-2 と dcap-4k-acc-2 の間のリンクを再確立します。
ステップ 13
各 DUT で show interface interface status コマンドを使用して、dcap-7k-agg-2 と dcap-4k-acc-2 を接
続するリンクのステータスを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-54
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 14
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 15
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-4k-acc-2 が Te1/49 インターフェイスでユニキャスト ト
ラフィックとマルチキャスト トラフィックを受信しているが、Te1/50 インターフェイスでは受信して
いないことを確認します。
ステップ 16
トラフィックを停止して、リンクがオンラインに戻るのに伴い発生したトラフィック ダウンタイムを
測定します。
ステップ 17
動作をもう一度確認するために、ここまでの 15 ステップを繰り返します。
ステップ 18
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 19
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-55
第2章
DCAP Nexus 7000 テスト
ネガティブ
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、スパニング ツリーが予期されたとおりに再コンバージェンスされる。
• リンクが再接続されると、スパニング ツリーが元のステートに戻る。
• リンクが再接続されると、VLAN トランクが正しく再形成される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-2 と dcap-4k-acc-2 の間の 10G L2 リンクの障害テストは正常に終了しました。
dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 リンクの障害
このテストでは、dcap-7k-agg-1 と dcap-4k-acc-2 の間のリンクの障害による影響を確認します。
テスト トラフィック プロファイルの実行中に、インターフェイスをシャットダウンします。トラ
フィック損失を測定し、スパニング ツリーの適切な再コンバージェンスが行われることを確認します。
インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、スパニング ツリーの再
コンバージェンスを再度確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 リンクの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
各 DUT で show interface interface status コマンドを使用して、dcap-7k-agg-1 と dcap-4k-acc-2 を接
続するリンクのステータスを確認します。
ステップ 3
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
Cisco Data Center Assurance Program（DCAP）6.0
2-56
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 4
dcap-7k-agg-1、dcap-7k-agg-2、および dcap-4k-acc-2 で show interface interface trunk コマンドを使
用して、この 3 つのスイッチを接続しているインターフェイスが正しくトランキングしていることを確
認します。
各インターフェイスで STP Forwarding としてリストされている VLAN に注目します。各インター
フェイスの VLAN のリストに、上記ステップ 3 のステートが反映されていれば正常です。
ステップ 5
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 6
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-4k-acc-2 が Te1/49 インターフェイスでユニキャスト ト
ラフィックとマルチキャスト トラフィックを受信しており、Te1/50 インターフェイスでマルチキャス
ト トラフィックだけを受信していることを確認します。
ステップ 7
shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-4k-acc-2 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 8
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：なし
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-57
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：なし
• Te1/50：3、500、1301 ～ 1500
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-4k-acc-2 が Te1/50 インターフェイスでユニキャスト ト
ラフィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 10
トラフィックを停止し、リンク切断により発生したトラフィック ダウンタイムを測定します。
ステップ 11
テスト トラフィック フローを再開します。
ステップ 12
no shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-4k-acc-2 の間のリンクを再確立します。
ステップ 13
各 DUT で show interface interface status コマンドを使用して、dcap-7k-agg-1 と dcap-4k-acc-2 を接
続するリンクのステータスを確認します。
ステップ 14
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
Cisco Data Center Assurance Program（DCAP）6.0
2-58
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 15
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-4k-acc-2 が Te1/49 インターフェイスでユニキャスト ト
ラフィックとマルチキャスト トラフィックを受信しており、Te1/50 インターフェイスでマルチキャス
ト トラフィックだけを受信していることを確認します。
ステップ 16
トラフィックを停止して、リンクがオンラインに戻るのに伴い発生したトラフィック ダウンタイムを
測定します。
ステップ 17
動作をもう一度確認するために、ここまでの 15 ステップを繰り返します。
ステップ 18
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 19
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、スパニング ツリーが予期されたとおりに再コンバージェンスされる。
• リンクが再接続されると、スパニング ツリーが元のステートに戻る。
• リンクが再接続されると、VLAN トランクが正しく再形成される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 リンクの障害テストは正常に終了しました。
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害
このテストでは、dcap-7k-agg-1 と dcap-5k-acc-1 の間のポートチャネル リンク全体の障害による影響
を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、スパニング ツリーの適切な再コンバージェンスが行われることを
確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、スパニ
ング ツリーの再コンバージェンスを再度確認します。また、LACP を使用したチャネル メンバの正し
い再構築および VLAN トランクの再構築を確認します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-59
第2章
DCAP Nexus 7000 テスト
ネガティブ
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-1 と dcap-5k-acc-1 を接続
するポートチャネルのステータスを確認します。
ステップ 3
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 4
dcap-7k-agg-1、dcap-7k-agg-2、および dcap-5k-acc-1 で show interface interface trunk コマンドを使
用して、この 3 つのスイッチを接続しているインターフェイスが正しくトランキングしていることを確
認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-60
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
各インターフェイスで STP Forwarding としてリストされている VLAN に注目します。各インター
フェイスの VLAN のリストに、上記ステップ 3 のステートが反映されていれば正常です。
ステップ 5
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 6
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-5k-acc-1 が Po1 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しているが、Po2 インターフェイスでは受信していな
いことを確認します。
ステップ 7
shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-5k-acc-1 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 8
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：なし
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：なし
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：500
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：500
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-5k-acc-1 が Po2 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 10
トラフィックを停止し、リンク切断により発生したトラフィック ダウンタイムを測定します。
ステップ 11
テスト トラフィック フローを再開します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-61
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 12
no shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-5k-acc-1 の間のリンクを再確立します。
ステップ 13
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-1 と dcap-5k-acc-1 を接続
するポートチャネルのステータスを確認します。
ステップ 14
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 15
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-5k-acc-1 が Po1 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しているが、Po2 インターフェイスでは受信していな
いことを確認します。
ステップ 16
トラフィックを停止して、リンクがオンラインに戻るのに伴い発生したトラフィック ダウンタイムを
測定します。
ステップ 17
動作をもう一度確認するために、ここまでの 15 ステップを繰り返します。
ステップ 18
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
2-62
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 19
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、スパニング ツリーが予期されたとおりに再コンバージェンスされる。
• リンクが再接続されると、スパニング ツリーが元のステートに戻る。
• リンクが再接続されると、VLAN トランクが正しく再形成される。
• リンクが再接続されるときに、ポートチャネルが正しく再設定される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 ポートチャネルの障害テストは正常に終了しました。
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 ポートチャネルの障害
このテストでは、dcap-7k-agg-1 と dcap-6k-acc-1 の間のポートチャネル リンク全体の障害による影響
を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、スパニング ツリーの適切な再コンバージェンスが行われることを
確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、スパニ
ング ツリーの再コンバージェンスを再度確認します。また、LACP を使用したチャネル メンバの正し
い再構築および VLAN トランクの再構築を確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-1 と dcap-6k-acc-1 を接続
するポートチャネルのステータスを確認します。
ステップ 3
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-63
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 4
dcap-7k-agg-1、dcap-7k-agg-2、および dcap-6k-acc-1 で show interface interface trunk コマンドを使
用して、この 3 つのスイッチを接続しているインターフェイスが正しくトランキングしていることを確
認します。
各インターフェイスで STP Forwarding としてリストされている VLAN に注目します。各インター
フェイスの VLAN のリストに、上記ステップ 3 のステートが反映されていれば正常です。
ステップ 5
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 6
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-6k-acc-1 が Po4 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しており、Po2 インターフェイスでマルチキャスト ト
ラフィックだけを受信していることを確認します。
ステップ 7
shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-6k-acc-1 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 8
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：なし
Cisco Data Center Assurance Program（DCAP）6.0
2-64
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：なし
• Po2：3、500、1301 ～ 1500
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-6k-acc-1 が Po2 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 10
トラフィックを停止し、リンク切断により発生したトラフィック ダウンタイムを測定します。
ステップ 11
テスト トラフィック フローを再開します。
ステップ 12
no shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-6k-acc-1 の間のリンクを再確立します。
ステップ 13
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-1 と dcap-6k-acc-1 を接続
するポートチャネルのステータスを確認します。
ステップ 14
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-65
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 15
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-6k-acc-1 が Po4 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しており、Po2 インターフェイスでマルチキャスト ト
ラフィックだけを受信していることを確認します。
ステップ 16
トラフィックを停止して、リンクがオンラインに戻るのに伴い発生したトラフィック ダウンタイムを
測定します。
ステップ 17
動作をもう一度確認するために、ここまでの 15 ステップを繰り返します。
ステップ 18
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 19
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、スパニング ツリーが予期されたとおりに再コンバージェンスされる。
• リンクが再接続されると、スパニング ツリーが元のステートに戻る。
• リンクが再接続されると、VLAN トランクが正しく再形成される。
• リンクが再接続されるときに、ポートチャネルが正しく再設定される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 ポートチャネルの障害テストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
2-66
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害
このテストでは、dcap-7k-agg-1 と dcap-7k-acc-1 の間のポートチャネル リンク全体の障害による影響
を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、スパニング ツリーの適切な再コンバージェンスが行われることを
確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、スパニ
ング ツリーの再コンバージェンスを再度確認します。また、LACP を使用したチャネル メンバの正し
い再構築および VLAN トランクの再構築を確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-1 と dcap-7k-acc-1 を接続
するポートチャネルのステータスを確認します。
ステップ 3
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-67
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 4
dcap-7k-agg-1、dcap-7k-agg-2、および dcap-7k-acc-1 で show interface interface trunk コマンドを使
用して、この 3 つのスイッチを接続しているインターフェイスが正しくトランキングしていることを確
認します。
各インターフェイスで STP Forwarding としてリストされている VLAN に注目します。各インター
フェイスの VLAN のリストに、上記ステップ 3 のステートが反映されていれば正常です。
ステップ 5
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 6
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しており、Po4 インターフェイスでマルチキャスト ト
ラフィックだけを受信していることを確認します。
ステップ 7
shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-7k-acc-1 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 8
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：なし
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
Cisco Data Center Assurance Program（DCAP）6.0
2-68
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：なし
• Po4：3、500、1301 ～ 1500
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 がユニキャスト トラフィックとマルチキャス
ト トラフィックを Po4 インターフェイスで受信していることを確認します。
ステップ 10
トラフィックを停止し、リンク切断により発生したトラフィック ダウンタイムを測定します。
ステップ 11
テスト トラフィック フローを再開します。
ステップ 12
no shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-7k-acc-1 の間のリンクを再確立します。
ステップ 13
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-1 と dcap-7k-acc-1 を接続
するポートチャネルのステータスを確認します。
ステップ 14
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-69
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 15
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しており、Po4 インターフェイスでマルチキャスト ト
ラフィックだけを受信していることを確認します。
ステップ 16
トラフィックを停止して、リンクがオンラインに戻るのに伴い発生したトラフィック ダウンタイムを
測定します。
ステップ 17
動作をもう一度確認するために、ここまでの 15 ステップを繰り返します。
ステップ 18
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 19
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、スパニング ツリーが予期されたとおりに再コンバージェンスされる。
• リンクが再接続されると、スパニング ツリーが元のステートに戻る。
• リンクが再接続されると、VLAN トランクが正しく再形成される。
• リンクが再接続されるときに、ポートチャネルが正しく再設定される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害テストは正常に終了しました。
dcap-7k-agg-1 と dcap-7k-agg-2 の間の L2 ポートチャネルの障害
このテストでは、dcap-7k-agg-1 と dcap-7k-agg-2 の間のポートチャネル リンク全体の障害による影響
を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、スパニング ツリーの適切な再コンバージェンスが行われることを
確認します。HSRP の安定性も確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、スパニ
ング ツリーの再コンバージェンスを再度確認します。また、LACP を使用したチャネル メンバの正し
い再構築、VLAN トランクの再構築、および HSRP の安定性を確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
Cisco Data Center Assurance Program（DCAP）6.0
2-70
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-7k-agg-1 と dcap-7k-agg-2 の間の L2 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-1 と dcap-7k-agg-2 を接
続するポートチャネルのステータスを確認します。
ステップ 3
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 4
dcap-7k-agg-1 と dcap-7k-agg-2 で show interface interface trunk コマンドを使用して、この 2 つのス
イッチを接続しているインターフェイスが正しくトランキングしていることを確認します。
各インターフェイスで STP Forwarding としてリストされている VLAN に注目します。各インター
フェイスの VLAN のリストに、上記ステップ 3 のステートが反映されていれば正常です。
ステップ 5
dcap-7k-agg-1 と dcap-7k-agg-2 で show hsrp brief コマンドを使用して、dcap-7k-agg-1 がすべての
VLAN インターフェイスで HSRP Active であり、dcap-7k-agg-2 がすべての VLAN インターフェイス
で Standby であることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-71
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 6
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-agg-1 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 8
shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-7k-agg-2 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 9
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイスでスパニング ツ
リーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：なし
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：なし
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1420
• Po6：3、500、1301 ～ 1420
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：1421 ～ 1500
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：1421 ～ 1500
ステップ 10
dcap-7k-agg-1 と dcap-7k-agg-2 で show hsrp brief コマンドを使用して、HSRP が引き続き安定して
いることを確認します。
ステップ 11
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-agg-1 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 12
トラフィックを停止し、リンク切断により発生したトラフィック ダウンタイムを測定します。
ステップ 13
テスト トラフィック フローを再開します。
ステップ 14
no shutdown コマンドを使用して、dcap-7k-agg-1 と dcap-7k-agg-2 の間のリンクを再確立します。
Cisco Data Center Assurance Program（DCAP）6.0
2-72
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 15
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-1 と dcap-7k-agg-2 を接
続するポートチャネルのステータスを確認します。
ステップ 16
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイスでスパニング ツ
リーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 17
dcap-7k-agg-1 と dcap-7k-agg-2 で show hsrp brief コマンドを使用して、HSRP が引き続き安定して
いることを確認します。
ステップ 18
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-agg-1 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 19
トラフィックを停止して、リンクがオンラインに戻るのに伴い発生したトラフィック ダウンタイムを
測定します。
ステップ 20
動作をもう一度確認するために、この直前までの 18 ステップを繰り返します。
ステップ 21
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-73
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 22
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、スパニング ツリーが予期されたとおりに再コンバージェンスされる。
• リンクが再接続されると、スパニング ツリーが元のステートに戻る。
• リンクが再接続されると、VLAN トランクが正しく再形成される。
• HSRP はこのテストを通じて安定している。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-7k-agg-2 の間の L2 ポートチャネルの障害テストは正常に終了しました。
dcap-7k-agg-2 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害
このテストでは、dcap-7k-agg-2 と dcap-7k-acc-1 の間のポートチャネル リンク全体の障害による影響
を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、スパニング ツリーの適切な再コンバージェンスが行われることを
確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、スパニ
ング ツリーの再コンバージェンスを再度確認します。また、LACP を使用したチャネル メンバの正し
い再構築および VLAN トランクの再構築を確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-agg-2 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-2 と dcap-7k-acc-1 を接続
するポートチャネルのステータスを確認します。
ステップ 3
show spanning-tree interface interface コマンドを使用して、レイヤ 2 ドメインのデバイスの
spanning-tree ステータスを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
Cisco Data Center Assurance Program（DCAP）6.0
2-74
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 4
dcap-7k-agg-1、dcap-7k-agg-2、および dcap-7k-acc-1 で show interface interface trunk コマンドを使
用して、この 3 つのスイッチを接続しているインターフェイスが正しくトランキングしていることを確
認します。
各インターフェイスで STP Forwarding としてリストされている VLAN に注目します。各インター
フェイスの VLAN のリストに、上記ステップ 3 のステートが反映されていれば正常です。
ステップ 5
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 6
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しているが、Po4 インターフェイスでは受信していな
いことを確認します。
ステップ 7
shutdown コマンドを使用して、dcap-7k-agg-2 と dcap-7k-acc-1 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 8
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-75
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：なし
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 9
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスで引き続きユニキャ
スト トラフィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 10
トラフィックを停止し、リンク切断により発生したトラフィック ダウンタイムを測定します。
ステップ 11
テスト トラフィック フローを再開します。
ステップ 12
no shutdown コマンドを使用して、dcap-7k-agg-2 と dcap-7k-acc-1 の間のリンクを再確立します。
ステップ 13
各 DUT で show port-channel summary コマンドを使用して、dcap-7k-agg-2 と dcap-7k-acc-1 を接続
するポートチャネルのステータスを確認します。
ステップ 14
show interface interface trunk コマンドを使用して、レイヤ 2 ドメイン内のデバイス間でスパニング
ツリーが正しく再コンバージェンスされたことを確認します。
dcap-7k-agg-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
• Po4：3、500、1301 ～ 1500
• Po6：3、500、1301 ～ 1420
dcap-7k-agg-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、1301 ～ 1500
• Eth3/2：3、500、1301 ～ 1500
• Po2：3、500、1301 ～ 1500
Cisco Data Center Assurance Program（DCAP）6.0
2-76
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• Po4：3、500、1301 ～ 1500
• Po6：500
dcap-4k-acc-2 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Te1/49：3、500、1301 ～ 1500
• Te1/50：なし
dcap-5k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po1：3、500、1301 ～ 1420
• Po2：3、500、1301 ～ 1420
dcap-6k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po4：3、500、1301 ～ 1500
• Po2：なし
dcap-7k-acc-1 で STP Forwarding ステートになることが予期される VLAN は次のとおりです。
• Po2：3、500、1301 ～ 1500
• Po4：なし
ステップ 15
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しているが、Po4 インターフェイスでは受信していな
いことを確認します。
ステップ 16
トラフィックを停止して、リンクがオンラインに戻るのに伴い発生したトラフィック ダウンタイムを
測定します。
ステップ 17
動作をもう一度確認するために、ここまでの 15 ステップを繰り返します。
ステップ 18
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 19
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、スパニング ツリーが予期されたとおりに再コンバージェンスされる。
• リンクが再接続されると、スパニング ツリーが元のステートに戻る。
• リンクが再接続されると、VLAN トランクが正しく再形成される。
• リンクが再接続されるときに、ポートチャネルが正しく再設定される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-2 と dcap-7k-acc-1 の間の L2 ポートチャネルの障害テストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-77
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害
このテストでは、dcap-7k-core-1 と dcap-7k-agg-1 の間の単一バンドル リンクの障害による影響を確
認します。
テスト トラフィック プロファイルの実行中、dcap-7k-core-1 と dcap-7k-agg-1 を接続しているポート
チャネルの 2 つのバンドル インターフェイスの一方をシャットダウンします。このバンドル リンクの
削除が原因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インター
フェイスから削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、この
リンクを経由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが
属しているポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスを 2 番目のバンドル リンクに対してもう 1 回繰り返します。
テスト手順
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害テストの実行手順は次のとおりで
す。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-1 と dcap-7k-agg-1 の間のポートチャネル リンクを経由する各種プロトコルのステータ
スを確認します。両方のデバイスでプロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po3
• PIM：show ip pim neighbor Po3
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある両方のバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-core-1 の Ethernet 1/2 インターフェイスをシャットダウンし
ます。
ステップ 6
コア デバイス間のポートチャネル リンクを経由する各種プロトコルのステータスを確認します。
dcap-7k-core-1 と dcap-7k-agg-1 の両方で、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po3
• PIM：show ip pim neighbor Po3
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-core-1 と dcap-7k-agg-1 の間のポートチャネルに残っている 1 つのリンクを介して送
信されていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使
用して、残っているバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
Cisco Data Center Assurance Program（DCAP）6.0
2-78
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 1/2 を dcap-7k-core-1 のポートチャネル 3 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
dcap-7k-core-1 と dcap-7k-agg-1 の間のポートチャネル リンクを経由する各種プロトコルのステータ
スを確認します。両方のテスト対象デバイスで、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po3
• PIM：show ip pim neighbor Po3
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-core-1 と dcap-7k-agg-1 の間のポートチャネルにある両方のバンドル リンクを介し
てロード バランスされていることを確認します。2 分間待機し、show interface interface | include
rate コマンドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、Ethernet 2/2 インターフェイス（ポートチャネル 3 バンド
ルのもう一方のメンバ）に障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害テストは正常に終了しました。
dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害
このテストでは、dcap-7k-core-1 と dcap-7k-agg-2 の間の単一バンドル リンクの障害による影響を確
認します。
テスト トラフィック プロファイルの実行中、dcap-7k-core-1 と dcap-7k-agg-2 を接続しているポート
チャネルの 2 つのバンドル インターフェイスの一方をシャットダウンします。このバンドル リンクの
削除が原因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インター
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-79
第2章
DCAP Nexus 7000 テスト
ネガティブ
フェイスから削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、この
リンクを経由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが
属しているポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスを 2 番目のバンドル リンクに対してもう 1 回繰り返します。
テスト手順
dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害テストの実行手順は次のとおりで
す。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-1 と dcap-7k-agg-2 の間のポートチャネル リンクを経由する各種プロトコルのステータ
スを確認します。両方のデバイスでプロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po5
• PIM：show ip pim neighbor Po5
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある両方のバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-core-1 の Ethernet 1/9 インターフェイスをシャットダウンし
ます。
ステップ 6
コア デバイス間のポートチャネル リンクを経由する各種プロトコルのステータスを確認します。
dcap-7k-core-1 と dcap-7k-agg-2 の両方で、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po5
• PIM：show ip pim neighbor Po5
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-core-1 と dcap-7k-agg-2 の間のポートチャネルに残っている 1 つのリンクを介して送
信されていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使
用して、残っているバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 1/9 を dcap-7k-core-1 のポートチャネル 5 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
dcap-7k-core-1 と dcap-7k-agg-2 の間のポートチャネル リンクを経由する各種プロトコルのステータ
スを確認します。両方のテスト対象デバイスで、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
Cisco Data Center Assurance Program（DCAP）6.0
2-80
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• OSPF：show ip ospf neighbor Po5
• PIM：show ip pim neighbor Po5
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-core-1 と dcap-7k-agg-2 の間のポートチャネルにある両方のバンドル リンクを介し
てロード バランスされていることを確認します。2 分間待機し、show interface interface | include
rate コマンドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、Ethernet 2/9 インターフェイス（ポートチャネル 5 バンド
ルのもう一方のメンバ）に障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害テストは正常に終了しました。
dcap-7k-core-1 と dcap-7k-core-2 の間の L3 バンドル リンクの障害
このテストでは、dcap-7k-core-1 と dcap-7k-core-2 の間の単一バンドル リンクの障害による影響を確
認します。
テスト トラフィック プロファイルの実行中、この 2 つのコア デバイスを接続しているポートチャネル
の 2 つのバンドル インターフェイスの一方をシャットダウンします。このバンドル リンクの削除が原
因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インターフェイスか
ら削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、このリンクを経
由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが属している
ポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスを 2 番目のバンドル リンクに対してもう 1 回繰り返します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-81
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-7k-core-1 と dcap-7k-core-2 の間の L3 バンドル リンクの障害テストの実行手順は次のとおりで
す。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
コア デバイス間のポートチャネル リンクを経由する各種プロトコルのステータスを確認します。
dcap-7k-core-1 と dcap-7k-core-2 の両方で、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po1
• PIM：show ip pim neighbor Po1
• MSDP：show ip msdp summary
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのコア デバイス間のポートチャネルにある両方のバンドル リンクを介してロード バラン
スされていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使
用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-core-1 の Ethernet 1/1 インターフェイスをシャットダウンし
ます。
ステップ 6
コア デバイス間のポートチャネル リンクを経由する各種プロトコルのステータスを確認します。
dcap-7k-core-1 と dcap-7k-core-2 の両方で、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po1
• PIM：show ip pim neighbor Po1
• MSDP：show ip msdp summary
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのコア デバイス間のポートチャネルに残っている 1 つのリンクを介して送信されているこ
とを確認します。2 分間待機し、show interface interface | include rate コマンドを使用して、残って
いるバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 1/1 を dcap-7k-core-1 のポートチャネル 1 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
コア デバイス間のポートチャネル リンクを経由する各種プロトコルのステータスを確認します。
dcap-7k-core-1 と dcap-7k-core-2 の両方で、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po1
• PIM：show ip pim neighbor Po1
• MSDP：show ip msdp summary
Cisco Data Center Assurance Program（DCAP）6.0
2-82
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのコア デバイス間のポートチャネルにある両方のバンドル リンクを介してロード バラン
スされていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使
用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、Ethernet 2/1 インターフェイス（ポートチャネル 1 バンド
ルのもう一方のメンバ）に障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 と dcap-7k-core-2 の間の L3 バンドル リンクの障害テストは正常に終了しました。
dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害
このテストでは、dcap-7k-core-2 と dcap-7k-agg-1 の間の単一バンドル リンクの障害による影響を確
認します。
テスト トラフィック プロファイルの実行中、dcap-7k-core-2 と dcap-7k-agg-1 を接続しているポート
チャネルの 2 つのバンドル インターフェイスの一方をシャットダウンします。このバンドル リンクの
削除が原因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インター
フェイスから削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、この
リンクを経由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが
属しているポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスを 2 番目のバンドル リンクに対してもう 1 回繰り返します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-83
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害テストの実行手順は次のとおりで
す。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-2 と dcap-7k-agg-1 の間のポートチャネル リンクを伝送される各種プロトコルのステー
タスを確認します。両方のデバイスでプロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po5
• PIM：show ip pim neighbor Po5
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある両方のバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-core-2 の Ethernet 1/9 インターフェイスをシャットダウンし
ます。
ステップ 6
コア デバイス間のポートチャネル リンクを経由する各種プロトコルのステータスを確認します。
dcap-7k-core-2 と dcap-7k-agg-1 の両方で、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po5
• PIM：show ip pim neighbor Po5
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-core-2 と dcap-7k-agg-1 の間のポートチャネルに残っている 1 つのリンクを介して送
信されていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使
用して、残っているバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 1/9 を dcap-7k-core-2 のポートチャネル 5 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
dcap-7k-core-2 と dcap-7k-agg-1 の間のポートチャネル リンクを伝送される各種プロトコルのステー
タスを確認します。両方のテスト対象デバイスで、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po5
• PIM：show ip pim neighbor Po5
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-core-2 と dcap-7k-agg-1 の間のポートチャネルにある両方のバンドル リンクを介し
てロード バランスされていることを確認します。2 分間待機し、show interface interface | include
rate コマンドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-84
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、Ethernet 2/9 インターフェイス（ポートチャネル 5 バンド
ルのもう一方のメンバ）に障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 バンドル リンクの障害テストは正常に終了しました。
dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害
このテストでは、dcap-7k-core-2 と dcap-7k-agg-2 の間の単一バンドル リンクの障害による影響を確
認します。
テスト トラフィック プロファイルの実行中、dcap-7k-core-2 と dcap-7k-agg-2 を接続しているポート
チャネルの 2 つのバンドル インターフェイスの一方をシャットダウンします。このバンドル リンクの
削除が原因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インター
フェイスから削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、この
リンクを経由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが
属しているポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスを 2 番目のバンドル リンクに対してもう 1 回繰り返します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-85
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害テストの実行手順は次のとおりで
す。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-2 と dcap-7k-agg-2 の間のポートチャネル リンクを伝送される各種プロトコルのステー
タスを確認します。両方のデバイスでプロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po3
• PIM：show ip pim neighbor Po3
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある両方のバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-core-2 の Ethernet 1/2 インターフェイスをシャットダウンし
ます。
ステップ 6
コア デバイス間のポートチャネル リンクを経由する各種プロトコルのステータスを確認します。
dcap-7k-core-2 と dcap-7k-agg-2 の両方で、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po3
• PIM：show ip pim neighbor Po3
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-core-2 と dcap-7k-agg-2 の間のポートチャネルに残っている 1 つのリンクを介して送
信されていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使
用して、残っているバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 1/2 を dcap-7k-core-2 のポートチャネル 3 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
dcap-7k-core-2 と dcap-7k-agg-2 の間のポートチャネル リンクを伝送される各種プロトコルのステー
タスを確認します。両方のテスト対象デバイスで、プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• OSPF：show ip ospf neighbor Po3
• PIM：show ip pim neighbor Po3
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-core-2 と dcap-7k-agg-2 の間のポートチャネルにある両方のバンドル リンクを介し
てロード バランスされていることを確認します。2 分間待機し、show interface interface | include
rate コマンドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-86
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、Ethernet 2/2 インターフェイス（ポートチャネル 3 バンド
ルのもう一方のメンバ）に障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 バンドル リンクの障害テストは正常に終了しました。
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害
このテストでは、dcap-7k-core-1 と dcap-7k-agg-1 の間のポートチャネル リンク全体の障害による影
響を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、PIM sparse モードの適切な再コンバージェンスが行われることを
確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、sparse
モードのコンバージェンスを確認します。また、LACP を使用したチャネル メンバの正しい再構築、
OSPF 近隣関係の再構築、および PIM ネイバーの再確立を確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-1 を dcap-7k-agg-1 に接続するポートチャネルのステータスと、このポートチャネルを経
由するプロトコルを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-87
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 5
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-agg-1 の正しいインターフェイスを経由していることを確認します。
ステップ 6
shutdown コマンドを使用して、dcap-7k-core-1 と dcap-7k-agg-1 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 7
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの切断によるトラフィック ダウンタイムを測定します。
ステップ 8
テスト トラフィック フローを再開します。
ステップ 9
トポロジに含まれる 4 つのレイヤ 3 デバイスで show ip mroute summary count コマンドと show ip
mroute コマンドを使用して、マルチキャスト ルーティングが正常に再コンバージェンスされたことを
確認します。
ステップ 10
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-agg-1 の正しいインターフェイスを経由していることを確認します。
ステップ 11
no shutdown コマンドを使用して、この 2 つのコア デバイス間のリンクが再確立します。
ステップ 12
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの再確立によるトラフィック ダウンタイムを測定します。
ステップ 13
テスト トラフィックを再開します。
ステップ 14
dcap-7k-core-1 を dcap-7k-agg-1 に接続するポートチャネルのステータスと、このポートチャネルを経
由するプロトコルを確認します。
ステップ 15
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 16
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-agg-1 の正しいインターフェイスを経由していることを確認します。
ステップ 17
テスト トラフィックを停止します。
ステップ 18
動作をもう一度確認するために、この直前までの 13 ステップを繰り返します。
ステップ 19
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 20
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
Cisco Data Center Assurance Program（DCAP）6.0
2-88
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• リンクが切断されると、マルチキャスト ルーティングが予期されたように再コンバージェンスさ
れる。
• リンクが再接続されると、マルチキャスト ルーティングが元のステートに戻る。
• 切断されたリンクが再接続されたときに、リンクで実行されている他のプロトコル（OSPF、PIM、
LACP）が正常に機能する。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害テストは正常に終了しました。
dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害
このテストでは、dcap-7k-core-1 と dcap-7k-agg-2 の間のポートチャネル リンク全体の障害による影
響を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、PIM sparse モードの適切な再コンバージェンスが行われることを
確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、sparse
モードのコンバージェンスを確認します。また、LACP を使用したチャネル メンバの正しい再構築、
OSPF 近隣関係の再構築、および PIM ネイバーの再確立を確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-1 を dcap-7k-agg-2 に接続するポートチャネルのステータスと、このポートチャネルを経
由するプロトコルを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 5
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 6
shutdown コマンドを使用して、dcap-7k-core-1 と dcap-7k-agg-2 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 7
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの切断によるトラフィック ダウンタイムを測定します。
ステップ 8
テスト トラフィック フローを再開します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-89
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 9
トポロジに含まれる 4 つのレイヤ 3 デバイスで show ip mroute summary count コマンドと show ip
mroute コマンドを使用して、マルチキャスト ルーティングが正常に再コンバージェンスされたことを
確認します。
ステップ 10
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 11
no shutdown コマンドを使用して、この 2 つのコア デバイス間のリンクが再確立します。
ステップ 12
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの再確立によるトラフィック ダウンタイムを測定します。
ステップ 13
テスト トラフィックを再開します。
ステップ 14
dcap-7k-core-1 を dcap-7k-agg-2 に接続するポートチャネルのステータスと、このポートチャネルを経
由するプロトコルを確認します。
ステップ 15
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 16
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 17
テスト トラフィックを停止します。
ステップ 18
動作をもう一度確認するために、この直前までの 13 ステップを繰り返します。
ステップ 19
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 20
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、マルチキャスト ルーティングが予期されたように再コンバージェンスさ
れる。
• リンクが再接続されると、マルチキャスト ルーティングが元のステートに戻る。
• 切断されたリンクが再接続されたときに、リンクで実行されている他のプロトコル（OSPF、PIM、
LACP）が正常に機能する。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害テストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
2-90
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-7k-core-1 と dcap-7k-core-2 の間の L3 ポートチャネルの障害
このテストでは、dcap-7k-core-1 と dcap-7k-core-2 の間のポートチャネル リンク全体の障害による影
響を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、PIM sparse モードの適切な再コンバージェンスが行われることを
確認します。この 2 つのコア デバイス間の MSDP ピアリングのメンテナンスも検証します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、sparse
モードのコンバージェンスを確認します。また、LACP を使用したチャネル メンバの正しい再構築、
OSPF 近隣関係の再構築、および PIM ネイバーの再確立を確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-core-1 と dcap-7k-core-2 の間の L3 ポートチャネルの障害テストの実行手順は次のとおりで
す。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-1 を dcap-7k-core-2 に接続するポートチャネルのステータスと、このポートチャネルを
経由するプロトコルを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 5
show ip msdp peer コマンドを使用して、この 2 つのコア デバイスが MSDP ピアであることを確認し
ます。
ステップ 6
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-core-2 の正しいインターフェイスを経由していることを確認します。
ステップ 7
shutdown コマンドを使用して、dcap-7k-core-1 と dcap-7k-core-2 を接続しているポートチャネル イ
ンターフェイスを切断します。
ステップ 8
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの切断によるトラフィック ダウンタイムを測定します。
ステップ 9
テスト トラフィック フローを再開します。
ステップ 10
トポロジに含まれる 4 つのレイヤ 3 デバイスで show ip mroute summary count コマンドと show ip
mroute コマンドを使用して、マルチキャスト ルーティングが正常に再コンバージェンスされたことを
確認します。
ステップ 11
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-core-2 の正しいインターフェイスを経由していることを確認します。
show ip msdp peer コマンドを使用して、この 2 つのコア デバイスが MSDP ピアであることを確認し
ます。
ステップ 13
no shutdown コマンドを使用して、この 2 つのコア デバイス間のリンクが再確立します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-91
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 14
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの再確立によるトラフィック ダウンタイムを測定します。
ステップ 15
テスト トラフィックを再開します。
ステップ 16
dcap-7k-core-1 を dcap-7k-core-2 に接続するポートチャネルのステータスと、このポートチャネルを
経由するプロトコルを確認します。
ステップ 17
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 18
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-1 と dcap-7k-core-2 の正しいインターフェイスを経由していることを確認します。
ステップ 19
テスト トラフィックを停止します。
ステップ 20
動作をもう一度確認するために、この直前までの 13 ステップを繰り返します。
ステップ 21
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 22
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、マルチキャスト ルーティングが予期されたように再コンバージェンスさ
れる。
• リンクが再接続されると、マルチキャスト ルーティングが元のステートに戻る。
• 切断されたリンクが再接続されたときに、リンクで実行されている他のプロトコル（OSPF、PIM、
LACP）が正常に機能する。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 と dcap-7k-core-2 の間の L3 ポートチャネルの障害テストは正常に終了しました。
dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害
このテストでは、dcap-7k-core-2 と dcap-7k-agg-1 の間のポートチャネル リンク全体の障害による影
響を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、PIM sparse モードの適切な再コンバージェンスが行われることを
確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、sparse
モードのコンバージェンスを確認します。また、LACP を使用したチャネル メンバの正しい再構築、
OSPF 近隣関係の再構築、および PIM ネイバーの再確立を確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-92
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-2 を dcap-7k-agg-1 に接続するポートチャネルのステータスと、このポートチャネルを経
由するプロトコルを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 5
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-2 と dcap-7k-agg-1 の正しいインターフェイスを経由していることを確認します。
ステップ 6
shutdown コマンドを使用して、dcap-7k-core-2 と dcap-7k-agg-1 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 7
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの切断によるトラフィック ダウンタイムを測定します。
ステップ 8
テスト トラフィック フローを再開します。
ステップ 9
トポロジに含まれる 4 つのレイヤ 3 デバイスで show ip mroute summary count コマンドと show ip
mroute コマンドを使用して、マルチキャスト ルーティングが正常に再コンバージェンスされたことを
確認します。
ステップ 10
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-2 と dcap-7k-agg-1 の正しいインターフェイスを経由していることを確認します。
ステップ 11
no shutdown コマンドを使用して、この 2 つのコア デバイス間のリンクが再確立します。
ステップ 12
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの再確立によるトラフィック ダウンタイムを測定します。
ステップ 13
テスト トラフィックを再開します。
ステップ 14
dcap-7k-core-2 を dcap-7k-agg-1 に接続するポートチャネルのステータスと、このポートチャネルを経
由するプロトコルを確認します。
ステップ 15
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 16
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-2 と dcap-7k-agg-1 の正しいインターフェイスを経由していることを確認します。
ステップ 17
テスト トラフィックを停止します。
ステップ 18
動作をもう一度確認するために、この直前までの 13 ステップを繰り返します。
ステップ 19
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-93
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 20
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、マルチキャスト ルーティングが予期されたように再コンバージェンスさ
れる。
• リンクが再接続されると、マルチキャスト ルーティングが元のステートに戻る。
• 切断されたリンクが再接続されたときに、リンクで実行されている他のプロトコル（OSPF、PIM、
LACP）が正常に機能する。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-2 と dcap-7k-agg-1 の間の L3 ポートチャネルの障害テストは正常に終了しました。
dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害
このテストでは、dcap-7k-core-2 と dcap-7k-agg-2 の間のポートチャネル リンク全体の障害による影
響を確認します。
テスト トラフィック プロファイルの実行中に、ポートチャネル インターフェイスをシャットダウンし
ます。トラフィック損失を測定し、PIM sparse モードの適切な再コンバージェンスが行われることを
確認します。
ポートチャネル インターフェイスがオンラインに戻ったら、トラフィック損失を再度測定し、sparse
モードのコンバージェンスを確認します。また、LACP を使用したチャネル メンバの正しい再構築、
OSPF 近隣関係の再構築、および PIM ネイバーの再確立を確認します。
動作の一貫性を確認するために、インターフェイス フラップ シーケンスをもう一回繰り返します（合
計 2 回）。
テスト手順
dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-core-2 を dcap-7k-agg-2 に接続するポートチャネルのステータスと、このポートチャネルを経
由するプロトコルを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-94
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 5
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-2 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 6
shutdown コマンドを使用して、dcap-7k-core-2 と dcap-7k-agg-2 を接続しているポートチャネル イン
ターフェイスを切断します。
ステップ 7
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの切断によるトラフィック ダウンタイムを測定します。
ステップ 8
テスト トラフィック フローを再開します。
ステップ 9
トポロジに含まれる 4 つのレイヤ 3 デバイスで show ip mroute summary count コマンドと show ip
mroute コマンドを使用して、マルチキャスト ルーティングが正常に再コンバージェンスされたことを
確認します。
ステップ 10
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-2 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 11
no shutdown コマンドを使用して、この 2 つのコア デバイス間のリンクが再確立します。
ステップ 12
トポロジが再コンバージェンスされ、トラフィックが送信側と受信側の間で再び正常に伝送されるよう
になったら、トラフィックを停止し、リンクの再確立によるトラフィック ダウンタイムを測定します。
ステップ 13
テスト トラフィックを再開します。
ステップ 14
dcap-7k-core-2 を dcap-7k-agg-2 に接続するポートチャネルのステータスと、このポートチャネルを経
由するプロトコルを確認します。
ステップ 15
show ip mroute summary count コマンドと show ip mroute コマンドを使用して、dcap-7k-core-1、
dcap-7k-core-2、dcap-7k-agg-1、および dcap-7k-agg-2 のマルチキャスト ルーティング テーブルのス
テートを確認します。
ステップ 16
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックが
dcap-7k-core-2 と dcap-7k-agg-2 の正しいインターフェイスを経由していることを確認します。
ステップ 17
テスト トラフィックを停止します。
ステップ 18
動作をもう一度確認するために、この直前までの 13 ステップを繰り返します。
ステップ 19
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 20
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• リンクのシャットダウンにより、2 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴い、2 秒未満のトラフィック損失が発生する。
• リンクが切断されると、マルチキャスト ルーティングが予期されたように再コンバージェンスさ
れる。
• リンクが再接続されると、マルチキャスト ルーティングが元のステートに戻る。
• 切断されたリンクが再接続されたときに、リンクで実行されている他のプロトコル（OSPF、PIM、
LACP）が正常に機能する。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-95
第2章
DCAP Nexus 7000 テスト
ネガティブ
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-2 と dcap-7k-agg-2 の間の L3 ポートチャネルの障害テストは正常に終了しました。
dcap-7k-agg-1 と dcap-5k-acc-1 の間のレイヤ 2 バンドル リンクの障害
このテストでは、dcap-7k-agg-1 と dcap-5k-acc-1 の間の単一バンドル リンクの障害による影響を確認
します。
テスト トラフィック プロファイルの実行中、dcap-7k-agg-1 と dcap-5k-acc-1 を接続しているポート
チャネルの 4 つのバンドル インターフェイスの 1 つをシャットダウンします。このバンドル リンクの
削除が原因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インター
フェイスから削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、この
リンクを経由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが
属しているポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスは他のバンドル リンクに対してもう 1 回繰り返します。
テスト手順
dcap-7k-agg-1 と dcap-5k-acc-1 の間のレイヤ 2 バンドル リンクの障害テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-agg-1 と dcap-5k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある 4 つのバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-agg-1 の Ethernet 3/1 インターフェイスをシャットダウンし
ます。
ステップ 6
dcap-7k-agg-1 と dcap-5k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
Cisco Data Center Assurance Program（DCAP）6.0
2-96
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-agg-1 と dcap-5k-acc-1 の間のポートチャネルに残っている 3 つのリンクを介して送
信されていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使
用して、残っているバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 3/1 を dcap-7k-agg-1 のポートチャネル 6 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
dcap-7k-agg-1 と dcap-5k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある 4 つのバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、ポートチャネル 6 の Ethernet 4/1 、Ethernet 4/2、および
Ethernet 9/1 の他のバンドル インターフェイスに障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-97
第2章
DCAP Nexus 7000 テスト
ネガティブ
結果
dcap-7k-agg-1 と dcap-5k-acc-1 の間のレイヤ 2 バンドル リンクの障害テストは正常に終了しました。
dcap-7k-agg-1 と dcap-6k-acc-1 の間のレイヤ 2 バンドル リンクの障害
このテストでは、dcap-7k-agg-1 と dcap-6k-acc-1 の間の単一バンドル リンクの障害による影響を確認
します。
テスト トラフィック プロファイルの実行中、dcap-7k-agg-1 と dcap-6k-acc-1 を接続しているポート
チャネルの 2 つのバンドル インターフェイスの一方をシャットダウンします。このバンドル リンクの
削除が原因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インター
フェイスから削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、この
リンクを経由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが
属しているポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスを 2 番目のバンドル リンクに対してもう 1 回繰り返します。
テスト手順
dcap-7k-agg-1 と dcap-6k-acc-1 の間のレイヤ 2 バンドル リンクの障害テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-agg-1 と dcap-6k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある 2 つのバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-agg-1 の Ethernet 7/2 インターフェイスをシャットダウンし
ます。
ステップ 6
dcap-7k-agg-1 と dcap-6k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
Cisco Data Center Assurance Program（DCAP）6.0
2-98
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-agg-1 と dcap-6k-acc-1 の間のポートチャネルに残っているリンクを介して送信され
ていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使用して、
残っているバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 7/2 を dcap-7k-agg-1 のポートチャネル 4 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
dcap-7k-agg-1 と dcap-6k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある 2 つのバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、ポートチャネル 4 の Ethernet 8/2 の他のバンドル インター
フェイスに障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-6k-acc-1 の間のレイヤ 2 バンドル リンクの障害テストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-99
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-7k-agg-1 と dcap-7k-acc-1 の間のレイヤ 2 バンドル リンクの障害
このテストでは、dcap-7k-agg-1 と dcap-7k-acc-1 の間の単一バンドル リンクの障害による影響を確認
します。
テスト トラフィック プロファイルの実行中、dcap-7k-agg-1 と dcap-7k-acc-1 を接続しているポート
チャネルの 2 つのバンドル インターフェイスの一方をシャットダウンします。このバンドル リンクの
削除が原因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インター
フェイスから削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、この
リンクを経由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが
属しているポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスを 2 番目のバンドル リンクに対してもう 1 回繰り返します。
テスト手順
dcap-7k-agg-1 と dcap-7k-acc-1 の間のレイヤ 2 バンドル リンクの障害テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-agg-1 と dcap-7k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある 2 つのバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-agg-1 の Ethernet 7/1 インターフェイスをシャットダウンし
ます。
ステップ 6
dcap-7k-agg-1 と dcap-7k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
Cisco Data Center Assurance Program（DCAP）6.0
2-100
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-agg-1 と dcap-7k-acc-1 の間のポートチャネルに残っているリンクを介して送信され
ていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使用して、
残っているバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 7/1 を dcap-7k-agg-1 のポートチャネル 2 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
dcap-7k-agg-1 と dcap-7k-acc-1 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある 2 つのバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、ポートチャネル 2 の Ethernet 8/1 の他のバンドル インター
フェイスに障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-7k-acc-1 の間のレイヤ 2 バンドル リンクの障害テストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-101
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-7k-agg-1 と dcap-7k-agg-2 の間のレイヤ 2 バンドル リンクの障害
このテストでは、dcap-7k-agg-1 と dcap-7k-agg-1 の間の単一バンドル リンクの障害による影響を確認
します。
テスト トラフィック プロファイルの実行中、dcap-7k-agg-1 と dcap-7k-agg-2 を接続しているポート
チャネルの 2 つのバンドル インターフェイスの一方をシャットダウンします。このバンドル リンクの
削除が原因のトラフィック損失を測定します。リンクを 1 つだけバンドル ポートチャネル インター
フェイスから削除した後、ポートチャネルの少なくとも 1 つのリンクが引き続き機能する場合に、この
リンクを経由するどのプロトコルにも影響が出なければ正常です。この手順では、切断されたリンクが
属しているポートチャネル インターフェイスを経由するプロトコルに影響がないことを確認します。
オンラインに戻ったバンドル リンクは、ポートチャネルに再び集約され、ロード バランス プールに追
加されれば正常です。この手順ではこのことを確認します。
動作の一貫性を確認するため、およびロード バランス アルゴリズムを実行するために、リンク フラッ
プ シーケンスを 2 番目のバンドル リンクに対してもう 1 回繰り返します。
テスト手順
dcap-7k-agg-1 と dcap-7k-agg-2 の間のレイヤ 2 バンドル リンクの障害テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
dcap-7k-agg-1 と dcap-7k-agg-2 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 3
テスト トラフィック プロファイルを開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある 2 つのバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 5
shutdown コマンドを使用して、dcap-7k-agg-1 の Ethernet 1/1 インターフェイスをシャットダウンし
ます。
ステップ 6
dcap-7k-agg-1 と dcap-7k-agg-2 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
Cisco Data Center Assurance Program（DCAP）6.0
2-102
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、dcap-7k-agg-1 と dcap-7k-agg-2 の間のポートチャネルに残っているリンクを介して送信され
ていることを確認します。2 分間待機し、show interface interface | include rate コマンドを使用して、
残っているバンドル インターフェイスのトラフィック レートが上がったことを確認します。
ステップ 8
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 9
テスト トラフィック プロファイルを開始します。
ステップ 10
no shutdown コマンドを使用して、Ethernet 1/1 を dcap-7k-agg-1 のポートチャネル 1 バンドルのアク
ティブ ポートとして復旧します。
ステップ 11
dcap-7k-agg-1 と dcap-7k-agg-2 の間のポートチャネル リンクを経由する各種プロトコルのステータス
を確認します。プロトコルに応じて次のコマンドを使用します。
• LACP：show port-channel summary
• HSRP：show hsrp brief
• PIM：show ip pim neighbor
• STP：show spanning-tree summary
ステップ 12
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、ユニキャスト トラフィックとマルチキャスト トラフィックの
両方が、2 つのテスト対象デバイス間のポートチャネルにある 2 つのバンドル リンクを介してロード
バランスされていることを確認します。2 分間待機し、show interface interface | include rate コマン
ドを使用して、各バンドル インターフェイスのトラフィック レートを確認します。
ステップ 13
テスト トラフィックを停止し、トラフィック損失に基づいてダウンタイムを測定します。
ステップ 14
ステップ 2 ～ 13 を繰り返します。今回は、ポートチャネル 1 の Ethernet 2/1 の他のバンドル インター
フェイスに障害を発生させてから、再度イネーブルにします。
ステップ 15
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 16
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• バンドル リンクのシャットダウンにより、1 秒未満のトラフィック損失が発生する。
• リンクがオンラインに戻るのに伴うトラフィック損失は発生しない。
• リンクを経由するトラフィックは、ポートチャネル バンドルに残っているリンクに再配布される。
• リンクが再接続され、バンドルに再び集約されると、トラフィックの負荷分散への参加を再開す
る。
• ポートチャネル バンドルを経由するプロトコルは、単一バンドル メンバに障害が発生しても影響
を受けない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-7k-agg-2 の間のレイヤ 2 バンドル リンクの障害テストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-103
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 バンドル リンクのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-4k-acc-2 と dcap-7k-agg-1 の間のリンクを繰り返しフラップし、ネットワークに対する影響を監
視します。
このテストでは、アクティブ HSRP スイッチへのリンクを 1,000 回フラップします。リンクをフラッ
プしてダウンさせてからアップに戻し、次のフラップまでの間に 3 秒の安定期間を設けます。
テスト手順
dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 バンドル リンクのフラップの繰り返しテストの実行手順は
次のとおりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
show interface interface status コマンドを発行して、dcap-7k-agg-1 と dcap-4k-acc-2 の間のリンクの
ステートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-4k-acc-1 が Te1/49 インターフェイスでユニキャスト ト
ラフィックとマルチキャスト トラフィックを受信しており、Te1/50 インターフェイスでマルチキャス
ト トラフィックだけを受信していることを確認します。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、3 秒間の待機の順序で、デバイス間のイン
ターフェイスを繰り返しフラップします。
ステップ 6
show interface interface status コマンドを発行して、dcap-7k-agg-1 と dcap-4k-acc-2 の間のリンクの
ステートを確認します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-4k-acc-1 が Te1/49 インターフェイスでユニキャスト ト
ラフィックとマルチキャスト トラフィックを受信しており、Te1/50 インターフェイスでマルチキャス
ト トラフィックだけを受信していることを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-4k-acc-2 の間の L2 バンドル リンクのフラップの繰り返しテストは正常に終了
しました。
Cisco Data Center Assurance Program（DCAP）6.0
2-104
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-5k-acc-1 と dcap-7k-agg-1 の間のバンドル ポートチャネル リンクを繰り返しフラップし、ネット
ワークに対する影響を監視します。
このテストでは、アクティブ HSRP スイッチへのバンドル ポートチャネル リンクを 1,000 回フラップ
します。リンクをフラップしてダウンさせてからアップに戻し、次のフラップまでの間に 20 秒の安定
期間を設けます。
テスト手順
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクのフラップの繰り返しテストの実行手順は
次のとおりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-5k-acc-1 の間のリンクのス
テートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-5k-acc-1 が Po1 インターフェイスと Eth1/5 インター
フェイスでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po2 イン
ターフェイスでは受信していないことを確認します。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、20 秒間の待機の順序で、デバイス間のイ
ンターフェイスを繰り返しフラップします。
ステップ 6
show interface interface status コマンドを発行して、dcap-7k-agg-1 と dcap-5k-acc-1 の間のリンクの
ステートを確認します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-5k-acc-1 が Po1 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しているが、Po2 インターフェイスでは受信していな
いことを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-105
第2章
DCAP Nexus 7000 テスト
ネガティブ
結果
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 バンドル リンクのフラップの繰り返しテストは正常に終了
しました。
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 バンドル リンクのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-6k-acc-1 と dcap-7k-agg-1 の間のバンドル ポートチャネル リンクを繰り返しフラップし、ネット
ワークに対する影響を監視します。
このテストでは、アクティブ HSRP スイッチへのバンドル ポートチャネル リンクを 1,000 回フラップ
します。リンクをフラップしてダウンさせてからアップに戻し、次のフラップまでの間に 10 秒の安定
期間を設けます。
テスト手順
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 バンドル リンクのフラップの繰り返しテストの実行手順は
次のとおりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
show etherchannel summary コマンドを発行して、dcap-7k-agg-1 と dcap-6k-acc-1 の間のリンクのス
テートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-6k-acc-1 が Po4 インターフェイスと Te1/3 インター
フェイスでユニキャスト トラフィックとマルチキャスト トラフィックを受信しており、Po2 インター
フェイスでマルチキャスト トラフィックだけを受信していることを確認します。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、10 秒間の待機の順序で、デバイス間のイ
ンターフェイスを繰り返しフラップします。
ステップ 6
show etherchannel summary コマンドを発行して、dcap-7k-agg-1 と dcap-6k-acc-1 の間のリンクのス
テートを確認します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-6k-acc-1 が Po4 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信しており、Po2 インターフェイスでマルチキャスト ト
ラフィックだけを受信していることを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
Cisco Data Center Assurance Program（DCAP）6.0
2-106
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 バンドル リンクのフラップの繰り返しテストは正常に終了
しました。
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 バンドル リンクのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-7k-acc-1 と dcap-7k-agg-1 の間のバンドル ポートチャネル リンクを繰り返しフラップし、ネット
ワークに対する影響を監視します。
このテストでは、アクティブ HSRP スイッチへのバンドル ポートチャネル リンクを 1,000 回フラップ
します。リンクをフラップしてダウンさせてからアップに戻し、次のフラップまでの間に 10 秒の安定
期間を設けます。
テスト手順
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 バンドル リンクのフラップの繰り返しテストの実行手順は
次のとおりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-7k-acc-1 の間のリンクのス
テートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスと Eth1/17 インター
フェイスでユニキャスト トラフィックとマルチキャスト トラフィックを受信しており、Po4 インター
フェイスでマルチキャスト トラフィックだけを受信していることを確認します。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、10 秒間の待機の順序で、デバイス間のイ
ンターフェイスを繰り返しフラップします。
ステップ 6
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-7k-acc-1 の間のリンクのス
テートを確認します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスと Eth1/17 インター
フェイスでユニキャスト トラフィックとマルチキャスト トラフィックを受信しており、Po4 インター
フェイスでマルチキャスト トラフィックだけを受信していることを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-107
第2章
DCAP Nexus 7000 テスト
ネガティブ
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 バンドル リンクのフラップの繰り返しテストは正常に終了
しました。
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 チャネルのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-5k-acc-1 と dcap-7k-agg-1 の間のバンドル ポートチャネルを繰り返しフラップし、ネットワーク
に対する影響を監視します。
このテストでは、アクティブ HSRP スイッチへのバンドル ポートチャネルを 1,000 回フラップします。
リンクをフラップしてダウンさせてからアップに戻し、次のフラップまでの間に 20 秒の安定期間を設
けます。
テスト手順
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 チャネルのフラップの繰り返しテストの実行手順は次のと
おりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-5k-acc-1 の間のリンクのス
テートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-5k-acc-1 が Po1 インターフェイスとそのすべての設定
メンバでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po2 インター
フェイスでは受信していないことを確認します。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、20 秒間の待機の順序で、デバイス間のイ
ンターフェイスを繰り返しフラップします。
ステップ 6
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-5k-acc-1 の間のリンクのス
テートを確認します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-5k-acc-1 が Po1 インターフェイスとそのすべての設定
メンバでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po2 インター
フェイスでは受信していないことを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
Cisco Data Center Assurance Program（DCAP）6.0
2-108
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-5k-acc-1 の間の L2 チャネルのフラップの繰り返しテストは正常に終了しまし
た。
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 チャネルのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-6k-acc-1 と dcap-7k-agg-1 の間のバンドル ポートチャネルを繰り返しフラップし、ネットワーク
に対する影響を監視します。
このテストでは、アクティブ HSRP スイッチへのバンドル ポートチャネルを 1,000 回フラップします。
リンクをフラップしてダウンさせてからアップに戻し、次のフラップまでの間に 10 秒の安定期間を設
けます。
テスト手順
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 チャネルのフラップの繰り返しテストの実行手順は次のと
おりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
show etherchannel summary コマンドを発行して、dcap-7k-agg-1 と dcap-6k-acc-1 の間のリンクのス
テートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-6k-acc-1 が Po4 インターフェイスとそのすべてのバン
ドル メンバでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po2 イン
ターフェイスではマルチキャスト トラフィックだけを受信していることを確認します。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、10 秒間の待機の順序で、デバイス間のイ
ンターフェイスを繰り返しフラップします。
ステップ 6
show etherchannel summary コマンドを発行して、dcap-7k-agg-1 と dcap-6k-acc-1 の間のリンクのス
テートを確認します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-6k-acc-1 が Po4 インターフェイスとそのすべてのバン
ドル メンバでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po2 イン
ターフェイスではマルチキャスト トラフィックだけを受信していることを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-109
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-6k-acc-1 の間の L2 チャネルのフラップの繰り返しテストは正常に終了しまし
た。
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 チャネルのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-7k-acc-1 と dcap-7k-agg-1 の間のバンドル ポートチャネルを繰り返しフラップし、ネットワーク
に対する影響を監視します。
このテストでは、アクティブ HSRP スイッチへのバンドル ポートチャネルを 1,000 回フラップします。
リンクをフラップしてダウンさせてからアップに戻し、次のフラップまでの間に 10 秒の安定期間を設
けます。
テスト手順
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 チャネルのフラップの繰り返しテストの実行手順は次のと
おりです。
ステップ 1
ステップ 2
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-7k-acc-1 の間のリンクのス
テートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスとそのすべてのバン
ドル メンバでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po4 イン
ターフェイスではマルチキャスト トラフィックだけを受信していることを確認します。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、10 秒間の待機の順序で、デバイス間のイ
ンターフェイスを繰り返しフラップします。
ステップ 6
show interface interface status コマンドを発行して、dcap-7k-agg-1 と dcap-7k-acc-1 の間のリンクの
ステートを確認します。
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-acc-1 が Po2 インターフェイスとそのすべてのバン
ドル メンバでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているが、Po4 イン
ターフェイスではマルチキャスト トラフィックだけを受信していることを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-110
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-agg-1 と dcap-7k-acc-1 の間の L2 チャネルのフラップの繰り返しテストは正常に終了しまし
たが、例外が発生しました。検出された例外は CSCsu66282 です。
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-7k-core-1 と dcap-7k-agg-1 の間のバンドル ポートチャネル リンクを繰り返しフラップし、ネッ
トワークに対する影響を監視します。
このテストでは、アクティブ HSRP スイッチとコア スイッチの間のバンドル ポートチャネル リンクを
1,000 回フラップします。リンクをフラップしてダウンさせてからアップに戻し、次のフラップまでの
間に 10 秒の安定期間を設けます。
テスト手順
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクのフラップの繰り返しテストの実行手順は
次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-7k-core-1 の間のリンクの
ステートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-core-1 が Po3 インターフェイスと Eth1/2 インター
フェイスでユニキャスト トラフィックとマルチキャスト トラフィックを受信していることを確認しま
す。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、10 秒間の待機の順序で、デバイス間のイ
ンターフェイスを繰り返しフラップします。
ステップ 6
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-7k-core-1 の間のリンクの
ステートを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-111
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-core-1 が Po3 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 バンドル リンクのフラップの繰り返しテストは正常に終了
しました。
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 チャネルのフラップの繰り返し
このテストでは、テスト対象デバイスのシステム安定性機能を検証します。このテストでは、
dcap-7k-core-1 と dcap-7k-agg-1 の間のバンドル ポートチャネルを繰り返しフラップし、ネットワー
クに対する影響を監視します。
このテストでは、アクティブ HSRP スイッチとコア スイッチの間のバンドル ポートチャネルを 1,000
回フラップします。リンクをフラップしてダウンさせてからアップに戻し、次のフラップまでの間に
10 秒の安定期間を設けます。
テスト手順
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 チャネルのフラップの繰り返しテストの実行手順は次のと
おりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
show port-channel summary コマンドを発行して、dcap-7k-agg-1 と dcap-7k-core-1 の間のリンクの
ステートを確認します。
ステップ 3
Ixia テスト プロファイル トラフィックの送信を開始します。
ステップ 4
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-core-1 が Po3 インターフェイスでユニキャスト トラ
フィックとマルチキャスト トラフィックを受信していることを確認します。
ステップ 5
shutdown コマンドの発行、no shutdown コマンドの発行、10 秒間の待機の順序で、デバイス間のイ
ンターフェイスを繰り返しフラップします。
ステップ 6
show interface interface status コマンドを発行して、dcap-7k-agg-1 と dcap-7k-core-1 の間のリンクの
ステートを確認します。
Cisco Data Center Assurance Program（DCAP）6.0
2-112
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 7
clear counters コマンドを使用してインターフェイス カウンタをクリアした後、show interface
interface counters コマンドを使用して、dcap-7k-core-1 が Po3 インターフェイスとそのすべてのバン
ドル インターフェイスでユニキャスト トラフィックとマルチキャスト トラフィックを受信しているこ
とを確認します。
ステップ 8
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 9
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ネットワークがリンク障害の繰り返しを適切に処理する。
• リンク障害の繰り返しによるシステム エラーは発生しない。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-core-1 と dcap-7k-agg-1 の間の L3 チャネルのフラップの繰り返しテストは正常に終了しまし
た。
システム イベント
ネガティブなシステム イベント テストでは、さまざまな条件の下でシステムがトラフィックを予期し
たとおりに伝送する能力に影響を与えるイベントに焦点を当てています。
ここでは、次の内容について説明します。
• 「dcap-4k-acc-2 でのラント フレームまたはジャイアント フレームの処理」（P.2-113）
• 「dcap-5k-acc-1 でのラント フレームまたはジャイアント フレームの処理」（P.2-114）
• 「dcap-6k-acc-1 でのラント フレームまたはジャイアント フレームの処理」（P.2-115）
• 「dcap-7k-acc-1 でのラント フレームまたはジャイアント フレームの処理」（P.2-116）
• 「異常な SNMP プロトコル テスト」（P.2-117）
• 「SSHv2 ログイン失敗試行の繰り返し」（P.2-118）
• 「Telnet ログイン失敗試行の繰り返し」（P.2-119）
dcap-4k-acc-2 でのラント フレームまたはジャイアント フレームの処理
このテストでは、極端に大きいか小さいフレームがアクセスレイヤ デバイスを介して送信されるとき
のアクセスレイヤ デバイスの機能を検証します。ラント フレーム（64 バイト未満）とジャイアント フ
レーム（設定されているジャンボフレーム MTU の上限を超える）はドロップされ、サイズが許容範囲
内のパケットが転送されます。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-113
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-4k-acc-2 でのラント フレームまたはジャイアント フレームの処理テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセスレイヤ デバイス上にジャンボ MTU が設定されていることを確認します。コンフィギュレー
ションの確認には show running-configuration interface interface コマンドを使用します。
ステップ 3
3 種類のストリームを送信するよう Ixia を設定します。最初のストリームは、長さ 40 ～ 63 バイトのフ
レームで構成します。2 番目のストリームは、長さ 64 ～ 9198 バイトのフレームで構成します。3 番目
のストリームは、長さ 9250 ～ 9400 バイトのフレームで構成します。
ステップ 4
ixia ストリームを開始します。宛先 ixia ポートで、最初と 3 番目のストリームがドロップされ、2 番目
のストリームのすべてのパケットが受信されることを確認します。
ステップ 5
clear counters コマンド、show interface interface コマンドの順に発行して、show interface counters
の出力を確認します。着信方向のラント フレームとジャイアント フレームのカウントが増加している
こと、および入力エラーの数が増加していることを確認します。
ステップ 6
すべてのデータを確認したら、ixia ストリームを停止します。
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ラント フレームで構成されたストリームとジャイアント フレームで構成されたストリームはド
ロップされ、このことがインターフェイス レベルのカウンタに示される。
• 64 ～ MTU バイトのフレームで構成されたストリームが受信 ixia ポートに転送される。
• CPU やメモリに問題が発生しない。
結果
dcap-4k-acc-2 でのラント フレームまたはジャイアント フレームの処理テストは正常に終了しました。
dcap-5k-acc-1 でのラント フレームまたはジャイアント フレームの処理
このテストでは、極端に大きいか小さいフレームがアクセスレイヤ デバイスを介して送信されるとき
のアクセスレイヤ デバイスの機能を検証します。ラント フレーム（64 バイト未満）とジャイアント フ
レーム（設定されているジャンボフレーム MTU の上限を超える）はドロップされ、サイズが許容範囲
内のパケットが転送されます。
Cisco Data Center Assurance Program（DCAP）6.0
2-114
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-5k-acc-1 でのラント フレームまたはジャイアント フレームの処理テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセスレイヤ デバイス上にジャンボ MTU が設定されていることを確認します。Nexus 5000 では、
ポリシーマップを作成し、それをシステムの Quality of Service（QOS）ポリシーに適用することで行
います。設定を確認するには、show system qos コマンドと show policy-mappolicy-map コマンドを
使用します。
ステップ 3
3 種類のストリームを送信するよう Ixia を設定します。最初のストリームは、長さ 40 ～ 63 バイトのフ
レームで構成します。2 番目のストリームは、長さ 64 ～ 9216 バイトのフレームで構成します。3 番目
のストリームは、長さ 9250 ～ 9400 バイトのフレームで構成します。
ステップ 4
ixia ストリームを開始します。宛先 ixia ポートで、最初と 3 番目のストリームがドロップされ、2 番目
のストリームのすべてのパケットが受信されることを確認します。
ステップ 5
まず clear counters コマンドを使用してカウンタをクリアし、次に show interface interface コマンド
を発行して show interface counters の出力を確認します。着信方向のラント フレームとジャイアント
フレームのカウントが増加していること、および入力ドロップの数が増加していることを確認します。
ステップ 6
すべてのデータを確認したら、ixia ストリームを停止します。
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ラント フレームで構成されたストリームとジャイアント フレームで構成されたストリームはド
ロップされ、このことがインターフェイス レベルのカウンタに示される。
• 64 ～ MTU バイトのフレームで構成されたストリームが受信 ixia ポートに転送される。
• CPU やメモリに問題が発生しない。
結果
dcap-5k-acc-1 でのラント フレームまたはジャイアント フレームの処理テストは正常に終了しました。
dcap-6k-acc-1 でのラント フレームまたはジャイアント フレームの処理
このテストでは、極端に大きいか小さいフレームがアクセスレイヤ デバイスを介して送信されるとき
のアクセスレイヤ デバイスの機能を検証します。ラント フレーム（64 バイト未満）とジャイアント フ
レーム（設定されているジャンボフレーム MTU の上限を超える）はドロップされ、サイズが許容範囲
内のパケットが転送されます。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-115
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-6k-acc-1 でのラント フレームまたはジャイアント フレームの処理テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセスレイヤ デバイス上にジャンボ MTU が設定されていることを確認します。コンフィギュレー
ションの確認には show running-configuration interface interface コマンドを使用します。
ステップ 3
3 種類のストリームを送信するよう Ixia を設定します。最初のストリームは、長さ 40 ～ 63 バイトのフ
レームで構成します。2 番目のストリームは、長さ 64 ～ 9216 バイトのフレームで構成します。3 番目
のストリームは、長さ 9250 ～ 9400 バイトのフレームで構成します。
ステップ 4
ixia ストリームを開始します。宛先 ixia ポートで、最初と 3 番目のストリームがドロップされ、2 番目
のストリームのすべてのパケットが受信されることを確認します。
ステップ 5
clear counters コマンドを使用してカウンタをクリアした後、show interface interface コマンドを発行
して show interface counters の出力を確認します。着信方向のラント フレームとジャイアント フレー
ムのカウントが増加していること、および入力ドロップの数が増加していることを確認します。
ステップ 6
すべてのデータを確認したら、ixia ストリームを停止します。
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ラント フレームで構成されたストリームとジャイアント フレームで構成されたストリームはド
ロップされ、このことがインターフェイス レベルのカウンタに示される。
• 64 ～ MTU バイトのフレームで構成されたストリームが受信 ixia ポートに転送される。
• CPU やメモリに問題が発生しない。
結果
dcap-6k-acc-1 でのラント フレームまたはジャイアント フレームの処理テストは正常に終了しました。
dcap-7k-acc-1 でのラント フレームまたはジャイアント フレームの処理
このテストでは、極端に大きいか小さいフレームがアクセスレイヤ デバイスを介して送信されるとき
のアクセスレイヤ デバイスの機能を検証します。ラント フレーム（64 バイト未満）とジャイアント フ
レーム（設定されているジャンボフレーム MTU の上限を超える）はドロップされ、サイズが許容範囲
内のパケットが転送されます。
Cisco Data Center Assurance Program（DCAP）6.0
2-116
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
dcap-7k-acc-1 でのラント フレームまたはジャイアント フレームの処理テストの実行手順は次のとおり
です。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
アクセスレイヤ デバイス上にジャンボ MTU が設定されていることを確認します。コンフィギュレー
ションの確認には show running-configuration interface interface コマンドを使用します。
ステップ 3
3 種類のストリームを送信するよう Ixia を設定します。最初のストリームは、長さ 40 ～ 63 バイトのフ
レームで構成します。2 番目のストリームは、長さ 64 ～ 9216 バイトのフレームで構成します。3 番目
のストリームは、長さ 9250 ～ 9400 バイトのフレームで構成します。
ステップ 4
ixia ストリームを開始します。宛先 ixia ポートで、最初と 3 番目のストリームがドロップされ、2 番目
のストリームのすべてのパケットが受信されることを確認します。
ステップ 5
clear counters コマンドを使用してカウンタをクリアした後、show interface interface コマンドを発行
して show interface counters の出力を確認します。着信方向のラント フレームとジャイアント フレー
ムのカウントが増加していること、および入力ドロップの数が増加していることを確認します。
ステップ 6
すべてのデータを確認したら、ixia ストリームを停止します。
ステップ 7
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 8
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• ラント フレームで構成されたストリームとジャイアント フレームで構成されたストリームはド
ロップされ、このことがインターフェイス レベルのカウンタに示される。
• 64 ～ MTU バイトのフレームで構成されたストリームが受信 ixia ポートに転送される。
• CPU やメモリに問題が発生しない。
結果
dcap-7k-acc-1 でのラント フレームまたはジャイアント フレームの処理テストは失敗しました。検出さ
れた障害は CSCsx32476 です。
異常な SNMP プロトコル テスト
このテストでは、SNMP 脆弱性が Cisco NX-OS コードにないことを確認します。このテストでは、エ
ラーのある SNMP パケットをテスト対象デバイス宛に送信します。これはネガティブ テストであるた
め、DUT が影響を受けないことだけを確認できます。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-117
第2章
DCAP Nexus 7000 テスト
ネガティブ
テスト手順
異常な SNMP プロトコル テストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
Ixia テスト トラフィックの送信を開始します。
ステップ 3
SNMP コミュニティ ストリングのデフォルトを確認します。デバイスの読み取り専用パスワードは
「public」（デフォルト）です。
ステップ 4
プロトコル トラフィック生成スクリプトを実行します。
ステップ 5
バックグラウンド トラフィックが完了したら、パケットが損失しなかったことを確認します。
ステップ 6
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 7
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• 異常なパケット入力によって発生したトラフィック損失はない。
• テスト中、すべての DUT がハングまたはクラッシュせず、トレースバックを与えない。
• CPU やメモリに問題が発生しない。
結果
異常な SNMP プロトコル テストは正常に終了しました。
SSHv2 ログイン失敗試行の繰り返し
このテストでは、SSHv2 経由でデバイスに繰り返しログインしようとするスクリプトの実行中または
実行後に、システムに悪影響が及ばないことを確認します。スクリプトによって不正なユーザ名とパス
ワードがデバイスに提示されるため、ログインが失敗します。
テスト手順
SSHv2 ログイン失敗試行の繰り返しテストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
失敗ログイン スクリプトを開始します。このスクリプトは、テスト対象デバイスに SSH 経由でログイ
ンしようとしますが、不正なユーザ名 / パスワードの組み合せを提示するため、ログインに成功しませ
ん。このシーケンスが 1,000 回繰り返されます。
ステップ 3
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
Cisco Data Center Assurance Program（DCAP）6.0
2-118
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
第2章
DCAP Nexus 7000 テスト
ネガティブ
ステップ 4
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• CPU やメモリに問題が発生しない。
結果
SSHv2 ログイン失敗試行の繰り返しテストは正常に終了しました。
Telnet ログイン失敗試行の繰り返し
このテストでは、Telnet 経由でデバイスに繰り返しログインしようとするスクリプトの実行中または実
行後に、システムに悪影響が及ばないことを確認します。スクリプトによって不正なユーザ名とパス
ワードがデバイスに提示されるため、ログインが失敗します。
テスト手順
Telnet ログイン失敗試行の繰り返しテストの実行手順は次のとおりです。
ステップ 1
バックグラウンド スクリプトを開始し、テスト ネットワーク デバイスの初期ステータスを収集しま
す。該当するネットワーク デバイスのメモリと CPU の使用率を監視します。
ステップ 2
失敗ログイン スクリプトを開始します。このスクリプトは、テスト対象デバイスに Telnet 経由でログ
インしようとしますが、不正なユーザ名 / パスワードの組み合せを提示するため、ログインに成功しま
せん。このシーケンスが 1,000 回繰り返されます。
ステップ 3
バックグラウンド スクリプトを停止し、ネットワーク デバイスの最終ステータスを収集して、エラー
を解析します。
ステップ 4
メモリと CPU に、重大な影響、継続的な影響、または許容できない影響がなかったことを確認しま
す。
予期される結果
予期されるテスト結果は次のとおりです。
• CPU やメモリに問題が発生しない。
結果
Telnet ログイン失敗試行の繰り返しテストは正常に終了しました。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
2-119
第2章
DCAP Nexus 7000 テスト
ネガティブ
Cisco Data Center Assurance Program（DCAP）6.0
2-120
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
A P P E N D I X
A
DCAP 6.0 のバグ
ここでは、Cisco Data Center Assurance Program（DCAP）6.0 のテストに関連して遭遇する
Development Defect Tracking System（DDTS）ソフトウェアのバグについて説明します。
この章では、Cisco Data Center Assurance Program （DCAP）6.0 のテスト中に遭遇するバグが表にま
とめられています。表には、シスコ障害 ID、シスコ内部ガイドラインを使用して評価された障害の重
大度、障害の説明、障害が解決されたソフトウェア バージョンが示されています。このマニュアルの
発行時に障害が修復されていない場合は、その旨が記載されています。障害のアップデートについて
は、担当者までお問い合せください。
（注）
次に示す一覧にすべて網羅されているわけではありません。製品の配置に影響する可能性がある未解決
事項の情報については、該当製品のリリース ノートを参照してください。また、詳細については担当
者にお問い合せください。
• 「Catalyst 6500 のバグ」（P.A-1）
• 「Catalyst 4948-10G のバグ」（P.A-2）
• 「Nexus 5000 のバグ」（P.A-2）
• 「Nexus 7000 のバグ」（P.A-2）
Catalyst 6500 のバグ
表 A-1 に、このテスト サイクルの Catalyst 6500 DDTS を示します。
表 A-1
この Cisco DCAP テスト サイクルの Catalyst 6500 DDTS
DDTS
重大度
説明
解決
CSCsw97764
3
トランクでの UDLD/CDP のタギング動作が SXF13 と SXI と
で異なる
未
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
A-1
付録 A
DCAP 6.0 のバグ
Catalyst 4948-10G のバグ
Catalyst 4948-10G のバグ
表 A-2 に、このテスト サイクルの Catalyst 4948-10G DDTS を示します。
表 A-2
この Cisco DCAP テスト サイクルの Catalyst 4948-10G DDTS
DDTS
重大度
説明
CSCsw77403
2
4948：show platform software ip exact-route でクラッ 12.2(52)SG
シュする
CSCsw77413
2
4948：show idprom interface FastEthernet 1 でクラッ 12.2(50)SG
シュする
解決
Nexus 5000 のバグ
表 A-3 に、このテスト サイクルの Nexus 5000 DDTS を示します。
表 A-3
この Cisco DCAP テスト サイクルの Nexus 5000 DDTS
DDTS
重大度
説明
CSCsu09543
2
Avalon から Maint にダウングレードし、"copy r s" を実行 4.0(1a)N1(1)
すると、ポートチャネル コアがダンプされる
CSCsv31204
2
高速 PIM hello または低速 IGMP フラッピングの送信時に 4.0(1a)N1(1)
NetStack がクラッシュする
CSCsl21529
3
show int output で、間違った MTU が表示される
未
CSCsq10325
3
"show processes cpu" で、意味のない文字が表示される
4.0(1a)N2(1)
CSCsw63309
5
N5K："sh udld <intf>" で、ディセーブルされたインター
未
解決
フェイスの双方向ステートが出力される
Nexus 7000 のバグ
表 A-4 に、このテスト サイクルの Nexus 7000 DDTS を示します。
表 A-4
この Cisco DCAP テスト サイクルの Nexus 7000 DDTS
DDTS
重大度
説明
CSCsr32008
2
L3 マルチキャスト スケーリング テスト中に NetStack がクラッ 4.2(1)
CSCsu65381
2
crdcfg が切り替え前にデータベースと適切に同期しなかった
CSCsv90818
2
VPC：UDLD "aggressive/empty echo" でパケット ドロップによ 4.1(3)
りすべてのメンバがディセーブルになった
CSCsw32798
2
トランク インターフェイス経由の ping が失敗する場合がある
CSCsw48988
2
N7K：LHR に対して spt-infnity を指定すると、MSDP で学習さ 4.1(3)
解決
シュする
4.1(2)
4.1(3)
れたルートが定期的に削除される
CSCsw77441
2
N7k：show identity policy [WORD] でクラッシュする
未
Cisco Data Center Assurance Program（DCAP）6.0
A-2
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
付録 A
DCAP 6.0 のバグ
Nexus 7000 のバグ
表 A-4
この Cisco DCAP テスト サイクルの Nexus 7000 DDTS （続き）
DDTS
重大度
説明
CSCsx24076
2
N7k：モジュールの OIR の後にマルチキャスト トラフィックが 4.1(2)
解決
ブラックホール化する
CSCsu66282
3
N7K：PC フラップ後に UDLD が FU_MEM_fu_gwrap_t でメモ 4.1(2)
リ リークを起こす
CSCsv75235
3
USER-3-SYSTEM_MSG：CLI 実行時に
SDWRAP_IOCG_HISTORY:errno:22 が発生する
4.1(2)
CSCsw25117
3
N7K：非常に低速の場合にパケット レート インターフェイス カ 4.1(3)
ウンタ値が 0 になる
CSCsw25186
3
N7K：VLAN タギングがイネーブルの場合にタギングされてい
ない UDLD/CDP パケットがドロップされる
4.1(3)
CSCsx03783
3
N7K：ポート セキュリティ違反カウントが増えない
4.1(3)
CSCsx15006
3
N7k：モジュールがシャットダウンされている場合に show
interface が Portchannel でエラーになる
4.1(3)
CSCsx26476
3
N7k：Sysmgr："show sys internal stats qos" 後に statclient がク 4.1(3)
CSCsx51043
3
CSCsv43276
4
ラッシュする
ISSU を 4.1(3) から 4.0(4) にした後、IGMP パケットがスヌーピ 4.2(1)
ングに転送されない
CSCsw77427
4
N7K：リンクがダウンしているときに、sh udld <intf> により双 4.1(3)
方向ステートが表示される
4.2(1)
N7k：show system internal sse loop でパーサーがハングする
4.2(1)
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
A-3
付録 A
DCAP 6.0 のバグ
Nexus 7000 のバグ
Cisco Data Center Assurance Program（DCAP）6.0
A-4
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
A P P E N D I X
B
トラフィック プロファイルの詳細
Data Center Assurance Program（DCAP）6.0 のテストでは、Catalyst 6500 と Nexus 7000 の両方のテ
スト トポロジで類似したトラフィック プロファイルを使用しています。これら 2 つのトポロジのテス
ト トラフィック プロファイルにおける主な違いは、Nexus 7000 トポロジには 1 つ多くアクセス レイ
ヤ スイッチがあり、このためにさらに 10 個のアクセス レイヤ ホストがあるということです。
Catalyst 6500 のトラフィック プロファイルの詳細
Catalyst 6500 のトラフィック プロファイルの詳細は次のとおりです。図 B-1 に、Catalyst 6500 のトラ
フィック プロファイル トポロジの詳細を示します。
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
B-1
付録 B
トラフィック プロファイルの詳細
Catalyst 6500 のトラフィック プロファイルの詳細
図 B-1
Catalyst 6500 のトラフィック プロファイル トポロジ
ࠢ࡜ࠗࠕࡦ࠻ ࡎࠬ࠻ ࡊࡠࡈࠔࠗ࡞
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
10.16.0.10-19
IGMP ࠰࡯ࠬ IP㧦
10.16.0.10
IXIA
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
239.2.16.1-50㧔⥄േ RP㧕
239.2.20.1-25㧔㕒⊛ RP㧕
Catalyst 6500 ࠺࡯࠲ ࠮ࡦ࠲࡯
IXIA
ࠨ࡯ࡃ ࡎࠬ࠻ ࡊࡠࡈࠔࠗ࡞
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
201.1.21.10㧔Vlan1121㧕
201.1.22.10㧔Vlan1122㧕
Catalyst 4948 Access
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
201.1.31.10㧔Vlan1131㧕
201.1.32.10㧔Vlan1132㧕
....
....
Nexus 5020 Access
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
201.1.1.10㧔Vlan1101㧕
201.1.2.10㧔Vlan1102㧕
....
201.1.30.10㧔Vlan1130㧕
201.1.40.10㧔Vlan1140㧕
201.1.10.10㧔Vlan1110㧕
IGMP ࠰࡯ࠬ IP㧦
201.1.30.10
IGMP ࠰࡯ࠬ IP㧦
201.1.40.10
IGMP ࠰࡯ࠬ IP㧦
201.1.40.10
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
239.1.30.1-50㧔⥄േ RP㧕
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
239.1.40.1-50㧔⥄േ RP㧕
10 ࠡࠟࡆ࠶࠻ ࠗ࡯ࠨࡀ࠶࠻
ࠡࠟࡆ࠶࠻ ࠗ࡯ࠨࡀ࠶࠻
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
239.1.10.1-50㧔⥄േ RP㧕
268430
Catalyst 6500 Access
ホスト
10 個のクライアント ホスト
アクセス スイッチごとに 10 個のサーバ ホスト、3 個のアクセス スイッチ（Catalyst 6500/Nexus
5000/Catalyst 4948）
Cisco Data Center Assurance Program（DCAP）6.0
B-2
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
付録 B
トラフィック プロファイルの詳細
Catalyst 6500 のトラフィック プロファイルの詳細
ユニキャスト トラフィック プロファイル
すべてのクライアント ホストとサーバ ホスト間のクライアント / サーバ トラフィックのフル メッシュ
が、テスト トラフィック フローの主要セットに使用されています。各フローは、レートが 1,000 pps、
パケット サイズが 512 バイトで送信されます。クライアント側の 10 個のホストのそれぞれがサーバ側
の 30 個のホストに送信することで、300 の双方向ユニキャスト フローが作成されます。
ユニキャスト トラフィック レート
クライアントからサーバ = 1.23 Gbps
サーバからクライアント = 1.23 Gbps
マルチキャスト トラフィック プロファイル
クライアント側のインターネット グループ管理プロトコル（IGMP）
クライアント側の単一のホストから 75 個のマルチキャスト グループに対して IGMP Join を送信しま
す。これらのグループの IP アドレスの範囲のうち、50 個は自動 Rendezvous Point（RP; ランデブー ポ
イント）、25 グループはスタティック RP のスコープに設定します。
サーバ側の IGMP
各アクセス レイヤ スイッチに接続している単一のクライアントから 50 個のマルチキャスト グループ
に対して IGMP Join を送信します。3 個のアクセス レイヤ スイッチで、合計 150 個のサーバ側マルチ
キャスト グループが作成されます。これらのグループの IP アドレスの範囲のすべてを自動 RP のス
コープに設定します。
クライアント側が送信元のトラフィック
クライアント側の 10 個のホストのそれぞれが、サーバ側のアクセス ホストから送信されたすべての
IGMP グループにマルチキャスト トラフィックを送信します。150 個のサーバ側マルチキャスト グ
ループにより、1,500 個のクライアント / サーバ マルチキャスト フローが作成されます。各ホストから
送信されたトラフィックは、結合レート 1,000 pps、パケット サイズ 512 バイトで送信されます。
サーバ側が送信元のトラフィック
サーバ側の 30 個のホストのそれぞれが、クライアント側のホストから送信されたすべての IGMP グ
ループにマルチキャスト トラフィックを送信します。75 個のクライアント側マルチキャスト グループ
により、2,250 個のサーバ / クライアント マルチキャスト フローが作成されます。各ホストから送信さ
れたトラフィックは、結合レート 1,000 pps、パケット サイズ 512 バイトで送信されます。
RP（S,G）カウント：3,750
マルチキャスト トラフィック レート
クライアントからサーバ = 786 Mbps
サーバからクライアント = 245 Mbps
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
B-3
付録 B
トラフィック プロファイルの詳細
Nexus 7000 のトラフィック プロファイルの詳細
Nexus 7000 のトラフィック プロファイルの詳細
Nexus 7000 のトラフィック プロファイルの詳細は次のとおりです。図 B-2 に、Nexus 7000 のトラ
フィック プロファイル トポロジの詳細を示します。
図 B-2
Nexus 7000 のトラフィック プロファイル トポロジ
ࠢ࡜ࠗࠕࡦ࠻ ࡎࠬ࠻ ࡊࡠࡈࠔࠗ࡞
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
10.15.0.10-19
IGMP ࠰࡯ࠬ IP㧦
IXIA
10.15.0.10
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
231.2.16.1-50㧔⥄േ RP㧕
231.2.20.1-25㧔㕒⊛ RP㧕
Nexus 7000 ࠺࡯࠲ ࠮ࡦ࠲࡯
IXIA
ࠨ࡯ࡃ ࡎࠬ࠻ ࡊࡠࡈࠔࠗ࡞
Catalyst 6500 Access
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
101.1.21.10㧔Vlan3121㧕
101.1.22.10㧔Vlan3122㧕
Nexus 7000 Access
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
101.1.11.10㧔Vlan3111㧕
101.1.12.10㧔Vlan3112㧕
....
....
Catalyst 4948 Access
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
101.1.31.10㧔Vlan3131㧕
101.1.32.10㧔Vlan3132㧕
....
Nexus 5020 Access
10 ࡙࠾ࠠࡖࠬ࠻ ࠢ࡜ࠗࠕࡦ࠻ IP㧦
101.1.1.10㧔Vlan3101㧕
101.1.2.10㧔Vlan3102㧕
....
101.1.30.10㧔Vlan3130㧕
101.1.20.10㧔Vlan3120㧕
101.1.40.10㧔Vlan3140㧕
101.1.10.10㧔Vlan3110㧕
IGMP ࠰࡯ࠬ IP㧦
101.1.29.10
101.1.30.10
IGMP ࠰࡯ࠬ IP㧦
101.1.19.10
101.1.20.10
IGMP ࠰࡯ࠬ IP㧦
101.1.39.10
101.1.40.10
IGMP ࠰࡯ࠬ IP㧦
101.1.9.10
101.1.10.10
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
231.1.19.1-25㧔⥄േ RP㧕
231.1.20.1-25㧔⥄േ RP㧕
10 ࠡࠟࡆ࠶࠻ ࠗ࡯ࠨࡀ࠶࠻
ࠡࠟࡆ࠶࠻ ࠗ࡯ࠨࡀ࠶࠻
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
231.1.39.1-25㧔⥄േ RP㧕
231.1.40.1-25㧔⥄േ RP㧕
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
231.1.9.1-25㧔⥄േ RP㧕
231.1.10.1-25㧔⥄േ RP㧕
268431
ࠢ࡜ࠗࠕࡦ࠻ IGMP ࠣ࡞࡯ࡊ㧦
231.1.29.1-25㧔⥄േ RP㧕
231.1.30.1-25㧔⥄േ RP㧕
Cisco Data Center Assurance Program（DCAP）6.0
B-4
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
付録 B
トラフィック プロファイルの詳細
Nexus 7000 のトラフィック プロファイルの詳細
ホスト
10 個のクライアント ホスト
アクセス レイヤ スイッチごとに 10 個のサーバ ホスト、4 個のアクセス スイッチ（Nexus
7000/Catalyst 6500/Nexus 5000/Catalyst 4948）
ユニキャスト トラフィック プロファイル
すべてのクライアント ホストとサーバ ホスト間のクライアント / サーバ トラフィックのフル メッシュ
が、テスト トラフィック フローの主要セットに使用されています。各フローは、レートが 1,000 pps、
パケット サイズが 512 バイトで送信されます。クライアント側の 10 個のホストのそれぞれがサーバ側
の 40 個のホストに送信することで、400 の双方向ユニキャスト フローが作成されます。
ユニキャスト トラフィック レート
クライアントからサーバ = 1.64 Gbps
サーバからクライアント = 1.64 Gbps
マルチキャスト トラフィック プロファイル
クライアント側のインターネット グループ管理プロトコル（IGMP）
クライアント側の単一のホストから 75 個のマルチキャスト グループに対して IGMP Join を送信しま
す。これらのグループの IP アドレスの範囲のうち、50 個は自動 RP、25 グループはスタティック RP
のスコープに設定します。
サーバ側の IGMP
各アクセス レイヤ スイッチに接続している 2 つのクライアントから 25 個のマルチキャスト グループ
に対して IGMP Join を送信します。4 個のアクセス レイヤ スイッチで、合計 200 個のサーバ側マルチ
キャスト グループが作成されます。これらのグループの IP アドレスの範囲のすべてを自動 RP のス
コープに設定します。
クライアント側が送信元のトラフィック
クライアント側の 10 個のホストのそれぞれが、サーバ側のアクセス ホストから送信されたすべての
IGMP グループにマルチキャスト トラフィックを送信します。200 個のサーバ側マルチキャスト グ
ループにより、2,000 個のクライアント / サーバ マルチキャスト フローが作成されます。各ホストから
送信されたトラフィックは、結合レート 1,000 pps、固定パケット サイズ 512 バイトで送信されます。
サーバ側が送信元のトラフィック
サーバ側の 40 個のホストのそれぞれが、クライアント側のホストから送信されたすべての IGMP グ
ループにマルチキャスト トラフィックを送信します。75 個のクライアント側マルチキャスト グループ
により、3,000 個のサーバ / クライアント マルチキャスト フローが作成されます。各ホストから送信さ
れたトラフィックは、結合レート 1,000 pps、固定パケット サイズ 512 バイトで送信されます。
RP（S,G）カウント：5,200
マルチキャスト トラフィック レート
クライアントからサーバ = 1.04 Gbps
サーバからクライアント = 326.6 Mbps
Cisco Data Center Assurance Program（DCAP）6.0
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト
B-5
付録 B
トラフィック プロファイルの詳細
Nexus 7000 のトラフィック プロファイルの詳細
Cisco Data Center Assurance Program（DCAP）6.0
B-6
第 2 巻 —Cisco DCAP 6.0 Catalyst 6500 & Nexus 7000 テスト