show interface richtig lesen: Errors, CRC, Drops und Speed/Duplex

show interfaces ist eines der wichtigsten Troubleshooting-Tools auf Cisco Switches. Der Output wirkt auf den ersten Blick lang, liefert aber sehr konkrete Hinweise: Ist der Link wirklich stabil? Gibt es physische Fehler (CRC/FCS), Duplex-/Speed-Probleme, Drops durch Überlast, Queue-Engpässe oder Anzeichen für Loops und Storms? Wer die wichtigsten Felder richtig interpretiert, kann in wenigen Minuten zwischen Layer-1-, Layer-2- und Kapazitätsproblemen unterscheiden. Dieser Leitfaden erklärt die typischen Zeilen und Counters praxisnah – mit Fokus auf Errors, CRC, Drops und Speed/Duplex.

Welche show-Commands du wirklich brauchst

Je nach IOS/IOS XE und Plattform gibt es mehrere Varianten. Für den Alltag reichen wenige Befehle: Interface-Detail, Fehlerzähler und Status/Speed-Duplex.

show interfaces gigabitEthernet 1/0/10
show interfaces counters errors
show interfaces status
show interfaces gigabitEthernet 1/0/10 switchport

Erster Block: Line Protocol und Link-Status richtig interpretieren

Die ersten Zeilen sagen dir, ob der Port physisch „up“ ist und ob das Line Protocol aktiv ist. Ein „up/down“ deutet oft auf L1/L2-Handshake-Probleme hin, ein „down/down“ eher auf Kabel/Transceiver oder administratives Shutdown.

Worauf du achtest

• up/up: Link und Protokoll aktiv, Basis okay
• up/down: Link da, aber Protokoll nicht (z. B. Duplex, EtherChannel, VLAN/Trunk, Remote-Seite)
• down/down: kein physischer Link (Kabel, SFP, Gegenstelle)
• administratively down: Port ist shutdown

Port schnell prüfen

show interfaces status
show logging | include LINK|LINEPROTO|UPDOWN

Speed und Duplex: Häufigste Ursache für „komische“ Errors

Speed/Duplex müssen zur Gegenstelle passen. Moderne Ports autonegotiaten meist zuverlässig, aber Mischumgebungen, Medienkonverter oder falsch gesetzte Fixwerte können zu Duplex-Mismatch führen. Das zeigt sich oft in Late Collisions, Input Errors und schlechten Throughput-Werten.

Speed/Duplex im Output finden

Im show interfaces Output siehst du Zeilen wie „Full-duplex, 1000Mb/s“ oder ähnliche Angaben. Zusätzlich hilft show interfaces status für eine schnelle Übersicht.

show interfaces gigabitEthernet 1/0/10 | include duplex|Duplex|Mb
show interfaces status

Wann du Speed/Duplex fixen solltest (und wann nicht)

• Meist: Autonegotiation beidseitig lassen
• Fixen: nur wenn Gegenstelle nicht sauber autonegotiatet (Legacy/Converter)
• Regel: Wenn du fixst, fixst du beidseitig identisch

CRC/FCS Errors: Starkes Signal für physische Probleme

CRC (Cyclic Redundancy Check) bzw. FCS Errors entstehen, wenn Frames beschädigt ankommen. Das ist in der Praxis fast immer Layer-1: Kabel, Stecker, Patchfeld, SFP/Transceiver oder elektromagnetische Störungen. Einzelne CRCs können passieren, aber ein stetiger Anstieg ist ein Alarm.

CRC/Frame-Fehler prüfen

show interfaces gigabitEthernet 1/0/10 | include CRC|FCS|frame|error
show interfaces counters errors

Typische Ursachen für CRC

• Defektes/zu langes Kupferkabel, schlechter Stecker
• Patchfeld-/Dose-Probleme, Wackelkontakt
• SFP/Transceiver defekt oder inkompatibel
• Bei Fiber: verschmutzte Endflächen oder schlechte Spleiße

Input Errors, Frame, Runts, Giants: Was sie bedeuten

Diese Zähler gruppieren verschiedene Fehlerarten. Sie helfen, das Fehlerbild zu präzisieren: zu kleine Frames (Runts), zu große Frames (Giants), Alignment/Frame Errors oder generische Input Errors.

• input errors: Sammelzähler (CRC, frame, overruns, ignored)
• frame: Framing/Alignment-Probleme, oft physisch oder Duplex
• runts: zu kleine Frames, oft Kollisionen/Fehler am Medium
• giants: zu große Frames, MTU/Jumbo/Fehlgeräte

Fehlerblock im Interface-Output isolieren

show interfaces gigabitEthernet 1/0/10 | include input errors|CRC|frame|runts|giants

Drops und Discards: Nicht immer physisch, oft Kapazität oder Queues

Drops/Discards entstehen häufig nicht durch kaputte Kabel, sondern weil die Port-Queues oder Puffer überlaufen. Das passiert bei Überlast (Microbursts), QoS-Fehlkonfiguration oder wenn ein Port dauerhaft am Limit läuft.

Wichtige Drop-Indikatoren

• output drops: Paket konnte nicht gesendet werden (Queue voll)
• input queue drops: Paket konnte nicht angenommen werden (Input Queue voll)
• ignored: oft Ressourcen-/Buffer-Thema

Rates und Drops prüfen

show interfaces gigabitEthernet 1/0/10 | include rate|drops|discard|ignored|queue
show interfaces counters errors

Praxisinterpretation

• CRC hoch + Drops: erst Physik lösen, dann Kapazität prüfen
• CRC niedrig, aber Drops hoch: eher Congestion/QoS/Microbursts
• Drops nur in eine Richtung: Asymmetrie, Speed-Mismatch oder Traffic-Pattern

Collisions, Late Collisions: Klassiker bei Duplex-Mismatch

In modernen Full-Duplex-Switched-Netzen sollten Kollisionen praktisch nicht auftreten. Late Collisions sind besonders verdächtig und weisen häufig auf Duplex-Mismatch oder Layer-1-Probleme hin.

Kollisionszähler prüfen

show interfaces gigabitEthernet 1/0/10 | include collision|late

Uplink vs. Access-Port: Unterschiedliche Erwartungswerte

Ein Access-Port zu einem PC sollte fast keine Errors haben und moderate Raten. Ein Uplink/Trunk trägt aggregierten Traffic und kann höhere Peaks haben. Beurteile Counters immer im Kontext der Portrolle.

• Access-Port: CRC/Drops nahe 0, stabile Speed/Duplex
• Uplink/Trunk: höhere Raten normal, Drops müssen beobachtet werden
• Port-Channel Member: Errors auf einem Member können Gesamtperformance drücken

Portrolle prüfen

show interfaces gigabitEthernet 1/0/10 switchport
show interfaces trunk
show etherchannel summary

Schritt-für-Schritt Vorgehen: Output in 5 Minuten bewerten

Mit diesem Ablauf kommst du schnell zur wahrscheinlichsten Ursache, ohne dich im Output zu verlieren.

• 1) Status: up/up? Logs auf Link-Flaps?
• 2) Speed/Duplex: passt es zur Gegenstelle?
• 3) CRC/Frame/Runts: physische Fehler ja/nein?
• 4) Drops/Queues: Congestion/QoS/Microbursts?
• 5) Kontext: Access vs. Uplink vs. Port-Channel Member

show interfaces status
show interfaces gigabitEthernet 1/0/10
show interfaces counters errors
show logging | include LINK|LINEPROTO|UPDOWN

Best Practices: Fehler schnell reduzieren und dauerhaft vermeiden

Viele Error-Klassen lassen sich durch Standards stark reduzieren: saubere Verkabelung, konsistente Autonegotiation, LACP-Port-Channels für Uplinks und proaktives Monitoring der Counters.

• Autonegotiation beidseitig nutzen (außer Legacy-Ausnahmen)
• Patchkabel/SFPs bei CRC-Anstieg konsequent tauschen
• Uplinks bündeln (LACP) statt einzelne Links am Limit
• Storms/Loops am Access verhindern (STP Guards, Storm Control)
• Monitoring: CRC/Drops/Flaps per SNMPv3 und Syslog auswerten

copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.