Root Cause QoS Incidents sauber zu identifizieren ist eine der wichtigsten Fähigkeiten im Betrieb moderner Netzwerke – und gleichzeitig eine der am häufigsten unterschätzten. Wenn Voice stottert, Video einfriert oder WebRTC in der Qualität springt, lautet die erste Vermutung oft „Congestion“. In der Praxis sind jedoch drei Ursachenklassen besonders dominant und leicht zu verwechseln: echte Überlast (Congestion), falsche Markierung oder falsche Klassifizierung (Mis-Marking/Mis-Classification) und zu aggressive oder falsch platzierte Policers. Alle drei können nahezu identische Symptome erzeugen: Jitter-Spikes, Paketverlust, schlechte MOS-Werte, verzögerte Call-Setups oder sporadische Aussetzer. Der Unterschied liegt im Mechanismus – und der bestimmt die richtige Gegenmaßnahme. Wer Congestion mit einem Policer „behebt“, verschlimmert oft alles. Wer Mis-Marking mit mehr Bandbreite löst, bezahlt ohne Effekt. Und wer einen Policer-Fehler als „Providerproblem“ abtut, verliert Zeit und Glaubwürdigkeit. Dieser Artikel zeigt, wie Sie Root Cause QoS Incidents systematisch auseinanderhalten, welche Beweise Sie benötigen (Per-Class Drops, Queue Depth/Delay, Drop Reasons, Classifier-Hits) und wie Sie aus der Diagnose direkt zu stabilen Fixes und präventiven Kontrollen kommen.
Das Grundproblem: Drei Ursachen, ein Symptom-Bild
Echtzeitqualität bricht immer dann ein, wenn Pakete zu spät kommen, in zu großer Varianz ankommen oder gar nicht ankommen. Für Anwendungen sieht das gleich aus: Audio klingt „robotisch“, Video friert, Meetings reconnecten. Aus Netzsicht können jedoch völlig unterschiedliche Mechanismen dahinterstecken:
- Congestion: Es kommt mehr Traffic an, als ein Link/Queue in einem Zeitfenster abtransportieren kann. Folge: Queue Depth steigt, Queue Delay steigt, später Drops.
- Mis-Marking/Mis-Classification: Der Traffic ist korrekt, aber landet in der falschen Klasse (z. B. Voice in Best Effort) oder wird unterwegs ummarkiert. Folge: Echtzeit konkurriert mit Datenverkehr, obwohl QoS „eigentlich“ vorhanden ist.
- Policer: Traffic wird hart begrenzt; bei Überschreitung werden Pakete gedroppt oder re-markiert. Folge: Loss tritt plötzlich auf, oft ohne vorheriges Queue-Wachstum.
Die Kunst der Root Cause Analyse ist, die Mechanik zu erkennen – nicht nur das Symptom.
Beweismittel, die Sie für jede Diagnose brauchen
Ohne die richtigen Metriken wird jede Ursachenanalyse zur Diskussion. Für QoS Incidents sind vier Datenkategorien entscheidend:
- Per-Class Counters: Matched Packets/Bytes pro Klasse, Per-Class Drops, ggf. Per-Class Rates.
- Queue Telemetry: Queue Depth (inkl. Peak), Queue Delay/Latency, Scheduler-Statistiken.
- Drop Reasons: Tail Drop/Queue Full, Policer Drop, WRED Drop, Buffer Exhaustion, Policy Drop.
- Service-Metriken: RTP/RTCP-Stats, MOS/Bad-Call-Rate, WebRTC Jitter/Loss/RTT, Video-Freeze/Downshift.
Mit diesen Daten können Sie fast immer eine belastbare Beweiskette aufbauen: Service degradiert → Netzsignal (Queue/Drops) → Ursache (Reason/Classifier).
Congestion als Root Cause: Das typische Fingerabdruck-Muster
Congestion ist der Klassiker – aber er hat sehr klare Indikatoren, wenn Sie auf Queue-Ebene messen. Ein Congestion-Incident zeigt meist eine zeitliche Abfolge: erst wächst Queue Depth, dann steigt Queue Delay, dann steigen Drops. Je nach Puffergröße kann Delay lange steigen, bevor Drops sichtbar werden (Bufferbloat). Außerdem ist Congestion häufig zeitlich oder lastabhängig: Stoßzeiten, Backup-Fenster, große Uploads, viele gleichzeitige Meetings oder Multicast-Replikation.
Typische Messsignaturen bei Congestion
- Queue Depth steigt: besonders in der betroffenen Klasse oder in Best Effort, wenn QoS nicht schützt.
- Queue Delay steigt: oft der früheste harte Indikator für Echtzeitprobleme.
- Tail Drops: Drop Reason „Queue Full“ oder „Tail Drop“ in einer oder mehreren Klassen.
- Shaper am Limit: am WAN-/Internet-Uplink steigt Backlog, Headroom geht gegen null.
- Service-Korrelation: Jitter/MOS kippt parallel zum Delay, Loss steigt parallel zu Drops.
Congestion tritt selten „überall“ auf
In der Praxis ist Congestion meist lokal: Standort-Uplink, Access-Uplink, VPN-Gateway, WLAN-Airtime, Provider-Access. Wenn Sie überall „ein bisschen“ sehen, ist oft ein gemeinsamer Engpass beteiligt (z. B. Internet-Edge oder SD-WAN-Underlay). Darum lohnt sich ein Engpass-fokussiertes Monitoring: Die richtigen Interfaces sind wichtiger als viele.
Mis-Marking/Mis-Classification als Root Cause: QoS existiert, aber greift nicht
Mis-Marking bedeutet: Der Verkehr ist da, aber die Markierung (DSCP/CoS) ist falsch oder wird auf dem Weg verändert. Mis-Classification bedeutet: Die Markierung mag korrekt sein, aber das Gerät klassifiziert anders (z. B. falsches Mapping DSCP->Queue, fehlende Policy auf einem Interface, falsche Trust Boundary). Das Ergebnis ist ähnlich: Echtzeit landet in Best Effort oder in einer falschen Sammelklasse und leidet unter normaler Datenlast. Besonders perfide: In solchen Fällen können Voice/Video-Probleme auch auftreten, obwohl die „Voice Queue“ perfekt aussieht – weil gar nichts dort ankommt.
Typische Messsignaturen bei Mis-Marking
- Classifier-Hits passen nicht: Voice/Media-Klasse hat unerwartet wenig Traffic, Default/Unmatched steigt.
- Per-Class Drops in Best Effort: Service leidet, aber Drops tauchen nicht in Voice/Media auf.
- Re-Marking Counter: DSCP wird am Edge oder an Security Devices zurückgesetzt oder umgeschrieben.
- Asymmetrie: nur eine Richtung schlecht, weil Marking/Trust auf einem Pfadsegment anders ist.
- Standort-/Gerätespezifik: Probleme nur bei bestimmten Client-Typen, SSIDs oder Segmenten.
Die häufigsten Ursachen für Mis-Marking in der Praxis
- Fehlende Trust Boundary: Endgeräte werden nicht trusted, DSCP wird auf 0 gesetzt.
- Inkonsequentes Mapping: DSCP->Queue auf Access anders als auf WAN-Edge.
- Tunnel/Overlay-Fehler: DSCP wird nicht vom Inneren auf das äußere Header kopiert.
- Security Appliances: NAT/Firewall/TLS-Inspection setzt DSCP zurück oder klassifiziert alles als Best Effort.
- Neue Applikationspfade: WebRTC fällt auf TCP/TLS zurück, Traffic sieht „wie HTTPS“ aus und wird anders behandelt.
Policer als Root Cause: Wenn QoS selbst den Verlust erzeugt
Policers sind in QoS-Designs nützlich, um Fehlmarkierung zu begrenzen oder bestimmte Klassen hart zu deckeln. Für Echtzeitverkehr sind sie jedoch riskant, weil sie bei Überschreitung direkt droppen oder re-marken – ohne die sanftere Glättung eines Shapers. Ein Policer-Incident zeigt oft ein anderes Muster als Congestion: Paketverlust tritt plötzlich auf, häufig ohne vorheriges Wachstum von Queue Depth/Delay. Außerdem sind Drop Reasons hier besonders eindeutig: „Policer Drop“, „Rate Limit Exceeded“ oder „Re-marked by Policer“.
Typische Messsignaturen bei Policer-Problemen
- Policer Drops > 0: in Voice/Media fast immer ein starkes Root-Cause-Signal.
- Loss ohne Queue-Wachstum: Queue Depth/Delay bleibt relativ unauffällig, trotzdem Loss im Service.
- Schwellen-/Burst-Effekte: Loss tritt in Clustern auf, wenn Bursts das Token-Bucket sprengen.
- Re-Marking sichtbar: Echtzeit wird in eine niedrigere Klasse gedrückt und leidet dann sekundär.
Warum Policers bei Echtzeit so oft „zu hart“ sind
RTP/RTC arbeitet paketbasiert mit relativ konstantem Timing, aber es gibt reale Bursts: Codec-Änderungen, FEC, Paketisierung, kurze OS-Scheduling-Spikes, Encapsulation oder Replikationseffekte. Ein Policer, der zu knapp dimensioniert ist oder zu kleine Burst-Toleranz hat, droppt genau diese kurzen Spitzen – und macht daraus hörbare Aussetzer. In vielen Designs ist Shaping am Uplink plus Scheduling die bessere Lösung, weil es Bursts glättet, statt Pakete zu vernichten.
Ein Entscheidungsbaum für die Root Cause Diagnose
Wenn Sie mitten im Incident stehen, hilft ein klarer Ablauf. Der folgende Entscheidungsbaum ist bewusst pragmatisch und basiert auf den stärksten Signalen:
- Schritt 1: Sind Service-KPIs schlecht? (RTP Loss/Jitter, MOS-Abfall, Bad-Call-Rate, Video-Freeze)
- Schritt 2: Gibt es Queue Delay/Depth-Spikes in Voice/Media an einem Engpass? Wenn ja, Congestion/Bufferbloat wahrscheinlich.
- Schritt 3: Gibt es Per-Class Drops in Voice/Media? Wenn ja, prüfen: Tail Drop (Congestion) oder Policer Drop (Policer).
- Schritt 4: Wenn Voice/Media keine Drops/Delay zeigen: Prüfen Sie Classifier-Hits und Default/Unmatched. Wenn Voice nicht in der Klasse landet, Mis-Marking/Mis-Classification wahrscheinlich.
- Schritt 5: Wenn alles „sauber“ wirkt, aber Service schlecht: Pfadwechsel (SD-WAN, WebRTC Transport-Fallback), WLAN-Retries/Airtime oder Provider/Peering als nächste Hypothesen prüfen.
Case Patterns: So sehen die drei Ursachen im Zeitverlauf aus
Viele Teams lösen QoS Incidents schneller, wenn sie Muster erkennen, statt jedes Mal bei Null zu starten. Typische Zeitmuster:
- Congestion: langsam ansteigende Delay-Kurve, dann Drops; oft korreliert mit Uplink-Sättigung oder wiederkehrenden Zeitfenstern.
- Mis-Marking: plötzliche Verschlechterung nach Changes, neue Client-Versionen oder neue Pfade; Classifier-Drift sichtbar; QoS-Queues „leer“ trotz schlechter QoE.
- Policer: Loss tritt ab einer Schwelle abrupt auf; Drop Reason zeigt Policer; häufig in Bursts statt kontinuierlich.
Praktische Fixes: Welche Maßnahmen zu welcher Root Cause passen
Ein Root-Cause-Artikel ist nur dann nützlich, wenn die Diagnose direkt zu passenden Maßnahmen führt. Wichtig ist, die Fixes nicht zu vermischen, weil das oft Nebenwirkungen erzeugt.
- Congestion-Fixes: Uplink-Shaping korrekt setzen, Klassenbandbreiten anpassen, Bulk drosseln, Zeitplanung für große Transfers, Kapazität erweitern, Pfade optimieren (Local Breakout statt Hairpin).
- Mis-Marking-Fixes: Trust Boundary definieren, DSCP/CoS-Mappings konsistent machen, Tunnel-DSCP-Copy aktivieren, Security Devices auf DSCP-Preservation konfigurieren, Klassifizierungsregeln ergänzen, App-spezifische Pfade berücksichtigen (UDP vs. TCP/TLS).
- Policer-Fixes: Policers auf Echtzeit entschärfen oder entfernen, Burst-Toleranz erhöhen, Shaping statt Policing nutzen, Re-Marking-Strategie überdenken, Policers nur als Schutz gegen Fehlmarkierung einsetzen.
Prävention: Kontrollen, die Root Causes früh abfangen
Viele QoS Incidents sind wiederkehrend. Sie können sie präventiv reduzieren, wenn Sie die passenden Kontrollen einführen. Queue Depth/Delay Monitoring ist ein Frühwarnsystem gegen Congestion und Bufferbloat. Classifier Drift und Re-Marking Counters warnen vor Mis-Marking, bevor Nutzerqualität kippt. Policer-Drops in Echtzeitklassen sollten als „Never Events“ behandelt werden: Sobald sie auftreten, ist ein Engineering-Check fällig.
- Early Warning Alerts: Voice/Media Queue Delay 95p/99p mit Persistenz.
- Per-Class Drop Alerts: Voice/Media Drops mit Drop Reason und Top-Offender-List.
- Mis-Marking Alerts: Default/Unmatched-Anteil steigt vs. Baseline, Re-Marking Events steigen.
- Policer Guardrails: Policer Drops in Voice/Media = sofortiger Incident/Change Review.
- Change Overlay: QoS-/SD-WAN-/Firewall-Changes in Zeitreihen markieren, um Kausalität schnell zu prüfen.
Dokumentation und Kommunikation: Root Cause so formulieren, dass es niemand diskutiert
Für Postmortems, Provider-Tickets oder interne Eskalationen ist die Beweisführung entscheidend. Eine gute Root-Cause-Formulierung enthält: betroffene Services, Zeitraum, betroffene Pfade/Interfaces, die Metrikbeweise (Queue Delay/Depth, Per-Class Drops, Drop Reasons, Classifier-Hits) und die Korrelation zu Service-KPIs. Das ist nicht nur technisch sauber, sondern schützt auch vor endlosen Diskussionen, weil „wo“ und „warum“ belegt sind.
- Was: Voice/Video Degradation (MOS-Abfall, Jitter/Loss-Anstieg, Bad-Call-Rate).
- Wo: konkretes Interface/Queue am Engpass (z. B. Standort-Uplink egress).
- Warum: Drop Reason oder Mechanik (Tail Drop = Congestion, Policer Drop = Policer, Classifier-Drift = Mis-Marking).
- Maßnahme: konkreter Fix plus Präventionskontrolle (Alert/Monitoring/Policy-Guardrail).
