Ein QoS-Troubleshooting Guide ist dann am wertvollsten, wenn er im Ernstfall wie ein Runbook funktioniert: klar, reproduzierbar und schnell. Denn wenn Voice knackt und Video ruckelt, ist der Impuls oft, „am Codec zu drehen“ oder „noch mehr Priorität zu geben“. Genau das verschlimmert Probleme in vielen Netzen, weil die Ursachen meist an Engpässen, Markierungslücken, Microbursts, Bufferbloat oder zu harten Policern liegen – nicht an der Anwendung selbst. Echtzeitdienste reagieren extrem sensibel auf Jitter, Paketverlust und Verzögerungsspitzen. Ein kurzer Drop-Cluster von wenigen Sekunden kann einen VoIP-Call hörbar zerstören, während ein Video-Client gleichzeitig auf niedrigere Bitrate fällt oder kurze Freezes zeigt. Gleichzeitig können Symptome täuschen: „Paketverlust“ ist manchmal Late Loss durch Bufferbloat, „nur über VPN schlecht“ ist häufig ein Outer-DSCP- oder MTU-Problem, und „QoS ist aktiv“ heißt nicht, dass Traffic tatsächlich in den richtigen Klassen landet. Dieses Troubleshooting-Runbook führt Sie deshalb in einer festen Reihenfolge durch Diagnose und Fix: erst Dienstsicht bestätigen, dann Markierungen und Klassen prüfen, dann Engpässe segmentieren, dann Queueing/Drops/Policer analysieren, anschließend Sonderfälle (MTU, VPN, WLAN, Interconnect) abarbeiten und am Ende Maßnahmen priorisieren und verifizieren. Ziel ist, Voice und Video stabil zu bekommen, ohne Nebenwirkungen wie Premium-Inflation oder Starvation zu erzeugen.
Symptome richtig einordnen: Was „knacken“ und „ruckeln“ technisch bedeuten
Bevor Sie messen, müssen Sie verstehen, was das Symptom wahrscheinlich ist. Das spart Zeit und verhindert falsche Maßnahmen.
- Voice knackt, robotisch, Silben fehlen: meist Jitterspitzen, Drop-Cluster, Policer-Drops oder Late Loss durch Bufferbloat.
- Voice verzögert, Echo wirkt stärker: hohe One-Way-Delay oder zu große Puffer (Bufferbloat), oft am Upstream.
- Video ruckelt, Freezes, Qualität pendelt: instabile Throughput-Fenster, Drop-Cluster, Microbursts, ABR-Downshifts (bei TCP/QUIC) oder Loss/Jitter (bei WebRTC/UDP).
- Nur einseitiges Audio: NAT/Firewall, SIP/SDP/ICE, MTU/PMTUD, falsches RTP-Pinning oder asymmetrisches Routing.
- Probleme nur in Busy Hour: Engpass/Congestion, falsche Queue-Gewichte, fehlendes Shaping, Premium-Inflation.
Praxisregel: Wenn Symptome sporadisch sind und „kurz“ auftreten, denken Sie an Microbursts und Perzentile. Wenn Symptome „nur bei Upload“ auftreten, denken Sie zuerst an Upstream-Shaping und Bufferbloat.
Schritt 0: Minimaldaten sammeln – ohne die geht Troubleshooting in Schleifen
Auch ohne lange Rückfragen können Sie strukturiert starten. Sammeln Sie, was in jedem Fall hilfreich ist:
- Zeitfenster: wann genau tritt es auf (Start/Ende, Busy Hour, wiederkehrend)?
- Richtung: Uplink, Downlink oder beides?
- Pfad: Standorte, VPN ja/nein, WLAN ja/nein, Provider/Interconnect ja/nein.
- Diensttyp: VoIP/IMS (RTP), WebRTC-Meeting, Streaming (TCP/QUIC), IPTV (Multicast).
- Klasse/Markierung: welche DSCP/CoS-Werte sind vorgesehen (Voice/EF, Video/AF, Control)?
Wenn Sie diese fünf Punkte haben, vermeiden Sie 80 % der typischen Diagnoseirrtümer.
Schritt 1: Dienstsicht verifizieren – ist es wirklich Loss oder Jitter?
Starten Sie mit dienstnahen KPIs, wenn verfügbar, denn sie bestätigen, dass es nicht nur „gefühlte“ Qualität ist.
- Voice: RTP/RTCP Jitter, RTP Loss, MOS/R-Faktor, Jitter-Buffer Events (Late Loss), Call Setup Time.
- WebRTC/UC Video: Packet Loss, Jitter, Frame Drops, Freeze Events, Bitrate Switching.
- Streaming (TCP/QUIC): Retransmits, RTT/RTT-Variabilität, Throughput-Perzentile, Rebuffer Events.
Interpretationshilfe: Wenn MOS fällt, aber keine Drops sichtbar sind, ist oft Bufferbloat (Queueing Delay) schuld. Wenn Loss steigt und gleichzeitig Queue-Drops steigen, ist Congestion wahrscheinlich.
Schritt 2: Markierung und Klassifizierung prüfen – QoS wirkt nur, wenn Traffic richtig einsortiert wird
Sehr viele QoS-Probleme sind nicht „QoS ist falsch“, sondern „QoS greift nicht“. Prüfen Sie daher zuerst die Klassenintegrität.
- DSCP/CoS-Verteilung: ist Voice wirklich EF? Ist Video wirklich in der Video-Klasse?
- Classify-Hits: sehen Ihre Policies überhaupt Treffer in den erwarteten Klassen?
- Remarking: werden Kundemarkierungen normalisiert? Wird Überschuss herabgestuft?
- Trust Boundary: darf ein Endpoint alles markieren? Premium-Inflation ist ein häufiger Voice-Killer.
- Tunnel/Overlay: ist Outer-DSCP korrekt? Inneres DSCP ist im Underlay oft unsichtbar.
Schneller Reality-Check: Wenn EF-Volumen ungewöhnlich hoch ist, stimmt die Governance nicht. Wenn EF-Volumen „zu niedrig“ ist, stimmt das Mapping nicht.
Schritt 3: Engpasssegment bestimmen – Access, Metro, Core oder NNI?
Ende-zu-Ende ist zu grob. Segmentieren Sie den Pfad in Abschnitte und suchen Sie, wo die Qualität kippt.
- Access/Edge: CPE, Firewall, VPN-Gateway, WLAN, Last-Mile. Häufigster Ort für Bufferbloat und Policer-Drops.
- Aggregation/Metro: CoS-Queuing, Ring-Überbuchung, Microbursts durch Aggregation.
- Core: seltener Engpass, aber möglich bei falschen TC-Mappings oder außergewöhnlichen Peaks.
- NNI/Interconnect: Kapazitätspeaks, Markierungsneutralisierung, SLA-Grenzen.
Praktisch: Nutzen Sie aktive UDP-Probes pro Klasse zwischen Messpunkten oder vergleichen Sie Queue-/Drop-Metriken an den jeweiligen Übergängen im Zeitfenster des Incidents.
Schritt 4: Queueing prüfen – Jitter kommt fast immer aus Warteschlangen
Wenn Voice knackt oder Video ruckelt, ist Queueing Delay häufig der erste sichtbare Vorläufer. Prüfen Sie pro betroffener Schnittstelle und pro Klasse:
- Queue Depth: wächst die Queue im Incident-Zeitfenster?
- Queueing Delay: steigen Peaks oder 95./99. Perzentile?
- Scheduler Share: bekommt Voice wirklich priorisierte Sendezeit? Werden Gewichte eingehalten?
- LLQ-Status: ist die Voice-LLQ „sauber“ (klein) oder steht sie voll?
Interpretationshilfe: Eine Voice-LLQ sollte fast immer sehr niedrige Queueing Delay zeigen. Wenn die Voice-Queue signifikant wächst, ist entweder das Limit zu eng, die Klasse zu groß (Fehlmarkierung) oder der Engpass wird falsch geshaped.
Schritt 5: Drops unterscheiden – Queue Drops, Policer Drops, PHY Drops
Drops sind nicht gleich Drops. Ihre Fix-Maßnahme hängt davon ab, wo und warum gedroppt wird.
Queue Drops (Congestion)
- Indikator: Queue Depth steigt, dann Tail Drops oder Early Drops.
- Fix: Shaping, Queue-Limits/Weights anpassen, Kapazität erhöhen, Microburst-Handling verbessern.
Policer Drops (Profil zu hart)
- Indikator: Policer Exceed/Violate und Drops, oft ohne große Queueing Delay-Anstiege.
- Fix: Burst/CIR anpassen, für Echtzeit Remarking statt Drop, Shaping vor Policer, Voice-Profil größer dimensionieren.
PHY-/Hardware Drops
- Indikator: CRC/FEC/Input Errors, Discards außerhalb QoS, Link Flaps.
- Fix: Optik/Port/Medium prüfen, FEC/Signalqualität, Duplex/Speed, Microwave-Parameter.
Late Loss (Delay statt Drop)
- Indikator: MOS fällt, Jitter-Buffer wächst, wenig echte Drops, aber hohe Queueing Delay-Perzentile.
- Fix: Bufferbloat bekämpfen (Upstream-Shaping), BE-Queue-Limits kontrollieren, Echtzeit aus dem Shaper priorisieren.
Schritt 6: Upstream-Shaping prüfen – der häufigste Sofort-Fix im Feld
Wenn Probleme vor allem bei Upload-Last auftreten oder in Filialen/Homeoffice/Last-Mile-Szenarien, ist Upstream-Shaping fast immer die wichtigste Stellschraube. Prüfen Sie:
- Gibt es Shaping am WAN-Egress? Wenn nein, entsteht Bufferbloat oft im Modem/CPE.
- Ist die Shaping-Rate realistisch? Sie sollte knapp unter der realen Linkrate liegen, sonst droppen Downstream-Profile oder Modems.
- Ist Voice aus dem Shaper priorisiert? LLQ muss innerhalb/oberhalb des Shapers so wirken, dass Audio minimal wartet.
- Shaper-Queueing: ist der Shaper permanent voll (Dauerstau) oder glättet er nur Peaks?
Wenn Shaping fehlt, ist es oft sinnvoller, zuerst Shaping einzuführen, statt an DSCP-Werten oder Codecs zu drehen.
Schritt 7: Sonderfall VPN/Tunnel – Outer-DSCP, MTU und CPU-Jitter
„Nur über VPN schlecht“ ist ein Klassiker. Hier sind drei Ursachen besonders häufig:
- Outer-DSCP fehlt: Underlay queued Best Effort, obwohl inneres DSCP korrekt ist. Fix: kontrolliertes DSCP-Copy/Mapping in den Outer-Header.
- MTU/Fragmentierung: Tunnel-Overhead erzeugt Fragmentverlust oder PMTUD-Blackholes. Fix: MTU Headroom, PMTUD ermöglichen, Fragmentierung vermeiden.
- CPU/Slowpath: VPN-Gateway/Firewall unter Last erzeugt Jitter, selbst wenn Links frei sind. Fix: Kapazität, Offload, Policy-Optimierung, Ressourcenreservierung.
Diagnosehinweis: Wenn QoE schlecht ist, aber Interface-Auslastung unauffällig, prüfen Sie CPU/Forwarding-Path und Drops auf Tunnel-Interfaces.
Schritt 8: Sonderfall WLAN – Airtime statt Bandbreite
Wenn Voice/Video nur über WLAN schlecht ist, sind die Ursachen oft RF/Airtime-basiert, nicht WAN-basiert:
- Retry Rate und Airtime Utilization: hohe Retransmissions erhöhen Jitter und Loss.
- WMM Mapping: Voice muss in WMM-Voice (AC_VO) landen; sonst konkurriert es mit Best Effort.
- Roaming Events: kurze Unterbrechungen erzeugen hörbare Aussetzer.
QoS im Core kann WLAN-Airtime-Probleme nicht kompensieren. Hier ist RF-Design Teil des Troubleshootings.
Schritt 9: Interconnect/Peering/Cloud – wenn die Domäne endet
Wenn Dienste zu Cloud-UC oder Partnernetzen laufen, ist DSCP nicht überall garantiert. Dann müssen Sie sauber zwischen „innerhalb der kontrollierten Domäne“ und „außerhalb“ trennen:
- NNI-Messpunkte: aktive Probes bis zur NNI zeigen, ob Probleme vorher entstehen.
- Kapazität und Pfad: Congestion an Interconnects wirkt wie QoS-Problem, ist aber Kapazitäts-/Peering-Thema.
- SLA-Grenzen: definieren, bis wohin QoS gilt; für strenge SLAs ggf. private Interconnects.
Wenn Probleme nur zu bestimmten Zielen auftreten, ist Pfaddiversität/Peering oft der Hebel, nicht das interne QoS.
Quick Wins vs. strukturelle Fixes: Welche Maßnahmen zuerst?
Ein guter Guide priorisiert Maßnahmen nach Wirkung und Risiko.
Quick Wins (niedriges Risiko, hohe Wirkung)
- Markierungsprüfung und Trust Boundary: Fehlmarkierung eliminieren, Premium-Inflation stoppen.
- Upstream-Shaping aktivieren/anpassen: Bufferbloat reduzieren, Bursts glätten.
- LLQ-Limit prüfen: nicht zu eng, aber strikt begrenzt; Voice-Queue-Limits klein halten.
- Outer-DSCP in Tunneln korrigieren: QoS sichtbar machen.
Strukturelle Fixes (höherer Aufwand, nachhaltige Stabilität)
- QoS-Klassenmodell vereinheitlichen: Voice/Video/Control/BE sauber trennen, Mapping über Domänen standardisieren.
- Congestion Avoidance für BE/Streaming: Tail Drop reduzieren, Throughput-Wellen glätten.
- Kapazitätsplanung: Engpässe erkennen und rechtzeitig ausbauen.
- Monitoring hochauflösend: Sekundenfenster, Perzentile, Drops pro Klasse, Policer-Hits.
Fehlersignaturen: Schnelle Zuordnung ohne langes Rätseln
- Voice-Drops in EF: Premium-Inflation oder LLQ-Limit zu eng oder falsches Mapping → Trust Boundary/Limit/Mappings prüfen.
- Keine Drops, aber hohe Voice-Delay-Perzentile: Bufferbloat → Upstream-Shaping/Queue-Limits.
- Policer-Drops korrelieren mit Knacken: Burst-Parameter/CIR zu hart → Shaping/Remarking/Burst anpassen.
- Nur VPN betroffen: Outer-DSCP/MTU/CPU → Tunnel-Mapping/MTU/Performance.
- Nur WLAN betroffen: Airtime/WMM/Roaming → RF/WMM/Client-Optimierung.
- Nur bestimmte Ziele: Interconnect/Peering → NNI-Messung/Kapazität/Pfad.
Runbook-Checkliste: In welcher Reihenfolge arbeiten?
- Dienst bestätigen: RTP/RTCP Jitter/Loss, MOS, Video Freeze/Bitrate Switching.
- Klasse prüfen: DSCP/CoS/TC-Verteilung, Classify-Hits, Remarking.
- Segment eingrenzen: Access/Metro/Core/NNI, aktive Probes pro Klasse, Messpunkte.
- Queueing prüfen: Queue Depth/Delay pro Klasse, Perzentile und Peaks.
- Drops klassifizieren: Queue vs. Policer vs. PHY vs. MTU/Late Loss.
- Engpass fixen: Shaping, Limits/Gewichte, Trust Boundary, MTU, Outer-DSCP.
- Verifizieren: Vor/Nach-Messung, Perzentile, kurze Fenster, QoE-KPIs.
Häufige Fragen beim QoS-Troubleshooting
Warum wird Voice manchmal schlechter, nachdem „mehr QoS“ aktiviert wurde?
Weil Premium-Inflation entsteht: zu viel Traffic landet in der höchsten Klasse (EF/LLQ), die Queue wird dauerhaft gefüllt, andere Klassen verhungern, und in manchen Geräten steigt sogar der Jitter durch Scheduling/CPU-Last. QoS muss streng begrenzt und durch Trust Boundaries geschützt werden.
Warum hilft es selten, den Codec zu ändern?
Weil die meisten hörbaren Probleme aus Jitter, Drop-Clustern oder Bufferbloat stammen. Ein anderer Codec kann etwas kaschieren, aber er behebt keine Queue-Drops oder MTU-Blackholes. Erst Netzstabilität herstellen, dann Codec optimieren.
Was ist der wichtigste Indikator, den ich sofort prüfen sollte?
Queueing Delay und Drops in der Voice-Klasse (EF/LLQ) im Incident-Zeitfenster. Wenn EF Drops zeigt, ist das ein Incident. Wenn EF Delay-Perzentile stark steigen, ist Bufferbloat oder Engpass-Queueing wahrscheinlich – selbst ohne sichtbare Drops.
