Site icon bintorosoft.com

QoS-Troubleshooting Guide: Wenn Voice knackt und Video ruckelt

Red Snapper

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.

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:

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.

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.

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.

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:

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)

Policer Drops (Profil zu hart)

PHY-/Hardware Drops

Late Loss (Delay statt Drop)

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:

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:

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:

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:

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)

Strukturelle Fixes (höherer Aufwand, nachhaltige Stabilität)

Fehlersignaturen: Schnelle Zuordnung ohne langes Rätseln

Runbook-Checkliste: In welcher Reihenfolge arbeiten?

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.

Exit mobile version