Probleemoplossing 3650/3850 stackbeheer - herladingen

Inleiding

Dit document beschrijft hoe u systeemrapporten kunt gebruiken om problemen met stapels te diagnosticeren.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Als je stack reloads oplost via een systeemrapport in afwezigheid van een crash wordt vaak gedaan op NGWC-schakelplatforms gebruik je de stapelbare technologie. De huidige documentatie is beperkt tot het gebruik van een systeemrapport en in deze handleiding wordt uitgelegd hoe u deze rapporten kunt gebruiken om problemen te diagnosticeren die doorgaans bij stapelproblemen worden gevonden. Deze handleiding is in het bijzonder gericht op de Catalyst 3650/3850 Switch-architecturen waarop Cisco IOS® XE met stapelmogelijkheden wordt uitgevoerd.

De meeste problemen met stapelbare technologie vloeien voort uit een communicatieprobleem tussen de leden binnen een stapel. Elke inconsistentie van informatie tussen de leden of verlies van connectiviteit kan resulteren in een probleem dat doordringt in de gehele stapel en uiteindelijk leidt tot een reset met stack manager. Dit document kan een aantal van de gebruikelijke soorten fouten die worden gezien bij stack-manager-reloads, gebruik van een systeemrapport en relevante CLI's die beschikbaar zijn voor diagnoses en verschillende soorten problemen belichten.

Systeemrapport versus Switch rapporten

Een system-report is een uitgebreid rapport van het lid over hoe het de status van de stapel waarneemt. Dit is geen crashinformatie (die geheugen kan dumpen voor verdere debugging), maar in plaats daarvan, is het een rapport dat logboeken en het zuiveren informatie voor diverse diensten heeft die onder Cisco IOS XE lopen die voor ontwikkeling nuttig zouden zijn om de staat van die dienst te volgen. Er kan een systeemrapport worden gegenereerd wanneer de switch wordt herladen door stack manager, er een procescrash heeft plaatsgevonden of handmatig door de gebruiker wordt gegenereerd tijdens de actieve handeling.

In veel gevallen kan een enkele switch in een stapel mislukken, maar de rest van de leden kan intact blijven. Om informatie te verzamelen over de status van de stack op het gegeven moment, werden switch_reports geïntroduceerd zodat de huidige leden er een kunnen genereren als ze merkt dat een lid is gedaald. Switch_report kan een lokaal rapport zijn van hoe dat lid de huidige status van de stack ziet.

Opmerking: deze rapporten worden geschreven en gecomprimeerd, zodat ze niet met meer kunnen worden afgedrukt naar de terminal. Ze kunnen worden verplaatst van de switch en gedecompresseerd om het logbestand te bekijken.

Waar systeem/Switch-rapporten moeten worden verzameld

Systeemrapporten kunnen meestal worden geschreven in de crashinfo: map van het lid in die stapel. Als er bijvoorbeeld een x-lid switch stack is, dan kan elke switch zijn eigen crashinfo directory hebben die toegankelijk kan zijn met dir crashinfo-x waar x overeenkomt met dat lid in de stack.

3850#dir crashinformatie-1:

Directory of crashinformatie:/    

11 -rwx 355 aug 14 2015 07:48:17 -04:00 last_systemreport_log  

12 -rwx 724015 okt 15 2014 07:14:32 -04:00 systeem-rapport_1_20141015-111342-UTC.gz

3850#dir crashinformatie-2:

Directory of crashinfo-2:/   

11 -rwx 357 aug 14 2015 07:50:49 -04:00 last_systemreport_log  

12 -rwx 751340 okt 15 2014 06:41:12 -04:00 systeem-report_1_20141015-104022-UTC.gz

Opmerking: Zorg ervoor dat u de uitvoer voor dir crashinfo-x verzamelt voor elke switch in die stapel, omdat de show tech niet de beschikbare bestandssystemen of de crashinfo bestanden kan weergeven. Het is belangrijk dat je het hele beeld van elk lid in die stapel hebt. Update: Vanaf de nieuwere Cisco IOS XE releases >3.6E, kan de show technologie de dir crashinformatie weerspiegelen: + toon bestandssystemen uitvoer. Zie Cisco bug-id CSC50428.

Opmerkelijke secties in het systeemrapport

Vanuit een TAC-perspectief zijn dit enkele van de meer algemeen bekeken vermeldingen in het systeemrapport die kunnen helpen bij het diagnosticeren van gebeurtenissen van een specifiek probleem. Er zijn andere logboeken van andere diensten in hier die de ontwikkeling kan vinden wil te herzien.

logbestand: /mnt/pss/sup_sysmgr_reset.log

Dit is een korte output om in het algemeen te begrijpen waarom een reset werd gezien. Zie de volgende soorten mislukkingen sectie om de betekenis en context te kijken in hoe deze redenen kunnen variëren.

Logbestand: Cisco IOS

Dit is de logbuffer die vanuit Cisco IOSd wordt onderhouden. Alle opdrachten die door de gebruiker zijn gegenereerd of die binnen Cisco IOSd zijn gegenereerd, kunnen in deze sectie worden gevonden. De meeste recente logboeken zijn tegen het eind van deze output.

Trace-buffer: stack-mgr-gebeurtenissen

Houdt gebeurtenissen bij die worden gezien van stapelmanager die kunnen omvatten wanneer andere leden zich aansluiten bij/verwijderd uit de stapel of welke stapelpoort de berichten binnenkomen door.

               

Trace Buffer: redundantie-timer-ha_mgr

De vertoningen houden levendige gebeurtenissen tussen switches in de stapel. De tijdstempels kunnen helpen bepalen wanneer de uitsplitsing in communicatie is gestart.

Typen fouten

Deze sectie kan sommige algemeen gezien terugstellen van een systeemrapport benadrukken die typisch door het proces van de stapelmanager worden aangehaald. Stack Manager is een Linux-proces dat de leden in de stack beheert en kan toezien op alle veranderingen in rollen tussen switches in de stack. Als stack manager tijdens de initialisatie of rolselectie een probleem detecteert, kan er een herladingssignaal naar individuele switches worden gestuurd, zodat de stack kan worden gereset. De volgende lijst kan ook een lijst maken van bekende bugs die zijn gekoppeld aan het betreffende type fout.

Reden opnieuw instellen:opnieuw laden gevraagd door [stack-manager]. [ISSU-incompatibiliteit]

U kunt dit type van terugstellen zien wanneer er een bulksynchronisatiefout is wanneer u probeert om de configuratie op actief tussen alle leden in de stapel te synchroniseren. Controleer het logbestand: Cisco IOS of de logs uit de actieve switch kunnen de configuraties markeren die hebben bijgedragen aan deze reset.

Reset Reden:Service [iosd] pid:[xyz] abnormaal afgesloten [11].

Dit werd gezien toen de switch crasht in Cisco IOSd-proces. Bekijk de crashinfo directories voor alle crashinfo bestanden + core dumps kunnen worden gebruikt om deze fout verder te zuiveren.

hap_sup_reset: Reset Reason:Reset/Reload aangevraagd door [stack-manager]. [Stapelen samenvoegen]

Een stapelfusie wordt gezien wanneer er twee of meer switches zijn die geloven dat zij de actieve switch van de stapel zijn. Dit is te zien wanneer er een breuk is in de ring van een stapel (dat wil zeggen, twee kabels zijn losgekoppeld van de stapel), zodat zowel de actieve als de stand-by communicatie met de andere leden verliest. De toevoeging van een reeds aangedreven switch aan een huidige stapel kan een stapelsamenvoeging veroorzaken aangezien er twee actieve switches in de stapel kunnen zijn.

Cisco bug-id CSC58098 - 3850 stack kan opnieuw worden geladen wanneer er problemen zijn met stackbekabeling

Cisco bug-id CSCui56058 - maakt defaultlogica voor stapelkabel mogelijk

Cisco bug-id CSCup5338 - 3850 SD-crash | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

hap_sup_reset: Reason Code:[4] Reset Reason:Reset/Reloadrequest by [stack-manager]. [stack samenvoegen vanwege incompatibiliteit]

Dit is waargenomen in situaties waarin een actieve en stand-by switch in de stapel aanwezig is. Als de actieve switch de communicatie met de stand-by verliest, kan de stand-by proberen om over te nemen als de actieve, ook al is de actieve nog actief.

Cisco fout-id CSCuo49555

Cisco bug-id CSCup58016 - 3850/3650 crashes als gevolg van unicastoverstroming op beheerpoort

Cisco bug-id CSCur07909 - Stapelsamenvoeging vanwege actieve en stand-by verloren connectiviteit

Reden opnieuw instellen:opnieuw laden gevraagd door [stack-manager]. [Verkeerde buur aangetroffen na ASIC-stemming]

Switches nemen deel aan een ASIC stembiljet tijdens het opstarten om de naburige switches binnen de stapel te bepalen. Deze reset kan worden gezien wanneer een timer vervalt voor een buurman om zichzelf te verklaren of als er een logische fout is tijdens het nbrcast gesprek. Dit is gezien in de context van defecte stapelkabels die door vervanging zijn opgelost.

Cisco bug-id CSCun60777 - Switch opnieuw geladen vanwege verkeerde buur na stemming op ASIC

Cisco bug-id CSCud93761 - Switch opnieuw geladen vanwege verkeerde buur na stemming op ASIC

Cisco bug-id CSCun17506 - Amoer:ng3k:dezelfde buur is te zien op beide stackpoorten op een 3-lidstack

hap_sup_reset: Reason Code:[4] Reset Reason:Reset/Reload gevraagd door [stack-manager]. [zowel actief als stand-by verloren]

Dit wordt typisch gezien van een lid op de stapel dat niet in een actieve of standby rol is. Wanneer het actieve bestand mislukt, als er geen stand-by switch is om de actieve rol voor de stapel over te nemen, dan kan de gehele stapel worden gereset. Als de stapel een instabiele staat is of het overtolligheidsbeleid nog niet gesynchroniseerd, kan dit worden gezien. Dit is waarschijnlijk een slachtoffer van de reden waarom de actieve/stand-by switches daalden of mogelijk een indicatie dat redundantie niet correct synchroniseert. Dit is ook te zien wanneer stapels zijn geconfigureerd in een halve ring.

Cisco bug-id CSCup5382 - switches van leden in een 3850 stack reboot - [verloren zowel actief als stand-by]

hap_sup_reset: Reason Code:[1] Reset Reason:Reset/Reload gevraagd door [stack-manager]. [Levenslang_Time-out]

Gezien wanneer de levensechte berichten niet van de switch in de stapel worden ontvangen. Kijk naar de Trace Buffer: redundantie-timer-ha_mgr en het toont de uitwisseling van "keep live"-berichten en biedt een tijdsperspectief voor wanneer de storing in communicatie begon. Als u switch rapporten van de rest van de stapel verzamelt en logboeken door het tijdkader bekijken kan helpen.

hap_sup_reset: Reset Reason:Reset/Reload aangevraagd door [stack-manager]. [Opnieuw laden]

Dit is een vrij intuïtieve reset reden - dit wordt gezien wanneer stack-manager een herladingsverzoek ontvangt dat via CLI of extern via het beheerapparaat (SNMP) kan worden opgeroepen. In gevallen van de Cisco bug-id CSCuj17317, verschijnt dit ook als een herladenopdracht die ook is gegenereerd. Van het logbestand: Cisco IOS kunt u zien:

CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr:  Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr:  Reloading due to reason Reload command

Verwante bugs

Cisco bug-id CSCur76872 - Stack manager gaat naar beneden wanneer het systeem geen SDP-buffer meer heeft.

Cisco bug-id CSCup49704 - 3850 FED-crash - wacht op SPI-kanalen FED_SPI_FLCD,FED_SPI_FAST ...

Een mogelijke stackkabel of poortprobleem diagnosticeren

Symptoom 1) Elk teken van een probleem met de stapelkabel wordt zichtbaar door elke flapping van de stapelpoort voordat de reset plaatsvindt. Bekijk het logbestand: Cisco IOS rapport voorafgaand aan een reset is meestal een goede plek om te beginnen. Hier is een voorbeeld van waar u flapping ziet van de stapelpoort die is geregistreerd op zowel de huidige SW2 als de standby SW1. Deze zelfde stapelpoort knipte elk in elke instantie van de reset en werd opgelost toen de stapelkabel werd vervangen:

=====================  log file: Cisco IOS  =====================
.
.
Aug  8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is down  (SW1-1)
Aug  8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is up  (SW1-1)
Aug  8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr:  Switch 1 has been removed from the stack.
Aug  8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1

Symptoom 2) Gebaseerd op de stapelbare opstelling wordt gebruikt (180, 480, plus), varieert het aantal transmissieringen per haven ASIC. Deze commando's houden globale registers bij die een totaal houden dat toeneemt met hoeveel leesfouten er worden gezien voor elke transmissie ring. Poortasic 0 komt overeen met stapelpoort 1 en poortasic 1 komt overeen met stapelpoort 2. Dit moet voor elke switch worden afgegeven en elk teken van tellingen die de toename kan isoleren of er een probleem kan zijn op de poort of met de stapelkabel.

Deze kunnen meerdere malen in een paar minuten worden verzameld om de delta's in de telling te vergelijken:

platform weergeven poort-asic <0-1> lees register SifRacDataCrcErrorCnt switch <switch#>

• Segment met gegevens-CRC-fout.

show platform port-asic <0-1> lees register SifRacRwCrcErrorCent switch <switch#>

• Verhoogd op elke mislukte CRC-controle.

show platform port-asic <0-1> lees register SifRacPcsCodeWordErrorCnt switch <switch#>

• Verhoogd op ongeldige PCS-code, onbekend PCS-codewoord, waarmee een gedetecteerde dispariteitsfout wordt uitgevoerd.

show platform port-asic <0-1> lees register SifRacInvalidRingWordCnt switch <switch#>

• Bit fout op stack veroorzaakt ringword CRC fout.

Voor Polaris (16.X-code) zijn dit de opdrachten:

Toon platte hardware fed sw <#/active/stand-by> fwd-asic register-naam lezen SifRacDataCrcErrorCent asic <0-1> 

Toon platte hardware gevoed sw <#/active/standby> fwd-asic register lees register-naam SifRacRwCrcErrorCent asic<0-1>

Toon platte hardware fed sw <#/active/stand-by> fwd-asic register-naam lezen SifRacPcsCodeWordErrorCent asic <0-1>

Toon platte hardware fed sw <#/active/stand-by> fwd-asic register-naam lezen SifRacInvalidRingWordCnt asic <0-1>

Dit voorbeeld laat zien waar je een stack merge event had gezien die beide leden van een 2-leden stack zag zonder enig teken van een flapping stack poort. U ziet de toename in ring[0] met CRC's op stack poort-1 van switch 1 en om voorbij dit probleem te komen, vervangt u de stapelkabel.

3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015

For asic 0

SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x00000031 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001
                               
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015

For asic 0

SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x000000c9 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001

Aanvullende tips

1. Archief Crashinfo directory's

Meer switches in de stapel betekent dat er meer rapport bestanden kunnen worden verzameld. Het aantal rapporten dat wordt opgesteld, maakt het niet uit. Organisatie is van vitaal belang om een mislukking los te koppelen. Vind een consistentie met tijdstempels van wanneer elke switch een rapportbestand voor een bepaald incident schreef, indien mogelijk. Van daaruit, vraag naar die zeer specifieke rapporten van die gegeven switches zodat de klant niet meerdere bestanden uploadt. De map crashinformatie kan ook worden gearchiveerd, zodat de Cisco-gebruiker één archief kan verzenden met de geïnteresseerde rapporten. Het volgende voorbeeld kan een archief met de naam crashinfo-archive.tar maken in de map flash:

F340.03.10-3800-1#archive tar /create ?
 WORD Tar filename

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
 WORD Dir to archive files from

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
 WORD File or Dir
 <cr>

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:

2. Een instabiele stack herstellen

Er kunnen situaties zijn waarin u een aantal leden ziet in een stack reload tijdens het opstarten nadat het stack verkiezingsproces plaatsvindt. Als een herladen switch zichzelf als actief beschouwt, kan dit vaak leiden tot een stack merge event en kan het in een boot loop status. In deze situatie kan het raadzaam zijn de Cisco-client de volgende vragen te stellen:

• Schakel de hele stapel uit en stel alle stackkabels stevig terug.
• Schakel elke switch in de stapel één voor één in totdat alle leden zijn geconvergeerd naar de verwachte status.
• In gevallen waarin een lid er niet in slaagt om zich aan te sluiten bij de stapel, verwijder dit uit de stapel en probeer deze persoon als standalone te starten om verder problemen op te lossen.

3. Systeemrapporten handmatig genereren

Een handmatig gemaakt systeemrapport vereist dat de service intern is ingeschakeld. Dit schrijft een systeemrapport als een tekstbestand dat per switch kan worden gemaakt.

3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit

3800-1#resource create_system_report ?
 WORD system report filename

3800-1#resource create_system_report sysreport.txt ?
 switch Switch number
 <cr>

3800-1#resource create_system_report sysreport.txt switch ?
 <1-1> Switch number

3800-1#resource create_system_report sysreport.txt switch 1 ?
 <cr>

Gerelateerde informatie

• Cisco Technical Support en downloads