3650/3850堆叠管理器重新加载故障排除
简介
本文档介绍如何利用系统报告诊断堆栈问题。
先决条件
要求
本文档没有任何特定的要求。
使用的组件
本文档不限于特定的软件和硬件版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
背景信息
如果在没有崩溃的情况下通过系统报告对堆栈重新加载进行故障排除，通常在NGWC交换平台上完成，则使用stackwise技术。当前文档只限于使用系统报告，本指南将说明如何使用这些报告来诊断通常与堆叠问题相关的问题。本指南尤其侧重于运行具有支持堆叠功能的Cisco IOS® XE的Catalyst 3650/3850交换机架构。
stackwise技术的大多数问题都源于堆叠内成员之间的通信问题。成员之间的任何信息不一致或连接丢失都可能导致贯穿整个堆栈的问题，并最终导致使用堆栈管理器进行重置。本文档可以重点介绍堆叠管理器重新加载时出现的一些常见故障、系统报告的使用，以及可用于诊断的相关CLI和不同类型的故障。
系统报告与交换机报告
系统报告是成员通过感知堆栈状态的方式而获得的综合报告。这并非是crashinfo（可转储内存以供进一步调试），相反，它是包含在Cisco IOS XE下运行的各种服务的日志和调试信息的报告，对于跟踪该服务状态的开发非常有用。当交换机由堆栈管理器重新加载、进程崩溃发生或用户在实时操作期间手动生成系统报告时，可以生成系统报告。
在许多情况下，单个交换机在堆叠中可能发生故障，但其余成员可以保持不变。为了收集给定时间堆栈状态的as信息，引入了switch_reports，以便当前成员可以在检测到成员已关闭时生成一个as。switch_report可以是一个本地报告，用于说明该成员如何感知堆栈的当前状态。
收集系统/交换机报告的位置
系统报告通常可写入该堆栈中成员的目录crashinfo：。例如，如果存在x成员交换机堆叠，则每个交换机可以拥有自己的crashinfo目录，该目录可以使用dir crashinfo-x进行访问，其中x对应于堆叠中的该成员。
3850#dir crashinfo-1：
crashinfo目录：/
11 -rwx 355 Aug 14 2015 07:48:17 -04:00 last_systemreport_log
12 -rwx 724015 2014年10月15日07:14:32 -04:00 system-report_1_20141015-111342-UTC.gz
3850#dir crashinfo-2：
crashinfo-2：/目录
11 -rwx 357 Aug 14 2015 07:50:49 -04:00 last_systemreport_log
12 -rwx 751340 2014年10月15日06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz
注意：只有思科注册用户才能访问内部思科漏洞信息和工具。
系统报告中值得注意的章节
从TAC的角度来看，这些是系统报告中比较常见的一些条目，可帮助诊断特定问题的事件。此处包含其他服务中的其他日志，开发人员可以发现需要查看。
日志文件：/mnt/pss/sup_sysmgr_reset.log
这是一个简短的输出，非常笼统地理解为什么会看到重置。请参阅以下失败类型部分，了解这些原因的含义和背景。
日志文件：Cisco IOS
这是从Cisco IOSd中维护的日志缓冲区。由用户发出的任何命令或Cisco IOSd中生成的系统日志都可以在本节中找到。最近的日志正接近此输出的末尾。
跟踪缓冲区：stack-mgr-events
跟踪从堆栈管理器中发现的事件，这些事件可能包括其他成员何时加入/从堆栈中移除或消息通过哪个堆栈端口传入。
跟踪缓冲区：redundancy-timer-ha_mgr
显示堆叠中交换机之间的保持连接事件。时间戳可以帮助确定通信故障发生的时间。
故障类型
本节可以突出显示系统报告中通常由堆栈管理器进程调用的某些常见重置。堆叠管理器是一个Linux进程，用于管理堆叠中的成员，并可监视堆叠中交换机之间角色的任何更改。如果堆叠管理器在初始化或角色选举期间检测到问题，它可以将重新加载信号发送到各个交换机，以便重置堆叠。下一个列表还可以列出已关联到各自故障类型的已知漏洞。
注意：并非所有堆叠管理器重新加载都归因于软件问题。事实上，更常见的是这些问题表现为核心硬件问题的次要/受害者问题。
重置原因：由[stack-manager]请求重置/重新加载。[ISSU不兼容]
当您尝试在堆叠中的所有成员之间同步活动上的配置时，如果出现批量同步故障，您可以看到这种类型的重置。检查日志文件：Cisco IOS或活动交换机的日志可以突出显示促成此重置的配置。
重置原因：服务[iosd] pid：[xyz]异常终止[11]。
当交换机在Cisco IOSd进程中崩溃时，会出现这种情况。查看crashinfo目录，查找可用于进一步调试此故障的任何crashinfo文件+核心转储。
hap_sup_reset：重置原因：由[stack-manager]请求重置/重新加载。[堆栈合并]
当有两台或多台交换机认为自己是堆栈的活动交换机时，就会发现堆栈合并。当堆栈的环中出现中断（即，两根电缆从堆栈断开）时，可以发现此问题，因此主用和备用链路均丢失与其他成员的通信。将已通电的交换机添加到当前堆叠中会导致堆叠合并，因为堆叠中可能有两个活动交换机。
Cisco bug ID CSCuh58098 - 3850堆叠在出现堆叠布线问题时可以重新加载
Cisco bug ID CSCui56058 -启用堆叠电缆的反退回逻辑
Cisco bug ID CSCup53338 - 3850 IOSD崩溃 | Signal=SIGSEGV(11) @ pm_port_data_from_swidb
hap_sup_reset：原因代码：[4] Reset Reason：Reset/Reloadrequested by [stack-manager]。[由于不兼容而导致堆栈合并]
在堆叠中存在主用和备用交换机时，会发现此问题。如果主用交换机失去与备用交换机的通信，则备用交换机可以尝试接替主用交换机，即使主用交换机仍然处于工作状态。
Cisco Bug ID CSCup58016（仅限注册用户）- 由于管理端口上的单播泛洪，3850/3650崩溃
思科漏洞ID CSCur07909 - 由于活动和备用连接丢失导致堆叠合并
重置原因：由[stack-manager]请求重置/重新加载。[在ASIC投票后遇到错误的邻居]
交换机在启动期间参与ASIC投票，以确定堆叠中的相邻交换机。当邻居的计时器过期以声明自身或广播会话期间出现逻辑错误时，可以看到此重置。在堆叠电缆故障问题已通过更换解决的情况下，可以看出这一点。
Cisco bug ID CSCun60777 - 在ASIC投票后，由于遇到错误的邻居，交换机重新加载
Cisco bug ID CSCud93761 -在ASIC投票后，由于遇到错误的邻居，交换机重新加载
Cisco bug ID CSCun17506 - Amur：ng3k：在3成员堆栈上的两个堆栈端口上都看到相同的邻居
hap_sup_reset：原因代码：[4] Reset Reason：Reset/Reload requested by [stack-manager]。[失去主用和备用]
这通常从堆叠中不属于活动或备用角色的成员中看到。当主用交换机发生故障时，如果没有备用交换机承担堆叠的主用角色，则整个堆叠都可以重置。如果堆叠处于不稳定状态或冗余策略尚未同步，则会出现这种情况。这可能是因为主用/备用交换机关闭的原因造成的，也可能是因为冗余未正确同步。在半环设置中配置堆栈时也可以看到此情况。
思科漏洞ID CSCup53882 - 3850堆叠重启中的成员交换机- [失去活动和备用状态]
hap_sup_reset：原因代码：[1] Reset Reason：Reset/Reload requested by [stack-manager]。[Keepalive_Timeout]
当从堆叠中的交换机未收到保持连接消息时，会看到此消息。查看Trace Buffer： redundancy-timer-ha_mgr，它显示保持连接消息的交换，并提供通信开始发生故障的时间角度。如果您从堆栈的其余部分收集交换机报告，并在整个时间段内查看日志会有所帮助。
hap_sup_reset：重置原因：由[stack-manager]请求重置/重新加载。[Reload Command]
这是一个非常直观的重置原因-当堆叠管理器收到重新加载请求时，会出现这种情况，该请求可以通过CLI或在外部通过管理设备(SNMP)调用。在思科漏洞ID为CSCuj17317的情况下，这也显示为发出的reload命令。从日志文件：Cisco IOS中可以看到：
CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr: Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr: Reloading due to reason Reload command
相关 Bug
Cisco bug ID CSCur76872 -当系统耗尽SDP缓冲区时，堆栈管理器关闭。
Cisco bug ID CSCup49704 - 3850 FED崩溃-等待SPI信道FED_SPI_FLCD、FED_SPI_FAST ...
诊断潜在的堆叠电缆或端口问题
症状1)在重置之前，堆栈端口的任何摆动都明显存在堆栈电缆问题的任何迹象。查看日志文件：重置之前的Cisco IOS报告通常是启动时的良好选择。以下示例显示了当前SW2和备用SW1上注册的堆叠端口的抖动。 在每个重置实例中，此同一堆叠端口都会摆动，更换堆叠电缆时，解决方法是：
===================== log file: Cisco IOS =====================
.
.
Aug 8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr: Stack port 1 on switch 1 is down (SW1-1)
Aug 8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr: Stack port 1 on switch 1 is up (SW1-1)
Aug 8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is down
Aug 8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is up
Aug 8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is down
Aug 8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is up
Aug 8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr: Switch 1 has been removed from the stack.
Aug 8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1
症状2)根据使用的Stackwise设置（180、480以及plus），每个端口ASIC的传输环数有所不同。这些命令会轮询全局寄存器，其总计数会随着每个传输环看到的读取错误数而增加。Port-asic 0对应堆叠端口1，port-asic 1对应堆叠端口2。必须对每台交换机发出此命令，计数增加的任何迹象都可确定端口或堆栈电缆是否存在问题。
可以在几分钟内多次收集这些数据，以比较计数中的增量：
show platform port-asic <0-1> read register SifRacDataCrcErrorCnt switch <switch#>
- 数据段存在数据CRC错误。
show platform port-asic <0-1> read register SifRacRwCrcErrorCnt switch <switch#>
- 任何失败的CRC检查都会递增。
show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>
- 在运行检测到的差异错误的无效PCS代码（未知PCS码字）上递增。
show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>
- 堆栈上的位错误导致铃声CRC错误。
对于Polaris（16.X代码），这些命令如下：
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacRwCrcErrorCnt asic<0-1>
show platt hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt asic <0-1>
此示例显示在一个堆栈合并事件中，两个成员堆栈中的两个成员均未看到任何堆栈端口摆动的迹象。您会看到环路[0]随着交换机1的堆叠端口1上的CRC而增加，要克服此问题，请更换堆叠电缆。
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015
For asic 0
SifRacRwCrcErrorCnt on Asic 0
[0]
count 0x00000031 <<
[1]
count 0x00000001
[2]
count 0x00000000
[3]
count 0x00000001
[4]
count 0x00000000
[5]
count 0x00000001
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015
For asic 0
SifRacRwCrcErrorCnt on Asic 0
[0]
count 0x000000c9 <<
[1]
count 0x00000001
[2]
count 0x00000000
[3]
count 0x00000001
[4]
count 0x00000000
[5]
count 0x00000001
注意：根据查看的寄存器，每种情况下的掩码可能不同。在上一个示例中，掩码可以围绕最后14位。因此，当计数器达到0x00003FFF时，它可恢复为0x00000000。
其他提示
1. 存档Crashinfo目录
堆叠中的交换机越多，意味着可以收集更多报告文件。生成的报告数量众多，这很容易让您措手不及。组织对于排除故障至关重要。如果可能，查找与每台交换机为给定事件编写报告文件的时间戳的一致性。然后，从给定交换机获取这些非常具体的报告，以便客户端不上传多个文件。也可以对crashinfo目录进行存档，以便思科用户可以发送包含相关报告的单个存档。下一个示例可以在flash目录中创建一个名为crashinfo-archive.tar的归档文件：
F340.03.10-3800-1#archive tar /create ?
WORD Tar filename
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
WORD Dir to archive files from
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
WORD File or Dir
<cr>
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:
2. 恢复不稳定堆栈
在某些情况下，您可能会在堆叠选举过程发生后启动期间看到堆叠重新加载过程中的多个成员。如果重新加载的交换机认为自己处于活动状态，则这通常会导致堆栈合并事件，并可能进入引导环路状态。在这种情况下，建议询问Cisco客户端：
- 关闭整个堆栈的电源，并牢固地重置所有堆栈电缆。
- 逐一启动堆栈中的每台成员交换机，直到所有成员都收敛到其预期状态。
- 如果某个成员无法加入堆叠，请从堆叠中将其删除，然后尝试将此成员作为独立设备启动，以进行进一步的故障排除。
3. 手动生成系统报告
手动创建的系统报告需要启用service internal。这会将系统报告作为文本文件写入，此操作可基于每台交换机完成。
3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit
3800-1#resource create_system_report ?
WORD system report filename
3800-1#resource create_system_report sysreport.txt ?
switch Switch number
<cr>
3800-1#resource create_system_report sysreport.txt switch ?
<1-1> Switch number
3800-1#resource create_system_report sysreport.txt switch 1 ?
<cr>
相关信息
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
5.0 |
03-Apr-2024 |
重新认证 |
1.0 |
14-Mar-2017 |
初始版本 |
反馈