Dépannage des rechargements de Stack Manager 3650/3850

Introduction

Ce document décrit comment utiliser les rapports système pour diagnostiquer les problèmes de pile.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Si vous dépannez des rechargements de pile par le biais d'un rapport système en l'absence d'une panne est généralement fait sur les plates-formes de commutation NGWC vous utilisez la technologie stackwise. La documentation actuelle est limitée aux utilisations d'un rapport système et ce guide explique comment vous pouvez utiliser ces rapports pour diagnostiquer les problèmes généralement rencontrés avec les problèmes d'empilage. Ce guide est particulièrement destiné aux architectures de commutateurs Catalyst 3650/3850 qui exécutent Cisco IOS® XE avec des fonctionnalités d'empilage.

La majorité des problèmes liés à la technologie stackwise proviennent d'un problème de communication entre les membres d'une pile. Toute incohérence d'informations entre les membres ou perte de connectivité peut entraîner un problème qui se répand dans toute la pile et entraîne finalement une réinitialisation avec le gestionnaire de pile. Ce document peut mettre en évidence certains des types courants de pannes observés avec les rechargements du gestionnaire de pile, les utilisations d'un rapport système et les CLI pertinentes disponibles pour diagnostiquer et différents types de problèmes.

Rapports système et rapports de commutateur

Un system-report est un rapport complet du membre sur la façon dont il perçoit l'état de la pile. Il ne s'agit pas d'une info de panne (qui peut vider de la mémoire pour un débogage ultérieur), mais plutôt d'un rapport qui a des journaux et des informations de débogage pour divers services qui s'exécutent sous Cisco IOS XE qui seraient utiles pour le développement pour suivre l'état de ce service. Un rapport système peut être généré lorsque le commutateur est rechargé par le gestionnaire de pile, qu'une panne de processus s'est produite ou qu'il est généré manuellement par l'utilisateur pendant le fonctionnement en direct.

Dans de nombreux cas, un seul commutateur peut tomber en panne dans une pile, mais les autres membres peuvent rester intacts. Pour collecter des informations sur l'état de la pile à un moment donné, switch_reports a été introduit afin que les membres actuels puissent en générer un lorsqu'il détecte qu'un membre est tombé en panne. Le switch_report peut être un rapport local sur la façon dont ce membre perçoit l'état actuel de la pile.

Remarque : ces rapports sont écrits et compressés, de sorte qu'ils ne peuvent pas être imprimés sur le terminal avec plus. Il peut être nécessaire de les transférer hors du commutateur et de les décompresser pour afficher le journal.

Où collecter les rapports système/commutateur

Les rapports système peuvent généralement être écrits dans le répertoire crashinfo: du membre de cette pile. Par exemple, s'il y a une pile de commutateurs membres de x, alors chaque commutateur peut avoir son propre répertoire crashinfo qui peut être accessible avec dir crashinfo-x où x correspond à ce membre dans la pile.

3850#dir crashinfo-1 :

Répertoire de crashinfo:/    

11 -rwx 355 14 août 2015 07:48:17 -04:00 last_systemreport_log  

12 -rwx 724015 15 octobre 2014 07:14:32 -04:00 system-report_1_20141015-111342-UTC.gz

3850#dir crashinfo-2 :

Répertoire de crashinfo-2:/   

11 -rwx 357 14 août 2015 07:50:49 -04:00 last_systemreport_log  

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

Remarque : veillez à collecter les informations de dir crashinfo-x pour chaque commutateur de cette pile, car la commande show tech ne peut pas répertorier les systèmes de fichiers disponibles ou les fichiers crashinfo. Il est important que vous ayez une image complète de chaque membre de cette pile. Mise à jour : à partir des nouvelles versions de Cisco IOS XE >3.6E, la commande show tech peut refléter le résultat dir crashinfo: + show file systems. Voir l'ID de bogue Cisco CSCun50428.

Sections importantes du rapport système

Du point de vue du centre d'assistance technique, il s'agit de certaines des entrées les plus fréquemment consultées dans le rapport système qui peuvent aider à diagnostiquer les événements d'un problème spécifique. Il existe d'autres journaux d'autres services contenus dans ce que le développement peut juger utile de consulter.

fichier journal : /mnt/pss/sup_sysmgr_reset.log

Il s'agit d'une sortie courte pour comprendre de manière très générique pourquoi une réinitialisation a été vue. Reportez-vous à la section suivante sur les types d'échecs pour voir la signification et le contexte de ces raisons.

fichier journal : Cisco IOS

Il s’agit du tampon de journalisation géré depuis Cisco IOSd. Toutes les commandes émises par l'utilisateur ou les syslogs générés dans Cisco IOSd sont disponibles dans cette section. Les journaux les plus récents sont vers la fin de ce résultat.

Mémoire tampon de suivi : stack-mgr-events

Assure le suivi des événements observés à partir du gestionnaire de pile, notamment lorsque d'autres membres rejoignent ou sont supprimés de la pile, ou du port de pile par lequel les messages arrivent.

               

Tampon de suivi : redundancy-timer-ha_mgr

Affiche les événements de maintien de la connexion entre les commutateurs de la pile. Les horodatages peuvent aider à déterminer quand la panne de communication a commencé.

Types de défaillances

Cette section peut mettre en évidence certaines réinitialisations courantes d'un rapport système qui sont généralement appelées par le processus du gestionnaire de pile. Le gestionnaire de pile est un processus Linux qui gère les membres de la pile et peut superviser toute modification des rôles entre les commutateurs de la pile. Si le gestionnaire de pile détecte un problème lors de l'initialisation ou de la sélection du rôle, il peut envoyer un signal de rechargement aux commutateurs individuels afin que la pile se réinitialise. La liste suivante peut également répertorier les bogues connus qui ont été associés au type de défaillance respectif.

Raison de la réinitialisation : réinitialisation/rechargement demandé par [gestionnaire de pile]. [Incompatibilité ISSU]

Vous pouvez voir ce type de réinitialisation en cas d'échec de synchronisation en bloc lorsque vous essayez de synchroniser la configuration sur l'actif entre tous les membres de la pile. Vérifiez le fichier journal : Cisco IOS ou les journaux du commutateur actif peuvent mettre en surbrillance les configurations qui ont contribué à cette réinitialisation.

Raison de la réinitialisation : le service [iosd] pid:[xyz] s'est terminé anormalement [11].

Ceci se produit lorsque le commutateur tombe en panne dans le processus Cisco IOSd. Consultez les répertoires crashinfo pour savoir si les fichiers crashinfo + core dumps peuvent être utilisés pour déboguer davantage cette panne.

hap_sup_reset : Raison de la réinitialisation : Réinitialisation/Rechargement demandée par [gestionnaire de pile]. [fusion de pile]

Une fusion de pile apparaît lorsqu'au moins deux commutateurs pensent qu'ils sont le commutateur actif de la pile. Ceci peut être vu lorsqu'il y a une rupture dans l'anneau d'une pile (c'est-à-dire que deux câbles sont déconnectés de la pile) de sorte que les deux éléments actif et de secours perdent la communication avec les autres éléments. L'ajout d'un commutateur déjà alimenté à une pile actuelle peut entraîner une fusion de pile, car il peut y avoir deux commutateurs actifs dans la pile.

ID de bogue Cisco CSCuh58098 - La pile 3850 peut être rechargée en cas de problèmes de câblage de la pile

ID de bogue Cisco CSCui56058 - Active la logique de renvoi pour le câble de pile

ID de bogue Cisco CSCup5338 - 3850 IOSD crash | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

hap_sup_reset : Code de raison : [4] Réinitialiser Motif : Réinitialisation/Rechargement demandée par [gestionnaire de pile]. [fusion de pile en raison d'une incompatibilité]

Cela a été observé dans des situations où un commutateur actif et de secours existe dans la pile. Si le commutateur actif perd la communication avec le commutateur en veille, le commutateur en veille peut tenter de prendre le relais en tant que commutateur actif même si le commutateur actif est toujours actif.

ID de bogue Cisco CSCuo49555

ID de bogue Cisco CSCup58016 - 3850/3650 se bloque en raison d'une inondation de monodiffusion sur le port de gestion

ID de bogue Cisco CSCur07909 - Fusion de pile en raison d'une perte de connectivité active et en veille

Raison de la réinitialisation : réinitialisation/rechargement demandé par [gestionnaire de pile]. [Voisin incorrect rencontré après le vote de l'ASIC]

Les commutateurs participent à un vote ASIC pendant le démarrage afin de déterminer leurs commutateurs voisins dans la pile. Cette réinitialisation peut être observée lorsqu'un minuteur expire pour qu'un voisin se déclare lui-même ou s'il y a une erreur logique pendant la conversation nbrcast. Cela a été vu dans le contexte de câbles de pile défectueux qui ont été résolus par le remplacement.

ID de bogue Cisco CSCun6077 - Commutateur rechargé en raison d'un voisin incorrect rencontré après le vote ASIC

ID de bogue Cisco CSCud93761 - Commutateur rechargé en raison d'un voisin incorrect rencontré après le vote ASIC

ID de bogue Cisco CSCun17506 - Amur:ng3k:same neighbor is seen on both stack ports on a 3 member stack

hap_sup_reset : Code de raison : [4] Rétablir Motif : Réinitialisation/Rechargement demandé par [gestionnaire de pile]. [perte des modes actif et veille]

Ceci est généralement observé à partir d'un membre de la pile qui n'est pas dans un rôle actif ou en veille. Lorsque la pile active échoue, s'il n'y a pas de commutateur de secours pour assumer le rôle actif pour la pile, alors la pile entière peut se réinitialiser. Si l'état de la pile est instable ou si la politique de redondance n'a pas encore été synchronisée, cela est visible. Il s'agit probablement d'une victime de la panne des commutateurs actif/veille ou d'une indication potentielle que la redondance ne se synchronise pas correctement. Ceci peut également être vu dans lorsque des piles sont configurées dans une configuration en demi-anneau.

ID de bogue Cisco CSCup5382- Commutateurs membres dans un redémarrage de pile 3850 - [perte active et en veille]

hap_sup_reset : Code de raison : [1] Réinitialiser Motif : Réinitialisation/Rechargement demandé par [gestionnaire de pile]. [Keepalive_Timeout]

Affiché lorsque les messages de maintien de la connexion ne sont pas reçus du commutateur de la pile. Examinez Trace Buffer : redundancy-timer-ha_mgr et cela montre l'échange de messages keep alive et fournissez une perspective de temps pour quand la panne dans la communication a commencé. Si vous collectez des rapports de commutateur à partir du reste de la pile et que vous examinez les journaux tout au long de la période, cela peut vous aider.

hap_sup_reset : Raison de la réinitialisation : Réinitialisation/Rechargement demandée par [gestionnaire de pile]. [Commande Recharger]

Il s'agit d'une raison de réinitialisation assez intuitive : cela se produit lorsque le gestionnaire de pile reçoit une requête de rechargement qui peut être invoquée via l'interface de ligne de commande ou en externe via le périphérique de gestion (SNMP). Dans les cas de l'ID de bogue Cisco CSCuj17317, ceci apparaît également comme une commande de rechargement émise également. Dans le fichier journal : Cisco IOS, vous pouvez voir :

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

Bogues associés

ID de bogue Cisco CSCur76872 - Le gestionnaire de pile tombe en panne lorsque le système manque de mémoire tampon SDP.

ID de bogue Cisco CSCup49704 - 3850 FED Crash - Attente des canaux SPI FED_SPI_FLCD, FED_SPI_FAST ...

Diagnostic d'un problème potentiel de câble ou de port de pile

Symptôme 1) Tout signe de problème lié à un câble de pile est visible par un battement du port de pile avant la réinitialisation. Consultez le fichier journal : le rapport Cisco IOS avant une réinitialisation est généralement un bon point de départ. Voici un exemple où vous voyez le battement du port de pile qui est enregistré à la fois sur le SW2 actuel et le SW1 de secours. Ce même port de pile battait à chaque fois dans chaque instance de la réinitialisation et a été résolu par lors du remplacement du câble de pile :

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

Symptôme 2) En fonction de la configuration en pile utilisée (180, 480 et plus), le nombre d’anneaux de transmission par ASIC de port varie. Ces commandes interrogent les registres globaux qui conservent un total qui augmente en fonction du nombre d'erreurs de lecture observées pour chaque anneau de transmission. Port-asic 0 correspond au port de pile 1 et port-asic 1 correspond au port de pile 2. Cette valeur doit être émise pour chaque commutateur et tout signe de comptage qui augmente peut isoler l'existence d'un problème au niveau du port ou du câble de pile.

Ceux-ci peuvent être collectés plusieurs fois sur quelques minutes pour comparer les deltas dans le décompte :

show platform port-asic <0-1> read register Commutateur SifRacDataCrcErrorCnt <switch#>

• Segment avec erreur CRC de données.

show platform port-asic <0-1> read register Commutateur SifRacRwCrcErrorCnt <switch#>

• Incrémenté sur tout échec de contrôle CRC.

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

• Incrémenté sur un code PCS non valide, un mot de code PCS inconnu, qui exécute une erreur de disparité détectée.

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

• Une erreur de bit sur la pile a causé une erreur CRC de mot de sonnerie.

Pour Polaris (code 16.X), voici les commandes :

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1> 

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacRwCrcErrorCnt asic<0-1>

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt asic <0-1>

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt asic <0-1>

Cet exemple montre où un événement de fusion de pile a vu les deux membres d'une pile de 2 membres sans aucun signe d'un port de pile instable. L'incrément de la sonnerie [0] avec les CRC s'affiche sur le port 1 de la pile du commutateur 1. Pour résoudre ce problème, remplacez le câble de la pile.

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

Conseils supplémentaires

1. Archiver les répertoires Crashinfo

Plus il y a de commutateurs dans la pile, plus il peut y avoir de fichiers de rapport à collecter. Il est facile de se laisser submerger par le nombre de rapports générés. L'organisation est vitale pour isoler un échec. Trouvez une cohérence avec les horodatages de la date à laquelle chaque commutateur a écrit un fichier de rapport pour un incident donné, si possible. À partir de là, demandez ces rapports très spécifiques à ces commutateurs donnés afin que le client ne télécharge pas plusieurs fichiers. Le répertoire crashinfo peut également être archivé afin que l'utilisateur Cisco puisse envoyer une seule archive contenant les rapports intéressés. L'exemple suivant peut créer une archive nommée crashinfo-archive.tar dans le répertoire 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. Récupérer une pile instable

Il peut y avoir des situations où vous voyez plusieurs membres dans une pile recharger pendant le démarrage après le processus de sélection de la pile. Si un commutateur rechargé croit être actif, cela peut souvent conduire à un événement de fusion de pile et peut entrer dans un état de boucle de démarrage. Dans ce cas, il peut être conseillé de demander au client Cisco :

• Mettez la pile entière hors tension et réinitialisez fermement tous les câbles de la pile.
• Mettez sous tension chaque commutateur membre de la pile un par un jusqu'à ce que tous les membres aient convergé vers leur état attendu.
• Si un membre ne parvient pas à rejoindre la pile, supprimez-le de la pile et essayez de démarrer cette personne en tant que personne autonome pour poursuivre le dépannage.

3. Générer des états système manuellement

Un rapport système créé manuellement nécessite l'activation du service interne. Un rapport système est alors écrit sous forme de fichier texte, ce qui peut être fait par commutateur.

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>

Informations connexes

• Assistance technique de Cisco et téléchargements