QoS für VPN Traffic ist in der Praxis oft der Punkt, an dem „saubere“ QoS-Konzepte scheitern: Innerhalb des LANs sind DSCP-Markierungen korrekt, Voice/Video laufen stabil – doch sobald der Verkehr in einen Tunnel (IPsec, GRE, DMVPN, SD-WAN-Overlay) geht, wirken Prioritäten plötzlich nicht mehr. Der Grund ist fast immer derselbe: Im Underlay werden Pakete nach dem Outer Header behandelt, während die ursprünglichen DSCP-Werte im Inner Header stecken – und damit für Router, Provider und Carrier-Queues unsichtbar werden. Genau deshalb ist die zentrale Designentscheidung bei QoS für VPN Traffic: DSCP Preservation vs. Re-Marking im Tunnel. Preservation bedeutet, dass Sie das innere Marking erhalten und (wenn nötig) in den Outer Header propagieren, damit Underlay-QoS greifen kann. Re-Marking bedeutet, dass Sie Markierungen am Tunnel-Endpunkt bewusst neu setzen oder normalisieren – typischerweise aus Governance- und Sicherheitsgründen. Beide Ansätze sind valide, aber sie haben unterschiedliche Risiken: Blindes Preservation kann Premium-Queues durch Missmarking fluten; aggressives Re-Marking kann legitime Echtzeit-Streams degradieren und QoE verschlechtern. Ein professionelles VPN-QoS-Design kombiniert daher eine klare Trust Boundary, ein schlankes Klassenmodell, definierte Copy-/Map-Regeln (inner↔outer), Shaping am echten Engpass und Monitoring, das Queue-Delay, Drops und Marking-Integrität entlang des Tunnels sichtbar macht.
Warum VPN-Traffic QoS „kaputtmachen“ kann: Inner vs. Outer Header
Die meisten VPN- und Overlay-Technologien kapseln den ursprünglichen Traffic (Inner Packet) in ein neues Transportpaket (Outer Packet). Router im Underlay treffen QoS-Entscheidungen typischerweise anhand des Outer IP-Headers (DSCP) und nicht anhand des inneren DSCP. Wenn der Outer DSCP nicht gesetzt ist oder vom Provider ignoriert wird, landet selbst perfekt markierter Echtzeitverkehr in Best Effort Queues. Damit ist nicht das QoS-Konzept falsch – das Marking ist nur an der falschen Stelle.
- Inner DSCP: beschreibt die Serviceklasse des ursprünglichen Verkehrs (z. B. Voice, Video, Business).
- Outer DSCP: steuert Underlay-Queueing; ohne korrekten Outer DSCP ist Underlay-QoS blind.
- Encapsulation: IPsec/GRE fügt Overhead hinzu und verändert MTU und effektive Bitraten.
- Konsequenz: QoS muss „tunnelfähig“ designt werden, nicht nur LAN-intern.
DSCP Preservation: Was „Preserve“ im VPN-Kontext wirklich bedeutet
DSCP Preservation bedeutet zunächst, dass das innere DSCP beim Encapsulieren nicht verloren geht. In der Praxis reicht das allein jedoch nicht aus, weil Underlay-Router das innere DSCP nicht sehen. Ein vollständiger Preservation-Ansatz umfasst daher zwei Ebenen: (1) Inner DSCP bleibt erhalten, (2) Outer DSCP wird aus dem inneren DSCP abgeleitet (Copy/Propagate), sodass die Underlay-Geräte die gleiche Klassenbehandlung anwenden können. Zusätzlich muss beim Decapsulieren sichergestellt sein, dass das innere Marking weitergeführt wird, damit nachfolgende Domänen (Campus, DC, MPLS) korrekt reagieren können.
- Preserve Inner: innere Markierung bleibt durch den Tunnel erhalten.
- Copy to Outer: Outer DSCP übernimmt die Serviceklasse, damit Underlay-QoS wirkt.
- Restore at Egress: nach Decap bleibt die innere Markierung konsistent für das Zielnetz.
- Messbarkeit: Ingress/Egress DSCP-Distribution prüfen, damit Copy wirklich passiert.
Re-Marking im Tunnel: Warum Provider und Enterprises bewusst neu markieren
Re-Marking bedeutet, dass Sie DSCP-Werte am Tunnel-Endpunkt bewusst neu setzen – unabhängig davon, was der innere Traffic „mitbringt“. Der Hauptgrund ist Governance: In Multi-Tenant- oder gemischten Umgebungen können Endgeräte und Applikationen Markings missbrauchen oder falsch konfigurieren. Wenn Sie blind „inner→outer“ kopieren, kann jeder Traffic als EF (Echtzeit) durch den Tunnel gehen und Premium-Queues fluten. Re-Marking setzt daher eine Trust Boundary: Nur definierte Anwendungen, Subnetze, VRFs oder Identitäten erhalten Premiumklassen, alles andere wird normalisiert oder in niedrigere Klassen degradiert.
- Trust Boundary: Tunnel-Endpunkt wird zur Policy-Grenze für Markings.
- Allowlist: nur definierte DSCP-Werte/Traffic-Typen dürfen Premiumklassen nutzen.
- Normalization: unbekannte oder unerwünschte Markings werden auf Best Effort gesetzt.
- Degradation: Überschreitungen werden ummarkiert statt gedroppt, um QoE nicht hart zu zerstören.
Der Kern-Trade-off: Transparenz vs. Kontrolle
DSCP Preservation ist transparent und end-to-end elegant, setzt aber voraus, dass Sie der Marking-Quelle vertrauen können und dass Underlay-Geräte das Outer Marking respektieren. Re-Marking bietet Kontrolle und Schutz, kann aber End-to-End Semantik verwässern, wenn es zu grob umgesetzt ist. Professionelle Designs kombinieren beide Ansätze: Preservation für definierte, vertrauenswürdige Klassen (z. B. Voice/Video aus gemanagten UC-Systemen), Re-Marking/Normalization für alles andere, und harte Budgets für strikt priorisierte Klassen.
- Preservation sinnvoll: kontrollierte Endpunkte, klare Marking-Standards, Managed Services.
- Re-Marking sinnvoll: BYOD, Multi-Tenant, unklare Applikationslandschaft, Missmarking-Risiko.
- Hybrid: Copy nur für erlaubte DSCPs, ansonsten normalize.
Welche Tunneltypen welche QoS-Fallen haben
Die Prinzipien sind gleich, aber die typischen Failure Patterns unterscheiden sich je nach Tunneltyp und Plattform. Besonders häufig: DSCP wird im Outer Header nicht gesetzt, wird auf dem Weg genullt, oder wird bei Crypto-Offload/Hardware-Pipeline nicht korrekt verarbeitet. Zusätzlich sind MTU-Probleme im Tunnelkontext sehr verbreitet, weil Overhead die Nutzpakete „zu groß“ macht.
- IPsec: Outer DSCP/ECN-Propagation muss explizit geklärt sein; Overhead und MTU sind kritisch.
- GRE: Marking-Copy ist oft einfacher, aber Underlay respektiert DSCP nicht immer (Internet).
- DMVPN/Hub-Spoke: Congestion sitzt oft am Hub; HQoS und Shaping am Hub sind entscheidend.
- SD-WAN Overlay: App-Awareness kann Re-Marking ersetzen, aber Underlay-Shaping bleibt Pflicht.
Underlay-Realität: DSCP wirkt im Internet oft nur begrenzt
Ein häufiger Irrtum: „Wir kopieren DSCP in den Outer Header, also wirkt QoS end-to-end.“ Das stimmt nur, wenn das Underlay QoS-Semantik respektiert (z. B. MPLS, Managed Carrier Ethernet, private Interconnects). Im öffentlichen Internet werden DSCP-Werte oft ignoriert oder überschrieben. Trotzdem ist Outer Marking nicht nutzlos: Es hilft auf der eigenen CPE-/Edge-Seite (erste Queue) und in kontrollierten Segmenten (z. B. Metro, Provider Access). Für echte Internetpfade ist Pfadwahl (SD-WAN), Shaping und lokale Queueing-Disziplin meist wichtiger als die Hoffnung auf globale DSCP-Behandlung.
- Managed Underlay: DSCP kann durchgängig wirken, wenn Provider es unterstützt.
- Public Internet: DSCP-Semantik ist nicht garantiert; QoS muss lokal wirken.
- Interconnects: Übergänge sind Congestion Domains; Shaping und Monitoring dort sind zentral.
Shaping und HQoS: Warum VPN-QoS ohne kontrollierte Queues scheitert
Die entscheidende Frage ist immer: Wo liegt die Queue? Wenn der Engpass beim Provider oder „im Internet“ liegt, sind Drops und Delay schwer steuerbar. Egress Shaping am Tunnel-Interface oder am WAN-Interface verlagert Congestion in den eigenen Einflussbereich. In Hub-and-Spoke Designs ist HQoS besonders wichtig: ein Parent-Shaper kontrolliert die Gesamtrate, Child-Queues priorisieren Voice/Video/Business innerhalb dieser Rate. Damit verhindern Sie, dass Bulk-Uploads den Tunnel aufblähen und Echtzeit jittert.
- Egress Shaping: knapp unter der realen Rate, um Bufferbloat und Drop-Bursts zu reduzieren.
- Realtime-Queue: Voice/Realtime kurz halten, strikt priorisieren und strikt limitieren.
- Best Effort mit AQM/ECN: reduziert RTT-Spitzen und stabilisiert Mischlast.
- Bulk/Scavenger: bewusst nachrangig, um Echtzeit zu schützen.
MTU, MSS und Overhead: Die unterschätzte QoS-Ursache im VPN
Encapsulation erhöht Paketgröße. Wenn MTU nicht angepasst ist, entsteht Fragmentierung oder Drop – beides besonders schädlich für Echtzeit. Zusätzlich erhöht Overhead die effektive Bitrate: Besonders bei kleinen Paketen (Voice-RTP) ist der Overhead prozentual hoch. Das wirkt direkt auf QoS-Budgets: LLQ-Limits, Policer und Shaper müssen die Underlay-Rate inklusive Overhead abdecken, sonst entstehen „unerklärliche“ Drops genau in der Echtzeitklasse.
- MTU-Standard: End-to-End MTU für Tunnelpfade definieren und testen.
- MSS-Clamping: TCP-Fragmentierung vermeiden, besonders bei SaaS/HTTPS.
- Budget-Anpassung: Overhead in Bandbreitenmodellen berücksichtigen (Voice/Video besonders betroffen).
Policy-Design: Ein praktisches Hybridmodell für DSCP Preservation und Re-Marking
In der Praxis ist ein Hybridmodell am robustesten: Sie preserven inner DSCP, aber propagieren in den Outer Header nur eine Allowlist definierter Klassen. Gleichzeitig setzen Sie Profile und Limits pro Klasse durch. So bleibt End-to-End Semantik für legitime Echtzeitdienste erhalten, während Missmarking abgefangen wird. Überschreitungen werden bevorzugt degradiert statt gedroppt, um QoE nicht sofort zu zerstören – insbesondere bei Voice, wo harte Drops sofort hörbar sind.
- Allowlist für Copy: nur EF/definierte AF/Control-Werte werden inner→outer kopiert.
- Normalization: alle anderen DSCP-Werte werden im Outer Header auf Best Effort gesetzt.
- Budget-Enforcement: pro Klasse Policing/Hierarchie, damit Premiumklassen nicht wachsen.
- Degrade statt Drop: Überschreitungen ummarkieren, wenn das Serviceprofil es erlaubt.
Monitoring: Wie Sie nachweisen, ob DSCP Preservation oder Re-Marking funktioniert
VPN-QoS lässt sich nur sauber betreiben, wenn Sie Marking-Integrität und Queue-Health messen. Dafür brauchen Sie (1) DSCP-Verteilungen am Tunnel-Ingress und Tunnel-Egress (inner und outer), (2) Queue-Delay und Drops pro Klasse am WAN-/Tunnel-Interface, (3) Policer-/Remarking-Zähler, um Missmarking und Profilüberschreitungen sichtbar zu machen, und (4) service-nahe KPIs für Echtzeit (RTP-Loss/Jitter, MOS/R-Faktor-Schätzungen, sofern verfügbar). Entscheidend sind kurze Zeitfenster und Perzentile, weil Mikrobursts und „Bad Minutes“ sonst unsichtbar bleiben.
- Marking-Integrity: inner DSCP vs. outer DSCP – stimmt die Copy-/Map-Regel?
- Queue-Delay p95/p99: Frühindikator für Jitter und bevorstehende QoE-Probleme.
- Class Drops: Drops in Realtime/Control sind kritisch; Best Effort Drops anders interpretieren.
- Policer/Remarking Counters: zeigen Missmarking, Überschreitungen und Policy-Wirkung.
Typische Failure Patterns: Wenn VPN-QoS „trotz allem“ nicht passt
Die häufigsten Störungen folgen wiederkehrenden Mustern. Wenn Sie diese Muster kennen, können Sie schnell unterscheiden, ob das Problem Marking, Underlay, Shaping oder MTU ist. Das spart Zeit und verhindert, dass man „noch mehr QoS“ konfiguriert, obwohl die Ursache woanders liegt.
- Alles wird Best Effort: Outer DSCP bleibt 0 oder wird genullt; Underlay priorisiert nicht.
- Premium-Queues überlaufen: Blindes Copy ohne Trust; Allowlist und Limits fehlen.
- Voice leidet bei Upload: Bufferbloat am Upstream; Shaping und AQM fehlen.
- Unerklärliche Drops: MTU/Fragmentierung durch Tunnel-Overhead; MTU/MSS prüfen.
- Asymmetrische Qualität: Copy/Re-Marking nur in eine Richtung; Hinweg ok, Rückweg schlecht.
Blueprint: QoS für VPN Traffic sauber aufsetzen
Ein belastbares Vorgehen beginnt mit einem schlanken Klassenmodell (Realtime, Video/Interactive, Business, Best Effort, Bulk plus Control) und klaren Trust Boundaries am Tunnel-Endpunkt. Danach entscheiden Sie für jede Serviceklasse, ob DSCP Preservation mit Outer-Propagation erlaubt ist oder ob Re-Marking/Normalization gilt. Implementieren Sie eine Allowlist für Copy, setzen Sie Budgets und Limits (insbesondere für Realtime/EF) und platzieren Sie Shaping so, dass Congestion kontrollierbar bleibt. Stellen Sie MTU/MSS end-to-end sicher, damit Encapsulation nicht zu Drops führt. Abschließend etablieren Sie Monitoring für Marking-Integrität, Queue-Delay/Drops und Policer-/Remarking-Zähler, ergänzt um QoE-KPIs für Voice/Video. So wird „DSCP Preservation vs. Re-Marking im Tunnel“ keine Glaubensfrage, sondern eine nachvollziehbare, messbare Designentscheidung, die VPN-Traffic zuverlässig QoS-fähig macht.