Dépannage des rechargements 3650/3850 par gestionnaire de pile via un rapport système
Contenu
Introduction
Le dépannage des rechargements de pile par le biais d'un rapport système en l'absence de panne est généralement effectué sur les plates-formes de commutation NGWC à l'aide de la technologie empilable. La documentation actuelle est limitée à l'utilisation d'un rapport système et ce guide est en cours de rédaction pour expliquer comment vous pouvez utiliser ces rapports pour diagnostiquer les problèmes généralement détectés avec des problèmes d'empilage. Ce guide est particulièrement adapté aux architectures de commutation Catalyst 3650/3850 exécutant IOS-XE qui prennent en charge les fonctionnalités d'empilage.
La plupart des problèmes liés à la technologie empilable proviennent d'un problème de communication entre les membres d'une pile. Toute incohérence des informations entre les membres ou toute perte de connectivité peut entraîner un problème qui se répercute sur l'ensemble de la pile, et aboutir finalement à une réinitialisation avec le gestionnaire de pile. Ce document met en évidence certains des types courants de pannes observés avec les rechargements de gestionnaire de pile, les utilisations d'un rapport système et les CLI pertinentes disponibles pour diagnostiquer et différents types de problèmes.
Informations générales :
Rapports système/commutateur
Un rapport système est un rapport complet du membre sur la manière dont il perçoit l'état de la pile. Il ne s'agit pas d'une crashinfo (qui videra de la mémoire pour un débogage ultérieur), mais d'un rapport qui contient des journaux et des informations de débogage pour différents services exécutés sous 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'un plantage de processus s'est produit ou généré manuellement par l'utilisateur pendant le fonctionnement en direct.
Dans de nombreux cas, un seul commutateur peut échouer dans une pile, mais les autres membres peuvent rester intacts. Pour collecter des informations sur l'état de la pile à un moment donné, les rapports switch_report ont été introduits afin que les membres restants en génèrent un lorsqu'ils détectent qu'un membre est tombé en panne. Le rapport switch_report sera un rapport local indiquant comment ce membre perçoit l'état actuel de la pile.
Où collecter les rapports système/commutateur
Les rapports système sont généralement écrits dans crashinfo : du membre de cette pile. Par exemple, s'il y a une pile de commutateurs membres x, chaque commutateur aura son propre répertoire crashinfo accessible à l'aide de “ dir crashinfo-x ” où 'x' correspond à ce membre de la pile.
3850#dir crashinfo-1 :
Répertoire crashinfo:/
11-rwx 35 août 14 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 août 14 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
Sections intéressantes 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 vues dans le rapport système qui peuvent aider à diagnostiquer les événements d'un problème spécifique. Il y a d'autres journaux d'autres services contenus ici que le développement pourrait trouver désireux de revoir.
fichier journal :/mnt/pss/sup_sysmgr_reset.log
Il s'agit d'un résultat court pour comprendre de manière très générale pourquoi une réinitialisation a été vue. Reportez-vous à la section Types d'échecs ci-dessous pour connaître le sens et le contexte de ces raisons.
fichier journal :IOS
Il s'agit de la mémoire tampon du journal gérée à partir d'IOSd. Toutes les commandes qui ont été émises par l'utilisateur ou les syslogs générés dans IOSd se trouvent dans cette section. Les journaux les plus récents sont vers la fin de cette sortie.
Tampon de suivi : stack-mgr-events
Effectue le suivi des événements vus à partir du gestionnaire de pile, qui inclura lorsque d'autres membres se connectent ou se retirent de la pile ou le port de pile par lequel les messages entrent.
Tampon de suivi : redundancy-timer-ha_mgr
Affiche les événements de maintien en vie 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 met en surbrillance 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 supervisera 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 envoie un signal de rechargement à chaque commutateur afin que la pile se réinitialise. Vous trouverez ci-dessous la liste des bogues connus qui ont été associés au type d'échec respectif.
Remarque: Tous les rechargements de gestionnaire de pile ne sont pas attribués à un problème logiciel. En fait, il est plus courant de voir ces problèmes se manifester comme un problème secondaire/victime d'un problème matériel sous-jacent.
Raison de la réinitialisation : Réinitialiser/Recharger demandé par [gestionnaire de pile]. [Incompatibilité ISSU]
Ce type de réinitialisation peut s'afficher en cas d'échec de synchronisation en bloc lors de la tentative de synchronisation de la configuration active entre tous les membres de la pile. Vérification du fichier journal : IOS ou les journaux du commutateur actif peuvent mettre en surbrillance les configurations qui ont contribué à cette réinitialisation.
Raison de réinitialisation : Service [iosd] pid : [xyz] s'est arrêté de manière anormale [11].
Cela s’est produit lorsque le commutateur tombe en panne dans le processus IOSd. Si vous regardez les répertoires crashinfo pour n'importe quel fichier crashinfo + core dumps, vous pouvez utiliser pour déboguer cette panne plus loin.
hap_sup_reset : Raison de la réinitialisation : Réinitialiser/Recharger demandé par [gestionnaire de pile]. [fusion de pile]
Une fusion de pile est visible lorsqu'il y a deux commutateurs ou plus qui croient qu'ils sont le commutateur actif de la pile. Ceci peut être observé en cas de coupure dans l'anneau d'une pile (c'est-à-dire que deux câbles sont déconnectés de la pile), de sorte que l'actif et l'en veille perdent la communication avec les autres membres. L'ajout d'un commutateur déjà alimenté à une pile existante peut provoquer une fusion de pile car il y aura deux commutateurs actifs dans la pile.
CSCuh58098 
- La pile 3850 peut se recharger en cas de problème de câblage de pile
CSCui56058 - Activation de la logique de débit pour le câble de pile
CSCup53338 - crash IOSD 3850 | Signal=SIGSEGV(11) @ pm_port_data_from_swidb
hap_sup_reset : Code raison : [4] Raison de réinitialisation : Réinitialiser/Recharger demandé 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 tente de prendre le relais en tant que commutateur actif même si le commutateur actif est toujours actif.
CSCuo49555 /CSCup58016 - 3850/3650 se plante en raison d'une inondation de monodiffusion sur le port de gestion
CSCur07909 - Fusion de la pile en raison d'une perte de connectivité active et de secours
Raison de la réinitialisation : Réinitialiser/Recharger demandé par [gestionnaire de pile]. [Mauvais voisin rencontré après le vote de l'ASIC]
Les commutateurs participent à un bulletin de vote ASIC lors du démarrage pour déterminer les commutateurs voisins dans la pile. Cette réinitialisation peut être vue lorsqu'un compteur 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é observé dans le contexte de câbles de pile défectueux qui ont été résolus par remplacement.
CSCun60777 - Commutateur rechargé en raison d'un voisin incorrect rencontré après le vote ASIC
CSCud93761 - Commutateur rechargé en raison d'un voisin incorrect rencontré après le vote ASIC
hap_sup_reset : Code raison : [4] Raison de réinitialisation : Réinitialiser/Recharger demandé par [gestionnaire de pile]. [perdu actif et en 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 l'active échoue, s'il n'y a pas de commutateur de secours pour assumer le rôle actif de la pile, la pile entière se réinitialise. Si la pile est instable ou si la stratégie de redondance n'a pas encore été synchronisée, cela peut être vu. Il est probable que cela soit une victime de la raison pour laquelle les commutateurs actifs/de secours sont tombés en panne ou d'une indication que la redondance ne se synchronise pas correctement. Cela peut également être vu lorsque des piles sont configurées dans une configuration en demi-anneau.
CSCup53882 - Commutateurs membres dans un redémarrage de pile 3850 - [perdu actif et en veille]
hap_sup_reset : Code raison : [1] Raison de réinitialisation : Réinitialiser/Recharger demandé par [gestionnaire de pile]. [Délai d'attente_de maintien]
Visualisé lorsque les messages de maintien en vie ne sont pas reçus du commutateur de la pile. Affichage de “ mémoire tampon de suivi : le ” redundancy-timer-ha_mgr doit montrer l'échange de messages de maintien en vie et fournir une perspective du moment où la panne de communication a commencé. La collecte de rapports de commutateur à partir du reste de la pile et la consultation des journaux pendant la période peuvent vous aider ici.
hap_sup_reset : Raison de la réinitialisation : Réinitialiser/Recharger demandé par [gestionnaire de pile]. [Commande Recharger]
C'est une raison assez intuitive de réinitialisation : elle est visible lorsque le gestionnaire de pile reçoit une demande de rechargement qui peut être appelée via l'interface de ligne de commande ou via un périphérique de gestion (SNMP). Dans les cas de CSCuj17317 , ceci apparaîtra également comme une « commande reload » émise. À partir du fichier journal : IOS :
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
Bogue pertinent
CSCur76872 - Le gestionnaire de pile tombe en panne lorsque le système est à court de mémoire tampon SDP.
CSCup49704 - 3850 FED Crash - En attente des canaux SPI FED_SPI_FLCD, FED_SPI_FAST ...
Diagnostic d'un problème potentiel de câblage de pile/port
Symptôme 1) Tous les signes d’un problème de câblage de pile sont visibles par tout battement du port de pile avant la réinitialisation. Affichage du fichier journal “ : Le rapport IOS ” avant une réinitialisation est généralement un bon point de départ. Voici un exemple de l'emplacement du battement du port de pile qui est enregistré sur le SW2 actuel et le SW1 de secours. Ce même port de pile battait chacun dans chaque instance de la réinitialisation 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
Symptôme 2) Selon la configuration empilée utilisée (180, 480, plus), le nombre de faisceaux de transmission par ASIC de port varie. Ces commandes interrogent les registres globaux qui conservent un total d'exécution 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. Ceci doit être émis pour chaque commutateur et tout signe d'incrémentation peut isoler s'il y a 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 SifRacDataCrcErrorCnt switch <switch#>
- Segment avec erreur CRC de données
show platform port-asic <0-1> read register SifRacCrcErrorCnt switch <switch#>
- Incrémenté sur toute vérification CRC ayant échoué
show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>
- Incrémenté sur un code PCS non valide, mot de passe PCS inconnu, erreur de disparité en cours d'exécution détectée
show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>
- Une erreur de bit sur la pile a provoqué une erreur CRC du mot de passe
Pour Polaris (code 16.X), les commandes sont les suivantes :
show plat hardware fed sw <#/active/standby> fwd-asic register read-name SifRacDataCrcErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacCrcErrorCnt asic<0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt base <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt base <0-1>
Voici un exemple où un événement de fusion de pile a vu les deux membres d'une pile de 2 membres sans aucun signe de port de pile battement. La sonnerie [0] s'incrémente avec les CRC sur le port de pile 1 du commutateur 1 et finit par remplacer le câble de pile pour contourner ce problème.
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 examiné, le masque peut être différent dans chaque cas. Dans l’exemple ci-dessus, le masque s’enroule sur les 14 derniers bits. Ainsi, lorsque le compteur atteint 0x00003FFF, il revient à 0x00000000.
Conseils supplémentaires
1. Archivage des répertoires Crashinfo
Plus la pile contient de commutateurs, plus il y aura de fichiers de rapport à collecter. Il est facile d'être dépassé par le nombre de rapports générés. L'organisation est vitale pour isoler un échec. Recherchez une cohérence à l’aide d’horodatages indiquant le moment où chaque commutateur a écrit un fichier de rapport pour un incident donné, si possible. À partir de là, demandez ces rapports très spécifiques à partir des commutateurs donnés afin que le client ne télécharge pas plusieurs fichiers. Le répertoire crashinfo peut également être archivé afin que le client puisse envoyer une archive unique contenant les rapports intéressés. Les éléments suivants créent 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ération d'une pile instable
Il peut y avoir des situations où plusieurs membres d'une pile redémarrent lors du démarrage après le processus de sélection de la pile. Si un commutateur rechargé se croit actif, cela peut souvent conduire à un événement de fusion de pile et entrer dans un état de boucle de démarrage. Dans ce cas, il peut être conseillé de demander au client :
- Mettez la pile hors tension et repositionnez 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 l'état prévu.
- Dans les cas où un membre ne parvient pas à joindre la pile, supprimez-la de la pile et essayez de démarrer cette personne en tant que personne autonome pour résoudre les problèmes.
3. Générer des rapports système manuellement
La création manuelle de rapports système nécessite l'activation du service interne. Cela permet d'écrire un rapport système sous forme de fichier texte pouvant être effectué 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>
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)