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.
In diesem Dokument finden Sie eine kurze Erläuterung der gängigen Syslog-Protokolle und Fehlermeldungen, die bei Cisco Catalyst Switches der Serien 6500/6000 mit Cisco IOS®-Systemsoftware angezeigt werden. Verwenden Sie den Cisco CLI Analyzer (nur für registrierte Kunden), wenn eine Fehlermeldung angezeigt wird, die in diesem Dokument nicht aufgeführt ist. Das Tool liefert die Bedeutung von Fehlermeldungen, die von der Cisco IOS Software und der Catalyst OS (CatOS) Software generiert werden.
Hinweis: Das genaue Format der Syslog- und Fehlermeldungen, die in diesem Dokument beschrieben werden, kann leicht abweichen. Die Variation hängt von der Softwareversion ab, die auf der Supervisor Engine ausgeführt wird.
Hinweis: Diese Mindestkonfiguration für die Protokollierung auf dem 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 Datum und Uhrzeit von einem NTP-Server abzurufen.
Stellen Sie sicher, dass die Protokollierungs- und Protokollierungszeitstempel aktiviert sind. Dies ist die Standardeinstellung.
Konfigurieren Sie den Switch so, dass er sich nach Möglichkeit bei einem Syslog-Server anmeldet.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Der Switch meldet folgende Fehlermeldung:
C6KPWR-SP-4-UNSUPPORTED: nicht unterstütztes Modul in Steckplatz [Num], keine Stromzufuhr zulässig: [Zeichen]
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 zeigt an, dass das Modul im angegebenen Steckplatz nicht unterstützt wird. Die [Zahl] ist die Nummer des Steckplatzes, und [Zeichen] liefert weitere Details über den Fehler.
Aktualisieren Sie die Supervisor Engine-Software auf eine Version, die das Hardwaremodul unterstützt. Weitere Informationen zu dieser Version finden Sie im Abschnitt Unterstützte Hardware der Versionshinweise zu Cisco Catalyst Switches der Serie 6500. Führen Sie eine der folgenden Aktionen aus, um das in der Meldung 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 folgende Fehlermeldung:
%DUAL-3-INTERN: IP-EIGRP 1: Interner Fehler
Die Fehlermeldung zeigt einen internen Fehler in der Cisco IOS Software an. Der Fehler wurde in den folgenden Versionen behoben:
Cisco IOS Software-Version 12.2(0.4)
Cisco IOS Software-Version 12.1(6.1)
Cisco IOS Software, Version 12.2(0.5)T
Cisco IOS Software, Version 12.1(6.5)E
Cisco IOS Software, Version 12.1(6.5)EC
Cisco IOS Software-Version 12.1(6)E02
Cisco IOS Software, Version 12.2(0.18)S
Cisco IOS Software-Version 12.2(2)B
Cisco IOS Software-Version 12.2(15)ZN
Aktualisieren Sie die Cisco IOS Software auf eine dieser Versionen oder die neueste Version.
Der Switch meldet folgende Fehlermeldung:
%EARL_L3_ASIC-SP-4-INTR_THROTTLE: Einschränkung "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 Nachricht gibt an, dass die Switch Forwarding Engine ein IP-Paket empfängt, dessen Länge kürzer als die zulässige Mindestlänge ist. Der Switch verwirft das Paket. In früheren Versionen wurde das Paket stumm verworfen und in den Statistiken der Weiterleitungs-Engine gezählt. Bei späteren Versionen wird die Fehlermeldung alle 30 Minuten im Syslog aufgezeichnet. Diese Probleme können dazu führen, dass die Switch Forwarding Engine diesen IP-Pakettyp empfängt:
Ein beschädigter Treiber für die Netzwerkschnittstellenkarte (NIC)
Ein Netzwerkkartentreiberfehler
Eine fehlerhafte Anwendung
Der Switch meldet lediglich, dass er diese "schädlichen" 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 fehlerhaften Pakete sendet. Die einzige Möglichkeit, das Gerät zu erkennen, besteht darin, einen Sniffer zu verwenden, der die Quelle aufspürt und das Gerät dann ersetzt.
Der Switch meldet folgende Fehlermeldung:
EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: nicht schwerwiegende Unterbrechung [Zeichen]
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 von EARL (Enhanced Address Recognition Logic) Layer 3 (L3) Application-Specific Integrated Circuit (ASIC) ein unerwarteter nicht schwerwiegender Zustand erkannt wurde. Dies weist darauf hin, dass ein fehlerhaftes Paket, wahrscheinlich ein Paket mit einer Layer-3-IP-Prüfsumme, empfangen und verworfen wurde. Die Ursache des Problems ist ein Gerät im Netzwerk, das fehlerhafte Pakete sendet. Diese Probleme können u. a. zu fehlerhaften Paketen führen:
Fehlerhafte NICs
Fehlerhafte NIC-Treiber
Fehlerhafte Anwendungen
In älteren Versionen der Cisco IOS Software werden diese Pakete normalerweise verworfen, ohne protokolliert zu werden. Die Funktion zum Protokollieren von Fehlermeldungen zu diesem Problem ist eine Funktion der Cisco IOS Software, Version 12.2SX und höher.
Diese Nachricht dient lediglich zu Informationszwecken. Verwenden Sie als Problemumgehung eine der beiden folgenden Optionen:
Verwenden Sie einen Netzwerk-Sniffer, um die Quelle zu identifizieren, die die fehlerhaften Pakete sendet. Beheben Sie dann das Problem mit dem Quellgerät oder der Anwendung.
Deaktivieren Sie Layer 3-Fehlerprüfungen in der Switch-Hardware für:
Paketprüfsummenfehler
Paketlängenfehler
Pakete mit identischen Quell- und Ziel-IP-Adressen
Verwenden Sie den Befehl no mls verify, um diese Fehlerprüfungen zu stoppen, 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 folgende Fehlermeldung:
EARL_NETFLOW-4-TCAM_THRLD: Netflow TCAM-Grenzwert überschritten, TCAM-Nutzung [[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 andere Protokolle mit demselben Schweregrad zu beeinträchtigen.
Diese Meldung zeigt an, dass der ternäre Ternary Content Addressable Memory (TCAM) von NetFlow fast voll ist. Aggressives Altern wird vorübergehend aktiviert. Wenn Sie die NetFlow-Maske in den FULL-Modus ändern, kann TCAM für NetFlow aufgrund der großen Anzahl von Einträgen überlaufen. Führen Sie den Befehl show mls netflow ip count aus, um diese Informationen zu überprüfen.
Die Supervisor Engine 720 überprüft, wie voll die NetFlow-Tabelle alle 30 Sekunden ist. Die Supervisor Engine aktiviert aggressives Altern, wenn die Tabellengröße fast 90 Prozent erreicht. Die Idee hinter aggressivem Altern ist, dass der Tisch fast voll ist, sodass es neue aktive Ströme gibt, die nicht erzeugt werden können. Daher ist es sinnvoll, die weniger aktiven Strömungen (oder inaktiven Strömungen) in der Tabelle aggressiv auszulagern, um Platz für aktivere Strömungen zu schaffen.
Die Kapazität der NetFlow-Tabelle (IPv4) für jede Policy Feature Card (PFC) für PFC3a und PFC3b beträgt 128.000 Flows. Die Kapazität des PFC3bXL beträgt 256.000 Flows.
Um dieses Problem zu vermeiden, deaktivieren Sie den FULL NetFlow-Modus. Führen Sie den Befehl no mls flow ip aus.
Hinweis: Im Allgemeinen wirkt sich der Befehl no mls flow ip nicht auf die Paketweiterleitung aus, da TCAM für die Paketweiterleitung und TCAM für die NetFlow-Abrechnung separat sind.
Um sich von diesem Problem zu erholen, aktivieren Sie das MLS-Fast-Aging. Wenn Sie die MLS-Funktion für die schnelle Alterungszeit aktivieren, legen Sie den Wert zunächst auf 128 Sekunden fest. Wenn die Größe des MLS-Caches über 32 K Einträge ansteigt, verkleinern Sie die Einstellung, bis die Cachegröße unter 32 K bleibt. Wenn der Cache weiterhin über 32.000 Einträge wächst, verringern Sie die normale MLS-Alterungszeit. Alle Werte für die Alterungszeit, die nicht ein Vielfaches von 8 Sekunden sind, werden auf das nächste Vielfache von 8 Sekunden eingestellt.
Switch#configure terminal Switch(config)#mls aging fast threshold 64 time 30
Die andere Problemumgehung würde service intern deaktivieren, falls Sie aktiviert haben, und mls flow ip interface-full entfernen, falls Sie keinen vollständigen Flow benötigen.
Switch(config)#no service internal Switch(config)#mls flow ip interface-full
Der Switch meldet diese Fehlermeldung, und der Port wird gezwungen, eine Verbindung herzustellen:
%ETHCNTR-3-LOOP_BACK_DETECTED : Keepalive-Paket-Loopback in [Zeichen] erkannt
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 in eine Schleife zu dem Port zurückgeleitet wird, der das Keepalive-Paket gesendet hat. Keepalives werden an die Catalyst Switches gesendet, um Schleifen im Netzwerk zu verhindern. Keepalives sind standardmäßig auf allen Schnittstellen aktiviert. Dieses Problem tritt auf dem Gerät auf, das die Schleife erkennt und unterbricht, nicht aber auf dem Gerät, das die Schleife verursacht.
Geben Sie den Schnittstellenbefehl no keepalive ein, um Keepalives zu deaktivieren. Eine Deaktivierung des Keepalive verhindert eine Deaktivierung der Schnittstelle, entfernt jedoch nicht die Schleife.
Hinweis: Ab Version 12.2(x)SE der Cisco IOS Software werden Keepalives standardmäßig nicht mehr an Glasfaser- und Uplink-Schnittstellen gesendet.
Der Switch meldet folgende Fehlermeldung:
loadprog: error - on file open boot: cannot load "bootflash:c6msfc2-boot-mz.121-8a.EX"
Das Problem tritt nur bei nicht ausgerichtetem Schreiben auf das Gerät auf, das sich in der Nähe einer internen 64-Byte-Grenze befindet. Das Problem kann unter folgenden Umständen auftreten:
Während des Schreibens einer Absturz-Dump-Datei
Etwas führt dazu, dass das System zum Zeitpunkt des Schreibens der Datei abstürzt.
Wenn Code während der Migration von CatOS auf Cisco IOS-Software beschädigt ist
Die Problemumgehung besteht darin, den Gerätetreiber so zu ändern, dass er den nicht ausgerichteten Zugriff richtig handhabt. Wenn der Fehler aufgrund einer Codebeschädigung während der Migration von CatOS zu Cisco IOS-Software auftritt, löschen Sie den Flash-Speicher, und laden Sie ein neues, gültiges CatOS-Software-Image herunter.
Der Switch meldet folgende Fehlermeldung:
%L3_ASIC-DFC3-4-ERR_INTRPT: Interrupt TF_INT:FI_DATA_INT in EARL %Layer 3 ASIC
Diese Fehlermeldung gibt an, dass ein Fehler im Layer 3 (L3) Forwarding Application-Specific Integrated Circuit (ASIC) vorliegt. Im Grunde zeigt der Switch diese Meldung an, wenn ein Teil des transienten Datenverkehrs den ASIC passiert, und die Software meldet lediglich das Auftreten einer Interrupt-Bedingung. Sobald diese Bedingung erfüllt ist, werden die Zähler, die der Befehl show earl statistics anzeigt, erhöht. Bei jedem Wiederherstellungsversuch eines solchen Zustands durch die Software generiert der Switch diese Syslog-Meldung. Im Allgemeinen ist diese Nachricht informativ, wenn ihr Auftreten gering bleibt. Tritt die Fehlermeldung jedoch häufig auf, kann ein Problem mit der Hardware auftreten.
Überprüfen Sie den Zählerwert in der Befehlsausgabe Frühe Statistiken anzeigen. Wenn die Zähler schnell ansteigen, weist dies auf ein mögliches Problem mit der Hardware hin.
Der Switch meldet folgende Fehlermeldung:
%MLS_STAT-SP-4-IP_LEN_ERR: Inkonsistenzen der 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 Nachrichten zeigen an, dass Pakete empfangen wurden, deren IP-Länge nicht mit der MAC-Länge des Pakets übereinstimmt. Die Supervisor Engine verwarf diese Pakete. Der Switch hat keine negativen Auswirkungen, da die Pakete verworfen werden. 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. zu fehlerhaften Paketen führen:
Fehlerhafte NICs
Fehlerhafte NIC-Treiber
Fehlerhafte Anwendungen
Verwenden Sie einen Netzwerk-Sniffer, um die Quelle zu finden, die die fehlerhaften Pakete sendet. Beheben Sie dann das Problem mit dem Quellgerät oder der Anwendung.
Die andere Problemumgehung besteht in einer Switch-Konfiguration, bei der die Switch-Prüfungen auf Folgendes beendet werden:
Paketprüfsummenfehler
Paketlängenfehler
Pakete mit identischen 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 folgende 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 zeigen an, dass der Switch IP-Pakete mit einer ungültigen Prüfsumme empfängt. Der Switch hat keine negativen Auswirkungen, da die Pakete verworfen werden. 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. zu fehlerhaften Paketen führen:
Fehlerhafte NICs
Fehlerhafte NIC-Treiber
Fehlerhafte Anwendungen
Verwenden Sie als Problemumgehung eine der beiden folgenden Optionen:
Verwenden Sie einen Netzwerk-Sniffer, um die Quelle zu identifizieren, die die fehlerhaften Pakete sendet. Beheben Sie dann das Problem mit dem Quellgerät oder der Anwendung.
Deaktivieren Sie Layer 3-Fehlerprüfungen in der Switch-Hardware für beide:
Paketprüfsummenfehler
Paketlängenfehler
Um diese Fehlerprüfungen zu beenden, verwenden Sie den Befehl no mls verify, 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 folgende 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 Nachricht zeigt an, 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 IGMP-Steuerungsdatenverkehr reserviert, z. B.:
Blätter
Teilt
Allgemeine Abfragen
Die Switch-CPU verarbeitet normalerweise den gesamten IGMP-Steuerungsdatenverkehr. Aus diesem Grund bietet die Cisco IOS Software einen Mechanismus, um übermäßigen IGMP-Multicast-Verkehr 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.
Suche nach der Quelle des illegalen Multicast-Datenverkehrs Anschließend wird entweder die Übertragung gestoppt oder die Eigenschaften des Streams geändert, sodass die Übertragung nicht mehr den IGMP-Kontrolldatenraum beeinträchtigt. Verwenden Sie außerdem die Fehlermeldung im Abschnitt Problem (Problem), der eine Netzwerkquelle angibt, die das Problem möglicherweise verursacht.
Der Switch meldet folgende Fehlermeldung:
c6k_pwr_get_fru_present(): fru_info für fru Typ 6 kann nicht gefunden werden, #
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 beim SNMP-Polling (Simple Network Management Protocol) der von Flex WAN-Modulen verwendeten Port-Adapter eine fehlerhafte Antwort erhalten hat. Diese Fehlermeldung wirkt sich nur kosmetisch aus, und es treten keine Probleme mit der Switch-Leistung auf. Das Problem wurde in den folgenden Versionen behoben:
Cisco IOS Software, Version 12.1(11b)E4
Cisco IOS Software, Version 12.1(12c)E1
Cisco IOS Software-Version 12.1(13)E
Cisco IOS Software-Version 12.1(13)EC
Spätere Versionen
Der Switch meldet folgende Fehlermeldung:
%MROUTE-3-WHEEL_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 ankündigen. Die Pakete melden einen höheren Haltezeitwert als die maximale Verzögerung, die das Betriebssystem des Switches zulässt, nämlich 4 Minuten. Bei diesen Paketen handelt es sich um Multicast-Kontrollpakete wie PIM, Distance Vector Multicast Routing Protocol (DVMRP) und andere Typen.
Bei späteren Versionen der Cisco IOS Software für den Catalyst 6500/6000 beträgt die maximale Verzögerung jetzt 65.535 Sekunden bzw. ca. 17 Minuten. Das Problem wurde in den folgenden Versionen behoben:
Cisco IOS Software-Version 12.1(12c)E
Cisco IOS Software, Version 12.2(12)T01
Cisco IOS Software-Version 12.1(13)E
Cisco IOS Software-Version 12.1(13)EC
Spätere Versionen
Konfigurieren Sie das Drittanbietergerät, das die PIM-Pakete generiert, für die Verwendung von Timern, die von Protokollstandards empfohlen werden.
Der Switch meldet folgende Fehlermeldung:
%MCAST-SP-6-GC_LIMIT_EXCEEDED
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 von Layer-2 (L2)-Einträgen erstellt hat. Standardmäßig kann der Switch maximal 15.488 L2-Einträge für Multicast-Gruppen erstellen. In späteren Versionen der Cisco IOS-Software werden nur die hardwareinstallierten L2-Multicast-Einträge bis zum Grenzwert berücksichtigt. Weitere Informationen finden Sie unter der Cisco Bug-ID CSCdx89380 (nur für registrierte Kunden). Das Problem wurde in Version 12.1(13)E1 und höher der Cisco IOS-Software behoben.
Sie können die L2-Grenze manuell erhöhen. Führen Sie den Befehl ip igmp l2-entry-limit aus.
Der Switch meldet folgende Fehlermeldung:
%MISTRAL-SP-3-FEHLER: Fehlerzustand 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 zeigt an, dass im Zeiger auf der nächsten Seite des internen Tabellen-Managers ein Paritätsfehler aufgetreten ist. Wenn auf dem Switch die Cisco IOS Software Version 12.1(8)E oder höher ausgeführt wird, erkennt der Switch den Paritätsfehler und setzt den Mistral ASIC zurück. Der Switch kann dann fortgesetzt werden, ohne dass ein Neuladen erforderlich ist. Eine zufällige statische Entladung oder andere externe Faktoren können den Paritätsfehler des Speichers verursachen. Wenn die Fehlermeldung nur einmal oder selten angezeigt wird, überwachen 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 folgende Fehlermeldung:
%MLS_STAT-4-IP_TOO_SHRT: Zu kurze empfangene IP-Pakete
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 Nachricht gibt an, dass die Switch Forwarding Engine ein IP-Paket empfängt, dessen Länge kürzer als die zulässige Mindestlänge ist. Der Switch verwirft das Paket. In früheren Versionen wurde das Paket stumm verworfen und in den Statistiken der Weiterleitungs-Engine gezählt. Dies gilt für Softwareversionen vor Version 7.x oder vor Version 12.1(13E) der Cisco IOS-Software. Bei Softwareversionen nach Version 7.x oder höher als Version 12.1(13E) der Cisco IOS-Software wird die Meldung alle 30 Minuten im Syslog aufgezeichnet.
Auf der Switch-Seite gibt es keine Auswirkungen. Der Switch verwirft das fehlerhafte Paket, das das empfangende Gerät dann verworfen hätte. Die einzige Sorge besteht darin, dass ein Gerät fehlerhafte Pakete sendet. Mögliche Ursachen:
Fehlerhafter NIC-Treiber
Ein Netzwerkkartentreiberfehler
Eine fehlerhafte Anwendung
Aufgrund von Hardware-Einschränkungen verfolgt die Supervisor Engine nicht die Quell-IP, MAC-Adresse oder den Port des Geräts, das böse Pakete sendet. Sie müssen eine Anwendung zum Erkennen von Paketen verwenden, um diese Geräte zu erkennen und die Quelladresse zu ermitteln.
Die Meldung im Abschnitt "Problem" ist lediglich eine Warnung/Informationsmeldung des Switches. Die Nachricht enthält keine Informationen über den Quellport, die MAC- oder IP-Adresse.
Verwenden Sie eine Anwendung zum Ermitteln von Paketen innerhalb des Netzwerks. 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 folgende Fehlermeldung:
Prozessor [Nummer] des Moduls in Steckplatz [Nummer] kann Sitzungsanfragen nicht bearbeiten
Dieser Fehler tritt auf, wenn Sie den Befehl session slot number processor number in einem Versuch, eine Sitzung in den folgenden Situationen einzurichten, ausführen:
Sie versuchen, eine Sitzung mit einem Modul herzustellen, in dem bereits eine Sitzung hergestellt wurde, während Sie sich beim Switch anmelden.
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 herzustellen.
Der Switch meldet folgende Fehlermeldung:
%PM_SCP-1-LCP_FW_ERR: Systemrücksetzmodul [dec] zur Wiederherstellung nach Fehler: [chars]
Die folgenden Beispiele zeigen die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%PM_SCP-SP-1-LCP_FW_ERR: Systemrücksetzmodul 13 zur Wiederherstellung nach Fehler: Linecard hat Systemausnahme empfangen
Oder
%PM_SCP-SP-1-LCP_FW_ERR: System setzt Modul 4 zurück, um den Fehler zu beheben: Coil Pb Rx Parity Error - Port #14
Die Meldung zeigt an, 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] der Fehler.
Setzen Sie das Modul wieder ein, oder stecken Sie es in einen anderen Steckplatz, und führen Sie den vollständigen Diagnosetest für den Systemstart durch. Weitere Informationen zur Online-Diagnose für die Catalyst Switches der Serie 6500 finden Sie unter Configuring Online Diagnostics (Konfigurieren der Online-Diagnose). Nachdem das Modul den Diagnosetest bestanden hat, überprüfen Sie die Wiederholung der Fehlermeldung. Wenn der Fehler erneut auftritt oder der Diagnosetest Probleme feststellt, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco, um den Fehler weiter zu beheben.
Der Switch meldet folgende Fehlermeldung:
%PM_SCP-2-LCP_FW_ERR_INFORM: Fehler im Modul [dec]: [chars]
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
%PM_SCP-SP-2-LCP_FW_ERR_INFORM: Modul 4 zeigt folgenden Fehler an: Bus Asic #0 transient Pb error
Das Modul meldet einen Fehlerzustand, wobei [dec] die Modulnummer und [chars] der Fehler ist. Dieser Zustand wird in der Regel durch eine falsch eingesetzte Linecard oder einen Hardwarefehler verursacht. Wenn die Fehlermeldung auf allen Linecards angezeigt wird, liegt die Ursache in einem falsch sitzenden Modul.
Setzen Sie die Linecard oder das Modul wieder ein, und setzen Sie es zurück. Führen Sie dann den Befehl show diagnostic result module module_# aus."
Wenn die Fehlermeldung nach dem Zurücksetzen des Moduls weiterhin angezeigt wird, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco, um weitere Fehlerbehebungsmaßnahmen durchzuführen.
Der Switch meldet folgende Fehlermeldung:
%PM_SCP-SP-2-LCP_FW_ERR_INFORM: Modul 4 zeigt folgenden Fehler an: Port #36 transienter TX Pb-Fehler
Diese Fehlermeldung weist auf einen vorübergehenden Fehler in 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 schließen Sie den Port Gi4/36, und überwachen Sie, ob das Problem erneut auftritt.
Wenn der Fehler erneut auftritt, setzen Sie die Diagnose mit dem Befehl diagnose bootup level complete auf complete. Setzen Sie dann die Linecard wieder ein.
Wenn die Fehlermeldung auch nach dem Wiedereinsetzen des Moduls angezeigt wird, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco, um weitere Fehlerbehebungen mithilfe der folgenden Befehlsausgaben durchzuführen:
Der Switch meldet folgende Fehlermeldung:
%PM_SCP-SP-4-UNK_OPCODE: Unbekannte unaufgeforderte Nachricht vom Modul [dec] empfangen, Opcode [hex]
Die folgenden Beispiele zeigen die Konsolenausgabe, die angezeigt wird, wenn dieses Problem auftritt:
10.12.12:44:18.117: %PM_SCP-SP-4-UNK_OPCODE: Unbekannte unsolicited Message von Modul 2 empfangen, opcode 0x330
Oder
10. Dez. 12:44:25.2010: %PM_SCP-SP-4-UNK_OPCODE: Unbekannte unsolicited Message von Modul 2 empfangen, opcode 0x114
Diese Fehlermeldung zeigt lediglich an, dass die Supervisor Engine die Kontrollmeldung der Linecard aufgrund von Funktionen nicht versteht, die von der Cisco IOS Software-Version des Switches nicht unterstützt werden.
Linecards senden Kontrollmeldungen an die aktive Supervisor Engine, die die von der Software unterstützten Funktionen angeben. Wenn die Software jedoch keine der Linecard-Funktionen unterstützt, werden diese Steuermeldungen nicht erkannt und die Fehlermeldung wird angezeigt. Diese Meldung tritt harmlos auf 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 folgende Fehlermeldung:
%PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM: Fehler bei der Integritätsprüfung des Transceivers im LAN-Port 5/2: Falscher Schlüssel
Der Grund für diese Fehlermeldung ist die Verwendung von SFP GBIC, die nicht von Cisco stammt und nicht unterstützt wird.
Die Cisco SFP GBICs verfügen über einen eindeutigen verschlüsselten Code (Qualitäts-ID), mit dem das Cisco IOS/CAT OS die austauschbaren Komponenten von Cisco erkennen kann. 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 folgende 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 senden und keine Seite der Verbindung eine Kollision erkennt. Der Grund für dieses Auftreten ist, dass für das Weiterleiten des Signals von einem Ende des Netzwerks zu einem anderen mehr Zeit benötigt wird als dafür, das gesamte Paket im Netzwerk zu platzieren. Die beiden Geräte, die die späte Kollision verursachen, bekommen nie mit, dass das jeweils andere Gerät sendet, bis das gesamte Paket im Netzwerk platziert wurde. Späte Kollisionen werden vom Sender erst nach dem ersten 64-Byte-Zeitrahmen erkannt. Dies liegt daran, dass sie nur bei der Übertragung von Paketen erkannt werden, die länger als 64 Byte sind.
Mögliche Ursachen - Verspätete Kollisionen sind das Ergebnis von Duplexdiskrepanzen, falschen Kabeln oder einer nicht konformen Anzahl von Hubs im Netzwerk. Späte Kollisionen können auch durch fehlerhafte NICs verursacht werden.
Der Switch meldet folgende Fehlermeldung:
%PM-3-INVALID_BRIDGE_PORT: Bridge Port number is out of range
Dieses Problem erscheint kosmetisch und ist auf eine SNMP-Abfrage des mib dot1dTpFdbEntry zurückzuführen.
Auf diesem Gerät können Sie das Polling der OID blockieren. Dieser Fehler wurde in Cisco IOS, Version 12.2(33)SRD04 und höher, behoben.
Der Switch meldet folgende Fehlermeldung:
%QM-4-TCAM_ENTRY: Hardware-TCAM-Eintrittskapazität überschritten
TCAM ist ein spezieller Speicher für schnelle Tabellensuchen durch die ACL- und QoS-Engines. Diese Meldung zeigt an, dass die TCAM-Ressourcen und das Software-Switching der Pakete erschöpft sind. Das bedeutet, dass jede Schnittstelle ihre eigene ID im TCAM hat und daher mehr TCAM-Ressourcen verwendet. Dieses Problem wird wahrscheinlich durch den Befehl mls qos marking statistics verursacht, 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, die gleichen ACLs über mehrere Schnittstellen hinweg zu verwenden, um den Konflikt mit den TCAM-Ressourcen zu reduzieren.
Der Switch meldet folgende Fehlermeldung:
%slot_earl_icc_shim_addr: Steckplatz [num] ist weder SuperCard noch Supervisor - Ungültiger Steckplatz
Diese Meldung wird angezeigt, wenn ein SNMP-Manager eine Abfrage nach TCAM-Daten einer Linecard durchführt, die über keine TCAM-Informationen verfügt. Dies ist nur bei einer Linecard in einem Catalyst Switch der Serie 6500 der Fall, 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 der Cisco Bug-ID CSCec39383 (nur für registrierte Kunden). Dieses Problem wurde in Version 12.2(18) der Cisco IOS-Software behoben.
Als Workaround können Sie die Abfrage von TCAM-Daten durch die NMSs blockieren. Das MIB-Objekt, das TCAM-Verwendungsdaten bereitstellt, ist "cseTcamUsageTable". Führen Sie die folgenden Schritte auf dem Router aus, um Rückverfolgungen zu vermeiden:
Führen Sie den Befehl snmp-server view tcamBlock caseTcamUsageTable excluded aus.
Geben Sie den Befehl snmp-server view tcamBlock iso included ein.
Geben Sie den Befehl snmp-server community public view tcamBlock ro ein.
Geben Sie den Befehl snmp-server community private view tcamBlock rw ein.
Der Switch meldet folgende Fehlermeldung:
%SYSTEM_CONTROLLER-SP-3-FEHLER: Fehlerzustand 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 des 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 zeigt an, dass ein Paritätsfehler aufgetreten ist. Prozessorspeicher-Paritätsfehler (PMPE) werden in zwei Typen unterteilt: Single Event Upset (SEU) und wiederholte Fehler.
Diese Einzelbitfehler treten auf, wenn sich ein Bit in einem Datenwort aufgrund externer Ereignisse unerwartet ändert (was beispielsweise dazu führt, dass eine Null spontan auf eine Eins wechselt). SEU sind ein universelles Phänomen, unabhängig von Anbieter oder Technologie. SEUs treten nur sehr selten auf, aber alle Computer- und Netzwerksysteme, selbst ein PC, unterliegen ihnen. SEUs werden auch als weiche Fehler bezeichnet, die durch Rauschen verursacht werden und zu einem vorübergehenden, inkonsistenten Fehler in den Daten führen. Dies hat nichts mit einem Komponentenausfall zu tun - meist das Ergebnis kosmischer Strahlung.
Wiederholte Fehler (häufig als schwerwiegende Fehler bezeichnet) werden durch fehlerhafte Komponenten verursacht. Ein schwerwiegender Fehler wird durch ein ausgefallenes Bauteil oder ein Problem auf Platinenebene verursacht, z. B. eine falsch hergestellte Leiterplatte, die zu wiederholten Vorkommen desselben Fehlers führt.
Wenn die Fehlermeldung nur einmal oder selten angezeigt wird, überwachen Sie das Switch-Syslog, um sicherzustellen, dass es sich bei der Fehlermeldung um einen isolierten Vorfall handelt. Wenn diese Fehlermeldungen erneut auftreten, setzen Sie den Supervisor Engine-Blade erneut ein. Wenn die Fehler aufhören, war es ein harter Paritätsfehler. Wenn diese Fehlermeldungen weiter auftreten, erstellen Sie ein Ticket beim Technical Assistance Center.
Der Switch meldet folgende Fehlermeldung:
%SYSTEM_CONTROLLER-SW2_SPSTBY-3-FEHLER: Fehlerzustand erkannt: TM_NPP_PARITY_ERROR
Diese Fehlermeldung zeigt an, dass ein Paritätsfehler aufgetreten ist und mögliche Ursachen eine zufällige statische Entladung oder andere externe Faktoren sind, die den Speicherparitätsfehler verursachen, wie z. B. eine vorübergehende Rückwandverbindung, oder aufgrund von Stromversorgungsproblemen auftreten können, und manchmal kann die Linecard nicht auf den seriellen PROM (SPROM)-Inhalt auf dem Modul 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), die manchmal als Paritätsfehler bezeichnet werden. Diese Einzelbitfehler treten dann auf, wenn sich ein Bit in einem Datenwort aufgrund externer Ereignisse unerwartet ändert und damit beispielsweise eine Null spontan auf eine Eins wechselt. SEU sind ein universelles Phänomen, unabhängig von Anbieter und Technologie. SEUs treten nur sehr selten auf, aber alle Computer- und Netzwerksysteme, selbst ein PC, unterliegen ihnen. SEUs werden auch als weiche Fehler bezeichnet, die durch Rauschen verursacht werden und zu einem vorübergehenden, inkonsistenten Fehler in den Daten führen und nicht mit einem Komponentenausfall in Zusammenhang stehen.
Wiederholte Fehler, häufig als schwerwiegende Fehler bezeichnet, werden durch fehlerhafte Komponenten verursacht. Ein schwerwiegender Fehler wird durch eine fehlerhafte Komponente oder ein Problem auf Platinenebene verursacht, z. B. eine falsch hergestellte Leiterplatte, die zu einem wiederholten Auftreten desselben Fehlers führt.
Wenn diese Fehlermeldungen erneut auftreten, setzen Sie das Supervisor-Modul während des Wartungsfensters wieder ein.
Der Switch meldet folgende Fehlermeldung:
SP: Linecard-Endpunkt von Kanal 14 hat Sync. an untere Fabric verloren und versucht, jetzt wiederherzustellen!
Die Fehlermeldung verweist in der Regel auf eine falsch eingesetzte Linecard. In den meisten Fällen können Sie die Linecard physisch wieder einsetzen, um dieses Problem zu lösen. In einigen Fällen ist das Modul fehlerhaft.
Führen Sie den Befehl show fabric fpoe map aus, 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 fpoe map. Anhand der Ausgabe können Sie feststellen, 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 wieder ein, wodurch die Fehlermeldung verursacht wird.
Während ein Cisco Catalyst 6000/6500 Switch bootet, kann er eine ähnliche Fehlermeldung auslösen:
%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 meistens dann auf, wenn die Boot-Variablen nicht richtig konfiguriert sind, um den Switch von einem gültigen Flash-Gerät zu booten.
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 des IOS-Dateinamens, s72033, stellt fest, dass das IOS für das Supervisor-Modul 720 ist. Das Supervisor 720-Modul verfügt nicht über ein Flash-Gerät mit dem Namen bootdisk oder unterstützt dieses. Da das Supervisor 720-Modul nicht über einen lokalen Flash-Speicher mit diesem Namen verfügt, denkt der Switch, dass Sie vom Netzwerk booten möchten. Daher wird die Fehlermeldung angezeigt.
Konfigurieren Sie die Boot-Variable mit dem richtigen Flash-Gerätenamen und dem gültigen Softwaredateinamen.
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: | Onboard-Flash-Speicher |
Steckplatz0: | Lineare Flash-PC-Karte (PCMCIA-Steckplatz) |
disk0: | ATA-Flash-PC-Karte (PCMCIA-Steckplatz) |
Supervisor Engine 720
Name des Flash-Geräts | Beschreibung |
---|---|
Bootflash: | Onboard-Flash-Speicher |
disk0: | Nur CompactFlash-Karte Typ II (Festplattensteckplatz 0) |
Festplatte1: | CompactFlash-Karte Typ II (Festplatte mit 1 Steckplatz) |
Supervisor Engine 32
Name des Flash-Geräts | Beschreibung |
---|---|
Bootdisk: | Onboard-Flash-Speicher |
disk0: | Nur CompactFlash-Karte Typ II (Festplattensteckplatz 0) |
Wenn das Problem dadurch nicht behoben wird, finden Sie weitere Informationen unter Wiederherstellen eines Catalyst 6500/6000 mit Cisco IOS System-Software aus einem beschädigten oder fehlenden Boot Loader-Image oder ROMmon-Modus.
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 zeigen an, dass CPU-Überwachungsmeldungen über einen längeren Zeitraum nicht gehört wurden. Wahrscheinlich tritt ein Timeout auf, wodurch das System zurückgesetzt wird. [dec] die Anzahl der Sekunden.
Das Problem kann aus folgenden Gründen auftreten:
Schlecht sitzende Linecard oder Modul
Fehlerhafte 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-Datenverkehr (Simple Network Management Protocol) und Pakete, die für den Switch bestimmt sind. Wenn der EOBC-Kanal aufgrund einer Flut von SNMP-Datenverkehr voller Nachrichten ist, kommt es zu Kollisionen mit dem Kanal. In diesem Fall ist EOBC möglicherweise nicht in der Lage, IPC-Nachrichten zu übertragen. Dadurch wird die Fehlermeldung angezeigt.
Setzen Sie die Linecard oder das Modul wieder ein. Wenn ein Wartungsfenster eingeplant werden kann, setzen Sie den Switch zurück, um vorübergehende Probleme zu beheben.
Die Fehlermeldung %Invalid IDPROM image for linecard (Ungültiges IDPROM-Image für Linecard) wird in Switches der Serie Catalyst 6500 empfangen, auf denen Cisco IOS-Systemsoftware ausgeführt wird.
Die Fehlermeldung kann wie folgt 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 zeigt an, dass die installierten Linecards nicht richtig gestartet wurden, da der Supervisor ein fehlerhaftes Signal auf dem Steuerbus erzeugt hat. In einigen Szenarien kann es vorkommen, dass ein falscher Sitz auch dazu führen kann, dass der Supervisor oder die Linecards auf dem Cat6500-Chassis nicht erkannt werden. Weitere Informationen finden Sie unter der Cisco Bug-ID CSCdz6585 (nur für registrierte Kunden).
Wenn ein redundantes Supervisor-Setup verfügbar ist, führen Sie einen erzwungenen Switchover durch, und setzen Sie den ursprünglich aktiven Supervisor wieder ein.
Wenn es sich um eine einzelne Supervisor-Konfiguration handelt, planen Sie eine Ausfallzeit, und gehen Sie wie folgt vor:
Setzen Sie das Supervisor-Modul in einen anderen Steckplatz ein.
Setzen Sie alle Linecards wieder ein, und stellen Sie sicher, dass sie richtig eingesetzt wurden.
Weitere Informationen zum Online-Einsetzen und Entfernen von Modulen in Cisco Catalyst Switches finden Sie unter Online Insertion and Removal (OIR).
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 alle zwei Sekunden einen SCP-Ping an jede Linecard. Wenn nach 3 Pings (6 Sekunden) keine Antwort eingeht, wird sie als erster Fehler gezählt. Nach 25 aufeinander folgenden Ausfällen oder nach 150 Sekunden, in denen die Linecard keine Antwort erhalten hat, schaltet der Supervisor die Linecard ein und aus. 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 mit den folgenden Syslogs neu gestartet:
%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 folgende 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 zeigt an, dass das Modul im angegebenen Steckplatz aus dem angegebenen Grund ausgeschaltet wurde. [dec] steht für die Steckplatznummer und [chars] steht für den Stromversorgungsstatus.
Der Switch hat seine normalen Schwingungen, die im Laufe der Zeit dazu führen können, dass sich ein Modul leicht von der Rückwandplatine löst. Wenn dies geschieht, 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 ihm herzustellen. Wenn das Modul immer noch nicht auf die Umfragen reagiert, startet der Supervisor das Modul kontinuierlich neu, deaktiviert es schließlich fehlerhaft und lässt keine Stromversorgung zu, um das Modul zu erreichen.
Ein einfaches Wiedereinsetzen des Moduls behebt dieses Problem 90 Prozent der Zeit. Wenn Sie das Modul wieder einsetzen, wird die Switch-Struktur neu ausgerichtet und eine feste Verbindung zur Rückwandplatine sichergestellt.
Wenn es sich bei dem betroffenen 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 wird unter der Cisco Bug-ID CSCei85928 (gegen CSM-Software) (nur registrierte Kunden) und der Cisco Bug-ID CSCek28863 (gegen Cisco IOS-Software) (nur registrierte Kunden) dokumentiert.
Die aktuelle CSM-Software kann von der Seite zum Herunterladen der Cisco Catalyst 6000 Content Switching-Module-Software heruntergeladen werden.
Der Switch meldet die folgende 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 normalerweise durch einen schlechten 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 folgende 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 Anforderung der Flussmaske für die flussbasierte Funktion ist fehlgeschlagen. Diese Bedingung kann aufgrund einer TCAM-Ressourcenausnahme auftreten, eine Flussmaske registriert eine Ressourcenausnahme oder eines nicht auflösbaren Konflikts mit einer Flussmaske mit anderen NetFlow-basierten Funktionen. Die NetFlow-Shortcut-Installation und Hardwarebeschleunigung für die Funktion können unter dieser Bedingung deaktiviert und in der Software angewendet werden.
Wenn für verschiedene Schnittstellen reflexive Eingangs-ACLs, Reflexions- und Eval-ACLs in Eingangsrichtung konfiguriert wurden, basiert die Anforderung der reflexiven ACL-Flussmaske auf reflexiven Eingangs-ACLs. Solange die reflexive ACL auf einer anderen Schnittstelle als die QoS-Microflow-Regelung konfiguriert ist oder sich nicht mit der Microflow-Regelung ü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 überlappen, deaktiviert die reflexive ACL die NetFlow-Shortcut-Installation, und der Datenverkehr passt an die reflexive ACL wird per Software-Switching angepasst. Dies liegt an den widersprüchlichen Anforderungen für die Flussmaske.
Bei einer reflexiven Ausgangs-ACL ist die Anforderung für die reflexive ACL-Flussmaske auf allen Schnittstellen global, da nur Ingress-NetFlow vorhanden ist. Wenn in diesem Fall QoS-benutzerbasierte Microflow Policing konfiguriert ist, deaktiviert die reflexive ACL die NetFlow-Shortcut-Installation, und der Datenverkehr, der mit der reflexiven ACL abgeglichen wird, wird per Software-Switching weitergeleitet.
Führen Sie den Befehl show fm file flowmask aus, um den NetFlow-Shortcut-Installationsstatus zum Aktivieren/Deaktivieren der Funktion zu bestimmen. Wenn die NetFlow-Shortcut-Installation und die Hardwarebeschleunigung für diese Funktion deaktiviert sind, verwenden Sie nur reflexive Eingangs-Zugriffslisten in Kombination mit Microflow Policing, und stellen Sie sicher, dass sich die Microflow Policer nicht mit der reflexiven Zugriffsliste überschneiden. Wenden Sie die Funktion erneut an, damit die Anforderung der Flussmaske erfolgreich ausgeführt werden kann, und aktivieren Sie die NetFlow-Shortcut-Installation für die Funktion erneut.
Der Switch meldet die folgende 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-Datenverkehr. Diese Situation erzwingt, dass Multicast-Pakete an den Routing-Prozessor weitergeleitet werden und diesen möglicherweise überfluten. IGMP-Snooping kann aufgrund von übermäßigem Multicast-Verkehr automatisch deaktiviert werden. IGMP-Snooping betrachtet im Wesentlichen diese Steuerungspakete, die zwischen Routern und Hosts ausgetauscht werden, und aktualisiert auf Basis der Joins, Laute und Abfragen, welche Ports das Multicast empfangen.
Diese Meldung tritt in der Regel auf, weil der Routingprozessor eine viel höhere Rate an IGMP-Join-Paketen oder normalen Multicast-Paketen empfängt, die für reservierte Layer-3-/Layer-2-Multicast-Adressbereiche bestimmt sind. Aus diesem Grund gehen dem Switch die Ressourcen aus, und da die Protokollnachrichten berichten, reduziert 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 höhere Anzahl festlegen.
Die Ratenbegrenzung ist eine wünschenswertere Methode, damit die Warteschlange nicht überlaufen wird. Sie bedeutet auch, dass gültige IGMP-Pakete eine geringere Wahrscheinlichkeit haben, verworfen zu werden, und dass der Snooping-Prozess auf dem Switch daher weiterhin entsprechend aktualisiert werden kann.
Führen Sie die folgenden Schritte aus, 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, dass die MAC-Adresse zu der 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 beiden 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
Ursache dieses Fehlers ist möglicherweise ein defektes Modul oder ein falsch sitzendes Modul. Bei diesem Steckplatz kann es sich auch um ein Gehäuseproblem handeln. Dies kann ein vorübergehendes Problem sein, wenn es auf ein falsch angebrachtes Modul zurückzuführen ist.
Diese Meldungen zeigen an, dass das System nicht wiederherstellbare Ressourcen erkannt hat, was auf das FIFO-Problem (First In, First Out) auf dem angegebenen Pinnacle ASIC oder dem angegebenen Port-ASIC zurückzuführen ist.
Geben Sie den Befehl remote command switch show platform hardware asicreg pinnacle slot 1 port 1 err ein, 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. Der Befehl kann nicht mit der Tab-Taste geschrieben werden.
Führen Sie den Befehl diagnose bootup level complete aus, um die Diagnoseebene auf complete 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 diagnostic aus, um den Switch zu überwachen und zu überprüfen, ob die Fehlermeldung weiterhin angezeigt wird.
Der Switch meldet folgende Fehlermeldungen:
%C6KERRDETECT-SP-4-SWBUSSTALL: Der Switching-Bus hält 3 Sekunden lang an.
%C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERED: Der Switching-Bus-Absturz wird wiederhergestellt, und das Switching für den Datenverkehr wird fortgesetzt.
Die Nachricht %C6KERRDETECT-SP-4-SWBUSSTALL zeigt an, dass der Switching-Bus gestoppt ist und Datenverkehr verloren geht.
Die Nachricht %C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERED gibt an, dass der Switching-Bus nicht mehr angehalten wird und der Datenverkehr fortgesetzt werden kann.
Wenn ein Modul am Systembus hängt, erkennt der Supervisor ein Timeout und versucht, das System selbst wiederherzustellen. Wenn ein Modul gerade installiert wurde, dann ist dies eine sehr mögliche Ursache für diese Meldungen, da dies zu einem Busabsturz führen kann, während das Modul in die Backplane eingesetzt wird.
Diese Fehlermeldung wird angezeigt, wenn die In-Band-Test-Pings nicht zu einer hohen CPU-Auslastung führen:
SP-RP Ping Test[7]: Test skipped due to high traffic/CPU utilization
Der SP-RP-In-Band-Ping ist ein Online-Diagnosetest, und die Meldung, dass der SP-RP-Ping-Test fehlgeschlagen ist, dient lediglich zu Informationszwecken. Sie weist auf eine hohe CPU-Auslastung hin und kann das Ergebnis eines hohen Datenverkehrs sein, der an den Routingprozessor weitergeleitet wird, oder von Switching-Datenverkehr, der an den Switchprozessor weitergeleitet wird. Dies kann auch bei Routen-Updates der Fall sein. Es ist normal, dass die Route-Prozessor-CPU manchmal bis zu 100 Prozent beansprucht.
Die Fehlermeldung dient lediglich zu Informationszwecken und hat keine Auswirkungen auf die Geräteleistung.
Der Switch meldet folgende 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 Serie 6500 verfügt über 4094 VLANs, die für verschiedene Zwecke verwendet werden. Führen Sie den Befehl show platform hardware capacity vlan aus, um den aktuellen Status der VLAN-Verfügbarkeit anzuzeigen.
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 sind, da sie den empfohlenen Grenzwert überschreitet.
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 dokumentiert (nur für registrierte Kunden), und das Problem wurde in den Cisco IOS Software-Versionen 12.2(18)SXF10 und Cisco IOS Software-Versionen 12.2(33)SXH oder höher behoben.
Der Switch meldet folgende 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 normalerweise 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 zeigt an, dass ein Layer-2-Eintrag nicht auf der Hardware installiert wurde, da nicht genügend Platz im Hash-Bucket vorhanden ist. Multicast-Pakete werden auf dem eingehenden VLAN geflutet, da die Installation des Layer-2-Eintrags fehlgeschlagen ist. Wenn der Grenzwert überschritten wird, werden zusätzliche Gruppen-MACs geflutet.
Wenn Sie kein Multicast verwenden, können Sie IGMP-Snooping deaktivieren. Andernfalls können Sie die Hash-Einstiegsgrenze mit dem Befehl ip igmp snooping l2-entry-limit erhöhen.
Der Switch meldet folgende Fehlermeldung:
%QM-4-AGG_POL_EXCEEDED: QoS Hardware Resources Exceeded : Out of Aggregate policers
Es kann nur eine begrenzte Anzahl von Aggregate Policers unterstützt werden. Bei EARL7-basierten Switches ist dieser Grenzwert 1023.
Anstelle einer portbasierten QoS können Sie auch eine VLAN-basierte QoS konfigurieren. Führen Sie diese Schritte aus:
Wenden Sie die Service-Richtlinie auf alle VLANs an, die auf dem Layer-2-Switch-Port konfiguriert sind.
Entfernen Sie die Service-Richtlinie von jedem Port, der zum jeweiligen VLAN gehört.
Konfigurieren Sie jeden Layer-2-Switch-Port mit dem Befehl mls qos vlan-based (mls qos vlan-basiert) für VLAN-basierte QoS.
Der Switch meldet folgende Fehlermeldung:
%EC-SP-5-CANNOT_BUNDLE2: ist nicht mit Gi2/1 kompatibel 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, und verursacht daher einen Fehler beim Hinzufügen des Port-Channels. Standardmäßig verwenden alle Schnittstellen eine MTU-Größe von 1500. Aufgrund von Diskrepanzen beim MTU-Wert kann der Port nicht zum Port-Channel hinzugefügt werden.
Konfigurieren Sie dieselbe MTU an diesen Member-Ports.
Der Switch meldet folgende Fehlermeldung:
%EC-SP-5-CANNOT_BUNDLE2: Gi1/4 ist nicht mit Gi6/1 kompatibel und wird ausgesetzt (Flusssteuerung von Gi1/4 ist ausgeschaltet, Gi6/1 ist eingeschaltet)
Diese Fehlermeldung gibt die Geschwindigkeit an oder eine Diskrepanz bei der Flusskontrolle. Die Ursache hierfür ist ein Fehler beim Hinzufügen eines Port-Channels.
Überprüfen Sie, ob die Schnittstellenkonfiguration für den Port-Channel übernommen wurde.
Der Switch meldet folgende 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 kurz davor ist, die Hardware-FIB-Kapazität oder den maximalen Routengrenzwert zu erreichen, der für das angegebene Protokoll festgelegt wurde. Wenn der Grenzwert erreicht wird, werden einige Präfixe verworfen.
Laden Sie den Router neu, um den Ausnahmemodus zu beenden. Geben Sie den Befehl mls cef maximum-route im globalen Konfigurationsmodus ein, um die maximale Anzahl von Routen für das Protokoll zu erhöhen. Standardmäßig hat eine PFC3 auf SUP eine Kapazität von 192.000 Einträgen. Wenn Sie jedoch den Befehl mls cef maximum-routes 239 verwenden, erhalten Sie die Möglichkeit, die maximal verfügbaren TCAM-Einträge zu verwenden. Verwenden Sie den Befehl show mls cef maximum-routes, um die maximal möglichen 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.
Der TestMatchCapture-Diagnosetest für Modul 5 (Supervisor) ist fehlgeschlagen, wie in der folgenden Ausgabe von show diagnostic result module module_# :
TestMatchCapture ----------------> F Error code ------------------> 59 (DIAG_L2_INDEX_MISMATCH_ERROR) Total run count -------------> 1 Last test execution time ----> Jun 25 2011 04:49:10 First test failure time -----> Jun 25 2011 04:49:10 Last test failure time ------> Jun 25 2011 04:49:10 Last test pass time ---------> n/a Total failure count ---------> 1 Consecutive failure count ---> 1
Der TestMatchCapture-Test ist eine Kombination aus dem TestProtocolMatchChannel- und dem TestCapture-Test, wie hier beschrieben:
TestProtocolMatchChannel - Mit dem TestProtocolMatchChannel-Test wird überprüft, ob bestimmte Layer-2-Protokolle im Layer-2-Weiterleitungsmodul übereinstimmen. Wenn Sie den Test für die Supervisor Engine ausführen, wird das Diagnosepaket vom In-Band-Port der Supervisor Engine gesendet und führt eine Paketsuche mit der Layer-2-Weiterleitungs-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 per Loopback zurückgeleitet. Die Übereinstimmungsfunktion wird während der Diagnosepaketsuche durch die Layer-2-Weiterleitungs-Engine verifiziert.
TestCapture: Der TestCapture-Test überprüft, ob die Erfassungsfunktion des Layer-2-Weiterleitungs-Moduls ordnungsgemäß funktioniert. Die Erfassungsfunktion wird für die Multicast-Replikation verwendet. Wenn Sie den Test für die Supervisor Engine ausführen, wird das Diagnosepaket vom In-Band-Port der Supervisor Engine gesendet und führt eine Paketsuche mit der Layer-2-Weiterleitungs-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 per Loopback zurückgeleitet. Die Erfassungsfunktion wird während der Diagnosepaketsuche durch die Layer-2-Weiterleitungs-Engine verifiziert.
Setzen Sie das Modul immer dann wieder ein, wenn sich Ihnen eine Gelegenheit bietet. Da es sich hierbei um geringfügige Fehler handelt, können diese ignoriert werden, wenn Sie keine Auswirkungen auf die Leistung feststellen.
Der Switch meldet folgende 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, ausgefallen ist. Der Port wird in den errdisable-Status versetzt.
Setzen Sie die Linecard zurück, um zu sehen, ob sich das Problem von selbst löst.
Der Switch meldet folgende 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 auf jedem Modul im System, indem er regelmäßig nach den in der Linecard verwalteten Fehlerzählern fragt.
Diese Fehlermeldung wird angezeigt, wenn ein ASIC auf der Linecard Pakete mit einer ungültigen CRC empfängt. Das Problem kann lokal in diesem Modul auftreten oder durch ein anderes fehlerhaftes Modul im Chassis ausgelöst werden. Dies kann auch auf Frames mit schlechter CRC zurückzuführen sein, die von pinnacle asic vom DBUS empfangen wurden. Das heißt, die Fehlermeldungen implizieren, dass fehlerhafte Pakete über den Bus auf Modul 7 empfangen werden.
Einer der Gründe für die Fehlermeldungen ist die Unfähigkeit des Moduls, mit der Rückwandplatine des Chassis zu kommunizieren, da das Modul falsch eingesetzt wurde. Das Problem liegt bei der Linecard (falsch angebrachtes Modul), dem Supervisor oder dem Datenbus. Es ist jedoch nicht möglich zu sagen, welche Komponente die Daten beschädigt und eine fehlerhafte CRC verursacht.
Setzen Sie zunächst Modul 7 wieder ein, und stellen Sie sicher, dass die Schrauben fest angezogen sind. Stellen Sie außerdem vor dem erneuten Einsetzen die Diagnose mit dem Befehl diagnose bootup level complete (Diagnosestartstufe vollständig abschließen) auf abgeschlossen.
Nach Abschluss des erneuten Einsetzens wird die vollständige Diagnose für das Modul ausgeführt. Anschließend können Sie bestätigen, dass keine Hardware-Probleme mit Modul 7 vorliegen.
Der Switch meldet folgende 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 zeigt an, dass ein Port mit einem unbekannten Protokollfehler betroffen ist. Beispielsweise empfängt ein Catalyst Switch der Serie 6500 Frames mit Protokollen, die er weder kennt noch erkennt. Die erste [dec] ist die Modulnummer, [chars] ist die Portnummer, und die 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 nicht übereinstimmender Geschwindigkeits- und Duplexeinstellungen
CDP ist an einem Ende und nicht an einem anderen Ende aktiviert.
Aufgrund von DTP ist diese Funktion standardmäßig an Switch-Schnittstellen aktiviert. Da Router DTP nicht verstehen, kann dies zu Problemen führen.
Überprüfen Sie den Runts-Zähler auf der Schnittstelle. Wenn sie zunimmt, kann es zu einer Duplexungleichheit an den Schnittstellen kommen.