目錄

簡介

必要條件

採用元件

Nexus 9000交換機如何中斷

用於解決重新載入和崩潰問題的重要資料

系統重置原因

核心檔案

板載日誌

進程日誌

來自Logflash的日誌檔案

常見重置原因

電源相關重新載入

說明

建議：

進程崩潰

說明

建議

EOBC故障

說明

建議

奇偶校驗錯誤

說明

建議

PCIE錯誤

說明

建議

監視器超時

說明

建議

由於CLI或升級而手動重新載入

說明

建議

思科錯誤ID

簡介

本檔案 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上有一個內建的logflash，日誌檔案在重新載入後仍存在。

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在進程重新啟動期間無法工作）或進程重新啟動時間達到最大重試，則發生重新載入。

建議

`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是乙太網帶外通道的簡稱。常規keepalive在supervisor和線卡之間傳輸。您收到的錯誤消息表明SUP和線卡之間丟失了心跳。如果丟失了單個心跳，則可以自動忽略它。但是，如果同時丟失多個心跳，則線路卡將重置。

EOBC失敗的原因通常有3個：

1. EOBC擁塞。您可以看到超過1個線路卡體驗EOBC丟失。

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時，會發生奇偶校驗錯誤。

大多數奇偶校驗錯誤是由靜電或磁相關的環境條件引起的。這些事件是隨機發生的，無法預防。

系統檢測到發生此錯誤，並強制系統崩潰以防止處理不正確的資料。出現一個問題並不意味著硬體或軟體有問題。

建議

奇偶校驗錯誤可能是臨時單事件顛覆(SEU)，也可能是由硬體故障引起的。要確定是哪種情況，您需要監控裝置48小時以確定其是否重複。

如果在48小時內沒有第二次發生，則將此問題視為暫時的，不需要執行任何操作。

頻繁或可重複（硬）奇偶校驗錯誤是由用於讀寫的儲存器或電路的物理故障導致的。在這種情況下，請更換硬體。

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錯誤分為兩種型別：可更正錯誤和不可更正錯誤。此分類基於這些錯誤的影響，這些錯誤會導致效能降級或功能故障。

可糾正的錯誤不會影響介面的功能。PCIE協定可以在沒有任何軟體干預或資料丟失的情況下恢復。硬體可以檢測和糾正這些錯誤。

無法糾正的錯誤會影響介面的功能。無法糾正的錯誤可能會導致特定事務或特定PCIE連結不可靠。根據這些錯誤情況，不可糾正的錯誤還會被劃分為非致命錯誤和致命錯誤。非致命錯誤導致特定事務不可靠，但PCIE鏈路本身完全正常。另一方面，致命錯誤會導致連結不可靠。

Nexus 9000檢測到致命的PCIE錯誤，並強制系統重新載入，以防止處理不正確的資料。

建議

與奇偶校驗錯誤相同。

如果在48小時內沒有第二次發生，則將此問題視為暫時的，不需要執行任何操作。

頻繁出現或可重複出現的錯誤是由物理故障導致的。在這種情況下，請更換硬體。

監視器超時

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)

思科錯誤ID

某些缺陷可能導致Nexus 9000交換機上發生意外重新載入。若要確認您是否已遇到已知軟體錯誤，請開啟TAC案例。

思科錯誤 ID

錯誤標題

修復版本

思科錯誤ID CSCwd53591

由於監視器超時（無核心/跟蹤）而重新載入

9.3(13)

思科錯誤ID CSCvz65993

tahoe0關閉，導致帶內連線故障

9.3(9)

思科錯誤ID CSCvs00400

由於連結翻動後監視器逾時，核心宕機和重新載入

9.3(3)和7.0(3)I7(8)

思科錯誤ID CSCvr57551

Cisco Nexus 9000重新載入時核心宕機 — 無法處理核心分頁請求

7.0(3)I7(8)和9.3(4)

思科錯誤ID CSCvo86286

使用Nexus 9500第1代線卡的7.0(3)I7(x)上出現核心宕機

7.0(3)I7(7)

思科錯誤ID CSCvx38752

記憶體洩漏導致Nexus 9k重新載入「ipfib」

7.0(3)I7(9)和9.3(2)

思科錯誤ID CSCvh13039

由於EOBC心跳導致LC/FM重新載入為CPU忙於維護hrtimer

7.0(3)I4(8)和7.0(3)I7(3)