Nexus 9000での予期しないリロードまたはクラッシュのトラブルシューティング
はじめに
このドキュメントでは、Nexus 9000スイッチでの予期しないリロードやクラッシュをトラブルシューティングする方法について説明します。
前提条件
このドキュメントには前提条件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
Nexus 9000スイッチの不具合
Cisco NX-OSは、復元力のあるオペレーティングシステムで、ネットワーク、システム、およびプロセスレベルでのハイアベイラビリティ(HA)に特化して設計されています。 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電源の冗長性をサポートしています。ほとんどまたはすべての電源で停電が発生すると、リロードが発生します。
推奨事項
- すべての電源の電源コードを確認します。
- 同じインレット回線を共有する他のデバイスでも障害が発生していないかを確認します。
- 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つの原因があります。
- EOBC輻輳1つ以上のラインカードのEOBCが失われていることが表示されます。
- 特定のモジュールのCPUホグ。 ラインカード/スーパーバイザのCPUがビジー状態で、EOBCメッセージを処理できません。Nexus 9000以降では、7.0(3)I7(3)からソフトウェアの機能拡張が行われています。
- ハードウェア障害.
推奨事項
- リロードの前後で、影響を受けるラインカードのCPUホグが発生しているかどうかを確認します。
- 他のラインカードでリロード前後のEOBC損失が発生していないかどうかを確認します。
- BFDまたはNetflow CPUへの展開が最近サービスを消費しているかどうかを確認します。
- 何の情報も得られずに複数回発生する場合は、ハードウェアを交換します。
パリティ エラー
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はソフトウェアのハングを検出し、スイッチを迅速にリブートできます。
推奨事項
- 既知のソフトウェアバグが現在のバージョンに影響するかどうかを確認します。
- 問題が再発する場合は、カーネルトレースと追加のログデータを収集します。
- サービスリクエストのケースをオープンします。
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が「Kernel panic - unable to handle kernel paging request」でリロードする | 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ビジーサービスhrtimerとしてのEOBCハートビートによるLC/FMリロード | 7.0(3)I4(8)および7.0(3)I7(3) |
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
05-Jun-2026
|
スペル、文法、文の構造、およびスペースが更新されました。 |
1.0 |
07-Feb-2024
|
初版 |
フィードバック