Fehlerbehebung bei Switch-Port- und Schnittstellenproblemen

Einleitung

Dieses Dokument beschreibt, wie Sie herausfinden können, warum bei einem Port oder einer Schnittstelle Probleme auftreten.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

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.

Konventionen

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.

Fehlerbehebung auf der physischen Ebene 

Verwenden der LEDs zur Fehlerbehebung

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	LEDs am Ethernet-Modul
Catalyst Switches der Serie 4000	LEDs am Ethernet-Modul
Catalyst Switches der Serie 3750	LEDs an der Vorderseite
Catalyst Switches der Serie 3550	LEDs an der Vorderseite
Switches der Catalyst 2950/2955-Serie	LEDs an der Vorderseite
Switches der Catalyst 2900/3500XL-Serie	LEDs an der Vorderseite
Switches der Catalyst 1900- und 2820-Serie	LEDs an der Vorderseite

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).

Überprüfen des Kabels und beider Seiten der Verbindung

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.

Ethernet-Kupfer- und Glasfaserkabel

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.

Maximale Übertragungsdistanzen für Ethernet und Fast Ethernet

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.

Gigabit-Ethernet-Fehlerbehebung

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

1. 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.

2. Ü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

1. 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.

2. Entfernungen basieren auf Glasfaserverlusten. Die Kabellänge wird durch mehrere Spleiße und minderwertige Glasfaserkabel reduziert.

3. Nur mit MMF verwenden.

4. 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.

5. Nur mit SMF verwenden.

6. Dispersionsverschobenes Singlemode-Glasfaserkabel.

7. 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.

Verbunden vs. nicht verbunden

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.

Fehlerbehebung bei den gängigsten Port- und Schnittstellenbefehlen für Cisco IOS

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 saved  mithilfe des Befehls write memory auf die Konfiguration in Cisco IOS. Dies ist hilfreich bei der Feststellung, ob eine falsche Konfiguration des Moduls/Ports oder der Schnittstelle ein Problem verursachen kann.
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.

Grundlegendes zur Ausgabe bestimmter Port- und Schnittstellenzähler für CatOS und Cisco IOS

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.

Cisco IOS – show interfaces

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.

Cisco IOS – show interfaces counters

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.

Cisco IOS – show counters 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.

„show controller ethernet-controllers“ für Cisco IOS

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: Wenn ein Port ein Zugangsport ist und der Port mit einem ISL-Trunk-Port (Inter-Switch Link Protocol) verbunden ist, ist der Zähler für No dest sehr groß, da nicht alle eingehenden ISL-Pakete weitergeleitet werden. Diese Konfiguration ist ungültig. Wenn ein Port durch das Spanning Tree Protocol (STP) blockiert wird, werden die meisten Pakete nicht weitergeleitet, sodass keine Zielpakete entstehen. Wenn ein Port gerade eine Verbindung erworben hat, gibt es einen sehr kurzen Zeitraum (weniger als eine Sekunde), in dem eingehende Pakete nicht weitergeleitet werden. Wenn sich der Port selbst in einem VLAN befindet und keine anderen Ports auf dem Switch zu diesem VLAN gehören, werden alle eingehenden Pakete verworfen und der Zähler erhöht. Der Zähler wird auch erhöht, wenn die Zieladresse des Pakets an dem Port erfasst wird, an dem das Paket empfangen wurde. Wenn ein Paket an Port 0/1 mit der MAC-Zieladresse X empfangen wurde und der Switch bereits erfahren hat, dass sich die MAC-Adresse X an Port 0/1 befindet, wird der Zähler erhöht und das Paket verworfen. Dies kann in folgenden Situationen passieren: Wenn ein Hub mit Port 0/1 verbunden ist und eine Workstation, die mit dem Hub verbunden ist, Pakete an eine andere Workstation überträgt, die mit dem Hub verbunden ist, leitet Port 0/1 dieses Paket nicht weiter, da sich die MAC-Zieladresse auf demselben Port befindet. Dies kann auch auftreten, wenn ein Switch mit Port 0/1 verbunden ist und Pakete an alle seine Ports flutet, um Informationen zu MAC-Adressen zu erhalten. Wenn eine statische Adresse an einem anderen Port in demselben VLAN eingerichtet wurde und keine statische Adresse für den empfangenden Port eingerichtet wurde, wird das Paket verworfen. Wenn beispielsweise eine statische Zuordnung für MAC-Adresse X an Port 0/2 konfiguriert wurde, um Traffic an Port 0/3 weiterzuleiten, muss das Paket an Port 0/2 empfangen werden. Andernfalls wird das Paket verworfen. Wenn ein Paket von einem anderen Port in demselben VLAN wie Port 0/2 gesendet wird, wird das Paket verworfen. Handelt es sich bei dem Port um einen sicheren Port, werden Pakete mit unzulässigen MAC-Quelladressen nicht weitergeleitet und der Zähler wird erhöht.
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.

Gängige Meldungen zu Systemfehlern

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.

%AMDP2_FE-3-UNDERFLO

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.

%INTR_MGR-DFC1-3-INTR: Warteschlangen-Engine (Blackwater) [1]: Unerwarteter FIC Fabric-A-Steuercode

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.

Befehl abgelehnt: [Schnittstelle] ist kein Switching-Port

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.

Häufige Port- und Schnittstellenprobleme

Port- oder Schnittstellenstatus ist „disable“ oder „shutdown“

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.

Port- oder Schnittstellenstatus ist „errDisable“

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

Port- oder Schnittstellenstatus ist „Inactive“

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.

Uplink-Port- oder Schnittstellenstatus ist „Inactive“

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.

Verzögerter Zähler auf der Catalyst Switch-Schnittstelle beginnt zu steigen

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.

Kurzzeitiger Fehler beim Festlegen des Timers [Wert] über VLAN [VLAN-Nr.]

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.

Nicht übereinstimmender Trunk-Modus

Ü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:

• Systemanforderungen für die Implementierung von Trunking

• Support-Seite für Trunking-Technologie

Jumbos, Giants und Baby Giants

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.

Endgerät kann nicht angepingt werden

Ü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.

Verwenden des Befehls „set port host“ oder „switchport host“ zum Beheben von Startverzögerungen

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.

Probleme mit Geschwindigkeit/Duplex, Autonegotiation oder NIC

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

• Probleme mit der NIC-Karte

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-Schleifen

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.

UDLD: Unidirektionaler Link

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.

Verzögerte Frames (Out-Lost oder Out-Discard)

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.

Softwareprobleme

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“.

Hardwareprobleme

Ü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.

Eingabefehler bei einer mit einem Layer-2-Switchport verbundenen Layer-3-Schnittstelle

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

Schnell zunehmender Zähler für Rx-No-Pkt-Buff und Eingabefehler

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.

Grundlegendes zu unbekannten Protokollausfällen

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.

Trunking zwischen einem Switch und einem Router

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:

1. Stellen Sie sicher, dass das Cisco Discovery Protocol (CDP) zwischen Switch und Router ausgeführt wird und beide sichtbar sind.

2. Deaktivieren Sie die Keepalives an der Schnittstelle des Routers.

3. Konfigurieren Sie die Trunk-Kapselung auf beiden Geräten neu.

Wenn die Keepalives deaktiviert sind, ermöglicht das CDP den normalen Betrieb der Verbindung.

Verbindungsprobleme durch Überbelegung

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.

Subschnittstellen in SPA-Modulen

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.

Fehlerbehebung bei Ausgabeausfällen

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

Letzte Eingabe nie aus der Ausgabe des Befehls „show interface“

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.

Zugehörige Informationen

• Behebung von Kompatibilitätsproblemen zwischen Cisco Catalyst Switches und NICs
• Verwenden von PortFast und anderen Befehlen zum Beheben von Verzögerungen bei der Workstation-Startverbindung
• Konfiguration und Fehlerbehebung für die automatische Ethernet-10/100/1000-Mb-Halb-/Vollduplex-Aushandlung
• Aktualisieren von Software-Images und Arbeiten mit Konfigurationsdateien auf Catalyst Switches
• Technischer Support und Dokumentation für Cisco Systeme