Interface Queueing Deep Dive: Output Drops, Tail Drop, WRED verstehen

Interface Queueing ist der Ort, an dem aus „Bandbreite“ plötzlich „Nutzer-Impact“ wird: Sobald ein Ausgangslink überlastet ist, bilden sich Queues, Latenz steigt, Jitter nimmt zu und irgendwann entstehen Drops. Genau diese Drops siehst du als output drops in show interfaces oder als Drops in QoS-Klassen. Der Deep Dive ist deshalb wichtig: Tail Drop ist das Standardverhalten (Queue voll → Paket weg), WRED ist ein kontrollierter Mechanismus, der Drops früher und intelligenter verteilt, um TCP-Staus zu vermeiden. Wer Queueing versteht, kann Congestion-Probleme sauber diagnostizieren und gezielt beheben.

Warum Output Queueing überhaupt entsteht

Queueing entsteht, wenn die eingehende Datenrate höher ist als das, was der Ausgangslink gerade senden kann. Das passiert besonders am WAN-Uplink (Upload) und bei Microbursts (kurze sehr hohe Spitzen), auch wenn der 5-Minuten-Durchschnitt „ok“ wirkt.

• Engpass ist fast immer Egress (WAN Upload, Shaper, Provider)
• Microbursts erzeugen Drops trotz „Link nicht voll“ im Mittel
• Queueing ist normal – problematisch wird es bei anhaltender Congestion

Die drei Kennzahlen: Latenz, Jitter, Loss

Queues beeinflussen immer Latenz und Jitter; Drops erzeugen Loss. Für Echtzeit (VoIP) ist Loss besonders kritisch, für TCP führt Loss zu Retransmits und geringerer effektiver Bandbreite.

• Latenz: steigt mit Queue-Tiefe
• Jitter: schwankt mit Queue-Variation
• Loss: entsteht bei Drops (Tail Drop/WRED/Policer)

Queue-Latenz als Denkmodell

$\text{QueueDelay}\approx \frac{\text{QueueBytes}\times 8}{\text{LinkRate}}$

Output Drops: Was sie bedeuten (und was nicht)

output drops sind Pakete, die nicht mehr in die Ausgangsqueue passen oder durch Queueing-Mechanismen verworfen wurden. Sie sind ein starkes Signal für Congestion – aber du musst unterscheiden: Drops durch Interface-Queue vs. Drops durch QoS-Policy (WRED/Policer) oder Hardware-Drops (QFP).

• Output Drops im Interface: Queue voll, Tail Drop oder WRED
• QoS Drops: class-default oder bestimmte Klassen droppen
• Hardware Drops: z. B. QFP-Drop-Reasons (Data Plane)

Erste Checks

show interfaces gigabitEthernet0/1 | include output drops|queue|rate
show policy-map interface gigabitEthernet0/1
show platform hardware qfp active statistics drop

Tail Drop verstehen: „Queue voll → Paket weg“

Tail Drop ist das Standardverhalten: Die Queue nimmt Pakete an, bis sie voll ist. Danach werden neue Pakete am Ende (tail) verworfen. Das ist einfach, aber für TCP oft schlecht, weil viele Flows gleichzeitig Verluste erleben („global synchronization“), wodurch die Gesamtauslastung schwankt.

• Vorteil: simpel, vorhersehbar
• Nachteil: Burst-Drops, TCP-Synchronisation, Jitter steigt
• Typisch: Default-Queue ohne spezielle QoS/WRED

WRED verstehen: Drops früher und „fairer“ verteilen

WRED (Weighted Random Early Detection) droppt Pakete probabilistisch, bevor die Queue komplett voll ist. Ziel ist, TCP früh zu signalisieren „reduziere Rate“, damit die Queue nicht dauerhaft vollläuft. WRED kann dabei DSCP/Precedence berücksichtigen: weniger wichtige Klassen droppen früher als wichtige.

• Early Drop: beginnt vor Queue-Vollstand
• Randomized Drop: verteilt Loss über Zeit/Flows
• Weighted: unterschiedliche Drop-Profile je DSCP/Precedence

WRED-Denkmodell

$\text{DropProbability}\nearrow \text{wenn QueueAvg}\nearrow$

Wo WRED sinnvoll ist (und wo nicht)

WRED ist primär für TCP-lastige Klassen sinnvoll (Bulk, Web), nicht für Echtzeit-Queues. Für Voice/Video nutzt du typischerweise LLQ oder strikte Prioritätsklassen – dort willst du keine random drops, sondern garantierte Behandlung.

• Sinnvoll: class-default oder „Bulk“-Klassen (TCP-dominant)
• Weniger sinnvoll: Voice/LLQ (Echtzeit) – dort Drops vermeiden
• Voraussetzung: DSCP/Marking ist konsistent, sonst bringt Weighting wenig

Queueing in Cisco QoS: CBWFQ, LLQ und WRED zusammen denken

In modernen Designs ist Interface-Queueing oft durch QoS-Policies gesteuert: CBWFQ verteilt Bandbreite, LLQ priorisiert Echtzeit, WRED managt Congestion in nichtkritischen Klassen. Wichtig ist die Reihenfolge: zuerst Shaping (damit Congestion im Router entsteht), dann Queueing/WRED.

• Parent Shaper: kontrolliert die „echte“ Linkrate
• Child Policy: Klassen + Queueing (LLQ/CBWFQ) + optional WRED
• WRED typischerweise in class-default oder Bulk-Klasse

Beispiel: WRED in class-default (Konzept)

policy-map PM_CHILD
 class CM_VOICE
  priority 1000
 class class-default
  random-detect dscp-based

Microbursts: Warum Drops trotz „genug Bandbreite“ auftreten

Microbursts sind kurze Spitzen, die Buffers füllen, bevor Shaping/Rate-Average greift. Du erkennst sie an Drops ohne dauerhaft hohe 5-Minuten-Rate. In solchen Fällen hilft oft Shaping, besseres Queueing oder eine Anpassung der Burst-Toleranz (plattform-/designabhängig).

• Symptom: Drops steigen, aber Durchschnittsrate wirkt moderat
• Ursache: kurze Peaks, Buffer füllen schneller als senden möglich ist
• Fix: Shaping korrekt setzen, Queueing optimieren, Traffic glätten

Troubleshooting-Workflow: Drops systematisch einordnen

Du willst zuerst wissen: Wo werden Pakete verworfen? Dann: Warum? Danach: Welche Klasse ist betroffen? So findest du gezielt den Fix (Shaper, QoS, WRED, Linkrate).

• 1) Interface Drops vs. QoS Drops vs. Hardware Drops trennen
• 2) Congestion bestätigen: Output rate nahe Shaper/Linkrate?
• 3) Klassen prüfen: welche Klasse droppt?
• 4) WRED/Tail Drop identifizieren (Policy)
• 5) Fix auswählen: Shaping/QoS/Marking/Capacity

Pflichtkommandos

show interfaces gigabitEthernet0/1
show interfaces gigabitEthernet0/1 | include 5 minute|output drops|queue
show policy-map interface gigabitEthernet0/1
show platform hardware qfp active statistics drop

Typische Fixes: Was wirklich hilft

Queueing-Probleme löst du selten durch „mehr Buffer“. Meist helfen korrekte Linkrate/Shaping, saubere Priorisierung und das Vermeiden unnötiger Bursts. Wenn der Engpass real ist, hilft am Ende nur Capacity oder bessere Pfadwahl.

• Shaping auf reale Provider-Rate (Congestion im Router kontrollieren)
• LLQ für Voice korrekt limitieren (nicht zu groß, nicht zu klein)
• WRED für TCP-lastige Klassen aktivieren (wenn Marking stimmt)
• Marking/Trust im Campus sauber machen (DSCP konsistent)
• Wenn dauerhaft voll: Kapazität erhöhen oder Traffic splitten (ECMP/Dual-WAN)

Quick-Reference: Output Drops in 60 Sekunden analysieren

Diese Sequenz liefert dir schnell: ob Congestion vorliegt, welche Klassen betroffen sind und ob WRED/Policer beteiligt ist.

show interfaces g0/1 | include 5 minute|output drops|queue
show policy-map interface g0/1
show platform hardware qfp active statistics drop
show interfaces g0/1 | include CRC|error|drops

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.