Inhoud

Inleiding

Achtergrond

Symptomen

Diagnose

Scenario's

Invorderingsprocedure voor elk scenario

Single Supervisor failliet scenario's

Scenario A (1 fout op de actieve versie)

Scenario B (2 fouten op de actieve versie)

Scenario’s met dubbele supervisor-fout

Scenario C (0 mislukt op de actieve versie, 1 fout op de standby-modus)

Scenario D (1 fout bij actief, 0 fout bij standby)

Scenario E (1 fout bij actief, 1 fout bij standby)

Scenario F (2 fouten op de actieve versie, 0 fouten op de standby-modus)

Scenario G (0 mislukt op de actieve versie, 2 mislukt op de standby-modus)

Scenario H (2 fouten op het actieve systeem, 1 fout in de standby)

Scenario I (1 fout bij actief, 2 fouten bij standby)

Scenario J (2 fouten op de actieve versie, 2 fouten op de standby-modus)

Samenvatting

Veelgestelde vragen

Is er een permanente oplossing voor deze kwestie?

Waarom is het niet mogelijk om een dubbele failover op de actieve en stand-by te herstellen door de standby supervisor te herladen en failover?

Wat gebeurt er als de Flash Recovery Tool niet in staat is om de compacte flitser te hertellen?

Heeft deze bug ook invloed op de Nexus 7700 Sup2E?

Werkt de hersteltool voor NPE-afbeeldingen?

Zal een kwestie aan een opgeloste versie van code deze kwestie oplossen?

We reset het betreffende bord. Raid status drukt 0xF0, maar GOLD testen nog steeds niet?

Zal de flitsstoring enige invloed hebben op de werking?

Wat wordt aanbevolen voor een gezond, actief systeem vanuit het perspectief van de klant in termen van bewaking en herstel?

Controleer de GOLD compacte teststatus voor eventuele storingen en probeer herstel zodra het eerste flitsonderdeel mislukt. Kan ik een mislukte eusb-flitsstoring oplossen door een ISSU uit de code te doen die is aangetast naar de vaste release?

Hoe lang duurt het voordat het probleem opnieuw verschijnt als u de flitsstoringen oplost met behulp van plugin of herladen?

Langetermijnoplossingen

Inleiding

Dit document beschrijft de Nexus 7000 Supervisor 2/2E compacte flitsfout die in softwarestornis CSCus22805 wordt gedocumenteerd, alle mogelijke mislukkingsscenario's, en terugwinningsstappen.

Voorafgaand aan een tijdelijke oplossing wordt ten zeerste aangeraden om fysieke toegang tot het apparaat te hebben als een fysieke herhaling vereist is.  Voor sommige herladen upgrades, console toegang kan worden vereist, en het wordt altijd aanbevolen om deze workarounds uit te voeren met console toegang tot de supervisor om het bootproces te observeren.

Als een van de stappen in de tijdelijke oplossing mislukt, neemt u contact op met Cisco TAC voor aanvullende mogelijke herstelopties.

Achtergrond

Elke N7K supervisor 2/2E is uitgerust met 2 eUSB-flitsapparaten in RAID1-configuratie, één primaire en één spiegel. Samen bieden ze niet-vluchtige repositories voor opstartbeelden, opstartconfiguratie en permanente toepassingsgegevens.

Wat er kan gebeuren is dat een van deze apparaten gedurende een periode van maanden of jaren in dienst wordt losgekoppeld van de USB-bus, waardoor de RAID-software het apparaat uit de configuratie laat vallen. Het apparaat kan nog steeds normaal functioneren met 1/2 apparaten. Echter, wanneer het tweede apparaat uit de array valt, wordt de bootflash opnieuw gemonteerd als alleen-lezen, wat betekent dat u geen configuratie of bestanden kunt opslaan op de bootflash, of de stand-by toestaan om te synchroniseren met de actieve in het geval het wordt herladen.

Er is geen operationele impact op systemen die draaien in een dubbele flitser mislukking staat, maar een herladen van de getroffen supervisor is nodig om te herstellen van deze staat. Bovendien zullen eventuele wijzigingen in de configuratie niet worden weerspiegeld in het opstarten en verloren gaan in het geval van een stroomuitval.

Symptomen

Deze symptomen zijn waargenomen:

- Compacte flash-diagnostische fout

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--------------------------> .

- Kan geen 'run start kopie' uitvoeren

dcd02.ptfrnyfs# copy running-config startup-config

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

Configuration update aborted: request was aborted

- eUSB wordt alleen-lezen of reageert niet

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-storingen, meestal bij failover naar de standby supervisor

Diagnose

Om de huidige status van de compacte flitskaarten te diagnosticeren moet u deze interne opdrachten gebruiken. Merk op dat het commando niet zal ontleden en dat het volledig getypt moet worden:

switch# toont systeem interne overval | grep -A 1 "Huidige RAID status info"

switch# toont systeem intern bestand /proc/mdstat

Als er twee supervisors in het chassis zijn, zult u de status van de standby supervisor moeten controleren om te bepalen welk mislukkingsscenario u onder ogen ziet. Controleer dit door de opdracht vooraf te laten gaan met het sleutelwoord "sleuf x", waarbij "x" het sleufnummer is van de standby supervisor. Hierdoor kunt u de opdracht op afstand uitvoeren in de stand-by modus.

switch# sleuf 2 toont systeem interne raid | grep -A 1 "Huidige RAID status info"

switch# sleuf 2 toont systeem intern bestand /proc/mdstat

Deze opdrachten geven veel RAID-statistieken en -gebeurtenissen, maar u bent alleen bezig met de huidige RAID-informatie.

In de regel "RAID data from CMOS", wilt u kijken naar de hex-waarde na 0xa5.  Hierin wordt aangegeven hoeveel knipperingen er op dit moment mogelijk zijn.

Voorbeeld:

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

Current RAID status info:

RAID data from CMOS = 0xa5 0xc3

Van deze output wilt u het aantal naast 0xa5 bekijken die 0xc3 is.  U kunt deze toetsen gebruiken om te bepalen of de primaire of secundaire compacte flitser is mislukt, of beide. De bovenstaande uitvoer toont 0xc3 wat ons vertelt dat zowel de primaire als de secundaire compacte flitsen hebben gefaald.

0,00

Geen storingen gemeld

0x1

Primaire flitser is mislukt

0xd2.

Alternatieve (of spiegel) flitser is mislukt

0xc3

Primair en Alternatief mislukt

Zorg er in de uitvoer "/proc/mdstat" voor dat alle disks worden weergegeven als "U", wat "U" vertegenwoordigt:

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 dit scenario ziet u dat de primaire compacte flitser niet omhoog [_U] is. Een gezonde output toont alle blokken als [UU].

Opmerking: Beide uitgangen moeten als gezond (0xf0 en [UU]) tonen om de supervisor als gezond te diagnosticeren. Dus als je een 0xf0 output ziet in de CMOS data maar een [_U] ziet in de /proc/mdstat, dan is het vak ongezond.

Scenario's

Om te bepalen met welk scenario u wordt geconfronteerd, zult u de bovengenoemde bevelen in de "Diagnose"sectie moeten gebruiken om met een hieronder Brief van het Scenario te correleren.  Gebruik de kolommen om het aantal mislukte compacte flitsen op elke supervisor aan te passen.

Bijvoorbeeld, als u zag dat de code 0xe1 op de Actieve supervisor en 0xd2 op de Standby is, zou dit "1 Fail"op Actief en "1 Fail"op de Standby zijn die scenariobrief "D"is.

Enkelvoudige supervisor:

Scenario-brief

Actieve supervisor

Active Supervisor-code

A

1 mislukt

0x1 of 0xd2

B

2 fouten

0xc3

Dubbele toezichthouders:

Scenario-brief

Actieve supervisor

Standby supervisor

Active Supervisor-code

Standby Supervisor Code

C

0 mislukt

1 mislukt

0,00

0x1 of 0xd2

D

1 mislukt

0 mislukt

0x1 of 0xd2

0,00

E

1 mislukt

1 mislukt

0x1 of 0xd2

0x1 of 0xd2

F

2 fouten

0 mislukt

0xc3

0,00

G

0 mislukt

2 fouten

0,00

0xc3

H

2 fouten

1 mislukt

0xc3

0x1 of 0xd2

I

1 mislukt

2 mislukt

0x1 of 0xd2

0xc3

J

2 fouten

2 fouten

0xc3

0xc3

Invorderingsprocedure voor elk scenario

Single Supervisor failliet scenario's

Scenario A (1 fout op de actieve versie)

Herstelscenario:

1 Fout bij actief

Stappen tot resolutie:

Met één supervisor chassis in een Pass/Fail scenario, kan een niet-beïnvloedend herstel worden uitgevoerd. Volg de onderstaande stappen in volgorde van de minste invloed op de meeste impact op herstel.

1. Laad flash herstel tool om bootflash te repareren. U kunt de hersteltool downloaden van CCO onder hulpprogramma’s voor het N7000 platform of gebruik de onderstaande link:

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

Het is verpakt in een tar gz gecomprimeerd bestand, maak het alstublieft uit elkaar om het .gbin herstel tool en een .pdf lees me te vinden. Bekijk het readme bestand en laad de .gbin tool op bootflash van de N7K. Terwijl dit herstel is ontworpen om niet-invloedrijk te zijn en live kan worden uitgevoerd, adviseert TAC om te presteren in een onderhoudsvenster in geval van onverwachte problemen. Nadat het bestand is op bootflash, kunt u het herstel tool uitvoeren met:

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

De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.

U kunt de herstelstatus controleren met:

# toont systeem intern bestand /proc/mdstat

Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:

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>

Na het herstel moet het als volgt zijn:

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>

Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.

2. Als de Flash Recovery Tool niet succesvol was in stap 1, de volgende stap zou zijn om logbestanden te verzamelen en TAC proberen om de schijven handmatig te herstellen met behulp van de debug plugin, merk op dat dit niet succesvol kan zijn als de hersteltool niet succesvol was.

Verzamelen:

show version

show module

boekhoudingslogboek tonen

logbestand logboekregistratie tonen

Toon systeem interne raid (Verborgen Opdracht)

laat systeem interne kernel berichten zien

logboekregistratie aan boord tonen

3. Als handmatig herstel niet werkt en er slechts één supervisor is, zal er waarschijnlijk een herladen van het chassis nodig zijn om te herstellen.

*Echter*, als u een reserve supervisor in een lab apparaat hebt, kunt u proberen dit te laden in de stand-by sleuf (in een onderhoudsvenster), om te zien of het volledig kan synchroniseren met de actieve in HA (Hoge beschikbaarheid) status.

Aangezien de RAID slechts één defecte schijf is, moet standby-synchronisatie met de actieve schijf mogelijk zijn. Als dit een optie is, kijk of de stand-by synchrone volledig synchroon is met de actieve "show module" en "show system redundancy status" om te controleren of de stand-by status "ha-standby" is. Dit geeft aan dat een Stateful Switchover (SSO) mogelijk zou moeten zijn met de opdracht "system switchover". Zorg er na het instellen van de stand-by voor dat de configuratie extern wordt opgeslagen, "copy run tftp: vdc-all", en dan volledig opslaan om op te starten met "copy run vdc-all". Hierna kunt u proberen "system switchover", die de huidige actieve stand zal herladen en de huidige stand-by zal dwingen in actief. Nadat de actieve software is herladen in de stand-by modus, moet deze automatisch de RAID-array herstellen. U kunt dit verifiëren nadat de herladen supervisor terug in "ha-standby"status is en een "slot x tonen systeem interne overval"uitvoert om te verifiëren alle schijven [U] zijn. Als de schijven nog steeds niet volledig back-up zijn, probeer dan de hersteltool opnieuw uit te voeren om eventuele resterende problemen op te lossen. Als dit nog steeds niet succesvol is, kunt u een "out-of-service module x" proberen voor de betreffende module, gevolgd door een "no power off module x". Als dit nog steeds niet lukt, probeer dan de betreffende module fysiek opnieuw in te stellen. Als het nog steeds niet is hersteld, kan dit legitieme HW-fout zijn en een RMA vereisen, maar u kunt proberen om te herladen in switch boot mode met behulp van de wachtwoordherstelprocedure en een "init systeem" uitvoeren als een laatste poging tot herstel.

Als er geen reservesupervisor beschikbaar is, is een volledige herlading noodzakelijk met de "herladen" opdracht. In dat geval zou het raadzaam zijn om fysieke toegang tot het apparaat te hebben als een fysieke herhaling vereist is. Alle actieve configuraties extern laten back-up maken, en wordt aanbevolen om ze op een USB-schijf te hebben, samen met het systeem en kickstart beelden om veilig te zijn. Nadat de herlading is uitgevoerd en het apparaat is ingeschakeld, controleert u of de RAID-status [UU] is en voert u de hersteltool uit als deze niet volledig gerepareerd lijkt. Als het systeem niet omhoog komt of het terugwinningshulpmiddel nog niet werkt, herhaal fasisch de supervisor module en observeer het laarsproces via console. Als een fysieke herstart niet herstellen, breek in lader met behulp van de wachtwoordherstelprocedure, voer switch bootmode in door het kickstart-beeld op te starten, en voer dan een "init-systeem" uit om te proberen en reinitialiseren de bootflash. Dit zou bestanden op de bootflash afvegen, dus het is cruciaal om alle benodigde bestanden en configuratie back-up voorafgaand aan deze stappen.

Als al het andere faalt, is het waarschijnlijk een zeldzaam geval van ware hardwarestoringen, en de supervisor zou RMA'd en misschien EFA'd moeten zijn. Dit is de reden waarom alle configuratie extern moet worden ondersteund voorafgaand aan de herstelstappen, in het geval een noodRMA is vereist, hebt u alle nodige configuratie om het systeem snel weer op te starten.

Scenario B (2 fouten op de actieve versie)

Herstelscenario:

2 Fouten in het actieve systeem

Stappen tot resolutie:

In het scenario van één enkele supervisor met dubbele flitsmislukking, moet een verstorend herladen worden uitgevoerd om te herstellen.

1. Back-up van alle lopende configuratie extern met "copy run tftp: vdc-all". Houd er rekening mee dat in het geval van een dubbele flitsfout, configuratie veranderingen aangezien het systeem opnieuw gemonteerd op alleen-lezen niet aanwezig zijn op de opstartconfiguratie. U kunt "run diff weergeven | i \+" om te bepalen welke veranderingen sinds de dubbele flitsmislukking werden aangebracht zodat zult u weten wat toe te voegen als de startconfiguratie anders is dan de lopende configuratie bij het herladen.

Merk op dat het mogelijk is dat de startconfiguratie wordt afgeveegd op het herladen van een supervisor met dubbele flitsmislukking, wat de reden is dat de configuratie extern moet worden gesteund.

2. Herlaad het apparaat, wordt sterk geadviseerd om consoletoegang te hebben en de fysieke toegang kan worden vereist. De supervisor zou zijn bootflash moeten herladen en herstellen. Controleer na het installeren van het systeem of beide schijven actief zijn met de status [UU] in "Toon systeem interne bestand /proc/mdstat" en "toon systeem interne overval". Als beide schijven actief zijn dan is het herstel voltooid en kunt u werken om alle vorige configuratie te herstellen. Als het herstel niet of slechts gedeeltelijk is geslaagd, gaat u naar stap 3.

Opmerking: Het wordt vaak gezien in gevallen van dubbele flitsfouten, een software herladen kan niet volledig herstellen van de RAID en kan vereisen het uitvoeren van de hersteltool of daaropvolgende herladen om te herstellen. In bijna elk geval is het opgelost met een fysieke herhaling van de supervisor module. Daarom, als fysieke toegang tot het apparaat mogelijk is, na externe back-up van configuratie, kunt u proberen een snel herstel dat de hoogste kans van slagen heeft door de supervisor fysiek te resetten wanneer klaar om het apparaat te herladen. Dit zal volledig de macht van de supervisor verwijderen en zou het herstel van beide schijven in de INVAL moeten toestaan. Ga verder met Stap 3 als het fysieke herstel slechts gedeeltelijk is, of Stap 4 als het volledig niet succesvol is in dat het systeem niet volledig opstart.

3. In het geval van een gedeeltelijk herstel, dat wil zeggen nadat de ene schijf is herladen en de andere nog steeds is met de status [U_], zou de volgende aanbevolen stap zijn om te proberen de Flash Recovery Tool uit te voeren om de andere schijf opnieuw te synchroniseren. Als de hersteltool niet succesvol is, neem contact op met TAC om handmatige herstelstappen te proberen. Een fysieke herhaling van de supervisor kan ook worden geprobeerd.

Als het herladen niet resulteert in de supervisor volledig opstarten, gelieve een fysieke herhaling van de supervisor module uit te voeren. Merk op dat het vaak wordt gezien in een conditie van dubbele flitsmislukking dat een software "herladen" niet volledig herstellen beide schijven als de macht niet volledig wordt verwijderd uit de module, die wordt bereikt met een fysieke herhaling. Als de fysieke herhaling niet succesvol is, gaat u naar stap 4.

4. In het geval een fysieke herhaling niet succesvol is, zou de volgende stap in laderherinnering te breken met behulp van de wachtwoordherstelstappen, de kickstart te laden om switch bootmode, en een "init systeem" uit te voeren, dat de bootflash zal afvegen en zal proberen om de array te herstellen. Als het init systeem voltooit of faalt en nog steeds een probleem ziet, probeer dan een andere fysieke herhaling.

Als al het andere faalt, is het waarschijnlijk een zeldzaam geval van ware hardwarestoringen, en de supervisor zou RMA'd en misschien EFA'd moeten zijn. Dit is de reden waarom alle configuratie extern moet worden ondersteund voorafgaand aan de herstelstappen, in het geval een noodRMA is vereist, hebt u alle nodige configuratie om het systeem snel weer op te starten.

Scenario’s met dubbele supervisor-fout

Scenario C (0 mislukt op de actieve versie, 1 fout op de standby-modus)

Foutscenario:

0 fouten op het actieve

1 Fout in standby

Stappen tot resolutie:

In het scenario van een dubbele supervisor-opstelling, zonder flitsmislukkingen op de actieve en één enkele mislukking op de standby, kan een niet beïnvloedend herstel worden uitgevoerd.

1. Aangezien het actieve systeem geen storingen heeft en de stand-by slechts één storing heeft, kan de Flash Recovery Tool worden geladen op het actieve en uitgevoerde. Nadat het gereedschap is uitgevoerd, zal het zichzelf automatisch kopiëren naar de stand-by en proberen de array te resynchrone.  De hersteltool kan hier worden gedownload:

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

Zodra u het gereedschap hebt gedownload, uitgelijnd en geüpload naar de bootflash van het vak, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:

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

De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.

U kunt de herstelstatus controleren met:

# systeem interne bestand /proc/mdstat tonen

Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:

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>

Na het herstel moet het als volgt zijn:

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>

Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.

2. Als de Flash Recovery Tool niet succesvol is, omdat de actieve twee schijven omhoog heeft, moet de stand-by met succes kunnen synchroniseren met de actieve herlading.

Daarom, in een gepland venster, voer een "out-of-service module x"voor de standby supervisor uit, wordt het aanbevolen om consoletoegang tot de stand-by te hebben om het laarsproces te observeren in het geval dat onverwachte problemen zich voordoen. Wacht een paar seconden nadat de supervisor is uitgeschakeld en voer vervolgens "no power off module x" uit voor de standby. Wacht totdat de stand-by volledig wordt opgestart in de "ha-standby"-status.

Nadat de stand-by back-up is, controleer de RAID met "slot x toon systeem interne raid" en "slot x toon systeem interne bestand /proc/mdstat".

Als beide schijven niet volledig back-up na herladen zijn, voert u het herstelprogramma opnieuw uit.

3. Als de herladen en herstel tool niet succesvol zijn, zou het worden aanbevolen om te proberen fysiek opnieuw te starten van de stand-by module in het venster om te proberen en de conditie te wissen.  Als de fysieke herstart niet succesvol is, probeer dan een "Init System" uit te voeren vanuit de switch-opstartmodus door de wachtwoordherstelstappen te volgen om tijdens het opstarten in deze modus te breken.  Neem contact op met TAC om handmatig herstel te proberen, indien nog steeds niet geslaagd.

Scenario D (1 fout bij actief, 0 fout bij standby)

Herstelscenario:

1 Fout bij actief

0 Fout bij standby

Stappen tot resolutie:

In het scenario van een dubbele supervisor-instelling, met 1 flitsmislukking op de actieve en geen mislukkingen op de standby, kan een niet-beïnvloedend herstel worden uitgevoerd door gebruik te maken van de Flash Recovery Tool.

1. Aangezien de stand-by geen storingen heeft en de actieve slechts één storing heeft, kan de Flash Recovery Tool worden geladen op de actieve en uitgevoerde. Nadat het gereedschap is uitgevoerd, zal het zichzelf automatisch kopiëren naar de stand-by en proberen de array te resynchrone.  De hersteltool kan hier worden gedownload:

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

Zodra u het hulpmiddel hebt gedownload, het uitgepakt, en geüpload het naar de bootflash van de actieve, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:

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

De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.

U kunt de herstelstatus controleren met:

# systeem interne bestand /proc/mdstat tonen

Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:

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>

Na het herstel moet het als volgt zijn:

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>

Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.

2. Als de Flash Recovery Tool niet succesvol is, zou de volgende stap zijn om een "systeem switchover" uit te voeren om de supervisor modules in een onderhoudsvenster te overschakelen.

Daarom, in een gepland venster, voer een "systeem switchover"uit, wordt aanbevolen om console toegang te hebben om het bootproces waar te nemen in het geval dat onverwachte problemen zich voordoen.  Wacht totdat de stand-by volledig wordt opgestart in de "ha-standby"-status.

Nadat de stand-by back-up is, controleer de RAID met "slot x toon systeem interne raid" en "slot x toon systeem interne bestand /proc/mdstat".

Als beide schijven niet volledig back-up na herladen zijn, voert u het herstelprogramma opnieuw uit.

3. Als de herladen en herstel tool niet succesvol zijn, zou het worden aanbevolen om te proberen fysiek opnieuw te starten van de stand-by module in het venster om te proberen en de conditie te wissen.  Als de fysieke herstart niet succesvol is, probeer dan een "Init System" uit te voeren vanuit de switch-opstartmodus door de wachtwoordherstelstappen te volgen om tijdens het opstarten in deze modus te breken.  Neem contact op met TAC om handmatig herstel te proberen, indien nog steeds niet geslaagd.

Scenario E (1 fout bij actief, 1 fout bij standby)

Herstelscenario:

1 Fout bij actief

1 Fout in standby

Stappen tot resolutie:

In het geval van één enkele flitsmislukking op zowel de actieve als stand-by, kan een niet beïnvloedende tijdelijke oplossing nog worden verwezenlijkt.

1. Aangezien geen supervisor in een read-only staat is, is de eerste stap te proberen met behulp van de Flash Recovery Tool.

De hersteltool kan hier worden gedownload:

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

Zodra u het hulpmiddel hebt gedownload, het uitgepakt, en geüpload het naar de bootflash van de actieve, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:

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

Het zal automatisch detecteren losgekoppelde schijven op de actieve en proberen reparatie, evenals automatisch kopiëren naar stand-by en detecteren en corrigeren van fouten daar.

U kunt de herstelstatus controleren met:

# systeem interne bestand /proc/mdstat tonen

Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:

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>

Na het herstel moet het als volgt zijn:

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>

Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.

Als beide toezichthouders herstellen in de status [UU], dan is herstel voltooid.  Als het herstel gedeeltelijk is of niet is geslaagd, gaat u naar Stap 2.

2. Indien de hersteltool niet is geslaagd, de huidige stand van de RAID op de modules aangeven. Als er nog steeds een enkele flitsfout op beide is, probeer dan een "system switchover" die de huidige actieve stroom zal herladen en de stand-by zal dwingen naar de actieve rol.

Nadat de vorige actieve stof opnieuw is geladen in "ha-standby", controleert u de RAID-status zoals deze moet worden hersteld tijdens het opnieuw laden.

Als de supervisor na de overschakeling met succes herstelt, kunt u proberen om de flash recovery tool opnieuw uit te voeren om te proberen en te repareren de single disk fout op de huidige actieve supervisor, of een andere "systeem switchover" om de huidige actieve en kracht de vorige actieve en huidige stand die werd hersteld terug naar de actieve rol. Controleer de herladen supervisor heeft beide schijven opnieuw gerepareerd, herstart de hersteltool indien nodig.

3. Als tijdens dit proces de overschakeling niet de RAID bevestigt, voer dan een "out-of-service module x" uit voor de standby en vervolgens "no power off module x" om de module volledig te verwijderen en opnieuw aan te drijven.

Als het buiten dienst stellen niet succesvol is, probeer dan een fysieke herhaling van de stand-by functie.

Als na het uitvoeren van de hersteltool de ene supervisor zijn RAID herstelt en de andere nog steeds een storing heeft, dwingt u de supervisor met de enkele fout om stand-by te staan met een "systeemswitchover" indien nodig. Als de supervisor met één enkele mislukking is

reeds stand-by, doe een "out-of-service module x" voor de standby- en "no power off module x" om de voeding van de module volledig te verwijderen en opnieuw toe te passen. Als de unit nog steeds niet herstelt, probeer dan een fysieke herhaling van de module. Indien een herhaling niet vaststaat,

breken in de switch boot prompt met behulp van de wachtwoordherstel procedure en doe een "init systeem" om de bootflash te reinitialiseren. Als dit nog steeds niet succesvol is, TAC poging handmatig herstel.

Opmerking: Als de stand-by op enig punt in een "aangedreven-stand" staat en niet in "stand-by", als de stand-by met de bovenstaande stappen niet volledig kan worden ingesteld, moet het chassis opnieuw worden geladen.

scenario F (2 fouten in het actieve circuit, 0 fouten in de stand-by modus)

Herstelscenario:

2 Fouten in het actieve systeem

0 Fout bij standby

Stappen tot resolutie:

Met 2 mislukkingen op de actieve en 0 op de standby supervisor is een niet-beïnvloedend herstel mogelijk, afhankelijk van hoeveel van de in bedrijf zijnde configuratie is toegevoegd sinds de stand-by niet in staat was om zijn in bedrijf zijnde-configuratie met de actieve te synchroniseren.

De herstelprocedure zal zijn om de huidige lopende configuratie te kopiëren van de actieve supervisor, failover naar de gezonde stand-by supervisor, de ontbrekende lopende configuratie te kopiëren naar de nieuwe actieve, handmatig brengen van de vorige actieve online, dan het herstel tool.

1.  Back-up van alle lopende configuratie extern met "copy running-config tftp: vdc-all". Houd er rekening mee dat in het geval van een dubbele flitsfout, configuratie veranderingen aangezien het systeem opnieuw gemonteerd op alleen-lezen niet aanwezig zijn op de opstartconfiguratie. U kunt "toon systeem interne overval"voor de beïnvloede module om te bepalen wanneer de tweede schijf ontbrak die is waar het systeem read-only gaat. Van daaruit kunt u "show accounting log"voor elke VDC bekijken om te bepalen welke veranderingen sinds de dubbele flitsmislukking werden aangebracht zodat u weet wat toe te voegen als de startconfiguratie bij herladen blijft.

Houd er rekening mee dat het mogelijk is dat de opstartconfiguratie wordt afgeveegd bij het opnieuw laden van een supervisor met dubbele flitsfout. Daarom moet van de configuratie extern een back-up worden gemaakt.

2.  Zodra de in werking stellen-configuratie van de actieve supervisor is gekopieerd, zal het een goed idee zijn om het bij de startconfiguratie te vergelijken om te zien wat sinds laatste sparen is veranderd.  Dit is te zien bij "show startup-configuratie".  De verschillen zijn natuurlijk volledig afhankelijk van het milieu, maar het is goed om te weten wat er mis kan gaan als de stand-by online komt als de actieve.  Het is ook een goed idee om de verschillen al gekopieerd in een blocnote te hebben zodat zij snel aan de nieuwe actieve supervisor na de omschakeling kunnen worden toegevoegd.

3.  Nadat de verschillen zijn geëvalueerd, zult u een supervisor switchover moeten uitvoeren.  TAC raadt aan dit te doen tijdens een onderhoudsvenster, omdat zich onverwachte problemen kunnen voordoen.  De opdracht voor het uitvoeren van de failover naar de standby is "system switchover".

4.  De overschakeling zou zeer snel moeten plaatsvinden en de nieuwe stand-by zal beginnen met het opstarten.  Tijdens deze tijd zult u om het even welke ontbrekende configuratie terug aan nieuw actief willen toevoegen.  Dit kan worden gedaan door de configuratie te kopiëren van de TFTP-server (of waar deze eerder is opgeslagen) of door de configuratie in de CLI eenvoudig handmatig toe te voegen.  In de meeste gevallen zijn de ontbrekende configuraties zeer kort en de CLI optie zal het meest haalbaar zijn.

5.  Na enige tijd kan de nieuwe standby-supervisor weer online komen in een "ha-standby"-staat, maar wat normaal gesproken gebeurt is dat het vastloopt in een "aangedreven" staat.  De staat kan worden bekeken met behulp van de "show module" opdracht en verwijzen naar de "Status" kolom naast de module.

Als de nieuwe stand-by in een "aangedreven-up" staat komt, moet u het handmatig weer online brengen.  Dit kan door het uitgeven van de volgende bevelen worden gedaan, waar "x"de standby module is die in een "aangedreven-omhoog"staat wordt geplakt:

(configuratie)# buiten-servicemodule x

(configuratie)# geen uitschakelmodule x

6.  Zodra de stand-by weer online is in een "ha-standby"-staat, moet u de hersteltool uitvoeren om ervoor te zorgen dat het herstel is voltooid.  U kunt de tool downloaden via de volgende link:

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

Zodra u het gereedschap hebt gedownload, uitgelijnd en geüpload naar de bootflash van het vak, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:

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

De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.

U kunt de herstelstatus controleren met:

# systeem interne bestand /proc/mdstat tonen

Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:

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>

Na het herstel moet het als volgt zijn:

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>

Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.

Scenario G (0 mislukt op de actieve versie, 2 mislukt op de standby-modus)

0 fouten op het actieve scherm, 2 fouten op de stand-by

Herstelscenario:

0 fouten op het actieve

2 Kan niet in standby

Stappen tot resolutie:

Met 0 storingen op de actieve en 2 op de standby supervisor is een niet-beïnvloedend herstel mogelijk.

De herstelprocedure bestaat erin de stand-by opnieuw te laden.

1. In supervisor met een dubbele flitsmislukking wordt algemeen gezien dat een software "herlaad module x" slechts gedeeltelijk de INVAL kan herstellen of het geplakt opgewekt bij reboot krijgen.

Daarom is het raadzaam om ofwel fysiek opnieuw te plaatsen de supervisor met dubbele flitsmislukking om volledig te verwijderen en opnieuw toe te passen macht op de module, of u kunt het volgende (x voor standby slot #) uitvoeren:

# buiten dienst gestelde module x

# geen uitschakelmodule x

Als u ziet dat de stand-by blijft vastzitten in de power-up staat en uiteindelijk de power cycling houdt na de stappen hierboven, is dit waarschijnlijk te wijten aan de actieve herladen van de stand voor niet op tijd komen.

Dit kan te wijten zijn aan de opstartstand die probeert om zijn bootflash/RAID opnieuw te initialiseren, die tot 10 minuten kan duren, maar het blijft worden gereset door de actieve voordat het kan bereiken.

Om dit op te lossen, het volgende te configureren met behulp van 'x' voor de standby-sleuf # vastgezet in power-up:

(configuratie)# systeem stand-by handmatige start

(config)# herlastmodule x force-dnld

Het bovenstaande maakt de stand-by modus zo actief dat de stand-by niet automatisch wordt gereset, en herlaadt de stand-by modus en dwingt deze om de afbeelding te synchroniseren met de actieve modus.

Wacht 10-15 minuten om te zien of de stand-by eindelijk in staat is om de ha-standby status te bereiken. Nadat de stand-by status is bereikt, schakelt u de automatische herstart van de stand-by opnieuw in met:

(configuratie)# systeem geen stand-by handmatige start

6.  Zodra de stand-by weer online is in een "ha-standby"-staat, moet u de hersteltool uitvoeren om ervoor te zorgen dat het herstel is voltooid.  U kunt de tool downloaden via de volgende link:

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

Zodra u het gereedschap hebt gedownload, uitgelijnd en geüpload naar de bootflash van het vak, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:

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

De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.

U kunt de herstelstatus controleren met:

# systeem interne bestand /proc/mdstat tonen

Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:

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>

Na het herstel moet het als volgt zijn:

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>

Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.

Scenario H (2 fouten op het actieve systeem, 1 fout in de standby-modus)

2 fouten op de actieve versie, 1 fout op de stand-by

Herstelscenario:

2 Fouten in het actieve systeem

1 Kan niet in standby

Stappen tot resolutie:

Met 2 mislukkingen op de actieve en 1 op de standby supervisor is een niet-beïnvloedend herstel mogelijk, afhankelijk van hoeveel van de in bedrijf zijnde configuratie is toegevoegd sinds de stand-by niet in staat was om zijn in bedrijf zijnde-configuratie met de actieve te synchroniseren.

De herstelprocedure zal zijn om back-up van de huidige lopende configuratie van de actieve supervisor, failover naar de gezonde standby supervisor, kopieer de ontbrekende lopende configuratie naar de nieuwe actieve, handmatig brengen van de vorige actieve online, en voer vervolgens de hersteltool uit.

1.  Back-up van alle lopende configuratie extern met "kopie in werking stellen-configuratie tftp: VDC-all". Houd er rekening mee dat in het geval van een dubbele flitsfout, configuratie veranderingen aangezien het systeem opnieuw gemonteerd op alleen-lezen niet aanwezig zijn op de opstartconfiguratie. U kunt "Toon systeem interne overval" voor de getroffen module om te bepalen wanneer de tweede schijf ontbrak die is waar het systeem gaat read-only. Van daaruit kunt u "show accounting log" voor elke VDC bekijken om te bepalen welke wijzigingen zijn aangebracht sinds de dubbele flitsfout, zodat u weet wat toe te voegen als de opstartconfiguratie bij herladen blijft.

Houd er rekening mee dat het mogelijk is dat de opstartconfiguratie wordt afgeveegd bij het opnieuw laden van een supervisor met dubbele flitsfout. Daarom moet van de configuratie extern een back-up worden gemaakt.

2.  Zodra de in werking stellen-configuratie van de actieve supervisor is gekopieerd, zal het een goed idee zijn om het bij de startconfiguratie te vergelijken om te zien wat sinds laatste sparen is veranderd.  Dit kan worden gezien met "show startup-configuratie".  De verschillen zijn natuurlijk volledig afhankelijk van het milieu, maar het is goed om te weten wat er mis kan gaan als de stand-by online komt als de actieve.  Het is ook een goed idee om de verschillen al gekopieerd in een blocnote te hebben zodat zij snel aan de nieuwe actieve supervisor na de omschakeling kunnen worden toegevoegd.

3.  Nadat de verschillen zijn geëvalueerd, zult u een supervisor switchover moeten uitvoeren.  TAC raadt aan dit te doen tijdens een onderhoudsvenster, omdat zich onverwachte problemen kunnen voordoen.  De opdracht voor het uitvoeren van de failover naar de standby is "system switchover".

4.  De overschakeling zou zeer snel moeten plaatsvinden en de nieuwe stand-by zal beginnen met het opstarten.  Tijdens deze tijd zult u om het even welke ontbrekende configuratie terug aan nieuw actief willen toevoegen.  Dit kan worden gedaan door de configuratie te kopiëren van de TFTP server (of waar het eerder werd opgeslagen) of door de configuratie in de CLI simpelweg handmatig toe te voegen, niet direct van tftp naar running-configuratie te kopiëren, eerst naar bootflash te kopiëren, en dan naar lopende configuratie.  In de meeste gevallen zijn de ontbrekende configuraties zeer kort en de CLI optie zal het meest haalbaar zijn.

5.  Na enige tijd kan de nieuwe standby-supervisor weer online komen in een "ha-standby"-staat, maar wat normaal gesproken gebeurt is dat het vastloopt in een "aangedreven" staat.  De staat kan worden bekeken met behulp van de "show module" opdracht en verwijzen naar de "Status" kolom naast de module.

Als de nieuwe stand-by in een "aangedreven-up" staat komt, moet u het handmatig weer online brengen.  Dit kan door het uitgeven van de volgende bevelen worden gedaan, waar "x"de standby module is die in een "aangedreven-omhoog"staat wordt geplakt:

(configuratie) #out-of-service module

(configuratie)# geen uitschakelmodule x

Als u ziet dat de stand-by blijft vastzitten in de power-up staat en uiteindelijk de power cycling houdt na de stappen hierboven, is dit waarschijnlijk te wijten aan de actieve herladen van de stand voor niet op tijd komen.

Dit kan te wijten zijn aan de opstartstand die probeert om zijn bootflash/RAID opnieuw te initialiseren, die tot 10 minuten kan duren, maar het blijft worden gereset door de actieve voordat het kan bereiken.

Om dit op te lossen, het volgende te configureren met behulp van 'x' voor de standby-sleuf # vastgezet in power-up:

(configuratie)# systeem stand-by handmatige start

(config)# herlastmodule x force-dnld

Het bovenstaande maakt de stand-by modus zo actief dat de stand-by niet automatisch wordt gereset, en herlaadt de stand-by modus en dwingt deze om de afbeelding te synchroniseren met de actieve modus.

Wacht 10-15 minuten om te zien of de stand-by eindelijk in staat is om de ha-standby status te bereiken. Nadat de stand-by status is bereikt, schakelt u de automatische herstart van de stand-by opnieuw in met:

(configuratie)# systeem geen stand-by handmatige start

6.  Zodra de stand-by weer online is in een "ha-standby"-staat, moet u de hersteltool uitvoeren om ervoor te zorgen dat de herstel is voltooid en om de single disk fout op de actieve schijf te repareren.  U kunt de tool downloaden via de volgende link:

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

Zodra u het gereedschap hebt gedownload, uitgelijnd en geüpload naar de bootflash van het vak, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:

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

De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.

U kunt de herstelstatus controleren met:

# systeem interne bestand /proc/mdstat tonen

Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:

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>

Na het herstel moet het als volgt zijn:

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>

Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.

Als de huidige actieve met een enkele fout niet wordt hersteld door de hersteltool, probeer dan een andere "system switchover" om ervoor te zorgen dat uw huidige stand-by status "ha-standby" is.  Als dit nog niet is gelukt, neem dan contact op met Cisco TAC

Scenario I (1 fout bij actief, 2 fouten bij standby)

Herstelscenario:

1 Fout bij actief

2 Kan niet in standby

Stappen tot resolutie:

In een dubbel supervisor scenario met 1 mislukking op de actieve en 2 mislukkingen op de standby supervisor kan een niet-beïnvloedend herstel mogelijk zijn, maar in veel gevallen kan een herlading noodzakelijk zijn.

Het proces zal aan eerste back-up alle lopende configuraties zijn, dan proberen om de mislukte compacte flits op de actieve met behulp van het herstel hulpmiddel terug te krijgen, dan, als succesvol, zal u handmatig opnieuw laden van de stand-by en het herstel gereedschap opnieuw uitvoeren.  Als de eerste herstelpoging niet in staat is om de mislukte flitser op het actieve bestand te herstellen, moet TAC worden ingeschakeld om een handmatig herstel te proberen met behulp van de debug plugin.

1.  Back-up van alle lopende configuratie extern met "copy running-config tftp: vdc-all".  U kunt ook het in werking stellen-configureren kopiëren naar een lokale USB-stick als een TFTP-server niet is ingesteld in de omgeving.

2.  Zodra de huidige in werking stellen-configuratie wordt gesteund, zult u dan het terugwinningshulpmiddel moeten in werking stellen om een terugwinning van de ontbroken flits op actief te proberen.  U kunt de tool downloaden via de volgende link:

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

Zodra u het gereedschap hebt gedownload, uitgelijnd en geüpload naar de bootflash van het vak, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:

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

De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.

U kunt de herstelstatus controleren met:

# systeem interne bestand /proc/mdstat tonen

Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:

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>

Na het herstel moet het als volgt zijn:

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>

Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.

3.  Als u, na het uitvoeren van de Recovery Tool in stap 2, niet in staat bent om de mislukte compacte flitser op de actieve supervisor te herstellen, moet u contact opnemen met TAC om een handmatig herstel te proberen met behulp van de linux debug plugin.

4.  Na te hebben gecontroleerd dat beide knipperingen worden weergegeven als "[U]" op de actieve, kunt u doorgaan met het handmatig opnieuw opstarten van de standby supervisor.  Dit kan door het uitgeven van de volgende bevelen worden gedaan, waar "x"de standby module is die in een "aangedreven-omhoog"staat wordt geplakt:

(configuratie)# buiten-servicemodule x

(configuratie)# geen uitschakelmodule x

Dit zou de standby supervisor terug in een "ha-standby"staat moeten brengen (dit wordt gecontroleerd door de kolom van de Status in de "show module"output te bekijken).  Als dit geslaagd is, gaat u verder naar stap 6 en als dit niet het geval is, probeert u de procedure die in stap 5 is beschreven.

5.  Als u ziet dat de stand-by blijft vastzitten in de power-up staat en uiteindelijk de power cycling houdt na de stappen hierboven, is dit waarschijnlijk te wijten aan de actieve herladen van de stand voor niet op tijd komen.  Dit kan te wijten zijn aan de opstartstand die probeert om zijn bootflash/RAID opnieuw te initialiseren, die tot 10 minuten kan duren, maar het blijft worden gereset door de actieve voordat het kan bereiken.  Om dit op te lossen, het volgende te configureren met behulp van 'x' voor de standby-sleuf # vastgezet in power-up:

(configuratie)# systeem stand-by handmatige start

(config) #reload module x force-dnld

Het bovenstaande maakt de stand-by modus zo actief dat de stand-by niet automatisch wordt gereset, en herlaadt de stand-by modus en dwingt deze om de afbeelding te synchroniseren met de actieve modus.

Wacht 10-15 minuten om te zien of de stand-by eindelijk in staat is om de ha-standby status te bereiken. Nadat de stand-by status is bereikt, schakelt u de automatische herstart van de stand-by opnieuw in met:

(configuratie)# systeem geen stand-by handmatige start

6.  Zodra de stand-by weer online is in een "ha-standby"-staat, moet u de hersteltool uitvoeren om ervoor te zorgen dat het herstel is voltooid.  U kunt hetzelfde gereedschap uitvoeren dat u hebt op de actieve voor deze stap, geen extra download is nodig als de hersteltool draait op de actieve en de stand-by.

scenario J (2 fouten in actief, 2 fouten in standby)

Herstelscenario:

2 Fouten in het actieve systeem

2 Kan niet in standby

Stappen tot resolutie:

In een dubbele supervisor met dubbele flitsmislukking, moet een verstorend herladen worden uitgevoerd om te herstellen. Volg de volgende stappen voor een resolutie:

1. Back-up van alle lopende configuratie extern met "copy running-config tftp: vdc-all". Houd er rekening mee dat in het geval van een dubbele flitsfout, configuratie veranderingen aangezien het systeem opnieuw gemonteerd op alleen-lezen niet aanwezig zijn op de opstartconfiguratie. U kunt "toon systeem interne overval"voor de beïnvloede module om te bepalen wanneer de tweede schijf ontbrak die is waar het systeem read-only gaat. Van daaruit kunt u "show accounting log"voor elke VDC bekijken om te bepalen welke veranderingen sinds de dubbele flitsmislukking werden aangebracht zodat u weet wat toe te voegen als de startconfiguratie bij herladen blijft.

Houd er rekening mee dat het mogelijk is dat de opstartconfiguratie wordt afgeveegd bij het opnieuw laden van een supervisor met dubbele flitsfout. Daarom moet van de configuratie extern een back-up worden gemaakt.

2. Herlaad het apparaat, wordt sterk geadviseerd om consoletoegang te hebben en de fysieke toegang kan worden vereist. De supervisor zou zijn bootflash moeten herladen en herstellen. Controleer na het installeren van het systeem of beide schijven actief zijn met de status [UU] in "Toon systeem interne bestand /proc/mdstat" en "toon systeem interne overval". Als beide schijven actief zijn dan is het herstel voltooid en kunt u werken om alle vorige configuratie te herstellen. Als het herstel niet of slechts gedeeltelijk is geslaagd, gaat u naar stap 3.

Opmerking: Het wordt vaak gezien in gevallen van dubbele flitsmislukkingen, een software "herladen" kan niet volledig herstellen van de RAID en kan het uitvoeren van de hersteltool of daaropvolgende herladen vereisen om te herstellen. In bijna elk geval is het opgelost met een fysieke herhaling van de supervisor module. Daarom, als fysieke toegang tot het apparaat mogelijk is, na externe back-up van configuratie, kunt u proberen een snel herstel dat de hoogste kans van slagen heeft door de supervisor fysiek te resetten wanneer klaar om het apparaat te herladen. Dit zal volledig de macht van de supervisor verwijderen en zou het herstel van beide schijven in de INVAL moeten toestaan. Ga verder met Stap 3 als het fysieke herstel slechts gedeeltelijk is, of Stap 4 als het volledig niet succesvol is in dat het systeem niet volledig opstart.

3. In het geval van een gedeeltelijk herstel, dat wil zeggen nadat de ene schijf is herladen en de andere nog steeds is met de status [U_], zou de volgende aanbevolen stap zijn om te proberen de Flash Recovery Tool uit te voeren om de andere schijf opnieuw te synchroniseren. Als de hersteltool niet succesvol is, neem contact op met TAC om handmatige herstelstappen te proberen. Een fysieke herhaling van de supervisor kan ook worden geprobeerd.  De hersteltool kan worden gedownload van de volgende link:

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

Als het herladen niet resulteert in beide supervisors volledig opstarten, gelieve een fysieke herhaling van de supervisor module uit te voeren. Merk op dat het vaak wordt gezien in een conditie van dubbele flitsmislukking dat een software "herladen" niet volledig herstellen beide schijven als de macht niet volledig wordt verwijderd uit de module, die wordt bereikt met een fysieke herhaling. Als de fysieke herhaling niet succesvol is, gaat u naar stap 4.

4. In het geval een fysieke herhaling niet succesvol is, zou de volgende stap in laderherinnering te breken met behulp van de wachtwoordherstelstappen, de kickstart te laden om switch bootmode, en een "init systeem" uit te voeren, dat de bootflash zal afvegen en zal proberen om de array te herstellen. Als het init systeem voltooit of faalt en nog steeds een probleem ziet, probeer dan een andere fysieke herhaling.

Als na de voltooiing van alle bovengenoemde stappen het herstel niet succesvol is, is het waarschijnlijk een zeldzaam geval van ware hardwarestoringen, en de supervisor zal moeten worden vervangen via RMA. Dit is de reden waarom alle configuratie extern moet worden ondersteund voorafgaand aan de herstelstappen, in het geval een noodRMA is vereist, hebt u alle nodige configuratie om het systeem snel weer op te starten.

Samenvatting

Veelgestelde vragen

Is er een permanente oplossing voor deze kwestie?

Zie het gedeelte over langetermijnoplossingen hieronder.

Waarom is het niet mogelijk om een dubbele failover op de actieve en stand-by te herstellen door de standby supervisor te herladen en failover?

De reden dat dit niet mogelijk is is omdat om de standby supervisor toe te staan om in een "ha-standby"staat omhoog te komen, de actieve supervisor verscheidene dingen aan zijn compacte flits (SNMP info, enz.) moet schrijven, die het niet kan doen als het een dubbele flitsmislukking zelf heeft.

Wat gebeurt er als de Flash Recovery Tool niet in staat is om de compacte flitser te hertellen?

Neem contact op met Cisco TAC voor opties in dit scenario.

Heeft deze bug ook invloed op de Nexus 7700 Sup2E?

De N7700 Sup2E - CSCuv64056 heeft een eigen defect.  De hersteltool werkt niet voor de N7700.

Werkt de hersteltool voor NPE-afbeeldingen?

De hersteltool werkt niet voor NPE-afbeeldingen.

Zal een kwestie aan een opgeloste versie van code deze kwestie oplossen?

Nee. Een ISSU zal gebruik maken van een supervisor switchover, die mogelijk niet correct presteert vanwege de compacte flitsstoring.

We reset het betreffende bord. Raid status drukt 0xF0, maar GOLD testen nog steeds niet?

RAID status bits worden gereset nadat board reset na toepassing van auto herstel.

Niet alle foutcondities kunnen echter automatisch worden hersteld.

Als de RAID-statusbits niet zijn afgedrukt als [2/2] [UU], is het herstel onvolledig.

Volg de genoemde herstelstappen

Zal de flitsstoring enige invloed hebben op de werking?

Nee, maar het systeem start mogelijk niet op bij een stroomuitval. Startup configuraties zullen ook verloren gaan.

Wat wordt aanbevolen voor een gezond, actief systeem vanuit het perspectief van de klant in termen van bewaking en herstel?

Controleer de GOLD compacte teststatus voor eventuele storingen en probeer herstel zodra het eerste flitsonderdeel mislukt.

Kan ik een mislukte eusb-flitsstoring oplossen door een ISSU uit de code te doen die is aangetast naar de vaste release?

ISSU zal mislukte eUSB niet repareren. De beste optie is om de hersteltool uit te voeren voor een enkele eusb fout op de sup of herladen van de sup geval van dubbele eusb falen.

Voer de upgrade uit als het probleem is opgelost. De oplossing voor CSCus22805 helpt alleen enkele sabfout te corrigeren en doet dit door het systeem met regelmatige tussenpozen te scannen en probeert ontoegankelijke of alleen-lezen eUSB opnieuw te activeren met behulp van het script.

Het is zeldzaam om te zien dat beide eusb flash-uitval op de supervisor tegelijkertijd voorkomen, vandaar dat deze tijdelijke oplossing zal effectief zijn.

Hoe lang duurt het voordat het probleem opnieuw verschijnt als u de flitsstoringen oplost met behulp van plugin of herladen?

Over het algemeen wordt het gezien door een langere uptime. Dit is niet precies gekwantificeerd en kan variëren van een jaar of langer. Het komt er op neer dat hoe meer stress op de USB-flitser in termen van lees schrijft, hoe groter de waarschijnlijkheid dat het systeem dit scenario tegenkomt.

Toon systeem interne overval toont de flitsstatus tweemaal in verschillende secties. Ook deze punten zijn niet consistent

De eerste sectie toont de huidige status en de tweede sectie toont de bootup status.

De huidige status is wat er toe doet en moet altijd als UU worden getoond.

Langetermijnoplossingen

Dit defect heeft een tijdelijke oplossing in 6.2(14), maar de firmware fix werd toegevoegd aan 6.2(16) en 7.2(x) en later.

Het is aan te raden om te upgraden naar een release met de firmware fix om dit probleem volledig op te lossen.

Als u niet kunt upgraden naar een vaste versie van NXOS, zijn er twee mogelijke oplossingen.

Oplossing 1 moet de flash recovery tool proactief elke week met behulp van de planner.  De volgende plannerconfiguratie met de flash recovery tool in de bootflash:

functieplanner

naam planner-taak Flash_Job

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

load bootflash:/flash_recovery_tool_copy

uitgang

Planner Schema naam Flash_Recovery

Taaknaam Flash_Job

wekelijkse tijd 7

Opmerkingen:

- Het flash herstel moet dezelfde naam en in de bootflash.

- De 7 in de "tijd week 7"-configuratie staat voor een dag van de week, in dit geval zaterdag.

- De maximale frequentie die Cisco aanbeveelt voor het gebruik van de flash recovery tool is eenmaal per week.

Oplossing 2 is gedocumenteerd via de volgende technologielink