システムレポートによるスタックマネージャによる3650/3850のリロードのトラブルシューティング
目次
はじめに
クラッシュがない場合のシステムレポートによるスタックのリロードのトラブルシューティングは、通常、stackwiseテクノロジーを使用してNGWCスイッチングプラットフォームで行われます。現在のドキュメントは、システムレポートの使用に限定されています。このガイドでは、スタックの問題に通常見られる問題を診断するためにこれらのレポートを活用する方法について説明します。このガイドは、スタック機能をサポートするIOS-XEを実行するCatalyst 3650/3850スイッチングアーキテクチャを対象としています。
stackwiseテクノロジーの問題の大部分は、スタック内のメンバ間の通信の問題によるものです。メンバー間の情報の不一致や接続の喪失が発生すると、最終的にスタック全体に浸透してスタックマネージャによるリセットが発生する可能性があります。このドキュメントでは、スタックマネージャのリロード、システムレポートの使用、および診断に使用できる関連するCLI、さまざまなタイプの問題で発生する一般的なタイプの障害について説明します。
背景説明:
システムレポートとスイッチレポート
システムレポートは、メンバがスタックの状態をどのように認識しているかについての包括的なレポートです。これはcrashinfoではなく、IOS-XEで実行されるさまざまなサービスのログとデバッグ情報を含むレポートで、そのサービスの状態を追跡する開発に役立ちます。スタックマネージャによってスイッチがリロードされたとき、プロセスクラッシュが発生したとき、またはユーザがライブオペレーション中に手動で生成したときに、システムレポートを生成できます。
多くの場合、スタック内の1台のスイッチで障害が発生しても、残りのメンバはそのままの状態のままである可能性があります。特定の時点でのスタックの状態に関する情報として収集するために、switch_reportsが導入され、メンバーがダウンしたことを検出すると残りのメンバーが生成されるようになりました。switch_reportは、そのメンバがスタックの現在の状態をどのように認識するかを示すローカルレポートです。
システム/スイッチレポートの収集場所
システムレポートは通常、crashinfo:ディレクトリを指定します。たとえば、xメンバのスイッチスタックがある場合、各スイッチには独自のcrashinfoディレクトリがあり、"dir crashinfo-x"を使用してアクセスできます。'x'はスタック内のメンバに対応します。
3850#dir crashinfo-1:
crashinfoのディレクトリ：/
11 -rwx 355 Aug 14 2015 07:48:17 -04:00 last_systemreport_log
12 -rwx 724015 Oct 15 2014 07:14:32 -04:00 system-report_1_20141015-11342-UTC.gz
3850#dir crashinfo-2:
crashinfo-2のディレクトリ：/
11 -rwx 357 Aug 14 2015 07:50:49 -04:00 last_systemreport_log
12 -rwx 751340 Oct 15 2014 06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz
システムレポートの対象セクション
TACの観点から見ると、これらはシステムレポート内で一般的に表示されるエントリの一部であり、特定の問題のイベントの診断に役立ちます。他のサービスからのログが他にもあります。このログには、開発がレビューを希望する可能性があります。
ログファイル：/mnt/pss/sup_sysmgr_reset.log
これは、リセットが発生した理由を一般的に理解するための短い出力です。これらの原因の違いについては、次のタイプの失敗のセクションを参照して、その意味とコンテキストを調べてください。
ログファイル：IOS
これは、IOSd内から維持されるログバッファです。IOSd内で生成されたユーザまたはsyslogによって発行されたコマンドは、このセクションに記載されています。最近のログは、この出力の終わりに近づいています。
トレースバッファ：stack-mgr-events
スタックマネージャから表示されるイベントを追跡します。スタックマネージャには、他のメンバがスタックに参加/削除されるタイミングや、メッセージが通過するスタックポートが含まれます。
トレースバッファ：redundancy-timer-ha_mgr
スタック内のスイッチ間のキープアライブイベントを表示します。タイムスタンプは、通信のブレークダウンがいつ開始されたかを判断するのに役立ちます。
障害のタイプ
このセクションでは、通常スタックマネージャプロセスによって呼び出されるシステムレポートから発生する一般的なリセットについて説明します。スタックマネージャは、スタック内のメンバを管理し、スタック内のスイッチ間のロールの変更を監視するLinuxプロセスです。初期化またはロール選択中にスタックマネージャが問題を検出すると、スタックをリセットするために個々のスイッチにリロード信号を送信します。また、それぞれの障害タイプに関連付けられている既知のバグも示します。
注：すべてのスタックマネージャのリロードがソフトウェアの問題に起因するわけではありません。実際、これらの問題は、基盤となるハードウェアの問題に対する二次的な問題または被害者的な問題として現れることがよくあります。
リセット理由：[stack-manager]によってリセット/リロードが要求されました。[ISSU非互換性]
スタック内のすべてのメンバ間でアクティブ上の設定を同期しようとしたときに一括同期エラーが発生すると、このタイプのリセットが表示される場合があります。ログファイルを確認しています：IOSまたはアクティブスイッチからのログにより、このリセットに影響を与えた設定が強調表示される場合があります。
リセット理由：サービス[iosd] pid:[xyz]が異常終了[11]。
これは、スイッチがIOSdプロセスでクラッシュしたときに表示されます。crashinfoディレクトリでcrashinfoファイル+コアダンプを探すと、この障害をさらにデバッグできます。
hap_sup_reset:リセット理由：[stack-manager]によってリセット/リロードが要求されました。[スタックのマージ]
スタックのマージは、スタックのアクティブスイッチであると考えられるスイッチが2つ以上ある場合に表示されます。これは、スタックのリングに破断が発生した場合（つまり、2本のケーブルがスタックから切断された場合）に発生し、アクティブとスタンバイの両方が他のメンバとの通信を失った場合に発生します。既存のスタックに電源が入っているスイッチを追加すると、スタック内に2つのアクティブスイッチが存在するため、スタックマージが発生する可能性があります。
CSCuh58098 
– スタックケーブルの問題が発生すると、3850スタックがリロードする可能性があります
CSCui56058 – スタックケーブルのデバウンスロジックの有効化
CSCup53338 - 3850 IOSDのクラッシュ | Signal=SIGSEGV(11) @ pm_port_data_from_swidb
hap_sup_reset:理由コード：[4] Reset Reason:[stack-manager]によってリセット/リロードが要求されました。[互換性がないためにスタックをマージ]
これは、アクティブおよびスタンバイスイッチがスタック内に存在する状況で発生します。アクティブスイッチからスタンバイへの通信が失われると、アクティブがまだ起動しているにもかかわらず、スタンバイはアクティブとして引き継ぎを試みます。
CSCuo49555 /CSCup58016:3850/3650 crashes due to unicast flood on mgmt port
CSCur07909 – アクティブおよびスタンバイの接続が失われたため、スタックのマージ
リセット理由：[stack-manager]によってリセット/リロードが要求されました。[ASIC投票後に誤ったネイバーが発生]
スイッチは起動時にASIC投票に参加し、スタック内の隣接スイッチを決定します。このリセットは、ネイバーが自身を宣言するためにタイマーが時間切れになった場合、またはnbrcastカンバセーション中に論理エラーが発生した場合に発生します。これは、交換によって解決されたスタックケーブルの障害に関連しています。
CSCun60777 - ASICの投票後に誤ったネイバーが検出されたため、スイッチがリロードされた
CSCud93761 - ASICの投票後に誤ったネイバーが検出されたため、スイッチがリロードされた
hap_sup_reset:理由コード：[4] Reset Reason: Reset/Reload requested by [stack-manager].[アクティブとスタンバイの両方が失われました]
これは通常、アクティブまたはスタンバイロールに属していないスタック上のメンバから表示されます。アクティブが失敗した場合、スタックのアクティブロールを引き継ぐスタンバイスイッチがない場合、スタック全体がリセットされます。スタックの状態が不安定な場合、または冗長ポリシーがまだ同期されていない場合は、これが表示される可能性があります。これは、アクティブ/スタンバイスイッチがダウンした理由の犠牲になったり、冗長性が正しく同期していない可能性があります。これは、ハーフリング設定でスタックが設定されている場合にも表示されます。
CSCup53882 - 3850スタックのメンバスイッチのリブート – [アクティブとスタンバイの両方が失われる]
hap_sup_reset:理由コード：[1] Reset Reason: Reset/Reload requested by [stack-manager].[Keepalive_Timeout]
スタック内のスイッチからキープアライブメッセージが受信されない場合に表示されます。「トレースバッファ：redundancy-timer-ha_mgr"は、キープアライブメッセージの交換を示し、通信のブレークダウンが開始された時点の視点を示す必要があります。残りのスタックからスイッチのレポートを収集し、時間枠内にログを確認すると役に立ちます。
hap_sup_reset:リセット理由：[stack-manager]によってリセット/リロードが要求されました。[リロードコマンド]
これは非常に直感的なリセットの理由です。これは、スタックマネージャがCLIから、または管理デバイス(SNMP)を介して外部から起動できるリロード要求を受信したときに表示されます。 CSCuj17317の場合 このコマンドは「reload command」も発行したコマンドとして表示されます。ログファイルから：次の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 FEDクラッシュ – SPIチャネルFED_SPI_FLCD,FED_SPI_FAST ...の待機中
潜在的なスタックケーブル配線/ポート問題の診断
症状1)スタックケーブル配線の問題の兆候は、リセット前のスタックポートのフラッピングによって明らかになります。「logfile:通常、リセット前の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
症状2)stackwise設定が使用される(180、480、およびポートASICごとの送信リングの数は異なります。これらのコマンドは、送信リングごとに読み取りエラーが発生する回数の合計を維持するグローバルレジスタをポーリングします。'Port-asic 0'はスタックポート1に、'port-asic 1'はスタックポート2に対応しています。これはスイッチごとに発行する必要があり、カウントが増加している兆候があれば、ポートまたはスタックケーブルに問題があるかどうかが特定できます。
これらの値は、数分間に数回収集して、カウント内の差分を比較できます。
show platform port-asic <0-1> read register SifRacDataCrcErrorCnt switch <switch#>
- データCRCエラーのあるセグメント
show platform port-asic <0-1> read register SifRacRwCrcErrorCnt switch <switch#>
- 失敗したCRCチェックで増加
show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>
- 無効なPCSコード、不明なPCSコードワードで増分され、実行中の不一致エラーが検出されました
show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>
- スタックのビットエラーによりリングワードCRCエラーが発生しました
Polaris （16.Xコード）のコマンドは次のとおりです。
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacRwCrcErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt asic <0-1>
次の例では、スタックマージイベントで、フラッピングしているスタックポートの兆候がない2メンバースタックの両方のメンバーを確認しています。スイッチ1のスタックポート1でリング[0]が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に達すると、0x000000000に戻ります。
その他のヒント
1 の L-AC-PLS-G）を注文します。 Crashinfoディレクトリのアーカイブ
スタック内のスイッチの数が多いほど、収集するレポートファイルが増えます。生成されるレポートの数に圧倒されやすい。障害を切り分けるには、組織が不可欠です。可能であれば、各スイッチが特定のインシデントのレポートファイルを書き込んだタイミングのタイムスタンプを使用して、整合性を見つけます。そこから、特定のスイッチから特定のレポートを要求して、お客様が複数のファイルをアップロードしないようにします。crashinfoディレクトリもアーカイブできるため、お客様は対象レポートを含むアーカイブを1つ送信できます。次の例では、「crashinfo-archive.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.不安定なスタックの回復
スタック選択プロセスが実行された後に、ブートアップ中にスタック内の複数のメンバがリロードする場合があります。リロードされたスイッチが自身がアクティブであると見なしている場合、これはスタックマージイベントの原因となり、ブートループ状態になる可能性があります。この状況では、お客様に次の質問をすることをお勧めします。
– スタック全体の電源を切り、すべてのスタックケーブルをしっかりと取り付け直します。
– スタック内の各メンバスイッチの電源を、すべてのメンバが期待される状態に収束するまで1つずつオンにします。
– メンバがスタックに参加できない場合は、スタックからこのメンバを削除し、スタンドアロンとしてこのメンバを起動して、さらにトラブルシューティングを行ってください。
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>
フィードバック