Commutateurs : Commutateurs Cisco Catalyst, s�rie 4500

Présentation et dépannage des délais Astro/Lemans/NiceR sur les commutateurs des gammes Catalyst 4000/4500

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (7 octobre 2015) | Commentaires


Contenu


Introduction

La gamme de commutateur du Catalyst 4000/4500 utilise une conception de la stub ASIC en architecture de commutateur. Le commutateur gère ces la stub ASIC (Astro/Leman/NiceR) de linecard par le protocole de contrôle de gestion interne. Quand ces demandes de gestion et réponses internes sont perdues ou retardées, la console et les messages de Syslog sont générés. Puisque les raisons pour ces pertes de communication varient, la cause principale n'est pas évidente avec ces messages d'erreur.

L'intention de ce document est d'aider à comprendre le message de délai d'attente Astro/Leman/Nicer généré sur la plate-forme Cat4000 et aux résoudre avec l'aide de Cisco TAC. Les versions futures ½ de CatOS et de Cisco IOSï de ¿  offriront les messages d'erreur améliorés, et si possible, identifient l'origine du problème.

Quand le délai d'attente de la stub ASIC (Astro/Mans/Nice) se produit, les messages semblables à suivre obtiennent signalé sur un commutateur du Catalyst basé 4000/4500 de CatOS :

%SYS-4-P2_WARN: 1/Astro(4/3) - timeout occurred
%SYS-4-P2_WARN: 1/Astro(4/3) - timeout is persisting

Veuillez noter que selon les versions de logiciel, les formulations du message d'erreur peuvent varier. Astro, Mans et Nice se rapportent au type différent de stub ASIC. Plus de détails est décrits dans la section de théorie générale de ce document.

Pour le Cisco IOS basé superviseurs (le superviseur II+, III et IV), le message d'erreur apparaît comme suit :

%C4K_LINECARDMGMTPROTOCOL-4-INITIALTIMEOUTWARNING: Astro 5-2(Fa5/9-16) - management 
request timed out. 
%C4K_LINECARDMGMTPROTOCOL-4-ONGOINGTIMEOUTWARNING: Astro 5-2(Fa5/9-16) - consecutive 
management requests timed out.

Remarque: Ce document adresse principalement le dépannage sur les superviseurs ou les Commutateurs basés sur CatOS. Certaines des informations s'appliquent au superviseur basé par Cisco IOS une fois remarquables.

Remarque: Ce document adresse également la stub ASIC d'Astro, mais la plupart des sections appliquez-vous à l'autre type de linecards de la stub ASIC (le Mans et Nice) et car tels seront notés dans les sections appropriées.

Après lecture de ce document, le lecteur comprendra ce qui suit :

  • La fonction de la stub ASIC dans le Catalyst 4000/4500.

  • Les conditions qui peuvent mener aux délais d'attente de paquets de gestion les messages internes.

  • Les étapes à prendre et commandes de recueillir pour le pour le dépannage de Cisco TAC cette condition.

Le délai d'attente et les sections dépannage d'Astro fournit le fond et l'explication détaillée au sujet de chaque question. Alternativement, on peut brancher directement aux moyens simples de dépanner la section de ce document.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Composants utilisés

Ce document est spécifique au superviseur ou aux linecards du Catalyst 4000/4500 utilisant la stub ASIC.

Théorie générale

La stub ASIC d'Astro se rapporte à la stub ASIC de 10/100 contrôle un 10/100 adjacent de ports de Groupe des Huit communiquant au superviseur par une connexion de bande passante de gigabit au fond de panier, suivant les indications de la figure ci-dessous.

http://www.cisco.com/c/dam/en/us/support/docs/switches/catalyst-4000-series-switches/45640-astroe5.gif

Les superviseurs communiquent à la stub ASIC de linecard par le composant SERDES (SERealizer-DESerializer). Il y a un composant SERDES sur se connecter latéral de superviseur à un fond de panier et à un SERDES différent sur le linecard pour chaque stub ASIC pour se connecter au fond de panier.

Le diagramme ci-dessus peut être utilisé en général pour dépanner le type différent de linecards. La stub ASIC référée dans les messages de délai d'attente serait différente selon le type de linecard. Voyez la table ci-dessous pour une liste de noms ASIC et de leur description.

Stub ASIC Description Exemple
Astro 8 stub ASIC de contrôleur du port 10/100 WS-X4148-RJ45V
Plus gentil 4 stub ASIC de contrôleur du port 1000 WS-X4418-GB(ports 3-18)
Le Mans 8 stub ASIC de contrôleur du port 10/100/1000 WS-X4448-GB-RJ

Le trafic d'administration interne traverse le les deux le composant SERDES avec le trafic de données normal. Le trafic d'administration interne est utilisé à la lecture/écriture la stub ASIC et des registres de Phy. Les exécutions les plus communes incluent l'état et les statistiques de lien de lecture.

Moyens simples de dépanner

Les sections suivantes expliquent la signification et les causes possibles du %SYS-4-P2_WARN : 1/(Stub)(module_number/) Stub_reference ? le délai d'attente s'est produit message d'erreur sur le Catalyst 4000/4500.

Les messages de délai d'attente d'Astro (stub) ont été ajoutés à la version de logiciel commençant dans 6.2.3 et 6.3.1 et amélioré postérieur dans 6.4.4 (CSCea73908) à indiquer que le superviseur a perdu des paquets de contrôle de gestion interne dans la communication à la stub ASIC d'Astro sur des linecards d'un 10/100. Il y a de plusieurs causes pour cette perte de communication comme expliqué en détail dans la section dépannage ci-dessous.

L'organigramme suivant de dépannage présente un rapide et une méthode facile pour isoler le problème entre les causes principales possibles :

http://www.cisco.com/c/dam/en/us/support/docs/switches/catalyst-4000-series-switches/45640-astroe8.gif

** Les diverses causes principales peuvent montrer les symptômes semblables. Veuillez entrer en contact avec le TAC pour davantage de dépannage.

Déracinez (Astro/Mans/Nice) les délais d'attente ASIC

Astro/Mans/Nice délais d'attente sont signalés quand le logiciel de superviseur ne reçoit pas de plusieurs réponses internes de Gestion de la stub ASIC de linecard. Ceci peut se produire si :

  • La demande de gestion est perdue ou retardée

  • La réponse de Gestion est perdue ou retardée

Un « délai d'attente s'est produit… » le message est imprimé une fois que le logiciel a chronométré 10 fois consécutives tout en attendant la réponse de paquet de gestion. Les délais d'attente conséquents ont Gestion consécutive comme conséquence impression « …. » ou « . .timeout persistant. » messages, selon la version du logiciel.

Ce message de log est débit-limité à une fois par 10 minutes. Le transfert de paquet à la stub affectée ASIC continue quand les délais d'attente se produisent. Cependant aucune modification au lien/à la vitesse/au duplex d'autoneg n'est vue car le logiciel ne reçoit pas les réponses de paquet de gestion. En outre, le processus de la mise à jour des statistiques de trafic pour le groupe de l'interface est affecté quand les délais d'attente se produisent.

Dépannage

Il y a de diverses causes pour que l'Astro/Mans/Nice les messages de délai d'attente apparaissent. Chacun est décrit ci-dessous.

Cause 1 : Le chargement du trafic élevé, posent la boucle 2, ou le trafic réseau excessif vers la CPU

Ce qui suit peut entraîner des états de délai d'attente de stub :

  • Problèmes de réseau

  • Problèmes de configuration

  • Éléments voisins

  • D'autres facteurs en dehors d'un commutateur de Catalyst

Posez la boucle 2 ou la saturation de diffusion que les résultats dans le chargement du trafic élevé peuvent perte de causes de paquets de contrôle de gestion interne. Ceci se produit habituellement en raison de la CPU pouvant occupée (porc CPU) et traiter ses files d'attente.

Le trafic de contrôle de gestion interne prend le même chemin de données au superviseur que le trafic de données normal de l'Astro (ou de tout autre puce de stub). Ainsi, les paquets de contrôle peuvent obtenir en raison perdu de l'encombrement.

Avec la difficulté pour l'ID de bogue Cisco CSCea73908 (clients enregistrés seulement), le délai d'inactivité interne de demande de gestion est manipulé mieux dans des versions de version 6.4(4) et ultérieures de CatOS. Cette amélioration peut empêcher beaucoup de délais d'attente passagers de paquets de contrôle provoqués par la CPU étant occupée.

Action : Dépannez la boucle de la couche 2 ; ou configuration de modification pour résoudre des structures de trafic.

Contournement : Déplacez l'interface de gestion de la commutation (sc0) au non-utilisateur que le trafic VLAN sur CatOS a basé des Commutateurs. Utilisez la commande de <vlan-id> du set interface sc0 de déplacer le VLAN de l'interface sc0.

Remarque: Commençant par le Cisco IOS 12.1(20)EW, les superviseurs basés par Cisco IOS introduit un amélioré dans la manipulation du mécanisme de manipulation interne de paquet de gestion par la CPU. Cette amélioration aidera à empêcher la perte de paquets de contrôle de gestion interne dus au trafic négligent de faible priorité accaparant la CPU.

Solution : Voir le contournement ci-dessus.

Cause 2 : Câblage de semi duplex/type 1A

Des ports d'utilisateur de panneau avant sont configurés dans bidirectionnel-alterné. Les collisions du trafic sortant avec le trafic entrant à la stub ASIC peuvent faire écouler la mémoire tampon de stub très lentement. Ceci peut faire remplir des tx-files d'attente sur le superviseur et on pourrait abandonner de nouvelles demandes de gestion internes qui auraient comme conséquence les messages d'erreur de dépassement de délai.

Un réseau avec le câblage Type1A peut également poser ce problème. Quand un poste de travail connecté aux transformateurs symétriques Type1A à un correctif de RJ-45 est déconnecté, le transformateur symétrique fait une boucle - arrière intérieurement et fait retourner le trafic sortant. Cette situation simule connecter un bouclage externe sur le port de panneau avant. Avant que le port se déplace à l'état de blocage, le trafic sortant est fait une boucle - arrière dans le commutateur. Ceci peut faire déborder les mémoires tampons de stub, selon le débit du trafic.

Action : Voir le contournement.

Contournement : Évitez la configuration semi-duplex. Dans le cas du câblage Type1A, évitez de brancher le cordon de raccordement de RJ-45 du transformateur symétrique du type 1A pour éviter de former un bouclage interne dans le transformateur symétrique.

Solution : Voir le contournement.

Cause 3 : Panne de composant SERDES

Si les erreurs sont vues seulement sur un Astro (ou autre stub ASIC) sur un module, et une boucle de la couche 2 ne se produit pas, le problème est le plus susceptible un composant défectueux SERDES sur le superviseur ou le linecard. Par exemple, si le message d'erreur est toujours sur Astro 4 sur le module 3 comme affiché ci-dessous, puis le composant SERDES sur le module 3 ou le composant SERDES sur le superviseur est défectueux.

%SYS-4-P2_WARN: 1/Astro(3/4) – timeout occurred

Dans le message d'erreur ci-dessus, le numéro "4" dans la parenthèse se rapporte à l'Astro #, et pas au port réel 3/4. Ce nombre met en référence les ports de Groupe des Huit (3/33-3/40), car c'est le quatrième Astro sur le module 3.

Un composant défectueux SERDES peut entraîner la connectivité intermittente pour le trafic de contrôle et le trafic de données à l'Astro/au Mans/au plus gentil, ayant pour résultat des délais d'attente. Typiquement, cependant, le message d'erreur sera continuellement affiché si le SERDES est défectueux.

Action : Afin de déterminer ce que (superviseur ou linecard) SERDES est mauvais, exécutez les étapes suivantes :

  1. Déplacez le linecard à un emplacement supplémentaire dans un châssis ou un châssis différent. Si l'emplacement libre est disponible, permutez les emplacements avec le module fonctionnant connu.

  2. Si vous continuez à obtenir Astro/Mans/Nice délais d'attente sur le mêmes Astro/Mans/Nice dans le nouvel emplacement, alors très probablement le SERDES ou l'Astro/Mans/le plus gentil sur le linecard a manqué et le linecard doit être remplacé

    Remarque: En réinsérant le module dans un emplacement supplémentaire, des diagnostics en direct est exécutés sur le linecard. Si un SERDES ou un Astro/Mans/un plus gentil défectueux est trouvé, alors le commutateur marquera le port comme défectueux.

  3. Si les délais d'attente ne continuent pas à se produire sur le linecard d'origine Astro/Mans/Nice, il est possible que le superviseur SERDES soit défectueux. Pour vérifier ceci, insérez un bon connu en fonctionnant le module dans l'emplacement d'origine et voyez si les délais d'attente se produisent avec le nouveau module.

    Si cela fonctionne, c'est probablement un SERDES est sur le superviseur. Référez-vous à la note de terrain partielle en perte de connectivité de présentations de superviseur du Catalyst WS-X4013 pour une liste de numéros de série affectés avec le composant manquant SERDES.

Contournement : Aucun

Solution : Entrez en contact avec le TAC pour davantage de dépannage.

Cause 4 : Panne passagère de /Hard SRAM

Les périphériques connectés à un Catalyst 4000 à un Supervisor I ou II ou III ou IV l'engine ou le Catalyst 2948G, Cat2980G peuvent éprouver la perte de connectivité réseau partielle ou pleine. Certains ou tous les ports ont pu être affectés. Ces symptômes seront accompagnés d'augmenter rapidement les paquets abandonnés par CRC non valide sur les messages d'erreur de dépassement de délai de base par CatOS de superviseur et de stub ASIC.

Le problème est dû à une panne de mémoire de tampon de paquets (SRAM), qui est un type dur ou passager.

Action : Sélectionnez la ligne de conduite selon laquelle des deux signatures passagères de panne de mémoire de tampon de paquets ci-dessous se sont produits :

  1. Signature passagère de panne de mémoire de tampon de paquets pour la PETITE GORGÉE I, PETITE GORGÉE II, 2948G, 2980G

    Ce qui suit sont des symptômes de ce problème :

    • InvalidPktBufferCRC incrémente rapidement avec un message semblable au suivant

      %SYS-4-P2_WARN: 1/Invalid crc, dropped packet, count = xxxx
    • Une étiquette logicielle utilisant la commande de remise ferait échouer le superviseur le POST.

    • Si une réinitialisation matérielle (arrêt et redémarrage) est exécutée, le superviseur passera le POST et n'éprouvera plus la panne.

    Remarque: En cas de panne dure de mémoire de tampon de paquets pour le Supervisor I, II, 2948G, 2980G, une réinitialisation matérielle ne résoudrait pas le problème et le superviseur ou le commutateur échouait toujours le POST.

    Pour plus d'informations sur cette question, référez-vous s'il vous plaît à l'ID de bogue Cisco CSCdy46288 (clients enregistrés seulement) pour Supervisor II, à l'ID de bogue Cisco CSCeb56266 (clients enregistrés seulement) pour le superviseur I/2948G/2980G et à l'ID de bogue Cisco CSCeb56325 (clients enregistrés seulement) pour le WS-C2980G-A.

  2. Signature passagère de panne de mémoire de tampon de paquets pour la PETITE GORGÉE III, PETITE GORGÉE IV

    Ce qui suit sont des symptômes de ce problème :

    • VlanZeroBadCrc parent rapidement des incréments et sont affichés dans la sortie de commande de ce qui suit :

      show platform cpuport all (prior to 12.1(11b)EW1 ) 
      or  show platform cpu packet statistics all (Since 12.1(11b)EW1) 
      depending upon the software version. Starting from 12.1(19)EW, 
      you should also see the following error message rapidly incrementing errors: 
      
      %C4K_SWITCHINGENGINEMAN-2-PACKETMEMORYERROR3: Persistent Errors in 
      Packet Memory xxxx
      
    • Une étiquette logicielle ferait échouer le superviseur le POST. Les shows diagnostic d'utilisation mettent sous tension la commande de vérifier la panne.

    • Une réinitialisation matérielle (arrêt et redémarrage) récupèrera le superviseur et lui passera le POST.

    Remarque: En cas de panne dure de SRAM pour le superviseur III/IV, une réinitialisation matérielle ne récupèrerait pas le superviseur et échouerait toujours le POST.

    Pour plus d'informations sur cette question sur le superviseur III/IV, référez-vous s'il vous plaît à l'ID de bogue Cisco CSCdz57255 (les clients enregistrés seulement)

Contournement : Arrêt et redémarrage ou réinitialisation matérielle le commutateur dans le cas du problème passager de SRAM. Le problème dur de SRAM n'a aucun contournement.

Solution : Entrez en contact avec le TAC pour davantage de dépannage.

Cause 5 : Panne d'horloge de superviseur

Si on voit Astro/Mans/Nice messages d'erreur de dépassement de délai qui se rapportent à des nombres de plusieurs modules ou à plusieurs Astro/à Mans/à Nice, alors ceci pourrait indiquer une panne d'horloge possible sur le superviseur. Généralement, une panne d'horloge est accompagnée de l'Astro/de Mans/Nice du message d'erreur de dépassement de délai et des messages d'erreur de BlockTXQueue et de BlockedGigaport comme affiché ci-dessous :

%SYS-4-P2_WARN: 1/Blocked queue on gigaport ...

Action : Entrez en contact avec le TAC pour davantage de dépannage se rapportant à l'ID de bogue Cisco CSCdp89537 (clients enregistrés seulement) et CSCdp93187 (clients enregistrés seulement).

Contournement : Aucun

Solution : Entrez en contact avec le TAC pour davantage de dépannage.

Cause 6 : Interruption courte d'alimentation

Un commutateur de gamme Catalyst 4000 avec Supervisor II (WS-X4013) peut entrer dans un état dans lequel le superviseur et les linecards ne peuvent pas communiquer correctement avec l'un l'autre. Quand le commutateur entre dans cet état, les diodes d'état de module seront (ne pas flasher) rouge et/ou le port LED flashera dans l'ordre semblable à une remise de module ou de commutateur. Ceci sera accompagné de l'Astro/du Mans/Nice des messages de délai d'attente.

Ce problème est provoqué par par une interruption provisoire de l'alimentation au commutateur (moins de 500 ms). L'interruption provisoire d'alimentation peut être due aux flux instables d'alimentation dedans un environnement de production.

Action : Voir le contournement ci-dessous.

Contournement : Remise (doux ou dur (arrêt et redémarrage)) le commutateur.

Solution : Mise à jour à l'image logicielle avec la difficulté pour l'ID de bogue Cisco CSCea14710 (clients enregistrés seulement) ou les versions ultérieures.


Informations connexes


Document ID: 45640