内容

概要

前提条件

要件

使用するコンポーネント

表記法

背景説明

syslog およびコンソールのエラー メッセージに関するトラブルシューティング

show diagnostic sanity コマンド

スーパーバイザ エンジンまたはモジュールの問題

スーパーバイザ エンジンの LED が赤/オレンジになる、またはステータスが faulty と表示される

スイッチが連続ブーティング ループに陥るか、ROMmon モードになる、またはシステム イメージが失われる場合

スタンバイ状態のスーパーバイザ エンジン モジュールがオンラインにならない、またはステータスが unknown と表示される

show module の出力で SPA モジュールが「not applicable」と表示される

スタンバイ側スーパーバイザ エンジンで予期しないリロードが始まる

一般的な原因および解決策

モジュールを取り外した後も、show run コマンドで取り外したモジュールのインターフェイスに関する情報が表示される

スイッチの自動リセットまたはリブート

一般的な原因および解決策

DFC 装備モジュールの自動リセット

オンラインにならなかったり、faulty やその他のステータスが表示されるモジュールのトラブルシューティング

一般的な原因および解決策

インバンド通信障害

一般的な原因および解決策 1

電源オンによりシステムが ROM モードに戻る（SP by Abort）

エラー:NVRAM: nv->magic != NVMAGIC, invalid nvram

エラー:Switching Bus FIFO counter stuck

エラー:カウンターがしきい値を超えているが、システム オペレーションが続行する

エラー:これ以上 SWIDB を割り当てることができない

SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE!

インターフェイスやモジュールの接続障害

サーバ ファームで使用されている WS-X6548-GE-TX および WS-X6148-GE-TX モジュールに見られる接続性の問題、またはパケットの消失

回避策

ワークステーションが起動時にネットワークにログインできない/DHCPアドレスを取得できない

一般的な原因および解決策

NIC の互換性に関する問題のトラブルシューティング

一般的な原因および解決策

インターフェイスが errdisable ステータスを示す

インターフェイス エラーのトラブルシューティング

一般的な原因および解決策

「%PM_SCP-SP-3-GBIC_BAD: GBIC integrity check on port x failed: bad key」エラーメッセージを受信する

WS-X6x48 モジュール インターフェイスで COIL エラー メッセージが表示される

WS-X6x48 モジュールの接続性問題のトラブルシューティング

STP 問題のトラブルシューティング

telnet コマンドを使用してスイッチに接続できない

原因

解決方法

RADIUS認証でスタンバイユニットをコンソールに表示できない

VSL インターフェイスでのジャイアント パケット カウンタ

複数の VLAN がスイッチに表示される

電源とファンの問題

電源の NPUT OK LED が点灯しない場合

エラー メッセージ「C6KPWR-4-POWRDENIED:insufficient power, module in slot [dec] power denied or %C6KPWR-SP-4-POWRDENIED:insufficient power, module in slot [dec] power denied」のトラブルシューティング

FAN LED が赤く点灯する、または show environment status コマンドの出力に障害が表示される

関連情報

概要

このドキュメントでは、Cisco IOS®システムソフトウェアが稼働するCatalyst 6500/6000スイッチのハードウェアおよび関連する一般的な問題をトラブルシューティングする方法について説明します。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

Cisco IOS ソフトウェアは、スーパバイザ エンジンおよびマルチレイヤ スイッチ フィーチャ カード（MSFC）モジュールの両方にバンドルされている 1 つの Cisco IOS イメージを指します。このドキュメントでは、問題の症状が発生しており、ユーザがこの問題に関する追加情報を必要としているか、またはこの問題の解決を希望していることを前提としています。このドキュメントは、スーパバイザ エンジン 1、2、または 720 ベースの Catalyst 6500/6000 スイッチに適用されます。

syslog およびコンソールのエラー メッセージに関するトラブルシューティング

システム メッセージは、コンソール ログがイネーブルになっている場合はコンソールに、syslog がイネーブルになっている場合は syslog に表示されます。これらのメッセージの中には、情報提供だけを目的としており、エラー状態を示さないものがあります。システムエラーメッセージの概要については、『システムメッセージの概要』を参照してください。適切なレベルのロギングを有効にし、syslogサーバにメッセージを記録するようにスイッチを設定します。設定情報の詳細については、『ルータとスイッチデバイスの設定』ドキュメントを参照してください。

記録されたメッセージを監視するには、show loggingコマンドを発行するか、ステーションを定期的に監視するツールを使用します。それでも問題を判別できない場合、またはエラーメッセージがドキュメントに記載されていない場合は、シスコテクニカルサポートのエスカレーションセンターに連絡してください。

エラー メッセージ %CONST_DIAG-SP-4-ERROR_COUNTER_WARNING:Module 4 Error counter exceeds threshold　が Catalyst 6500 のコンソールに表示されます。この問題には、次の 2 つの原因が考えられます。

- バックプレーンへの不完全な接続（コネクタ ピンの曲がりや不完全な電気的接続）、または

- モジュールに欠陥があることを示す最初の徴候と考えられる原因。

この問題を解決するには、診断時の起動レベルを「complete」に設定し、モジュール 4 をシャーシにしっかりと装着します。これは、潜在的なハードウェア障害をキャッチし、バックプレーン接続の問題を解決します。

show diagnostic sanity コマンド

show diagnostic sanity コマンドは、特定のシステム状態の組み合せについて、設定で事前に決められた一連のチェックを実行します。その後、警告状態のリストを作成します。これらのチェックは、不適切と思われる設定を検出する設計になっています。このチェックは、システムの健全性を維持するためのトラブルシューティングに役立ちます。このコマンドでは、現在の変数やシステム状態は変更されません。事前に設定された組み合せに一致した場合に警告を発するために、設定に関連するシステム変数と状態を読み取ります。このコマンドはスイッチの機能には影響しないため、実稼働ネットワーク環境で使用できます。プロセス実行中の唯一の制限事項は、このコマンドがブート イメージにアクセスして有効性を検証する間、一定時間ファイル システムを予約することです。このコマンドは、Cisco IOS ソフトウェア リリース 12.2(18)SXE1 以降でサポートされています。

このコマンドは、有効と思われるものの負の意味を持つ可能性があるパラメータの設定を確認するのに役立ちます。次の場合、ユーザに警告を発してください。

- Trunking：トランク モードが「on」であるか、またはポートが「auto」でトランキングしている場合。トランク ポートのモードが desirable に設定されているのにトランキングしていないか、またはトランク ポートが半二重にネゴシエートされている場合。

- Channeling：チャネリング モードが「on」であるか、またはポートがチャネリングしていないのに、モードが desirable に設定されている場合。

- Spanning Tree：次のいずれかがデフォルトに設定されている場合。

- Root Max Age

- root forward delay

- 最大経過時間

- max forward delay

- ハロー タイム

- port cost

- port priority

または、VLAN にスパニングツリー ルートが設定されていない場合。

- UDLD：ポートで UniDirectional Link Detection（UDLD）がディセーブル、シャットダウン、または undetermined 状態になっている場合。

- Flow control and PortFast：ポートがフロー制御を無効に受け取ったか、PortFastが有効になっている場合。

- High Availability：冗長構成のスーパーバイザ エンジンがあるが、high availability（HA）がディセーブルになっている場合。

- Boot String and boot config register：ブートストリングが空であるか、ブートイメージとして無効なファイルが指定されています。コンフィギュレーション レジスタが 0x2、0x102、0x2102 以外に設定されている場合。

- IGMP Snooping：Internet Group Management Protocol（IGMP）スヌーピングがディセーブルの場合。また、IGMPスヌーピングが無効で、Router-Port Group Management Protocol(RGMP)が有効である場合、およびマルチキャストがグローバルに有効だがインターフェイスで無効である場合も同様です。

- SNMP Community access strings：アクセス ストリング（rw、ro、rw-all）がデフォルトに設定されている場合。

- Ports：ポートが半二重にネゴシエートされているか、デュプレックス/VLANの不一致があります。

- Inline power ports：インラインパワー ポートが次のいずれかの状態になっている場合。

- denied

- faulty

- その他

- オフ

- Modules：モジュールの状態が「ok」以外の場合。

- Tests：起動時に障害が検出されたシステム診断テストをリストアップします。

- Default gateway(s) unreachable：デフォルトのゲートウェイに ping を送信して、到達不能なものをリストアップします。

- ブートフラッシュが正しくフォーマットされているかどうか、ならびに crashinfo ファイルを保存するのに十分なスペースがあるかどうかをチェックします。

次に出力例を示します。

注：実際の出力は、ソフトウェアのバージョンにより異なる場合があります。

Switch#show diagnostic sanity

Status of the default gateway is:

10.6.144.1 is alive

The following active ports have auto-negotiated to half-duplex:

4/1

The following vlans have a spanning tree root of 32k:

1

The following ports have a port cost different from the default:

4/48,6/1

The following ports have UDLD disabled:

4/1,4/48,6/1

The following ports have a receive flowControl disabled:

4/1,4/48,6/1

The value for Community-Access on read-only operations for

SNMP is the same as default. Please verify that this is the best

value from a security point of view.

The value for Community-Access on read-write operations for SNMP is

the same as default. Please verify that this is the best value from

a security point of view.

The value for Community-Access on read-write-all operations for SNMP

is the same as default. Please verify that this is the best value from

a security point of view.

Please check the status of the following modules:

8,9

Module 2 had a MINOR_ERROR.

The Module 2 failed the following tests:

TestIngressSpan

The following ports from Module2 failed test1:

1,2,4,48

『ソフトウェアコンフィギュレーションガイド』の「show diagnostic sanity」セクションを参照してください。

スーパーバイザ エンジンまたはモジュールの問題

スーパーバイザ エンジンの LED が赤/オレンジになる、またはステータスが faulty と表示される

スイッチのスーパーバイザ エンジン LED が赤色に点灯するか、ステータスが faulty を示す場合、ハードウェアの問題が存在する可能性があります。次のようなシステム エラー メッセージが表示される場合があります。

%DIAG-SP-3-MINOR_HW:

Module 1: Online Diagnostics detected Minor Hardware Error

さらにトラブルシューティングを行うには、次の手順を使用します。

1. スーパーバイザエンジンにコンソール接続し、show diagnostic module {1 | 2}コマンドを発行します。

注：診断レベルは complete に設定する必要があります。それによって、スイッチは、ハードウェア障害を判別するためのフル スイートのテストを実行できるようになります。complete レベルのオンライン診断テストを実行すると、起動に少し時間がかかるようになります。minimal レベルでの起動では、complete レベルほど長い時間ではありませんが、カードの潜在的なハードウェア問題の検出は同じように行われます。診断レベルを切り替えるには、diagnostic bootup levelグローバルコンフィギュレーションコマンドを発行します。Cisco IOSシステムソフトウェアでは、デフォルトの診断レベルはminimalです。

注：Cisco IOS ソフトウェアが稼働する Supervisor Engine 1 ベースのシステムでは、オンライン診断はサポートされていません。

次に出力では、障害の例が示されています。

Router#show diagnostic mod 1

Current Online Diagnostic Level = Complete

Online Diagnostic Result for Module 1 : MINOR ERROR

Test Results: (. = Pass, F = Fail, U = Unknown)

1 . TestNewLearn             : .

2 . TestIndexLearn           : .

3 . TestDontLearn            : .

4 . TestConditionalLearn     : F

5 . TestBadBpdu              : F

6 . TestTrap                 : .

7 . TestMatch                : .

8 . TestCapture              : F

9 . TestProtocolMatch        : .

10. TestChannel              : .

11. IpFibScTest              : .

12. DontScTest               : .

13. L3Capture2Test           : F

14. L3VlanMetTest            : .

15. AclPermitTest            : .

16. AclDenyTest              : .

17. TestLoopback:

Port  1  2

----------

.  .

18. TestInlineRewrite:

Port  1  2

----------

.  .

パワーオン診断で failure が返されるとき、つまりテスト結果に F が示されている場合には、次の手順を実行します。

1. モジュールをしっかりと取り付け直して、ネジがしっかり締め付けられていることを確認します。

2. 同じシャーシまたは別のシャーシにある正常な正常なスロットにモジュールを移動します。

注：Supervisor Engine 1 や 2 は、スロット 1 またはスロット 2 だけに装着できます。

3. トラブルシューティングを実行して、モジュールに障害が発生している可能性を排除します。

注：まれに、モジュールの障害によって、スーパーバイザ エンジンが faulty と報告される結果になる場合があります。

この可能性を排除するには、次の手順のいずれかを実行します。

- 最近モジュールを挿入したことがあり、スーパーバイザ エンジンが問題を報告し始めた場合には、最後に挿入したモジュールを取り外して、しっかりと取り付け直します。それでもスーパーバイザ エンジンが faulty であることを示すメッセージが表示される場合は、そのモジュールを取り外してリブートします。スーパーバイザ エンジンが正常に機能している場合は、モジュールに障害がある可能性があります。モジュールのバックプレーン コネクタを調べて、損傷がないことを確認します。損傷を確認できない場合は、そのモジュールを別のスロットか別のシャーシで試してみます。また、バックプレーンのスロット コネクタのピンが曲がっていないかを調べます。シャーシのバックプレーンにあるコネクタ ピンを調べるときには、必要に応じて懐中電灯を使用してください。それでもサポートが必要な場合には、シスコ テクニカルサポートにお問い合せください。

- 最近モジュールを追加したわけではなく、またスーパーバイザ エンジンを交換しても問題が解決されない場合は、モジュールが不適切に取り付けられている可能性、またはモジュールに欠陥がある可能性があります。トラブルシューティングを進めるには、スーパーバイザ エンジン以外のすべてのモジュールをシャーシから取り外します。シャーシの電源を投入して、スーパーバイザ エンジンが問題なく起動することを確認します。スーパーバイザ エンジンが問題なく起動したら、障害のあるモジュールが特定されるまで、一度に 1 つずつモジュールを挿入して確認します。スーパーバイザ エンジンで障害が再び発生しなければ、いずれかのモジュールが適切に取り付けられていなかった可能性があります。スイッチを観察して、問題が続くようであれば、シスコ テクニカルサポートでサービス リクエストを作成して、さらにトラブルシューティングを継続します。

これらの各手順を実行した後で、show diagnostic module <module_number>コマンドを発行します。モジュールで failure ステータスがまだ表示されているかどうかを調べます。failureステータスがまだ表示される場合は、前のステップのログをキャプチャし、シスコテクニカルサポートでサービスリクエストを作成して、サポートを依頼してください。

注：Cisco IOS ソフトウェア リリース 12.1(8) トレインが稼働している場合は、この診断機能はフルサポートされません。診断をイネーブルにすると、誤った障害メッセージが返されます。診断機能は、Cisco IOS ソフトウェア リリース 12.1(8b)EX4 以降でサポートされています。また、スーパーバイザ エンジン 2 ベースのシステムの場合は、Cisco IOS ソフトウェア リリース 12.1(11b)E1 以降でサポートされています。また、詳細は、『Field Notice：Cisco IOSソフトウェアリリース12.1(8b)EX2および12.1(8b)EX3で診断が誤ってイネーブルにされる』を参照してください。

2. スイッチが起動せず、ブートシーケンス中に自己診断に失敗する場合は、出力をキャプチャし、シスコテクニカルサポートでサービスリクエストを作成して、サポートを依頼してください。

3. ブート シーケンスや show diagnostics module {1 | 2} コマンドを発行し、show environment status およびshow environment temperature コマンドを発行して、環境条件に関連する出力をチェックし、他の障害が発生したコンポーネントを探します。

cat6knative#show environment status

backplane:

operating clock count: 2

operating VTT count: 3

fan-tray 1:

fan-tray 1 fan-fail: OK

VTT 1:

VTT 1 OK: OK

VTT 1 outlet temperature: 35C

VTT 2:

VTT 2 OK: OK

VTT 2 outlet temperature: 31C

VTT 3:

VTT 3 OK: OK

VTT 3 outlet temperature: 33C

clock 1:

clock 1 OK: OK, clock 1 clock-inuse: in-use

clock 2:

clock 2 OK: OK, clock 2 clock-inuse: not-in-use

power-supply 1:

power-supply 1 fan-fail: OK

power-supply 1 power-output-fail: OK

module 1:

module 1 power-output-fail: OK

module 1 outlet temperature: 28C

module 1 device-2 temperature: 32C

RP 1 outlet temperature: 34C

RP 1 inlet temperature: 34C

EARL 1 outlet temperature: 34C

EARL 1 inlet temperature: 28C

module 3:

module 3 power-output-fail: OK

module 3 outlet temperature: 39C

module 3 inlet temperature: 23C

EARL 3 outlet temperature: 33C

EARL 3 inlet temperature: 30C

module 4:

module 4 power-output-fail: OK

module 4 outlet temperature: 38C

module 4 inlet temperature: 26C

EARL 4 outlet temperature: 37C

EARL 4 inlet temperature: 30C

module 5:

module 5 power-output-fail: OK

module 5 outlet temperature: 39C

module 5 inlet temperature: 31C

module 6:

module 6 power-output-fail: OK

module 6 outlet temperature: 35C

module 6 inlet temperature: 29C

EARL 6 outlet temperature: 39C

EARL 6 inlet temperature: 30C

ファンや電圧終端（VTT）などのシステム コンポーネントに何らかのエラーがある場合は、シスコ テクニカル サポートでサービス リクエストを作成し、コマンド出力を提供してください。

この出力にモジュールの障害ステータスが示されている場合は、hw-module module <module_number> resetコマンドを発行します。または、モジュールを回復させるために、同じスロットか別のスロットでモジュールを取り付け直してください。さらにサポートが必要な場合は、このドキュメントの「オンラインにならない、またはfaultyやその他のステータスを示すモジュールのトラブルシューティング」セクションを参照してください。

4. ステータスが OK と表示されている場合は、ステップ 3 の出力例に示されているように、環境アラームをチェックするために show environment alarms コマンドを発行します。

アラームがない場合、出力は次のようになります。

cat6knative#show environment alarm

environmental alarms:

no alarms

一方、アラームがある場合、出力は次のようになります。

cat6knative#show environment alarm

environmental alarms:

system minor alarm on VTT 1 outlet temperature (raised 00:07:12 ago)

system minor alarm on VTT 2 outlet temperature (raised 00:07:10 ago)

system minor alarm on VTT 3 outlet temperature (raised 00:07:07 ago)

system major alarm on VTT 1 outlet temperature (raised 00:07:12 ago)

system major alarm on VTT 2 outlet temperature (raised 00:07:10 ago)

system major alarm on VTT 3 outlet temperature (raised 00:07:07 ago)

スイッチが連続ブーティングループ状態、ROMmonモード、または Missing システムイメージ

スイッチのスーパーバイザエンジンが booting  ROMモニタ(ROMmon)モードのループ、またはシステムイメージがない場合、問題はおそらくハードウェアの問題ではありません。

システムイメージが破損しているか、またはシステムイメージが破損している場合、スーパーバイザエンジンはROMmonモードになるか、ブートに失敗します missing.スーパーバイザエンジンの回復方法については、 Cisco IOSシステムソフトウェアが稼働しているCatalyst 6500/6000の破損または Missing ブートローダーイメージまたはROMmonモード.

Cisco IOS イメージは、Sup-bootflash:、または slot0:（PC カード スロット）のどちらからでも起動できます。 迅速に回復できるように、システム イメージのコピーを両方のデバイスに置いてください。ご使用の Supervisor Engine 2 のブートフラッシュ デバイスが 16 MB しかない場合は、新しいシステム イメージをサポートするために、32 MB にアップグレードする必要があります。詳細は、『Catalyst 6500 シリーズ Supervisor Engine 2 ブート ROM とブートフラッシュ デバイス アップグレード インストレーション ノート』を参照してください。

スタンバイ状態のスーパーバイザ エンジン モジュールがオンラインにならない、またはステータスが unknown と表示される

この項では、スタンバイ スーパバイザ エンジン モジュールがオンラインにならない一般的な理由と、各問題の解決方法について説明します。次のいずれかの方法で、スーパバイザ エンジン モジュールがオンラインにならないことを判断できます。

- show module コマンドの出力で、ステータスが other または faulty と表示される。

- Status LED がオレンジ色に点灯している。

一般的な原因および解決策

- スタンバイ側のスーパーバイザエンジンにコンソール接続して、ROMmonモードまたは連続リブート状態であるかどうかを確認します。スーパバイザ エンジンがこれらのいずれかの状態にある場合は、「Cisco IOS システム ソフトウェアが稼働している Catalyst 6500/6000 でのブート ローダ イメージの破損や欠落あるいは ROMmon モードからの回復」を参照してください。

注：アクティブ側のスーパーバイザ エンジンとスタンバイ側のスーパーバイザ エンジンで同じ Cisco IOS ソフトウェア リリースが稼働していない場合は、スタンバイ側のスーパーバイザ エンジンがオンラインにならないことがあります。たとえば、次のような状況では、スーパバイザ エンジンはオンラインになれない可能性があります。

- アクティブ スーパバイザ エンジンがルート プロセッサの冗長性プラス（RPR+）モードを実行している。

注：RPR+ モードは、Cisco IOS ソフトウェア リリース 12.1[11]EX 以降で使用できます。

- スタンバイ側のスーパーバイザ エンジンで、RPR/RPR+ モードを使用できないソフトウェア バージョン（Cisco IOS ソフトウェア リリース 12.1(8b)E9 など）が稼働している場合。

この場合、2番目のスーパーバイザエンジンは、デフォルトで冗長性モードがEnhanced High System Availability(EHSA)になっているので、オンラインになりません。スタンバイ スーパバイザ エンジンは、アクティブ スーパバイザ エンジンとネゴシエーションできません。両方のスーパーバイザ エンジンで、同じレベルの Cisco IOS ソフトウェアが稼働していることを確認してください。

この出力には、スロット 2 のスーパバイザ エンジンが ROMmon モードで表示されます。回復するには、スタンバイ側のスーパーバイザエンジンにコンソール接続する必要があります。回復手順については、『Cisco IOSシステムソフトウェアが稼働しているCatalyst 6500/6000でのブートローダーイメージの破損や欠落あるいはROMmonモードからの回復』を参照してください。

tpa_data_6513_01#show module

Mod Ports Card Type                              Model              Serial No.

--- ----- -------------------------------------- ------------------ -----------

1    2  Catalyst 6000 supervisor 2 (Active)    WS-X6K-S2U-MSFC2   SAD0628035C

2    0  Supervisor-Other                       unknown            unknown

3   16  Pure SFM-mode 16 port 1000mb GBIC      WS-X6816-GBIC      SAL061218K3

4   16  Pure SFM-mode 16 port 1000mb GBIC      WS-X6816-GBIC      SAL061218K8

5    0  Switching Fabric Module-136 (Active)   WS-X6500-SFM2      SAD061701YC

6    1  1 port 10-Gigabit Ethernet Module      WS-X6502-10GE      SAD062003CM

Mod MAC addresses                       Hw    Fw           Sw           Status

--- ---------------------------------- ------ ------------ ------------ -------

1  0001.6416.0342 to 0001.6416.0343   3.9   6.1(3)       7.5(0.6)HUB9 Ok

2  0000.0000.0000 to 0000.0000.0000   0.0   Unknown      Unknown      Unknown

3  0005.7485.9518 to 0005.7485.9527   1.3   12.1(5r)E1   12.1(13)E3,  Ok

4  0005.7485.9548 to 0005.7485.9557   1.3   12.1(5r)E1   12.1(13)E3,  Ok

5  0001.0002.0003 to 0001.0002.0003   1.2   6.1(3)       7.5(0.6)HUB9 Ok

6  0002.7ec2.95f2 to 0002.7ec2.95f2   1.0   6.3(1)       7.5(0.6)HUB9 Ok

Mod Sub-Module                  Model           Serial           Hw     Status

--- --------------------------- --------------- --------------- ------- -------

1 Policy Feature Card 2       WS-F6K-PFC2     SAD062802AV      3.2    Ok

1 Cat6k MSFC 2 daughterboard  WS-F6K-MSFC2    SAD062803TX      2.5    Ok

3 Distributed Forwarding Card WS-F6K-DFC      SAL06121A19      2.1    Ok

4 Distributed Forwarding Card WS-F6K-DFC      SAL06121A46      2.1    Ok

6 Distributed Forwarding Card WS-F6K-DFC      SAL06261R0A      2.3    Ok

6 10GBASE-LR Serial 1310nm lo WS-G6488        SAD062201BN      1.1    Ok

- スーパバイザ エンジン モジュールがバックプレーン コネクタに正しく装着されていることを確認します。また、スーパーバイザエンジンの取り付けネジが完全に締められていることを確認します。詳細については、『Catalyst 6500 シリーズ スイッチ モジュールの取り付けの注意事項』を参照してください。

- スタンバイ スーパバイザ エンジンに障害があるかどうかを確認するには、アクティブ スーパバイザ エンジンから redundancy reload peer コマンドを発行します。ハードウェア障害の発生を判別するには、スタンバイ側のスーパーバイザ エンジンへのコンソール経由でブート シーケンスを観察します。

スタンバイ側のスーパーバイザエンジンがオンラインにならないままの場合は、さらにトラブルシューティングを行うために、シスコテクニカルサポートでサービスリクエストを作成します。サービスリクエストを作成する際には、前の手順で収集したスイッチ出力のログを提供します。

show module の出力で SPA モジュールが「not applicable」と表示される

このエラー メッセージが発生するのは、PA-1XCHSTM1/OC3 には SRB では診断機能がサポートされていないためです。スイッチで SRB コードを実行しながら、このコマンドが渡されると、not applicable ステータスが表示されます。全体の診断では適切な結果が出ているため、SPA インターフェイス プロセッサのステータスがチェックされていないのではありません。SRC コード以降の出力結果に関しては問題ありません。これはSRBコードの不具合が原因で、この不具合はCisco Bug ID CSCso02832（登録されたCiscoクライアントのみがアクセス可能）に記載されています。

スタンバイ側スーパーバイザ エンジンで予期しないリロードが始まる

このセクションでは、Catalyst スイッチのスーパーバイザで予期しないリロードが発生する一般的な原因について説明しています。

一般的な原因および解決策

- 障害の後では、スタートアップ コンフィギュレーションによる同期を行うために、アクティブ側のスーパーバイザがスタンバイ側のスーパーバイザをリセットします。この問題は、管理ステーションで短い間隔（1 ～ 3 秒）で連続的に実行される wr mem が原因で発生する可能性があります。つまり、それによってスタートアップ コンフィギュレーションがロックされ、同期に失敗するためです。最初の同期プロセスが完了せず、2 番目の wr mem が発行された場合、スタンバイ側のスーパーバイザは同期に失敗し、リロードまたはリセットが発生する場合もあります。この問題は、Cisco Bug ID CSCsg24830（登録されたCiscoクライアントだけにアクセス可能）に記述されています。 同期の障害は、次のエラー メッセージによって特定できます。

%PFINIT-SP-5-CONFIG_SYNC: Sync'ing the startup configuration to

the standby Router

%PFINIT-SP-1-CONFIG_SYNC_FAIL: Sync'ing the startup configuration

to the standby Router FAILED

- アクティブ側のスーパーバイザは、スタンバイ側のスーパーバイザとコンフィギュレーションを同期していません。これは一時的な状態であり、他のプロセスによって、コンフィギュレーション ファイルが一時的に利用されていることによって発生します。コンフィギュレーションまたは実行コンフィギュレーションを表示するために、show configuration コマンドまたは show running-configuration コマンドを入力すると、コンフィギュレーション ファイルがロックされます。この問題は、Cisco Bug ID CSCeg21028（登録Ciscoクライアントによるアクセスのみ）に記述されています。 同期の障害は、次のエラー メッセージによって特定できます。

%PFINIT-SP-1-CONFIG_SYNC_FAIL_RETRY: Sync'ing the startup

configuration to the standby Router FAILED, the file may be already locked by a command

モジュールを取り外した後も、show run コマンドで取り外したモジュールのインターフェイスに関する情報が表示される

モジュールをシャーシから物理的に取り外しても、スロット内のそのモジュールのコンフィギュレーションが引き続き表示されます。この問題は、モジュールの交換を容易にする設計に由来するものです。スロットに同じタイプのモジュールを挿入した場合、スイッチでは、以前にスロットに入っていたモジュールのコンフィギュレーションが使用されます。このスロットに別のタイプのモジュールが挿入されると、このモジュールのコンフィギュレーションはクリアされます。スロットからモジュールが取り外されたときに、自動的にコンフィギュレーションを削除するには、グローバル コンフィギュレーション モードで module clear-config コマンドを発行します。コマンドは、必ずスロットからモジュールが取り外される前に発行するようにしてください。このコマンドでは、スロットからすでに取り外されているモジュールの古いコンフィギュレーションはクリアされません。このコマンドでクリアされるのは、show running-config コマンドで出力されたモジュール コンフィギュレーションと、show ip interface brief コマンドで出力されたインターフェイス詳細情報です。Cisco IOS リリース 12.2(18)SXF 以降では、show version コマンドで出力されたインターフェイス タイプのカウントも削除されます。

スイッチの自動リセットまたはリブート

手動介入なしでスイッチが自動的にリセットした場合には、次の手順に従って問題を特定してください。

一般的な原因および解決策

- スイッチは、ソフトウェア クラッシュになっている可能性があります。dir bootflash:コマンドを発行してMSFC(ルートプロセッサ(RP))のブートフラッシュデバイスを表示し、dir slavebootflash:コマンドを発行してソフトウェアクラッシュが発生しているかどうかを確認します。

このセクションの出力を見ると、RP bootflash: に crashinfo が記録されていることがわかります。この crashinfo が最も最近のクラッシュに関するものであることを確認してください。crashinfo ファイルを表示するには、more bootflash:filename コマンドを発行します。この例では、コマンドは more bootflash:crashinfo_20020829-112340 です。

cat6knative#dir bootflash:

Directory of bootflash:/

1  -rw-     1693168   Jul 24 2002 15:48:22  c6msfc2-boot-mz.121-8a.EX

2  -rw-      183086   Aug 29 2002 11:23:40  crashinfo_20020829-112340

3  -rw-    20174748   Jan 30 2003 11:59:18  c6sup22-jsv-mz.121-8b.E9

4  -rw-        7146   Feb 03 2003 06:50:39  test.cfg

5  -rw-       31288   Feb 03 2003 07:36:36  01_config.txt

6  -rw-       30963   Feb 03 2003 07:36:44  02_config.txt

31981568 bytes total (9860396 bytes free)

dir sup-bootflash:コマンドでは、スーパーバイザ エンジンの bootflash:デバイスをフォーマットします。dir slavesup-bootflash:コマンドでは、スタンバイ側のスーパーバイザ エンジンの bootflash:デバイスをフォーマットします。次の出力には、スーパーバイザ エンジンの bootflash: デバイスに記録された crashinfo を表示します。

cat6knative11#dir sup-bootflash:

Directory of sup-bootflash:/

1  -rw-    14849280   May 23 2001 12:35:09  c6sup12-jsv-mz.121-5c.E10

2  -rw-       20176   Aug 02 2001 18:42:05  crashinfo_20010802-234205

!--- Output suppressed.

スイッチがリブートされたと思われる時刻にソフトウェア クラッシュが発生していたことがコマンド出力に表示されている場合は、Cisco テクニカルサポートまでお問い合せください。その際には、crashinfo ファイルの出力のほかに、show tech-support および show logging コマンドの出力も提供してください。ファイルを送るには、スイッチから TFTP サーバに TFTP で転送し、ファイルをサービス リクエストに添付してください。

- crashinfo ファイルがない場合は、スイッチの電源を調べて、電源に障害が発生していないことを確認してください。無停電電源装置（UPS）を使用している場合には、装置が正常に操作していることを確認します。それでも問題が判別できない場合は、シスコのテクニカルサポートのエスカレーション センターにお問い合せください。

DFC 装備モジュールの自動リセット

Distributed Forwarding Card（DFC；分散型フォワーディングカード）を搭載したモジュールが、ユーザのリロードなしで自動的にリセットされた場合は、DFCカードのブートフラッシュをチェックして、クラッシュしたかどうかを確認します。クラッシュ情報ファイルが作成されている場合は、クラッシュの原因を確認できます。クラッシュ情報ファイルがあるかどうか、およびいつ書き出されたかを確認するには、dir dfc#module_#-bootflash: コマンドを発行します。DFC のリセットが crashinfo のタイムスタンプに一致する場合は、more dfc#module_#-bootflash:filename コマンドを発行します。または、copy dfc#module_#-bootflash:filename tftp コマンドを発行して、TFTP 経由で、そのファイルを TFTP サーバに転送してください。

cat6knative#dir dfc#6-bootflash:

Directory of dfc#6-bootflash:/

-#- ED ----type---- --crc--- -seek-- nlen -length- -----date/time------ name

1   ..   crashinfo 2B745A9A   C24D0   25   271437 Jan 27 2003 20:39:43 crashinfo_

20030127-203943

サポートが必要な場合は、crashinfo ファイルと、show logging および show tech コマンドの出力を用意して、シスコ テクニカルサポートに連絡してください。

オンラインにならなかったり、faulty やその他のステータスが表示されるモジュールのトラブルシューティング

このセクションでは、モジュールの1つがオンラインにならない一般的な原因と、問題の解決方法について説明します。次のいずれかの方法で、モジュールがオンラインにならないことを確認できます。

- show module コマンドの出力に、次のいずれかのステータスが表示されている。

- その他

- unknown

- faulty

- errdisable

- power-deny

- power-bad

- Status LED がオレンジ色か赤色に点灯している。

一般的な原因および解決策

- 関連するリリースの『Catalyst 6500 シリーズのリリース ノート』の「サポート対象ハードウェア」セクションを調べてください。現在実行しているソフトウェアでモジュールがサポートされていない場合は、Cisco IOS Software Centerから必要なソフトウェアをダウンロードします。

- ステータスが power-deny である場合、スイッチにはこのモジュールに電力を供給するのに十分な電力がありません。十分な電力を利用できるかどうかを確認するには、show power コマンドを発行します。このドキュメントの「Troubleshoot C6KPWR-4-POWRDENIED: insufficient power, module in slot [dec] power denied or %C6KPWR-SP-4-POWRDENIED:insufficient power, module in slot [dec] power denied」のトラブルシューティング」セクションを参照してください。

- ステータスが power-bad の場合、スイッチはカードを認識していますが、電力を割り当てることができません。ラインカードの ID を判別するために、スーパーバイザ エンジンがモジュール上のシリアル PROM（SPROM）のコンテンツにアクセスできない場合に、この現象が発生する可能性があります。SPROMが読み取り可能かどうかを確認するには、show idprom moduleコマンドを発行します。SPROM にアクセスできない場合は、モジュールをリセットします。

- モジュールがコネクタに適切に取り付けられて、完全にネジ止めされていることを確認してください。それでもモジュールがオンラインにならない場合は、diagnostic bootup level completeグローバルコンフィギュレーションコマンドを発行して、診断がイネーブルになっていることを確認します。次に、hw-module module <slot_number> resetコマンドを発行します。それでもモジュールがオンラインにならない場合は、モジュールのバックプレーンコネクタを調べて、破損がないことを確認します。視認できる損傷がない場合は、別のスロットまたは別のシャーシにモジュールを取り付けてみてください。また、バックプレーンのスロット コネクタのピンが曲がっていないかを調べます。シャーシのバックプレーンにあるコネクタ ピンを調べるときには、必要に応じて懐中電灯を使用してください。

- show diagnostics module <slot_number>コマンドを発行して、モジュールのハードウェア障害を特定します。完全な診断をイネーブルにするには、diagnostic bootup level completeグローバルコンフィギュレーションコマンドを発行します。スイッチでモジュールの診断を実行できるようにするには、完全な診断をイネーブルにする必要があります。最小限の診断を完全な診断に変更する場合には、スイッチで完全な診断を実行できるようにするには、モジュールをリセットする必要があります。このセクションの出力例では、show diagnostics module コマンドを発行しています。ところが、テストの多くはすでに最小限のモードで実行されているため、この出力結果は確定的ではありません。この出力では、完全な結果を表示するために、診断レベルをオンにして、show diagnostics module コマンドを再発行する方法が示されています。

注：出力例のモジュールには、ギガビット インターフェイス コンバータ（GBIC）はインストールされていません。そのため、完全性テストは実施されていません。BIC の完全性テストが実行されるのは、銅線接続対応の GBIC（WS-G5483=）に対してだけです。

cat6native#show diagnostic module 3

Current Online Diagnostic Level = Minimal

Online Diagnostic Result for Module 3 : PASS

Online Diagnostic Level when Module 3 came up = Minimal

Test Results: (. = Pass, F = Fail, U = Unknown)

1 . TestGBICIntegrity :

Port  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16

----------------------------------------------------

U  U  U  U  U  U  U  U  U  U  U  U  U  U  U  U

2 . TestLoopback :

Port  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16

----------------------------------------------------

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

3 . TestDontLearn                 : U

4 . TestConditionalLearn          : .

5 . TestStaticEntry               : U

6 . TestCapture                   : U

7 . TestNewLearn                  : .

8 . TestIndexLearn                : U

9 . TestTrap                      : U

10. TestIpFibShortcut             : .

11. TestDontShortcut              : U

12. TestL3Capture                 : U

13. TestL3VlanMet                 : .

14. TestIngressSpan               : .

15. TestEgressSpan                : .

16. TestAclPermit                 : U

17. TestAclDeny                   : U

18. TestNetflowInlineRewrite :

Port  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16

----------------------------------------------------

U  U  U  U  U  U  U  U  U  U  U  U  U  U  U  U

!--- Tests that are marked "U" were skipped because a minimal

!--- level of diagnostics was enabled.

cat6knative#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

cat6knative(config)#diagnostic bootup level complete

!--- This command enables complete diagnostics.

cat6knative(config)#end

cat6knative#

*Feb 18 13:13:03 EST: %SYS-5-CONFIG_I: Configured from console by console

cat6knative#

cat6knative#hw-module module 3 reset

Proceed with reload of module? [confirm]

% reset issued for module 3

cat6knative#

*Feb 18 13:13:20 EST: %C6KPWR-SP-4-DISABLED: power to module in slot 3 set off

(Reset)

*Feb 18 13:14:12 EST: %DIAG-SP-6-RUN_COMPLETE: Module 3: Running Complete Online

Diagnostics...

*Feb 18 13:14:51 EST: %DIAG-SP-6-DIAG_OK: Module 3: Passed Online Diagnostics

*Feb 18 13:14:51 EST: %OIR-SP-6-INSCARD: Card inserted in slot 3, interfaces

are now online

cat6knative#show diagnostic module 3

Current Online Diagnostic Level = Complete

Online Diagnostic Result for Module 3 : PASS

Online Diagnostic Level when Module 3 came up = Complete

Test Results: (. = Pass, F = Fail, U = Unknown)

1 . TestGBICIntegrity :

Port  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16

----------------------------------------------------

U  U  U  U  U  U  U  U  U  U  U  U  U  U  U  U

!--- The result for this test is unknown ("U", untested)

!--- because no copper GBICS are plugged in.

2 . TestLoopback :

Port  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16

----------------------------------------------------

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

3 . TestDontLearn                 : .

4 . TestConditionalLearn          : .

5 . TestStaticEntry               : .

6 . TestCapture                   : .

7 . TestNewLearn                  : .

8 . TestIndexLearn                : .

9 . TestTrap                      : .

10. TestIpFibShortcut             : .

11. TestDontShortcut              : .

12. TestL3Capture                 : .

13. TestL3VlanMet                 : .

14. TestIngressSpan               : .

15. TestEgressSpan                : .

16. TestAclPermit                 : .

17. TestAclDeny                   : .

18. TestNetflowInlineRewrite :

Port  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16

----------------------------------------------------

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

- show tech-support コマンドと show logging コマンドを発行します。さらにトラブルシューティングを進めるには、このモジュールに関する他のメッセージを探します。

モジュールがオンラインにならないままの場合は、さらにトラブルシューティングを行うために シスコのテクニカルサポートへのサービス リクエストを作成します。収集したスイッチ出力のログと前のステップの情報を提供します。

インバンド通信障害

スーパーバイザ エンジンでは、インバンド通信障害を示すメッセージを送出できます。スイッチには次のようなメッセージがログに記録されます。

InbandKeepAliveFailure:Module 1 not responding over inband

InbandKeepAlive:Module 2 inband rate: rx=0 pps, tx=0 pps

ProcessStatusPing:Module 1 not responding over SCP

ProcessStatusPing:Module 1 not responding... resetting module

一般的な原因および解決策 1

スイッチの管理インターフェイスで大量のトラフィックが処理されると、スイッチでは InbandKeepAliveFailure エラー メッセージの発生がログに記録されます。これには、次の理由が考えられます。

- スーパーバイザ エンジンのビジー状態

- スパニングツリー プロトコルのループ状態

- インバンド通信チャネルでの ACL および QoS ポリサーによるトラフィックの抑制や廃棄

- ポート ASIC 同期の問題

- スイッチ ファブリック モジュールの問題

この問題を解決するには、次の手順を実行します。

1. show process cpu コマンドを使用して、問題を起こしているプロセスを特定します。根本的な原因を解消するには、『Catalyst 6500/6000 スイッチの CPU 高使用率』を参照してください。

2. これらのコミュニケーション障害メッセージは、誤って装着されたり、障害のあるスーパーバイザ モジュールにより送出される場合があります。このエラー メッセージからの復旧には、メンテナンスの時間を確保して、スーパーバイザ モジュールを取り付け直してください。

電源オンによりシステムが ROM モードに戻る（SP by Abort）

Cisco IOS ソフトウェアが稼動する Cisco Catalyst 6500/6000 では、次のリセット理由が表示され、リロードされたように見える場合があります。

System returned to ROM by power-on (SP by abort)

Catalyst 6500/6000 の SP のコンフィギュレーション レジスタがブレークを許可するように設定されている場合（たとえば、0x2）、コンソールのブレーク信号を受信すると ROMmon 診断モードに入ります。システムはクラッシュしたように見えます。SP と RP でのコンフィギュレーション レジスタ設定のミスマッチにより、このタイプのリロードが発生する可能性があります。具体的には、スーパーバイザ エンジンのスイッチ プロセッサ（SP）のコンフィギュレーション レジスタを ignore break を実行しない値に設定して、その一方で、マルチレイヤ スイッチ フィーチャ カード（MSFC）のルート プロセッサ（RP）のコンフィギュレーション レジスタを ignore break を実行する適切な値に設定した場合です。たとえば、スーパーバイザエンジンSPを0x2、MSFC RPを0x2102に設定できます。詳細は、『Cisco IOS Catalyst 6500/6000のリセット』を参照してください。

Cisco IOS ソフトウェアが稼動する Cisco Catalyst 6500/6000 では、実行コンフィギュレーションの BOOT 変数の設定にかかわらず、sup-bootdisk 内の古いイメージが起動されます。外部フラッシュからブートするように BOOT 変数が設定されている場合でも、スイッチでは sup-bootdisk 内の古いイメージだけが起動されます。この問題の原因は、SP と RP でのコンフィギュレーション レジスタ設定のミスマッチにあります。

RP でコマンド show bootvar を発行します。

Switch#show boot

BOOT variable =

sup-bootdisk:s72033-advipservicesk9_wan-mz.122-18.SXF7.bin,1;

CONFIG_FILE variable =

BOOTLDR variable =

Configuration register is 0x2102

SP でコマンド show bootvar を発行します。

Switch-sp#show boot

BOOT variable = bootdisk:s72033-advipservicesk9_wan-mz.122-18.SXF7.bin,1;

CONFIG_FILE variable does not exist

BOOTLDR variable does not exist

Configuration register is 0x2101

このように設定されているために、スイッチでは、実行コンフィギュレーションでの BOOT 変数の設定にかかわらず、以前のイメージでブートされることになります。この問題を解決するには、switch(config)#config-register 0x2102 コマンドを発行した後で、SP と RP のコンフィギュレーション レジスタ値が同じであることを確認します。設定をスタートアップコンフィギュレーションに書き込んだ後、スイッチをリロードします。

エラー:NVRAM: nv->magic != NVMAGIC, invalid nvram

このエラー メッセージは、NVRAM に問題があることを示しています。NVRAMを消去してスイッチをリロードすると、NVRAMを回復できます。それでも問題が解決しない場合は、NVRAMをフォーマットして問題を解決します。いずれの場合も、NVRAM のコンテンツのバックアップを取っておくことを推奨いたします。このエラー メッセージが表示されるのは、NVRAM デバッギングがイネーブルになっている場合だけです。

エラー:Switching Bus FIFO counter stuck

エラー メッセージ「CRIT_ERR_DETECTED Module 7 - Error: Switching Bus FIFO counter stuckは、モジュールがデータスイッチングバス上で動作していないことを示します。このエラーは、新しく挿入されたモジュールが最初はシャーシにしっかり挿入されなかったか、または押し込みが遅すぎたことが原因である可能性があります。

問題を解決するには、モジュールを取り付け直します。

エラー:カウンターがしきい値を超えているが、システム オペレーションが続行する

Catalyst 6500 vss クラスタで、次のエラー メッセージが表示されます。

%CONST_DIAG-4-ERROR_COUNTER_WARNING: Module [dec] Error counter exceeds

threshold, system operation continue.

TestErrorCounterMonitorは、指定されたモジュールのエラーカウンタがしきい値を超えたことを検出しました。エラーカウンタに関する特定のデータは、別のシステムメッセージで送信できます。TestErrorCounterMonitorは、システム内の各ラインカードまたはスーパーバイザモジュールのエラーカウンタと割り込みカウンタを定期的にポーリングする、中断のないヘルスモニタリングのバックグラウンドプロセスです。

%CONST_DIAG-4-ERROR_COUNTER_DATA: ID:[dec] IN:[dec] PO:[dec] RE:[dec] RM:[dec]

DV:[dec] EG:[dec] CF:[dec] TF:[dec]

TestErrorCounterMonitorは、指定されたモジュールのエラーカウンタがしきい値を超えたことを検出しました。このメッセージには、エラーカウンタに関する特定のデータと、カウンタのASICとレジスタに関する情報、およびエラーカウントが含まれています。

このエラーメッセージは、ラインカード上のASICが不正なCRCを持つパケットを受信すると表示されます。この問題は、このモジュールに固有である可能性があり、シャーシ内の他の障害のあるモジュールによってトリガーされる場合があります。

以下に、いくつかの例を示します。

%CONST_DIAG-SW1_SP-4-ERROR_COUNTER_WARNING: Module 2

Error counter exceeds threshold, system operation continue.

このエラーは、新しく挿入されたモジュールがしっかりと挿入されていないために発生する可能性があります。問題を解決するには、モジュールを取り付け直してください。

エラー:これ以上 SWIDB を割り当てることができない

ソフトウェアインターフェイス記述子ブロック(SWIDB)の最大数に達すると、次のエラーメッセージが表示されます。

%INTERFACE_API-SP-1-NOMORESWIDB: これ以上SWIDBを割り当てることはできません。最大許容12000数

『Cisco IOSプラットフォームのインターフェイスおよびサブインターフェイスの最大数：IDB制限』を参照してください。

非スイッチポートインターフェイスをスイッチポートに変換しようとすると、エラーが返されます。

Switch(config)#interface gigabit ethernet 7/29

Switch(config-if)#switchport

%Command rejected: Cannot convert port.

Maximum number of interfaces reached.

Output of idb:

AMC440E-SAS01#show idb

Maximum number of Software IDBs 12000.  In use 11999.

HWIDBs     SWIDBs

Active                    218        220

Inactive                11779      11779

Total IDBs              11997      11999

Size each (bytes)        3392       1520

Total bytes          40693824   18238480

次の例は、（SWIDBs列の下の）Total IDBsの数がIDBの最大数の制限に達したことを示しています。サブインターフェイスを削除すると、SWIDB列のActiveとInactiveの数値が変わります。ただし、合計IDB数はメモリに残ります。この問題を解決するには、スイッチをリロードしてIDBデータベースをクリアします。それ以外の場合は、使い果たしてしまったら、削除したサブインターフェイスを再利用する必要があります。

SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE!

Cisco Catalyst 6500 スイッチで、指定の Cisco IOS ソフトウェア リリースを使用した起動が失敗すると、同様のエラー メッセージが報告されます。

00:00:56: %SYS-SP-2-MALLOCFAIL: Memory allocation of 2177024 bytes failed from 0x40173D8C,

alignment 8

Pool: Processor  Free: 1266272  Cause: Not enough free memory

Alternate Pool: None  Free: 0  Cause: No Alternate pool

-Process= "TCAM Manager process", ipl= 0, pid= 112

-Traceback= 4016F4D0 40172688 40173D94 40577FF8 4055DB04 4055DEDC

SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE!

%Software-forced reload

この問題は、フラッシュ内のイメージを圧縮解除するのに利用できる DRAM の容量が不足している場合によく発生します。

この問題を解決するには、次のいずれかの手順を実行します。

- DRAM をアップグレードする。

『Cisco IOS ソフトウェア リリースの選択方法』の「メモリ要件」（例 4）セクションを参照してください。それによって、使用のイメージに必要な DRAM 総量を算出できます。

- 現在のメモリ サイズに適したイメージをロードする。

ご使用の Catalyst 6500/6000 にインストールされているスーパーバイザのタイプを判別するには、『Catalyst 6500/6000 シリーズ スイッチにインストールされたスーパーバイザ モジュールのタイプ判別方法』を参照してください。

Catalyst 6500/6000 で使用可能なデフォルトのメモリ オプションを調べるには、『Catalyst スイッチ プラットフォームでサポートされるメモリおよびフラッシュ サイズ』を参照してください。

適切なソフトウェアを選択してダウンロードするには、「ソフトウェア ダウンロード - スイッチ」（登録ユーザ専用）ページを参照してください。

インターフェイスやモジュールの接続障害

サーバ ファームで使用されている WS-X6548-GE-TX および WS-X6148-GE-TX モジュールに見られる接続性の問題、またはパケットの消失

WS-X6548-GE-TX モジュールか WS-X6148-GE-TX モジュールを使用している場合、個々のポートの使用率により、周囲のインターフェイスで接続性の問題やパケットの喪失が発生する可能性があります。特に、これらのラインカードで EtherChannel と Remote Switched Port Analyzer（RSPAN）を使用しているときは、パケットの喪失による応答の遅延が発生する可能性があります。これらのラインカードは、ギガビットをデスクトップまで拡張するように設計されたオーバーサブスクリプションカードであり、サーバファーム接続には最適ではありません。これらのモジュールには、8 つのポートをサポートするポート ASIC からの単一の 1 ギガビット イーサネット アップリンクがあります。8 つのポートからなる各ブロックは 8:1 のオーバーサブスクライブであるため、これらのカードでは、ポート（1-8、9-16、17-24、25-32、33-40、および 41-48）のグループ間で 1 Mb のバッファが共有されます。8 つのポートからなる各ブロックの集約スループットは、1 Gbps を超えることはできません。さまざまなタイプのイーサネット インターフェイス モジュールとポートあたりのサポート バッファ サイズの詳細は、『Cisco Catalyst 6500 シリーズ 10/100 および 10/100/1000 Mbps イーサネット インターフェイス モジュール』の表 4 を参照してください。

オーバーサブスクライブは、複数のポートが単一の Pinnacle ASIC に統合されていることにより発生します。Pinnacle ASIC は、パックプレーンのスイッチング バスとネットワーク ポート間でパケットを転送するダイレクト メモリ アクセス（DMA）エンジンです。この範囲にあるいずれかのポートで、その帯域幅を超えたレートでトラフィックの送受信が行われるか、またはバースト性のトラフィックを処理するために大量のバッファが使用された場合には、同じ範囲にある他のポートでパケットの喪失が発生する可能性があります。

VLAN 全体や複数のポートから単一インターフェイスへのトラフィックのコピーは珍しくないため、スパンの終点にこそ原因があります。個別にインターフェイス バッファを備えたカードでは、宛先ポートの帯域幅を超えたパケットは通知されることなく廃棄されるため、他のポートに影響が及ぶことはありません。共有バッファの場合には、これによって同じ範囲内の他のポートで接続性の問題が発生します。ただし、ほとんどのシナリオでは、共有バッファにより問題が発生することはありません。ワークステーションにギガビットが 8 つ接続されている場合であっても、割り当てられている帯域幅を超過することはほとんどありません。

スイッチでローカル SPAN を設定してあると、特に大量の送信元ポートを監視している場合に、サービスの低下が発生する可能性があります。特定の VLAN を複数監視していて、これらの VLAN のいずれかに多数のポートが割り当てられている場合には、この問題は解決しません。

SPAN がハードウェアで実行されていても、スイッチでは 2 倍のトラフィックが搬送されるため、パフォーマンスに影響が現れます。各ラインカードでは、入力時にトラフィックが複製されるため、ポートが監視されている場合には、ファブリック到着時にすべての入力トラフィックは倍になります。ラインカードで多数のビジー ポートのトラフィックをキャプチャすると、特に 8 ギガビットのファブリック接続しかない WS-6548-GE-TX カードでは、ファブリック接続がいっぱいになる可能性があります。

WS-X6548-GE-TX、WS-X6548V-GE-TX、WS-X6148-GE-TX、および WS-X6148V-GE-TX モジュールには、EtherChannel に関する制約があります。EtherChannel では、データの宛先が別のリンクであっても、バンドル内のすべてのリンクからのデータがポート ASIC に送信されます。このデータは 1 ギガビット イーサネット リンクの帯域幅を消費します。これらのモジュールでは、EtherChannel 上のすべてのデータの合計が 1 ギガビットを超えることはできません。

バッファの過剰使用に関連した廃棄が発生しているモジュールを確認するには、次の出力を調べてください。

- ネイティブCisco IOS

Cat6500# show counters interface gigabitEthernet <mod/port> | include qos3Outlost

51. qos3Outlost = 768504851

asicreg が一定の傾向で増加していることを確認するために、show コマンドを何度か発行します。asicreg の出力は実行されるたびにクリアされます。asicreg の出力がゼロにならない場合は、現在廃棄が行われていることを示しています。トラフィックのレートに基づいて、このデータを大幅に増加させるには、数分にわたって収集する必要があります。

回避策

次のステップを実行します。

1. 他のインターフェイスへのドロップの影響を最小限に抑えるため、ポートの範囲に対して常にオーバーサブスクライブされているポートを切り離します。

たとえば、インターフェイスをオーバーサブスクライブするポート 1 に接続されたサーバがある場合、 oversubscribing この場合、2 ～ 8の範囲のポートに他の複数のサーバが接続されていると、応答が遅くなることがあります。この場合は、 oversubscribing ポート1 ～ 8の最初のブロックのバッファを解放するために、サーバからポート9に設定します。新しいソフトウェアバージョンでは、SPAN宛先でバッファリングがインターフェイスに自動的に移動されるため、範囲内の他のポートには影響しません。詳細は、Cisco Bug ID CSCin70308 （登録されたCiscoクライアントだけにアクセス可能）を参照してください。

2. 共有バッファの代わりにインターフェイス バッファを使用する Head of Line blocking（HOL）をディセーブルにします。

この結果、使用率が高いポートからのドロップのみが発生します。インターフェイス バッファ（32 k）は 1 Mb の共有バッファよりも著しく小さいため、個々のポートではさらに多くのパケットが廃棄される可能性があります。これが推奨されるのは、比較的低速なクライアント場合や、SPAN ポートを専用のインターフェイス バッファを提供する他のラインカードに移動できない場合など、極端なケースに限られます。

- ネイティブCisco IOS

Router(config)# interface gigabitethernet <mod/port>

Router(config-if)# hol-blocking disable

これがディセーブルにされると、廃棄はインターフェイス カウンタに移動し、show interface gigabit <mod/port> コマンドで確認できます。他のポートも個別に動作しない限り、これらのポートは影響を受けません  bursting .HOL ブロッキングはイネーブル状態に維持することが推奨されるため、この情報を利用すれば、そのポートの範囲内でバッファ オーバーランが発生しているデバイスを見つけて、他のカードかカード上の隔離領域に移すことによって HOL ブロッキングを再度イネーブルにできます。

3. SPAN セッションを設定するときは、その特定インターフェイスでのエラーが宛先ポートで報告されていないことを確認してください。宛先ポートで発生する可能性のあるエラーをチェックするには、Cisco IOSのshow interface <interface type> <interface number>コマンドの出力をチェックして、出力ドロップまたはエラーがあるかどうかを確認します。宛先ポートでのエラーを避けるために、宛先ポートに接続されたデバイスとポート自体は、速度とデュプレックスの設定を同じにする必要があります。

4. オーバーサブスクライブ状態のポートがないイーサネット モジュールへの移動を検討してください。サポート対象モジュールの詳細は、『Cisco Catalyst 6500 シリーズ スイッチ - 対応インターフェイスとモジュール』を参照してください。

ワークステーションが起動時にネットワークにログインできない/DHCPアドレスを取得できない

スイッチで実行されているプロトコルによっては、初期接続遅延が引き起こされる場合があります。クライアント マシンの電源投入時やリブート時に次のいずれかの症状が見られる場合は、この問題が起きている可能性があります。

- Microsoft networking [No Domain Controllers Available] が表示されます。

- DHCP で「No DHCP Servers Available」と報告される。

- Novell Internetwork Packet Exchange（IPX）ネットワーキング ワークステーションで、起動時に Novell Login 画面が表示されない。

- AppleTalk networking クライアントに「Access to your AppleTalk network has been interrupted.To re-establish your connection, open and close the AppleTalk control panel」と表示される。AppleTalk クライアントのセレクタ アプリケーションにゾーン リストが表示されないか、不完全なゾーン リストが表示される場合もある。

- IBM ネットワーク ステーションに次のいずれかのメッセージが表示される。

- NSB83619--Address resolution failed

- NSB83589--Failed to boot after 1 attempt

- NSB70519--Failed to connect to a server

一般的な原因および解決策

インターフェイスの遅延により、「ワークステーションが起動時にネットワークにログインできない/DHCPアドレスを取得できない」セクションに示す症状が発生する場合があります。インターフェイスの遅延が発生する一般的な原因は次のとおりです。

- スパニングツリー プロトコル（STP）遅延

- EtherChannel 遅延

- トランキング遅延

- オートネゴシエーション遅延

遅延と可能なソリューションについての詳細は、『PortFast と他のコマンドを使用したワークステーションの接続始動遅延の修復』を参照してください。

この手順を調べて実施しても問題が解決しない場合は、シスコのテクニカルサポートにお問い合せください。

NIC の互換性に関する問題のトラブルシューティング

次のいずれかの問題が見られる場合は、スイッチでネットワーク インターフェイス カード（NIC）の互換性の問題や誤設定の問題がある可能性があります。

- スイッチへのサーバ/クライアント接続が確立されない。

- 自動ネゴシエーションの問題が発生している。

- ポートでエラーが発生している。

一般的な原因および解決策

これらの問題には、次の原因が考えられます。

- NIC ドライバの既知の問題

- 速度とデュプレックスのミスマッチ

- オートネゴシエーションの問題

- ケーブルに関する問題

さらにトラブルシューティングを進めるには、『Cisco Catalyst スイッチと NIC との互換性に関する問題のトラブルシューティング』を参照してください。

インターフェイスが errdisable ステータスを示す

show interface status コマンドの出力でインターフェイスのステータスが errdisable である場合、そのインターフェイスはエラー状態によりディセーブルになっています。errdisable ステータスにあるインターフェイスの例を次に示します。

cat6knative#show interfaces gigabitethernet 4/1 status

Port    Name               Status       Vlan       Duplex  Speed Type

Gi4/1                      err-disabled 100          full   1000 1000BaseSX

または、エラー状態でインターフェイスがディセーブルになっている場合は、次のようなメッセージが表示される場合があります。

%SPANTREE-SP-2-BLOCK_BPDUGUARD:

Received BPDU on port GigabitEthernet4/1 with BPDU Guard enabled. Disabling port.

%PM-SP-4-ERR_DISABLE:

bpduguard error detected on Gi4/1, putting Gi4/1 in err-disable state

このメッセージ例は、Bridge Protocol Data Unit（BPDU; ブリッジ プロトコル データ ユニット）がホスト ポートで受信されたときに表示されます。実際のメッセージは、エラー状態となる理由によって異なります。

インターフェイスが errdisable 状態になる理由はさまざまです。次のような理由が考えられます。

- 二重モードの不一致

- ポート チャネルの設定ミス

- BPDU Guard 違反

- UDLD 条件

- レイト コリジョンの検出

- リンクフラップの検出

- セキュリティ違反

- ポート集約プロトコル（PAgP）フラップ

- レイヤ 2 トンネリング プロトコル（L2TP）ガード

- DHCP スヌーピングのレート制限

errdisabled 状態のポートをイネーブルにするには、次の手順を実行します。

1. 接続の一端のケーブルを取り外します。

2. インターフェイスを再設定します。

たとえば、Etherchannel の誤設定によりインターフェイスが errdisabled ステートになっている場合は、その Etherchannel のインターフェイス範囲を再設定します。

3. 両端でポートをシャットダウンします。

4. 両方のスイッチにケーブルを接続します。

5. インターフェイスで no shutdown コマンドを発行します。

さらに、errdisable recovery cause cause enable コマンドを発行して、設定されたタイマーの時間が経過した後に、自動的に再度イネーブルにする、タイムアウト メカニズムを設定することもできます。

注：この問題の根本原因を解決しないと、エラー状態が再発します。

errdisable ステータスの理由を判別するには、show errdisable recovery コマンドを発行します。

cat6knative#show errdisable recovery

ErrDisable Reason    Timer Status

-----------------    --------------

udld                 Enabled

bpduguard            Enabled

security-violatio    Enabled

channel-misconfig    Enabled

pagp-flap            Enabled

dtp-flap             Enabled

link-flap            Enabled

l2ptguard            Enabled

psecure-violation    Enabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Interface    Errdisable reason    Time left(sec)

---------    -----------------    --------------

Gi4/1           bpduguard             270

errdisable の原因が判明したら、問題をトラブルシューティングして問題の根源を修復します。たとえば、例で示されているように、PortFast 対応のアクセス ポートで BPDU を受信したために、ポートが errdisable 状態になる場合があります。スイッチが偶然そのポートに接続されたのかどうか、またはハブが接続されたことでループ状態が発生したのかどうかを、トラブルシューティングできます。他のシナリオのトラブルシューティングを行うには、製品ドキュメントの特定の機能情報を参照してください。errdisableステータスの包括的な情報については、『Cisco IOSプラットフォームでのerrdisableポート状態の回復』を参照してください。この情報に基づいて確認とトラブルシューティングを行った後も問題が解決しない場合は、シスコテクニカルサポートに問い合わせてください。

インターフェイス エラーのトラブルシューティング

show interface コマンドの出力にエラーがある場合は、問題が発生しているインターフェイスの状態をチェックしてください。また、そのインターフェイスをトラフィックが通過しているかどうかをチェックしてください。『Cisco IOSシステムソフトウェアが稼働しているCatalyst 6500/6000でのWS-X6348モジュールのポート接続のトラブルシューティング』の「ステップ12」を参照してください。

cat6knative#show interfaces gigabitethernet 1/1

GigabitEthernet1/1 is up, line protocol is up (connected)

Hardware is C6k 1000Mb 802.3, address is 0001.6416.042a (bia 0001.6416.042a)

Description: L2 FX Trunk to tpa_data_6513_01

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Full-duplex mode, link type is autonegotiation, media type is SX

output flow-control is unsupported, input flow-control is unsupported, 1000Mb/s

Clock mode is auto

input flow-control is off, output flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:01, output 00:00:28, output hang never

Last clearing of "show interface" counters never

Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 118000 bits/sec, 289 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

461986872 packets input, 33320301551 bytes, 0 no buffer

Received 461467631 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 137 overrun, 0 ignored

0 input packets with dribble condition detected

64429726 packets output, 4706228422 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

cat6knative#

また、show interfaces <interface-id> counters errorsコマンドの出力にエラーが表示される場合もあります。その場合は、そのインターフェイスに関連するエラーをチェックしてください。『Cisco IOSシステムソフトウェアが稼働しているCatalyst 6500/6000でのWS-X6348モジュールのポート接続のトラブルシューティング』の「ステップ14」を参照してください。

cat6knative#show interfaces gigabitethernet 3/1 counters errors

Port        Align-Err    FCS-Err   Xmit-Err    Rcv-Err UnderSize OutDiscards

Gi3/1               0          0          0          0         0           0

Port      Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen     Runts    Giants

Gi3/1              0         0         0          0         0         0         0

Port       SQETest-Err Deferred-Tx IntMacTx-Err IntMacRx-Err Symbol-Err

Gi3/1                0           0            0            0          0

一般的な原因および解決策

- インターフェイスでエラーが表示される原因は、下記のような物理レイヤの問題にある可能性があります。

- 障害のあるケーブルや NIC

- 速度やデュプレックスのミスマッチなどの設定の問題

- オーバーサブスクリプションなどのパフォーマンスの問題

これらの問題を理解してトラブルシューティングするには、『トラブルシューティング：スイッチ ポートおよびインターフェイスの問題』を参照してください。

- 場合によっては、ソフトウェアの不具合やハードウェアの制限によりエラー カウンタが不正確に増分されることがあります。次の表では、Cisco IOS ソフトウェアが稼動する Catalyst 6500/6000 プラットフォームでのカウンタの既知の問題が挙げられています。

注：内部サイトとバグ情報にアクセスできるのは、登録されているCiscoクライアントだけです。

症状

説明

修正

Supervisor Engine 720 ベースのスイッチの IEEE 802.1Q トランク インターフェイスでのジャイアント

Catalyst 6500シリーズスイッチでは、1496バイトを超え、スーパーバイザエンジン720ポートを経由するトランクでタグ付きで受信されるパケットサイズについて、ジャイアントを報告できます。これは、67xx ラインカードでも、問題として現れる場合もあります。この問題は見かけ上のもので、スイッチではそれらのパケットは転送されます。この問題は ISL1 トランクでも発生します。詳細については、Cisco Bug ID CSCec62587およびCisco Bug ID CSCed42859を参照してください。

Cisco IOSソフトウェアリリース12.2(17b)SXA以降Cisco IOSソフトウェアリリース12.2(18)SXD以降

スーパーバイザ エンジン 2 ベースのスイッチでの 802.1Q トランク インターフェイス上のジャイアント

スイッチは、802.1Qトランクポート上の非ネイティブVLAN上の1497 ～ 1500の範囲にあるパケットをジャイアントとしてカウントします。これは見かけ上の問題で、それらのパケットはスイッチにより転送されます。詳細については、Cisco Bug ID CSCdw04642を参照してください。

現在のところ、

トラフィックが少ない状態でも、ギガビットインターフェイスでのshow interfaceコマンドの出力に過剰な出力廃棄カウンタが表示されます。

トラフィックが少ない状態にあるギガビットインターフェイスでは、show interfaceコマンドの出力に過剰な出力廃棄カウンタが表示されます。Cisco Bug ID CSCdv86024

を参照してください。

Cisco IOSソフトウェアリリース12.1(8b)E12以降Cisco IOSソフトウェアリリース12.1(11b)E8以降Cisco IOSソフトウェアリリース12.1(12c)E1以降Cisco IOSソフトウェアリリース12.1(13)E1以降

ポート チャネル インターフェイスで、show interface コマンドの出力に、bps1 と pps2 に関する不正確な統計情報が示される。

Cisco IOS ソフトウェアを使用していて、2 つのファスト イーサネット ポートにポート チャネルが定義されているときに、そのポート チャネルを経由するトラフィックが生成されると、物理インターフェイスには正確なレート統計情報が示されます。ところが、ポート チャネル インターフェイスには不正確な統計情報が示されます。詳細については、Cisco Bug ID CSCdw23826を参照してください。

Cisco IOSソフトウェアリリース12.1(8a)EX Cisco IOSソフトウェアリリース12.1(11b)E1 Cisco IOSソフトウェアリリース12.1(13)E1

1 ISL = Inter-Switch Link（スイッチ間リンク）。

2 bps = bits per second（ビット/秒）。

3 packets per second（パケット/秒）。

このセクションで紹介されているドキュメントに基づいて検討とトラブルシューティングを行っても問題が解決しない場合は、シスコのテクニカルサポートにサポートを要請してください。

「%PM_SCP-SP-3-GBIC_BAD: GBIC integrity check on port x failed: bad key」エラーメッセージを受信する

Cisco IOS ソフトウェア リリース 12.1(13)E よりも前のソフトウェア リリースで稼動している GBIC では、アップグレードを行うと障害が発生します。

Cisco IOS ソフトウェア リリース 12.1(13) システム ソフトウェアでは、不正な GBIC EEPROM のチェックサムを持つ GBIC のポートは up 状態になれません。1000BASE-TX（銅ケーブル接続）と Coarse Wave Division Multiplexer（CWDM）GBIC では、これは想定される動作です。ただし、これは他の GBIC に関しては、正しい動作ではありません。初期のリリースでは、他の GBIC を備えたポートでチェックサム エラーが発生しても、up 状態になることができました。

このエラーが Cisco IOS ソフトウェア リリース 12.1(13)E で発生すると、次のエラー メッセージが表示されます。

%PM_SCP-SP-3-GBIC_BAD: GBIC integrity check on port 1/2 failed: bad key

show interface コマンドを発行すると、次の出力が表示されます。

Router#show interface status

Port    Name               Status       Vlan       Duplex  Speed Type

Gi2/1                      faulty       routed       full   1000 bad EEPROM

この問題は、Cisco IOSソフトウェアリリース12.1(13)E1、12.1(14)E以降のリリースで修正できます。

この問題についての詳細は、『Field Notice：Catalyst 6000のCisco IOS®ソフトウェアリリース12.1(13)Eで不正なGBIC EEPROMエラー。

WS-X6x48 モジュール インターフェイスで COIL エラー メッセージが表示される

syslogまたはshow logコマンドの出力に、次のエラーメッセージが1つ以上表示されます。

- Coil Pinnacle Header Checksum

- Coil Mdtif State Machine Error

- Coil Mdtif Packet CRC Error

- Coil Pb Rx Underflow Error

- Coil Pb Rx Parity Error

WS-X6348 モジュール、またはその他の 10/100 モジュールでホストとの接続に関して接続性の問題があるか、またはこのセクションでリストされているものに類するエラー メッセージが表示されていて、スタック状態でトラフィックが通過できない 12 ポートのグループがある場合には、次の手順を実行します。

1. インターフェイスをいったんディセーブルにしてからイネーブルにします。

2. コマンドを発行して、モジュールをソフトリセットします。

3. モジュールをハード リセットするには、以下の操作のいずれかを実行します。

- カードを物理的に取り付け直します。

- no power enable module module_# グローバル コンフィギュレーション コマンドと power enable module module_# グローバル コンフィギュレーション コマンドを発行します。

この手順を実行した後で、次のいずれかの問題が発生した場合は、情報を添えてシスコのテクニカルサポートにお問い合せください。

- モジュールがオンラインにならない。

- モジュールはオンラインになるが、12個のインターフェイスのグループで診断に失敗する。

これは、show diagnostic module <module_number>コマンドの出力で確認できます。

- モジュールが起動しても、other の状態に留まっている。

- モジュールのすべてのポート LED がオレンジになる。

- すべてのインターフェイスが errdisabled ステートになっている。

これは、show interfaces status module module_# コマンドを発行すると表示されます。

詳細は、『Cisco IOSシステムソフトウェアが稼働するCatalyst 6500/6000でのWS-X6348モジュールのポート接続のトラブルシューティング』を参照してください。

WS-X6x48 モジュールの接続性問題のトラブルシューティング

WS-X6348モジュールまたは他の10/100モジュール上のホストの接続に接続の問題がある場合は、「Cisco IOSシステムソフトウェアが稼働するCatalyst 6500/6000でのWS-X6348モジュールのポート接続のトラブルシューティング」を参照してください。ドキュメント「Catalyst 6でのWS-X6348モジュール8の接続に問題があるがある場合Cisco IOSシステムソフトウェアが稼働している500/6000の場合は、シスコテクニカルサポートに連絡して、さらにサポートを求めてください。

STP 問題のトラブルシューティング

スパニングツリー関連の問題によって、交換回線ネットワークで接続上の問題が発生することがあります。スパニングツリーの問題を回避する方法のガイドラインについては、『Cisco IOSシステムソフトウェアが稼働するCatalystスイッチでのSTPに関するトラブルシューティング』を参照してください。

telnet コマンドを使用してスイッチに接続できない

原因

Cisco IOS デバイスと同様に、Catalyst 6500 スイッチにおいても、許可される telnet セッションの数は制限されています。この制限に達すると、スイッチではそれ以上の vty セッションは許可されません。この問題が発生しているかどうかを確認するには、スーパーバイザ エンジンのコンソールに接続します。show bootvar コマンドを発行します。このコマンドのコマンドライン インターフェイス（CLI）出力には、次のように、現在占有されている回線の数が示されます。

Cat6500#show user

Line     User    Host(s)      Idle     Location

0 con 0         10.48.72.118 00:00:00

1 vty 0         10.48.72.118 00:00:00 10.48.72.118

2 vty 1         10.48.72.118 00:00:00 10.48.72.118

3 vty 2         10.48.72.118 00:00:00 10.48.72.118

4 vty 3         10.48.72.118 00:00:00 10.48.72.118

*5 vty 4         idle         00:00:00 10.48.72.118

解決方法

次のステップを実行します。

1. show user コマンドの出力に基づいて廃棄されたセッションをクリアするために、clear line line_number コマンドを発行します。

Cat6500#show user

Line     User    Host(s)      Idle     Location

0 con 0         10.48.72.118 00:00:00

1 vty 0         10.48.72.118 00:00:00 10.48.72.118

2 vty 1         10.48.72.118 00:00:00 10.48.72.118

3 vty 2         10.48.72.118 00:00:00 10.48.72.118

4 vty 3         10.48.72.118 00:00:00 10.48.72.118

*5 vty 4        idle         00:00:00 10.48.72.118

Cat6500#clear line 1

Cat6500#clear line 2

!--- Output suppressed.

2. アクティブではないセッションをクリアするために、vty セッションとコンソール回線にアイドル タイムアウトを設定します。次の例には、アイドル タイムアウトを 10 分にセットするための設定が示されています。

Cat6500#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

Cat6500(config)#line vty 0 4

Cat6500(config-line)#exec-timeout ?

<0-35791>  Timeout in minutes

Cat6500(config-line)#exec-timeout 10 ?

<0-2147483>  Timeout in seconds

<cr>

Cat6500(config-line)#exec-timeout 10 0

Cat6500(config-line)#exit

Cat6500(config)#line con 0

Cat6500(config-line)#exec-timeout 10 0

Cat6500(config-line)#exit

Cat6500(config)#

3. 利用可能な vty セッションの数を増やすこともできます。line vty 0 4の代わりにline vty 0 6コマンドを使用します。

場合によっては、show user コマンドの出力に、アクティブな vty セッションが 1 つも示されないのに、telnet コマンドを使用してスイッチに接続しようとすると、次のエラー メッセージで失敗することがあります。

% telnet connections not permitted from this terminal

この場合、vty を正しく設定してあることを確認してください。すべてを転送することを vty に許可するには、transport input all コマンドを発行します。

RADIUS認証でスタンバイユニットをコンソールに表示できない

問題

6500 のスイッチが VSS クラスタで作動不能になる。スタンバイスイッチにコンソール接続しようとすると、次のRADIUSログメッセージが表示されて失敗します。

%RADIUS-4-RADIUS_DEAD:RADIUS server 10.50.245.20:1812,1813 is not responding.

このスタンバイスーパーバイザへのTelnetによる認証は正常に機能し、アクティブスーパーバイザのコンソールログインも正常に機能します。この問題は、スタンバイスーパーバイザのコンソールへの接続で発生します。

ソリューション：

スタンバイユニットのコンソールに対するRADIUS認証はできません。スタンバイには、AAA 認証に対応する IP 接続がありません。ローカルデータベースなどのフォールバックオプションを使用する必要があります。

VSL インターフェイスでのジャイアント パケット カウンタ

システムでジャイアント データ パケットが送信されていないにもかかわらず、VSL インターフェイスでジャイアント パケットのカウンタが増加することがあります。

VSLインターフェイスを通過するパケットは、通常のMACヘッダーを超えて32バイトのVSLヘッダーを伝送します。このヘッダーは理論上はパケット サイズの分類付けからは除外されていますが、実際には、ポートの ASIC ではこのヘッダーを分類付けしています。その結果、正規サイズのパケットの 1518 のサイズ制限に近いサイズの制御パケットが、ジャイアント パケットとして分類される結果となる可能性があります。

現在のところ、この問題の回避策はありません。

複数の VLAN がスイッチに表示される

以前に、存在しなかった複数の VLAN がスイッチに表示される場合があります。以下に、いくつかの例を示します。

Vlan982         unassigned      YES unset  administratively down down

Vlan983         unassigned      YES unset  administratively down down

Vlan984         unassigned      YES unset  administratively down down

Vlan985         unassigned      YES unset  administratively down down

Vlan986         unassigned      YES unset  administratively down down

Vlan987         unassigned      YES unset  administratively down down

Vlan988         unassigned      YES unset  administratively down down

Vlan989         unassigned      YES unset  administratively down down

Vlan990         unassigned      YES unset  administratively down down

Vlan991         unassigned      YES unset  administratively down down

Vlan992         unassigned      YES unset  administratively down down

Vlan993         unassigned      YES unset  administratively down down

Vlan994         unassigned      YES unset  administratively down down

Vlan995         unassigned      YES unset  administratively down down

Vlan996         unassigned      YES unset  administratively down down

Vlan997         unassigned      YES unset  administratively down down

Vlan998         unassigned      YES unset  administratively down down

Vlan999         unassigned      YES unset  administratively down down

Vlan1000        unassigned      YES unset  administratively down down

Vlan1001        unassigned      YES unset  administratively down down

Vlan1002        unassigned      YES unset  administratively down down

Vlan1003        unassigned      YES unset  administratively down down

Vlan1004        unassigned      YES unset  administratively down down

Vlan1005        unassigned      YES unset  administratively down down

解決策として、vlan filter Traffic-Capture vlan-list 1 - 700コマンドが設定に追加されます。まだ設定されていないVLANは、レイヤ3 VLANとして追加できます。

電源とファンの問題

電源の NPUT OK LED が点灯しない場合

電源スイッチをオンにしても、電源モジュールの INPUT OK LED が点灯しない場合は、show power status all コマンドを発行してください。次の例のように、電源モジュールのステータスを調べます。

cat6knative#show power status all

Power-Capacity PS-Fan Output Oper

PS   Type               Watts   A @42V Status Status State

---- ------------------ ------- ------ ------ ------ -----

1    WS-CAC-2500W       2331.00 55.50  OK     OK     on

2    none

Pwr-Requested  Pwr-Allocated  Admin Oper

Slot Card-Type          Watts   A @42V Watts   A @42V State State

---- ------------------ ------- ------ ------- ------ ----- -----

1    WS-X6K-S2U-MSFC2    142.38  3.39   142.38  3.39  on    on

2    WSSUP1A-2GE         142.38  3.39   142.38  3.39  on    on

3    WS-X6516-GBIC       231.00  5.50   231.00  5.50  on    on

4    WS-X6516-GBIC       231.00  5.50   231.00  5.50  on    on

5    WS-X6500-SFM2       129.78  3.09   129.78  3.09  on    on

6    WS-X6502-10GE       226.80  5.40   226.80  5.40  on    on

cat6knative#

ステータスがこの例のように OK ではない場合、トラブルシューティングを進めるには、ドキュメント『トラブルシューティング』（Catalyst 6500 シリーズ スイッチ）の「電源モジュールのトラブルシューティング」セクションに示されている手順に従ってください。

エラー メッセージ「C6KPWR-4-POWRDENIED:insufficient power, module in slot [dec] power denied or %C6KPWR-SP-4-POWRDENIED:insufficient power, module in slot [dec] power denied」のトラブルシューティング

ログにこのメッセージが記録されていた場合、モジュールの電源をオンにするのに十分な電力がないことを示しています。メッセージ中の [dec] はスロット番号を示しています。

%OIR-SP-6-REMCARD: Card removed from slot 9, interfaces disabled

C6KPWR-4-POWERDENIED: insufficient power, module in slot 9 power denied

C6KPWR-SP-4-POWERDENIED: insufficient power, module in slot 9 power denied

電源モジュールの冗長性のモードを確認するには、show power コマンドを発行します。

cat6knative#show power

system power redundancy mode = redundant

system power total = 27.460A

system power used = 25.430A

system power available = 2.030A

FRU-type       #    current   admin state oper

power-supply   1    27.460A   on          on

power-supply   2    27.460A   on          on

module         1    3.390A    on          on

module         2    3.390A    on          on

module         3    5.500A    on          on

module         5    3.090A    on          on

module         7    5.030A    on          on

module         8    5.030A    on          on

module         9    5.030A    on          off (FRU-power denied).

この出力は、電源モジュールのモードが冗長であり、1つの電源モジュールではシャーシ全体に電力を供給するのに十分ではないことを示しています。次のいずれかの手順を実行できます。

- ワット数が高い電源モジュールを入手する。

たとえば、現在の電源モジュールが 1300W AC の場合は、2500W AC か 4000W AC の電源モジュールを入手します。

- 電源モジュールの冗長性モードを combined にする。

以下が一例です。

cat6knative(config)#power redundancy-mode combined

cat6knative(config)#

%C6KPWR-SP-4-PSCOMBINEDMODE: power supplies set to combined mode.

combined モードでは、両方の電源モジュールから電力が供給されます。ただし、このモードでは、一方の電源モジュールで障害が発生すると、残った電源モジュールだけではシャーシ全体への電力供給ができないため、再びモジュールへの電力供給が失われることになります。

そのため、ワット数のより高い電源モジュールを使用することが、よりよい選択肢となります。

空きスロットに予約済みの電力は再割り当てできません。たとえば、スロット 6 が空で、スロット 2 では 68 ワットしか使用できない場合に、スロット 2 で使用できるワット量を増やすために、スロット 6 に予約済みの 282 ワットを、スロット 2 に再割り当てはできません。

各スロットで使用できる電力には制限があり、使用されていない場合であっても、他のスロットに再割り当てすることはできません。空きスロットに予約済みの電力を無効にするコマンドはありません。

注：電源装置の最大電力容量を使用するには、スイッチを110 VACではなく220 VACに接続してください（電源装置が220 VACをサポートしている場合）。電源管理についての詳細は、『Catalyst 6000 シリーズ スイッチの電源管理』を参照してください。

FAN LED が赤く点灯する、または show environment status コマンドの出力に障害が表示される

show environment status コマンドを発行してファン アセンブリの障害が表示される場合は、ドキュメント『トラブルシューティング』（Catalyst 6500 シリーズ スイッチ）の「ファン アセンブリのトラブルシューティング」セクションに示されている手順に従って、問題を特定してください。

以下が一例です。

cat6knative#show environment status

backplane:

operating clock count: 2

operating VTT count: 3

fan-tray 1:

fan-tray 1 fan-fail: failed

!--- Output suppressed.

関連情報

- Cisco IOS システム ソフトウェアが稼働している Catalyst 6500/6000 でのブート ローダ イメージの破損や欠落あるいは ROMmon モードからの回復

- スイッチ製品に関するサポート ページ

- LAN スイッチング テクノロジーに関するサポート ページ

- Cisco Catalyst 6000 シリーズ スイッチのサポート ページ

- テクニカル サポートとドキュメント – Cisco Systems