Site icon bintorosoft.com

QoS-Policy Verifikation: Prüfen, ob Klassen wirklich greifen

Red Snapper

QoS-Policy Verifikation ist der Schritt, der aus einer „konfigurierten“ QoS-Strategie eine nachweisbar wirksame Servicequalität macht. In der Praxis scheitern QoS-Projekte selten daran, dass keine Klassen existieren – sie scheitern daran, dass Klassen nicht überall greifen: DSCP-Markierungen werden an einer Firewall genullt, ein Tunnel kopiert DSCP nicht in den Outer-Header, ein Metro-Switch mappt 802.1p falsch, eine LLQ ist zwar konfiguriert, aber am falschen Interface, oder Class-Maps matchen nicht, weil Ports/Protokolle anders sind als gedacht. Das Ergebnis ist typisch: Auf einem Router sieht die Policy „sauber“ aus, aber Voice knackt trotzdem, Video ruckelt in der Busy Hour, und im Monitoring erscheinen entweder keine Treffer in den Premiumklassen oder Premium-Inflation bläht EF/LLQ so stark auf, dass das Netz instabil wird. Professionelle QoS-Policy Verifikation bedeutet daher: systematisch prüfen, ob (1) Markierungen korrekt ankommen, (2) Klassifizierung wirklich matcht, (3) Queues/Scheduler tatsächlich wie geplant arbeiten, (4) Profile und Shaper/Policer keine Echtzeitpakete zerstören, und (5) das Ganze end-to-end über alle Domänen (Access, Metro, Core, Interconnect, VPN) kohärent ist. Dieser Artikel liefert ein praxisnahes Prüfverfahren, das Sie als Runbook nutzen können – inklusive typischer Fehlersignaturen und konkreter Checks, um sicherzustellen, dass QoS-Klassen wirklich greifen.

Was bedeutet „QoS greift“ überhaupt?

„QoS greift“ ist mehr als ein grüner Konfigurationsstatus. In einem belastbaren Betrieb meint es drei Dinge gleichzeitig:

Verifikation muss alle drei Ebenen abdecken. Wenn Sie nur Konfiguration prüfen, übersehen Sie Effektprobleme. Wenn Sie nur QoE prüfen, fehlt die Ursache.

Die häufigsten Gründe, warum Klassen nicht greifen

Bevor Sie prüfen, lohnt eine mentale „Fehlerlandkarte“. Die meisten QoS-Verifikationsfehler fallen in wenige Muster:

Ein gutes Runbook sucht diese Muster gezielt ab, statt „random“ auf Geräten zu klicken.

Verifikationsprinzip: In fünf Ebenen prüfen

Ein praxistauglicher Ablauf für QoS-Policy Verifikation lässt sich in fünf Ebenen gliedern. Jede Ebene beantwortet eine klare Frage:

Wenn Sie diese Reihenfolge einhalten, vermeiden Sie den Klassiker: QoE ist schlecht, Sie ändern Gewichte – obwohl die Klasse gar nicht matched.

Ebene 1: Markierung verifizieren (DSCP, CoS, MPLS-TC, Outer-Header)

Die Markierung ist die „Sprache“, in der QoS arbeitet. Verifikation beginnt daher mit der Frage: Trägt der Traffic die erwarteten Marker an den relevanten Punkten?

Typische Fehlersignatur: Voice ist am Endgerät EF, am Provider-Edge aber DSCP 0. Dann ist jedes weitere QoS-Tuning sinnlos, bis die Markierungskette geschlossen ist.

Ebene 2: Klassifizierung verifizieren (Classify-Hits statt Annahmen)

Die wichtigste Verifikationsmetrik heißt: Treffer. Wenn eine Class-Map keine Hits hat, greift sie nicht – egal wie schön sie konfiguriert ist.

Typische Fehlersignatur: „Voice knackt, aber EF hat 0 Hits.“ Das ist fast immer ein Match- oder Markierungsproblem, nicht ein Bandbreitenproblem.

Ebene 3: Queue- und Scheduler-Wirkung verifizieren

Wenn Markierung und Match stimmen, ist die nächste Frage: Tut der Scheduler das Richtige? Hier sind drei Messgrößen Pflicht: Queueing Delay, Drops und Service Share.

Typische Fehlersignatur: Voice-Klasse hat Hits, aber Queueing Delay-Peaks steigen stark. Das deutet auf fehlendes Shaping am Upstream, falsche Interface-Richtung oder überfüllte Premiumklasse (Inflation) hin.

Ebene 4: Policer, Shaper und Remarking verifizieren

Viele QoS-Designs scheitern nicht in den Queues, sondern an Profilen. Policer schneiden Bursts hart ab, Shaper glätten, Remarking verschiebt Überschuss. Verifikation bedeutet: Sie müssen sehen, ob Profile „sauber“ arbeiten.

Typische Fehlersignatur: Keine Queue-Drops, aber Policer-Drops auf Video oder sogar Voice. Dann ist der Policer der Engpass – nicht die Queue.

Ebene 5: End-to-End Verifikation über Domänen und Übergänge

QoS ist nur so gut wie das schwächste Segment. Deshalb müssen Sie die Übergänge prüfen, an denen QoS-„Sprachen“ wechseln:

Hier entstehen die typischen „QoS-Löcher“: Alles ist korrekt markiert, aber ein Segment queued nach einem anderen Feld oder verliert Markierungen.

Verifikation mit synthetischem Traffic: Klassen gezielt „auslösen“

Wenn Sie Verifikation ohne echten Diensttraffic brauchen oder wenn Sie sicherstellen wollen, dass jede Klasse messbar greift, sind synthetische Tests sinnvoll. Die Idee: Erzeugen Sie pro Klasse einen kleinen, kontrollierten Teststrom.

Wichtig: Tests müssen klein sein, damit sie das Netz nicht selbst belasten. Ziel ist Verifikation der Behandlung, nicht Lasttest.

Premium-Inflation erkennen: Wenn „zu viel“ in den richtigen Klassen landet

Eine besonders gefährliche Fehlersignatur ist Premium-Inflation: Die Klassen greifen technisch, aber zu viele Flows landen in Premium. Dann wird Voice paradox schlechter, obwohl EF aktiv ist.

Fix-Logik: Trust Boundary schärfen, DSCP-Whitelist, Profilierung pro Kunde/Standort, Video strikt aus EF entfernen, LLQ-Limit korrekt setzen.

Typische Verifikationsfehler: Warum viele Checks „falsch grün“ sind

Runbook: QoS-Policy Verifikation in 12 Checks

Diese Reihenfolge ist bewusst so gewählt, dass Sie erst Semantik, dann Mechanik, dann Wirkung verifizieren.

Praktische Verifikation pro Serviceprofil: Voice, Video, Signaling, Best Effort

Häufige Fragen zur QoS-Policy Verifikation

Woran erkenne ich am schnellsten, dass Klassen nicht greifen?

An Classify-Hits und DSCP-Verteilungen. Wenn eine Klasse erwartet wird, aber 0 Hits hat, oder wenn DSCP am Egress nicht mehr dem Ingress entspricht, ist die Verifikationsdiagnose klar: Markierung oder Match stimmt nicht.

Warum kann Voice trotz EF/LLQ schlechter werden?

Meist wegen Premium-Inflation oder fehlendem Shaping am Engpass. Wenn zu viel Traffic in EF landet oder wenn Bufferbloat im Upstream entsteht, steigen Queueing Delay-Spitzen und Drops – Voice knackt trotz „richtiger“ Markierung.

Wie verifiziere ich QoS ohne echten Voice/Video-Traffic?

Mit kleinen, DSCP-markierten synthetischen Streams pro Klasse (Voice-ähnlicher UDP-Stream für EF, Video-ähnlicher Stream für AF, Control-Stream) plus Telemetrie (Hits, Queueing Delay, Drops, Policer/Shaper). So sehen Sie, ob das Netz die Klassen wie geplant behandelt, ohne Produktivtraffic zu benötigen.

Exit mobile version