Site icon bintorosoft.com

Per-Class Drops: Wie Sie “wo” und “warum” Paketverlust beweisen

Red Snapper

Per-Class Drops sind eine der wenigen Messgrößen, mit denen Sie Paketverlust nicht nur vermuten, sondern gerichtsfest „wo“ und „warum“ beweisen können. In vielen QoS-Diskussionen bleibt es bei Aussagen wie „das WAN ist schuld“ oder „das WLAN droppt“, weil nur grobe Interface-Zähler betrachtet werden: Discards, Output Drops oder eine durchschnittliche Linkauslastung. Für Echtzeitdienste wie RTP, WebRTC, Videostreaming oder kritische Applikationen ist das zu ungenau. Ein Paket kann auf dem Weg durch mehrere Hops verloren gehen, und häufig ist nicht die gesamte Schnittstelle überlastet, sondern eine einzelne Queue oder Klasse. Genau hier setzt Per-Class Drops an: Sie zeigen, in welcher QoS-Klasse (z. B. Voice, Video, Best Effort, Bulk) Pakete verworfen wurden – und oft sogar mit Drop Reasons, also dem Grund für den Verlust (Tail Drop, Policer, WRED, Buffer Exhaustion, Policy Drop). Wer Per-Class Drops sauber erhebt und mit Klassifizierungszählern, Queue-Delay und Applikationsmetriken korreliert, kann Paketverlust eindeutig lokalisieren, Fehlmarkierung entlarven und QoS-Policies so nachschärfen, dass sie im Betrieb wirklich schützen.

Warum klassische Interface-Drops nicht ausreichen

Interface-Zähler sind wichtig, aber sie erzählen selten die ganze Geschichte. „Output drops“ können bedeuten, dass eine egress Queue überläuft – oder dass ein Hardwarepuffer erschöpft ist – oder dass ein Policer hart zuschlägt, bevor das Paket überhaupt die Queue erreicht. Manche Plattformen zählen Drops auch erst sehr spät oder aggregiert, sodass Sie nicht erkennen, welche Traffic-Klasse betroffen war. Für die Praxis heißt das: Wenn Sie nur auf Interface-Ebene messen, können Sie weder beweisen, welche Anwendung getroffen wird, noch ob QoS tatsächlich geholfen hat.

Was Per-Class Drops genau bedeuten

Per-Class Drops sind Zähler, die pro QoS-Klasse oder pro Queue erfassen, wie viele Pakete/Bytes verworfen wurden. Je nach Plattform liegen die Zähler auf unterschiedlichen Ebenen: in der Policy (Class-Based QoS), in der egress Queue des ASICs oder in einem Shaper/Policer-Modul. Der zentrale Vorteil bleibt: Sie sehen, welche Klasse betroffen ist. Damit lässt sich Paketverlust „an der richtigen Stelle“ diskutieren: Wenn Drops nur in Best Effort auftreten, ist das oft tolerierbar. Wenn Drops in Voice oder einer Media-Klasse auftreten, ist das ein harter Qualitätsvorfall.

„Wo“ beweisen: Der methodische Ansatz zur Lokalisierung von Paketverlust

Um den Ort des Paketverlusts zu beweisen, brauchen Sie eine Messkette entlang des Pfads. Die Grundidee ist simpel: Wenn Sie an Hop A keine Drops sehen, an Hop B aber schon, dann liegt der Verlust zwischen diesen Punkten – meist direkt auf dem Egress von B oder in dessen vorgelagerten QoS-/Hardware-Mechanismen. Entscheidend ist, dass Sie nicht nur einen Hop messen, sondern mindestens die Engpässe abdecken: Standort-Uplink, WAN/SD-WAN-Edge, Aggregationslinks und Access-Uplinks. In der Praxis sind es oft erstaunlich wenige Stellen, an denen Congestion wirklich entsteht.

Die wichtigste Unterscheidung: Ingress- vs. Egress-Drops

Viele Missverständnisse entstehen, weil Drops an unterschiedlichen Stellen passieren können. Ingress-Drops deuten häufig auf Policers, ACLs, L2/L3-Fehler oder Ressourcenmangel beim Empfang hin. Egress-Drops deuten meist auf Congestion in Queues, Shaping-Grenzen oder egress Buffer-Limits hin. Für QoS-Nachweise sind egress Per-Class Drops besonders aussagekräftig, weil QoS-Scheduler dort arbeiten.

„Warum“ beweisen: Drop Reasons als Übersetzer von Countern zu Ursachen

Ein Drop-Zähler ohne Grund ist wie ein Alarm ohne Meldung. Moderne Plattformen können Drop Reasons liefern, entweder als explizite Counter pro Mechanismus (Tail Drop, Policer Drop, WRED Drop) oder als Telemetry-Felder aus dem ASIC. Der Nutzen ist enorm: Tail Drop in einer Video-Klasse heißt „Queue voll“. Policer Drop heißt „Rate überschritten“. WRED Drop heißt „frühzeitiges Drop-Verhalten“ (meist für TCP). Buffer Exhaustion heißt „Shared Buffer oder Headroom erschöpft“, oft microburst-getrieben. Diese Gründe führen zu unterschiedlichen Maßnahmen und belegen, dass der Verlust nicht „mystisch“ ist, sondern einem klaren Mechanismus folgt.

Die Beweiskette: Per-Class Drops mit Klassifizierung verknüpfen

Per-Class Drops beweisen, dass Pakete in einer Klasse verworfen wurden. Um zu beweisen, dass es wirklich Ihre Anwendung war, brauchen Sie den zweiten Beweis: Die Anwendung muss in dieser Klasse angekommen sein. Dafür sind Klassifizierungszähler essenziell: Matched Packets/Bytes pro Klasse, „unmatched“ oder Default-Class-Anteile, Re-Marking-Counter. Ein typischer Fehler in der Praxis ist, Drops in Best Effort zu sehen und daraus abzuleiten, dass Voice sauber ist – obwohl Voice wegen Fehlmarkierung ebenfalls in Best Effort lief. Erst wenn Sie zeigen können, dass RTP/Media tatsächlich in der Media-/Voice-Klasse matched wurde, sind Per-Class Drops wirklich belastbar.

Queue-Delay als Ergänzung: Verlust ist nicht das einzige Problem

Sie können Paketverlust beweisen – und trotzdem bleibt die Qualität schlecht, weil Delay und Jitter steigen. Deshalb sollte jede Per-Class-Drop-Analyse immer auch Queue-Occupancy und Queue-Delay betrachten. Das ist besonders wichtig bei großen Puffern (Bufferbloat) oder bei Shaping, wo Pakete bewusst verzögert werden, aber nicht droppen. Für Echtzeitdienste kann ein wachsender Backlog in der Media-Klasse bereits problematisch sein, bevor überhaupt Drops auftreten. Der „Beweis“ lautet dann nicht Verlust, sondern Verzögerung: Queue-Delay korreliert mit Jitter und Qualitätsereignissen.

Praktisches Vorgehen: Paketverlust auf einen Engpass „festnageln“

Ein praxistauglicher Nachweis besteht aus einem wiederholbaren Ablauf. Zuerst definieren Sie das Symptom und das Zeitfenster (z. B. „10:14–10:18 Uhr ruckelte Video, Audio stotterte“). Dann identifizieren Sie die Engpassstellen im Pfad. Anschließend ziehen Sie Per-Class Drops und Drop Reasons für diese Interfaces. Parallel prüfen Sie Klassifizierungszähler, damit Sie sicher sind, dass die Anwendung in der erwarteten Klasse läuft. Abschließend korrelieren Sie mit Applikationsmetriken (RTP-Sequenzlücken, RTCP Receiver Reports, WebRTC Stats). Wenn alle drei Ebenen zeitlich zusammenpassen, haben Sie Ihren Beweis.

Typische Muster und was sie beweisen

Im Betrieb begegnen Ihnen wiederkehrende Muster. Wenn Tail Drops nur in Best Effort auftreten, während Media/Voice stabil bleibt, beweist das, dass QoS schützt. Wenn Tail Drops in der Media-Klasse an einem Standort-Uplink auftreten und gleichzeitig RTP-Loss beim Receiver steigt, ist der Engpass klar. Wenn Policer Drops in einer Voice-Klasse auftreten, ist das fast immer ein Designfehler: Echtzeit sollte selten hart gepoliced werden. Wenn Buffer Exhaustion erscheint, ist der Engpass nicht unbedingt „zu wenig Bandbreite“, sondern häufig Microburst- oder Plattform-Headroom.

Microbursts sichtbar machen: Warum Drops „kurz und heftig“ sein können

Per-Class Drops steigen manchmal sprunghaft, obwohl die durchschnittliche Rate unauffällig ist. Das ist typisch für Microbursts: Viele Flows senden gleichzeitig, oder ein upstream Device bündelt Pakete, etwa durch Encapsulation (VXLAN/IPsec), Replikation (Multicast) oder durch TCP-Congestion-Window-Effekte. Wenn der egress Buffer nicht genug Headroom hat, kommt es zu Tail Drops oder Buffer Exhaustion. Um das zu beweisen, brauchen Sie hochauflösende Telemetry: Queue-Occupancy als Zeitreihe, Peak-Raten und idealerweise Burst-spezifische Counter. Ein einmaliger Snapshot nach dem Ereignis reicht oft nicht.

Applikationsbezug herstellen: RTP/WebRTC/Video-Qualität mit Drops verbinden

Per-Class Drops beweisen den Verlust im Netzwerk. Der nächste Schritt ist, zu zeigen, dass die Anwendung ihn spürt. Bei RTP ist das elegant: Sequenznummern zeigen fehlende Pakete, RTCP liefert Jitter/Loss-Indikatoren. Bei WebRTC liefern getStats-Metriken Round-Trip, Jitter, Packet Loss, Bitrate-Änderungen und Transport-Fallbacks. Bei IPTV/Multicast können Probe-Receiver Sequenzlücken erfassen. Wenn Sie diese Applikationsmetriken im gleichen Zeitfenster wie Per-Class Drops sehen, ist die Kausalität überzeugend: „Drops in der Media-Klasse am Standort-Uplink verursachen Loss beim Receiver.“

Best Practices: Per-Class Drops dauerhaft operationalisieren

Damit Per-Class Drops nicht nur im Incident helfen, sollten Sie sie in den Normalbetrieb integrieren. Das heißt: Baselines pro Engpass, Alarme auf Drops und Delay in Echtzeitklassen, sowie Dashboards, die „wo“ und „warum“ in einem Blick beantworten. Besonders hilfreich ist eine Sicht, die pro Standort-Uplink die Top-Klassen nach Drops und Delay zeigt, inklusive Drop Reasons. Ergänzend sollten Sie die Trust Boundary und Klassifizierungsregeln regelmäßig verifizieren, damit Fehlmarkierung nicht unbemerkt die Beweiskette zerstört.

Exit mobile version