QoS Troubleshooting: Warum Policies nicht matchen und Drops entstehen

QoS Troubleshooting auf Cisco-Geräten wird oft erst dann ernst genommen, wenn Voice knistert, Videokonferenzen ruckeln oder kritische Applikationen „sporadisch“ langsam sind. Genau dann fällt auf: Eine QoS-Policy kann formal korrekt konfiguriert sein und trotzdem nicht matchen, oder sie matcht zwar, aber Drops entstehen an anderer Stelle als erwartet. In Enterprise-Netzen ist QoS zudem selten ein einzelnes Feature – es ist eine Kette aus Klassifizierung, Markierung, Trust Boundary, Queuing, Shaping/Policing und ggf. Congestion Avoidance (WRED). Wenn ein Glied dieser Kette nicht passt, wirkt das Ergebnis wie „QoS funktioniert nicht“. Ein professioneller Diagnose-Workflow arbeitet daher nicht mit Vermutungen („die Policy matcht nicht“), sondern mit Beweisen: Wo wird klassifiziert? Welche Markierung liegt tatsächlich am Wire an? Auf welchem Interface und in welcher Richtung ist die Policy angewendet? Welche Zähler steigen, und sind es Drops durch Policing, durch Queue-Overflow oder durch WRED? Dieser Artikel zeigt einen praxistauglichen Cisco-Workflow, um Ursachen schnell zu isolieren, False Positives zu vermeiden und QoS so zu stabilisieren, dass es auch unter Last reproduzierbar wirkt.

Grundprinzip: QoS ist eine Pipeline, nicht eine einzelne Policy

Viele Troubleshooting-Fehler entstehen, weil nur ein Ausschnitt betrachtet wird, etwa eine policy-map auf einem Interface. QoS funktioniert aber als Pipeline, die je nach Plattform und Richtung (Ingress/Egress) unterschiedlich umgesetzt wird. Ein robustes mentales Modell ist:

• Ingress: Klassifizieren → Markieren (oder vertrauen) → ggf. Policen → intern in Hardware-Queues abbilden
• Egress: Warteschlangen/Queues → Scheduling (LLQ/CBWFQ) → Shaping → Congestion Avoidance (WRED) → physischer Ausgang

Wenn Ihre Policy „nicht matcht“, liegt die Ursache häufig davor (Markierungen kommen nicht an) oder dahinter (Drops passieren in einer Hardware-Queue, die Sie nicht beobachten). Deshalb ist der erste Schritt immer: In welcher Richtung und an welcher Stelle der Pipeline erwarten Sie den Effekt?

Vor dem ersten Kommando: Symptom präzisieren und Scope begrenzen

QoS-Probleme sind oft lastabhängig. Ohne saubere Symptomdefinition laufen Sie Gefahr, „QoS zu reparieren“, obwohl die Ursache z. B. ein Duplex-Problem oder ein fehlerhaftes WAN-Shaping ist. Klären Sie daher:

• Welche Applikation ist betroffen? Voice, Video, Citrix, Backup, Storage, Best-Effort?
• In welche Richtung? Upload, Download oder beides? Gerade WAN-Edges sind oft asymmetrisch.
• Wann tritt es auf? Nur bei Peak-Last, nach einem Change, nur auf bestimmten Links?
• Welche Linkart? Campus-Uplink (L2/L3), WAN (MPLS/Internet), Datacenter (Leaf/Spine)?

Das Ziel ist ein konkreter Pfad: Endgerät → Access → Distribution → WAN/Core → Ziel. QoS Troubleshooting ohne Pfad ist meist Zeitverschwendung.

Warum Policies nicht matchen: Die häufigsten Ursachencluster

Wenn „Zähler bleiben auf 0“, ist das selten ein „Bug“. In Cisco-Umgebungen sind es fast immer eine der folgenden Ursachen:

• Policy in falscher Richtung angewendet: Ingress vs. Egress verwechselt; insbesondere bei service-policy input/output.
• Policy am falschen Interface: QoS muss am Engpass greifen. Auf einem 10G-Core-Link bringt Shaping nichts, wenn der Engpass ein 1G-WAN ist.
• Trust Boundary falsch: DSCP/CoS wird nicht vertraut oder wird überschrieben, bevor es klassifiziert wird.
• Class-Map matcht nicht: Falscher match-Befehl, falscher DSCP/ACL, falscher Protokollport, IPv6 vs. IPv4 verwechselt.
• Hardware-/Plattformlimits: Nicht jede Plattform zählt gleich oder unterstützt jede MQC-Funktion in jedem Pfad (ASIC vs. CPU).

Schritt 1: Verifizieren, dass die Policy wirklich aktiv ist

Bevor Sie über Markierungen sprechen, verifizieren Sie die Basics: Ist die Policy auf dem Interface gebunden, und zwar in der erwarteten Richtung? Klingt trivial, ist aber einer der häufigsten Fehler nach Template- oder Rollout-Changes.

• Ist die Policy gebunden? Prüfen Sie, ob die service-policy am richtigen Interface existiert.
• Richtung korrekt? Input/Output muss zur Erwartung passen (Ingress-Markierung vs. Egress-Queuing).
• Richtige Instanz? In VRF-/Subinterface-/Port-Channel-Designs kann QoS an einem anderen logischen Interface greifen als gedacht.

Praxisregel: QoS-Änderungen immer mit „Before/After“-Zählern verifizieren. Wenn Zähler nach Traffic-Generierung nicht steigen, ist die Policy entweder falsch platziert oder matcht nicht.

Schritt 2: Trust Boundary sauber prüfen (DSCP/CoS und Remarking)

Die Trust Boundary entscheidet, ob Markierungen aus dem Netzrand übernommen werden oder ob der Switch/Router neu markiert. In Campus-Netzen ist die klassische Frage: Vertrauen wir dem Endgerät, dem IP-Phone oder dem Access-Switch? In Datacenter-Designs: Vertrauen wir dem Server/Hypervisor oder setzen wir Markierungen am ToR?

• Ingress-Markierung prüfen: Kommt DSCP/CoS tatsächlich so an, wie Sie es erwarten?
• Remarking identifizieren: Wird DSCP auf dem Weg überschrieben (z. B. durch policy-map, trust settings, oder durch Provider-Klassen)?
• CoS↔DSCP Mapping: Bei Trunks wird häufig CoS genutzt; am L3-Hop zählt DSCP. Falsche Mapping-Tabellen führen zu „Policy matcht nicht“.

Ein typisches Fehlerbild: Voice wird am Phone korrekt mit DSCP EF markiert, aber der Access-Switch vertraut nicht und setzt alles auf DSCP 0. Die WAN-Policy matcht dann „Voice“ nie.

Schritt 3: Klassifizierung validieren (Class-Maps, ACLs, NBAR)

Wenn die Policy aktiv ist, prüfen Sie, ob Klassifizierung logisch korrekt ist. In MQC passiert das über class-map/match statements. Häufige Ursachen für Nicht-Matching:

• Falscher DSCP-Wert: EF ist nicht „irgendein hoher Wert“. Prüfen Sie konkrete DSCP-Klassen (EF, AFxy, CSx).
• ACL matcht nicht: Quell-/Zielnetze vertauscht, falsche Ports, TCP vs. UDP, IPv4 ACL auf IPv6 Traffic.
• NBAR/NBAR2 Limits: Applikationserkennung hängt von Plattform und Lizenz ab; verschlüsselter Traffic wird oft nicht granular erkannt.
• Match-Reihenfolge: In manchen Designs wird zuerst anhand DSCP klassifiziert, in anderen anhand ACL. Konsistenz ist entscheidend.

Counter richtig interpretieren

Ein Counter in der Policy zeigt „wie viel Traffic in dieser Klasse gesehen wurde“. Wenn er 0 bleibt, heißt das: Entweder kommt der Traffic nicht vorbei, oder er wird vorher ummarkiert, oder die Klassifizierung ist falsch. Wenn der Counter steigt, aber die Applikation trotzdem schlecht ist, sind Sie wahrscheinlich im Egress-Queuing/Drop-Thema.

Warum Drops entstehen: Policing vs. Queue-Overflow vs. WRED

„Drops“ sind nicht gleich „Drops“. Für sauberes QoS Troubleshooting müssen Sie unterscheiden, ob Drops durch Policing (bewusst), durch Queue-Overflow (Congestion) oder durch WRED (gezielte Early Drops) entstehen. Jede Ursache hat eine andere Lösung.

• Policing Drops: Policy limitiert Rate/Burst; Drops sind erwartbar, wenn Traffic über dem Vertrag liegt.
• Queue-Overflow: Eine Queue füllt sich schneller als sie geleert wird; irgendwann werden Pakete verworfen.
• WRED Drops: Pakete werden früh verworfen, um TCP zu „signalisieren“, bevor die Queue voll ist.

Schritt 4: Policing-Probleme erkennen und korrekt bewerten

Policing ist ein häufiger Grund für „plötzlich Drops“. Typisch ist es am WAN-Edge oder in Service-Provider-Designs. Policing-Probleme entstehen oft nicht, weil Policing „falsch“ ist, sondern weil es nicht zum Trafficprofil passt.

• Falsche CIR/Burst-Werte: Zu kleiner Burst kann sogar bei korrekter Durchschnittsrate Drops erzeugen.
• Falsche Klassenlogik: Voice/Video wird in eine Best-Effort-Police gesteckt und gedroppt.
• Marking-Policy vs. Policing: Wenn Sie im Policer remarken (z. B. exceed → DSCP downmark), prüfen Sie, ob nachfolgende Policies diese Downmarks korrekt behandeln.

Praxisregel: Policing sollte als Vertragsdurchsetzung verstanden werden. Wenn es im eigenen Netz aktiv ist, muss es zum realen Trafficprofil passen – sonst erzeugt es selbst Störungen.

Schritt 5: Queuing- und LLQ-Probleme sauber diagnostizieren

LLQ (Low Latency Queue) und CBWFQ (Class-Based Weighted Fair Queuing) sind typische Cisco-Mechanismen, um Echtzeittraffic zu priorisieren und anderen Klassen garantierte Bandbreite zu geben. Fehlerbilder entstehen häufig durch falsche Erwartung oder falsche Dimensionierung.

• LLQ überdimensioniert: Wenn die Priority-Queue zu groß ist, kann sie Best-Effort verhungern lassen oder Drops in anderen Klassen triggern.
• LLQ unterdimensioniert: Voice/Video wird trotz Priority gedroppt, weil die LLQ-Rate zu niedrig ist.
• Falsche Richtung: LLQ wirkt im Egress. Wenn Sie im Ingress priorisieren wollen, brauchen Sie andere Mechanismen (Marking/Policing/Hardware queues).
• Shaping fehlt am WAN: Ohne Shaping kontrollieren Sie den Engpass nicht. Dann droppt oft der Provider oder das Modem – außerhalb Ihrer Sicht.

Priority Queue und „Policed Priority“

Viele Cisco-Plattformen policen die Priority-Queue automatisch oder erwarten eine explizite Limitierung. Das ist betrieblich sinnvoll: Sonst könnte eine falsch markierte Trafficwelle die Priority-Queue dominieren. Im Troubleshooting prüfen Sie daher, ob Drops in der Priority-Klasse durch ein Priority-Limit entstehen und ob die Markierungen sauber sind (kein Best-Effort als EF).

Schritt 6: Shaping am richtigen Engpass setzen (WAN, Subrate, Overhead)

Ein Klassiker im QoS Troubleshooting: Die Policy matcht, aber Drops sind trotzdem hoch – weil der Engpass nicht dort kontrolliert wird, wo er entsteht. In WAN-Szenarien muss Shaping häufig auf die reale verfügbare Rate inkl. Overhead angepasst werden.

• Physische Rate vs. Vertrag: Ein 1G-Interface kann effektiv weniger liefern, wenn der Provider subraten oder policen.
• Overhead: Encapsulation (MPLS, GRE, IPsec) verändert effektive Nutzdatenrate; ohne Reserve entstehen Drops.
• Hierarchie: Häufig ist HQoS (Hierarchical QoS) sinnvoll: Parent Shaper auf Linkrate, Child Policy für Klassen.

Wenn Sie nicht shapen, „sehen“ Sie oft nicht, wo Drops passieren – sie passieren dann beim Provider oder auf einem nachgelagerten Gerät.

Schritt 7: WRED verstehen – und warum es wie ein „Bug“ aussehen kann

WRED (Weighted Random Early Detection) droppt absichtlich, bevor die Queue voll ist. Das stabilisiert TCP, kann aber im Incident wie „unerklärliche Drops“ wirken, wenn Teams WRED nicht im Blick haben oder wenn es auf falsche Klassen angewendet wurde.

• WRED ist für TCP gedacht: Für Echtzeit (Voice) ist WRED meist nicht sinnvoll.
• DSCP-basierte WRED-Profile: Wenn DSCP falsch gemappt ist, dropt WRED möglicherweise die falschen Klassen.
• Symptom: Drops steigen, obwohl Queue nicht „voll“ wirkt; das kann korrektes WRED-Verhalten sein.

Plattformrealität: Warum MQC-Zähler nicht immer die ganze Wahrheit sind

Ein häufiger Frustpunkt: Die MQC-Policy zeigt kaum Counter, aber die Nutzer sehen Paketverlust. Das liegt oft daran, dass Drops in Hardware-Queues, in ASIC-Puffern oder in einer anderen Pipeline-Stufe passieren, die nicht direkt in Ihrer MQC-Ausgabe sichtbar ist. Besonders in Switch-Plattformen (Campus/Datacenter) ist die Hardware-Pipeline entscheidend.

• ASIC-Queues: Drops können in egress hardware queues passieren, während MQC nur den logischen Klassifizierungszähler zeigt.
• Microbursts: Kurze Bursts können Buffer überlaufen lassen, bevor Softwarezähler sichtbar steigen.
• Interface-Level Counters: Output drops/queue drops auf dem Interface sind oft der beste Hinweis auf echte Congestion.

Praxisregel: Wenn MQC „nichts zeigt“, prüfen Sie Interface-Level Drops, Queue-Statistiken und Buffer-/Queue-Ausgaben der Plattform. Nur so erhalten Sie ein vollständiges Bild.

Typische Fehlerbilder: Schnelle Zuordnung und Gegenmaßnahmen

• Policy matcht gar nicht: Falsche Richtung, falsches Interface, DSCP wurde vorher auf 0 remarkt → Trust Boundary und Placement prüfen.
• Match vorhanden, aber Drops in Best-Effort: LLQ zu groß oder Shaping fehlt → HQoS/Parent Shaper prüfen, LLQ begrenzen.
• Voice schlecht trotz LLQ: Voice nicht korrekt markiert oder LLQ zu klein → Marking prüfen, Priority-Limit dimensionieren.
• Nur große Transfers brechen ab: MTU/Fragmentierung oder Policing Burst zu klein → MTU und Burst/CIR prüfen.
• Drops „ohne volle Queue“: WRED aktiv → WRED-Profil und DSCP-Mapping prüfen.
• Ein Link zeigt starke Drops, andere nicht: Engpass ist an anderer Stelle oder asymmetrische Pfade → Pfad und Richtung isolieren, Shaping dort setzen, wo der Engpass ist.

Debugging und Captures: Beweise sammeln, ohne das Netz zu gefährden

QoS-Probleme sind oft reproduzierbar unter Last. Statt lauter Debugs sind kurze, gefilterte Captures oder Messungen sinnvoll. Ziel ist, die Markierung am Wire zu beweisen und Congestion/Drop-Ort zu identifizieren.

• Markierung prüfen: DSCP/CoS im Capture validieren, bevor Sie Policies ändern.
• Gezielte Lasttests: Kontrollierte Traffic-Generatoren oder Applikations-Tests, um Counter zu triggern.
• Kurze Zeitfenster: Captures und Messungen zeitlich begrenzen, um Nebenwirkungen zu vermeiden.

Best Practices: Damit QoS-Policies langfristig stabil matchen

• Trust Boundary definieren: Wo wird markiert, wo wird vertraut, wo wird überschrieben?
• Rollenbasierte Standards: Access/Distribution/WAN/DC getrennt; nicht jede Policy passt überall.
• Deterministische Klassen: Wenige, klar definierte Klassen statt „zu viele feine Klassen“, die niemand pflegt.
• Shaping am Engpass: WAN-Edges konsequent shapen, Overhead berücksichtigen.
• Policy-Änderungen mit Soft Rollout: Maintenance Window, Pre/Post-Checks, Rollback-Plan.
• Monitoring: Queue drops, policer drops, interface output drops, LLQ utilization als Standard-KPIs.

Runbook: QoS Troubleshooting Schrittfolge

• Pfad festlegen: Betroffener Flow, Richtung, Engpass-Link identifizieren.
• Policy aktiv? Service-policy am richtigen Interface und in der richtigen Richtung.
• Marking/Trust prüfen: DSCP/CoS am Wire und nach jedem Hop.
• Classification prüfen: Class-map matches, ACL/DSCP korrekt, Counter steigen unter Testtraffic.
• Drop-Typ bestimmen: Policer drops vs. queue drops vs. WRED drops.
• Engpass kontrollieren: Shaping/HQoS am richtigen Link, Overhead berücksichtigen.
• Nachjustieren: LLQ/CBWFQ dimensionieren, WRED korrekt einsetzen, Mapping korrigieren.
• Post-Checks: Stabilität unter Last, keine unerwarteten Drops, Monitoring-KPIs grün.

Outbound-Referenzen

• Cisco: DSCP-Werte und Markierungen als Referenz für korrekte Klassifizierungsgrundlagen.
• Cisco: QoS Command References für MQC-Grundlagen, policy-map/class-map und Plattformvarianten.
• Cisco: QoS in Catalyst-Umgebungen für Campus-spezifische Hardware-Queue-Realitäten und Trust-Modelle.
• RFC 2474 (DiffServ) als technische Grundlage für DSCP und Differentiated Services.
• Wireshark Dokumentation für praktische Verifikation von DSCP/CoS-Markierungen und Paketverlustanalyse.

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.