Dieses Dokument enthält eine kurze Erläuterung gängiger Syslog-Protokolle und Fehlermeldungen, die auf Catalyst Switches der Serien 6500 und 6000 angezeigt werden, auf denen die Catalyst OS (CatOS)-Software ausgeführt wird.
Verwenden Sie das Error Message Decoder Tool (nur registrierte Kunden), wenn eine Fehlermeldung angezeigt wird, die in diesem Dokument nicht angezeigt wird. Dieses Tool zeigt die Bedeutung von Fehlermeldungen an, die von der Cisco IOS® Software und der 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 Sie auf der Switch Supervisor Engine ausführen.
Hinweis: Cisco empfiehlt folgende Mindestkonfiguration für die Protokollierung der Switches der Catalyst 6500-/6000-Serie:
Geben Sie den Befehl set time ein, um das Datum und die Uhrzeit auf dem Switch festzulegen. 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).
Die Meldungen in diesem Abschnitt sind allgemeine Fehlermeldungen, die Sie auf Catalyst Switches der Serien 6500 und 6000 sehen, auf denen CatOS ausgeführt wird.
Der Switch generiert häufige %CDP-4-NVLANMISMATCH-Syslog-Meldungen.
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn diese Fehlermeldung auf dem Switch auftritt:
2002 Jan 11 08:50:40 EST -05:00 %CDP-4-NVLANMISMATCH: Native vlan mismatch detected on port 4/1 2002 Jan 11 02:02:45 %CDP-4-NVLANMISMATCH: Native vlan mismatch detected on port 1/1
Der Switch generiert diese Meldung, wenn der Switch-Port physisch mit einem anderen Switch oder Router verbunden ist. Diese Meldung wird auf dem Switch angezeigt, weil das konfigurierte native VLAN auf dem Port sich von dem nativen VLAN auf dem Switch/Router-Port unterscheidet.
Ein Trunk-Port, der mit IEEE 802.1Q-Tagging konfiguriert wurde, kann getaggten und nicht getaggten Datenverkehr empfangen. Standardmäßig leitet der Switch nicht getaggten Datenverkehr mit dem für den Port konfigurierten nativen VLAN weiter. Wenn ein Paket über eine VLAN-ID verfügt, die mit der nativen VLAN-ID des ausgehenden Ports übereinstimmt, überträgt der Switch das Paket unmarkiert. Andernfalls überträgt der Switch das Paket mit einem Tag.
Stellen Sie sicher, dass das native VLAN für einen 802.1Q-Trunk an beiden Enden der Trunk-Verbindung identisch ist. Wenn sich das native VLAN an einem Ende des Trunks vom nativen VLAN am anderen Ende unterscheidet, kann der Datenverkehr der nativen VLANs an beiden Seiten nicht korrekt auf dem Trunk übertragen werden. Dieses Problem kann einige Verbindungsprobleme in Ihrem Netzwerk zur Folge haben.
Geben Sie den Befehl show trunk mod/port ein, um das auf Ihrem Switch konfigurierte native VLAN zu überprüfen. In diesem Befehl ist mod/port der Trunk-Port. Hier eine Beispielausgabe:
Console> (enable) show trunk 5/24 Port Mode Encapsulation Status Native vlan -------- ----------- ------------- ------------ ----------- 5/24 desirable dot1q not-trunking 1 Port Vlans allowed on trunk -------- --------------------------------------------------------------------- 5/24 1-1005 Port Vlans allowed and active in management domain -------- --------------------------------------------------------------------- 5/24 1 Port Vlans in spanning tree forwarding state and not pruned -------- --------------------------------------------------------------------- 5/24 Console> (enable)
Geben Sie den Befehl set vlan vlan_id mod/port ein, um das für den Trunk-Port konfigurierte native VLAN zu ändern. In diesem Befehl ist mod/port der Trunk-Port.
Hinweis: Die Syslog-Fehlermeldung "%CDP-4-NATIVE_VLAN_MISMATCH" weist auf eine native VLAN-Diskrepanz in Catalyst-Switches hin, auf denen die Cisco IOS-Software ausgeführt wird.
Hinweis: Wenn Switches mit Nicht-Trunk-Ports verbunden sind, stellen Sie sicher, dass Sie die Ports für das gleiche VLAN konfigurieren. Wenn sich die Ports nicht im gleichen VLAN befinden, erhalten Sie die Fehlermeldung %CDP-4-NVLANMISMATCH: Native VLAN-Diskrepanz auf Port [Portnummer].
Der Switch generiert DTP-1-ILGLCFG: Illegale Konfigurationsfehler (on, isl - on,dot1q) auf Port [mod/port].
Diese Meldung kann auftreten, wenn Sie beide Seiten des Trunks auf on gesetzt haben, die Kapselungstypen (isl, dot1q) jedoch nicht übereinstimmen. Wenn Sie die Trunk-Modi auf wünschenswert eingestellt haben, wird der Trunk aufgrund dieser Fehlkonfiguration nicht angezeigt. Überprüfen Sie die Ausgabe des Befehls show trunk auf beiden Seiten, um eine Fehlerbehebung durchzuführen. Stellen Sie sicher, dass die Kapselungstypen identisch sind.
Der Switch generiert periodische %IP-3-UDP_SOCKOVFL:UDP-Socket-Überlauf-Syslog-Meldungen.
Dieses Beispiel zeigt die Konsolenausgabe, die Sie sehen, wenn dieser Fehler auftritt:
Hinweis: Die angezeigte UDP-Socketnummer (User Datagram Protocol) kann unterschiedlich oder einheitlich sein.
%IP-3-UDP_SOCKOVFL:UDP socket 2353 overflow %IP-3-UDP_SOCKOVFL:UDP socket 2353 overflow %IP-3-UDP_SOCKOVFL:UDP socket 2353 overflow %IP-3-UDP_SOCKOVFL:UDP socket 2353 overflow
Der Switch generiert diese Syslog-Meldung, wenn der Puffer, der eingehenden Paketen auf dem angegebenen Socket (dem UDP-Zielport) zugewiesen wird, voll ist. Dieser Puffer ist voll, da die Datenverkehrsrate, die für den Socket bestimmt ist, zu hoch ist. Diese Bedingung kann beispielsweise auftreten, wenn eine Netzwerkmanagementstation eine große Anzahl von SNMP-Abfragen (Simple Network Management Protocol) sendet. Wenn ein UDP-Überlauf auftritt, versuchen Sie, die Anzahl der SNMP-Abfragen zu reduzieren. Um die Anzahl der Abfragen zu reduzieren, erhöhen Sie das Abfrageintervall in der Netzwerkmanagement-Station, oder reduzieren Sie die Anzahl der MIB-Objekte, die von der Netzwerkmanagement-Station abgefragt werden.
Im Beispiel in diesem Abschnitt erhielt der Switch eine übermäßige Anzahl von Paketen, die für die Switch-IP-Adresse (oder die Broadcast-Adresse) mit dem Ziel-UDP-Socket 2353 bestimmt waren. Da der Eingabepuffer für diesen Socket auf dem Switch voll ist, generiert der Switch eine Syslog-Meldung. Geben Sie den Befehl show netstat udp ein, um die Anzahl der Zugriffe des Switches auf den Überlaufzustand anzuzeigen.
Console> (enable) show netstat udp udp: 0 incomplete headers 0 bad data length fields 0 bad checksums 0 socket overflows 110483 no such ports Console> (enable)
Diese Syslog-Meldungen weisen darauf hin, dass eine oder mehrere Stationen einen großen Teil des UDP-Datenverkehrs an den Switch auf den angegebenen UDP-Ziel-Ports senden. Wenn der Switch zu viele dieser Meldungen generiert, verwenden Sie einen Netzwerkanalyst, um die Quelle des Datenverkehrs zu identifizieren. Reduzieren Sie dann die Datenverkehrsrate. Da der UDP-Datenverkehr an die CPU des Switches gerichtet ist, können Sie die SPAN-Funktion (Switched Port Analyzer) verwenden und den Quellport auf sc0 festlegen. Das SPAN identifiziert die interne Schnittstelle für die Supervisor Engine. Weitere Informationen finden Sie im Konfigurationsbeispiel für Catalyst Switched Port Analyzer (SPAN).
Hinweis: Machen Sie sich keine Gedanken über den Port-Zähler ohne diesen. Dieser Zähler zeigt die Anzahl der UDP-Pakete, die der Switch empfangen hat und für nicht vorhandene Ports bestimmt waren.
Der Switch generiert %EC-SP-5-L3DONTBNDL1: TE (Mod/Port) wird ausgesetzt: PAgP ist auf dem Remote-Port nicht aktiviert.
Diese Fehlermeldung tritt im Allgemeinen auf, wenn PAgP (Port Aggregation Protocol) an der Layer 3 (L3)-Schnittstelle aktiviert ist, der Partnerport jedoch nicht für PAgP aktiviert ist. Hier ein Beispiel:
%EC-SP-5-L3DONTBNDL1: Te(mod/port)suspended: PAgP not enabled on the remote port. %EC-SP-5-L3DONTBNDL1: Te(mod/port)suspended: PAgP not enabled on the remote port. %EC-SP-5-L3DONTBNDL1: Te(mod/port)suspended: PAgP not enabled on the remote port.
Die Fehlermeldung tritt höchstwahrscheinlich aufgrund von Konfigurationsproblemen auf, kann aber auch auf Hardware-/Verkabelungsprobleme zurückzuführen sein. Stellen Sie sicher, dass die Konfiguration mit dem Konfigurationsleitfaden übereinstimmt. Wenn der Fehler weiterhin besteht, beheben Sie die Kabel- und Hardware-Probleme. Führen Sie zur Fehlerbehebung für die Hardware folgende Schritte aus:
Setzen Sie den Gigabit Interface Converter (GBIC) wieder ein.
Ersetzen Sie das GBIC.
Testen Sie die Hardware mit einer anderen Linecard.
Der Switch generiert periodische %IP-3-UDP_SOCKOVFL:UDP-Socket-Überlauf-Syslog-Meldungen.
Dieses Beispiel zeigt die Konsolenausgabe, die Sie sehen, wenn dieser Fehler auftritt:
Hinweis: Die angezeigte UDP-Socketnummer kann unterschiedlich oder einheitlich sein.
%IP-3-UDP_BADCKSUM:UDP bad checksum
Der Switch generiert diese Syslog-Meldung, wenn der Switch eine fehlerhafte Prüfsumme für ein UDP-Datagramm, z. B. SNMP-Pakete, erkennt. Der UDP-Datagram-Header enthält eine Prüfsumme, die das empfangende Netzwerkgerät überprüft, um sicherzustellen, dass das Datagramm während der Übertragung beschädigt wurde. Wenn die empfangene Prüfsumme nicht mit dem Prüfsummenwert im Header übereinstimmt, verwirft das Gerät das Datagramm und protokolliert eine Fehlermeldung. Geben Sie den Befehl show netstat udp ein, um die Anzahl der vom Switch erkannten Fehlermeldungen zu sehen.
Console> (enable) show netstat udp udp: 0 incomplete headers 0 bad data length fields 0 bad checksums 0 socket overflows 110483 no such ports Console> (enable)
Diese Nachricht dient nur zu Informationszwecken. Ein Netzwerkgerät sendet fehlerhafte Pakete an den Switch und verursacht die Fehlermeldung. Verwenden Sie einen Netzwerkanalysator, um die Quelle des Datenverkehrs zu identifizieren. Da der UDP-Datenverkehr an die CPU des Switches gerichtet ist, können Sie die SPAN-Funktion verwenden und den Quellport auf sc0 festlegen. Das SPAN identifiziert die interne Schnittstelle für die Supervisor Engine. Weitere Informationen finden Sie im Konfigurationsbeispiel für Catalyst Switched Port Analyzer (SPAN).
Hinweis: Machen Sie sich keine Gedanken über den Port-Zähler ohne diesen. Dieser Zähler zeigt die Anzahl der UDP-Pakete, die der Switch empfangen hat und für nicht vorhandene Ports bestimmt waren.
Der Switch generiert periodisch %KERNEL-5-UNALIGNACCESS:Die Alignment-Korrektur erstellte Syslog-Meldungen.
Dieses Beispiel zeigt die Syslog-Ausgabe, die Sie sehen, wenn dieser Fehler auftritt:
%KERNEL-5-UNALIGNACCESS:Alignment correction made at 0x80056B3C reading 0x81B82F36 %KERNEL-5-UNALIGNACCESS:Alignment correction made at 0x80056B88 reading 0x81B82F36 %KERNEL-5-UNALIGNACCESS:Alignment correction made at 0x80056B3C reading 0x81BF1DB6 %KERNEL-5-UNALIGNACCESS:Alignment correction made at 0x80056B88 reading 0x81BF1DB6
Diese Syslog-Meldungen weisen darauf hin, dass die Switch-CPU einen Ausrichtungsfehler erkannt und korrigiert hat, während versucht wurde, auf Daten im DRAM zuzugreifen. Diese Meldungen dienen nur zu Informationszwecken. Die Meldungen weisen nicht auf ein Problem mit dem Switch hin und wirken sich nicht auf die Systemleistung aus.
In einigen Fällen sehen Sie eine übermäßige Anzahl dieser Meldungen. Diese Meldungen können beispielsweise die Protokolldatei des Syslog-Servers oder die Switch-Konsole überfluten. Wenn Sie mehr als eine Nachricht erhalten, erwägen Sie ein Upgrade der Switch-Software auf die neueste Wartungsversion für Ihren Software-Release-Train. Oder geben Sie den Standard-Befehl set logging level kernel 4 aus, um die Protokollierungsebene für die Kernel-Einrichtung auf 4 oder niedriger zu ändern.
Wenn Sie ein Upgrade auf die neueste Maintenance-Version durchführen, diese Syslog-Meldungen aber dennoch erhalten, stellen Sie beim technischen Support von Cisco eine Serviceanfrage.
Der Switch generiert ungültigen Datenverkehr aus Multicast-Quelladressennachrichten.
Dieses Beispiel zeigt die Syslog-Ausgabe, die Sie sehen, wenn dieser Fehler auftritt:
%MCAST-4-RX_JNRANGE:IGMP: Rcvd Report in the range 01-00-5e-00-00-xx
Der Rcvd-Bericht im Bereich der Syslog-Meldung dient nur zur Information. Der Switch generiert diese Nachricht beim Empfang von IGMP-Berichtspaketen (Internet Group Management Protocol) mit einer Multicast-MAC-Adresse, die mit 01-00-5e-00-00-xx beginnt. Dieser Layer-2-Adressbereich (L2) entspricht einem L3-Multicast-Adressbereich zwischen 224.0.0.0 und 224.0.0.255. Diese Adressen sind für die Verwendung von Routing-Protokollen und anderen Low-Level-Topologieerkennungs- oder Wartungsprotokollen reserviert. Beispiele für diese Protokolle sind die Gateway-Erkennung und die Berichte über Gruppenmitgliedschaften.
Verwenden Sie ein Paket-Erfassungstool wie einen Sniffer, und filtern Sie nach IGMP-Nachrichten, um dieses Problem zu beheben. Darüber hinaus können Sie die Catalyst SPAN-Funktion verwenden, um Pakete von einem Port zu kopieren, von dem Sie vermuten, dass diese Nachrichten von einem Netzwerkgerät empfangen werden. Um diese Meldungen zu unterdrücken, geben Sie den Befehl set logging level mcast 2 default ein. Mit diesem Befehl wird die Protokollierungsebene für Multicast-Meldungen auf 2 geändert.
Verwenden Sie die Ports, die der Befehl show multicast router anzeigt, und/oder Uplinks zum Netzwerkkern als SPAN-Quellports. Falls es sich bei diesen Ports um Trunk-Ports handelt, konfigurieren Sie auch den SPAN-Zielport als Trunk-Port. Geben Sie den Befehl show trunk ein, um zu überprüfen, ob es sich bei den Ports um Trunk-Ports handelt.
Bei einem Switch mit aktiviertem IGMP-Snooping wird der %MCAST-2-IGMP_FALLBACK:IGMP angezeigt: Fehlermeldung wird im FALL BACK-Modus ausgeführt.
Dieses Beispiel zeigt die Syslog-Ausgabe, die Sie sehen, wenn dieser Fehler auftritt:
%MCAST-2-IGMP_ADDRAL:IGMP: Address Aliasing for 01-00-5e-00-00-01 %MCAST-2-IGMP_FALLBACK:IGMP: Running in FALL BACK mode
Der Switch generiert diese Syslog-Meldung, wenn der Switch exzessiven Multicast-Datenverkehr empfängt, der für eine Multicast-MAC-Adresse im Bereich 01-00-00-xx bestimmt ist. IGMP-Snooping unterstützt keine Multicast-Streams an Adressen in diesem MAC-Adressbereich. Dieser Mangel an Unterstützung besteht darin, dass MAC-Adressen in diesem Bereich auch für IGMP-Kontrolldatenverkehr wie Blätter, Joins und allgemeine Abfragen verwendet werden. Im Beispiel in diesem Abschnitt empfängt der Switch eine übermäßige Menge an Datenverkehr mit der MAC-Zieladresse 01-00-5e-00-00-01. Diese Meldung weist darauf hin, dass der Network Management Processor (NMP) einen Multicast-Datenstrom erkennt, der die Protokollumleitungslogik deaktiviert hat. Der Stream ist an eine der folgenden speziellen Multicast-Adressen gebunden:
01-00-5e-00-00-01 01-00-5e-00-00-04 01-00-5e-00-00-05 01-00-5e-00-00-06 01-00-5e-00-00-0d
Wenn der Switch eine hohe Rate dieses Datenverkehrs erkennt, hört der Switch für kurze Zeit auf, Pakete mit der angegebenen MAC-Zieladresse zu snoopieren. Dieser Freeze-Modus wird als Fallback-Modus bezeichnet. Anschließend beginnt der Switch wieder mit dem Snooping, der als normaler Modus bezeichnet wird. Der Switch generiert die Syslog-Meldung, die in diesem Abschnitt beschrieben wird, wenn der Switch im Fallback-Modus ausgeführt wird.
Führen Sie einen der folgenden Ansätze durch, um zu ermitteln, welcher Switch Datenverkehr bis 01-00-5e-00-01 generiert:
Geben Sie den Befehl set span sc0 mod/port ein, um den sc0-Port zu überwachen und den Datenverkehr an einen Sniffer zu senden. Das SPAN zeigt den gesamten Datenverkehr an, der an die CPU des Switches geleitet wird.
Hinweis: Der Datenverkehr zu diesen MAC-Adressen wird nur dann an die CPU umgeleitet, wenn sich der Switch nicht im Fallback-Modus befindet. Wenn sich der Switch im Fallback-Modus befindet, erlaubt der Switch nicht, dass die Pakete an die CPU gesendet werden, um eine Datenverkehrsflut zu vermeiden.
Wenn Sie Software der Version 6.3(10), 7.4(3) oder höher ausführen, gibt es zusätzliche Syslog-Meldungen, die Ihnen die falsche Quell-MAC-Adresse, den Quell-Port und die Quell-IP-Adresse mitteilen. Lesen Sie die folgenden Syslog-Meldungen, die ähnlich aussehen:
2003 Jan 24 04:07:43 %MCAST-2-IGMP_ADDRAL:IGMP: Address Aliasing for 224.0.0.1 2003 Jan 24 04:07:43 %MCAST-2-IGMP_FALLBACK:IGMP: Running in FALL BACK mode 2003 Jan 24 04:07:43 %MCAST-2-IGMP_ADDRALDETAILS:IGMP: Multicast address aliasing: From 00-00-0c-11-22-33 (3.3.3.33) on 1/2 to 01-00-5e-00-00-01 (224.0.0.1)
Die Lösung besteht darin, den Host zu isolieren, der diese Art von Multicast-Datenverkehr erzeugt. Überprüfen Sie, welche Adresse gelöscht wird. Versuchen Sie, diese Adresse nicht für den Multicast-Datenfeed zu verwenden. In der Syslog-Meldung finden Sie den Host-Standort, um herauszufinden, warum der Host diesen Datenverkehr sendet. In diesem Beispiel ist der Speicherort des Hosts 3.3.3.33.
Der Switch generiert MGMT-4-OUTOFNVRAM: Syslog-Meldungen außerhalb des NVRAM-Speichers.
Sie sehen eine ähnliche Meldung, wenn dem System der NVRAM-Speicher fehlt:
%MGMT-4-OUTOFNVRAM:Out of NVRAM space: (62,39204,524288,24976)
Diese Meldung weist darauf hin, dass ein NVRAM-Schreibvorgang fehlschlägt, weil kein Speicherplatz zur Verfügung steht. Die vier [dec] in Klammern zeigen Folgendes an:
First [dec] - Der in den NVRAM geschriebene Konfigurationsblock
Second [dec] - Die Größe der Konfiguration, die in den NVRAM geschrieben wird
Third [dec] - Die gesamte NVRAM-Größe im System
Vierter [dec] - Der verfügbare NVRAM-Speicherplatz
Die Lösung besteht darin, die Systemkonfiguration vom Standard-Binärmodus in den Textmodus zu ändern. Sie verwenden den Textmodus, wenn die Konfiguration zu groß für den Speicher im Binärformat im NVRAM ist. Die textbasierte Methode schreibt die Konfigurationsänderungen beim Eingeben der Änderungen nicht in den NVRAM. Diese Methode speichert stattdessen die Änderungen in DRAM, bis Sie den Befehl write memory über die Befehlszeile ausgeben. Weitere Konfigurationsanweisungen finden Sie im Abschnitt Einstellen des Textdateikonfigurationsmodus des Dokuments Arbeiten mit dem Flash-Dateisystem.
Hinweis: Bei Verwendung des Textmodus werden nur die Konfiguration der QoS- und ACL-Listen (Security Access Control List) und die modulbezogene Konfiguration gelöscht. Die restliche Konfiguration wird wie zuvor im Binärformat im NVRAM gespeichert.
Der Switch generiert die Konfiguration des Textmodus kann nicht aktiviert werden, wenn die ACL-Konfiguration aus der Fehlermeldung nvram gelöscht wird.
Der Switch generiert diese Meldung, wenn versucht wird, zu einem Zeitpunkt, zu dem die aktuelle bestätigte ACL-Konfiguration nicht im NVRAM gespeichert wird, von einer Binärmodus-Konfiguration in eine Textmodus-Konfiguration zu wechseln.
In den meisten Fällen können Sie den Befehl set config acl nvram ausführen, um dieses Problem zu beheben. Mit dem Befehl wird die aktuell bestätigte ACL-Konfiguration aus dem DRAM wieder in den NVRAM kopiert.
Der Switch generiert MGMT-5-LOGIN_FAIL:Der Benutzer konnte sich aufgrund von Konsolenfehlern nicht anmelden.
Diese Meldung weist möglicherweise auf ein Problem mit dem Terminalserver hin, der mit dem Konsolenport des Switches verbunden ist. Wenn die Switch-Konsole mit einer asynchronen Leitung eines Terminalservers verbunden ist und Sie einen Soft Reset am Switch durchführen, werden überflüssige Elemente (zufällige Zeichen) mehrere Minuten lang über den Bildschirm übertragen. Wenn TACACS auf dem Switch aktiviert ist, können mehrere Minuten als TACACS-Puffer mehrere Tage dauern und den Müll Stück für Stück verarbeiten. Die Lösung besteht darin, den Befehl no exec auf der asynchronen Leitung auszugeben, mit der der Switch verbunden wird.
Hinweis: Auch nachdem Sie den Befehl no exec ausgegeben haben, werden die Meldungen fortgesetzt, bis der Puffer leer ist.
Der Switch generiert häufige Syslog-Meldungen %PAGP-5-PORTFROMSTP und %PAGP-5-PORTTOSTP.
Dieses Beispiel zeigt die Konsolenausgabe, die Sie sehen, wenn der Switch diese Syslog-Meldungen generiert:
%PAGP-5-PORTFROMSTP:Port 3/3 left bridge port 3/3 %PAGP-5-PORTTOSTP:Port 3/3 joined bridge port 3/3 %PM_SCP-SP-4-LCP_FW_ABLC
Die PAgP-Protokollierung meldet Ereignisse, die PAgP betreffen. Sie verwenden PAgP, um EtherChannel-Verbindungen zwischen Switches auszuhandeln. Der Switch generiert die Syslog-Meldung %PAGP-5-PORTFROMSTP bei Verlust einer Verbindung an einem Switch-Port. Der Switch generiert die Syslog-Meldung %PAGP-5-PORTTOSTP, wenn eine Verbindung an einem Switch-Port erkannt wird. Diese Syslogs sind normale Informationsmeldungen, die auf das Hinzufügen oder Entfernen eines Ports aus dem Spanning Tree hinweisen.
Hinweis: Die Aktivierung der Weiterleitung ist nicht erforderlich, damit diese Nachrichten angezeigt werden.
Im Beispiel in diesem Abschnitt verlor der Switch zunächst die Verbindung an Port 3/3, wodurch der Port aus dem Spanning Tree entfernt wurde. Anschließend erkannte der Switch erneut die Verbindung am Port, die den Port wieder in den Spanning Tree einfügte.
Wenn Sie diese Meldungen häufig für einen bestimmten Port sehen, blinkt der Link, was bedeutet, dass der Link ständig verloren geht und wiederhergestellt wird. Untersuchen Sie die Ursache. Typische Ursachen für das Flapping von Verbindungen auf einen Switch-Port sind:
Unstimmigkeit bei Geschwindigkeit/Duplex
Späte Kollision
Fehlerhaftes Kabel
Fehlerhafte Netzwerkschnittstellenkarte (NIC) oder ein anderes Problem mit der Endstation
Fehlerhafter Switch-Port
Andere Fehlkonfiguration
Wenn Sie diese Syslog-Meldungen unterdrücken möchten, geben Sie den Befehl set logging level pagp 4 default ein, um die Protokollierungsebene für die PAgP-Einrichtung auf 4 oder niedriger zu ändern. Die Standardprotokollierungsstufe für PAgP ist 5.
Der Switch generiert periodische %SPANTREE-3-PORTDEL_FAILNOTFOUND-Syslog-Meldungen.
Dieses Beispiel zeigt die Syslog-Ausgabe, die Sie sehen, wenn dieser Fehler auftritt:
%SPANTREE-3-PORTDEL_FAILNOTFOUND:9/5 in vlan 10 not found (PAgP_Group_Rx)
Diese Syslog-Meldungen weisen darauf hin, dass der PAgP versucht hat, einen Port aus dem Spanning Tree für das angegebene VLAN zu entfernen. Der Port war jedoch nicht in der Spanning Tree-Datenstruktur für dieses VLAN enthalten. In der Regel wurde der Port bereits durch einen anderen Prozess, z. B. das Dynamic Trunking Protocol (DTP), aus dem Spanning Tree entfernt.
Diese Meldungen begleiten in der Regel %PAGP-5-PORTFROMSTP-Nachrichten. Die Meldungen dienen Debugzwecken. Die Meldungen weisen nicht auf ein Problem mit dem Switch hin und wirken sich nicht auf die Switching-Leistung aus. Darüber hinaus werden diese Meldungen nur protokolliert, wenn Sie die standardmäßige SPANTREE-Einrichtungsprotokollkonfiguration geändert haben. Die Standardprotokollierungsstufe für SPANTREE ist 2.
In einigen Fällen sehen Sie eine übermäßige Anzahl dieser Meldungen. Diese Meldungen können beispielsweise die Switch-Konsole überfluten. Wenn Sie mehr als eine Nachricht erhalten, erwägen Sie ein Upgrade der Switch-Software auf die neueste Wartungsversion für Ihren Software-Release-Train. In den meisten Fällen unterdrücken spätere Softwareversionen diese Meldungen.
Der Switch generiert %SYS-1-CFG_RESTORE-Syslog-Meldungen.
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn diese Fehlermeldung auf dem Switch auftritt:
2005 Oct 14 14:36:26 %SYS-1-CFG_RESTORE:Global block restored from backup
Diese Meldungen dienen nur zu Informationszwecken. Die in Version 6.4(x) eingeführte NVRAM-Überwachungsfunktion generiert diese Meldungen. Die Meldungen geben im Wesentlichen an, dass ein beschädigter Block im NVRAM vorhanden war und dass die Konfiguration aus dem Backup wiederhergestellt wurde. Die [Diagramme] sind der Blocktyp, den der Benutzer oder Prozess ändern kann. Standardmäßig werden Prüfungen auf beschädigte Blöcke im NVRAM durchgeführt. Beschädigte Blöcke werden mit der Kopie im DRAM wiederhergestellt. Die Konfiguration geht daher nicht verloren.
Der Switch generiert periodische %SYS-1-SYS_OVERPWRRTNG-Syslog-Meldungen.
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieser Fehler auf dem Switch auftritt:
Oct 13 11:27:11 %SYS-1-SYS_OVERPWRRTNG:System drawing more power than the power supply rating Oct 13 11:27:11 %SYS-1-SYS_OVERPWRRTNG:System drawing more power than the power supply rating
Diese Meldung weist darauf hin, dass das System mehr Strom verbraucht als das Netzteil. Die LED-Betriebsanzeige leuchtet rot. Dieser Zustand tritt nur ein, wenn das System vollständig konfiguriert ist und die Supervisor Engines eine ungleiche Leistung beziehen.
Die Lösung besteht darin, die Netzteile wieder einzusetzen und die Supervisor Engine-Software auf eine Version zu aktualisieren, die die Hardware unterstützt. Versionshinweise für die Cisco Catalyst Switches der Serie 6500 finden Sie im Abschnitt Unterstützte Hardware.
Der Switch generiert einen periodischen %SYS-1-MOD_DCPWRMISMATCH:Module[num]DC-Stromausfall, der während des Pollings von Syslog-Meldungen erkannt wird.
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieser Fehler auf dem Switch auftritt:
%SYS-1-MOD_DCPWRMISMATCH:Module[num]DC power failure detected during polling
Diese Meldung tritt aufgrund eines der folgenden Probleme auf:
Die Linecard ist nicht richtig im Gehäuse eingesetzt.
Setzen Sie die Linecard wieder ein.
Der Chassis-Steckplatz ist defekt.
Prüfen Sie, ob Stifte verbogen sind. Testen Sie die Linecard in einem anderen Steckplatz.
Die Linecard ist defekt.
Wenden Sie sich an den technischen Support von Cisco.
Bei Catalyst 6000-Switches mit redundanter Supervisor Engines (Multilayer Switch Feature Card [MSFC] und Policy Feature Card [PFC]) kann diese Bus-ASIC-Sequenzungleichheit innerhalb eines Switchover auftreten:
SYS-1-MOD_SEQMISMATCH: Bus asic sequence mismatch occurred on module [dec] (asic=[dec], srcidx=0x[hex], seq=[dec])
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieser Fehler auf dem Switch auftritt:
%SYS-1-MOD_SEQMISMATCH:Bus asic sequence mismatch occurred on module 7 (asic=1, srcidx=0x0, seq=0)
Der Fehler tritt auf dem Switch-Module Configuration Protocol (SCP)-Bus auf, der zwischen dem Supervisor und den Linecards kommuniziert. Der Supervisor sendet einen Heartbeat an die Linecards, und diese Linecards reagieren nicht entsprechend auf den Supervisor.
Diese Fehlermeldungen können aus einem der folgenden Gründe verursacht werden:
Die Supervisor Engine ist überlastet
STP-Schleifen (Spanning Tree Protocol)
Die ACLs und QoS-Überwacher drosseln oder verwerfen den Datenverkehr über den In-Band-Kommunikationskanal.
Probleme bei der Port-ASIC-Synchronisierung oder Probleme mit dem Switch-Fabric-Modul
Hardwarefehler oder falsch sitzendes Modul
In einigen Fällen werden diese Meldungen auch bei Linecards beobachtet: WS-X6348-RJ45 und WS-X6516-GBIC.
Diese Meldung hat keine Auswirkungen und kann ignoriert werden. Setzen Sie das Modul als Problemumgehung physisch wieder ein, und setzen Sie es wieder fest ein. Die Linecards sind Hot-Swap-fähig und können den gleichen Steckplatz wie die ursprünglichen Standorte verwenden, sodass alle Ports mit der Supervisor-Konfiguration übereinstimmen.
Der Switch generiert %SYS-3-EOBC_CHANNELREINIT-Syslog-Meldungen.
Diese Beispiele zeigen die Syslog-Ausgabe, die Sie sehen, wenn dieser Fehler auftritt:
CatOS 6.3.8, 7.3.2 und 7.5.1:
%SYS-3-EOBC_CHANNELREINIT:Ethernet out of band channel reinitialized (1)
CatOS Version 7.6(6):
%SYS-5-EOBC_CHANNELREINIT:Ethernet out of band channel reinitialized (1)
CatOS 6.3.8, 7.3.2 und 7.5.1 führten diese Meldung ein. Die Meldung wird angezeigt, wenn der Fehler nicht schwerwiegend ist. Die Meldung weist darauf hin, dass beide Ereignisse aufgetreten sind:
Der Switch hat einen Ethernet-Out-of-Band-Kanal (EOBC)-Übertragungs-Warteschlangenzustand (Tx) auf dem anwendungsspezifischen integrierten Schaltkreis (ASIC) des System-Controllers erkannt.
Der ASIC wurde ohne Zurücksetzen des Switches neu initialisiert.
Hinweis: Das Vorhandensein einer Karte mit einem fehlerhaften EOBC-Puffer kann auch die Meldung verursachen.
Das EOBC ist eine 100-Mbit/s-Halbduplex-Verbindung, die die Supervisoren und Linecards verwenden, um über die Backplane zu kommunizieren. Da es sich um Halbduplex-Verbindungen handelt, sind hier Kollisionen im Kommunikationskanal zu erwarten. Es ist normal, wenn diese Meldungen gelegentlich gemeldet werden, da sie Teil des Selbstwiederherstellungsprozesses sind.
Der Datenverkehr fließt weiterhin durch den Switch. Diese Nachricht ist nur informativ und erfordert keine Aktion. Spätere Softwareversionen enthalten eine Änderung des Schweregrads der Meldung, sodass der Schweregrad mit dem Schweregrad des Fehlers übereinstimmt. Wenn Sie diese Meldung sehr häufig sehen, kann es zu mehr Verlusten bei der Kontrolle von Datenverkehr kommen, was ein Grund zur Besorgnis ist. Wenn wieder initialisierte Meldungen in einem engen Intervall angezeigt werden, wenden Sie sich für weitere Informationen an den technischen Support von Cisco.
Diese Fehlermeldungen werden im Syslog angezeigt:
%SYS-3-SYS_MEMERR:Ungültige magische Nummer beim Freigeben der Adresse 0x82175564
oder
%SYS-3-SYS_MEMERR:Ungültige Prozess-ID bei Zuweisung der Adresse 0x80ea51a4
Diese Fehlermeldungen weisen darauf hin, dass die Speicherverwaltung Speicherbeschädigungen festgestellt hat. Die ersten [Chars] können eine der folgenden Ausdrücke sein:
Außerhalb des Bereichs
Fehlerhafte Ausrichtung
Block ist nicht frei
Falsche Anzeige des Rückzeigers
Falsche Zaubernummer
Blockierung außerhalb der Reichweite
Falsch ausgerichtete Blockierung
Blockzuvor nicht in Reichweite
Falsch ausgerichteter Blockvorlauf
Fehlerhafte Prozess-ID
Die zweite [Chars] kann eine der folgenden sein:
Freistellung
Zuteilung
Das [Hexadezimalfeld] ist die Blockadresse, die freigegeben oder zugewiesen werden soll.
Die Fehlermeldung %SYS-3-SYS_MEMERR gibt an, dass beim Zugriff auf den Speicherblock die Speicherverwaltung festgestellt hat, dass die Informationen beschädigt wurden. Dieses Problem tritt gelegentlich auf, ohne dass der Switch beeinträchtigt wird. Wenn dieser Fehler innerhalb kurzer Zeit mehrmals auftritt, überprüfen Sie, ob die Blockadresse, die in den Fehlermeldungen erwähnt wird, identisch ist. Wenn die Blockadresse identisch ist, kann es vorkommen, dass dieser Sektor auf dem Speicherchip nicht mehr funktioniert und ausgetauscht werden muss.
SYS-3-SYS_LCPERR3: Modul [dec]: Coil [dec] Port [dec] klemmte [dec] Zeiten ([dec] aufgrund von lcol; [dec] aufgrund von notx) Fehlermeldungen werden im Syslog angezeigt.
Diese Fehlermeldungen weisen darauf hin, dass das Modul ein Problem mit dem Port-ASIC erkannt hat und dass ein Port gesperrt ist.
Diese Fehlermeldungen weisen nicht notwendigerweise auf ein Hardwareproblem hin. Der Fehler tritt zum ersten Mal auf, wenn der Switch aufgrund einer Duplexungleichheit oder eines langen Kabels verspätet kollidiert hat. Im CatOS 7.2(2)-Code gibt es jedoch einen Softwarefehler, der dazu führt, dass der Switch nicht auf inkrementelle Fehler überprüft. Derselbe Fehler wird wiederholt protokolliert. Weitere Informationen zu diesem Problem finden Sie unter Cisco Bug ID CSCdx79107 (nur registrierte Kunden). Das Problem wurde in CatOS Version 7.3(1) behoben.
Der generierte Syslog-Fehler ähnelt dem folgenden Beispiel:
2005 Aug 02 09:20:16 %SYS-3-SYS_LCPERR3:Module 5: Coil 3 Port 1: 3-mal festgeklebt(3 aufgrund von lcol; 0 wegen notx)
2005 Aug 02 10:10:45 %SYS-3-SYS_LCPERR3:Module 5: Coil 3 Port 1: 3-mal festgeklebt(3 aufgrund von lcol; 0 wegen notx)
Diese Liste definiert Elemente der Fehlermeldung:
Modul [dec] ist das Modul, das den Fehler meldet.
Coil [dec] ist die Nummer des ASICs, der den Fehler meldet.
Port [dec] ist der ASIC-Port, bei dem der Fehler auftritt.
Stock [dec] ist die Fehlerdauer.
Die letzten beiden [dec] sind die Zähler lcol und notx.
Um diese Syslog-Fehlermeldungen zu deaktivieren, deaktivieren Sie die Option set errordetection portcounters privileged mode (privilegierter Modus).
Überprüfen Sie außerdem den physischen Status des Ports auf eines der folgenden Probleme:
Duplexungleichheit
Nicht synchronisierte NICs auf den angeschlossenen Workstations
Der Status "error disable"
Späte Kollisionen
Alle Fehler auf Verbindungsebene
Um die Probleme zu beheben, die sich aus einem dieser Probleme ergeben, lesen Sie die folgenden Dokumente:
Beheben von Problemen mit der NIC-Kompatibilität bei Cisco Catalyst Switches
Wiederherstellen vom errDisable-Port-Status auf den CatOS-Plattformen
Wenn der Fehler mehrmals auftritt, wenden Sie sich an den technischen Support von Cisco, um dieses Problem weiter zu beheben.
Diese Meldung weist darauf hin, dass das Modul Frames mit einem fehlerhaften Paket-CRC erkannt hat, die vom Bus-ASIC von DBus empfangen wurden. Die erste [dec] ist die Modulnummer. Die zweite [dec] ist die ASIC-Nummer, die den Fehler meldet. Der dritte [dec] ist die Fehleranzahl.
Die fehlerhaften CRC-Pakete können von einem beliebigen Port über den Datenbus gesendet werden. Mögliche Ursachen sind falsch eingesetzte oder fehlerhafte Line-Module.
Wenn Sie während des Wartungsfensters eine Fehlerbehebung für den Switch durchführen können, setzen Sie alle Module einschließlich der Supervisoren wieder ein, und überprüfen Sie, ob die Fehlermeldung erneut auftritt. Wenn dies der Fall ist, können Sie zwei Verfahren verwenden, um festzustellen, welches der Module die Wurzel der fehlerhaften Pakete ist und das Modul ersetzen lassen.
Diagnosestufe verwenden:
Konfigurieren Sie den Switch für eine vollständige POST-Analyse.
set test diaglevel complete
Setzen Sie alle Module einschließlich der Supervisor Engines wieder ein.
Abrufen der POST-Analyseergebnisse
show test all
Kontaktieren Sie den technischen Mitarbeiter von Cisco, um die Ausgabe des Befehls show test all zu erhalten.
Verwenden Sie die Pinnacle ASIC-Zähler:
Entfernen Sie jeweils ein Modul.
Verwenden Sie diesen Befehl, und achten Sie auf den Zähler 0xC7, um Fehler zu erhöhen.
show asicreg/ pinnacle errcounters
Dieser Befehl zeigt alle Zähler für Pinnacle ASIC in diesem Modul an. Der Zähler 0xC7 wird in der dritten Zeile der Ausgabe angezeigt. Bei jeder Ausführung des Befehls werden die Zähler gelöscht. Die ideale Zahl ist 0 Fehler.
C6500> (enable) show asicreg 3/1 pinnacle errcounters
00C5: PI_CI_S_HDR_FCS_REG = 0000
00C6: PI_CI_S_RBUS_FCS_REG = 0000
00C7: PI_CI_S_PKTCRC_ERR_REG = 0000
00C8: PI_CI_S_PKTLEN_ERR_REG = 0000
00C9: PI_CI_S_BPDU_OUTLOST_REG = 0000
00CE: PI_CI_S_HOLD_REG = 0000
00CA: PI_CI_S_QOS0_OUTLOST_REG = 0000
00CE: PI_CI_S_HOLD_REG = 0000
00CB: PI_CI_S_QOS1_OUTLOST_REG = 0000
00CE: PI_CI_S_HOLD_REG = 0000
00CC: PI_CI_S_QOS2_OUTLOST_REG = 0000
!--- Output elided.
Wiederholen Sie die Schritte 1 und 2, bis der Fehler nicht auftritt. Wenden Sie sich an den technischen Mitarbeiter von Cisco, um das fehlerhafte Modul auszutauschen.
Diese Fehlermeldungen werden im Syslog angezeigt:
%SYS-4-SUPERVISOR_ERR:Forwarding engine IP length error counter =4 %SYS-4-SUPERVISOR_ERR:Forwarding engine IP too short error counter =1 %SYS-4-SUPERVISOR_ERR:Forwarding engine IP check sum error counter = 38
Diese Meldungen weisen darauf hin, dass die Switch Forwarding Engine ein IP-Paket mit einer Länge empfängt, die unter der zulässigen Mindestlänge liegt, und das Paket dann verwirft. In Codeversionen, die älter als 7.x sind, verwirft die Weiterleitungs-Engine das Paket stillschweigend und zählt das Paket in den Statistiken der Weiterleitungs-Engine. Bei Codeversionen ab 7.x wird diese Meldung einmal alle 30 Minuten im Syslog gespeichert.
Auf der Switch-Seite treten keine Auswirkungen auf. Auf der Switch-Seite wird das fehlerhafte Paket verworfen, 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, ein Fehler beim NIC-Treiber oder eine fehlerhafte Anwendung. Die Supervisor Engine überwacht nicht die Quell-IP-Adresse des Geräts, das die schädlichen Pakete sendet. Die einzige Möglichkeit, diese Geräte zu erkennen, besteht darin, einen Sniffer zu verwenden, um die Quelladresse nachzuverfolgen.
Diese Meldung ist nur eine Informationsmeldung und Warnung vom Switch. Geben Sie den Befehl set errordection portcounter disable des Switches ein, um diese Fehlermeldungen zu deaktivieren.
Der Switch generiert ungültigen Datenverkehr aus Multicast-Quelladressennachrichten.
Dieses Beispiel zeigt die Syslog-Ausgabe, die Sie sehen, wenn dieser Fehler auftritt:
SYS-4-P2_WARN: 1/Invalid traffic from multicast source address
Diese Syslog-Meldung für die Multicast-Quelladresse wird generiert, wenn der Switch Pakete empfängt, die eine Multicast-MAC-Adresse als Quell-MAC-Adresse haben. Die Verwendung einer Broadcast- oder Multicast-MAC-Adresse als Quell-MAC für einen Frame ist nicht standardkonform. Der Switch leitet jedoch weiterhin Datenverkehr weiter, der von einer Multicast-MAC-Adresse stammt. Die Syslog-Meldung gibt die Multicast-MAC-Adresse im Quell-MAC-Feld des Frames sowie den Port an, an dem der Datenverkehr empfangen wurde. Die Problemumgehung besteht darin, die Endstation zu identifizieren, die Frames mit einer Multicast-Quell-MAC-Adresse erzeugt. In der Regel überträgt eines dieser Geräte solche Frames:
Ein Datenverkehrsgenerator, z. B. Spirent SmartBits
Geräte von Drittanbietern, die eine Multicast-MAC-Adresse gemeinsam nutzen, z. B. Firewall-Lastenausgleich oder Serverprodukte
Der Fehler verursacht keine Leistungsprobleme. Um die Fehlermeldung zu vermeiden, deaktivieren Sie das Protokoll der Meldungen. Eine weitere Problemumgehung besteht darin, das Gerät nachzuverfolgen, das Frames mit einer Multicast-Quell-MAC-Adresse generiert. Verwenden Sie dann einen Sniffer oder eine SPAN-Konfiguration, um das Gerät zu suchen und dessen Konfigurationen zu überprüfen.
Diese Fehlermeldungen werden im Syslog angezeigt:
%SYS-4-PORT_ERR:Port 16/1 rxTotalDrops (7426859)
oder
%SYS-4-PORT_ERR:Port 15/1 rxTotalDrops (2563127)
Im Beispiel in diesem Abschnitt wurden FEHLERERKENNUNGSPORTCOUNTER aktiviert, und es treten Rx-Fehler (Receive) auf Port 1/1 auf. Die Syslog-Meldung (SYS-4-PORT_ERR) meldet rxTotalDrops auf 15/1 statt 1/1.
Hinweis: FEHLERERKENNUNGSPORTCOUNTER sind standardmäßig deaktiviert.
Bei einigen Installationen aktiviert die Software die Funktion und bleibt nach Upgrades aktiviert. Dieses Problem wurde in 6.3(1) für eine neue Installation behoben. Wenn Sie diese Meldung sehen, überprüfen Sie den ersten Uplink-Port (1/1 oder 2/1), nicht den Port, den das Syslog meldet (15/1 oder 16/1). Die Ausgabe des Befehls show counter zeigt die auftretenden Fehler. Wenn der einzige Fehlerindikator, der Fehler meldet, rxTotalDrops ist, werden die Verwerfungen höchstwahrscheinlich durch die CBL (Color Blocking Logic) ausgelöst. Wenn Spanning Tree für ein VLAN an diesem Port blockiert, ist mit diesen Verlusten zu rechnen. CBL-Verwerfen sind Pakete, die auf einem Trunk für ein VLAN empfangen werden, das auf diesem Trunk blockiert ist. So können beispielsweise Broadcast-, Multicast- oder Unicast-Nachrichten mit unbekannter Ursache noch immer auf einem blockierten Port empfangen werden.
Wenn andere Fehlerindikatoren Fehler melden, muss die Ursache weiter untersucht werden.
Die Problemumgehung besteht darin, die FEHLERERKENNUNGSPORTCOUNTER zu deaktivieren. Geben Sie den Befehl set errordection portcounter disable ein.
Der Switch meldet diese Fehlermeldung an die Switch-Konsole und das Syslog für eine WS-X6608-Linecard:
2002 Aug 26 09:22:58 %SYS-4-MODHPRESET: Host process (860) 3/5 got reset asynchronously
Aktive T1- oder E1-Ports auf WS-X6608-Modulen werden zufällig und selten zurückgesetzt. Diese Zurücksetzung führt dazu, dass alle aktiven Anrufe an das öffentliche Telefonnetz (Public Switched Telefone Networks, PSTNs) verworfen werden. Ports, die nicht konfiguriert sind, aber bei dem Versuch, eine Verbindung zu einem Cisco CallManager herzustellen, kontinuierlich zurückgesetzt werden. Diese Rücksetzmeldungen können sich mit den aktiven Gateway-Ports überschneiden und zu einem unerwünschten Zurücksetzen führen. Die Überlappung und das Zurücksetzen sind möglich, da alle acht Ports den Prozessor gemeinsam nutzen. Diese Systemmeldung wird, falls Sie sie konfiguriert haben, kontinuierlich auf dem Konsolenbildschirm und in Ihren Syslogs angezeigt. Dieses Verhalten wird für diesen Blade erwartet. Das Verhalten beeinträchtigt die Systemleistung nicht.
Die Lösung besteht darin, nicht verwendete Ports zu deaktivieren. Geben Sie den Befehl set port disable mod/port (Port-Deaktivierung festlegen) ein. Fügen Sie alle Ports zur Cisco CallManager-Datenbank hinzu. Sie können diese Ports als Gateways, Media Termination Points (MTPs) oder Hardware Conference Bridges konfigurieren.
Das Syslog meldet diese Fehlermeldung im Protokoll:
2002 Aug 23 08:59:16 %SYS-4-NVLOG:SYNDIAGS: Bus ASIC sync error on Module 16, bus I/F register = 0xa0 2002 Aug 23 09:00:53 %SYS-4-NVLOG:SYNDIAGS: Bus ASIC sync error on Module 1, bus I/F register = 0x30
Diese Meldung kann darauf hinweisen, dass der ASIC der Supervisor Engine vor der Ausführung der Diagnose nicht synchronisiert wurde. Wenn Sie diese Meldung erhalten, versuchen Sie, das Modul wieder einzusetzen, oder setzen Sie es in einen anderen Steckplatz ein, um festzustellen, ob die Meldung nicht mehr angezeigt wird. Wenn Sie immer noch die Nachricht erhalten, geben Sie den Befehl show test mod_number ein, erfassen Sie die Ausgabe, und wenden Sie sich an den technischen Support von Cisco. Dieses Problem ist ein Hardwareproblem. Die Lösung besteht darin, das Modul zu ersetzen, das diese Fehlermeldung ausgibt.
Die GBIC-Module WS-G5484, WS-G5486 und WS-G5487 scheinen normal zu funktionieren, die Module melden jedoch folgende Softwarefehler:
%SYS-4-PORT_GBICBADEEPROM: port bad gbic eeprom checksum %SYS-4-PORT_GBICNOTSUPP: port gbic not supported
Wenn Sie die GBIC-Module WS-G5484, WS-G5486 und WS-G5487 mit einer WS-X6408-GBIC-Karte verwenden, werden im Softwareprotokoll Fehlermeldungen angezeigt, obwohl keine Probleme auftreten. Wenn Sie dieselben GBICs an andere Module oder Supervisor Engines anschließen, werden die Fehler möglicherweise nicht angezeigt, sofern die GBICs über ein gültiges Cisco GBIC Supervisor Engine EEPROM (SEEPROM) verfügen. Diese Fehlermeldung ist nur visuell. Die Meldung betrifft nicht den Datenverkehr, der durch das Modul oder GBIC geleitet wird.
Dieses Problem ist nur ein kosmetisches Softwareproblem. Ersetzen Sie die Hardware nicht. Diese verfügbaren Catalyst-Softwareversionen haben dieses Problem behoben, wenn SEEPROMs auf dem Cisco GBIC verfügbar sind:
CatOS 5.5(5) und höher
CatOS 6.2(3) und höher
Wenn ein GBIC nicht über ein Cisco SEEPROM verfügt, wird die Fehlermeldung durch ein Upgrade der CatOS-Software nicht behoben. In diesem Fall weist der Fehler darauf hin, dass ein früheres Cisco GBIC oder ein nicht zertifiziertes, nicht von Cisco stammendes GBIC vorhanden ist. Sie können zertifizierte Cisco GBICs nur im Rahmen eines Supportvertrags oder einer Garantie ersetzen. Überprüfen Sie anhand des Etiketts oben im GBIC-Fall, ob es sich bei dem GBIC um ein zertifiziertes Cisco GBIC handelt. Suchen Sie nach folgenden Elementen:
Ein Cisco Logo
Eine Cisco Teilenummer, die mit 30 beginnt
GBIC-Anbietername
Weitere Informationen finden Sie unter Problemhinweis: G5484, G5486, G5487 GBICs generieren fehlerhafte EPROM-Fehler.
Die Konsole oder das Syslog melden folgende Fehlermeldungen:
%SYS-4-SYS_LCPERR4:Module 12: Pinnacle #1 PB parity error. Tx path. Status=0x0046: Module needs troubleshooting or TAC assistance. %SYS-4-SYS_LCPERR4:Module 12: Pinnacle #1 PB parity error. Rx path. Status=0x0002: Module needs troubleshooting or TAC assistance.
Diese Meldung kann auf ein vorübergehendes Pinnacle ASIC-Paketpufferproblem hinweisen. Die erste [dec] ist die Modulnummer. Die zweite [dec] ist die ASIC-Nummer. Wenn der Fehler auf ein einzelnes Modul beschränkt ist, setzen Sie das Modul wieder ein, und schalten Sie es ein. Wenn Sie diese Fehlermeldung häufig sehen, wenden Sie sich an den technischen Support von Cisco, um weitere Unterstützung zu erhalten.
Die Konsole oder das Syslog melden folgende Fehlermeldungen:
%SYS-5-SYS_LCPERR5:Module 7: Coil Pinnacle Header Checksum Error - Port #32: %SYS-5-SYS_LCPERR5:Module 7: Coil Mdtif Packet CRC Error - Port #32: %SYS-5-SYS_LCPERR5:Module 7: Coil Mdtif State Machine Error - Port #32:
Diese Fehlermeldung bezieht sich auf 6348 Linecards. Die Protokollmeldung im Problem-Abschnitt kann das Ergebnis eines Hardware- oder Softwareproblems sein. Führen Sie die Schritte in diesem Abschnitt aus, um festzustellen, ob das Problem ein Hardware- oder Softwareproblem ist.
Gehen Sie wie folgt vor, wenn beide Punkte zutreffen:
Sie sehen nur die Meldung, die im Abschnitt Problem angezeigt wird, und keine weiteren spule-bezogenen Meldungen in den Syslogs.
Die Übertragung ist an einem Port, aber nicht an einer Gruppe von 12 Ports blockiert.
Führen Sie den Befehl show mac mod/port in Intervallen von zwei Sekunden zweimal aus, um sicherzustellen, dass die Übertragung blockiert ist.
Versuchen Sie, Datenverkehr zwischen den einzelnen Befehlen zu senden. Überprüfen Sie, ob die Transmit-Zähler erhöht wurden. Wenn Sie sehen, dass die Anzahl erhöht ist, bleibt die Übertragung nicht hängen.
Deaktivieren/aktivieren Sie die Ports, und überprüfen Sie, ob sie wiederhergestellt werden.
Geben Sie den Befehl reset mod_number ein, um das Modul weich zurückzusetzen.
Überprüfen Sie, ob das Modul wiederhergestellt wird.
Stellen Sie die Stromversorgung des Setmoduls ein {up} | down} mod_number-Befehl, um das Modul zu hartsetzen.
Überprüfen Sie, ob das Modul wiederhergestellt wird.
Wenn alle diese Punkte zutreffen, besteht bei Ihnen höchstwahrscheinlich ein Softwareproblem:
Sie können die Ports deaktivieren/aktivieren und das Modul entweder zurücksetzen oder auf Festplatte zurücksetzen, und die Karte wird in Betrieb genommen.
Die Diagnose aller Ports verläuft in der Ausgabe des Befehls show test erfolgreich.
Der Datenverkehr beginnt fehlerfrei zu verlaufen.
Wenn alle diese Punkte zutreffen, verwenden Sie die Cisco Bug-ID CSCdu03935 (nur registrierte Kunden). Das Problem wurde in den Versionen 5.5(18), 6.3(10), 7.4(3) und höher behoben.
In einigen Fällen sehen Sie %SYS-5-SYS_LCPERR5:Modul 9: Coil Pinnacle Header Checksum Error - Port #37 Fehlermeldungen und eine oder mehrere dieser Meldungen:
Coil Mdtif State Machine-Fehler
Coil Mdtif Packet CRC-Fehler
Coil Pb Rx Underflow-Fehler
Coil PB Rx Paritätsfehler
Wenn Sie diese Meldungen sehen, stellen Sie fest, ob einige oder alle dieser Elemente zutreffen:
Nach einem Soft-Reset bzw. harten Zurücksetzen des Moduls wird das Modul immer noch nicht online gestellt.
Das Modul wird online gestellt, aber eine Gruppe von 12 Ports konnte die Diagnose in der Befehlsausgabe show test nicht ausführen.
Das Modul ist beim Booten in einem anderen Zustand fixiert.
Alle Port-LEDs am Modul leuchten gelb.
Alle Ports sind im deaktivierten Zustand, wenn Sie den Befehl show port mod_number eingeben.
Wenn eines der Probleme in dieser Liste auftritt, besteht höchstwahrscheinlich ein Hardwareproblem. Sie müssen die Karte ersetzen.
Der Switch generiert periodisch convert_post_SAC_CiscoMIB: Syslog-Meldungen.
Dieses Beispiel zeigt die Konsolenausgabe, die Sie sehen, wenn diese Meldung auftritt:
SYS-4-NVLOG:convert_post_SAC_CiscoMIB:Nvram block 0 unconvertible: ) SYS-4-NVLOG:convert_post_SAC_CiscoMIB:Nvram block 1 unconvertible: ) SYS-4-NVLOG:convert_post_SAC_CiscoMIB:Nvram block 2 unconvertible: )
Diese Konsolenmeldungen werden häufig angezeigt, wenn Sie CatOS-Codeversionen aktualisieren oder herunterladen. Die Meldungen können auch auftreten, wenn Sie eine Switch-Konfiguration laden, die von einem anderen Switch generiert wird, oder wenn Sie eine Switch-Konfiguration aus einer anderen Codeversion verwenden. Ein Failover auf die Standby-Supervisor Engine kann diese Meldungen ebenfalls generieren.
Verschiedene Codeversionen enthalten Variablen, die im NVRAM gespeichert werden. Wenn der Switch anfänglich zu einer späteren oder früheren Version von CatOS startet, konvertiert der Switch die vorherige Konfiguration in eine Version, die vom aktuellen Boot-Image verwendet werden kann. Während dieses Vorgangs wird ein bestimmter Speicherblock, der in der aktuellen Form nicht erforderlich oder verwendbar ist, dereserviert und nicht konvertiert. Diese interne Funktion erzeugt die Fehlermeldung.
Diese Nachricht dient in der Regel nur zur Information. Vergleichen Sie die vorherige Konfiguration mit der aktuellen Konfiguration, um die ordnungsgemäße Konvertierung aller Konfigurationsinformationen zu überprüfen.
Wenn diese Meldungen angezeigt werden, wenn kein Code-Upgrade, keine Konfigurationsänderung oder Supervisor Engine-Failover aufgetreten ist, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco.
Der Switch generiert einen periodischen %SYS-6-CFG_CHG:Module [dec]-Block, der durch SecurityRx-Syslog-Meldungen geändert wurde.
Dieses Beispiel zeigt die Konsolenausgabe, die angezeigt wird, wenn dieser Fehler auf dem Switch auftritt:
%SYS-6-CFG_CHG:Module 3 block changed by SecurityRx %SYS-6-CFG_CHG:Module 4 block changed by SecurityRx
Diese Meldung weist darauf hin, dass der Konfigurationsblock geändert wurde. Diese Meldungen werden erwartet, wenn die Port-Sicherheit auf dem Switch konfiguriert und die Alterung aktiviert ist. Eine PSecure-MAC-Adresse ist die MAC-Adresse, die aus dem Port-Sicherheitsprozess gelernt und der CAM-Tabelle als statischer Eintrag hinzugefügt wird, um den Port zu sichern. Wenn die Port-Sicherheitskonfiguration eine Alterungszeit aufweist, wird die MAC-Adresse zur Alterungszeit aus der CAM-Tabelle und dem NVRAM (in dem PSecure MACs gespeichert sind) entfernt. Das nächste Paket, das nach dieser Alterung vom Port empfangen wird, unterstützt die Replikation des CAM und des NVRAM mit der PSecure MAC-Adresse.
Diese Fehlermeldungen werden in der Ausgabe des Befehls show log angezeigt:
InbandPingProcessFailure:Module 2 not responding over inband InbandPingProcessFailure:Module 2 not responding over inband
Diese Meldung weist darauf hin, dass das Modul nicht auf die Anfragen der Supervisor Engine über den In-Band-Kommunikationskanal reagiert. Eines dieser Ereignisse kann den Fehler verursachen:
Die Supervisor Engine ist überlastet.
Es gibt Spanning Tree Protocol (STP)-Schleifen.
ACLs und QoS-Überwachung drosseln oder verwerfen den Datenverkehr über den In-Band-Kommunikationskanal.
Es gibt Probleme mit der ASIC-Synchronisierung des Ports.
Es gibt Probleme mit dem Switch-Fabric-Modul.
Die Supervisor Engine fragt die Multilayer Switch Feature Card (MSFC) alle 10 Sekunden über einen speziellen Ping ab. Die Supervisor Engine setzt dann die MSFC zurück, wenn die MSFC nicht auf drei aufeinander folgende Pings reagiert. Darüber hinaus fragen sich die aktiven Supervisor Engines und die Standby-Supervisor Engines in CatOS 6.2 und höher über den In-Band-Kanal ab, und der Switch fällt bei der Standby-Supervisor Engine aus.
Hinweis: Wenn Sie vor Kurzem zu oder von Version 6.3(10), 7.4(2) oder 7.4(3) migriert haben, kann der Switch zurückgesetzt werden, wenn Sie den Befehl show log oder den Befehl show tech-support ausgeben und die Fehlermeldung InbandPing im Protokoll haben. Die Problemumgehung besteht darin, den Befehl clear log auszugeben, bevor Sie den Befehl show log ausführen. Cisco Bug ID CSCdz32730 (nur registrierte Kunden) identifiziert diesen Vorbehalt. Das Problem wurde in Version 6.4(1) , 7.5(1) und höher behoben.
In der Regel resultieren diese Meldungen aus einem ausgefallenen Port-ASIC oder einer unzuverlässigen Verbindung zur Backplane. Gehen Sie wie folgt vor:
Entfernen Sie das Modul, auf das die Meldungen verweisen.
Setzen Sie das Modul fest wieder in den Steckplatz ein.
Führen Sie den Befehl set test diaglevel complete (Testdiagnosestufe abgeschlossen) aus, um sicherzustellen, dass der vollständige Diagnosemodus aktiviert ist.
Geben Sie den Befehl show log mod_number und den Befehl show test mod_number ein, um fehlgeschlagene Tests zu finden.
Wenn das Problem mit Schritt 2 nicht behoben werden kann, erstellen Sie eine Serviceanfrage beim technischen Support von Cisco.
Gehen Sie wie folgt vor, um die erforderlichen Informationen bereitzustellen:
Erfassen Sie die Ausgabe der entsprechenden show-Befehle des CatOS.
Wenn das referenzierte Modul keine MSFC ist, erfassen Sie die Ausgabe der folgenden Befehle:
Technischer Support anzeigen
Anzeigeprotokoll
show logging buffer 1024
show test mod_number
Hinweis: Geben Sie diesen Befehl einmal für jede Linecard ein.
scp mod mod_number anzeigen
Hinweis: Geben Sie diesen Befehl einmal für jede Linecard ein.
Schaumodus
Wenn das referenzierte Modul eine MSFC ist, erfassen Sie die Ausgabe der folgenden Befehle:
Inband anzeigen
Test 0 anzeigen
SCP-Statistiken anzeigen
show scp failure
show scp mod
SCP-Prozess anzeigen
Hinweis: Die Befehle show scp sind ausgeblendet.
Überprüfen Sie außerdem, ob im Bootflash Crashinfo-Dateien vorhanden sind. Geben Sie den Bootflash anzeigen: Befehl.
Bestimmen Sie, wann und wie oft das Problem auftritt.
Tritt das Problem auf, wenn die In-Band-Verbindung überlastet ist? Führen Sie einen Ping-Test zwischen der sc0-Schnittstelle der Supervisor Engine und einer VLAN-Schnittstelle der MSFC durch, um eine In-Band-Überlastung zu testen. Wenn auf Ihrem Catalyst CatOS-Systemsoftware ausgeführt wird, gehen Sie wie folgt vor:
Erfassen Sie die Ausgabe des Befehls show inband (In-Band anzeigen) an der Befehlszeilenschnittstelle der Supervisor Engine (CLI).
Öffnen Sie eine separate Telnet-Sitzung direkt zur MSFC, und pingen Sie von einer VLAN-Schnittstelle zur sc0-Schnittstelle.
Erfassen Sie die Ausgabe erneut mit dem Befehl show inband (In-Band anzeigen) in der Supervisor Engine-CLI.
Wenn mehrere Pings ausfallen oder eine Zeitüberschreitung auftreten, geben Sie den Befehl set span sc0 mod/port disable beider inpkts ein.
Mit diesem Befehl wird eine SPAN-Sitzung für die sc0-Schnittstelle konfiguriert. Nachdem Sie den Sniffer oder eine ähnliche Software gestartet haben, führen Sie einen erweiterten Ping-Test zwischen der sc0-Schnittstelle und einer VLAN-Schnittstelle durch.
Stellen Sie fest, ob der Befehl sc0 einem speziellen Management-VLAN oder einem VLAN mit einem hohen Datenverkehrsaufkommen, insbesondere Broadcasts und Multicasts, zugewiesen wird.
Überwachen Sie die Ausgabe des Befehls show errordetection inband.
Mit dem Befehl set errordection können Sie den Switch überwachen. Bei der Erkennung eines Fehlers informiert Sie eine Syslog-Meldung, dass ein Problem vorliegt, bevor eine spürbare Leistungsminderung auftritt. Der Befehl show errordection inband gibt den Typ des In-Band-Fehlers an, z. B. ein In-Band-Stoß, Ressourcenfehler oder In-Band-Fehler beim Hochfahren.
Die Fehlermeldung Ungültiger Feature-Index für Modul wird angezeigt, wenn Sie ein neues Switching-Modul in einem Catalyst Switch der Serien 6500/600 installieren.
Dieses Beispiel zeigt die Konsolenausgabe, die Sie sehen, wenn dieser Fehler auftritt:
%SYS-5-MOD_INSERT:Module 4 has been inserted Invalid feature index set for module 4
Der Ungültige Feature-Index für Modulfehler tritt auf, wenn die Software-Image-Version, die derzeit auf der Supervisor Engine ausgeführt wird, die eingesetzte Hardwarekomponente nicht unterstützt.
Im Beispiel in diesem Abschnitt wurde ein 10/100-Mbit/s-Switching-Modul mit 48 Ports (WS-X6348-RJ-45) in einen Catalyst 6000-Switch eingefügt, auf dem die Softwareversion 5.3(2)CSX ausgeführt wird. Die mindestens erforderliche Softwareversion für das WS-X6348-RJ-45-Modul ist 5.4(2).
Die Lösung besteht darin, die Supervisor Engine-Software auf eine Version zu aktualisieren, die die Hardware unterstützt. In den Versionshinweisen für Catalyst 6000/6500 Software Release 5.x finden Sie eine Liste der Mindestsoftwareversionen für jedes Modul.
Die Fehlermeldung Pinnacle Synch Failed (Pinnacle Synch fehlgeschlagen) wird beim Start angezeigt.
Dieses Beispiel zeigt die Konsolenausgabe, die Sie sehen, wenn dieser Fehler auftritt:
System Power On Diagnostics Complete Boot image: bootflash:cat6000-sup.5-4-4.bin In Local Test Mode, Synch Failed. Retries: 4 Local Test Mode encounters Minor hardware problem in Module # 1 Running System Diagnostics from this Supervisor (Module 1) This may take up to 2 minutes....please wait Pinnacle Synch Failed. Retries: 4 Minor hardware problem in Module # 1 Use 'show test 1' to see results of tests. Cisco Systems Console Enter password:
Die Problemumgehung besteht darin, den Switch auszuschalten und die folgenden Punkte zu prüfen:
Sie haben die Supervisor Engines und alle Switching-Module fest in die Chassis-Backplane eingesetzt.
Sie haben die Auswurfhebel auf der linken und rechten Seite der Module vollständig eingerastet. Stellen Sie sicher, dass Sie die Hebel vollständig gegen die Vorderseite des Moduls drücken.
Sie haben die Griffschrauben auf der linken und rechten Seite der Module in den Kartenträger geschraubt und die Schrauben festgezogen.
Nachdem Sie alle Module im Chassis korrekt eingesetzt haben, schalten Sie das Chassis ein.
Wenn Sie immer noch Pinnacle Synch Failed-Meldungen sehen, kann ein Hardwareproblem mit einem der Module auftreten.
Schalten Sie den Switch aus, und entfernen Sie alle Switching-Module. Schalten Sie den Switch nur mit der Supervisor Engine im Chassis ein. Fügen Sie jeweils ein Modul hinzu, und wiederholen Sie den Vorgang, bis Sie das Problem-Modul identifizieren.
Diese Fehlermeldungen werden im Syslog angezeigt:
RxSBIF_SEQ_NUM_ERROR:slot=9, pinnacleMask=0X1, errSeqNum=b,source Index=0X1, errorType=0X2 RxSBIF_SEQ_NUM_ERROR:slot=3, pinnacleMask=0X1, errSeqNum=b,source Index=0X1, errorType=0X2
Die Line Cards für Catalyst 6500/6000 und das Supervisor Engine-Modul verwenden Port-ASICs, wenn sie Pakete mit hoher Geschwindigkeit zwischen Ports umschalten. Der Pinnacle ASIC stellt eine Gigabit Ethernet-Schnittstelle für den Catalyst 6500/6000-Datenbus bereit. Um hohe Weiterleitungsraten zu unterstützen, unterstützt der Switching-Bus des Catalyst 6500/6000 Pipelining. Beim Pipelining kann der Catalyst 6500/6000 mehrere Frames auf den Bus umschalten, bevor die Ergebnisse des ersten Frames abgerufen werden. Jedem Frame wird ein interner Bus-Header vorangestellt, der eine Folgenummer enthält. Der Switch verwendet die Nummer, um die verschiedenen Frames zu verfolgen, die auf eine Weiterleitungsentscheidung warten. Alle Linecards und die Supervisor Engines müssen die aktuelle und die nächste Sequenznummer kennen. Dieses Verständnis ist sehr wichtig.
Die RXSBIF-Fehlermeldung zeigt das Auftreten eines Sequenzfehlers im Switching-Bus. Zu diesen Fehlern gehören eine Sequenzungleichheit und eine ungültige Sequenz. Eine ungültige Sequenz bedeutet, dass das aktuelle Paket im Switching-Bus eine Folgenummer hat, die sich von der von den ASICs erwarteten Zahl unterscheidet. Im Folgenden sind einige Fehlermeldungen aufgeführt, die ungültige Sequenznummern melden:
%SYS-1-MOD_INVALIDSEQ:Bus asic invalid sequence occurred on module 1 (asic=1, srcidx=0x0, seq=14)
Eines dieser Probleme verursacht in der Regel die Fehlermeldungen:
Falsch eingesetztes Modul - Setzen Sie die Module wieder in die entsprechenden Steckplätze ein.
Hinweis: Das Modul, das die Bussequenzfehler erkennt, ist nicht unbedingt das fehlerhafte Modul. Ein falsch eingesetztes Modul kann dazu führen, dass ein anderes Modul Probleme mit der Bus-Sequenznummer meldet. Daher kann ein erneutes Einsetzen aller Module erforderlich sein.
Stellen Sie sicher, dass Sie die Auswurfhebel fest einrasten und die Schrauben festziehen.
Fehlerhafte Hardware - Diese Ursache ist nicht so häufig. Setzen Sie die Module wieder ein. Wenn ein Fehler auftritt, überprüfen Sie die Linecards auf Beschädigungen des Anschlusses, und prüfen Sie den Steckplatz der Rückwandplatine im Gehäuse auf verbogene Stifte. Verwenden Sie bei Bedarf eine Taschenlampe, wenn Sie die Kontaktstifte an der Chassis-Rückwandplatine überprüfen.
Wenn das Problem weiterhin besteht, nachdem Sie alle Karten wieder eingesetzt haben, erfassen Sie die Ausgabe des Befehls show tech-support und des Befehls show scp mod oder show scp failure secret. Erstellen Sie eine Serviceanfrage beim technischen Support von Cisco, und geben Sie diese Informationen an.
Bekanntes Problem: Wenn das Catalyst 6500/600-System mit dem CatOS-Software-Image 6.1(1b) geladen wird, können Synchronisierungsfehlermeldungen in der Supervisor Engine 2 auftreten. Siehe Problemhinweis: Kontinuierliche Synchronisierungsfehler mit Supervisor Engine 2 auf Catalyst 6000 für weitere Informationen.
Das NVRAM-Protokoll zeigt den Paritätsfehler für die Weiterleitungstabelle (ft_par_err) an.
lyra_ft_par_err_intr_hdlr: LKUPRAM, addr [hex], data [hex]
Diese Fehlermeldung weist darauf hin, dass in der Weiterleitungstabelle ein Paritätsfehler erkannt wurde. Die Fehlermeldung gibt den Speicherort des Fehlers im Speicher an (zuerst [hex]) und die Daten an diesem Ort (zweites [hex]).
Die wahrscheinliche Ursache für diese Fehlermeldung ist, dass eine Linecard nicht korrekt eingesetzt wurde und einen anderen Linecard-Typ in diesem Steckplatz ersetzt.
Gehen Sie wie folgt vor, um das Problem zu beheben:
Entfernen Sie das Modul vom Switch.
Überprüfen Sie die Rückwandplatinen-Pins, und setzen Sie das Modul wieder ein.
Wenn das Problem weiterhin besteht, wenden Sie sich an den technischen Mitarbeiter von Cisco.
Um das Problem zu vermeiden, führen Sie den Befehl module clear-config aus, bevor Sie Module entfernen. Dieser Befehl entfernt automatisch die Konfiguration, die zu einem Modul gehört, nachdem das Modul aus dem Gehäuse entfernt wurde. Weitere Informationen finden Sie im Abschnitt "Selbst nach dem Entfernen der Module" unter "show run Command" weiterhin Informationen zu den entfernten Modulschnittstellen unter "Fehlerbehebung bei Hardware" und "Häufige Probleme bei Catalyst Switches der Serien 6500/6000 mit Cisco IOS-Systemsoftware".
Hinweis: Der Befehl löscht nicht die Konfigurationen von Modulen, die bereits aus dem Steckplatz entfernt wurden.
Diese Fehlermeldung wird in den Protokollen angezeigt:
%KERNEL-1-CREATEPROCESSFAILED:Error in creating process: Unavailable free stack; stack type: 2; Name: tnetproc
%KERNEL-1-CREATEPROCESSFAILED: Fehler beim Erstellen des Prozesses: [Diagramme]; Stapeltyp:[dec]; Name: [chars] Fehlermeldung gibt an, dass der Erstellungsprozess fehlgeschlagen ist. Das System ist nicht prozessfähig. Das Catalyst-Betriebssystem erlaubt eine begrenzte Anzahl von Prozessen, basierend auf der Anzahl der verfügbaren Stacks. Wenn keine Stapel verfügbar sind, wird diese Meldung generiert. Die erste [chars] ist die Prozess-ID. Der [dec] ist der Stapeltyp, und die zweite [chars] ist der Prozessname.
Der CatOS-Switch erlaubt nur eine begrenzte Anzahl von Prozessen mit einem Typ-2-Stack im System, z. B. Console, snmpdm, VtpRx, THREAD oder telnet145. Die maximale Anzahl von Prozessen mit einem Stack vom Typ 2 beträgt 13. Telnet oder Secure Shell (SSH) ist einer der Prozesse, der einen Stack vom Typ 2 erfordert. Wenn alle Stacks vom Typ 2 verwendet werden, wird diese Fehlermeldung bei jedem Versuch, eine Verbindung über Telnet herzustellen, angezeigt.
Dies ist möglicherweise darauf zurückzuführen, dass bei den alten Telnet- oder SSH-Sitzungen keine Zeitüberschreitung auf dem Switch aufgetreten ist oder der Vorgang ausgeführt wurde.
Um dieses Problem zu beheben, geben Sie den Befehl show users ein, um zu überprüfen, wie viele Telnet-Sitzungen für den Switch geöffnet wurden. Trennen Sie die Telnet-Sitzungen, die vom Remote-Gerät mit dem Befehl disconnect ip_address geöffnet werden.
Switch> (enable) show asicreg 4/28 pinnacle err
00C7: PI_CI_S_PKTCRC_ERR_REG = FFFF
016F: PI_CI_S_CBL_DROP_REG = 1619
Dieses Register/dieser Zähler weist nicht auf Hardwareprobleme hin. Sie erhöht sich, wenn ein Paket mit spezifischen VLAN-Tags am Port empfangen wird und dieses VLAN auf dem Port nicht konfiguriert ist. Als Ergebnis wird das Paket verworfen und der Zähler erhöht. Color Blocking Logic (CBL) bezieht sich auf das VLAN-Tagging auf Trunks. VLANs, die von Trunks getrennt werden, verwerfen ihren Datenverkehr. Dieser Zustand tritt auf, wenn eine Seite des Trunks über eine höhere Anzahl von VLANs im Spanning Tree-Weiterleitungsstatus verfügt.
Die Zähler "PI_CI_S_CBL_DROP_REG" können in jedem beliebigen Modus inkrementiert werden. Wenn der Port die STP-Modi durchläuft, werden Treffer an einem Access Port angezeigt. Wenn auf dem Port eine Aushandlung stattfindet (Standardeinstellung), kann dies auch als normales Verhalten oder eine normale Funktion des Switches angesehen werden.
Dieser Zähler zählt Pakete, die aufgrund der CBL-Suche in einem CBIC-Block (Complementary Bipolar Integrated Circuit) verworfen wurden. Der Switch möchte ein Paket an einem bestimmten Port für ein VLAN senden, und die CBL-Logik besagt, dass der Port blockiert/deaktiviert/lernfähig ist. Dies ist kein großes Problem, da diese Pakete in der CBIC-Logik verworfen werden, bevor sie Paketpuffer verbrauchen. Sie können den Port deaktivieren bzw. aktivieren, um festzustellen, ob er den Zähler löscht.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
28-Nov-2008 |
Erstveröffentlichung |