概要
このドキュメントでは、Cisco IOS® システム ソフトウェアが稼動している Catalyst 6500/6000 シリーズ スイッチのハードウェアおよび共通問題のトラブルシューティングについて説明しています。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 ソフトウェアが稼動しているシステムのトラブルシューティングには、次のドキュメントを参照してください。
- ハイブリッド モードの Catalyst 6500/6000 シリーズ スイッチのトラブルシューティング
- MSFC および MSFC2 のハードウェアと関連問題のトラブルシューティング
前提条件
要件
このドキュメントに関する特別な要件はありません。
使用するコンポーネント
このドキュメントは、特定のソフトウェアやハードウェアに限定されるものではありません。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
syslogおよびコンソールのエラーメッセージのトラブルシューティング
システム メッセージは、コンソール ログがイネーブルになっている場合はコンソールに、syslog がイネーブルになっている場合は syslog に表示されます。情報提供のためにだけ表示され、エラー状態を示すものではないメッセージもあります。システムのエラー メッセージの概要は、『システム メッセージの概要』を参照してください。
適切なレベルのログをイネーブルにして、syslog サーバにメッセージを記録するようにスイッチを設定します。設定の詳細は、「IOS デバイスの設定手順」セクション（『Resource Manager Essentials と Syslog Analysis：手引き』）を参照してください。
ログに記録されたメッセージをモニタするには、show logging コマンドを発行します。または、必要に応じて CiscoWorks や HP OpenView などのモニタリング ステーションを使用します。
特定のシステム メッセージを詳しく調べるには、『メッセージと回復手順』（Catalyst 6500/6000 Cisco IOS システム ソフトウェア）を参照してください。
それでも問題の判別ができないか、表示されているエラー メッセージがこのドキュメントに見つからない場合は、シスコのテクニカルサポートのエスカレーション センターにご連絡ください。
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 age
- hello time
- 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
- off
- 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になる
スイッチの Supervisor Engine 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 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 が示されている場合には、次の手順を実行します。
a.モジュールをしっかりと取り付け直して、ネジがしっかり締め付けられていることを確認します。
b. 同じシャーシ、または別のシャーシの正常に動作することが確認されているスロットにモジュールを移動します。
注：Supervisor Engine 1 や 2 は、スロット 1 またはスロット 2 だけに装着できます。
c. トラブルシューティングを実行して、モジュールに障害が発生している可能性を排除します。
注：まれに、モジュールの障害によって、スーパーバイザ エンジンが 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 コマンドを発行して、他に障害が発生しているコンポーネントがないか探してください。
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: コマンドを発行します。
このセクションの出力を見ると、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
!--- 出力を省略。
スイッチがリブートされたと思われる時刻にソフトウェア クラッシュが発生していたことがコマンド出力に表示されている場合は、シスコのテクニカルサポートまでお問い合せください。その際には、crashinfo ファイルの出力のほかに、show tech-support および show logging コマンドの出力も提供してください。ファイルを送るには、スイッチから TFTP サーバに TFTP で転送し、ファイルをサービス リクエストに添付してください。
- crashinfo ファイルがない場合は、スイッチの電源を調べて、電源に障害が発生していないことを確認してください。無停電電源装置（UPS）を使用している場合には、装置が正常に操作していることを確認します。それでも問題が判別できない場合は、シスコのテクニカルサポートのエスカレーション センターにお問い合せください。
DFC装備モジュールの自動リセット
Distributed Forwarding Card（DFC）を装備したモジュールがユーザによるリロードではなく、自動的にリセットされた場合は、DFC カードのブートフラッシュを確認して、クラッシュが発生したかどうかを確認できます。クラッシュ情報ファイルが作成されている場合は、クラッシュの原因を確認できます。クラッシュ情報ファイルがあるかどうか、およびいつ書き出されたかを確認するには、dir dfc#module_#-bootflash: コマンドを発行します。DFC のリセットが crashinfo のタイムスタンプに一致する場合は、more dfc#module_#-bootflash:filename コマンドを発行します。または、copy dfc#module_#-bootflash:filename tftp コマンドを発行して、TFTP 経由で、そのファイルを TFTP サーバに転送してください。
cat6knative#dir dfc#6-bootflash:
Directory of dfc#6-bootflash:/
-#- ED ----type---- --crc--- -seek-- nlen -length- -----date/time------ name
1 .. crashinfo 2B745A9A C24D0 25 271437 Jan 27 2003 20:39:43 crashinfo_
20030127-203943
crashinfo ファイルが利用可能になったら、show logging コマンドと show tech コマンドの出力を収集して、シスコのテクニカルサポートに、さらにサポートを依頼してください。
オンラインにならなかったり、Faultyやその他のステータスが表示されるモジュールのトラブルシューティング
このセクションでは、モジュールの 1 つがオンラインにならない一般的な理由とその問題の解決法の概要を説明しています。モジュールがオンラインになっていないことは、次の方法のいずれかで判別できます。
- show module コマンドの出力に、次のいずれかのステータスが表示されている。
- other
- unknown
- faulty
- errdisable
- power-deny
- power-bad
- Status LED がオレンジ色か赤色に点灯している。
<p>- 関連するリリースの『<a href="http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html">Catalyst 6500 シリーズのリリース ノート</a>』の「<strong>サポート対象ハードウェア</strong>」セクションを調べてください。モジュールが現在稼動中のソフトウェアでサポートされていない場合は、<a target="_blank" href="http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=268438303">Cisco IOS Software Center</a> <img height="9" width="15" border="0" src="http://www.cisco.com/apps-ui/generic/interim/images/popup_icon.gif" />（<font size="-1"><a href="http://tools.cisco.com/RPF/register/register.do?locale=ja_JP">登録</a>ユーザ専用</font>）から必要なソフトウェアをダウンロードしてください。
</p>
<p>- ステータスが <tt>power-deny</tt> の場合は、スイッチにはそのモジュールに供給するのに十分な電力がありません。十分な電力を利用できるかどうかを確認するには、<b>show power</b> コマンドを発行します。このドキュメントの「<a href="#subtopic4b">エラー メッセージ「C6KPWR-4-POWRDENIED: See the Troubleshoot C6KPWR-4-POWRDENIED: insufficient power, module in slot [dec] power denied or %C6KPWR-SP-4-POWRDENIED: insufficient power, module in slot [dec] power denied」のトラブルシューティング</a>」セクションを参照してください。
</p>
<p>- ステータスが <tt>power-bad</tt> の場合、スイッチはカードを認識していますが、電力を割り当てることができません。ラインカードの ID を判別するために、スーパーバイザ エンジンがモジュール上のシリアル PROM（SPROM）のコンテンツにアクセスできない場合に、この現象が発生する可能性があります。SPROM が読み取り可能かどうかを確認するには、<b>show idprom module <span style="font-weight:normal; font-style:italic">slot</span></b> コマンドを発行します。SPROM にアクセスできない場合は、モジュールをリセットします。 </p>
<p>- モジュールがコネクタに適切に取り付けられて、完全にネジ止めされていることを確認してください。それでも、モジュールがオンラインにならない場合は、診断がイネーブルであることを確認するために、<b>diagnostic level complete</b> グローバル コンフィギュレーション コマンドを発行します。次に、<b>hw-module module <span style="font-weight:normal; font-style:italic">slot_number</span> reset</b> コマンドを発行します。それでもモジュールがオンラインにならない場合は、モジュール上のバックプレーン コネクタを検査して、破損していないことを確認します。視認できる損傷がない場合は、別のスロットまたは別のシャーシにモジュールを取り付けてみてください。また、バックプレーンのスロット コネクタのピンが曲がっていないかを調べます。シャーシのバックプレーンにあるコネクタ ピンを調べるときには、必要に応じて懐中電灯を使用してください。</p>
<p>- モジュールのハードウェア エラーを特定するには、<b>show diagnostics module <span style="font-weight:normal; font-style:italic">slot_number</span></b> コマンドを発行します。完全な診断をイネーブルにするために、<b>diagnostic level complete</b> グローバル コンフィギュレーション コマンドを発行します。スイッチでモジュールの診断を実行できるようにするには、完全な診断をイネーブルにする必要があります。最小限の診断を完全な診断に変更する場合には、スイッチで完全な診断を実行できるようにするには、モジュールをリセットする必要があります。このセクションの出力例では、<b>show diagnostics module</b> コマンドを発行しています。ところが、テストの多くはすでに最小限のモードで実行されているため、この出力結果は確定的ではありません。この出力では、完全な結果を表示するために、診断レベルをオンにして、<b>show diagnostics module</b> コマンドを再発行する方法が示されています。 </p>
<p>-
<b>注：</b>出力例のモジュールには、ギガビット インターフェイス コンバータ（GBIC）はインストールされていません。そのため、完全性テストは実施されていません。BIC の完全性テストが実行されるのは、銅線接続対応の GBIC（WS-G5483=）に対してだけです。 </p>
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
!--- 「U」とマーキングされているテストは省略されます。その理由は
!--- 最小限のレベルの診断がイネーブルであるためです。
cat6knative#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
cat6knative(config)#diagnostic level complete
!--- このコマンドにより完全な診断がイネーブルにされます。
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</b>
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
!--- このテストの結果は不明です（「U」はテストされていません）。
!--- その理由は、銅線接続の GBIC がないためです。
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 エラー メッセージの発生がログに記録されます。これには、次の理由が考えられます。
<p>- スーパーバイザ エンジンのビジー状態</p>
<p>- スパニング ツリー プロトコルのループ状態</p>
<p>- インバンド通信チャネルでの ACL および QoS ポリサーによるトラフィックの抑制や廃棄</p>
<p>- ポート ASIC 同期の問題</p>
<p>- スイッチ ファブリック モジュールの問題</p>
この問題を解決するには、次の手順を実行します。
1. show process cpu コマンドを使用して、問題を起こしているプロセスを特定します。根本的な原因を解消するには、『Catalyst 6500/6000 スイッチの CPU 高使用率』を参照してください。
2. これらのコミュニケーション障害メッセージは、誤って装着されたり、障害のあるスーパーバイザ モジュールにより送出される場合があります。このエラー メッセージからの復旧には、メンテナンスの時間を確保して、スーパーバイザ モジュールを取り付け直してください。
電源オンによりシステムがROMモードに戻る(SP by Abort)
Cisco IOS ソフトウェアが稼動する Cisco Catalyst 6500/6000 では、次のリセット理由が表示され、リロードされたように見える場合があります。
System returned to ROM by power-on (SP by abort)
Catalyst 6500/6000 の SP のコンフィギュレーション レジスタがブレークを許可するように設定されている場合（たとえば、0x2）、コンソールのブレーク信号を受信すると ROMmon 診断モードに入ります。システムはクラッシュしたように見えます。SP と RP でのコンフィギュレーション レジスタ設定のミスマッチにより、このタイプのリロードが発生する可能性があります。具体的には、スーパーバイザ エンジンのスイッチ プロセッサ（SP）のコンフィギュレーション レジスタを ignore break を実行しない値に設定して、その一方で、マルチレイヤ スイッチ フィーチャ カード（MSFC）のルート プロセッサ（RP）のコンフィギュレーション レジスタを ignore break を実行する適切な値に設定した場合です。たとえば、スーパーバイザ エンジン SP を 0x2、MSFC RP を 0x2102 に設定した場合です。
詳細は、『エラー「System returned to ROM by power-on (SP by abort)」による IOS Catalyst 6500/6000 のリセット』を参照してください。
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
<p>このように設定されているために、スイッチでは、実行コンフィギュレーションでの BOOT 変数の設定にかかわらず、以前のイメージでブートされることになります。この問題を解決するには、<b>switch(config)#config-register 0x2102</b> コマンドを発行した後で、SP と RP のコンフィギュレーション レジスタ値が同じであることを確認します。これをスタートアップ コンフィギュレーションに保存してから、スイッチをリロードします。</p>
Error: NVRAM: nv->magic != NVMAGIC, invalid nvram
このエラー メッセージは、NVRAM に問題があることを示しています。NVRAM と消去して、スイッチをリロードすると、NVRAM を回復できます。
これで問題が解決しない場合には、NVRAM をフォーマットしてください。いずれの場合も、NVRAM のコンテンツのバックアップを取っておくことを推奨いたします。
このエラー メッセージが表示されるのは、NVRAM デバッギングがイネーブルになっている場合だけです。
Error: Switching Bus FIFO counter stuck
<p>エラー メッセージ「<tt>CRIT_ERR_DETECTED Module 7 - Error: Switching Bus FIFO counter stuck</tt>」は、データ スイッチング バスでモジュールの動作が確認できないことを示しています。</p>
<p>このエラーは、新しく挿入したモジュールがシャーシ内部にしっかりと固定されていないか、またはゆっくり押し込みすぎた場合に発生します。
</p>
<p>モジュールを取り付け直して、問題を解決します。</p>
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 の容量が不足している場合によく発生します。
この問題を解決するには、次のいずれかの手順を実行します。
<p>DRAM をアップグレードする。</p>
<p>『<a href="/JP/support/public/ht/tac/100/1007817/choosing_ios-j.shtml">Cisco IOS ソフトウェア リリースの選択方法</a>』の「<a href="/JP/support/public/ht/tac/100/1007817/choosing_ios-j.shtml#memory">メモリ要件</a>」（例 4）セクションを参照してください。それによって、使用のイメージに必要な DRAM 総量を算出できます。</p>
<p>現在のメモリ サイズに適したイメージをロードする。</p>
<p>ご使用の Catalyst 6500/6000 にインストールされているスーパーバイザのタイプを判別するには、『<a href="/JP/support/public/ht/tac/100/1008525/96-j.shtml">Catalyst 6500/6000 シリーズ スイッチにインストールされたスーパーバイザ モジュールのタイプ判別方法</a>』を参照してください。</p>
<p> Catalyst 6500/6000 で使用可能なデフォルトのメモリ オプションを調べるには、『<a href="/JP/support/public/ht/tac/100/1008272/switchMEM_FLASHsizes_24050-j.shtml">Catalyst スイッチ プラットフォームでサポートされるメモリおよびフラッシュ サイズ</a>』を参照してください。</p>
<p> 適切なソフトウェアを選択してダウンロードするには、「<a href="http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=268438038">ソフトウェア ダウンロード - スイッチ</a>」（<font size="-1"><a href="http://tools.cisco.com/RPF/register/register.do?locale=ja_JP">登録</a>ユーザ専用</font>）
ページを参照してください。</p>
CatOS から Cisco IOS ソフトウェアへの変更、または Cisco IOS ソフトウェアから CatOS への変更
CatOS から Cisco IOS システム ソフトウェアへ、あるいは、Cisco IOS ソフトウェアから CatOS への変更が困難な場合には、次のドキュメントを参照してください。
- Catalyst 6500/6000 スイッチでの CatOS から Cisco IOS へのシステム ソフトウェアの変更
- Catalyst 6500/6000 スイッチでの Cisco IOS から CatOS へのシステム ソフトウェアの変更
Cisco IOS から CatOS への変更後に NVRAM にアクセスする際の問題
Cisco IOS から CatOS への変更中に NVRAM が破損したか、または MSFC の ROMmon の CONFIG_FILE 変数の値が設定された場合に、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 で失敗します。この問題は、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
!--- Enter キーまたは Return キーを押します。
!--- ROMmon 特権モードに入っています。
!--- 次の出力が表示されます。
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
!--- Enter キーまたは Return キーを押します。
!--- これで CONFIG_FILE 変数が設定解除されます。
- rommon 4 >sync
!--- Enter キーまたは Return キーを押します。
- rommon 5 >reset
!--- Enter キーまたは Return キーを押します。
Cisco IOS から CatOS への変更中に NVRAM が損傷を受けた場合は、NVRAM を消去して問題を解決します。NVRAM を消去するには、ROMmon モードに入ってから、次のコマンドを発行します。
rommon 1 >priv
!--- Enter キーまたは Return キーを押します。
!--- ROMmon 特権モードに入っています。
!--- 次の出力が表示されます。
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
rommon 2 >nvram_erase
!--- Enter キーまたは Return キーを押します。
!--- 次のパラメータを正確に入力します。
!--- 1 行目は、「be」の後に（スペースを空けずに）6 個のゼロ（「000000」）を入力します。
!--- 2 行目は、「2」の後に（スペースを空けずに）4 個のゼロ（「00000」）を入力します。
Enter in hex the start address [0xbe020000]: be000000
!--- Enter キーまたは Return キーを押します。
Enter in hex the test size or length in bytes [0x100]: 200000
!--- Enter キーまたは Return キーを押します。
!--- NVRAM の消去が完了したら、reset コマンドを発行します。
rommon 3 >reset
!--- Enter キーまたは 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 Monitor（ROMmon）モードのままになる可能性があります。
この問題を解決するには、次の手順を実行します。
この問題は、ソフトウェア イメージのチェックサムが正しくないために発生する場合があります。Cisco IOS ソフトウェア イメージを TFTP サーバから再度ダウンロードしてください。
再度ダウンロードしても問題が解決しない場合は、フラッシュ カードをフォーマットしてから、もう一度 Cisco IOS ソフトウェア イメージをダウンロードしてください。 フラッシュの消去方法については、『PCMCIA ファイル システムの互換性マトリクスとファイル システム情報』を参照してください。
- この問題はハードウェアの障害によって引き起こされる場合もありますが、エラー メッセージにはどのハードウェア コンポーネントが問題を引き起こしてるかは表示されません。別のフラッシュ カードを使用して 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 つの 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 全体や複数のポートから単一インターフェイスへのトラフィックのコピーは珍しくないため、スパンの終点にこそ原因があります。個別にインターフェイス バッファを備えたカードでは、宛先ポートの帯域幅を超えたパケットは通知されることなく廃棄されるため、他のポートに影響が及ぶことはありません。共有 バッファの場合には、これによって同じ範囲内の他のポートで接続性の問題が発生します。ただし、ほとんどのシナリオでは、共有バッファにより問題が発生す ることはありません。ワークステーションにギガビットが 8 つ接続されている場合であっても、割り当てられている帯域幅を超過することはほとんどありません。
スイッチでローカル SPAN を設定してあると、特に大量の送信元ポートを監視している場合に、サービスの低下が発生する可能性があります。特定の VLAN を複数監視していて、これらの VLAN のいずれかに多数のポートが割り当てられている場合には、この問題は解決しません。
SPAN がハードウェアで実行されていても、スイッチでは 2 倍のトラフィックが搬送されるため、パフォーマンスに影響が現れます。各ラインカードでは、入力時にトラフィックが複製されるため、ポートが監視されてい る場合には、ファブリック到着時にすべての入力トラフィックは倍になります。ラインカードで多数のビジー ポートのトラフィックをキャプチャすると、特に 8 ギガビットのファブリック接続しかない WS-6548-GE-TX カードでは、ファブリック接続がいっぱいになる可能性があります。
WS-X6548-GE-TX、WS-X6548V-GE-TX、WS-X6148-GE-TX、および WS-X6148V-GE-TX モジュールには、EtherChannel に関して制限があります。
EtherChannel では、1 つのバンドル内のすべてのリンクからのデータは、データの宛先が別のリンクであったとしても、ポート 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
asicreg が一定の傾向で増加していることを確認するために、show コマンドを何度か発行します。asicreg の出力は実行されるたびにクリアされます。asicreg の出力がゼロにならない場合は、現在廃棄が行われていることを示しています。顕著な増加を確認するには、トラフィックのレートに基づいて、数分間に渡ってこのデータを収集する必要があります。
回避策
次の手順を実行します。
1. 他のインターフェイスに対する廃棄の影響を最小にするために、同じ範囲内のポートに対して常にオーバーサブスクライブを引き起こす可能性のあるポートがあれば、それを隔離します。
たとえば、インターフェイスにオーバーサブスクライブを引き起こしているポート 1 に接続されたサーバがある場合は、他のサーバが範囲 2 ～ 8 のポートに接続されているときに、応答が遅延する可能性があります。この場合、ポート 1 ～ 8 の最初のブロックのバッファを空けるために、オーバーサブスクライブ状態にあるサーバをポート 9 に移します。新しいソフトウェア バージョンでは、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. オーバーサブスクライブ状態のポートがないイーサネット モジュールへの移動を検討してください。サポート対象モジュールの詳細は、『Cisco Catalyst 6500 シリーズ スイッチ - 対応インターフェイスとモジュール』を参照してください。
ワークステーションが起動中にネットワークにログインできない、または DHCP アドレスを取得できない
スイッチで実行されているプロトコルによっては、初期接続遅延が引き起こされる場合があります。クライアント マシンの電源投入時やリブート時に次のいずれかの症状が見られる場合は、この問題が起きている可能性があります。
- Microsoft ネットワーキング クライアントで「No Domain Controllers Available」と表示される。
- DHCP で「No DHCP Servers Available」と報告される。
- Novell Internetwork Packet Exchange（IPX）ネットワーキング ワークステーションで、起動時に Novell Login 画面が表示されない。
- 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 ステータスを示す
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 ガード違反
* UDLD 条件
* レイト コリジョンの検出
* リンクフラップの検出
* セキュリティ違反
* Port Aggregation Protocol（PAgP; ポート集約プロトコル）のフラップ
* レイヤ 2 トンネリング プロトコル（L2TP）ガード
* DHCP スヌーピングのレート制限
errdisabled 状態のポートをイネーブルにするには、次の手順を実行します。
1.接続の一端のケーブルを取り外します。
2.インターフェイスを再設定します。
たとえば、Etherchannel の誤設定によりインターフェイスが errdisabled ステートになっている場合は、
その Etherchannel のインターフェイス範囲を再設定します。
3.両端でポートをシャットダウンします。
4.両方のスイッチにケーブルを接続します。
5.インターフェイスで no shutdown コマンドを発行します。
さらに、errdisable recovery cause cause enable コマンドを発行して、
設定されたタイマーの時間が経過した後に、
自動的に再度イネーブルにする、タイムアウト メカニズムを設定することもできます。
注：この問題の根本原因を解決しないと、エラー状態が再発します。
errdisable ステータスの理由を判別するには、show errdisable recovery コマンドを発行します。
cat6knative#show errdisable recovery
ErrDisable Reason Timer Status
----------------- --------------
udld Enabled
bpduguard Enabled
security-violatio Enabled
channel-misconfig Enabled
pagp-flap Enabled
dtp-flap Enabled
link-flap Enabled
l2ptguard Enabled
psecure-violation Enabled
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
Interface Errdisable reason Time left(sec)
--------- ----------------- --------------
Gi4/1 bpduguard 270
rrdisable の原因が判明したら、問題をトラブルシューティングして問題の根源を修復します。たとえば、例で示されているように、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#
<p>さらに、<b>show interfaces <span style="font-weight:normal; font-style:italic">interface-id</span> counters errors</b> コマンドの出力にエラーが表示される場合があります。その場合は、そのインターフェイスに関連するエラーをチェックしてください。『<a href="/JP/support/public/ht/tac/100/1008098/162-j.shtml">Cisco IOS システム ソフトウェアが稼動する Catalyst 6500/6000 での WS-X6348 モジュールのポート接続のトラブルシューティング</a>』の「<a href="/JP/support/public/ht/tac/100/1008098/162-j.shtml#steps"><strong>ステップ 14</strong></a>」を参照してください。</p>
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
一般的な原因とソリューション
- インターフェイスでエラーが表示される原因は、下記のような物理レイヤの問題にある可能性があります。
- 障害のあるケーブルや NIC
- 速度やデュプレックスのミスマッチなどの設定の問題
- オーバーサブスクリプションなどのパフォーマンスの問題
<p>これらの問題を理解してトラブルシューティングするには、『<a href="/JP/support/public/ht/tac/100/1008244/53-j.shtml">トラブルシューティング：スイッチ ポートおよびインターフェイスの問題</a>』を参照してください。</p>
- 場合によっては、ソフトウェアの不具合やハードウェアの制限によりエラー
カウンタが不正確に増分されることがあります。
次の表では、Cisco IOS ソフトウェアが稼動する Catalyst 6500/6000
プラットフォームでのカウンタの既知の問題が挙げられています。
<table bgcolor="#FFFFFF" cellpadding="3" cellspacing="1" border="1" width="60%">
<tr>
<th height="" width="" bgcolor="CCCCFF" colspan="1" rowspan="1">
<p>症状</p>
</th>
<th height="" width="" bgcolor="CCCCFF" colspan="1" rowspan="1">
<p>説明</p>
</th>
<th height="" width="" bgcolor="CCCCFF" colspan="1" rowspan="1">
<p>修正</p>
</th>
</tr>
<tr>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>Supervisor Engine 720 ベースのスイッチの IEEE 802.1Q トランク インターフェイスでのジャイアント</p>
</td>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>Catalyst 6500 シリーズでは、Supervisor Engine 720 のポートを介したトランクで、タグ付きで受信した 1496 バイトを超過するパケット サイズについて、ジャイアントが報告される場合があります。これは、67xx ラインカードでも、問題として現れる場合もあります。この問題は見かけ上のもので、スイッチではそれらのパケットは転送されます。この問題は ISL<sup>1</sup> トランクでも発生します。詳細は、Cisco Bug ID <a target="_blank" href="http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCec62587">CSCec62587</a> <img height="9" width="15" border="0" src="http://www.cisco.com/apps-ui/generic/interim/images/popup_icon.gif" /> （<font size="-1"><a href="http://tools.cisco.com/RPF/register/register.do?locale=ja_JP">登録</a>ユーザ専用</font>）および <a target="_blank" href="http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCed42859">CSCed42859</a> <img height="9" width="15" border="0" src="http://www.cisco.com/apps-ui/generic/interim/images/popup_icon.gif" /> （<font size="-1"><a href="http://tools.cisco.com/RPF/register/register.do?locale=ja_JP">登録</a>ユーザ専用</font>）を参照してください。</p>
</td>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>Cisco IOS ソフトウェア リリース 12.2(17b)SXA 以降 </p>
<p>Cisco IOS ソフトウェア リリース 12.2(18)SXD 以降 </p>
</td>
</tr>
<tr>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>スーパーバイザ エンジン 2 ベースのスイッチでの 802.1Q トランク インターフェイス上のジャイアント</p>
</td>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>スイッチでは、802.1Q トランクでの非ネイティブ VLAN 上の 1497 ～ 1500 の範囲に当てはまるパケットがジャイアントとしてカウントされます。これは見かけ上の問題で、それらのパケットはスイッチにより転送されます。詳細は、Cisco Bug ID <a target="_blank" href="http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdw04642">CSCdw04642</a> <img height="9" width="15" border="0" src="http://www.cisco.com/apps-ui/generic/interim/images/popup_icon.gif" /> （<font size="-1"><a href="http://tools.cisco.com/RPF/register/register.do?locale=ja_JP">登録</a>ユーザ専</font>用）を参照してください。</p>
</td>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>現在のところ、利用可能ではありません。</p>
</td>
</tr>
<tr>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>トラフィックが少ない状態でも、ギガビット インターフェイスでの <b>show interface</b> コマンドの出力で、過度の出力廃棄カウンタが示される。</p>
</td>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>トラフィックが少ない状態でも、ギガビット インターフェイスでの <b>show interface</b> コマンドの出力で、過度の出力廃棄カウンタが示される。詳細は、Cisco Bug ID <a target="_blank" href="http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdv86024">CSCdv86024</a> <img height="9" width="15" border="0" src="http://www.cisco.com/apps-ui/generic/interim/images/popup_icon.gif" /> （<font size="-1"><a href="http://tools.cisco.com/RPF/register/register.do?locale=ja_JP">登録</a>ユーザ専用</font>）を参照してください。</p>
</td>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>Cisco IOS ソフトウェア リリース 12.1(8b)E12 以降 </p>
<p>Cisco IOS ソフトウェア リリース 12.1(11b)E8 以降 </p>
<p>Cisco IOS ソフトウェア リリース 12.1(12c)E1 以降 </p>
<p>Cisco IOS ソフトウェア リリース 12.1(13)E1 以降 </p>
</td>
</tr>
<tr>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>ポート チャネル インターフェイスで、<b>show interface</b> コマンドの出力に、bps<sup>1</sup> と pps<sup>2</sup> に関する不正確な統計情報が示される。
</p>
</td>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>Cisco IOS ソフトウェアを使用していて、2 つのファスト イーサネット ポートにポート チャネルが定義されているときに、そのポート チャネルを経由するトラフィックが生成されると、物理インターフェイスには正確なレート統計情報が示されます。ところが、ポート チャネル インターフェイスには不正確な統計情報が示されます。詳細は、Cisco Bug ID <a target="_blank" href="http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdw23826 ">CSCdw23826</a> <img height="9" width="15" border="0" src="http://www.cisco.com/apps-ui/generic/interim/images/popup_icon.gif" /> （<font size="-1"><a href="http://tools.cisco.com/RPF/register/register.do?locale=ja_JP">登録</a>ユーザ専用</font>）を参照してください。
</p>
</td>
<td height="" width="" bgcolor="FFFFFF" colspan="1" rowspan="1">
<p>Cisco IOS ソフトウェア リリース 12.1(8a)EX </p>
<p>Cisco IOS ソフトウェア リリース 12.1(11b)E1</p>
<p>Cisco IOS ソフトウェア リリース 12.1(13)E1 </p>
</td>
</tr>
</table>
<p>
<sup>1</sup> ISL = Inter-Switch Link（スイッチ間リンク）。</p>
<p>
<sup>2</sup> bps = bits per second（ビット/秒）。</p>
<p>
<sup>3</sup> packets per second（パケット/秒）。</p>
<p>このセクションで紹介されているドキュメントに基づいて検討とトラブルシューティングを行っても問題が解決しない場合は、<a href="http://www.cisco.com/en/US/support/tsd_contact_technical_support.html">シスコのテクニカルサポート</a>にサポートを要請してください。</p>
エラー メッセージ「%PM_SCP-SP-3-GBIC_BAD: GBIC integrity check on port x failed: bad key」が表示される
Cisco IOS ソフトウェア リリース 12.1(13)E よりも前のソフトウェア リリースで稼動している GBIC では、アップグレードを行うと障害が発生します。
Cisco IOS ソフトウェア リリース 12.1(13) システム ソフトウェアでは、不正な GBIC EEPROM のチェックサムを持つ GBIC のポートは up 状態になれません。1000BASE-TX（銅ケーブル接続）と Coarse Wave Division Multiplexer（CWDM）GBIC では、これは想定される動作です。ただし、これは他の GBIC に関しては、正しい動作ではありません。初期のリリースでは、他の GBIC を備えたポートでチェックサム エラーが発生しても、up 状態になることができました。
このエラーが Cisco IOS ソフトウェア リリース 12.1(13)E で発生すると、次のエラー メッセージが表示されます。
%PM_SCP-SP-3-GBIC_BAD: GBIC integrity check on port 1/2 failed: bad key
show interface コマンドを発行すると、次の出力が表示されます。
Router#show interface status
Port Name Status Vlan Duplex Speed Type
Gi2/1 faulty routed full 1000 bad EEPROM
この問題は、Cisco IOS ソフトウェア リリース 12.1(13)E1、12.1(14)E 以降で解決される予定です。
この問題についての詳細は、『Field Notice：Catalyst 6000 の Cisco IOS® ソフトウェア リリース 12.1(13)E での不正な GBIC EEPROM エラー』を参照してください。
WS-X6x48 モジュール インターフェイスで COIL エラー メッセージが表示される
<p>syslog あるいは <b>show log</b> コマンドの出力に、次のエラー メッセージが 1 つまたは複数表示される場合があります。</p>
Coil Pinnacle Header Checksum
Coil Mdtif State Machine Error
Coil Mdtif Packet CRC Error
Coil Pb Rx Underflow Error
Coil Pb Rx Parity Error
<p>WS-X6348 モジュール、またはその他の 10/100 モジュールでホストとの接続に関して接続性の問題があるか、またはこのセクションでリストされているものに類するエラー メッセージが表示されていて、スタック状態でトラフィックが通過できない 12 ポートのグループがある場合には、次の手順を実行します。 </p>
1. インターフェイスを一度ディセーブルにして、再度イネーブルにします。
2. hw-module module module_# reset コマンドを発行して、モジュールをソフト リセットします。
3.モジュールをハード リセットするには、下記の操作を実行します。
-カードを物理的に取り付け直します。
-no power enable module module_# グローバル コンフィギュレーション コマンドと power enable module module_# グローバル コンフィギュレーショ ン コマンドを発行します。
この手順を実行した後で、次のいずれかの問題が発生した場合は、情報を添えてシスコのテクニカルサポートにお問い合せください。
-モジュールがオンラインにならない。
-モジュールはオンラインになるが、12 インターフェイスのグループで診断が失敗する。
-これは、show diagnostic module module_# コマンドの出力に表示されます。
-モジュールが起動しても、other の状態に留まっている。
-モジュールのすべてのポート LED がオレンジになる。
-すべてのインターフェイスが errdisabled ステートになっている。
これは、show interfaces status module module_# コマンドを発行すると表示されます。
トラブルシューティングについての詳細は、『Cisco IOS システム ソフトウェアが稼動する Catalyst 6500/6000 での WS-X6348 モジュールのポート接続のトラブルシューティング』を参照してください。
WS-X6x48 モジュールの接続性問題のトラブルシューティング
WS-X6348 モジュールと他の 10/100 モジュールでホストとの接続に問題がある場合、トラブルシューティングについての詳細は、『Cisco IOS システム ソフトウェアが稼動する Catalyst 6500/6000 での WS-X6348 モジュールのポート接続のトラブルシューティング』を参照してください。
ドキュメント『Cisco IOS システム ソフトウェアが稼動する Catalyst 6500/6000 での WS-X6348 モジュールのポート接続のトラブルシューティング』に基づいて検討とトラブルシューティングを行っても問題が解決しない場合は、シスコのテクニカルサポートにサポートを要請してください。
STP 問題のトラブルシューティング
スパニングツリー関連の問題によって、交換回線ネットワークで接続上の問題が発生することがあります。トラブルシューティングの手順とスパニングツリーの問題を防ぐガイドラインは、『Cisco IOS システム ソフトウェアが稼動する Catalyst スイッチでの STP に関するトラブルシューティング』を参照してください。
telnet コマンドを使用してスイッチに接続できない
原因
Cisco IOS デバイスと同様に、Catalyst 6500 スイッチにおいても、許可される telnet セッションの数は制限されています。この制限に達すると、スイッチではそれ以上の vty セッションは許可されません。この問題が発生しているかどうかを確認するには、スーパーバイザ エンジンのコンソールに接続します。show bootvar コマンドを発行します。このコマンドのコマンドライン インターフェイス（CLI）出力には、次のように、現在占有されている回線の数が示されます。
Cat6500#show user
Line User Host(s) Idle Location
0 con 0 10.48.72.118 00:00:00
1 vty 0 10.48.72.118 00:00:00 10.48.72.118
2 vty 1 10.48.72.118 00:00:00 10.48.72.118
3 vty 2 10.48.72.118 00:00:00 10.48.72.118
4 vty 3 10.48.72.118 00:00:00 10.48.72.118
*5 vty 4 idle 00:00:00 10.48.72.118
ソリューション
次の手順を実行します。
1. show user コマンドの出力に基づいて廃棄されたセッションをクリアするために、clear line line_number コマンドを発行します。
Cat6500#show user
Line User Host(s) Idle Location
0 con 0 10.48.72.118 00:00:00
1 vty 0 10.48.72.118 00:00:00 10.48.72.118
2 vty 1 10.48.72.118 00:00:00 10.48.72.118
3 vty 2 10.48.72.118 00:00:00 10.48.72.118
4 vty 3 10.48.72.118 00:00:00 10.48.72.118
*5 vty 4 idle 00:00:00 10.48.72.118
Cat6500#clear line 1
Cat6500#clear line 2
!--- 出力を省略。
<p>アクティブではないセッションをクリアするために、vty セッションとコンソール回線にアイドル タイムアウトを設定します。次の例には、アイドル タイムアウトを 10 分にセットするための設定が示されています。</p>
Cat6500#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Cat6500(config)#line vty 0 4
Cat6500(config-line)#exec-timeout ?
<0-35791> Timeout in minutes
Cat6500(config-line)#exec-timeout 10 ?
<0-2147483> Timeout in seconds
<cr>
Cat6500(config-line)#exec-timeout 10 0
Cat6500(config-line)#exit
Cat6500(config)#line con 0
Cat6500(config-line)#exec-timeout 10 0
Cat6500(config-line)#exit
Cat6500(config)#
3. 利用可能な vty セッションの数を増やすこともできます。line vty 0 4 の代わりに、
line vty 0 6 コマンドを使用してください。
場合によっては、show user コマンドの出力に、アクティブな vty セッションが 1 つも示されないのに、telnet コマンドを使用してスイッチに接続しようとすると、次のエラー メッセージで失敗することがあります。
% telnet connections not permitted from this terminal
この場合、vty を正しく設定してあることを確認してください。すべてを転送することを vty に許可するには、transport input all コマンドを発行します。
VSL インターフェイスでのジャイアント パケット カウンタ
システムでジャイアント データ パケットが送信されていないにもかかわらず、VSL インターフェイスでジャイアント パケットのカウンタが増加することがあります。
VSL インターフェイスを通過するパケットでは、通常の MAC ヘッダーに加えて 32 バイトの VSL ヘッダーが搬送されます。このヘッダーは理論上はパケット サイズの分類付けからは除外されていますが、実際には、ポートの ASIC ではこのヘッダーを分類付けしています。その結果、正規サイズのパケットの 1518 のサイズ制限に近いサイズの制御パケットが、ジャイアント パケットとして分類される結果となる可能性があります。
現在のところ、この問題の回避策はありません。
モジュールとファンの問題
電源モジュールの INPUT OK LED が点灯しない
電源スイッチをオンにしても、電源モジュールの INPUT OK LED が点灯しない場合は、show power status all コマンドを発行してください。次の例のように、電源モジュールのステータスを調べます。
cat6knative#show power status all
Power-Capacity PS-Fan Output Oper
PS Type Watts A @42V Status Status State
---- ------------------ ------- ------ ------ ------ -----
1 WS-CAC-2500W 2331.00 55.50 OK OK on
2 none
Pwr-Requested Pwr-Allocated Admin Oper
Slot Card-Type Watts A @42V Watts A @42V State State
---- ------------------ ------- ------ ------- ------ ----- -----
1 WS-X6K-S2U-MSFC2 142.38 3.39 142.38 3.39 on on
2 WSSUP1A-2GE 142.38 3.39 142.38 3.39 on on
3 WS-X6516-GBIC 231.00 5.50 231.00 5.50 on on
4 WS-X6516-GBIC 231.00 5.50 231.00 5.50 on on
5 WS-X6500-SFM2 129.78 3.09 129.78 3.09 on on
6 WS-X6502-10GE 226.80 5.40 226.80 5.40 on on
cat6knative#
ステータスがこの例のように OK ではない場合、トラブルシューティングを進めるには、ドキュメント『トラブルシューティング』（Catalyst 6500 シリーズ スイッチ）の「電源モジュールのトラブルシューティング」セクションに示されている手順に従ってください。
エラー メッセージ「C6KPWR-4-POWRDENIED: insufficient power, module in slot [dec] power denied or %C6KPWR-SP-4-POWRDENIED: insufficient power, module in slot [dec] power denied」のトラブルシューティング
ログにこのメッセージが記録されていた場合、モジュールの電源をオンにするのに十分な電力がないことを示しています。メッセージ中の [dec] はスロット番号を示しています。
%OIR-SP-6-REMCARD: Card removed from slot 9, interfaces disabled
C6KPWR-4-POWERDENIED: insufficient power, module in slot 9 power denied
C6KPWR-SP-4-POWERDENIED: insufficient power, module in slot 9 power denied
電源モジュールの冗長性のモードを確認するには、show power コマンドを発行します。
cat6knative#show power
system power redundancy mode = redundant
system power total = 27.460A
system power used = 25.430A
system power available = 2.030A
FRU-type # current admin state oper
power-supply 1 27.460A on on
power-supply 2 27.460A on on
module 1 3.390A on on
module 2 3.390A on on
module 3 5.500A on on
module 5 3.090A on on
module 7 5.030A on on
module 8 5.030A on on
module 9 5.030A on off (FRU-power denied).
この出力には、電源モジュールが冗長性モードであり、1 台の電源モジュールでシャーシ全体に電力供給するには十分ではないことが示されています。次のいずれかの手順を実行できます。
- ワット数が高い電源モジュールを入手する。
たとえば、現在の電源モジュールが 1300W AC の場合は、2500W AC か 4000W AC の電源モジュールを入手します。
- 電源モジュールの冗長性モードを combined にする。
次に例を示します。
cat6knative(config)#power redundancy-mode combined
cat6knative(config)#
%C6KPWR-SP-4-PSCOMBINEDMODE: power supplies set to combined mode.
combined モードでは、両方の電源モジュールから電力が供給されます。ただし、このモードでは、一方の電源モジュールで障害が発生すると、残った電源モジュールだけ ではシャーシ全体への電力供給ができないため、再びモジュールへの電力供給が失われることになります。
そのため、ワット数のより高い電源モジュールを使用することが、よりよい選択肢となります。
空きスロットに予約済みの電力は再割り当てできません。たとえば、スロット 6 が空で、スロット 2 では 68 ワットしか使用できない場合に、スロット 2 で使用できるワット量を増やすために、スロット 6 に予約済みの 282 ワットを、スロット 2 に再割り当てはできません。
各スロットで使用できる電力には制限があり、使用されていない場合であっても、他のスロットに再割り当てすることはできません。空きスロットに予約済みの電力を無効にするコマンドはありません。
注：電源モジュールの電源容量をフルに使用するには、スイッチが 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
!--- 出力を省略。
「Diagnostic level complete」により 6500 でクラッシュが発生する
このエラー メッセージは古い IOS バージョン 12.1 で表示されるもので、このバージョンはすでにサポート終了（EOS）/廃止（EOL）になっています。このエラーを解決するには、診断をデフォルトの最小 に戻すか、デバイスで稼動している IOS を最新バージョンにアップグレードします。
--------------------------------------------------------
Document ID: 24053
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
