WAN QoS konfigurieren: Priorisierung über langsame Leitungen

Wer ein Standortnetz mit einem 10- oder 20-Gbit/s-LAN betreibt, erlebt beim Wechsel ins WAN oft einen harten Realitätscheck: Über langsame Leitungen wie VDSL, LTE/5G, Richtfunk oder schmalbandige MPLS-Anschlüsse entstehen schnell Warteschlangen, Paketverlust, hohe Latenz und spürbarer Jitter. Genau hier wird das Thema WAN QoS konfigurieren entscheidend. Wenn sich Backups, Cloud-Synchronisation, Updates und gleichzeitige Echtzeitkommunikation (VoIP, Videokonferenzen, VDI) eine begrenzte Leitung teilen, reicht „Best Effort“ nicht mehr aus. QoS sorgt nicht für zusätzliche Bandbreite, sondern steuert, welcher Verkehr bei Engpässen bevorzugt behandelt wird, wie Warteschlangen aufgebaut sind und wie Burst-Traffic geglättet wird. Besonders über langsame Leitungen ist die richtige Priorisierung der Unterschied zwischen „Voice klingt sauber“ und „Telefonie bricht ein“. Dieser Leitfaden zeigt praxisnah, wie Sie QoS im WAN so aufbauen, dass kritische Anwendungen zuverlässig durchkommen: mit einem klaren Klassenmodell, konsistenten Markierungen (DSCP/CoS), einer passenden Trust Boundary, Low Latency Queue (LLQ) für Sprache und – in den meisten Fällen – Shaping am WAN-Uplink, damit der Router selbst die Congestion kontrolliert.

Warum WAN-QoS sich anders anfühlt als LAN-QoS

Im LAN sind Engpässe selten dauerhaft. Im WAN dagegen ist der Engpass meist „eingebaut“: Die Leitung ist langsamer als das interne Netz, und die Bandbreite ist häufig asymmetrisch (z. B. 250/40 Mbit/s). Sobald mehrere Datenströme parallel laufen, entstehen Warteschlangen. Ohne QoS werden Pakete in einer Default-Queue nach „first come, first served“ behandelt, was bei Echtzeitverkehr sofort hör- und spürbar ist.

• Latenz steigt durch Queueing, wenn zu viel Traffic gleichzeitig gesendet werden soll.
• Jitter entsteht, wenn Pakete ungleichmäßig aus Warteschlangen herauskommen.
• Paketverlust tritt auf, wenn Puffer voll sind oder Provider-Edges droppen.

WAN-QoS hat deshalb zwei Kernziele: Echtzeit- und kritischer Traffic soll bei Congestion bevorzugt werden, und der Router soll den Engpass aktiv kontrollieren, statt dass Drops unkontrolliert beim Provider entstehen.

Grundprinzip: QoS wirkt nur am Engpass

Ein häufiger Grund für „QoS bringt nichts“ ist die falsche Platzierung. QoS wirkt dort, wo Congestion entsteht. Über langsame Leitungen ist das fast immer die Ausgangsrichtung (Egress) am WAN-Uplink. Wenn Congestion jedoch bereits im Modem oder beim Provider-Edge entsteht, greifen lokale Warteschlangen nur eingeschränkt. Deshalb ist im WAN-Kontext Shaping so wichtig: Es sorgt dafür, dass der Router selbst zum Engpass wird und die Pakete kontrolliert in die Leitung einspeist.

Bausteine einer sauberen WAN-QoS-Strategie

Unabhängig vom konkreten Cisco-Modell (klassischer IOS Router, IOS XE, Integrated Services Router, Edge Router) folgt ein robustes WAN-QoS-Design typischerweise diesem Bauplan:

• Klassifizieren: Traffic wird erkannt (am besten per DSCP, alternativ per ACL/NBAR).
• Markieren: Falls nötig, DSCP am Rand setzen oder korrigieren (Trust Boundary).
• Queueing/Scheduling: LLQ für Voice, garantierte Bandbreite für wichtige Klassen, Default fair behandeln.
• Shaping: Ausgangsrate so begrenzen, dass der Router Congestion kontrolliert.
• Policing: Untrusted oder Bulk-Traffic begrenzen oder herabstufen, um Missbrauch zu verhindern.
• Verifizieren: Counters, Drops und Queue-Statistiken prüfen, nicht nur „Konfig vorhanden“.

Als Einstieg in Cisco QoS und MQC eignet sich der Anchor-Text Cisco QoS Übersicht. Für DiffServ/DSCP-Grundlagen ist der Anchor-Text RFC 2474 (DiffServ) hilfreich.

Schritt 1: Klassenmodell für langsame Leitungen definieren

Über langsame Leitungen ist „weniger ist mehr“. Ein zu komplexes Modell führt zu Pflegeproblemen und erschwert Troubleshooting. Ein praxistauglicher Start für WAN-QoS umfasst oft fünf Klassen:

• VOICE (RTP): höchste Priorität, niedrige Latenz (LLQ)
• SIGNALING (SIP/Call-Control): wichtig, aber meist keine strikte Priority
• CRITICAL: geschäftskritische Apps (VDI, ERP, Transaktionen)
• DEFAULT: Best Effort
• SCAVENGER: Hintergrund/Bulk (Backups, Updates), bewusst gedrosselt

Wichtig ist, dass Sie die Klassen mit Ihrem Marking-Plan (DSCP) verbinden. Ein verbreitetes Muster ist Voice als DSCP EF, Signalisierung als CS3 und Scavenger als CS1. Entscheidend ist Konsistenz und ein klarer Owner für das Marking.

Schritt 2: Markierungen im WAN bewusst behandeln (Trust Boundary)

Im LAN kann man Markierungen oft „durchwinken“. Im WAN sollten Sie sehr bewusst entscheiden, welchen Markierungen Sie vertrauen. Ohne Trust Boundary kann jeder Client Traffic „hoch markieren“ und die Priority Queue verschmutzen. Bewährte Ansätze:

• Trusted Quellen: IP-Telefone, UC-Infrastruktur, bestimmte Netzwerkkomponenten, kontrollierte Server
• Untrusted Quellen: Clients, Gäste, IoT, unbekannte Endgeräte
• Edge-Markierung: Untrusted Traffic wird am WAN-Edge neu markiert oder auf Default gesetzt

Wenn Ihr WAN über Provider läuft, die DSCP nicht garantieren, kann es sinnvoll sein, Markierungen intern beizubehalten (für Ihre eigenen Queues), aber extern nicht als „SLA“ zu betrachten. Für Details und Plattformvarianten ist der Anchor-Text Cisco QoS Konfigurationsguides hilfreich.

Schritt 3: Klassifizierung mit Class Maps (DSCP-first)

Für WAN-QoS ist DSCP-basierte Klassifizierung meist am robustesten, weil sie unabhängig von Ports und dynamischen Protokolldetails funktioniert. Beispielkonzept:

configure terminal
class-map match-any VOICE
match dscp ef
class-map match-any SIGNALING
match dscp cs3
class-map match-any CRITICAL
match dscp af31
class-map match-any SCAVENGER
match dscp cs1
end

Wenn Markierungen nicht zuverlässig sind, können Sie ergänzend mit ACLs klassifizieren. Das ist jedoch wartungsintensiver, insbesondere bei dynamischen Ports (z. B. RTP). In vielen Designs ist daher „erst markieren, dann nach DSCP matchen“ die stabilere Route.

Schritt 4: Queueing und Priorisierung in der Child-Policy (LLQ für Voice)

Die eigentliche Priorisierung passiert in der Policy Map. Für Voice verwenden Sie typischerweise eine LLQ über priority. Entscheidend ist, dass LLQ begrenzt wird, damit sie andere Klassen nicht verdrängt. Über langsame Leitungen kann schon eine kleine falsche Markierungsmenge die LLQ „verstopfen“, wenn Trust zu großzügig ist.

Beispiel: Child-Policy für WAN-Out

configure terminal
policy-map WAN-CHILD
class VOICE
priority percent 10
class SIGNALING
bandwidth percent 5
class CRITICAL
bandwidth percent 20
class SCAVENGER
bandwidth percent 5
class class-default
fair-queue
end

Hinweis zur Dimensionierung: Prozentwerte beziehen sich auf die verfügbare Ausgangsrate (und in Parent/Child-Designs auf die Shaping-Rate). Bei sehr langsamen Leitungen ist es sinnvoll, Voice konservativ zu begrenzen und sicherzustellen, dass nur echter RTP-Traffic in dieser Klasse landet.

Schritt 5: Shaping als Parent-Policy (damit der Router der Engpass wird)

Über langsame Leitungen ist Shaping oft der wichtigste Baustein. Ohne Shaping entsteht Congestion häufig beim Provider-Edge oder im Modem, sodass Ihre interne LLQ nicht zuverlässig „vorne dran“ ist. Mit Shaping halten Sie die Sendeleistung knapp unter der realen Rate, damit der Router die Warteschlangen kontrolliert.

Beispiel: Parent-Policy mit Shape und Child-Policy

configure terminal
policy-map WAN-PARENT
class class-default
shape average 10000000
service-policy WAN-CHILD
end

Dann binden Sie die Parent-Policy am WAN-Interface in Ausgangsrichtung:

configure terminal
interface GigabitEthernet0/0
description WAN-Uplink 10 Mbit/s
service-policy output WAN-PARENT
end

Praxis-Tipp: Setzen Sie die Shaping-Rate häufig etwas unter die real verfügbare Bandbreite (z. B. 90–98 %), damit der Router die Congestion sieht. Bei DSL- oder LTE-Links kann die reale Rate schwanken; hier sind Messung und iterative Anpassung wichtig.

Schritt 6: Policing gezielt einsetzen (untrusted und Bulk kontrollieren)

Policing ist kein Ersatz für Shaping, aber ein sehr nützliches Werkzeug, um bestimmte Traffic-Arten zu begrenzen oder Markierungs-Missbrauch zu verhindern. Typische Szenarien im WAN:

• Untrusted EF verhindern: Wenn Clients Traffic als EF markieren, kann ein Policer EF begrenzen oder herabstufen.
• Scavenger drosseln: Backups/Updates sollen die Leitung nicht dominieren.
• Partner-/Gastnetze: Harte Obergrenzen pro Segment oder pro Klasse.

Beispiel: Scavenger hart begrenzen

policy-map WAN-CHILD
class SCAVENGER
police 1000000 conform-action transmit exceed-action drop

Bei sehr langsamen Leitungen kann es sinnvoll sein, Scavenger nicht nur mit „bandwidth“, sondern zusätzlich mit Policing zu begrenzen, damit Bulk-Traffic nicht in Peaks alles verdrängt. Alternativ kann überschüssiger Traffic herabgestuft (Remarking) statt gedroppt werden, sofern das Plattformfeature dies unterstützt und Ihr QoS-Ende-zu-Ende sauber ist.

Praxisbeispiel: Komplettes WAN-QoS-Profil für eine 5-Mbit/s-Leitung

Gerade bei sehr langsamen Leitungen sind Prioritäten und Limits extrem spürbar. Ein kompaktes Profil könnte so aussehen:

• Shaping auf 5.000.000 bps
• Voice LLQ 10 % (max. 0,5 Mbit/s)
• Signalisierung 5 %
• Critical 25 %
• Scavenger 5 % + optional Police
• Default fair-queue

Konzeptuell:

class-map match-any VOICE
match dscp ef
class-map match-any SIGNALING
match dscp cs3
class-map match-any CRITICAL
match dscp af31
class-map match-any SCAVENGER
match dscp cs1

policy-map WAN-CHILD
class VOICE
priority percent 10
class SIGNALING
bandwidth percent 5
class CRITICAL
bandwidth percent 25
class SCAVENGER
bandwidth percent 5
class class-default
fair-queue

policy-map WAN-PARENT
class class-default
shape average 5000000
service-policy WAN-CHILD

interface GigabitEthernet0/0
service-policy output WAN-PARENT

Diese Konfiguration ist bewusst schlank. In realen Umgebungen ergänzen Sie je nach Bedarf weitere Klassen (z. B. Video) oder spezielle Regeln für Management und Monitoring, halten das Modell aber so klein wie möglich.

Besonderheiten bei langsamen Leitungen: Fragmentierung, MTU und Overhead

Über langsame Links und insbesondere über Tunnel (IPsec, GRE, DMVPN) spielt Overhead eine größere Rolle. Zudem kann Path MTU Discovery bei restriktivem ICMP-Handling Probleme verursachen. Für WAN-QoS bedeutet das:

• Shaping-Rate sollte Overhead berücksichtigen, damit der Router nicht „zu hoch“ shaped.
• Tunnel können Markierungen beeinflussen (innerer vs. äußerer Header).
• Wenn große Transfers unerwartet brechen, ist oft MTU/PMTUD und nicht QoS die Ursache.

Eine bewährte Betriebsregel ist, ICMP nicht pauschal zu blockieren und WAN-/Tunnel-Overhead in die Shaping-Kalkulation einzubeziehen.

Verifikation: So prüfen Sie, ob WAN-QoS wirklich arbeitet

QoS ohne Verifikation ist ein Ratespiel. In Cisco MQC ist der wichtigste Befehl im Alltag:

show policy-map interface <WAN-INTERFACE>

Damit prüfen Sie:

• Hat die VOICE-Klasse Treffer (Packets/Bytes)?
• Gibt es Drops in der Priority Queue?
• Greift Shaping (Parent-Policy sichtbar, Rate plausibel)?
• Hat class-default auffällig viele Drops (Hinweis auf Congestion ohne passende Klassen)?
• Greift ein Policer (conform/exceed Statistiken)?

Ergänzend:

• show interfaces <WAN-INTERFACE> (Auslastung, Drops, Errors)
• show policy-map und show class-map (Definitionen prüfen)

Wenn Klassen keine Treffer haben, matcht Ihre Klassifizierung nicht: Markierung fehlt, Trust Boundary ist falsch, oder der Traffic läuft über einen anderen Pfad. In diesem Fall ist das Problem meist nicht „QoS“, sondern „Erkennung“.

Typische Fehler im WAN-QoS und wie Sie sie vermeiden

• Kein Shaping am WAN: Congestion passiert beim Provider, LLQ wirkt unzuverlässig.
• Policy am falschen Interface: QoS ist konfiguriert, aber nicht am echten Engpass gebunden.
• Falsche Richtung: Queueing/LLQ inbound statt outbound angewendet.
• Marking inkonsistent: Voice ist nicht EF, oder EF wird von untrusted Clients missbraucht.
• LLQ zu groß oder unlimitiert: Andere Klassen droppen stark, Netz wirkt instabil.
• Zu viele Klassen: Komplexität steigt, Pflegefehler häufen sich, Troubleshooting wird langsam.

Best Practices: WAN-Priorisierung dauerhaft betreibbar machen

• Einheitlicher DSCP-Plan: Dokumentieren Sie, welche Anwendungen welche Markierung erhalten.
• Trust Boundary definieren: Trusted nur dort, wo es kontrollierbar ist (Telefon/UC), sonst remarken.
• Shaping als Standard: Über langsame Leitungen lieber shaped egress als „nur Queueing“.
• LLQ begrenzen: Priority Queue immer limitieren und „EF sauber halten“.
• Scavenger bewusst behandeln: Bulk-Traffic drosseln, damit er nicht alles andere verdrängt.
• Schrittweise einführen: Erst Marking/Klassifizierung verifizieren, dann Bandbreitenanteile optimieren.
• Monitoring: Drops, Queue-Depths, Voice-Jitter/Loss in UC-Systemen oder Monitoring-Tools beobachten.

Für vertiefende Cisco-spezifische Beispiele, Plattformunterschiede und Konfigurationsdetails sind die Anchor-Texte Cisco QoS Konfigurationsguides und Cisco QoS Übersicht nützliche Startpunkte.

Praxis-Checkliste: WAN QoS konfigurieren über langsame Leitungen

• Ist der Engpass identifiziert (WAN-Uplink, Tunnel, Provider-Edge)?
• Gibt es ein kleines, klares Klassenmodell (Voice, Signaling, Critical, Default, Scavenger)?
• Sind Markierungen (DSCP) konsistent und ist die Trust Boundary definiert?
• Ist LLQ für Voice aktiv und begrenzt (percent oder Rate)?
• Ist Shaping aktiv, sodass der Router die Congestion kontrolliert (Parent/Child)?
• Werden Bulk-Flows (Backups/Updates) gedrosselt oder herabgestuft?
• Wurde die Wirkung verifiziert (show policy-map interface, Drops, Counters)?
• Gibt es Monitoring für Jitter/Loss und regelmäßige Reviews der QoS-Werte?

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.