Paketverlust lokalisieren ist im Provider- und Enterprise-Betrieb eine der wichtigsten Fähigkeiten, weil „irgendwo gehen Pakete verloren“ als Symptom alles sein kann: von einer überlasteten Queue über einen falsch eingestellten Policer bis hin zu einem fehlerhaften Optikmodul oder einem MTU-Blackhole in einem Tunnel. Für Voice und interaktives Video ist Paketverlust besonders kritisch, weil UDP-Echtzeit keine Retransmits hat und schon kurze Drop-Cluster sofort hör- oder sichtbar werden. Gleichzeitig ist Paketverlust in modernen Netzen selten „gleichmäßig verteilt“. Häufig tritt er in kurzen Bursts auf (Microbursts), nur in eine Richtung (Upstream vs. Downstream) oder nur in bestimmten Klassen (z. B. Best Effort dropt, Premium bleibt sauber – oder umgekehrt bei Premium-Inflation). Wer Paketverlust sauber lokalisieren will, braucht deshalb eine strukturierte Methode: erstens den Verlust aus Dienstsicht bestätigen (RTP/RTCP, MOS, Video-Freezes), zweitens die Richtung und Klasse bestimmen (DSCP/CoS/TC), drittens den Pfad segmentieren (Access, Metro, Core, NNI/Interconnect) und viertens die Verlustursache je Segment prüfen (Queue Drops, Policer Drops, PHY Errors, MTU/Fragmentierung, Security-Hops). Dieser Artikel zeigt praxisnah, wie Sie Paketverlust nicht nur „messen“, sondern wirklich bis zur Ursache lokalisieren – schnell, reproduzierbar und SLA-tauglich.
Was genau ist Paketverlust – und warum „Loss“ nicht immer gleich Loss ist
Im Betrieb wird Paketverlust oft als Prozentwert genannt. Für die Ursachenanalyse ist jedoch entscheidend, welcher Verlust gemeint ist:
- Echte Drops im Netz: Pakete werden verworfen, weil Puffer voll sind, Policers greifen oder Hardware überläuft.
- Late Loss: Pakete kommen zu spät an und werden von Echtzeitempfängern verworfen (Jitter-Buffer leer) – das fühlt sich wie Loss an, obwohl es „Delay“ ist.
- Fragmentverlust: ein Fragment fehlt, das gesamte Originalpaket ist verloren (besonders tückisch bei VPN/Overlays).
- Messartefakte: Drops in ICMP/Ping oder Sampling-Effekte werden fälschlich als Service-Loss interpretiert.
Bevor Sie lokalisieren, müssen Sie klarstellen, ob es um Netz-Drops, Service-Loss (RTP/RTCP) oder Late Loss geht. Diese Unterscheidung entscheidet, ob Sie zuerst in Queues oder in Time/Bufferbloat suchen.
Schritt 1: Paketverlust aus Dienstsicht bestätigen
Die erste Pflichtaufgabe ist, den Verlust dort zu validieren, wo er die Qualität beeinflusst. Je nach Dienst sind das unterschiedliche Datenquellen:
- Voice (RTP/SRTP): RTP Loss und Jitter aus RTCP-Reports, MOS/R-Faktor, One-Way Audio Events.
- Interaktives Video (WebRTC/UC): Packet Loss, Freeze Events, Bitrate-Switching, Frame Drops.
- TCP/QUIC-Video (Streaming): Retransmits, Throughput-Einbrüche, Rebuffer-Events (hier ist „Loss“ oft indirekt sichtbar).
Wenn Sie keine Diensttelemetrie haben, nutzen Sie aktive UDP-Probes (voice-ähnlich, z. B. 50 pps) als Ersatz – aber interpretieren Sie sie als Netzindikator, nicht als vollständige QoE-Wahrheit.
Schritt 2: Richtung und Klasse bestimmen – Loss ist oft asymmetrisch
Die Lokalisierung wird deutlich schneller, wenn Sie früh klären, ob der Verlust in einer Richtung dominiert und welche QoS-Klasse betroffen ist.
- Uplink vs. Downlink: Access-Upstreams sind häufiger Engpässe als Downstreams; Bufferbloat und Policer-Drops sind dort typisch.
- Klassenverlust: Dropt Best Effort, während Voice sauber ist? Oder dropt Voice wegen Premium-Inflation oder zu engem LLQ-Limit?
- DSCP/CoS/TC-Kohärenz: Ist der Traffic wirklich als EF/AF/Control gekennzeichnet, oder geht die Markierung unterwegs verloren?
Ein einfacher, aber extrem wirksamer Blick ist die Klassen-Statistik am Engpassinterface: Drops pro Klasse plus Queueing Delay pro Klasse. Damit sehen Sie in Minuten, ob es ein QoS-/Congestion-Thema ist oder eher PHY/MTU.
Schritt 3: Pfad segmentieren – wo genau beginnt der Verlust?
„Ende-zu-Ende“ ist für Troubleshooting zu grob. Sie brauchen Segmentierung. Im Provider-Netz sind typische Segmente:
- Customer Edge / Access: CPE, ONT, DSLAM/OLT, DOCSIS CMTS, WLAN/Last-Mile.
- Aggregation / Metro: Access-Aggregation, Metro-Ringe, Carrier Ethernet.
- Core: IP/MPLS/SR-Core, Backbone-PoPs, Transit-Router.
- NNI/Interconnect: Übergang zu Partnern, Wholesale, Peering/Transit, Cloud-Edges.
Praktisches Vorgehen: Messen Sie Loss pro Segment mit aktiven Probes zwischen Messpunkten oder über OAM (z. B. zwischen Access-Aggregation und Metro-Knoten, Metro zu Core, Core zu NNI). Parallel korrelieren Sie mit Geräte-Queue-Drops an den jeweiligen Übergängen.
Schritt 4: Verlustursache klassifizieren – Congestion, Policer, PHY oder MTU?
Sobald Sie das Segment eingegrenzt haben, kommt die wichtigste Frage: Warum werden Pakete verworfen? Es gibt vier Hauptklassen von Ursachen, die sich in Metriken sehr unterschiedlich zeigen.
Congestion und Queue Drops
- Symptom: Queue Depth steigt, Queueing Delay steigt, dann Drops (Tail Drop oder Early Drop).
- Erkennbar an: Drops pro Klasse, Queueing Delay-Perzentile, „sägezahnartige“ Muster.
- Typisch: Busy Hour, Microbursts, falsche Queue-Limits, fehlendes Shaping am Upstream.
Wenn Loss mit Queueing Delay-Spitzen korreliert, ist Congestion die wahrscheinlichste Ursache.
Policer Drops und Profilverletzungen
- Symptom: Drops ohne große Queueing Delay-Anstiege (weil Policer am Ingress hart verwirft).
- Erkennbar an: Policer Conform/Exceed/Violate, Policer Drop Counter, Remarking-Stats.
- Typisch: zu enge CIR/Burst-Werte, falsche Klassenzuordnung, Burst-Spitzen (Keyframes, VAD-Transitions).
Policer-Loss ist häufig „spiky“ und tritt genau bei Bursts auf – besonders schädlich für Voice und interaktives Video.
Physische Fehler und Layer-1/2-Probleme
- Symptom: CRC-Errors, FEC-Anstiege, Input/Output Errors, Drops außerhalb von QoS-Queues.
- Erkennbar an: Interface Error Counter, Optics Telemetry, Link Flaps, Microwave Retransmissions.
- Typisch: schlechte Optik, verschmutzte Steckverbindungen, schwache Funkstrecken, Duplex-/Speed-Mismatches.
Wenn Loss auch bei niedriger Auslastung auftritt und Error Counter steigen, ist PHY zuerst zu prüfen – QoS ist dann nicht der Hebel.
MTU, Fragmentierung und PMTUD-Blackholes
- Symptom: sporadische Ausfälle bei bestimmten Flows, Einweg-Audio, Setup-Probleme, Fragment- oder „Packet too big“-Drops.
- Erkennbar an: Fragment Counters, ICMP „Packet too big“/„Fragmentation needed“, Drops auf Tunnel-Interfaces.
- Typisch: VPN/Overlays, PPPoE, VXLAN ohne Headroom, blockiertes ICMP.
MTU-Probleme erzeugen oft „mystische“ Loss-Symptome, weil nicht jeder Flow große Pakete sendet – der Fehler ist pfad- und paketgrößenabhängig.
Die wichtigste Praxisfrage: Ist der Verlust klassenabhängig?
Für QoS-Design und SLA ist entscheidend, ob Premiumklassen betroffen sind. Zwei typische Muster:
- Best Effort dropt, Voice sauber: QoS schützt Echtzeit, aber Kapazität oder BE-Queue-Design ist zu knapp; Kunden sehen langsame Daten, Voice bleibt gut.
- Voice dropt: kritisch. Meist Premium-Inflation, zu enges LLQ-Limit, fehlende Trust Boundary, oder ein Engpass, der Voice nicht korrekt priorisiert (Mapping-Loch).
Operative Regel: Drops in der Voice-Klasse sind immer incident-würdig. Drops in Video/AF sind ebenfalls kritisch, aber in manchen Profilen tolerierbar, wenn sie nicht clusterig sind.
Microbursts: Warum Loss oft in Sekunden passiert und dann „verschwindet“
Microbursts sind kurze, hohe Trafficspitzen, die Puffer überlaufen lassen, obwohl der Durchschnitt nicht hoch ist. Sie sind die häufigste Ursache für schwer reproduzierbaren Paketverlust in modernen Netzen (10G/100G Core, Aggregation, EVPN/VXLAN, Traffic-Spikes durch Applikationen).
- Erkennbar an: kurzzeitigen Queue-Drops, Peak-Queueing Delay, Drops in 1s/10s Fenstern.
- Verstärkt durch: fehlendes Shaping, zu kleine Buffers, ungünstige Burst-Parameter in Policers.
Wenn Loss nur in Peaks sichtbar ist, benötigen Sie Telemetrie mit hoher Auflösung (Sekunden statt Minuten) oder gezielte Burst-Tests mit UDP-Probes.
Aktive Lokalisierung: Probes und Messpunkte richtig einsetzen
Für Provider ist aktive Messung oft der schnellste Weg, den Verlustort einzukreisen – vorausgesetzt, die Messpunkte sind sinnvoll gesetzt und Sie messen pro Klasse.
- UDP-Probes pro QoS-Klasse: EF-Probe (voice-ähnlich), AF-Probe (video-ähnlich), BE-Probe – so sehen Sie, ob QoS wirkt.
- Segment-Messungen: Access->Metro, Metro->Core, Core->NNI. Loss, Delay und Jitter pro Segment zeigen den Problemabschnitt.
- Richtungstrennung: wenn möglich One-Way; sonst Messpunkte so platzieren, dass Up/Down getrennt interpretiert werden kann.
Wichtig: Probes müssen klein sein und dürfen das Netz nicht belasten. Ziel ist Diagnose, nicht Lasttest.
Passive Lokalisierung: Router-/Switch-Telemetrie als „Loss-Mikroskop“
Wenn Sie wissen wollen, warum Loss entsteht, sind Gerätecounter und Telemetrie oft aussagekräftiger als End-to-End-Probes. Pflichtquellen:
- Queue Drops pro Klasse: zeigen Congestion in einer bestimmten Klasse.
- Queueing Delay/Depth: zeigt Bufferbloat und bevorstehende Drops.
- Policer Counters: Conform/Exceed/Drop und Remarking, um Profilfehler zu erkennen.
- Interface Errors: CRC/FEC/Discards für PHY-Probleme.
- ACL/Security Drops: Firewall-/Filterdrops, die als „Loss“ wirken können.
Ein sehr praktikabler Ansatz ist die Korrelation über Zeit: Loss-Event im Dienst → welcher Counter sprang im selben Zeitfenster? Damit sparen Sie viele Stunden im Troubleshooting.
Interconnect und Partnernetze: Wo lokalisieren Sie, wenn die Domäne endet?
Telcos arbeiten selten in einer vollständig kontrollierten Domäne. An NNI/Peering/Transit endet häufig die Sicht. Dann wird Lokalisierung zu einem Grenzthema:
- Messpunkte an der NNI: Probes bis zur NNI zeigen, ob Loss vor dem Übergang entsteht.
- Markierungs-Checks: DSCP/CoS kann an Übergängen neutralisiert werden; Loss kann klassenabhängig „plötzlich“ anders aussehen.
- SLA-Grenze: klar definieren, welche KPIs bis wohin garantiert werden und welche Messpunkte als Nachweis gelten.
Best Practice: Für Premiumdienste mit strengen SLAs sind private Interconnects oder vertragliche QoS-Übergaben häufig der einzig belastbare Weg, um Loss außerhalb der eigenen Domäne zu kontrollieren.
Typische Fehlersignaturen: So erkennen Sie den Loss-Typ in Minuten
- Queue Drops + steigender Queueing Delay: Congestion/Microbursts am Engpass.
- Policer Drops ohne Queueing Delay-Anstieg: Profil zu hart, Burst-Parameter zu klein, falsche Klasse.
- CRC/FEC/Link Flaps: physisches Problem, oft unabhängig von Traffic-Klasse.
- Loss nur bei bestimmten Flows/Setups: MTU/PMTUD, Firewall/NAT, Tunnel-Overhead, Fragmentierung.
- Loss nur in einer Richtung: Upstream-Engpass, asymmetrische Profile, CPE-Bufferbloat.
Diese Muster sollten als Runbook im NOC verfügbar sein. Sie verkürzen die Mean Time to Repair erheblich.
Praxis-Blueprint: Paketverlust lokalisieren Schritt für Schritt
- Dienstverlust bestätigen: RTCP/RTP Loss, MOS, Video-QoE, Rebuffer/Freeze-Events.
- Richtung und Klasse bestimmen: Up/Down, DSCP/CoS/TC, betroffenes Serviceprofil.
- Segment messen: Access, Metro, Core, NNI – mit UDP-Probes und/oder OAM, pro Klasse.
- Gerätecounter korrelieren: Queue Drops/Delay, Policer Drops, Interface Errors, Security Drops.
- Ursache klassifizieren: Congestion vs. Policer vs. PHY vs. MTU/Fragmentierung.
- Fix priorisieren: Shaping an Engpässen, Limits/Gewichte anpassen, Trust Boundary setzen, PHY/Optik reparieren, MTU/PMTUD korrigieren.
- Nachweis führen: vor/nach Messungen, Perzentile und kurze Zeitfenster, SLA-Report aktualisieren.
Häufige Fragen aus dem Betrieb
Warum sehe ich Paketverlust, obwohl die Leitung nicht voll ist?
Weil Loss oft durch Microbursts, harte Policer oder Hardware-/PHY-Probleme entsteht. Der 5-Minuten-Durchschnitt der Auslastung kann niedrig sein, während in Sekundenfenstern Puffer überlaufen. Deshalb sind Queueing Delay-Perzentile und Drop-Burstiness wichtiger als reine Auslastung.
Wie finde ich heraus, ob Loss im Access oder im Core entsteht?
Durch Segmentierung: Messen Sie Loss zwischen Messpunkten (Access->Metro, Metro->Core, Core->NNI) und korrelieren Sie mit Queue Drops/Delay an den entsprechenden Interfaces. In vielen Fällen liegt der Engpass im Access-Upstream oder an Aggregationsuplinks, nicht im Core.
Was ist das schnellste Signal für ein QoS-Designproblem?
Drops in Premiumklassen, insbesondere in der Voice-Klasse, oder eine unplausibel hohe Premium-Auslastung (Premium-Inflation). Beides deutet auf fehlende Trust Boundary, zu enge Limits oder falsches Mapping hin und sollte sofort untersucht werden.
