QoS Troubleshooting: Warum greift die Policy nicht?

Wenn QoS „nicht greift“, ist das im Betrieb meist kein einzelner Fehler, sondern eine Kette aus kleinen Unstimmigkeiten: Traffic ist anders markiert als gedacht, Class Maps matchen nicht, die Policy ist am falschen Interface gebunden oder der Engpass liegt an einer Stelle, an der überhaupt keine QoS-Mechanik aktiv ist. Genau deshalb ist QoS Troubleshooting eine eigene Disziplin. Die Frage „Warum greift die Policy nicht?“ lässt sich zuverlässig beantworten, wenn Sie systematisch vorgehen und sich auf messbare Indikatoren verlassen: Counters, Drops, Queue-Statistiken, Interface-Auslastung und Markierungen auf dem Draht. Besonders bei Cisco QoS mit MQC (Class Map, Policy Map, Service Policy) ist die Diagnose gut strukturiert möglich, weil die Plattform in vielen Fällen klar zeigt, welche Klasse Pakete sieht, welche Aktionen angewendet werden und ob Shaping oder Policing aktiv ist. In diesem Leitfaden erhalten Sie ein praxistaugliches Playbook: Sie lernen, wie Sie den tatsächlichen Engpass identifizieren, wie Sie prüfen, ob die Policy wirklich gebunden ist, warum Class Maps oft keine Treffer haben, welche typischen Ursachen bei DSCP/CoS-Markierungen auftreten und wie Sie Fehler schnell eingrenzen, ohne das Netz durch hektische Änderungen instabil zu machen.

Grundidee: QoS wirkt nur am Engpass

Der häufigste Grund, warum QoS scheinbar „nicht greift“, ist simpel: Die Policy ist nicht dort aktiv, wo Congestion entsteht. QoS ist kein globaler Schalter, der überall im Netz „Qualität“ verbessert. Es wirkt nur dort, wo Pakete in Warteschlangen landen, weil ein Ausgangslink weniger Kapazität hat als der angebotene Traffic.

• Typische Engpässe: WAN-Uplink, Internetanschluss, VPN-Tunnel, WLAN-Uplink, überlastete Trunk-Links.
• Typischer Irrtum: QoS ist im Campus konfiguriert, aber der WAN-Link ist der Engpass (oder umgekehrt).
• Konsequenz: Bevor Sie an Class Maps schrauben, klären Sie, wo Congestion wirklich entsteht.

Als Orientierung zu Cisco QoS-Konzepten und typischen Implementierungen ist der Anchor-Text Cisco QoS Übersicht hilfreich.

Schritt 1: Den betroffenen Traffic sauber beschreiben

QoS Troubleshooting scheitert häufig daran, dass der „kritische Traffic“ nicht konkret genug beschrieben ist. Definieren Sie den Flow so präzise wie möglich:

• Welche Anwendung? (VoIP RTP, SIP, Teams/Zoom, VDI, Backup, ERP)
• Quelle und Ziel (Netze, Server, Standorte)
• Protokoll und Ports (TCP/UDP, ggf. dynamische Ports bei RTP)
• Erwartete Markierung (DSCP/CoS) oder erwartete Klassifizierung (ACL/NBAR)
• Wo soll QoS wirken? (WAN-Out, Tunnel, Uplink, Port)

Erst wenn klar ist, welchen Traffic Sie in welcher Klasse erwarten, sind Counter-Aussagen sinnvoll.

Schritt 2: Prüfen, ob die Policy überhaupt aktiv gebunden ist

Der Klassiker: Die Policy ist korrekt gebaut, aber nicht (oder nicht am richtigen Interface) gebunden. Prüfen Sie daher zuerst die Bindung.

Router: Service Policy auf dem Interface prüfen

• show running-config interface <INTERFACE>
• show policy-map interface <INTERFACE>

Wichtige Fragen dabei:

• Ist die Policy output oder input gebunden?
• Ist das Interface wirklich der Engpass (z. B. WAN-Uplink) oder nur ein Transit?
• Sehen Sie die Policy in der Ausgabe von show policy-map interface überhaupt?

Switch: QoS-Policy und Queueing abhängig von Plattform

Bei Switches ist die Darstellung je nach Catalyst-/IOS-XE-Plattform unterschiedlich. Prüfen Sie Port-Profile, Trust-Settings, Queue-Drops und Mappings mit den jeweiligen „show qos“- und „show platform“-Befehlen Ihrer Plattformdokumentation. Ein guter Startpunkt ist der Anchor-Text Cisco QoS Konfigurationsguides.

Schritt 3: Counter lesen lernen – die wichtigste QoS-Diagnose

Bei MQC ist show policy-map interface die zentrale Wahrheit. Sie sehen dort, ob Ihre Klassen Treffer haben, ob Drops passieren, ob Policing aktiv ist und ob Shaping greift (bei Parent/Child-Designs).

Was Sie in der Ausgabe suchen

• Packets/Bytes pro Klasse: Hat die erwartete Klasse überhaupt Treffer?
• Drops: Dropt die Klasse (insbesondere LLQ/priority)?
• Queue depth/queue limit: Bilden sich Warteschlangen?
• Policer-Statistik: conform/exceed (wird gedroppt oder remarkt)?
• Shaping-Statistik: Greift das Shape und ist die Child-Policy aktiv?

Typische Interpretation

• Klasse hat 0 Treffer: Match-Kriterium stimmt nicht (Marking fehlt, ACL falsch, falscher Pfad).
• Nur class-default hat Treffer: Traffic wird nicht klassifiziert oder Marking ist anders als gedacht.
• Klasse hat Treffer, aber keine Drops/Queues: Es gibt vermutlich keine Congestion an diesem Punkt – QoS kann dann „unsichtbar“ wirken.

Schritt 4: Warum matcht die Class Map nicht?

Wenn die Policy gebunden ist, aber die erwartete Klasse keine Treffer hat, liegt der Fehler fast immer in der Klassifizierung. Die typischen Ursachen unterscheiden sich je nach Match-Methode.

Match nach DSCP: Marking ist nicht vorhanden oder wird überschrieben

• Endgerät markiert nicht wie erwartet (z. B. Voice nicht EF).
• Ein Switchport ist untrusted und setzt DSCP zurück (remarking auf default).
• Ein WAN-Edge oder Tunnel kopiert DSCP nicht oder verändert es.
• Der Traffic ist verschlüsselt oder getunnelt, und Sie matchen auf dem „falschen“ Header.

Prüfen Sie in diesem Fall konsequent die Trust Boundary. DSCP ist nur dann zuverlässig, wenn Sie festlegen, wo Markierungen akzeptiert und wo sie neu gesetzt werden. Grundlagen zu DSCP/DiffServ finden Sie im Anchor-Text RFC 2474.

Match per ACL: ACL trifft nicht oder ist zu spezifisch

• Ports sind anders (z. B. SIP-TLS 5061 statt 5060).
• RTP nutzt dynamische Ports; eine „eq“-Regel matcht nicht.
• Quelle/Ziel sind anders (NAT, Load Balancer, Proxy).
• Die Richtung ist vertauscht (Client → Server vs. Server → Client).

Praxis-Tipp: Wenn ACL-Matches zu fragil sind, ist ein Marking-Ansatz am Rand oft robuster: erst markieren, dann nach DSCP klassifizieren.

Match per NBAR: Erkennung ist nicht verfügbar oder nicht aktiv

• NBAR ist nicht auf der Plattform verfügbar oder nicht aktiv.
• Applikation wird aufgrund Verschlüsselung nicht erkannt.
• NBAR-Definitionen sind unvollständig oder zu allgemein.

Schritt 5: Policy greift, aber die Wirkung ist „nicht spürbar“

Ein häufiger Fall: Counter steigen, die Policy matcht, aber die Nutzer merken keine Verbesserung. Das liegt meist daran, dass an der Stelle gar kein Engpass ist oder dass die QoS-Aktion nicht zur Problemursache passt.

• Keine Congestion: Ohne Engpass keine sichtbare Wirkung; QoS zeigt dann vor allem Counters, aber keine Drops.
• Engpass liegt woanders: QoS ist am LAN, aber der WAN-Link dropt; oder QoS ist am WAN, aber WLAN ist überlastet.
• Falsche Maßnahme: Sie priorisieren Voice, aber das Problem ist Packet Loss durch physische Errors, Duplex/Speed-Mismatch oder WLAN-Roaming.

Prüfen Sie deshalb zusätzlich immer die Basics: show interfaces (Errors/Drops), Link-Auslastung, und im WLAN-Fall die Funkmetriken.

Schritt 6: LLQ/Priority Queue korrekt dimensionieren

VoIP- und Echtzeittraffic werden häufig über priority (LLQ) behandelt. Wenn LLQ falsch dimensioniert ist, wirkt QoS „kaputt“ – entweder weil Voice dropt (zu klein) oder weil andere Klassen leiden (zu groß).

Typische Fehlerbilder

• Priority Queue dropt: LLQ-Limit ist zu niedrig oder Marking/Trust erlaubt zu viel Traffic in die LLQ.
• Andere Klassen droppen stark: LLQ ist zu groß oder unlimitiert; Best Effort wird verdrängt.
• Voice klingt trotzdem schlecht: Engpass ist vor dem Router; LLQ kann nicht wirken.

Best Practice: LLQ immer begrenzen (percent oder Rate) und sicherstellen, dass nur „echter“ Voice-Traffic in die LLQ gelangt (saubere Marking-Policy, klare Trust Boundary).

Schritt 7: Shaping fehlt – QoS verliert am WAN

Einer der wichtigsten Gründe für „Policy greift nicht“ am WAN ist fehlendes Shaping. Wenn der Engpass im Modem oder beim Provider liegt, entstehen Drops außerhalb Ihrer Kontrolle. Dann kann die Router-Queueing-Policy (LLQ, bandwidth) nicht sauber wirken.

Symptome für fehlendes Shaping

• Hohe Auslastung, aber in show policy-map interface kaum Queueing-Effekte sichtbar.
• Voice leidet unter Last, obwohl LLQ konfiguriert ist.
• Drops treten „irgendwo“ auf, aber nicht in den erwarteten Klassen.

Praxislösung: Parent/Child mit Shape

Ein bewährtes Muster ist eine Parent-Policy mit shape average, die die Child-Policy enthält. Dadurch wird der Router selbst zum Engpass und kann die Warteschlangen korrekt steuern.

policy-map WAN-CHILD
class VOICE
priority percent 10
class class-default
fair-queue

policy-map WAN-PARENT
class class-default
shape average 50000000
service-policy WAN-CHILD

Die konkrete Rate muss zu Ihrem Link passen; in der Praxis liegt sie oft leicht unter der realen Provider-Rate.

Schritt 8: Markierungen verschwinden unterwegs – DSCP/CoS End-to-End prüfen

Wenn Sie nach DSCP matchen, ist die wichtigste Frage: Ist DSCP dort noch vorhanden, wo Sie matchen? Markierungen können auf dem Weg verloren gehen oder verändert werden:

• Untrusted Access-Ports: Switch setzt DSCP/CoS zurück.
• Trunks/Mapping: DSCP wird nicht korrekt in interne Queues gemappt; CoS wird nicht korrekt transportiert.
• VPN/Tunnel: DSCP wird nicht in den Outer Header kopiert oder wird remapped.
• Provider: DSCP wird ignoriert oder ummarkiert, insbesondere im Internet.

Best Practice im Troubleshooting: Prüfen Sie Markierungen hop-by-hop an den kritischen Übergängen (Access → Distribution, Distribution → WAN, WAN → Gegenstelle). Wo das technisch möglich ist, nutzen Sie Counter, platform-spezifische QoS-Show-Kommandos und konsistente Testflüsse.

Schritt 9: Input vs. Output – der häufigste Bindungsfehler

Viele QoS-Aktionen sind richtungsgebunden. Queueing und Priorisierung sind in der Praxis fast immer auf output relevant, weil Congestion beim Senden auf einen begrenzten Link entsteht. Input Policies sind häufig für Marking und Policing sinnvoll.

• Queueing/Priority: typischerweise output am Engpass-Link
• Marking/Policing: häufig input am Edge, um untrusted Traffic zu kontrollieren

Wenn die Policy „nicht greift“, prüfen Sie, ob sie vielleicht in der falschen Richtung gebunden ist. Besonders bei WAN-Interfaces ist „output“ meist die entscheidende Richtung.

Schritt 10: Platform-spezifische Besonderheiten auf Switches

Bei Cisco Switches ist QoS stark plattformabhängig: Manche Plattformen nutzen TCAM/Hardware-Queueing mit festen Mappings, andere bieten flexible Policies. Typische Ursachen, warum QoS „nicht wirkt“ auf Switches:

• QoS global nicht aktiviert (plattformabhängig)
• Trust/Marking am Access-Port fehlt oder ist falsch gesetzt
• Queue-Mapping (DSCP/CoS → Queue) entspricht nicht dem erwarteten Design
• Congestion entsteht nicht am Switchport, sondern weiter upstream (z. B. WAN)

Nutzen Sie für Ihr konkretes Modell die passenden Cisco-Konfigurationsguides über den Anchor-Text Cisco QoS Konfigurationsguides, weil dort die plattformspezifischen „show“-Befehle und Mappings beschrieben sind.

Sichere Vorgehensweise bei Änderungen: Troubleshooting ohne Kollateralschaden

QoS-Änderungen wirken auf produktive Flows. Deshalb sollten Sie Anpassungen kontrolliert durchführen:

• Baseline sichern: Ausgangslage dokumentieren (Policy-Definitionen, Counter, Interface-Auslastung).
• Änderungen klein halten: Erst die Klassifizierung stabilisieren, dann die Policy-Aktionen optimieren.
• Counter vergleichen: Vorher/Nachher mit show policy-map interface prüfen.
• Test unter Last: QoS zeigt sich meist erst, wenn Congestion entsteht (kontrollierter Lasttest).
• Rollback-Plan: Policy-Binding entfernen oder alte Policy wieder anbinden können.

Typische Ursachenliste: „Warum greift die Policy nicht?“

• Policy ist nicht gebunden oder am falschen Interface gebunden
• Policy ist in falscher Richtung gebunden (input statt output)
• Class Map matcht nicht (Marking fehlt, ACL trifft nicht, falsche Ports)
• Markierungen werden unterwegs überschrieben oder gehen im Tunnel verloren
• Engpass liegt an einer Stelle ohne QoS oder vor dem Router (fehlendes Shaping)
• Platform-Mapping (DSCP/CoS → Queue) entspricht nicht dem erwarteten Modell
• QoS greift, aber es gibt keine Congestion (keine sichtbare Wirkung)
• Problemursache ist nicht QoS (Errors, Duplex, WLAN, Routing, Provider-Loss)

Praxis-Checkliste: QoS Troubleshooting in 15 Minuten

• Engpass identifiziert? (WAN, Trunk, WLAN, Tunnel)
• show policy-map interface: Policy sichtbar und Counter steigen?
• Treffer in der erwarteten Klasse oder nur in class-default?
• Marking verifiziert (DSCP/CoS) und Trust Boundary geprüft?
• Input/Output Bindung korrekt?
• Shaping am WAN aktiv, wenn Provider-Link der Engpass ist?
• Drops/Queues dort sichtbar, wo Congestion erwartet wird?
• Interface-Errors ausgeschlossen (show interfaces)?
• Switch-/Plattformbesonderheiten geprüft (Queue-Mapping, QoS-Global-Settings)?

Für weiterführende Cisco-spezifische Details zur MQC-Syntax, zu platformabhängigen QoS-Implementierungen und zu Verifikationsbefehlen ist der Anchor-Text Cisco QoS Konfigurationsguides eine passende Referenz. Für den konzeptionellen Hintergrund zu DSCP/DiffServ ist der Anchor-Text RFC 2474 hilfreich.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.