Eine QoS-Fehlkonfiguration beheben Sie, indem Sie zuerst die Verkehrsklassifizierung prüfen, dann DSCP- oder CoS-Markierungen entlang des gesamten Pfades verfolgen und schließlich Warteschlangen, Bandbreitenreserven und Policer an jeder Schnittstelle angleichen. Fehler entstehen fast immer durch inkonsistente Markierungen zwischen Endgerät, Switch, Router und WAN.
Symptome
- VoIP-Anrufe stottern oder brechen ab, obwohl die reine Bandbreite ausreichend ist
- Videokonferenzen zeigen Pixelblöcke, Ruckler oder plötzliche Auflösungsreduzierung
- Hohe Jitter-Werte (>30 ms) und Paketverluste in Echtzeitanwendungen
- Kritische Anwendungen werden langsam, sobald Backups oder Downloads laufen
- QoS-Zähler an der WAN-Schnittstelle zeigen Drops in der Prioritätswarteschlange
Häufige Ursachen
Inkonsistente DSCP- oder CoS-Markierung
Endgeräte markieren Pakete mit EF oder AF41, doch ein Trust-Boundary-Fehler auf dem Access-Switch überschreibt die Werte auf 0. Ab dieser Stelle behandelt das Netzwerk den Verkehr als Best-Effort.
Falsche Bandbreitenreservierung
Die Priority-Queue erhält mehr Bandbreite, als der WAN-Link physisch tragen kann, oder deutlich zu wenig für die tatsächliche Anzahl gleichzeitiger Sprachströme. Beides führt zu Tail Drops.
Widersprüchliche Class-Maps und Policies
Mehrere Access-Listen greifen auf denselben Datenverkehr zu und ordnen ihn unterschiedlichen Klassen zu. Die zuerst gematchte Regel gewinnt, was oft nicht die beabsichtigte ist.
QoS nicht auf der Engpass-Schnittstelle aktiv
QoS wirkt nur dort, wo Pakete in eine Warteschlange gehen, also am tatsächlichen Bottleneck. Ist die Policy auf einem LAN-Interface statt am WAN-Uplink gebunden, hat sie keinerlei Effekt.
ISP ignoriert Markierungen
Viele Provider setzen DSCP am Eingang auf 0 zurück, wenn kein Business-SLA mit QoS-Transparenz gebucht ist. Priorisierung im eigenen Netz nützt dann nur bis zum CE-Router.
Schritt-für-Schritt-Lösung
- Baseline messen: Jitter, Latenz und Paketverlust dokumentieren
Bevor Sie Konfigurationen ändern, brauchen Sie belastbare Zahlen. Führen Sie über 15 Minuten iperf3 mit UDP-Last parallel zu einem VoIP-Testcall aus und protokollieren Sie Jitter, Verlustrate und Round-Trip-Zeit. Ohne Baseline lässt sich später nicht beurteilen, ob eine Änderung tatsächlich geholfen hat. - Verkehr klassifizieren und tatsächliche Markierungen prüfen
Spiegeln Sie den Uplink-Port per SPAN auf einen Analyzer und öffnen Sie eine Wireshark-Aufzeichnung. Filtern Sie nach ip.dsfield.dscp und vergleichen Sie die Werte mit Ihrem Design: VoIP-Payload sollte EF (46) tragen, Signalisierung CS3 (24), interaktives Video AF41 (34). Abweichungen zeigen sofort, wo die Trust-Kette bricht. - Trust Boundary am Access-Switch korrekt setzen
An Access-Ports, an denen IP-Telefone hängen, muss der Switch der Markierung des Telefons vertrauen, aber der Markierung eines dahinter angeschlossenen PCs nicht. Auf Cisco-Plattformen erreichen Sie das über mls qos trust device cisco-phone bzw. eine Service-Policy, die PC-Verkehr neu klassifiziert. - Class-Maps und Policy-Maps auf Konflikte prüfen
Listen Sie alle aktiven Klassen mit show policy-map interface auf und achten Sie auf überlappende ACL-Treffer. Konsolidieren Sie doppelte Regeln, ordnen Sie spezifischere Matches vor allgemeineren an und stellen Sie sicher, dass class-default nur den Rest trägt, nicht versehentlich VoIP. - Warteschlangen und Bandbreiten am WAN-Ausgang dimensionieren
Am tatsächlichen Engpass, meist dem WAN-Uplink, weisen Sie der Priority-Queue nicht mehr als 33 Prozent der garantierten Linkrate zu. Rechnen Sie pro G.711-Anruf rund 100 kbit/s inklusive Overhead. Setzen Sie ein Shape Average auf die vom ISP zugesicherte CIR, damit die Queues überhaupt greifen. - WAN-seitige DSCP-Erhaltung mit dem Provider klären
Fragen Sie beim ISP schriftlich nach, ob DSCP-Bits im Transit erhalten bleiben oder überschrieben werden. Bei MPLS-Diensten gibt es meist ein CoS-Mapping, das Sie mit dem Provider abstimmen müssen. Ohne diese Zusage endet Ihre QoS am eigenen CE-Router. - Änderungen verifizieren und Baseline erneut messen
Wiederholen Sie den Belastungstest aus Schritt 1 mit identischen Parametern. Vergleichen Sie Drop-Zähler pro Klasse mit show policy-map interface vor und nach der Änderung. Erst wenn Jitter und Verlust unter den Zielwerten liegen und die Prioritätsklasse keine Drops mehr zeigt, gilt der Fix als bestätigt.
Typische Anwendungsklassen mit empfohlener DSCP-Markierung und Zielwerten
| Verkehrstyp | DSCP | Max. Jitter | Max. Paketverlust |
|---|---|---|---|
| VoIP-Sprachpayload (RTP) | EF (46) | 30 ms | 1 % |
| Sprachsignalisierung (SIP) | CS3 (24) | nicht kritisch | 1 % |
| Interaktives Video | AF41 (34) | 50 ms | 1 % |
| Geschäftsanwendungen (ERP, DB) | AF31 (26) | nicht kritisch | 0,5 % |
| Bulk-Traffic (Backup, Update) | AF11 (10) | nicht relevant | toleriert |
| Scavenger / P2P | CS1 (8) | nicht relevant | toleriert |
| Best Effort (Rest) | 0 | nicht relevant | toleriert |
So beugen Sie vor
- QoS-Design dokumentieren: DSCP-Werte, Klassen und Bandbreiten je Standort in einer Referenztabelle
- Trust Boundaries konsequent am Access-Layer setzen, nie im Core
- Änderungen an Policies im Change-Management mit Vorher-Nachher-Messung erfassen
- Regelmäßig Drop-Zähler der Prioritätsklassen auslesen und in das Monitoring aufnehmen
Häufige Fragen
Warum bleibt VoIP schlecht, obwohl QoS aktiv ist?
In den meisten Fällen greift die Policy nicht dort, wo tatsächlich Pakete verworfen werden. Prüfen Sie, ob die Service-Policy am WAN-Ausgangsinterface gebunden ist und ob ein Shaper die Linkrate exakt auf die CIR des Providers begrenzt. Ohne Shaping puffert der ISP-Router und Ihre Priorisierung wirkt nicht.
Muss ich QoS auch im LAN mit 1 Gbit/s aktivieren?
Im ruhigen Betrieb selten nötig, in Lastspitzen jedoch schon. Sobald ein Server mit 10 Gbit/s in einen 1-Gbit/s-Access-Port sendet oder ein Backup den Uplink füllt, entstehen Mikroburst-Drops. Eine minimale Klassifizierung mit Trust-DSCP am Access-Layer schadet nie und schützt Echtzeitverkehr.
Wie erkenne ich, ob der ISP meine DSCP-Bits überschreibt?
Setzen Sie eine Testquelle mit definiertem DSCP-Wert (etwa EF) und messen Sie am entfernten Standort mit Wireshark oder tcpdump, welcher Wert ankommt. Kommt konsistent 0 an, hat der Provider die Bits am Ingress remarkiert. Klären Sie dann, ob ein CoS-fähiger Tarif gebucht werden kann.
Lassen Sie Ihr QoS-Design von unseren Netzwerkspezialisten prüfen und dokumentieren.