En dépannant 3650/3850 de recharges par le gestionnaire de pile par un système signalez

 

Introduction

Le dépannage des recharges de pile par un état de système faute de crash est généralement fait sur des Plateformes de commutation NGWC utilisant la technologie de stackwise. La documentation en cours est limitée sur les utilisations d'un état de système et ce guide est écrit pour expliquer comment vous pouvez accroître ces états pour diagnostiquer des problèmes typiquement trouvés avec empiler des questions. Ce guide est en particulier adapté pour les architectures de commutation du Catalyst 3650/3850 exécutant IOS-XE qui prend en charge empiler des capacités.

La majorité de questions avec la technologie de stackwise proviennent d'un problème de communication entre les membres dans une pile. N'importe quelle incohérence des informations entre les membres ou la perte de connectivité peut avoir comme conséquence un problème qui imprègne par la pile entière menant finalement à une remise avec le gestionnaire de pile. Ce document mettra en valeur certains des types communs de pannes vues avec des recharges de pile-gestionnaire, des utilisations d'un état de système, et CLIs approprié disponible de diagnostiquer et de différents types de problèmes.

L'information générale :

État de système contre des états de commutateur

Un système-état est un état complet du membre de la façon dont il perçoit l'état de la pile. Ce n'est pas un crashinfo (qui videra la mémoire pour davantage d'élimination des imperfections), mais à la place, est un état qui a des logs et des informations de débogage pour de divers services s'exécutant sous IOS-XE qui serait utile pour que le développement dépiste l'état de ce service. Un système-état peut être généré quand le commutateur est rechargé par le gestionnaire de pile, un crash de processus s'est produit, ou manuellement généré par l'utilisateur pendant l'exécution vivante.

 

Dans de nombreux cas, il y a des situations dans lesquelles un commutateur simple pourrait échouer dans une pile mais le reste des membres peut demeurer intact. Pour recueillir comme informations sur l'état de la pile au temps donné, des switch_reports ont été introduits de sorte que les membres restants génèrent un quand elle la détecte qu'un membre est descendu. Le switch_report sera un état local de la façon dont ce membre perçoit l'état actuel de la pile.

 

Remarque: Ces états sont rédigés et compressés ainsi ils ne peuvent pas être imprimés au terminal utilisant « plus ». Ils devront être transférés outre du commutateur et être décompressés pour visualiser le log.

 

Où recueillir des états de système/commutateur

Des états de système seront typiquement rédigés dans le crashinfo : répertoire du membre dans cette pile. Par exemple, s'il y a une pile de commutateurs de x-membre, puis chaque commutateur aura leur propre répertoire de crashinfo qui peut être accessible utilisant le « crashinfo-x de dir » où « x » correspond à ce membre dans la pile.

 

3850#dir crashinfo-1 :

Répertoire de crashinfo : //    

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

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 - last_systemreport_log du rwx 357 14 août 2015 07:50:49 -04:00  

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

 

Remarque: Soyez sûr de recueillir la sortie pour le « crashinfo-x de dir :  » pour chaque commutateur dans cette pile parce que « le tech d'exposition » ne répertoriera pas les systèmes de fichiers disponibles ou les fichiers crashinfo. Il est important que vous ayez l'image entière de chaque membre dans cette pile. Mise à jour : En date de plus nouvelles releases >3.6E IOS-XE, le tech d'exposition reflétera le '' crashinfo de dir : '+ la « sortie de show file systems. Voir le CSCun50428 .

 

Sections intéressantes dans l'état de système

D'un point de vue TAC, ce sont certaines des entrées généralement visualisées dans l'état de système qui peut aider à diagnostiquer des événements d'une problématique spécifique. Il y a d'autres logs d'autres services contenus dans ici que le développement peut le trouver veulent passer en revue.

 

fichier journal : /mnt/pss/sup_sysmgr_reset.log

C'est un résultat court à comprennent très génériquement pourquoi une remise a été vue. Voyez les types ci-dessous de section de pannes pour regarder la signification et le contexte dans la façon dont ces raisons varieront.

 

fichier journal : IOS

C'est la mémoire tampon de log mise à jour d'IOSd. Toutes les commandes qui ont été émises par l'utilisateur ou les Syslog générés dans IOSd seront trouvées dans cette section. Les logs les plus récents sont vers l'extrémité de cette sortie.

 

Mémoire tampon de suivi : pile-directeur-événements

Maintient des événements vus du gestionnaire de pile qui inclura quand d'autres membres sont se joindre/enlevé de la pile ou qui empilent le port les messages entrent.

               

Mémoire tampon de suivi : redundancy-timer-ha_mgr

Affiche des événements de keepalive entre les Commutateurs dans la pile. Les horodateurs peuvent aider à déterminer quand la panne dans la transmission a commencé.

 

Types de pannes

Cette section en mettra en valeur généralement - les remises vues d'un état de système qui sont typiquement appelées par le processus maître de pile. Le gestionnaire de pile est un processus de Linux qui gère les membres dans la pile et surveillera tous les changements des rôles entre les Commutateurs dans la pile. Si le gestionnaire de pile détecte un problème pendant l'élection d'initialisation ou de rôle, elle enverra un signal de recharge à différents Commutateurs pour que la pile remette à l'état initial. Au-dessous de la volonté répertoriez également les bogues connu qui ont été associées au type de panne respectif.

 

Remarque: Non toutes les recharges de pile-gestionnaire sont attribuées à un problème logiciel. En fait, il est plus commun pour voir ces problèmes manifestes comme question secondaire/victime à un problème matériel sous-jacent.

 

Raison de la réinitialisation : Remettez à l'état initial/recharge demandé par [pile-gestionnaire]. [Incompatibilité ISSU]

Vous pourriez voir ce type de remise quand il y a une panne en vrac de sync tout en essayant de synchroniser la configuration sur le maître entre tous les membres dans la pile. Vérifier le fichier journal : L'IOS ou les les logs du commutateur actif pourrait mettre en valeur les configurations qui ont contribué à cette remise.

Raison de la réinitialisation : Service [iosd] PID : [xyz] anormalement terminé [11].

Ceci vu quand le commutateur tombe en panne dans le processus d'IOSd. Regarder les répertoires de crashinfo pour tous les fichiers crashinfo + vidages de mémoire peut être utilisé pour mettre au point cette panne plus loin.

 

hap_sup_reset : Raison de la réinitialisation : Remettez à l'état initial/recharge demandé par [pile-gestionnaire]. [fusion de pile]

Une fusion de pile est vue quand il y a deux Commutateurs ou plus qui les croient sont le maître de pile. Ceci peut être vu quand il y a une rupture dans la sonnerie d'une pile (c.-à-d. deux câbles sont déconnectés de la pile) ainsi l'actif et le de réserve perd la transmission aux autres membres. L'ajout d'un interrupteur déjà à une pile existante peut entraîner une fusion de pile car il y aura deux Commutateurs actifs dans la pile.

 

CSCuh58098 - 3850 piles peuvent recharger quand les problèmes de câblage de pile sont présents

CSCui56058 - Activation de la logique de debounce pour le câble de pile

CSCup53338 - crash 3850 IOSD | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

 

hap_sup_reset : Raison de la réinitialisation de la raison Code:[4] : Remise/Reloadrequested par [pile-gestionnaire]. [fusion de pile due à l'incompatibilité]

Ceci a été vu dans les situations quand un commutateur actif et de réserve existe dans la pile. Si le commutateur actif perd la transmission au standby, le standby tentera de succéder comme active quoique l'active soit toujours.

 

CSCuo49555 /CSCup58016 - 3850/3650 de crash dus à l'inondation d'unicast sur le mgmt mettent en communication

CSCur07909 - Fusion de pile due à la Connectivité perdue active et de standby

 

 

Raison de la réinitialisation : Remettez à l'état initial/recharge demandé par [pile-gestionnaire]. [Voisin faux produit après vote ASIC]

Les Commutateurs participent à un vote ASIC pendant le démarrage déterminent jusqu'à ses Commutateurs voisins dans la pile. Cette remise peut être vue quand un temporisateur expire pour qu'un voisin se déclare ou s'il y a une erreur de logique pendant la conversation de nbrcast. Ceci a été vu dans le contexte des câbles défectueux de pile qui ont été résolus par le remplacement.

 

CSCun60777 - Commutez dû rechargé pour faire du tort le voisin produit après vote ASIC

CSCud93761 - Commutez dû rechargé pour faire du tort le voisin produit après vote ASIC

 

 

 

hap_sup_reset : Raison de la réinitialisation de la raison Code:[4] : Remettez à l'état initial/recharge demandé par [pile-gestionnaire]. [actif et de réserve perdus]

Ceci est typiquement vu d'un membre sur la pile qui n'est pas dans un rôle actif ou de réserve. Quand l'active échoue, s'il n'y a aucun commutateur de réserve pour assumer le rôle actif pour la pile, alors la pile entière remettra à l'état initial. Si la pile est un état instable ou stratégie de Redondance pas synced encore, ceci peut être vu. C'est probable une victime de le pourquoi Commutateurs actifs/de réserve sont allés vers le bas ou potentiellement une indication que la Redondance pas syncing correctement. Ceci peut également être vu dans quand des piles sont configurées dans une installation de moitié-sonnerie.

 

CSCup53882 - Commutateurs de membre dans une réinitialisation de 3850 piles - [actifs et de réserve perdus]

 

hap_sup_reset : Raison de la réinitialisation de la raison Code:[1] : Remettez à l'état initial/recharge demandé par [pile-gestionnaire]. [Keepalive_Timeout]

Vu quand des messages de keepalive ne sont pas reçus du commutateur dans la pile. Regarder la « mémoire tampon de suivi : le redundancy-timer-ha_mgr » devrait afficher l'échange des messages de keepalive et fournir un point de vue d'heure pour quand la panne dans la transmission a commencé. Recueillant le commutateur signale du reste de la pile et regarder des logs pendant la période peut aider ici.

 

 

hap_sup_reset : Raison de la réinitialisation : Remettez à l'état initial/recharge demandé par [pile-gestionnaire]. [Commande de recharge]

C'est une raison de la réinitialisation assez intuitive – ceci est vu quand le pile-gestionnaire reçoit une demande de recharge qui pourrait être appelée par le CLI ou extérieurement par l'intermédiaire du périphérique de Gestion (SNMP). En cas de CSCuj17317 , ceci apparaîtra également comme une « commande de recharge » a émis aussi bien. À partir du fichier journal : IOS que 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 appropriées

CSCur76872 - Le gestionnaire de pile va en bas de quand le système manque de mémoire tampon SDP.

CSCup49704 - 3850 ALIMENTÉS le crash - attendant le SPI creuse des rigoles FED_SPI_FLCD, FED_SPI_FAST…

 

 

 

Diagnostic d'un câblage/de problème de port potentiels de pile

Le symptôme 1) tous les signes d'un problème de câblage de pile sera évident par n'importe quel lien instable du port de pile avant la remise. Regarder le « fichier journal : État IOS le » avant une remise est typiquement un emplacement adapté à commencer. Voici un exemple d'où vous voyez le lien instable du port de pile qui est enregistré en le courant SW2 et l'état d'alerte SW1. Ce même port de pile agitait chacun dans chaque exemple de la remise et a été résolu en remplaçant le câble de pile :

 

=====================  log file: 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

 

Le symptôme 2) selon l'installation de stackwise est utilisé (180, 480, plus), le nombre de sonneries de transmission par port ASIC variera. Ces commandes voteront les registres globaux qui mettent à jour un total cumulé de combien des erreurs de lecture sont vues pour chaque sonnerie de transmission. « Port-ASIC 0" correspond pour empiler le port 1 et « port-ASIC 1" correspond pour empiler le port 2. Ceci devrait être émis pour chaque commutateur et tous les signes d'incrémenter des comptes peuvent isoler si là peut-être un problème au port ou avec le câble de pile.

 

 

 

 

Ceux-ci peuvent être collectés plusieurs fois au-dessus de quelques minutes de comparer les deltas dans le compte :

 

le show platform port-asic <0-1> a lu le <switch#> de commutateur de SifRacDataCrcErrorCnt de registre

• Segment avec l'erreur de CRC de données

le show platform port-asic <0-1> a lu le <switch#> de commutateur de SifRacRwCrcErrorCnt de registre

• Incrémenté sur tout contrôle défectueux de CRC

le show platform port-asic <0-1> a lu le <switch#> de commutateur de SifRacPcsCodeWordErrorCnt de registre

• Incrémenté sur le code non valide PCS, le mot de passe inconnu PCS, erreur courante de disparité est détecté

le show platform port-asic <0-1> a lu le <switch#> de commutateur de SifRacInvalidRingWordCnt de registre

• Erreur de bit sur l'erreur de CRC de ringword entraînée par pile

 

 

Ce qui suit est un exemple où vous avez eu un événement de fusion de pile non vu les deux membres d'une pile 2-member sans aucun signe d'un port instable de pile. Vous voyez ring[0] incrémenter avec des crc sur la pile port-1 du commutateur 1 et fini par remplaçant le câble de pile pour obtenir après cette question.

 

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

 

Remarque: Selon le registre qui est regardé, le masque peut-être différent dans chaque cas. Dans l'exemple ci-dessus, le masque s'enveloppera autour sur les 14 derniers bits. Ainsi, quand le compteur atteint 0x00003FFF, il s'enveloppera de nouveau à 0x00000000.

 

Conseils supplémentaires

1. Archivage des répertoires de Crashinfo

Plus de Commutateurs dans la pile signifient qu'il y aura plus de fichiers de rapport à collecter. Il est facile d'obtenir accablé par le nombre d'états qui sont générés. L'organisation est essentielle à isoler une panne. Trouvez une cohérence utilisant des horodateurs de quand chaque commutateur a écrit le fichier de rapport pour un incident donné si possible. De là, demandez ces états spécifiques mêmes de ces Commutateurs donnés ainsi le client ne télécharge pas plusieurs fichiers. Le répertoire de crashinfo peut également être archivé ainsi le client peut envoyer des archives simples contenant les états intéressés. Ce qui suit créera des archives nommées « 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 quelques situations où vous voyez plusieurs membres dans une pile rechargeant pendant l'amorce après que le processus d'élection de pile ait lieu. Si un commutateur rechargé se pense pour être le maître de pile puis ceci peut souvent mener à un événement de fusion de pile et entrera dans un état de boucle de démarrage. Dans cette situation, il peut être recommandé de demander au client :

- L'alimentation en bas de la pile entière et réinsèrent tous les câbles de pile fermement.

- Mettez sous tension chaque commutateur de membre dans la pile un jusqu'à ce que tous les membres aient convergé à son état prévu.

- Dans les cas où un membre ne joint pas la pile, ne retire pas ceci de la pile et n'essaye pas amorcer cette personne en tant qu'autonome pour dépanner plus loin.

 

3. Générez les états de système manuellement

Manuellement la création des états de système exige du « service interne » d'être activé. Ceci rédigera un état de système comme fichier texte qui peut être fait par base de 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>