スイッチ : Cisco Catalyst 6500 シリーズ スイッチ

Cisco IOS システム ソフトウェアが稼働している Catalyst 6500/6000 シリーズ スイッチのハードウェアと一般的な問題のトラブルシューティング

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2010 年 8 月 30 日) | 英語版 (2015 年 9 月 19 日) | フィードバック


目次


概要

この資料は Catalyst 6500/6000 スイッチのハードウェアおよび Cisco IOS を実行する関連よくある 問題を解決することを記述しますか。 システム ソフトウェア。 Cisco IOS ソフトウェアでは、スーパーバイザ エンジンとマルチレイヤ スイッチ フィーチャ カード(MSFC)モジュールは、どちらもバンドルされた単一の Cisco IOS イメージに依存しています。 このドキュメントでは、問題と見られる症状が発生しており、それに関する追加情報を必要としているか、または解決する必要があるということを想定しています。 このドキュメントに該当する製品は、Supervisor Engine 1、2、720 ベースの Catalyst 6500/6000 スイッチです。

ソフトウェア イメージの命名規則については、『Catalyst 6500/6000 スイッチでの CatOS から Cisco IOS へのシステム ソフトウェアの変更』マニュアルの「CatOS と Cisco IOS ソフトウェア イメージの命名規則」セクションを参照してください。

スーパーバイザ エンジンで Catalyst OS(CatOS)が稼働していて、MSFC で Cisco IOS ソフトウェアが稼働しているシステムのトラブルシューティングには、次のドキュメントを参照してください。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

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

表記法

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

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

システム メッセージは、コンソール ログがイネーブルになっている場合はコンソールに、syslog がイネーブルになっている場合は syslog に表示されます。 これらのメッセージの中には、情報提供だけを目的としており、エラー状態を示さないものがあります。 システムのエラー メッセージの概要については、『システム メッセージの概要』を参照してください。

適切なレベルのログをイネーブルにして、syslog サーバにメッセージを記録するようにスイッチを設定します。 設定情報の詳細については、「Step-by-Step Instructions to Configure IOS Devices」セクション(『Resource Manager Essentials and Syslog Analysis:  How-To』マニュアル内にある)を参照してください。

ログに記録されたメッセージをモニタするには、show logging コマンドを発行します。 または、必要に応じて CiscoWorks や HP OpenView などのモニタリング ステーションを使用します。

特定のシステム メッセージを詳しく調べるには、「メッセージと回復手順」(Catalyst 6500/6000 Cisco IOS システム ソフトウェア)を参照してください。

それでも問題を判別できないか、表示されているエラー メッセージがこのドキュメントに見つからない場合は、シスコ テクニカル サポートのエスカレーション センターにご連絡ください。

エラー メッセージ %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: ポートで、単方向リンク検出(UDLD)がディセーブル、シャットダウン、または未定状態になっている場合。

  • 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:アクセス ストリング(rwrorw-all)がデフォルトに設定されている場合。

  • Ports:ポートが半二重にネゴシエートされているか、またはポートでデュプレックス/VLAN のミスマッチがある場合。

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

    • denied

    • faulty

    • other

    • オフ

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

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

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

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

次に出力例を示します。

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

IOSSwitch>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 レベルほど長い時間ではありませんが、カードの潜在的なハードウェア問題の検出は同じように行われます。 診断テスト レベルを bypass に設定すると、診断テストは実行されません。 diagnostic bootup level {complete  | minimal  | bypass} グローバル コンフィギュレーション コマンドを発行して、診断レベルを切り替えます。 デフォルトの診断レベルは minimal です。これは CatOS でも Cisco IOS システム ソフトウェアでも同じです。

    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_# コマンドを発行します。 モジュールで 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_# 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 モードになる、またはシステム イメージが失われる場合

スイッチのスーパーバイザ エンジンで起動中に連続ループが発生している場合や、ROM モニタ(ROMmon)モードになっている場合、またはシステム イメージが失われている場合には、ほとんどの場合、ハードウェアの問題ではありません。

システム イメージが破損しているか、または失われている場合には、スーパーバイザ エンジンは ROMmon モードになるか、起動に失敗します。 スーパーバイザ エンジンを回復させる方法に関する手順については、『Cisco IOS システム ソフトウェアが稼働している Catalyst 6500 または 6000 でのブートローダ イメージの破損や欠落あるいは 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 ソフトウェア リリースが稼働していない場合は、スタンバイ側のスーパーバイザ エンジンがオンラインにならないことがあります。 たとえば、次のような状況では、スーパーバイザ エンジンがオンラインにならない場合があります。

    • アクティブ状態のスーパーバイザ エンジンが、Route Processor Redundancy Plus(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 シリーズ スイッチ モジュールのインストール ノート』を参照してください。

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

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

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

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

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

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

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

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

    %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 コマンドを入力して設定または実行中の設定を表示した場合、 コンフィギュレーション ファイルはロックされます。 この問題は、 Bug ID CSCeg21028 登録ユーザ専用) を探します。 同期の障害は、次のエラー メッセージによって特定できます。

    %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: コマンドを発行して、ソフトウェア クラッシュをチェックします。

    このセクションの出力は、crashinfo が RP ブートフラッシュに記録されていることを示します。 表示される crashinfo が 最新のクラッシュであることを確認します。 more bootflash: filename コマンドを発行して、 crashinfo ファイルを表示します。 この例では、コマンドは 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: コマンドは、 スーパーバイザ エンジンのブートフラッシュ デバイスを表示することもできます。 dir slavesup-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.
    
    

    スイッチがリブートしたと思われるときに、コマンド出力が ソフトウェア クラッシュの発生を示す場合は、 シスコ テクニカル サポートに連絡してください。 その際には、 show tech-support コマンドおよび show 記録 コマンド、ならびに crashinfo ファイルの 出力を提供してください。 ファイルを送信するには、TFTP を通じて、スイッチから TFTP サーバ に転送し、そのケースにファイルを添付します。

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

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

Distributed Forwarding Card(DFC)を装備したモジュールが ユーザのリロードなしに、勝手にリセットする場合、DFC カードのブートフラッシュをチェックして、クラッシュしているかどうかを 確認できます。 crashinfo ファイルが使用可能な場合、クラッシュの原因を 確認できます。 dir dfc#module_#-bootflash: コマンドを発行して、 crashinfo ファイルがあるかどうか、およびそれがいつ書き込まれたかを確認します。 If the 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 やその他のステータスが表示されるモジュールのトラブルシューティング

このセクションでは、任意のモジュールをオンラインにできない一般的な原因と この問題を解決する方法について説明します。 以下のいずれかの方法で、モジュールが オンラインにならないかどうかを判別できます。

  • show module コマンドが、以下のいずれかのステータスを表示する。

    • other

    • unknown

    • faulty

    • errdisable

    • power-deny

    • power-bad

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

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

  • サポート対象ハードウェア」セクション (該当リリースの『Catalyst 6500 シリーズのリリース ノート』) を確認します。 モジュールが、現在実行しているソフトウェアでサポートされていない場合、 必要なソフトウェアを Cisco IOS ソフトウェア センター 登録ユーザ専用) を探します。

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

  • ステータスが power-bad の場合、スイッチは カードを確認できますが、電源を割り当てることはできません。 これは、 スーパーバイザ エンジンが、ラインカードの ID を特定するために シリアル PROM(SPROM)のコンテンツにアクセスできない場合に実行できます。 show idprom module slot コマンドを発行して、SPROM が読み取り可能かどうかを確認します。 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)は インストールされていませんでした。 そのため、完全性テストは実施されていません。 GBIC 完全性テストは、銅線 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 記録 コマンドを発行します。 このモジュールに関連するメッセージを探して、 さらにトラブルシューティングを行います。

    それでも、モジュールがオンラインにならない場合は、 さらにトラブルシューティングを行うために、 シスコ テクニカル サポートでサービス リクエストを作成します。 収集したスイッチの出力のログと実行したトラブルシューティングの 手順を提供してください。

インバンド通信障害

スーパーバイザ エンジンは、インバンド通信障害を示すメッセージを スローする場合があります。 スイッチのログに記録されメッセージは、 次のように表示されます。

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 コマンドを使用して、 この問題を引き起こすプロセスを特定します。 PortFast を有効にする方法の詳細については、 「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)

中断できる SP コンフィギュレーション レジスタ(0x2)を搭載し、 コンソール ブレーク信号を受信する Catalyst 6500/6000 が、 ROMmon 診断モードになります。 システムはクラッシュしたように見えます。 SP および RP のコンフィギュレーション レジスタ設定 の不一致が、このタイプのリロードを発生させる場合があります。 具体的には、 スーパーバイザ エンジン スイッチ プロセッサ(SP)のコンフィギュレーション レジスタを 中断を無視しない値に設定する一方で、マルチレイヤ スイッチ フィーチャ カード(MSFC)ルート プロセッサ(RP)のコンフィギュレーション レジスタを 中断を無視する適切な値に設定できます。 たとえば、 スーパーバイザ エンジン SP を 0x2、MSFC RP を 0x2102 に設定します。

詳細については、 「IOS Catalyst 6500/6000 は、「電源オンによりシステムが ROM モードに戻る(SP by abort)エラーによってリセットされる」を参照してください。

Cisco IOS ソフトウェアを実行する Cisco Catalyst 6500/6000 は、 実行コンフィギュレーションの BOOT 変数の設定にかかわらず、sup-bootdisk 内の 古いイメージをブートします。 BOOT 変数が外部フラッシュからブートするように 設定されている場合でも、スイッチは sup-bootdisk 内の古いイメージをブートします。 これらのモジュールでの 原因は、SP および RP のコンフィギュレーション レジスタ設定の 不一致です。

RP で、 show bootvar を探します。

Switch#sh 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#sh 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 に同じ config-register 値が設定されていることを確認します。 これをスタートアップ コンフィギュレーションに保存してから、 スイッチをリロードします。

エラー: 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: No more SWIDB can be allocated, maximum allowed 12000

PortFast を有効にする方法の詳細については、 「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

この例は、合計 IDB 数(SWIDB 列の下)が IDB 制限の最大数に到達したことを示します。 サブインターフェイスを削除すると、SWIDB 列のアクティブおよび 非アクティブ数が変わります。 ただし、 合計 IDB 数はメモリに残ります。

この問題を解決するには、スイッチをリロードして IDB データベース database. 削除しない場合、使用し尽くしたときに、削除したサブインターフェイスを 再利用する必要があります。

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 がない場合に発生します。

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

CatOS から Cisco IOS ソフトウェアへの変換、または Cisco IOS ソフトウェアから CatOS への変換のトラブルシューティング

CatOS から Cisco IOS システム ソフトウェアまたは Cisco IOS ソフトウェアから CatOS への変換に問題がある場合は、以下のドキュメントを 参照してください。

Cisco IOS から CatOS への変換後に NVRAM にアクセスする際の問題

Cisco IOS から CatOS への変換中に NVRAM が破損するか、または CONFIG_FILE 変数が MSFC ROMmon から設定される場合、 MSFC から NVRAM にアクセスしようとすると、 問題が発生する場合があります。 また、以下のようなエラー メッセージが 表示されます。

Router#write memory
     startup-config file open failed (Not enough space)
Router#dir nvram:
     Directory of nvram:/       
    
%Error calling getdents for nvram:/ (Unknown error 89)

MSFC が ROMmon で設定された CONFIG_FILE をロードする場合、 ユーザは NVRAM に設定を保存できません。 これらのモジュールでの show startup-config は、エラー コード 89 によって失敗します。 89. この問題は、MSFC3 上で Cisco IOS ソフトウェア リリース 12.2 (14)SX2 を実行する、 ハイブリッド モードのスーパーバイザ エンジン 720 を搭載した Catalyst 6500 で発生します。

CONFIG_FILE が設定されている場合、 以下の回避策があります。

  1. MSFC3 コードを、Cisco IOS ソフトウェア リリース 12.2(17a)SX 以降に アップグレードします。 MSFC 上のソフトウェア イメージをアップグレードする方法の詳細については、 『 「Catalyst スイッチ レイヤ 3 モジュールのソフトウェア イメージをアップグレードする方法』を参照してください。

  2. MSFC ROMmon から CONFIG_FILE 変数を 設定解除します。

    ROMmon モードに入るには、MSFC をリロードし、 起動してから 60 秒以内に Ctrl+Break キーを押します。 MSFC が ROMmon モードに入ったら、以下のコマンドを発行して、 CONFIG_FILE を設定解除します。

    • rommon 2 >priv
      
      !--- Press Enter or Return.
      !--- You have entered ROMmon privileged mode.
      !--- You see this output:
      
      You now have access to the full set of monitor commands.
      Warning: some commands will allow you to destroy your
      configuration and/or system images and could render
      the machine unbootable.
    • rommon 3 >unset CONFIG_FILE
      
      !--- Press Enter or Return.
      !--- This unsets the CONFIG_FILE variable.
      
      
    • rommon 4 >sync
      
      !--- Press Enter or Return.
      
      
    • rommon 5 >reset
      
      
      !--- Press Enter or Return.
      
      

Cisco IOS から CatOS への変換中に NVRAM が破損した場合、 問題を解決するには、NVRAM を消去します。 NVRAM を消去するには、 ROMmon モードに入り、以下のコマンドを発行します。

  • rommon 1 >priv
    
    
    !--- Press Enter or Return.
    !--- You have entered ROMmon privileged mode.
    !--- You see this output:
    
    You now have access to the full set of monitor commands.
    Warning: some commands will allow you to destroy your
    configuration and/or system images and could render
    the machine unbootable.
  • rommon 2 >nvram_erase
    
    
    !--- Press Enter or Return.
    !--- Be sure to enter these parameters exactly:
    !--- The first line is a "be" (no space) followed by six zeros ("000000").
    !--- The next line is an "2" (no space) followed by five zeros ("00000").
    
    Enter in hex the start address [0xbe020000]:  be000000
    
    
    !--- Press Enter or Return.
    
    Enter in hex the test size or length in bytes [0x100]:  200000
    
    
    !--- Press Enter or Return.
    !--- After the NVRAM erase has completed, issue the reset command.
    
    
    rommon 3 >reset
    
    !--- Press Enter or Return.
    
    

    スーパーバイザ エンジン 720 は、 ルート プロセッサ(MSFC)ROMmon に nvram_erase コマンドを備えていますが、 スイッチ プロセッサ(スーパーバイザ エンジン)ROMmon の有効な コマンドではありません。

CatOS から Cisco IOS に変換する際に Cisco IOS ソフトウェアでブートできない

変換処理中に disk0 または slot0 から Cisco IOS ソフトウェアを起動しようとすると、 以下のようなエラー メッセージが表示される場合があります。

*** TLB (Store) Exception ***
Access address = 0x10000403
PC = 0x8000fd60, Cause = 0xc, Status Reg = 0x30419003
 
monitor: command "boot" aborted due to exception

このエラー メッセージは、ハードウェアまたはソフトウェアに関連する可能性があり、 ROM モニタ(ROMmon)モードで起動ループまたはスイッチの作動不能が生じる可能性があります。

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

  1. この問題は、ソフトウェア イメージのチェックサムが正しくないために発生する場合があります。 TFTP サーバから Cisco IOS ソフトウェア イメージを再度ダウンロード してください。

  2. 再度ダウンロードしても問題が解決しない場合は、フラッシュ カードをフォーマットし、 Cisco IOS ソフトウェア イメージを再度ダウンロードします。

    PortFast を有効にする方法の詳細については、 『PCMCIA ファイル システムの互換性マトリクスとファイルシステム情報』 を参照してください。

  3. この問題はハードウェアの障害に起因する可能性もありますが、エラー メッセージには どのハードウェア コンポーネントが原因で問題が発生しているかは示されません。 別のフラッシュ カード から Cisco IOS ソフトウェアの起動を試みてください。

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

サーバ ファームで使用されている 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)エンジンです。 この範囲にあるのポートが 帯域幅を超えるレートでトラフィックを送受信する場合、 またはトラフィックのバーストを処理するために大量のバッファを使用する場合、 同じ範囲内の他のポートでパケット損失が発生する可能性があります。 これらのモジュールでの バッファの割り当ては、『 Catalyst 6500 のイーサネット モジュールのバッファ、キュー、およびしきい値』で報告されています。

VLAN 全体または複数のポートからインターフェイスにトラフィックをコピーすることはよくあることなので、 SPAN 宛先は非常に一般的な原因です。 個別のインターフェイス バッファを持つカードでは、宛先ポートの帯域幅を超えるパケットは サイレント ドロップされ、他のポートは影響を受けません。 これは、共有バッファによって、この範囲の他のポートに対して 接続問題を発生させます。 ただし、ほとんどのシナリオでは、共有バッファにより問題が発生することはありません。 8 ギガビット搭載ワークステーションであっても、提供された 帯域幅を超えることはほとんどありません。

特に大量のソース ポートをモニタする場合、 スイッチにローカル SPAN を設定する際に、スイッチでサービスの低下が発生する 検討してください。 この問題は、特定の VLAN をモニタする場合、 および大量のポートがこれらの VLAN のいずれかに割り当てられている場合にも発生します。

ハードウェアで SPAN が実行される場合でも、スイッチは 2 倍のトラフィックを伝送するため、 パフォーマンスへの影響があります。 各ライン・カードは、 ポートがモニタされる場合、常に入力時にトラフィックを複製するため、 すべての入力トラフィックは、ファブリックにヒットするときに 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 ギガビットを超えることはできません。

モジュールでバッファの過剰使用に関連するドロップが発生するかどうかを確認するには、 次の出力を調べます。

  • CatOS

    Cat6500 (enable)  show asicreg <mod/port> pinnacle err

    レジスタのリスト内の次の出力を調べます。 この出力内の設定が ゼロ以外の場合、バッファ オーバーランによるドロップが 発生したことを示します。

    015B:  PI_PBT_S_QOS3_OUTLOST_REG = 0011

    015F:  PI_PBT_S_HOLD_REG = D26C

  • NativeIOS

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

    51. qos3Outlost = 768504851

show コマンドを数回実行して、 asicreg が着実に増加するかどうかを調べます。 これらのモジュールでの このコマンドを実行するたびに、asicreg の出力はクリアされます。 asicreg の出力がゼロ以外のままの場合、 ドロップがアクティブであることを示します。 トラフィックのレートに応じて、有意な増加を取得するために、 数分間にわたりこのデータを収集する必要がある 場合があります。

回避策

次の手順を実行します。

  1. 他のインターフェイスへの影響を最小限に抑えるため、 それ自体のポートの範囲に常にオーバーサブスクライブする可能性のあるポートを 発行します。

    たとえば、インターフェイスをオーバーサブスクライブするポート 1 に接続されたサーバがある場合、 他の複数のサーバが範囲 2 ~ 8 のポートに接続されていると、 応答の遅延が発生する可能性があります。 この場合は、 オーバーサブスクライブするサーバをポート 9 に移動して、 ポート 1 ~ 8 の最初のブロックバッファを解放します。 最新のソフトウェア バージョンでは、SPAN 宛先は このインターフェイスに自動的に移動するバッファリングを備えているので、 その範囲内の他のポートに影響を与えることはありません。 詳細については、Cisco Bug ID CSCed25278 登録ユーザ専用) (CatOS)および CSCin70308 登録ユーザ専用) (NativeIOS)を 参照してください。

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

    その結果、使用されているポートのうち 1 つだけがドロップされるようになります。 インターフェイス バッファ(32 k)は 1 Mb 共有バッファより非常に小さいため、 個別のポート上でより多くのパケット損失が発生する 検討してください。 これは、低速のクライアントまたは SPAN ポートが、 専用インターフェイスを提供する他のラインカードに移動できない 極端なケースにのみ推奨されます。

    • NativeIOS

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

      Router(config-if)#  hol-blocking  disable

      これがディセーブルになると、ドロップがインターフェイス カウンタに移動し、 show interface gigabit <mod/port> コマンドを使用して表示できます。 同じように個別にバーストが行われなければ、 他のポートは影響を受けません。 これは、 HOL ブロッキングをイネーブルにするために推奨されるため、この情報を使用して、 ポートの範囲でバッファをオーバーランするデバイスを検出し、 HOL ブロッキングを再イネーブルできるように、他のカードまたはカード上の隔離された範囲にデバイスを移動する ために使用できます。

    • CatOS

      Console>  ((enable)  set port hol-blocking <mod/port>  disable

      これがディセーブルになると、ドロップがインターフェイス カウンタに移動し、 show mac <mod/port> コマンドを発行します。 同じように個別にバーストが行われなければ、 他のポートは影響を受けません。 これは、HOL ブロッキングをイネーブルにするために推奨されるため、 この情報を使用して、ポートの範囲でバッファをオーバーランするデバイスを検出し、 HOL ブロッキングを再イネーブルできるように、他のカードまたはカード上の隔離された範囲にデバイスを移動する ために使用できます。

  3. SPAN セッションを設定するときは、 宛先ポートがその特定のインターフェイス上でエラーをレポートしていないことを確認します。 宛先ポートで、 エラーが発生していないかどうかを確認するには、IOS の show interface <interface type> <interface number> コマンドまたは CatOS の show port counters mod/port コマンドで、 ドロップやエラーの出力がないかどうかを確認します。 宛先ポートに接続されているデバイス およびポート自体は、宛先ポートのエラーを回避するために、 速度とデュプレックス設定が必要です。

  4. オーバーサブスクライブ状態のポートがないイーサネット モジュールへの移動を 検討してください。 PortFast を有効にする方法の詳細については、 (『Cisco Catalyst 6500 シリーズ スイッチ:関連インターフェイスとモジュール』 を参照してください。

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

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

  • Microsoft ネットワーク クライアントで No Domain Controllers Available と表示される。

  • DHCP で DHCP Servers Available Available と表示される。

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

  • AppleTalk ネットワーク クライアントで、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 ステータスを示す

インターフェイスのステータスが、errdisable (show interface status コマンドの出力)の場合、 インターフェイスはエラー状態によりディセーブルになっています。 インターフェイスが 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

このメッセージの例は、ブリッジ プロトコル データ ユニット(BPDU)が ホスト ポートで受信されたときに表示されます。 実際のメッセージは、エラー状態の原因によって 異なります。

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

  • デュプレックスのミスマッチ

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

  • BPDU ガード違反

  • UDLD 条件

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

  • リンクフラップの検出

  • セキュリティ違反

  • Port Aggregation Protocol(PAgP; ポート集約プロトコル)フラップ

  • レイヤ 2 トンネリング プロトコル(L2TP)ガード

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

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

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

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

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

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

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

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

また、errdisable recovery cause cause enabled コマンドを発行して、 タイマー期間を設定した後に、自動的にポートを再イネーブルするタイムアウト メカニズムを 設定します。

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

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 を受信したために、ポートが rrdisable  になっている可能性があります。 スイッチが誤ってそのポートに接続されている場合、 ハブがループ条件を作成したポートに接続されている場合は、 トラブルシュートできます。 他のシナリオを修復するには、 製品マニュアルの特定の機能情報を参照してください。

PortFast を有効にする方法の詳細については、 『Cisco IOS プラットフォームでの Errdisable ポート状態の回復』 を参照してください。

この情報に基づいて見直しを行い、トラブルシュートしても問題が 解決しない場合は、 シスコ テクニカル サポートにサポートを依頼してください。

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

show interface コマンド出力でエラーが表示される場合は、問題が発生したインターフェイスの状態と正常性を チェックします。 また、そのインターフェイスをトラフィックが通過しているかどうかをチェックしてください。 PortFast を有効にする方法の詳細については、 ステップ 12 トラブルシューティング システム ソフトウェアを実行する Catalyst 6500/6000 の WS-X6348 モジュールのポート接続の トラブルシューティング」)を参照してください。

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 コマンドの出力で エラーが表示される場合があります。 その場合は、そのインターフェイスに関連するエラーをチェックしてください。 詳細に 『 ステップ 14 トラブルシューティング システム ソフトウェアを実行する Catalyst 6500/6000 の WS-X6348 モジュールのポート接続の トラブルシューティング」)を参照してください。

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 プラットフォームによる ソフトウェア:

    症状 説明 修正
    スーパーバイザ エンジン 720 ベースのスイッチの IEEE 802.1Q トランク インターフェイス 上のジャイアント。 Catalyst 6500 シリーズ スイッチは、1496 バイトを超え、 スーパーバイザ エンジン 720 ポートを通じてタグ付けされて受信されるパケット サイズの ジャイアントをレポートします。 これは、67xx ラインカードでも、問題として現れる場合もあります。 この問題は見かけ上のもので、スイッチではそれらのパケットは転送されます。 この問題は、 ISL1 トランクでも発生します。 詳細については、Cisco Bug ID CSCec62587 登録ユーザ専用) および 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 pps = 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 は アップできません。 これは、 1000BASE-TX(銅線)と低密度波長分割多重(CWDM GBIC)では予期された動作です。 ただし、これは他の GBIC に関しては、正しい動作ではありません。 以前のリリースでは、 チェックサム エラーがある他の GBIC を備えるポートがアップできました。

次のエラー メッセージは、このエラーが 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: Cisco IOS で不正確な GBIC EEPROM エラーか。 不正な GBIC EEPROM エラー』を参照してください。

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

syslog または show log コマンドの出力で、以下のいずれかのメッセージが表示される場合があります。

  • 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_#  グローバル コンフィギュレーション コマンドを発行します。

これらの手順を実行した後で、以下の 1 つまたは複数の問題が発生した場合は、情報を添えて シスコ テクニカル サポート に相談してください。

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

  • モジュールはオンラインになるが、12 個のインターフェイスのグループで診断 する必要があります。

    これは、 show diagnostic module module_# コマンドを発行します。

  • 起動時に、他の状態でモジュールが 作動不能になる。

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

  • すべてのインターフェイスが errdisabled になる。

    これは、show interfaces status module module_#  コマンドを発行します。

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

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

WS-X6348 モジュールまたは他の 10/100 モジュール上 のホストの接続で接続問題がある場合は、 『Cisco IOS システム ソフトウェアを実行する Catalyst 6500/6000 での  WS-X6348 モジュール ポート接続のトラブルシューティング』 を参照してください。

この情報に基づいて見直しを行い、トラブルシュートしても問題が ドキュメント 『Cisco IOS システム ソフトウェアを実行する Catalyst 6500/6000 での  WS-X6348 モジュール ポート接続のトラブルシューティング』に基づいて見直しを行い、トラブルシュートしても問題が解決しない場合は、 シスコ テクニカル サポートにサポートを依頼してください。

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

スパニングツリー関連の問題によって、スイッチド ネットワークで 接続性問題が発生する可能性があります。 スパニングツリーの問題を防止するためのトラブルシューティングの 段階的手順およびガイドラインについては、『 Cisco IOS システム ソフトウェアを実行する Catalyst スイッチでの STP のトラブルシューティング』を参照してください。

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

原因

すべての Cisco IOS デバイスがそうであるように、Catalyst 6500 スイッチも、 限られた数の Telnet セッションのみ許可されます。 この制限に達すると、スイッチは それ以上の vty セッションを許可されません。 この問題に陥っているかどうかを確認するには、 スーパーバイザ エンジンのコンソールに接続します。 show user コマンドを発行します。 このコマンドのコマンドライン インターフェイス(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 linex 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 4 を探します。

show user コマンドの出力がセッションで非アクティブな vty を表示できる場合がありますが、 telnet コマンドを使用したスイッチへの接続が、 次のエラー メッセージを表示して引き続き失敗する場合があります。

% telnet connections not permitted from this terminal

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

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

問題

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

%%RADIUS-4-RADIUS_DEAD: RADIUS サーバ 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 として VLANs.

電源とファンの問題

電源の 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 つの電源がシャーシ全体に電力供給するには十分ではないことを示します。 次の 2 つのオプションの いずれかを実行できます。

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

    たとえば、現在の電源が 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 モードでは、両方の電源モジュールから電力が供給されます。 ただし、 このモードでは、1 つの電源に障害が発生した場合、残りの電源がシャーシ全体に電力を供給できないため、 モジュールの電源は再び失われます。

そのため、より高いワット数の電源を使用することを 推奨します。

空きスロットに予約済みの電力は再割り当てできません。 たとえば、 スロット 6 が空きになっていて、スロット 2 では 68 ワットしか使用できない場合、 スロット 6 用に予約された 282 ワットをスロット 2 に再割り当てして、 スロット 2 でより多くのワット数を使用できるようにすることはできません。

各スロットには、それ自体に使用可能な電源があり、それを使用していない場合、 別のスロットに再割り当てすることはできません。 空きスロットの予約済み電力をディスエーブルにする コマンドはありません。

電源のフル電力容量を使用するには、スイッチが 110VAC ではなく 220VAC に接続されていることを確認します (電源が 220VAC をサポートしている場合)。

電源管理の詳細については、『 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.

"「Diagnostic level complete」により 6500 でクラッシュが発生する

このエラー メッセージは、サポート終了 [EOS}/耐用年数 [EOL] に到達した古い IOS バージョン 12.1 で 表示されます。 診断レベルをデフォルトの minimal に設定し、 デバイスで実行している IOS を最新バージョンの IOS に アップグレードします。


関連情報


Document ID: 24053