Ce document décrit comment dépanner le matériel et les problèmes courants associés sur les commutateurs Catalyst 6500/6000 qui exécutent le logiciel système Cisco IOS®.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Le logiciel Cisco IOS se rapporte à l'image simple empaquetée Cisco IOS à la fois pour le Supervisor Engine et le module de carte (MSFC) de fonctionnalité de commutateur multicouche. Ce document suppose que vous avez un symptôme du problème et que vous voulez obtenir des informations supplémentaires à son sujet ou que vous voulez le résoudre. Ce document peut s'appliquer au Supervisor Engine 1, 2, ou à des commutateurs Catalyst 6500/6000 basés 720.
Les messages du système sont imprimés sur la console si la journalisation est activée sur la console ou dans le Syslog, si le Syslog est activé. Une partie des messages sont à titre informatif seulement et n'indiquent pas une condition d'erreur. Pour une présentation des messages d'erreur système, référez-vous à Vue d'ensemble des messages système. Activez le niveau approprié de journalisation et configurez le commutateur pour journaliser les messages sur un serveur syslog. Pour plus d'informations sur la configuration, référez-vous au document Configurer les périphériques du routeur et du commutateur.
Afin de surveiller les messages consignés, émettez la commande show logging ou utilisez un outil pour surveiller les stations périodiquement. Si vous êtes toujours incapable de déterminer le problème, ou si le message d'erreur n'est pas présent dans la documentation, contactez le centre d'escalade du support technique Cisco.
Le message d'erreur %CONST_DIAG-SP-4-ERROR_COUNTER_WARNING : Le compteur d'erreurs du module 4 dépasse le seuil s'affiche sur la console du Catalyst 6500. Ce problème peut avoir deux causes :
Une connexion médiocre au fond de panier (broche de connecteur courbée ou connexion électrique médiocre) ou
Cela peut être lié à la première indication d'un module défaillant.
Afin de résoudre ce problème, définissez le niveau de démarrage de diagnostic sur « terminé », puis réinstallez fermement le module 4 dans le châssis. Cela détecte toute défaillance matérielle latente et résout également les problèmes de connexion du fond de panier.
La commande show diagnostic sanity exécute une série de contrôles prédéterminés sur la configuration, avec une combinaison de certains états su système. La commande compile alors une liste des conditions d'avertissement. Les contrôles sont conçus pour rechercher tout ce qui semble inadéquat. Les vérifications sont destinées à faciliter le dépannage et la maintenance de la santé du système. La commande ne modifie pas les variables ou les états système actuels. Elle lit les variables du système qui correspondent à la configuration et aux états afin de lancer des avertissements s'il existe une correspondance d'une série de combinaisons prédéterminées. La commande n'a pas d'effet sur la fonctionnalité du commutateur, et vous pouvez l'utiliser sur un environnement de réseau de production. La seule limitation pendant le processus d'exécution est que la commande réserve le système de fichier pendant un temps déterminé tandis que la commande accède aux images de démarrage et teste leur validité. La commande est supportée dans la version Cisco IOS 12.2(18)SXE1 ou supérieure.
Cette commande permet de vérifier la configuration d'un paramètre qui semble valide mais qui peut avoir une implication négative. Avertissez l'utilisateur dans les cas suivants :
Trunking : le mode Trunk est activé ou si le port est agrégé en mode automatique. Un port de jonction a un mode qui est fixé sur souhaité et qui n'est pas en liaison ou si le port de jonction négocie au half-duplex.
Canalisation : le mode de canalisation est activé ou si un port n'effectue pas de canalisation et que le mode est défini sur desirable.
Spanning Tree : l'un de ces paramètres est défini par défaut :
Root Max Age
retard de retransmission de root
Âge maximum
retard de retransmission maximum
Délai Hello
coût du port
priorité de port
Ou, si la racine de spanning-tree n'est pas définie pour un VLAN.
UDLD : le port UDLD (UniDirectional Link Detection) est désactivé, arrêté ou dans un état indéterminé.
Contrôle de flux et PortFast : le contrôle de flux a été désactivé sur le port ou si PortFast est activé.
Haute disponibilité - Le Supervisor Engine redondant est présent mais la haute disponibilité (HA) est désactivée.
Chaîne de démarrage et registre de configuration de démarrage : la chaîne de démarrage est vide ou contient un fichier non valide spécifié comme image de démarrage. Le registre de configuration est quelque chose d'autre que 0x2,0x102, ou 0x2102.
IGMP Snooping : la surveillance IGMP (Internet Group Management Protocol) est désactivée. En outre, si la surveillance IGMP est désactivée mais que le protocole RGMP (Router-Port Group Management Protocol) est activé, et si la multidiffusion est activée globalement mais désactivée sur l'interface.
SNMP Community access strings : les chaînes d'accès (rw, ro, rw-all) sont définies par défaut.
Ports : un port négocie en mode bidirectionnel non simultané ou présente une non-concordance bidirectionnel/VLAN.
Ports d'alimentation en ligne : un port d'alimentation en ligne présente l'un des états suivants :
nié
défectueux
other (autre)
désactivé
Modules : un module est dans un état autre que "ok".
Tests : répertorie les tests de diagnostic du système qui ont échoué au démarrage.
Passerelle(s) par défaut inaccessible : envoie une requête ping aux passerelles par défaut afin de répertorier celles qui ne sont pas accessibles.
Contrôle si le bootflash est correctement formaté et a assez d'espace pour contenir un fichier crashinfo.
Voici un exemple de sortie :
Note: La sortie réelle peut varier, en fonction de la version du logiciel.
Switch#show diagnostic sanity Status of the default gateway is: 10.6.144.1 is alive The following active ports have auto-negotiated to half-duplex: 4/1 The following vlans have a spanning tree root of 32k: 1 The following ports have a port cost different from the default: 4/48,6/1 The following ports have UDLD disabled: 4/1,4/48,6/1 The following ports have a receive flowControl disabled: 4/1,4/48,6/1 The value for Community-Access on read-only operations for SNMP is the same as default. Please verify that this is the best value from a security point of view. The value for Community-Access on read-write operations for SNMP is the same as default. Please verify that this is the best value from a security point of view. The value for Community-Access on read-write-all operations for SNMP is the same as default. Please verify that this is the best value from a security point of view. Please check the status of the following modules: 8,9 Module 2 had a MINOR_ERROR. The Module 2 failed the following tests: TestIngressSpan The following ports from Module2 failed test1: 1,2,4,48
Reportez-vous à la section show diagnostic sanity du Guide de configuration du logiciel.
Si la LED de votre commutateur du Supervisor Engine est rouge, ou si l'état montre faulty, il peut y avoir un problème de matériel. Vous pouvez recevoir un message d'erreur système qui est semblable à ceci :
%DIAG-SP-3-MINOR_HW: Module 1: Online Diagnostics detected Minor Hardware Error
Procédez comme suit pour poursuivre le dépannage :
Accédez au Supervisor Engine par la console et exécutez la commande show diagnostic module {1 | 2}, si possible.
Note: Vous devez définir le niveau de diagnostic sur complet de sorte que le commutateur puisse exécuter une suite complète de tests pour identifier n'importe quelle défaillance matérielle. La réalisation du test de diagnostic en ligne complet augmente légèrement le temps de démarrage. Le démarrage au niveau minimal ne prend pas autant de temps qu'au niveau complet, mais la détection des problèmes matériels potentiels sur la carte se produit toujours. Émettez la commande de configuration globale diagnostic boot level afin de basculer entre les niveaux de diagnostic. Le niveau de diagnostic par défaut est minimal, sur le logiciel système Cisco IOS.
Note: Des diagnostics en ligne ne sont pas supportés pour les systèmes basés sur le Supervisor Engine 1 qui exécute le logiciel Cisco IOS.
Cette sortie montre un exemple de défaillance :
Router#show diagnostic mod 1
Current Online Diagnostic Level = Complete
Online Diagnostic Result for Module 1 : MINOR ERROR
Test Results: (. = Pass, F = Fail, U = Unknown)
1 . TestNewLearn : .
2 . TestIndexLearn : .
3 . TestDontLearn : .
4 . TestConditionalLearn : F
5 . TestBadBpdu : F
6 . TestTrap : .
7 . TestMatch : .
8 . TestCapture : F
9 . TestProtocolMatch : .
10. TestChannel : .
11. IpFibScTest : .
12. DontScTest : .
13. L3Capture2Test : F
14. L3VlanMetTest : .
15. AclPermitTest : .
16. AclDenyTest : .
17. TestLoopback:
Port 1 2
----------
. .
18. TestInlineRewrite:
Port 1 2
----------
. .
Si les diagnostics à la mise sous tension renvoient la failure, que le F indique dans les résultats de test, exécutez ces étapes :
Réinsérez le module fermement et assurez-vous que les vis sont fortement serrées.
Déplacez le module vers un emplacement fonctionnel, en bon état, sur le même châssis ou sur un châssis différent.
Note: Le Supervisor Engine 1 ou 2 peut entrer dans l'emplacement 1 ou l'emplacement 2 seulement.
Dépannez pour éliminer la possibilité d'un module défectueux.
Note: Dans quelques rares circonstances, un module défectueux peut avoir comme conséquence que l'état du Supervisor Engine est faulty.
Afin d'éliminer la possibilité, exécutez une de ces étapes :
Si vous avez récemment inséré un module et si le Supervisor Engine a commencé à signaler des problèmes, enlevez le module que vous avez inséré en dernier et réinsérez-le fermement. Si vous recevez toujours des messages qui indiquent que le Supervisor Engine est faulty, redémarrez le commutateur sans ce module. Si le Supervisor Engine fonctionne correctement, il y a une possibilité que le module soit défectueux. Inspectez le connecteur du fond de panier sur le module pour être sûr qu'il n'y a aucun dommage. S'il n'y a aucun dommage visuel, essayez le module dans un autre emplacement ou dans un châssis différent. En outre, inspectez les broches coudées sur le connecteur de l'emplacement sur le fond de panier. Utilisez une lampe-torche s'il y a lieu, quand vous inspectez les broches de connecteur sur le fond du panier du châssis. Si vous avez toujours besoin d'aide, entrez en contact avec l'assistance technique Cisco.
Si vous ne savez pas si un module a récemment été ajouté, et si le remplacement du Supervisor Engine ne règle pas le problème, il est possible que le module soit mal inséré ou qu'il soit défectueux. Afin de dépanner, enlevez du châssis tous les modules sauf le Supervisor Engine. Mettez le châssis sous tension et assurez-vous que le Supervisor Engine ne présente aucune défaillance. Si le Supervisor Engine ne présente aucune défaillance, commencez à insérer les modules un par un jusqu'à ce que vous déterminiez le module qui est défectueux. Si le Supervisor Engine n'échoue plus, il est possible qu'un des modules n'ait pas été placé correctement. Observez le commutateur et, si vous continuez à avoir des problèmes, créer une demande de service avec l'assistance technique Cisco afin de dépanner plus loin.
Après avoir effectué chacune de ces étapes, exécutez la commande show diagnostic module <module_number>. Regardez si le module montre toujours failure status. Si l'état d'échec apparaît toujours, capturez le journal des étapes précédentes et créez une demande de service avec l'assistance technique Cisco pour obtenir une assistance supplémentaire.
Note: Si vous exécutez le train de logiciel Cisco IOS version 12.1(8), les diagnostics n'ont pas tous une assistance. Vous recevez des messages d'échec faux quand les diagnostics sont activés. Les diagnostics sont supportés dans Cisco IOS version 12.1(8b)EX4 et versions ultérieures, et pour les systèmes basés sur le Supervisor Engine 2, dans le logiciel Cisco IOS version 12.1(11b)E1 et ultérieures. En outre, reportez-vous aux notes de champs : Diagnostics incorrectement activés dans le logiciel Cisco IOS versions 12.1(8b)EX2 et 12.1(8b)EX3 pour plus d'informations.
Si le commutateur ne démarre pas et échoue aux autodiagnostics pendant la séquence de démarrage, capturez le résultat et créez une demande de service auprès de l'assistance technique Cisco pour obtenir de l'aide.
Si vous ne voyez aucune défaillance matérielle dans la séquence de démarrage ou dans la sortie de la commande show diagnostics module {1 | 2}, émettez les commandes show environment status et show environment temperature afin de vérifier les sorties liées aux conditions d'environnement et rechercher d'autres composants défaillants.
cat6knative#show environment status backplane: operating clock count: 2 operating VTT count: 3 fan-tray 1: fan-tray 1 fan-fail: OK VTT 1: VTT 1 OK: OK VTT 1 outlet temperature: 35C VTT 2: VTT 2 OK: OK VTT 2 outlet temperature: 31C VTT 3: VTT 3 OK: OK VTT 3 outlet temperature: 33C clock 1: clock 1 OK: OK, clock 1 clock-inuse: in-use clock 2: clock 2 OK: OK, clock 2 clock-inuse: not-in-use power-supply 1: power-supply 1 fan-fail: OK power-supply 1 power-output-fail: OK module 1: module 1 power-output-fail: OK module 1 outlet temperature: 28C module 1 device-2 temperature: 32C RP 1 outlet temperature: 34C RP 1 inlet temperature: 34C EARL 1 outlet temperature: 34C EARL 1 inlet temperature: 28C module 3: module 3 power-output-fail: OK module 3 outlet temperature: 39C module 3 inlet temperature: 23C EARL 3 outlet temperature: 33C EARL 3 inlet temperature: 30C module 4: module 4 power-output-fail: OK module 4 outlet temperature: 38C module 4 inlet temperature: 26C EARL 4 outlet temperature: 37C EARL 4 inlet temperature: 30C module 5: module 5 power-output-fail: OK module 5 outlet temperature: 39C module 5 inlet temperature: 31C module 6: module 6 power-output-fail: OK module 6 outlet temperature: 35C module 6 inlet temperature: 29C EARL 6 outlet temperature: 39C EARL 6 inlet temperature: 30C
Si vous voyez une panne d'un composant système (thermoventilateur, terminaison de tension [VTT]), créez une demande de service auprès de l'assistance technique Cisco et fournissez la sortie de commande.
Si vous voyez un état d'échec dans cette sortie pour l'un des modules, émettez la commande hw-module module <module_number> reset. Ou réinsérez le module dans le même emplacement afin d'essayer de récupérer le module. Consultez également la section Dépannage d'un module qui ne se met pas en ligne ou indique un état défectueux ou autre de ce document pour plus d'aide.
Si l'état indique OK, comme le montre l'exemple de sortie dans l'étape 3, émettez la commande show environment alarms pour vérifier s'il y a une alerte environnement.
S'il n'y a aucune alerte, la sortie est semblable à ceci :
cat6knative#show environment alarm environmental alarms: no alarms
Mais, s'il y a une alerte, la sortie est semblable à ceci :
cat6knative#show environment alarm environmental alarms: system minor alarm on VTT 1 outlet temperature (raised 00:07:12 ago) system minor alarm on VTT 2 outlet temperature (raised 00:07:10 ago) system minor alarm on VTT 3 outlet temperature (raised 00:07:07 ago) system major alarm on VTT 1 outlet temperature (raised 00:07:12 ago) system major alarm on VTT 2 outlet temperature (raised 00:07:10 ago) system major alarm on VTT 3 outlet temperature (raised 00:07:07 ago)
Missing l'image systèmeSi votre commutateur Supervisor Engine est dans une booting , en mode moniteur ROM (ROMmon), ou n'a pas l'image système, le problème n'est probablement pas un problème matériel.
Le Supervisor Engine passe en mode ROMmon ou ne démarre pas lorsque l'image système est endommagée ou missing. Pour des instructions sur la façon de récupérer le Supervisor Engine, référez-vous à Récupération d'un commutateur Catalyst 6500/6000 exécutant le logiciel système Cisco IOS à partir d'un Image du chargeur de démarrage ou mode ROMmon.Missing
Vous pouvez démarrer l'image Cisco IOS à partir de n'importe quel Sup-bootflash. ou slot0: (l'emplacement pour carte PC). Ayez une copie de l'image du système dans les deux périphériques pour une récupération plus rapide. Si le périphérique du bootflash du Supervisor Engine 2 a seulement 16 Mo, une mise à niveau jusqu'à 32 Mo peut être nécessaire pour prendre en charge les images système les plus récentes. Pour plus d'informations, reportez-vous à la ROM de démarrage du Supervisor Engine 2 de la gamme Catalyst 6500 et à la note d'installation de la mise à jour du bootflash.
Cette partie présente les raisons communes pour lesquelles le module du Supervisor Engine de secours ne parvient pas à se mettre en ligne et indique comment résoudre chaque problème. Vous pouvez faire en sorte que le module du Supervisor Engine ne se mette pas en ligne en procédant d'une de ces façons :
La sortie de la commande show module montre l'état other ou faulty.
La LED d'état ambre est éclairée.
Raisons communes/solutions
Accédez à la console du Supervisor Engine de secours afin de déterminer s'il est en mode ROMmon ou en redémarrage continu. Si le Supervisor Engine est dans l'un de ces états, reportez-vous à Récupérer un commutateur Catalyst 6500/6000 exécutant le logiciel système Cisco IOS à partir d'une image de chargement de démarrage altérée ou manquante ou à partir du mode ROMmon.
Note: Si les Supervisor Engines actif et de secours n'exécutent pas la même version de logiciel Cisco IOS, se peut que le Supervisor Engine de secours ne se mette pas en ligne. Par exemple, un Supervisor Engine peut ne pas parvenir à démarrer lorsque :
Le moteur actif du superviseur exécute la Redondance du processeur de routage plus (RPR+) mode.
Note: Le mode RPR+ est disponible dans la version 12.1(11)EX du logiciel Cisco IOS et les versions ultérieures.
Le Supervisor Engine de secours exécute une version de logiciel dans laquelle le mode RPR/RPR+ n'est pas disponible, comme Cisco IOS version 12.1[8b]E9.
Dans ce cas, le second Supervisor Engine ne se met pas en ligne parce que le mode de redondance est EHSA (Enhanced High System Availability), par défaut. Le Supervisor Engine de secours ne parvient pas à négocier avec le Supervisor Engine actif. Assurez-vous que les deux Supervisor Engines exécutent la même version du logiciel Cisco IOS.
Cette sortie montre le moteur de supervision dans l'emplacement 2 en mode ROMmon. Vous devez vous connecter au Supervisor Engine de secours pour le récupérer. Pour des procédures de récupération, référez-vous à Récupérer un commutateur Catalyst 6500/6000 exécutant le logiciel système Cisco IOS à partir d'une image de chargement de démarrage altérée ou manquante ou à partir du mode ROMmon.
tpa_data_6513_01#show module Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 2 Catalyst 6000 supervisor 2 (Active) WS-X6K-S2U-MSFC2 SAD0628035C 2 0 Supervisor-Other unknown unknown 3 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAL061218K3 4 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAL061218K8 5 0 Switching Fabric Module-136 (Active) WS-X6500-SFM2 SAD061701YC 6 1 1 port 10-Gigabit Ethernet Module WS-X6502-10GE SAD062003CM Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ------ ------------ ------------ ------- 1 0001.6416.0342 to 0001.6416.0343 3.9 6.1(3) 7.5(0.6)HUB9 Ok 2 0000.0000.0000 to 0000.0000.0000 0.0 Unknown Unknown Unknown 3 0005.7485.9518 to 0005.7485.9527 1.3 12.1(5r)E1 12.1(13)E3, Ok 4 0005.7485.9548 to 0005.7485.9557 1.3 12.1(5r)E1 12.1(13)E3, Ok 5 0001.0002.0003 to 0001.0002.0003 1.2 6.1(3) 7.5(0.6)HUB9 Ok 6 0002.7ec2.95f2 to 0002.7ec2.95f2 1.0 6.3(1) 7.5(0.6)HUB9 Ok Mod Sub-Module Model Serial Hw Status --- --------------------------- --------------- --------------- ------- ------- 1 Policy Feature Card 2 WS-F6K-PFC2 SAD062802AV 3.2 Ok 1 Cat6k MSFC 2 daughterboard WS-F6K-MSFC2 SAD062803TX 2.5 Ok 3 Distributed Forwarding Card WS-F6K-DFC SAL06121A19 2.1 Ok 4 Distributed Forwarding Card WS-F6K-DFC SAL06121A46 2.1 Ok 6 Distributed Forwarding Card WS-F6K-DFC SAL06261R0A 2.3 Ok 6 10GBASE-LR Serial 1310nm lo WS-G6488 SAD062201BN 1.1 Ok
Assurez-vous que le module du du moteur de superviseur est correctement posé dans le connecteur de carte mère. Assurez-vous également que la vis d'installation du moteur de supervision est complètement serrée. Reportez-vous à la Note d'installation de module de commutation de la gamme Catalyst 6500 pour plus d'informations.
Afin d'identifier si le Supervisor Engine de secours est faulty, lancez la commande redundancy reload peer à partir du Supervisor Engine actif. Par l'intermédiaire de la console vers le Supervisor Engine de secours, observez la séquence de démarrage afin d'identifier toutes les défaillances matérielles.
Si le Supervisor Engine de secours ne se met toujours pas en ligne, créez une demande de service auprès de l'assistance technique Cisco afin de poursuivre le dépannage. Lorsque vous créez la demande de service, fournissez le journal de la sortie de commutateur que vous avez collectée lors des étapes précédentes.
Ce message d'erreur apparaît parce que PA-1XCHSTM1/OC3 n'a pas le support diagnostique dans le SRB. Quand cette commande est réussie, tandis que le commutateur exécute un code SRB, l'état not applicable est indiqué. Ceci ne signifie pas que l'état du processeur d'interface de SPA n'est pas contrôlé, puisque les diagnostics globaux donnent les résultats appropriés. A partir du code SRC, cette sortie fonctionne. Ceci est causé par un bogue avec le code SRB, et ce bogue est classé dans l'ID de bogue Cisco CSCso02832 (accessible seulement aux clients Cisco enregistrés).
Cette section présente les raisons communes pour lesquelles le Supervisor de secours du commutateur Catalyst se recharge inopinément.
Le superviseur actif réinitialise le superviseur de secours après une défaillance de synchronisation avec la configuration de mise en route. Ce problème peut être dû à la wr mem consécutive qui est exécutée par des stations de gestion dans une courte envergure de temps (1-3 secondes), qui verrouille la configuration de mise en route et provoque l'échec de la synchronisation. Si le premier processus de sync n'est pas achevé et si le second mem wr est émis, il y a une panne de sync sur le supervisor de secours, et parfois, celui-ci se recharge ou se réinitialise. Ce problème est documenté dans l'ID de bogue Cisco CSCsg24830 (accessible uniquement aux clients Cisco enregistrés). Cette défaillance de synchronisation peut être identifiée par ce message d'erreur:
%PFINIT-SP-5-CONFIG_SYNC: Sync'ing the startup configuration to the standby Router %PFINIT-SP-1-CONFIG_SYNC_FAIL: Sync'ing the startup configuration to the standby Router FAILED
Le superviseur actif ne synchronise pas sa configuration avec le superviseur de secours. Il peut s'agir d'une condition transitoire provoquée par l'utilisation temporaire du fichier de configuration par un autre processus. Si vous avez entré la commande show configuration ou la commande show running-configuration pour afficher la configuration ou la configuration en cours, le fichier de configuration est verrouillé. Ce problème est documenté dans l'ID de bogue Cisco CSCeg21028 (accès par les clients Cisco enregistrés seulement). Cette défaillance de synchronisation peut être identifiée par ce message d'erreur:
%PFINIT-SP-1-CONFIG_SYNC_FAIL_RETRY: Sync'ing the startup configuration to the standby Router FAILED, the file may be already locked by a command
Lorsque vous retirez physiquement un module du châssis, la configuration du module dans le logement apparaît toujours. Ce problème est le résultat de la conception qui permet un remplacement plus facile du module. Si vous insérez le même type de module dans le logement, le commutateur utilise les configurations du module qui se trouvait précédemment dans le logement. Si vous insérez un autre type de module dans le logement, la configuration du module est effacée. Afin de supprimer la configuration automatiquement une fois qu'un module est sorti d'un logement, émettez la commande module clear-config du mode de configuration globale. Assurez-vous d'exécuter la commande avant que les modules ne soient retirés du logement. La commande n'efface pas les anciennes configurations des modules qui avaient déjà été retirés du logement. Cette commande efface la configuration du module du résultat de la commande show running-config et les détails de l'interface du résultat de la commande show ip interface brief. Dans les versions 12.2(18)SXF et ultérieures de Cisco IOS, il supprime également le nombre de types d'interface de la commande show version.
Si votre commutateur a été réinitialisé seul sans intervention manuelle, suivez ces étapes afin d'identifier le problème :
Le commutateur peut avoir eu une panne de logiciel. Émettez la commande dir bootflash: qui affiche le périphérique bootflash MSFC (processeur de routage [RP]) et la commande dir slavebootflash: afin de vérifier qu'il n'y a pas de panne logicielle.
Le résultat dans cette section montre que crashinfo a été enregistré dans le bootflash du RP : . Assurez-vous que les informations de panne que vous affichez correspondent à la panne la plus récente. Émettez la commande more bootflash:filename afin d'afficher le fichier crashinfo. Dans cet exemple, la commande est more bootflash:crashinfo_20020829-12340.
cat6knative#dir bootflash:
Directory of bootflash:/
1 -rw- 1693168 Jul 24 2002 15:48:22 c6msfc2-boot-mz.121-8a.EX
2 -rw- 183086 Aug 29 2002 11:23:40 crashinfo_20020829-112340
3 -rw- 20174748 Jan 30 2003 11:59:18 c6sup22-jsv-mz.121-8b.E9
4 -rw- 7146 Feb 03 2003 06:50:39 test.cfg
5 -rw- 31288 Feb 03 2003 07:36:36 01_config.txt
6 -rw- 30963 Feb 03 2003 07:36:44 02_config.txt
31981568 bytes total (9860396 bytes free)
La commande dir sup-bootflash : affiche le bootflash du Supervisor Engine : périphérique. Vous pouvez également émettre la commande dir slavesup-bootflash: afin d'afficher le bootflash du Supervisor Engine de secours : périphérique. Ce résultat montre crashinfo enregistré dans le bootflash du Supervisor Engine : périphérique:
cat6knative11#dir sup-bootflash:
Directory of sup-bootflash:/
1 -rw- 14849280 May 23 2001 12:35:09 c6sup12-jsv-mz.121-5c.E10
2 -rw- 20176 Aug 02 2001 18:42:05 crashinfo_20010802-234205
!--- Output suppressed.
Si le résultat de la commande indique qu'une panne logicielle s'est produite au moment où vous soupçonniez que le commutateur a redémarré, contactez le support technique Cisco. Fournissez le résultat de la commande show tech-support et de la commande show logging, ainsi que le résultat du fichier crashinfo. Pour envoyer le fichier, transférez-le via TFTP du commutateur vers un serveur TFTP et joignez le fichier au boîtier.
S'il n'y a pas de fichier crashinfo, vérifiez la source d'alimentation du commutateur pour vous assurer qu'il n'a pas échoué. Si vous utilisez une alimentation sans coupure (UPS), assurez-vous qu'elle fonctionne correctement. Si vous ne parvenez toujours pas à identifier le problème, contactez le centre d'escalade du support technique Cisco.
Si un module équipé d'une carte DFC a été réinitialisé seul sans rechargement par l'utilisateur, vérifiez le bootflash de la carte DFC pour voir s'il s'est écrasé. Si un fichier d'informations de panne est disponible, vous pouvez trouver la cause de la panne. Émettez la commande dir dfc#module_#-bootflash: afin de vérifier s'il y a un fichier d'information de panne et quand il a été écrit. Si la réinitialisation DFC correspond à l'horodatage crashinfo, émettez la commande more dfc#module_#-bootflash:filename. Ou émettez la commande copy dfc#module_#-bootflash:filename tftp afin de transférer le fichier via TFTP vers un serveur TFTP.
cat6knative#dir dfc#6-bootflash: Directory of dfc#6-bootflash:/ -#- ED ----type---- --crc--- -seek-- nlen -length- -----date/time------ name 1 .. crashinfo 2B745A9A C24D0 25 271437 Jan 27 2003 20:39:43 crashinfo_ 20030127-203943
Une fois que vous avez le fichier crashinfo disponible, collectez le résultat de la commande show logging et de la commande show tech et contactez l'assistance technique Cisco pour obtenir de l'aide.
Cette section décrit les raisons courantes pour lesquelles l'un des modules peut ne pas être mis en ligne et explique comment résoudre le problème. Vous pouvez déterminer qu'un module ne se met pas en ligne de l'une des manières suivantes :
Le résultat de la commande show module montre l'un de ces états :
other (autre)
inconnu
défectueux
errdisable
power-deny
power-bad
L'état ambre ou rouge de la LED est allumé.
Consultez la section Matériel pris en charge des Notes de version de la gamme Catalyst 6500 de la version concernée. Si le module n'est pas pris en charge par le logiciel que vous exécutez actuellement, téléchargez le logiciel requis depuis le Centre logiciel Cisco IOS.
Si l'état est power-deny, le commutateur n'a pas assez d'énergie disponible pour alimenter ce module. Émettez la commande show power afin de confirmer si assez de puissance est disponible. Consultez la section Dépanner les messages d'erreur C6KPWR-4-POWRDENIED : insufficient power, module in slot [dec] power denied ou %C6KPWR-SP-4-POWRDENIED : alimentation insuffisante, module dans le logement [dec] alimentation refusée section Messages d'erreur de ce document.
Si l'état est power-bad, le commutateur peut voir une carte, mais ne peut pas allouer d'énergie. Cela est possible si le Supervisor Engine n'est pas en mesure d'accéder au contenu de la mémoire SPROM (Serial PROM) sur le module afin de déterminer l'identification de la carte de ligne. Vous pouvez émettre la commande show idprom module afin de vérifier si la SPROM est lisible. Si la mémoire SPROM n'est pas accessible, vous pouvez réinitialiser le module.
Assurez-vous que le module est correctement inséré et vissé. Si le module n'est toujours pas en ligne, émettez la commande de configuration globale diagnostic boot level complete afin de vous assurer que le diagnostic est activé. Ensuite, exécutez la commande hw-module module <slot_number> reset. Si le module n'est toujours pas en ligne, inspectez le connecteur de fond de panier sur le module pour vous assurer qu'il n'est pas endommagé. S'il n'y a aucun dommage visuel, essayez le module dans un autre logement ou dans un autre châssis. En outre, inspectez les broches coudées sur le connecteur de l'emplacement sur le fond de panier. Utilisez une lampe-torche s'il y a lieu, quand vous inspectez les broches de connecteur sur le fond du panier du châssis.
Émettez la commande show diagnostics module <slot_number>afin d'identifier les défaillances matérielles sur le module. Émettez la commande de configuration globale diagnostic boot level complete afin d'activer les diagnostics complets. Les diagnostics complets doivent être activés pour que le commutateur puisse effectuer des diagnostics sur le module. Si les diagnostics minimaux sont activés et que vous passez aux diagnostics complets, le module doit être réinitialisé afin que le commutateur puisse effectuer les diagnostics complets. L'exemple de sortie dans cette section émet la commande show diagnostics module. Mais le résultat n'est pas concluant parce que beaucoup de tests ont été effectués en mode minimal. Le résultat montre comment activer le niveau de diagnostic, puis émettre à nouveau la commande show diagnostics module afin de voir les résultats complets.
Note: Les convertisseurs d'interface Gigabit (GBIC) n'ont pas été installés dans le module d'exemple. Par conséquent, les tests d'intégrité n'ont pas été réalisés. Le test d'intégrité GBIC est effectué uniquement sur les GBIC cuivre (WS-G5483= ).
cat6native#show diagnostic module 3
Current Online Diagnostic Level = Minimal
Online Diagnostic Result for Module 3 : PASS
Online Diagnostic Level when Module 3 came up = Minimal
Test Results: (. = Pass, F = Fail, U = Unknown)
1 . TestGBICIntegrity :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
----------------------------------------------------
U U U U U U U U U U U U U U U U
2 . TestLoopback :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
----------------------------------------------------
. . . . . . . . . . . . . . . .
3 . TestDontLearn : U
4 . TestConditionalLearn : .
5 . TestStaticEntry : U
6 . TestCapture : U
7 . TestNewLearn : .
8 . TestIndexLearn : U
9 . TestTrap : U
10. TestIpFibShortcut : .
11. TestDontShortcut : U
12. TestL3Capture : U
13. TestL3VlanMet : .
14. TestIngressSpan : .
15. TestEgressSpan : .
16. TestAclPermit : U
17. TestAclDeny : U
18. TestNetflowInlineRewrite :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
----------------------------------------------------
U U U U U U U U U U U U U U U U
!--- Tests that are marked "U" were skipped because a minimal
!--- level of diagnostics was enabled.
cat6knative#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
cat6knative(config)#diagnostic bootup level complete
!--- This command enables complete diagnostics.
cat6knative(config)#end
cat6knative#
*Feb 18 13:13:03 EST: %SYS-5-CONFIG_I: Configured from console by console
cat6knative#
cat6knative#hw-module module 3 reset
Proceed with reload of module? [confirm]
% reset issued for module 3
cat6knative#
*Feb 18 13:13:20 EST: %C6KPWR-SP-4-DISABLED: power to module in slot 3 set off
(Reset)
*Feb 18 13:14:12 EST: %DIAG-SP-6-RUN_COMPLETE: Module 3: Running Complete Online
Diagnostics...
*Feb 18 13:14:51 EST: %DIAG-SP-6-DIAG_OK: Module 3: Passed Online Diagnostics
*Feb 18 13:14:51 EST: %OIR-SP-6-INSCARD: Card inserted in slot 3, interfaces
are now online
cat6knative#show diagnostic module 3
Current Online Diagnostic Level = Complete
Online Diagnostic Result for Module 3 : PASS
Online Diagnostic Level when Module 3 came up = Complete
Test Results: (. = Pass, F = Fail, U = Unknown)
1 . TestGBICIntegrity :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
----------------------------------------------------
U U U U U U U U U U U U U U U U
!--- The result for this test is unknown ("U", untested)
!--- because no copper GBICS are plugged in.
2 . TestLoopback :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
----------------------------------------------------
. . . . . . . . . . . . . . . .
3 . TestDontLearn : .
4 . TestConditionalLearn : .
5 . TestStaticEntry : .
6 . TestCapture : .
7 . TestNewLearn : .
8 . TestIndexLearn : .
9 . TestTrap : .
10. TestIpFibShortcut : .
11. TestDontShortcut : .
12. TestL3Capture : .
13. TestL3VlanMet : .
14. TestIngressSpan : .
15. TestEgressSpan : .
16. TestAclPermit : .
17. TestAclDeny : .
18. TestNetflowInlineRewrite :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
----------------------------------------------------
. . . . . . . . . . . . . . . .
Émettez la commande show tech-support et la commande show logging. Recherchez tout autre message relatif à ce module afin de poursuivre le dépannage.
Si le module n'est toujours pas en ligne, créez une demande de service avec l'assistance technique Cisco afin de poursuivre le dépannage. Fournissez le journal de la sortie du commutateur que vous avez collectée et les informations des étapes précédentes.
Les Supervisor Engines peuvent lancer des messages qui indiquent un échec de communication intrabande. Les messages consignés par le commutateur ressemblent à ceux-ci :
InbandKeepAliveFailure:Module 1 not responding over inband InbandKeepAlive:Module 2 inband rate: rx=0 pps, tx=0 pps ProcessStatusPing:Module 1 not responding over SCP ProcessStatusPing:Module 1 not responding... resetting module
Lorsque l'interface de gestion du commutateur traite un trafic important, des messages d'erreur InbandKeepAliveFailure apparaissent dans les journaux du commutateur. Cela peut être dû aux raisons suivantes :
Supervisor Engine occupé
Boucle de spanning-tree protocol
Les listes de contrôle d’accès et les contrôleurs QoS ont limité ou abandonné le trafic sur le canal de communication intrabande
Problèmes de synchronisation de Port ASIC
Problèmes de modules de matrice de commutation
Afin de résoudre le problème, suivez ces instructions :
Utilisez show process cpu , pour déterminer quel processus cause ce problème. Référez-vous à Utilisation CPU élevée du commutateur Catalyst 6500/6000 pour effacer la cause racine.
Un module de supervision mal positionné ou défectueux peut émettre ces messages d'échec de communication. Afin de récupérer à partir de ces messages d'erreur, planifiez une fenêtre de maintenance et réinstallez le module de supervision.
Un commutateur Cisco Catalyst 6500/6000 qui exécute le logiciel Cisco IOS peut sembler se recharger pour la raison suivante :
System returned to ROM by power-on (SP by abort)
Un commutateur Catalyst 6500/6000 avec un registre de configuration SP qui autorise l’interruption, par exemple 0x2, et qui reçoit un signal d’interruption de console passe en mode de diagnostic ROMmon. Le système tombe en panne. Une non-correspondance des paramètres du registre de configuration sur SP et RP peut entraîner ce type de rechargement. Plus précisément, vous pouvez définir le registre de configuration du processeur de commutation du Supervisor Engine (SP) sur une valeur qui n'ignore pas break, tandis que le registre de configuration du processeur de routage (RP) de la carte MSFC (Multilayer Switch Feature Card) est une valeur correcte qui ne ignore pas break. Par exemple, vous pouvez définir le SP du Supervisor Engine sur 0x2 et le RP MSFC sur 0x2102. Pour plus d'informations, référez-vous à Réinitialisations de Cisco IOS Catalyst 6500/6000 avec l'erreur "Système retourné à la ROM par la mise sous tension (SP par abandon)".
Un commutateur Cisco Catalyst 6500/6000 qui exécute le logiciel Cisco IOS amorce l'ancienne image dans le disque de démarrage secondaire, quelle que soit la configuration de la variable BOOT dans la configuration en cours. Bien que la variable BOOT soit configurée pour démarrer à partir de la mémoire flash externe, elle démarre uniquement l'ancienne image dans le sup-bootdisk. La cause de ce problème est la non-correspondance des paramètres du registre de configuration sur SP et RP.
Dans le RP, émettez la commande show bootvar.
Switch#show boot BOOT variable = sup-bootdisk:s72033-advipservicesk9_wan-mz.122-18.SXF7.bin,1; CONFIG_FILE variable = BOOTLDR variable = Configuration register is 0x2102
Dans le SP, émettez la commande show bootvar.
Switch-sp#show boot BOOT variable = bootdisk:s72033-advipservicesk9_wan-mz.122-18.SXF7.bin,1; CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x2101
Ceci amène le commutateur à démarrer l'image précédente indépendamment de la configuration de variable BOOT dans la configuration en cours. Afin de résoudre ce problème, émettez la commande switch(config)#config-register 0x2102, puis confirmez que le SP et le RP ont la même valeur config-register. Rechargez le commutateur après avoir écrit la configuration dans la configuration initiale.
Ce message d'erreur indique que le NVRAM a des problèmes. Si vous effacez la mémoire vive non volatile et rechargez le commutateur, celui-ci peut récupérer la mémoire vive non volatile. Si cela ne résout pas le problème, formatez la mémoire vive non volatile afin de résoudre le problème. Dans les deux cas, il est recommandé de disposer d’une sauvegarde du contenu de la mémoire vive non volatile. Ce message d'erreur s'affiche uniquement lorsque le débogage NVRAM est activé.
Le message d'erreur CRIT_ERR_DETECTED Module 7 - Error: Le compteur FIFO du bus de commutation coincé indique que le module n'a pas vu d'activité sur le bus de commutation de données. La raison de cette erreur peut être que le module nouvellement inséré n'a pas été inséré fermement dans le châssis initialement ou a été inséré trop lentement.
Réinstallez le module afin de résoudre le problème.
Le cluster vss Catalyst 6500 rencontre ce message d'erreur :
%CONST_DIAG-4-ERROR_COUNTER_WARNING: Module [dec] Error counter exceeds threshold, system operation continue.
TestErrorCounterMonitor a détecté qu'un compteur d'erreurs dans le module spécifié a dépassé un seuil. Des données spécifiques sur le compteur d'erreurs peuvent être envoyées dans un message système distinct. TestErrorCounterMonitor est un processus d'arrière-plan de surveillance de l'état sans interruption qui interroge régulièrement les compteurs d'erreurs et d'interruptions de chaque carte de ligne ou module de supervision du système.
%CONST_DIAG-4-ERROR_COUNTER_DATA: ID:[dec] IN:[dec] PO:[dec] RE:[dec] RM:[dec] DV:[dec] EG:[dec] CF:[dec] TF:[dec]
TestErrorCounterMonitor a détecté qu'un compteur d'erreurs dans le module spécifié a dépassé un seuil. Ce message contient des données spécifiques sur le compteur d'erreurs, ainsi que des informations sur l'ASIC et le registre du compteur, et le nombre d'erreurs.
Ce message d'erreur est reçu 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.
Exemple :
%CONST_DIAG-SW1_SP-4-ERROR_COUNTER_WARNING: Module 2 Error counter exceeds threshold, system operation continue.
La raison de cette erreur peut être que le module nouvellement inséré n'a pas été correctement inséré. Réinstallez le module afin de résoudre le problème.
Ce message d'erreur est reçu lorsque le nombre maximal de blocs de descripteurs d'interface logicielle (SWIDB) est atteint :
%INTERFACE_API-SP-1-NOMORESWIDB : Aucun autre SWIDB ne peut être alloué, maximum autorisé 12000
Référez-vous à Nombre maximal d'interfaces et de sous-interfaces pour les plates-formes Cisco IOS : Limites BID pour plus d'informations sur les limites BID.
Lorsque vous essayez de convertir une interface non-switchport en port de commutation, une erreur est renvoyée.
Switch(config)#interface gigabit ethernet 7/29
Switch(config-if)#switchport
%Command rejected: Cannot convert port.
Maximum number of interfaces reached.
Output of idb:
AMC440E-SAS01#show idb
Maximum number of Software IDBs 12000. In use 11999.
HWIDBs SWIDBs
Active 218 220
Inactive 11779 11779
Total IDBs 11997 11999
Size each (bytes) 3392 1520
Total bytes 40693824 18238480
Cet exemple montre que le nombre Total IDBs (sous la colonne SWIDBs) a atteint le nombre maximal de IDBs limite. Lorsque vous supprimez une sous-interface, les nombres Active et Inactive dans la colonne SWIDBs changent ; Cependant, le nombre total d'IDB reste dans la mémoire. Afin de résoudre ce problème, rechargez le commutateur pour effacer la base de données IDB. Sinon, une fois que vous avez terminé, vous devez réutiliser les sous-interfaces supprimées.
Un message d'erreur similaire est signalé lorsque le commutateur Cisco Catalyst 6500 ne démarre pas avec une version du logiciel Cisco IOS spécifiée.
00:00:56: %SYS-SP-2-MALLOCFAIL: Memory allocation of 2177024 bytes failed from 0x40173D8C, alignment 8 Pool: Processor Free: 1266272 Cause: Not enough free memory Alternate Pool: None Free: 0 Cause: No Alternate pool -Process= "TCAM Manager process", ipl= 0, pid= 112 -Traceback= 4016F4D0 40172688 40173D94 40577FF8 4055DB04 4055DEDC SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE! %Software-forced reload
Ce problème se produit généralement lorsqu'il n'y a pas assez de DRAM disponible pour décompresser l'image dans Flash.
Afin de résoudre ce problème, exécutez une de ces options :
Mettez à jour la DRAM.
Reportez-vous à la section Mémoire requise (exemple 4) de Comment choisir une version du logiciel Cisco IOS. Cela calcule la quantité de DRAM requise pour votre image.
Chargez une image appropriée compte tenu de la taille de la mémoire actuelle.
Afin de déterminer le type de superviseur installé sur votre Catalyst 6500/6000, consultez Comment déterminer le type de module de superviseur qui est installé dans les commutateurs de la gamme Catalyst 6500/6000.
Afin de connaître les options de mémoire par défaut disponibles dans Catalyst 6500/6000, référez-vous à Taille de mémoire/flash prise en charge dans les plates-formes de commutateur Catalyst.
Afin de choisir et télécharger le logiciel approprié, utilisez la page Téléchargements - Commutateurs (clients enregistrés seulement).
Lorsque vous utilisez les modules WS-X6548-GE-TX ou WS-X6148-GE-TX, il est possible que l'utilisation de ports individuels entraîne des problèmes de connectivité ou la perte de paquets sur les interfaces environnantes. En particulier lorsque vous utilisez EtherChannel et Remote Switched Port Analyzer (RSPAN) dans ces cartes de ligne, vous pouvez potentiellement voir la réponse lente due à la perte de paquets. Ces cartes de ligne sont des cartes de surabonnement conçues pour étendre le gigabit au bureau et non idéales pour la connectivité de la batterie de serveurs. Sur ces modules, il existe une liaison ascendante de 1 Gigabit Ethernet unique à partir du port ASIC prenant en charge huit ports. Ces cartes partagent une mémoire tampon de 1 Mo entre un groupe de ports (1-8, 9-16, 17-24, 25-32, 33-40 et 41-48) puisque chaque bloc de huit ports est surabonné 8:1. Le débit cumulé de chaque bloc de huit ports ne peut pas dépasser 1 GBPs. Le tableau 4 des modules d'interface Ethernet 10/100 et 10/100/1000 Mbits/s de la gamme Cisco Catalyst 6500 indique les différents types de modules d'interface Ethernet et la taille de tampon prise en charge par port.
Un surabonnement se produit en raison de plusieurs ports combinés dans un seul ASIC Pinnacle. L'ASIC Pinnacle est un moteur d'accès direct à la mémoire (DMA) qui transfère les paquets entre le bus de commutation du fond de panier et les ports réseau. Si un port de cette plage reçoit ou transmet du trafic à un débit qui dépasse sa bande passante ou utilise une grande quantité de tampons pour gérer des rafales de trafic, les autres ports de la même plage peuvent potentiellement subir une perte de paquets.
Une destination SPAN est une cause très courante puisqu'il n'est pas rare de copier le trafic d'un VLAN entier ou de plusieurs ports vers une seule interface. Sur une carte avec des tampons d'interface individuels, les paquets qui dépassent la bande passante du port de destination sont silencieusement abandonnés et aucun autre port n'est affecté. Avec une mémoire tampon partagée, cela entraîne des problèmes de connectivité pour les autres ports de cette plage. Dans la plupart des cas, les mémoires tampons partagées ne posent pas de problème. Même avec huit stations de travail connectées gigabit, il est rare que la bande passante fournie soit dépassée.
Le commutateur peut subir une dégradation des services lorsque vous configurez la fonctionnalité SPAN locale dans un commutateur, en particulier s'il surveille une grande quantité de ports source. Ce problème persiste s'il surveille certains VLAN et si un grand nombre de ports est attribué à l'un de ces VLAN.
Même si la fonctionnalité SPAN est exécutée sur le matériel, elle a un impact sur les performances, car le commutateur transporte désormais deux fois plus de trafic. Chaque carte de ligne répliquant le trafic en entrée, chaque fois qu'un port est surveillé, tout le trafic en entrée est doublé lorsqu'il atteint le fabric. La capture du trafic d'un grand nombre de ports occupés sur une carte de ligne peut remplir la connexion de fabric, en particulier avec les cartes WS-6548-GE-TX, qui n'ont qu'une connexion de fabric 8 Gigabit.
Les modules WS-X6548-GE-TX, WS-X6548V-GE-TX, WS-X6148-GE-TX et WS-X6148V-GE-TX ont une limitation concernant l’EtherChannel. Pour l’EtherChannel, les données de tous les liens dans un lot vont vers le port ASIC, même si les données sont destinées à un autre lien. Ces données consomment la bande passante dans le lien de 1 Gigabit Ethernet. Pour ces modules, la capacité totale de toutes les données sur un module EtherChannel ne peut pas dépasser 1 Go.
Vérifiez ce résultat afin de vérifier que le module subit des pertes liées à des mémoires tampon surutilisées :
Cisco IOS natif
Cat6500# show counters interface gigabitEthernet <mod/port> | include qos3Outlost
51. qos3Outlost = 768504851
Exécutez les commandes show plusieurs fois pour vérifier si asicreg augmente régulièrement. Les sorties asicreg sont effacées à chaque exécution. Si les sorties asicreg restent non-nulles alors cela indique des abandons actifs. En fonction du débit du trafic, ces données doivent être collectées sur plusieurs minutes afin d'obtenir des incréments significatifs.
Procédez comme suit :
Isolez tous les ports qui sont constamment surabonnés à leur propre plage de ports afin de minimiser l'impact des abandons vers d'autres interfaces.
Par exemple, si vous avez un serveur connecté au port 1 qui est oversubscribing l'interface, cela peut entraîner une réponse lente si plusieurs autres serveurs sont connectés aux ports compris entre 2 et 8. Dans ce cas, déplacez le oversubscribing serveur au port 9 afin de libérer la mémoire tampon dans le premier bloc des ports 1 à 8. Sur les versions logicielles plus récentes, la mémoire tampon des destinations SPAN est automatiquement déplacée vers l’interface, de sorte qu’elle n’a pas d’impact sur les autres ports de sa plage. ID de bogue Cisco CSCin70308 (accessible uniquement aux clients Cisco enregistrés) pour plus d’informations.
Désactivez le blocage de tête de ligne (HOL) qui utilise les tampons d'interface au lieu des tampons partagés.
Cela entraîne des pertes à partir du seul port surutilisé uniquement. Comme les tampons d'interface (32 k) sont sensiblement plus petits que le tampon partagé de 1 Mo, il peut y avoir plus de pertes de paquets sur les ports individuels. Ceci n'est recommandé que dans les cas extrêmes où les clients plus lents ou les ports SPAN ne peuvent pas être déplacés vers les autres cartes de ligne qui offrent des tampons d'interface dédiés.
Cisco IOS natif
Router(config)# interface gigabitethernet <mod/port>
Router(config-if)# désactivation du blocage des trous
Une fois cette option désactivée, les abandons se déplacent vers les compteurs d'interface et peuvent être vus avec la commande show interface gigabit <mod/port>. Les autres ports ne sont plus affectés, à condition qu'ils ne le soient pas individuellement bursting . Comme il est recommandé de maintenir le blocage HOL activé, ces informations peuvent être utilisées pour trouver le périphérique qui dépasse les tampons sur la plage de ports et le déplacer vers une autre carte ou une plage isolée sur la carte afin que le blocage HOL puisse être réactivé.
Lorsque vous configurez une session SPAN, assurez-vous que le port de destination ne signale aucune erreur sur cette interface spécifique. Afin de vérifier toutes les erreurs possibles sur le port de destination, vérifiez le résultat de la commande show interface <type d'interface> <numéro d'interface> pour Cisco IOS pour voir s'il y a des pertes de sortie ou des erreurs. Le périphérique connecté au port de destination et le port lui-même doivent avoir les mêmes paramètres de vitesse et de duplex pour éviter toute erreur sur le port de destination.
Envisagez de passer à des modules Ethernet sans ports en sursouscription. Référez-vous à Commutateurs de la gamme Cisco Catalyst 6500 - Interfaces et modules pertinents pour plus d'informations sur les modules pris en charge.
Les protocoles exécutés sur le commutateur peuvent introduire un délai de connectivité initial. Il est possible que vous rencontriez ce problème si vous observez l'un des symptômes suivants lorsque vous mettez sous tension ou redémarrez une machine client :
A Microsoft networking Le client affiche Aucun contrôleur de domaine disponible .
Un DHCP indique No DHCP Servers Available.
Un poste de travail de mise en réseau Novell Internetwork Packet Exchange (IPX) n'a pas l'écran d'ouverture de connexion Novell au démarrage.
Un AppleTalk networking Le client affiche L'accès à votre réseau AppleTalk a été interrompu. Pour rétablir votre connexion, ouvrez puis fermez votre panneau de configuration AppleTalk. Il est également possible que le sélecteur du client AppleTalk n'affiche pas de liste de zone ou affiche une liste de zone incomplète.
Les postes IBM Network peuvent afficher l'un de ces messages :
NSB83619--Address resolution failed
NSB83589--Failed to boot after 1 attempt
NSB70519--Failed to connect to a server
Le délai d’interface peut entraîner les symptômes suivants : la section Station de travail ne peut pas se connecter au réseau pendant le démarrage/Impossible d’obtenir les listes d’adresses DHCP. Voici les causes courantes du retard d’interface :
Retard de spanning-tree protocol (STP)
Retard d'EtherChannel
Retard de liaison de jonction
Délai de négociation automatique
Pour plus d'informations sur ces retards et les solutions possibles, référez-vous à Utilisation de PortFast et d'autres commandes pour corriger les retards de connectivité de démarrage de station de travail.
Si vous rencontrez toujours des problèmes après avoir vérifié et suivi la procédure, contactez le support technique Cisco.
Vous pouvez rencontrer des problèmes de compatibilité ou de configuration incorrecte de la carte réseau (NIC) avec le commutateur si vous rencontrez l'un des problèmes suivants :
Aucune connexion serveur/client au commutateur ne s'établit.
Vous avez des problèmes de négociation automatique.
Vous voyez des erreurs sur le port.
La raison de ces symptômes peut être :
Un problème connu de pilote NIC
Speed-duplex mismatch
Problèmes de négociation automatique
Problèmes de câble
Afin de dépanner plus loin, référez-vous à Dépannage des problèmes de compatibilité des commutateurs Cisco Catalyst avec les cartes réseau.
Si l'état de l'interface est errdisable dans le résultat de la commande show interface status, l'interface a été désactivée en raison d'une condition d'erreur. Voici un exemple de l'interface dans l'état errdisable :
cat6knative#show interfaces gigabitethernet 4/1 status Port Name Status Vlan Duplex Speed Type Gi4/1 err-disabled 100 full 1000 1000BaseSX
Vous pouvez également voir des messages similaires à ceux-ci si l'interface a été désactivée en raison d'une condition d'erreur :
%SPANTREE-SP-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet4/1 with BPDU Guard enabled. Disabling port. %PM-SP-4-ERR_DISABLE: bpduguard error detected on Gi4/1, putting Gi4/1 in err-disable state
Cet exemple de message s'affiche lorsque l'unité BPDU (Bridge Protocol Data Unit) est reçue sur un port hôte. Le message réel dépend de la raison de la condition d'erreur.
Il y a diverses raisons du passage de l'interface dans l'état errdisable. La raison peut être l'une des suivantes :
Non-correspondance de mode duplex
Configuration incorrecte du canal de port
Violation de la protection BPDU
condition UDLD
Détection de collisions tardives
Détection d'affolement de liaison
Violation de la sécurité
Affolement du protocole d'agrégation de ports (PAgP)
Protection du protocole L2TP (Layer 2 Tunneling Protocol)
Limite du taux de surveillance DHCP
Afin d'activer un port errdisabled, procédez comme suit:
Débranchez le câble à l'une des extrémités de la connexion.
Reconfigurez les interfaces.
Par exemple, si les interfaces sont dans un état errdisabled en raison d'une configuration incorrecte d'Etherchannel, reconfigurez les plages d'interfaces pour l'Etherchannel.
Arrêtez les ports aux deux extrémités.
Branchez les câbles aux deux commutateurs.
Exécutez la commande no shutdown sur les interfaces.
Vous pouvez également émettre la commande errdisable recovery cause cause enable afin de configurer des mécanismes de délai d'attente qui réactivent automatiquement le port après une période de minuteur configurée.
Note: La condition d'erreur se reproduit si vous ne résolvez pas la cause première du problème.
Afin de déterminer la raison de l'état errdisable, émettez la commande show errdisable recovery.
cat6knative#show errdisable recovery ErrDisable Reason Timer Status ----------------- -------------- udld Enabled bpduguard Enabled security-violatio Enabled channel-misconfig Enabled pagp-flap Enabled dtp-flap Enabled link-flap Enabled l2ptguard Enabled psecure-violation Enabled Timer interval: 300 seconds Interfaces that will be enabled at the next timeout: Interface Errdisable reason Time left(sec) --------- ----------------- -------------- Gi4/1 bpduguard 270
Une fois que vous connaissez la cause de l'errdisable, dépannez le problème et corrigez la racine du problème. Par exemple, votre port peut être en errdisable en raison de la réception d'une BPDU sur un port d'accès activé PortFast, comme dans l'exemple. Vous pouvez déterminer si un commutateur a été accidentellement connecté à ce port ou si un concentrateur connecté a créé une condition de bouclage. Afin de dépanner d'autres scénarios, référez-vous aux informations de fonctionnalité spécifiques dans la documentation du produit. Référez-vous à Récupération de l'état des ports Errdisable sur les plates-formes Cisco IOS pour des informations plus complètes sur l'état errdiable. Si vous avez encore des problèmes après avoir examiné et dépanné sur la base de ces informations, contactez le support technique Cisco pour une assistance supplémentaire.
Si vous voyez des erreurs dans le résultat de la commande show interface, vérifiez l'état et l'intégrité de l'interface qui rencontre les problèmes. Contrôlez également si le trafic passe à travers l'interface. Reportez-vous à l'étape 12 de Dépannage de la connectivité des ports du module WS-X6348 sur un Catalyst 6500/6000 exécutant le logiciel système Cisco IOS.
cat6knative#show interfaces gigabitethernet 1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0001.6416.042a (bia 0001.6416.042a)
Description: L2 FX Trunk to tpa_data_6513_01
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex mode, link type is autonegotiation, media type is SX
output flow-control is unsupported, input flow-control is unsupported, 1000Mb/s
Clock mode is auto
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:28, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 118000 bits/sec, 289 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
461986872 packets input, 33320301551 bytes, 0 no buffer
Received 461467631 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 137 overrun, 0 ignored
0 input packets with dribble condition detected
64429726 packets output, 4706228422 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
cat6knative#
En outre, vous pouvez voir des erreurs dans le résultat de la commande show interfaces <interface-id> counters errors. Si oui, vérifiez les erreurs qui sont associées à l'interface. Reportez-vous à l'étape 14 de Dépannage de la connectivité des ports du module WS-X6348 sur un Catalyst 6500/6000 exécutant le logiciel système Cisco IOS.
cat6knative#show interfaces gigabitethernet 3/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi3/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Gi3/1 0 0 0 0 0 0 0 Port SQETest-Err Deferred-Tx IntMacTx-Err IntMacRx-Err Symbol-Err Gi3/1 0 0 0 0 0
La raison pour laquelle l’interface affiche des erreurs peut être des problèmes de couche physique, tels que :
Cable/NIC défectueux
Problèmes de configuration, tels qu'une non-concordance de débit-duplex
Problèmes de performances, tels que la sursouscription
Afin de comprendre et de dépanner ces problèmes, référez-vous à Dépannage des problèmes de port et d'interface de commutateur.
Parfois, les compteurs d'erreurs sont incrémentés de manière incorrecte en raison d'un bogue logiciel ou d'une limitation matérielle. Ce tableau répertorie certains des problèmes de compteur connus avec la plate-forme Catalyst 6500/6000 qui exécute le logiciel Cisco IOS :
Note: Seuls les clients Cisco enregistrés peuvent accéder aux sites internes et aux informations de bogue.
| Symptôme | Description | Régler |
|---|---|---|
| Géants sur les interfaces d'agrégation IEEE 802.1Q sur les commutateurs basés sur Supervisor Engine 720. | Un commutateur de la gamme Catalyst 6500 peut signaler des géants pour des tailles de paquets supérieures à 1496 octets et qui sont reçus étiquetés sur une agrégation sur les ports du Supervisor Engine 720. Vous pouvez également voir cette question sur les cartes de ligne 67xx. Le problème est cosmétique, et le commutateur transmet les paquets. Le problème se produit également avec les liaisons ISL1. Référez-vous à ID de bogue Cisco CSCec62587 et ID de bogue Cisco CSCed42859 pour plus de détails. | Logiciel Cisco IOS Version 12.2(17b)SXA et ultérieure Logiciel Cisco IOS Version 12.2(18)SXD et ultérieure |
| Géants sur les interfaces d'agrégation 802.1Q sur les commutateurs basés sur Supervisor Engine 2. | Le commutateur compte les paquets compris entre 1497 et 1500 sur un VLAN non natif sur le port trunk 802.1Q comme des paquets géants. Il s’agit d’un problème d’ordre esthétique, et les paquets sont transférés par le commutateur. Référez-vous à l'ID de bogue Cisco CSCdw04642 pour plus de détails. | Non actuellement disponible |
| Des compteurs de pertes de sortie excessifs sont visibles dans la sortie de commande show interface sur les interfaces Gigabit, même quand il y a de faibles conditions de trafic. | Des compteurs d'abandon de sortie excessifs sont visibles dans le résultat de la commande show interface sur les interfaces Gigabit quand il y a des conditions de trafic faible. Référez-vous à l'ID de bogue Cisco CSCdv86024 pour plus de détails. |
Logiciel Cisco IOS Version 12.1(8b)E12 et ultérieure Logiciel Cisco IOS Version 12.1(11b)E8 et ultérieure Logiciel Cisco IOS Version 12.1(12c)E1 et ultérieure Logiciel Cisco IOS Version 12.1(13)E1 et ultérieure |
| L'interface de canal de port a des statistiques incorrectes dans le résultat de la commande show interface pour les bps1 et pps2. | Lorsque vous utilisez le logiciel Cisco IOS et qu’un canal de port est défini sur deux ports Fast Ethernet et que le trafic est généré via le canal de port, les interfaces physiques disposent des statistiques de débit correctes. Cependant, les statistiques de l'interface du canal de port sont incorrectes. Référez-vous à l'ID de bogue Cisco CSCdw23826 pour plus de détails. | Logiciel Cisco IOS Version 12.1(8a)EX Logiciel Cisco IOS Version 12.1(11b)E1 Logiciel Cisco IOS Version 12.1(13)E1 |
1 ISL = liaison entre commutateurs.
2 bits/s = bits par seconde.
3 pps = paquets par seconde.
Si vous rencontrez encore des problèmes après avoir examiné et résolu les problèmes sur la base des documents mentionnés dans cette section, contactez le support technique Cisco pour obtenir de l'aide.
Les GBIC fonctionnant dans des versions de logiciel antérieures à la version 12.1(13)E du logiciel Cisco IOS échouent après la mise à niveau.
Avec le logiciel système Cisco IOS Version 12.1(13), les ports avec des GBIC dont la somme de contrôle GBIC EEPROM est incorrecte ne sont pas autorisés à s'afficher. Il s'agit du comportement attendu pour les GBIC 1000BASE-TX (cuivre) et CWDM (Coarse Wave Division Multiplexer). Cependant, le comportement est incorrect pour d'autres GBIC. Avec les versions précédentes, les ports avec les autres GBIC qui avaient des erreurs de somme de contrôle étaient autorisés à apparaître.
Ce message d'erreur est imprimé lorsque cette erreur se produit dans le logiciel Cisco IOS Version 12.1(13)E :
%PM_SCP-SP-3-GBIC_BAD: GBIC integrity check on port 1/2 failed: bad key
Émettez la commande show interface afin d'afficher cette sortie :
Router#show interface status Port Name Status Vlan Duplex Speed Type Gi2/1 faulty routed full 1000 bad EEPROM
Ce problème peut être résolu dans les versions du logiciel Cisco IOS 12.1(13)E1, 12.1(14)E et ultérieures.
Pour plus de détails sur ce problème, reportez-vous à la notice de champ : Erreurs GBIC EEPROM incorrectes dans le logiciel Cisco IOS® version 12.1(13)E pour Catalyst 6000.
Vous pouvez voir un ou plusieurs des messages d'erreur suivants dans le résultat de la commande syslogs ou show log :
Coil Pinnacle Header Checksum
Coil Mdtif State Machine Error
Coil Mdtif Packet CRC Error
Coil Pb Rx Underflow Error
Coil Pb Rx Parity Error
Si vous rencontrez des problèmes de connectivité avec la connexion des hôtes sur le module WS-X6348 ou d'autres modules 10/100, ou si vous voyez des messages d'erreur similaires à ceux répertoriés dans cette section, et que vous avez un groupe de 12 ports qui sont bloqués et ne transmettent pas de trafic, procédez comme suit :
Désactivez et activez les interfaces.
Émettez la commande afin de réinitialiser le module.
Exécutez une de ces actions pour la réinitialisation matérielle du module :
Réinsérez physiquement la carte.
Exécutez la commande de configuration globale no power enable module module_# et la commande de configuration globale power enable module module_# .
Après avoir effectué ces étapes, contactez l'assistance technique Cisco avec les informations si vous rencontrez un ou plusieurs des problèmes suivants :
Le module n'est pas en ligne.
Le module est mis en ligne, mais un groupe de 12 interfaces échoue aux diagnostics.
Vous pouvez le voir dans le résultat de la commande show diagnostic module <module_number>.
Le module est bloqué dans l'autre état au démarrage.
Tous les LEDs du port sur le module deviennent ambres.
Toutes les interfaces sont à l'état errdisabled.
Vous pouvez le voir quand vous émettez la commande show interfaces status module_#.
Référez-vous à Dépannage de la connectivité des ports du module WS-X6348 sur un Catalyst 6500/6000 exécutant le logiciel système Cisco IOS pour plus de détails.
Si vous avez des problèmes de connectivité avec la connexion des hôtes sur le module WS-X6348 ou d'autres modules 10/100, référez-vous à Dépannage de la connectivité des ports du module WS-X6348 sur un Catalyst 6500/6000 exécutant le logiciel système Cisco IOS pour plus de détails. Si vous avez toujours des problèmes après avoir examiné et dépanné sur la base du document Dépannage de la connectivité des ports du module WS-X6348 sur un Catalyst 6500/60 0 En exécutant le logiciel système Cisco IOS, contactez le support technique Cisco pour obtenir de l'aide.
Les problèmes liés au Spanning Tree peuvent entraîner des problèmes de connectivité dans un réseau commuté. Pour obtenir des directives sur la façon d'empêcher les problèmes de Spanning Tree, référez-vous à Dépannage STP sur le commutateur Catalyst exécutant le logiciel système Cisco IOS .
Comme tous les périphériques Cisco IOS, le commutateur Catalyst 6500 autorise également un nombre limité de sessions Telnet. Si vous atteignez cette limite, le commutateur n’autorise plus de sessions vty. Afin de vérifier si vous rencontrez ce problème, connectez-vous à la console du Supervisor Engine. Émettez la commande show user. Le résultat de l'interface de ligne de commande (CLI) de cette commande indique le nombre de lignes actuellement occupées :
Cat6500#show user Line User Host(s) Idle Location 0 con 0 10.48.72.118 00:00:00 1 vty 0 10.48.72.118 00:00:00 10.48.72.118 2 vty 1 10.48.72.118 00:00:00 10.48.72.118 3 vty 2 10.48.72.118 00:00:00 10.48.72.118 4 vty 3 10.48.72.118 00:00:00 10.48.72.118 *5 vty 4 idle 00:00:00 10.48.72.118
Procédez comme suit :
Sur la base du résultat de la commande show user, émettez la commande clear line line_number afin d'effacer les sessions obsolètes.
Cat6500#show user Line User Host(s) Idle Location 0 con 0 10.48.72.118 00:00:00 1 vty 0 10.48.72.118 00:00:00 10.48.72.118 2 vty 1 10.48.72.118 00:00:00 10.48.72.118 3 vty 2 10.48.72.118 00:00:00 10.48.72.118 4 vty 3 10.48.72.118 00:00:00 10.48.72.118 *5 vty 4 idle 00:00:00 10.48.72.118 Cat6500#clear line 1 Cat6500#clear line 2 !--- Output suppressed.
Configurez le délai d'inactivité pour les sessions vty et la ligne de console afin d'effacer toutes les sessions inactives. Cet exemple montre la configuration à utiliser afin de définir le délai d'inactivité à 10 minutes :
Cat6500#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Cat6500(config)#line vty 0 4 Cat6500(config-line)#exec-timeout ? <0-35791> Timeout in minutes Cat6500(config-line)#exec-timeout 10 ? <0-2147483> Timeout in seconds <cr> Cat6500(config-line)#exec-timeout 10 0 Cat6500(config-line)#exit Cat6500(config)#line con 0 Cat6500(config-line)#exec-timeout 10 0 Cat6500(config-line)#exit Cat6500(config)#
Vous pouvez également augmenter le nombre de sessions vty disponibles. Utilisez la commande line vty 0 6 au lieu de line vty 0 4 .
Dans certains cas, la sortie de la commande show user peut afficher no active vty under sessions, mais une connexion au commutateur à l'aide de la commande telnet échoue toujours avec ce message d'erreur :
% telnet connections not permitted from this terminal
Dans ce cas, vérifiez que vous avez correctement configuré le vty. Émettez la commande transport input all afin de permettre au vty de transporter tout.
Problème
6500 commutateurs sont empilés dans le cluster VSS ; lorsque vous essayez de le connecter à un commutateur de secours, il échoue avec ce message de journal Radius :
%RADIUS-4-RADIUS_DEAD : RADIUS server 10.50.245.20:1812,1813 is not responding.
L'authentification via Telnet vers ce superviseur de secours fonctionne correctement, et la connexion de la console sur le superviseur actif fonctionne également correctement. Le problème se produit lors de la connexion à la console du superviseur de secours.
Solution :
L'authentification Radius sur la console de l'unité en veille n'est pas possible. Le périphérique de secours ne dispose pas de connectivité IP pour l'authentification AAA. Vous devez utiliser l'option de secours, telle qu'une base de données locale.
Parfois, les compteurs de paquets géants sur les interfaces VSL s’incrémentent même si aucun paquet de données géant n’est envoyé via le système.
Les paquets qui traversent les interfaces VSL transportent un en-tête VSL de 32 octets, au-delà de l’en-tête MAC normal. Idéalement, cet en-tête est exclu de la classification de taille de paquet, mais le ASIC de port inclut en fait cet en-tête dans cette classification. Par conséquent, les paquets de contrôle dont la taille est proche de la limite de 1518 pour les paquets de taille normale peuvent être classés comme des paquets géants.
Actuellement, il n'y a aucun contournement de ce problème.
Vous pouvez voir plusieurs VLAN sur le commutateur qui n'étaient pas là avant. Exemple :
Vlan982 unassigned YES unset administratively down down Vlan983 unassigned YES unset administratively down down Vlan984 unassigned YES unset administratively down down Vlan985 unassigned YES unset administratively down down Vlan986 unassigned YES unset administratively down down Vlan987 unassigned YES unset administratively down down Vlan988 unassigned YES unset administratively down down Vlan989 unassigned YES unset administratively down down Vlan990 unassigned YES unset administratively down down Vlan991 unassigned YES unset administratively down down Vlan992 unassigned YES unset administratively down down Vlan993 unassigned YES unset administratively down down Vlan994 unassigned YES unset administratively down down Vlan995 unassigned YES unset administratively down down Vlan996 unassigned YES unset administratively down down Vlan997 unassigned YES unset administratively down down Vlan998 unassigned YES unset administratively down down Vlan999 unassigned YES unset administratively down down Vlan1000 unassigned YES unset administratively down down Vlan1001 unassigned YES unset administratively down down Vlan1002 unassigned YES unset administratively down down Vlan1003 unassigned YES unset administratively down down Vlan1004 unassigned YES unset administratively down down Vlan1005 unassigned YES unset administratively down down
En guise de résolution, la commande vlan filter Traffic-Capture vlan-list 1 - 700 est ajoutée à la configuration. Tous les VLAN non encore configurés peuvent être ajoutés en tant que VLAN de couche 3.
Si le voyant INPUT OK de l'alimentation ne s'allume pas après la mise sous tension de l'interrupteur d'alimentation, exécutez la commande show power status all. Recherchez l'état de l'alimentation électrique, comme cet exemple le montre :
cat6knative#show power status all
Power-Capacity PS-Fan Output Oper
PS Type Watts A @42V Status Status State
---- ------------------ ------- ------ ------ ------ -----
1 WS-CAC-2500W 2331.00 55.50 OK OK on
2 none
Pwr-Requested Pwr-Allocated Admin Oper
Slot Card-Type Watts A @42V Watts A @42V State State
---- ------------------ ------- ------ ------- ------ ----- -----
1 WS-X6K-S2U-MSFC2 142.38 3.39 142.38 3.39 on on
2 WSSUP1A-2GE 142.38 3.39 142.38 3.39 on on
3 WS-X6516-GBIC 231.00 5.50 231.00 5.50 on on
4 WS-X6516-GBIC 231.00 5.50 231.00 5.50 on on
5 WS-X6500-SFM2 129.78 3.09 129.78 3.09 on on
6 WS-X6502-10GE 226.80 5.40 226.80 5.40 on on
cat6knative#
Si l'état n'est pas OK, comme dans cet exemple, suivez les étapes indiquées dans la section Dépannage de l'alimentation du document Dépannage (commutateurs de la gamme Catalyst 6500) afin de dépanner plus loin.
Si ce message s'affiche dans le journal, il indique qu'il n'y a pas assez de puissance pour mettre le module sous tension. Le [dec] du message indique le numéro de logement :
%OIR-SP-6-REMCARD: Card removed from slot 9, interfaces disabled C6KPWR-4-POWERDENIED: insufficient power, module in slot 9 power denied C6KPWR-SP-4-POWERDENIED: insufficient power, module in slot 9 power denied
Émettez la commande show power afin de trouver le mode de redondance d'alimentation.
cat6knative#show power system power redundancy mode = redundant system power total = 27.460A system power used = 25.430A system power available = 2.030A FRU-type # current admin state oper power-supply 1 27.460A on on power-supply 2 27.460A on on module 1 3.390A on on module 2 3.390A on on module 3 5.500A on on module 5 3.090A on on module 7 5.030A on on module 8 5.030A on on module 9 5.030A on off (FRU-power denied).
Ce résultat indique que le mode d'alimentation est redondant et qu'une seule alimentation n'est pas suffisante pour alimenter l'ensemble du châssis. Vous pouvez effectuer l'une des deux opérations suivantes :
Trouvez une alimentation électrique de haute puissance en watts.
Par exemple, si l'alimentation actuelle est 1 300 W CA, obtenez une alimentation 2 500 W CA ou 4 000 W CA.
Combinez le mode de redondance de l'alimentation électrique.
Voici un exemple :
cat6knative(config)#power redundancy-mode combined cat6knative(config)# %C6KPWR-SP-4-PSCOMBINEDMODE: power supplies set to combined mode.
Dans le mode combiné, les deux alimentations électriques fournissent la puissance. Cependant, dans ce mode, si une alimentation tombe en panne, vous perdez à nouveau l'alimentation du module car l'alimentation restante ne peut pas alimenter l'ensemble du châssis.
Par conséquent, la meilleure option consiste à utiliser une alimentation de puissance supérieure.
La puissance qui est réservée à un emplacement vide ne peut pas être réattribuée. Si, par exemple, le logement 6 est vide et que le logement 2 ne dispose que de 68 watts, vous ne pouvez pas réallouer les 282 watts réservés au logement 6 au logement 2 afin d'avoir plus de puissance disponible pour le logement 2.
Chaque logement dispose de sa propre alimentation et, s'il n'est pas utilisé, il ne peut pas être réalloué à un autre logement. Il n'y a aucune commande pour désactiver l'alimentation réservée pour un logement vide.
Note: Assurez-vous que le commutateur est connecté à un 220 VCA au lieu d'un 110 VCA (si le module d'alimentation prend en charge le 220 VCA) pour utiliser toute la capacité des modules d'alimentation. Pour plus d'informations sur la gestion de l'alimentation, référez-vous à Gestion de l'alimentation pour les commutateurs de la gamme Catalyst 6000.
Si vous émettez la commande show environment status et constatez que l'ensemble ventilateur est en panne, suivez les étapes de la section Dépannage de l'ensemble ventilateur du document Dépannage (commutateurs de la gamme Catalyst 6500) afin d'identifier le problème.
Voici un exemple :
cat6knative#show environment status backplane: operating clock count: 2 operating VTT count: 3 fan-tray 1: fan-tray 1 fan-fail: failed !--- Output suppressed.