読み込み 3650/3850 のシステムによってスタック マネージャによってトラブルシューティング報告して下さい

 

概要

クラッシュがない時のシステム レポートによるトラブルシューティング スタック読み込みは stackwise テクノロジーを使用して NGWC スイッチング プラットフォームで一般に行われます。 現在のドキュメントはシステム レポートの使用で制限され、一般的に問題のスタックと見つけられる問題を診断するのにどのようにこれらのレポートを活用できるか説明するためにこのガイドは書かれています。 このガイドは機能のスタッキングをサポートする IOS XE を実行する Catalyst 3650/3850 スイッチングアーキテクチャのために特に連動になります。

スタック内のメンバー間の通信上の問題からの stackwise テクノロジー茎においての問題の大半。 メンバーまたは接続切断間の情報のどの不整合でも最終的にスタック マネージャとのリセットに導く全体のスタックに浸透する問題という結果に終る場合があります。 この資料は診断するいくつかのシステム レポートのスタック マネージャ読み込みと、使用、および利用可能 な関連した CLI および問題の異なる型見られた失敗のよくある タイプを強調表示したものです。

バックグラウンド情報:

システム レポート vs スイッチ レポート

システム レポートはスタックの状態をどのようにからの感知するかメンバーの広範囲のレポートです。 これは（それ以上のデバッグのためのメモリをダンプする） crashinfo、代りに、です開発がそのサービスの状態をトラッキングすることができるように役立つ IOS XE の下で実行するさまざまなサービスのためのログおよびデバッグ情報があるレポートではないですが。 システム レポートはユーザによってスイッチがスタック マネージャによってリロードされるとき生成されて、プロセス クラッシュ発生しました、またはライブ オペレーションの間に手動で生成することができます。

 

多くの場合、単一 の スイッチがスタックで壊れるかもしれないメンバーの他がそのまま残すかもしれない状況があります。 所定の時間にスタックの状態の情報として収集するために、switch_reports はメンバーはダウン状態になったこと検出するとき残りのメンバーが 1 つを生成するようにもたらされました。 switch_report はそのメンバーがスタックの現在のステートをどのようにの感知するかローカル レポートです。

 

注: これらのレポートは書かれ、圧縮されます従って「もっと」を使用してターミナルに印刷することができません。 それらはスイッチを離れて転送され、ログを調べるために復元される必要があります。

 

システム/スイッチ レポートをどこで収集するか

システム レポートは crashinfo に一般的に書かれます: そのスタックのメンバーのディレクトリ。 たとえば x メンバー スイッチ スタックがあれば、そして各スイッチに「x」がスタック内のそのメンバーに対応するところに「ディレクトリ crashinfox」を使用してアクセス可能である場合もある自身の crashinfo ディレクトリがあります。

 

3850#dir crashinfo-1:

crashinfo のディレクトリ: /    

11 - rwx 14 年 8 月 355 日 2015 07:48:17 -04:00 last_systemreport_log  

12 - rwx 15 年 10 月 724015 日 2014 07:14:32 -04:00 system-report_1_20141015-111342-UTC.gz

 

3850#dir crashinfo-2:

crashinfo-2:/ のディレクトリ   

11 - rwx 14 年 8 月 357 日 2015 07:50:49 -04:00 last_systemreport_log  

12 - rwx 15 年 10 月 751340 日 2014 06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz

 

注: 「ディレクトリ crashinfox のための出力を収集することを忘れないでいて下さい: 」そのスタックの各スイッチのために「show tech が」利用可能 な ファイル システムか crashinfo ファイルをリストしないので。 そのスタックで各メンバーの全体のピクチャがあることは重要です。 アップデート: より新しい IOS XE リリース >3.6E 現在で、show tech は"ディレクトリ crashinfo を反映します: 「+ 「show file systems」出力。 CSCun50428 を参照して下さい 。

 

システム レポートの興味深いセクション

TAC 観点から、これらはいくつかの特定の問題のイベントの診断を助けることができるシステム レポート内の一般には表示されたエントリです。 開発が検討したいと思うと見つけるかもしれないことここにに含まれているその他のサービスから他のログがあります。

 

ログファイル: /mnt/pss/sup_sysmgr_reset.log

これはリセットがなぜ見られたか短い出力へ非常に総称的に理解しますです。 検知 するために失敗セクションの下記の型がこれらの原因がどのようにの変わるか意味およびコンテキストを表示されて下さい。

 

ログファイル: IOS

これは IOSd 内から維持されるログ バッファです。 IOSd の内で生成されたユーザか syslog によって発行されたどのコマンドでもこのセクションで見つけられます。 最新ログはこの出力の端の方にあります。

 

トレース バッファ: スタック mgr イベント

スタックから取除かれる他のメンバーが/加入のまたはスタック ポートがメッセージ入るとき含んでいるスタック マネージャから参照されるイベントを把握します。

               

トレース バッファ: redundancy-timer-ha_mgr

スタックのスイッチ間のキープ アライブ イベントを表示する。 タイムスタンプは通信の内訳が開始したときに判別を助けることができます。

 

失敗の型

このセクションはスタック マネージャプロセスによって一般的に呼び出されるシステム レポートからのいくつかのよく見られるリセットを強調表示します。 スタックのメンバーを管理し、スタックのスイッチ間のロールの変更を監督するスタック マネージャは Linux プロセスです。 スタック マネージャが初期化か選択ロールのの間に問題を検出する場合、スタックのために個々のスイッチにリセットするリロード場合を送ります。 の下でまたそれぞれ故障形に関連付けられた既知の不具合をリストします。

 

注： ソフトウェア側の問題にすべてのスタック マネージャ読み込みが帰因しません。 実際、それはよりよくあります根本的なハードウェア上の問題にセカンダリ/対象問題として明らかなこれらの問題を見るために。

 

Reset Reason: 要求されるリセット/リロード[スタック マネージャ]。 [ISSU 非互換性]

スタックのすべてのメンバー間のマスターの設定を同期することを試みている間バルク同期化失敗があるときリセットのこの型が表示されるかもしれません。 ログファイルのチェック: アクティブなスイッチからの IOS かログはこのリセットに貢献したコンフィギュレーションを強調表示するかもしれません。

Reset Reason: サービス[iosd] pid: [xyz]異常に終えられた [11]。

見られるこれ時 IOSd プロセスの switch crash。 crashinfo ファイル + コアダンプのための crashinfo ディレクトリを検知 することがこの失敗を更にデバッグするのに使用することができます。

 

hap_sup_reset: Reset Reason: 要求されるリセット/リロード[スタック マネージャ]。 [スタック マージ]

スタック マージはそれらはスタック マスターであることを信じる 2つ以上のスイッチがあるとき見られます。 これはときそこにであるスタックのリングの中断見られる場合があります（すなわち 2 つのケーブルはスタックから切断されています）従ってアクティブおよびスタンバイは両方他のメンバーに通信を切断します。 スタックに 2 つのアクティブなスイッチがあるので既存のスタックへの既に電源スイッチの付加によりスタック マージを引き起こす場合があります。

 

CSCuh58098 -スタック ケーブル接続 に 関する 問題がある時 3850 スタックはリロードするかもしれません

CSCui56058 -スタック ケーブルのための debounce ロジックを有効に すること

CSCup53338 - 3850 IOSD クラッシュ |　 Signal=SIGSEGV(11) @ pm_port_data_from_swidb

 

hap_sup_reset: 原因 Code:[4] リセット理由: リセット/Reloadrequested による[スタック マネージャ]。 [非互換性によるスタック マージ]

これは状況で時スタックで存在 する アクティブおよびスタンバイ スイッチ見られました。 アクティブなスイッチがスタンバイに通信を切断する場合、スタンバイはアクティブがまだあるのにアクティブとして引き継ぐように試みます。

 

CSCuo49555 /CSCup58016 -ユニキャストによるクラッシュ 3850/3650 は mgmt ポートであふれます

CSCur07909 -アクティブおよびスタンバイ失われた接続によるマージをスタックして下さい

 

 

Reset Reason: 要求されるリセット/リロード[スタック マネージャ]。 [ASIC 投票用紙の後で見つけられる間違ったネイバー]

スイッチはブートの間に ASIC 投票用紙に確認しますまでスタック内の近接のスイッチを加わります。 このリセットはネイバーがそれ自身を宣言することができるまたは論理エラーが nbrcast メッセージ交換の間にあればようにときタイマーが切れる見られる場合があります。 これは置換を通して解決された不良なスタック ケーブルのコンテキストで見られました。

 

CSCun60777 - ASIC 投票用紙の後で見つけられる間違ったネイバーがリロードされた原因で切り替えて下さい

CSCud93761 - ASIC 投票用紙の後で見つけられる間違ったネイバーがリロードされた原因で切り替えて下さい

 

 

 

hap_sup_reset: 原因 Code:[4] リセット理由: 要求されるリセット/リロード[スタック マネージャ]。 [失われたアクティブおよびスタンバイ両方]

にアクティブまたはスタンバイ ロールではないこれはスタックのメンバーから一般的に見られます。 アクティブが失敗する場合、スタックのためのアクティブな役割を担うスタンバイ スイッチがない場合全体のスタックはリセットします。 スタックが不安定状態であるかまたは冗長性がポリシーまだ同期しなかったら、これは見られる場合があります。 これはアクティブ/スタンバイ な スイッチが冗長性が正しく同期していない示す値なぜまたは可能性としては行ったか本当らしいですの対象。 これはまたスタックが半リング セットアップで設定されるときで見られる場合があります。

 

CSCup53882 - 3850 スタック 再度ブートするのメンバースイッチ- [失われたアクティブおよびスタンバイ両方]

 

hap_sup_reset: 原因 Code:[1] リセット理由: 要求されるリセット/リロード[スタック マネージャ]。 [Keepalive_Timeout]

キープ アライブ メッセージがスタックのスイッチから届かない時見られる。 「トレース バッファを検知 すること: redundancy-timer-ha_mgr は」通信の内訳が始まったときにキープ アライブ メッセージの交換を示し、時間の観点をの提供する必要があります。 スイッチを収集することはスタックおよびログを検知 することの他からフレームがここに助けるかもしれない時報告します。

 

 

hap_sup_reset: Reset Reason: 要求されるリセット/リロード[スタック マネージャ]。 [Reload コマンド]

これはかなり直観的なリセット理由です–スタック マネージャが CLI によってまたは外部に 管理 デバイス（SNMP）で呼び出すことができるリロード 要求を受け取るときこれは見られます。 CSCuj17317 のケースでは 、これはまた「reload コマンドが」また発行したように出て来ます。 ログファイルから: 次のように表示できる IOS:

 

CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr:  Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr:  Reloading due to reason Reload command

 

関連したバグ

CSCur76872 -スタック マネージャはシステムが SDP バッファを使い果たすときの下で行きます。

CSCup49704 は - 3850 連邦機関クラッシュ-待っている SPI チャネリングします FED_SPI_FLCD を、FED_SPI_FAST は…

 

 

 

潜在的なスタック ケーブル接続の/ポート問題診断

現象は 1） スタック ケーブル接続 に 関する 問題のあらゆるサイン リセット前にスタック ポートのあらゆるフラッピングによって明白です。 「ログファイルを検知 すること: IOS」リセット前のレポートは一般的に開始するべき適切な場所です。 電流 SW2 およびスタンバイ SW1 両方で登録されているスタック ポートのフラッピングをどこにの見るか例はここにあります。 この同じスタック ポートはリセットの各例でそれぞれフラップして、スタック ケーブルの交換によって解決されました:

 

=====================  log file: IOS  =====================
.
.
Aug  8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is down  (SW1-1)
Aug  8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is up  (SW1-1)
Aug  8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr:  Switch 1 has been removed from the stack.
Aug  8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1

 

stackwise セットアップによる現象は 2） （180、480、と）、ポート ASIC ごとの伝達リングの数変わります使用されます。 これらのコマンドは何読み込みエラーが各伝達 リングについては見られるかの累計を維持するグローバル な登録をポーリングします。 「ポート ASIC 0'スタック ポート 1 に対応し、「はポート ASIC 1'はスタック ポート 2.に対応します。 これは各スイッチのために発行する必要があり、数を増分することのどのサインでもポートでまたはスタック ケーブルとかどうかそこに多分問題隔離できます。

 

 

 

 

これらは数回数の差分を比較する数分にわたる集めることができます:

 

プラットフォーム ポート ASIC <0-1> によって読まれるレジスタ SifRacDataCrcErrorCnt スイッチ <switch#> を示して下さい

• データ CRCエラーとセグメント化して下さい

プラットフォーム ポート ASIC <0-1> によって読まれるレジスタ SifRacRwCrcErrorCnt スイッチ <switch#> を示して下さい

• 壊れる CRC チェックで増分される

プラットフォーム ポート ASIC <0-1> によって読まれるレジスタ SifRacPcsCodeWordErrorCnt スイッチ <switch#> を示して下さい

• 、未知 PC コードワードは無効 な PC コードで増分されて、実行ディスパリティ エラー 検出する

プラットフォーム ポート ASIC <0-1> によって読まれるレジスタ SifRacInvalidRingWordCnt スイッチ <switch#> を示して下さい

• スタックのビットエラーにより ringword CRCエラーを引き起こしました

 

 

以下はフラッピング スタック ポートのサインなしで 2 メンバー スタックの両方のメンバー参照されたスタック マージ イベントがあったところに例です。 ring[0] がこの問題を通り越すためにスタック ケーブルの交換の上で終了されてスイッチ 1 のスタック port-1 の CRC と増分することを見。

 

3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015
 
For asic 0
 
SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x00000031 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001
                               
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015
 
For asic 0
 
SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x000000c9 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001

 

注： レジスタによっては検知 されて いる、各ケースで別の多分マスク。 上の例では、マスクは最後の 14 ビットでラップします。 従って、カウンターは 0x00003FFF に達する場合、0x00000000 に戻ってラップします。

 

追加助言

1. Crashinfo ディレクトリのアーカイブ

スタックのより多くのスイッチは集められるべき More レポート ファイルがあることを意味します。 生成されるレポートの数圧倒されて得ることは容易です。 組織は失敗を切り離すことに重要です。 各スイッチがもし可能ならある特定の事件のためにレポートファイルを書いたときにタイムスタンプを使用して一貫性をの見つけて下さい。 そこにから、それらのある特定のスイッチからのそれらの極めて特殊なレポートを頼んで下さいそうすれば顧客は複数のファイルをアップロードしません。 crashinfo ディレクトリはまたアーカイブすることができます従って顧客は興味があるレポートが含まれている単一 アーカイブを送信 することができます。 以下はフラッシュディレクトリで「crashinfoarchive.tar」と指名されたアーカイブを作成します:

 

F340.03.10-3800-1#archive tar /create ?
 WORD Tar filename

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
 WORD Dir to archive files from

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
 WORD File or Dir
 <cr>

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:

 

 

2. 不安定なスタックの回復

スタック 選択プロセスが起こった後の間に起動するためにリロードするスタックの何人かメンバーに会ういくつかの状況があるかもしれません。 リロードされたスイッチがスタック マスターであるとそれ自身が信じればこれは頻繁にスタック マージ イベントの原因となる場合があり、ためにブート ループに状態を入力して下さい。 この場合、顧客に依頼することは賢明であるかもしれません:

-全体のスタックの電源を切り、すべてのスタック ケーブルをしっかりと再置して下さい。

-すべてのメンバーが期待された状態にコンバージするまでスタックの各メンバースイッチに一つずつ電源を投入して下さい。

-スタックに加入し、これをスタックから取除き、スタンドアロンとしてこのユーザーを起動することを試みなければメンバーが更に解決するために。

 

3. システム レポートを手動で生成して下さい

手動で システム レポートを作成することは「service internal」が有効に なるように要求します。 これはスイッチ基礎ごとにすることができるテキストファイルとしてシステム レポートを書きます。

 

 

3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit

3800-1#resource create_system_report ?
 WORD system report filename

3800-1#resource create_system_report sysreport.txt ?
 switch Switch number
 <cr>

3800-1#resource create_system_report sysreport.txt switch ?
 <1-1> Switch number

3800-1#resource create_system_report sysreport.txt switch 1 ?
 <cr>