Congestion Management: LLQ, CBWFQ und WRED richtig konfigurieren

Congestion Management ist der Kern von QoS im Unternehmensnetz: Sobald ein Link oder eine Ausgangsqueue ausgelastet ist, entscheidet nicht mehr „wer zuerst kommt, mahlt zuerst“, sondern Ihre Queueing- und Drop-Strategie darüber, welche Anwendungen stabil bleiben und welche leiden. In Cisco-Umgebungen sind dabei drei Begriffe besonders wichtig: LLQ (Low Latency Queue) für echten Echtzeitverkehr, CBWFQ (Class-Based Weighted Fair Queuing) für faire, garantierte Bandbreitenanteile pro Klasse und WRED (Weighted Random Early Detection) als kontrollierte Drop-Strategie, um TCP frühzeitig zu signalisieren, dass Stau entsteht. Genau hier passieren in der Praxis die meisten Fehler: LLQ wird zu groß dimensioniert oder „zu großzügig“ trusted, CBWFQ wird auf falschen Interfaces angewendet oder mit falschen Bandbreiten gerechnet, und WRED wird blind aktiviert, ohne die Auswirkungen auf Applikationen oder DSCP-Precedence zu verstehen. Das Ergebnis sind schwer erklärbare Effekte wie sporadische VoIP-Aussetzer trotz „Priority-Queue“, merkwürdige TCP-Performance, die nach einem QoS-Change schlechter wird, oder Queue-Drops in der falschen Klasse. Dieser Artikel zeigt, wie Sie Congestion Management mit LLQ, CBWFQ und WRED auf Cisco sauber konfigurieren: mit einem robusten Klassenmodell, klarer Trust Boundary, richtigen Einsatzpunkten (Ingress vs. Egress), passenden Shaping/Policing-Entscheidungen und einem Verifikationsansatz, der im Day-2-Betrieb zuverlässig funktioniert.

Was „Congestion“ technisch bedeutet: Engpässe entstehen am Egress

Stau (Congestion) entsteht dort, wo mehr Daten gesendet werden sollen, als ein Ausgangsinterface in einem Zeitintervall übertragen kann. Das ist typischerweise ein Egress-Problem: Ingress kann Pakete annehmen, aber Egress muss sie in eine begrenzte Leitung „einsortieren“. Deshalb ist Congestion Management überwiegend egress-orientiert. Ingress-QoS ist wichtig für Markierung, Policing und Schutz der Control Plane, aber Queueing und Scheduling wirken am Ausgang.

• Queueing: Welche Pakete werden zuerst gesendet, welche später?
• Scheduling: Wie verteilt der Scheduler Bandbreite zwischen Klassen?
• Drop Policy: Welche Pakete werden bei vollem Puffer verworfen – und wie früh?

Für den architektonischen Hintergrund zu DiffServ und DSCP, die häufig als Klassifizierungsgrundlage für Congestion Management dienen, sind RFC 2474 und RFC 2475 zentrale Referenzen.

MQC als Werkzeugkasten: Class-Map, Policy-Map, Service-Policy

In Cisco-Netzen wird Congestion Management meist über MQC (Modular QoS CLI) umgesetzt. Das Muster ist immer gleich: Sie definieren Trafficklassen (class-map), legen pro Klasse das Verhalten fest (policy-map) und binden die Policy an ein Interface (service-policy). Entscheidend ist, dass Scheduling- und Drop-Mechanismen dort angewendet werden, wo Engpässe tatsächlich auftreten: am Egress des Bottleneck-Links (WAN, Internet-Exit, DC-Uplink, etc.).

• class-map: Match nach DSCP/CoS, Subnetzen oder Ports (je nach Strategie).
• policy-map: priority (LLQ), bandwidth (CBWFQ), random-detect (WRED), ggf. shape/police.
• service-policy: Anwendung auf Interface (meist output) oder in Hierarchien (HQoS).

Cisco dokumentiert MQC und QoS-Modelle plattformabhängig, z. B. über die Cisco IOS XE QoS Overview sowie die jeweiligen IOS XE Configuration Guides und Nexus 9000 (NX-OS) Configuration Guides.

LLQ richtig einsetzen: Echtzeit braucht Priorität, aber auch Grenzen

LLQ (Low Latency Queue) ist die klassische „Priority Queue“ für Echtzeittraffic, typischerweise Voice Media (DSCP EF). LLQ sorgt dafür, dass diese Pakete bevorzugt gesendet werden und dadurch Latenz und Jitter minimiert werden. Der Profi-Punkt ist: LLQ darf nie unkontrolliert wachsen. Wenn zu viel Traffic in LLQ landet, verdrängt er andere Klassen und kann das Netz unter Last destabilisieren – insbesondere, wenn Endgeräte DSCP missmarkieren oder wenn Trust Boundaries unklar sind.

Best Practices für LLQ

• LLQ nur für echten Echtzeitverkehr: EF für Voice Media ist der Standardfall; „kritische Apps“ gehören meist nicht in LLQ.
• LLQ klein dimensionieren: LLQ ist kein Bandbreiten-Reservoir für alles Wichtige, sondern eine Latenzgarantie für wenige Flows.
• Policing der LLQ: Viele Designs begrenzen LLQ, damit Missmarkierung nicht das gesamte Scheduling dominiert.
• Trust Boundary erzwingen: Nur definierte Geräte (z. B. IP-Telefone) dürfen EF setzen; untrusted Traffic wird remarkt.

Für die Standard-Definition der EF-Per-Hop-Behavior-Klasse (typisch für Voice) ist RFC 3246 eine gängige Referenz.

Typische LLQ-Fallstricke

• „EF überall“: Wenn Clients EF setzen dürfen, wird LLQ zur Überholspur für jeden und verliert ihre Schutzwirkung.
• Zu große Priority: Eine überdimensionierte LLQ kann Best Effort und kritische Datenklassen aushungern.
• Falscher Einsatzpunkt: LLQ auf einem Interface ohne Engpass bringt wenig; LLQ muss am Bottleneck greifen.

CBWFQ: Faire Bandbreite und Mindestgarantien pro Klasse

CBWFQ (Class-Based Weighted Fair Queuing) ist das Arbeitstier für Congestion Management. Während LLQ „Echtzeit zuerst“ priorisiert, sorgt CBWFQ dafür, dass wichtige Datenklassen bei Stau nicht komplett verdrängt werden. Dazu weisen Sie Klassen Mindestbandbreitenanteile zu (z. B. in Prozent oder absolut, abhängig von Plattform und Policy). Der Scheduler verteilt Bandbreite unter Congestion gemäß diesen Zuteilungen.

Wie CBWFQ in der Praxis sinnvoll wird

• Wenige, stabile Klassen: Lieber 4–6 Klassen mit klarer Semantik als 12 Klassen mit Overlaps.
• Mindestbandbreite dort, wo es zählt: Auf Engpässen (WAN, Internet-Exit) ist Mindestbandbreite wertvoll; auf 10/40/100G-Core-Links oft weniger relevant.
• Priorisierung ohne LLQ-Missbrauch: Business-kritische Apps können über CBWFQ abgesichert werden, ohne in LLQ zu landen.

CBWFQ-Fallstricke

• Falsche Bandbreitenannahmen: Zuteilungen müssen zur realen Linkrate passen; insbesondere bei WAN-Links mit Shaping ist das kritisch.
• „Bandwidth“ ohne Congestion: Mindestbandbreiten wirken primär unter Stau. Ohne Engpass sehen Sie wenig Effekt – was korrekt ist.
• Klassen ohne Messung: Wenn Sie nicht prüfen, welche Flows tatsächlich in welcher Klasse landen, bleibt CBWFQ ein Ratespiel.

WRED: Frühzeitige Drops statt harter Tail Drops

WRED (Weighted Random Early Detection) ist ein Congestion Avoidance Mechanismus: Statt erst dann zu droppen, wenn der Puffer vollständig ist (Tail Drop), droppt WRED zufällig und früher – abhängig von Schwellenwerten und Gewichten. Der Zweck ist vor allem TCP-stabil: Wenn TCP frühzeitig vereinzelte Drops sieht, reduziert es das Sendefenster kontrolliert, bevor es zu massiven Drops und globaler Synchronisation kommt. WRED ist daher in Best-Effort- und AF-Klassen häufig sinnvoll, aber in Echtzeitklassen (LLQ/Voice) in der Regel nicht.

Wann WRED Sinn ergibt

• Best Effort mit vielen TCP-Flows: WRED kann Peaks glätten und Retransmits reduzieren.
• AF-Klassen mit Drop Precedence: Wenn Sie AFxy-Logik tatsächlich nutzen, kann WRED je Precedence unterschiedliche Drop-Wahrscheinlichkeiten setzen.
• Links mit regelmäßiger Congestion: WRED ist ein Werkzeug für echte Engpässe, nicht für „QoS im Leerlauf“.

Wann WRED eher nicht passt

• LLQ/Voice: Drops sind hier meist schlimmer als zusätzliche Verzögerung; Echtzeit soll nicht „random early“ gedroppt werden.
• Applikationen ohne TCP-Backoff: Für UDP-lastige Streams ohne Congestion Control bringt WRED weniger Nutzen.
• Blindes Aktivieren: Ohne Verständnis von DSCP/AF-Precedence und Queue-Schwellen führt WRED zu überraschenden Drops.

Das Zusammenspiel: LLQ + CBWFQ + WRED als konsistentes Modell

Ein robustes Congestion-Management-Design kombiniert die drei Mechanismen bewusst: LLQ schützt Echtzeit, CBWFQ schützt wichtige Datenklassen, WRED stabilisiert die „große Masse“ (Best Effort/AF) unter Stau. Der Schlüssel ist, dass jede Klasse eine klare Bedeutung hat und dass Missmarkierung durch Trust Boundaries und (wo nötig) Policer kontrolliert wird.

• Echtzeit: LLQ (priority), streng begrenzt, nur für definierte DSCP-Werte.
• Kritische Daten: CBWFQ (bandwidth) mit Mindestgarantie, ggf. ohne WRED oder mit konservativem WRED je nach Trafficprofil.
• Best Effort: CBWFQ mit Standardanteil, WRED aktiv, um Stau kontrolliert zu behandeln.
• Bulk/Scavenger: Niedriger Anteil, ggf. aggressiveres WRED oder Policing, um wichtige Klassen zu schützen.

Shaping vs. Policing: Ohne Rate-Kontrolle wird Congestion Management am WAN oft wirkungslos

Viele QoS-Probleme am WAN entstehen, weil der Provider bereits policet. Wenn Sie nur queueing konfigurieren, aber den Ausgang nicht auf die echte, vertragliche Rate (CIR/Access Rate) shapen, dann entstehen Drops beim Provider – außerhalb Ihrer Kontrolle. In solchen Szenarien ist Shaping häufig der wichtigste Hebel, weil es Bursts glättet und die Drops in Ihre kontrollierte Queue-Logik holt.

• Shaping: Glättet Traffic auf eine definierte Rate; erhöht Latenz im Puffer, reduziert aber harte Provider-Drops.
• Policing: Droppt bei Überschreitung sofort; kann TCP stark beeinträchtigen, ist aber für harte Grenzen sinnvoll (z. B. Gastnetz).
• Praxisregel: Am WAN-Egress oft „shape parent“, darunter „queue child“ – damit LLQ/CBWFQ/WRED innerhalb des geshapten Rahmens wirken.

Hierarchische QoS: Parent Shaping, Child Queueing

Hierarchische QoS (HQoS) ist das Standardmuster, wenn Sie sowohl eine Gesamtbandbreite (Shaping) als auch ein differenziertes Congestion Management (LLQ/CBWFQ/WRED) benötigen. Die Parent-Policy shaped den Gesamttraffic (z. B. auf 100 Mbit/s), die Child-Policy enthält die Klassenlogik. So vermeiden Sie, dass ein globales Shaping die Klassenrelationen verfälscht.

• Parent Policy: shape average auf die WAN-Rate oder eine gemessene, stabile Rate.
• Child Policy: LLQ/CBWFQ/WRED je Klasse.
• Nutzen: Engpass liegt dort, wo Ihre QoS-Policy kontrolliert wirkt – nicht beim Provider.

DSCP Trust Boundary: Ohne saubere Markierungen sind LLQ und WRED gefährlich

Congestion Management hängt direkt an Klassifizierung. Wenn DSCP-Werte am Rand nicht kontrolliert sind, werden LLQ und CBWFQ entweder missbraucht oder treffen die falschen Flows. Deshalb gehört die Trust Boundary zur Congestion-Management-Baseline: nur kontrollierte Geräte dürfen priorisierte Markierungen setzen, untrusted Ports remarken auf Best Effort oder auf definierte Profile.

• Telefon-Ports: DSCP trust oder gezielte Markierung für Voice/Signalisierung, PC-Traffic restriktiv.
• User-Ports: Untrusted, Remarking auf Best Effort, Ausnahmen nur dokumentiert.
• WLAN: Häufig Reclassification am Controller/Policy-Edge statt Trust am Client.

Verifikation: Ohne Counters und Dropsichtbarkeit ist Congestion Management nur Theorie

Profis betreiben Congestion Management nicht „auf Hoffnung“, sondern messen. MQC bietet Klassen-Counter, Policer-Drops, Queue-Drops und WRED-Statistiken. Diese Daten sind die Grundlage, um zu entscheiden, ob LLQ zu klein/groß ist, ob CBWFQ-Anteile passen und ob WRED in der richtigen Klasse greift.

• Class Counters: Landet Traffic in den erwarteten Klassen oder ist die Klassifizierung falsch?
• LLQ Drops: Drops in der Echtzeitklasse sind ein starkes Warnsignal (Missmarkierung oder zu kleine LLQ).
• WRED Drops: Erwartete, kontrollierte Drops in Best Effort/AF können normal sein; „Drops überall“ deuten auf falsche Schwellen oder falsche Klassifizierung.
• Queue Depth: Lange Queues bedeuten Latenz; das ist in Best Effort tolerierbar, in Echtzeit nicht.

Ein wichtiger Betriebspunkt: Prüfen Sie nicht nur auf einem Gerät. Congestion Management ist end-to-end; Sie müssen Engpassstellen identifizieren (WAN, Internet-Exit, DC-Uplinks) und dort messen.

Praxis-Klassenmodell: Wenige Klassen, die wirklich durchhaltbar sind

Ein bewährtes Enterprise-Modell lässt sich mit wenigen Klassen abbilden. Entscheidend ist die Semantik: Jede Klasse hat eine klare Bedeutung, und die Organisation weiß, welche Anwendungen hinein dürfen. Ohne diese Governance wird QoS schnell zur politischen Diskussion.

• Realtime (EF): Voice Media, LLQ.
• Critical: Signalisierung und geschäftskritische, interaktive Anwendungen, CBWFQ mit Mindestbandbreite.
• Best Effort: Standardverkehr, CBWFQ und ggf. WRED.
• Bulk/Scavenger: Backups/Updates, niedrige Priorität, ggf. aggressiveres WRED oder Policing.

Typische Fehlerbilder und wie Sie sie sauber beheben

• Voice hat Jitter trotz LLQ: Prüfen Sie, ob Voice wirklich in EF/LLQ landet, ob LLQ-Drops auftreten und ob LLQ durch Missmarkierung zu voll ist.
• TCP wird „schlechter“ nach QoS: Oft ist Policing zu aggressiv oder WRED falsch parametrisiert; auch Provider-Policer ohne eigenes Shaping sind ein Klassiker.
• Nur bestimmte Applikationen leiden: Häufig Klassifizierung nach Ports unvollständig, DSCP-Mappings inkonsistent oder Rückwege laufen über andere Engpässe.
• „Alles ist High Priority“: Trust Boundary fehlt oder ist zu großzügig; Remarking/Whitelist-Ansatz am Edge einführen.
• Drops in falscher Klasse: Overlapping class-maps oder falsche Reihenfolge/Default-Class-Handling; Klassenmodell vereinfachen.

Rollout-Strategie: Erst Konsistenz, dann Optimierung

Congestion Management sollte nicht als Big-Bang ausgerollt werden, weil kleine Fehler große Auswirkungen haben. Ein stabiler Rollout folgt einem Stufenmodell: zuerst Markierungs- und Trust-Standards, dann Queueing an den echten Engpässen, dann WRED/Feintuning.

• Phase 1: DSCP-Policy und Trust Boundary definieren, Remarking etablieren.
• Phase 2: LLQ/CBWFQ am Bottleneck einführen, zunächst konservativ dimensioniert.
• Phase 3: Shaping am WAN ergänzen (HQoS), Provider-Drops reduzieren.
• Phase 4: WRED gezielt aktivieren und anhand von Counters optimieren.

Outbound-Referenzen

• Cisco IOS XE: QoS Overview für MQC, Scheduling-Modelle und plattformspezifische Hinweise.
• Cisco IOS XE Configuration Guides für konkrete MQC-/LLQ-/CBWFQ-/WRED-Konfigurationen je Release.
• Cisco Nexus 9000 (NX-OS) Configuration Guides für NX-OS-spezifische QoS-Modelle und Hardware-Pipeline-Details.
• RFC 2474 und RFC 2475 als Basis für DSCP/DiffServ.
• RFC 3246 (EF PHB) als Referenz für die Echtzeit-/Voice-Klasse.

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.