排除Nexus 9000上的意外重新加载或崩溃故障

简介

本文档介绍如何对Nexus 9000交换机上的意外重新加载或崩溃进行故障排除。

先决条件

读者无需满足任何前提条件即可理解本文档内容。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

Nexus 9000交换机如何中断

Cisco NX-OS是专为网络、系统和进程级别的高可用性(HA)而设计的弹性操作系统。Nexus 9000交换机上发生意外重新加载有3个原因：

• 用户空间中的进程可能会发生崩溃。
• 进程或硬件可能遇到监视器超时或心跳故障。

• 内核本身遇到不可恢复的情况并崩溃。

对重新加载和崩溃进行故障排除的重要数据

• 重新加载的确切日期和时间。
• 重新加载之前发生了什么情况？是否更改了配置？规模有变化吗？设备上是否有日志？环境有什么变化吗？CPU/内存使用率是否增加？
• 交换机启动并稳定后，收集并检查输出。 
• 如果交换机无法启动，请通过控制台访问，然后检查是否有任何输出。此外，检查交换机LED。您可以在硬件安装指南中找到有关LED的详细信息。 

System Reset-Reason

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失败通常有三个原因：

1. EOBC拥塞。您会看到超过1个线路卡EOBC丢失。
2. CPU占用特定模块。 线路卡/主管CPU繁忙，无法处理EOBC消息。从Nexus 9000开始从7.0(3)I7(3)进行软件增强。 
3. 硬件故障. 

建议

1. 检查CPU是否在重新加载时占用任何受影响的线卡。
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小时内没有第二次发生，则此问题会被视为临时问题，无需执行任何操作。频繁出现或可重复的错误是由物理故障导致的。在这种情况下，请更换硬件。

<a href="http://www.cisco.com/MT/eval/zh/nopage.html" >监视器超时

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能够检测软件挂起并及时重新启动交换机。

建议

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交换机上意外重新加载。要确认您是否遇到了已知软件Bug，请打开TAC案例。

Cisco Bug ID	Bug标题	修复版本
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 9k重新加载“ipfib”	7.0(3)I7(9)和9.3(2)
Cisco Bug ID CSCvh13039	由于EOBC心跳导致LC/FM重新加载为CPU忙于服务hrtimer	7.0(3)I4(8)和7.0(3)I7(3)

修订历史记录

版本	发布日期	备注
2.0	05-Jun-2026	更新的拼写、语法、句子结构和间距。
1.0	07-Feb-2024	初始版本