Site icon bintorosoft.com

QoS Troubleshooting: Warum Policies nicht matchen und Drops entstehen

Red Snapper

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:

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:

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:

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.

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:

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.

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).

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.

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.

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:

Runbook-Baustein: QoS Troubleshooting in 15 Minuten

Typische Korrekturen, die nachhaltig helfen

Weiterführende Quellen für Standards und Praxis

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