Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document fournit une brève explication des messages syslog et des messages d'erreur courants que vous voyez sur les commutateurs Cisco de la gamme Catalyst 6500/6000 qui exécutent la plate-forme logicielle Cisco IOS®. Utilisez Cisco CLI Analyzer (pour les clients enregistrés uniquement) si vous avez un message d'erreur qui n'apparaît pas dans ce document. L'outil fournit la signification des messages d'erreur générés par les logiciels Cisco IOS et CatalystOS (CatOS).
Remarque : le format exact des messages syslog et des messages d'erreur décrits dans ce document peut varier légèrement. La variation dépend de la version de logiciel qui fonctionne sur Supervisor Engine.
Remarque : cette configuration minimale de journalisation sur le Catalyst 6500/6000 est recommandée :
Définissez la date et l'heure sur le commutateur, ou configurez le commutateur pour qu'il utilise le Protocole d'Heure Réseau (NTP) pour obtenir la date et l'heure d'un serveur NTP.
Assurez-vous que la journalisation et les marqueurs temporels de la journalisation sont activés, ce qui est le cas par défaut.
Configurez le commutateur pour qu'il enregistre sur un serveur Syslog, si possible.
Aucune exigence spécifique n'est associée à ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Le commutateur enregistre ce message d'erreur :
C6KPWR-SP-4-UNSUPPORTED : module non pris en charge dans le logement [num], alimentation non autorisée : [chars]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Oct 14 16:50:13: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot 2, power not allowed: Unknown Card Type Oct 14 16:50:20: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot 2, power not allowed: Unknown Card Type
Ce message indique que le module dans l'emplacement spécifié n'est pas pris en charge. La valeur [num] est le numéro de l'emplacement et [chars] fournit plus de détails au sujet de l'erreur.
Mettez à niveau le logiciel Supervisor Engine avec une version qui prend en charge le module matériel. Référez-vous à la section Matériel pris en charge de Notes de publication relatives aux commutateurs de la gamme Cisco Catalyst 6500. Afin de résoudre le problème décrit dans le message, exécutez une de ces actions :
Insérez ou remplacez le Module de matrice de commutation.
Déplacez le module non pris en charge à un emplacement différent.
Le commutateur enregistre ce message d'erreur :
%DUAL-3-INTERNAL : IP-EIGRP 1 : erreur interne
Le message d'erreur indique qu'il y a un bogue interne dans le logiciel Cisco IOS. Le bogue a été corrigé dans les versions suivantes :
Logiciel Cisco IOS Version 12.2(0.4)
Logiciel Cisco IOS Version 12.1(6.1)
Logiciel Cisco IOS Version 12.2(0.5)T
Logiciel Cisco IOS Version 12.1(6.5)E
Logiciel Cisco IOS Version 12.1(6.5)EC
Logiciel Cisco IOS Version 12.1.(6)E02
Logiciel Cisco IOS Version 12.2(0.18)S
Logiciel Cisco IOS Version 12.2(2)B
Logiciel Cisco IOS Version 12.2(15)ZN
Mettez à niveau le logiciel Cisco IOS avec l'une de ces versions ou la dernière.
Le commutateur enregistre ce message d'erreur :
%EARL_L3_ASIC-SP-4-INTR_THROTTLE : limitation de « IP_TOO_SHRT »
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Jul 25 12:00:40.228 AEST: %EARL_L3_ASIC-SP-4-INTR_THROTTLE: Throttling "IP_TOO_SHRT"Intr. Exceeded permitted 1000/100 intrs/msec
Ce message indique que le moteur de transfert du commutateur reçoit un paquet IP d'une longueur inférieure à la longueur minimale permise. Le commutateur supprime le paquet. Dans les versions antérieures, le paquet est supprimé silencieusement et compté dans les statistiques du moteur de transfert. Dans les versions postérieures, le message d'erreur est enregistré dans le syslog une fois toutes les 30 minutes. Ces problèmes peuvent engendrer la réception par le moteur de transfert du commutateur de ce type de paquet IP :
Un gestionnaire de carte d'interface réseau défectueux (NIC)
Un bogue du pilote de carte NIC
Une mauvaise application
Le commutateur enregistre simplement qu'il a reçu ces « mauvais » paquets et qu'il va les supprimer.
L'origine du problème est externe au commutateur. Malheureusement, le moteur de transfert ne garde pas trace de l'adresse IP source du périphérique qui envoie ces mauvais paquets. La seule façon de détecter le périphérique est d'employer un analyseur réseau pour détecter la source, puis pour remplacer le périphérique.
Le commutateur enregistre ce message d'erreur :
EARL_L3_ASIC-SP-3-INTR_WARN : ASIC EARL L3 : interruption non fatale [chars]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Apr 20 17:53:38: %EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: Non-fatal interrupt Packet Parser block interrupt Apr 20 19:13:05: %EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: Non-fatal interrupt Packet Parser block interrupt
Le message d'erreur %EARL_L3_ASIC-SP-3-INTR_WARN indique que le circuit intégré spécifique à l'application (ASIC) de la couche 3 (L3) de la logique de reconnaissance des adresses encodées (EARL) a détecté une condition inattendue non fatale. Ceci indique qu'un mauvais paquet, contenant probablement une erreur de contrôle de la couche 3 IP, a été reçu et supprimé. Le problème est dû à un périphérique du réseau qui envoie de mauvais paquets. Les problèmes suivants, notamment, peuvent entraîner de mauvais paquets :
De mauvaises NIC
De mauvais pilotes de carte NIC
De mauvaises applications
Dans des versions plus anciennes du logiciel Cisco IOS, ces paquets sont normalement supprimés sans être journalisés. La fonctionnalité de journalisation des messages d'erreur liés à ce problème est incluse dans le logiciel Cisco IOS Version 12.2SX et ultérieure.
Ce message est à des fins d'information seulement. Comme contournement, utilisez une de ces deux options :
Utilisez un analyseur réseau afin d'identifier la source qui envoie les paquets erronés. Puis, résolvez le problème avec l'équipement ou l'application qui en est à l'origine.
Désactivez les contrôles d'erreur de la couche 3 dans le matériel de commutation pour :
Les erreurs de total de contrôle de paquets
Les erreurs de longueur de paquet
Les paquets ayant les mêmes adresse IP source et de destination
Utilisez la commande no mls verify pour arrêter ces contrôles d'erreur, comme dans ces exemples :
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet
!--- checksum errors.
Switch(config)#no mls verify ip length {consistent | minimum} !--- This configures the switch to discontinue checks for packet
!--- length errors.
Switch(config)#no mls verify ip same-address !--- This configures the switch to discontinue checks for packets that have the
!--- same source and destination IP addresses.
Le commutateur enregistre ce message d'erreur :
EARL_NETFLOW-4-TCAM_THRLD : seuil TCAM Netflow dépassé, utilisation TCAM [[dec]%]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Aug 24 12:30:53: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [97%] Aug 24 12:31:53: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [97%]
Remarque : si vous souhaitez filtrer ce message d'erreur spécifique, sachez que tous les messages d'erreur ayant le même niveau de gravité seront filtrés. Un message du journal spécifique ne peut pas être filtré sans affecter d'autres journaux en-dessous, qui sont sous le même niveau de gravité.
Ce message indique que la mémoire ternaire adressable par le contenu de Netflow (TCAM) est presque pleine. Le vieillissement agressif sera temporairement activé. Si vous changez le masque de Netflow en mode FULL, TCAM pour le Netflow peut déborder en raison de ce grand nombre d'entrées. Émettez la commande show mls netflow ip count afin de contrôler ces informations.
Supervisor Engine 720 contrôle toutes les 30 secondes dans quelle mesure la table de Netflow est pleine. Supervisor Engine active le vieillissement agressif quand la taille de la table atteint presque 90 pour cent. L'idée derrière le vieillissement agressif est que la table est presque pleine de sorte qu'il y a de nouveaux flux actifs qui ne peuvent pas être créés. Par conséquent, il semble logique de vieillir agressivement les flux les moins actifs (ou flux inactifs) dans la table pour libérer de l'espace pour les flux plus actifs.
La capacité pour chaque table Netflow (ipv4) de la carte de fonctionnalités de politique (PFC), pour PFC3a et PFC3b, est 128.000 flux. Pour le PFC3bXL, la capacité est de 256.000 flux.
Afin d'empêcher ce problème, désactivez le mode FULL de Netflow. Émettez la commande no mls flow ip.
Remarque : en général, la commande no mls flow ip n'affecte pas le transfert de paquets car TCAM pour le transfert de paquets et TCAM pour la comptabilisation NetFlow sont distincts.
Pour éliminer ce problème, activez le vieillissement rapide de MLS. Lorsque vous activez la durée de vieillissement rapide de MLS, définissez au commencement la valeur à 128 secondes. Si la taille du cache MLS continue à se développer à plus de 32 K entrées, diminuez la configuration jusque ce que la taille du cache reste inférieure à 32 K. Si le cache continue à se développer au-dessus de 32K entrées, diminuez la durée de vieillissement normal de MLS. Toute valeur de durée de vieillissement qui n'est pas un multiple de 8 secondes est ajustée sur le multiple le plus proche de 8 secondes.
Switch#configure terminal Switch(config)#mls aging fast threshold 64 time 30
L'autre contournement consiste à désactiver service intrenal au cas où vous l'ayez activé, et à supprimer mls flow ip interface-full au cas où vous n'ayez pas besoin de flux complet.
Switch(config)#no service internal Switch(config)#mls flow ip interface-full
Le commutateur enregistre ce message d'erreur et le port est forcé d'arrêter la liaison :
%ETHCNTR-3-LOOP_BACK_DETECTED : Boucle de paquets persistante détectée sur [chars]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Oct 2 10:40:13: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/1 Oct 2 10:40:13: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in err-disable state
Le problème survient parce que le paquet keepalive fait une boucle vers le port qui a envoyé le keepalive. Des keepalives sont envoyés sur les commutateurs Catalyst afin d'empêcher des boucles dans le réseau. Des keepalives sont activées par défaut sur toutes les interfaces. Vous voyez ce problème sur le périphérique qui détecte et casse la boucle, mais pas sur le périphérique qui entraîne la boucle.
Émettez la commande d'interface no keepalive afin de désactiver les keepalives. Désactiver la keepalive empêche l'état errdisable de l'interface, mais ne supprime pas la boucle.
Remarque : dans les versions 12.2(x)SE et ultérieures du logiciel Cisco IOS, les messages de test d'activité ne sont pas envoyés par défaut sur les interfaces fibre et de liaison ascendante.
Le commutateur enregistre ce message d'erreur :
loadprog: error - on file open boot: cannot load "bootflash:c6msfc2-boot-mz.121-8a.EX"
Le problème survient seulement sur une écriture non alignée sur le périphérique qui est fermé à une limite interne de 64 octets. Le problème peut se poser dans l'une de ces circonstances :
Pendant l'écriture d'un fichier de vidage sur incident
Quelque chose entraîne une défaillance du système au moment de l'écriture du fichier.
Quand le code est altéré pendant la migration de CatOS vers le logiciel Cisco IOS
Le contournement consiste à modifier le pilote du périphérique de sorte qu'il gère correctement l'accès non aligné. Si l'erreur se produit en raison d'une corruption de code pendant la migration de CatOS vers le logiciel Cisco IOS, effacez la mémoire Flash et téléchargez une nouvelle image logicielle CatOS valide.
Le commutateur enregistre ce message d'erreur :
%L3_ASIC-DFC3-4-ERR_INTRPT : interruption TF_INT : FI_DATA_INT survenant dans l'ASIC %Layer 3 EARL
Ce message d'erreur indique qu'il y a une erreur dans la couche 3 (L3) expédiant le circuit ASIC. Fondamentalement, le commutateur montre ce message quand un trafic temporaire traverse le circuit ASIC et que le logiciel enregistre simplement l'occurrence d'une condition d'interruption. Dès que cette condition apparaît, les compteurs indiqués par la commande show earl statistics augmentent. Chaque fois que le logiciel essaye de récupérer d'un tel état, le commutateur produit ce message syslog. Généralement, ce message est à des fins d'information tant que son occurrence demeure faible. Mais si le message d'erreur se produit fréquemment, il peut y a un problème avec le matériel.
Contrôlez la valeur des compteurs dans la sortie de la commande show earl statistics. Si les compteurs augmentent rapidement, cela indique un éventuel problème avec le matériel.
Le commutateur enregistre ce message d'erreur :
%MLS_STAT-SP-4-IP_LEN_ERR : incohérences de longueur MAC/IP
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
May 29 21:54:14 JST: %MLS_STAT-SP-4-IP_LEN_ERR: MAC/IP length inconsistencies May 29 23:10:44 JST: %MLS_STAT-SP-4-IP_LEN_ERR: MAC/IP length inconsistencies
Ces messages indiquent que des paquets ont été reçus dans lesquels la longueur IP ne correspond pas à la longueur MAC du paquet. Supervisor Engine a supprimé ces paquets. Il n'y a aucun effet négatif sur le commutateur parce qu'il supprime les paquets. Le commutateur enregistre le message à des fins d'information. Le problème est dû à un périphérique du réseau qui envoie de mauvais paquets. Les problèmes suivants, notamment, peuvent entraîner de mauvais paquets :
De mauvaises NIC
De mauvais pilotes de carte NIC
De mauvaises applications
Utilisez un analyseur réseau afin de trouver la source qui envoie les paquets erronés. Puis, résolvez le problème avec l'équipement ou l'application qui en est à l'origine.
L'autre contournement est une configuration du commutateur qui arrête les contrôle du commutateur :
Les erreurs de total de contrôle de paquets
Les erreurs de longueur de paquet
Les paquets ayant les mêmes adresse IP source et de destination
Utilisez ces commandes pour arrêter les contrôles du commutateur :
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet checksum errors.
Switch(config)#no mls verify ip length !--- This configures the switch to discontinue checks for packet length errors.
Switch(config)#no mls verify ip same-address !--- This configures the switch to discontinue checks for packets that have the
!--- same source and destination IP addresses.
Le commutateur enregistre ce message d'erreur :
%MLS_STAT-SP-4-IP_CSUM_ERR : erreurs de somme de contrôle IP
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Jan 20 12:48:52: %MLS_STAT-SP-4-IP_CSUM_ERR: IP checksum errors Jan 20 14:49:53: %MLS_STAT-SP-4-IP_CSUM_ERR: IP checksum errors
Ces messages indiquent que le commutateur reçoit des paquets IP qui ont une valeur de la somme de contrôle incorrecte. Il n'y a aucun effet négatif sur le commutateur parce qu'il supprime les paquets. Le commutateur enregistre le message à des fins d'information. Le problème est dû à un périphérique du réseau qui envoie de mauvais paquets. Les problèmes suivants, notamment, peuvent entraîner de mauvais paquets :
De mauvaises NIC
De mauvais pilotes de carte NIC
De mauvaises applications
Comme contournement, utilisez une de ces deux options :
Utilisez un analyseur réseau afin d'identifier la source qui envoie les paquets erronés. Puis, résolvez le problème avec l'équipement ou l'application qui en est à l'origine.
Désactivez les contrôles d'erreur de la couche 3 dans le matériel de commutation pour les deux éléments suivants :
Les erreurs de total de contrôle de paquets
Les erreurs de longueur de paquet
Pour arrêter ces contrôles d'erreur, utilisez la commande no mls verify , comme dans ces exemples :
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet
!--- checksum errors.
Switch(config)#no mls verify ip length {consistent | minimum} !--- This configures the switch to discontinue checks for packet
!--- length errors.
Le commutateur enregistre ce message d'erreur :
%MCAST-SP-6-ADDRESS_ALIASING_FALLBACK :
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%MCAST-SP-6-ADDRESS_ALIASING_FALLBACK: Address Aliasing detected for group 0100.5e00.0001 on vlan 632 from possible source ip 10.158.132.185 source mac 0000.bea6.82e0
Ce message indique que le commutateur reçoit un trafic muticast excessif qui est destiné à une adresse MAC multicast dans la plage 01-00-5e-00-00-xx. Cette plage multicast est réservée au trafic de contrôle d'Internet Group Management Protocol (IGMP), par exemple :
Feuilles
Jointures
Requêtes générales
Le CPU du commutateur traite normalement tout le trafic de contrôle d'IGMP. Par conséquent, le logiciel Cisco IOS fournit un mécanisme pour ignorer le trafic IGMP multicast excessif, qui est destiné aux adresses réservées. Le mécanisme s'assure que le CPU ne devient pas submergé. L'utilisation de ce mécanisme est désigné sous le nom de « mode de secours ».
Recherchez la source du trafic de multidiffusion illégal. Puis, arrêtez la transmission ou modifiez les caractéristiques du flux de sorte que la transmission ne viole plus l'espace de données de contrôle d'IGMP. En outre, utilisez le message d'erreur dans la section Problème, qui fournit une source réseau pouvant éventuellement provoquer le problème.
Le commutateur enregistre ce message d'erreur :
c6k_pwr_get_fru_present() : impossible de trouver fru_info pour fru type 6, #
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #38 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #38 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #43 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #43
Ce message d'erreur apparaît en raison d'une réponse incorrecte du commutateur au vote de Protocole de gestion de réseau simple (SNMP) des adaptateurs de port qui fléchissent les modules Flex WAN utilisent. Ce message d'erreur est essentiellement cosmétique, et il n'y a aucun problème de performances préjudiciable au commutateur. Le problème est résolu dans ces versions :
Logiciel Cisco IOS Version 12.1(11b)E4
Logiciel Cisco IOS Version 12.1(12c)E1
Logiciel Cisco IOS Version 12.1(13)E
Logiciel Cisco IOS Version 12.1(13)EC
Versions ultérieures
Le commutateur enregistre ce message d'erreur :
%MROUTE-3-TWHEEL_DELAY_ERR :
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%MROUTE-3-TWHEEL_DELAY_ERR: Exceeded maximum delay (240000 ms) requested: 7200000
Ce message apparaît quand le commutateur reçoit les paquets multicast PIM (Protocol Independent Multicast) Joindre/Élaguer qui présentent une valeur élevée de temps de maintien. Les paquets présentent une valeur de temps de maintien plus élevée que le délai maximal permis par le système d'exploitation du commutateur, qui est de 4 minutes. Ces paquets sont des paquets de contrôle multicast, tels que PIM, Distance Vector Multicast Routing Protocol (DVMRP) et d'autres types.
Les versions ultérieures du logiciel Cisco IOS pour Catalyst 6500/6000 ont augmenté ce délai maximal à 65.535 secondes, ou approximativement 17 minutes. Le problème est résolu dans ces versions :
Logiciel Cisco IOS Version 12.1(12c)E
Logiciel Cisco IOS Version 12.2(12)T01
Logiciel Cisco IOS Version 12.1(13)E
Logiciel Cisco IOS Version 12.1(13)EC
Versions ultérieures
Configurez le périphérique tiers qui produit des paquets PIM pour qu'il utilise les temporisateurs recommandés par les normes du protocole.
Le commutateur enregistre ce message d'erreur :
%MCAST-SP-6-GC_LIMIT_EXCEEDED
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%MCAST-SP-6-GC_LIMIT_EXCEEDED: IGMP snooping was trying to allocate more Layer 2 entries than what=allowed (13000)
Ce message d'erreur est enregistré quand la fonction IGMP Snooping sur le commutateur a créé le nombre maximal d'entrées autorisées sur la couche 2 (L2). Le nombre maximum par défaut d'entrées sur la couche L2 que le commutateur peut créer pour des groupes multicast est 15.488. Dans les versions ultérieures du logiciel Cisco IOS, seules les entrées de multidiffusion L2 installées sur le matériel comptent vers la limite. Référez-vous à l'ID bogue Cisco CSCdx89380 (clients enregistrés seulement) pour plus de détails. Le problème est résolu dans le logiciel Cisco IOS Version 12.1(13)E1 et ultérieure.
Vous pouvez élever manuellement la limite L2. Émettez la commande ip igmp l2-entry-limit.
Le commutateur enregistre ce message d'erreur :
%MISTRAL-SP-3-ERROR : Condition d'erreur détectée : TM_NPP_PARITY_ERROR
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Apr 19 22:14:18.237 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Apr 19 22:14:25.050 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Apr 19 22:15:20.171 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR
Ce message d'erreur indique qu'il y a eu une erreur de parité dans le pointeur de la page suivante du gestionnaire interne de table. Si le commutateur exécute le logiciel Cisco IOS Version 12.1(8)E ou ultérieure, il détecte l'erreur de parité et réinitialise l'ASIC Mistral. Le commutateur peut alors continuer, sans nécessité de recharger. Une décharge électrostatique aléatoire ou d'autres facteurs externes peuvent entraîner l'erreur de parité de la mémoire. Si vous voyez le message d'erreur seulement une fois ou rarement, contrôlez le Syslog du commutateur afin de confirmer que le message d'erreur est un incident isolé. Si ces messages d'erreur se reproduisent, créez une demande de service avec l'assistance technique de Cisco.
Le commutateur enregistre ce message d'erreur :
%MLS_STAT-4-IP_TOO_SHRT : paquets IP reçus trop courts
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
*Apr 1 10:30:35 EST: %MLS_STAT-SP-4-IP_TOO_SHRT: Too short IP packets received
Ce message indique que le moteur de transfert du commutateur reçoit un paquet IP d'une longueur inférieure à la longueur minimum permise. Le commutateur supprime le paquet. Dans les versions antérieures, le paquet est supprimé silencieusement et compté dans les statistiques du moteur de transfert. Ceci s'applique aux versions de logiciel qui sont antérieures à 7.x ou antérieures au logiciel Cisco IOS Version 12.1(13E). Dans des versions de logiciel postérieures à 7.x ou postérieures au logiciel Cisco IOS Version 12.1(13E), le message est enregistré dans le syslog une fois toutes les 30 minutes.
Il n'y a aucun effet du côté du commutateur. Le commutateur supprime le mauvais paquet, que l'équipement en réception aurait supprimé en conséquence. Le seul souci est qu'il y a un périphérique qui envoie de mauvais paquets. Les causes possibles incluent :
Un mauvais pilote de carte NIC
Un bogue du pilote de carte NIC
Une mauvaise application
En raison des limitations matérielles, Supervisor Engine ne garde pas trace de la source IP, de l'adresse MAC ni du port du périphérique qui envoie les mauvais paquets. Vous devez employer une application de reniflage de paquets afin de détecter ces périphériques et de détecter l'adresse source.
Le message dans la section Problème est simplement un message envoyé par le commutateur aux fins d'avertissement/d'information. Le message ne fournit aucune information au sujet du port source, de l'adresse MAC ou de l'adresse IP.
Utilisez une application de reniflage de paquets à l'intérieur du réseau. Essayez en arrêter une partie de l'interface ou de supprimer certains périphériques du réseau afin de déterminer si vous isoler le périphérique qui fonctionne mal.
Le commutateur enregistre ce message d'erreur :
Processor [number] of module in slot [number] cannot service session requests
Cette erreur se produit quand vous émettez la commande session slot number processor number afin d'essayer d'établir une session dans ces situations :
Vous essayez d'établir une session vers un module dans lequel une session a déjà été établie lors de la connexion au commutateur.
Vous essayez d'établir une session pour un module indisponible dans l'emplacement.
Vous essayez d'établir a session pour un processeur indisponible dans le module.
Le commutateur enregistre ce message d'erreur :
%PM_SCP-1-LCP_FW_ERR : Module de réinitialisation du système [dec] à récupérer après l'erreur : [chars]
Ces exemples montrent la sortie de console qui est affichée quand ce problème survient :
%PM_SCP-SP-1-LCP_FW_ERR : Réinitialisation du système du module 13 pour récupérer de l'erreur : exception système reçue par la carte de ligne
ou
%PM_SCP-SP-1-LCP_FW_ERR : Réinitialisation du système du module 4 pour récupérer de l'erreur : Erreur de parité de bobine Pb Rx - Port #14
Le message indique que le microprogramme du module spécifié a détecté une erreur. Le système réinitialise automatiquement le module afin de récupérer de l'erreur. La valeur [dec] est le numéro de module, et [chars] est l'erreur.
Réinsérez le module ou mettez le module dans un emplacement différent et permettez au module de passer par le test complet de diagnostic de démarrage. Pour plus d'informations sur les diagnostics en direct sur les commutateurs de la gamme Catalyst 6500, référez-vous à Configuration des diagnostics en ligne. Après que le module passe le test de diagnostics, contrôlez la récurrence du message d'erreur. Si l'erreur se produit de nouveau ou si le test de diagnostics détecte un problème, créez une demande de service avec l'assistance technique de Cisco pour davantage de dépannage.
Le commutateur enregistre ce message d'erreur :
%PM_SCP-2-LCP_FW_ERR_INFORM : Le module [dec] rencontre l'erreur suivante : [chars]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%PM_SCP-SP-2-LCP_FW_ERR_INFORM : Le module 4 rencontre l'erreur suivante : Bus Asic #0 transitoire Pb error
Le module signale une condition d'erreur, où [dec] est le numéro de module et [chars] est l'erreur. Cette situation est généralement due à une carte de ligne mal insérée ou à une défaillance matérielle. Si le message d'erreur s'affiche sur toutes les cartes de ligne, cela est dû à un module mal installé.
Réinstallez et réinitialisez la carte de ligne ou le module. Exécutez ensuite la commande show diagnostic result module_#."
Si le message d'erreur persiste après la réinitialisation du module, créez une demande de service auprès de l'assistance technique Cisco pour un dépannage plus approfondi.
Le commutateur enregistre ce message d'erreur :
%PM_SCP-SP-2-LCP_FW_ERR_INFORM : Le module 4 rencontre l'erreur suivante : Port #36 transitoire TX Pb error
Ce message d'erreur indique une erreur transitoire sur le module numéro 4 dans le chemin de données du port 36. Dans la plupart des cas, il s'agit d'un problème ponctuel/transitoire.
Fermez et défermez le port Gi4/36 et surveillez la récurrence du problème.
Si l'erreur se produit à nouveau, définissez le diagnostic sur terminé avec la commande diagnostic bootup level complete. Réinstallez ensuite physiquement la carte de ligne.
Si le message d'erreur persiste après la réinstallation du module, créez une demande de service avec l'assistance technique de Cisco pour un dépannage plus approfondi avec ces sorties de commande :
Le commutateur enregistre ce message d'erreur :
%PM_SCP-SP-4-UNK_OPCODE : message non sollicité inconnu reçu du module [dec], opcode [hex]
Ces exemples montrent la sortie de console qui est affichée quand ce problème survient :
10 déc 12:44:18.117: %PM_SCP-SP-4-UNK_OPCODE: message non sollicité inconnu reçu du module 2, opcode 0x330
ou
Dec 10 12:44:25.210: %PM_SCP-SP-4-UNK_OPCODE: réception d'un message non sollicité inconnu du module 2, opcode 0x114
Ce message d'erreur indique simplement que Supervisor Engine ne comprend pas le message de contrôle de la carte de ligne en raison de fonctionnalités qui ne sont pas prises en charge par la version du logiciel Cisco IOS du commutateur.
Les cartes de ligne envoient les messages de contrôle au Supervisor Engine actif qui indiquent les fonctionnalités prises en charge par le logiciel. Mais si le logiciel ne prend en charge aucune des fonctionnalités de la de carte de ligne, ces messages de contrôle ne sont pas reconnus et le message d'erreur est affiché. Ce message est une occurrence inoffensive et n'affecte aucune fonction sur Supervisor Engine ou les cartes de ligne.
Mettez à niveau le logiciel Supervisor Engine avec la dernière version qui a une prise en charge maximale des fonctionnalités. Puisque ce message d'erreur n'affecte pas la production ou le trafic, vous pouvez ignorer le message.
Le commutateur enregistre ce message d'erreur :
%PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM : échec du contrôle d'intégrité de l'émetteur-récepteur sur le port LAN 5/2 : clé incorrecte
La raison de ce message d'erreur est l'utilisation d'un GBIC non-Cisco SFP, qui n'est pas pris en charge.
Les modules GBIC SFP Cisco disposent d'un code chiffré unique (Quality ID) qui permet à Cisco IOS/CAT OS d'identifier les composants enfichables Cisco. Les GBIC normaux n'ont pas cette fonction et peuvent donc fonctionner. Référez-vous à %PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM pour plus d'informations.
Le commutateur enregistre ce message d'erreur :
%PM_SCP-SP-3-LCP_FW_ABLC : message de collision tardive du module 3, port : 035
Collisions tardives : une collision tardive se produit lorsque deux périphériques transmettent simultanément et qu'aucun des deux côtés de la connexion ne détecte de collision. Cela se produit car le temps nécessaire à la propagation du signal d'une extrémité à l'autre du réseau est plus long que le temps nécessaire pour placer la totalité du paquet sur le réseau. Les deux périphériques à l'origine de la collision tardive ne voient jamais que l'autre effectue un envoi tant qu'ils n'ont pas placé la totalité du paquet sur le réseau. Les collisions tardives ne sont détectées par l'émetteur qu'après la plage de temps des 64 premiers octets. En effet, elles sont détectées uniquement dans les transmissions de paquets dont la taille est supérieure à 64 octets.
Causes possibles - Les collisions tardives sont le résultat d’une non-concordance de mode bidirectionnel, d’un câblage incorrect ou d’un nombre non conforme de concentrateurs sur le réseau. Les cartes NIC défectueuses peuvent également provoquer des collisions tardives.
Le commutateur enregistre ce message d'erreur :
%PM-3-INVALID_BRIDGE_PORT: Bridge Port number is out of range
Ce problème semble cosmétique et est dû à un sondage SNMP de la mib dot1dTpFdbEntry.
Vous pouvez bloquer l'OID de l'interrogation sur ce périphérique. Ce défaut est corrigé à partir de la version 12.2(33)SRD04 de Cisco IOS et ultérieure.
Le commutateur enregistre ce message d'erreur :
%QM-4-TCAM_ENTRY : capacité d'entrée TCAM matérielle dépassée
TCAM est une partie spécialisée de la mémoire conçue pour des recherches de table rapides par les moteurs d'ACL et de QoS. Ce message indique l'épuisement des ressources TCAM et la commutation logicielle de paquets. Ceci signifie que chaque interface a son propre ID dans TCAM et utilise donc plus de ressources TCAM. Ce problème est très probablement provoqué par la présence de la commande mls qos marking statistics ou quand le matériel TCAM n'a pas la capacité de gérer tous les ACL configurés.
Désactivez la commande mls qos marking statistics puisqu'elle est activée par défaut.
Essayez de partager les mêmes ACL à travers plusieurs interfaces afin de réduire le conflit de ressources TCAM.
Le commutateur enregistre ce message d'erreur :
%slot_earl_icc_shim_addr : le logement [num] n'est ni une super carte ni un superviseur - Logement non valide
Ce message se produit quand un gestionnaire SNMP vote pour les données TCAM d'une carte de ligne qui n'a aucune information TCAM. Ceci se produit seulement pour une carte de ligne dans un commutateur Catalyst 6500 qui exécute le logiciel Cisco IOS. Si la carte de ligne a des informations TCAM pendant le vote SNMP, les données sont fournies au système de gestion de réseaux (NMS) pour un autre traitement. Référez-vous à l'ID bogue Cisco CSCec39383 (clients enregistrés seulement) pour plus de détails. Ce problème est résolu dans le logiciel Cisco IOS Version 12.2(18) .
Comme contournement, vous pouvez bloquer la requête des données TCAM par les NMS. L'objet MIB qui fournit les données d'utilisation TCAM est cseTcamUsageTable. Complétez ces étapes sur le routeur afin d'éviter des retours arrière :
Émettez la commande tcamBlock cseTcamUsageTable excluded.
Émettez la commande tcamBlock iso included.
Émettez la commande snmp-server community public view tcamBlock ro.
Émettez la commande snmp-server community private view tcamBlock rw.
Le commutateur enregistre ce message d'erreur :
%SYSTEM_CONTROLLER-SP-3-ERROR : Condition d'erreur détectée : TM_NPP_PARITY_ERROR
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
Feb 23 21:55:00: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Feb 23 22:51:32: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Feb 23 23:59:01: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR
Les erreurs les plus communes de l'ASIC Mistral sur le MSFC sont TM_DATA_PARITY_ERROR, SYSDRAM_PARITY_ERROR, SYSAD_PARITY_ERROR et TM_NPP_PARITY_ERROR. Parmi les causes possibles de ces erreurs de parité figurent une décharge électrostatique aléatoire ou d'autres facteurs externes. Ce message d'erreur indique qu'il y avait une erreur de parité. Les erreurs PMPE (Processor Memory Parity Errors) sont divisées en deux types : les erreurs SEU (Single Event Dispersion) et les erreurs répétées.
Ces erreurs à bit unique se produisent quand un bit dans un mot contenant des données change inopinément en raison des événements externes (qui entraînent, par exemple, le changement spontané d'un zéro en un un). Les SEU sont un phénomène universel indépendant du constructeur ou de la technologie. Les SEU se produisent très rarement, mais tous les systèmes informatiques et systèmes réseau, même un PC, y sont sujets. Les SEU, également appelées « erreurs mineures », sont provoquées par du bruit et résultent d'une erreur passagère et incohérente dans les données. Ceci est indépendant d'une panne composante et est le plus souvent dû à au rayonnement cosmique.
Des erreurs répétées (souvent appelées « erreurs majeures ») sont provoquées par les composants défaillants. Une erreur majeure est provoquée par un composant défaillant ou un problème au niveau du panneau, tel qu'une carte de circuit imprimé mal construit, avec pour conséquences des occurrences répétées de la même erreur.
Si vous voyez le message d'erreur seulement une fois ou rarement, contrôlez le Syslog du commutateur afin de confirmer que le message d'erreur est un incident isolé. Si ces messages d'erreur se reproduisent, réinsérez la lame de Supervisor Engine. Si les erreurs s'arrêtent, c'est qu'il s'agissait d'une erreur de parité majeure. Si ces messages d'erreur continuent à se reproduire, ouvrez un cas auprès du centre d'assistance technique.
Le commutateur enregistre ce message d'erreur :
%SYSTEM_CONTROLLER-SW2_SPSTBY-3-ERROR : Condition d'erreur détectée : TM_NPP_PARITY_ERROR
Ce message d'erreur indique qu'il y a eu une erreur de parité et que les causes possibles sont une décharge statique aléatoire ou d'autres facteurs externes, ce qui entraîne l'erreur de parité de mémoire, telle qu'une connectivité transitoire du panneau arrière ou peut se produire en raison de problèmes d'alimentation et parfois la carte de ligne ne peut pas accéder au contenu de la mémoire PROM série (SPROM) sur le module afin de déterminer l'identification de la carte de ligne.
Tous les systèmes informatiques et réseau sont sujets à de rares perturbations d'événements uniques (SEU), parfois qualifiées d'erreurs de parité. Ces erreurs sur un seul bit se produisent lorsqu'un bit d'un mot de données change de manière inattendue en raison d'événements externes, et provoquent ainsi, par exemple, le passage spontané d'un zéro à un un. Les SEU sont un phénomène universel indépendamment du fournisseur et de la technologie. Les SEU se produisent très rarement, mais tous les systèmes informatiques et systèmes réseau, même un PC, y sont sujets. Les SEU sont également appelées erreurs temporaires, qui sont causées par le bruit et entraînent une erreur transitoire et incohérente dans les données, et ne sont pas liées à une défaillance de composant.
Les erreurs répétées, souvent appelées erreurs matérielles, sont causées par des composants défaillants. Une erreur matérielle est provoquée par un composant défectueux ou par un problème au niveau de la carte, tel qu'une carte de circuit imprimé mal fabriquée, qui entraîne des occurrences répétées de la même erreur.
Si ces messages d'erreur se répètent, réinstallez le module de supervision pendant la fenêtre de maintenance.
Le commutateur enregistre ce message d'erreur :
SP : le point de terminaison de la carte de ligne du canal 14 a perdu la synchronisation avec le fabric inférieur et tente de récupérer maintenant !
Le message d'erreur indique habituellement une carte de ligne mal ajustée. Dans la plupart des cas, vous pouvez physiquement réinsérer la carte de ligne afin de résoudre ce problème. Dans certains cas, le module est défectueux.
Émettez la commande show fabric fpoe map afin d'identifier le module qui entraîne ce message d'erreur.
Switch#configure terminal Switch(config)#service internal Switch(config)#end Switch#show fabric fpoe map Switch#configure terminal Switch(config)#no service internal Switch(config)#end
Cet exemple est le résultat de la commande show fabric fpoe map. À partir de la sortie, vous pouvez identifier que le module à l'emplacement 12 entraîne le message d'erreur.
switch#show fabric fpoe map slot channel fpoe 12 0 14 << There are also related errors in "show fabric channel-counters" : slot channel rxErrors txErrors txDrops lbusDrops 1 0 1 0 0 0 2 0 16 0 0 0 3 0 16 0 0 0
Réinsérez le module qui génère le message d'erreur.
Pendant le démarrage d'un commutateur Cisco Catalyst 6000/6500, il peut afficher un message d'erreur semblable :
%SYSTEM-1-INITFAIL: Network boot is not supported. Invalid device specified Booting from default device Initializing ATA monitor library... monlib.open(): Open Error = -13 loadprog: error - on file open boot: cannot load "bootdisk:s72033-ipservicesk9-mz.122-18.SXF7.bin"
Cette erreur se produit en grande partie quand les variables de démarrage ne sont pas configurées correctement pour démarrer le commutateur à partir d'un périphérique Flash valide.
Dans l'illustration, notez la dernière ligne du message :
boot: cannot load "bootdisk:s72033-ipservicesk9-mz.122-18.SXF7.bin"
Le nom du périphérique Flash mentionné est bootdisk, et la première partie du nom de fichier IOS, s72033 indique que IOS est pour le module Supervisor 720. Le module Supervisor 720 ne comporte ni ne prend en charge un périphérique Flash appelé bootdisk. Puisque le module Supervisor 720 n'a pas de Flash local de ce nom, le commutateur pense que vous voulez démarrer à partir du réseau, d'où l'affichage du message d'erreur.
Configurez la variable de démarrage avec le nom de périphérique Flash correct et le nom correct du fichier de logiciel.
Ces périphériques Flash sont pris en charge par les modules de Supervisor :
Supervisor Engine 1 et Supervisor Engine 2
Nom du périphérique Flash | Description |
---|---|
bootflash: | Mémoire Flash embarquée |
slot0: | Carte PC Flash linéaire (emplacement PCMCIA) |
disk0: | Carte PC Flash ATA (emplacement PCMCIA) |
Supervisor Engine 720
Nom du périphérique Flash | Description |
---|---|
bootflash: | Mémoire Flash embarquée |
disk0: | Carte CompactFlash de type II seulement (emplacement disque 0) |
disk1: | Carte CompactFlash de type I (emplacement disque 1) |
Supervisor Engine 32
Nom du périphérique Flash | Description |
---|---|
bootdisk : | Mémoire Flash embarquée |
disk0: | Carte CompactFlash de type II seulement (emplacement disque 0) |
Si ceci ne résout pas le problème, référez-vous à Récupération d'un Catalyst 6500/6000 exécutant la plate-forme logicielle Cisco IOS à partir d'une image de programme de démarrage altérée ou absente ou d'un mode ROMmon.
Le commutateur enregistre ces messages d'erreur :
CPU_MONITOR-3-TIMED_OUT: CPU monitor messages have failed, resetting system CPU_MONITOR-6-NOT_HEARD: CPU monitor messages have not been heard for [dec] seconds
Ces messages indiquent que des messages de contrôle du CPU n'ont pas été entendus pendant une période importante. Un temps d'attente se produit probablement, ce qui réinitialise le système. [dec] est le nombre de secondes.
Le problème se pose probablement pour ces raisons :
Carte de ligne ou module mal installé
Mauvais ASIC ou mauvais fond de panier
Bogues logiciels
Erreur de parité
Trafic élevé dans l'Ethernet hors du canal Ethernet Out of Band Channel (EOBC)
Le canal EOBC est un canal bidirectionnel à l'alternat, qui gère beaucoup d'autres fonctions dont le trafic du Protocole de gestion de réseau simple (SNMP) et les paquets qui sont destinés au commutateur. Si le canal EOBC est plein de messages en raison d'une tempête de trafic SNMP, le canal est alors soumis à des collisions. Quand ceci se produit, EOBC n'est peut-être pas capable de porter les messages IPC. Ceci provoque l'affichage du message d'erreur par le commutateur.
Réinsérez la carte de ligne ou le module. Si une fenêtre de maintenance peut être planifiée, réinitialisez le commutateur pour supprimer tout problème passager.
Le message d'erreur %Invalid IDPROM image for linecard est reçu dans les commutateurs de la gamme Catalyst 6500 exécutant la plate-forme logiciel Cisco IOS.
Le message d'erreur peut être semblable à ceux-ci :
% Invalid IDPROM image for daughterboard 1 in slot 4 (error = 4) % Invalid IDPROM image for linecard in slot 5 (error = 4) % Invalid IDPROM image for daughterboard 1 in slot 5 (error = 4)
Cette erreur indique que les cartes de ligne installées n'ont pas démarré correctement parce que le superviseur a généré un mauvais signal sur le bus de commande. Dans certains scénarios, on voit que l'allocation erronée des places peut également entraîner la non-reconnaissance du superviseur ou les cartes de ligne sur le châssis Cat6500. Référez-vous à l'ID bogue Cisco CSCdz65855 (clients enregistrés seulement) pour plus d'informations.
Si la configuration avec un superviseur redondant est disponible, exécutez un changement de force et réinsérez le superviseur actif initial.
S'il s'agit d'une configuration avec un superviseur unique, programmez un temps d'arrêt et exécutez ces étapes :
Déplacez le module de supervision à l'autre emplacement.
Réinsérez toutes les cartes de ligne et assurez-vous qu'elles sont placées correctement.
Le commutateur enregistre ces messages d'erreur :
%CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 61 seconds [2/0] %CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 151 seconds [2/0] %CPU_MONITOR-SP-3-TIMED_OUT: CPU_MONITOR messages have failed, resetting module [2/0] %OIR-SP-3-PWRCYCLE: Card in module 1, is being power cycled off (Module not responding to
Keep Alive polling) %OIR-SP-3-PWRCYCLE: Card in module 2, is being power-cycled off (Heartbeat Messages Not
Received From Module)
Le superviseur envoie une requête ping SCP toutes les 2 secondes à chaque carte de ligne. Si aucune réponse n'est reçue après 3 requêtes ping (6 secondes), elle est comptée comme premier échec. Après 25 défaillances successives, ou après 150 secondes de non-réception d'une réponse de la carte de ligne, le superviseur met cette carte de ligne sous tension. Toutes les 30 secondes, ce message d'erreur s'affiche sur le commutateur :
%CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 61 seconds [2/0] %CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 151 seconds [2/0]
Après 150 secondes, le module est mis hors tension puis sous tension à l'aide des journaux système suivants :
%CPU_MONITOR-SP-3-TIMED_OUT: CPU_MONITOR messages have failed, resetting module [2/0] %OIR-SP-3-PWRCYCLE: Card in module 1, is being power-cycled off (Module not responding to
Keep Alive polling) %OIR-SP-3-PWRCYCLE: Card in module 2, is being power-cycled off (Heartbeat Messages Not
Received From Module)
Le commutateur enregistre ce message d'erreur :
%C6KPWR-4-DISABLED: Power to module in slot [dec] set [chars]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%C6KPWR-SP-4-DISABLED: power to module in slot 10 set off (Fabric channel errors) %C6KPWR-SP-4-DISABLED: power to module in slot 2 set off (Module Failed SCP dnld) %C6KPWR-SP-4-DISABLED: power to module in slot 9 set off (Module not responding to Keep
Alive polling)
Ce message indique que le module dans l'emplacement indiqué a été mis hors tension pour la raison indiquée. [dec] est le numéro de l'emplacement, et [chars] indique l'état de l'alimentation.
Un commutateur a des vibrations normales qui, au fil du temps, peuvent faire déplacer légèrement un module du fond du panier. Quand ceci se produit, les interrogations des keepalives du superviseur ne reçoivent pas de réponse du module dans le temps imparti et le superviseur redémarre le module afin d'essayer d'obtenir une meilleure connexion. Si le module ne répond toujours pas aux interrogations, le superviseur redémarre continuellement le module pour finalement le mettre dans l'état error disable et ne permet pas à l'alimentation d'atteindre ce module.
Une simple réinsertion du module corrige ce problème 90 pour cent des fois. Si vous réinsérez le module, cela réaligne la matrice de commutation et assure une connexion ferme au fond du panier.
Si le module intéressé est le module de commutation du contenu (CSM), envisagez la mise à niveau du logiciel CSM à la version 4.1(7) ou ultérieure. Ce problème est documenté comme l'ID bogue Cisco CSCei85928 (contre logiciel CSM) (clients enregistrés seulement) et l'ID bogue Cisco CSCek28863 (contre logiciel Cisco IOS) (clients enregistrés seulement).
Le dernier logiciel CSM peut être téléchargé depuis la page de téléchargement du logiciel du module de commutation de contenu Cisco Catalyst 6000.
Le commutateur enregistre le message d'erreur :
ONLINE-SP-6-INITFAIL: Module [dec]: Failed to [chars]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%ONLINE-SP-6-INITFAIL: Module 5: Failed to synchronize Port asic
La cause de la panne est que la synchronisation par l'ASIC Pinnacle a échoué. Ceci est habituellement provoqué par un mauvais contact ou une carte mal insérée.
Le système récupère sans intervention de l'utilisateur. Si le message d'erreur se reproduit, réinsérez la carte de ligne ou le module intéressé.
Le commutateur enregistre le message d'erreur :
%FM_EARL7-4-FLOW_FEAT_FLOWMASK_REQ_FAIL: Flowmask request for the flow based feature [chars] for protocol [chars] is unsuccessful, hardware acceleration may be disabled for the feature
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%FM_EARL7-4-FLOW_FEAT_FLOWMASK_REQ_FAIL: Flowmask request for the flow based feature Reflexive ACL for protocol IPv4 is unsuccessful, hardware acceleration may be disabled for the feature
La requête de masque du flux pour la fonctionnalité basée sur le flux est infructueuse. Cette condition peut se produire en raison d'une exception de ressource TCAM, d'un masque de flux qui enregistre une exception de ressource ou d'un conflit insoluble de masque de flux avec d'autres fonctionnalités basées sur Netflow. L'installation du raccourci Netflow et l'accélération matérielle pour la fonctionnalité peuvent être désactivées sous cette condition, et la fonctionnalité peut être appliquée dans le logiciel.
Si vous avez la liste de contrôle d'accès réflexive (ACL) en entrée seulement, reflect et eval configurés dans le sens des entrées sur différentes interfaces, alors la condition de masque de flux d'ACL est basée sur des ACL réflexives d'entrée. Tant que l'ACL réflexive est configurée sur une interface différente que le contrôle micro-flux de QoS ou qu'elle ne s'y superpose pas, ils peuvent coexister dans le matériel en étant sur la même interface. S'ils sont sur la même interface et que l'ACL reflexive et le contrôle QoS se superposent, alors l'ACL réflexive désactive l'installation du raccourci de Netflow et l'ACL reflexive correspondante du trafic est commutée par le logiciel. Ceci est dû aux conditions contradictoires du masque de flux.
En cas d'ACL réflexive de sortie, la condition de masque de flux de l'ACL réflexive est globale sur toutes les interfaces, puisqu'il y a seulement le Netflow d'entrée. Si le contrôle du micro-flux QoS basé sur l'utilisateur est configuré dans ce cas, l'ACL réflexive désactive l'installation du raccourci de Netflow et l'ACL reflexive correspondante du trafic est commutée par le logiciel.
Émettez la commande show fm fie flowmask afin de déterminer l'installation du raccourci de Netflow est activée/désactivée pour la fonctionnalité. Si l'installation du raccourci de Netflowet et l'accélération matérielle sont désactivée pour la fonctionnalité, utilisez seulement les listes d'accès réflexives d'entrée en combination avec le contrôle du micro-flux, et assurez-vous que le régulateur de micro-flux ne se superpose pas à la liste d'accès réflexive. Réappliquez la fonctionnalité pour que la requête de masque de flux réussisse et réactivez l'installation du raccourci Netflow pour la fonctionnalité.
Le commutateur enregistre le message d'erreur :
%MCAST-2-IGMP_SNOOP_DISABLE:IGMP Snooping disabled due to excessive events/packets, [dec]/[dec]; auto reenable in about 2 mins
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%MCAST-2-IGMP_SNOOP_DISABLE:IGMP Snooping disabled due to excessive events/packets, 0/19880; auto reenable in about 2 mins
IGMP Snooping est désactivé, mais le système reçoit le trafic de multidiffusion. Cette situation force les paquets de multidiffusion à être dirigés vers le processeur de routage, qui peut le saturer. IGMP Snooping peut être désactivé automatiquement dû au trafic multicast excessif. IGMP Snooping regarde ces paquets de contrôle qui sont échangés entre les routeurs et les hôtes et, selon les messages d'entrée, de sortie et de requête, met à jour les ports qui reçoivent le multicast.
Ce message se produit généralement parce que le processeur de routage reçoit un débit beaucoup plus important que prévu de paquets IGMP d'entrée ou des paquets multicast normaux destinés à des plages d'adresse multicast réservées de couche 3/couche 2. Par conséquent, le commutateur manque de ressources et, comme le signale les messages de journalisation, il atténue et désactive IGMP Snooping pendant une brève période.
Vous pouvez activer la fonctionnalité de limitation du débit multicast et définir le seuil à nombre supérieur.
La limitation du débit est une méthode plus souhaitable pour que la file d'attente ne soit pas débordée ; elle signifie également que les paquets IGMP valides ont moins de possibilité d'être supprimés et donc que le processus de surveillance sur le commutateur peut toujours mettre à jour convenablement.
Réalisez ces étapes pour résoudre ce problème :
Désactivez IGMP Snooping avec la commande no ip igmp snooping.
Configurez une session SPAN sur l'interface VLAN de gestion sur votre Catalyst 6500 afin de déterminer que l'adresse MAC appartient à la source d'où provient le trafic excessif.
Regardez dans la table CAM afin d'identifier la source et supprimez-la.
Réactivez IGMP Snooping.
Le commutateur enregistre ces messages d'erreur. Le message d'erreur peut être l'un de ces deux types :
C6KERRDETECT-2-FIFOCRITLEVEL: System detected an unrecoverable resources error on the
active supervisor pinnacle
C6KERRDETECT-2-FIFOCRITLEVEL: System detected unrecoverable resources error on active
supervisor port-asic
La cause à l'origine de cette erreur est probablement un module défectueux ou un module mal inséré. Cela peut également être un problème de châssis avec cet emplacement particulier. S'il est dû à un module mal inséré, ceci peut être un problème passager.
Ces messages indiquent que le système a détecté des ressources irrécupérables en raison d'un problème FIFO (First In, First Out) sur l'ASIC Pinacle indiqué ou le port ASIC spécifié.
Émettez la commande remote command switch show platform hardware asicreg pinnacle slot 1 port 1 err afin de résoudre cette erreur, et configurez le commutateur pour exécuter des tests matériels améliorés avec ces étapes :
Remarque : tapez la commande complète et appuyez sur la touche Entrée. Vous ne pouvez pas écrire la commande avec la touche Tab.
Émettez la commande diagnostic bootup level complete pour définir le niveau de diagnostic à réaliser, et sauvegardez la configuration.
Réinsérez le superviseur et insérez-le fermement.
Une fois que le superviseur entre en ligne, émettez la commande show diagnostic pour contrôler le commutateur et vérifiez si le message d'erreur persiste.
Le commutateur enregistre ces messages d'erreur :
%C6KERRDETECT-SP-4-SWBUSSTALL : le bus de commutation est bloqué pendant 3 secondes
%C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERED : le blocage du bus de commutation est récupéré et la commutation du trafic de données continue
Le message %C6KERRDETECT-SP-4-SWBUSSTALL indique que le bus de commutation est bloqué et que le trafic de données est perdu.
Le message %C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERED indique que le bus de commutation n'est plus bloqué et que le trafic de données peut continuer.
En fait, si un module quelconque du bus système se bloque, le superviseur détecte un dépassement de délai et tente de récupérer lui-même. Si un module était en cours d'installation, alors c'est une cause très possible de ces messages puisque cela peut provoquer un arrêt du bus pendant que le module est assis dans le fond de panier.
Ce message d'erreur est reçu quand les pings de test intrabande ont échoué en raison d'un CPU élevé :
SP-RP Ping Test[7]: Test skipped due to high traffic/CPU utilization
Le SP-RP dans le ping de bande est un test de diagnostic en ligne et le message SP-RP ping test failed est purement à titre d'information. Il indique une utilisation élevée du CPU et peut être le résultat d'un fort trafic passant sur le processeur de routage ou d'un trafic de commutation circulant vers le processeur du commutateur. Ceci peut également se produire pendant les mises à jour de routage. Il est normal d'avoir le CPU du processeur de routage utilisé jusqu'à 100 pour cent parfois.
Le message d'erreur est purement à titre informatif et n'a pas d'incidence sur les performances du périphérique.
Le commutateur enregistre ce message d'erreur :
%SW_VLAN-4-MAX_SUB_INT : The number of sub-interfaces allocated for interface [chars] has exceeded recommended limits of [dec]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%SW_VLAN-4-MAX_SUB_INT: The number of sub-interfaces allocated for interface Gi1/1 has exceeded recommended limits of 1000
Le nombre des sous-interfaces de couche 3 est limité par les VLAN internes dans le commutateur. La gamme Catalyst 6500 a 4094 VLAN qui sont utilisés pour des fins diverses. Émettez la commande show platform hardware capacity vlan afin de connaître l'état actuel de disponibilité du VLAN.
Switch#show platform hardware capacity vlan VLAN Resources VLANs: 4094 total, 9 VTP, 0 extended, 17 internal, 4068 free
La limite recommandée de sous interfaces est 1.000 pour chaque interface et 2000 pour chaque module. Réduisez le nombre de sous-interface allouées pour l'interface car il a dépassé la limite recommandée.
Remarque : la console peut être verrouillée en raison de l'inondation de ces messages qui sont affichés lors du rechargement du commutateur. Ce problème est documenté dans l'ID bogue Cisco CSCek73741 (clients enregistrés seulement) et est résolu dans le logiciel Cisco IOS Versions 12.2(18)SXF10 et Cisco IOS12.2(33)SXH ou ultérieures .
Le commutateur enregistre ce message d'erreur :
MCAST-6-L2_HASH_BUCKET_COLLISION: Failure installing (G,C)->index: ([enet],[dec])->[hex] Protocol :[dec] Error:[dec]
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%MCAST-SP-6-L2_HASH_BUCKET_COLLISION: Failure installing (G,C)->index: (0100.5e31.d522,802)->0xDA4 Protocol :0 Error:3
Ce message d'erreur est normalement vu avec ce message :
%MCAST-SP-6-GC_LIMIT_EXCEEDED: IGMP snooping was trying to allocate more Layer 2 entries than what allowed (15488)
Ce message indique qu'une entrée de la couche 2 n'a pas été installée dans le matériel parce qu'il n'y a pas assez d'espace dans le compartiment de hachage. Des paquets de multidiffusion sont saturés sur le VLAN entrant parce que l'installation de l'entrée de la couche 2 a échoué. Quand la limite est dépassée, la saturation se produit pour d'autres groupes MAC.
Si vous n'utilisez pas la multidiffusion, vous pouvez désactiver IGMP Snooping. Autrement, vous pouvez augmenter la limite d'entrée d'informations parasites en utilisant la commande ip igmp snooping l2-entry-limit.
Le commutateur enregistre ce message d'erreur :
%QM-4-AGG_POL_EXCEEDED: QoS Hardware Resources Exceeded : Out of Aggregate policers
Seul un nombre limité de régulateurs agrégés peut être pris en charge. Sur les commutateurs basé sur EARL7, limite est 1023.
Au lieu d'un QoS basé sur les ports, vous pouvez configurer un QoS sur les VLAN. Procédez comme suit :
Appliquez la politique de service à chaque VLAN configuré sur le port de commutateur de la couche 2.
Supprimez la politique de service de chaque port qui appartient au spécifique VLAN.
Configurez chaque port de commutateur de la couche 2 pour le QoS basé sur les VLAN avec la commande mls qos vlan-based.
Le commutateur enregistre ce message d'erreur :
%EC-SP-5-CANNOT_BUNDLE2 : n'est pas compatible avec Gi2/1 et sera suspendu (MTU de Gi2/2 est 1500, Gi2/1 est 9216)
Ce message d'erreur indique que le MTU du membre du canal de port n'est pas le même, donc provoquez l'échec de l'ajout du canal de port. Par défaut, toutes les interfaces utilisaient la taille MTU 1500. En raison d'une non-correspondance de la valeur MTU, le port ne peut pas être ajouté au canal de port.
Configurez le même MTU sur ces ports membres.
Le commutateur enregistre ce message d'erreur :
%EC-SP-5-CANNOT_BUNDLE2 : Gi1/4 n'est pas compatible avec Gi6/1 et sera suspendu (l'envoi de contrôle de flux de Gi1/4 est désactivé, Gi6/1 est activé)
Ce message d'erreur indique une vitesse ou une non-concordance de contrôle de flux, la cause en est donc une défaillance d'ajout de canal de port.
Vérifiez que la configuration d'interface participe au canal de port.
Le commutateur enregistre ce message d'erreur :
%CFIB-7-CFIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched
Le message d'erreur indique que le nombre d'entrées de route installées est sur le point d'atteindre la capacité FIB matérielle ou la limite maximale de routes définie pour le protocole spécifié. Si la limite est atteinte, certains préfixes sont supprimés.
Rechargez le routeur afin de quitter le mode d'exception. Entrez la commande mls cef maximum-routes en mode de configuration globale afin d'augmenter le nombre maximal de routes pour le protocole. Par défaut, une PFC3 sur SUP a une capacité de 192K entrées mais si vous utilisez la commande mls cef maximum-routes 239, ceci donne une option pour utiliser le maximum d'entrées TCAM disponibles. Utilisez la commande show mls cef maximum-routes afin de vérifier les routes maximales. Utilisez la commande show mls cef summary, qui affiche le résumé des informations de la table CEF, afin de vérifier l'utilisation actuelle.
Le module 5(supervisor) échoue au test de diagnostic TestMatchCapture comme indiqué dans cette sortie de show diagnostic result module module_# :
TestMatchCapture ----------------> F Error code ------------------> 59 (DIAG_L2_INDEX_MISMATCH_ERROR) Total run count -------------> 1 Last test execution time ----> Jun 25 2011 04:49:10 First test failure time -----> Jun 25 2011 04:49:10 Last test failure time ------> Jun 25 2011 04:49:10 Last test pass time ---------> n/a Total failure count ---------> 1 Consecutive failure count ---> 1
Le test TestMatchCapture est une combinaison des tests TestProtocolMatchChannel et TestCapture comme décrit ici :
TestProtocolMatchChannel - Le test TestProtocolMatchChannel vérifie la capacité à faire correspondre des protocoles de couche 2 spécifiques dans le moteur de transfert de couche 2. Lorsque vous exécutez le test sur le moteur de supervision, le paquet de diagnostic est envoyé à partir du port intrabande du moteur de supervision et effectue une recherche de paquets avec le moteur de transfert de couche 2. Pour les modules compatibles DFC, le paquet de diagnostic est envoyé depuis le port intrabande du moteur de supervision via la matrice de commutation et est rebouclé depuis l'un des ports DFC. La fonctionnalité de correspondance est vérifiée lors de la recherche de paquets de diagnostic par le moteur de transfert de couche 2.
TestCapture - Le test TestCapture vérifie que la fonctionnalité de capture du moteur de transfert de couche 2 fonctionne correctement. La fonctionnalité de capture est utilisée pour la réplication multidiffusion. Lorsque vous exécutez le test sur le moteur de supervision, le paquet de diagnostic est envoyé à partir du port intrabande du moteur de supervision et effectue une recherche de paquets avec le moteur de transfert de couche 2. Pour les modules compatibles DFC, le paquet de diagnostic est envoyé depuis le port intrabande du moteur de supervision via la matrice de commutation et est rebouclé depuis l'un des ports DFC. La fonction Capture est vérifiée lors de la recherche de paquets de diagnostic par le moteur de transfert de couche 2.
Réinstallez le module chaque fois que vous en avez l'occasion. Comme il s'agit d'erreurs mineures, elles peuvent être ignorées si vous ne voyez aucun impact sur les performances.
Le commutateur enregistre ce message d'erreur :
%CONST_DIAG-SP-3-HM_PORT_ERR: Port [dec] on module [dec] failed [dec] consecutive times. Disabling the port.
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%CONST_DIAG-SP-3-HM_PORT_ERR: Port 5 on module 2 failed 10 consecutive times. Disabling the port.
Le message d'erreur indique que le chemin de données qui correspond au port a échoué. Le port est mis dans l'état errdisable.
Réinitialisez la carte de ligne afin de voir si le problème se résout de lui-même.
Le commutateur enregistre ce message d'erreur :
%CONST_DIAG-SP-4-ERROR_COUNTER_WARNING: Module 7 Error counter exceeds threshold, system operation continue. %CONST_DIAG-SP-4-ERROR_COUNTER_DATA: ID:42 IN:0 PO:255 RE:200 RM:255 DV:2 EG:2 CF:10 TF:117
Vérifiez les résultats du diagnostic :
TestErrorCounterMonitor ---------> . Error code ------------------> 0 (DIAG_SUCCESS) Total run count -------------> 33658 Last test execution time ----> Apr 15 2012 11:17:46 First test failure time -----> Apr 03 2012 20:11:36 Last test failure time ------> Apr 08 2012 19:24:47 Last test pass time ---------> Apr 15 2012 11:17:46 Total failure count ---------> 5 Consecutive failure count ---> 0 Error Records ---------------> n/a
TestErrorCounterMonitor surveille les erreurs/interruptions sur chaque module du système en interrogeant périodiquement les compteurs d'erreurs conservés dans la carte de ligne.
Ce message d'erreur apparaît lorsqu'un ASIC sur la carte de ligne reçoit des paquets avec un CRC incorrect. Le problème peut être local à ce module ou peut être déclenché par un autre module défectueux dans le châssis. Cela peut également être dû à des trames avec un CRC incorrect reçues par pinnacle asic du DBUS. En d'autres termes, les messages d'erreur impliquent que des paquets erronés sont reçus sur le bus du module 7.
L'une des raisons pour lesquelles les messages d'erreur se produisent est l'incapacité du module à communiquer correctement avec le fond de panier du châssis en raison d'un mauvais positionnement du module. Le problème provient de la carte de ligne (module mal inséré), du superviseur ou du bus de données. Cependant, il n'est pas possible de dire quel composant corrompt les données et provoque un CRC incorrect.
Effectuez tout d'abord une remise en place du module 7 et assurez-vous que les vis sont bien serrées. En outre, avant la réinstallation, configurez les diagnostics pour qu'ils se terminent avec la commande diagnostic bootup level complete.
Une fois la réinstallation terminée, les diagnostics complets s'exécuteront sur le module. Ensuite, vous pouvez confirmer qu'il n'y a aucun problème matériel sur le module 7.
Le commutateur enregistre ce message d'erreur :
%SYS-3-PORT_RX_BADCODE:Port [dec]/[chars] detected [dec] bad code errors in last 30 minutes
Cet exemple montre la sortie de console qui est affichée quand ce problème survient :
%SYS-3-PORT_RX_BADCODE: Port 3/43 detected 7602 bad code error(s) in last 30 minutes
Ce message d'erreur indique qu'un port a été affecté par une erreur de protocole inconnue. Par exemple, un commutateur de la gamme Catalyst 6500 reçoit des trames avec un protocole qu’il ne connaît pas et qu’il ne reconnaît pas. Le premier [dec] est le numéro de module, [chars] est le numéro de port et le second [dec] est le nombre de paquets entrants avec des protocoles inconnus rencontrés au cours des 30 dernières minutes.
Voici les causes possibles du message d'erreur :
En raison de paramètres de vitesse et de duplex incorrects.
Le protocole CDP est activé à une extrémité et non à l’autre.
En raison du protocole DTP, il est activé par défaut sur les interfaces de commutateur. Comme les routeurs ne comprennent pas le protocole DTP, cela peut entraîner certains problèmes.
Vérifiez le compteur runts sur l'interface. Si elle augmente, il peut y avoir une non-correspondance de mode duplex sur les interfaces.