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.
- Physik: CRC/FCS/Input Errors → Frames kommen kaputt an
- Congestion: Output Drops/Queue Drops → Frames werden verworfen
- Topologie: Link-Flaps/TCNs/MAC-Flaps → kurzfristige Unterbrechungen/Flooding
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.
- Client → Default-Gateway (SVI): trennt LAN vs. WAN
- Client → Server im gleichen VLAN: prüft reine L2-Strecke
- Access-Switch → Distribution: prüft Uplink-Strecke
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
- Counter zurücksetzen, kurz messen, Counter erneut prüfen
- Wenn CRC in kurzer Zeit wieder steigt: Layer-1-Problem sehr wahrscheinlich
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
- Output Drops hoch auf Uplink: Uplink überlastet oder Microbursts
- Input Queue Drops: Switch kann Traffic nicht schnell genug annehmen
- CRC niedrig, Drops hoch: eher Kapazität/QoS als Kabel
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
- Viele Link up/down Meldungen am betroffenen Port/Uplink
- Hohe Anzahl TCNs, wechselnde Topologie
- MAC-Flapping Meldungen (Loop/Topologieproblem)
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.
- Beweis A (Physik): CRC/FCS steigen im Messfenster → Frame Corruption → Loss plausibel
- Beweis B (Congestion): Output Drops steigen im Messfenster → Queue Overflow → Loss plausibel
- Beweis C (Topologie): Link-Flaps/TCNs im Messfenster → Unterbrechungen → Loss plausibel
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.
- CRC: Patchkabel tauschen, Port wechseln, SFP tauschen, TDR/DOM prüfen
- Drops: Uplink-Kapazität erhöhen (LACP), QoS/Queues prüfen, Microbursts berücksichtigen
- Flaps: Kabel/SFP, PoE/Endgerät-Reboots, Gegenstelle prüfen
- STP/Loops: BPDU Guard/Root Guard/Loop Guard, fehlerhafte Verkabelung beheben
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.
- Monitoring auf CRC/Drops/Flaps (SNMPv3 + Syslog)
- Uplinks bündeln (LACP) und Trunks whitelisten
- PortFast/BPDU Guard, Storm Control am Access
- Regelmäßige Audit-Checks von Counters und Logs
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.
