Site icon bintorosoft.com

QoS Troubleshooting: Warum Policies nicht matchen und Drops entstehen

Red Snapper

Laptops connected to a network hub

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:

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:

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:

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.

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?

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:

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.

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.

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.

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.

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.

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.

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

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.

Best Practices: Damit QoS-Policies langfristig stabil matchen

Runbook: QoS Troubleshooting Schrittfolge

Outbound-Referenzen

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:

Lieferumfang:

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.

 

Exit mobile version