Tools für QoS Troubleshooting sind der Unterschied zwischen „Voice ist manchmal schlecht“ und einer belastbaren Root-Cause-Analyse, die Sie in Minuten statt Tagen zum Ergebnis bringt. QoS-Probleme sind selten sichtbar, wenn man nur auf Interface-Auslastung oder Ping schaut. Echtzeitqualität hängt an Peaks: kurze Queue-Spikes, Microbursts, Policer-Drops, Mis-Marking oder Security-Processing im Slow Path. Genau deshalb braucht QoS Troubleshooting eine Werkzeugkette, die sowohl Mechanik als auch Nutzerwirkung abdeckt: Counters zeigen, ob Policies greifen (Classifier-Hits) und wo gedroppt wird; Telemetry zeigt Trends und Perzentile (Queue Delay/Depth, Drop Reasons) und macht Peaks sichtbar; PCAPs liefern den forensischen Nachweis auf Paketebene (DSCP, Sequenzen, Timing, Retransmissions); und RTP Stats verbinden alles mit echter Sprach-/Videoqualität (Jitter, Loss, MOS, Burst Loss). Wer diese Tools kombiniert, kann typische Root Causes sauber unterscheiden: Congestion vs. Mis-Marking vs. Policer vs. Overlay/DSCP-Copy vs. WLAN Airtime vs. CPU/vSwitch-Limits. Dieser Artikel erklärt, welche Tools Sie für QoS Troubleshooting brauchen, wie Sie sie in der richtigen Reihenfolge einsetzen und wie Sie aus den Daten eine Beweiskette bauen, die auch im NOC, gegenüber Providern oder in Postmortems Bestand hat.
Das Grundprinzip: QoS Troubleshooting ist eine Beweiskette, kein Bauchgefühl
Ein robustes Vorgehen beginnt immer mit der Frage: Ist es ein Nutzerqualitätsproblem (QoE) oder ein Mechanikproblem (QoS)? In der Praxis brauchen Sie beides. Die beste Struktur ist eine dreistufige Beweiskette:
- QoE-Evidence: Was merkt der Nutzer? (RTP Jitter/Loss, MOS, Freeze-Events, Call Setup Time)
- QoS-Evidence: Was macht das Netz? (Queue Delay/Depth, Per-Class Drops, Drop Reasons, Shaper-Headroom)
- Packet-Evidence: Was passiert auf Paketebene? (DSCP, Sequenzen, Timing, Fragmentierung, Retransmissions)
Wenn Sie diese drei Ebenen zeitlich korrelieren, können Sie nicht nur sagen „es ist schlecht“, sondern „es ist schlecht, weil an Interface X die Media-Queue tail-dropped, nachdem der Shaper am Limit war“ – und das ist die Basis für dauerhafte Fixes.
Counters: Die schnellsten Indikatoren, ob QoS überhaupt greift
Counters sind Ihre erste Wahl, wenn Sie klären wollen, ob Traffic in die erwarteten Klassen fällt und ob die Queues tun, was sie sollen. In vielen Incidents ist der Root Cause simpel: Die Policy ist nicht gebunden, die Classifier matchen nicht, oder DSCP driftet. Diese Dinge sehen Sie in Sekunden, wenn Sie die richtigen Zähler anschauen. Wichtig ist, Counters immer am richtigen Ort zu betrachten: an den Congestion Domains und vor allem am Egress.
- Classifier-Hits (Packets/Bytes pro Klasse): beweist, dass Traffic wirklich in VOICE/MEDIA/SIGNAL landet.
- Default/Unmatched: steigt dieser Anteil, ist Mis-Marking oder Match-Drift wahrscheinlich.
- Queue Drops pro Klasse: zeigt, ob Echtzeit betroffen ist oder ob BE/BULK die Einbußen trägt.
- Queue Depth/Backlog (falls als Counter): zeigt, ob die Queue regelmäßig anläuft.
- Shaper/Policer Counters: revealen harte Limits und Policer-Drops (häufiger „Never Event“ für Voice).
Counter-Interpretation: Was die häufigsten Muster bedeuten
Ein Counter ist nur dann hilfreich, wenn Sie ihn richtig deuten. Es gibt einige wiederkehrende Muster, die Sie sofort in Richtung Root Cause lenken.
- VOICE hat kaum Hits, Default hoch: Klassifizierung/Trust Boundary falsch, DSCP verloren oder nicht trusted.
- VOICE hat Hits, aber trotzdem schlechte QoE: Problem liegt oft nicht in Klassifizierung, sondern in Queueing, Policer oder außerhalb der Kontrolle (Provider-Buffer, Security, WLAN).
- Drops in VOICE/MEDIA: echte Degradation; prüfen, ob Tail Drop (Queue voll) oder Policer.
- Policer Drops in Echtzeit: Loss-Spikes ohne Queue-Wachstum; meist Designfehler (zu harte Limits).
- Keine Drops, aber Delay hoch: Bufferbloat; Shaping/Buffer-Profile und Queue Delay perzentilbasiert prüfen.
Telemetry: Trends, Perzentile und Drop Reasons statt „5-Minuten-Mittelwert“
Telemetry ist das Werkzeug, das QoS Troubleshooting skalierbar macht. Counters geben Momentaufnahmen, Telemetry zeigt Verlauf und Peaks. Für Echtzeit ist nicht der Durchschnitt entscheidend, sondern das 95./99. Perzentil und kurze Delay-Spitzen. Eine gute Telemetry-Strategie liefert daher pro Congestion Domain: Queue Delay (95p/99p), Queue Depth Peak, Per-Class Drops, Drop Reasons und Shaper-Headroom. Damit erkennen Sie Degradation früh und können sie zeitlich mit QoE-Problemen korrelieren.
- Queue Delay 99p: Frühwarnsystem gegen Echtzeitprobleme; Peaks sind entscheidend.
- Peak Queue Depth: Microburst-Indikator, auch bei niedriger Durchschnittsauslastung.
- Per-Class Drops: zeigt, ob QoS „richtig opfert“ (BE/BULK) oder Echtzeit trifft.
- Drop Reasons: Tail Drop vs. Policer vs. Buffer Exhaustion vs. Policy Drops.
- Shaper Headroom: zeigt, ob Engpässe dauerhaft am Limit laufen oder nur sporadisch.
Telemetry-Design: Wo und wie Sie messen müssen
Telemetry ist nur nützlich, wenn sie an den richtigen Messpunkten erhoben wird. In QoS gilt: Messen Sie dort, wo Congestion entsteht – WAN/Internet-Uplinks, Aggregationslinks, Metro/PoP-Uplinks, Underlay-Egress bei SD-WAN, Security-Edges, WLAN (Airtime), virtuelle Datenpfade (vSwitch/CPU). Zusätzlich ist Zeitauflösung wichtig: Minutenauflösung verschleiert Microbursts. Wo Sekundenauflösung nicht möglich ist, nutzen Sie Perzentile und Max-Werte.
- Engpass-Egress: WAN/Internet/Interconnect – häufig wichtigste Quelle für Delay/Drops.
- Overlay Underlay: Egress ins Underlay (nicht nur Tunnelinterface).
- Security Interfaces: vor/nach Firewall, um Processing-Latenz sichtbar zu machen.
- WLAN: Airtime Utilization, Retry Rates, PHY-Rates, Roaming-Events als Funk-QoS-Telemetry.
- Compute: CPU Ready/Steal, cgroup Throttling, vSwitch Queueing als Ergänzung zu Netztelemetry.
PCAPs: Der forensische Nachweis auf Paketebene
PCAPs (Packet Captures) sind das schärfste Werkzeug, aber sie sind teuer: Sie erzeugen Datenmengen und brauchen Zeit zur Auswertung. Deshalb sollten Sie PCAPs zielgerichtet einsetzen, wenn Counters/Telemetry den Verdacht eingrenzen, aber Sie den Beweis brauchen – zum Beispiel für DSCP Preservation, Sequenzlücken, Retransmissions, MTU/Fragmentierung oder NAT/One-Way-Audio. Ein PCAP ist besonders wertvoll, wenn Sie an mehreren Punkten capturen: vor und nach einem Tunnel, vor und nach einer Firewall, am Sender und am Empfänger. So sehen Sie, wo Marking verloren geht oder wo Loss entsteht.
- DSCP/CoS Check: stimmt DSCP im inneren Paket und (bei VPN) im outer Header?
- Timing/Jitter: Inter-Arrival Times und Burstiness; besonders bei RTP sichtbar.
- Loss-Beweis: Sequenzlücken, Out-of-Order, Duplicate Packets.
- TCP Artefakte: Retransmissions, Zero-Window, RTT-Spikes (für Video-ABR/Sharing relevant).
- MTU/Fragmentierung: Fragmente oder ICMP-PTB-Probleme, die zu Retransmissions führen.
PCAP-Strategie: „Capture smart“ statt „Capture everything“
Damit PCAPs im Incident nicht zur Zeitfalle werden, helfen einige pragmatische Regeln: Capturen Sie kurz und präzise (z. B. 30–120 Sekunden um den Peak), nutzen Sie Filter (5-Tuple, Ports, DSCP), und fokussieren Sie auf die Congestion Domain oder den Verdachtspunkt. Bei verschlüsselten Medien (SRTP, DTLS-SRTP) sehen Sie keinen Payload, aber Sie sehen weiterhin Timing, DSCP, Sequenzen und Paketgrößen – oft genug, um QoS-Probleme zu belegen.
- Zeitfenster: um den Degradationspeak, nicht „den ganzen Tag“.
- Filter: IPs/Ports/DSCP; bei RTP helfen SSRC/Port-Korrelationen.
- Mehrpunkt-Capture: vor/nach Tunnel, vor/nach Firewall, Sender/Empfänger.
- Beweisziel: vorab definieren (DSCP-Verlust? Loss-Ort? MTU?).
RTP Stats: QoE direkt aus dem Medienstrom ableiten
RTP Stats sind die Brücke zwischen Netzmechanik und wahrnehmbarer Qualität. Sie liefern Jitter, Paketverlust, Out-of-Order, Burst Loss und – je nach System – MOS oder Qualitätsindikatoren. RTP/RTCP-Berichte sind besonders hilfreich, weil sie auch bei verschlüsselter Nutzlast funktionieren: SRTP verschlüsselt den Payload, aber RTP/RTCP-Metadaten und Sequenzen bleiben analysierbar, sofern Sie sie aus Endpunkten oder Monitoring-Systemen erhalten. Für WebRTC liefern vergleichbare Informationen die getStats-APIs: Jitter, RTT, Packet Loss, Bitrate, Frames Dropped, Freeze-Events.
- Jitter: entscheidend für Audioqualität; Peaks sind wichtiger als Mittelwerte.
- Loss und Burst Loss: Burst Loss ist für Verständlichkeit schlimmer als gleichmäßig verteilter Loss.
- RTT/Delay: hohe RTT kann Echo/Interaktion verschlechtern und ABR beeinflussen.
- MOS/Quality Scores: hilfreich für Management-Reporting, aber immer mit Netz-KPIs korrelieren.
RTP Stats interpretieren: typische Muster und ihre Bedeutung
RTP- und WebRTC-Stats zeigen nicht nur „schlecht“, sondern geben Hinweise auf die Art des Problems. Kombiniert mit Queue- und Drop-Daten können Sie sehr schnell zu einer Ursache kommen.
- Hoher Jitter, wenig Loss: oft Queueing/Bufferbloat oder Security/Compute-Variabilität.
- Loss-Spikes ohne Jitter-Anstieg: häufig Policer-Drops oder harte Limits.
- Out-of-Order/Duplicates: Pfadwechsel (SD-WAN), ECMP-Asymmetrie oder Reordering in Overlays.
- Einseitige Probleme: Return Path, NAT/Firewall oder asymmetrische QoS-Policies.
Tool-Kombinationen: Welche Werkzeuge wann am schnellsten zum Ergebnis führen
QoS Troubleshooting wird deutlich effizienter, wenn Sie typische Incident-Pfade standardisieren. Eine gute Praxis ist, mit Telemetry und Counters zu starten und PCAPs nur dann einzusetzen, wenn Sie einen spezifischen Beweis brauchen. RTP Stats liefern parallel den Nutzerbezug.
- „Policy greift nicht“: Classifier-Hits + Default/Unmatched + Attachment-Check; PCAP nur für DSCP-Verlustbeweis.
- „Nur zu Stoßzeiten schlecht“: Queue Delay/Depth 99p + Shaper-Headroom + Per-Class Drops; RTP Jitter korrelieren.
- „Loss ohne Queueing“: Drop Reasons + Policer Counters; PCAP zur Bestätigung von Loss-Spikes.
- „Über VPN schlecht“: Outer DSCP prüfen (PCAP/Telemetry), Underlay-Egress Queueing, DSCP Copy/Mapping; RTP Stats.
- „Nur WLAN“: Airtime/Retry/PHY-Metriken + WMM Mapping; RTP/WebRTC Stats und Roaming-Events.
Pragmatisches Setup: Was ein Team mindestens braucht
Sie müssen nicht sofort eine perfekte Observability-Plattform haben. Entscheidend ist, die minimalen Bausteine bereitzustellen, mit denen Sie wiederkehrende QoS-Fragen beantworten können: Greift die Policy? Wo entsteht Delay? Wo wird gedroppt? Warum wird gedroppt? Was merkt der Nutzer?
- Standardisierte Counters: pro Klasse Hits, Drops, Queue Stats, Policer/Shaper.
- Telemetry-Panels: Queue Delay/Depth (95p/99p), Drops, Drop Reasons, Shaper-Headroom.
- RTP/WebRTC QoE: Jitter/Loss/RTT/MOS/Freeze-Events, idealerweise pro Standort/Providerpfad.
- PCAP-Fähigkeit: gezielte Captures an definierten Punkten (Edge, Tunnel, Security, WLAN-Gateway).
- Playbooks: Congestion vs. Mis-Marking vs. Policer vs. Overlay vs. WLAN als standardisierte Diagnosepfade.
Checkliste: QoS Troubleshooting Schritt für Schritt
- 1) Scope: Betroffene Standorte, Pfade, Zeitfenster (Peak!), Richtung (Tx/Rx).
- 2) QoE: RTP/WebRTC Stats prüfen (Jitter/Loss/RTT, MOS, Freeze/Downshift).
- 3) Counters: Classifier-Hits, Default/Unmatched, Per-Class Drops, Policer/Shaper prüfen.
- 4) Telemetry: Queue Delay/Depth 99p, Drop Reasons, Shaper-Headroom an Congestion Domains.
- 5) Hypothese: Congestion vs. Mis-Marking vs. Policer vs. Overlay vs. WLAN vs. Security/Compute.
- 6) PCAP (gezielt): DSCP inner/outer, Sequenzlücken, Timing, MTU/Fragmentierung, Retransmissions beweisen.
- 7) Fix & Guardrail: Shaping/Mapping/Trust/Queue-Limits anpassen und Monitoring-Alert ergänzen.
