QoS für Voice/Video debuggen: DSCP Trust, Queues, Policer

QoS für Voice/Video debuggen ist eine der effektivsten Maßnahmen, um aus „die Calls sind schlecht“ innerhalb kurzer Zeit eine belastbare technische Ursache zu machen. Echtzeitverkehr reagiert empfindlich auf Jitter, Paketverlust und Queueing-Delay – und genau diese Effekte entstehen oft nicht durch zu wenig Bandbreite, sondern durch falsches Marking, fehlendes DSCP Trust, ungeeignete Queue-Parameter oder Policer, die kurze Peaks abschneiden. In vielen Umgebungen ist die Konfiguration zudem mehrstufig: Endgeräte markieren DSCP, Access-Switches müssen dieses Marking vertrauen (oder korrekt neu setzen), WLAN übersetzt in WMM-Klassen, WAN-Edges shapen auf Provider-Rate, und Firewalls/Overlays können DSCP unterwegs überschreiben. Wenn in dieser Kette nur ein Glied falsch ist, matchen Policies nicht, Voice landet in Best Effort, und Drops entstehen in der falschen Queue oder in einem Policer, den niemand auf dem Radar hatte. Dieses Troubleshooting-Thema verlangt daher ein methodisches Vorgehen: erst Marking und Trust beweisen, dann Queue-Zuordnung und Scheduling prüfen, anschließend Policer/Shaper und Drop-Typen identifizieren und am Ende Side Effects wie ECMP, Tunnels, MTU und Asymmetrie ausschließen. Dieser Artikel zeigt Ihnen genau dieses Vorgehen – praxisnah, evidenzbasiert und so strukturiert, dass er als Runbook im On-Call taugt.

Warum Voice/Video anders ist: QoS-Ziele und typische Failure Modes

Voice (RTP/VoIP) und interaktives Video tolerieren nur begrenzt Verzögerung und Schwankung. Während TCP bei Verlust nachsteuert, läuft Echtzeit oft über UDP und „nimmt“ Loss direkt als Qualitätsabfall mit. Typische Zielwerte (als Orientierung, abhängig von Codec/Plattform): niedriger Jitter, möglichst kein Loss, und begrenzte One-Way-Delay. QoS hilft, indem es diese Traffic-Klassen bevorzugt bedient und vor Congestion schützt. QoS kann aber auch Schaden anrichten, wenn es falsch eingesetzt wird.

• Marking-Failure: DSCP/CoS geht verloren oder wird überschrieben, Traffic landet in falscher Queue.
• Trust-Failure: Access-Switch oder WLAN vertraut Markings nicht und setzt alles auf Best Effort.
• Queue-Failure: Priority Queue zu klein, falsch gewichtet oder nicht begrenzt; andere Klassen verhungern oder Voice wird gedroppt.
• Policer-Failure: Policer schneidet Bursts ab (gerade bei Video sehr häufig), erzeugt Loss und Jitter.
• Congestion an unerwarteter Stelle: Drops passieren nicht am WAN-Edge, sondern am Uplink, im WLAN, im Firewall-Cluster oder in einem „schlechten“ ECMP-Member.

Das End-to-End-Modell: DSCP Trust, Queues und Policer als Pipeline

QoS Troubleshooting wird zuverlässig, wenn Sie QoS als Pipeline betrachten. Sie prüfen nicht „die Policy“, sondern den Weg des Pakets durch Klassifizierung, Marking, Queueing und Congestion-Mechanismen.

• Klassifizierung: Wie erkennt das Gerät Voice/Video? Über DSCP, Ports, NBAR/DPI, VLAN, 802.1p, etc.
• Trust/Remarking: Wird DSCP/CoS übernommen oder überschrieben? Passiert Marking am Edge oder im Access?
• Queue-Zuordnung: In welche Queue fällt die Klasse? Gibt es eine echte Priority Queue für Voice?
• Scheduling: Wie werden Queues bedient (Strict Priority, Weighted Fair Queuing, Deficit RR)?
• Policing/Shaping: Wird Traffic begrenzt? Wo wird gedroppt oder remarkt?

Für den Hintergrund zu DSCP und DiffServ ist RFC 2474 (DS Field/DSCP) und RFC 2475 (DiffServ Architektur) eine saubere Referenz. Für Expedited Forwarding (häufig für Voice) ist RFC 3246 relevant.

Schritt 1: DSCP Marking beweisen, bevor Sie irgendetwas ändern

Der häufigste Grund, warum QoS für Voice/Video nicht wirkt, ist banal: Der Traffic ist gar nicht so markiert, wie es die Policy erwartet. Oder er ist korrekt markiert, aber am relevanten Hop sieht man nur den falschen Header (z. B. Outer statt Inner). Deshalb beginnt jedes Debugging mit der Frage: Mit welchem DSCP kommt der Traffic wirklich am Klassifizierungs-Punkt an?

Praktische Checks für Marking

• Edge-Capture: Kurzer Mitschnitt am Access-Port oder am WLAN-Controller-Uplink: DSCP der Voice/Video-Pakete prüfen.
• Vergleich an zwei Punkten: Einmal nah am Endgerät, einmal am WAN-Edge. Wenn DSCP unterwegs kippt, wissen Sie, wo Sie suchen müssen.
• Inner vs. Outer Header: Bei IPsec/GRE/VXLAN/MPLS prüfen, ob DSCP vom Inner Header korrekt in den Outer Header übernommen wird.

Für die praktische Analyse sind die Wireshark Dokumentation und die tcpdump Manpage hilfreiche Einstiegspunkte, um DSCP/ToS-Felder schnell zu verifizieren.

Typische Marking-Fallen bei Voice/Video

• Softphones markieren anders: Nicht jede App nutzt EF/AF wie erwartet; manche Plattformen markieren nur Audio, nicht Video.
• WLAN/WMM Mapping: DSCP wird in WMM-Klassen übersetzt; am Übergang WLAN→LAN kann Marking verloren gehen oder falsch gemappt werden.
• Firewalls/Proxies: Remarking ist oft Default oder Teil einer Security-Policy („normalize DSCP“).
• Provider setzt DSCP auf 0: Ohne QoS-Vertrag wird DSCP häufig ignoriert oder genullt – dann muss Shaping/Queueing lokal greifen.

Schritt 2: DSCP Trust richtig einordnen

„Trust“ bedeutet: Das Gerät übernimmt die Markierung, die ein Paket mitbringt, und nutzt sie als Grundlage für Klassifizierung und Queue-Zuordnung. Das klingt gut, ist aber ein Sicherheits- und Design-Thema: Wenn Sie jedem Endgerät trusten, kann jeder Client „EF“ setzen und die Priority Queue missbrauchen. Daher ist die entscheidende Frage nicht „Trust an oder aus“, sondern „Wo trusten wir bewusst und wo markieren wir neu?“

Trust-Strategien, die in der Praxis funktionieren

• Trust am Phone-Port, nicht am PC-Port: IP-Telefone dürfen marken, PCs dahinter nicht (klassisches Campus-Design).
• Trust am WLAN-Controller, nicht am Client: Controller klassifiziert (z. B. anhand SSID/Policy) und markiert konsistent.
• Trust in Server-/DC-Zonen selektiv: Nur bekannte Workloads dürfen priorisieren; alles andere wird normalisiert.

Wie Trust-Probleme aussehen

• Policy matcht nie: Counters bleiben 0, weil DSCP am Switch/Router nicht mehr vorhanden ist.
• Alles matcht Voice: Wenn trust zu breit ist, landen unerwartet viele Flows in Voice/Video-Klassen; dann entstehen Drops trotz „Priority“.
• Nur ein Standort betroffen: Ein Access-Stack oder ein WLAN-Controller hat eine abweichende Trust-Policy.

Schritt 3: Queues und Scheduling prüfen – Voice braucht Priorität, aber mit Grenzen

Für Echtzeittraffic ist die Queue-Logik entscheidend. In vielen Designs gibt es eine Strict Priority Queue (oft „LLQ“ genannt) für Voice. Das ist sinnvoll, aber gefährlich, wenn sie nicht begrenzt wird: Eine unbegrenzte Priority Queue kann andere Klassen verhungern lassen und dadurch die Gesamtstabilität verschlechtern. Umgekehrt ist eine zu kleine Priority Queue oder falsches Scheduling der schnellste Weg zu Voice-Loss.

Was Sie bei Queues konkret prüfen sollten

• Welche Queue bekommt EF? EF/Voice muss in der priorisierten Queue landen, nicht in Best Effort.
• Wie groß ist die Priority-Rate? Gibt es ein explizites Limit/Policer auf der Priority Queue?
• Queue Occupancy und Drops: Ist die Voice-Queue voll? Gibt es Tail Drops oder WRED?
• Scheduling-Gewichte: Video (oft AF-Klasse) braucht ausreichend Bandbreite, sonst wird es „blocky“ oder friert ein.

Typische Queue-Fehlerbilder

• Voice leidet unter Last, obwohl „Priority“ aktiv ist: EF wird falsch klassifiziert oder Priority-Queue ist zu klein/überlastet.
• Andere Anwendungen brechen ein, sobald Voice läuft: Priority Queue ist nicht begrenzt oder Voice-Klasse wird missbraucht (Trust zu breit).
• Video bricht zuerst: Video ist meist nicht in Strict Priority, sondern in einer AF-Klasse; falsche Gewichte oder Policer treffen Video besonders stark.

Schritt 4: Policer und Shaper – der häufigste Grund für „Audio ok, Video schlecht“

Policer sind bei Voice/Video oft der entscheidende Störfaktor. Audio hat relativ konstante, kleine Bitraten; Video ist burstiger und skaliert dynamisch. Ein zu aggressiver Policer (zu niedrige Rate oder zu kleiner Burst) erzeugt gezielt Loss – und Loss ist bei Video sofort sichtbar. Gleichzeitig können Shaper falsch dimensioniert sein, wenn sie auf Interface-Speed statt auf Provider-Rate oder auf eine falsche Overhead-Annahme konfiguriert sind.

Policer-Drops erkennen und unterscheiden

• Policer-Drops: Zähler steigen in der Policier-Instanz, oft unabhängig von Queue-Füllständen.
• Remark statt Drop: Manche Policer remarken (z. B. EF→BE) statt zu droppen; dann ist Voice plötzlich „best effort“.
• Burst-Problem: Durchschnittsrate passt, aber kurze Peaks werden abgeschnitten → „sporadische“ Qualitätseinbrüche.

Shaping richtig dimensionieren

• Auf Provider-Rate shapen: Wenn der Provider 100 Mbit/s liefert, aber Ihr Interface 1 Gbit/s ist, muss Shaping an der Edge auf 100 Mbit/s erfolgen.
• Overhead berücksichtigen: Ethernet/VLAN/MPLS/VXLAN/IPsec erhöhen den Overhead; falsche Annahmen erzeugen Drops „trotz Shaping“.
• Queueing bewusst akzeptieren: Shaping erzeugt Delay durch Pufferung; bei Voice muss die Queue-Architektur dafür gemacht sein.

Schritt 5: Drop-Ort lokalisieren – nicht jeder Drop ist „QoS Drop“

In komplexen Netzen sind Drops oft nicht dort, wo die QoS-Policy sitzt. Sie können in ASIC-Buffern passieren, in WLAN-Queues, an einem einzelnen ECMP-Member oder durch MTU/Fragmentation. Deshalb ist der wichtigste Debugging-Schritt: Wo genau entstehen die Drops?

High-Signal Indizien für Drop-Lokus

• Queue Drops pro Klasse: Wenn nur Voice-Queue droppt, ist Klassifizierung/Queueing/Rate-Limit verdächtig.
• Output Drops ohne Queue-Stat: Hinweis auf ASIC-/Hardware-Buffer oder Oversubscription.
• Nur bestimmte Flows betroffen: ECMP/Flow Pinning auf „schlechtem Pfad“; Member-spezifische Counters prüfen.
• „Ping ok, Call schlecht“: Jitter/Loss/Microbursts; ICMP ist zu klein und zu tolerant.

Microbursts: Warum ein 1-Minuten-Graph Sie belügt

Voice/Video kann schon bei sehr kurzen Congestion-Ereignissen leiden. Microbursts füllen Buffers in Millisekunden. Das zeigt sich nicht in grober Auslastung, aber sehr wohl in Queue Drops, Jitter und RTP-Loss. Wenn Sie wiederkehrende, kurze Quality-Spikes sehen, ist Microburst-Telemetrie oder eine feinere Zeitauflösung in Monitoring entscheidend.

DSCP für Voice/Video: bewährte Zuordnungen und typische Missverständnisse

Viele Umgebungen nutzen konventionelle DiffServ-Modelle: Voice als EF, Video als AF (oder eigener Video-PHB), Signalisierung als CS/AF niedrig, Best Effort als DSCP 0. Das ist sinnvoll, aber Sie müssen sicherstellen, dass alle Hops dieselbe Interpretation nutzen.

• Voice (RTP): häufig EF gemäß RFC 3246
• Video: häufig AF-Klassen gemäß RFC 2597
• Signalisierung: oft CS/AF niedrig, aber konsistent und nicht in Best Effort „versenkt“

Ein typisches Missverständnis ist, dass „EF“ automatisch „keine Drops“ bedeutet. EF ist ein Per-Hop Behavior, kein Garant. Wenn die Priority Queue falsch dimensioniert ist oder die Gesamtlast zu hoch ist, werden auch EF-Pakete verworfen.

Overlay- und Tunnel-Sonderfälle: Wenn QoS am falschen Header matcht

In modernen Netzen läuft Voice/Video oft über Overlays: SD-WAN, IPsec, GRE, VXLAN. Dann entscheidet sich, ob QoS am Underlay oder am Overlay greift. Häufig sind zwei Fehlerklassen:

• Inner DSCP korrekt, Outer DSCP falsch: Underlay-Policy matcht Outer und sieht alles als Best Effort.
• Outer DSCP korrekt, aber irgendwo genullt: Provider/Firewall setzt Outer DSCP zurück, obwohl Edge korrekt markiert.

Die Lösung ist, bewusst festzulegen, wo klassifiziert wird (vor oder nach Encap) und wie DSCP propagiert wird. Für den Praxisnachweis ist ein Capture am Tunnel-Interface und am physischen Egress hilfreich.

WLAN-Spezifik: DSCP Trust endet oft an der Luftschnittstelle

Voice/Video läuft sehr häufig über WLAN. Dort gilt nicht direkt DSCP, sondern WMM-Kategorien (Voice/Video/Best Effort/Background). Ein sauberer QoS-Designpunkt ist die konsistente Zuordnung DSCP↔WMM↔802.1p. Wenn diese Zuordnung nicht passt, wird Voice im WLAN wie Best Effort behandelt, unabhängig davon, wie perfekt das LAN/WAN konfiguriert ist.

• Indiz: VoIP über LAN ok, über WLAN schlecht.
• Nachweis: Controller/AP zeigt WMM-Klassifikation; DSCP kommt am AP an, wird aber in falsche WMM-Klasse gemappt.
• Fix-Richtung: DSCP-to-WMM Mapping und Trust-Boundary am WLAN-Edge konsistent setzen.

Evidence Pack: Was Sie im Voice/Video QoS Incident immer sichern sollten

QoS-Diskussionen werden schnell emotional („Netzwerk ist schuld“). Mit einem kleinen, standardisierten Evidence Pack können Sie objektiv arbeiten:

• 3–5 Beispiel-Flows: IPs/Ports/Protokoll (RTP/UDP, SRTP, QUIC), Zeitpunkt, betroffener Standort.
• DSCP-Wahrheit: DSCP am Endgerät-nahen Hop und am WAN-Egress (idealerweise per Capture oder Telemetrie).
• Policy Counters: Match-Hits pro Klasse, Queue Stats (Occupancy/Drops), Policer Drops/Remarks.
• Interface Counters: Errors, output drops, queue drops, Microburst-Indizien.
• Pfadkontext: WLAN oder LAN, Tunnel/Overlay, ECMP/LAG, Provider-Rate und Shaper-Rate.

Runbook-Baustein: QoS für Voice/Video in 15 Minuten debuggen

• Minute 0–3: Symptomprofil: Audio/Video betroffen? Nur WLAN oder auch LAN? Loss/Jitter/Delay? 3 konkrete Flows sichern.
• Minute 3–6: DSCP beweisen: Capture/Telemetrie am Trust-Punkt. DSCP korrekt? Inner/Outer Header bei Tunneln prüfen.
• Minute 6–9: Trust/Remarking prüfen: Wo wird DSCP überschrieben (WLAN, Firewall, Provider, Tunnel-Endpunkt)?
• Minute 9–12: Queue/Scheduling prüfen: EF in Priority Queue? Queue Drops? Priority begrenzt? Video-Klasse ausreichend gewichtet?
• Minute 12–15: Policer/Shaper prüfen: Policer Drops/Remarks? Shaper-Rate korrekt (Provider + Overhead)? Congestion-Lokus bestimmen und minimalen Fix anwenden, danach Verifikation mit denselben Flows.

Nachhaltige Korrekturen: QoS stabil und betrieblich „langweilig“ machen

• Trust-Boundaries dokumentieren: Wo wird markiert, wo wird trusted, wo wird normalisiert?
• Klassenmodell vereinheitlichen: Wenige, klar definierte Klassen (Voice, Video, Business, Best Effort) statt komplexer Wildwuchs.
• Priority Queue begrenzen: Voice priorisieren, aber Rate-Limit/Policer auf Priority, um Starvation zu vermeiden.
• Video bewusst behandeln: Video braucht oft mehr Bandbreite und toleriert weniger Policer; Bursts einplanen.
• Shaping an Engpässen: Egress-Shaping auf reale Raten, inklusive Overhead; Drops so weit wie möglich an den Rand verlagern.
• Monitoring auf QoS-KPIs: Nicht nur Bandbreite, sondern Queue Occupancy, Drops pro Klasse, Remarking-Events, Jitter/Loss pro Site.
• WLAN QoS end-to-end: DSCP↔WMM↔LAN konsistent, Querier/Snooping/Multicast nur wenn relevant.

Weiterführende Quellen für Standards und Praxis

• RFC 2474 und RFC 2475 für DSCP/DiffServ Grundlagen
• RFC 3246 für Expedited Forwarding (EF), häufiges Voice-PHB
• RFC 2597 für Assured Forwarding (AF), oft für Video/Business-Klassen
• Wireshark Dokumentation für DSCP/ToS-Analyse, RTP/UDP-Forensik 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.