Cisco Catalyst 6500 シリーズ

Cisco Catalyst 6500シリーズ スイッチのGOLD(Generic Online Diagnostics)フレームワーク

ダウンロード

Cisco Catalyst 6500シリーズ スイッチのGOLD(Generic Online Diagnostics)フレームワーク

ホワイト ペーパー


Cisco Catalyst 6500シリーズ スイッチのGOLD(Generic Online Diagnostics)フレームワーク


はじめに

シスコシステムズのモジュール型LANスイッチの最上位機種であるCisco® Catalyst® 6500シリーズは、企業ネットワークおよびサービス プロバイダー ネットワーク全体にわたって、高い可用性と信頼性を確保し、安全な統合型ネットワーク サービスを提供します。Cisco Catalyst 6500シリーズには、可用性や信頼性を実現する機能に加えて、最大限の稼働時間を実現するために不可欠なコンポーネントとして、障害検出機能が組み込まれています。つまり、システムで異常が検出されると、障害検出メカニズムによって障害復旧メカニズムが起動されます。障害検出の一般的な手段としては、システム間でのキープアライブがあります。ただし、動作している特定のシステムの健全性を保証するには、内部的な復元力メカニズムも必要です。この機能は、Generic Online Diagnostics(GOLD)と呼ばれる汎用の診断フレームワークによって提供されます。GOLDの機能をCisco Catalyst 6500シリーズに組み込むことにより、このプラットフォームは一層強化され、一段階上のアベイラビリティ(可用性)が実現できます。

ここでは、Cisco Catalyst 6500シリーズに組み込まれているGOLDについて説明します。まずGOLDの概要について説明し、次にCisco Catalyst 6500シリーズで利用できる主な診断メカニズムについて説明します。GOLDは装置の健全性を保証する多くのメカニズムを実装していますが、この文書は、Cisco Catalyst 6500シリーズで利用できるすべての診断テストを網羅しているわけではありません。GOLDは、Supervisor Engine 2ではCisco IOS®ソフトウェア リリース12.1(13)Eおよび12.2(17d)SXB、Supervisor Engine 720ではCisco IOSソフトウェア リリース12.2(14)SXによってCisco Catalyst 6500シリーズに組み込まれました。それ以降のリリースをCisco Catalyst 6500シリーズで使用している場合には、より多くのテストを実施でき、診断の対象範囲が広がります。

GOLDの概要

GOLDのフレームワーク
GOLDは、Cisco IOSソフトウェアを実行しているシスコの全プラットフォームの診断動作について、共通のフレームワークを定義しています。図1は、GOLDのフレームワーク、およびGOLDとプラットフォーム依存の診断動作およびネットワーク管理システムとの相互関係を示しています。

図1 GOLDのフレームワーク

GOLDフレームワークでは、一元管理型および分散型のシステムに対して、プラットフォームに依存しない障害検出を提供するアーキテクチャを前提としています。そのため、GOLDフレームワークには、一般的な診断CLI(コマンドライン インターフェイス)、およびプラットフォームに依存しないブートアップ診断とランタイム診断に関する障害検出プロシージャが含まれます。プラットフォーム固有の診断では、特定ハードウェア向けの障害検出テストが実施され、診断テストの結果に対応して必要な修正措置がとられます。Cisco Catalyst 6500シリーズでは、多くの情報がハードウェア ベースで転送されるため、ハードウェアの機能を定期的にテストすることが重要になります。

診断動作
GOLDの実装では、ハードウェア コンポーネントの健全性をチェックし、システムのデータ プレーンとコントロール プレーンが正常に動作していることを確認します。テストのなかには、システム起動時に実施されるものもあれば、システム稼働中に実施されるものもあります。図1に示したように、テストはブートアップ診断とランタイム診断の2つのカテゴリに分類されます。これらのテストは、複数を並行して実行することが可能です。

ブートアップ診断
ブート モジュールは一連のチェックを受けてからオンラインになります。これによって、システムの起動時にハードウェア コンポーネントの障害を検出でき、障害のあるモジュールが稼働中のネットワークに入り込むことを防止できます。

ブートアップ診断によってCisco Catalyst 6500シリーズで障害が検出された場合、その障害のあるモジュールはシャットダウンされます。管理者は、ブートアップ診断のレベルを最小限(minimal)、完全(complete)、または無効(disabled)に設定できます。完全診断が推奨されますが、Catalyst 6500シリーズのデフォルト設定ではシステムがより早くオンラインになるように最小限診断を実行するようになっています。ブートアップ診断レベルをCLIで確認するには、次のようなコマンドを実行します。

Router (config)#diagnostic bootup level ?
complete Complete level
minimal Minimal level


ランタイム診断
障害の診断はシステムの稼働中(ランタイム)にも実施されます。一連の診断チェックを有効にすれば、オンライン システムの状態を判定することができます。ただし、ディスラプティブ テスト(運用中に実行するトラフィックに影響を与える可能性のあるテスト)とノンディスラプティブ テスト(運用中に問題なく実行可能なテスト)を区別して実行してください。ノンディスラプティブ テストはシステムのデータやコントロール プレーンに影響を与えないため、稼働中にバックグラウンドで実行できます。しかし、ディスラプティブ テストは稼働中に実行するとパケット フローに影響を与えるため、メンテナンス期間を特に設けて計画的に実施する必要があります。CLIコマンドshow diagnostic content moduleを実行すると、各種のテストについてディスラプティブ/ノンディスラプティブの区別などの属性が表示されます(「Supervisor Engine 720の診断の対象範囲」にある設定の出力例を参照)。

多くのディスラプティブ テストは、メンテナンス以外の稼働中に実行したとしても数秒程度で完了するため、その影響はほとんどありません。ただし、完全メモリ テストについては、完了するまでに数時間かかる場合があるので注意が必要です。また、不要なテストを避けるため、ランタイム診断テストのほとんどがデフォルトでは無効になっています。たとえば、お客様がネットワークでIPv4トラフィックのみを運用している場合は、ハードウェアのIPv6およびMultiprotocol Label Switching(MPLS)機能をテストする必要はありません。Supervisor Engine 720の場合、このようなMPLSおよびIPv6固有のテストとして、TestMplsFibShortcutやTestIPv6FibShortcutなどが用意されています。Supervisor Engine 720で実施できるテストの一覧については、「Supervisor Engine 720の診断の対象範囲」を参照してください。管理者が必要と判断すれば、実施する診断テストを追加することができます。

ランタイム診断チェックは、オンデマンドでの実行、時間を指定してスケジューリングした実行、またはバックグラウンドでの継続的な実行を選択できます。

  • ヘルス モニタリング診断テスト
    ヘルス モニタリング診断テストはシステムの動作に影響を与えないノンディスラプティブ テストなので、システム稼働中にバックグラウンドで実行できます。オンラインのヘルス モニタリング診断を行う目的は、稼働中のネットワーク環境でハードウェア障害をプロアクティブに検出し、適切なエンティティに障害を通知することです。実行するヘルス モニタリングのチェック数、およびそれらを実行する間隔は、管理者が決定します。ヘルス モニタリング診断テストは、システムのパフォーマンスに影響を与えません。しかし、CPUパフォーマンスへの影響を防ぐため、ソフトウェアによって実行間隔は制限されています。複数の障害が続けて検出された場合、ヘルス モニタリング診断テストによってモジュールをリセットすることもできます。デフォルト設定のヘルス モニタリング診断テストには、データ プレーンとコントロール プレーンの検証、およびハードウェア レジスタが正常に機能しているかの確認などがあります。CLIコマンドshow diagnostics contentを実行すると、ヘルス モニタリング テストの完全なリストを確認できます。ノンディスラプティブ(N)とマークされたテストは、すべてヘルス モニタリング テストとして実行されるように設定できます。たとえば、次のCLIコマンドでは、スロット5のスーパーバイザに対してインバンドpingテスト(テスト番号2)を15秒ごとに実施するようにスケジューリングしています。CLIコマンドの出力としてこのインバンド テストに「test 2」が割り当てられていることに注意してください。「?」を入力することで、テスト番号へのマッピングが取得できます。
    Router(config)#diagnostic monitor interval module 5 test ?
    Router(config)#diagnostic monitor interval module 5 test 2 00:00:15 0 0

  • オンデマンド診断
    管理者がdiagnostic startコマンドを実行すると、オンデマンドの診断テストがスタティックに起動されます。管理者はテストの実行回数、および障害が検出された時にテストを継続するかどうかを指定できます。オンデマンド診断は、主にトラブルシューティング ツールとして、管理者がハードウェア障害の可能性があると判断した場合に、ハードウェア機能を確認するために使われます。オンデマンド診断によって、障害のあるハードウェアがリセットされたり、Cisco Catalyst 6500シリーズの電源が落とされたりすることはありません。Syslogメッセージがハードウェア障害について警告すると、管理者は診断結果をチェックしてテストがパスしたか失敗したかを確認し、必要な措置をとります。一例として、次のコマンドでは、スロット2のモジュールに対して2つのオンデマンド モジュール メモリ テスト(テスト番号12)を起動しています。最初のメモリ テストが失敗した場合、それ以降のテストは実行されません。
    Router#diagnostic ondemand iterations 2
    Router#diagnostic ondemand action-on-failure stop
    Router#diagnostic start module 2 test ?
    Router#diagnostic start module 2 test 12

  • スケジュールド診断
    スケジュールド診断テストは、指定した時間に実行されるか、または定期的に実行されます。これは、特にディスラプティブ テストをメンテナンス期間中に行うようにスケジューリングする場合に有効です。障害が検出された場合、対応するSyslogメッセージが表示されます。診断結果を調べるには、スイッチでshow diagnostic resultコマンドを実行します。スケジュールド診断によって、障害のあるハードウェアがリセットされたり、Cisco Catalyst 6500シリーズの電源が落とされたりすることはありません。次のCLIコマンドでは、モジュール2に位置するモジュールに対して、毎週月曜日の午前3時にループバック テスト(テスト番号1)が行われるようにスケジューリングしています。
    Router(config)#diagnostic schedule module 2 test ?
    Router(config)#diagnostic schedule module 2 test 1 weekly MON 03:00


診断結果
GOLDでは、すべてのテストについて診断結果と詳細な統計情報(最後の実行時刻、最初と最後のテスト パス時刻、最初と最後のテスト失敗時刻、総実行回数、総失敗回数、失敗連続回数、およびエラー コード)が収集されます。これらのテスト結果は、管理者がシステムの状態を判断し、システム障害の原因を特定するのに役立ちます。診断結果は、スイッチでshow diagnostic resultコマンドを実行することで表示できます。

プラットフォームごとに用意されているソフトウェアは、システムが障害検出のあとに特定の動作をするのに役立ちます。Cisco Catalyst 6500シリーズでは、適切なSyslogメッセージがコンソールまたは端末に表示され、管理者に障害の発生を通知します。障害は、マイナー障害とメジャー障害に分類されます。マイナー障害では、エラーはSyslogメッセージで報告されます。メジャー障害もSyslogメッセージで報告されますが、さらにモジュールの電源が落とされる場合があります。次の例は、エラーが検出されたときに表示されるSyslogメッセージです。

%DIAG-SP-3-MAJOR: Module 2: Online Diagnostics detected a Major Error. Please use 'show diagnostic Module 2' to see test results.

ハードウェア レベルでは、ブートアップ診断にパスしなかったモジュールはオンラインにはならず、稼働中のシステムで不安定な状態にあると診断されたモジュールは、電源を落とされる場合があります。これは、スーパーバイザ エンジンにも当てはまります。ソフトウェアによってアクティブまたはスタンバイ スーパーバイザ エンジンで障害が検出された場合、そのスーパーバイザ エンジンの電源が落とされる場合があります。ただし、ポート障害が検出されても、モジュールのリセットまたは電源切断が行われるとは限りません。ソフトウェアは障害のあるポートを無効にするだけの場合もあります。

GOLDアプリケーション
GOLDは、システムを監視することでMTTR(平均復旧時間)を短縮し、ハードウェアおよびソフトウェア障害をプロアクティブに識別します。

ブートアップ時、ブートアップ診断にパスしたモジュールだけが「online」となります。これによって、健全性の確認されたシステムのみが稼働中のネットワークに参加するようにできます。

またノンディスラプティブ テストは、スイッチオーバーのトリガーとなります。障害検出診断メカニズムは、アクティブまたはスタンバイのスーパーバイザで有効にします。GOLDの組み込まれたCisco Catalyst 6500シリーズでスイッチオーバーが起動されるのは、ソフトウェアで例外が発生した場合だけではありません。スーパーバイザのコントロール パスおよびデータ パスに不整合や欠陥がある場合、またはハードウェアの作動不良が検出された場合にも、スイッチオーバーが起動されることがあります。さらに診断は、スイッチオーバーのトリガーとなるだけでなく、スタンバイ スーパーバイザが必要なときにいつでも交代できる状態であることを定期的に監視します。診断には、スイッチオーバーをスケジューリングする機能もあります。管理者は、オンライン診断CLIコマンドによって、スイッチオーバーが特定の時間に行われるようにスケジューリングできます。

スーパーバイザ間のStateful Switchover(SSO;ステートフル スイッチオーバー)メカニズムと組み合わせれば、Cisco Catalyst 6500シリーズでほぼ100%の可用性を実現できます。GOLDはSSOにも対応しているため、アクティブおよびスタンバイ スーパーバイザ間でそれぞれの診断テストの結果を同期できます。これによって、スイッチオーバーが発生した場合の問題のトラブルシューティングが簡単になり、診断結果がスイッチオーバーによって失われることがありません。

GOLDでは、ハードウェア コンポーネント障害、コネクタ障害、インターフェイス障害、メモリ障害、およびデータ パスとコントロール パスの異常を引き起こす不整合といった問題を検出できます。GOLDでは、ソフトウェアの不具合や障害も検出できます。これらの問題は、起動時および稼働中の環境で検出可能です。

GOLDは非常に強力なトラブルシューティング ツールであり、お客様やテクニカル サポート技術者がソフトウェア障害とハードウェア障害とを区別するのに役立ちます。問題の原因がハードウェア障害にある場合は、Return Materials Authorization(RMA)のプロセスを効果的に処理できます。

Cisco Catalyst 6500シリーズの診断の対象範囲

ハードウェア コンポーネントの整合性と機能をチェックするには、GOLDを使用する各プラットフォームで独自のハードウェア テストを定義する必要があります。これは、プラットフォーム固有の診断と呼ばれます。Cisco Catalyst 6500シリーズでは、ハードウェア コンポーネントの機能を検証するために特定のテストが用意されています。これらのテストは、パケット スイッチング テストを使用して実装されます。

Cisco Catalyst 6500シリーズの診断テストは特定のハードウェア コンポーネントを対象とし、Cisco Catalyst 6500シリーズのアーキテクチャと非常に密接な関係があります。こうしたテストのなかには、Supervisor Engine 720とWS-X6748-GE-TXのアーキテクチャに基づくものもあります。ただし、Cisco Catalyst 6500シリーズの他のあらゆるモジュールに同じロジックが適用できます。Cisco Catalyst 6500シリーズに関連するすべてのテスト シナリオを説明することはこの文書の目的ではありませんが、診断テストはそれぞれ特定のハードウェア コンポーネントを対象としているため、どの診断テストも重要となります。
以下に、Cisco Catalyst 6500シリーズの診断テストの分類を示します。これは、実行するテストを決定する際に役立ちます。

Supervisor Engine 720の診断の対象範囲
図2は、Supervisor Engine 720のアーキテクチャを示しています。Supervisor Engine 720は、以下で構成されています。

  • Policy Feature Card 3(PFC3) ― レイヤ2およびレイヤ3~4エンジンが搭載されています。これらのエンジンではハードウェア スイッチング機能が実行されます。
  • Multilayer Switching Feature Card 3(MSFC3) ― Route Processor(RP)とスイッチ プロセッサが搭載されています。
  • 内蔵スイッチ ファブリック― Cisco Catalyst 6500シリーズの各スロットへの専用のデータ プレーン帯域幅を提供します。
  • ファブリック インターフェイスとレプリケーション エンジン ― スイッチ ファブリックへのインターフェイス接続、およびハードウェア マルチキャスト機能とSwitched Port Analyzer(SPAN)機能を提供します。
  • ポートApplication Specific Integrated Circuit(ASIC;特定用途向けIC) ― ポート関連の機能、およびアップリンク ポートとCPUへの帯域幅を提供します。


図2 Supervisor Engine 720のアーキテクチャ

Supervisor Engine 720のメイン コンポーネントは、オンライン診断によってテストします。次の出力は、Supervisor Engine 720とCisco IOSソフトウェア リリース12.2(18)SXDを使用した場合に利用できる30種類の診断テストのリストです。リストされているテストの多くが、Supervisor Engine 720のアーキテクチャの図に示されたコンポーネントに関係していることに注意してください。CLIコマンドshow diagnostics content moduleを実行すると、出力として特定のモジュールに使用できる診断テストが表示されます。

Sup720# show diagnostic content module 5

 

Module 5:

 

Diagnostics test suite attributes:

M/C/* - Minimal bootup level test / Complete bootup level test / NA

B/* - Basic ondemand test / NA

P/V/* - Per port test / Per device test / NA

D/N/* - Disruptive test / Non-disruptive test / NA

S/* - Only applicable to standby unit / NA

X/* - Not a health monitoring test / NA

F/* - Fixed monitoring interval test / NA

E/* - Always enabled monitoring test / NA

A/I - Monitoring is active / Monitoring is inactive

R/* - Power-down line cards and need reset supervisor / NA

K/* - Require resetting the line card after the test has completed / NA

 

Testing Interval

ID Test Name Attributes (day hh:mm:ss.ms)

==== ================================== ============ =================

1) TestScratchRegister -------------> ***N****A** 000 00:00:30.00

2) TestSPRPInbandPing --------------> ***N****A** 000 00:00:15.00

ヘルス モニタリング

3) TestTransceiverIntegrity --------> **PD****I** not configured

4) TestActiveToStandbyLoopback -----> M*PDS***I** not configured

5) TestLoopback --------------------> M*PD****I** not configured

ポート単位のテスト

6) TestNewIndexLearn ---------------> M**N****I** not configured

7) TestDontConditionalLearn --------> M**N****I** not configured

8) TestBadBpduTrap -----------------> M**D****I** not configured

9) TestMatchCapture ----------------> M**D****I** not configured

10) TestProtocolMatchChannel --------> M**D****I** not configured

PFCレイヤ2エンジンのテスト

11) TestFibDevices ------------------> M**N****I** not configured

12) TestIPv4FibShortcut -------------> M**N****I** not configured

13) TestL3Capture2 ------------------> M**N****I** not configured

14) TestIPv6FibShortcut -------------> M**N****I** not configured

15) TestMPLSFibShortcut -------------> M**N****I** not configured

16) TestNATFibShortcut --------------> M**N****I** not configured

17) TestAclPermit -------------------> M**N****I** not configured

18) TestAclDeny ---------------------> M**D****A** 000 00:00:05.00

19) TestQoSTcam ---------------------> M**D****I** not configured

PFCレイヤ3~4エンジンのテスト

20) TestL3VlanMet -------------------> M**N****I** not configured

21) TestIngressSpan -----------------> M**N****I** not configured

22) TestEgressSpan ------------------> M**N****I** not configured

レプリケーション エンジンのテスト

23) TestNetflowInlineRewrite --------> C*PD****I** not configured

ポート単位のテスト

24) TestFabricSnakeForward ----------> M**N****I** not configured

25) TestFabricSnakeBackward ---------> M**N****I** not configured

ファブリック テスト

26) TestFibTcamSSRAM ----------------> ***D****IR* not configured

27) TestAsicMemory ------------------> ***D****IR* not configured

28) TestAclQosTcam ------------------> ***D****IR* not configured

29) TestNetflowTcam -----------------> ***D****IR* not configured

メモリ テスト
30) ScheduleSwitchover --------------> ***D****I** not configured スイッチオーバーのスケジュール


このCLI出力では、ディスラプティブ テスト(Dとマークされているエントリ)とノンディスラプティブ テスト(Nとマークされているエントリ)が混在しています。ノンディスラプティブ テストは、ヘルス モニタリング テストとして実行することができます。また、スイッチが最小限(Mとマークされているエントリ)または完全(Cとマークされているエントリ)ブートアップ診断レベルに設定されているときは、起動時に実施されるテストが通知されます。テストは、右側に記載されたテスト カテゴリに分類できます。これらのカテゴリは、管理者が各テストをスーパーバイザのアーキテクチャに適用する方法を理解しやすくするために書き加えました。これらのテスト カテゴリの説明は、このあとの「主な診断の対象範囲」に記載されています。

WS-X6748-GE-TXの診断の対象範囲
図3は、WS-X6748-GE-TXのアーキテクチャを示しています。WS-X6748-GE-TXは、次のコンポーネントで構成されています。

  • ファブリック インターフェイスとレプリケーション エンジン―スイッチ ファブリックへのインターフェイス接続、およびマルチキャスト機能とSPAN機能を提供します。
  • ポートASIC ―ポートの機能を提供します。
  • Central Forwarding Card(CFC)―中央のレプリケーション機能向け共有システム バスへのインターフェイスを提供します。または、ハードウェア スイッチング機能を実行するレイヤ2およびレイヤ3~4エンジンを含むDistributed Forwarding Card 3(DFC3)がオプションで搭載されています。


図3 WS-F6700-DFC3を搭載したWS-X6748-GE-TXのアーキテクチャ

大部分のモジュール コンポーネントは、オンライン診断によってテストされます。次の出力は、WS-X6748-GE-TXにWS-F6700-DFC3Aを搭載し、Cisco IOSソフトウェア リリース12.2(18)SXDを使用した場合に利用できる、28種類の診断テストの完全なリストです。WS-X6748-GE-TXのアーキテクチャの図に記載されているものと同じコンポーネントが対象とされていることがわかります。このCLIコマンドshow diagnostics content moduleの出力は、WS-F6700-DFC3Aを搭載したモジュールに関するものです。

Sup720#show diagnostic content module 7

Module 7:


Sup720# show diagnostic content module 7

 

Module 7:

 

Diagnostics test suite attributes:

M/C/* - Minimal bootup level test / Complete bootup level test / NA

B/* - Basic ondemand test / NA

P/V/* - Per port test / Per device test / NA

D/N/* - Disruptive test / Non-disruptive test / NA

S/* - Only applicable to standby unit / NA

X/* - Not a health monitoring test / NA

F/* - Fixed monitoring interval test / NA

E/* - Always enabled monitoring test / NA

A/I - Monitoring is active / Monitoring is inactive

R/* - Power-down line cards and need reset supervisor / NA

K/* - Require resetting the line card after the test has completed / NA

 

Testing Interval

ID Test Name Attributes (day hh:mm:ss.ms)

==== ================================== ============ =================

1) TestLoopback --------------------> M*PD****I** not configured ポート単位のテスト

2) TestScratchRegister -------------> ***N****A** 000 00:00:30.00

3) TestTxPathMonitoring ------------> M**N****A** 000 00:00:02.00

ヘルス モニタリング

4) TestDontLearn -------------------> C**D****I** not configured

5) TestConditionalLearn ------------> M**D****I** not configured

6) TestNewLearn --------------------> C**D****I** not configured

7) TestStaticEntry -----------------> C**D****I** not configured

8) TestIndexLearn ------------------> C**D****I** not configured

9) TestCapture ---------------------> C**D****I** not configured

10) TestTrap ------------------------> C**D****I** not configured

DFCレイヤ2エンジンのテスト
11) TestMacNotification -------------> M**N****A** 000 00:00:15.00 ヘルス モニタリング

12) TestFibDevices ------------------> M**D****I** not configured

13) TestIPv4FibShortcut -------------> M**D****I** not configured

14) TestIPv6FibShortcut -------------> M**D****I** not configured

15) TestL3HealthMonitoring ----------> ***N****A** 000 00:00:05.00

16) TestNATFibShortcut --------------> M**D****I** not configured

17) TestMPLSFibShortcut -------------> M**D****I** not configured

DFCレイヤ3~4エンジンのテスト

18) TestL3Capture -------------------> C**D****I** not configured

19) TestL3VlanMet -------------------> M**D****I** not configured

20) TestIngressSpan -----------------> M**D****I** not configured

21) TestEgressSpan ------------------> M**D****I** not configured

レプリケーション エンジンのテスト

22) TestAclPermit -------------------> M**D****I** not configured

23) TestAclDeny ---------------------> C**D****I** not configured

24) TestQos -------------------------> M**D****I** not configured

25) TestNetflowShortcut -------------> M**D****I** not configured

DFCレイヤ3~4エンジンのテスト
26) TestLinecardMemory --------------> ***D****I*K not configured メモリ テスト
27) TestEobcStressPing --------------> ***D****I** not configured ストレス テスト
28) TestFibTcamSSRAM ----------------> ***D****I*K not configured スイッチオーバーのスケジュール


このCLI出力を詳しく調べると、「Supervisor Engine 720の診断の対象範囲」で規定されているものと同じテスト カテゴリが含まれることがわかります。DFCに関連するカテゴリは、モジュールにDFCを搭載しなければ表示されないことに注意してください。

主な診断の対象範囲
「Supervisor Engine 720の診断の対象範囲」および「WS-X6748-GE-TXの診断の対象範囲」で規定されているテスト カテゴリの一覧と説明を以下に示します。

  • ヘルス モニタリング テスト―ヘルス モニタリング テストはバックグラウンドで実行されます。Supervisor Engine 720では、TestInbandSPRPingおよびTestScratchRegister(これらはデフォルトで有効)が障害検出で重要な役割を果たします。TestTxPathMonitoringは、WS-X6748-GE-TXモジュールではデフォルトで有効になっています。
    TestInbandSPRPingは、フォワーディング エンジンを経由して、pingの使用によりスイッチ プロセッサとRP間のコントロール パスとデータ パスを検証します。「Inband」とは、Ethernet Out-of-Band Channel(EOBC)とは対照的に、ポートASICとファブリック インターフェイスを経由する内部のデータ パス通信を指します。このテストは、スイッチ プロセッサとRPとの間で、EOBCのみを使用して定期的に行われるハートビート テストとは異なります。デフォルトでは、このテストは15秒ごとに実行され、10回連続して失敗すると致命的障害とみなされてスーパーバイザのスイッチオーバーが起動されます。RPとスイッチ プロセッサ間のpingテストは、トラフィックまたはCPU使用率が高い場合はスキップされます。
    TestScratchRegisterもデフォルトで有効になっています。このテストでは、値をレジスタに書き込み、それをレジスタから読み取ることで、ASICの健全性が監視されます。テストは30秒ごとに定期的に実行され、5回連続して失敗すると致命的障害とみなされてスーパーバイザのスイッチオーバーが発生します。
    TestTxPathMonitoringは、モジュールとアクティブ スーパーバイザ間のデータ パスとコントロール パスを監視します。
    TestMacNotificationでは、モジュールとスーパーバイザ間のデータ パスとコントロール パスが検証されます。これは、システム内の全レイヤ2 MACアドレス テーブルにわたってMACアドレス テーブルの一貫性を保証するためにも役立ちます。
  • PFCおよびDFCレイヤ2のテスト―これらのテストでは、レイヤ2エンジンのルックアップ動作が正常かどうかを確認します。このテストは、MACアドレスの学習、キャプチャ、およびレイヤ2機能に関連するその他のテストで構成されます。TestMacNotificationは、DFCを搭載したWS-X6748-GE-TXでは、デフォルトで有効になっています。TestMacNotificationは、システムの動作に影響を与えないヘルス モニタリング テストです。
  • PFCおよびDFCレイヤ3~4エンジンのテスト―これらのテストでは、レイヤ3~4エンジンのルックアップ動作が正常かどうかを確認します。Access Control List(ACL;アクセス制御リスト)、Quality of Service(QoS;サービス品質)、NetFlow、およびForwarding Information Base(FIB;フォワーディング情報ベース)の各機能が対象となります。隣接テーブルの機能もFIB関連テストの対象となります。一部のテストは、特定の機能またはプロトコルを対象としています。たとえば、IPv4、IPv6、またはMPLSに固有のテストだけをCLIに出力させることもできます。一般にこれらのテストでは、予約アドレスを使用してハードウェア内に診断エントリまたはショートカットをプログラミングしており、それらのショートカットが有効になっていることを確認します。
  • ポートASICの機能 ― これらのテストは、ポートASICとトランシーバを対象としています。ループバック テストでは、ポートをループバック モードに設定することによって、プロセッサ、フォワーディング エンジン、およびポートASIC間のデータ パスが検証されます。ループバック テストがディスラプティブ テストとなるか、ノンディスラプティブ テストとなるかは、モジュールによって異なります。ただし、ディスラプティブ ループバック テストでも1秒程度で完了します。インライン リライト テストでは、ポートASICのレイヤ2リライト機能が検証されます。
  • ファブリック テスト ― これらのテストでは、アクティブおよびスタンバイ ファブリックの動作が正常かどうかを確認します。これは、あるファブリック チャネルから別のファブリック チャネルへのスイッチング機能、およびフォワーディング エンジンとファブリック インターフェイス間のデータ パスをテストすることによって行われます。
  • レプリケーション エンジンのテスト ― これらのテストでは、ハードウェアのSPAN機能、中央リライト機能、およびマルチキャスト レプリケーション機能が検証されます。
  • メモリ テスト ― メモリが動作不良を起こすと、フォワーディング エラーが発生したり、データが損傷したりする可能性があります。メモリ テストには、メモリ エラー相関テストと完全メモリ テストの2種類が用意されています。ノンディスラプティブ メモリ テストでは、過剰なCyclic Redundancy Check(CRC;巡回冗長検査)、Error Checking and Correction(ECC)、ファブリック、またはフォワーディング エラーを監視して、障害発生を検出します。完全バッファ メモリ テスト、Synchronous Static RAM(SSRAM)テスト、およびTernary Content Addressable Memory(TCAM)テストは、ディスラプティブ テストであり、完了までに数時間かかる場合があります。こうしたテストを稼働中の環境で実行するには、十分な注意が必要です。次の文書を参照して、これらのテストの実行方法に関する推奨事項を確認してください。
    http://www.cisco.com/jp/service/manual_j/sw/cat60/iosscg/chapter39/39_diags.shtml
  • ストレス テスト ― ストレス テストはディスラプティブ テストであり、コントロール プレーンとデータ プレーンに負荷を加えて、動作が正常かどうかを確認します。
  • スケジュール スイッチオーバー機能 ― この機能によって、管理者はスーパーバイザのスイッチオーバーをスケジューリングできます。


図4は、スイッチ プロセッサとRP間のインバンドpingテスト(TestInbandSPRPing)を図で表したものです。データ パスとコントロール パスが診断パケットによってバックグラウンドで効果的にテストされる機構を理解してください。

図4 スイッチ プロセッサとRP間のインバンドpingテスト

診断パケットは、レイヤ2エンジンを経由してスイッチ プロセッサからRPに送信されます。その診断パケットは、レイヤ3~4エンジンと、リライトおよびマルチキャスト エンジンの機能を使用して、スイッチ プロセッサに送り返されます。このテストでは、ASIC障害、コネクタ障害、およびソフトウェア障害を検出できます。

カテゴリはここで紹介したものがすべてではありません。利用できる診断テストはほかにもあり、これから実装されるものもあります。また、診断テストはスーパーバイザとモジュールでしか実施できないわけではありません。ヘルス モニタリング機能は、電源装置、ファン トレイ、温度、およびCisco Catalyst 6500シリーズに関連するその他のコンポーネントを対象としても実装されています。さらに、組み込みのイベント マネージャを利用すれば、ヘルス モニタリング機能をソフトウェアおよびハードウェアのさまざまなスレッシュホールド パラメータにまで拡張することができます。

まとめ

これまでの実績によって、ブートアップ診断とランタイム診断は、両方ともハードウェアおよびソフトウェアの障害を検出する手段として非常に効果的であることがわかっています。ブートアップ診断は、障害コネクタの問題、ドータカードの装着ミス、ポート障害、およびモジュール障害を検出できることが実証されています。また、ヘルス モニタリング テストは、ソフトウェア、メモリ、およびハードウェア コンポーネントに関連するその他の問題を検出できることが実証されています。
プラットフォーム固有のオンライン診断と組み合わせれば、GOLDによって復元力のある障害検出メカニズムを実現できます。したがって、GOLDはCisco Catalyst 6500シリーズ プラットフォームの非常に重要な構成部分であり、高い信頼性と優れた可用性を提供します。

参考資料

Cisco Catalyst 6500シリーズの診断設定に関する包括的な情報については、次のサイトを参照してください。
http://www.cisco.com/jp/service/manual_j/sw/cat60/iosscg/chapter39/39_diags.shtml