目录

简介

背景

症状

诊断

场景

每个场景的恢复过程

单管理引擎故障场景

场景A（1在活动状态下失败）

场景B（2在活动设备上发生故障）

双管理引擎故障场景

场景C（0在主用设备上发生故障，1在备用设备上发生故障）

场景D（1在主用模式下发生故障，0在备用模式下发生故障）

场景E（1在主用模式下发生故障，1在备用模式下发生故障）

场景F（2在主用模式下失败，0在备用模式下失败）

场景G（0在主用设备上发生故障，2在备用设备上发生故障）

场景H（2在主用设备上发生故障，1在备用设备上发生故障）

场景I（1在主用模式下发生故障，2在备用模式下发生故障）

场景J（2在活动模式上发生故障，2在备用模式上发生故障）

摘要

常见问题解答

这个问题有没有永久性的解决办法？

为什么不能通过重新加载备用Supervisor和故障转移来恢复主用和备用上的双故障切换？

如果闪存恢复工具无法重新装载闪存，会发生什么情况？

此Bug是否也会影响Nexus 7700 Sup2E?

恢复工具是否适用于NPE映像？

ISSU到已解析版本的代码是否会解决此问题？

重置受影响的主板。Raid状态显示0xF0，但GOLD测试仍失败？

闪存故障是否会对操作产生影响？

从客户的角度出发，在监控和恢复方面，建议如何使系统正常运行？

检查GOLD compact test状态是否有任何故障，并在第一个闪存部件出现故障后立即尝试恢复。能否通过将受影响代码中的ISSU更改为固定版本来修复发生故障的eusb闪存故障？

如果使用插件或重新加载修复闪存故障，问题需要多长时间才能重新出现？

长期解决方案

简介

本文档介绍软件缺陷CSCus22805中记录的Nexus 7000 Supervisor 2/2E闪存故障问题、所有可能的故障场景和恢复步骤。

在采取任何解决方法之前，强烈建议物理接触设备，以防需要物理重新拔插。  对于某些重新加载升级，可能需要控制台访问，并且始终建议通过控制台访问Supervisor来执行这些解决方法，以观察引导过程。

如果解决方法中的任何步骤失败，请联系思科TAC获取其他可能的恢复选项。

背景

每个N7K Supervisor 2/2E都配备2个RAID1配置的eUSB闪存设备，一个主镜像和一个镜像。它们共同为启动映像、启动配置和持久应用数据提供非易失性存储库。

在服务数月或数年的时间内，其中一个设备可能会从USB总线断开，从而导致RAID软件从配置中丢弃该设备。设备仍可通过1/2设备正常运行。但是，当第二台设备从阵列中退出时，bootflash会以只读方式重新加载，这意味着您不能将配置或文件保存到bootflash，或允许备用设备在重新加载时同步到主用设备。

在双闪存故障状态下运行的系统不会受到操作影响，但需要重新加载受影响的Supervisor才能从该状态恢复。此外，对运行配置的任何更改都不会反映在启动中，而且会在断电时丢失。

症状

已发现以下症状：

- 闪存诊断故障

switch# show diagnostic result module 5

Current bootup diagnostic level: complete

Module 5: Supervisor module-2  (Standby)

Test results: (. = Pass, F = Fail, I = Incomplete,

U = Untested, A = Abort, E = Error disabled)

1) ASICRegisterCheck-------------> .

2) USB---------------------------> .

3) NVRAM-------------------------> .

4) RealTimeClock-----------------> .

5) PrimaryBootROM----------------> .

6) SecondaryBootROM--------------> .

7) CompactFlash------------------> F  <=====

8) ExternalCompactFlash----------> .

9) PwrMgmtBus--------------------> U

10) SpineControlBus---------------> .

11) SystemMgmtBus-----------------> U

12) StatusBus---------------------> U

13) StandbyFabricLoopback---------> .

14) ManagementPortLoopback--------> .

15) EOBCPortLoopback--------------> .

16) OBFL--------------------------> .

- 无法执行“copy run start”

dcd02.ptfrnyfs# copy running-config startup-config

[########################################] 100%

Configuration update aborted: request was aborted

- eUSB变为只读或无响应

switch %MODULE-4-MOD_WARNING: Module 2 (Serial number: JAF1645AHQT) reported warning

due to The compact flash power test failed in device DEV_UNDEF (device error 0x0)

switch %DEVICE_TEST-2-COMPACT_FLASH_FAIL: Module 1 has failed test CompactFlash 20

times on device Compact Flash due to error The compact flash power test failed

- ISSU故障，通常在尝试故障切换到备用Supervisor时

诊断

要诊断闪存卡的当前状态，您需要使用这些内部命令。请注意，该命令不会解析出，并且必须完整键入：

switch# show system internal raid | grep -A 1 "当前RAID状态信息"

switch# show system internal file /proc/mdstat

如果机箱中有两个管理引擎，您需要检查备用管理引擎的状态并确定您面临的故障场景。检查这一点，方法是使用“slot x”关键字预置命令，其中“x”是备用Supervisor的插槽编号。这允许您在备用设备上远程运行命令。

switch# slot 2 show system internal raid | grep -A 1 "当前RAID状态信息"

switch# slot 2 show system internal file /proc/mdstat

这些命令将提供大量RAID统计信息和事件，但您只关注当前RAID信息。

在“来自CMOS的RAID数据”行中，您需要查看0xa5之后的十六进制值。  这将显示当前可能面临问题的闪烁数量。

例如：

switch# show system internal raid | grep -A 1 "Current RAID status info"

Current RAID status info:

RAID data from CMOS = 0xa5 0xc3

在此输出中，您想要查看0xa5旁边的编号，即0xc3。  然后，您可以使用这些密钥来确定主闪存或辅助闪存是否发生故障，或者两者都发生故障。上面的输出显示0xc3，它告诉我们主压缩闪烁（闪烁）和辅助压缩闪烁（闪烁）都失败了。

0xf0

未报告故障

0xe1

主闪存失败

0xd2

备用（或镜像）闪存出现故障

0xc3

主要和备用均失败

在“/proc/mdstat”输出中，确保所有磁盘都显示为“U”，表示“U”p:

switch# slot 2 show system internal file /proc/mdstat

Personalities : [raid1]

md6 : active raid1 sdc6[0] sdb6[1]

77888 blocks [2/1] [_U]

md5 : active raid1 sdc5[0] sdb5[1]

78400 blocks [2/1] [_U]

md4 : active raid1 sdc4[0] sdb4[1]

39424 blocks [2/1] [_U]

md3 : active raid1 sdc3[0] sdb3[1]

1802240 blocks [2/1] [_U]

在此场景中，您看到主闪存未启动[_U]。正常输出将显示所有块为[UU]。

注意：两个输出都需要显示为正常（0xf0和[UU]）才能诊断主控引擎是否正常。因此，如果您在CMOS数据中看到0xf0输出，但在/proc/mdstat中看到[_U]，则该框将不正常。

场景

要确定您所面临的场景，您需要使用上述“Diagnostics”（诊断）部分中的命令与下面的Scenario Letter(场景字母)关联。  使用这些列，匹配每个管理引擎上失败紧凑闪烁的数量。

例如，如果您看到代码在活动Supervisor上是0xe1，在备用上是0xd2，则此代码在活动Supervisor上是“1 Fail”，在备用Supervisor上是“1 Fail”，即方案字母“D”。

单个管理引擎：

场景字母

主用管理引擎

活动管理引擎代码

A

1失败

0xe1或0xd2

B

2个失败

0xc3

双管理引擎：

场景字母

主用管理引擎

standby supervisor

活动管理引擎代码

备用管理引擎代码

C

0失败

1失败

0xf0

0xe1或0xd2

D

1失败

0失败

0xe1或0xd2

0xf0

E

1失败

1失败

0xe1或0xd2

0xe1或0xd2

F

2个失败

0失败

0xc3

0xf0

G

0失败

2个失败

0xf0

0xc3

H

2个失败

1失败

0xc3

0xe1或0xd2

I

1失败

2失败

0xe1或0xd2

0xc3

J

2个失败

2个失败

0xc3

0xc3

每个场景的恢复过程

单管理引擎故障场景

场景A（1在活动状态下失败）

恢复场景：

1在活动时失败

解决步骤：

在“通过/失败”场景中，使用单个管理引擎机箱，可以执行无影响的恢复。按照以下步骤操作，以便从影响最小到影响最大的恢复。

1.加载闪存恢复工具以修复bootflash。您可以从CCO下载N7000平台实用程序下的恢复工具，或使用以下链接：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

它封装在tar gz压缩文件中，请解压缩它以查找.gbin恢复工具和.pdf自述文件。查看自述文件，将.gbin工具加载到N7K的bootflash上。虽然此恢复设计为无影响，并且可以实时执行，但TAC建议在维护窗口中执行此恢复，以防出现任何意外问题。在文件位于bootflash上之后，您可以使用以下方式运行恢复工具：

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

该工具将开始运行并检测断开连接的磁盘，然后尝试使用RAID阵列重新同步这些磁盘。

您可以使用以下命令检查恢复状态：

# show system internal file /proc/mdstat

确认恢复正在继续，可能需要几分钟才能完全修复所有磁盘到[UU]状态。操作中的恢复示例如下所示：

switch# show system internal file /proc/mdstat \

Personalities : [raid1]

md6    : active raid1 sdd6[2] sdc6[0]

77888 blocks [2/1] [U_]  <-- "U_" represents the broken state

resync=DELAYED

md5    : active raid1 sdd5[2] sdc5[0]

78400 blocks [2/1] [U_]

resync=DELAYED

md4    : active raid1 sdd4[2] sdc4[0]

39424 blocks [2/1] [U_]

resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0]

1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec

unused devices: <none>

恢复完成后，应如下所示：

switch# show system internal file /proc/mdstat Personalities : [raid1]

md6 :active raid1 sdd6[1] sdc6[0]

77888 blocks [2/2] [UU]  <-- "UU" represents the fixed state

md5 :active raid1 sdd5[1] sdc5[0]

78400 blocks [2/2] [UU]

md4 :active raid1 sdd4[1] sdc4[0]

39424 blocks [2/2] [UU]

md3 :active raid1 sdd3[1] sdc3[0]

1802240 blocks [2/2] [UU]

unused devices: <none>

所有磁盘都位于[UU]中后，RAID阵列将完全备份，两个磁盘均同步。

2.如果在步骤1中闪存恢复工具未成功，则下一步是收集日志并让TAC尝试使用调试插件手动恢复磁盘，请注意，如果恢复工具未成功，则此操作可能无法成功。

收集：

show version

show module

show accounting log

show logging logfile

show system internal raid（隐藏命令）

show system internal kernel messages

show logging onboard

3.如果手动恢复不起作用，并且只有一个Supervisor，则可能需要重新加载机箱才能恢复。

*但是*，如果实验设备中有备用Supervisor，您可以尝试将其加载到备用插槽（在维护窗口中），以查看它是否可以完全同步到活动状态进入HA（高可用性）状态。

由于RAID只是单个故障磁盘，因此应该可以备用同步到主用磁盘。如果此选项可用，请参阅备用设备是否使用“show module”和“show system redundancy status”完全同步到主用设备，以验证备用设备是否处于“ha-standby”状态。这表示应可以使用“system switchover”命令进行状态切换(SSO)。在备用设备启动后，确保配置保存在外部，“copy run tftp:vdc-all”，然后使用“copy run start vdc-all”完全保存到启动。 在此之后，您可以尝试“系统切换”，这将重新加载当前主用模式并强制当前备用模式进入主用模式。在主用阵列重新加载到备用阵列后，它应自动恢复其RAID阵列。在重新加载的Supervisor处于“ha-standby”状态并执行“slot x show system internal raid”以验证所有磁盘是[UU]之后，您可以验证这一点。如果磁盘仍未完全备份，请尝试再次运行恢复工具以尝试清除任何遗留问题。如果仍不成功，您可以尝试将受影响模块设置为“out-of-service module x”，然后按“no power off module x”。 如果仍不成功，请尝试用物理方式重新拔插受影响的模块。如果仍未恢复，这可能是合法的硬件故障并需要RMA，但是您可以尝试使用密码恢复过程重新加载到交换机引导模式，并执行“init system”作为恢复的最后尝试。

如果没有备用Supervisor，则必须使用“reload”命令进行完全重新加载。在这种情况下，如果需要进行物理重新拔插，则建议对设备进行物理访问。将所有运行配置备份在外部，建议将其与系统和启动映像一起存在于USB磁盘上，以确保安全。执行重新加载且设备启动后，请检查RAID状态为[UU]，如果恢复工具看起来未完全修复，请运行该恢复工具。如果系统未启动或恢复工具仍无法运行，请物理重新拔插Supervisor模块并通过控制台观察启动过程。如果物理重新拔插无法恢复，请使用密码恢复过程中断加载程序，通过启动kickstart映像进入交换机引导模式，然后执行“init system”以尝试并重新初始化bootflash。这将擦除bootflash上的文件，因此在这些步骤之前备份所有必要的文件和配置至关重要。

如果其他所有故障均发生故障，则可能是罕见的真正硬件故障，并且主管需要是RMA，也可能需要是EFA。这就是在恢复步骤之前，必须对所有配置进行外部备份的原因，在需要紧急RMA的情况下，您必须进行所有必要配置以快速恢复系统。

场景B（2在活动设备上发生故障）

恢复场景：

2在活动接口上失败

解决步骤：

在单管理引擎出现双闪存故障的情况下，必须执行中断重新加载才能恢复。

1.使用“copy run tftp:vdc-all”。 请注意，出现双闪存故障时，由于系统重新加载为只读而导致的配置更改不会出现在启动配置中。您可以查看“show run diff | i \+”确定自双闪存故障后进行了哪些更改，这样您便知道当启动配置与重新加载时的运行配置不同时添加的内容。

请注意，在双闪存故障的Supervisor重新加载时，启动配置可能会被擦除，因此必须在外部备份配置。

2.重新加载设备，强烈建议使用控制台访问，并且可能需要物理访问。Supervisor应重新加载并修复其bootflash。系统启动后，验证两个磁盘是否都已启动并正在运行，且状态在“show system internal file /proc/mdstat”和“show system internal raid”中。 如果两个磁盘都已启动并正在运行，则恢复过程完成，您可以恢复所有先前的配置。如果恢复不成功或部分成功，请转至步骤3。

注意：在出现双闪存故障时，软件重新加载可能无法完全恢复RAID，并且可能需要运行恢复工具或后续重新加载才能恢复。几乎每次都通过物理重新拔插Supervisor模块解决了此问题。因此，如果可以对设备进行物理访问，在外部备份配置后，您可以在准备重新加载设备时通过物理重新安装Supervisor来尝试最有可能成功的快速恢复。这将完全断开管理引擎的电源，并且应该允许恢复RAID中的两个磁盘。如果物理重新拔插恢复只是部分恢复，请继续执行步骤3；如果由于系统未完全启动，导致完全恢复失败，请继续执行步骤4。

3.在部分恢复的情况下，即重新加载后，一个磁盘处于up状态，另一个磁盘仍处于down状态，则建议的下一步是尝试运行闪存恢复工具以重新同步另一个磁盘。如果恢复工具未成功，请联系TAC尝试手动恢复步骤。也可以尝试物理重新拔插Supervisor。

如果重新加载未使Supervisor完全启动，请对Supervisor模块执行物理重新拔插。请注意，在双闪存故障的情况下，通常会出现软件“reload”不能完全恢复两个磁盘的情况，因为电源未完全从模块中拔出，这通过物理重新拔插来实现。如果物理重新拔插不成功，请转至步骤4。

4.如果物理重新拔插不成功，下一步是使用密码恢复步骤进入加载程序提示符，将kickstart加载到交换机引导模式，然后执行“init system”，这将擦除bootflash并尝试修复阵列。如果init系统完成或失败但仍发现问题，请尝试再次物理重新拔插。

如果其他所有故障均发生故障，则可能是罕见的真正硬件故障，并且主管需要是RMA，也可能需要是EFA。这就是在恢复步骤之前，必须对所有配置进行外部备份的原因，在需要紧急RMA的情况下，您必须进行所有必要配置以快速恢复系统。

双管理引擎故障场景

场景C（0在主用设备上发生故障，1在备用设备上发生故障）

故障场景：

0在活动时失败

1在备用设备上发生故障

解决步骤：

在双Supervisor设置的情况下，主用设备上无闪存故障，备用设备上无单一故障，可以执行无影响的恢复。

1.由于主用设备没有发生故障，而备用设备只有一次故障，因此可以将闪存恢复工具加载到主用设备上并执行。运行该工具后，它将自动将其自身复制到备用设备并尝试重新同步阵列。  恢复工具可在此处下载：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

下载该工具、解压缩并将其上传到盒子的bootflash后，您需要执行以下命令开始恢复：

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

该工具将开始运行并检测断开连接的磁盘，然后尝试使用RAID阵列重新同步这些磁盘。

您可以使用以下命令检查恢复状态：

# show system internal file /proc/mdstat

确认恢复正在继续，可能需要几分钟才能完全修复所有磁盘到[UU]状态。操作中的恢复示例如下所示：

switch# show system internal file /proc/mdstat \

Personalities : [raid1]

md6    : active raid1 sdd6[2] sdc6[0]

77888 blocks [2/1] [U_]    <-- "U_" represents the broken state

resync=DELAYED

md5    : active raid1 sdd5[2] sdc5[0]

78400 blocks [2/1] [U_]

resync=DELAYED

md4    : active raid1 sdd4[2] sdc4[0]

39424 blocks [2/1] [U_]

resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0]

1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec

unused devices: <none>

恢复完成后，应如下所示：

switch# show system internal file /proc/mdstat Personalities : [raid1]

md6 :active raid1 sdd6[1] sdc6[0]

77888 blocks [2/2] [UU]    <-- "UU" represents the correct state

md5 :active raid1 sdd5[1] sdc5[0]

78400 blocks [2/2] [UU]

md4 :active raid1 sdd4[1] sdc4[0]

39424 blocks [2/2] [UU]

md3 :active raid1 sdd3[1] sdc3[0]

1802240 blocks [2/2] [UU]

unused devices: <none>

所有磁盘都位于[UU]中后，RAID阵列将完全备份，两个磁盘均同步。

2.如果闪存恢复工具不成功，因为主用磁盘已启动两个磁盘，则备用磁盘应该能够在重新加载时成功同步到主用磁盘。

因此，在计划的窗口中，对备用Supervisor执行“out-of-service module x”，建议对备用Supervisor进行控制台访问，以便在出现任何意外问题时观察引导过程。在Supervisor关闭后，等待几秒钟，然后对备用设备执行“no power off module x”。等到备用设备完全启动进入“ha-standby”状态。

备份备用设备后，使用“slot x show system internal raid”和“slot x show system internal file /proc/mdstat”检查RAID。

如果在重新加载后两个磁盘均未完全备份，请再次运行恢复工具。

3.如果重新加载和恢复工具不成功，建议尝试在窗口中物理地重新安装备用模块以尝试清除该情况。  如果物理重新拔插不成功，请尝试从交换机引导模式执行“init system”，方法是在引导期间执行密码恢复步骤以中断此模式。  如果仍失败，请联系TAC尝试手动恢复。

场景D（1在主用模式下发生故障，0在备用模式下发生故障）

恢复场景：

1在活动时失败

0在备用设备上发生故障

解决步骤：

在双Supervisor设置方案中，主用设备有1个闪存故障，备用设备无故障，因此可以使用闪存恢复工具执行无影响的恢复。

1.由于备用设备没有故障，而主用设备只有单个故障，因此可以将闪存恢复工具加载到主用设备上并执行。运行该工具后，它将自动将其自身复制到备用设备并尝试重新同步阵列。  恢复工具可在此处下载：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

下载工具、解压缩并将其上传到活动程序的bootflash后，您需要执行以下命令开始恢复：

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

该工具将开始运行并检测断开连接的磁盘，然后尝试使用RAID阵列重新同步这些磁盘。

您可以使用以下命令检查恢复状态：

# show system internal file /proc/mdstat

确认恢复正在继续，可能需要几分钟才能完全修复所有磁盘到[UU]状态。操作中的恢复示例如下所示：

switch# show system internal file /proc/mdstat \

Personalities : [raid1]

md6    : active raid1 sdd6[2] sdc6[0]

77888 blocks [2/1] [U_]    <-- "U_" represents the broken state

resync=DELAYED

md5    : active raid1 sdd5[2] sdc5[0]

78400 blocks [2/1] [U_]

resync=DELAYED

md4    : active raid1 sdd4[2] sdc4[0]

39424 blocks [2/1] [U_]

resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0]

1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec

unused devices: <none>

恢复完成后，应如下所示：

switch# show system internal file /proc/mdstat Personalities : [raid1]

md6 :active raid1 sdd6[1] sdc6[0]

77888 blocks [2/2] [UU]    <-- "UU" represents the correct state

md5 :active raid1 sdd5[1] sdc5[0]

78400 blocks [2/2] [UU]

md4 :active raid1 sdd4[1] sdc4[0]

39424 blocks [2/2] [UU]

md3 :active raid1 sdd3[1] sdc3[0]

1802240 blocks [2/2] [UU]

unused devices: <none>

所有磁盘都位于[UU]中后，RAID阵列将完全备份，两个磁盘均同步。

2.如果闪存恢复工具不成功，下一步是执行“系统切换”以在维护窗口中对管理引擎模块进行故障切换。

因此，在计划的窗口中，执行“system switchover”，建议使用控制台访问，以便在出现任何意外问题时观察引导过程。  等到备用设备完全启动进入“ha-standby”状态。

备份备用设备后，使用“slot x show system internal raid”和“slot x show system internal file /proc/mdstat”检查RAID。

如果在重新加载后两个磁盘均未完全备份，请再次运行恢复工具。

3.如果重新加载和恢复工具不成功，建议尝试在窗口中物理地重新安装备用模块以尝试清除该情况。  如果物理重新拔插不成功，请尝试从交换机引导模式执行“init system”，方法是在引导期间执行密码恢复步骤以中断此模式。  如果仍失败，请联系TAC尝试手动恢复。

场景E（1在主用模式下发生故障，1在备用模式下发生故障）

恢复场景：

1在活动时失败

1在备用设备上发生故障

解决步骤：

在主用和备用交换机上发生单闪存故障时，仍可实现不影响性能的解决方法。

1.由于没有管理引擎处于只读状态，第一步是尝试使用快速恢复工具。

恢复工具可在此处下载：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

下载工具、解压缩并将其上传到活动程序的bootflash后，您需要执行以下命令开始恢复：

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

它将自动检测活动磁盘上断开的磁盘并尝试修复，以及自动将自身复制到备用磁盘并检测和纠正其中的故障。

您可以使用以下命令检查恢复状态：

# show system internal file /proc/mdstat

确认恢复正在继续，可能需要几分钟才能完全修复所有磁盘到[UU]状态。操作中的恢复示例如下所示：

switch# show system internal file /proc/mdstat \

Personalities : [raid1]

md6    : active raid1 sdd6[2] sdc6[0]

77888 blocks [2/1] [U_]    <-- "U_" represents the broken state

resync=DELAYED

md5    : active raid1 sdd5[2] sdc5[0]

78400 blocks [2/1] [U_]

resync=DELAYED

md4    : active raid1 sdd4[2] sdc4[0]

39424 blocks [2/1] [U_]

resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0]

1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec

unused devices: <none>

恢复完成后，应如下所示：

switch# show system internal file /proc/mdstat Personalities : [raid1]

md6 :active raid1 sdd6[1] sdc6[0]

77888 blocks [2/2] [UU]    <-- "UU" represents the correct state

md5 :active raid1 sdd5[1] sdc5[0]

78400 blocks [2/2] [UU]

md4 :active raid1 sdd4[1] sdc4[0]

39424 blocks [2/2] [UU]

md3 :active raid1 sdd3[1] sdc3[0]

1802240 blocks [2/2] [UU]

unused devices: <none>

所有磁盘都位于[UU]中后，RAID阵列将完全备份，两个磁盘均同步。

如果两个管理引擎恢复到[UU]状态，则恢复完成。  如果恢复为部分恢复或未成功，请转至步骤2。

2.如果恢复工具未成功，请确定模块上RAID的当前状态。如果两个交换机上仍有一个闪存故障，则尝试“系统切换”，这将重新加载当前主用模式，并强制备用模式成为主用模式。

将上一个主用设备重新加载回“ha-standby”后，检查其RAID状态，因为在重新加载期间应将其恢复。

如果Supervisor在切换后成功恢复，您可以再次尝试运行闪存恢复工具以尝试修复当前主用Supervisor上的单个磁盘故障，或者尝试另一个“系统切换”以重新加载当前主用并强制将之前已修复的主用和当前备用状态恢复为主用角色。验证重新加载的Supervisor是否再次修复了两个磁盘，如有必要，请重新运行恢复工具。

3.如果在此过程中，切换未修复RAID，请对备用模块执行“服务中断模块x”，然后执行“no power off module x”以完全移除模块并重新为其供电。

如果停止服务不成功，尝试物理重新拔插备用。

如果在运行恢复工具后，一个管理引擎恢复其RAID，而另一个管理引擎仍有故障，则强制发生单个故障的管理引擎备用，如有必要，执行“系统切换”。如果只有一个故障的Supervisor是

已处于备用状态，请对备用模块执行“服务中断模块x”操作，并执行“无电源模块x”操作，以完全移除模块并重新为其供电。如果仍然无法恢复，请尝试物理重新拔插模块。如果重新拔插无法修复，

使用密码恢复过程进入交换机引导提示符，然后执行“init system”以重新初始化bootflash。如果仍失败，请让TAC尝试手动恢复。

注意：如果在任何时候备用设备都停滞在“通电”状态而不是“高待机状态”，如果无法按照上述步骤完全启动备用设备，则需要重新加载机箱。

场景 F（2在活动状态发生故障，0在备用状态发生故障）

恢复场景：

2在活动接口上失败

0在备用设备上发生故障

解决步骤：

如果主用管理引擎上有2个故障，备用管理引擎上有0个故障，则有可能进行无影响的恢复，具体取决于由于备用管理引擎无法将其运行配置与主用管理引擎同步而添加了多少运行配置。

恢复过程将是：从主用管理引擎复制当前运行配置，故障切换至正常备用管理引擎，将缺少的运行配置复制到新的主用管理引擎，手动使以前的主用管理引擎联机，然后运行恢复工具。

1.  使用“copy running-config tftp:vdc-all”。 请注意，出现双闪存故障时，由于系统重新加载为只读而导致的配置更改不会出现在启动配置中。您可以查看受影响模块的“show system internal raid”，以确定第二个磁盘何时发生故障，即系统变为只读状态。从那里，您可以查看每个VDC的“show accounting log”，以确定自双闪存故障以来进行了哪些更改，这样您就会知道在重新加载后启动配置持续的情况下要添加什么。

请注意，在双闪存故障的Supervisor重新加载时，启动配置可能会被擦除，因此必须在外部备份配置。

2.  将运行配置从活动Supervisor复制出来后，最好将其与启动配置进行比较，以查看自上次保存以来发生了哪些更改。  这可以通过“show startup-configuration”看到。  当然，差异将完全取决于环境，但最好了解当备用设备作为主用设备联机时可能缺少什么。  最好在记事本中复制这些差异，以便在切换后快速将其添加到新的活动Supervisor。

3.  评估差异之后，您需要执行管理引擎切换。  TAC建议在维护时段期间完成此操作，因为可能会出现未知问题。  执行到备用设备的故障切换的命令将是“system switchover”。

4.  切换应会非常快地进行，并且新的备用设备将开始重新启动。  在此期间，您需要将所有缺失的配置重新添加到新的主用配置中。  这可以通过从TFTP服务器复制配置（或以前保存的任何位置），或者只在CLI中手动添加配置来实现。  在大多数情况下，缺少的配置非常短，而CLI选项将是最可行的。

5.  一段时间后，新的备用Supervisor可能会以“ha-standby”状态重新联机，但通常会出现的情况是，它将停滞在“powered-up”状态。  可使用“show module”命令并参考模块旁边的“Status”列查看状态。

如果新的备用设备处于“通电”状态，则需要手动使其重新联机。  这可以通过发出以下命令来完成，其中“x”是停滞在“通电”状态的备用模块：

(config)# out-of-service module x

(config)#no poweroff module x

6.  一旦备用设备在“ha-standby”状态下重新联机，您需要运行恢复工具以确保恢复完成。  可通过以下链接下载该工具：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

下载该工具、解压缩并将其上传到盒子的bootflash后，您需要执行以下命令开始恢复：

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

该工具将开始运行并检测断开连接的磁盘，然后尝试使用RAID阵列重新同步这些磁盘。

您可以使用以下命令检查恢复状态：

# show system internal file /proc/mdstat

确认恢复正在继续，可能需要几分钟才能完全修复所有磁盘到[UU]状态。操作中的恢复示例如下所示：

switch# show system internal file /proc/mdstat \

Personalities : [raid1]

md6    : active raid1 sdd6[2] sdc6[0]

77888 blocks [2/1] [U_]    <-- "U_" represents the broken state

resync=DELAYED

md5    : active raid1 sdd5[2] sdc5[0]

78400 blocks [2/1] [U_]

resync=DELAYED

md4    : active raid1 sdd4[2] sdc4[0]

39424 blocks [2/1] [U_]

resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0]

1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec

unused devices: <none>

恢复完成后，应如下所示：

switch# show system internal file /proc/mdstat

Personalities : [raid1]

md6 :active raid1 sdd6[1] sdc6[0]

77888 blocks [2/2] [UU]    <-- "UU" represents the correct state

md5 :active raid1 sdd5[1] sdc5[0]

78400 blocks [2/2] [UU]

md4 :active raid1 sdd4[1] sdc4[0]

39424 blocks [2/2] [UU]

md3 :active raid1 sdd3[1] sdc3[0]

1802240 blocks [2/2] [UU]

unused devices: <none>

所有磁盘都位于[UU]中后，RAID阵列将完全备份，两个磁盘均同步。

场景G（0在主用设备上发生故障，2在备用设备上发生故障）

0在活动模式上发生故障，2在备用模式上发生故障

恢复场景：

0在活动时失败

2在备用设备上发生故障

解决步骤：

在主用管理引擎上有0个故障，备用管理引擎上有2个故障，可以实现无影响的恢复。

恢复过程将是重新加载备用设备。

1.在双闪存故障的管理引擎中，通常可以看到，软件“reload module x”只能部分修复RAID或在重新启动时使其停电。

因此，建议使用双闪存故障物理重新拔插Supervisor以完全移除并重新接通模块的电源，或者您可以执行以下操作（x表示备用插槽编号）：

# out-of-service module x

# no power off module x

如果您看到备用设备一直停滞在通电状态，并最终在上述步骤后保持电源循环，这可能是由于主用设备重新加载备用设备导致无法及时启动。

这可能是由于正在引导的备用设备尝试重新初始化其bootflash/RAID（可能需要10分钟），但它在完成之前一直被主用设备重置。

要解决此问题，请使用“x”为停留在通电状态的备用插槽#配置以下内容：

(config)# system standby manual-boot

(config)# reload module x force-dnld

上述操作将使主用设备不会自动重置备用设备，然后重新加载备用设备并强制其从主用设备同步其映像。

等待10-15分钟，查看备用设备是否最终能够进入ha-standby状态。当它处于ha-standby状态后，使用以下命令重新启用备用设备的自动重启：

(config)# system no standby manual-boot

6.  一旦备用设备在“ha-standby”状态下重新联机，您需要运行恢复工具以确保恢复完成。  可通过以下链接下载该工具：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

下载该工具、解压缩并将其上传到盒子的bootflash后，您需要执行以下命令开始恢复：

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

该工具将开始运行并检测断开连接的磁盘，然后尝试使用RAID阵列重新同步这些磁盘。

您可以使用以下命令检查恢复状态：

# show system internal file /proc/mdstat

确认恢复正在继续，可能需要几分钟才能完全修复所有磁盘到[UU]状态。操作中的恢复示例如下所示：

switch# show system internal file /proc/mdstat

Personalities : [raid1]

md6    : active raid1 sdd6[2] sdc6[0]

77888 blocks [2/1] [U_]    <-- "U_" represents the broken state

resync=DELAYED

md5    : active raid1 sdd5[2] sdc5[0]

78400 blocks [2/1] [U_]

resync=DELAYED

md4    : active raid1 sdd4[2] sdc4[0]

39424 blocks [2/1] [U_]

resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0]

1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec

unused devices: <none>

恢复完成后，应如下所示：

switch# show system internal file /proc/mdstat Personalities : [raid1]

md6 :active raid1 sdd6[1] sdc6[0]

77888 blocks [2/2] [UU]    <-- "UU" represents the correct state

md5 :active raid1 sdd5[1] sdc5[0]

78400 blocks [2/2] [UU]

md4 :active raid1 sdd4[1] sdc4[0]

39424 blocks [2/2] [UU]

md3 :active raid1 sdd3[1] sdc3[0]

1802240 blocks [2/2] [UU]

unused devices: <none>

所有磁盘都位于[UU]中后，RAID阵列将完全备份，两个磁盘均同步。

场景H(2在主用设备上发生故障，1在备用设备上发生故障)

2在“活动”模式中发生故障，1在“备用”模式中发生故障

恢复场景：

2在活动接口上失败

1在备用设备上发生故障

解决步骤：

如果主用管理引擎上有2个故障，备用管理引擎上有1个故障，则有可能进行无影响的恢复，具体取决于由于备用管理引擎无法将其运行配置与主用管理引擎同步而添加了多少运行配置。

恢复过程将是：从主用管理引擎备份当前运行配置，故障切换至正常备用管理引擎，将缺少的运行配置复制到新的主用管理引擎，手动使以前的主用管理引擎联机，然后运行恢复工具。

1.  使用“copy running-config tftp:vdc-all”。 请注意，出现双闪存故障时，由于系统重新加载为只读而导致的配置更改不会出现在启动配置中。您可以查看受影响模块的“show system internal raid”，以确定第二个磁盘何时发生故障，即系统变为只读状态。从那里，您可以查看每个VDC的“show accounting log”，以确定自双闪存故障以来进行了哪些更改，这样您就会知道重新加载后如果启动配置继续存在，要添加什么。

请注意，在双闪存故障的Supervisor重新加载时，启动配置可能会被擦除，因此必须在外部备份配置。

2.  将运行配置从活动Supervisor复制出来后，最好将其与启动配置进行比较，以查看自上次保存以来发生了哪些更改。  这可以在“show startup-configuration”中看到。  当然，差异将完全取决于环境，但最好了解当备用设备作为主用设备联机时可能缺少什么。  最好在记事本中复制这些差异，以便在切换后快速将其添加到新的活动Supervisor。

3.  评估差异之后，您需要执行管理引擎切换。  TAC建议在维护时段期间完成此操作，因为可能会出现未知问题。  执行到备用设备的故障切换的命令将是“系统切换”。

4.  切换应会非常快地进行，并且新的备用设备将开始重新启动。  在此期间，您需要将所有缺失的配置重新添加到新的主用配置中。  这可以通过从TFTP服务器复制配置（或以前保存的任何位置）完成，或者只需在CLI中手动添加配置，不要直接从tftp复制到运行配置，先复制到bootflash，然后再复制到运行配置。  在大多数情况下，缺少的配置非常短，而CLI选项将是最可行的。

5.  一段时间后，新的备用Supervisor可能会以“ha-standby”状态重新联机，但通常会出现的情况是，它将停滞在“powered-up”状态。  可使用“show module”命令并参考模块旁边的“Status”列来查看状态。

如果新的备用设备处于“通电”状态，则需要手动使其重新联机。  这可以通过发出以下命令来完成，其中“x”是停滞在“通电”状态的备用模块：

(config)#服务中断模块

(config)#no poweroff module x

如果您看到备用设备一直停滞在通电状态，并最终在上述步骤后保持电源循环，这可能是由于主用设备重新加载备用设备导致无法及时启动。

这可能是由于正在引导的备用设备尝试重新初始化其bootflash/RAID（可能需要10分钟），但它在完成之前一直被主用设备重置。

要解决此问题，请使用“x”为停留在通电状态的备用插槽#配置以下内容：

(config)# system standby manual-boot

(config)# reload module x force-dnld

上述操作将使主用设备不会自动重置备用设备，然后重新加载备用设备并强制其从主用设备同步其映像。

等待10-15分钟，查看备用设备是否最终能够进入ha-standby状态。当它处于ha-standby状态后，使用以下命令重新启用备用设备的自动重启：

(config)# system no standby manual-boot

6.  一旦备用设备在“ha-standby”状态下重新联机，您需要运行恢复工具以确保恢复完成，并修复主用设备上的单个磁盘故障。  可通过以下链接下载该工具：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

下载该工具、解压缩并将其上传到盒子的bootflash后，您需要执行以下命令开始恢复：

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

该工具将开始运行并检测断开连接的磁盘，然后尝试使用RAID阵列重新同步这些磁盘。

您可以使用以下命令检查恢复状态：

# show system internal file /proc/mdstat

确认恢复正在继续，可能需要几分钟才能完全修复所有磁盘到[UU]状态。操作中的恢复示例如下所示：

switch# show system internal file /proc/mdstat \

Personalities : [raid1]

md6    : active raid1 sdd6[2] sdc6[0]

77888 blocks [2/1] [U_]    <-- "U_" represents the broken state

resync=DELAYED

md5    : active raid1 sdd5[2] sdc5[0]

78400 blocks [2/1] [U_]

resync=DELAYED

md4    : active raid1 sdd4[2] sdc4[0]

39424 blocks [2/1] [U_]

resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0]

1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec

unused devices: <none>

恢复完成后，应如下所示：

switch# show system internal file /proc/mdstat Personalities : [raid1]

md6 :active raid1 sdd6[1] sdc6[0]

77888 blocks [2/2] [UU]    <-- "UU" represents the correct state

md5 :active raid1 sdd5[1] sdc5[0]

78400 blocks [2/2] [UU]

md4 :active raid1 sdd4[1] sdc4[0]

39424 blocks [2/2] [UU]

md3 :active raid1 sdd3[1] sdc3[0]

1802240 blocks [2/2] [UU]

unused devices: <none>

所有磁盘都位于[UU]中后，RAID阵列将完全备份，两个磁盘均同步。

如果恢复工具未恢复出现单个故障的当前主用状态，则尝试另一个“系统切换”，确保当前备用状态处于“ha-standby”状态。  如果仍不成功，请联系思科TAC

场景I（1在主用模式下发生故障，2在备用模式下发生故障）

恢复场景：

1在活动时失败

2在备用设备上发生故障

解决步骤：

在双管理引擎场景中，主用管理引擎上有1个故障，备用管理引擎上有2个故障，因此可以执行无影响恢复，但在很多情况下，可能需要重新加载。

此过程将首先备份所有运行配置，然后尝试使用恢复工具恢复主用上的故障闪存，如果成功，您将手动重新加载备用闪存并再次运行恢复工具。  如果初始恢复尝试无法恢复活动上的失败闪存，则必须让TAC尝试使用调试插件进行手动恢复。

1.  使用“copy running-config tftp:vdc-all”。  如果环境中未设置TFTP服务器，也可以将运行配置复制到本地USB盘中。

2.  备份当前运行配置后，您需要运行恢复工具以尝试恢复活动上的故障闪存。  可通过以下链接下载该工具：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

下载该工具、解压缩并将其上传到盒子的bootflash后，您需要执行以下命令开始恢复：

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

该工具将开始运行并检测断开连接的磁盘，然后尝试使用RAID阵列重新同步这些磁盘。

您可以使用以下命令检查恢复状态：

# show system internal file /proc/mdstat

确认恢复正在继续，可能需要几分钟才能完全修复所有磁盘到[UU]状态。操作中的恢复示例如下所示：

switch# show system internal file /proc/mdstat \

Personalities : [raid1]

md6    : active raid1 sdd6[2] sdc6[0]

77888 blocks [2/1] [U_]    <-- "U_" represents the broken state

resync=DELAYED

md5    : active raid1 sdd5[2] sdc5[0]

78400 blocks [2/1] [U_]

resync=DELAYED

md4    : active raid1 sdd4[2] sdc4[0]

39424 blocks [2/1] [U_]

resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0]

1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec

unused devices: <none>

恢复完成后，应如下所示：

switch# show system internal file /proc/mdstat

Personalities : [raid1]

md6 :active raid1 sdd6[1] sdc6[0]

77888 blocks [2/2] [UU]    <-- "UU" represents the correct state

md5 :active raid1 sdd5[1] sdc5[0]

78400 blocks [2/2] [UU]

md4 :active raid1 sdd4[1] sdc4[0]

39424 blocks [2/2] [UU]

md3 :active raid1 sdd3[1] sdc3[0]

1802240 blocks [2/2] [UU]

unused devices: <none>

所有磁盘都位于[UU]中后，RAID阵列将完全备份，两个磁盘均同步。

3.  如果在步骤2中运行恢复工具后，无法恢复活动Supervisor上发生故障的闪存，必须联系TAC尝试使用Linux调试插件进行手动恢复。

4.  检验活动状态下两个闪烁均显示为“[UU]”后，您可以继续手动重新启动备用Supervisor。  这可以通过发出以下命令来完成，其中“x”是停滞在“通电”状态的备用模块：

(config)# out-of-service module x

(config)#no poweroff module x

这应该使备用Supervisor恢复到“ha-standby”状态(通过查看“show module”输出中的Status列检查此情况)。  如果此操作成功，请继续步骤6，如果不成功，请尝试步骤5中概述的步骤。

5.  如果您看到备用设备一直停滞在通电状态，并最终在上述步骤后保持电源循环，这可能是由于主用设备重新加载备用设备导致无法及时启动。  这可能是由于正在引导的备用设备尝试重新初始化其bootflash/RAID（可能需要10分钟），但它在完成之前一直被主用设备重置。  要解决此问题，请使用“x”为停留在通电状态的备用插槽#配置以下内容：

(config)# system standby manual-boot

(config)# reload module x force-dnld

上述操作将使主用设备不会自动重置备用设备，然后重新加载备用设备并强制其从主用设备同步其映像。

等待10-15分钟，查看备用设备是否最终能够进入ha-standby状态。当它处于ha-standby状态后，使用以下命令重新启用备用设备的自动重启：

(config)# system no standby manual-boot

6.  一旦备用设备在“ha-standby”状态下重新联机，您需要运行恢复工具以确保恢复完成。  您可以为此步骤运行在主用设备上使用的相同工具，由于恢复工具在主用和备用设备上运行，因此无需额外下载。

场景 J（2在活动状态上失败，2在备用状态上失败）

恢复场景：

2在活动接口上失败

2在备用设备上发生故障

解决步骤：

在双管理引擎出现双闪存故障时，必须执行中断重新加载才能进行恢复。请按照以下步骤解决问题：

1.使用“copy running-config tftp:vdc-all”。 请注意，出现双闪存故障时，由于系统重新加载为只读而导致的配置更改不会出现在启动配置中。您可以查看受影响模块的“show system internal raid”，以确定第二个磁盘何时发生故障，即系统变为只读状态。从那里，您可以查看每个VDC的“show accounting log”，以确定自双闪存故障以来进行了哪些更改，这样您就会知道在重新加载后启动配置持续的情况下要添加什么。

请注意，在双闪存故障的Supervisor重新加载时，启动配置可能会被擦除，因此必须在外部备份配置。

2.重新加载设备，强烈建议使用控制台访问，并且可能需要物理访问。Supervisor应重新加载并修复其bootflash。系统启动后，验证两个磁盘是否都已启动并正在运行，且状态在“show system internal file /proc/mdstat”和“show system internal raid”中。 如果两个磁盘都已启动并正在运行，则恢复过程完成，您可以恢复所有先前的配置。如果恢复不成功或部分成功，请转至步骤3。

注意：在出现双闪存故障时，软件“reload”可能无法完全恢复RAID，并且可能需要运行恢复工具或后续重新加载才能恢复。几乎每次都通过物理重新拔插Supervisor模块解决了此问题。因此，如果可以对设备进行物理访问，在外部备份配置后，您可以在准备重新加载设备时通过物理重新安装Supervisor来尝试最有可能成功的快速恢复。这将完全断开管理引擎的电源，并且应该允许恢复RAID中的两个磁盘。如果物理重新拔插恢复只是部分恢复，请继续执行步骤3；如果由于系统未完全启动，导致完全恢复失败，请继续执行步骤4。

3.在部分恢复的情况下，即重新加载后，一个磁盘处于up状态，另一个磁盘仍处于down状态，则建议的下一步是尝试运行闪存恢复工具以重新同步另一个磁盘。如果恢复工具未成功，请联系TAC尝试手动恢复步骤。也可以尝试物理重新拔插Supervisor。  可从以下链接下载恢复工具：

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

如果重新加载未导致两个Supervisor完全启动，请对Supervisor模块执行物理重新拔插。请注意，在双闪存故障的情况下，通常会出现软件“reload”不能完全恢复两个磁盘的情况，因为电源未完全从模块中拔出，这通过物理重新拔插来实现。如果物理重新拔插不成功，请转至步骤4。

4.如果物理重新拔插不成功，下一步是使用密码恢复步骤进入加载程序提示符，将kickstart加载到交换机引导模式，然后执行“init system”，这将擦除bootflash并尝试修复阵列。如果init系统完成或失败但仍发现问题，请尝试再次物理重新拔插。

如果完成上述所有步骤后恢复不成功，则极有可能出现真正的硬件故障，需要通过RMA更换管理引擎。这就是在恢复步骤之前，必须对所有配置进行外部备份的原因，在需要紧急RMA的情况下，您必须进行所有必要配置以快速恢复系统。

摘要

常见问题解答

这个问题有没有永久性的解决办法？

请参见下面的长期解决方案部分。

为什么不能通过重新加载备用Supervisor和故障转移来恢复主用和备用上的双故障切换？

无法这样做的原因是，为了允许备用Supervisor在“ha-standby”状态下启动，主用Supervisor必须向其闪存（SNMP信息等）中写入若干内容，如果它自身有双闪存故障，则无法执行此操作。

如果闪存恢复工具无法重新装载闪存，会发生什么情况？

请联系Cisco TAC了解此场景中的选项。

此Bug是否也会影响Nexus 7700 Sup2E?

N7700 Sup2E - CSCuv64056有一个单独的缺陷。  恢复工具在N7700上不起作用。

恢复工具是否适用于NPE映像？

恢复工具不适用于NPE映像。

ISSU到已解析版本的代码是否会解决此问题？

不可以。 ISSU将使用管理引擎切换，由于紧凑型闪存故障，该功能可能无法正常运行。

重置受影响的主板。Raid状态显示0xF0，但GOLD测试仍失败？

RAID状态位在应用自动恢复后板重置后重置。

但是，并非所有故障条件都能自动恢复。

如果RAID状态位未打印为[2/2] [UU]，则恢复未完成。

执行列出的恢复步骤

闪存故障是否会对操作产生影响？

否，但系统可能无法在电源故障时重新启动。启动配置也会丢失。

从客户的角度出发，在监控和恢复方面，建议如何使系统正常运行？

检查GOLD compact test状态是否有任何故障，并在第一个闪存部件出现故障后立即尝试恢复。

能否通过将受影响代码中的ISSU更改为固定版本来修复发生故障的eusb闪存故障？

ISSU无法修复发生故障的eUSB。最佳选择是在管理引擎上运行单个eusb故障的恢复工具，或在双eusb故障时重新加载sup。

一旦问题得到纠正，则进行升级。针对CSCus22805的修复程序有助于仅纠正单个eusb故障，它通过定期扫描系统并尝试使用脚本重新唤醒无法访问的或只读的eUSB来修复此问题。

Supervisor上同时出现两个eusb闪存故障的情况非常少见，因此这种解决方法将非常有效。

如果使用插件或重新加载修复闪存故障，问题需要多长时间才能重新出现？

通常，正常运行时间较长。这不能准确量化，范围可能在一年或更长。最重要的是，在读取写入方面，eusb闪存上的压力越大，系统进入此场景的概率越高。

Show system internal raid在不同部分显示两次闪存状态。这些部分也不一致

第一部分显示当前状态，第二部分显示启动状态。

当前状态是重要的，它应始终显示为UU。

长期解决方案

此缺陷在6.2(14)中有解决方法，但固件修复已添加到6.2(16)和7.2(x)及更高版本。

建议升级到包含固件修复程序的版本，以完全解决此问题。

如果您无法升级到NXOS的固定版本，有两种可能的解决方案。

解决方案1是每周使用调度程序前瞻性地运行闪存恢复工具。  在bootflash中使用闪存恢复工具配置以下调度程序：

功能调度程序

计划程序作业名称Flash_Job

copy bootflash:/n7000-s2-flash-recovery-tool.10.0.2.gbin bootflash:/flash_recovery_tool_copy

load bootflash:/flash_recovery_tool_copy

退出

scheduler schedule name Flash_Recovery

作业名称Flash_Job

时间每周7

注意：

- 闪存恢复需要具有相同的名称并且位于bootflash中。

- “time weekly 7”配置中的7表示一周中的一天，在本例中为星期六。

- Cisco建议运行闪存恢复工具的最大频率为每周一次。

解决方案2在以下技术说明链接中提供