Catalyst 4000/4500 シリーズ スイッチ上の Astro/Leman/NiceR タイムアウトの説明とトラブルシューティング

概要

Catalyst 4000/4500 スイッチ シリーズは、スイッチ アーキテクチャでスタブ ASIC 設計を使用しています。スイッチは内部管理制御プロトコルを介して、こうしたラインカード スタブ ASIC（Astro/Leman/NiceR）を管理します。これらの内部管理要求と応答が失われたり遅れたりすると、コンソール メッセージとシスログ メッセージが生成されます。こうした通信損失の原因は多岐にわたるため、このようなエラー メッセージに関する根本原因は明白ではありません。

この文書の目的は Cat4000 プラットフォーム上で生成される Astro/Leman/NiceR タイムアウト エラー メッセージを分かりやすく説明し、Cisco TAC からの支援によりこれらのエラー メッセージを解決することです。CatOSおよびCisco IOS®の今後のバージョンでは、改善されたエラーメッセージが表示されます。可能であれば、問題の根本原因を特定します。

スタブ ASIC（Astro/Leman/NiceR）タイムアウトが発生すると、次のようなメッセージが Catalyst 4000/4500 スイッチ ベースの CatOS で報告されます。

%SYS-4-P2_WARN: 1/Astro(4/3) - timeout occurred
%SYS-4-P2_WARN: 1/Astro(4/3) - timeout is persisting

ソフトウェア バージョンによって、エラー メッセージの表現が異なる場合があります。Astro、Leman および NiceR は、異なるスタブ ASIC タイプを指します。詳細については、この文書の「背景理論」のセクションに記載されています。

Cisco IOS ベースのスーバーバイザ（Supervisor II+、III、IV）の場合、次のようなエラー メッセージが表示されます。

%C4K_LINECARDMGMTPROTOCOL-4-INITIALTIMEOUTWARNING: Astro 5-2(Fa5/9-16) - management 
request timed out. 
%C4K_LINECARDMGMTPROTOCOL-4-ONGOINGTIMEOUTWARNING: Astro 5-2(Fa5/9-16) - consecutive 
management requests timed out.

注：このドキュメントでは、主にCatOSベースのスーパーバイザまたはスイッチのトラブルシューティングについて説明します。その旨が記載されている場合、一部の情報は Cisco IOS ベースのスーパーバイザに適用可能です。

注：このドキュメントではAstroスタブASICについても説明しますが、ほとんどのセクションは他のタイプのスタブASIC（LemanおよびNicer）ラインカードに適用され、適切なセクションで説明します。

この文書を読むと、次の項目が理解できます。

• Catalyst 4000/4500 のスタブ ASIC の機能。

• 内部管理パケット タイムアウト メッセージの発生原因となる条件。

• この状況をトラブルシューティングする場合に、実行するステップおよび Cisco TAC のための情報を収集するコマンド。

Astro のタイムアウトとトラブルシューティングのセクションでは、各問題に関する背景知識と詳細な説明が記述されています。また、この文書の「簡単なトラブルシューティング方法」のセクションに直接ジャンプすることもできます。

はじめに

表記法

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

前提条件

このドキュメントに関しては個別の前提条件はありません。

使用するコンポーネント

この文書の情報は、Catalyst 4000/4500 スーバーバイザまたはスタブ ASIC を使用しているラインカードに固有のものです。

背景理論

Astro スタブ ASIC とは、バックプレーンへのギガビット帯域幅接続を介して、スーパーバイザと通信している 8 つの隣接する 10/100 ポートの 1 グループを制御する 10/100 スタブ ASIC を指します（次図参照）。

スーパーバイザは、SERDES（SERealizer-DESerializer）コンポーネントを介して、ラインカード スタブ ASIC と通信します。バックプレーンに接続されているスーバーバイザ側に SERDES コンポーネントが 1 つあり、バックプレーンと接続するための各スタブ ASIC のラインカード上に、別の SERDES があります。

上記ダイヤグラムは、さまざまなタイプのラインカードをトラブルシューティングするため、一般的に使用できます。タイムアウトメッセージで参照されるスタブASICは、ラインカードのタイプによって異なります。ASIC名とその説明のリストについては、次の表を参照してください。

スタブ ASIC	説明	例
Astro	8 ポート 10/100 コントローラ スタブ ASIC	WS-X4148-RJ45V
NiceR	4 ポート 1000 コントローラ スタブ ASIC	WS-X4418-GB（ポート 3 〜 18）
Leman	8 ポート 10/100/1000 コントローラ スタブ ASIC	WS-X4448-GB-RJ

内部管理トラフィックは、通常データ トラフィックと一緒に、両方の SERDES コンポーネントを通過します。内部管理メッセージ トラフィックは、スタブ ASIC と Phy レジスタの読み書きに使用されます。最も一般的な操作は、リンク状態および統計情報の読み取りです。

簡単なトラブルシューティングの方法

次のセクションでは、%SYS-4-P2_WARNの意味と考えられる原因について説明します。1/(Stub)(module_number/) Stub_reference:Catalyst 4000/4500でtimeout occurredエラーメッセージが表示されます。

10/100 ラインカード上の Astro スタブ ASIC との通信中にスーパーバイザが内部管理制御パケットを喪失したことを表示するため、6.2.3 と 6.3.1 以降のソフトウェア バージョンで Astro（スタブ）タイムアウト メッセージが追加され、その後 6.4.4（CSCea73908）で改善されました。後述のトラブルシューティングのセクションで詳細に説明しているように、この通信喪失には複数の原因があります。

次のトラブルシューティングのフローチャートは、考えられる根本原因の中から、問題をすばやくかつ簡単に切り分けるための方法を示しています。

** 症状は似ていても、根本原因はさまざまに異なっていることがあります。トラブルシューティングの詳細について、TAC に問い合せてください。

スタブ（Astro/Leman/NiceR）ASIC タイムアウト

スーパーバイザ ソフトウェアがラインカード スタブ ASIC からの内部管理応答を複数回受信しない場合、Astro/Leman/Nicer タイムアウトが報告されます。これは次の場合に発生します。

• 管理要求が失われたか、遅れている。

• 管理応答が失われたか、遅れている。

管理パケットの応答を待っている間にソフトウェアが10回連続してタイムアウトすると、「timeout occurred..」メッセージが出力されます。その結果、タイムアウトが発生すると、「consecutive management ....」と出力されます または「。.timeout persisting..」 メッセージが表示されます。

このログ メッセージは、10 分間に 1 回の頻度に制限されます。タイムアウトが発生しても、関連するスタブ ASIC へのパケットの転送は継続されます。ただし、リンク/自動ネゴシエーション速度/ディプレックスは表示されません。これは、ソフトウェアが管理パケット応答を受信していないためです。またタイムアウトが発生すると、インターフェイス グループのトラフィック統計情報の更新プロセスも影響を受けます。

トラブルシューティング

Astro/Leman/NiceR タイムアウト メッセージが表示されるのには、さまざまな原因があります。次に個別に説明します。

原因 1：高いトラフィック負荷、レイヤ 2 ループ、または CPU に対する過度のネットワーク トラフィック

次の原因によって、スタブ タイムアウト状態が発生することがあります。

• ネットワーク障害

• 設定の問題

• 隣接要素

• Catalyst スイッチ以外のその他の問題

レイヤ 2 ループや、高いトラフィック負荷の原因となるブロードキャスト ストームによって、内部管理制御パケットの喪失が発生することがあります。これは通常、CPU がビジー状態（CPU Hog）で、CPU のキューを処理できないために発生します。

内部管理制御トラフィックは、Astro（または他の任意のスタブ チップ）からの通常のデータ トラフィックと同じデータ パスを通ってスーパーバイザへ到達します。 このため、制御パケットは輻輳が原因で失われることがあります。

Cisco Bug ID CSCea73908（登録ユーザ）の修正プログラムを使うと、CatOS バージョン 6.4(4) 以降で、内部管理要求タイムアウト期間の処理が向上します。この改善によって、ビジー状態の CPU が原因で発生する、一時的な制御パケット タイムアウトの多くを防止できます。

Action:レイヤ2ループのトラブルシューティングまたは設定を変更してトラフィックパターンを解決します。

回避策：スイッチ管理インターフェイス（sc0）を、CatOS ベース スイッチ上の非ユーザ トラフィック VLAN に移動します。set interface sc0 <vlan-id>コマンドを使用して、インターフェイスsc0のvlanを移動します。

注：Cisco IOS 12.1(20)EW以降、Cisco IOSベースのスーパーバイザでは、CPUによる内部管理パケット処理メカニズムの処理が強化されています。この改善により、優先度の低い不慮のトラフィックが CPU を占有することによる、内部管理制御パケットの喪失が防止されます。

ソリューション：前述の回避策を参照してください。

原因 2：半二重/ タイプ 1A ケーブル接続

フロント パネルのユーザ ポートは、半二重に設定されています。スタブ ASIC での発信トラフィックと着信トラフィックの衝突により、スタブ バッファの処理が非常に遅くなることがあります。これによりスーバーバイザの tx キューがいっぱいになり、場合によって新しい内部管理要求がドロップされるため、タイムアウト エラー メッセージが表示されます。

タイプ 1A ケーブル配線を使ったネットワークでも、この問題が発生することがあります。RJ-45 パッチを使ってタイプ 1A バランに接続されているワークステーションが接続を解除されると、バランの内部でループバックが発生し、発信トラフィックが戻ってきます。この状況は、フロントパネル ポートでの外部ループバックの接続をシミュレートしています。ポートがブロック状態に移行する前に、発信トラフィックがスイッチにループバックします。この状態が発生すると、トラフィック レートによってはスタブ バッファがオーバーフローすることがあります。

Action:回避策を参照してください。

回避策：半二重設定をしないでください。タイプ 1A ケーブル接続の場合、バラン内での内部ループバックが形成されないようにするため、タイプ 1A バランからの RJ-45 パッチ コードを外さないようにしてください。

ソリューション：回避策を参照してください。

原因 3：SERDES コマンド障害コンポーネント障害

エラーが一つのモジュールのAstro（または他のスタブASIC）上にのみ表示され、レイヤ2ループが発生しない場合、問題はおそらくスーパーバイザまたはラインカードのSERDESコンポーネントに障害が発生しています。たとえば、次に示すように、エラーメッセージが常にモジュール3のAstro 4にある場合、モジュール3のSERDESコンポーネントまたはスーパーバイザのSERDESコンポーネントに障害があります。

%SYS-4-P2_WARN: 1/Astro(3/4) – timeout occurred

上記のエラーメッセージでは、カッコ内の番号「4」は実際のポート3/4ではなくAstro番号を示します。この番号は、モジュール3の4番目のAstroであるため、8つのポート(3/33-3/40)のグループを参照します。

SERDES コンポーネントに障害があると、Astro/Leman/NiceR への制御トラフィックやデータ トラフィックで断続的な寸断が発生することがあり、その結果、タイムアウトが発生します。ただし SERDES に障害があると、エラー メッセージは通常、継続的に表示されます。

Action:どの（スーパーバイザまたはラインカードの）SERDES に障害があるか突き止めるため、次のステップを実行します。

1. ラインカードをシャーシまたは別のシャーシの予備スロットに移動させます。空のスロットが使用できる場合、動作が確認されているモジュールとスロットを交換します。

2. 新しいスロットに挿入した同じ Astro/Leman/NiceR でも、Astro/Leman/NiceR タイムアウトが発生する場合、最も考えられる原因は、ラインカードの SERDES または Astro/Leman/NiceR の障害です。この場合ラインカードを交換する必要があります。

   注：スペアスロットにモジュールを再挿入すると、ラインカードでオンライン診断が実行されます。障害のあるSERDESまたはAstro/Leman/Nicerが見つかった場合、スイッチはそのポートをfaultyとしてマークします。

3. 元のラインカードの Astro/Leman/NiceR でタイムアウトが継続しない場合、スーパーバイザの SERDES に障害があると考えられます。このことを検証するには、動作が確認されているモジュールを元のスロットに挿入し、新しいモジュールでタイムアウトが発生するか確認することです。

   正常に動作する場合、スーパーバイザの SERDES に障害がある可能性が高くなります。障害のある SERDES コンポーネントの該当するシリアル番号のリストについては、Field Notice『Catalyst 4000/4500 WS-X4013で部分的な接続断が発生』を参照してください。

回避策：なし

ソリューション：トラブルシューティングの詳細については、TAC に問い合せてください。

原因 4：一時的/恒常的 SRAM 障害

Supervisor I、II、III または IV エンジンを搭載している Catalyst 4000、または Catalyst 2948G や Cat2980G に接続されているデバイスでは、ネットワーク接続の一時的または完全な切断が発生することがあります。一部またはすべてのポートが該当します。こうした症状には、CatOS ベースのスーパーバイザ上での無効な CRC ドロップ パケットと、スタブ ASIC タイムアウト エラー メッセージの急増が伴います。

この問題の原因は Packet Buffer Memory（SRAM; パケット バッファ メモリ）障害で、恒久的タイプまたは一時的タイプのいずれかのタイプです。

Action:次の 2 つの一時的パケット バッファ メモリ障害シグニチャのいずれであるかに応じて、操作を選択します。

1. SUP I、SUP II、2948G または 2980G に対する一時的パケット バッファ メモリ障害のシグニチャ

   この問題の症状を次に示します。

   • InvalidPktBufferCRCは、次のようなメッセージで急速に増加します

     %SYS-4-P2_WARN: 1/Invalid crc, dropped packet, count = xxxx

   • reset コマンドを使ってソフト リセットを実行すると、スーパーバイザは POST で障害を起こします。

   • ハード リセット（電源のオン→オフ）を実行すると、スーパーバイザは POST をパスし、障害が発生しなくなります。

   注：スーパーバイザI、II、2948G、2980Gのハードパケットバッファメモリ障害の場合、ハードリセットでは問題が解決せず、スーパーバイザまたはスイッチではPOSTが失敗します。

   この問題の詳細については、スーパーバイザ II の Cisco Bug ID CSCdy46288（登録ユーザのみ）、スーパーバイザ I/2948G/2980G の Cisco Bug ID CSCeb56266（登録ユーザのみ）、および WS-C2980G-A の Cisco Bug ID CSCeb56325（登録ユーザのみ）を参照してください。

2. Transient Packet Buffer Memory Failure Signature for SUP III または SUP IV に対する一時パケット バッファ メモリ障害のシグニチャ

   この問題の症状を次に示します。

   • VlanZeroBadCrc カウンタが急増し、次のコマンド出力に表示されます。

     show platform cpuport all (prior to 12.1(11b)EW1 ) 
     or  show platform cpu packet statistics all (Since 12.1(11b)EW1) 
     depending upon the software version. Starting from 12.1(19)EW, 
     you should also see the following error message rapidly incrementing errors: 
     
     %C4K_SWITCHINGENGINEMAN-2-PACKETMEMORYERROR3: Persistent Errors in 
     Packet Memory xxxx
     

   • ソフト リセットを実行すると、スーパーバイザの POST で障害が発生します。show diagnostics power-on コマンドを使って、障害を確認します。

   • ハード リセット（電源のオフ→オン）を実行するとスーパーバイザが復旧し、POST をパスします。

   注：スーパーバイザIII/IVのハードSRAM障害の場合、ハードリセットではスーパーバイザが回復せず、POSTは失敗します。

   Supervisor III/IV のこの問題の詳細は、Cisco Bug ID CSCdz57255（登録ユーザのみ）を参照してください。

回避策：一時的 SRAM 障害の場合、スイッチの電源オフ→オンまたはハード リセットを実行します。恒久的 SRAM 障害には回避策はありません。

ソリューション：トラブルシューティングの詳細については、TAC に問い合せてください。

原因 5：監視クロック障害

複数のモジュール番号または複数の Astro/Leman/NiceR を参照する Astro/Leman/NiceR タイムアウト エラー メッセージが表示される場合、スーパーバイザ上のクロック障害が考えられる場合があります。一般的にクロック障害には、Astro/Leman/NiceR タイムアウト エラー メッセージと、次に示すような BlockTXQueue および BlockedGigaport エラー メッセージが付随します。

%SYS-4-P2_WARN: 1/Blocked queue on gigaport ...

Action:詳細なトラブルシューティングについては、Cisco Bug ID CSCdp89537（登録ユーザのみ）と CSCdp93187（登録ユーザのみ）を参照し、TAC に問い合せてください。

回避策：なし

ソリューション：トラブルシューティングの詳細については、TAC に問い合せてください。

原因 6：短時間の電源遮断

スーパーバイザ II（WS-X4013）を搭載した Catalyst 4000 シリーズでは、スーパーバイザとラインカードが相互に正常な通信ができない状態に陥ることがあります。スイッチがこの状態に陥ると、モジュール ステータス LED が赤になり（点滅はしない）、モジュールやスイッチのリセットと同じように、ポート LED が順次点滅します。また、Astro/Leman/NiceR タイムアウト メッセージも表示されます。

この問題は、スイッチの電源の一時的な遮断（500 ミリ秒未満）によって発生します。 一時的な電源遮断は、実稼働環境における不安定な電源供給に起因することがあります。

Action:次の回避策を参照してください。

回避策：スイッチをリセット(ソフトまたはハード（電源のオフ/オン）)します。

ソリューション：Cisco Bug ID CSCea14710（登録ユーザのみ）の修正プログラム、またはそれ以降のリリースを使って、ソフトウェア イメージをアップグレードします。

関連情報

• 「Common CatOS Error Messages on Catalyst 4000 Series Switches（Catalyst 4000 シリーズ スイッチでの一般的な CatOS エラー メッセージ）」
• Catalyst 4000/4912G/2980G/2948G シリーズ スイッチのハードウェア トラブルシューティング
• トラブルシューティング：スーパーバイザ III および IV を搭載した Catalyst 4000 および 4500 のハードウェアおよび関連問題
• Catalyst 4000/4500 シリーズ スイッチのサポート ページ
• LAN スイッチング テクノロジーに関するサポート ページ
• Catalyst LAN スイッチおよび ATM スイッチの製品サポート
• テクニカル サポートとドキュメント – Cisco Systems