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

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

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


目次


概要

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 を指します(次図参照)。

http://www.cisco.com/c/dam/en/us/support/docs/switches/catalyst-4000-series-switches/45640-astroe5.gif

スーパーバイザは、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 の発生しました。

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

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

http://www.cisco.com/c/dam/en/us/support/docs/switches/catalyst-4000-series-switches/45640-astroe8.gif

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

スタブ(Astro/Leman/NiceR)ASIC タイムアウト

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

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

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

「タイムアウトは発生しました…」 メッセージは管理パケット応答を待っている間ソフトウェアが 10 の連続した回を時間を計ったら印刷されます。 必然的なタイムアウトは印刷という結果に終ります「連続した管理….」または「。持続する .timeout」。 ソフトウェアのバージョンによるメッセージ。

このログ メッセージは、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 が原因で発生する、一時的な制御パケット タイムアウトの多くを防止できます。

アクション: レイヤ2 ループを解決して下さい; またはトラフィックパターンを解決する変更設定。

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

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

解決策: 前述の回避策を参照してください。

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

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

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

アクション: 回避策を参照してください。

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

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

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

エラーが 1 モジュールの 1 Astro (か他のスタブ ASIC)でだけ見られ、レイヤ2 ループが発生しなければ場合、問題は可能性が高いですスーパバイザまたはラインカードの不良な SERDES コンポーネント。 たとえばエラーメッセージが下記に示されているようにモジュール 3 の常時接続 Astro 4 なら、そしてモジュール 3 の SERDES コンポーネントかスーパバイザの SERDES コンポーネントは不良です。

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

上記のエラーメッセージでは、かっこ内の第 "4" は Astro #、およびない実際のポート 3/4 を示します。 この数はそれがモジュール 3.の第 4 Astro であるので、8 つのポートのグループ(3/33-3/40)を参照します。

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

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

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

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

    予備スロットのモジュールの再挿入によって、オンライン診断はラインカードで実行された。 不良な SERDES か Astro/ルマン/より素晴らしいのある場合、スイッチは不良ようにポートを示します。

  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; パケット バッファ メモリ)障害で、恒久的タイプまたは一時的タイプのいずれかのタイプです。

アクション: 次の 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 をパスします。

    Supervisor 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 ...

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

回避策: なし

解決策: トラブルシューティングの詳細については、TAC に問い合せてください。

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

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

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

アクション: 次の回避策を参照してください。

回避策: リセット(ソフトかハード(パワーサイクル)) スイッチ。

解決策: Cisco Bug ID CSCea14710登録ユーザのみ)の修正プログラム、またはそれ以降のリリースを使って、ソフトウェア イメージをアップグレードします。


関連情報


Document ID: 45640