Paketverlust im LAN: Cisco Switch Fehleranalyse Schritt-für-Schritt

Paketverlust im LAN wirkt auf den ersten Blick wie ein „diffuses“ Problem: Anwendungen reagieren träge, VoIP klingt abgehackt, Videokonferenzen ruckeln, Dateiübertragungen brechen ab – und trotzdem scheint „alles verbunden“ zu sein. In Cisco-Umgebungen ist Paketverlust im LAN jedoch fast immer erklärbar, wenn Sie strukturiert vorgehen und die richtigen Zähler, Logs und Interface-Statistiken auswerten. Gerade auf Switch-Ebene entsteht Paketverlust typischerweise durch wenige wiederkehrende Ursachen: physische Fehler (CRC, Kabel, SFP), Duplex/Speed-Mismatch, Überlast und Queue-Drops, Microbursts, Fehlkonfigurationen in EtherChannel, Layer-2-Loops oder Sicherheitsfeatures, die Traffic stillschweigend verwerfen. Eine zuverlässige Cisco Switch Fehleranalyse Schritt-für-Schritt beginnt deshalb nicht mit „irgendwo ist Loss“, sondern mit der Frage: Wo wird gedroppt (Ingress oder Egress), warum wird gedroppt (Errors vs. Queues vs. Policies) und wie lässt sich das reproduzierbar nachweisen. Dieser Leitfaden führt Sie durch ein praxiserprobtes Vorgehen – von schnellen Basischecks über Interface- und Switching-Analyse bis hin zu QoS- und Microburst-Themen. Ziel ist, dass Sie Paketverlust nicht nur „vermuteten“, sondern auf einem konkreten Port, VLAN oder Pfad belegen und anschließend mit passenden Cisco-Maßnahmen beheben können.

Schritt 1: Paketverlust sauber definieren und eingrenzen

Bevor Sie am Switch schrauben, definieren Sie, was genau unter „Paketverlust“ verstanden wird. In der Praxis werden mehrere Phänomene zusammengeworfen:

• Layer-1/2 Errors: Frames werden beschädigt übertragen (CRC) oder verworfen (Input Errors).
• Queue Drops: Frames werden verworfen, weil Ausgabeschlangen überlaufen (Congestion, Microbursts).
• Policy Drops: ACLs, Storm-Control, Port-Security, DAI oder QoS-Policer droppen Traffic.
• Application-Level Timeouts: Kein echter Paketverlust im LAN, sondern Server/WAN/Firewall-Probleme.

Praktisch hilfreich: Bestimmen Sie mindestens zwei Endpunkte im gleichen VLAN und zwei Endpunkte über VLAN-Grenzen hinweg. So erkennen Sie schnell, ob der Loss lokal (innerhalb eines Switch-Segments) oder eher auf dem Routing-/Upstream-Pfad entsteht.

Schritt 2: Quick Health Check auf dem betroffenen Switch

Starten Sie immer mit einem kurzen Überblick. Sie möchten wissen: Gibt es Link-Flapping, errdisable, CPU-Spikes oder klare Syslog-Hinweise?

• show version (Uptime, Neustarts, Plattform)
• show clock (Zeit plausibel; NTP wichtig für Log-Korrelation)
• show logging (Link up/down, STP, PoE, Security Drops)
• show interfaces status (Ports up/down, Speed/Duplex, VLAN)
• show ip interface brief (SVIs, falls L3-Switching)

Wenn in show logging wiederkehrende Link-Flaps zu sehen sind, ist Paketverlust oft nur ein Symptom. In diesem Fall hat die physische Stabilität Priorität.

Schritt 3: Betroffenen Pfad finden: Welcher Port ist „im Spiel“?

Der häufigste Fehler im Troubleshooting ist, auf dem falschen Port zu messen. Bevor Sie Counters interpretieren, identifizieren Sie den relevanten Access-Port und den Uplink-Pfad.

• Client-Port finden: show mac address-table interface Gi1/0/10
• MAC im VLAN verfolgen: show mac address-table vlan 10
• Nachbarn prüfen: show cdp neighbors oder show lldp neighbors

Praxis-Tipp: Wenn Sie wissen, welche MAC-Adresse zum betroffenen Client gehört, können Sie deren Lernort schnell verfolgen. Häufig liegt Paketverlust nicht am Access-Port, sondern am Uplink/Port-Channel.

Schritt 4: Interface-Statistiken auswerten – der wichtigste Block

Jetzt kommt der Kern: Auf dem Cisco Switch verraten Ihnen Interface-Counters, ob Drops durch physische Fehler oder durch Überlast entstehen. Der wichtigste Befehl ist nahezu immer:

show interfaces GigabitEthernet1/0/10

Achten Sie dabei auf diese Kategorien:

• Input Errors / CRC: deutet auf Kabel, SFP, Duplex/Speed oder EMV hin.
• Collisions / Late Collisions: starkes Indiz für Duplex-Mismatch (insbesondere bei 10/100).
• Output Drops: deutet auf Congestion/Queueing hin (Egress-Überlast, Microbursts).
• Interface Resets: kann auf Instabilität oder Flapping hindeuten.

Zusätzliche schnelle Übersicht (plattformabhängig):

• show interfaces counters errors
• show interfaces counters

Schritt 5: Physische Ursachen – Kabel, SFP, Duplex/Speed

Wenn CRCs und Input Errors steigen, ist die Wahrscheinlichkeit hoch, dass Sie ein Layer-1/2-Thema haben. Typische Ursachen:

• Defektes Patchkabel, wackeliger Stecker, schlechte Dose/Patchfeld
• Defekter oder inkompatibler SFP/Transceiver, verschmutzte LWL-Stecker
• Duplex/Speed Mismatch (eine Seite fix, andere Auto)
• Link fällt auf 100M zurück (bei 1G oft Verkabelung/Paare)

Diagnosebefehle:

• show interfaces status (Speed/Duplex auffällig?)
• show interfaces Gi1/0/10 (CRC, collisions, late collisions)
• show running-config interface Gi1/0/10 (speed/duplex fest gesetzt?)

Schnelle Fixes (geordnet nach Risiko):

• Patchkabel tauschen (beidseitig), Port testweise wechseln
• Bei LWL: SFP tauschen, Stecker reinigen, Rx/Tx prüfen
• Duplex/Speed konsistent setzen (meist Auto/Auto): no speed und no duplex am Interface

Für Cisco-spezifische Ethernet- und Counter-Interpretationen ist der Anchor-Text Cisco Ethernet Troubleshooting Hinweise hilfreich.

Schritt 6: Egress-Überlast und Microbursts – wenn Output Drops dominieren

Wenn Sie kaum CRCs sehen, aber Output Drops steigen, ist Paketverlust sehr häufig ein Congestion-Thema: Der Switch kann nicht schnell genug ausleiten, und die Queues laufen über. Das passiert besonders bei Microbursts: Viele Geräte senden kurzfristig gleichzeitig, was Switch-Queues trotz durchschnittlich moderater Auslastung überfordert.

Was prüfen?

• show interfaces Gi1/0/49 (Uplink: Output Drops?)
• show interfaces counters (Drop-Zähler im Zeitverlauf)
• show processes cpu sorted (CPU hoch? deutet eher auf Storm/Control-Plane)

Typische Ursachen:

• Oversubscription: viele Access-Ports bündeln auf einen kleineren Uplink
• Fehlende oder falsche QoS-Queueing-Policy
• Asymmetrische Links (z. B. 1G Access → 100M Uplink irgendwo im Pfad)
• Server/Storage senden bursts (Backup, vMotion, Replikation)

Typische Fix-Strategien:

• Uplink-Kapazität erhöhen (z. B. 1G → 10G) oder EtherChannel einsetzen
• Traffic-Engineering: Backup-Fenster, Rate-Limits, Shaping/Policing (bewusst)
• QoS korrekt einführen (Priorisierung von Voice/Control, Begrenzung von Bulk)

Schritt 7: QoS und Queueing prüfen – wenn Policies droppen

QoS kann Paketverlust verhindern (durch Priorisierung), aber auch verursachen (durch Policing oder falsche Klassifizierung). Wenn Sie QoS einsetzen, prüfen Sie explizit, ob Drops aus Policies kommen.

• show policy-map interface (Drops/Packets in Klassen, wenn MQC genutzt wird)
• show mls qos interface (plattformabhängig)
• show queueing interface (plattformabhängig)

Warnsignale:

• Hohe Drop-Zähler in einer Policy-Map-Klasse
• Policer zu aggressiv (z. B. Rate zu niedrig, Burst zu klein)
• Falsche DSCP/CoS-Markierung oder Trust falsch (Access vs. Uplink)

Praxis-Tipp: Wenn Sie QoS-Drops finden, entscheiden Sie zuerst, ob das „beabsichtigter“ Drop (Policing) ist oder ein unbeabsichtigter Drop. Beabsichtigt ist nicht automatisch sinnvoll – besonders bei TCP kann zu hartes Policing die Performance deutlich verschlechtern.

Schritt 8: VLAN/Trunk-Probleme erkennen – „Loss“ durch falschen Pfad

Manchmal ist Paketverlust in Wirklichkeit ein „Black Hole“ durch VLAN/Trunk-Misskonfiguration. Dann wirkt es wie Loss, weil Pakete verschwinden, aber nicht wegen Errors, sondern weil sie nie ihr Ziel erreichen.

• show vlan brief (VLAN existiert?)
• show interfaces trunk (VLAN erlaubt? Native VLAN passt?)
• show spanning-tree vlan 10 (Port blockt?)

Typische Fixes:

• Allowed VLANs auf Trunks korrigieren
• Native VLAN Mismatch beseitigen
• STP Root-Design stabilisieren, unerwartetes Blocking erklären

Für STP-Zusammenhänge ist der Anchor-Text Cisco STP Grundlagen hilfreich.

Schritt 9: Layer-2 Loops und Broadcast-Stürme – der „klassische“ LAN-Killer

Ein Loop im Layer 2 kann Paketverlust massiv verursachen, weil Broadcast/Unknown-Unicast die Switch-Fabric und CPU überlastet. Dann sehen Sie oft nicht nur Loss, sondern auch hohe Latenz, MAC-Flapping und STP-Topology-Changes.

Checks:

• show spanning-tree detail (Topology Change Count, Last Change)
• show mac address-table (MAC-Flapping, ungewöhnlich viele MACs auf einem Port)
• show processes cpu sorted (Control-Plane hoch?)
• show logging (STP/loop-related Messages)

Schnelle Stabilisierung (vorsichtig):

• Verdächtige Ports isolieren (shutdown) – kontrolliert und dokumentiert
• BPDU Guard auf Access-Ports, Root Guard wo sinnvoll
• Storm-Control einsetzen (mit Verständnis für Nebenwirkungen)

Schritt 10: EtherChannel/LACP – Paketverlust durch inkonsistente Bundles

Wenn Uplinks über Port-Channels laufen, kann Paketverlust durch Member-Instabilität oder Mismatch entstehen. Besonders tückisch: Ein Teil des Traffics hasht auf einen fehlerhaften Member-Link.

Checks:

• show etherchannel summary (Sind alle Member im Bundle?)
• show lacp neighbor (LACP-State stabil?)
• show interfaces port-channel 1 (Drops/Errors am logischen Interface?)

Typische Fixes:

• Member-Ports identisch konfigurieren (Trunk, Allowed VLANs, Native VLAN, Speed/Duplex, MTU)
• LACP konsistent (active/active oder active/passive)
• Bei wiederkehrender Instabilität: Member einzeln testen und fehlerhafte Links/SFPs austauschen

Vertiefung: Cisco EtherChannel Grundlagen.

Schritt 11: Security-Features als Drop-Ursache – wenn „alles korrekt“ wirkt

In vielen Netzen sind Sicherheitsfeatures aktiv, die Traffic gezielt verwerfen. Wenn Paketverlust nur bestimmte Clients oder bestimmte Traffic-Typen betrifft, prüfen Sie explizit diese Bereiche:

• Port-Security: show port-security interface Gi1/0/10
• DHCP Snooping: show ip dhcp snooping, show ip dhcp snooping binding
• DAI: show ip arp inspection, show ip arp inspection statistics
• ACLs: show ip access-lists (Trefferzähler!)

Wenn Drops an Policies hängen, ist die schnelle Lösung selten „Feature aus“. Besser: Trusted Ports korrekt setzen, Bindings prüfen, ACL-Reihenfolge korrigieren und notwendige Protokolle gezielt erlauben.

Schritt 12: Schrittweise Tests – Paketverlust reproduzierbar messen

Um Paketverlust sauber nachzuweisen, brauchen Sie reproduzierbare Tests, die Sie vor und nach Fixes wiederholen können:

• Ping mit Wiederholungen: Paketverlust in Prozent sichtbar (gleiches VLAN vs. über Gateway)
• Ping mit größerer Größe: Kann MTU-/Fragmentierungsprobleme sichtbar machen (IPv4 DF-Bit)
• Durchsatztest: Wenn möglich iperf oder kontrollierte Dateiübertragung im LAN

MTU/Blackhole-Tests: Hintergrund zu PMTUD über den Anchor-Text RFC 1191. In LANs ist PMTUD seltener das Primärproblem, aber bei Jumbo/Tunneln oder bestimmten Firewalls kann es relevant werden.

Schritt 13: Verifikation nach dem Fix – Counters, Logs und Stabilität

Ein Fix ist nur dann belastbar, wenn Sie zeigen können, dass die Drop-Zähler nicht weiter steigen und dass die Netzstabilität zurück ist. Verwenden Sie eine kurze Verifikationsroutine:

• show interfaces Gi… (Errors/Drops stabil?)
• show logging | include UPDOWN (kein Flapping?)
• show spanning-tree detail (Topology Changes reduzieren sich?)
• show etherchannel summary (Bundle stabil?)
• show ip access-lists (unerwartete deny-Hits?)

Praxis-Tipp: Dokumentieren Sie die wichtigsten Counter-Werte vor dem Fix und vergleichen Sie nach 15–30 Minuten erneut. Trends sind aussagekräftiger als Momentaufnahmen.

Best Practices: Paketverlust im LAN langfristig vermeiden

• Saubere Verkabelung und Standardisierung: geprüfte Patchkabel/SFPs, klare Beschriftung, Zugentlastung.
• Uplink-Design: ausreichend Kapazität, LACP/EtherChannel korrekt, Dual-Homing bewusst planen.
• STP-Disziplin: Root-Design festlegen, PortFast/BPDU Guard korrekt einsetzen, Loop-Schutz aktiv halten.
• QoS bewusst einsetzen: Priorisierung für Echtzeit, Bulk begrenzen, Policer nicht „blind“ konfigurieren.
• Monitoring: Alarme auf CRC, Drops, Flaps, STP-Changes, CPU-Spikes.
• Security-Features sauber betreiben: DHCP Snooping/DAI/Port-Security mit korrekten Trusted Ports und Dokumentation.

Outbound-Links zur Vertiefung

• Cisco EtherChannel Grundlagen
• Cisco Spanning Tree Protocol Grundlagen
• Cisco IOS Command Reference
• RFC 1191: Path MTU Discovery

Praxis-Checkliste: Cisco Switch Fehleranalyse bei Paketverlust

• Ist „Paketverlust“ wirklich Loss oder eher Policy/Blackhole/Timeout? (Tests im gleichen VLAN vs. über VLAN-Grenzen)
• Gibt es Link-Flapping oder Errdisable-Hinweise in show logging?
• Sehen Sie CRC/Input Errors (physisch) oder Output Drops (Congestion) in show interfaces?
• Ist Speed/Duplex plausibel und konsistent (kein unerwarteter Fallback auf 100M)?
• Ist der Uplink/Port-Channel stabil (show etherchannel summary) und sind Member-Ports identisch?
• Gibt es STP-Topology-Changes oder Hinweise auf Loops (show spanning-tree detail)?
• Droppen Security-Features oder ACLs Traffic (Trefferzähler, Snooping/DAI/Port-Security)?
• Wurde nach dem Fix verifiziert (Counters stabil, Logs ruhig, Anwendungen 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.