Das Blueprint „VPN QoS“ beschreibt, wie Sie Quality of Service über IPSec- und SD-WAN-Tunnel so umsetzen, dass DSCP-Markierungen erhalten bleiben und Echtzeitverkehr (Voice, Video, WebRTC, Contact Center, SIP/IMS-nahe Flows) auch über verschlüsselte Overlay-Pfade stabil priorisiert wird. In der Praxis scheitert VPN-QoS selten daran, dass „keine Policy existiert“, sondern an Details: DSCP wird im Tunnel nicht auf den Outer Header kopiert, der Underlay-Link sieht nur Best Effort; die QoS-Policy ist am falschen Interface oder in der falschen Richtung gebunden; Shaping fehlt, sodass Congestion im Provider-Buffer statt in den eigenen Queues entsteht; oder ein SD-WAN-Stack ändert bei App-Steering den Pfad, ohne dass die QoS-Semantik mitwandert. Hinzu kommt: IPSec-Encapsulation erhöht Overhead, reduziert effektive Nutzrate und verschärft Microbursts – alles Faktoren, die Echtzeitqualität beeinträchtigen können, wenn sie im Design nicht berücksichtigt werden. Dieses Blueprint zeigt praxisnah, wie Sie DSCP Preservation über IPSec/SD-WAN erreichen, wie Sie Trust Boundaries im Overlay definieren, wo Shaping Points sitzen müssen, welche HQoS-Patterns sich bewährt haben und wie Sie mit Telemetry und Tests beweisen, dass „VPN QoS“ nicht nur konfiguriert, sondern wirksam ist.
Warum VPNs QoS so oft unsichtbar machen
Ein VPN-Tunnel kapselt Pakete. Für das Underlay (Internet, MPLS, Metro, LTE/5G) sind die inneren IP-Header häufig nicht sichtbar oder werden nicht für QoS ausgewertet. Entscheidend wird daher der Outer Header: dessen DSCP/CoS/MPLS-TC bestimmt, in welche Underlay-Queue ein Paket landet. Wenn Outer DSCP nicht gesetzt ist oder auf 0 bleibt, läuft selbst perfekt markierter Voice-Traffic im Underlay als Best Effort. Das führt zum klassischen Fehlerbild: „Im LAN ist DSCP EF korrekt, aber über das VPN ist Voice schlecht.“
- Encapsulation: Innerer DSCP ist für das Underlay oft irrelevant.
- Outer Header entscheidet: QoS-Queues im Underlay sehen nur Outer DSCP/CoS.
- Default-Verhalten: viele Plattformen kopieren DSCP nicht automatisch.
- Fehlinterpretation: „Policy greift“ lokal, aber der Engpass liegt im Underlay ohne passende Markierung.
DSCP Preservation: Inner ↔ Outer – die zentrale Designentscheidung
DSCP Preservation bedeutet im VPN-Kontext zwei Dinge: Erstens muss der DSCP-Wert im inneren Paket (vom Client oder vom Edge gesetzt) erhalten bleiben, damit Sie im Overlay klassifizieren können. Zweitens muss dieser DSCP-Wert – je nach Architektur – auf den Outer Header kopiert oder in eine konsistente Outer-Markierung übersetzt werden, damit das Underlay korrekt priorisiert. In der Praxis haben Sie drei grundlegende Strategien, die Sie bewusst auswählen sollten.
- Copy-Strategie: Inner DSCP wird direkt auf Outer DSCP kopiert (schnell, konsistent, aber nur sicher bei sauberer Trust Boundary).
- Map-Strategie: Inner DSCP wird in ein definiertes Outer-Set gemappt (Whitelist), um Missmarking zu verhindern.
- Rewrite-Strategie: Outer DSCP wird unabhängig vom Inner DSCP basierend auf Policy/Traffic-Klasse gesetzt (z. B. App-ID im SD-WAN).
Trust Boundary im VPN: Warum „Copy“ ohne Regeln gefährlich sein kann
Wenn Sie Inner DSCP blind auf Outer kopieren, kann jeder Client theoretisch Premium-Markierungen erzeugen. In Enterprise- und Telco-nahen Umgebungen ist das ein Governance-Problem: Premium-Queues sind begrenzt, Missmarking kann Echtzeit verdrängen. Das Blueprint setzt daher auf eine klare Trust Boundary am Tunnel-Edge: Nur definierte Quellen dürfen Inner DSCP setzen, oder die Edge normalisiert Markierungen auf eine Whitelist. Erst danach ist Copy oder Mapping auf Outer DSCP sinnvoll.
- Trusted Sources: IP-Telefone, Room Systems, gemanagte Endpoints, definierte UC-Gateways.
- Untrusted Sources: BYOD, Gäste, unbekannte Subnetze; Marking wird normalisiert.
- Whitelist DSCP: nur definierte DSCP-Werte werden akzeptiert und weitergegeben.
- Guardrails: Premiumklassen dürfen nicht unbegrenzt wachsen; Limits sind Pflicht.
IPSec-Overhead und Realrate: Warum Shaping im VPN wichtiger wird
IPSec erhöht Paketgrößen durch zusätzliche Header. Dadurch sinkt die effektive Nutzrate des Links, und Microbursts werden wahrscheinlicher, weil mehr Bytes pro „Nutzpaket“ über den gleichen Engpass müssen. Wenn Sie weiterhin auf die Vertragsrate shapet oder gar nicht shapet, kann Congestion im Provider-Buffer oder im CPE entstehen. Dann wird QoS unkontrollierbar, und Echtzeit leidet trotz richtiger Klassen. Ein VPN QoS Blueprint fordert daher Realrate-Shaping am Egress des Underlays, unter Berücksichtigung des Tunnel-Overheads.
- Overhead-Kalkulation: Encapsulation reduziert Nutzrate; Shaper muss darunter liegen.
- Uplink-Fokus: Upstream ist oft der Engpass; dort zuerst shapen.
- Controlled Congestion: Queueing soll in Ihren Queues sichtbar sein, nicht im Provider-Modem.
- HQoS: Gesamtshaper für Underlay + Klassen-Queues darunter.
HQoS Pattern im VPN: Parent Shaper auf Underlay, Child Klassen für Overlay-Traffic
Ein bewährtes Pattern ist hierarchisches QoS am Underlay-Egress: Ein Parent-Shaper begrenzt die Gesamtrate auf Realrate (inkl. Overhead), darunter klassifizieren Sie Traffic in VOICE/MEDIA/SIGNAL/BE/BULK und schedulen entsprechend. Entscheidend ist, dass die Klassifizierung entweder auf dem inneren DSCP (Overlay-Sicht) oder auf Outer DSCP (Underlay-Sicht) basiert – je nachdem, wo Sie ansetzen. In der Praxis ist es oft stabil, inner DSCP für die Klassifizierung zu nutzen und Outer DSCP konsistent zu setzen, damit das Underlay passende Queues verwendet.
- Parent: Shaper auf Realrate (Underlay), damit Congestion kontrolliert entsteht.
- Child VOICE: strikt priorisiert, aber begrenzt (LLQ mit Ceiling).
- Child MEDIA: hohe Priorität, limitiert, getrennt von Voice.
- Child SIGNAL: kleine, stabile Klasse für SIP/Control/DTLS/ICE, damit Sessions stabil bleiben.
- Child BULK: gedrosselt, trägt Delay/Drops unter Congestion.
SD-WAN Besonderheiten: App-Erkennung, Pfadwechsel und QoS-Semantik
SD-WAN bringt Vorteile für Echtzeit, weil es Pfade nach Jitter/Loss/RTT steuern kann. Gleichzeitig entstehen neue QoS-Risiken: Ein App-ID-Classifier kann sich durch neue Client-Versionen ändern; Pfadwechsel kann dazu führen, dass ein Flow plötzlich über ein Underlay läuft, dessen QoS-Profile anders sind; oder die SD-WAN-Overlay-Marking-Policy setzt Outer DSCP nicht konsistent auf allen Transporten. Ein VPN QoS Blueprint definiert deshalb pro Underlay ein konsistentes QoS-Profil und sorgt dafür, dass SD-WAN-Policies diese Profile einheitlich nutzen.
- Per-Underlay QoS: Internet, MPLS, LTE/5G erhalten jeweils passende Shaper und Queue-Profile.
- Consistent Marking: Outer DSCP muss je Underlay gleich semantisch interpretiert werden.
- Steering Guardrails: Echtzeit darf nicht auf Pfade wechseln, die keine QoS-Reserven haben.
- Fallback Awareness: bei UDP-Blockaden kann WebRTC auf TCP/TLS wechseln; Klassifizierung muss das berücksichtigen.
Wo VPN QoS „wirklich“ scheitert: die häufigsten Bruchstellen
In der Praxis wiederholen sich die Fehlerbilder. Das Blueprint macht diese Bruchstellen bewusst sichtbar, damit Sie sie in Reviews und Compliance Checks systematisch abfangen können.
- Outer DSCP = 0: Inner Marking ist korrekt, aber Underlay sieht Best Effort.
- Policy am falschen Interface: QoS auf Tunnel-Interface, Engpass ist Underlay-Egress (oder umgekehrt).
- Kein Shaping: Congestion im Provider-Buffer; Router-Queues bleiben „leer“, QoS wirkt nicht.
- Policer trifft Echtzeit: Loss-Spikes ohne Queue-Wachstum; Token-Bucket zu hart.
- Mapping Drift: DSCP→Queue ist je Plattform/Standort unterschiedlich; Multi-Vendor-Interop bricht.
- Virtualisierte Edges: vSwitch/CPU Scheduling erzeugt Jitter, obwohl Linkauslastung moderat ist.
Monitoring und Evidence: VPN QoS messbar machen
VPN QoS braucht Metriken auf beiden Ebenen: Overlay/Service-Qualität und Underlay/Queueing. Für Echtzeit sind Queue Delay/Depth, Per-Class Drops und Drop Reasons an den Underlay-Egress-Interfaces die wichtigsten Frühindikatoren. Ergänzend liefern QoE-KPIs (RTP/WebRTC Jitter/Loss, MOS, Quality Events) den Nutzerbezug. Ein starkes Betriebsmodell korreliert beides: Wenn Voice-Queue Delay steigt, sollte sich Jitter verschlechtern; wenn Policer Drops auftreten, sieht man Loss-Spikes ohne Queue-Wachstum.
- Queue Delay 95p/99p: VOICE/MEDIA am Underlay-Egress als Frühwarnsignal.
- Per-Class Drops: Voice Drops = Incident, BE/Bulk Drops = erwartbar unter Congestion.
- Drop Reasons: Tail Drop vs. Policer vs. Buffer Exhaustion für schnelle Root Cause.
- Shaper Headroom: zeigt dauerhafte Sättigung und Kapazitätsrisiko pro Underlay.
- QoE KPIs: RTP/RTCP Jitter/Loss, MOS-Trends, WebRTC getStats als Realitätscheck.
Validation: Wie Sie DSCP Preservation und QoS-Wirkung beweisen
Ein VPN QoS Blueprint ist erst dann produktionsreif, wenn Sie es testen können. Es gibt zwei zentrale Nachweise: (1) DSCP Preservation (Inner und Outer) und (2) QoS-Wirkung unter Congestion. Der erste Nachweis lässt sich durch gezielte Testflüsse mit definiertem DSCP erbringen, die am Tunnel-Edge und am Underlay geprüft werden. Der zweite Nachweis ist der Congestion-Proof: Bulk saturiert den Uplink, Voice bleibt stabil.
- DSCP Proof: definierter DSCP im Inner, erwarteter DSCP im Outer, konsistentes DSCP→Queue Mapping.
- Congestion Proof: Bulk füllt Underlay, Voice Queue Delay bleibt niedrig, Voice Drops bleiben 0.
- Regression: Tests wiederholen nach SD-WAN/Firewall/Provider-Changes, um Drift früh zu erkennen.
Rollout ohne Risiko: Canary für VPN QoS
VPN QoS kann große Blast Radii haben, weil Tunnel oft viele Standorte tragen. Deshalb ist ein progressiver Rollout Pflicht: Start mit wenigen Sites/Edges, Control Group zum Vergleich, harte Stop-Regeln (Voice Drops, Policer Drops, Delay 99p) und ein schneller Rollback auf Template-Vorversion. Wichtig ist, auch echte Peak-Fenster abzudecken, weil viele VPN-QoS-Probleme erst bei Meeting-Starts oder Backup-Fenstern sichtbar werden.
- Canary Auswahl: low-risk, repräsentativ, high-complexity (WLAN/RTC/hoher Upload).
- Stop-Regeln: Voice Drops, Policer Drops, Voice Delay 99p, Default/Unmatched Drift.
- Rollback: versionierte Policies, atomarer Switch, KPI-Rückkehr zur Baseline als Nachweis.
Pragmatische Blueprint-Checkliste „VPN QoS“
- Klassenmodell: VOICE/MEDIA/SIGNAL/BE/BULK klein und konsistent, Media getrennt von Voice.
- Trust Boundary: DSCP nur von vertrauenswürdigen Quellen übernehmen; Whitelist/Normalize gegen Missmarking.
- DSCP Preservation: Inner→Outer Copy oder Mapping definiert, konsistent pro Underlay.
- Realrate-Shaping: Underlay-Egress shapen, Overhead durch IPSec berücksichtigen, Congestion kontrollieren.
- HQoS: Parent Shaper + Child Klassen, Voice strikt priorisiert aber begrenzt, Bulk gedrosselt.
- Interop: DSCP→Queue Mapping über Vendoren und Standorte hinweg standardisieren und prüfen.
- Monitoring: Queue Delay/Depth, Per-Class Drops, Drop Reasons, Shaper-Headroom und QoE-KPIs korrelieren.
- Validation: DSCP-Proof + Congestion-Proof als Regression Suite.
- Canary Rollout: progressiv ausrollen, Guardrails, schneller Rollback.
