In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beschreibt das Compact-Flash-Problem beim Nexus 7000 Supervisor 2/2E, das im Softwarefehler CSCus22805 dokumentiert ist, alle möglichen Fehlerszenarien und die Wiederherstellungsschritte.
Vor einer Problemumgehung wird dringend empfohlen, physischen Zugriff auf das Gerät zu haben, falls ein physischer Wiedereinbau erforderlich ist. Bei einigen Aktualisierungen zum erneuten Laden ist möglicherweise Konsolenzugriff erforderlich, und es wird immer empfohlen, diese Problemumgehungen mit Konsolenzugriff auf den Supervisor durchzuführen, um den Bootvorgang zu beobachten.
Wenn einer der Schritte zur Problemumgehung fehlschlägt, wenden Sie sich an Cisco TAC, um weitere Optionen zur Wiederherstellung zu erhalten.
Jeder N7K Supervisor 2/2E ist mit zwei eUSB-Flash-Geräten in RAID1-Konfiguration, einem primären und einem Mirror ausgestattet. Zusammen bieten sie nichtflüchtige Repositorys für Boot-Images, Startkonfigurationen und persistente Anwendungsdaten.
Es kann passieren, dass eines dieser Geräte über einen Zeitraum von Monaten oder Jahren im Einsatz vom USB-Bus getrennt wird, wodurch die RAID-Software das Gerät aus der Konfiguration entfernt. Das Gerät kann mit 1/2 Geräten weiterhin normal funktionieren. Wenn jedoch das zweite Gerät aus dem Array ausfällt, wird der Bootflash als schreibgeschützt wiederhergestellt, d. h. Sie können keine Konfigurationen oder Dateien im Bootflash speichern oder dem Standby-Gerät gestatten, sich mit dem aktiven Gerät zu synchronisieren, falls es neu geladen wird.
Es gibt keine Auswirkungen auf den Betrieb von Systemen, die in einem Dual-Flash-Fehlerzustand ausgeführt werden, jedoch ist ein Neuladen des betroffenen Supervisors erforderlich, um diesen Zustand zu beheben. Außerdem werden Änderungen an der aktuellen Konfiguration beim Start nicht berücksichtigt und gehen bei einem Stromausfall verloren.
Diese Symptome wurden beobachtet:
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--------------------------> .
dcd02.ptfrnyfs# copy running-config startup-config
[########################################] 100%
Configuration update aborted: request was aborted
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
Um den aktuellen Zustand der Compact-Flash-Karten zu diagnostizieren, müssen Sie diese internen Befehle verwenden. Beachten Sie, dass der Befehl nicht analysiert wird und vollständig ausgetippt werden muss:
switch# System-interne RAID anzeigen | grep -A 1 "Aktuelle RAID-Statusinformationen"
switch# show system internal file /proc/mdstat
Wenn sich im Chassis zwei Supervisoren befinden, müssen Sie auch den Status des Standby-Supervisors überprüfen, um festzustellen, bei welchem Fehlerszenario es sich um einen Fehler handelt. Überprüfen Sie dies, indem Sie dem Befehl das Schlüsselwort "slot x" vorstellen, wobei "x" die Steckplatznummer des Standby-Supervisors ist. Dadurch können Sie den Befehl im Standby-Modus remote ausführen.
switch# slot 2 show system internal raid | grep -A 1 "Aktuelle RAID-Statusinformationen"
switch# slot 2 show system internal file /proc/mdstat
Diese Befehle liefern viele RAID-Statistiken und -Ereignisse, Sie sind jedoch nur mit den aktuellen RAID-Informationen beschäftigt.
In der Zeile "RAID-Daten von CMOS" soll der Hexadezimalwert nach 0xa5 betrachtet werden. Dies zeigt, wie viele Blitze derzeit mit einem Problem konfrontiert sind.
Beispiele:
switch# show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xc3
Von dieser Ausgabe möchten Sie die Zahl neben 0xa5 betrachten, die 0xc3 ist. Mit diesen Tasten können Sie feststellen, ob der primäre oder sekundäre Compact Flash-Speicher ausgefallen ist oder beide. Die obige Ausgabe zeigt 0xc3, was uns sagt, dass sowohl der primäre als auch der sekundäre Compact-Flash fehlgeschlagen sind.
0xf0 | Keine Fehler gemeldet |
0x1 | Primärer Flash-Fehler |
0xd2 | Alternativer Flash-Speicher (oder Spiegelungs-Flash) fehlgeschlagen |
0xc3 | Sowohl primäre als auch alternative Fehler |
Stellen Sie in der Ausgabe "/proc/mdstat" sicher, dass alle Festplatten als "U" angezeigt werden, was "U"p darstellt:
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]
In diesem Szenario sehen Sie, dass der primäre Compact-Flash-Speicher nicht aktiv ist [_U]. Eine fehlerfreie Ausgabe zeigt alle Blöcke als [UU] an.
Anmerkung: Beide Ausgaben müssen als fehlerfrei (0xf0 und [UU]) angezeigt werden, damit der Supervisor als fehlerfrei diagnostiziert werden kann. Wenn Sie also eine 0xf0-Ausgabe in den CMOS-Daten sehen, aber eine [_U] in /proc/mdstat, ist das Feld ungesund.
Um zu bestimmen, mit welchem Szenario Sie konfrontiert werden, müssen Sie die oben genannten Befehle im Abschnitt "Diagnose" verwenden, um sie mit einem unten stehenden Szenariobuchstaben zu korrelieren. Ordnen Sie mithilfe der Spalten die Anzahl der fehlerhaften Compact-Blitze auf jedem Supervisor zu.
Wenn Sie z. B. sehen, dass der Code 0xe1 auf dem aktiven Supervisor und 0xd2 auf dem Standby-Gerät lautet, wäre dies "1 Fail" auf dem aktiven Gerät und "1 Fail" auf dem Standby-Gerät, was dem Szenariobuchstaben "D" entspricht.
Ein Supervisor:
Szenarioschreiben | Aktiver Supervisor | Aktiver Supervisor-Code |
A | 1 fehlgeschlagen | 0xe1 oder 0xd2 |
B | 2 fehlgeschlagen | 0xc3 |
Zwei Supervisoren:
Szenarioschreiben | Aktiver Supervisor | Standby-Supervisor | Aktiver Supervisor-Code | Standby-Supervisor-Code |
C | 0 Fehlschlag | 1 fehlgeschlagen | 0xf0 | 0xe1 oder 0xd2 |
G | 1 fehlgeschlagen | 0 Fehlschlag | 0xe1 oder 0xd2 | 0xf0 |
O | 1 fehlgeschlagen | 1 fehlgeschlagen | 0xe1 oder 0xd2 | 0xe1 oder 0xd2 |
F | 2 fehlgeschlagen | 0 Fehlschlag | 0xc3 | 0xf0 |
G | 0 Fehlschlag | 2 fehlgeschlagen | 0xf0 | 0xc3 |
H | 2 fehlgeschlagen | 1 fehlgeschlagen | 0xc3 | 0xe1 oder 0xd2 |
I | 1 fehlgeschlagen | 2 fehlgeschlagen | 0xe1 oder 0xd2 | 0xc3 |
J | 2 fehlgeschlagen | 2 fehlgeschlagen | 0xc3 | 0xc3 |
Wiederherstellungsszenario:
1 Fehlschlag bei aktiven Systemen
Lösungsschritte:
1. Laden Sie Flash-Wiederherstellungstool, um bootflash zu reparieren. Sie können das Wiederherstellungstool von CCO unter Dienstprogramme für die N7000-Plattform herunterladen oder den folgenden Link verwenden:
Es ist in eine tar gz komprimierte Datei verpackt, entpacken Sie es, um das .gbin Wiederherstellungstool und eine .pdf-Readme zu finden. Überprüfen Sie die Readme-Datei, und laden Sie das Tool .gbin auf den Bootflash des N7K. Diese Wiederherstellung hat keine Auswirkungen und kann live durchgeführt werden. Das TAC empfiehlt jedoch die Durchführung in einem Wartungsfenster, falls unerwartete Probleme auftreten. Nachdem die Datei im Bootflash ist, können Sie das Wiederherstellungstool ausführen mit:
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>
Wiederherstellungsszenario:
2 Fehlschläge bei aktiven Systemen
Lösungsschritte:
Anmerkung: Es ist in der Regel in Fällen von Dual-Flash-Ausfällen zu sehen, ein Software-Neuladen kann das RAID nicht vollständig wiederherstellen und kann die Ausführung des Recovery-Tools oder nachfolgende Neuladevorgänge erfordern, um wiederherzustellen. In fast jedem Fall wurde sie durch einen physischen Wiedereinbau des Supervisor-Moduls behoben. Wenn also nach dem externen Backup der Konfiguration physischer Zugriff auf das Gerät möglich ist, können Sie eine schnelle Wiederherstellung mit der größten Erfolgschance versuchen, indem Sie den Supervisor physisch wieder einsetzen, wenn Sie das Gerät neu laden möchten. Dadurch wird der Supervisor vollständig entlastet, und es sollte die Wiederherstellung beider Festplatten im RAID möglich sein. Fahren Sie mit Schritt 3 fort, wenn die physische Wiederherstellung nach dem Wiedereinsetzen nur teilweise erfolgt, oder mit Schritt 4, wenn dies nicht erfolgreich ist, da das System nicht vollständig bootet.
Fehlerszenario:
0 Fehlschläge im aktiven Modus
1 Ausfall im Standby-Modus
Lösungsschritte:
Bei einem Szenario mit dualem Supervisor und ohne Flash-Fehler im aktiven und mit einem einzigen Fehler im Standby-Modus kann eine Wiederherstellung ohne Auswirkungen durchgeführt werden.
1. Da der aktive Server keine Fehler hat und der Standby-Server nur einen einzigen Fehler hat, kann das Flash Recovery Tool auf den aktiven Server geladen und ausgeführt werden. Nach dem Ausführen des Tools kopiert es sich automatisch in den Standby-Modus und versucht, das Array erneut zu synchronisieren. Das Wiederherstellungstool kann hier heruntergeladen werden:
Sobald Sie das Tool heruntergeladen, entpackt und in den Bootflash des Pakets hochgeladen haben, müssen Sie den folgenden Befehl ausführen, um die Wiederherstellung zu beginnen:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Das Tool startet und erkennt nicht verbundene Festplatten und versucht, sie mit dem RAID-Array neu zu synchronisieren.
Sie können den Wiederherstellungsstatus wie folgt überprüfen:
# show system internal file /proc/mdstat
Überprüfen Sie, ob die Wiederherstellung fortgesetzt wird. Es kann einige Minuten dauern, bis alle Datenträger vollständig auf [UU] repariert sind. Ein Beispiel für eine Wiederherstellung im Betrieb sieht wie folgt aus:
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>
Nachdem die Wiederherstellung abgeschlossen ist, sollte es wie folgt aussehen:
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>
Nachdem alle Festplatten in [UU] sind, wird das RAID-Array vollständig gesichert, und beide Festplatten werden synchronisiert.
2. Wenn das Flash Recovery Tool nicht erfolgreich ist, da das aktive Laufwerk beide Laufwerke aktiviert hat, sollte das Standby-Gerät in der Lage sein, beim erneuten Laden erfolgreich mit dem aktiven Laufwerk zu synchronisieren.
Führen Sie daher in einem geplanten Fenster ein "Out-of-Service-Modul x" für den Standby-Supervisor aus. Es wird empfohlen, Konsolenzugriff auf den Standby-Server zu haben, um den Bootvorgang zu beobachten, falls unerwartete Probleme auftreten. Wenn der Supervisor heruntergefahren ist, warten Sie einige Sekunden, und führen Sie dann "no poweroff module x" für den Standby-Modus aus. Warten Sie, bis der Standby-Modus vollständig in den "ha-standby"-Status wechselt.
Nachdem der Standby-Modus wieder aktiviert wurde, überprüfen Sie das RAID mit "slot x show system internal raid" und "slot x show system internal file /proc/mdstat".
Wenn beide Festplatten nach dem Neuladen nicht vollständig gesichert sind, führen Sie das Wiederherstellungstool erneut aus.
3. Wenn das Neuladen und Wiederherstellen-Tool nicht erfolgreich sind, wird empfohlen, das Standby-Modul erneut in das Fenster einzusetzen, um den Zustand zu beheben. Wenn der physische Neustart nicht erfolgreich ist, versuchen Sie, ein "init system" aus dem Switch-Startmodus auszuführen. Befolgen Sie dazu die Schritte zur Kennwortwiederherstellung, um während des Bootvorgangs in diesen Modus zu wechseln. Sollte dies weiterhin nicht gelingen, wenden Sie sich an das TAC, um eine manuelle Wiederherstellung zu versuchen.
Wiederherstellungsszenario:
1 Fehlschlag bei aktiven Systemen
0 Fehlschläge im Standby-Modus
Lösungsschritte:
Bei einem Szenario mit dualem Supervisor und einem aktiven Flash-Fehler ohne Fehler im Standby-Modus kann mithilfe des Flash Recovery Tools eine Wiederherstellung ohne Auswirkungen durchgeführt werden.
1. Da der Standby-Modus keine Fehler aufweist und der aktive Modus nur einen einzigen Fehler aufweist, kann das Flash Recovery Tool auf den aktiven Modus geladen und ausgeführt werden. Nach dem Ausführen des Tools kopiert es sich automatisch in den Standby-Modus und versucht, das Array erneut zu synchronisieren. Das Wiederherstellungstool kann hier heruntergeladen werden:
Sobald Sie das Tool heruntergeladen, entpackt und in den Bootflash des aktiven hochgeladen haben, müssen Sie den folgenden Befehl ausführen, um die Wiederherstellung zu beginnen:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Das Tool startet und erkennt nicht verbundene Festplatten und versucht, sie mit dem RAID-Array neu zu synchronisieren.
Sie können den Wiederherstellungsstatus wie folgt überprüfen:
# show system internal file /proc/mdstat
Überprüfen Sie, ob die Wiederherstellung fortgesetzt wird. Es kann einige Minuten dauern, bis alle Datenträger vollständig auf [UU] repariert sind. Ein Beispiel für eine Wiederherstellung im Betrieb sieht wie folgt aus:
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>
Nachdem die Wiederherstellung abgeschlossen ist, sollte es wie folgt aussehen:
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>
Nachdem alle Festplatten in [UU] sind, wird das RAID-Array vollständig gesichert, und beide Festplatten werden synchronisiert.
2. Wenn das Flash Recovery Tool nicht erfolgreich ist, besteht der nächste Schritt darin, einen "System-Switchover" durchzuführen, um die Supervisor-Module in einem Wartungsfenster per Failover zu sichern.
Aus diesem Grund wird empfohlen, in einem geplanten Fenster einen "System-Switchover" durchzuführen, um den Bootvorgang zu beobachten, falls unerwartete Probleme auftreten. Warten Sie, bis der Standby-Modus vollständig in den "ha-standby"-Status wechselt.
Nachdem der Standby-Modus wieder aktiviert wurde, überprüfen Sie das RAID mit "slot x show system internal raid" und "slot x show system internal file /proc/mdstat".
Wenn beide Festplatten nach dem Neuladen nicht vollständig gesichert sind, führen Sie das Wiederherstellungstool erneut aus.
3. Wenn das Neuladen und Wiederherstellen-Tool nicht erfolgreich sind, wird empfohlen, das Standby-Modul erneut in das Fenster einzusetzen, um den Zustand zu beheben. Wenn der physische Neustart nicht erfolgreich ist, versuchen Sie, ein "init system" aus dem Switch-Startmodus auszuführen. Befolgen Sie dazu die Schritte zur Kennwortwiederherstellung, um während des Bootvorgangs in diesen Modus zu wechseln. Sollte dies weiterhin nicht gelingen, wenden Sie sich an das TAC, um eine manuelle Wiederherstellung zu versuchen.
Wiederherstellungsszenario:
1 Fehlschlag bei aktiven Systemen
1 Ausfall im Standby-Modus
Lösungsschritte:
Sollte ein einzelner Flash-Fehler sowohl im aktiven als auch im Standby-Modus auftreten, kann weiterhin eine Workaround-Lösung ohne Auswirkungen durchgeführt werden.
1. Da kein Supervisor schreibgeschützt ist, besteht der erste Schritt darin, das Flash Recovery Tool zu verwenden.
Das Wiederherstellungstool kann hier heruntergeladen werden:
Sobald Sie das Tool heruntergeladen, entpackt und in den Bootflash des aktiven hochgeladen haben, müssen Sie den folgenden Befehl ausführen, um die Wiederherstellung zu beginnen:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Es erkennt automatisch nicht verbundene Festplatten im aktiven Zustand und versucht eine Reparatur, kopiert sich automatisch in den Standby-Modus und erkennt und korrigiert Fehler dort.
Sie können den Wiederherstellungsstatus wie folgt überprüfen:
# show system internal file /proc/mdstat
Überprüfen Sie, ob die Wiederherstellung fortgesetzt wird. Es kann einige Minuten dauern, bis alle Datenträger vollständig auf [UU] repariert sind. Ein Beispiel für eine Wiederherstellung im Betrieb sieht wie folgt aus:
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>
Nachdem die Wiederherstellung abgeschlossen ist, sollte es wie folgt aussehen:
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>
Nachdem alle Festplatten in [UU] sind, wird das RAID-Array vollständig gesichert, und beide Festplatten werden synchronisiert.
Wenn beide Supervisoren den [UU]-Status wiederherstellen, ist die Wiederherstellung abgeschlossen. Wenn die Wiederherstellung nur teilweise erfolgt ist oder nicht erfolgreich war, fahren Sie mit Schritt 2 fort.
2. Falls das Wiederherstellungstool nicht erfolgreich war, ermitteln Sie den aktuellen Status des RAID auf den Modulen. Wenn bei beiden Systemen immer noch ein einziger Flash-Fehler auftritt, versuchen Sie einen "System-Switchover", der den aktuell aktiven Server neu lädt und den Standby-Server in die aktive Rolle zwingt.
Nachdem der zuvor aktive Server wieder in "ha-standby" geladen wurde, überprüfen Sie seinen RAID-Status, wie er während des erneuten Ladens wiederhergestellt werden sollte.
Wenn der Supervisor nach dem Switchover erfolgreich wiederhergestellt wird, können Sie erneut versuchen, das Flash Recovery Tool auszuführen, um den Ausfall einer Festplatte auf dem derzeit aktiven Supervisor zu beheben, oder einen anderen "System Switchover", um den derzeit aktiven Supervisor neu zu laden und den vorherigen aktiven und aktuellen Standby, der repariert wurde, wieder in die aktive Rolle zu zwingen. Überprüfen Sie, ob der neu geladene Supervisor beide Festplatten repariert hat, und führen Sie das Wiederherstellungstool gegebenenfalls erneut aus.
3. Wenn der Switchover während dieses Vorgangs das RAID nicht repariert, führen Sie ein "Out-of-Service-Modul x" für den Standby-Modus und dann "kein Power-Off-Modul x" aus, um das Modul vollständig zu entfernen und neu zu betreiben.
Wenn der Out-of-Service nicht erfolgreich ist, versuchen Sie, den Standby-Switch wieder einzusetzen.
Wenn nach dem Ausführen des Wiederherstellungstools ein Supervisor sein RAID wiederherstellt und der andere noch einen Fehler aufweist, erzwingen Sie den Supervisor mit dem einzelnen Fehler, bei Bedarf den Standby-Modus mit einem "System-Switchover" zu aktivieren. Wenn der Supervisor mit einem einzigen Ausfall
bereits im Standby-Modus, führen Sie ein "Out-of-Service-Modul x" für den Standby-Modus und ein "Kein Ausschaltmodul x" aus, um das Modul vollständig aus- und wieder einzuschalten. Wenn sich das Modul immer noch nicht erholt, setzen Sie es physisch wieder ein. Falls ein Wiedereinsetzen nicht funktioniert,
brechen Sie mithilfe des Kennwortwiederherstellungsverfahrens in die Boot-Aufforderung des Switches ein, und führen Sie eine "init system"-Aktion durch, um den Bootflash erneut zu initialisieren. Sollte dies weiterhin nicht erfolgreich sein, lassen Sie das TAC versuchen, manuell wiederherzustellen.
Anmerkung: Wenn der Standby-Modus zu einem bestimmten Zeitpunkt nicht "ha-standby" sondern "hochgefahren" ist und der Standby-Modus nicht wie oben beschrieben aktiviert werden kann, muss das Chassis neu geladen werden.
Wiederherstellungsszenario:
2 Fehlschläge bei aktiven Systemen
0 Fehlschläge im Standby-Modus
Lösungsschritte:
Bei 2 Fehlern auf dem aktiven und 0 auf dem Standby-Supervisor ist eine Wiederherstellung ohne Auswirkungen möglich, je nachdem, wie viel der aktuellen Konfiguration hinzugefügt wurde, da der Standby-Server seine aktuelle Konfiguration nicht mit dem aktiven synchronisieren konnte.
Das Wiederherstellungsverfahren besteht darin, die aktuelle Konfiguration vom aktiven Supervisor, Failover zum intakten Standby-Supervisor, die fehlende aktuelle Konfiguration in den neuen aktiven Supervisor zu kopieren, den vorherigen aktiven Supervisor manuell in den Online-Modus zu versetzen und dann das Wiederherstellungstool auszuführen.
2. Nachdem die aktuelle Konfiguration vom aktiven Supervisor kopiert wurde, empfiehlt es sich, sie mit der Startkonfiguration zu vergleichen, um festzustellen, was sich seit der letzten Speicherung geändert hat. Dies ist zu sehen mit "show startup-configuration". Die Unterschiede werden natürlich vollständig von der Umgebung abhängen, aber es ist gut, sich bewusst zu sein, was fehlen kann, wenn der Standby-Server als aktiver online geht. Es ist auch sinnvoll, die Unterschiede bereits in einem Notizblock kopiert zu haben, sodass sie nach dem Switchover schnell zum neuen aktiven Supervisor hinzugefügt werden können.
3. Nachdem die Unterschiede evaluiert wurden, müssen Sie einen Supervisor-Switchover durchführen. TAC empfiehlt, dies während eines Wartungsfensters zu tun, da unvorhergesehene Probleme auftreten können. Der Befehl zum Durchführen des Failovers zum Standby-Modus lautet "system switchover".
4. Der Switchover sollte sehr schnell erfolgen, und der neue Standby-Modus startet neu. Während dieser Zeit möchten Sie alle fehlenden Konfigurationen wieder zu den neuen aktiven hinzufügen. Kopieren Sie dazu die Konfiguration vom TFTP-Server (oder von dem Ort, an dem sie zuvor gespeichert wurde), oder fügen Sie sie manuell der CLI hinzu. In den meisten Fällen sind die fehlenden Konfigurationen sehr kurz, und die CLI-Option ist die praktikabelste.
5. Nach einiger Zeit kann der neue Standby-Supervisor wieder im "ha-standby"-Status online sein, aber normalerweise bleibt er im "powered"-Status stecken. Der Status kann mit dem Befehl "show module" angezeigt werden und bezieht sich auf die Spalte "Status" neben dem Modul.
Wenn der neue Standby-Modus in den "eingeschalteten" Zustand versetzt wird, müssen Sie ihn manuell wieder online schalten. Dazu müssen Sie die folgenden Befehle eingeben, wobei "x" für das Standby-Modul steht, das sich im eingeschalteten Zustand befindet:
(config)# Out-of-Service-Modul x
(config)# Kein Abschaltmodul x
6. Sobald der Standby-Modus wieder online ist und den Status "ha-standby" aufweist, müssen Sie das Wiederherstellungstool ausführen, um sicherzustellen, dass die Wiederherstellung abgeschlossen ist. Das Tool kann unter dem folgenden Link heruntergeladen werden:
Sobald Sie das Tool heruntergeladen, entpackt und in den Bootflash des Pakets hochgeladen haben, müssen Sie den folgenden Befehl ausführen, um die Wiederherstellung zu beginnen:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Das Tool startet und erkennt nicht verbundene Festplatten und versucht, sie mit dem RAID-Array neu zu synchronisieren.
Sie können den Wiederherstellungsstatus wie folgt überprüfen:
# show system internal file /proc/mdstat
Überprüfen Sie, ob die Wiederherstellung fortgesetzt wird. Es kann einige Minuten dauern, bis alle Datenträger vollständig auf [UU] repariert sind. Ein Beispiel für eine Wiederherstellung im Betrieb sieht wie folgt aus:
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>
Nachdem die Wiederherstellung abgeschlossen ist, sollte es wie folgt aussehen:
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>
Nachdem alle Festplatten in [UU] sind, wird das RAID-Array vollständig gesichert, und beide Festplatten werden synchronisiert.
0 Fehlschläge im aktiven, 2 im Standby-Modus
Wiederherstellungsszenario:
0 Fehlschläge im aktiven Modus
2 Ausfälle im Standby-Modus
Lösungsschritte:
Bei 0 Fehlern auf dem aktiven und 2 Fehlern auf dem Standby-Supervisor ist eine Wiederherstellung ohne Auswirkungen möglich.
Das Wiederherstellungsverfahren besteht darin, ein Neuladen des Standby-Geräts durchzuführen.
1. Bei Supervisoren mit einem Dual-Flash-Fehler wird häufig festgestellt, dass ein Software-"reload module x" das RAID nur teilweise reparieren kann oder dass es beim Neustart eingeschaltet bleibt.
Es wird daher empfohlen, den Supervisor entweder physisch wieder einzusetzen, wenn ein Dual-Flash-Fehler auftritt, um das Modul vollständig zu entfernen und erneut mit Strom zu versorgen, oder Sie können Folgendes ausführen (x für Standby-Steckplatz #):
# Out-of-Service-Modul x
# kein Abschaltmodul x
Wenn Sie feststellen, dass der Standby-Modus im eingeschalteten Zustand feststeckt und nach den obigen Schritten den Stromzyklus aufrecht erhält, ist dies wahrscheinlich darauf zurückzuführen, dass der Standby-Modus aktiv neu geladen wird und nicht rechtzeitig verfügbar ist.
Dies kann daran liegen, dass der Standby-Bootvorgang versucht, sein Bootflash/RAID neu zu initialisieren. Dies kann bis zu 10 Minuten dauern, wird jedoch weiterhin vom aktiven System zurückgesetzt, bevor dies möglich ist.
Um dieses Problem zu beheben, konfigurieren Sie die folgenden Einstellungen mithilfe von "x" für die im aktiven Zustand befindliche Nummer des Standby-Steckplatzes:
(config)# manueller Systemstandby-Systemstart
(config)# reload module x force-dnld
Mit den obigen Einstellungen wird der Standby-Modus so konfiguriert, dass er nicht automatisch zurückgesetzt wird. Anschließend wird der Standby-Modus neu geladen, und das Image wird vom aktiven Modus synchronisiert.
Warten Sie 10 bis 15 Minuten, um festzustellen, ob der Standby-Modus endlich den Status "ha-standby" erreicht. Aktivieren Sie nach dem Ha-Standby-Status den automatischen Neustart des Standby-Systems mit:
(config)# System kein manueller Standby-Start
6. Sobald der Standby-Modus wieder online ist und den Status "ha-standby" aufweist, müssen Sie das Wiederherstellungstool ausführen, um sicherzustellen, dass die Wiederherstellung abgeschlossen ist. Das Tool kann unter dem folgenden Link heruntergeladen werden:
https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest
Sobald Sie das Tool heruntergeladen, entpackt und in den Bootflash des Pakets hochgeladen haben, müssen Sie den folgenden Befehl ausführen, um die Wiederherstellung zu beginnen:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Das Tool startet und erkennt nicht verbundene Festplatten und versucht, sie mit dem RAID-Array neu zu synchronisieren.
Sie können den Wiederherstellungsstatus wie folgt überprüfen:
# show system internal file /proc/mdstat
Überprüfen Sie, ob die Wiederherstellung fortgesetzt wird. Es kann einige Minuten dauern, bis alle Datenträger vollständig auf [UU] repariert sind. Ein Beispiel für eine Wiederherstellung im Betrieb sieht wie folgt aus:
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>
Nachdem die Wiederherstellung abgeschlossen ist, sollte es wie folgt aussehen:
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>
Nachdem alle Festplatten in [UU] sind, wird das RAID-Array vollständig gesichert, und beide Festplatten werden synchronisiert.
2 Fehlschläge im aktiven, 1 im Standby-Modus
Wiederherstellungsszenario:
2 Fehlschläge bei aktiven Systemen
1 Fehlfunktion im Standby-Modus
Lösungsschritte:
Bei zwei Fehlern auf dem aktiven und einem auf dem Standby-Supervisor ist eine Wiederherstellung ohne Auswirkungen möglich, je nachdem, wie viel der aktuellen Konfiguration hinzugefügt wurde, da der Standby-Server seine aktuelle Konfiguration nicht mit dem aktiven synchronisieren konnte.
Das Wiederherstellungsverfahren besteht darin, die aktuelle aktuelle Konfiguration vom aktiven Supervisor zu sichern, ein Failover auf den intakten Standby-Supervisor durchzuführen, die fehlende aktuelle Konfiguration in den neuen aktiven Supervisor zu kopieren, den vorherigen aktiven Supervisor manuell online zu schalten und anschließend das Wiederherstellungstool auszuführen.
1. Externes Backup der aktuellen Konfiguration mit "copy running-config tftp: vdc-all". Bitte beachten Sie, dass bei einem Dual-Flash-Fehler Konfigurationsänderungen seit der Wiederaufnahme des schreibgeschützten Systems in der Startkonfiguration nicht vorhanden sind. Sie können "show system internal raid" für das betroffene Modul durchgehen, um festzustellen, wann der zweite Datenträger ausfällt, d. h. wo das System schreibgeschützt ist. Von dort aus können Sie "show accounting log" (Kontoführungsprotokoll anzeigen) für jeden VDC überprüfen, um festzustellen, welche Änderungen seit dem Dual-Flash-Fehler vorgenommen wurden. So wissen Sie, was hinzugefügt werden muss, wenn die Startkonfiguration beim Neuladen beibehalten wird.
Beachten Sie, dass es möglich ist, dass die Startkonfiguration beim erneuten Laden eines Supervisors mit Dual-Flash-Fehler gelöscht wird. Aus diesem Grund muss die Konfiguration extern gesichert werden.
2. Nachdem die aktuelle Konfiguration vom aktiven Supervisor kopiert wurde, empfiehlt es sich, sie mit der Startkonfiguration zu vergleichen, um festzustellen, was sich seit der letzten Speicherung geändert hat. Dies ist zu sehen mit "show startup-configuration". Die Unterschiede werden natürlich vollständig von der Umgebung abhängen, aber es ist gut, sich bewusst zu sein, was fehlen kann, wenn der Standby-Server als aktiver online geht. Es ist auch sinnvoll, die Unterschiede bereits in einem Notizblock kopiert zu haben, sodass sie nach dem Switchover schnell zum neuen aktiven Supervisor hinzugefügt werden können.
3. Nachdem die Unterschiede evaluiert wurden, müssen Sie einen Supervisor-Switchover durchführen. TAC empfiehlt, dies während eines Wartungsfensters zu tun, da unvorhergesehene Probleme auftreten können. Der Befehl zum Durchführen des Failovers zum Standby-Modus lautet "system switchover".
4. Der Switchover sollte sehr schnell erfolgen, und der neue Standby-Modus startet neu. Während dieser Zeit möchten Sie alle fehlenden Konfigurationen wieder zu den neuen aktiven hinzufügen. Dies kann durch Kopieren der Konfiguration vom TFTP-Server (oder von dem Ort, an dem sie zuvor gespeichert wurde) oder durch manuelles Hinzufügen der Konfiguration in der CLI erfolgen. Kopieren Sie die Konfiguration nicht direkt von TFTP in die aktuelle Konfiguration, kopieren Sie sie zuerst in den Bootflash und dann in die aktuelle Konfiguration. In den meisten Fällen sind die fehlenden Konfigurationen sehr kurz, und die CLI-Option ist die praktikabelste.
5. Nach einiger Zeit kann der neue Standby-Supervisor wieder im "ha-standby"-Status online sein, aber normalerweise bleibt er im "powered"-Status stecken. Der Status kann mit dem Befehl "show module" in der Spalte "Status" neben dem Modul angezeigt werden.
Wenn der neue Standby-Modus in den "eingeschalteten" Zustand versetzt wird, müssen Sie ihn manuell wieder online schalten. Dazu müssen Sie die folgenden Befehle eingeben, wobei "x" für das Standby-Modul steht, das sich im eingeschalteten Zustand befindet:
(config)# Out-of-Service-Modul
(config)# Kein Abschaltmodul x
Wenn Sie feststellen, dass der Standby-Modus im eingeschalteten Zustand feststeckt und nach den obigen Schritten den Stromzyklus aufrecht erhält, ist dies wahrscheinlich darauf zurückzuführen, dass der Standby-Modus aktiv neu geladen wird und nicht rechtzeitig verfügbar ist.
Dies kann daran liegen, dass der Standby-Bootvorgang versucht, sein Bootflash/RAID neu zu initialisieren. Dies kann bis zu 10 Minuten dauern, wird jedoch weiterhin vom aktiven System zurückgesetzt, bevor dies möglich ist.
Um dieses Problem zu beheben, konfigurieren Sie die folgenden Einstellungen mithilfe von "x" für die im aktiven Zustand befindliche Nummer des Standby-Steckplatzes:
(config)# manueller Systemstandby-Systemstart
(config)# reload module x force-dnld
Mit den obigen Einstellungen wird der Standby-Modus so konfiguriert, dass er nicht automatisch zurückgesetzt wird. Anschließend wird der Standby-Modus neu geladen, und das Image wird vom aktiven Modus synchronisiert.
Warten Sie 10 bis 15 Minuten, um festzustellen, ob der Standby-Modus endlich den Status "ha-standby" erreicht. Aktivieren Sie nach dem Ha-Standby-Status den automatischen Neustart des Standby-Systems mit:
(config)# System kein manueller Standby-Start
6. Sobald der Standby-Modus wieder online ist und sich im "ha-standby"-Modus befindet, müssen Sie das Wiederherstellungstool ausführen, um sicherzustellen, dass die Wiederherstellung abgeschlossen ist, und um den einzelnen Festplattenfehler auf dem aktiven System zu beheben. Das Tool kann unter dem folgenden Link heruntergeladen werden:
https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest
Sobald Sie das Tool heruntergeladen, entpackt und in den Bootflash des Pakets hochgeladen haben, müssen Sie den folgenden Befehl ausführen, um die Wiederherstellung zu beginnen:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Das Tool startet und erkennt nicht verbundene Festplatten und versucht, sie mit dem RAID-Array neu zu synchronisieren.
Sie können den Wiederherstellungsstatus wie folgt überprüfen:
# show system internal file /proc/mdstat
Überprüfen Sie, ob die Wiederherstellung fortgesetzt wird. Es kann einige Minuten dauern, bis alle Datenträger vollständig auf [UU] repariert sind. Ein Beispiel für eine Wiederherstellung im Betrieb sieht wie folgt aus:
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>
Nachdem die Wiederherstellung abgeschlossen ist, sollte es wie folgt aussehen:
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>
Nachdem alle Festplatten in [UU] sind, wird das RAID-Array vollständig gesichert, und beide Festplatten werden synchronisiert.
Wenn der aktuell aktive Switch mit einem einzelnen Ausfall nicht vom Recovery-Tool wiederhergestellt wird, versuchen Sie einen weiteren "System-Switchover", um sicherzustellen, dass sich Ihr aktueller Standby-Switch im "ha-standby"-Status befindet. Wenn Sie immer noch nicht erfolgreich sind, wenden Sie sich an das Cisco TAC.
Wiederherstellungsszenario:
1 Fehlschlag bei aktiven Systemen
2 Ausfälle im Standby-Modus
Lösungsschritte:
In einem Szenario mit zwei Supervisors, bei dem ein Fehler auf dem aktiven Supervisor und zwei Fehler auf dem Standby-Supervisor auftritt, kann eine Recovery ohne Auswirkungen möglich sein, in vielen Fällen kann jedoch ein Neuladen erforderlich sein.
Der Prozess besteht darin, zunächst alle ausgeführten Konfigurationen zu sichern, dann zu versuchen, den fehlerhaften Compact Flash auf dem aktiven System mithilfe des Wiederherstellungstools wiederherzustellen. Wenn dies erfolgreich ist, laden Sie das Standby-System manuell neu und führen das Wiederherstellungstool erneut aus. Wenn der erste Wiederherstellungsversuch nicht in der Lage ist, den fehlgeschlagenen Flash-Speicher auf dem aktiven Gerät wiederherzustellen, muss das TAC aktiviert werden, um eine manuelle Wiederherstellung mithilfe des Debug-Plugins zu versuchen.
1. Sichern Sie alle aktuellen Konfigurationen extern mit "copy running-config tftp: vdc-all". Sie können die aktuelle Konfiguration auch auf einen lokalen USB-Stick kopieren, wenn in der Umgebung kein TFTP-Server eingerichtet ist.
2. Sobald die aktuelle Konfiguration gesichert ist, müssen Sie das Wiederherstellungstool ausführen, um eine Wiederherstellung des fehlerhaften Flash-Speichers auf dem aktiven System zu versuchen. Das Tool kann unter dem folgenden Link heruntergeladen werden:
Sobald Sie das Tool heruntergeladen, entpackt und in den Bootflash des Pakets hochgeladen haben, müssen Sie den folgenden Befehl ausführen, um die Wiederherstellung zu beginnen:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Das Tool startet und erkennt nicht verbundene Festplatten und versucht, sie mit dem RAID-Array neu zu synchronisieren.
Sie können den Wiederherstellungsstatus wie folgt überprüfen:
# show system internal file /proc/mdstat
Überprüfen Sie, ob die Wiederherstellung fortgesetzt wird. Es kann einige Minuten dauern, bis alle Datenträger vollständig auf [UU] repariert sind. Ein Beispiel für eine Wiederherstellung im Betrieb sieht wie folgt aus:
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>
Nachdem die Wiederherstellung abgeschlossen ist, sollte es wie folgt aussehen:
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>
Nachdem alle Festplatten in [UU] sind, wird das RAID-Array vollständig gesichert, und beide Festplatten werden synchronisiert.
3. Wenn Sie nach dem Ausführen des Wiederherstellungstools in Schritt 2 nicht in der Lage sind, den ausgefallenen Compact Flash auf dem aktiven Supervisor wiederherzustellen, müssen Sie sich an das TAC wenden, um eine manuelle Wiederherstellung mit dem Linux-Debugmodul zu versuchen.
4. Nachdem Sie überprüft haben, ob beide Blitze im aktiven Zustand als [UU] angezeigt werden, können Sie den Standby-Supervisor manuell neu starten. Dazu müssen Sie die folgenden Befehle eingeben, wobei "x" für das Standby-Modul steht, das sich im eingeschalteten Zustand befindet:
(config)# Out-of-Service-Modul x
(config)# Kein Abschaltmodul x
Dadurch sollte der Standby-Supervisor wieder in den "ha-standby"-Status versetzt werden (dies wird durch Anzeige der Spalte "Status" in der Ausgabe von "Modul anzeigen" überprüft). Wenn dies erfolgreich ist, fahren Sie mit Schritt 6 fort. Wenn dies nicht der Fall ist, führen Sie die in Schritt 5 beschriebenen Schritte aus.
5. Wenn Sie feststellen, dass der Standby-Modus im eingeschalteten Zustand feststeckt und nach den obigen Schritten den Stromzyklus aufrecht erhält, ist dies wahrscheinlich darauf zurückzuführen, dass der Standby-Modus aktiv neu geladen wird und nicht rechtzeitig verfügbar ist. Dies kann daran liegen, dass der Standby-Bootvorgang versucht, sein Bootflash/RAID neu zu initialisieren. Dies kann bis zu 10 Minuten dauern, wird jedoch weiterhin vom aktiven System zurückgesetzt, bevor dies möglich ist. Um dieses Problem zu beheben, konfigurieren Sie die folgenden Einstellungen mithilfe von "x" für die im aktiven Zustand befindliche Nummer des Standby-Steckplatzes:
(config)# manueller Systemstandby-Systemstart
(config)# Modul neu laden x force-dnld
Mit den obigen Einstellungen wird der Standby-Modus so konfiguriert, dass er nicht automatisch zurückgesetzt wird. Anschließend wird der Standby-Modus neu geladen, und das Image wird vom aktiven Modus synchronisiert.
Warten Sie 10 bis 15 Minuten, um festzustellen, ob der Standby-Modus endlich den Status "ha-standby" erreicht. Aktivieren Sie nach dem Ha-Standby-Status den automatischen Neustart des Standby-Systems mit:
(config)# System kein manueller Standby-Start
6. Sobald der Standby-Modus wieder online ist und den Status "ha-standby" aufweist, müssen Sie das Wiederherstellungstool ausführen, um sicherzustellen, dass die Wiederherstellung abgeschlossen ist. Sie können das gleiche Tool ausführen, das Sie auf dem aktiven für diesen Schritt haben, es ist kein zusätzlicher Download erforderlich, da das Wiederherstellungstool auf dem aktiven und dem Standby-Gerät ausgeführt wird.
Wiederherstellungsszenario:
2 Fehlschläge bei aktiven Systemen
2 Ausfälle im Standby-Modus
Lösungsschritte:
Anmerkung: Es ist in der Regel in Fällen von Dual-Flash-Ausfällen zu sehen, eine Software "neu laden" kann nicht vollständig das RAID wiederherstellen und erfordert möglicherweise die Ausführung des Recovery-Tools oder nachfolgenden Neuladevorgänge, um wiederherzustellen. In fast jedem Fall wurde sie durch einen physischen Wiedereinbau des Supervisor-Moduls behoben. Wenn also nach dem externen Backup der Konfiguration physischer Zugriff auf das Gerät möglich ist, können Sie eine schnelle Wiederherstellung mit der größten Erfolgschance versuchen, indem Sie den Supervisor physisch wieder einsetzen, wenn Sie das Gerät neu laden möchten. Dadurch wird der Supervisor vollständig entlastet, und es sollte die Wiederherstellung beider Festplatten im RAID möglich sein. Fahren Sie mit Schritt 3 fort, wenn die physische Wiederherstellung nach dem Wiedereinsetzen nur teilweise erfolgt, oder mit Schritt 4, wenn dies nicht erfolgreich ist, da das System nicht vollständig bootet.
Siehe Abschnitt zu langfristigen Lösungen unten.
Dies ist nicht möglich, da der aktive Supervisor, um den Standby-Supervisor in einen "ha-standby"-Status zu versetzen, mehrere Dinge in seinen Compact Flash schreiben muss (SNMP-Info usw.), was er bei einem Dual-Flash-Ausfall nicht selbst tun kann.
Wenden Sie sich für die Optionen in diesem Szenario an Cisco TAC.
Es gibt einen separaten Fehler für N7700 Sup2E - CSCuv64056 . Das Wiederherstellungstool funktioniert für den N7700 nicht.
Das Wiederherstellungstool funktioniert nicht für NPE-Images.
Nein. Ein ISSU verwendet einen Supervisor-Switchover, der aufgrund eines Compact-Flash-Ausfalls möglicherweise nicht ordnungsgemäß ausgeführt wird.
RAID-Statusbits werden nach dem Zurücksetzen der Karte nach Anwendung der automatischen Wiederherstellung zurückgesetzt.
Allerdings können nicht alle Fehlerzustände automatisch wiederhergestellt werden.
Wenn die RAID-Statusbits nicht als [2/2] [UU] ausgegeben werden, ist die Wiederherstellung unvollständig.
Führen Sie die aufgeführten Wiederherstellungsschritte aus.
Nein, aber das System startet bei einem Stromausfall möglicherweise nicht neu. Auch die Startkonfigurationen gehen verloren.
ISSU behebt fehlgeschlagene eUSB-Geräte nicht. Die beste Option ist, das Wiederherstellungstool für einen einzelnen Eusb-Fehler auf dem Sup auszuführen oder den Sup im Falle eines dualen Eusb-Fehlers neu zu laden.
Sobald das Problem behoben ist, führen Sie das Upgrade durch. Die Korrektur für CSCus22805 hilft, einzelne USB-Fehler NUR zu korrigieren, indem das System in regelmäßigen Intervallen gescannt wird und versucht, unzugängliche oder schreibgeschützte eUSB mit dem Skript wieder zu aktivieren.
Es kommt selten vor, dass beide USB-Flash-Fehler auf dem Supervisor gleichzeitig auftreten, daher ist diese Problemumgehung effektiv.
In der Regel wird dies durch eine längere Betriebszeit erkannt. Dies ist nicht genau quantifiziert und kann ein Jahr oder länger dauern. Die Quintessenz ist, dass die Wahrscheinlichkeit, dass das System in dieses Szenario läuft, umso höher ist, je mehr Stress auf das USB-Flash in Bezug auf Schreibvorgänge.
Systeminterne Schlachtzüge anzeigen zeigt den Flash-Status zweimal in verschiedenen Abschnitten an. Auch diese Abschnitte sind nicht konsistent
Im ersten Abschnitt wird der aktuelle Status und im zweiten Abschnitt der Startstatus angezeigt.
Der aktuelle Status ist das, was zählt, und er sollte immer als EU angezeigt werden.
Dieser Fehler wurde in 6.2(14) umgangen, die Firmware-Korrektur wurde jedoch zu 6.2(16) und 7.2(x) und späteren Versionen hinzugefügt.
Es ist ratsam, ein Upgrade auf eine Version mit dem Firmware-Fix durchzuführen, um dieses Problem vollständig zu beheben.
Wenn Sie kein Upgrade auf eine feste Version von NXOS durchführen können, gibt es zwei Möglichkeiten.
Die Lösung 1 besteht darin, das Flash Recovery Tool jede Woche proaktiv mit dem Scheduler auszuführen. Die folgende Scheduler Konfiguration mit dem Flash Recovery Tool im Bootflash:
Feature Scheduler
Scheduler Jobname Flash_Job
copy bootflash:/n7000-s2-flash-recovery-tool.10.0.2.gbin bootflash:/flash_recovery_tool_copy
load bootflash:/flash_recovery_tool_copy
beenden
Planer Name Flash_Recovery
Jobname Flash_Job
Wochenzeit 7
Hinweise:
Die Lösung 2 wird unter dem folgenden Link zu den technischen Hinweisen dokumentiert