QoS mit GRE/VXLAN Tunneln ist ein klassischer „Hidden Complexity“-Bereich in modernen Netzen: Im LAN sind Markierungen sauber, die Bandbreite wirkt ausreichend – und trotzdem verschlechtern sich Voice/Video, interaktive Applikationen oder kritische Steuerdaten, sobald Traffic gekapselt wird. Der Grund liegt selten an einem einzelnen Faktor, sondern am Zusammenspiel aus Overhead, MTU und Scheduling. GRE und VXLAN erzeugen einen Outer Header, der für das Underlay sichtbar ist und dort die Warteschlangenentscheidung steuert. Gleichzeitig erhöhen beide Tunneltypen die Paketgröße, was MTU-Probleme und Fragmentierung begünstigt. Und schließlich ändern Tunnel die Dynamik von Bursts und Warteschlangen: Mikrobursts können durch Encapsulation und Fan-in in Overlays stärker werden, während große Puffer (Bufferbloat) Latenz und Jitter erhöhen, ohne dass Drops sofort auffallen. Ein professionelles Design für QoS mit GRE/VXLAN Tunneln beginnt daher nicht bei „DSCP setzen“, sondern bei einem End-to-End Modell: Welche Markings sollen im Outer Header gelten? Wo liegt der echte Engpass? Welche Shaping Points holen die Queue in den eigenen Einflussbereich? Welche MTU/MSS-Standards verhindern Fragmentierung? Und wie wird Scheduling so umgesetzt, dass Echtzeitklassen stabil bleiben, während Best Effort nicht die Tunnel-Queues „aufbläht“? Wer diese Fragen systematisch beantwortet, bekommt Tunnel-QoS reproduzierbar in den Griff – auch über WAN, Metro, DC-Fabrics und Interconnects hinweg.
GRE und VXLAN im Vergleich: Was sich für QoS unterscheidet
GRE ist ein allgemeiner Kapselmechanismus, der IP (oder andere Protokolle) in IP transportiert. VXLAN ist ein Overlay für Ethernet über IP/UDP und wird häufig in EVPN/VXLAN-Fabrics und Data-Center-Overlays eingesetzt. QoS-technisch haben beide Gemeinsamkeiten: Ein Outer IP-Header entscheidet im Underlay über Queueing, und Encapsulation erzeugt Overhead. In der Praxis unterscheiden sie sich aber in typischen Einsatzorten und Failure Patterns: GRE sieht man oft im WAN/Provider-Umfeld, VXLAN häufig im Data Center, in Campus-Overlays oder in Hybrid-Cloud-Architekturen. VXLAN nutzt UDP, wodurch Hashing/ECMP besser verteilt werden kann – gleichzeitig können UDP-basierte Mikrobursts und MTU-Fehler in Fabrics sehr sichtbar werden.
- GRE: flexibel, häufig im WAN/Overlay-Transport; QoS hängt stark von Outer DSCP und Shaping am WAN-Edge ab.
- VXLAN: Ethernet-over-IP/UDP, oft in Fabrics; QoS hängt stark von Marking Preservation (inner↔outer) und Underlay-Queue-Profilen ab.
- Gemeinsam: Outer Header ist maßgeblich für Underlay-QoS; Overhead beeinflusst MTU und effektive Rate.
Der zentrale QoS-Effekt von Tunneln: Underlay sieht den Outer Header
In einem nicht gekapselten IP-Netz ist DSCP im IP-Header das primäre QoS-Signal. Bei GRE/VXLAN liegt die ursprüngliche Markierung im Inner Packet – Underlay-Router sehen aber in erster Linie den Outer IP-Header. Wenn der Outer DSCP nicht korrekt gesetzt ist, wird Underlay-QoS blind. Das ist der Hauptgrund, warum Echtzeitverkehr trotz „korrekter“ Markierung im LAN im Tunnel wie Best Effort behandelt wird. Ein sauberes Tunnel-QoS-Design definiert daher explizit, ob Markings vom Inner Header in den Outer Header kopiert, gemappt oder komplett neu gesetzt werden.
- Inner DSCP: beschreibt die Serviceklasse des eigentlichen Datenverkehrs.
- Outer DSCP: steuert Queueing im Underlay; ohne korrektes Outer Marking wirken Underlay-Queues nicht.
- Copy/Map/Rewrite: entscheidet, wie inneres Marking im Tunnel transportfähig wird.
Marking Preservation vs. Governance: Trust Boundaries am Tunnel-Endpunkt
Das „einfachste“ Design wäre, inneres DSCP 1:1 in den Outer Header zu kopieren. Das funktioniert gut, wenn die Marking-Quelle vertrauenswürdig ist (z. B. gemanagte Endpoints, klar definierte UC-Systeme). In Multi-Tenant- oder gemischten Umgebungen ist blindes Copy riskant: Jede Anwendung könnte sich Premium-Queues erschleichen, wodurch Realtime-Klassen wachsen und Scheduling instabil wird. Deshalb braucht es Trust Boundaries am Encapsulation-Point (GRE Endpoint oder VTEP): Nur definierte Markings werden übernommen (Allowlist), alles andere wird normalisiert oder in niedrigere Klassen gemappt.
- Copy (kontrolliert): nur erlaubte DSCP-Werte werden inner→outer übernommen.
- Map: inner DSCP wird auf ein schlankes Underlay-Klassenmodell übersetzt.
- Rewrite: Outer DSCP wird ausschließlich aus Kontext (VRF/VNI/Interface/Policy) gesetzt.
- Budget-Regel: strikt priorisierte Klassen (z. B. Voice) immer limitieren, unabhängig vom Marking-Ansatz.
Overhead: Warum Tunnel die effektive Bandbreite und QoS-Budgets verändern
GRE und VXLAN fügen Header hinzu. Dadurch steigt die Anzahl der Bytes, die über das Underlay geschickt werden müssen, obwohl die Nutzdaten gleich bleiben. Für QoS ist das entscheidend, weil Bandbreitenbudgets und LLQ-Limits häufig anhand der „inneren“ Applikationsrate dimensioniert werden. In Wirklichkeit ist die Underlay-Rate höher – und genau dadurch geraten Shaper, Policer oder Queue-Limits unerwartet früh an Grenzen. Besonders bei kleinen Paketen (Voice/RTP) ist der relative Overhead hoch: Wenige zusätzliche Bytes pro Paket wirken prozentual stark, weil es viele Pakete pro Sekunde sind.
- Effektive Rate: Underlay-Bandbreite = Nutzlast + Tunnelheader (plus ggf. VLAN/MPLS/Transport-Overhead).
- Realtime besonders betroffen: kleine Pakete, hohe Paketfrequenz, hoher relativer Overhead.
- LLQ/Policer-Risiko: Budgets werden zu knapp, Drops entstehen in der Echtzeitklasse.
- Kapazitätsplanung: Busy-Hour und Failover-Headroom müssen Overhead einschließen.
MTU und Fragmentierung: Der häufigste Root Cause für „mysteriösen Loss“
Encapsulation macht Pakete größer. Wenn die Underlay-MTU nicht entsprechend erhöht ist oder wenn PMTUD/ICMP-Handling nicht sauber funktioniert, kommt es zu Fragmentierung oder zu Drops. Beides ist für QoS kritisch: Fragmentierung erhöht die Verlustwahrscheinlichkeit (ein Fragment reicht, um das Paket unbrauchbar zu machen) und kann Jitter erhöhen; Drops wirken wie Packet Loss und sind bei Echtzeit sofort spürbar. In Overlays ist MTU deshalb kein Detail, sondern ein zentrales Design-Objekt: Sie müssen End-to-End eine MTU-Strategie haben, inklusive MSS-Clamping für TCP und klarer Standards pro Domäne (Campus, DC, WAN, Interconnect).
- Underlay-MTU: muss Overlay-Overhead einplanen, sonst entstehen Drops oder Fragmentierung.
- MSS-Clamping: verhindert TCP-Fragmentierung über Tunnelpfade.
- ICMP/PMTUD: Blockierte ICMP-Messages führen zu „Black Hole MTU“ und sporadischen Problemen.
- Realtime-Effekt: selbst wenige Fragment-/Drop-Events können Voice/Video deutlich verschlechtern.
Scheduling: Wo Tunnel-QoS wirklich „gewonnen“ wird
Marking ist nur ein Signal; Scheduling ist die tatsächliche Umsetzung. In Tunnel-Designs entstehen Engpässe typischerweise am WAN-Uplink, am DC-Fabric-Uplink (Leaf→Spine, Spine→Border) oder an Interconnects. Dort muss die Queue-Behandlung greifen – und zwar anhand des Outer Headers, wenn Underlay-Geräte nur diesen sehen. Ein bewährtes Scheduling-Modell bleibt auch im Tunnelkontext gültig: eine limitierte Realtime-Queue für Voice, gewichtete Klassen für Video/Business, Best Effort mit AQM/ECN gegen Bufferbloat und Bulk/Scavenger nachrangig. Der kritische Punkt ist die Limitierung: Strict Priority ohne Obergrenze destabilisiert Multi-Service-Links, besonders wenn Markings nicht streng kontrolliert werden.
- Realtime (Voice): LLQ/Strict Priority, aber strikt limitiert und mit kurzen Queue-Limits.
- Video/Interactive: gewichtete Echtzeitklasse, Mindestbandbreite, stabile Bedienung.
- Business: bevorzugte Datenklasse, fair, mit planbaren RTT-Perzentilen.
- Best Effort: AQM/ECN zur Latenzstabilisierung unter Mischlast.
- Bulk: nachrangig, um Peaks (Backups/Updates) vom Echtzeitpfad fernzuhalten.
Shaping: Die Queue an den richtigen Ort holen
Ein wiederkehrendes Muster in Tunnel-QoS ist: Die entscheidende Warteschlange liegt nicht auf dem eigenen Gerät, sondern beim Provider oder in einem nicht transparenten Segment. Dann sehen Sie im eigenen Monitoring wenig Drops, aber Nutzer erleben Aussetzer. Egress Shaping knapp unter die reale Rate verlagert Congestion in das eigene Gerät und macht QoS reproduzierbar. Besonders im Upstream ist das entscheidend, weil Upload-Bursts schnell zu Bufferbloat führen. In Hub-and-Spoke Designs (z. B. GRE/DMVPN) ist zusätzlich HQoS sinnvoll: pro Tunnel oder pro Site ein Parent-Shaper, darunter Klassenqueues, damit eine Site nicht alle anderen verdrängt.
- Egress Shaping: kontrolliert Burstiness und hält Congestion im eigenen Einflussbereich.
- HQoS: per Tunnel/Site/Service budgetieren, dann innerhalb priorisieren.
- Underlay-Realität: besonders wichtig, wenn DSCP im Internet nicht respektiert wird.
VXLAN-spezifisch: VTEP als QoS-Schlüsselpunkt in EVPN/VXLAN Fabrics
Bei VXLAN ist der VTEP die entscheidende Stelle, an der inneres Marking in das Underlay übertragen werden muss. In Data-Center-Fabrics ist Underlay-QoS oft stark von Hardware-Queues abhängig, die nur wenige Klassen erlauben. Deshalb ist ein schlankes Mapping von inner DSCP auf wenige Outer DSCP-Werte sinnvoll, kombiniert mit Trust Boundaries, damit Tenants nicht Premium-Queues fluten. Zusätzlich sind Mikrobursts in Fabrics typisch; AQM/ECN und kurze Queue-Limits sind dort besonders wertvoll, um Latenzspitzen zu reduzieren.
- Outer DSCP setzen: sonst behandelt das Underlay VXLAN-Traffic als Best Effort.
- Few-Queue Reality: Klassenmodell an die Hardware-Queues anpassen, nicht umgekehrt.
- Fan-in Mikrobursts: Leaf-Uplinks sind Congestion Points; kurze Telemetrieintervalle nötig.
Messbarkeit: Tunnel-QoS nur über Marking-Integrität und Queue-Health betreiben
Damit QoS mit GRE/VXLAN Tunneln nicht zur Vermutung wird, müssen Sie drei Dinge messen: (1) Marking-Integrität (inner DSCP vs. outer DSCP), (2) Queue-Health (Queue-Delay und Drops pro Klasse an den echten Engpässen) und (3) MTU/Fragmentierungsindikatoren (damit „Loss“ nicht falsch diagnostiziert wird). Mittelwerte reichen nicht: Mikrobursts und „Bad Minutes“ dominieren QoE. Deshalb sind Perzentile (p95/p99) und kurze Zeitfenster (1–5 Minuten) in der Praxis entscheidend.
- DSCP Distribution: Outer DSCP muss die Klassenabsicht tragen; Abweichungen sind sofort sichtbar.
- Queue-Delay p95/p99: Frühindikator für Jitter, bevor Drops auftreten.
- Class Drops: Drops in Realtime/Control sind kritisch; Best Effort Drops differenziert bewerten.
- MTU/Fragmentation: Fragmentzähler, PMTUD-Events, ICMP-Blockaden als Root-Cause Hinweise.
Typische Failure Patterns bei QoS mit GRE/VXLAN Tunneln
Wenn Tunnel-QoS „nicht funktioniert“, sind die Ursachen oft wiederkehrend. Das spart Zeit in der Fehlersuche: Erst prüfen, ob Outer Marking korrekt ist, dann MTU/Fragmentierung, dann Shaping/Queueing am Engpass, und erst zuletzt exotische Spezialfälle. Besonders häufig sind inkonsistente Copy-Regeln, fehlende Trust Boundaries und Overhead, der in Budgets nicht berücksichtigt wurde.
- Alles ist Best Effort: Outer DSCP bleibt 0; Underlay priorisiert nicht.
- Premium-Queues laufen voll: blindes Copy ohne Trust; Allowlist und Limits fehlen.
- Unerklärliche Drops: MTU/Fragmentierung durch Overhead; MSS/MTU/ICMP prüfen.
- Voice leidet bei Upload: Bufferbloat; Shaping und AQM fehlen oder Queue-Limits sind zu groß.
- QoS bricht bei Failover: Backup-Pfad ohne kompatible Queue-Profile oder ohne Headroom.
Blueprint: QoS mit GRE/VXLAN Tunneln robust designen
Ein bewährter Ansatz beginnt mit einem schlanken Klassenmodell (Realtime, Video/Interactive, Business, Best Effort, Bulk plus Control) und einer klaren Marking-Strategie: inneres Marking erhalten, Outer DSCP kontrolliert setzen (Copy nur für Allowlist oder Mapping auf wenige Klassen). Danach wird MTU end-to-end geplant: Underlay-MTU, MSS-Clamping, PMTUD/ICMP-Handling, Tests mit realen Paketgrößen. Anschließend wird Scheduling an den echten Congestion Points umgesetzt: limitierte LLQ für Voice, gewichtete Klassen für Video/Business, AQM/ECN für Best Effort, Bulk nachrangig. Shaping holt Congestion in den eigenen Einflussbereich, HQoS verhindert Noisy-Neighbor-Effekte pro Tunnel/Site. Abschließend wird Monitoring aufgebaut, das Outer/Inner Marking-Integrität, Queue-Delay/Drops und MTU-Indikatoren korreliert. So werden Overhead, MTU und Scheduling nicht zu Stolpersteinen, sondern zu kontrollierten Designparametern – und QoS in GRE/VXLAN Tunneln funktioniert reproduzierbar end-to-end.
