システムレポートによるスタックマネージャによる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-111342-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]リセット理由：[stack-manager]によってリセット/リロードが要求されました。[互換性がないためにスタックをマージ]
これは、アクティブおよびスタンバイスイッチがスタックに存在する状況で発生します。アクティブスイッチからスタンバイへの通信が失われた場合、アクティブがまだ起動していても、スタンバイはアクティブとして引き継ぎを試みます。
CSCuo49555 /CSCup58016 - 3850/3650が管理ポートでのユニキャストフラッドによりクラッシュする
CSCur07909 – アクティブおよびスタンバイの接続が失われたため、スタックのマージが行われます
リセットの理由：[stack-manager]によってリセット/リロードが要求されました。[ASIC投票後に誤ったネイバーが検出されました]
スイッチは起動時にASIC投票に参加し、スタック内の隣接スイッチを決定します。このリセットは、ネイバーが自身を宣言するためにタイマーが時間切れになった場合、またはnbrcastカンバセーション中に論理エラーが発生した場合に発生します。これは、交換によって解決されたスタックケーブルの障害に関連して見られます。
CSCun60777 - ASICの投票後に誤ったネイバーが検出されたため、スイッチがリロードされました
CSCud93761 - ASICの投票後に誤ったネイバーが検出されたため、スイッチがリロードされました
hap_sup_reset:理由コード：[4] Reset Reason:[stack-manager]によってリセット/リロードが要求されました。[アクティブとスタンバイの両方が失われました]
これは通常、アクティブまたはスタンバイの役割を持たないスタック上のメンバから表示されます。アクティブが失敗すると、スタックのアクティブロールを引き継ぐスタンバイスイッチがない場合、スタック全体がリセットされます。スタックの状態が不安定な場合、または冗長ポリシーがまだ同期されていない場合は、これが表示されます。これは、アクティブ/スタンバイスイッチがダウンした理由の犠牲になったり、冗長性が正しく同期していないことを示している可能性があります。これは、スタックがハーフリング設定で設定されている場合にも表示されます。
CSCup53882 - 3850スタックリブートのメンバスイッチ – [アクティブとスタンバイの両方が失われました]
hap_sup_reset:理由コード：[1] Reset Reason:[stack-manager]によってリセット/リロードが要求されました。[Keepalive_Timeout]
スタック内のスイッチからキープアライブメッセージが受信されない場合に表示されます。「Trace Buffer:redundancy-timer-ha_mgr"は、キープアライブメッセージの交換を示し、通信の内訳が開始された時点の時間の観点を示す必要があります。残りのスタックからスイッチレポートを収集し、時間枠の間にログを確認すると、この問題に役立ちます。
hap_sup_reset:リセットの理由：[stack-manager]によってリセット/リロードが要求されました。[リロードコマンド]
これは非常に直感的なリセットの理由です。これは、スタックマネージャが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 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、および180+）に応じて、ポートASICごとの送信リングの数が異なります。これらのコマンドは、送信リングごとに読み取りエラーの総数を維持するグローバルレジスタをポーリングします。「ポートASIC 0」はスタックポート1に、「ポート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のCRCでring[0]が増加し、スタックケーブルを交換して、この問題を回避することができました。
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ディレクトリのアーカイブ
スタック内のスイッチが増えると、収集されるレポートファイルが増えます。生成されるレポートの数に圧倒されやすい。障害を切り分けるには、組織が不可欠です。可能であれば、各スイッチが特定のインシデントのレポートファイルを書き込んだタイミングのタイムスタンプを使用して、整合性を見つけます。そこから、特定のスイッチからそれらの非常に具体的なレポートを求めて、お客様が複数のファイルをアップロードしないようにします。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>
フィードバック