Site icon BintoroSoft PDF Tools

Congestion Management: LLQ, CBWFQ und WRED richtig konfigurieren

Red Snapper

A close-up image of a server rack showcasing multiple colorful network cables and connectors, highlighting modern data infrastructure and technology components in a detailed, organized setup

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.

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

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

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

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

CBWFQ-Fallstricke

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

Wann WRED eher nicht passt

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.

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.

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.

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.

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.

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.

Typische Fehlerbilder und wie Sie sie sauber beheben

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.

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