この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Cisco IOS®システムソフトウェアが稼働しているCatalyst 6500/6000スイッチのハードウェアおよび共通問題のトラブルシューティング方法について説明します。
このドキュメントに関する固有の要件はありません。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
Cisco IOS ソフトウェアは、スーパバイザ エンジンおよびマルチレイヤ スイッチ フィーチャ カード(MSFC)モジュールの両方にバンドルされている 1 つの Cisco IOS イメージを指します。このドキュメントでは、問題の症状が発生しており、ユーザがこの問題に関する追加情報を必要としているか、またはこの問題の解決を希望していることを前提としています。このドキュメントは、スーパバイザ エンジン 1、2、または 720 ベースの Catalyst 6500/6000 スイッチに適用されます。
システム メッセージは、コンソール ログがイネーブルになっている場合はコンソールに、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 コマンドは、特定のシステム状態の組み合せについて、設定で事前に決められた一連のチェックを実行します。その後、警告状態のリストを作成します。これらのチェックは、不適切と思われる設定を検出する設計になっています。このチェックは、システムの健全性を維持するための支援トラブルシューティングとして機能することを目的としています。このコマンドでは、現在の変数やシステム状態は変更されません。事前に設定された組み合せに一致した場合に警告を発するために、設定に関連するシステム変数と状態を読み取ります。このコマンドはスイッチの機能には影響しないため、実稼働ネットワーク環境で使用できます。プロセス実行中の唯一の制限事項は、このコマンドがブート イメージにアクセスして有効性を検証する間、一定時間ファイル システムを予約することです。このコマンドは、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
other
オフ
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 を示す場合、ハードウェアの問題が存在する可能性があります。次のようなシステム エラー メッセージが表示される場合があります。
%DIAG-SP-3-MINOR_HW: Module 1: Online Diagnostics detected Minor Hardware Error
さらにトラブルシューティングを行うには、次の手順を使用します。
スーパーバイザエンジンにコンソールを接続し、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は、スロット1またはスロット2のいずれかに装着できます。
トラブルシューティングを実行して、モジュールに障害が発生している可能性を排除します。
注:まれに、モジュールの障害によって、スーパーバイザエンジンが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で診断機能が誤ってイネーブルにされる』の詳細も参照してください。
スイッチが起動せず、ブートシーケンス中に自己診断で失敗する場合は、出力をキャプチャして、シスコテクニカルサポートでサービスリクエストを作成し、サポートを依頼してください。
ブート シーケンスや 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やその他のステータスが表示されるモジュールのトラブルシューティング」セクションを参照してください。
ステータスが 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)
Missing
になるスイッチのスーパーバイザエンジンが booting
ループ、ROMモニタ(ROMmon)モード、またはシステムイメージがない場合、問題はおそらくハードウェアの問題ではありません。
システムイメージが破損していると、スーパーバイザエンジンはROMmonモードになるか、ブートに失敗します missing
。スーパーバイザエンジンを回復させる方法に関する手順は、『Cisco IOSシステムソフトウェアが稼働しているCatalyst 6500または6000での破損や
ブートローダーイメージまたはROMmonモードからの回復』を参照してください。 Missing
Cisco IOSイメージは、Sup-bootflash:またはslot0:(PCカードスロット)からブートできます。迅速に回復できるように、システム イメージのコピーを両方のデバイスに置いてください。ご使用の Supervisor Engine 2 のブートフラッシュ デバイスが 16 MB しかない場合は、新しいシステム イメージをサポートするために、32 MB にアップグレードする必要があります。詳細は、『Catalyst 6500 シリーズ Supervisor Engine 2 ブート ROM とブートフラッシュ デバイス アップグレード インストレーション ノート』を参照してください。
この項では、スタンバイ スーパバイザ エンジン モジュールがオンラインにならない一般的な理由と、各問題の解決方法について説明します。次のいずれかの方法で、スーパバイザ エンジン モジュールがオンラインにならないことを判断できます。
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 コマンドを発行します。ハードウェア障害の発生を判別するには、スタンバイ側のスーパーバイザ エンジンへのコンソール経由でブート シーケンスを観察します。
スタンバイ側のスーパーバイザエンジンがオンラインにならないままの場合は、さらにトラブルシューティングを行うために、シスコテクニカルサポート(登録ユーザ専用)でサービスリクエストを作成します。サービスリクエストを作成する際には、前のステップで収集したスイッチ出力のログを提供してください。
このエラー メッセージが発生するのは、PA-1XCHSTM1/OC3 には SRB では診断機能がサポートされていないためです。スイッチで SRB コードを実行しながら、このコマンドが渡されると、not applicable ステータスが表示されます。これは、全体の診断で適切な結果が得られるため、SPAインターフェイスプロセッサのステータスがチェックされないという意味ではありません。SRC コード以降の出力結果に関しては問題ありません。これはSRBコードの不具合によって引き起こされます。この不具合はCisco Bug ID CSCso02832 (登録したシスコのクライアントのみアクセス可能)に記載されています。
このセクションでは、Catalyst スイッチのスーパーバイザで予期しないリロードが発生する一般的な原因について説明しています。
障害の後では、スタートアップ コンフィギュレーションによる同期を行うために、アクティブ側のスーパーバイザがスタンバイ側のスーパーバイザをリセットします。この問題は、管理ステーションで短時間(1 ~ 3秒)のうちに連続してwr memが実行され、スタートアップコンフィギュレーションがロックされて同期が失敗するために発生する可能性があります。最初の同期プロセスが完了せず、2番目の wr memが発行された場合、スタンバイ側のスーパーバイザは同期に失敗し、リロードまたはリセットが発生する場合もあります。この問題は、Cisco 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 コマンドを入力すると、コンフィギュレーション ファイルがロックされます。この問題は、Cisco 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
モジュールをシャーシから物理的に取り外しても、スロット内のそのモジュールのコンフィギュレーションが引き続き表示されます。この問題は、モジュールの交換を容易にする設計に由来するものです。スロットに同じタイプのモジュールを挿入した場合、スイッチでは、以前にスロットに入っていたモジュールのコンフィギュレーションが使用されます。このスロットに別のタイプのモジュールが挿入されると、このモジュールのコンフィギュレーションはクリアされます。スロットからモジュールが取り外されたときに、自動的にコンフィギュレーションを削除するには、グローバル コンフィギュレーション モードで 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 テクニカルサポートまでお問い合わせください。 その際には、 show tech-support および show logging コマンドの出力と crashinfo ファイルの出力を提供してください。ファイルを送るには、スイッチから TFTP サーバに TFTP で転送し、ファイルをサービス リクエストに添付してください。
crashinfo ファイルがない場合は、スイッチの電源を調べて、電源に障害が発生していないことを確認してください。無停電電源装置(UPS)を使用している場合には、装置が正常に操作していることを確認します。それでも問題が判別できない場合は、シスコのテクニカルサポートのエスカレーション センターにお問い合せください。
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 コマンドの出力を用意して、シスコ テクニカルサポートに連絡してください。
このセクションでは、モジュールの1つがオンラインにならない一般的な原因と、その問題の解決方法について説明します。モジュールがオンラインになっていないことは、次のいずれかの方法で判別できます。
show module コマンドの出力に、次のいずれかのステータスが表示されている。
other
unknown
faulty
errdisable
power-deny
power-bad
Status LED がオレンジ色か赤色に点灯している。
関連するリリースの『Catalyst 6500 シリーズのリリース ノート』の「サポート対象ハードウェア」セクションを調べてください。モジュールが現在実行しているソフトウェアでサポートされていない場合は、Cisco IOS Software Centerから必要なソフトウェアをダウンロードします。
ステータスが power-deny である場合、スイッチにはこのモジュールに電力を供給するのに十分な電力がありません。十分な電力を利用できるかどうかを確認するには、show power /strong>コマンドを発行します。このドキュメントの「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)のコンテンツにアクセスできない場合に、この現象が発生する可能性があります。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
スイッチの管理インターフェイスで大量のトラフィックが処理されると、スイッチでは InbandKeepAliveFailure エラー メッセージの発生がログに記録されます。これには、次の理由が考えられます。
スーパーバイザ エンジンのビジー状態
スパニングツリー プロトコルのループ状態
インバンド通信チャネルでの ACL および QoS ポリサーによるトラフィックの抑制や廃棄
ポート ASIC 同期の問題
スイッチ ファブリック モジュールの問題
この問題を解決するには、次の手順を実行します。
show process cpu コマンドを使用して、問題を起こしているプロセスを特定します。根本的な原因を解消するには、『Catalyst 6500/6000 スイッチの CPU 高使用率』を参照してください。
これらのコミュニケーション障害メッセージは、誤って装着されたり、障害のあるスーパーバイザ モジュールにより送出される場合があります。このエラー メッセージからの復旧には、メンテナンスの時間を確保して、スーパーバイザ モジュールを取り付け直してください。
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 に設定した場合です。 詳細は、『エラー「System returned to ROM by power-on (SP by abort)」による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 に問題があることを示しています。NVRAM と消去して、スイッチをリロードすると、NVRAM を回復できます。 これで問題が解決しない場合には、NVRAM をフォーマットしてください。いずれの場合も、NVRAM のコンテンツのバックアップを取っておくことを推奨いたします。このエラー メッセージが表示されるのは、NVRAM デバッギングがイネーブルになっている場合だけです。
エラーメッセージ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.
このエラーは、新しく挿入されたモジュールがしっかりと挿入されていないことが原因である可能性があります。 問題を解決するには、モジュールを取り付け直します。
Software Interface Descriptor Block(SWIDB)の最大数に達すると、次のエラーメッセージが表示されます。
%INTERFACE_API-SP-1-NOMORESWIDB:これ以上SWIDBを割り当てることはできない、最大許容12000
IDB制限についての詳細は、『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の数値が変わりますが、Total IDBの数値はメモリに残ります。 この問題を解決するには、スイッチをリロードしてIDBデータベースをクリアします。それ以外の場合は、枯渇した後、削除したサブインターフェイスを再利用する必要があります。
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 モジュールを使用している場合、個々のポートの使用率により、周囲のインターフェイスで接続性の問題やパケットの喪失が発生する可能性があります。特に、これらのラインカードで EtherChannel と Remote Switched Port Analyzer(RSPAN)を使用しているときは、パケットの喪失による応答の遅延が発生する可能性があります。これらのラインカードは、ギガビットをデスクトップにまで拡張するように設計されたオーバーサブスクリプションカードであり、サーバファームの接続には適していません。これらのモジュールには、8 つのポートをサポートするポート ASIC からの単一の 1 ギガビット イーサネット アップリンクがあります。これらのカードは、ポートのグループ(1 ~ 8、9 ~ 16、17 ~ 24、25 ~ 32、33 ~ 40、および41 ~ 48)間で1 Mbのバッファを共有します。これは、8個のポートの各ブロックが8:1のオーバーサブスクライブ状態であるためです。8 つのポートからなる各ブロックの集約スループットは、1 Gbps を超えることはできません。さまざまなタイプのイーサネットインターフェイスモジュールとポートあたりのサポートバッファサイズの詳細は、『Cisco Catalyst 6500シリーズ10/100および10/100/1000 Mbpsイーサネットインターフェイスモジュール』の表4を参照してください。
オーバーサブスクライブは、複数のポートが単一の Pinnacle ASIC に統合されていることにより発生します。Pinnacle ASIC は、パックプレーンのスイッチング バスとネットワーク ポート間でパケットを転送するダイレクト メモリ アクセス(DMA)エンジンです。この範囲にあるいずれかのポートで、その帯域幅を超えたレートでトラフィックの送受信が行われるか、またはバースト性のトラフィックを処理するために大量のバッファが使用された場合には、同じ範囲にある他のポートでパケットの喪失が発生する可能性があります。
SPAN宛先は、VLAN全体または複数のポートから1つのインターフェイスにトラフィックをコピーすることが珍しくないため、非常に一般的な原因です。個別にインターフェイス バッファを備えたカードでは、宛先ポートの帯域幅を超えたパケットは通知されることなく廃棄されるため、他のポートに影響が及ぶことはありません。共有バッファの場合には、これによって同じ範囲内の他のポートで接続性の問題が発生します。ただし、ほとんどのシナリオでは、共有バッファにより問題が発生することはありません。ワークステーションにギガビットが 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 ギガビットを超えることはできません。
バッファの過剰使用に関連した廃棄が発生しているモジュールを確認するには、次の出力を調べてください。
ネイティブCisco IOS
Cat6500# show counters interface gigabitEthernet <mod/port>(ギガビットイーサネットコマンド) | include qos3Outlost
51. qos3Outlost = 768504851
asicreg が一定の傾向で増加していることを確認するために、show コマンドを何度か発行します。asicreg の出力は実行されるたびにクリアされます。asicreg の出力がゼロにならない場合は、現在廃棄が行われていることを示しています。トラフィックのレートに基づいて、このデータを数分で収集して、大幅な増分を取得する必要があります。
次のステップを実行します。
他のインターフェイスへの廃棄の影響を最小限に抑えるため、自身のポート範囲で常にオーバーサブスクライブしているすべてのポートを切り離します。
たとえば、インターフェイスであるポート1に接続されたサーバがあ oversubscribing
る場合、2 ~ 8の範囲のポートに接続された他のサーバがあると、応答が遅くなる可能性があります。この場合は、 oversubscribing< /code> server to port 9 in order to free up the buffer in the first block of ports 1-8. On newer software versions, SPAN destinations have the buffering automatically moved to the interface, so it does not impact the other ports in its range. Cisco bug ID CSCin70308 (accessible only to registered Cisco clients) for more information.
共有バッファの代わりにインターフェイス バッファを使用する Head of Line blocking(HOL)をディセーブルにします。
この結果、使用されている単一のポートからのみドロップが発生します。インターフェイスバッファ(32 k)は1 Mbの共有バッファよりも大幅に小さいため、個々のポートではより多くのパケット損失が発生する可能性があります。これが推奨されるのは、比較的低速なクライアント場合や、SPAN ポートを専用のインターフェイス バッファを提供する他のラインカードに移動できない場合など、極端なケースに限られます。
ネイティブCisco IOS
Router(config)# interface gigabitethernet <mod/port>
Router(config-if)# hol-blockingディセーブル
これがディセーブルにされると、廃棄はインターフェイス カウンタに移動し、show interface gigabit <mod/port> コマンドで確認できます。他のポートも個別にbursting
を実行しない限り、これらのポートは影響を受けません。HOLブロッキングはイネーブル状態に維持することが推奨されるため、この情報を使用して、ポート範囲でバッファをオーバーランしているデバイスを特定し、別のカードまたはカード上の隔離領域に移動して、HOLブロッキングを再度イネーブルにできます。
SPAN セッションを設定するときは、その特定インターフェイスでのエラーが宛先ポートで報告されていないことを確認してください。宛先ポートで発生する可能性のあるエラーをチェックするには、Cisco IOSのshow interface <interface type> <interface number>コマンドの出力を調べて、出力の廃棄やエラーがないことを確認します。宛先ポートでのエラーを避けるために、宛先ポートに接続されたデバイスとポート自体は、速度とデュプレックスの設定を同じにする必要があります。
オーバーサブスクライブ状態のポートがないイーサネット モジュールへの移動を検討してください。サポート対象モジュールの詳細は、『Cisco Catalyst 6500 シリーズ スイッチ - 対応インターフェイスとモジュール』を参照してください。
スイッチで実行されているプロトコルによっては、初期接続遅延が引き起こされる場合があります。クライアント マシンの電源投入時やリブート時に次のいずれかの症状が見られる場合は、この問題が起きている可能性があります。
Microsoftクライアントで「No Domain Controllers Available」と networking
表示される。
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 ドライバの既知の問題
速度とデュプレックスのミスマッチ
オートネゴシエーションの問題
ケーブルに関する問題
さらにトラブルシューティングを進めるには、『Cisco Catalyst スイッチと NIC との互換性に関する問題のトラブルシューティング』を参照してください。
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 状態のポートをイネーブルにするには、次の手順を実行します。
接続の一端のケーブルを取り外します。
インターフェイスを再設定します。
たとえば、Etherchannel の誤設定によりインターフェイスが errdisabled ステートになっている場合は、その Etherchannel のインターフェイス範囲を再設定します。
両端でポートをシャットダウンします。
両方のスイッチにケーブルを接続します。
インターフェイスで 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
errdisabl eの原因が判明したら、問題をトラブルシューティングし、問題の根本的な原因を修正します。たとえば、例で示されているように、PortFast 対応のアクセス ポートで BPDU を受信したために、ポートが errdisable 状態になる場合があります。スイッチが偶然そのポートに接続されたのかどうか、またはハブが接続されたことでループ状態が発生したのかどうかを、トラブルシューティングできます。他のシナリオをトラブルシューティングするには、製品のドキュメントでそれぞれの機能の情報を参照してください。 errdiable ステータスに関するさらに包括的な情報は、『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 プラットフォームでのカウンタの既知の問題が挙げられています。
注:内部サイトおよびバグ情報にアクセスできるのは、登録されているシスコのクライアントだけです。
症状 | 説明 | 修正 |
---|---|---|
Supervisor Engine 720 ベースのスイッチの IEEE 802.1Q トランク インターフェイスでのジャイアント | Catalyst 6500シリーズスイッチでは、Supervisor Engine 720ポートを介したトランク上でタグ付きで受信された1496バイトを超えるパケットサイズのジャイアントが報告される場合があります。これは、67xx ラインカードでも、問題として現れる場合もあります。この問題は見かけ上のもので、スイッチではそれらのパケットは転送されます。この問題は、ISL 1(ISL)トランクでも発生します。詳細については、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コマンドの出力に、bps 1 とpps 2 に関する不正確な統計情報が示される。 | 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(パケット/秒)。
このセクションで紹介されているドキュメントに基づいて検討とトラブルシューティングを行っても問題が解決しない場合は、シスコのテクニカルサポートにサポートを要請してください。
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エラーの誤り』を参照してください。
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 ポートのグループがある場合には、次の手順を実行します。
インターフェイスをいったんディセーブルにしてからイネーブルにします。
モジュールをソフトリセットするコマンドを発行します。
モジュールをハード リセットするには、以下の操作のいずれかを実行します。
カードを物理的に取り付け直します。
no power enable module module_# グローバル コンフィギュレーション コマンドと power enable module module_# グローバル コンフィギュレーション コマンドを発行します。
これらの手順を実行した後、次の問題が1つ以上発生した場合は、情報を添えてシスコテクニカルサポート< /a>にお問い合わせください。
モジュールがオンラインにならない。
モジュールはオンラインになるが、12インターフェイスのグループの診断で問題が発生。
これは、show diagnostic module <module_number>(登録ユーザ専用)コマンドの出力に表示されます。
モジュールが起動しても、other の状態に留まっている。
モジュールのすべてのポート LED がオレンジになる。
すべてのインターフェイスが errdisabled ステートになっている。
これは、show interfaces status module module_# コマンドを発行すると表示されます。
詳細については、「Cisco IOSシステムソフトウェアが稼動するCatalyst 6500/6000でのWS-X6348モジュールのポート接続のトラブルシューティング」を参照してください。
WS-X6348モジュールまたはその他の10/100モジュールでホストの接続に問題がある場合、詳細については「Cisco IOSシステムソフトウェアが稼動するCatalyst 6500/6000でのWS-X6348モジュールのポート接続のトラブルシューティング」を参照してください。 ドキュメント『Cisco IOSシステムソフトウェアが稼動するCatalyst 6500/6000でのWS-X6348モジュールのポート接続のトラブルシューティング』に基づいて検討とトラブルシューティングを行っても問題が解決しない場合は、シスコのテクニカルサポートにサポートを要請してください。
スパニングツリー関連の問題によって、交換回線ネットワークで接続上の問題が発生することがあります。スパニングツリーの問題を防ぐ方法に関するガイドラインは、『Cisco IOSシステムソフトウェアが稼働するCatalystスイッチでのSTPに関するトラブルシューティング』を参照してください。
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
次のステップを実行します。
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.
アクティブではないセッションをクリアするために、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)#
利用可能な 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 コマンドを発行します。
問題
6500スイッチはVSSクラスタ内にスタックされています。これをスタンバイスイッチにコンソール接続しようとすると、次のRADIUSログメッセージが表示されて失敗します。
%RADIUS-4-RADIUS_DEAD: RADIUSサーバ10.50.245.20:1812,1813が応答していません。
このスタンバイ側スーパーバイザへのTelnetによる認証は正常に動作し、アクティブ側スーパーバイザへのコンソールログインも正常に動作します。この問題は、スタンバイスーパーバイザのコンソールへの接続で発生します。
解決方法
スタンバイユニットのコンソールに対するRADIUS認証は実行できません。スタンバイには、AAA 認証に対応する IP 接続がありません。ローカルデータベースなどのフォールバックオプションを使用する必要があります。
システムでジャイアント データ パケットが送信されていないにもかかわらず、VSL インターフェイスでジャイアント パケットのカウンタが増加することがあります。
VSLインターフェイスを通過するパケットは、通常のMACヘッダーを超えて32バイトのVSLヘッダーを伝送します。このヘッダーは理論上はパケット サイズの分類付けからは除外されていますが、実際には、ポートの ASIC ではこのヘッダーを分類付けしています。その結果、正規サイズのパケットの 1518 のサイズ制限に近いサイズの制御パケットが、ジャイアント パケットとして分類される結果となる可能性があります。
現在のところ、この問題の回避策はありません。
以前に、存在しなかった複数の 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として追加できます。
電源スイッチをオンにしても、電源モジュールの 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シリーズスイッチ)の「電源モジュールのトラブルシューティング」セクションで示されている手順を使用します。
ログにこのメッセージが記録されていた場合、モジュールの電源をオンにするのに十分な電力がないことを示しています。メッセージ中の [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 シリーズ スイッチの電源管理』を参照してください。
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.
改定 | 発行日 | コメント |
---|---|---|
2.0 |
22-Sep-2023 |
再認定 |
1.0 |
28-May-2002 |
初版 |