簡介
本檔案 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) |
意見