In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beschreibt, wie Sie herausfinden können, warum bei einem Port oder einer Schnittstelle Probleme auftreten.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Dieses Dokument gilt für Catalyst Switches, auf denen die Cisco IOS®-Systemsoftware ausgeführt wird.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Hinweis: Um auf Tools und Websites zugreifen zu können, müssen Sie registrierter Cisco Kunde sein.
Wenn Sie physischen Zugriff auf den Switch haben, kann er save
Zeit, um die Port-LEDs anzuzeigen, die Ihnen den Verbindungsstatus anzeigen oder einen Fehlerzustand anzeigen können (rot oder orange). In der Tabelle werden die LED-Statusanzeigen für Ethernet-Module oder Switches mit fester Konfiguration beschrieben:
Plattform | URL |
Catalyst Switches der Serie 6000 |
|
Catalyst Switches der Serie 4000 |
|
Catalyst Switches der Serie 3750 |
|
Catalyst Switches der Serie 3550 |
|
Switches der Catalyst 2950/2955-Serie |
|
Switches der Catalyst 2900/3500XL-Serie |
|
Switches der Catalyst 1900- und 2820-Serie |
Stellen Sie sicher, dass beide Seiten eine Verbindung haben. Ein einzelner defektes Kabel oder ein heruntergefahrener Port kann das Problem verursachen, wenn eine Seite über eine Verbindungsleuchte verfügt, die andere jedoch nicht.
Eine Verbindungsleuchte garantiert nicht, dass das Kabel voll funktionsfähig ist. Das Kabel kann physischen Belastungen ausgesetzt sein, die dazu führen, dass es nur in geringem Umfang funktionsfähig ist. Normalerweise können Sie diese Situation erkennen, wenn der Port viele Paketfehler aufweist oder ständig ein Flapping auslöst (Verbindung wird unterbrochen und wiederhergestellt).
Wenn die Verbindungsleuchte für den Port nicht leuchtet, können Sie folgende Möglichkeiten in Betracht ziehen:
Mögliche Ursache | Korrekturmaßnahme |
Kein Kabel angeschlossen |
Verbinden Sie das Kabel vom Switch mit einem funktionsfähigen Gerät. |
Falscher Port |
Stellen Sie sicher, dass beide Enden des Kabels an den richtigen Ports angeschlossen sind. |
Gerät wird nicht mit Strom versorgt |
Stellen Sie sicher, dass beide Geräte mit Strom versorgt werden. |
Falscher Kabeltyp |
Überprüfen Sie die Kabelauswahl. Weitere Informationen finden Sie im Handbuch zu Catalyst Switch-Kabeln. |
Fehlerhaftes Kabel |
Ersetzen Sie das verdächtige Kabel durch ein funktionsfähiges Kabel. Suchen Sie nach abgebrochenen oder fehlenden Pins an den Anschlüssen. |
Lose Verbindungen |
Suchen Sie nach losen Verbindungen. Manchmal scheint ein Kabel in die Buchse eingesetzt zu sein, ist es aber nicht. Ziehen Sie das Kabel ab und stecken Sie es wieder ein. |
Patchpanel |
Vermeiden Sie fehlerhafte Patchpanel-Verbindungen. Umgehen Sie das Patchpanel, wenn möglich, um es auszuschließen. |
Media Converter |
Vermeiden Sie fehlerhafte Media Converter: Glasfaser-zu-Kupfer usw. Umgehen Sie den Media Converter, wenn möglich, um ihn auszuschließen. |
Ungültiger oder falscher Gigabit Interface Converter (GBIC) |
Tauschen Sie den verdächtigen GBIC gegen einen funktionsfähigen GBIC aus. Überprüfen Sie die HW- und SW-Unterstützung für diese Art von GBIC. |
Fehlerhafter Port oder Modul-Port oder Schnittstelle oder Modul ist nicht aktiviert |
Schließen Sie das Kabel an einen bekanntermaßen funktionsfähigen Port an, um Fehler an einem verdächtigen Port oder Modul zu beheben. Verwenden Sie den Befehl show interface für Cisco IOS, um nach dem Status errdisable, disable oder shutdown zu suchen. Der Befehl show module kann auf einen Fehler hinweisen, der auf ein Hardwareproblem hindeutet. Weitere Informationen finden Sie in diesem Dokument im Abschnitt Häufige Port- und Schnittstellenprobleme. |
Stellen Sie sicher, dass Sie das richtige Kabel für den Verbindungstyp haben. Kupferkabel der Kategorie 3 können für UTP-Verbindungen (Unshielded Twisted Pair) mit 10 Mbit/s verwendet werden, dürfen jedoch niemals für UTP-Verbindungen mit 10/100 oder 10/100/1000 Mbit/s verwendet werden. Verwenden Sie für UTP-Verbindungen mit 10/100 oder 10/100/1000 Mbit/s immer die Kategorie 5, Kategorie 5e oder Kategorie 6.
Warnung: Kabel der Kategorien 5e und 6 können sich aufgrund der dielektrischen Eigenschaften ihres Materials sehr stark statisch aufladen. Diese Kabel müssen daher (insbesondere bei neuen Kabelführungen) vor dem Anschließen an das Modul immer mit einer geeigneten und sicheren Erdung verbunden werden.
Stellen Sie sicher, dass Sie für Glasfaserkabel das richtige Kabel für die entsprechenden Entfernungen und die Art der verwendeten Glasfaser-Ports verwenden. Die beiden Optionen sind Singlemode Fiber (SMF) oder Multimode Fiber (MMF). Stellen Sie sicher, dass die Ports an den miteinander verbundenen Geräten beide SMF- oder MMF-Ports sind.
Hinweis: Stellen Sie bei Glasfaserverbindungen sicher, dass der Übertragungslead eines Ports mit dem Empfangslead des anderen Ports verbunden ist. Verbindungen für Transmit-to-Transmit und Receive-to-Receive funktionieren nicht.
Transceiver-Geschwindigkeit | Kabeltyp | Duplexmodus | Maximale Distanz zwischen Stationen |
10 Mbit/s |
Kategorie 3 UTP |
Voll und halb |
100 m |
10 Mbit/s |
MMF |
Voll und halb |
2 km |
100 Mbit/s |
UTP der Kategorie 5, UTP der Kategorie 5e |
Voll und halb |
100 m |
100 Mbit/s |
Kategorie 6 UTP |
Voll und halb |
100 m |
100 Mbit/s |
MMF |
Mittel |
400 m |
Full-Commit |
2 km |
||
100 Mbit/s |
SMF |
Mittel |
400 m |
Full-Commit |
10 km |
Weitere Informationen zu den verschiedenen Kabeltypen/Anschlüssen, den Verkabelungsanforderungen, den optischen Anforderungen (Distanz, Typ, Patchkabel usw.), dem Anschluss der verschiedenen Kabel und den Kabeln, die von den meisten Cisco Switches und Modulen verwendet werden, finden Sie im Handbuch zu Catalyst Switch-Kabeln.
Führen Sie dieses Verfahren aus, wenn Gerät A über eine Gigabit-Verbindung mit Gerät B verbunden ist und die Verbindung nicht hergestellt wird.
Schritt-für-Schritt-Anleitung
Stellen Sie sicher, dass Gerät A und B den gleichen GBIC sowie Kabel mit der gleichen Kurzwellenlänge (SX), Langwellenlänge (LX), Langstrecke (LH), erweiterten Wellenlänge (ZX) oder Kupfer-UTP (TX) verwenden. Beide Geräte müssen zum Herstellen einer Verbindung den gleichen GBIC-Typ verwenden. Ein SX GBIC muss mit einem SX GBIC verbunden werden. Ein SX GBIC kann nicht mit einem LX GBIC verbunden werden. Weitere Informationen finden Sie unter Installationshinweise für Patchkabel mit Moduskonditionierung.
Überprüfen Sie die Distanz und das Kabel, die pro GBIC verwendet werden, wie in dieser Tabelle definiert.
Kabelspezifikationen für 1000BASE-T- und 1000BASE-X-Ports
GBIC |
Wellenlänge (nm) |
Kupfer-/Glasfasertyp |
Core-Größe1(Mikrometer) |
Modale Bandbreite (MHz/km) |
Kabellänge2 |
WS-G54831000Base-T (Kupfer) |
UTP der Kategorie 5, UTP der Kategorie 5e, UTP der Kategorie 6 |
100 m |
|||
WS-G54841000BASE-SX3 |
850 |
MMF |
62.5 62.5 50.0 50.0 |
160 200 400 500 |
220 m, 275 m, 500 m, 550 m |
WS-G54861000BASE-LX/LH |
1310 |
MMF4SMF |
62.5 50.0 50.0 8.3/9/10 |
500 400 500- |
550 m, 550 m, 550 m ,10 km |
WS-G54871000BASE-ZX5 |
1550 |
MMF SMF6 |
8.3/9/10 8.3/9/10 |
70 km7100 km |
Die angegebenen Zahlen für Multimode-Glasfaserkabel beziehen sich auf den Kerndurchmesser. Bei Singlemode-Glasfaserkabeln beziehen sich 8,3 Mikrometer auf den Kerndurchmesser. Die Werte 9 Mikrometer und 10 Mikrometer beziehen sich auf den Modenfelddurchmesser (MFD), den Durchmesser des lichttragenden Teils der Faser. Dieser Bereich besteht aus dem Faserkern und einem kleinen Teil der umgebenden Umhüllung. Der MFD ist eine Funktion des Kerndurchmessers, der Wellenlänge des Lasers und der Brechungsindexdifferenz zwischen Kern und Umhüllung.
Entfernungen basieren auf Glasfaserverlusten. Die Kabellänge wird durch mehrere Spleiße und minderwertige Glasfaserkabel reduziert.
Nur mit MMF verwenden.
Wenn Sie einen LX/LH-GBIC mit einem 62,5-Mikrometer-MMF verwenden, müssen Sie sowohl am Sende- als auch am Empfangsende der Verbindung ein Patchkabel mit Moduskonditionierung (CAB-GELX-625 oder gleichwertig) zwischen dem GBIC und dem MMF-Kabel installieren. Das Patchkabel mit Moduskonditionierung ist für Verbindungsabstände von weniger als 100 m oder mehr als 300 m erforderlich. Das Patchkabel mit Moduskonditionierung verhindert ein Übersteuern des Empfängers bei kurzen Längen von MMF und reduziert die Differenzmodusverzögerung bei großen Längen von MMF. Weitere Informationen finden Sie unter Installationshinweise für Patchkabel mit Moduskonditionierung.
Nur mit SMF verwenden.
Dispersionsverschobenes Singlemode-Glasfaserkabel.
Die minimale Verbindungsdistanz für ZX GBICs beträgt 10 km, wobei an jedem Ende der Verbindung ein 8-dB-Dämpfungsglied installiert ist. Ohne Dämpfungsglieder beträgt die minimale Verbindungsdistanz 40 km.
3. Wenn eines der Geräte über mehrere Gigabit-Ports verfügt, verbinden Sie die Ports miteinander. Dadurch wird jedes Gerät getestet und überprüft, ob die Gigabit-Schnittstelle ordnungsgemäß funktioniert. Beispiel: Sie haben einen Switch mit zwei Gigabit-Ports. Verbinden Sie Gigabit-Port 1 mit Gigabit-Port 2. Wird die Verbindung hergestellt? Wenn ja, ist der Port in Ordnung. STP blockiert den Port und verhindert Schleifen (Port 1 Receive (RX) geht an Port 2 Transmit (TX) und Port 1 TX geht an Port 2 RX).
4. Wenn eine einzelne Verbindung oder Schritt 3 mit SC-Anschlüssen fehlschlägt, schleifen Sie den Port zu sich selbst zurück (Port 1 RX geht zu Port 1 TX). Wird der Port geöffnet? Wenn nicht, wenden Sie sich an das TAC, da dieser Port möglicherweise fehlerhaft ist.
5. Wenn die Schritte 3 und 4 erfolgreich sind, aber keine Verbindung zwischen Gerät A und B hergestellt werden kann, schleifen Sie die Ports mit dem Kabel, das an die beiden Geräte angrenzt, um. Stellen Sie sicher, dass kein fehlerhaftes Kabel vorhanden ist.
6. Stellen Sie sicher, dass jedes Gerät die 802.3z-Spezifikation für die Gigabit-Autonegotiation unterstützt. Gigabit-Ethernet verfügt über ein Autonegotiation-Verfahren, das umfangreicher ist als das Verfahren, das für 10/100-Ethernet verwendet wird (Gigabit-Autonegotiation, Spezifikation: IEEE Std 802.3z-1998). Wenn Sie die Verbindungsaushandlung aktivieren, handelt das System automatisch Flusskontrolle, Duplexmodus und Remote-Fehlerinformationen aus. Sie müssen die Verbindungsaushandlung an beiden Enden der Verbindung aktivieren oder deaktivieren. Beide Enden der Verbindung müssen auf den gleichen Wert gesetzt werden, da andernfalls keine Verbindung hergestellt werden kann. Bei der Herstellung einer Verbindung mit Geräten, die vor der Ratifizierung des Standards IEEE 802.3z hergestellt wurden, sind Probleme aufgetreten. Wenn eines der Geräte die automatische Gigabit-Aushandlung nicht unterstützt, deaktivieren Sie die automatische Gigabit-Aushandlung. Dann wird das Herstellen der Verbindung erzwungen. Es dauert 300 ms, bis die Karten-Firmware die Software benachrichtigt, dass ein(e) 10/100/1000BASE-TX-Verbindung/-Port inaktiv ist. Der standardmäßige Debounce-Timer von 300 ms kommt vom Firmware-Abruf-Timer zu den Linecards, der alle 300 ms auftritt. Wenn diese Verbindung im 1G-Modus (1000BASE-TX) ausgeführt wird, muss die Verbindung bei der Gigabit-Synchronisierung, die alle 10 ms erfolgt, schneller erkannt werden. Bei der Erkennungszeit von Verbindungsausfällen gibt es einen Unterschied zwischen der Ausführung von Gigabit Ethernet über Kupfer und Gigabit Ethernet über Glasfaser. Dieser Unterschied in der Erkennungszeit basiert auf den IEEE-Standards.
Warnung: Durch das Deaktivieren der automatischen Aushandlung werden Probleme mit Verbindungsausfällen oder Probleme auf physischer Ebene ausgeblendet. Die Deaktivierung der automatischen Aushandlung ist nur erforderlich, wenn Endgeräte wie ältere Gigabit-NICs verwendet werden, die IEEE 802.3z nicht unterstützen. Deaktivieren Sie die automatische Aushandlung zwischen Switches nur, wenn dies unbedingt erforderlich ist. Probleme auf physischer Ebene können sonst nicht erkannt werden, was STP-Schleifen zur Folge hat. Alternativ können Sie sich an den Anbieter wenden, um ein Software-/Hardware-Upgrade zu erhalten, damit die automatische Aushandlung nach IEEE 802.3z Gigabit unterstützt wird.
Informationen zu den Systemanforderungen von GigabitEthernet sowie von Gigabit Interface Converters (GBICs), Coarse Wavelength Division Multiplexing (CWDM) und Small Form-Factor Pluggable (SFP) finden Sie in folgenden Dokumenten:
Systemanforderungen für die Implementierung von Gigabit-Ethernet auf Catalyst Switches
Kompatibilitätsmatrix für den Catalyst GigaStack Gigabit Interface Converter-Switch
Kompatibilitätsmatrix für Cisco Gigabit Ethernet Transceiver-Module
Kompatibilitätsmatrix für Cisco 10-Gigabit-Ethernet-Transceivermodule
Allgemeine Informationen zur Konfiguration und Fehlerbehebung finden Sie unter Konfiguration und Fehlerbehebung bei Ethernet 10/100/1000 MB mit Halb-/Vollduplex-Autonegotiation.
Bei den meisten Cisco Switches befindet sich ein Port im Status „notconnect“ (Nicht verbunden). Dies bedeutet, dass er derzeit mit keinem Gerät verbunden ist, aber eine Verbindung aufbaut, wenn eine gute Verbindung zu einem anderen betriebsbereiten Gerät besteht. Wenn Sie ein einwandfreies Kabel an zwei Switch-Ports im Status „notconnect“ anschließen, muss die Verbindungsleuchte für beide Ports grün leuchten und der Portstatus muss „connected“ (verbunden) lauten. Dies bedeutet, dass der Port für Layer 1 (L1) aktiv ist.
Unter Cisco IOS können Sie mit dem Befehl show interfaces überprüfen, ob die Schnittstelle aktiv und das Leitungsprotokoll aktiv (verbunden) ist. Das erste up bezieht sich auf den Status der Schnittstelle auf der physischen Ebene. Die Meldung line protocol up zeigt den Status der Schnittstelle auf der Datenverbindungsebene an und besagt, dass die Schnittstelle Keepalives senden und empfangen kann.
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is down, line protocol is down (notconnect)!--- Reasons: In this case, !--- 1) A cable is not properly connected or not connected at all to this port. !--- 2) The connected cable is faulty. !--- 3) Other end of the cable is not connected to an active port or device. !--- Note: For gigabit connections, GBICs need to be matched on each !--- side of the connection. !--- There are different types of GBICs, depends on the cable and !--- distances involved: short wavelength (SX), !--- long-wavelength/long-haul (LX/LH) and extended distance (ZX). !--- An SX GBIC needs to connect with an SX GBIC; !--- an SX GBIC does not link with an LX GBIC. Also, some gigabit !--- connections require conditioning cables, !--- that depend on the lengths involved.
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is up, line protocol is down (notconnect)
!--- The interface is up (or not in a shutdown state), but line protocol down. !--- Reason: In this case, the device on the other side of the wire is a !--- CatOS switch with its port disabled.
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 notconnect 1 auto auto 10/100BaseTX
Wenn show interfaces (Schnittstellen anzeigen) up/line protocol up (verbunden) anzeigt, die Fehleranzahl jedoch in der Ausgabe eines Befehls zunimmt, finden Sie entsprechende Hinweise im Abschnitt Common Port and Interface Problems (Häufige Port- und Schnittstellenprobleme) dieses Dokuments.
Diese Tabelle enthält die häufigsten Befehle zur Fehlerbehebung bei Port- oder Schnittstellenproblemen auf Switches, auf denen die Cisco IOS-Systemsoftware auf dem Supervisor ausgeführt wird.
Hinweis: Die rechte Spalte enthält eine kurze Beschreibung der Funktionen des Befehls und listet alle Ausnahmen für die Verwendung pro Plattform auf.
Wenn Sie von Ihrem Cisco Gerät die Ausgabe der unterstützten Befehle erhalten, können Sie den Cisco CLI Analyzer verwenden, um potenzielle Probleme und deren Behebung anzuzeigen.
Befehle in Cisco IOS | Beschreibung |
show version |
Dieser Befehl zeigt eine Ausgabe an, die einem Cisco Router ähnelt, z. B. Name und Version der Software-Images sowie Informationen zu Systemspeichergrößen. Hilfreich bei der Suche nach Software-/Hardware-Inkompatibilitäten (Versionshinweise oder Software Advisor) und Bugs (mit dem Bug Search Tool). Hinweis: Nur registrierte Cisco Benutzer können auf interne Cisco Tools und Informationen zugreifen. |
show module |
Dieser Befehl zeigt an, welche Karten im Switch vorhanden sind, welche Softwareversion sie ausführen und in welchem Status sich die Module befinden: ok, faulty (fehlerhaft) usw. Dies ist hilfreich bei der Diagnose eines Hardwareproblems an einem Modul oder Port. Weitere Informationen zur Behebung von Hardwareproblemen mit dem Befehl show module finden Sie unter Port- oder Schnittstellenstatus ist deaktiviert oder heruntergefahren oder in den Abschnitten zu Hardwareproblemen dieses Dokuments. |
show run-config |
Dieser Befehl zeigt die aktuelle Konfigurationsdatei des Switches an. Änderungen sind |
show interfaces |
Der Befehl show interface zeigt den Administrations- und Betriebsstatus eines Switching-Ports, Eingabe- und Ausgabepakete, Pufferfehler, Fehler usw. an. |
clear counters |
Verwenden Sie den Befehl clear counters, um den Datenverkehr und die Fehlerzähler auf Null zu setzen, damit Sie sehen können, ob das Problem nur vorübergehend auftritt oder ob die Zähler weiter inkrementiert werden. Hinweis: Bei den Catalyst Switches der 6500/6000-Serie werden die Bitzähler einer Schnittstelle mit dem Befehl clear counters nicht gelöscht. Die einzige Möglichkeit, die Bitzähler in diesen Switches zu löschen, ist das erneute Laden. |
show interfaces counters |
Dies ist der Befehl für die Serien Catalyst 6000, 4000, 3550, 2950 und 3750. |
show counters interface show controllers ethernet-controller |
Der Befehl show counters interface wurde in Softwareversion 12.1(13)E nur für die Catalyst Serie 6000 eingeführt und zeigt 32-Bit- und 64-Bit-Fehlerzähler an. Für Cisco IOS auf Switches der Serien 2900/3500XL, 2950/2955, 3550, 2970 und 3750 zeigt der Befehl show controllers Ethernet-controller verworfene Frames, verzögerte Frames, Ausrichtungsfehler, Kollisionen usw. an. |
show interfaces counters |
Dies ist der Befehl für die Serien Catalyst 6000, 4000, 3550, 2950 und 3750. |
show diagnostic(s) show post |
Der Befehl show diagnostic wurde in 12.1(11b)E für die Catalyst 6000-Serie eingeführt, und show diagnostics (mit s)wurde für die Catalyst 4000-Serie eingeführt. Auf den Switches der 2900/3500XL-, 2950/2955-, 3550-, 2970- und 3750-Serie lautet der entsprechende Befehl show post. Er zeigt die Ergebnisse des Switch-POST an. Weitere Informationen zur Fehlerbehebung bei Hardwarefehlern auf Catalyst Switches finden Sie in diesem Dokument im Abschnitt Hardwareprobleme. |
Die meisten Switches haben eine Möglichkeit, die Pakete und Fehler zu verfolgen, die an einem Port oder einer Schnittstelle auftreten. Die gängigen Befehle zum Auffinden dieser Art von Informationen sind in diesem Dokument im Abschnitt Gängigste Befehle zur Fehlerbehebung bei Ports und Schnittstellen für Cisco IOS beschrieben.
Hinweis: Die Implementierung der Zähler kann je nach Plattform und Version unterschiedlich sein. Obwohl die Werte der Zähler weitgehend genau sind, ist ihr Design nicht sehr präzise. Für das Abrufen der genauen Traffic-Statistiken wird empfohlen, einen Sniffer zu verwenden, mit dem die erforderlichen Eingangs- und Ausgangsschnittstellen überwacht werden können.
Übermäßige Fehler bei bestimmten Zählern weisen in der Regel auf ein Problem hin. Wenn Sie mit Halbduplex arbeiten, sind einige Datenverbindungsfehler, die in Frame Check Sequence (FCS), Ausrichtung, Runts und Kollisionszählern zunehmen, normal. Im Allgemeinen ist bei Halbduplex-Verbindungen ein Verhältnis von einem Prozent der Fehler zum Gesamt-Traffic zulässig. Wenn das Verhältnis von Fehlern zu Eingabepaketen über zwei oder drei Prozent liegt, sind Abstriche bei der Leistung festzustellen.
In Halbduplex-Umgebungen ist es sowohl dem Switch als auch dem angeschlossenen Gerät möglich, die Leitung zu erkennen und gleichzeitig zu übertragen und eine Kollision zu verursachen. Kollisionen können Runts, FCS und Ausrichtungsfehler verursachen, da der Frame nicht vollständig in die Leitung kopiert wird, was zu fragmentierten Frames führt.
Wenn Sie mit Vollduplex arbeiten, müssen die Fehler bei Zählern für FCS, Cyclic Redundancy Checks (CRC), Ausrichtung und Runt minimal sein. Wenn die Verbindung im Vollduplex-Modus betrieben wird, ist der Kollisionszähler nicht aktiv. Wenn der Zähler für FCS, CRC, Ausrichtung oder Runt inkrementiert wird, überprüfen Sie, ob eine Duplex-Fehlanpassung vorliegt. Bei einer Duplex-Fehlanpassung arbeitet der Switch im Vollduplex-Modus und das angeschlossene Gerät im Halbduplex-Modus (oder umgekehrt). Die Folgen einer Duplex-Fehlanpassung sind eine extrem langsame Leistung, Verbindungsunterbrechungen und ein Verbindungsverlust. Andere mögliche Ursachen für Datenverbindungsfehler bei Vollduplex sind fehlerhafte Kabel, fehlerhafte Switch-Ports oder Probleme mit der NIC-Software/Hardware. Weitere Informationen finden Sie in diesem Dokument im Abschnitt Häufige Port- und Schnittstellenprobleme.
Der Befehl show interfaces card-type {slot/port}wird unter Cisco IOS auf dem Supervisor verwendet, um Fehlerzähler und Statistiken anzuzeigen. Eine Alternative zu diesem Befehl (für Catalyst Switches der Serien 6000, 4000, 3550, 2970, 2950/2955 und 3750) ist der Befehl show interfaceCard-type <slot/port> counters errors, der nur die Schnittstellenfehlerindikatoren anzeigt. 1. In Tabelle 1 finden Sie Erläuterungen zur Ausgabe des Fehlerzählers.
Hinweis: Verwenden Sie für Switches der 2900/3500XL-Serie den Befehl show interfaces card-type{slot/port} mit dem Befehl show controllers Ethernet-controller .
Router#sh interfaces fastEthernet 6/1 FastEthernet6/1 is up, line protocol is up (connected) Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 100Mb/s input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:14, output 00:00:36, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec
Die Befehlsausgabe von show interfaces bis zu diesem Zeitpunkt wird hier (in dieser Reihenfolge) erläutert:
up, line protocol is up (connected): Das erste up bezieht sich auf den Status der Schnittstelle auf der physischen Ebene. Die Meldung line protocol up zeigt den Status der Schnittstelle auf der Datenverbindungsebene an und besagt, dass die Schnittstelle Keepalives senden und empfangen kann.
MTU – Maximum Transmission Unit (maximale Übertragungseinheit) beträgt standardmäßig 1500 Byte für Ethernet (für den maximalen Datenbereich des Frames).
Vollduplex, 100 Mbit/s: Vollduplex und 100 Mbit/s ist die aktuelle Geschwindigkeits- und Duplexeinstellung der Schnittstelle. Dies sagt jedoch nicht aus, ob die automatische Aushandlung hierzu verwendet wurde. Verwenden Sie den Befehl show interfaces fastEthernet 6/1 status, um Folgendes anzuzeigen:
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 connected 1 a-full a-100 10/100BaseTX
!--- Autonegotiation was used to achieve full-duplex and 100Mbps.
Last input, output – Die Anzahl der Stunden, Minuten und Sekunden, seit das letzte Paket erfolgreich von der Schnittstelle empfangen oder übertragen wurde. Dies ist nützlich, um zu wissen, wann eine inaktive Schnittstelle ausgefallen ist.
Letztes Löschen von Show Interface Counters - Das letzte Mal, dass der Befehl clear counters seit dem letzten Neustart des Switches ausgegeben wurde. Der Befehl clear counters wird verwendet, um Schnittstellenstatistiken zurückzusetzen.
Hinweis: Variablen, die sich auf das Routing auswirken können (z. B. Last und Zuverlässigkeit), werden beim Löschen der Zähler nicht gelöscht.
Eingabewarteschlange - Die Anzahl der Pakete in der Eingabewarteschlange.Size/max/drops= die aktuelle Anzahl der Frames in der Warteschlange / die maximale Anzahl der Frames, die die Warteschlange aufnehmen kann, bevor sie mit dem Verwerfen von Frames beginnen muss / die tatsächliche Anzahl der wegen Überschreitung der maximalen Warteschlangengröße verworfenen Frames. Flushes wird zum Zählen von SPD-Drops (Selective Packet Discard) für Catalyst Switches der Serie 6000 verwendet, auf denen Cisco IOS ausgeführt wird. (Der Zähler für Flushes kann verwendet werden, erhöht sich jedoch nicht für die Catalyst Switches der Serie 4000, auf denen Cisco IOS ausgeführt wird.) SPD ist ein Mechanismus, der bei Überlastung der CPU Pakete mit niedriger Priorität schnell verwirft, um save
Verarbeitungskapazität für Pakete mit hoher Priorität. Der Zähler für Flushes in der Ausgabe des Befehls „show interface“ erhöht sich als Teil des SPD-Mechanismus, der eine Richtlinie für den selektiven Packet-Drop in der IP-Prozesswarteschlange des Routers implementiert. Daher gilt sie nur für prozessgesteuerten Traffic.
Der Zweck von SPD ist es, sicherzustellen, dass wichtige Kontrollpakete, z. B. Routing-Updates und Keepalives, nicht verworfen werden, wenn die IP-Eingabewarteschlange voll ist. Wenn die Größe der IP-Eingabewarteschlange zwischen dem minimalen und maximalen Schwellenwert liegt, werden normale IP-Pakete basierend auf einer bestimmten Drop-Wahrscheinlichkeit verworfen. Diese zufälligen Drops werden als SPD-Flushes bezeichnet.
Total output drops – Die Anzahl der Pakete, die verworfen wurden, weil die Ausgabewarteschlange voll ist. Eine häufige Ursache ist der Traffic von einer Verbindung mit hoher Bandbreite zu einer Verbindung mit niedrigerer Bandbreite oder der Traffic von mehreren eingehenden Verbindungen zu einer einzelnen ausgehenden Verbindung. Wenn beispielsweise über eine Gigabit-Schnittstelle eine große Menge von Traffic-Flow eingeht und auf eine 100-Mbit/s-Schnittstelle umgeschaltet wird, kann dies zum Verwerfen von Ausgangspaketen an der 100-Mbit/s-Schnittstelle führen. Dies liegt daran, dass die Ausgabewarteschlange an dieser Schnittstelle durch den übermäßigen Traffic aufgrund der Geschwindigkeitsunterschiede zwischen den eingehenden und ausgehenden Bandbreiten überfordert ist.
Output queue – Die Anzahl der Pakete in der Ausgabewarteschlange. „size/max“ steht für die aktuelle Anzahl der Frames in der Warteschlange/die maximale Anzahl der Frames, die die Warteschlange halten kann, bevor sie voll ist und mit dem Löschen von Frames beginnen muss.
5 minute input/output rate – Die durchschnittliche Eingabe- und Ausgaberate, die von der Schnittstelle in den letzten fünf Minuten erkannt wurde. Geben Sie einen kürzeren Zeitraum an, um genaue Informationen zu erhalten (z. B. zur besseren Erkennung von Datenverkehrsspitzen), und geben Sie den Schnittstellenbefehl load-interval <seconds> aus.
In Tabelle 1 finden Sie Erläuterungen zur Ausgabe des Fehlerzählers.
!--- ...show interfaces command output continues. 1117058 packets input, 78283238 bytes, 0 no buffer Received 1117035 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 285811 packets output, 27449284 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
Hinweis: Es gibt einen Unterschied zwischen dem Zähler der Befehlsausgabe von „show interface“ für eine physische Schnittstelle und einer VLAN-Schnittstelle. Die Zähler für die Eingangspakete erhöhen sich in der Ausgabe von show interface für eine VLAN-Schnittstelle, wenn es sich um ein von der CPU verarbeitetes Layer 3 (L3)-Paket handelt. Datenverkehr, der über Layer 2 (L2) geswitcht wird, gelangt nie zur CPU und wird in den Zählern für die Anzeige der Schnittstellen für die VLAN-Schnittstelle nicht gezählt. Er würde bei der Ausgabe des Befehls show interface für die entsprechende physische Schnittstelle gezählt.
Der Befehl show interfaces <card-type> <slot/port> counters errors wird in Cisco IOS verwendet, um nur die Ausgabe der Schnittstellenfehler anzuzeigen. In Tabelle 1 finden Sie Erläuterungen zur Ausgabe des Fehlerzählers.
Router#show interfaces fastEthernet 6/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Fa6/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Fa6/1 0 0 0 0 0 0 0
Tabelle 1: Cisco IOS-Fehlerindikatorausgabe für "Schnittstellen anzeigen" oder "Schnittstellen anzeigen" < Kartentyp> <x/y> Zähler-Fehler für die Catalyst 6000 und 4000 Serien.
Zähler (in alphabetischer Reihenfolge) | Probleme und häufige Ursachen, die die Fehlerzähler erhöhen |
Align-Err |
Beschreibung: „show interfaces“-Zählerfehler. Ausrichtungsfehler sind die Anzahl der empfangenen Frames, die nicht mit einer geraden Anzahl von Oktetten enden und eine fehlerhafte zyklische Redundanzprüfung (CRC, Cyclic Redundancy Check) aufweisen. Häufige Ursachen: Diese sind in der Regel das Ergebnis einer Duplexdiskrepanz oder eines physischen Problems (z. B. Verkabelung, beschädigter Port oder fehlerhafte NIC). Wenn das Kabel zum ersten Mal an den Port angeschlossen wird, können einige dieser Fehler auftreten. Wenn ein Hub mit dem Port verbunden ist, können Kollisionen zwischen anderen Geräten am Hub diese Fehler verursachen. Plattformausnahmen: Ausrichtungsfehler werden bei dem Supervisor I (WS-X4012) oder Supervisor II (WS-X4013) der Catalyst 4000-Serie nicht gezählt. |
babbles |
Beschreibung: „show interfaces“-Zähler, der angibt, dass der Jabber-Timer für die Übertragung abgelaufen ist. Ein Jabber ist ein Frame, der länger als 1518 Oktette ist (exklusive der Framing-Bits, aber inklusive der FCS-Oktette), der nicht mit einer geraden Anzahl von Oktetten endet (Ausrichtungsfehler) oder einen FCS-Fehler aufweist. |
Carri-Sen |
Beschreibung: „show interfaces“-Zählerfehler. Der Zähler für Carri-Sen (Carrier Sense) erhöht sich jedes Mal, wenn ein Ethernet-Controller Daten über eine Halbduplex-Verbindung senden möchte. Der Controller erkennt die Leitung und prüft vor der Übertragung, ob diese belegt ist. Häufige Ursachen: Dies ist bei einem Halbduplex-Ethernet-Segment normal. |
collisions (Kollisionen) |
Beschreibungen: „show interfaces“-Zähler. Gibt an, wie oft eine Kollision aufgetreten ist, bevor die Schnittstelle einen Frame erfolgreich an das Medium übertragen hat. Häufige Ursachen: Kollisionen sind bei Schnittstellen normal, die als Halbduplex konfiguriert sind, dürfen bei Vollduplex-Schnittstellen jedoch nicht auftreten. Wenn die Kollisionen drastisch zunehmen, deutet dies auf eine stark ausgelastete Verbindung oder möglicherweise auf eine Duplex-Fehlanpassung bei dem angeschlossenen Gerät hin. |
CRC |
Beschreibung: „show interfaces“-Zähler. Dieser Wert erhöht sich, wenn der von der LAN-Station oder dem fernen Gerät, von dem der Traffic ausgeht, generierte CRC nicht mit der aus den empfangenen Daten berechneten Prüfsumme übereinstimmt. Häufige Ursachen: Dies deutet normalerweise auf Rauschen oder Übertragungsprobleme auf der LAN-Schnittstelle oder im LAN selbst hin. Eine hohe Anzahl von CRCs ist in der Regel das Ergebnis von Kollisionen, kann aber auch auf ein physisches Problem (z. B. Verkabelung, fehlerhafte Schnittstelle oder NIC) oder eine Duplex-Fehlanpassung hinweisen. |
deferred (verzögert) |
Beschreibung: „show interfaces“-Zähler. Die Anzahl der Frames, die nach dem Warten erfolgreich übertragen wurden, da das Medium ausgelastet war. Häufige Ursachen: Dies tritt normalerweise in Halbduplex-Umgebungen auf, in denen der Carrier bereits verwendet wird, wenn er versucht, einen Frame zu übertragen. |
pause input |
Beschreibung: „show interfaces“-Zähler. Eine Erhöhung des Zählers zur Eingangsunterbrechung bedeutet, dass das verbundene Gerät eine Traffic-Pause anfordert, wenn sein Empfangspuffer fast voll ist. Häufige Ursachen: Dieser Zähler wird zu Informationszwecken erhöht, da der Switch den Frame akzeptiert. Die Unterbrechungspakete werden angehalten, wenn das verbundene Gerät den Traffic empfangen kann. |
input packets with dribble condition |
Beschreibung: „show interfaces“-Zähler. Ein Fehler des Typs „dribble bit“ gibt an, dass ein Frame etwas zu lang ist.Häufige Ursachen: Dieser Frame-Fehlerzähler wird zu Informationszwecken erhöht, da der Switch den Frame akzeptiert. |
Excess-Col |
Beschreibung: „show interfaces“-Zählerfehler. Eine Anzahl von Frames, für die die Übertragung an einer bestimmten Schnittstelle aufgrund übermäßiger Kollisionen fehlschlägt. Eine übermäßige Kollision tritt auf, wenn ein Paket 16 Mal hintereinander kollidiert. Das Paket wird dann verworfen. Häufige Ursachen: Übermäßige Kollisionen sind in der Regel ein Hinweis darauf, dass die Load im Segment auf mehrere Segmente aufgeteilt werden muss, kann aber auch auf eine Duplex-Fehlanpassung mit dem angeschlossenen Gerät hinweisen. Kollisionen dürfen nicht auf als Vollduplex konfigurierten Schnittstellen auftreten. |
FCS-Err |
Beschreibung: „show interfaces“-Zählerfehler. Die Anzahl der Frames mit gültiger Größe mit FCS-Fehlern (Frame Check Sequence), aber ohne Frame-Fehler. Häufige Ursachen: Dies ist in der Regel ein physisches Problem (z. B. Verkabelung, fehlerhafter Port oder fehlerhafte Netzwerkkarte), kann aber auch auf eine Duplex-Fehlanpassung hinweisen. |
Frame |
Beschreibung: „show interfaces“-Zähler. Die Anzahl der falsch empfangenen Pakete mit einem CRC-Fehler und einer nicht ganzzahligen Anzahl von Oktetten (Ausrichtungsfehler). Häufige Ursachen: Dies ist in der Regel das Ergebnis von Kollisionen oder eines physischen Problems (z. B. Verkabelung, fehlerhafter Port oder fehlerhafte NIC), kann aber auch auf eine Duplex-Fehlanpassung hinweisen. |
Giants |
Beschreibung: „show interfaces“-Fehler und „show interfaces“-Zählerfehler. Empfangene Frames, die die maximale IEEE 802.3-Framegröße (1518 Byte für Nicht-Jumbo-Ethernet) überschreiten und eine fehlerhafte Frame Check Sequence (FCS) aufweisen. Häufige Ursachen: In vielen Fällen ist dies das Ergebnis einer fehlerhaften Netzwerkkarte. Versuchen Sie, das fehlerhafte Gerät zu finden, und entfernen Sie es aus dem Netzwerk. Plattformausnahmen: Catalyst Cat4000-Serie mit Cisco IOS. Vor Softwareversion 12.1(19)EW wurde der Zähler für Giants für einen Frame > 1518 Byte erhöht. Nach 12.1(19)EW wird der Zähler für Giants im Befehl „show interfaces“ nur erhöht, wenn ein Frame > 1518 Byte mit einer fehlerhaften FCS empfangen wird. |
ignoriert |
Beschreibung: „show interfaces“-Zähler. Die Anzahl der empfangenen Pakete, die von der Schnittstelle ignoriert werden, da die Schnittstellenhardware nicht über genügend interne Puffer verfügt. Häufige Ursachen: Broadcast-Stürme und Rauschspitzen können dazu führen, dass die ignorierte Anzahl erhöht wird. |
Input errors |
Beschreibung: „show interfaces“-Zähler. Häufige Ursachen: In diese Kategorie gehören Runts, Giants, No Buffer, CRC, Frame, Overrun sowie Ignored. Andere eingabebedingte Fehler können ebenfalls dazu führen, dass sich die Anzahl der Eingabefehler erhöht. Zudem können einige Datagramme mehr als einen Fehler aufweisen. Daher kann diese Summe nicht mit der Summe der aufgezählten Eingabefehlerzahlen ausgeglichen werden. Siehe auch den Abschnitt Eingabefehler bei einer mit einem Layer-2-Switchport verbundenen Layer-3-Schnittstelle. |
Late-Col |
Beschreibung: show interfaces and show interfaces counterserrors. Die Häufigkeit, mit der eine Kollision spät im Übertragungsprozess an einer bestimmten Schnittstelle erkannt wird. Bei einem 10-Mbit/s-Port dauert die Übertragung eines Pakets mehr als 512 Bitzeiten. 512 Bitzeiten entsprechen 51,2 Mikrosekunden auf einem 10-Mbit/s-System. Häufige Ursachen: Dieser Fehler kann unter anderem auf eine Duplex-Fehlanpassung hinweisen. Für das Szenario der Duplex-Fehlanpassung wird die späte Kollision auf der Halbduplex-Seite beobachtet. Da die Halbduplex-Seite sendet, wartet die Vollduplex-Seite nicht, bis sie an der Reihe ist, und sendet gleichzeitig. Dadurch wird eine späte Kollision verursacht. Späte Kollisionen können auch auf ein zu langes Ethernet-Kabel oder -Segment hinweisen. Kollisionen dürfen nicht auf als Vollduplex konfigurierten Schnittstellen auftreten. |
lost carrier |
Beschreibung: „show interfaces“-Zähler. Gibt an, wie oft der Carrier bei der Übertragung verloren ging. Häufige Ursachen: Überprüfen Sie, ob ein Kabel fehlerhaft ist. Überprüfen Sie die physische Verbindung auf beiden Seiten. |
Multi-Col |
Beschreibung: „show interfaces“-Zählerfehler. Gibt an, wie oft mehrere Kollisionen aufgetreten sind, bevor die Schnittstelle einen Frame erfolgreich an das Medium übertragen hat. Häufige Ursachen: Kollisionen sind bei Schnittstellen normal, die als Halbduplex konfiguriert sind, dürfen bei Vollduplex-Schnittstellen jedoch nicht auftreten. Wenn die Kollisionen drastisch zunehmen, deutet dies auf eine stark ausgelastete Verbindung oder möglicherweise auf eine Duplex-Fehlanpassung bei dem angeschlossenen Gerät hin. |
no buffer |
Beschreibung: „show interfaces“-Zähler. Die Anzahl der empfangenen Pakete, die verworfen wurden, da kein Pufferspeicher vorhanden ist. Häufige Ursachen: Mit ignorierter Anzahl vergleichen. Broadcast-Stürme können häufig für Ereignisse dieser Art verantwortlich sein. |
no carrier |
Beschreibung: „show interfaces“-Zähler. Gibt an, wie oft der Carrier bei der Übertragung nicht vorhanden war. Häufige Ursachen: Überprüfen Sie, ob ein Kabel fehlerhaft ist. Überprüfen Sie die physische Verbindung auf beiden Seiten. |
Out-Discard |
Beschreibung: Die Anzahl der ausgewählten ausgehenden Pakete, die verworfen werden sollen, obwohl keine Fehler erkannt wurden. Häufige Ursachen: Ein möglicher Grund, ein solches Paket zu verwerfen, kann die Freigabe von Pufferspeicher sein. |
output buffer failures output buffers swapped out |
Beschreibung: „show interfaces“-Zähler. Die Anzahl der fehlgeschlagenen Puffer und die Anzahl der ausgetauschten Puffer. Häufige Ursachen: Ein Port puffert die Pakete an den Tx-Puffer, wenn die an den Port umgeleitete Traffic-Rate hoch ist und die Traffic-Menge nicht verarbeitet werden kann Der Port beginnt, die Pakete zu verwerfen, wenn der Tx-Puffer voll ist, und erhöht somit die Unterläufe und die Fehlerzähler für den Ausgangspuffer. Die Erhöhung der Fehlerzähler für den Ausgabepuffer kann ein Zeichen dafür sein, dass die Ports mit geringerer Geschwindigkeit und/oder Duplex betrieben werden oder dass zu viel Traffic über den Port läuft. Stellen Sie sich als Beispiel ein Szenario vor, in dem ein 1-Gigabit-Multicast-Stream an 24 Ports mit 100 Mbit/s weitergeleitet wird. Wenn eine Egress-Schnittstelle überbelegt ist, treten normalerweise Ausgangspufferfehler auf, die zusammen mit Out-Discards zunehmen. Informationen zur Fehlerbehebung finden Sie in diesem Dokument im Abschnitt Verzögerte Frames (Out-Lost oder Out-Discard). |
output errors |
Beschreibung: „show interfaces“-Zähler. Die Summe aller Fehler, die verhindert haben, dass Datagramme über die Schnittstelle übertragen werden konnten. Häufige Ursache: Dieses Problem ist auf die geringe Größe der Ausgabewarteschlange zurückzuführen. |
overrun |
Beschreibung: Die Häufigkeit, mit der die Empfängerhardware empfangene Daten nicht an einen Hardwarepuffer übergeben konnte. Häufige Ursachen:Die Traffic-Eingangsrate hat die Fähigkeit des Empfängers überschritten, die Daten zu verarbeiten. |
packets input/output |
Beschreibung: „show interfaces“-Zähler. Gesamtzahl der an der Ethernet-Schnittstelle empfangenen und gesendeten fehlerfreien Pakete. Das Monitoring dieser Zähler auf Erhöhungen ist hilfreich, um festzustellen, ob der Traffic ordnungsgemäß über die Schnittstelle fließt. Der Bytezähler enthält sowohl die Daten- als auch die MAC-Kapselung in den vom System empfangenen und gesendeten fehlerfreien Paketen. |
Rcv-Err |
Beschreibung: Nur für Catalyst Switches der Serie 6000 - show interfaces counters error (Schnittstellenzähler anzeigen). Häufige Ursachen: Siehe Plattformausnahmen.Plattformausnahmen: Catalyst 5000-Serie rcv-err = Receive Buffer Failure (Pufferfehler empfangen). Beispielsweise wird der Zähler für rcv-err durch einen Runt, Giant oder FCS-Err nicht erhöht. Der Zähler für rcv-err wird bei einem Gerät mit der 5000-Serie nur aufgrund von übermäßigem Traffic erhöht. Bei der Catalyst 4000-Serie steht rcv-err für die Summe aller Empfangsfehler. Das heißt, der Zähler für rcv-err-wird im Gegensatz zum Catalyst 5000 erhöht, wenn die Schnittstelle einen Fehler wie einen Runt, Giant oder FCS-Err empfängt. |
Runts |
Beschreibung: „show interfaces“-Fehler und „show interfaces“-Zählerfehler. Die empfangenen Frames sind kleiner als die minimale IEEE 802.3-Framegröße (64 Byte für Ethernet) und weisen eine fehlerhafte CRC auf. Häufige Ursachen: Dies kann durch eine Duplexungleichheit und physische Probleme wie fehlerhafte Kabel, Ports oder NICs am angeschlossenen Gerät verursacht werden. Plattformausnahmen: Catalyst-Switches der Serie 4000 mit Cisco IOS Zurück zur Softwareversion 12.1(19)EW, ein Runt = zu klein. Zu klein = Frame <64 Byte. Der Zähler für Runts wurde nur bei Empfang eines Frames mit weniger als 64 Byte erhöht. Nach 12.1(19)EW – ein Runt = ein Fragment. Ein Fragment ist ein Frame <64 Byte, aber mit einer fehlerhaften CRC. Das Ergebnis ist, dass der Zähler für Runts jetzt im Befehl show interfaces erhöht wird, zusammen mit dem Zähler für Fragments im Befehl show interfaces counters errors, wenn ein Frame <64 Byte mit einer fehlerhaften CRC empfangen wird. Cisco Catalyst Switches der Serie 3750 In Versionen vor Cisco IOS 12.1(19)EA1, in denen dot1q für die Trunk-Schnittstelle von Catalyst 3750 verwendet wird, sind Runts für die Show-Schnittstellen-Ausgabe sichtbar, da gültige dot1q-gekapselte Pakete 61 bis 64 Byte enthalten und q -Tags werden vom Catalyst 3750 als unterdimensionierte Frames gezählt, obwohl diese Pakete richtig weitergeleitet werden. Darüber hinaus werden diese Pakete in Empfangsstatistiken nicht in der entsprechenden Kategorie (Unicast, Multicast oder Broadcast) gemeldet. Dieses Problem wurde in Cisco IOS Version 12.1(19)EA1 oder 12.2(18)SE oder höher behoben. |
Single-Col |
Beschreibung: „show interfaces“-Zählerfehler. Gibt an, wie oft eine Kollision aufgetreten ist, bevor die Schnittstelle einen Frame erfolgreich an das Medium übertragen hat. Häufige Ursachen: Kollisionen sind bei Schnittstellen normal, die als Halbduplex konfiguriert sind, dürfen bei Vollduplex-Schnittstellen jedoch nicht auftreten. Wenn die Kollisionen drastisch zunehmen, deutet dies auf eine stark ausgelastete Verbindung oder möglicherweise auf eine Duplex-Fehlanpassung bei dem angeschlossenen Gerät hin. |
throttles |
Beschreibung: „show interfaces“. Gibt an, wie oft der Empfänger am Port deaktiviert wurde, möglicherweise aufgrund von einer Puffer- oder Prozessorüberlastung. Wenn hinter dem Zählerwert für Throttles ein Sternchen (*) angezeigt wird, bedeutet dies, dass die Schnittstelle zum Zeitpunkt der Befehlsausführung gedrosselt wird. Häufige Ursachen: Zu den Paketen, welche die Prozessorüberlastung erhöhen können, zählen IP-Pakete mit Optionen, abgelaufene TTL, Nicht-ARPA-Kapselung, Fragmentierung, Tunnel, ICMP-Pakete, Pakete mit MTU-Prüfsummenfehler, RPF-Fehler, IP-Prüfsummen- und Längenfehler. |
underruns |
Beschreibung: Die Häufigkeit, mit welcher der Transmitter schneller ausgeführt wurde, als der Switch verarbeiten kann. Häufige Ursachen: Dies kann in einer Situation mit hohem Durchsatz auftreten, wenn eine Schnittstelle mit einem hohen Volumen an Traffic-Bursts von vielen anderen Schnittstellen gleichzeitig betroffen ist. Zusammen mit den Underruns kann es zu Schnittstellenzurücksetzungen kommen. |
UnderSize |
Beschreibung: „show interfaces“-Zählerfehler. Die empfangenen Frames, die kleiner als die Mindestgröße für IEEE 802.3-Frames von 64 Byte sind (exklusive Frame-Bits, jedoch inklusive FCS-Oktette), die ansonsten wohlgeformt sind. Häufige Ursachen: Überprüfen Sie das Gerät, das diese Frames sendet. |
Xmit-Err |
Beschreibung: „show interfaces“-Zählerfehler. Dies zeigt an, dass der interne Sendepuffer (Tx) voll ist. Häufige Ursachen: Eine häufige Ursache für Xmit-Err kann der Traffic von einer Verbindung mit hoher Bandbreite zu einer Verbindung mit niedrigerer Bandbreite oder der Traffic von mehreren eingehenden Verbindungen zu einer einzelnen ausgehenden Verbindung sein. Wenn beispielsweise über eine Gigabit-Schnittstelle eine große Menge von Traffic-Bursts eingeht und auf eine 100-Mbit/s-Schnittstelle umgeschaltet wird, kann dies zu einem Rückgang von Xmit-Err an der 100-Mbit/s-Schnittstelle führen. Dies liegt daran, dass der Ausgabepuffer an dieser Schnittstelle durch den übermäßigen Traffic aufgrund der Geschwindigkeitsunterschiede zwischen den eingehenden und ausgehenden Bandbreiten überfordert ist. |
Zum Monitoring des eingehenden und ausgehenden Traffics auf dem Port, wie in der nächsten Ausgabe angezeigt, für Unicast-, Multicast- und Broadcast-Traffic. Der Befehl show interfaces card-type {slot/port} counters wird verwendet, wenn Sie Cisco IOS auf dem Supervisor ausführen.
Hinweis: Es gibt einen Zähler für verworfene Geräte im Befehl Cisco IOS show interfaces counters errors (Schnittstellenzähler anzeigen), der in Tabelle 1 erläutert wird.
Router#show interfaces fas 6/1 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Fa6/1 47856076 23 673028 149 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Fa6/1 22103793 17 255877 3280 Router#
!--- Cisco IOS counters used to monitor inbound and outbound unicast, multicast !--- and broadcast packets on the interface.
Der Befehl show counters interface card-type {slot/port} wurde in der Cisco IOS Software-Version 12.1(13)E nur für die Catalyst Serie 6000 eingeführt. Er bietet noch detailliertere Statistiken für Ports und Schnittstellen. Mit diesem Befehl werden die 32-Bit- und 64-Bit-Fehlerindikatoren pro Port oder Schnittstelle angezeigt.
Verwenden Sie für Switches der Catalyst 3750-, 3550-, 2970-, 2950/2955-, 2940- und 2900/3500XL-Serie den Befehl „show controller ethernet-controller“ zum Anzeigen des Traffic-Zählers und den Befehl „error counter output“, der mit der Ausgabe für Switches der Catalyst 6000-Serie vergleichbar ist.
3550-1#show controller ethernet-controller fastEthernet 0/1 !--- Output from a Catalyst 3550. Transmit FastEthernet0/1 Receive 0 Bytes 0 Bytes 0 Unicast frames 0 Unicast frames 0 Multicast frames 0 Multicast frames 0 Broadcast frames 0 Broadcast frames 0 Discarded frames 0 No dest, unicast 0 Too old frames 0 No dest, multicast 0 Deferred frames 0 No dest, broadcast 0 1 collision frames 0 2 collision frames 0 FCS errors 0 3 collision frames 0 Oversize frames 0 4 collision frames 0 Undersize frames 0 5 collision frames 0 Collision fragments 0 6 collision frames 0 7 collision frames 0 Minimum size frames 0 8 collision frames 0 65 to 127 byte frames 0 9 collision frames 0 128 to 255 byte frames 0 10 collision frames 0 256 to 511 byte frames 0 11 collision frames 0 512 to 1023 byte frames 0 12 collision frames 0 1024 to 1518 byte frames 0 13 collision frames 0 14 collision frames 0 Flooded frames 0 15 collision frames 0 Overrun frames 0 Excessive collisions 0 VLAN filtered frames 0 Late collisions 0 Source routed frames 0 Good (1 coll) frames 0 Valid oversize frames 0 Good(>1 coll) frames 0 Pause frames 0 Pause frames 0 Symbol error frames 0 VLAN discard frames 0 Invalid frames, too large 0 Excess defer frames 0 Valid frames, too large 0 Too large frames 0 Invalid frames, too small 0 64 byte frames 0 Valid frames, too small 0 127 byte frames 0 255 byte frames 0 511 byte frames 0 1023 byte frames 0 1518 byte frames 3550-1#
!--- See the next table for additional counter output for 2900/3500XL Series switches.
Zähler | Beschreibung | Mögliche Ursachen |
Übertragene Frames |
||
Discarded frames (Verworfene Frames) |
Die Gesamtanzahl der Frames, bei denen der Übertragungsversuch aufgrund unzureichender Ressourcen abgebrochen wurde. Dieser Gesamtwert enthält Frames aller Zieltypen. |
Die Traffic-Last an der Schnittstelle ist zu hoch und führt dazu, dass die Frames verworfen werden. Reduzieren Sie die Traffic-Load an der Schnittstelle, wenn in diesem Feld eine zunehmende Anzahl von Paketen angezeigt wird. |
Too old frames (zu alte Frames) |
Anzahl der Frames, bei denen es mehr als zwei Sekunden gedauert hat, um durch den Switch zu gelangen. Aus diesem Grund wurden sie vom Switch verworfen. Dies geschieht nur bei extremer, hoher Belastung. |
Die Traffic-Last für diesen Switch ist zu hoch und führt dazu, dass die Frames verworfen werden. Reduzieren Sie die Switch-Load, wenn in diesem Feld eine zunehmende Anzahl von Paketen angezeigt wird. Möglicherweise müssen Sie Ihre Netzwerktopologie ändern, um die Traffic-Last für diesen Switch zu reduzieren. |
Deferred frames (verzögerte Frames) |
Die Gesamtanzahl der Frames, deren erster Übertragungsversuch aufgrund des Traffics in den Netzwerkmedien verzögert wurde. Diese Summe umfasst nur die Frames, die anschließend fehlerfrei und ohne Beeinträchtigung durch Kollisionen übertragen werden. |
Die für diesen Switch bestimmte Traffic-Last ist zu hoch und führt dazu, dass die Frames verworfen werden. Reduzieren Sie die Switch-Load, wenn in diesem Feld eine zunehmende Anzahl von Paketen angezeigt wird. Möglicherweise müssen Sie Ihre Netzwerktopologie ändern, um die Traffic-Last für diesen Switch zu reduzieren. |
Collision frames (Kollisions-Frames) |
Die Zähler für Kollisions-Frames geben die Anzahl der fehlgeschlagenen Versuche einer Paketübertragung an, die beim nächsten Versuch jedoch erfolgreich war. Dies bedeutet, dass der Switch zweimal vergeblich versucht hat, das Paket zu senden, beim dritten Versuch jedoch erfolgreich war, wenn der Zähler für 2 Kollisions-Frames erhöht wurde. |
Die Traffic-Last an der Schnittstelle ist zu hoch und führt dazu, dass die Frames verworfen werden. Reduzieren Sie die Traffic-Load an der Schnittstelle, wenn in diesem Feld eine zunehmende Anzahl von Paketen angezeigt wird. |
Excessive collisions (übermäßige Kollisionen) |
Der Zähler für übermäßige Kollisionen erhöht sich, nachdem 16 aufeinanderfolgende späte Kollisionen in Folge aufgetreten sind. Nach 16 Versuchen, das Paket zu senden, wird das Paket verworfen und der Zähler erhöht. |
Wenn dieser Zähler erhöht wird, deutet dies auf ein Verkabelungsproblem, ein überlastetes Netzwerk oder eine Duplex-Fehlanpassung hin. Ein überlastetes Netzwerk kann durch zu viele Geräte in einem freigegebenen Ethernet verursacht werden. |
Late collisions (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. |
Späte Kollisionen sind das Ergebnis einer falschen Verkabelung oder einer nicht konformen Anzahl von Hubs im Netzwerk. Späte Kollisionen können auch durch fehlerhafte NICs verursacht werden. |
Good (1 coll) frames (Gute Frames, 1 Kollision) |
Die Gesamtanzahl der Frames, die genau einer Kollision unterliegen und dann erfolgreich übertragen werden. |
Kollisionen in einer Halbduplex-Umgebung weisen normal erwartetes Verhalten auf. |
Good (>1 coll) frames (Gute Frames, >1 Kollision) |
Die Gesamtanzahl der Frames, die zwischen 2 und 15 Kollisionen (einschließlich) aufweisen und dann erfolgreich übertragen werden. |
Kollisionen in einer Halbduplex-Umgebung weisen normal erwartetes Verhalten auf. Frames, die am oberen Ende dieses Zählers erhöht werden, laufen Gefahr, 15 Kollisionen zu überschreiten und dann als übermäßige Kollisionen zu zählen. |
VLAN discard frames (verworfene Frames des VLAN) |
Die Anzahl der an einer Schnittstelle verworfenen Frames, da das CFI-Bit festgelegt ist. |
Das Canonical Format Indicator(CFI)-Bit in der TCI eines 802.1q-Frames ist für das kanonische Ethernet-Frame-Format auf 0 gesetzt. Wenn das CFI-Bit auf 1 gesetzt ist, deutet dies auf das Vorhandensein eines nicht kanonischen Routing Information Field(RIF)- oder Token Ring-Frames hin, der verworfen wird. |
Received Frames (empfangene Frames) |
||
Keine Frames mit Bandbreite |
Nur 2900/3500XL.Die Häufigkeit, mit der ein Port ein Paket vom Netzwerk empfangen hat, der Switch jedoch nicht über die Ressourcen verfügt, um es zu empfangen. Dies geschieht nur bei hoher Belastung, kann aber auch durch Traffic-Spitzen auf mehreren Ports auftreten. Daher ist eine kleine Anzahl von Frames ohne Bandbreite kein Grund zur Sorge. (Es muss immer noch weit weniger als ein Prozent der empfangenen Frames sein.) |
Die Traffic-Last an der Schnittstelle ist zu hoch und führt dazu, dass die Frames verworfen werden. Reduzieren Sie die Traffic-Load an der Schnittstelle, wenn in diesem Feld eine zunehmende Anzahl von Paketen angezeigt wird. |
No buffers frames (keine Puffer-Frames) |
Nur 2900/3500XL.Die Häufigkeit, mit der ein Port ein Paket vom Netzwerk empfangen hat, der Switch jedoch nicht über die Ressourcen verfügt, um es zu empfangen. Dies geschieht nur bei hoher Belastung, kann aber auch durch Traffic-Spitzen auf mehreren Ports auftreten. Daher ist eine kleine Anzahl von keine Puffer-Frames kein Grund zur Sorge. (Es muss immer noch weit weniger als ein Prozent der empfangenen Frames sein.) |
Die Traffic-Last an der Schnittstelle ist zu hoch und führt dazu, dass die Frames verworfen werden. Reduzieren Sie die Traffic-Load an der Schnittstelle, wenn in diesem Feld eine zunehmende Anzahl von Paketen angezeigt wird. |
No dest, unicast (kein Ziel, Unicast) |
Kein Ziel (Unicast) gibt die Anzahl der Unicast-Pakete an, die der Port nicht an andere Ports weitergeleitet hat. |
Es folgen kurze Beschreibungen, wann die Zähler für No dest (Unicast, Multicast und Broadcast) erhöht werden können:
|
No dest, multicast (kein Ziel, Multicast) |
Kein Ziel (Multicast) gibt die Anzahl der Multicast-Pakete an, die der Port nicht an andere Ports weitergeleitet hat. |
|
No dest, broadcast (kein Ziel, Broadcast) |
Kein Ziel (Broadcast) gibt die Anzahl der Broadcast-Pakete an, die der Port nicht an andere Ports weitergeleitet hat. |
|
Anordnungsfehler |
Anordnungsfehler gibt die Anzahl der Frames mit Anordnungsfehlern an (Frames, die nicht mit einer geraden Anzahl von Oktetten enden und einen fehlerhaften CRC aufweisen), die an dem Port empfangen wurden. |
Anordnungsfehler entstehen, wenn der Frame nicht vollständig in die Leitung kopiert wird, was zu fragmentierten Frames führt. Anordnungsfehler sind das Ergebnis von Kollisionen bei Halbduplex, einer Duplex-Fehlanpassung, fehlerhafter Hardware (NIC, Kabel oder Port) oder verbundenen Geräten, die Frames generieren, die nicht mit einem Oktett enden und eine fehlerhafte FCS aufweisen. |
FCS error (FCS-Fehler) |
Die FCS-Fehleranzahl gibt die Anzahl der Frames an, die mit einer falschen Prüfsumme (CRC-Wert) im Ethernet-Frame empfangen wurden. Diese Frames werden verworfen und nicht an andere Ports weitergegeben. |
FCS-Fehler sind das Ergebnis von Kollisionen bei Halbduplex, einer Duplex-Fehlanpassung, fehlerhafter Hardware (NIC, Kabel oder Port) oder verbundenen Geräten, die Frames mit einer fehlerhaften FCS generieren. |
Undersize frames (zu kleine Frames) |
Diese Frames geben die Gesamtanzahl der empfangenen Pakete an, die weniger als 64 Oktette lang waren (exklusive der Frame-Bits, aber inklusive FCS) und einen guten FCS-Wert aufweisen. |
Dies kann ein Hinweis auf einen fehlerhaften Frame sein, der vom verbundenen Gerät generiert wurde. Überprüfen Sie, ob das angeschlossene Gerät ordnungsgemäß funktioniert. |
Oversize frames (übergroße Frames) |
Anzahl der Pakete, die vom Port vom Netzwerk empfangen wurden und die eine Größe von 1514 Byte überschreiten. |
Dies kann ein Hinweis auf fehlerhafte Hardware, dot1q oder ISL-Trunking-Konfigurationsprobleme sein. |
Collision fragments (Kollisionsfragmente) |
Die Gesamtanzahl der Frames, die weniger als 64 Oktette lang sind (exklusive der Frame-Bits, aber inklusive FCS) und einen schlechten FCS-Wert aufweisen. |
Wenn dieser Zähler erhöht wird, ist dies ein Hinweis darauf, dass die Ports auf Halbduplex konfiguriert sind. Ändern Sie die Duplexeinstellung in Vollduplex. |
Overrun frames (Überlauf von Frames) |
Die Häufigkeit, mit der die Empfängerhardware empfangene Daten nicht an einen Hardwarepuffer übergeben konnte. |
Die Traffic-Eingangsrate hat die Fähigkeit des Empfängers überschritten, die Daten zu verarbeiten. |
VLAN filtered frames (VLAN-gefilterte Frames) |
Die Gesamtanzahl der Frames, die aufgrund der im Frame enthaltenen Art von VLAN-Informationen gefiltert werden. |
Der Port kann so konfiguriert werden, dass er markierte 802.1Q-Frames filtert. Wenn ein Frame empfangen wird, der ein 802.1Q-Tag enthält, wird der Frame gefiltert und diese Statistik erhöht. |
Source routed frames (quellgeführte Frames) |
Die Gesamtanzahl der empfangenen Frames, die verworfen werden, weil das Quellroutenbit in der Quelladresse des nativen Frames festgelegt wurde. |
Diese Art von Quellrouting ist nur für Token-Ring und FDDI definiert. Die IEEE-Ethernet-Spezifikation verbietet es, dieses Bit in einem beliebigen Ethernet-Frame festzulegen. Daher verwirft der Switch solche Frames. |
Valid oversize frames (gültige übergroße Frames) |
Die Gesamtanzahl der empfangenen Frames, deren Länge die System-MTU überschreitet, die jedoch gute FCS-Werte aufweisen. |
Diese Statistik zählt Frames, die die konfigurierte System-MTU überschreiten, die jedoch von 1518 Byte erhöht werden können, um Q-in-Q- oder MPLS-Kapselungen zu ermöglichen. |
Symbol error frames (Symbolfehler-Frames) |
Gigabit-Ethernet (1000 Base-X) verwendet die 8B/10B-Codierung, um 8-Bit-Daten von der MAC-Teilschicht (Schicht 2) in ein 10-Bit-Symbol zu übersetzen, das über das Kabel gesendet wird. Wenn ein Port ein Symbol empfängt, extrahiert er die 8-Bit-Daten aus dem Symbol (10 Bit). |
Ein Symbolfehler bedeutet, dass die Schnittstelle ein nicht definiertes (ungültiges) Symbol erkennt. Kleine Mengen an Symbolfehlern können ignoriert werden. Große Mengen an Symbolfehlern können auf ein fehlerhaftes Gerät, Kabel oder fehlerhafte Hardware hinweisen. |
Invalid frames, too large (ungültige Frames, zu groß) |
Giant-Frames oder empfangene Frames, die die maximale Frame-Größe nach IEEE 802.3 (1518 Byte für Nicht-Jumbo-Ethernet) überschreiten und eine fehlerhafte Frame Check Sequence (FCS) aufweisen. |
In vielen Fällen ist dies das Ergebnis einer fehlerhaften Netzwerkkarte. Versuchen Sie, das fehlerhafte Gerät zu finden, und entfernen Sie es aus dem Netzwerk. |
Invalid frames, too small (ungültige Frames, zu klein) |
Runt-Frames oder empfangene Frames, die kleiner als 64 Byte sind (einschließlich der FCS-Bits und ausschließlich des Frame-Headers) und entweder einen FCS-Fehler oder einen Anordnungsfehler aufweisen. |
Dies kann durch eine Duplex-Fehlanpassung und physische Probleme wie ein fehlerhaftes Kabel, einen fehlerhaften Port oder eine fehlerhafte Netzwerkkarte an dem angeschlossenen Gerät verursacht werden. |
Informationen zum Nachrichtenformat des Cisco IOS-Systems finden Sie im Leitfaden zu Nachrichten und Wiederherstellungsverfahren für die von Ihnen ausgeführte Softwareversion. Sie können sich beispielsweise die Meldungen und Wiederherstellungsverfahren für Cisco IOS-Versionen ansehen.
Diese Fehlermeldung wird verursacht, wenn ein Frame übertragen wird und der lokale Puffer des lokalen Controller-Chip-Puffers nicht genügend Daten empfängt. Die Daten können nicht schnell genug auf den Chip übertragen werden, um mit der Ausgaberate Schritt zu halten. Normalerweise ist ein solcher Zustand temporär und hängt von vorübergehenden Spitzenlasten im System ab. Das Problem tritt auf, wenn eine übermäßige Menge an Traffic von der Fast-Ethernet-Schnittstelle verarbeitet wird. Die Fehlermeldung wird empfangen, wenn der Traffic etwa 2,5 MB erreicht. Diese Einschränkung des Traffics ist auf Hardwarebeschränkungen zurückzuführen. Daher besteht die Möglichkeit, dass das mit dem Catalyst Switch verbundene Gerät Pakete verwirft.
Das Problem wird in der Regel behoben, indem das System automatisch wiederhergestellt wird. Es sind keine Maßnahmen erforderlich. Wenn die Ethernet-Schnittstelle durch den Switch überlastet wird, sollten Sie die Geschwindigkeits- und Duplexeinstellungen überprüfen. Verwenden Sie auch ein Sniffer-Programm, um Pakete zu analysieren, die in der Fast-Ethernet-Schnittstelle des Routers ein- und ausgehen. Geben Sie zur Vermeidung von Paketverlusten auf dem mit dem Catalyst Switch verbundenen Gerät in der Fast-Ethernet-Schnittstelle des Geräts den Befehl ip cef aus.
Der Grund für diese Fehlermeldung ist der Empfang eines Pakets von der Switch-Fabric, bei dem der CRC-Wert im Fabric-Header für dieses Paket nicht mit dem vom Fabric Interface Controller(FIC)-Unterblock des Blackwater-ASIC berechneten CRC-Wert übereinstimmt. Dies zeigt an, dass das Paket während der Übertragung beschädigt wurde und Blackwater das beschädigte Paket erhalten hat.
Bei Switches, die sowohl L3-Schnittstellen als auch L2-Switch-Ports unterstützen, wird die Meldung "Befehl abgelehnt: [Schnittstelle] kein Switching-Port" angezeigt, wenn Sie versuchen, einen Befehl für Layer 2 an einem Port einzugeben, der als Layer-3-Schnittstelle konfiguriert ist.
Um die Schnittstelle vom Layer-3-Modus in den Layer-2-Modus zu konvertieren, geben Sie den Schnittstellenkonfigurationsbefehl switchport ein. Konfigurieren Sie nach der Befehlsausgabe den Port für beliebige Layer-2-Eigenschaften.
Eine offensichtliche, aber manchmal übersehene Ursache für einen Ausfall der Portverbindung ist eine falsche Konfiguration des Switches. Wenn ein Port durchgehend orange leuchtet, bedeutet dies, dass die Software im Switch den Port entweder über die Benutzeroberfläche oder durch interne Prozesse heruntergefahren hat.
Hinweis: Einige Port-LEDs der Plattform funktionieren in Bezug auf STP unterschiedlich. Der Catalyst 1900/2820 aktiviert bei den Ports beispielsweise die orangefarbene LED, wenn sie sich im STP-Blockiermodus befinden. In diesem Fall kann eine orangefarbene LED die normalen Funktionen des STP anzeigen. Der Catalyst 6000/4000 aktiviert nicht die orangefarbene Port-LED, wenn er sich im STP-Blockiermodus befindet.
Stellen Sie sicher, dass der Port oder das Modul nicht aus irgendeinem Grund deaktiviert oder ausgeschaltet wurde. Wenn ein Port oder ein Modul auf einer Seite der Verbindung manuell abgeschaltet wird, wird die Verbindung erst wieder hergestellt, wenn Sie den Port wieder aktivieren. Überprüfen Sie den Portstatus auf beiden Seiten. Verwenden Sie den Befehl show run interface, und überprüfen Sie, ob die Schnittstelle in einem heruntergefahrenen Zustand ist:
Switch#show run interface fastEthernet 4/2 ! interface FastEthernet4/2 switchport trunk encapsulation dot1q switchport mode trunk shutdown duplex full speed 100 end
!--- Use the no shut command in config-if mode to re-enable this interface.
Wenn der Port unmittelbar nach einem Neustart des Switches in den Shutdown-Modus wechselt, ist die Ursache dafür vermutlich die Port-Sicherheitseinstellungen. Wenn Unicast-Flooding für diesen Port aktiviert ist, kann der Port nach einem Neustart heruntergefahren werden. Cisco empfiehlt, Unicast-Flooding zu deaktivieren, da dadurch auch sichergestellt wird, dass am Port kein Flooding auftritt, sobald die MAC-Adressgrenze erreicht ist.
Standardmäßig kann ein Port oder eine Schnittstelle durch Softwareprozesse heruntergefahren werden, wenn bestimmte Fehler erkannt werden.
Wenn Sie den Schnittstellenkartentyp-Statusbefehl {slot/port} für Cisco IOS betrachten:
Router#show interface fastethernet 2/4 status Port Name Status Vlan Duplex Speed Type Gi2/4 err-disabled 1 full 1000 1000BaseSX
!--- The show interfaces card-type {slot/port} status command for Cisco IOS !--- displays a status of errdisabled. !--- The show interfaces status errdisabled command shows all the interfaces !--- in this status.
Der Befehl show logging für Cisco IOS zeigt außerdem die Fehlermeldungen (mit unterschiedlichem Nachrichtenformat) an, die sich auf den errdisable-Status beziehen.
Web-Ports oder Schnittstellen, die aufgrund von „errdisable“ heruntergefahren werden, werden in Cisco IOS als Ursachen bezeichnet. Die Ursache für dieses Ereignis kann eine EtherChannel-Fehlkonfiguration, die einen PAgP-Flap verursacht, eine Duplex-Fehlanpassung, eine gleichzeitige Konfiguration von BPDU Port-Guard und Portfast, eine UDLD, die eine unidirektionale Verbindung erkennt, usw. sein.
Sie müssen den Port oder die Schnittstelle erneut manuell aktivieren, um den errdisable-Status zu deaktivieren, es sei denn, Sie konfigurieren eine errdisable-Wiederherstellungsoption. In der Cisco IOS-Software können Sie einen Port nach einer konfigurierbaren Zeitspanne, die Sie im errdisable-Status verbracht haben, automatisch wieder aktivieren. Das Endergebnis ist, dass, selbst wenn Sie die Schnittstelle für die Wiederherstellung von „errdisable“ konfigurieren, das Problem erneut auftritt, bis die Ursache ermittelt wurde.
Hinweis: Weitere Informationen zum Status „errdisable“ auf Switches mit Cisco IOS finden Sie unter Wiederherstellung aus dem errdisable-Portstatus auf Cisco IOS-Plattformen.
Diese Tabelle zeigt ein Beispiel für die Befehle zur Konfiguration, Überprüfung und Fehlerbehebung des errdisable-Status von Switches. Weitere Informationen zu den Befehlen finden Sie unter dem Link Wiederherstellung aus dem errdisable-Portstatus auf Cisco IOS-Plattformen:
Aktion | errdisable-Befehle in Cisco IOS |
---|---|
Konfigurieren | errdisable detect cause |
Konfigurieren | errdisable recovery cause |
Konfigurieren | errdisable recovery interval <timer_interval_in_seconds> |
Überprüfen und Fehlerbehebung | show errdisable detect |
Überprüfen und Fehlerbehebung | show interfaces status err-disabled |
Eine häufige Ursache für inaktive Ports bei Switches, auf denen Cisco IOS ausgeführt wird, ist das Verschwinden des VLAN, zu dem sie gehören. Dies kann auftreten, wenn Schnittstellen als Layer-2-Switch-Ports konfiguriert werden, die den Befehl switchport verwenden.
Jeder Port in einem Layer-2-Switch gehört zu einem VLAN. Jeder Port auf einem Layer-3-Switch, der als L2-Switchport konfiguriert ist, muss ebenfalls zu einem VLAN gehören. Wenn dieses VLAN gelöscht wird, wird der Port oder die Schnittstelle inaktiv.
Hinweis: Bei einigen Switches leuchtet die LED an den einzelnen Ports orange (gelb).
Verwenden Sie den Befehl show interfaces card-type {slot/port} switchport zusammen mit show vlan, um dies zu überprüfen.
Router#show interfaces fastEthernet 4/47 switchport Name: Fa4/47Switchport: Enabled Administrative Mode: static access Operational Mode: static access Administrative Trunking Encapsulation: negotiate Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 11 ((Inactive))
!--- FastEth 4/47 is inactive. Router#show vlan VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Gi1/1, Gi2/1, Fa6/6 10 UplinkToGSR's active Gi1/2, Gi2/2
!--- VLANs are displayed in order and VLAN 11 is not available.
30 SDTsw-1ToSDTsw-2Link active Fa6/45
Wenn es sich bei dem Switch, der das VLAN gelöscht hat, um einen VTP-Server für die VTP-Domain handelt, wird das VLAN bei jedem Server- und Client-Switch in der Domain ebenfalls aus der zugehörigen VLAN-Tabelle entfernt. Wenn Sie das VLAN wieder in die VLAN-Tabelle eines VTP-Server-Switches hinzufügen, werden die Ports der Switches in der Domain, die zu diesem wiederhergestellten VLAN gehören, wieder aktiv. Ein Port merkt sich, welchem VLAN er zugewiesen ist, auch wenn das VLAN selbst gelöscht wird. Weitere Informationen zu VTP finden Sie unter Verstehen und Konfigurieren des VLAN Trunk Protocol (VTP).
Hinweis: Wenn die Ausgabe des Befehls show interface <Schnittstelle> switchport den Port auch dann als Trunk-Port anzeigt, wenn Sie den Port mit dem Befehl switchport access vlan <vlan> als Access-Port konfigurieren, geben Sie den Befehl switchport mode access aus, um den Port als Access-Port festzulegen.
Auf einem Switch der Catalyst 4510R-Serie gibt es eine optionale Konfiguration, um sowohl die 10-Gigabit-Ethernet- als auch die Gigabit-Ethernet-SFP-Uplink-Ports zu aktivieren. Geben Sie für die gleichzeitige Verwendung der 10-Gigabit-Ethernet- und Gigabit-Ethernet-SFP-Schnittstellen den Befehl hw-module uplink select all aus. Starten Sie den Switch neu, nachdem Sie den Befehl ausgegeben haben. Andernfalls wird der Uplink-Port in der Ausgabe des Befehls show interface status module <module number> (Schnittstellenstatusmodul <Modulnummer> anzeigen) als inaktiv angezeigt.
Cisco IOS-Softwareversion 12.2(25)SG unterstützt die gleichzeitige Verwendung von 10-Gigabit-Ethernet- und Gigabit-Ethernet-SFP-Schnittstellen auf Catalyst 4500-Switches.
Hinweis: Bei den Catalyst-Switches der 4503-, 4506- und 4507R-Serie wird diese Funktion automatisch aktiviert.
Ursache hierfür ist, dass die für diesen Switch bestimmte Traffic-Last zu hoch ist und dazu führt, dass die Frames verworfen werden. Normalerweise geben die verzögerten Frames die Anzahl der Frames an, die nach dem Warten auf die Medien erfolgreich übertragen wurden, da die Medien ausgelastet waren. Dies tritt normalerweise in Halbduplex-Umgebungen auf, in denen der Carrier bereits verwendet wird, wenn er versucht, einen Frame zu übertragen. Doch in Vollduplex-Umgebungen tritt das Problem auf, wenn die übermäßige Last für den Switch bestimmt ist.
Problemumgehung:
Hartcodieren Sie beide Enden der Verbindung zu Vollduplex, damit die Verhandlungsinkongruenz vermieden werden kann.
Wechseln Sie das Kabel und das Patchpanel-Kabel, um sicherzustellen, dass die Kabel nicht defekt sind.
Hinweis: Wenn der Fehler „Deferred Counter“ in einem Gigabit-Ethernet eines Supervisor 720 erhöht wird, aktivieren Sie die Geschwindigkeitsverhandlung auf der Schnittstelle als Problemumgehung.
Das Problem tritt auf, wenn die EARL (Encoded Address Recognition Logic) die CAM-Fälligkeitszeit für das VLAN nicht auf die erforderliche Anzahl von Sekunden festlegen kann. Hier ist die VLAN-Fälligkeitszeit bereits auf Fast Aging eingestellt.
Wenn sich das VLAN bereits im Fast-Aging-Modus befindet, kann EARL das VLAN nicht auf Fast-Aging festlegen. Der Prozess zum Festlegen des Fälligkeits-Timers wird dann blockiert. Die CAM-Standardfälligkeitszeit beträgt fünf Minuten. Das heißt, dass der Switch die Tabelle mit den erfassten MAC-Adressen alle fünf Minuten leert. Dadurch wird sichergestellt, dass die MAC-Adressentabelle (die CAM-Tabelle) die neuesten Einträge enthält.
Durch Fast Aging wird die CAM-Fälligkeitszeit vorübergehend auf die vom Benutzer angegebene Anzahl von Sekunden festgelegt und in Verbindung mit dem TCN-Prozess (Topology Change Notification) verwendet. Die Idee ist, dass bei einer Topologieänderung dieser Wert erforderlich ist, um die CAM-Tabelle schneller zu leeren und die Topologieänderung zu kompensieren.
Geben Sie den Befehl show cam aging aus, um die CAM-Fälligkeitszeit auf dem Switch zu überprüfen. TCNs und Fast Aging sind ziemlich selten. Daher hat die Nachricht den Schweregrad 3. Wenn die VLANs häufig schnell altert, sollten Sie den Grund für das Fast Aging prüfen.
Der häufigste Grund für TCNs sind Client-PCs, die direkt mit einem Switch verbunden sind. Wenn Sie den PC ein- oder ausschalten, ändert der Switch-Port seinen Status und der Switch startet den TCN-Prozess. Dies liegt daran, dass der Switch nicht weiß, dass das angeschlossene Gerät ein PC ist. Der Switch weiß nur, dass der Port seinen Status geändert hat.
Zur Behebung dieses Problem hat Cisco die PortFast-Funktion für Host-Ports entwickelt. Ein Vorteil von PortFast ist, dass diese Funktion TCNs für einen Host-Port unterdrückt.
Hinweis: PortFast umgeht auch Spanning-Tree-Berechnungen an dem Port und ist daher nur für die Verwendung auf einem Host-Port geeignet.
Überprüfen Sie den Trunking-Modus auf beiden Seiten der Verbindung. Stellen Sie sicher, dass sich beide Seiten im gleichen Modus befinden (beide Trunking mit der gleichen Methode: ISL oder 802.1q, oder beide nicht Trunking). Wenn Sie den Trunking-Modus für einen Port aktivieren (im Gegensatz zu „auto“ (automatisch) oder „desirable“ (erwünscht)) und der Trunking-Modus des anderen Ports deaktiviert ist, können sie nicht kommunizieren. Durch Trunking wird die Formatierung des Pakets geändert. Die Ports müssen sich darüber einig sein, welches Format sie für die Verbindung verwenden. Andernfalls können sie nicht kommunizieren.
Verwenden Sie für Cisco IOS den Befehl show interfaces card-type {mod/port} trunk, um die Trunking-Konfiguration und das native VLAN zu überprüfen.
Router#show interfaces fastEthernet 6/1 trunk Port Mode Encapsulation Status Native vlan Fa6/1 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa6/1 1-4094 !--- Output truncated.
Weitere Informationen zu den verschiedenen Trunking-Modi, Richtlinien und Einschränkungen finden Sie in den folgenden Dokumenten:
Die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) des Datenbereichs eines Ethernet-Frames beträgt standardmäßig 1500 Byte. Wenn die MTU des übertragenen Traffics die unterstützte MTU überschreitet, leitet der Switch das Paket nicht weiter. Darüber hinaus erhöhen einige Switch-Plattformen abhängig von der Hardware und Software die Port- und Schnittstellenfehlerzähler.
Jumbo-Frames sind nicht als Teil des IEEE-Ethernet-Standards definiert und anbieterabhängig. Sie können als jeder Frame definiert werden, der größer als der Standard-Ethernet-Frame von 1518 Byte ist (einschließlich L2-Header und Cyclic Redundancy Check (CRC)). Bei Jumbos sind die Frames größer, in der Regel > 9000 Bytes.
Giant-Frames sind alle Frames, die die maximale Größe eines Ethernet-Frames überschreiten (größer als 1518 Bytes), der eine fehlerhafte FCS aufweist.
Baby Giant-Frames überschreiten die maximale Größe eines Ethernet-Frames nur leicht. In der Regel sind dies Frames mit einer Größe von bis zu 1600 Bytes.
Die Unterstützung von Jumbo- und Baby Giant-Frames bei Catalyst-Switches variiert je nach Switch-Plattform, manchmal sogar nach Modulen im Switch. Auch die Softwareversion spielt eine Rolle.
Weitere Informationen zu Systemanforderungen, Konfiguration und Fehlerbehebung bei Problemen mit Jumbo- und Baby-Riesen finden Sie unter Configuring Jumbo/Giant Frame Support on Catalyst Switches.
Überprüfen Sie das Endgerät, indem Sie zuerst den direkt verbundenen Switch anpingen. Arbeiten Sie sich dann Port für Port, Schnittstelle für Schnittstelle, Trunk für Trunk zurück, bis Sie die Quelle des Verbindungsproblems gefunden haben. Stellen Sie sicher, dass jeder Switch die MAC-Adresse des Endgeräts in seiner CAM-Tabelle (Content-Addressable Memory) sehen kann.
Verwenden Sie den Befehl show mac address-table dynamic oder ersetzen Sie das interface-Schlüsselwort.
Router#show mac-address-table interface fastEthernet 6/3 Codes: * - primary entry vlan mac address type learn qos ports ------+----------------+--------+-----+---+-------------------------- * 2 0040.ca14.0ab1 dynamic No -- Fa6/3
!--- A workstation on VLAN 2 with MAC address 0040.ca14.0ab1 is directly connected !--- to interface fastEthernet 6/3 on a switch running Cisco IOS.
Sobald Sie wissen, dass der Switch tatsächlich die MAC-Adresse des Geräts in seiner CAM-Tabelle hat, stellen Sie fest, ob sich dieses Gerät in demselben oder einem anderen VLAN befindet, von dem aus Sie versuchen, den Ping-Befehl auszuführen.
Wenn sich das Endgerät in einem anderen VLAN befindet als dem, in dem Sie versuchen, den Ping-Befehl auszuführen, muss ein L3-Switch oder -Router konfiguriert werden, damit die Geräte kommunizieren können. Stellen Sie sicher, dass Ihre L3-Adressierung auf dem Endgerät und auf dem Router/L3-Switch korrekt konfiguriert ist. Überprüfen Sie IP-Adresse, Subnetzmaske, Standard-Gateway, Konfiguration des dynamischen Routing-Protokolls, statische Routen usw.
Wenn Stationen nicht in der Lage sind, mit ihren primären Servern zu kommunizieren, wenn sie sich über einen Switch verbinden, kann das Problem darin bestehen, dass der Switch-Port erst nach dem Verbindungsaufbau auf der physischen Ebene aktiv wird. In einigen Fällen können diese Verzögerungen bis zu 50 Sekunden betragen. Einige Workstations können bei der Suche nach ihrem Server einfach nicht so lange warten und brechen daher den Vorgang ab. Diese Verzögerungen werden durch STP, Trunking-Verhandlungen (DTP) und EtherChannel-Verhandlungen (PAgP) verursacht. Alle diese Protokolle können für Zugriffsports deaktiviert werden, wenn sie nicht benötigt werden. Demnach beginnt der Switch-Port oder die Schnittstelle einige Sekunden nach der Herstellung einer Verbindung mit dem Nachbargerät mit der Weiterleitung von Paketen.
In Cisco IOS können Sie mit dem Befehl switchport host das Channeling deaktivieren und Spanning-Tree-Portfast aktivieren. Mit dem Befehl switchport nonegotiate können Sie DTP-Verhandlungspakete deaktivieren. Verwenden Sie den Befehl interface-range , um mehrere Schnittstellen gleichzeitig zu deaktivieren.
Router6k-1(config)#interface range fastEthernet 6/13 - 18 Router6k-1(config-if-range)#switchport Router6k-1(config-if-range)#switchport host switchport mode can be set to access spanning-tree portfast can be enabled channel group can be disabled !--- Etherchannel is disabled and portfast is enabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#switchport nonegotiate !--- Trunking negotiation is disabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#end Router6k-1#
Cisco IOS bietet die Möglichkeit, den globalen Spanning-Tree-Standardbefehl portfast zu verwenden, um portfast automatisch auf jede Schnittstelle anzuwenden, die als Layer-2-Access-Switch-Port konfiguriert ist. Überprüfen Sie die Befehlsreferenz für Ihre Softwareversion, um die Verfügbarkeit dieses Befehls zu überprüfen. Sie können auch den Befehl spanning-tree portfast pro Schnittstelle verwenden. Hierzu müssen Sie jedoch Trunking und EtherChannel separat deaktivieren, um Verzögerungen beim Start der Workstation vorzubeugen.
Hinweis: Weitere Informationen zum Beheben von Startverzögerungen finden Sie unter Verwenden von Portfast und anderen Befehlen zum Beheben von Verbindungsverzögerungen beim Starten von Workstations.
Wenn eine große Anzahl von Anordnungsfehlern, FCS-Fehlern oder späten Kollisionen vorliegt, kann dies auf Folgendes hinweisen:
Duplexkonflikt
Fehlerhaftes oder beschädigtes Kabel
Duplexkonflikt
Ein häufiges Problem mit Geschwindigkeit/Duplex ist, wenn bei den Duplexeinstellungen zwischen zwei Switches, zwischen einem Switch und einem Router oder zwischen dem Switch und einer Workstation oder einem Server eine Fehlanpassung vorliegt. Dies kann der Fall sein, wenn Geschwindigkeit und Duplex manuell hartcodiert werden oder Probleme bei der automatischen Verhandlung zwischen den beiden Geräten aufgetreten sind.
Wenn die Fehlanpassung zwischen zwei Cisco Geräten mit aktiviertem Cisco Discovery Protocol (CDP) auftritt, werden die CDP-Fehlermeldungen auf der Konsole oder im Protokollierungspuffer beider Geräte angezeigt. CDP ist nützlich, um Fehler sowie Port- und Systemstatistiken auf Cisco Geräten in der Nähe zu erkennen. CDP ist Eigentum von Cisco und funktioniert, indem Pakete an eine bekannte MAC-Adresse 01-00-0C-CC-CC-CC gesendet werden.
Das Beispiel zeigt die Protokollmeldungen, die aus einer Duplexdiskrepanz zwischen zwei Catalyst Switches der Serie 6000 mit Cisco IOS resultieren. Diese Nachrichten geben in der Regel an, um welche Fehlanpassung es sich handelt und wo diese auftritt.
Jun 2 11:16:45 %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet6/2 (not half duplex), with TBA04251336 3/2 (half duplex).
Verwenden Sie den Befehl show cdp neighbors card-type <slot/port> detail, um CDP-Informationen für benachbarte Cisco Geräte anzuzeigen.
Router#show cdp neighbors fastEthernet 6/1 detail ------------------------- Device ID: TBA04251336 Entry address(es): IP address: 10.1.1.1 Platform: WS-C6006, Capabilities: Trans-Bridge Switch IGMP Interface: FastEthernet6/1, Port ID (outgoing port): 3/1 Holdtime : 152 sec Version : WS-C6006 Software, Version McpSW: 6.3(3) NmpSW: 6.3(3) Copyright (c) 1995-2001 by Cisco Systems !--- Neighbor device to FastEth 6/1 is a Cisco Catalyst 6000 Switch !--- on port 3/1 running CatOS. advertisement version: 2 VTP Management Domain: 'test1' Native VLAN: 1 Duplex: full !--- Duplex is full. Router#
Das Festlegen von automatischer Geschwindigkeit/Duplex auf einer Seite und 100/Vollduplex auf der anderen Seite ist ebenfalls eine Fehlkonfiguration und kann zu einer Duplex-Fehlanpassung führen. Wenn der Switch-Port viele spätere Kollisionen empfängt, deutet dies normalerweise auf das Problem einer Duplex-Fehlanpassung hin und kann dazu führen, dass der Port in den Status „errdisable“ versetzt wird. Die Halbduplex-Seite erwartet nur Pakete zu bestimmten Zeiten, nicht zu jedem Zeitpunkt, und zählt daher Pakete, die zum falschen Zeitpunkt empfangen wurden, als Kollisionen. Neben Duplex-Fehlanpassungen gibt es auch andere Ursachen für späte Kollisionen, doch dies ist einer der häufigsten Gründe. Legen Sie immer beide Seiten der Verbindung so fest, dass Geschwindigkeit/Duplex per Autonegotiation ausgehandelt wird, oder legen Sie Geschwindigkeit/Duplex manuell auf beiden Seiten fest.
Verwenden Sie den Befehl show interfaces <Kartentyp> <Steckplatz/Port> status, um die Geschwindigkeit und die Duplexeinrichtung sowie weitere Informationen anzuzeigen. Verwenden Sie die Befehle speed und duplex aus dem Schnittstellenkonfigurationsmodus, um beide Seiten je nach Bedarf auf 10 oder 100 und halb oder voll zu codieren.
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 connected 1 a-full a-100 10/100BaseTX
Wenn Sie den Befehl show interfaces ohne die Status-Option verwenden, sehen Sie eine Konfiguration für Geschwindigkeit und Duplex, aber Sie wissen nicht, ob diese Geschwindigkeit und dieser Duplex durch automatische Aushandlung erreicht wurde oder nicht.
Router#show interface fas 6/1 FastEthernet6/1 is up, line protocol is up (connected) Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 100Mb/s
!--- Full-duplex and 100Mbps does not tell you whether autoneg was used to achieve this. !--- Use the sh interfaces fas 6/1 status command to display this.
Fehlerhaftes oder beschädigtes Kabel
Überprüfen Sie das Kabel immer auf geringfügige Schäden oder Ausfälle. Ein Kabel kann gerade gut genug sein, um es auf der physischen Ebene zu verbinden, kann Pakete jedoch durch geringfügige Schäden an der Verkabelung oder den Anschlüssen beschädigen. Überprüfen Sie das Kupfer- oder Glasfaserkabel oder tauschen Sie es aus. Tauschen Sie den GBIC gegen Glasfaserverbindungen aus (sofern er austauschbar ist). Prüfen Sie, ob Patchpanel-Verbindungen oder Medienkonverter zwischen Quelle und Ziel Fehler aufweisen. Testen Sie das Kabel an einem anderen Port oder einer anderen Schnittstelle aus, sofern verfügbar, und prüfen Sie, ob das Problem weiterhin besteht.
Automatische Aushandlung und Probleme mit der NIC-Karte
Manchmal treten zwischen Cisco Switches und bestimmten NIC-Karten von Drittanbietern Probleme auf. Standardmäßig sind Catalyst Switch-Ports und -Schnittstellen auf automatische Aushandlung festgelegt. Es ist üblich, dass Geräte wie Laptops oder andere Geräte ebenfalls auf automatische Aushandlung festgelegt sind, doch manchmal treten bei der automatischen Aushandlung Probleme auf.
Zur Behebung von Problemen bei der automatischen Verhandlung wird häufig empfohlen, für beide Seiten eine Hartcodierung zu verwenden. Wenn weder automatische Verhandlung noch Hartcodierung zu funktionieren scheinen, liegt möglicherweise ein Problem mit der Firmware oder Software auf Ihrer NIC-Karte vor. Aktualisieren Sie den NIC-Kartentreiber auf die neueste Version, die auf der Website des Herstellers verfügbar ist, um dieses Problem zu beheben.
Einzelheiten zur Behebung von Geschwindigkeits-/Duplexproblemen und zur automatischen Aushandlung finden Sie unter Configuring and Troubleshooting Ethernet 10/100/1000 MB Half/Full Duplex Auto-Negotiation (Konfigurieren und Problembehebung bei Ethernet 10/100/1000 MB).
Weitere Informationen zur Behebung von Problemen mit NIC-Karten von Drittanbietern finden Sie unter Fehlerbehebung bei Problemen mit der NIC-Kompatibilität von Cisco Catalyst Switches.
Spanning Tree Protocol(STP)-Schleifen können schwerwiegende Leistungsprobleme verursachen, die als Port- oder Schnittstellenprobleme getarnt sind. In diesem Fall wird Ihre Bandbreite immer wieder von denselben Frames verwendet. Dies lässt wenig Platz für legitimen Traffic.
Die STP Loop Guard-Funktion bietet zusätzlichen Schutz vor Layer-2-Weiterleitungsschleifen (STP-Schleifen). Eine STP-Schleife (Loop) entsteht, wenn in einer redundanten Topologie ein blockierender STP-Port irrtümlicherweise in den Weiterleitungszustand übergeht. Dies tritt in der Regel ein, weil einer der Ports in einer physisch redundanten Topologie (nicht zwangsläufig der blockierende STP-Port) keine STP-BPDUs mehr empfängt. Bei seinem Betrieb stützt sich STP auf kontinuierlichen Empfang oder die Übertragung von BPDUs basierend auf der Port-Rolle. Der designierte Port überträgt BPDUs und der nicht designierte Port empfängt BPDUs.
Wenn einer der Ports in einer physisch redundanten Topologie keine BPDUs mehr empfängt, stellt der STP fest, dass die Topologie schleifenfrei ist. Anschließend wird der blockierende Port des alternativen oder Backup-Ports festgelegt und wechselt in den Weiterleitungsstatus. Diese Situation erzeugt eine Schleife.
Die Loop Guard-Funktion führt zusätzliche Prüfungen durch. Wenn BPDUs auf einem nicht designierten Port nicht empfangen werden und Loop Guard aktiviert ist, wird dieser Port in den inkonsistenten STP Loop-Blockierstatus statt in den Überwachungs-, Ermittlungs- oder Weiterleitungsstatus versetzt. Ohne die Loop Guard-Funktion übernimmt der Port die angegebene Port-Rolle. Der Port wechselt in den STP-Weiterleitungsstatus und erstellt eine Schleife. Weitere Informationen zur Funktion des Loop Guards finden Sie unter Configure STP with Loop Guard and BPDU Skew Detection.
Dieses Dokument beschreibt die Gründe, warum STP fehlschlagen kann, nach welchen Informationen Sie suchen sollten, um die Ursache des Problems zu ermitteln, und durch welche Art von Design STP-Risiken minimiert werden.
Schleifen können auch durch eine unidirektionale Verbindung verursacht werden. Weitere Informationen finden Sie im Abschnitt „UDLD: Probleme mit unidirektionalen Links“ in diesem Dokument.
Eine unidirektionale Verbindung ist eine Verbindung, bei der der Traffic in eine Richtung abgeht, aber kein Traffic in Eingangsrichtung empfangen wird. Der Switch weiß nicht, dass die Eingangsrichtung der Verbindung fehlerhaft ist (der Port denkt, dass die Verbindung aktiv ist und funktioniert).
Diese unidirektionale Kommunikation kann durch ein defektes Glasfaserkabel oder andere Verkabelungs-/Portprobleme verursacht werden. Diese teilweise funktionsfähigen Verbindungen können Probleme wie STP-Schleifen verursachen, wenn die beteiligten Switches nicht wissen, dass die Verbindung teilweise unterbrochen ist. UDLD kann einen Port in den Status „errdisable“ versetzen, wenn er eine unidirektionale Verbindung erkennt. Der Befehl udld aggressive-mode kann auf Switches mit Cisco IOS (siehe Versionshinweise zur Befehlsverfügbarkeit) für Punkt-zu-Punkt-Verbindungen zwischen Switches konfiguriert werden, bei denen fehlerhafte Verbindungen nicht toleriert werden können. Mithilfe dieser Funktion können Sie schwer zu findende Probleme mit unidirektionalen Verbindungen identifizieren.
Konfigurationsinformationen zu UDLD finden Sie unter Configure the UDLD Protocol Feature.
Wenn Sie über eine große Anzahl von verzögerten Frames oder Out-Discards (auf einigen Plattformen auch als Out-Lost bezeichnet) verfügen, bedeutet dies, dass die Ausgangspuffer des Switches voll sind und der Switch diese Pakete verwerfen musste. Dies kann ein Zeichen dafür sein, dass dieses Segment mit einer geringeren Geschwindigkeit und/oder Duplex betrieben wird oder dass zu viel Traffic über diesen Port läuft.
Verwenden Sie den Befehl show interfaces counters error (Schnittstellenzähler anzeigen), um OutDiscards anzuzeigen.
Router#show interfaces counters error Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Fa7/47 0 0 0 0 0 0 Fa7/48 0 0 0 0 0 2871800 Fa8/1 0 0 0 0 0 2874203 Fa8/2 103 0 0 103 0 2878032 Fa8/3 147 0 0 185 0 0 Fa8/4 100 0 0 141 0 2876405 Fa8/5 0 0 0 0 0 2873671 Fa8/6 0 0 0 0 0 2 Fa8/7 0 0 0 0 0 0
!--- The show interfaces counters errors command shows certain interfaces !--- that increment in large amounts OutDiscards while others run clean.
Untersuchen Sie die folgenden häufigsten Ursachen für Fehler im Ausgangspuffer:
Unterdurchschnittliche Geschwindigkeit/Duplex für die Menge des Traffics
Ihr Netzwerk kann über diesen Port so viele Pakete senden, dass der Port diese mit den aktuellen Geschwindigkeits-/Duplexeinstellungen nicht verarbeiten kann. Dies kann passieren, wenn mehrere Hochgeschwindigkeits-Ports an einen einzelnen (normalerweise langsameren) Port geleitet werden. Sie können das Gerät, das an diesem Port hängt, auf schnellere Medien verschieben. Wenn der Port beispielsweise 10 Mbit/s umfasst, verschieben Sie dieses Gerät auf einen 100 Mbit/s- oder Gigabit-Port. Sie können die Topologie ändern, um Frames anders zu routen.
Überlastungsprobleme: Segment zu beschäftigt
Wenn das Segment gemeinsam genutzt wird, können andere Geräte in diesem Segment so viel übertragen, dass der Switch keine Möglichkeit zur Übertragung hat. Vermeiden Sie nach Möglichkeit verkettete Hubs. Eine Überlastung kann zu Paketverlusten führen. Paketverluste verursachen erneute Übertragungen auf der Transportschicht, was wiederum zu einer Latenz auf Anwendungsebene führt. Sie können nach Möglichkeit ein Upgrade von 10-Mbit/s-Verbindungen auf 100-Mbit/s- oder Gigabit-Ethernet-Verbindungen durchführen. Sie können einige Geräte aus überfüllten Segmenten entfernen und in andere, weniger belegte Segmente einfügen. Die Vermeidung von Überlastungen sollte in Ihrem Netzwerk Priorität haben.
Anwendungs-
Manchmal können die Eigenschaften der verwendeten Anwendungen für die Übertragung von Traffic zu Problemen mit dem Ausgangspuffer führen. NFS-Dateiübertragungen von einem Gigabit-Server, der UDP (User Datagram Protocol) mit einer Fenstergröße von 32 KB verwendet, sind ein Beispiel für eine Anwendungseinstellung, die diese Art von Problem hervorrufen kann. Wenn Sie die anderen Vorschläge in diesem Dokument geprüft oder getestet haben (Geschwindigkeit/Duplex geprüft, keine physischen Fehler in der Verbindung, der gesamte Traffic ist normal und gültig usw.), kann das Reduzieren der von der Anwendung gesendeten Einheitengröße helfen, dieses Problem zu beheben.
Wenn Sie Verhaltensweisen sehen, die nur als seltsam eingestuft werden können, können Sie das Verhalten auf ein bestimmtes Feld isolieren. Da sie sich alle bisher vorgeschlagenen Maßnahmen angesehen haben, kann dies auf Software- oder Hardwareprobleme hinweisen. In der Regel ist es einfacher, ein Software-Upgrade durchzuführen als ein Hardware-Upgrade. Ändern Sie zunächst die Software.
Verwenden Sie den Befehl show version , um die aktuelle Softwareversion zusammen mit dem Befehl dir flash : oder dir bootflash: (je nach Plattform) zu überprüfen, um den verfügbaren Flash-Speicher für das Upgrade zu überprüfen:
Router#show version Cisco Internetwork Operating System Software Cisco IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-IS-M), Version 12.1(13)EW, EA RLY DEPLOYMENT RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 20-Dec-02 13:52 by eaarmas Image text-base: 0x00000000, data-base: 0x00E638AC ROM: 12.1(12r)EW Dagobah Revision 71, Swamp Revision 24 trunk-4500 uptime is 2 weeks, 2 days, 6 hours, 27 minutes System returned to ROM by redundancy reset System image file is "bootflash:cat4000-is-mz.121-13.EW.bin"
!--- Typical Cisco IOS show version output. Router#dir bootflash: Directory of bootflash:/ 1 -rw- 8620144 Mar 22 2002 08:26:21 cat4000-is-mz.121-13.EW.bin 61341696 bytes total (52721424 bytes free)
!--- Verify available flash memory on switch running Cisco IOS.
Upgrade für die Software
Informationen zum Upgrade der Software für Ihre Cisco Switches finden Sie unter dem Link. Wählen Sie Ihre Plattform und sehen Sie sich den Abschnitt „Softwarekonfiguration“ an.
Hardware-Software-Inkompatibilität
Es kann vorkommen, dass die Software nicht mit der Hardware kompatibel ist. Dies geschieht, wenn neue Hardware auf den Markt kommt und spezielle Unterstützung durch die Software erfordert. Weitere Informationen zur Softwarekompatibilität finden Sie im Software Advisor-Tool.
Software-Bugs
Das Betriebssystem kann einen Fehler aufweisen. Wenn Sie eine neuere Softwareversion laden, kann dieser häufig behoben werden. Sie können mit dem Software-Bug-Toolkit nach bekannten Softwarefehlern suchen.
Beschädigte Bilder
Ein Image kann beschädigt worden sein. Für Informationen zur Wiederherstellung von beschädigten Images wählen Sie Ihren Plattform-Switch aus und lesen Sie den Abschnitt „Fehlerbehebung“.
Überprüfen Sie die Ergebnisse des Anzeigemoduls für Catalyst Switches der Serien 6000 und 4000 mit Cisco IOS.
Überprüfen Sie POST-Ergebnisse des Switches, um festzustellen, ob für einen Teil des Switches Fehler angezeigt wurden. Sind beim Testen eines Moduls oder Ports Fehler aufgetreten, wird ein „F“ in den Testergebnissen angezeigt.
Verwenden Sie für Cisco IOS auf modularen Switches wie dem Cat6000 den Befehl show diagnostics (Diagnose anzeigen). Um die POST-Ergebnisse pro Modul anzuzeigen, verwenden Sie den Befehl show diagnostics module < module> (Diagnosemodul anzeigen).
ecsj-6506-d2#sh diagnostic module 3 Current Online Diagnostic Level = Minimal !--- The diagnostic level is set to minimal which is a shorter, !--- but also less thorough test result. !--- You may wish to configure diagnostic level complete to get more test results. Online Diagnostic Result for Module 3 : MINOR ERROR Online Diagnostic Level when Line Card came up = Minimal Test Results: (. = Pass, F = Fail, U = Unknown) 1 . TestLoopback : Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ---------------------------------------------------------------------------- . . . . . . . . . . . . . . . . . . F F F F F F
!--- Notice the MINOR ERROR test result and failed loopback test which means !--- these ports are currently unusable. !--- Use the hw-module{mod}reset command or, if necessary, physically reseat the !--- module to try and fix this problem. !--- If these steps fail, open a case with Cisco Technical Support.
Hinweis: Bei Switches der Serien Catalyst 3750, 3550, 2970, 2950/2955 und 2900/3500XL wird der Befehl show post verwendet, der einen einfachen Lauf oder Fehler für den Hardware-Status anzeigt. Verwenden Sie die LEDs an diesen Switches, um die POST-Ergebnisse besser zu verstehen.
Weitere Informationen zur Behebung von Hardwareproblemen bei Catalyst Switches mit Cisco IOS finden Sie auf den Support-Seiten für Cisco Switches. Wählen Sie Ihre Plattform aus, und lesen Sie die Troubleshooting > Hardware
Abschnitt. Informationen zu möglichen Problemen im Zusammenhang mit Problemhinweisen finden Sie unter Problemhinweise zu für LAN- und ATM-Switches.
Standardmäßig befinden sich alle Layer-2-Ports im dynamischen Modus desirable (erwünscht), sodass der Layer-2-Port versucht, eine Trunk-Verbindung zu bilden, und DTP-Pakete an das Remote-Gerät sendet. Wenn eine Layer-3-Schnittstelle mit einem Layer-2-Switchport verbunden ist, kann sie diese Frames nicht interpretieren. Dies hat Eingabefehler, WrongEncap-Fehler und Unterbrechungen von Eingabewarteschlangen zur Folge.
Ändern Sie zur Behebung dieses Problems den Modus des Switchports gemäß Ihren Anforderungen in statischer Zugriff oder Trunk.
Switch2(config)#interface fastEthernet1/0/12 Switch2(config-if)#switchport mode access
ODER
Switch2(config)#interface fastEthernet1/0/12
Switch2(config-if)#switchport trunk encapsulation dot1q
Switch2(config-if)#switchport mode trunk
Der Zähler für Rx-No-Pkt-Buff kann bei Ports erhöht werden, wenn er über Blades verfügt, z. B. WS-X4448-GB-RJ45, WS-X4548-GB-RJ45 und WS-X4548-GB-RJ45V. Auch eine gewisse Erhöhung der verworfenen Pakete ist normal und das Ergebnis von Traffic-Spitzen.
Diese Art von Fehlern nimmt schnell zu, insbesondere wenn der Traffic über diese Verbindung hoch ist oder wenn Geräte wie Server mit dieser Schnittstelle verbunden sind. Diese hohe Traffic-Last überlastet die Ports. Dadurch sind die Eingangspuffer überlastet, was dazu führt, dass der Zähler für Rx-No-Pkt-Buff- und die Eingabefehler schnell zunehmen.
Wenn ein Paket nicht vollständig empfangen werden kann, weil der Switch keine Paketpuffer mehr hat, wird dieser Zähler für jedes verworfene Paket einmal erhöht. Dieser Zähler zeigt den internen Status der Switching-ASICs auf dem Supervisor an und zeigt nicht unbedingt einen Fehlerzustand an.
Pausen-Frames
Wenn die Rx-FIFO-Warteschlange des Empfangsteils (Rx) des Ports gefüllt ist und die obere Grenze erreicht, beginnt der Sendeteil (Tx) des Ports, Pausen-Frames mit einem darin erwähnten Intervallwert zu generieren. Es wird erwartet, dass das Remote-Gerät die Übertragung von Paketen für die im Pausen-Frame genannte Intervallzeit stoppt/reduziert.
Wenn der Rx in der Lage ist, die Rx-Warteschlange zu löschen oder die untere Grenze innerhalb dieses Intervalls zu erreichen, sendet Tx einen speziellen Pausen-Frame aus, in dem das Intervall als Null (0x0) bezeichnet wird. Dadurch kann das Remote-Gerät mit der Übertragung von Paketen beginnen.
Wenn der Rx weiterhin in der Warteschlange arbeitet, sendet der Tx nach Ablauf der Intervallzeit erneut einen neuen Pausen-Frame mit einem neuen Intervallwert.
Wenn der Zähler für Rx-No-Pkt-Buff Null ist oder nicht erhöht wird und der Zähler für TxPauseFrames erhöht wird, zeigt dies an, dass unser Switch Pausen-Frames generiert und das Remote-Ende befolgt, sodass die Rx-FIFO-Warteschlange deplantiert.
Wenn die Zähler für Rx-No-Pkt-Buff und TxPauseFrames ebenfalls erhöht werden, bedeutet dies, dass das Remote-Ende die Pausen-Frames ignoriert (unterstützt keine Flusskontrolle) und trotz Pausen-Frames weiterhin Traffic sendet. Konfigurieren Sie zur Umgehung dieser Situation die Geschwindigkeit und den Duplex manuell und deaktivieren Sie ggf. die Flusskontrolle.
Diese Arten von Fehlern in der Schnittstelle stehen im Zusammenhang mit einem Traffic-Problem mit überbelegten Ports. Die Switch-Module WS-X4448-GB-RJ45, WS-X4548-GB-RJ45 und WS-X4548-GB-RJ45V verfügen über 48 überlastete Ports in sechs Gruppen mit jeweils acht Ports:
Ports 1, 2, 3, 4, 5, 6, 7, 8
Ports 9, 10, 11, 12, 13, 14, 15, 16
Ports 17, 18, 19, 20, 21, 22, 23, 24
Ports 25, 26, 27, 28, 29, 30, 31, 32
Ports 33, 34, 35, 36, 37, 38, 39, 40
Ports 41, 42, 43, 44, 45, 46, 47, 48
Die acht Ports innerhalb jeder Gruppe verwenden gemeinsame Schaltkreise, die die Gruppe effektiv zu einer einzigen, nicht blockierenden Vollduplex-Gigabit-Ethernet-Verbindung zur internen Switch-Fabric multiplexen. Für jede Gruppe von acht Ports werden die empfangenen Frames gepuffert und an die gemeinsame Gigabit-Ethernet-Verbindung zur internen Switch-Fabric gesendet. Wenn die für einen Port empfangene Datenmenge die Pufferkapazität überschreitet, sendet die Flusskontrolle Pausen-Frames an den Remote-Port, um den Traffic vorübergehend zu stoppen und Frame-Verluste zu verhindern.
Wenn die empfangenen Frames in einer Gruppe die Bandbreite von 1 Gbit/s überschreiten, beginnt das Gerät, die Frames zu verwerfen. Diese Verluste sind nicht offensichtlich, da die Frames an der internen ASIC statt an den tatsächlichen Schnittstellen verworfen werden. Dies kann zu einer Verschlechterung des Paketdurchsatzes auf dem Gerät führen.
Der Rx-No-Pkt-Buff hängt nicht von der Gesamt-Traffic-Rate ab. Er hängt von der Menge der Pakete ab, die im Rx-FIFO-Puffer des Modul-ASIC gespeichert werden. Die Größe dieses Puffers beträgt nur 16 KB. Es wird mit kurzen Traffic-Bursts gezählt, wenn einige Pakete diesen Puffer füllen. Daher kann Rx-No-Pkt-Buff auf jedem Port gezählt werden, wenn die gesamte Traffic-Rate dieser ASIC-Portgruppe 1 Gbit/s überschreitet, da WS-X4548-GB-RJ45 ein Modul mit 8:1-Überbelegung ist.
Wenn Sie über Geräte verfügen, die eine große Menge an Traffic über diese Schnittstelle übertragen müssen, sollten Sie die Verwendung eines Ports jeder Gruppe in Betracht ziehen, damit die gemeinsamen Schaltkreise, die sich eine einzelne Gruppe teilen, von dieser Menge an Traffic nicht betroffen sind. Wenn das Gigabit-Ethernet-Switching-Modul nicht vollständig ausgelastet ist, können Sie Port-Verbindungen über Portgruppen hinweg ausgleichen, um die verfügbare Bandbreite zu maximieren. Mit dem 10/100/1000-Switch-Modul WS-X4448-GB-RJ45 können Sie beispielsweise Ports aus verschiedenen Gruppen verbinden, z. B. die Ports 4, 12, 20 oder 30 (in beliebiger Reihenfolge), bevor Sie Ports von derselben Gruppe verbinden, z. B. die Ports 1, 2, 3, 4, 5, 6, 7 und 8. Wenn das Problem dadurch nicht behoben wird, müssen Sie ein Modul ohne Überbelegung von Ports in Betracht ziehen.
Unknown protocol drops (unbekannte Protokollausfälle) ist ein Zähler an der Schnittstelle. Er wird durch Protokolle verursacht, die vom Router/Switch nicht verstanden werden. Dieses Beispiel des Befehls show run interface zeigt die unbekannten Protokoll-Drops auf der GigabitEthernet 0/1-Schnittstelle.
Switch#show run interface GigabitEthernet0/1 GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1125 Internal MAC, address is 0000.0000.0000 (via 0000.0000) MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:05, output 00:00:03, output hang never Last clearing of "show interface" counters 16:47:42 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 3031 packets input, 488320 bytes, 0 no buffer Received 3023 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 63107 multicast, 0 pause input 0 input packets with dribble condition detected 7062 packets output, 756368 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 2015 unknown protocol drops 4762 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out
Unbekannte Protokollausfälle werden normalerweise verworfen, da die Schnittstelle, an der diese Pakete empfangen werden, nicht für diese Art von Protokoll konfiguriert ist oder ein beliebiges Protokoll sein kann, das der Router nicht erkennt. Wenn Sie beispielsweise zwei Router angeschlossen haben und CDP auf einer Router-Schnittstelle deaktivieren, führt dies zu unbekannten Protokollausfällen an dieser Schnittstelle. Die CDP-Pakete werden nicht mehr erkannt und verworfen.
Trunk-Verbindungen zwischen einem Switch und einem Router können dazu führen, dass der Switchport ausfällt. Der Trunk kann wieder aktiviert werden, nachdem Sie den Switchport deaktiviert und aktiviert haben. Der Switchport kann allerdings wieder ausfallen.
Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:
Stellen Sie sicher, dass das Cisco Discovery Protocol (CDP) zwischen Switch und Router ausgeführt wird und beide sichtbar sind.
Deaktivieren Sie die Keepalives an der Schnittstelle des Routers.
Konfigurieren Sie die Trunk-Kapselung auf beiden Geräten neu.
Wenn die Keepalives deaktiviert sind, ermöglicht das CDP den normalen Betrieb der Verbindung.
Wenn Sie die Module WS-X6548-GE-TX oder WS-X6148-GE-TX verwenden, besteht die Möglichkeit, dass die Nutzung einzelner Ports zu Verbindungsproblemen oder Paketverlusten an den umliegenden Schnittstellen führt. Weitere Informationen zur Überbelegung finden Sie unter Probleme bei Schnittstellen-/Modulverbindungen.
In SPA-Modulen kann dasselbe VLAN auf dem Switch nicht verwendet werden, nachdem Sie eine Subschnittstelle mit 802.1Q erstellt haben. Sobald Sie dot1q auf einer Subschnittstelle gekapselt haben, können Sie dieses VLAN nicht mehr im System verwenden, da 6500 oder 7600 das VLAN intern zuweisen und diese Subschnittstelle zu ihrem einzigen Mitglied machen. Erstellen Sie Trunk-Ports anstelle von Subschnittstellen, um dieses Problem zu beheben. Auf diese Weise ist das VLAN in allen Schnittstellen sichtbar.
In der Regel treten die Ausgabeausfälle auf, wenn QoS konfiguriert ist und einer bestimmten Klasse von Paketen nicht genügend Bandbreite zur Verfügung stellt. Sie treten auch bei einer Überbelegung auf.
Hier sehen Sie z. B. eine hohe Menge an Ausgabeausfällen in der Schnittstelle GigabitEthernet 8/9 bei einem Catalyst Switch der 6500-Serie:
Switch#show interface GigabitEthernet8/9 GigabitEthernet8/9 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 0013.8051.5950 (bia 0013.8051.5950) Description: Connection To Bedok_Core_R1 Ge0/1 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 18/255, rxload 23/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:28, output 00:00:10, output hang never Last clearing of "show interface" counters never Input queue: 0/2000/3/0 (size/max/drops/flushes); Total output drops: 95523364 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94024000 bits/sec, 25386 packets/sec 5 minute output rate 71532000 bits/sec, 24672 packets/sec 781388046974 packets input, 406568909591669 bytes, 0 no buffer Received 274483017 broadcasts (257355557 multicasts) 0 runts, 0 giants, 0 throttles 3 input errors, 2 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 749074165531 packets output, 324748855514195 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out
Erfassen Sie zur Analyse des Problems die Ausgabe der folgenden Befehle:
show fabric utilization detail
show fabric errors
show platform hardware capacity
show catalyst6000 traffic-meter
show platform hardware capacity rewrite-engine drop
Dieses Beispiel für den Befehl show interface zeigt die letzte Eingabe niemals auf der TenGigabitEthernet1/15-Schnittstelle.
Switch#show interface TenGigabitEthernet1/15 TenGigabitEthernet1/15 is up, line protocol is up (connected) Hardware is C6k 10000Mb 802.3, address is 0025.84f0.ab16 (bia 0025.84f0.ab16) Description: lsnbuprod1 solaris MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 10Gb/s input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:17, output hang never Last clearing of "show interface" counters 2d22h Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 46000 bits/sec, 32 packets/sec 52499121 packets input, 3402971275 bytes, 0 no buffer Received 919 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 118762062 packets output, 172364893339 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out
Dieser Wert zeigt die Anzahl der Stunden, Minuten und Sekunden an, seit das letzte Paket erfolgreich von einer Schnittstelle empfangen und lokal auf dem Router verarbeitet wurde. Dies ist nützlich, um zu wissen, wann eine inaktive Schnittstelle ausgefallen ist. Dieser Zähler wird nur aktualisiert, wenn Pakete prozessgesteuert vertauscht werden, nicht wenn Pakete schnell gewechselt werden. Last input never (letzte Eingabe nie) bedeutet, dass keine erfolgreiche Übertragung des Schnittstellenpakets zu einem anderen Endpunkt oder Terminal durchgeführt wurde. Normalerweise bedeutet dies, dass im Verhältnis zu dieser Entität keine Paketübertragung erfolgt ist.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
03-Nov-2023 |
Rezertifizierung |
1.0 |
04-Dec-2001 |
Erstveröffentlichung |