Risoluzione Dei Problemi Di Ricaricamento Di Stack Manager 3650/3850

Introduzione

Questo documento descrive come usare i report di sistema per diagnosticare i problemi dello stack.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Se si devono risolvere problemi di ricaricamento dello stack tramite un report di sistema in assenza di un crash, in genere si utilizza la tecnologia stackwise sulle piattaforme di switching NGWC. La documentazione corrente è limitata agli utilizzi di un report di sistema e questa guida spiega come utilizzare questi report per diagnosticare i problemi tipicamente riscontrati con i problemi di stack. Questa guida è destinata in particolare alle architetture degli switch Catalyst 3650/3850 con Cisco IOS® XE con funzionalità di stacking.

La maggior parte dei problemi relativi alla tecnologia stackwise deriva da un problema di comunicazione tra i membri di uno stack. L'incoerenza delle informazioni tra i membri o la perdita di connettività possono causare un problema che attraversa l'intero stack e in ultima analisi portare a un reset con lo stack manager. Questo documento può evidenziare alcuni dei tipi di guasti più comuni riscontrati con il ricaricamento dello stack manager, l'uso di un report di sistema e le CLI appropriate disponibili per la diagnosi e diversi tipi di problemi.

Report di sistema e report di switch

Un report di sistema è un report completo del membro dal modo in cui percepisce lo stato dello stack. Non si tratta di un crashinfo (che può scaricare memoria per ulteriori operazioni di debug), ma di un report contenente log e informazioni di debug per vari servizi eseguiti in Cisco IOS XE che sarebbe utile allo sviluppo per tenere traccia dello stato di tale servizio. È possibile generare un report sul sistema quando lo switch viene ricaricato dallo stack manager, si è verificato un arresto anomalo del processo o è stato generato manualmente dall'utente durante le operazioni in tempo reale.

In molti casi, un singolo switch può guastarsi in uno stack, ma il resto dei membri può rimanere intatto. Per raccogliere informazioni sullo stato dello stack in un determinato momento, sono stati introdotti i report_switch in modo che i membri correnti possano generarne uno quando rilevano che un membro è diventato inattivo. Il report_switch può essere un report locale che mostra in che modo il membro percepisce lo stato corrente dello stack.

Nota: questi rapporti vengono scritti e compressi in modo che non possano essere stampati sul terminale con altro materiale. Potrebbe essere necessario trasferirle dallo switch e decomprimerle per visualizzare il registro.

Dove raccogliere i report di sistema/switch

I report di sistema possono in genere essere scritti nella directory crashinfo: del membro appartenente allo stack. Ad esempio, se è presente uno stack di switch x, ciascuno switch può avere la propria directory crashinfo accessibile con dir crashinfo-x, dove x corrisponde a quel membro all'interno dello stack.

3850#dir crashinfo-1:

Directory di crashinfo:/    

11 -rwx 355 ago 14 2015 07:48:17 -04:00 ultimo_systemreport_log  

12 -rwx 724015 ott 15 2014 07:14:32 -04:00 rapporto-sistema_1_20141015-111342-UTC.gz

3850#dir crashinfo-2:

Directory di crashinfo-2:/   

11 -rwx 357 ago 14 2015 07:50:49 -04:00 ultimo_systemreport_log  

12 -rwx 751340 ott 15 2014 06:41:12 -04:00 rapporto-sistema_1_20141015-104022-UTC.gz

Nota: accertarsi di raccogliere l'output per dir crashinfo-x per ciascuno switch nello stack perché show tech non può elencare i file system disponibili o i file crashinfo. È importante disporre dell'immagine completa di ciascun singolo membro appartenente allo stack. Aggiornamento: a partire dalle nuove versioni di Cisco IOS XE >3.6E, il comando show tech può riflettere l'output del comando crashinfo: + show file systems. Vedere l'ID bug Cisco CSCun50428.

Sezioni rilevanti nel report di sistema

Dal punto di vista TAC, queste sono alcune delle voci più comunemente visualizzate nel report di sistema che possono aiutare a diagnosticare gli eventi di un problema specifico. In questa sezione sono contenuti altri log di altri servizi che lo sviluppo potrebbe voler esaminare.

file di log: /mnt/pss/sup_sysmgr_reset.log

Questo è un output breve per capire in modo molto generico perché è stato visto un reset. Vedere la sezione successiva relativa ai tipi di errore per esaminare il significato e il contesto delle possibili variazioni di questi motivi.

file di log: Cisco IOS

Si tratta del buffer di registro gestito da Cisco IOSd. In questa sezione sono riportati tutti i comandi emessi dall'utente o dai syslog generati in Cisco IOSd. I log più recenti sono verso la fine di questo output.

Buffer di traccia: stack-mgr-events

Tiene traccia degli eventi visualizzati dal gestore dello stack, che possono verificarsi quando altri membri vengono aggiunti o rimossi dallo stack o tramite quale porta dello stack passano i messaggi.

               

Buffer di traccia: redundancy-timer-ha_mgr

Visualizza gli eventi keep-alive tra gli switch dello stack. Gli indicatori di data e ora possono aiutare a determinare quando è iniziata la comunicazione interrotta.

Tipi di errori

In questa sezione vengono evidenziati alcuni dei ripristini più comuni rilevati da un report di sistema che in genere vengono richiamati dal processo di gestione dello stack. Lo Stack Manager è un processo Linux che gestisce i membri dello stack e può supervisionare le modifiche ai ruoli tra gli switch dello stack. Se lo stack manager rileva un problema durante l'inizializzazione o la scelta del ruolo, può inviare un segnale di ricaricamento ai singoli switch per reimpostare lo stack. Nell'elenco successivo vengono anche elencati i bug noti associati al rispettivo tipo di errore.

Reimpostazione Motivo:reimpostazione/ricaricamento richiesto da [stack-manager]. [Incompatibilità PROBLEMA]

Questo tipo di ripristino è visibile quando si verifica un errore di sincronizzazione globale quando si cerca di sincronizzare la configurazione sul dispositivo attivo tra tutti i membri dello stack. Controllare il file di registro: Cisco IOS o i log dello switch attivo possono evidenziare le configurazioni che hanno contribuito a questo ripristino.

Reimpostazione Motivo:PID [iosd]:[xyz] terminato in modo anomalo [11].

Questa condizione si verifica quando lo switch si blocca nel processo Cisco IOSd. Esaminare le directory di crashinfo per individuare i file di crashinfo + i dump dei core che possono essere utilizzati per eseguire ulteriormente il debug di questo errore.

hap_sup_reset: Reset. Motivo:Reset/Reload richiesto da [stack-manager]. [unione stack]

L'unione dello stack si verifica quando due o più switch sono considerati switch attivi dello stack. Questa condizione può essere rilevata quando si verifica un'interruzione nell'anello di uno stack (ossia quando due cavi sono disconnessi dallo stack) in modo che sia il dispositivo attivo che quello in standby perdano la comunicazione con gli altri membri. L'aggiunta di uno switch già acceso a uno stack corrente può causare un'unione dello stack, in quanto nello stack possono essere presenti due switch attivi.

Cisco ID bug CSCuh58098 - È possibile ricaricare lo stack 3850 in caso di problemi di cablaggio

Cisco bug ID CSCui56058 - Abilita la logica di debug per il cavo dello stack

Cisco ID bug CSCup5338 - 3850 IOSD crash | Signal=SIGSEGV(1) @ pm_port_data_from_swidb

hap_sup_reset: Codice motivo: [4] Ripristino Motivo: reimpostazione/ricaricamento richiesto da [stack-manager]. [unione dello stack a causa di incompatibilità]

Questa condizione è stata rilevata in situazioni in cui nello stack esiste uno switch attivo e uno switch in standby. Se lo switch attivo perde la comunicazione con lo switch in standby, lo switch in standby può tentare di assumere il controllo come switch attivo anche se lo switch attivo è ancora attivo.

ID bug Cisco CSCuo4955

ID bug Cisco CSCup58016 - 3850/3650 in caso di arresto anomalo del sistema a causa di un'inondazione unicast sulla porta di gestione

ID bug Cisco CSCur07909 - Unione dello stack a causa di una connettività attiva e in standby persa

Reimpostazione Motivo:reimpostazione/ricaricamento richiesto da [stack-manager]. [Rilevato vicino errato dopo la votazione ASIC]

Gli switch partecipano alla votazione ASIC durante l'avvio per determinare gli switch adiacenti all'interno dello stack. Questo reset può essere rilevato quando un timer scade per consentire a un router adiacente di dichiararsi o se si verifica un errore logico durante la conversazione nbrcast. Questa condizione è stata rilevata nel contesto di cavi dello stack difettosi che sono stati risolti con la sostituzione.

ID bug Cisco CSCun60777 - Switch ricaricato a causa di un vicino errato rilevato dopo la votazione ASIC

ID bug Cisco CSCud93761 - Switch ricaricato a causa di un vicino errato riscontrato dopo la votazione ASIC

Cisco bug ID CSCun17506 - Amur:ng3k:same neighbors viene visualizzato su entrambe le porte dello stack su uno stack di 3 membri

hap_sup_reset: Codice motivo: [4] Ripristino. Motivo: il ripristino o il ricaricamento è stato richiesto da [stack-manager]. [ha perso sia lo stato attivo che quello in standby]

Ciò si verifica in genere quando il membro dello stack non ha un ruolo attivo o in standby. Se il dispositivo attivo non funziona, e non è presente uno switch in standby che deve assumere il ruolo attivo per lo stack, l'intero stack può essere ripristinato. Se lo stack è instabile o i criteri di ridondanza non sono ancora stati sincronizzati, è possibile verificare questa condizione. Ciò è probabilmente dovuto al motivo per cui gli switch attivo/standby sono stati disattivati o a un'indicazione che la ridondanza non è sincronizzata correttamente. Questa condizione può essere rilevata anche quando gli stack sono configurati in una configurazione half-ring.

Cisco bug ID CSCup53882 - Switch membri in un riavvio dello stack 3850 - [perdita di switch attivi e in standby]

hap_sup_reset: Codice motivo: [1] Ripristino. Motivo: il ripristino o il ricaricamento è stato richiesto da [stack-manager]. [Keepalive_Timeout]

Visualizzati quando i messaggi keep-alive non vengono ricevuti dallo switch nello stack. Osservate Trace Buffer: redundancy-timer-ha_mgr e mostra lo scambio di messaggi keep-alive e fornisce una prospettiva di tempo per l'inizio del guasto nella comunicazione. Se si raccolgono i report degli switch dal resto dello stack e si esaminano i log nel corso dell'intervallo di tempo, è possibile risolvere il problema.

hap_sup_reset: Reset. Motivo:Reset/Reload richiesto da [stack-manager]. [Comando Ricarica]

Questo è un motivo per il reset abbastanza intuitivo - ciò si verifica quando lo stack-manager riceve una richiesta di ricaricamento che può essere richiamata tramite CLI o esternamente tramite il dispositivo di gestione (SNMP). Nei casi in cui viene usato l'ID bug Cisco CSCuj17317, questo comando viene visualizzato anche come comando reload. Dal file di log: Cisco IOS è possibile visualizzare:

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

Bug correlati

Cisco ID bug CSCur76872 - Lo Stack Manager non funziona quando il sistema esaurisce il buffer SDP.

Cisco ID bug CSCup49704 - 3850 FED Crash - In attesa dei canali SPI FED_SPI_FLCD,FED_SPI_FAST ...

Diagnosi di un potenziale problema della porta o del cavo dello stack

Sintomo 1) Qualunque segno di un problema sul cavo dello stack è evidente da uno sfarfallio sulla porta dello stack prima del reset. Esaminare il file di log: in genere il report di Cisco IOS precedente a un reset è un buon punto di partenza. Di seguito è riportato un esempio di dove è possibile vedere lo sfarfallio della porta dello stack registrata sia sull'SW2 corrente sia sull'SW1 in standby. La stessa porta dello stack lampeggiava in ciascuna istanza del reset ed è stata risolta nel momento in cui il cavo dello stack è stato sostituito:

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

Sintomo 2) In base alla configurazione stackwise utilizzata (180, 480, più), il numero di anelli di trasmissione per porta ASIC varia. Questi comandi eseguono il polling dei registri globali che mantengono un totale incrementato del numero di errori di lettura rilevati per ogni anello di trasmissione. Il valore Port-asic 0 corrisponde alla porta dello stack 1 e il valore Port-asic 1 corrisponde alla porta dello stack 2. Questo comando deve essere emesso per ciascuno switch e qualsiasi segno di conteggio che comporti un incremento può isolare la presenza di un problema sulla porta o sul cavo dello stack.

Questi possono essere raccolti più volte in pochi minuti per confrontare i delta nel conteggio:

show platform port-asic <0-1> lettura del registro switch SifRacDataCrcErrorCnt <switch#>

• Segmento con errore CRC dei dati.

show platform port-asic <0-1> lettura del registro switch SifRacRwCrcErrorCnt <switch#>

• Incrementato a ogni controllo CRC non riuscito.

show platform port-asic <0-1> lettura del registro switch SifRacPcsCodeWordErrorCnt <switch#>

• Incrementato su codice PCS non valido, parola in codice PCS sconosciuto, che esegue un errore di disparità rilevato.

show platform port-asic <0-1> lettura del registro SifRacInvalidRingWordCnt switch <switch#>

• Errore CRC della parola chiave causato da un errore di bit nello stack.

Per Polaris (codice 16.X) questi sono i comandi:

show platform hardware plat <#/active/standby> fwd-asic registro lettura nome registro SifRacDataCrcErrorCnt asic <0-1> 

show platform hardware plat <#/active/standby> fwd-asic registro lettura nome registro SifRacRwCrcErrorCnt asic<0-1>

show platform per hardware <#/active/standby> fwd-asic registro lettura nome registro SifRacPcsCodeWordErrorCnt asic <0-1>

show platform per hardware <#/active/standby> fwd-asic registro lettura nome registro SifRacInvalidRingWordCnt asic <0-1>

Nell'esempio viene mostrato dove si è verificato un evento di unione dello stack e dove sono stati rilevati entrambi i membri di uno stack di due membri senza alcun segno di una porta dello stack lampeggiante. L'incremento ring[0] con i CRC sulla porta dello stack 1 dello switch 1 è visibile e per risolvere il problema, sostituire il cavo dello stack.

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

Suggerimenti aggiuntivi

1. Archivio delle directory Crashinfo

Maggiore è il numero di switch nello stack, maggiore è il numero di file di report da raccogliere. Il numero di report generati può facilmente sovraccaricare. L'organizzazione è vitale per separare un fallimento. Trovare la coerenza con i timestamp del momento in cui ogni switch ha scritto il file di report per un determinato incidente, se possibile. Da qui, richiedere quei rapporti molto specifici da questi switch in modo che il client non carica diversi file. La directory crashinfo può anche essere archiviata in modo che l'utente Cisco possa inviare un singolo archivio contenente i report interessati. Nell'esempio seguente viene creato un archivio denominato crashinfo-archive.tar nella directory 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. Ripristino di uno stack instabile

In alcune situazioni, è possibile vedere diversi membri ricaricati durante l'avvio dopo la selezione dello stack. Se lo switch ricaricato si considera attivo, spesso si verifica un evento di unione dello stack e può entrare in uno stato del loop di avvio. In questa situazione, è consigliabile chiedere al client Cisco:

• Spegnere l'intero stack e ripristinare correttamente tutti i cavi dello stack.
• Accendere uno alla volta ciascuno switch membro dello stack finché tutti i membri non hanno raggiunto lo stato previsto.
• Se un membro non si unisce allo stack, rimuoverlo e provare ad avviare il dispositivo come dispositivo indipendente per risolvere ulteriormente il problema.

3. Generazione manuale dei rapporti di sistema

I report di sistema creati manualmente richiedono l'attivazione del servizio interno. In questo modo viene scritto un report di sistema come file di testo che può essere eseguito per switch.

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>

Informazioni correlate

• Supporto tecnico Cisco e download