Ein Duplex/Speed Mismatch finden gehört zu den wichtigsten Basisfähigkeiten im Cisco-Alltag, weil diese Fehlerklasse zwar alt ist, aber bis heute zuverlässig für schwer greifbare Symptome sorgt: schlechte Performance trotz „Link up“, hohe Paketverluste, einseitig langsame Übertragungen, instabile VoIP-Qualität, RDP-Sessions mit Hängern oder scheinbar „zufällige“ Timeouts bei Dateiübertragungen. Besonders tückisch ist, dass ein Mismatch oft nicht als kompletter Ausfall auffällt. Stattdessen funktionieren kleine Pings, DNS und manche Anwendungen, während größere Transfers einbrechen. In Cisco-Umgebungen ist die Cisco Diagnose und Lösung meist schnell möglich, wenn Sie wissen, welche Counters und Statusinformationen relevant sind und wie Autonegotiation wirklich arbeitet. Dieser Leitfaden zeigt Ihnen, wie Sie Duplex- und Speed-Probleme strukturiert erkennen, welche Show Commands die stärksten Hinweise liefern, welche Konfigurationsfehler am häufigsten vorkommen und wie Sie den Fix sauber umsetzen, ohne neue Probleme (z. B. EtherChannel-Mismatches oder Port-Flapping) zu verursachen. Das Ziel ist eine praxisnahe Routine: Verdacht bestätigen, Ursache isolieren, Konfiguration konsistent setzen, danach messen und verifizieren.
Duplex und Speed: Was bedeutet das konkret?
Bevor Sie suchen, sollten Sie die Begriffe sauber trennen:
- Speed: Die Link-Geschwindigkeit, z. B. 10/100/1000 Mbit/s oder 10 Gbit/s.
- Duplex: Ob gleichzeitig gesendet und empfangen werden kann. Full Duplex erlaubt Senden und Empfangen gleichzeitig; Half Duplex teilt sich das Medium, was Kollisionen und Wartezeiten verursacht.
- Autonegotiation: Mechanismus, mit dem beide Seiten Speed und Duplex automatisch aushandeln. In modernen Netzen ist Auto/Auto meist die stabilste Einstellung – sofern beide Seiten es korrekt unterstützen.
Ein Duplex/Speed Mismatch entsteht typischerweise, wenn eine Seite fest konfiguriert ist (z. B. 100/full), während die Gegenstelle auf Auto steht oder eine andere feste Einstellung nutzt. Besonders kritisch ist der Fall „eine Seite Full, andere Half“ – das führt zu massiven Performanceproblemen.
Warum Duplex/Speed-Mismatches so „leise“ sind
Viele Administratoren erwarten bei einem grundlegenden Linkproblem einen klaren Ausfall. Ein Duplex-Mismatch ist jedoch oft ein „Degradationsfehler“: Der Link steht, aber die Qualität ist schlecht. Das hat drei Gründe:
- Kleine Pakete wirken unauffällig: Pings oder kurze DNS-Anfragen funktionieren noch.
- TCP kaschiert Fehler: TCP retransmittiert; das wirkt wie „langsam“ statt „kaputt“.
- Symptome ähneln anderen Problemen: QoS, Overload, schlechte WLAN-Qualität oder Server-Performance können ähnlich aussehen.
Typische Symptome: Wann Sie sofort an Mismatch denken sollten
- Sehr niedriger Durchsatz trotz „Gigabit-Link“
- Viele Retransmits, langsame Dateiübertragungen, „stockende“ Sessions
- VoIP: Jitter/Packet Loss, knarzige Calls, einseitige Audioaussetzer
- Hohe Fehlerzähler auf einem Interface (CRC, input errors) ohne klare Kabelursache
- Viele collisions, late collisions oder deferred (besonders bei Half-Duplex)
- Unerwartetes Port-Flapping bei bestimmten Gegenstellen oder Switch-zu-Medienkonverter-Setups
Der wichtigste Start: Cisco Show Commands für die Diagnose
Mit wenigen Befehlen bekommen Sie ein belastbares Bild. Beginnen Sie am betroffenen Switchport und arbeiten Sie sich dann zur Gegenstelle vor.
show interfaces status(Speed/Duplex-Spalte, VLAN, Link-State)show interfaces GigabitEthernet1/0/10(Duplex/Speed, Errors, Collisions, Input/Output Drops)show interfaces GigabitEthernet1/0/10 switchport(Access/Trunk, Administrative/Operational Mode)show running-config interface GigabitEthernet1/0/10(fix gesetzte Speed/Duplex?)show logging | include Gi1/0/10(Link up/down Events, errdisable Hinweise)
Wenn Sie tiefer nachlesen möchten, bietet die Cisco IOS Command Reference die genaue Syntax und Ausgabedetails für Ihre IOS/IOS XE-Version.
Was Sie in der Ausgabe wirklich suchen müssen
Ein häufiger Fehler ist, nur auf „Duplex full“ zu schauen und damit zufrieden zu sein. Entscheidend sind die Counters und Hinweise auf Kollisionen/Fehler. In der Ausgabe von show interfaces sind insbesondere diese Felder relevant:
- Duplex / Speed: z. B. „Full-duplex, 1000Mb/s“
- input errors / CRC: viele CRCs deuten oft auf Layer-1/2-Probleme hin; in Kombination mit Mismatch sind sie häufig erhöht
- collisions / late collisions: klare Indikatoren für Half-Duplex oder Konflikte bei Aushandlung
- interface resets: kann bei Instabilität oder Flapping zunehmen
- output drops: eher Hinweis auf Queueing/Überlast, aber kann sekundär auftreten
Interpretation: Wenn Sie collisions sehen, ist das in modernen Switch-Netzen ein Warnsignal, weil Full Duplex bei Fast/Gigabit praktisch Standard ist. Late collisions sind besonders verdächtig und deuten oft auf Duplex-Probleme oder verkabelungsnahe Störungen hin.
Autonegotiation verstehen: Warum „Auto“ meist richtig ist
In aktuellen Ethernet-Standards ist Autonegotiation nicht nur Komfort, sondern oft Voraussetzung für stabile Links, insbesondere bei höheren Geschwindigkeiten. Der verbreitetste Mismatch entsteht durch „Auto auf der einen Seite, fix auf der anderen Seite“. Denn wenn eine Seite fix konfiguriert ist, kann die Auto-Seite die Duplex-Information manchmal nicht korrekt „lernen“ und fällt in ungünstige Defaults zurück (klassisch: Half Duplex bei 100 Mbit/s in bestimmten Legacy-Szenarien).
- Best Practice: Auto/Auto auf beiden Seiten, solange keine zwingenden Gründe dagegen sprechen.
- Ausnahme: Provider- oder Legacy-Equipment, das feste Werte verlangt (dann beidseitig identisch fix setzen).
- Wichtig: Einseitig fix und einseitig Auto ist fast immer eine Einladung zum Mismatch.
Die häufigsten Ursachen für Duplex/Speed Mismatch
- Einseitig fix konfiguriert: Switchport fix, Server/NIC auf Auto (oder umgekehrt).
- Medienkonverter oder ältere Geräte: Manche Konverter handeln schlecht aus oder „übersetzen“ Duplex nicht sauber.
- Fehlerhafte Patchkabel/Verkabelung: Kann Autonegotiation stören, sodass der Link auf eine niedrigere Geschwindigkeit zurückfällt.
- EEE/Energiesparfeatures (Gegenstelle): Bestimmte NIC-Treiber oder Switch-Features können Link-Verhalten beeinflussen.
- EtherChannel-Member inkonsistent: Unterschiedliche Speed/Duplex/MTU in einem Bundle können Instabilität oder Suspend verursachen.
Schritt-für-Schritt Diagnose: Von „Verdacht“ zu „Beweis“
Eine praxistaugliche Vorgehensweise ist, die Diagnose in vier Schritte zu teilen:
Schritt 1: Betroffenen Port eindeutig identifizieren
- Welcher Client/Server hängt am Port? (Portbeschreibung, MAC-Table)
- Prüfen:
show mac address-table interface Gi1/0/10 - Wenn nötig: Nachbarn via LLDP/CDP prüfen:
show lldp neighbors detailbzw.show cdp neighbors detail
Schritt 2: Status und Aushandlung prüfen
show interfaces status: Welche Speed/Duplex werden angezeigt?show interfaces Gi1/0/10: Gibt es collisions/late collisions/CRC?
Schritt 3: Gegenstelle einbeziehen
- Server/NIC: Welche Speed/Duplex/MTU sind dort gesetzt?
- Anderer Switch: Port-Status auf der Gegenstelle prüfen.
- Medienkonverter: Spezifikation prüfen, ggf. testweise tauschen.
Schritt 4: Fix setzen und messen
- Konfiguration anpassen (Auto/Auto oder fix/fix).
- Port resetten (shutdown/no shutdown) nur wenn nötig und im Wartungsfenster bei kritischen Links.
- Danach Counters beobachten und einen Throughput-Test durchführen.
Cisco Fixes: Konfigurationen, die typischerweise helfen
Es gibt zwei saubere Strategien: konsequent Auto/Auto oder konsequent fix/fix. Mischformen sind der häufigste Fehler.
Variante A: Auto/Auto (empfohlen für die meisten Access-Ports)
Auf vielen Cisco-Switches sind Speed und Duplex standardmäßig auf Auto. Falls an einem Port „alte“ fixe Einstellungen stehen, entfernen Sie diese:
configure terminal
interface GigabitEthernet1/0/10
no speed
no duplex
end
Wichtig: Das wirkt nur, wenn die Gegenstelle ebenfalls Autonegotiation verwendet oder korrekt damit kompatibel ist.
Variante B: Fix/Fix (nur wenn erforderlich, dann beidseitig identisch)
Wenn ein Provider, ein Legacy-Gerät oder ein spezieller Medienkonverter feste Werte verlangt, setzen Sie Speed und Duplex beidseitig identisch. Beispiel für 100 Mbit/s Full Duplex:
configure terminal
interface FastEthernet0/1
speed 100
duplex full
end
Achtung: Fix/Fix erfordert Disziplin. Sobald jemand auf einer Seite „zurück auf Auto“ stellt, ist der Mismatch wieder da.
Besonderheit: Gigabit und höher – warum Duplex-Mismatch dort seltener, aber nicht unmöglich ist
Bei 1G über Kupfer (1000BASE-T) ist Autonegotiation technisch stärker verankert. In der Praxis sind klassische Half/Full-Mismatches seltener als bei 100BASE-T. Trotzdem können Links auf 100M zurückfallen, wenn die Verkabelung schlecht ist oder Aushandlung scheitert. Dann tauchen die klassischen Mismatch-Symptome wieder auf.
- Wenn ein eigentliches Gigabit-Gerät plötzlich mit 100M läuft: Verkabelung, Patchfeld, Adernpaare prüfen.
- Wenn ein Link zwischen Switch und Gerät häufig die Speed wechselt: Kabel/Port/Transceiver tauschen und Logs auf Flaps prüfen.
Duplex/Speed Mismatch vs. Kabeldefekt: So unterscheiden Sie es
Beide Fehlerbilder können CRCs und Performanceprobleme erzeugen. Ein paar Indizien helfen bei der Abgrenzung:
- Collisions/Late Collisions: eher Duplex-Thema, besonders bei Half/Full-Mismatch.
- Viele CRCs ohne Collisions: häufig Kabel/SFP/EMV oder physische Probleme.
- Speed fällt auf 100M zurück: oft Verkabelung (bei 1G müssen alle Paare sauber sein).
- Flapping: eher physisch (wackliger Stecker, defekter Port, PoE-Probleme), kann aber sekundär bei Autonegotiation-Problemen auftreten.
EtherChannel und Uplinks: Warum Mismatch dort besonders gefährlich ist
Auf Uplinks oder Port-Channels hat ein Duplex/Speed-Problem oft größere Auswirkungen, weil es viele Clients oder VLANs betrifft. Zusätzlich sind EtherChannel-Bundles empfindlich auf Inkonistenzen: Wenn Member-Ports unterschiedliche Speed/Duplex/MTU haben, kann LACP Ports suspendieren oder das Bundle instabil werden.
- Prüfen:
show etherchannel summary,show lacp neighbor - Member-Ports identisch konfigurieren (Trunk, Allowed VLANs, Native VLAN, MTU, Speed/Duplex).
Für EtherChannel-Grundlagen ist der Anchor-Text Cisco EtherChannel Übersicht hilfreich.
Monitoring und Verifikation: Nach dem Fix ist vor dem Fix
Nach einer Änderung sollten Sie nicht nur „Link up“ sehen, sondern die Stabilität nachweisen. Ein verlässlicher Verifikationssatz:
show interfaces Gi1/0/10(keine neuen CRCs/collisions?)show interfaces status(korrekte Speed/Duplex, stabil)show logging | include Gi1/0/10(keine neuen Link-Flaps)- Praktischer Test: Dateiübertragung oder iperf im lokalen Netz (wenn verfügbar)
Wenn Sie Counters besser beobachten möchten, können Sie nach einem Wartungsfenster die Werte notieren und nach 15–30 Minuten erneut vergleichen. Der Trend ist wichtiger als ein einzelner Snapshot.
Prävention: Wie Sie Duplex/Speed-Probleme dauerhaft vermeiden
- Standardprofile: Nutzen Sie Templates für Access-Ports, Uplinks und Server-Ports, statt ad-hoc Änderungen.
- Auto/Auto als Default: Fix-Werte nur dort, wo es wirklich nötig ist, und dann dokumentiert.
- Saubere Verkabelung: Zertifizierte Links, korrekte Patchkabel, Zugentlastung, klare Beschriftung.
- Change-Disziplin: Jede Änderung an Speed/Duplex im Change-Protokoll festhalten.
- Monitoring: Alerts auf CRC/Errors und Link-Flaps, nicht erst auf „Interface down“.
Als betriebliches Rahmenwerk für Monitoring, Change-Management und Basissicherheit kann der Anchor-Text CIS Controls hilfreich sein.
Outbound-Links für vertiefende Informationen
Praxis-Checkliste: Duplex/Speed Mismatch finden und beheben
- Zeigt
show interfaces statusunerwartete Speed/Duplex-Werte (z. B. 100M statt 1G)? - Gibt es in
show interfacescollisions/late collisions oder auffällige CRC/input errors? - Ist auf dem Port eine fixe Konfiguration gesetzt (
show run interface) und passt sie zur Gegenstelle? - Ist die Gegenstelle wirklich auf Auto oder fix konfiguriert (Server/NIC/Provider)?
- Wurde eine saubere Strategie gewählt: Auto/Auto oder fix/fix – ohne Mischbetrieb?
- Wurde nach dem Fix verifiziert (Counters stabil, keine Flaps, Throughput plausibel)?
- Bei Uplinks/Port-Channels: Sind alle Member-Ports identisch und bleibt das Bundle stabil?
copy running-config startup-config
Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte
Cisco Networking • CCNA • Packet Tracer • Network Configuration
Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.
Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.
Leistungsumfang:
-
Netzwerkdesign & Topologie-Planung
-
Router- & Switch-Konfiguration (Cisco IOS)
-
VLAN, Inter-VLAN Routing
-
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
-
NAT, ACL, DHCP, DNS-Konfiguration
-
Troubleshooting & Netzwerkoptimierung
-
Packet Tracer Projektentwicklung & Dokumentation
-
CCNA Lern- & Praxisunterstützung
Lieferumfang:
-
Konfigurationsdateien
-
Packet-Tracer-Dateien (.pkt)
-
Netzwerkdokumentation
-
Schritt-für-Schritt-Erklärungen (auf Wunsch)
Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert
CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.












