Site icon bintorosoft.com

Paketverlust im LAN: Wie du Switches als Ursache bestätigst

Red Snapper

Create a visual aid showing the process of data integration from multiple sources. Include steps like data extraction, transformation, and loading (ETL).

Paketverlust im LAN ist besonders tückisch: Anwendungen wirken „zäh“, VoIP knackt, RDP/SSH ruckelt, Dateiübertragungen brechen ein – aber der Link ist scheinbar „up“. In vielen Fällen liegt die Ursache nicht am Switch, sondern an Endgeräten, WLAN, Servern oder Routing. Genau deshalb ist ein methodischer Nachweis wichtig: Wie bestätigst du, dass Switches (oder eine bestimmte Switch-Strecke) tatsächlich die Loss-Quelle sind? Dieser Guide zeigt ein praxistaugliches Vorgehen, mit dem du Paketverlust im LAN eingrenzt und Switch-Indizien sauber belegst (Errors, Drops, Queues, Flaps, STP/EtherChannel).

Vorab: Was bedeutet „Paketverlust“ im Switch-Kontext?

Switches „verlieren“ Frames typischerweise aus drei Gründen: physische Fehler (CRC), Überlast/Queue-Overflow (Drops/Discards) oder instabile Layer-2-Topologie (Flaps, STP-Reconvergence, Loops). Ein „Router/Firewall-Loss“ sieht oft anders aus. Ziel ist, die Kategorie schnell zu bestimmen.

Schritt 1: Paketverlust messen – aber richtig (wo, wie, wie lange?)

Bevor du am Switch suchst, definiere ein reproduzierbares Messbild: Von welchem Client zu welchem Ziel? Innerhalb des gleichen VLANs oder über Routing? Konzentriere dich auf einen Pfad, den du vollständig kontrollieren kannst.

Switch-seitiger Ping als Referenz (aus Management-/SVI-Kontext)

ping 10.1.10.1
ping 10.1.10.50

Schritt 2: Pfad ermitteln – welcher Switchport ist betroffen?

Du musst wissen, wo der Client wirklich hängt. Nutze MAC Table und ggf. ARP, um den Access-Port zu identifizieren. Ohne diese Zuordnung ist jeder weitere Schritt geraten.

IP → MAC → Port (praxisnah)

show ip arp | include 10.1.10.55
show mac address-table | include aaaa.bbbb.cccc
show mac address-table interface gigabitEthernet 1/0/10

Schritt 3: Physische Fehler ausschließen – CRC/FCS sind harte Beweise

Wenn CRC/FCS Errors steigen, ist das ein sehr starkes Indiz für Switchport/Kabel/Transceiver-Probleme. Solche Errors korrelieren häufig direkt mit Paketverlust, weil Frames beschädigt ankommen und verworfen werden.

Errors am Client-Port prüfen

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

Beweisführung in der Praxis

Counters gezielt zurücksetzen (für Messfenster)

clear counters gigabitEthernet 1/0/10
show interfaces gigabitEthernet 1/0/10 | include CRC|error|rate|duplex|Mb

Schritt 4: Drops/Discards prüfen – Hinweis auf Überlast und Queue-Overflow

Wenn keine CRCs auftreten, aber Drops steigen, ist das oft Congestion: Microbursts, Oversubscription oder QoS/Queue-Probleme. Das ist ein typischer Switch-bezogener Loss, besonders auf Uplinks.

Drops im Interface-Output finden

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

Interpretation

Schritt 5: Link-Flapping und STP-Konvergenz als Loss-Ursache bestätigen

Kurze Unterbrechungen durch Link-Flaps oder STP-Topology-Changes wirken wie Paketverlust. Wenn Ports häufig down/up gehen oder STP TCNs hoch sind, ist Loss sehr plausibel.

Flaps und TCNs prüfen

show logging | include LINK|LINEPROTO|UPDOWN
show spanning-tree summary
show spanning-tree vlan 10 detail

Typische Indikatoren

Schritt 6: EtherChannel prüfen – instabile Member erzeugen „weichen“ Loss

Wenn der Pfad über einen Port-Channel läuft, kann ein einzelner fehlerhafter Member Paketverlust verursachen, obwohl der Port-Channel „up“ bleibt. Prüfe daher Bundle-Status und Errors pro Member.

EtherChannel Status und Member prüfen

show etherchannel summary
show lacp neighbor
show interfaces port-channel 1
show interfaces gigabitEthernet 1/0/47
show interfaces gigabitEthernet 1/0/48

Beweisindikator

Ein Member mit steigenden CRCs/Flaps bei gleichzeitigem Traffic erklärt Loss-Spitzen sehr gut, insbesondere bei asymmetrischer Lastverteilung (Hashing).

Schritt 7: Storms/Loops ausschließen – Flooding erzeugt Drops und CPU-Last

Broadcast/Multicast/Unknown-Unicast Stürme können Links fluten und Drops verursachen. Häufige Hinweise sind Storm-Control Events, hohe CPU und MAC-Flapping.

Storm-Indikatoren prüfen

show storm-control
show processes cpu sorted
show logging | include STORM|MACFLAP|TOPOLOGY|SPANNING

Schritt 8: Switch als Ursache „belegen“ – saubere Argumentationskette

Ein belastbarer Nachweis braucht mindestens eine der folgenden Ketten: Fehlerzähler korrelieren mit Loss, Drops korrelieren mit Last, oder Logs zeigen Flaps/Topology-Changes im Loss-Fenster. Dokumentiere immer Zeit und Counter-Stände.

Minimal-Dokumentation (Copy/Paste-ready)

show clock
show interfaces gigabitEthernet 1/0/10
show interfaces gigabitEthernet 1/0/48
show interfaces counters errors
show etherchannel summary
show spanning-tree vlan 10 detail
show logging | include LINK|LINEPROTO|UPDOWN|CRC|DROP|TOPOLOGY|MACFLAP

Typische Switch-nahe Root Causes und schnelle Fixes

Wenn du den Switch als Ursache bestätigt hast, ist der nächste Schritt die passende Maßnahme. Diese Fixes sind in der Praxis die häufigsten Erstmaßnahmen.

Uplink-Kapazität erhöhen (Beispiel LACP statt Einzeluplink)

configure terminal
interface range gigabitEthernet 1/0/47 - 48
 switchport mode trunk
 channel-group 1 mode active
exit
interface port-channel 1
 switchport mode trunk
end

Best Practices: Paketverlust proaktiv verhindern

Viele Loss-Situationen sind durch Standards vermeidbar: stabile Physik, redundante Uplinks als Port-Channel, Edge-Schutz gegen Storms/Loops und kontinuierliches Monitoring der Error-/Drop-Counter.

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

Sie erhalten

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.

Exit mobile version