Site icon bintorosoft.com

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

Red Snapper

View of modern internet switch with plugged ethernet cables and blinking lights on server representi

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:

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?

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.

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:

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

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:

Diagnosebefehle:

Schnelle Fixes (geordnet nach Risiko):

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?

Typische Ursachen:

Typische Fix-Strategien:

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.

Warnsignale:

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.

Typische Fixes:

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:

Schnelle Stabilisierung (vorsichtig):

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:

Typische Fixes:

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:

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:

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:

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

Outbound-Links zur Vertiefung

Praxis-Checkliste: Cisco Switch Fehleranalyse bei Paketverlust

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:

Lieferumfang:

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.

 

Exit mobile version