Nexus 9000での予期しないリロードまたはクラッシュのトラブルシューティング

はじめに

本資料 d説明 nexus 9000スイッチで予期しないリロードまたはクラッシュをトラブルシューティングする方法

前提条件

このドキュメントに関する要件はありません。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

Nexus 9000スイッチの不具合

Cisco NX-OSは、ネットワーク、システム、およびプロセスレベルでの高可用性を実現するために特別に設計された、復元力のあるオペレーティングシステムです。

Nexus 9000で予期しないリロードが発生する原因は3つあります。

• ユーザ空間のプロセスがクラッシュする可能性があります。
• プロセスまたはハードウェアの一部で、ウォッチドッグタイムアウトまたはハートビート障害が発生する可能性があります。

• カーネル自体が回復不能な状態に陥り、クラッシュします。

リロードとクラッシュのトラブルシューティングに重要なデータ

• リロードの正確な日時。
• リロードの前に何が起きていましたか。設定に変更はありますか。スケールの変更は？デバイスのログは？環境の変化は？CPU/メモリ使用量の増加はありますか。
• スイッチが起動して安定したら、出力を収集して確認します。 
• スイッチが起動しない場合は、コンソールからアクセスし、何らかの出力が表示されるかどうかを確認します。また、スイッチのLEDを確認します。LEDの詳細については、ハードウェアインストールガイドを参照してください。 

システムリセットの理由

N9K#show system reset-reason module 1
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 21301 usecs after Tue Jan 17 20:29:20 2023
Reason: Reset Requested due to Fatal Module Error
Service: ipfib hap reset
Version: 9.3(8)

コアファイル

N9K#show cores
VDC  Module Instance  Process-name    PID      Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
A     B       C         D             E          2024-01-04 19:17:25
copy core://<module-number>/<process-id>[/instance-num]
copy core://B/E/C ftp://<address>/<directory>

オンボードログ

show logging onboard
show logging onboard kernel-trace
show logging onboard stack-trace
**************************************************************
STACK TRACE GENERATED AT Sun Sep 10 19:06:39 2023 CCT
**************************************************************
<snip>                                                                        >>>dumps kernel massages before reload
<0>[10925084.972289] [1694343998] sysServices Unexpected call in interrupt context, serviceId=824
<0>[10925084.980666] [1694343998] cctrl_set_card_offline - EOBC switch reset failed
<0>[10925084.987824] [1694343998] sysServices Unexpected call in interrupt context, serviceId=824
<0>[10925084.996200] [1694343998] cctrl_set_card_offline - EPC switch reset failed
<snip>
<4>[10925085.040600] [1694343998] Dumping interrupt statistics                >>>dump interrupt statictics
<4>[10925085.045928] [1694343998] CPU0 CPU1 
<4>[10925085.051732] [1694343998] 3: 0 0 axp_irq Armada Error Handler
<4>[10925085.059909] [1694343998] 4: 0 0 axp_irq Armada MBUS unit Error Handle
<4>[10925085.068957] [1694343998] 5: 1012335907 809985523 axp_irq axp_local_clockevent
<4>[10925085.077136] [1694343998] 8: 1260801154 0 axp_irq mv_eth
<4>[10925085.084108] [1694343998] 31: 11230 0 axp_irq mv64xxx_i2c
<4>[10925085.091508] [1694343998] 41: 7111 1 axp_irq serial
<4>[10925085.098471] [1694343998] 51: 2 0 axp_irq mv_xor.0
<4>[10925085.105602] [1694343998] 52: 2 0 axp_irq mv_xor.1
<4>[10925085.112760] [1694343998] 94: 1 0 axp_irq mv_xor.2
<4>[10925085.119890] [1694343998] 95: 1 0 axp_irq mv_xor.3
<4>[10925085.127029] [1694343998] 107: 0 0 axp_irq axp-temp
<4>[10925085.134200] [1694343998] 168: 0 0 axp_irq cctrl_mrv_nmi_irq
<4>[10925085.142134] [1694343998] 195: 29 0 axp_msi_irq cctrl_sc_msi_irq
<4>[10925085.150225] [1694343998] 196: 0 2399172865 axp_msi_irq linux-kernel-bde
<4>[10925085.158325] [1694343998] IPI0 : 0 0 Timer broadcast interrupts
<4>[10925085.166130] [1694343998] IPI1 : 1711470501 3532640372 Rescheduling interrupts
<4>[10925085.173672] [1694343998] IPI2 : 0 0 Function call interrupts
<4>[10925085.181302] [1694343998] IPI3 : 44582 118572 Single function call interrupts
<4>[10925085.189541] [1694343998] IPI4 : 0 0 CPU stop interrupts
<4>[10925085.196734] [1694343998] PMU: : 0 0 
<4>[10925085.202186] [1694343998] Err : 0

show logging onboard exception-log                               >>>Check if any exception is raised before reload

プロセスログ

N9K# show processes log details                                  >>>detail process memory usage prior to crash
Service: ethpm
Description: Test Ethernet Port Manager
Executable: /isan/bin/ethpm

Started at Wed Jun 5 18:20:46 2023 (251615 us)
Stopped at Sat Jun 8 00:08:53 2023 (661042 us)
Uptime: 2 days 5 hours 48 minutes 7 seconds

Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Last heartbeat 48.10 secs ago
System image name: 
System image version: 7.0(3)I7(6)
PID: 28914 
Exit code: signal 5 (core dumped)
CWD: /var/sysmgr/work
RLIMIT_AS: 1019819820                                             >>>limit memory usage
Virtual Memory:
CODE 1007E000 - 1068DBD4
DATA 1068E000 - 106DC3E8
BRK 1194F000 - 11CF9000
STACK FFA28650
TOTAL 576004 KB                                                   >>>memory usage before crash

Logflashからのログファイル

Nexus 9000には組み込みのログフラッシュがあり、ログファイルはリロード後も保持されます。

N9K#dir logflash:log | grep messages
3714961 Jan 13 18:05:31 2024 messages
4194331 Jan 13 17:30:14 2021 messages.1
5497842 May 11 15:59:00 2021 messages.2
4194341 Jul 30 07:25:36 2022 messages.3
4194510 Feb 09 14:50:50 2023 messages.4
4194426 Jun 04 05:00:40 2023 messages.5

N9K#show file logflash:log/messages
N9K#show file logflash:log/messages.1
N9K#show file logflash:log/messages.2
N9K#show file logflash:log/messages.3
N9K#show file logflash:log/messages.4
N9K#show file logflash:log/messages.5

リセットの一般的な原因

電源関連のリロード

N9K#show system reset-reason 
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 280125 usecs after Fri Aug 4 02:01:14 2023
Reason: Module PowerCycled
Service: HW check by card-client
Version: 

説明

Nexus 9000スイッチは、N+1電源の冗長性をサポートしています。ほとんどの電源またはすべての電源で停電が発生すると、リロードが発生します。

推奨：

1.電源装置の電源コードを確認します。

2.同じインレット回路を共有する他のデバイスにも障害が発生していないかを確認します。

3. Nexus 9000またはPDUに電源関連のアラームがあるかどうかを確認します。

プロセスのクラッシュ

N9K#show system reset-reason module 1
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) 
1) At 21301 usecs after Tue Jan 17 20:29:20 2023 
Reason: Reset Requested due to Fatal Module Error 
Service: ipfib hap reset                                              >>>ipfib process reset
Version: 9.3(8)

説明

各サービスには、ハートビートタイマー、再起動方法、ステートフル再起動最大再試行など、独自の高可用性(HA)ポリシーがあります。Cisco NX-OSソフトウェアでは、ほとんどのプロセスとサービスをステートフルに再起動できます。リロードは、プロセスhaポリシーがリセットされた場合（NX-OSがプロセスの再起動時に動作しない場合）、またはプロセスの再起動時がmax retryに達した場合に発生します。  

推奨

`show cores`
VDC  Module  Instance  Process-name     PID       Date(Year-Month-Day Time)
---  ------  --------  ---------------  --------  -------------------------
1    1       1         ipfib            27446     2023-01-17 20:30:30   
copy core://1/27446/1 ftp://<address>/<directory>

プロセスのクラッシュのほとんどはソフトウェア不具合であり、コアファイルは保存されています。確認するには、サービスリクエストケースを開きます。 

• コアファイルはTACエンジニアがデコードできます。 
• サービスリクエストをオープンするには、Product > Unexpected Reboot > Software Failureの順に選択し、適切なチームでサービスリクエストをオープンしてください。

EOBC障害

2018 Jan 21 01:56:42.789 N9K#%KERN-0-SYSTEM_MSG: [4590707.849157] [1516460202] EMON: module 2 is not responding on EOBC path. Reloading module. - kernel
2018 Jan 21 01:56:43.071 N9K#%MODULE-2-MOD_DIAG_FAIL: Module 2 (Serial number: xxxxxxxxxx) reported failure due to EOBC heartbeat failure in device DEV_EOBC_MAC (device error 0xc0a1b137)

説明

EOBCはEthernet Out of Band Channelの略です。通常のキープアライブは、スーパーバイザとラインカードの間で行われます。受信したエラーメッセージは、SUPとラインカードの間でハートビートが失われたことを示しています。単一のハートビートが失われた場合は、自動的に無視できます。ただし、複数のハートビートが同時に失われると、ラインカードがリセットされます。

通常、EOBC障害には次の3つの理由があります。
1. EOBC輻輳EOBCが失ったラインカードの数が1つ以上あることがわかります。
2.特定のモジュールのCPUホグ。ラインカード/スーパーバイザCPUがビジー状態で、EOBCメッセージを処理できません。Nexus 9000以降では、7.0(3)I7(3)からソフトウェアの機能拡張が行われています。 
3.ハードウェア障害。 

推奨

1.影響を受けるラインカードのCPUhogがリロードの前後にあるかどうかを確認します。

2.他のラインカードでリロード前後のEOBC損失が発生していないかどうかを確認します。 

3.最近、BFDまたはNetflow CPUを消費するサービスが展開されたかどうかを確認します。 

4.何の情報も得られずに複数回発生する場合は、ハードウェアを交換します。 

パリティ エラー

N9K#show logging onboard stack-trace
**************************************************************
        STACK TRACE GENERATED AT Tue Sep 21 02:27:58 2021 UTC
**************************************************************
<0>[88302546.800770] [1632158876] ERROR: MACHINE: Uncorrectable
<0>[88302546.809202] [1632158876] L2CACHE ERROR: Cause 0x88
<0>[88302546.814368] [1632158876] TAG Parity Error                           >>>>>Parity error
<0>[88302546.818750] [1632158876] Kernel panic - not syncing: L2CACHE ERROR
<4>[88302546.825212] [1632158876] Cpu: 0 Pid: 0, comm:            swapper/0

説明

情報のビットが1から0または0から1に反転すると、パリティエラーが発生します。

ほとんどのパリティエラーは、静電気または磁気関連の環境条件によって発生します。これらのイベントはランダムに発生し、防止することはできません。

システムはこのエラーが発生したことを検出し、システムを強制的にクラッシュさせて、不正なデータが処理されないようにします。ハードウェアまたはソフトウェアの問題を示すものではありません。

推奨

パリティエラーは、一時的なSingle-Event Upset（SEU；シングルイベントアップセット）の場合もあれば、ハードウェアの欠陥が原因の場合もあります。これを判断するには、デバイスを48時間監視して、再発があるかどうかを確認する必要があります。

48時間以内に2回目の問題が発生しなかった場合は、問題は一時的なものと見なされ、対処は必要ありません。 

頻繁かつ繰り返し発生する可能性のある（ハード）パリティ エラーは、読み取り/書き込みに使用するメモリまたは回路の物理的な誤動作によって発生します。このような場合は、ハードウェアを交換します。

PCIEエラー

N9K#show logging onboard stack-trace
<6>[  105.196227]     CCTRL PANIC DUMP
<6>[  105.196229] =========================
<6>[  105.196231] WDT last punched at 105192052644
<6>[  105.196234] REG(0x60) = 3c
<6>[  105.196238] REG(0x64) = 0
<6>[  105.196241] REG(0x300) = baadbeef
<6>[  105.196245] REG(0x304) = baadbeef
<6>[  105.196246] =========================
<0>[  105.197303] nxos_panic: Kernel panic - not syncing: PCIE Uncorrectable error   >>>>>PCIE Uncorrectable error

説明

PCIEエラーは、訂正可能なエラーと訂正不能なエラーの2種類に分類されます。この分類は、これらのエラーの影響に基づいており、パフォーマンスの低下や機能障害を引き起こします。

修正可能なエラーは、インターフェイスの機能には影響しません。PCIEプロトコルは、ソフトウェアの介入やデータの損失なしに回復できます。これらのエラーはハードウェアによって検出され、修正されます。

修正不可能なエラーは、インターフェイスの機能に影響します。修正不可能なエラーがあると、特定のトランザクションまたは特定のPCIEリンクの信頼性が低下する可能性があります。これらのエラー条件に応じて、修正不可能なエラーは、さらに致命的でないエラーと致命的なエラーに分類されます。致命的でないエラーが発生すると、特定のトランザクションの信頼性が低下しますが、PCIEリンク自体は完全に機能します。一方、致命的なエラーが発生すると、リンクの信頼性が低下します。

Nexus 9000は致命的なPCIEエラーを検出し、システムを強制的にリロードして、誤ったデータが処理されないようにします。 

推奨

パリティエラーでも同じです。 

48時間以内に2回目の問題が発生しなかった場合は、問題は一時的なものと見なされ、対処は必要ありません。 

頻繁または繰り返し発生するエラーは、物理的な誤動作によって発生します。このような場合は、ハードウェアを交換します。

ウォッチドッグ タイムアウト

N9K#show system reset-reason
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 88659 usecs after Mon Sep 24 18:33:04 2023
   Reason: Watchdog Timeout
   Service:
   Version: 7.0(3)I7(9)

説明

ウォッチドッグタイマーは、一般に、組み込み型システムやコンピュータで制御されるその他の機器で使用されており、これらの機器に人間が簡単にアクセスできない場合や、障害にタイムリーに対応できない場合に使用されます。
Nexus 9000は、FPGAを介してウォッチドッグタイマー機能を導入します。これにより、Nexus 9000はソフトウェアのハングを検出し、スイッチを迅速にリブートできます。

推奨

1.既知のソフトウェアバグが現在のバージョンに影響するかどうかを確認します。

2.問題が再発した場合は、カーネルトレースと追加のログデータを収集します。

3.サービスリクエストケースをオープンします。

CLIまたはアップグレードによる手動リロード

N9K# show system reset-reason
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 343832 usecs after Sat Jan 13 17:58:53 2024
Reason: Reset Requested by CLI command reload
Service: 
Version: 10.2(5)
>
4) At 282886 usecs after Fri Jan 12 07:42:33 2024
Reason: Reset due to upgrade
Service: 
Version: 10.3(4a)                >>>>>version prior to upgrading

説明

Nexus 9000シリーズスイッチは、デフォルトで中断を伴うソフトウェアアップグレードとダウングレードをサポートします。アップグレード中にNexus 9000がリロードされます。

推奨

予想される動作です。CLIセッションの詳細については、アカウンティングログを確認してください。 

CLIのリロードの例：

Sat Jan 13 17:58:40 2024:type=update:id=console0:user=admin:cmd=reload (REDIRECT)
Sat Jan 13 17:58:47 2024:type=update:id=console0:user=admin:cmd=Rebooting the switch

アップグレードのリロード例：

Fri Jan 12 07:35:52 2024:type=update:id=console0:user=admin:cmd=install all nxos bootflash:/nxos64-cs.10.2.5.M.bin (SUCCESS)

Cisco Bug ID

一部の不具合は、Nexus 9000スイッチで予期しないリロードを引き起こす可能性があります。既知のソフトウェアバグに該当するかどうかを確認するには、TACケースをオープンしてください。

Cisco Bug ID	バグタイトル	修正バージョン
Cisco Bug ID CSCwd53591	コア/トレースのないウォッチドッグタイムアウトによるリロード	9.3(13)
Cisco Bug ID CSCvz65993	tahoe0がダウンし、インバンド接続障害が発生した	9.3(9)
Cisco Bug ID CSCvs00400	リンクのフラップ後のウォッチドッグタイムアウトによるカーネルパニックとリロード	9.3(3)および7.0(3)I7(8)
Cisco Bug ID CSCvr57551	Cisco Nexus 9000がカーネルパニックでリロードする：カーネルページング要求を処理できない	7.0(3)I7(8)および9.3(4)
Cisco Bug ID CSCvo86286	Nexus 9500第1世代ラインカード搭載の7.0(3)I7(x)で見られるカーネルパニック	7.0(3)I7(7)
Cisco Bug ID CSCvx38752	メモリリークにより、Nexus 9000が「ipfib」をリロードする	7.0(3)I7(9)および9.3(2)
Cisco Bug ID CSCvh13039	CPUビジーサービシングタイマーとしてのEOBCハートビートによるLC/FMリロード	7.0(3)I4(8)および7.0(3)I7(3)