QoS über VPN/Tunnel ist in modernen Telco- und Enterprise-Netzen eine der häufigsten Ursachen für „QoS wirkt nicht“, obwohl DSCP sauber gesetzt ist und die Queues im Backbone korrekt konfiguriert sind. Der Grund ist die Kapselung: Sobald Traffic in einen Tunnel (z. B. IPsec, GRE, L2TP, VXLAN, Geneve, WireGuard, MPLS VPN, SRv6-Encap, SD-WAN-Overlays) gepackt wird, existieren plötzlich zwei Header-Ebenen – ein innerer Header (Originalpaket) und ein äußerer Header (Tunneltransport). Viele Geräte treffen ihre Queueing-Entscheidungen aber anhand des äußeren Headers. Wenn die DSCP- oder CoS-Markierung nicht vom inneren in den äußeren Header übernommen oder korrekt gemappt wird, „verschwindet“ QoS im Underlay. Umgekehrt kann blindes Kopieren von Markierungen die Trust Boundary aushebeln: Ein untrusted Endpoint markiert alles als EF, und plötzlich steuert er die Prioritätsqueues im Provider- oder Unternehmensnetz. Professionelles QoS über VPN/Tunnel bedeutet deshalb: eine klare Strategie für DSCP-Propagation (copy, map, rewrite), definierte Trust Boundaries an Tunnel-Endpunkten, profilierte Budgets pro Klasse (besonders für EF/Voice), konsistentes Mapping auf Underlay-Technologien (802.1p CoS, MPLS-TC/EXP) sowie Monitoring, das inneren und äußeren Header sichtbar macht. Dieser Artikel erklärt praxisnah, wie Sie Markierungen über VPN/Tunnel erhalten und korrekt mappen, welche typischen Fehler in der Praxis auftreten und wie Sie Voice & Video auch über verschlüsselte und gekapselte Pfade stabil bekommen.
Warum Tunnel QoS „unsichtbar“ machen können
Im klassischen IP-Netz reicht oft: Traffic markieren (DSCP), an Engpässen klassifizieren, in die richtige Queue legen. Bei Tunneln kommt eine zusätzliche Ebene dazu: Das Underlay sieht häufig nur den äußeren Header. Der innere DSCP-Wert ist dann zwar im Paket enthalten, aber für das Underlay irrelevant, wenn es nicht hineinschaut. Typische Folgen:
- Voice wird Best Effort: RTP ist innen als EF markiert, außen steht DSCP 0. Das Underlay queuet Best Effort.
- Video verliert Garantien: AF-Markierungen gehen verloren, Video teilt sich Best Effort mit großen Downloads.
- Jitter-Spitzen trotz QoS: Scheduling greift nicht, weil die falsche Klasse im Underlay ankommt.
- Fehlersuche wird schwer: im Overlay scheint alles korrekt, im Underlay sieht man nur „normalen“ Traffic.
Das Kernproblem lautet: QoS wirkt an Engpässen – und Engpässe liegen oft im Underlay. Also muss das Underlay die richtige Klasse sehen.
Innerer vs. äußerer Header: Das Grundprinzip für QoS über Tunnel
Jeder Tunnel erzeugt zwei Sichten auf denselben Traffic:
- Innerer Header: Originalpaket (z. B. IPv4/IPv6) mit DSCP/Traffic Class, ggf. auch mit innerem VLAN/CoS bei L2-over-L3.
- Äußerer Header: Transportpaket des Tunnels (z. B. IPsec-Outer-IP, GRE-Outer-IP, VXLAN-Outer-IP/UDP), das durch das Underlay geroutet wird.
Für QoS ist entscheidend, welches Feld das Underlay zur Klassifizierung nutzt. In den meisten Telco- und Enterprise-Backbones ist es der äußere Header (DSCP, CoS oder MPLS-TC), weil er am schnellsten auswertbar ist.
Die drei Strategien: Copy, Map, Rewrite
Um Markierungen durch Tunnel zu bekommen, gibt es drei grundlegende Ansätze. Welcher richtig ist, hängt vom Trust-Modell und vom Produkt ab.
Copy (Propagation): DSCP vom inneren in den äußeren Header kopieren
- Vorteil: End-to-End-Semantik bleibt erhalten; das Underlay sieht die gleiche Klasse wie das Overlay.
- Nachteil: gefährlich ohne Trust Boundary – untrusted Endpunkte könnten Underlay-Priorität steuern.
Map (Policy-based Mapping): inneres DSCP wird auf wenige Underlay-Klassen abgebildet
- Vorteil: kontrolliert und skalierbar; mehrere Tenant-/Applikationsmarkierungen werden auf ein Provider-Klassenmodell reduziert.
- Nachteil: erfordert saubere Mapping-Tabellen und Tests, sonst entstehen QoS-Löcher.
Rewrite (Set): Outer-DSCP wird unabhängig vom inneren gesetzt
- Vorteil: maximale Kontrolle; ideal, wenn das Underlay nur wenige Klassen akzeptiert oder wenn Sie Markierungen nicht vertrauen.
- Nachteil: Verlust von Dienstsemantik; alle Flows im Tunnel sehen gleich aus, echte Echtzeit kann nicht differenziert werden.
Für Voice & Video in professionellen Netzen ist „Map“ häufig der beste Kompromiss: Sie erhalten Differenzierung, ohne blind zu vertrauen.
Trust Boundary am Tunnel-Endpunkt: Wer darf die Outer-Markierung bestimmen?
Der Tunnel-Endpunkt (VPN-Gateway, SD-WAN-Edge, PE-Router, vTEP, IPsec-Headend) ist die natürliche Trust Boundary. Hier muss entschieden werden, ob inneres DSCP übernommen werden darf.
- Untrusted Endpoint: Inneres DSCP nicht übernehmen; map/rewrite auf definierte Klassen.
- Trusted Domain: Managed CPE oder kontrollierte CNFs dürfen Markierungen setzen; Copy oder Map ist möglich.
- Conditional Trust: Markierungen werden übernommen, aber nur innerhalb profilierter Budgets; Überschuss wird remarkt.
Im Telco- und Carrier-Kontext ist Conditional Trust besonders wichtig: So bleibt EF/LLQ für Voice klein und stabil, selbst wenn ein Kunde Fehler macht.
IPsec: QoS trotz Verschlüsselung richtig umsetzen
IPsec ist einer der häufigsten QoS-Stolpersteine, weil die Payload verschlüsselt wird und Zwischenknoten nicht mehr in den inneren Header schauen können. Das Underlay muss daher über den äußeren IP-Header priorisieren.
- Outer-DSCP ist entscheidend: Die Underlay-Queueing-Entscheidung hängt meist am äußeren DSCP.
- DSCP-Propagation explizit konfigurieren: je nach Plattform wird DSCP kopiert, genullt oder policy-basiert gesetzt.
- Overhead berücksichtigen: IPsec vergrößert Pakete; falsche MTU kann PMTUD-Probleme und Retransmits auslösen, was Video und UC verschlechtert.
Praxisregel: Für Echtzeit über IPsec benötigen Sie eine definierte Outer-DSCP-Strategie plus Shaping an Engpässen, damit Bursts nicht in Drop-Cluster umschlagen.
GRE, L2TP, IP-in-IP: Klassisch, aber nicht automatisch QoS-fähig
Klassische Tunnels wie GRE oder IP-in-IP sind technisch einfacher als IPsec, aber QoS-Probleme sind ähnlich: Der Outer-Header entscheidet. Häufige Fehler sind Default-Outer-DSCP oder inkonsistente Copy-Settings.
- GRE-Overlay in Metro/Backhaul: Voice/Video gehen in denselben Tunnel – ohne Mapping sehen alle gleich aus.
- L2TP/PPPoE-Umgebungen: CoS/DSCP-Mapping an Aggregationspunkten ist kritisch, besonders im Upstream.
Wenn Sie über solche Tunnel mehrere Dienstklassen transportieren, brauchen Sie auch hier Map/Copy-Regeln und eine Trust Boundary.
EVPN/VXLAN, Geneve und Data-Center-Overlays: Inner/Outer DSCP sauber propagieren
In EVPN/VXLAN- oder Geneve-Fabrics ist das Problem sehr häufig: Workloads markieren DSCP im inneren Header, aber das Underlay queuet nach dem äußeren Header. Ohne DSCP-Propagation landet Echtzeit im Best Effort des Underlays.
- Inner->Outer DSCP Propagation: Copy oder policy-basiertes Mapping am Tunnel Ingress (vTEP/Leaf).
- CoS/Queueing im Underlay: Underlay-Links müssen die Outer-Markierung in Hardware-Queues abbilden können.
- Multi-Tenancy: Trust ist kritisch; nicht jeder Tenant darf „EF“ bestimmen.
Best Practice ist ein kleines Underlay-Klassenmodell (z. B. Voice, Video, BE), in das innere DSCP-Werte gemappt werden.
SD-WAN und VPN-Overlays: QoS ist Policy, nicht nur Markierung
Bei SD-WAN kommt eine zusätzliche Ebene hinzu: Das Overlay entscheidet nicht nur über QoS, sondern auch über Pfadwahl, FEC, Jitter-Buffer und Applikationserkennung. Trotzdem bleibt das Grundprinzip: Das Underlay muss die Klasse verstehen, wenn Engpässe im Underlay liegen.
- App-Policy: SD-WAN kann Voice/Video erkennen und in bestimmte Klassen stecken.
- Outer-Markierung: muss so gesetzt sein, dass Provider/Internet-Underlays zumindest intern differenzieren können (wenn möglich).
- Realistische Erwartungen: Über das öffentliche Internet ist DSCP nicht zuverlässig; dann ist Pfaddiversität und Kapazität wichtiger als Markierungsdurchsetzung.
Für managed Underlays (MPLS, Carrier Ethernet) ist SD-WAN-QoS besonders wirksam, weil Markierungen und Klassen end-to-end kontrollierbar sind.
Mapping auf Underlay-Technologien: DSCP->CoS->MPLS-TC
Viele Netze sind multi-layer. Damit QoS über Tunnel wirklich wirkt, müssen Sie Outer-DSCP in die Underlay-Queueing-Mechanik übersetzen:
- Ethernet Metro/Access: Outer-DSCP muss ggf. in 802.1p CoS/PCP gemappt werden, weil Switches nach PCP queuen.
- MPLS/SR-Core: Outer-DSCP muss am PE in MPLS-TC/EXP übersetzt werden, damit der Core korrekt queued.
- Interconnects: Partnernetze neutralisieren DSCP oft; hier sind Shaping, Kapazität und Pfadsteuerung kritischer.
Das wichtigste Designprinzip: Eine Markierung ist nur dann nützlich, wenn sie auf jedem Engpass in eine echte Queue-Behandlung übersetzt wird.
Profilierung und Burst-Handling: Warum Tunnel QoS oft bei Peak-Last kippt
Tunnel bündeln viele Flows. Das macht sie bursty. Ohne Shaping und sinnvolle Queue-Limits entstehen Microbursts, die Drop-Cluster verursachen – besonders schädlich für Voice.
- Shaping am Egress: glättet Tunneltraffic auf rate-limitierten Links und reduziert Downstream-Policer-Drops.
- LLQ für Voice, aber begrenzt: Voice in Low Latency Queue mit Limit; sonst droht Starvation.
- Video gewichtet: AF-Klasse mit garantierten Anteilen; keine strict priority.
- Remarking statt Drop: Überschuss-Video in niedrigere Drop-Precedence oder Best Effort; Voice möglichst nicht droppen.
Gerade bei IPsec und SD-WAN ist das entscheidend: Die Kapselung erhöht Overhead und Burstigkeit, wodurch falsche Profile schneller hörbar werden.
Typische Fehler bei QoS über VPN/Tunnel
- Outer-DSCP bleibt Default: Underlay sieht alles als Best Effort, Echtzeit leidet.
- Blindes Copy ohne Trust: Untrusted Endpunkte steuern Underlay-Priority, Premium-Inflation entsteht.
- Inkonsequentes Mapping: DSCP wird kopiert, aber nicht in CoS/TC gemappt; QoS-Löcher in Metro/Core.
- Policing mit Drops auf Echtzeit: Voice knackt bei Bursts; Drops kommen in Clustern.
- MTU/PMTUD-Probleme: IPsec/Encap verursacht Fragmentierung oder Blackholing; Video und UC pendeln.
- Monitoring nur auf inneren DSCP: Outer-Header bleibt unsichtbar, Ursache wird übersehen.
Monitoring: Inner und Outer sichtbar machen
QoS über Tunnel ist nur dann stabil betreibbar, wenn Sie beide Ebenen beobachten können. Sinnvolle Monitoring-Bausteine sind:
- Traffic pro Klasse: sowohl inner (Original) als auch outer (Transport) – um Mapping-Fehler zu finden.
- Queue-Drops pro Klasse: Drops in Voice sind kritisch; Drops in Video deuten auf Burst/Weight-Probleme hin.
- Queue-Depth/Queueing Delay: zeigt Bufferbloat und Jitterrisiko, besonders an rate-limitierten Links.
- Policer-Hits/Remarking: zeigt Profilüberschreitungen und Missmarkierung am Tunnel-Endpunkt.
- QoE-KPIs: MOS/R-Faktor, Jitter/Loss aus RTP/RTCP, Video-Freeze-Events – korreliert mit Tunnel-Events.
Ein praxistauglicher Betriebssatz bleibt: Drops in der Voice-Klasse sind ein Incident. Bei Tunneln prüfen Sie dann zuerst, ob Outer-DSCP korrekt gesetzt und korrekt gequeued wird.
Praxis-Blueprint: Markierungen über VPN/Tunnel erhalten und korrekt mappen
- Klassenmodell definieren: Voice (EF), Video (AF), Control, Best Effort, Background – wenige, klare Klassen.
- Trust Boundary am Tunnel-Endpunkt: untrusted/conditional/trusted je Szenario; Kundenmarkierungen normalisieren.
- Propagation-Strategie festlegen: Copy, Map oder Rewrite – dokumentiert pro Tunneltyp.
- Outer-Header priorisierungsfähig machen: Outer-DSCP muss im Underlay wirken; bei Ethernet ggf. DSCP->CoS, bei MPLS DSCP->TC.
- Profilierung und Burst-Handling: Shaping an Engpässen, LLQ mit Limit für Voice, Video gewichtet, Remarking für Überschuss.
- MTU sauber planen: Encapsulation-Overhead berücksichtigen, PMTUD sicherstellen.
- Monitoring dual: inner/outer Markierungen, Drops, Queue-Depth, QoE-Korrelation.
Häufige Fragen zu QoS über VPN/Tunnel
Kann ich DSCP einfach „durch den Tunnel“ mitnehmen?
Nur wenn das Underlay die Markierung auch sieht und nutzt. In den meisten Fällen muss DSCP vom inneren in den äußeren Header kopiert oder gemappt werden, weil das Underlay nach dem äußeren Header queued.
Warum ist blindes DSCP-Copy riskant?
Weil es die Trust Boundary aushebelt: Ein untrusted Endpunkt könnte durch DSCP-Markierung Underlay-Priorität steuern. In Provider- und Multi-Tenant-Umgebungen sollten Sie daher meist policy-basiert mappen und Premium-Klassen profilieren.
Was ist der häufigste Grund für schlechte Voice-Qualität über IPsec?
Outer-DSCP ist nicht korrekt gesetzt oder wird im Underlay nicht gemappt, sodass Voice in Best Effort landet. Zusätzlich führen Bursts und falsches Shaping/Policing zu Drop-Clustern, die als Knacken hörbar werden. Eine klare Outer-DSCP-Strategie plus Shaping an Engpässen behebt viele dieser Fälle.