Site icon bintorosoft.com

Troubleshooting QoS: “Policy greift nicht” systematisch debuggen

Red Snapper

Troubleshooting QoS mit der Diagnose „Policy greift nicht“ gehört zu den häufigsten und frustrierendsten Situationen im Netzwerkbetrieb. Auf dem Papier ist alles sauber: DSCP ist definiert, Queues sind konfiguriert, Bandbreiten reserviert, vielleicht gibt es sogar schöne Dashboards. Und trotzdem stottert Voice, Video friert ein oder ein Standort kippt bei Last. In der Praxis steckt hinter „Policy greift nicht“ fast immer eine von wenigen Ursachenklassen: Traffic wird nicht korrekt klassifiziert (falsches Matching), Markierungen gehen unterwegs verloren (Trust Boundary/Rewrite), die Policy ist am falschen Interface oder in der falschen Richtung gebunden (Ingress vs. Egress), Hardware-Queues werden nicht wie erwartet gemappt (ASIC/Platform-Quirks), oder ein Shaper/Policer beeinflusst den Verkehr anders als gedacht. Der Schlüssel ist eine systematische Debug-Methodik, die nicht mit „noch mehr Regeln“ beginnt, sondern mit Beweisen: Welche Pakete kommen wo an, mit welchen Markierungen, in welcher Klasse, in welcher Queue – und was passiert dann mit ihnen? Dieser Artikel zeigt einen praxistauglichen Schritt-für-Schritt-Ansatz, um QoS-Policies zuverlässig zu debuggen, typische Fallstricke zu erkennen und schnell zu einer belastbaren Ursache zu kommen.

Was „Policy greift nicht“ technisch bedeuten kann

Bevor Sie debuggen, sollten Sie den Satz präzisieren – nicht durch Rückfragen, sondern durch ein klares internes Modell. „Policy greift nicht“ kann mindestens fünf Dinge bedeuten:

Diese Einordnung verhindert, dass Sie stundenlang an Regeln drehen, obwohl die Policy schlicht am falschen Ort sitzt.

Das Debug-Prinzip: Von außen nach innen – und vom Symptom zur Queue

Ein robustes Troubleshooting folgt einer Kette, die Sie immer wieder nutzen können: (1) Symptom und Zeitfenster, (2) betroffener Pfad, (3) Traffic-Klassifizierung, (4) Queue-Mapping und Scheduler, (5) Drops/Delay und Gründe. Wenn Sie diese Reihenfolge einhalten, vermeiden Sie typische Sackgassen wie „wir haben doch DSCP EF, also muss es stimmen“.

Schritt 1: Den echten Pfad verifizieren

Viele QoS-Debugs scheitern, weil das Team die falsche Strecke untersucht. Moderne Netze sind dynamisch: SD-WAN kann Underlays wechseln, ECMP kann Flows verteilen, WebRTC kann von UDP auf TCP/TLS fallbacken, und Internet-Breakouts können standortabhängig sein. QoS wirkt nur dort, wo der Traffic tatsächlich läuft. Deshalb ist der erste Schritt immer: Pfadidentität.

Schritt 2: Trust Boundary prüfen – Markierung ist kein Naturgesetz

QoS setzt fast immer auf Markierungen (DSCP/CoS). „Policy greift nicht“ bedeutet häufig: Die Markierung ist am entscheidenden Punkt nicht vorhanden oder wurde umgeschrieben. Darum ist die Trust Boundary der Kern jeder Analyse: Wo wird DSCP akzeptiert, wo wird es neu gesetzt, und wo wird es zurückgesetzt?

Typischer Klassiker: DSCP stimmt am LAN, ist aber am WAN-Edge weg

Wenn der LAN-Switch korrekt matcht, aber der WAN-Router alles als Best Effort sieht, liegt die Ursache oft in einem Übergang: Firewall setzt DSCP zurück, Tunnel kopiert DSCP nicht, oder ein Zwischenrouter hat ein anderes DSCP->CoS Mapping. In diesem Fall „greift“ die WAN-Policy nicht, weil sie nie das erwartete Marking sieht.

Schritt 3: Classifier-Hits – zuerst beweisen, dass ein Match stattfindet

Bevor Sie über Queues, LLQ oder Bandbreitenreservierung diskutieren, müssen Sie belegen, dass der Traffic überhaupt in der gewünschten Klasse matched. Das ist die wichtigste Debug-Regel: Ohne Classifier-Hits ist jede QoS-Policy nur Deko. Prüfen Sie daher pro relevantem Interface:

Wenn die Voice-Klasse „0“ bleibt, ist die Diagnose klar: Der Classifier trifft nicht, oder die Markierung ist nicht vorhanden.

Schritt 4: Ingress vs. Egress – QoS am richtigen Ort anwenden

QoS-Policies werden oft in der falschen Richtung implementiert. Congestion entsteht in der Regel beim Senden (Egress), weil dort entschieden wird, welcher Traffic wann auf den Link darf. Ingress-QoS ist sinnvoll für Markierung, Policing und Schutz der internen Ressourcen, löst aber selten ein Egress-Congestion-Problem. Wenn „Policy greift nicht“ bedeutet, dass Echtzeit trotz Priorität leidet, ist häufig die Egress-Policy am Engpassinterface entscheidend.

Schritt 5: DSCP->Queue Mapping – wenn die Klasse nicht in der richtigen Hardware-Queue landet

Selbst wenn Classifier-Hits stimmen, kann die Wirkung ausbleiben, wenn das Mapping auf Hardware-Queues falsch ist. Viele Plattformen unterscheiden zwischen „Policy-Klassen“ (logisch) und „Egress-Queues“ (physisch). Ein DSCP-Wert kann in einer Policy als „Voice“ gematcht werden, aber am ASIC in einer anderen Queue landen, wenn das Mapping nicht konsistent ist oder wenn ein Default-Template greift.

Schritt 6: Scheduling und Bandbreitenparameter – wenn „Priorität“ falsch verstanden wird

Viele Policies sehen korrekt aus, aber ihre Parameter sind praktisch unwirksam. Beispiele: Eine LLQ ist so klein, dass sie unter Last sofort dropt, oder eine Media-Klasse hat keine garantierte Bandbreite und wird von Best Effort verdrängt. Umgekehrt kann eine zu große Priority-Queue andere Klassen verhungern lassen, was Nebenwirkungen erzeugt und Debugging erschwert. Entscheidend ist, Bandbreiten und Limits in Relation zur realen Last zu sehen – und nicht nur als Prozentzahlen in einer Konfiguration.

Shaping ist oft der missing link

Wenn die Policy scheinbar „nicht greift“, obwohl Classifier und Queue stimmen, liegt die Ursache häufig darin, dass Congestion nicht in Ihrem Gerät stattfindet, sondern dahinter – z. B. im Provider-Access oder im CPE-Puffer. Durch Shaping knapp unter Realrate holen Sie Congestion in Ihre kontrollierten Queues zurück, und erst dann kann Scheduling wirken.

Schritt 7: Drop Reasons – die schnellste Abkürzung zur Ursache

Wenn Sie Drops sehen, müssen Sie wissen, warum. Tail Drops bedeuten Congestion in einer Queue. Policer Drops bedeuten Rate Limit. WRED Drops bedeuten bewusstes frühes Dropping (meist für TCP). Buffer Exhaustion bedeutet Plattform-/Microburst-Themen. Policy Drops bedeuten Filterung. Diese Gründe sind nicht nur „nice“, sondern oft die schnellste Route zur Root Cause.

Schritt 8: Service-Korrelation – beweisen, dass QoS-Fehler die Nutzer trifft

QoS-Debugging ist am stärksten, wenn Sie Netztelemetry mit Service-KPIs koppeln. Für Voice sind RTP-Sequenzlücken, RTCP-Jitter, MOS-Trends und Bad-Call-Rate hilfreich. Für Video/RTC sind Jitter/Loss/RTT sowie Freeze/Downshift-Indikatoren relevant. Wenn diese Werte zeitlich mit Queue Delay/Drops korrelieren, ist der Nachweis belastbar – und die Fixpriorisierung klar.

Typische Szenarien: „Policy greift nicht“ in der Praxis

Bestimmte Fälle kommen immer wieder vor. Wenn Sie diese Muster kennen, verkürzt das Debugging drastisch.

Eine praktische Debug-Checkliste: In 15 Minuten zur Hypothese

Stabiler machen als debuggen: Guardrails gegen „Policy greift nicht“

Viele Teams debuggen wiederkehrend dieselben Muster. Guardrails machen solche Fehler früh sichtbar: Alerts auf Default/Unmatched-Drift, Re-Marking-Events, Policer Drops in Echtzeitklassen (als „Never Event“) und Queue Delay Peaks am WAN-Uplink. Kombiniert mit Change-Markern in Zeitreihen erkennen Sie außerdem schnell, ob ein QoS-/Firewall-/SD-WAN-Change die Ursache war.

Exit mobile version