QoS Troubleshooting: Warum Policies nicht matchen und Drops entstehen

QoS Troubleshooting ist im Netzwerkbetrieb eine der häufigsten Ursachen für „schwer erklärbare“ Performance-Probleme: Voice klingt abgehackt, Videokonferenzen frieren ein, Applikationen wirken träge, obwohl die Bandbreite laut Monitoring noch „frei“ ist. Der Kernfehler ist dabei selten „QoS ist schlecht“, sondern fast immer einer von zwei Punkten: Die QoS Policies matchen nicht das, was sie matchen sollen – oder Drops entstehen an einer Stelle, an der man sie nicht erwartet (Queueing, Policing, Buffer-Überlauf, Microbursts, falsche Shaper-Rate). Weil QoS gleichzeitig aus Klassifizierung, Marking, Scheduling und Queue-Management besteht, reicht es nicht, nur die Konfiguration zu lesen. Sie müssen nachweisen, welche Pakete tatsächlich mit welchen Markierungen an welchem Interface ankommen, wie sie in Klassen einsortiert werden, welche Queue sie belegen und ob Drops durch Policer, Tail Drop oder AQM (z. B. WRED) entstehen. Dieser Artikel zeigt eine praxiserprobte Methodik für QoS Troubleshooting: Warum Policies nicht matchen, welche Side Effects durch Remarking, Tunneling oder ECMP entstehen, wie Sie Drops sauber lokalisieren und welche Baselines QoS in komplexen Netzen stabil und auditierbar machen.

QoS als Paketpfad-Modell: Wo QoS wirkt und wo nicht

QoS ist kein einzelnes Feature, sondern eine Kette von Entscheidungen entlang des Paketpfads. Für Troubleshooting ist es entscheidend, diese Kette als „Pipeline“ zu verstehen – und pro Schritt Evidence zu sammeln. In der Praxis unterscheiden Sie mindestens vier Stufen:

• Klassifizierung: Welcher Traffic gehört in welche Klasse? (z. B. Voice, Video, Business, Best Effort)
• Marking/Remarking: Welche Kennzeichnung trägt das Paket (DSCP/ToS, 802.1p/CoS, MPLS TC/EXP), und wird sie verändert?
• Queueing/Scheduling: In welcher Queue landet der Traffic, wie wird er bedient (Priority Queue, Weighted Fair Queuing, RR)?
• Congestion Management: Wann und wie wird verworfen (Tail Drop, Policing Drops, WRED/AQM), und an welchem Hop?

Die formale Basis für DiffServ/DSCP ist RFC 2474 und für das DiffServ-Architekturmodell RFC 2475. Diese Dokumente helfen besonders, wenn Teams DSCP-Werte „frei erfinden“ oder Marking inkonsistent interpretieren.

Der häufigste Fehler: QoS matcht nicht – weil das Paket anders aussieht als gedacht

Wenn eine QoS Policy „nicht matcht“, ist das fast nie ein geheimnisvoller Bug. In den meisten Fällen matcht die Policy exakt das, was sie sieht – nur sehen Sie nicht, was sie sieht. Typische Ursachen sind:

• Falscher Matchpunkt: Die Policy sitzt auf dem falschen Interface oder in der falschen Richtung (Ingress statt Egress oder umgekehrt).
• Marking ist nicht vorhanden: Die Applikation markiert nicht, oder Marking wird upstream entfernt.
• Marking wurde überschrieben: WLAN, Access-Switches, Firewalls, Tunnel-Endpunkte oder Provider-Edges remarken DSCP/CoS.
• Header ist gekapselt: Bei IPsec/GRE/VXLAN/MPLS sieht das Underlay nicht den Inner Header, sondern nur Outer Header (und damit ggf. ein anderes DSCP).
• Falsche Protokoll-/Portannahmen: Applikationen nutzen dynamische Ports oder QUIC statt TCP, Policy matcht aber „klassische“ Ports.

Praktischer Nachweis: „Was kommt wirklich an?“

Der schnellste Weg, „matcht nicht“ zu lösen, ist ein kurzer Capture am Ingress-Interface, an dem klassifiziert wird. Sie prüfen: DSCP/ToS, Ports, Protokoll, ggf. Outer/Inner Header. Dafür reichen oft wenige Sekunden und ein sehr enger Filter. Referenzen zur Analyse finden Sie in der Wireshark-Dokumentation und in der tcpdump Manpage.

Die zweite große Fehlerklasse: Drops entstehen – aber nicht dort, wo Sie hinschauen

QoS-Drops sind für viele Teams gleichbedeutend mit „zu wenig Bandbreite“. In Wirklichkeit entstehen Drops aus mehreren Mechanismen, die sich unterschiedlich anfühlen und unterschiedlich behoben werden müssen:

• Policing Drops: Traffic überschreitet eine Rate/Burst, Policer verwirft oder remarkt (häufig hart und reproduzierbar).
• Queue Tail Drop: Queue läuft voll, am Ende wird verworfen (typisch bei Microbursts oder wenn Scheduler unfair ist).
• WRED/AQM Drops: Frühes, probabilistisches Verwerfen zur Vermeidung globaler TCP-Synchronisation (wirkt wie „leichter Loss“, aber kann gewollt sein).
• Hardware-Buffer/ASIC Drops: Drops passieren unterhalb Ihrer Policy-Counter (z. B. in internen Buffern oder wegen Oversubscription).

Der erste Troubleshooting-Schritt ist daher nicht „Queue größer“, sondern „Welche Drop-Art ist es?“ Nur dann ist der Fix sauber.

QoS-Checkliste: Reihenfolge, die in der Praxis funktioniert

QoS Troubleshooting wird deutlich schneller, wenn Sie immer dieselbe Reihenfolge verwenden. Das verhindert, dass Sie an Scheduling drehen, obwohl Klassifizierung bereits falsch ist.

• 1) Klassifizierung beweisen: Welche Klasse sieht der Switch/Router wirklich? (Class counters / match hits)
• 2) Marking-Kontinuität beweisen: Trägt der Traffic DSCP/CoS/TC end-to-end? Wo wird remarkt?
• 3) Congestion-Lokus finden: Wo entsteht Queueing/Drops – Access, WAN-Edge, Core, Provider-Handoff, WLAN?
• 4) Drop-Typ bestimmen: Policer vs. Tail Drop vs. WRED vs. ASIC Drops
• 5) Side Effects prüfen: ECMP, Tunneling, MTU/Fragmentation, asymmetrische Pfade über stateful Geräte

Warum Policies nicht matchen: Die häufigsten Ursachen im Detail

Falsches Interface oder falsche Richtung

Viele QoS-Modelle unterscheiden Ingress und Egress fundamental: Ingress wird klassifiziert/markiert/policed, Egress wird geshaped/queued/scheduled. Eine Policy auf dem „richtigen“ Gerät kann trotzdem wirkungslos sein, wenn sie auf dem falschen Interface hängt oder in der falschen Richtung aktiviert wurde. Typischer Effekt: Counters bleiben 0, obwohl Traffic vorhanden ist.

Marking wird entfernt oder normalisiert

Eine besonders häufige Ursache: Marking wird irgendwo „bereinigt“. Beispiele aus der Praxis:

• WLAN/WMM Mapping: DSCP ↔ WMM Access Categories ↔ 802.1p ist nicht konsistent, und der Übergang WLAN→LAN verliert Priorität.
• Firewalls/Proxies: Security-Geräte remarken DSCP bewusst (Compliance) oder unbewusst (Default Settings).
• Provider-Handoffs: Provider setzen DSCP auf definierte Werte (oder 0), wenn keine QoS-Verträge existieren.

Der Fix ist selten „QoS neu bauen“, sondern die Marking-Policy end-to-end konsistent zu machen: Definieren, wo Marking passiert, und wo Remarking explizit erlaubt oder verboten ist.

Tunnel- und Overlay-Effekte: Inner vs. Outer DSCP

Bei IPsec, GRE, VXLAN oder MPLS sieht das Underlay häufig nicht den inneren IP-Header. Wenn Ihre QoS-Policy am Underlay-Interface matcht, muss sie eventuell auf Outer DSCP oder auf MPLS TC/EXP matchen – oder Sie müssen DSCP/CoS korrekt in den Outer Header kopieren. Sonst ist die Klassifizierung zwangsläufig falsch.

• Indiz: QoS funktioniert „on-prem“, aber nicht über Tunnel/WAN.
• Nachweis: Capture zeigt: Inner DSCP ist korrekt, Outer DSCP ist 0 (oder umgekehrt).
• Fix-Richtung: DSCP/TC Copy/Propagation bewusst konfigurieren, und Policies auf den Header matchen, der am jeweiligen Hop sichtbar ist.

Warum Drops entstehen: Von Policing bis Microbursts

Policing: Der häufigste „harte“ Drop

Policer sind einfach: Sie begrenzen eine Rate. Wenn Traffic darüber liegt, wird er verworfen oder remarkt. Viele Netze policen an WAN-Edges oder Provider-Handoffs. Häufige Fehler sind falsche CIR/EIR-Werte, zu kleine Burst-Größen oder Policer an der falschen Stelle (z. B. Ingress Policer auf Voice, der Peaks abschneidet).

• Indiz: Drops steigen gleichmäßig bei Last; Voice/Video verschlechtert sich unter planbarer Auslastung.
• Nachweis: Policer-Counter steigen, Queue-Counter bleiben unauffällig.
• Fix-Richtung: Policer-Raten und Burst an reale Traffic-Profile anpassen; ggf. statt Policing Shaping nutzen, wenn Delay tolerierbar ist.

Shaping vs. Scheduling: Wenn die Queue falsch bedient wird

Shaping begrenzt eine Rate durch Pufferung (Queueing), während Scheduling entscheidet, welche Klasse wann bedient wird. Ein typischer Fehler ist, dass zwar Klassen existieren, aber die Prioritätsklasse zu groß dimensioniert ist oder ohne harte Begrenzung läuft. Ergebnis: Priority Queue kann andere Klassen „aushungern“ oder umgekehrt.

• Indiz: Best Effort bricht ein, sobald Voice aktiv ist (oder Voice leidet, obwohl Bandbreite da ist).
• Nachweis: Queue-Stats zeigen hohe Occupancy und Drops in einer bestimmten Klasse, während andere leer bleiben.
• Fix-Richtung: Priority Queue policed/limited dimensionieren, Scheduling-Gewichte korrekt setzen, Shaper-Raten an den realen Link anpassen (inkl. Overhead).

Microbursts: Wenn 10 ms reichen, um alles zu ruinieren

Microbursts sind kurze, sehr hohe Traffic-Spitzen, die Interface-Utilization-Durchschnittswerte nicht zeigen. Sie füllen Buffers in Millisekunden und verursachen Tail Drops. Besonders häufig in Data-Center-Fabrics, bei East-West Traffic, bei Storage/Backup oder wenn mehrere Sender gleichzeitig auf einen Engpass schieben.

• Indiz: Drops trotz „nur 40% Auslastung“ im 1-Minuten-Graph; TCP Retransmissions, Jitter, kurze Aussetzer.
• Nachweis: Queue Drops/Buffer Drops korrelieren mit Traffic-Spikes, nicht mit langfristiger Auslastung.
• Fix-Richtung: Bessere Buffer/Queue-Strategie, AQM/WRED für geeignete Klassen, Traffic Shaping an Aggregationspunkten, oder Kapazität/Topologie verbessern.

Wenn QoS „richtig“ ist und trotzdem schlecht wirkt: Hidden Side Effects

Asymmetrische Pfade über stateful Geräte

QoS kann Pfade indirekt beeinflussen (z. B. PBR/SD-WAN Steering nach Klassen). Wenn dadurch Hin- und Rückweg über unterschiedliche Firewalls/NAT-Instanzen laufen, entstehen Drops, die wie QoS-Drops aussehen (Timeouts), aber eigentlich State-Probleme sind. Deshalb gehört „Asymmetrie“ in jede QoS-Diagnose, sobald stateful Geräte im Pfad sind.

ECMP und Flow Pinning

In Netzen mit ECMP können Flows auf unterschiedliche Pfade verteilt werden. Wenn ein Pfad degradiert ist (Errors, Drops, höhere Latenz), leiden nur die Flows, die dort landen. QoS-Counter wirken dann „komisch“, weil nicht alle Flows gleich betroffen sind. In solchen Fällen ist Member-spezifische Telemetrie entscheidend.

MTU/Fragmentation: QoS als falscher Verdächtiger

Vor allem bei Tunneln (IPsec/VXLAN/MPLS) kann MTU zu klein sein. Große Pakete droppen, kleine gehen. Das wirkt wie QoS-Policing oder Drops, ist aber ein MTU/PMTUD-Problem. Für PMTUD sind RFC 1191 (IPv4) und RFC 8201 (IPv6) relevante Quellen.

Evidence Pack: Welche Daten Sie im QoS-Incident immer sammeln sollten

QoS-Störungen eskalieren häufig, weil Evidence fehlt. Mit einem kleinen, standardisierten Evidence Pack wird die Diskussion deutlich schneller und belastbarer:

• Konkrete Flows: 3–5 Beispiele (5-Tuple), betroffene Applikation, Zeitpunkt, Symptom (Loss/Jitter/Delay).
• Marking-Realität: DSCP/CoS/TC am Eintrittspunkt der QoS-Klassifizierung (Capture oder Telemetrie).
• Policy Counters: Match-Hits pro Klasse, Drops/remarks pro Policer, Queue-Stats (Occupancy/Drops).
• Interface Health: Errors, output drops, queue drops, CoPP/Policer drops (falls Control Plane relevant ist).
• Pfadkontext: Welche Links/Edges sind im Datenpfad? ECMP-Members? Tunnel-Overhead?

Runbook-Baustein: QoS Troubleshooting in 15 Minuten

• Minute 0–3: Symptomprofil: Loss/Jitter/Delay? Welche Applikation? Welche Flows? Betroffene Segmente/Standorte?
• Minute 3–6: Marking prüfen: Kommt DSCP/CoS so an, wie erwartet? Gibt es Remarking (WLAN/Firewall/Provider/Tunnel)?
• Minute 6–9: Policy matcht? Counters/Hitcounts pro Klasse. Wenn 0: falsches Interface/Richtung oder falsche Match-Kriterien.
• Minute 9–12: Drops lokalisieren: Policer-Drops vs. Queue-Drops vs. ASIC Drops. Congestion-Lokus bestimmen (WAN-Edge, Aggregation, Core).
• Minute 12–15: Fix-Richtung: Marking-Kette korrigieren, Policer/Shaper-Raten/Bursts anpassen, Priority Queue begrenzen, Microbursts adressieren, ECMP-Member isolieren. Danach Verifikation mit denselben Flows.

Typische Korrekturen, die nachhaltig helfen

• End-to-End Marking-Plan: Festlegen, wo markiert wird (Edge), wo trusted ist, wo remarkt wird (und warum).
• Policy-Simplifizierung: Weniger Klassen, klarere Match-Kriterien, „spezifisch vor generisch“.
• Shaping an Engpässen: Egress-Shaping auf die reale Provider-Rate, nicht auf die Interface-Speed, inklusive Overhead.
• Priority Queue begrenzen: Voice/Realtime priorisieren, aber durch Policer/Rate-Limit vor Starvation schützen.
• Microburst-Strategie: Telemetrie mit kurzer Granularität, AQM sinnvoll einsetzen, Engpässe identifizieren.
• Monitoring auf Counters: Nicht nur Bandbreite, sondern Queue Occupancy, Drops pro Klasse, Remarking Events.

Weiterführende Quellen für Standards und Praxis

• RFC 2474 für DSCP und Differentiated Services Field
• RFC 2475 für die DiffServ-Architektur (Per-Hop Behaviors, Konzeptmodell)
• RFC 3246 für Expedited Forwarding (EF), häufig für Voice/Realtime genutzt
• RFC 2597 für Assured Forwarding (AF) Klassenmodell
• RFC 1191 und RFC 8201 für PMTUD (wichtig bei Tunnel-Overhead und „QoS wirkt wie Drop“)
• Wireshark Dokumentation für DSCP/CoS/Timing-Analyse und Loss-Indizien
• tcpdump Manpage für effiziente Mitschnitte im Incident

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.