In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument enthält eine kurze Erläuterung gängiger Syslog-Protokolle und Fehlermeldungen, die auf Cisco Catalyst Switches der Serien 6500 und 6000 angezeigt werden, auf denen die Cisco IOS® Systemsoftware ausgeführt wird. Verwenden Sie den Cisco CLI Analyzer (nur registrierte Kunden), wenn eine Fehlermeldung angezeigt wird, die in diesem Dokument nicht angezeigt wird. Das Tool gibt die Bedeutung von Fehlermeldungen an, die von der Cisco IOS Software und der Catalyst OS (CatOS)-Software generiert werden.
Hinweis: Das genaue Format des Syslog und der in diesem Dokument beschriebenen Fehlermeldungen kann leicht abweichen. Die Variation hängt von der Softwareversion ab, die auf der Supervisor Engine ausgeführt wird.
Hinweis: Diese minimale Protokollierungskonfiguration für den Catalyst 6500/6000 wird empfohlen:
Legen Sie das Datum und die Uhrzeit auf dem Switch fest, oder konfigurieren Sie den Switch so, dass er das Network Time Protocol (NTP) verwendet, um das Datum und die Uhrzeit von einem NTP-Server abzurufen.
Stellen Sie sicher, dass die Protokollierung und Protokollierung der Zeitstempel aktiviert ist (Standardeinstellung).
Konfigurieren Sie den Switch so, dass er sich möglichst bei einem Syslog-Server anmeldet.
Für dieses Dokument bestehen keine speziellen Anforderungen.
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
Der Switch meldet diese Fehlermeldung:
C6KPWR-SP-4 WIRD NICHT UNTERSTÜTZT: nicht unterstütztes Modul im Steckplatz [num], Stromversorgung nicht zulässig: [Diagramme]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Diese Meldung weist darauf hin, dass das Modul im angegebenen Steckplatz nicht unterstützt wird. Die [num] ist die Steckplatznummer, und [chars] enthält weitere Details zum Fehler.
Aktualisieren Sie die Supervisor Engine-Software auf eine Version, die das Hardwaremodul unterstützt. Versionshinweise für die Cisco Catalyst Switches der Serie 6500 finden Sie im Abschnitt Unterstützte Hardware. Führen Sie eine der folgenden Aktionen aus, um das in der Nachricht beschriebene Problem zu beheben:
Setzen Sie das Switch-Fabric-Modul ein, oder ersetzen Sie es.
Setzen Sie das nicht unterstützte Modul in einen anderen Steckplatz ein.
Der Switch meldet diese Fehlermeldung:
%DUAL-3-INTERNAL: IP-EIGRP 1: Interner Fehler
Die Fehlermeldung weist darauf hin, dass ein interner Fehler in der Cisco IOS Software aufgetreten ist. Der Fehler wurde in den folgenden Versionen behoben:
Cisco IOS Softwareversion 12.2(0.4)
Cisco IOS Softwareversion 12.1(6.1)
Cisco IOS Softwareversion 12.2(0.5)T
Cisco IOS Softwareversion 12.1(6.5)E
Cisco IOS Softwareversion 12.1(6.5)EC
Cisco IOS Softwareversion 12.1(6)E02
Cisco IOS Softwareversion 12.2(0.18)S
Cisco IOS Softwareversion 12.2(2)B
Cisco IOS Softwareversion 12.2(15)ZN
Aktualisieren Sie die Cisco IOS Software auf eine dieser Versionen oder auf die neueste Version.
Der Switch meldet diese Fehlermeldung:
%EARL_L3_ASIC-SP-4-INTR_THROTTLE: Throttling "IP_TOO_SHRT"
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Diese Meldung weist darauf hin, dass die Switch-Weiterleitungs-Engine ein IP-Paket mit einer Länge empfängt, die kleiner als die zulässige Mindestlänge ist. Der Switch verwirft das Paket. In früheren Versionen wird das Paket unbeaufsichtigt verworfen und in die Statistik der Weiterleitungs-Engine einbezogen. In späteren Versionen wird die Fehlermeldung einmal alle 30 Minuten im Syslog aufgezeichnet. Diese Probleme können dazu führen, dass die Switch Forwarding Engine diesen Typ von IP-Paket empfängt:
Ein falscher Treiber für die Netzwerkschnittstellenkarte (NIC)
Fehler beim NIC-Treiber
Fehlerhafte Anwendung
Der Switch meldet lediglich, dass er diese "schlechten" Pakete erhalten hat und beabsichtigt, diese zu verwerfen.
Der Ursprung des Problems liegt außerhalb des Switches. Leider verfolgt die Weiterleitungs-Engine nicht die Quell-IP-Adresse des Geräts, das diese schädlichen Pakete sendet. Die einzige Möglichkeit, das Gerät zu erkennen, besteht darin, einen Sniffer zu verwenden, um die Quelle nachzuverfolgen und das Gerät dann zu ersetzen.
Der Switch meldet diese Fehlermeldung:
EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: Non-letal Interrupt [chars]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Die Fehlermeldung %EARL_L3_ASIC-SP-3-INTR_WARN gibt an, dass der Application-Specific Integrated Circuit (ASIC) für die Enhanced Address Recognition Logic (EARL) Layer 3 (L3) einen unerwarteten, nicht tödlichen Zustand erkannt hat. Dies weist darauf hin, dass ein fehlerhaftes Paket, wahrscheinlich ein Paket, das einen IP-Prüfsummenfehler auf Layer 3 enthält, empfangen und verworfen wurde. Die Ursache des Problems ist ein Gerät im Netzwerk, das fehlerhafte Pakete sendet. Diese Probleme können u. a. die fehlerhaften Pakete verursachen:
Fehlerhafte NICs
Falsche NIC-Treiber
Fehlerhafte Anwendungen
Bei älteren Versionen der Cisco IOS Software werden diese Pakete normalerweise verworfen, ohne protokolliert zu werden. Die Funktion zur Protokollierung von Fehlermeldungen zu diesem Problem ist in der Cisco IOS Software-Version 12.2SX und höher enthalten.
Diese Nachricht dient nur zu Informationszwecken. Verwenden Sie als Problemumgehung eine der beiden folgenden Optionen:
Verwenden Sie einen Netzwerk-Sniffer, um die Quelle zu identifizieren, die fehlerhafte Pakete sendet. Beheben Sie dann das Problem mit dem Quellgerät oder der Anwendung.
Deaktivieren Sie die Layer-3-Fehlerprüfungen in der Switch-Hardware für:
Paketprüfsummenfehler
Paketlängenfehler
Pakete mit denselben Quell- und Ziel-IP-Adressen
Verwenden Sie den Befehl no mls verify, um diese Fehlerprüfungen zu beenden, wie in den folgenden Beispielen gezeigt:
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.
Der Switch meldet diese Fehlermeldung:
EARL_NETFLOW-4-TCAM_THRLD: NetFlow TCAM-Grenzwert überschritten, TCAM-Auslastung [[dec]%]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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%]
Hinweis: Wenn Sie diese spezifische Fehlermeldung herausfiltern möchten, beachten Sie, dass alle Fehlermeldungen mit demselben Schweregrad gefiltert werden. Eine bestimmte Protokollmeldung kann nicht gefiltert werden, ohne dass andere Protokolle unter dem gleichen Schweregrad betroffen sind.
Diese Meldung weist darauf hin, dass der adressierbare NetFlow-Ternary Content Addressable Memory (TCAM) nahezu voll ist. Aggressive Alterung wird vorübergehend aktiviert. Wenn Sie die NetFlow-Maske in den VOLLSTÄNDIGEN Modus ändern, kann TCAM für NetFlow einen Überlauf verursachen, da so viele Einträge vorhanden sind. Geben Sie den Befehl show mls netflow ip count ein, um diese Informationen zu überprüfen.
Die Supervisor Engine 720 überprüft alle 30 Sekunden, wie voll die NetFlow-Tabelle ist. Die Supervisor Engine schaltet aggressives Altern ein, wenn die Tabellengröße fast 90 Prozent erreicht. Die Idee hinter aggressiver Alterung ist, dass der Tisch fast voll ist, also gibt es neue aktive Ströme, die nicht geschaffen werden können. Daher ist es sinnvoll, die weniger aktiven Flüsse (oder inaktiven Flüsse) in der Tabelle aggressiv zu altern, um Platz für aktivere Flüsse zu schaffen.
Die Kapazität für jede PFC-NetFlow-Tabelle (IPv4) für PFC3a und PFC3b beträgt 128.000 Flows. Für PFC3bXL beträgt die Kapazität 256.000 Flows.
Um dieses Problem zu vermeiden, deaktivieren Sie den VOLLSTÄNDIGEN NetFlow-Modus. Geben Sie den Befehl no mls flow ip ein.
Hinweis: Im Allgemeinen hat der Befehl no mls flow ip keinen Einfluss auf die Paketweiterleitung, da TCAM für die Paketweiterleitung und TCAM für die NetFlow-Abrechnung separat sind.
Aktivieren Sie MLS Fast Aging, um dieses Problem zu beheben. Wenn Sie die schnelle Alterung von MLS aktivieren, legen Sie den Wert zunächst auf 128 Sekunden fest. Wenn die Größe des MLS-Cache weiter über 32 K-Einträge wächst, reduzieren Sie die Einstellung, bis die Cache-Größe weniger als 32 K beträgt. Wenn der Cache weiter um mehr als 32.000 Einträge wächst, reduzieren Sie die normale MLS-Alterungszeit. Jeder Wert für die Alterungszeit, der nicht ein Vielfaches von 8 Sekunden ist, wird auf das nächste Vielfaches von 8 Sekunden eingestellt.
Switch#configure terminal Switch(config)#mls aging fast threshold 64 time 30
Die andere Problemumgehung würde den Service intern deaktivieren, wenn Sie aktiviert haben, und mls flow ip interface-full in den Fall entfernen, dass Sie keinen vollständigen Fluss benötigen.
Switch(config)#no service internal Switch(config)#mls flow ip interface-full
Der Switch meldet diese Fehlermeldung, und der Port muss eine Verbindung herstellen:
%ETHCNTR-3-LOOP_BACK_ERKANNT: Keepalive-Paket-Loop-Back erkannt auf [chars]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Das Problem tritt auf, weil das Keepalive-Paket an den Port zurückgeleitet wird, der den Keepalive gesendet hat. Keepalives werden an die Catalyst Switches gesendet, um Schleifen im Netzwerk zu vermeiden. Keepalives sind auf allen Schnittstellen standardmäßig aktiviert. Sie sehen dieses Problem auf dem Gerät, das die Schleife erkennt und bricht, aber nicht auf dem Gerät, das die Schleife verursacht.
Geben Sie den Befehl no keepalive interface ein, um Keepalives zu deaktivieren. Eine Deaktivierung der Keepalive-Funktion verhindert eine Fehlabschaltung der Schnittstelle, entfernt die Schleife jedoch nicht.
Hinweis: In Versionen ab Version 12.2(x)SE der Cisco IOS-Software werden Keepalives nicht standardmäßig über Glasfaser- und Uplink-Schnittstellen gesendet.
Der Switch meldet diese Fehlermeldung:
Lastprog: Fehler - bei geöffnetem Dateiboot: "bootflash:c6msfc2-boot-mz.121-8a.EX" kann nicht geladen werden.
Das Problem tritt nur bei einem nicht ausgerichteten Schreibvorgang auf das Gerät auf, das sich nahe einer internen 64-Byte-Grenze befindet. Das Problem kann unter folgenden Umständen auftreten:
Während der Erstellung einer Crash-Dump-Datei
Irgendetwas führt dazu, dass das System zum Zeitpunkt der Erstellung der Datei abstürzt.
Wenn Code bei der Migration von CatOS zur Cisco IOS Software beschädigt ist
Die Lösung besteht darin, den Gerätetreiber so zu ändern, dass er den nicht ausgerichteten Zugriff korrekt behandelt. Falls der Fehler während der Migration von CatOS zur Cisco IOS-Software aufgrund einer Codebeschädigung auftritt, löschen Sie den Flash-Speicher, und laden Sie ein neues, gültiges CatOS-Software-Image herunter.
Der Switch meldet diese Fehlermeldung:
%L3_ASIC-DFC3-4-ERR_INTRPT: Interrupt TF_INT:FI_DATA_INT tritt bei EARL %Layer 3 ASIC auf
Diese Fehlermeldung weist darauf hin, dass ein Fehler in der Layer 3 (L3)-Weiterleitung ASIC (Application-Specific Integrated Circuit) vorliegt. Grundsätzlich zeigt der Switch diese Meldung an, wenn ein vorübergehender Datenverkehr den ASIC passiert und die Software lediglich das Auftreten eines Unterbrechungszustands meldet. Sobald diese Bedingung erfüllt ist, werden die Zähler, die der Befehl show earl statistics anzeigt, erhöht. Jedes Mal, wenn die Software versucht, sich von einem solchen Zustand zu erholen, generiert der Switch diese Syslog-Meldung. Im Allgemeinen ist diese Nachricht informativ, wenn ihr Vorkommen gering ist. Wenn die Fehlermeldung jedoch häufig auftritt, kann ein Problem mit der Hardware vorliegen.
Überprüfen Sie den Zählerwert in der Befehlsausgabe Erste Statistiken anzeigen. Wenn die Zähler schnell ansteigen, weist dies auf ein mögliches Problem mit der Hardware hin.
Der Switch meldet diese Fehlermeldung:
%MLS_STAT-SP-4-IP_LEN_ERR: Inkonsistenzen bei MAC/IP-Länge
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Diese Meldungen weisen darauf hin, dass Pakete empfangen wurden, bei denen die IP-Länge nicht mit der MAC-Länge des Pakets übereinstimmt. Die Supervisor Engine hat diese Pakete verworfen. Der Switch hat keine negativen Auswirkungen, da er die Pakete verwirft. Der Switch meldet die Nachricht zu Informationszwecken. Die Ursache des Problems ist ein Gerät im Netzwerk, das fehlerhafte Pakete sendet. Diese Probleme können u. a. die fehlerhaften Pakete verursachen:
Fehlerhafte NICs
Falsche NIC-Treiber
Fehlerhafte Anwendungen
Verwenden Sie einen Netzwerk-Sniffer, um die Quelle zu finden, die fehlerhafte Pakete sendet. Beheben Sie dann das Problem mit dem Quellgerät oder der Anwendung.
Die andere Problemumgehung ist eine Switch-Konfiguration, die verhindert, dass der Switch folgende Anforderungen erfüllt:
Paketprüfsummenfehler
Paketlängenfehler
Pakete mit denselben Quell- und Ziel-IP-Adressen
Verwenden Sie die folgenden Befehle, um die Switch-Prüfungen zu beenden:
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.
Der Switch meldet diese Fehlermeldung:
%MLS_STAT-SP-4-IP_CSUM_ERR: IP-Prüfsummenfehler
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Diese Meldungen weisen darauf hin, dass der Switch IP-Pakete mit einem ungültigen Prüfsummenwert empfängt. Der Switch hat keine negativen Auswirkungen, da er die Pakete verwirft. Der Switch meldet die Nachricht zu Informationszwecken. Die Ursache des Problems ist ein Gerät im Netzwerk, das fehlerhafte Pakete sendet. Diese Probleme können u. a. die fehlerhaften Pakete verursachen:
Fehlerhafte NICs
Falsche NIC-Treiber
Fehlerhafte Anwendungen
Verwenden Sie als Problemumgehung eine der beiden folgenden Optionen:
Verwenden Sie einen Netzwerk-Sniffer, um die Quelle zu identifizieren, die fehlerhafte Pakete sendet. Beheben Sie dann das Problem mit dem Quellgerät oder der Anwendung.
Deaktivieren Sie die Layer-3-Fehlerprüfungen in der Switch-Hardware für beide:
Paketprüfsummenfehler
Paketlängenfehler
Um diese Fehlerprüfungen zu stoppen, verwenden Sie den Befehl no mls verify (no mls verifizieren), wie in den folgenden Beispielen gezeigt:
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.
Der Switch meldet diese Fehlermeldung:
%MCAST-SP-6-ADDRESS_ALIASING_FALLBACK:
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%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
Diese Meldung weist darauf hin, dass der Switch übermäßigen Multicast-Datenverkehr empfängt, der für eine Multicast-MAC-Adresse im Bereich 01-00-5e-00-00-xx bestimmt ist. Dieser Multicast-Bereich ist für Internet Group Management Protocol (IGMP)-Kontrollverkehr reserviert, z. B.:
Blätter
Joins
Allgemeine Fragen
Die Switch-CPU verarbeitet in der Regel den gesamten IGMP-Kontrolldatenverkehr. Aus diesem Grund bietet die Cisco IOS Software einen Mechanismus, um übermäßigen IGMP-Multicast-Datenverkehr zu ignorieren, der für reservierte Adressen bestimmt ist. Der Mechanismus stellt sicher, dass die CPU nicht überlastet wird. Die Verwendung dieses Mechanismus wird als "Fallback-Modus" bezeichnet.
Suchen Sie die Quelle für den illegalen Multicast-Datenverkehr. Beenden Sie dann entweder die Übertragung, oder ändern Sie die Eigenschaften des Streams, sodass die Übertragung nicht mehr den IGMP-Datenspeicher beeinträchtigt. Verwenden Sie außerdem die Fehlermeldung im Problemabschnitt, der eine Netzwerkquelle bereitstellt, die das Problem möglicherweise verursacht.
Der Switch meldet diese Fehlermeldung:
c6k_pwr_get_fru_gegenwärtig(): fru_info für fru type 6, # nicht finden
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Diese Fehlermeldung wird angezeigt, weil der Switch auf das Simple Network Management Protocol (SNMP) Polling der Port-Adapter, die von Flex WAN-Modulen verwendet werden, falsch reagiert hat. Diese Fehlermeldung ist rein kosmetischer Natur und weist keine nachteiligen Leistungsprobleme bei Switches auf. Das Problem wurde in den folgenden Versionen behoben:
Cisco IOS Softwareversion 12.1(11b)E4
Cisco IOS Softwareversion 12.1(12c)E1
Cisco IOS Softwareversion 12.1(13)E
Cisco IOS Softwareversion 12.1(13)EC
Spätere Versionen
Der Switch meldet diese Fehlermeldung:
%MROUTE-3-TWHEEL_DELAY_ERR:
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%MROUTE-3-TWHEEL_DELAY_ERR: Exceeded maximum delay (240000 ms) requested: 7200000
Diese Meldung wird angezeigt, wenn der Switch Protocol Independent Multicast (PIM)-Join/Prune-Pakete empfängt, die einen hohen Haltezeitwert angeben. Die Pakete geben einen höheren Wert für die Haltezeit an als die maximale Verzögerung, die das Betriebssystem des Switches zulässt (4 Minuten). Bei diesen Paketen handelt es sich um Multicast-Kontrollpakete wie PIM, DVMRP (Distance Vector Multicast Routing Protocol) und andere Typen.
Bei späteren Versionen der Cisco IOS Software für Catalyst 6500/6000 wurde diese maximale Verzögerung auf 65.535 Sekunden oder etwa 17 Minuten erhöht. Das Problem wurde in den folgenden Versionen behoben:
Cisco IOS Softwareversion 12.1(12c)E
Cisco IOS Softwareversion 12.2(12)T01
Cisco IOS Softwareversion 12.1(13)E
Cisco IOS Softwareversion 12.1(13)EC
Spätere Versionen
Konfigurieren Sie das Gerät eines Drittanbieters, das die PIM-Pakete generiert, für die Verwendung von Timern, die von Protokollstandards empfohlen werden.
Der Switch meldet diese Fehlermeldung:
%MCAST-SP-6-GC_LIMIT_EXCEED
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%MCAST-SP-6-GC_LIMIT_EXCEEDED: IGMP snooping was trying to allocate more Layer 2 entries than what=allowed (13000)
Diese Fehlermeldung wird protokolliert, wenn die IGMP-Snooping-Funktion auf dem Switch die maximal zulässige Anzahl an Layer 2 (L2)-Einträgen erstellt hat. Standardmäßig kann der Switch für Multicast-Gruppen maximal 15.488 L2-Einträge erstellen. In späteren Versionen der Cisco IOS-Software werden nur die hardwareinstallierten L2-Multicast-Einträge berücksichtigt. Weitere Informationen finden Sie unter Cisco Bug ID CSCdx89380 (nur registrierte Kunden). Das Problem wurde in Cisco IOS Software Release 12.1(13)E1 und höher behoben.
Sie können den L2-Grenzwert manuell erhöhen. Geben Sie den Befehl ip igmp l2-entry-limit ein.
Der Switch meldet diese Fehlermeldung:
%MISTRAL-SP-3-FEHLER: Fehlerbedingung erkannt: TM_NPP_PARITY_ERROR
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Diese Fehlermeldung weist darauf hin, dass im nächsten Seitenzeiger des internen Table Manager ein Paritätsfehler aufgetreten ist. Wenn der Switch die Cisco IOS Software Version 12.1(8)E oder höher ausführt, erkennt der Switch den Paritätsfehler und setzt den Mistral ASIC zurück. Der Switch kann dann fortfahren, ohne dass ein Neuladen erforderlich ist. Eine zufällige statische Entladung oder andere externe Faktoren können den Speicherparitätsfehler verursachen. Wenn Sie die Fehlermeldung nur einmal oder selten sehen, überprüfen Sie das Switch-Syslog, um sicherzustellen, dass es sich bei der Fehlermeldung um einen isolierten Vorfall handelt. Wenn diese Fehlermeldungen erneut auftreten, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco.
Der Switch meldet diese Fehlermeldung:
%MLS_STAT-4-IP_TOO_SHRT: Zu kurze IP-Pakete empfangen
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
*Apr 1 10:30:35 EST: %MLS_STAT-SP-4-IP_TOO_SHRT: Too short IP packets received
Die Meldung weist darauf hin, dass die Switch Forwarding Engine ein IP-Paket mit einer Länge empfängt, die kleiner als die zulässige Mindestlänge ist. Der Switch verwirft das Paket. In früheren Versionen wird das Paket unbeaufsichtigt verworfen und in die Statistik der Weiterleitungs-Engine einbezogen. Dies gilt für Softwareversionen, die älter als 7.x oder früher als die Cisco IOS Software, Version 12.1(13E), sind. Bei Softwareversionen, die später als 7.x oder höher als die Cisco IOS Software Version 12.1(13E) sind, wird die Meldung einmal alle 30 Minuten im Syslog gespeichert.
Auf der Switch-Seite treten keine Auswirkungen auf. Der Switch verwirft das fehlerhafte Paket, das das empfangende Gerät daraufhin verloren gegangen wäre. Die einzige Sorge besteht darin, dass ein Gerät schädliche Pakete sendet. Mögliche Ursachen sind:
Ein falscher NIC-Treiber
Fehler beim NIC-Treiber
Fehlerhafte Anwendung
Aufgrund von Hardware-Einschränkungen verfolgt die Supervisor Engine nicht die Quell-IP, die MAC-Adresse oder den Port des Geräts, das böse Pakete sendet. Um diese Geräte zu erkennen und die Quelladresse nachzuverfolgen, müssen Sie eine Anwendung zum Ausspucken von Paketen verwenden.
Die Meldung im Abschnitt "Problem" ist lediglich eine Warnung/Informationsmeldung vom Switch. Die Nachricht liefert keine Informationen über den Quellport, die MAC-Adresse oder die IP-Adresse.
Verwenden Sie im Netzwerk eine Anwendung zum Ausschneiden von Paketen. Versuchen Sie, eine Schnittstelle herunterzufahren oder ein Gerät aus dem Netzwerk zu entfernen, um festzustellen, ob Sie das fehlerhafte Gerät isolieren können.
Der Switch meldet diese Fehlermeldung:
Prozessor [Nummer] Modul im Steckplatz [Nummer] kann keine Serviceanfragen durchführen
Dieser Fehler tritt auf, wenn Sie den Befehl für die Sitzungssteckplatznummer mit dem Befehl Prozessornummer ausgeben, um in diesen Situationen eine Sitzung einzurichten:
Sie versuchen, eine Sitzung mit einem Modul herzustellen, in dem bereits eine Sitzung beim Anmelden beim Switch eingerichtet wurde.
Sie versuchen, eine Sitzung für ein nicht verfügbares Modul im Steckplatz einzurichten.
Sie versuchen, eine Sitzung für einen nicht verfügbaren Prozessor im Modul einzurichten.
Der Switch meldet diese Fehlermeldung:
%PM_SCP-1-LCP_FW_ERR: System-Reset-Modul [dec] zur Wiederherstellung nach einem Fehler: [Diagramme]
Diese Beispiele zeigen die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%PM_SCP-SP-1-LCP_FW_ERR: Systemrücksetzmodul 13 zur Wiederherstellung nach einem Fehler: Linecard erhielt Systemausnahme
oder
%PM_SCP-SP-1-LCP_FW_ERR: Systemrücksetzmodul 4 zur Wiederherstellung nach einem Fehler: Coil Pb Rx Parity Error - Port #14
Die Meldung weist darauf hin, dass die Firmware des angegebenen Moduls einen Fehler erkannt hat. Das System setzt das Modul automatisch zurück, um den Fehler zu beheben. [dec] ist die Modulnummer, und [chars] ist der Fehler.
Setzen Sie das Modul wieder ein, oder setzen Sie das Modul in einen anderen Steckplatz ein, und führen Sie den kompletten Diagnosetest für den Systemstart durch. Weitere Informationen zur Online-Diagnose für die Catalyst Switches der Serie 6500 finden Sie unter Konfigurieren der Online-Diagnose. Wenn der Diagnosetest für das Modul erfolgreich abgeschlossen ist, überprüfen Sie, ob die Fehlermeldung erneut auftritt. Wenn der Fehler erneut auftritt oder der Diagnosetest Probleme entdeckt, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco für die weitere Fehlerbehebung.
Der Switch meldet diese Fehlermeldung:
%PM_SCP-2-LCP_FW_ERR_INFORM: Beim Modul [dec] tritt der folgende Fehler auf: [Diagramme]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%PM_SCP-SP-2-LCP_FW_ERR_INFORM: Bei Modul 4 tritt folgender Fehler auf: Bus ASIC #0 transiente PB-Fehler
Das Modul meldet einen Fehlerzustand, wobei [dec] die Modulnummer und [chars] der Fehler ist. Dieser Zustand wird in der Regel durch eine falsch sitzende Linecard oder einen Hardwarefehler verursacht. Wenn die Fehlermeldung auf allen Linecards angezeigt wird, ist das Modul nicht korrekt eingesetzt.
Setzen Sie die Linecard oder das Modul neu ein, und setzen Sie sie wieder ein. Geben Sie dann den Befehl show diagnose result module _# ein."
Wenn die Fehlermeldung nach dem Zurücksetzen des Moduls weiterhin auftritt, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco für die weitere Fehlerbehebung.
Der Switch meldet diese Fehlermeldung:
%PM_SCP-SP-2-LCP_FW_ERR_INFORM: Bei Modul 4 tritt folgender Fehler auf: Port #36 Transient TX PB Fehler
Diese Fehlermeldung weist auf einen vorübergehenden Fehler auf Modul 4 im Datenpfad von Port 36 hin. In den meisten Fällen handelt es sich um ein einmaliges/vorübergehendes Problem.
Schließen und deaktivieren Sie den Port Gi4/36, und überwachen Sie das erneute Auftreten des Problems.
Wenn der Fehler erneut auftritt, stellen Sie die Diagnose so ein, dass sie mit dem Befehl Diagnosestartstufe abgeschlossen abgeschlossen ist. Setzen Sie die Linecard dann physisch wieder ein.
Wenn die Fehlermeldung nach dem Wiedereinsetzen des Moduls weiterhin auftritt, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco, um weitere Fehlerbehebungen mit den folgenden Befehlsausgaben durchzuführen:
Der Switch meldet diese Fehlermeldung:
%PM_SCP-SP-4-UNK_OPCODE: Unbekannte unaufgeforderte Nachricht von Modul [dec], opcode [hex] empfangen
Diese Beispiele zeigen die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
10. Dez. 12:44:18.117: %PM_SCP-SP-4-UNK_OPCODE: Unbekannte unaufgeforderte Nachricht von Modul 2, Opcode 0x330 empfangen
oder
10. Dez. 12:44:25.210: %PM_SCP-SP-4-UNK_OPCODE: Unbekannte unaufgeforderte Nachricht von Modul 2, Opcode 0x114 empfangen
Diese Fehlermeldung zeigt einfach an, dass die Supervisor Engine die Kontrollmeldung von der Linecard nicht versteht, da Funktionen von der Cisco IOS Software-Version des Switches nicht unterstützt werden.
Linecards senden Steuermeldungen an die aktive Supervisor Engine, die die von der Software unterstützten Funktionen anzeigen. Wenn die Software jedoch keine der Linecard-Funktionen unterstützt, werden diese Kontrollmeldungen nicht erkannt und die Fehlermeldung angezeigt. Diese Meldung ist ein harmloses Vorkommen und hat keine Auswirkungen auf Funktionen der Supervisor Engine oder der Linecards.
Aktualisieren Sie die Supervisor Engine-Software auf die neueste Version, die die maximale Funktionsunterstützung bietet. Da sich diese Fehlermeldung nicht auf die Produktion oder den Datenverkehr auswirkt, können Sie die Meldung ignorieren.
Der Switch meldet diese Fehlermeldung:
%PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM: Integritätsprüfung des Transceivers im LAN-Port 5/2 fehlgeschlagen: schlechter Schlüssel
Der Grund für diese Fehlermeldung ist die Verwendung von nicht von Cisco stammendem SFP-GBIC, der nicht unterstützt wird.
Cisco SFP GBICs verfügen über einen eindeutigen verschlüsselten Code (Qualitäts-ID), mit dem Cisco IOS/CAT-Betriebssysteme Plug-fähige Teile von Cisco identifizieren können. Normale GBICs haben dies nicht und können daher möglicherweise funktionieren. Weitere Informationen finden Sie unter %PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM.
Der Switch meldet diese Fehlermeldung:
%PM_SCP-SP-3-LCP_FW_ABLC: Späte Kollisionsmeldung von Modul 3, Port:035
Späte Kollisionen - Eine späte Kollision tritt auf, wenn zwei Geräte gleichzeitig übertragen werden, und keine der beiden Seiten der Verbindung eine Kollision erkennt. Der Grund dafür ist, dass die Zeit für die Übertragung des Signals von einem Ende des Netzwerks an ein anderes länger ist als die Zeit, das gesamte Paket in das Netzwerk einzufügen. Die beiden Geräte, die die späte Kollision verursachen, sehen nie, dass das andere Gerät sendet, bis es das gesamte Paket im Netzwerk ablegt. Späte Kollisionen werden vom Sender erst nach der ersten 64-Byte-Steckplatzzeit erkannt. Dies liegt daran, dass sie nur bei Übertragungen von Paketen erkannt werden, die länger als 64 Byte sind.
Mögliche Ursachen: Späte Kollisionen sind das Ergebnis einer Duplexungleichheit, falscher Verkabelung oder einer nicht konformen Anzahl von Hubs im Netzwerk. Schlechte NICs können auch zu späten Kollisionen führen.
Der Switch meldet diese Fehlermeldung:
%PM-3-INVALID_BRIDGE_PORT: Bridge Port number is out of range
Dieses Problem scheint kosmetisch zu sein und ist auf eine SNMP-Abfrage des mib dot1dTpFdbEntry zurückzuführen.
Sie können die OID auf diesem Gerät von der Abfrage blockieren. Dieser Fehler wurde in Cisco IOS Release 12.2(33)SRD04 und höher behoben.
Der Switch meldet diese Fehlermeldung:
%QM-4-TCAM_ENTRY: Hardware-TCAM-Einstiegskapazität überschritten
TCAM ist ein spezialisierter Arbeitsspeicher, der für schnelle Tabellensuche durch die ACL- und QoS-Engines entwickelt wurde. Diese Meldung weist auf die Erschöpfung der TCAM-Ressourcen und das Software-Switching von Paketen hin. Das bedeutet, dass jede Schnittstelle ihre eigene ID im TCAM hat und daher mehr TCAM-Ressourcen verwendet. Höchstwahrscheinlich ist dieses Problem entweder auf das Vorhandensein des Befehls mls qos marking statistics zurückzuführen oder wenn der Hardware-TCAM nicht über die Kapazität verfügt, alle konfigurierten ACLs zu verarbeiten.
Deaktivieren Sie den Befehl mls qos marking statistics, da er standardmäßig aktiviert ist.
Versuchen Sie, dieselben ACLs über mehrere Schnittstellen hinweg zu teilen, um den Konflikt mit den TCAM-Ressourcen zu reduzieren.
Der Switch meldet diese Fehlermeldung:
%slot_earl_icc_shim_addr: Steckplatz [num] ist weder SuperCard noch Supervisor - Ungültiger Steckplatz.
Diese Meldung wird angezeigt, wenn ein SNMP Manager die TCAM-Daten einer Linecard abfragt, die über keine TCAM-Informationen verfügt. Dies tritt nur bei Line Cards auf, die auf einem Catalyst Switch der Serie 6500 ausgeführt werden, auf dem die Cisco IOS Software ausgeführt wird. Wenn die Linecard während der SNMP-Abfrage über TCAM-Informationen verfügt, werden die Daten zur weiteren Verarbeitung an das Netzwerkmanagementsystem (NMS) weitergeleitet. Weitere Informationen finden Sie unter Cisco Bug ID CSCec39383 (nur registrierte Kunden). Dieses Problem wurde in der Cisco IOS Software-Version 12.2(18) behoben.
Als Problemumgehung können Sie die Abfrage von TCAM-Daten durch die NMSs blockieren. Das MIB-Objekt, das TCAM-Nutzungsdaten bereitstellt, lautet cseTcamUsageTable. Führen Sie die folgenden Schritte auf dem Router aus, um Rückverfolgung zu vermeiden:
Geben Sie den Befehl snmp-server view tcamBlock cseTcamUsageTable excluded ein.
Geben Sie den Befehl snmp-server view tcamBlock iso include ein.
Geben Sie den Befehl snmp-server community public view tcamBlock ro ein.
Geben Sie den Befehl snmp-server community private view tcamBlock rw aus.
Der Switch meldet diese Fehlermeldung:
%SYSTEM_CONTROLLER-SP-3-FEHLER: Fehlerbedingung erkannt: TM_NPP_PARITY_ERROR
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
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
Die häufigsten Fehler der Mistral-ASIC auf der MSFC sind TM_DATA_PARITY_ERROR, SYSDRAM_PARITY_ERROR, SYSAD_PARITY_ERROR und TM_NPP_PARITY_ERROR. Mögliche Ursachen für diese Paritätsfehler sind zufällige statische Entladung oder andere externe Faktoren. Diese Fehlermeldung weist darauf hin, dass ein Paritätsfehler aufgetreten ist. Prozessorspeicher-Paritätsfehler (PMPEs) werden in zwei Arten unterteilt: Single Event Rupset (SEU) und wiederholte Fehler.
Diese Einzelbitfehler treten auf, wenn ein Bit in einem Datenwort aufgrund externer Ereignisse unerwartet wechselt (was beispielsweise dazu führt, dass 0 (null) spontan zu 1 (eins) wechselt). SEUs sind ein universelles Phänomen, unabhängig von Anbieter oder Technologie. SEUs treten sehr selten auf, aber alle Computer- und Netzwerksysteme, auch ein PC, unterliegen ihnen. SEUs werden auch als weiche Fehler bezeichnet, die durch Lärm verursacht werden und zu einem vorübergehenden, inkonsistenten Fehler in den Daten führen. Dies steht in keinem Zusammenhang mit einem Komponentenausfall - meist das Ergebnis kosmischer Strahlung.
Wiederholte Fehler (häufig als harte Fehler bezeichnet) werden durch fehlerhafte Komponenten verursacht. Ein harter Fehler wird durch eine fehlerhafte Komponente oder ein Problem mit der Platinenebene verursacht, z. B. eine falsch hergestellte Platine, die zu wiederholten Vorfällen desselben Fehlers führt.
Wenn Sie die Fehlermeldung nur einmal oder selten sehen, überprüfen Sie das Switch-Syslog, um sicherzustellen, dass es sich bei der Fehlermeldung um einen isolierten Vorfall handelt. Wenn diese Fehlermeldungen erneut auftreten, setzen Sie das Blade der Supervisor Engine wieder ein. Wenn die Fehler nicht mehr auftreten, war der Paritätsfehler schwerwiegend. Wenn diese Fehlermeldungen weiterhin auftreten, erstellen Sie ein Ticket beim Technical Assistance Center.
Der Switch meldet diese Fehlermeldung:
%SYSTEM_CONTROLLER-SW2_SPSTBY-3-FEHLER: Fehlerbedingung erkannt: TM_NPP_PARITY_ERROR
Diese Fehlermeldung weist darauf hin, dass ein Paritätsfehler aufgetreten ist, und mögliche Ursachen sind eine zufällige statische Entladung oder andere externe Faktoren, die den Speicherparitätsfehler verursachen, wie z. B. eine vorübergehende Verbindung an der Rückseite der Leiste oder aufgrund von Stromversorgungsproblemen, und manchmal kann die Linecard nicht auf den SPROM-Inhalt (Serial PROM) des Moduls zugreifen, um die Identifizierung der Linecard zu bestimmen.
Alle Computer- und Netzwerksysteme sind anfällig für das seltene Auftreten von Single Event Upsets (SEU), manchmal auch als Paritätsfehler bezeichnet. Diese Einzelbitfehler treten auf, wenn ein Bit in einem Datenwort aufgrund externer Ereignisse unerwartet wechselt und somit beispielsweise eine Null zu spontanem Wechsel zu einem solchen verursacht. SEUs sind ein universelles Phänomen, unabhängig von Anbieter und Technologie. SEUs treten sehr selten auf, aber alle Computer- und Netzwerksysteme, auch ein PC, unterliegen ihnen. SEUs werden auch als "Soft Error" (Soft-Fehler) bezeichnet, die durch Geräusche verursacht werden und einen vorübergehenden, inkonsistenten Datenfehler verursachen und nicht in Zusammenhang mit einem Komponentenausfall stehen.
Wiederholte Fehler, die häufig als harte Fehler bezeichnet werden, werden durch fehlerhafte Komponenten verursacht. Ein harter Fehler wird durch eine ausgefallene Komponente oder ein Problem auf Platinenebene verursacht, z. B. eine unsachgemäß hergestellte Platine, die zu wiederholten Vorfällen desselben Fehlers führt.
Wenn diese Fehlermeldungen erneut auftreten, setzen Sie das Supervisor-Modul während des Wartungsfensters wieder ein.
Der Switch meldet diese Fehlermeldung:
SP: Der Linecard-Endpunkt von Kanal 14 hat die Synchronisierung verloren. zu Lower Fabric und versuchen, jetzt wiederherzustellen!
Die Fehlermeldung verweist in der Regel auf eine falsch positionierte Linecard. In den meisten Fällen können Sie die Linecard physisch wieder einsetzen, um dieses Problem zu beheben. In einigen Fällen ist das Modul fehlerhaft.
Geben Sie den Befehl show Fabric-Fopmap ein, um das Modul zu identifizieren, das diese Fehlermeldung verursacht.
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
Dieses Beispiel ist das Ergebnis des Befehls show Fabric-Fopmap. Aus der Ausgabe können Sie erkennen, dass das Modul in Steckplatz 12 die Fehlermeldung verursacht.
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
Setzen Sie das Modul, das die Fehlermeldung verursacht, wieder ein.
Während ein Cisco Catalyst Switch 6000/6500 hochgefahren wird, kann eine ähnliche Fehlermeldung ausgegeben werden:
%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"
Dieser Fehler tritt hauptsächlich auf, wenn die Boot-Variablen nicht richtig konfiguriert sind, um den Switch von einem gültigen Flash-Gerät aus zu starten.
Beachten Sie in der Abbildung die letzte Zeile der Nachricht:
boot: cannot load "bootdisk:s72033-ipservicesk9-mz.122-18.SXF7.bin"
Der Name des erwähnten Flash-Geräts ist bootdisk, und der erste Teil der IOS-Datei s72033 weist darauf hin, dass das IOS für das Supervisor-Modul 720 gilt. Das Supervisor 720-Modul verfügt über kein Flash-Gerät mit dem Namen bootdisk oder unterstützt dieses nicht. Da das Supervisor 720-Modul über keinen lokalen Flash-Speicher mit diesem Namen verfügt, denkt der Switch, dass Sie vom Netzwerk starten möchten. Daher wird die Fehlermeldung angezeigt.
Konfigurieren Sie die Boot-Variable mit dem richtigen Namen des Flash-Geräts und dem gültigen Namen der Softwaredatei.
Diese Flash-Geräte werden von den Supervisor-Modulen unterstützt:
Supervisor Engine 1 und Supervisor Engine 2
Name des Flash-Geräts | Beschreibung |
---|---|
Bootflash: | Integrierter Flash-Speicher |
Slot0: | Lineare Flash-PC-Karte (PCMCIA-Steckplatz) |
disk0: | ATA-Flash-PC-Karte (PCMCIA-Steckplatz) |
Supervisor Engine 720
Name des Flash-Geräts | Beschreibung |
---|---|
Bootflash: | Integrierter Flash-Speicher |
disk0: | Nur CompactFlash Typ II-Karte (Festplattensteckplatz 0) |
disk1: | CompactFlash Typ II-Karte (Festplattensteckplatz 1) |
Supervisor Engine 32
Name des Flash-Geräts | Beschreibung |
---|---|
Bootdisk: | Integrierter Flash-Speicher |
disk0: | Nur CompactFlash Typ II-Karte (Festplattensteckplatz 0) |
Wenn das Problem dadurch nicht behoben wird, lesen Sie den Abschnitt Wiederherstellen einer Catalyst 6500/6000-Software mit Cisco IOS-Systemsoftware von einem beschädigten oder fehlenden Boot Loader-Image- oder ROMmon-Modus aus.
Der Switch meldet folgende Fehlermeldungen:
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
Diese Meldungen weisen darauf hin, dass CPU-Überwachungsmeldungen über einen längeren Zeitraum nicht mehr zu hören sind. Ein Timeout tritt höchstwahrscheinlich auf, wodurch das System zurückgesetzt wird. [dec] ist die Anzahl der Sekunden.
Das Problem tritt möglicherweise aus folgenden Gründen auf:
Schlecht sitzende Linecard oder Module
Schlechte ASIC oder fehlerhafte Rückwandplatine
Software-Bugs
Paritätsfehler
Hoher Datenverkehr im EOBC-Kanal (Ethernet Out of Band Channel)
Der EOBC-Kanal ist ein Halbduplex-Kanal, der viele andere Funktionen bereitstellt, darunter SNMP-Verkehr (Simple Network Management Protocol) und Pakete, die für den Switch bestimmt sind. Wenn der EOBC-Kanal aufgrund eines SNMP-Datenverkehrs voller Nachrichten ist, wird der Kanal Kollisionen ausgesetzt. In diesem Fall kann EOBC möglicherweise keine IPC-Nachrichten übertragen. Dadurch wird der Switch die Fehlermeldung anzeigen.
Setzen Sie die Linecard oder das Modul wieder ein. Wenn ein Wartungsfenster geplant werden kann, setzen Sie den Switch zurück, um alle Übergangsprobleme zu beheben.
Die Fehlermeldung "%Invalid IDPROM image for linecard" (Ungültiges IDPROM-Image für Linecard) wird in Catalyst Switches der Serie 6500 mit Cisco IOS-Systemsoftware ausgegeben.
Die Fehlermeldung kann ähnlich wie die folgenden Meldungen aussehen:
% 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)
Dieser Fehler weist darauf hin, dass die installierten Linecards nicht ordnungsgemäß gestartet wurden, da der Supervisor ein schlechtes Signal für den Steuerbus erzeugte. In einigen Szenarien kann es vorkommen, dass ein unsachgemäßes Sitzen auch dazu führen kann, dass der Supervisor oder die Linecards im Chassis des Cat6500 nicht erkannt werden. Weitere Informationen finden Sie unter Cisco Bug ID CSCdz65855 (nur registrierte Kunden).
Wenn eine redundante Supervisor-Konfiguration verfügbar ist, führen Sie einen Force Switchover durch, und setzen Sie den ursprünglichen aktiven Supervisor wieder ein.
Wenn es sich um eine einzelne Supervisor-Konfiguration handelt, planen Sie Ausfallzeiten und führen Sie die folgenden Schritte aus:
Setzen Sie das Supervisor-Modul in einen anderen Steckplatz ein.
Setzen Sie alle Linecards wieder ein, und vergewissern Sie sich, dass sie korrekt platziert sind.
Unter Online Insertion and Removal (OIR) von Modulen in Cisco Catalyst Switches finden Sie weitere Informationen zum Online-Einfügen und -Entfernen von Modulen.
Der Switch meldet folgende Fehlermeldungen:
%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)
Der Supervisor sendet einmal alle 2 Sekunden ein SCP-Ping an jede Linecard. Wenn nach 3 Pings (6 Sekunden) keine Antwort eingeht, wird sie als erster Fehler gezählt. Nach 25 derartigen Fehlern oder nach 150 Sekunden, nachdem die Linecard keine Antwort erhalten hat, fährt der Supervisor die Linecard neu. Nach 30 Sekunden wird diese Fehlermeldung auf dem Switch angezeigt:
%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]
Nach 150 Sekunden wird das Modul mithilfe der folgenden Syslogs aus- und wieder eingeschaltet:
%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)
Der Switch meldet diese Fehlermeldung:
%C6KPWR-4-DISABLED: Power to module in slot [dec] set [chars]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%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)
Diese Meldung weist darauf hin, dass das Modul im angegebenen Steckplatz aus dem angegebenen Grund ausgeschaltet wurde. [dec] ist die Steckplatznummer und [chars] gibt den Stromversorgungsstatus an.
Der Switch hat seine normalen Schwingungen, und im Laufe der Zeit können diese Schwingungen dazu führen, dass ein Modul leicht von der Rückwandplatine entfernt wird. In diesem Fall erhält der Supervisor Keepalive Polling innerhalb der zugewiesenen Zeit keine Antwort vom Modul und der Supervisor startet das Modul neu, um eine bessere Verbindung zu diesem Modul herzustellen. Wenn das Modul immer noch nicht auf die Umfragen reagiert, startet der Supervisor das Modul kontinuierlich neu und setzt es schließlich für die Fehlerabschaltung ein und lässt keine Stromversorgung zu diesem Modul zu.
Durch einen einfachen Wiedereinsetzen des Moduls wird dieses Problem 90 Prozent der Zeit behoben. Wenn Sie das Modul wieder einsetzen, wird die Switch-Fabric neu ausgerichtet und eine feste Verbindung zur Backplane sichergestellt.
Wenn es sich bei dem betreffenden Modul um das Content Switching Module (CSM) handelt, sollten Sie ein Upgrade der CSM-Software auf Version 4.1(7) oder höher in Betracht ziehen. Dieses Problem ist unter Cisco Bug ID CSCei85928 (gegen CSM-Software) (nur registrierte Kunden) und Cisco Bug ID CSCek28863 (gegen Cisco IOS-Software) (nur registrierte Kunden) dokumentiert.
Die neueste CSM-Software kann von der Software-Download-Seite für das Cisco Catalyst 6000 Content Switching Module heruntergeladen werden.
Der Switch meldet die Fehlermeldung:
ONLINE-SP-6-INITFAIL: Module [dec]: Failed to [chars]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%ONLINE-SP-6-INITFAIL: Module 5: Failed to synchronize Port asic
Die Ursache des Absturzes ist, dass der Pinnacle ASIC nicht synchronisiert werden konnte. Dies wird in der Regel durch einen fehlerhaften Kontakt oder eine schlecht sitzende Karte verursacht.
Das System wird ohne Benutzereingriff wiederhergestellt. Wenn die Fehlermeldung erneut auftritt, setzen Sie die betreffende Linecard oder das betreffende Modul wieder ein.
Der Switch meldet die Fehlermeldung:
%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
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%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
Die Flow-Maske-Anfrage für die Flow-basierte Funktion ist nicht erfolgreich. Diese Bedingung kann aufgrund einer TCAM-Ressourcenausnahme, einer Flow-Maske, die eine Ressourcenausnahme registriert, oder eines nicht auflösbaren Flow-Maske-Konflikts mit anderen NetFlow-basierten Funktionen auftreten. Die Installation der NetFlow-Verknüpfung und die Hardwarebeschleunigung für diese Funktion können unter diesem Zustand deaktiviert werden, und die Funktion kann in der Software angewendet werden.
Wenn Sie nur eine reflexive Eingangs-Zugriffskontrollliste haben, die in Eingangsrichtung auf verschiedenen Schnittstellen konfiguriert ist, reflektieren und eval, dann basiert die Anforderung für die reflexive ACL-Flussmaske auf reflexiven Eingangs-Zugriffskontrolllisten. Solange die reflexive ACL auf einer anderen Schnittstelle konfiguriert ist als die QoS-Mikroflow-Richtlinien oder sich nicht mit der Microflow-Richtlinienkontrollliste für ACLs überschneidet, können sie auf derselben Schnittstelle gleichzeitig in der Hardware vorhanden sein. Wenn sie sich auf derselben Schnittstelle befinden und sich die reflexiven ACL- und QoS-Richtlinien überschneiden, deaktiviert die reflexive ACL die Installation von NetFlow-Verknüpfungen und die Anpassung von Datenverkehr und reflexiven ACLs erfolgt per Software-Switching. Dies liegt an den Anforderungen an die sich widersprechende Flussmaske.
Bei einer reflexiven Ausgangszugriffskontrollliste ist die Anforderung für die reflexive Zugriffskontrolllisten-Flussmaske auf allen Schnittstellen global, da es nur NetFlow für den eingehenden Datenverkehr gibt. Wenn in diesem Fall QoS-benutzerbasierte Mikroflow-Richtlinien konfiguriert werden, deaktiviert die reflexive Zugriffskontrollliste die NetFlow-Verknüpfungsinstallation, und die Anpassung des Datenverkehrs an reflexive Zugriffskontrolllisten erfolgt per Software-Switching.
Geben Sie den Befehl show fm file flow mask ein, um den Aktivierungs-/Deaktivierungsstatus der NetFlow-Verknüpfung für die Funktion zu bestimmen. Wenn die NetFlow-Verknüpfungsinstallation und die Hardwarebeschleunigung für die Funktion deaktiviert sind, verwenden Sie nur Eingangs-reflexive Zugriffslisten in Kombination mit der Mikroflow-Überwachung, und stellen Sie sicher, dass sich die Microflow-Richtlinien nicht mit der reflexiven Zugriffsliste überschneiden. Wenden Sie die Funktion für die Flow-Maske-Anfrage erneut an, um sie erfolgreich durchzuführen, und aktivieren Sie die NetFlow-Verknüpfungsinstallation für diese Funktion erneut.
Der Switch meldet die Fehlermeldung:
%MCAST-2-IGMP_SNOOP_DISABLE:IGMP Snooping disabled due to excessive events/packets, [dec]/[dec]; auto reenable in about 2 mins
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%MCAST-2-IGMP_SNOOP_DISABLE:IGMP Snooping disabled due to excessive events/packets, 0/19880; auto reenable in about 2 mins
IGMP-Snooping ist deaktiviert, aber das System empfängt Multicast-Verkehr. Diese Situation erzwingt, dass Multicast-Pakete an den Routingprozessor weitergeleitet werden und möglicherweise überflutet werden. IGMP-Snooping kann aufgrund von übermäßigem Multicast-Verkehr automatisch deaktiviert werden. IGMP-Snooping untersucht im Wesentlichen diese Kontrollpakete, die zwischen Routern und Hosts ausgetauscht werden, und richtet sich nach den Joins, Hinterlassen und Abfragen, um zu aktualisieren, welche Ports Multicast empfangen.
Diese Meldung tritt in der Regel auf, weil der Routingprozessor eine wesentlich höhere Geschwindigkeit als erwartet von IGMP-Join-Paketen oder normalen Multicast-Paketen erhält, die für reservierte Layer3/Layer2-Multicast-Adressbereiche bestimmt sind. Aus diesem Grund werden dem Switch keine Ressourcen mehr zur Verfügung gestellt, und wie die Protokollmeldungen anzeigen, verringert und deaktiviert der Switch IGMP-Snooping für einen kurzen Zeitraum.
Sie können die Funktion zur Beschränkung der Multicast-Rate aktivieren und den Schwellenwert auf eine größere Zahl festlegen.
Die Ratenbegrenzung ist eine wünschenswertere Methode, damit die Warteschlange nicht überlaufen wird. Sie bedeutet auch, dass gültige IGMP-Pakete weniger Chancen auf einen Paketverlust haben und daher der Snooping-Prozess auf dem Switch weiterhin entsprechend aktualisiert werden kann.
Gehen Sie wie folgt vor, um dieses Problem zu beheben:
Deaktivieren Sie IGMP-Snooping mit dem Befehl no ip igmp snooping.
Richten Sie auf der Management-VLAN-Schnittstelle des Catalyst 6500 eine SPAN-Sitzung ein, um zu bestimmen, ob die MAC-Adresse zur Quelle gehört, von der der übermäßige Datenverkehr stammt.
Suchen Sie in der CAM-Tabelle nach der Quelle, und entfernen Sie diese.
Aktivieren Sie IGMP-Snooping erneut.
Der Switch meldet diese Fehlermeldungen. Bei der Fehlermeldung kann es sich um einen der folgenden Typen handeln:
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
Die Ursache für diesen Fehler ist möglicherweise ein defektes Modul oder ein falsch sitzendes Modul. Es kann sich auch um ein Chassis-Problem mit diesem Steckplatz handeln. Dies kann ein vorübergehendes Problem darstellen, wenn es auf ein falsch sitzendes Modul zurückzuführen ist.
Diese Meldungen weisen darauf hin, dass das System auf dem angegebenen Pinnacle ASIC oder dem angegebenen Port-ASIC nicht wiederherstellbare Ressourcen erkannt hat, was auf das First In, First Out [FIFO]-Problem zurückzuführen ist.
Führen Sie den Befehl remote command switch show platform hardware asicreg pinnacle slot 1 port 1 err aus, um diesen Fehler zu beheben, und konfigurieren Sie den Switch so, dass erweiterte Hardwaretests mit den folgenden Schritten ausgeführt werden:
Hinweis: Geben Sie den gesamten Befehl ein, und drücken Sie die Eingabetaste. Sie können den Befehl nicht mit der Tab-Taste schreiben.
Geben Sie den Befehl Diagnosestartstufe abgeschlossen ein, um die Diagnosestufe auf abgeschlossen festzulegen, und speichern Sie die Konfiguration.
Setzen Sie den Supervisor wieder ein, und setzen Sie ihn fest ein.
Sobald der Supervisor online ist, führen Sie den Befehl show diagnose aus, um den Switch zu überwachen und zu überprüfen, ob die Fehlermeldung weiterhin auftritt
Der Switch meldet folgende Fehlermeldungen:
%C6KERRDETECT-SP-4-SWBUSSTALL: Der Switching-Bus ist 3 Sekunden lang stillgelegt.
%C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERY: Der Switching-Bus ist betriebsbereit, und das Switching des Datenverkehrs wird fortgesetzt.
Die Meldung %C6KERRDETECT-SP-4-SWBUSSTALL weist darauf hin, dass der Switching-Bus zum Stillstand gekommen ist und der Datenverkehr verloren geht.
Die Meldung %C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERED weist darauf hin, dass der Switching-Bus nicht mehr zum Stillstand kommt und der Datenverkehr fortgesetzt werden kann.
Wenn ein Modul im Systembus hängen bleibt, erkennt der Supervisor ein Timeout und versucht, es selbst wiederherzustellen. Wenn ein Modul gerade installiert wurde, ist dies eine sehr mögliche Ursache für diese Meldungen, da dies einen Busstall verursachen kann, während das Modul in die Rückwandplatine eingesetzt wird.
Diese Fehlermeldung wird angezeigt, wenn In-Band-Test-Pings die CPU-Auslastung nicht erreicht haben:
SP-RP Ping Test[7]: Test skipped due to high traffic/CPU utilization
Der SP-RP im Band-Ping ist ein Online-Diagnosetest, und die Meldung, dass der SP-RP-Ping-Test fehlgeschlagen ist, ist rein informativ. Sie ist ein Hinweis auf eine hohe CPU-Auslastung und kann das Ergebnis eines großen Datenverkehrs sein, der an den Routingprozessor weitergeleitet wird, oder von einem Switching-Datenverkehr, der zum Switch-Prozessor fließt. Dies kann auch bei Routen-Updates der Fall sein. Es ist normal, dass Route Processor CPU manchmal bis zu 100 Prozent beansprucht.
Die Fehlermeldung ist rein informativ und hat keine Auswirkungen auf die Geräteleistung.
Der Switch meldet diese Fehlermeldung:
%SW_VLAN-4-MAX_SUB_INT : The number of sub-interfaces allocated for interface [chars] has exceeded recommended limits of [dec]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%SW_VLAN-4-MAX_SUB_INT: The number of sub-interfaces allocated for interface Gi1/1 has exceeded recommended limits of 1000
Die Anzahl der Layer-3-Subschnittstellen wird durch die internen VLANs im Switch begrenzt. Die Catalyst 6500-Serie verfügt über 4094 VLANs, die für verschiedene Zwecke verwendet werden. Geben Sie den Befehl show platform hardware acity vlan ein, um die aktuelle Status-VLAN-Verfügbarkeit zu ermitteln.
Switch#show platform hardware capacity vlan VLAN Resources VLANs: 4094 total, 9 VTP, 0 extended, 17 internal, 4068 free
Die empfohlene Obergrenze für Subschnittstellen beträgt 1.000 pro Schnittstelle und 2.000 pro Modul. Reduzieren Sie die Anzahl der Subschnittstellen, die der Schnittstelle zugewiesen wurden, da sie den empfohlenen Grenzwert überschritten hat.
Hinweis: Die Konsole kann aufgrund der Flut dieser Meldungen, die beim Neuladen des Switches angezeigt werden, gesperrt werden. Dieses Problem ist in der Cisco Bug-ID CSCek73741 (nur registrierte Kunden) dokumentiert und das Problem wurde in den Cisco IOS Software-Versionen 12.2(18)SXF10 und den Cisco IOS Software-Versionen 12.2(33)SXH oder höher behoben.
Der Switch meldet diese Fehlermeldung:
MCAST-6-L2_HASH_BUCKET_COLLISION: Failure installing (G,C)->index: ([enet],[dec])->[hex] Protocol :[dec] Error:[dec]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%MCAST-SP-6-L2_HASH_BUCKET_COLLISION: Failure installing (G,C)->index: (0100.5e31.d522,802)->0xDA4 Protocol :0 Error:3
Diese Fehlermeldung wird in der Regel zusammen mit der folgenden Meldung angezeigt:
%MCAST-SP-6-GC_LIMIT_EXCEEDED: IGMP snooping was trying to allocate more Layer 2 entries than what allowed (15488)
Diese Meldung weist darauf hin, dass ein Layer-2-Eintrag nicht in der Hardware installiert wurde, da nicht genügend Speicherplatz im Hash-Bucket vorhanden ist. Multicast-Pakete werden im eingehenden VLAN überflutet, da die Installation des Layer-2-Eintrags fehlgeschlagen ist. Bei Überschreitung des Grenzwerts kommt es bei zusätzlichen Gruppen-MACs zu Überflutungen.
Wenn Sie kein Multicast verwenden, können Sie IGMP-Snooping deaktivieren. Andernfalls können Sie die Hash-Einstiegsgrenze mithilfe des Befehls ip igmp snooping l2-entry-limit erhöhen.
Der Switch meldet diese Fehlermeldung:
%QM-4-AGG_POL_EXCEEDED: QoS Hardware Resources Exceeded : Out of Aggregate policers
Es kann nur eine begrenzte Anzahl von aggregierten Policers unterstützt werden. Bei EARL7-basierten Switches ist dieser Grenzwert 1023.
Anstelle der Port-basierten QoS können Sie VLAN-basierte QoS konfigurieren. Gehen Sie wie folgt vor:
Wenden Sie die Service-Richtlinie auf jedes VLAN an, das auf dem Layer-2-Switch-Port konfiguriert wurde.
Entfernen Sie die Service-Richtlinie von jedem Port, der zum spezifischen VLAN gehört.
Konfigurieren Sie jeden Layer-2-Switch-Port für VLAN-basierte QoS mit dem Befehl mls qos vlan-basiert.
Der Switch meldet diese Fehlermeldung:
%EC-SP-5-CANNOT_BUNDLE2: ist nicht kompatibel mit Gi2/1 und wird ausgesetzt (MTU von Gi2/2 ist 1500, Gi2/1 ist 9216)
Diese Fehlermeldung weist darauf hin, dass die MTU des Port-Channel-Mitglieds nicht identisch ist, sodass der Port-Channel einen Fehler beim Hinzufügen verursacht. Standardmäßig haben alle Schnittstellen die MTU-Größe 1500 verwendet. Aufgrund einer Abweichung des MTU-Werts kann der Port nicht zum Port-Channel hinzugefügt werden.
Konfigurieren Sie die gleiche MTU an diesen Mitglieds-Ports.
Der Switch meldet diese Fehlermeldung:
%EC-SP-5-CANNOT_BUNDLE2: Gi1/4 ist nicht mit Gi6/1 kompatibel und wird ausgesetzt (die Flusssteuerung "Senden von Gi1/4" ist deaktiviert, Gi6/1 ist aktiviert).
Diese Fehlermeldung weist auf eine Geschwindigkeit oder eine Nichtübereinstimmung der Flusssteuerung hin, sodass die Ursache ein Fehler beim Hinzufügen eines Port-Channels ist.
Überprüfen Sie, ob die Schnittstellenkonfiguration am Port-Channel beteiligt ist.
Der Switch meldet diese Fehlermeldung:
%CFIB-7-CFIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched
Die Fehlermeldung zeigt an, dass die Anzahl der installierten Routeneinträge die FIB-Kapazität der Hardware oder den für das angegebene Protokoll festgelegten maximalen Routengrenzwert erreicht. Wenn das Limit erreicht ist, werden einige Präfixe verworfen.
Laden Sie den Router neu, um den Ausnahmemodus zu beenden. Geben Sie den Befehl mls cef maximum-routen im globalen Konfigurationsmodus ein, um die maximale Anzahl von Routen für das Protokoll zu erhöhen. Standardmäßig hat ein PFC3 auf SUP eine Kapazität von 192.000 Einträgen. Wenn Sie jedoch den Befehl mls cef maximum-routen 239 verwenden, können Sie die maximal verfügbaren TCAM-Einträge verwenden. Verwenden Sie den Befehl show mls cef maximum-routen, um die maximalen Routen zu überprüfen. Verwenden Sie den Befehl show mls cef summary , der die Zusammenfassung der CEF-Tabelleninformationen anzeigt, um die aktuelle Verwendung zu überprüfen.
Modul 5 (Supervisor) schlägt den TestMatchCapture-Diagnosetest fehl, wie in dieser Ausgabe aus dem Anzeigeergebnismodul _#:
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
Der TestMatchCapture-Test ist eine Kombination aus dem TestProtocolMatchChannel und den TestCapture-Tests, wie hier beschrieben:
TestProtocolMatchChannel - Der TestProtocolMatchChannel-Test überprüft, ob bestimmte Layer-2-Protokolle in der Layer-2-Weiterleitungs-Engine übereinstimmen. Wenn Sie den Test auf der Supervisor Engine ausführen, wird das Diagnosepaket vom In-Band-Port der Supervisor Engine gesendet und führt eine Paketsuche mit der Layer 2 Forwarding Engine durch. Bei DFC-fähigen Modulen wird das Diagnosepaket vom In-Band-Port der Supervisor Engine über die Switch-Fabric gesendet und von einem der DFC-Ports zurückgeleitet. Die Match-Funktion wird während der Paketsuche für die Diagnose durch die Layer 2 Forwarding Engine überprüft.
TestCapture: Der TestCapture-Test überprüft, ob die Erfassungsfunktion der Layer-2-Forwarding-Engine ordnungsgemäß funktioniert. Die Erfassungsfunktion wird für die Multicast-Replikation verwendet. Wenn Sie den Test auf der Supervisor Engine ausführen, wird das Diagnosepaket vom In-Band-Port der Supervisor Engine gesendet und führt eine Paketsuche mit der Layer 2 Forwarding Engine durch. Bei DFC-fähigen Modulen wird das Diagnosepaket vom In-Band-Port der Supervisor Engine über die Switch-Fabric gesendet und von einem der DFC-Ports zurückgeleitet. Die Capture-Funktion wird während der Paketsuche für die Diagnose durch die Layer 2 Forwarding Engine überprüft.
Setzen Sie das Modul wieder ein, wenn eine Gelegenheit besteht. Da es sich um geringfügige Fehler handelt, können diese ignoriert werden, wenn Sie keine Auswirkungen auf die Leistung sehen.
Der Switch meldet diese Fehlermeldung:
%CONST_DIAG-SP-3-HM_PORT_ERR: Port [dec] on module [dec] failed [dec] consecutive times. Disabling the port.
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%CONST_DIAG-SP-3-HM_PORT_ERR: Port 5 on module 2 failed 10 consecutive times. Disabling the port.
Die Fehlermeldung zeigt an, dass der Datenpfad, der dem Port entspricht, fehlgeschlagen ist. Der Port wird in den Status errdisable gesetzt.
Setzen Sie die Linecard zurück, um festzustellen, ob das Problem selbst behoben wird.
Der Switch meldet diese Fehlermeldung:
%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
Überprüfen Sie die Diagnoseergebnisse:
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
Der TestErrorCounterMonitor überwacht die Fehler/Interrupts jedes Moduls im System, indem regelmäßig Abfragen für die Fehlerzähler durchgeführt werden, die in der Linecard verwaltet werden.
Diese Fehlermeldung wird angezeigt, wenn ein ASIC auf der Linecard Pakete mit schlechtem CRC empfängt. Das Problem kann lokal auf diesem Modul auftreten oder durch ein anderes fehlerhaftes Modul im Chassis ausgelöst werden. Dies kann auch auf Frames mit schlechtem CRC zurückzuführen sein, die von der Pinnacle-Basis des DBUS empfangen wurden. Das heißt, die Fehlermeldungen deuten darauf hin, dass fehlerhafte Pakete über den Bus in Modul 7 empfangen werden.
Einer der Gründe für die Fehlermeldungen ist, dass das Modul aufgrund eines falschen Sitzens des Moduls nicht richtig mit der Backplane des Chassis kommunizieren kann. Das Problem besteht bei der Linecard (am falschen Platz sitzendes Modul), dem Supervisor oder dem Data Bus. Es ist jedoch nicht möglich zu sagen, welche Komponente die Daten beschädigt und einen fehlerhaften CRC verursacht.
Führen Sie zunächst einen Wiedereinsetzen von Modul 7 durch, und vergewissern Sie sich, dass die Schrauben fest angezogen sind. Stellen Sie vor dem erneuten Einsetzen des Geräts die Diagnose auf den Abschluss mit dem Befehl Diagnosestartstufe abgeschlossen ein.
Nach dem Wiedereinsetzen wird die vollständige Diagnose für das Modul ausgeführt. Anschließend können Sie bestätigen, dass auf Modul 7 keine Hardwareprobleme auftreten.
Der Switch meldet diese Fehlermeldung:
%SYS-3-PORT_RX_BADCODE:Port [dec]/[chars] detected [dec] bad code errors in last 30 minutes
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%SYS-3-PORT_RX_BADCODE: Port 3/43 detected 7602 bad code error(s) in last 30 minutes
Diese Fehlermeldung weist darauf hin, dass ein Port von einem unbekannten Protokollfehler betroffen ist. Beispielsweise empfängt ein Catalyst Switch der Serie 6500 Frames mit einem Protokoll, das er nicht kennt oder nicht erkennt. Das erste [dec] ist die Modulnummer, [chars] die Portnummer, und das zweite [dec] ist die Anzahl der eingehenden Pakete mit unbekannten Protokollen, die in den letzten 30 Minuten aufgetreten sind.
Dies sind die möglichen Ursachen der Fehlermeldung:
Aufgrund von falsch eingestellten Geschwindigkeits- und Duplexeinstellungen.
CDP ist auf dem einen und nicht auf dem anderen Ende aktiviert.
Aufgrund von DTP ist dies auf Switch-Schnittstellen standardmäßig aktiviert. Da Router DTP nicht verstehen, kann dies zu Problemen führen.
Überprüfen Sie den Laufzähler auf der Schnittstelle. Wenn sie zunimmt, kann es zu Duplexdiskrepanzen an den Schnittstellen kommen.