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:
- Kein Match: Der Classifier trifft nicht – Traffic landet in Default/Best Effort.
- Match ja, Wirkung nein: Packets werden gezählt, aber Scheduling/Queueing passiert nicht wie erwartet.
- Wirkung lokal, aber nicht end-to-end: Auf einem Gerät stimmt es, auf dem nächsten geht Marking/Mapping verloren.
- Falsche Richtung: Policy ist auf Ingress gebunden, das Problem ist aber Egress-Congestion (oder umgekehrt).
- Falscher Pfad: Der produktive Traffic nimmt einen anderen Pfad (SD-WAN-Steering, ECMP, NAT, WebRTC-Fallback).
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“.
- Symptom: Was war schlecht? (RTP Loss/Jitter, MOS-Abfall, Video-Freeze, Setup-Delay)
- Zeitfenster: Wann genau? (Sekunden/Minuten, nicht Tagesmittelwerte)
- Pfad: Welche Geräte/Interfaces sind wirklich beteiligt?
- Classifier: Landet der Traffic in der erwarteten Klasse?
- Queue: Landet die Klasse in der erwarteten Hardware-Queue?
- Scheduling: Werden die Pakete priorisiert/geshaped wie geplant?
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.
- Standort-Exit: Geht der Traffic wirklich über den erwarteten WAN-/Internet-Uplink?
- Overlay vs. Underlay: Läuft RTP im IPsec/SD-WAN-Tunnel oder direkt?
- Transport-Fallback: UDP vs. TCP/TLS – besonders bei WebRTC/Zoom/Teams relevant.
- Asymmetrie: Hin- und Rückweg können unterschiedlich sein; QoS muss pro Richtung passen.
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?
- Endgerät: Setzt das Endpoint überhaupt DSCP? (IP-Phone vs. Softphone auf PC)
- Access-Switch/AP: Wird DSCP trusted oder auf 0 gesetzt?
- Security/Tunnel: Bleibt DSCP erhalten oder wird beim Encapsulation verloren?
- Provider-Edge: Werden Markierungen neutralisiert, insbesondere bei Best-Effort-Internet?
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:
- Matched Packets/Bytes pro Klasse: Steigt die Voice/Media-Klasse, wenn Calls/Meetings laufen?
- Default/Unmatched: Wächst die Default-Class, obwohl Echtzeitverkehr aktiv ist?
- Re-Marking Counter: Werden Pakete ummarkiert, bevor sie klassifiziert werden?
- ACL-basierte Klassen: Stimmen Ports/IPs noch, oder hat die Anwendung ihr Verhalten geändert?
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.
- Egress-Symptom: Queue Delay/Depth steigt, Tail Drops treten auf – Egress-Scheduling ist relevant.
- Ingress-Symptom: Policer Drops, ACL Drops, Input Drops – Ingress-Mechanismen sind relevant.
- Fehlerbild: Policy ist auf dem LAN-Interface gebunden, der Engpass ist aber WAN-Egress.
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.
- Queue-Mapping prüfen: Welche DSCP-Werte landen in welcher Queue?
- Queue-Stats pro Klasse: Gibt es Queue Depth/Delay/Drops in der erwarteten Voice/Media-Queue?
- Plattformbesonderheiten: Manche Geräte haben feste Queue-Anzahlen oder eingeschränkte Scheduling-Modelle.
- CoS/DSCP Interworking: Trunking (802.1p) und DSCP können unterschiedlich gemappt sein.
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.
- LLQ-Größe: Voice braucht Schutz, aber die Priority-Queue sollte begrenzt bleiben.
- Garantie für Media: Video/Sharing brauchen eine eigene Klasse, nicht „irgendwo“ im Best Effort.
- Shaping am Uplink: Ohne Shaping passiert Congestion im Modem/Provider-Buffer, nicht in Ihren Queues.
- Policer vermeiden: Auf Echtzeit sind harte Policers oft die Ursache für Loss.
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.
- Tail Drop: Queue voll → Bandbreite/Queueing/Shaping/Traffic-Mix prüfen.
- Policer Drop: Rate überschritten → Policer entschärfen, Burst-Toleranz erhöhen, Shaping nutzen.
- WRED Drop: Policy prüfen → Echtzeitklassen nicht mit WRED behandeln.
- Buffer Exhaustion: Microbursts/Shared Buffer → Peak Queue Depth, Encapsulation, Port-Speed-Mismatch.
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.
- Delay hoch + Jitter hoch: Bufferbloat/Congestion wahrscheinlich.
- Drops hoch + Loss hoch: Paketverlust ist real und klassenspezifisch lokalisierbar.
- QoE schlecht, QoS „grün“: Pfad falsch, Messpunkt falsch oder Mis-Marking (Traffic läuft nicht in der Klasse).
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.
- Softphone auf PC: DSCP wird nicht gesetzt oder am Switch nicht trusted → Voice läuft in Best Effort.
- SD-WAN Overlays: DSCP wird nicht auf Outer Header kopiert → Provider sieht Best Effort.
- WebRTC Fallback: Medien laufen über TCP/TLS/443 → Port-/App-Klassifizierung greift nicht mehr.
- WAN ohne Shaping: Congestion passiert im Modem → Router-Queues bleiben „leer“, QoS wirkt nicht.
- Policer auf Voice: Token-Bucket zu klein → sporadische Drops, obwohl Link nicht voll ist.
- Inkonsequentes Mapping: Access markiert, Core/WAN mappt anders → Klasse ändert sich unterwegs.
Eine praktische Debug-Checkliste: In 15 Minuten zur Hypothese
- Zeitfenster: Wann genau war der Vorfall? (Sekunden/Minuten)
- Pfad: Welcher Exit/Underlay wurde genutzt? (SD-WAN, VPN, Internet-Breakout)
- Marking: Ist DSCP am Probleminterface vorhanden?
- Classifier: Steigen Hits in der erwarteten Klasse, oder wächst Default/Unmatched?
- Queue: Gibt es Queue Delay/Depth in der erwarteten Queue?
- Drops: Gibt es Per-Class Drops in Voice/Media?
- Reasons: Tail Drop vs. Policer Drop vs. Buffer Exhaustion?
- Shaping: Ist Uplink-Shaping aktiv und korrekt gesetzt?
- Service-Korrelation: Stimmen RTP/MOS/RTC-Metriken zeitlich mit Queue/Drops überein?
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.
- Classifier Drift Alerts: Default/Unmatched-Anteil steigt vs. Baseline.
- Re-Marking Alerts: DSCP wird ungewöhnlich oft zurückgesetzt.
- Policer Guardrail: Policer Drops in Voice/Media sofort eskalieren.
- Queue Early Warning: Voice/Media Queue Delay 95p/99p als Frühindikator.
- Change Overlay: Konfigurationsänderungen im Monitoring markieren.
