Below are the summary of the procedure in scenario F: When we dealing with scenario F a non-impacting recovery is possible. Recovery ProcedureĬisco has published a procedure for every scenarios listed on the document. That is because we are going to show you how we were accomplished this recovery activity on our client using this scenario. On the table above, scenario F is highlighted.
You will need to use the above commands in the “Problem Analysis” section to correlate with a scenario letter below. To determine which scenario you are facing, Cisco comes up with several scenarios letter. N7K-SUP2E# slot 2 show system internal file /proc/mdstat Below is the sample of the healty compact flash on my secondary SUP2E. A healthy output will show all blocks as. In this scenario you see that the primary compact flash is not up. N7K-SUP2E# show system internal file /proc/mdstat Below is the reference table to pull up the information.
The above output shows 0xc3 which tells us that both the primary and the secondary compact flashes have failed. You can then use these keys to determine if the primary or secondary compact flash has failed, or both. N7K-SUP2E# show system internal raid | grep -A 1 "Current RAID status info"įrom this output you want to look at the number beside of 0xa5 which is 0xc3.
Below are the output from those internal command related to my case. Don’t use tab keyboard to syntax completion it won’t working. Do notice, since these commands are internal, you might need to enter it completely. If you have more than one supervisor, you may check it by adding slot x before the internal command, where x is the SUP2/2E slot position. To diagnose the current state of the compact flash cards you need to use some internal commands Cisco provides on the documentation, those are show system internal raid | grep -A 1 “Current RAID status info” and show system internal file /proc/mdstat. ISSU failures, usually when trying to failover to the standby supervisor.eUSB becomes read-only or is non-responsive.
100%Ĭonfiguration update aborted: request was aborted N7K-SUP2E# copy running-config startup-config U = Untested, A = Abort, E = Error disabled) N7K-SUP2E# show diagnostic result module 1Ĭurrent bootup diagnostic level: complete However, when the second device drops out of the array, the bootflash is remounted as read-only, meaning you cannot save configuration or files to the bootflash, or allow the standby to sync to the active in the event it is reloaded. The device can still function normally with 1/2 devices.
What can happen is over a period of months or years in service, one of these devices may be disconnected from the USB bus, causing the RAID software to drop the device from the configuration. Together they provide non-volatile repositories for boot images, startup configuration and persistent application data. BackgroundĪccording to the documentation, Each N7K supervisor 2/2E is equipped with 2 eUSB flash devices in RAID1 configuration, one primary and one mirror. Before we show the procedure and CLI output during the recovery process, We are going to show how Cisco documentation explain regarding this issue. Cisco has published a bug id CSCus22805 (CCO account required) on their bug documentation. This article describes one of the procedure to recover flash failure on Cisco Nexus 7000 using SUP2E.