Paketverlust gemeldet: Ursachen systematisch eingrenzen

Erst die Messung hinterfragen, dann das Netz

Bevor irgendeine Ursache untersucht wird, gehört die Zahl selbst auf den Prüfstand. 20 Prozent Verlust --> gemessen womit, von wo nach wo, über welchen Zeitraum, mit welcher Paketgröße? Ein Ping vom Notebook im WLAN zu einem Router-Interface misst etwas völlig anderes als ein TWAMP-Test (Netzwertestgerät) zwischen zwei kabelgebundenen Messpunkten. Viele Router und Firewalls priorisieren ICMP-Antworten auf die eigene Control Plane herab (Control-Plane-Policing); ein Ping auf ein Gerät kann deshalb Verluste zeigen, die im Datenpfad durch das Gerät gar nicht existieren. Ebenso wichtig: Ist der Verlust konstant, bursthaft oder lastabhängig? Konstante 20 Prozent riechen nach einem deterministischen Problem (Physik, Duplex, Policer), bursthafter Verlust nach Congestion, lastabhängiger Verlust nach Oversubscription oder Queue Drops.

Erst wenn Messmethode und Verlustmuster geklärt sind, lohnt sich die eigentliche Ursachenanalyse. Interessant ist auch noch die Uhrzeit. Wiederholend? Ist ein Backup der Verursacher?

Der Hypothesenraum: elf Kandidaten, geordnet nach Schichten

Ein einzelner Verdacht ist im Troubleshooting fast immer zu wenig. Tragfähig wird die Analyse, wenn man die plausiblen Ursachen nebeneinanderlegt und für jede weiß, welches Indiz sie bestätigt oder ausschließt.

Physical Layer

Defekte oder zu lange Kabel, verschmutzte LWL-Stecker, sterbende Optiken, Dämpfung außerhalb der Spezifikation. Das Erkennungsmerkmal sind CRC- und Input-Errors auf dem Interface sowie bei Glasfaser auffällige RX/TX-Pegel in der DDM/DOM-Diagnose der Transceiver. Physikprobleme sind lastunabhängig: Der Verlust bleibt auch nachts um drei bestehen.

Interface-Fehler und Duplex-Mismatch

Eng verwandt, aber eigenständig: ein Duplex-Mismatch, meist durch einseitig fest konfigurierte Ports. Das Muster ist charakteristisch: die Half-Duplex-Seite zählt Late Collisions, die Full-Duplex-Seite CRC-Fehler, und der Verlust steigt mit der Last. Bei kleinen Datenmengen fällt so ein Link jahrelang nicht auf.

Congestion und Queue Drops

Der Klassiker: Ein Interface ist zeitweise voll, der Puffer läuft über, der Switch verwirft. Sichtbar als Output Drops bzw. Tail Drops in der Interface- und QoS-Statistik – ohne begleitende CRC-Fehler. Wichtig ist der Blick in die einzelnen Queues: Wenn nur eine Klasse droppt, ist es kein Kapazitäts-, sondern ein QoS-Konfigurationsproblem, etwa ein zu knapp bemessener Policer oder Shaper. Microbursts sind hier die Falle schlechthin: Eine 5-Minuten-Auslastung von 30 Prozent schließt Drops im Millisekundenbereich nicht aus.

WLAN

Liegt ein Funkstreckenanteil im Pfad, ist er der Hauptverdächtige. Interferenzen, schlechter SNR, Sticky Clients, Co-Channel-Belegung . Auf Layer 2 werden viele Verluste zwar durch Retransmissions kaschiert, nach oben sichtbar bleiben Jitter und Restverlust. Die Abgrenzung ist trivial und wird trotzdem oft ausgelassen: dieselbe Messung einmal per Kabel wiederholen. Verschwindet der Verlust, ist der Fall auf die Funkzelle eingegrenzt.

WAN-Provider

Verlust auf der Providerstrecke zeigt sich, wenn die Messung segmentiert wird: sauber bis zum eigenen CE-Router, Verlust dahinter. Hilfreich sind Referenzmessungen von einem zweiten Standort und die Provider-eigenen SLA-Reports. Vorsicht bei MPLS- und SD-WAN-Strecken: Traceroute-Ergebnisse können durch verborgene Hops und ECMP-Lastverteilung täuschen; Paced-Probe-Verfahren wie mtr mit ausreichender Laufzeit sind aussagekräftiger als drei schnelle Pings.

Routing und Instabilität

Flappende Adjazenzen, Route-Churn oder ein Load-Balancing über einen gesunden und einen defekten Pfad erzeugen typisch periodischen oder anteiligen Verlust. Ein Blick in Routing-Logs (Neighbor-Resets, SPF-Läufe) und ein Vergleich mehrerer Flows mit unterschiedlichen Ports,die per ECMP-Hashing auf verschiedene Pfade fallen, trennen diese Hypothese von den anderen: Verliert nur jeder zweite Flow Pakete, ist einer von zwei Pfaden defekt.

Firewall und Session-Handling

Firewalls verwerfen gezielt volle Session-Tabellen, greifende DoS-Schwellwerte, asymmetrisch ankommende Pakete ohne passenden State, Fehlklassifizierung durch die Applikationserkennung. Das Indiz: Der Verlust betrifft bestimmte Protokolle, Ports oder Verbindungsphasen, nicht den Verkehr gleichmäßig. Die Drop-Counter und Session-Logs der Firewall geben hier schneller Auskunft als jede Messung von außen.

MTU und Fragmentierung

Streng genommen kein statistischer Verlust, aber er sieht so aus: Große Pakete kommen nicht an, kleine schon. Klassische Auslöser sind Pfade mit reduzierter MTU, bei denen ICMP „Fragmentation Needed" gefiltert wird – die Path MTU Discovery läuft ins Leere. Der Test ist eindeutig: Ping mit gesetztem DF-Bit und wachsender Paketgröße. Bricht die Erreichbarkeit an einer festen Größe ab, ist es kein Packet Loss, sondern ein MTU-Problem.

Tunnel und Overlays

IPsec, GRE, VXLAN und SD-WAN-Overlays kombinieren gleich mehrere Fehlerquellen: Der Header-Overhead verschärft MTU-Probleme, Rekeying-Ereignisse erzeugen kurze Ausfälle, und der Verlust der Underlay-Strecke schlägt vollständig auf den Tunnel durch. Entscheidend ist die getrennte Messung von Underlay und Overlay: Verliert das Underlay bereits, ist der Tunnel nur der Überbringer der Nachricht.

Asymmetrisches Routing

Hin- und Rückweg verlaufen über unterschiedliche Pfade: der Verlust kann auf jedem der beiden liegen, und zustandsbehaftete Geräte im Pfad verwerfen zusätzlich, was sie nur halb sehen. Einseitige Messungen (One-Way-Loss statt Round-Trip) oder zeitgleiche Captures an beiden Enden zeigen, welche Richtung tatsächlich verliert. Ein Round-Trip-Ping kann das prinzipiell nicht unterscheiden.

Oversubscription

Strukturelle Überbuchung: zu viele Access-Ports auf zu wenig Uplink, unterdimensionierte Firewall-Cluster, virtuelle Switches auf ausgelasteten Hosts. Anders als kurzfristige Congestion ist das ein Architekturthema: Der Verlust korreliert reproduzierbar mit Produktions- oder Backup-Zeitfenstern und verschwindet nicht durch Neustarts. Die Diagnose läuft über Auslastungshistorien mit hoher zeitlicher Auflösung, die Therapie über Kapazität oder Architektur, nicht über Konfiguration.

Die Messlogik: halbieren statt raten

Die Kunst liegt nicht im Aufzählen der Hypothesen, sondern im effizienten Ausschließen. Bewährt hat sich eine binäre Suche über den Pfad: Messpunkt in die Mitte der Strecke legen, feststellen, in welcher Hälfte der Verlust entsteht, dort erneut halbieren. Parallel dazu drei Fragen, die den Hypothesenraum jeweils grob halbieren:

• Lastabhängig oder konstant? Konstant deutet auf Physik, Duplex oder Policer. Lastabhängig auf Congestion, Oversubscription oder WLAN.
• Alle Pakete oder nur bestimmte? Größenabhängig heißt MTU; protokoll- oder portabhängig heißt Firewall oder Policy. Flowabhängig heißt ECMP mit defektem Teilpfad.
• Eine Richtung oder beide? Einseitiger Verlust deutet auf Asymmetrie oder eine gerichtete Störung. Das klärt nur eine richtungsgetrennte Messung.

Mit diesen drei Antworten bleiben von elf Kandidaten meist zwei oder drei übrig und für die gibt es dann jeweils einen gezielten Einzeltest.

Welche Messung kommt als Nächstes?

Die ehrliche Antwort lautet: die Interface-Counter entlang des Pfades bevor irgendein aktiver Test läuft. CRC-Errors, Input/Output Drops, Queue-Statistiken und Optik-Pegel auf jedem Hop kosten fünf Minuten und entscheiden bereits zwischen Physik, Congestion und „das Problem liegt woanders". Counter dabei einmal löschen oder Deltas notieren; absolute Zählerstände seit dem letzten Reboot sind wertlos.

Erst danach folgt die aktive Messung, und zwar segmentiert: kontinuierliche Probes (etwa mtr oder ein Ping-Dauerlauf mit Zeitstempeln) von beiden Enden auf Zwischenpunkte, ergänzt um einen DF-Bit-Sweep zur MTU-Kontrolle. Wenn das nicht reicht, kommen zeitsynchronisierte Captures an zwei Punkten. Der Vergleich der Sequenznummern zeigt exakt, zwischen welchen beiden Geräten die Pakete verschwinden. Das ist aufwendig, aber beweiskräftig, und beendet jede Diskussion mit Provider oder Herstellersupport.

Der OT-Blickwinkel

In Produktionsnetzen verschiebt sich die Gewichtung. Erstens sind aktive Messungen mit Vorsicht einzusetzen: Ein Ping-Sweep oder ein Lasttest im falschen Zellennetz kann ältere Steuerungen stören. Passive Verfahren wie Counter, SPAN-Ports und TAPs haben Vorrang. Zweitens sind die Symptome andere: 20 Prozent Verlust äußern sich hier nicht als „das Videomeeting ruckelt", sondern als sporadische SPS-Verbindungsabbrüche, Timeouts in der Prozessvisualisierung oder Störmeldungen ohne erkennbares Muster. Drittens sind physische Ursachen deutlich wahrscheinlicher als im Büro: Vibration an Steckverbindern, EMV-Einstreuung neben Frequenzumrichtern, Temperatur im Schaltschrank, unmanaged Switches ohne jede Diagnosemöglichkeit im Feld.

Gerade der letzte Punkt ist ein Argument für saubere Netzarchitektur: Wer seine Zellen sauber segmentiert und an den Übergängen Messpunkte vorsieht, kann im Störungsfall in Minuten eingrenzen, in welcher Zelle das Problem liegt statt in einer flachen Broadcast-Domäne mit hunderten Teilnehmern zu suchen.

Fazit

20 Prozent Paketverlust haben nicht eine Ursache, sondern einen Ursachenraum. Wer die Messung zuerst validiert, die Hypothesen nach Schichten ordnet und mit drei Unterscheidungsfragen halbiert, findet die Ursache in einem Bruchteil der Zeit und tauscht keine Hardware auf Verdacht. Die wertvollste „nächste Messung" ist dabei fast immer die unspektakulärste: die Interface-Counter entlang des Pfades, sauber als Delta gelesen. Alles Weitere ergibt sich aus dem, was sie zeigen.