简介
本文档解释了软件强制崩溃的最常见原因,并介绍了为排除故障必须收集的信息。如果您对软件强制崩溃开立 TAC 服务请求,则要求您收集的信息对解决问题非常重要。
先决条件
要求
本文档的读者应掌握以下这些主题的相关知识:
使用的组件
本文档不限于特定的软件和硬件版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。
规则
有关文件规则的更多信息请参见“ Cisco技术提示规则”。
当路由器检测到严重的不可恢复错误,并且重新加载自身以便不传送损坏的数据时,则表明出现了软件强制崩溃。绝大多数软件所致崩溃是由Cisco IOS®软件错误引起的,但也有一些平台(例如旧的Cisco 4000)可能将硬件问题报告为软件所致崩溃。
如果未重新启动或手动重新加载路由器,则 show version 命令的输出会显示以下内容:
Router uptime is 2 days, 21 hours, 30 minutes
System restarted by error - Software-forced crash, PC 0x316EF90 at 20:22:37 edt
System image file is "flash:c2500-is-l.112-15a.bin", booted via flash
如果您有思科设备的show version命令输出,可以使用思科CLI分析器(仅限于注册客户)揭示潜在问题并进行修复。
可能的原因
下表解释了软件强制崩溃的可能原因:
原因 |
说明 |
监视器超时 |
处理器使用计时器来避免出现无限循环,导致路由器停止响应。在正常操作情况下,CPU 会定期重置这些计时器。如果不这样做,将会导致系统重新加载。报告为软件强制崩溃的监视器超时与软件有关。有关其他类型的监视器超时的信息,请参阅监视器超时故障排除。系统在重新加载前阻塞在一条环路中。因此,堆栈跟踪并不一定是相关的。您可以在以下控制台日志行中识别此类型的软件强制崩溃: %SYS-2-WATCHDOG: Process aborted on watchdog timeout, process = Exec
and
*** System received a Software forced crash ***
signal = 0x17, code = 0x24, context= 0x60ceca60
|
内存不足 |
当路由器的运行内存过低时,它可能会最终重新加载自身并将其报告为软件强制崩溃。在这种情况下,控制台日志中会显示内存分配失败错误消息: %SYS-2-MALLOCFAIL: Memory allocation of 734 bytes failed from 0x6015EC84,
pool Processor, alignment 0 |
软件镜像损坏 |
在启动时,路由器可能会检测到 Cisco IOS 软件镜像已损坏、返回 compressed image checksum is incorrect 消息并尝试重新加载。在这种情况下,该事件将报告为软件强制崩溃。 Error : compressed image checksum is incorrect 0x54B2C70A
Expected a checksum of 0x04B2C70A
*** System received a Software forced crash ***
signal= 0x17, code= 0x5, context= 0x0
PC = 0x800080d4, Cause = 0x20, Status Reg = 0x3041f003
这可能是由于 Cisco IOS 软件镜像在传输到路由器期间已实际损坏所致。在这种情况下,您可以将新镜像加载到路由器上以解决问题。[有关适用于您的平台的 ROMMON 恢复方法,请参阅 Cisco 7200、7300、7400、7500、RSP7000、Catalyst 5500 RSM、uBR7100、uBR7200、uBR10000 和 12000 系列路由器的 ROMmon 恢复过程。]此外,也可能是由于内存硬件故障或软件 Bug 所致。 |
其他故障 |
处理器硬件经常会检测到导致崩溃的错误,该硬件将自动调用 ROM Monitor 中的特殊错误处理代码。ROM 监视器可以识别错误,打印消息,保存故障信息并重新启动系统。有些崩溃中什么都不会发生(请参阅监视器超时),而有些崩溃中软件会检测到问题并调用故障转储功能。这是实际的“软件强制”崩溃。在 Power PC 平台上,“software-forced crash”并非调用故障转储功能时列显的重新启动原因 - 至少到目前为止如此。在这些平台上(Cisco IOS 软件版本 12.2(12.7) 之前),这些称为“SIGTRAP”例外。在所有其他方面,SIGTRAP 和 SFC 是相同的。 |
故障排除
软件强制崩溃通常是由 Cisco IOS 软件 Bug 引起的。如果日志中显示了内存分配失败错误消息,请参阅内存问题故障排除。
如果未看到内存分配失败错误消息,并且没有在软件强制崩溃后手动重新加载或重新启动路由器,则可使用的最佳工具是思科CLI分析器(仅限于注册客户)来搜索已知的匹配漏洞ID。此工具加入了旧版堆栈解码器工具的功能。
示例:
-
从路由器收集 show stack 的输出。
-
转至思科CLI分析器(仅限注册客户)工具。
-
从下拉菜单中选择 show stack。
-
粘贴您收集的输出。
-
单击 submit。
如果 show stack 命令的解码输出与已知的软件 Bug 匹配,您将会收到最可能导致软件强制崩溃的软件 Bug 的 Bug ID。
-
单击 Bug ID 超链接查看来自 Cisco Bug 工具包(仅限注册用户)的更多 Bug 详细信息(可以帮助您确定正确的 Bug ID 匹配)。
当您确定了与错误匹配的 Bug ID 后,请参阅“fixed in”字段以确定包含该 Bug 修补程序的第一个 Cisco IOS 软件版本。
如果您不确定该 Bug ID 或不确定包含问题修补程序的 Cisco IOS 软件版本,请将 Cisco IOS 软件升级到版本系列中的最新版本。由于最新版本包含大量 Bug 的修补程序,因此这将会很有帮助。即使这不能解决问题,当您拥有最新版本的软件后,Bug 报告和解决过程也会更简洁快速。
如果在使用思科CLI分析器后,您怀疑或确实发现了仍未解决的漏洞,我们建议您打开TAC服务请求,以提供其他信息来帮助解决该漏洞,并在最终解决该漏洞时更快地发出通知。
配置过程
如果问题被确定为新的软件 Bug,Cisco TAC 工程师可能会请求您将路由器配置为收集核心转储。有时,需要使用核心转储来确定可以执行哪些操作来修复软件 Bug。
要收集核心转储中更有用的信息,建议您使用隐藏的 debug sanity 命令。这样将会导致在分配缓冲区以及释放缓冲区时,对系统中使用的每个缓冲区进行健全性检查。必须在特权 EXEC 模式(启用模式)下发出 debug sanity 命令,该命令涉及某个 CPU,但不会严重影响路由器的功能。如果要禁用健全性检查,请使用 undebug sanity 特权 EXEC 命令。
对于主内存为 16 MB 或以下的路由器,可以使用简单文件传输协议 (TFTP) 收集核心转储。如果路由器的主内存超过 16MB,建议您使用文件传输协议 (FTP)。请使用此部分中的配置过程,或者参阅创建核心转储。
完成以下步骤配置您的路由器:
-
使用 configure terminal 命令配置路由器。
-
键入 exception dump n.n.n.n,其中 n.n.n.n 为远程简单文件传输协议 (TFTP) 服务器主机的 IP 地址。
-
退出配置模式。
TFTP 服务器主机配置过程
完成以下步骤配置 TFTP 服务器主机:
-
借助所选择的编辑器在远程主机的 /tftpboot 目录下创建一个文件。文件名为 Cisco 路由器 hostname-core。
-
在 UNIX 系统上,将“hostname-core”文件的权限模式更改为全局兼容 (666)。您可以通过 copy running-config tftp 命令检查该文件中的 TFTP 设置。
-
确保 /tftpboot 下的可用磁盘空间超过 16 MB。
如果系统崩溃,exception dump 命令将会在上述文件中创建输出。如果路由器的主内存超过 16 MB,请使用文件传输协议 (FTP) 或远程复制协议 (RCP) 获取核心转储。在路由器上,配置以下项目:
exception protocol ftp
exception dump n.n.n.n
ip ftp username
ip ftp password
ip ftp source-interface
exception core-file
当您收集核心转储后,请将其上载到 ftp://ftp-sj.cisco.com/incoming(在 UNIX 中,依次键入 pftp ftp-sj.cisco.com 和 cd incoming),然后通知案例所有者并包括文件名。
建立 TAC 服务请求时要收集的信息
相关信息