QoS im SD-WAN unterscheidet sich grundlegend von klassischer QoS im MPLS- oder Campus-Netz: Statt nur Warteschlangen zu konfigurieren, kombiniert SD-WAN QoS typischerweise drei Steuerhebel zu einem End-to-End Mechanismus – SLA Probes (aktive Messungen), Pfadwahl (Dynamic Path Selection) und Application Awareness (Anwendungserkennung). Genau diese Kombination ist der Grund, warum SD-WAN für Voice/Video, SaaS-Anwendungen und verteilte Standorte so attraktiv ist: Sie können nicht nur „bei Congestion priorisieren“, sondern bereits vorher erkennen, welcher Underlay-Pfad gerade gute Latenz-, Jitter- und Loss-Werte liefert, und Traffic pro Anwendung aktiv auf den passenden Transport legen (z. B. MPLS, Internet, LTE/5G). Gleichzeitig ist SD-WAN kein Zauberstab: Wenn Sie SLA-Schwellen falsch setzen, Probes nicht repräsentativ sind oder Underlay-QoS/Marking nicht konsistent umgesetzt wird, kann SD-WAN sogar Instabilität erzeugen (Flapping, wechselnde Pfade, mehr Jitter). Wer QoS im SD-WAN professionell plant, denkt deshalb in „SLOs pro Applikation“, in belastbaren Messmethoden, in klaren Policy-Hierarchien (Business-Intent, App-Policy, Fallback) und in einem Zusammenspiel von Overlay-Steering und Underlay-Queueing, damit Echtzeit nicht nur den „besten Pfad“, sondern auch eine verlässliche Behandlung auf diesem Pfad bekommt.
Warum SD-WAN QoS anders ist: Overlay-Steuerung trifft Underlay-Realität
Im klassischen WAN war QoS häufig gleichbedeutend mit DSCP-Markierung und Queueing auf dem WAN-Interface. SD-WAN verschiebt den Fokus: Die Plattform baut meist ein Overlay (häufig IPsec/GRE/UDP-basiert) über mehrere Underlays und wählt dynamisch den Pfad. Dadurch wird QoS zur Kombination aus Transportwahl und klassischer Paketbehandlung. Das führt zu einem wichtigen Prinzip: SD-WAN kann Pfade optimieren, aber es kann keine Underlay-Engpässe „wegkonfigurieren“. Wenn ein Internetlink dauerhaft überlastet ist oder wenn die letzte Meile (WLAN/Access) jittert, müssen Sie weiterhin klassisches QoS, Shaping und Kapazitätsplanung einsetzen.
- Overlay: steuert, wohin Traffic geht (Policy/Steering).
- Underlay: entscheidet, wie Pakete im Netz des Providers behandelt werden (Queues/Peering/Last Mile).
- End-to-End: nur stabil, wenn Overlay-Policies und Underlay-QoS zusammenpassen.
SLA Probes: Die Messbasis jeder guten Pfadwahl
SLA Probes sind aktive Messpakete, die SD-WAN-Geräte zwischen Standorten oder zu Hubs/Cloud-Gateways senden. Aus diesen Probes werden Latenz, Jitter, Loss und oft auch Pfadverfügbarkeit abgeleitet. Die Pfadwahl-Logik verwendet diese Werte, um zu entscheiden, ob ein Pfad „gut genug“ für eine Anwendung ist. In der Praxis ist die Probe-Qualität entscheidend: Wenn Probes zu selten sind, reagieren Policies zu spät. Wenn Probes zu aggressiv sind, belasten sie schwache Links oder führen zu „Nervosität“. Wenn Probes nicht repräsentativ für den echten Traffic sind (z. B. andere MTU, andere DSCP, anderer Transport), stimmen die Entscheidungen nicht.
- Latenz: Zeit pro Richtung oder RTT; wichtig für Interaktivität und SaaS-Responsiveness.
- Jitter: Variabilität; entscheidend für Voice/Video.
- Loss: Paketverlust; kritisch für Echtzeit und für TCP-Throughput.
- Availability: Pfad-„Up/Down“ plus Qualitätsdegradation (brownout vs. blackout).
Probe-Design: Damit Messungen wirklich aussagekräftig sind
- Repräsentative Markierung: Probes sollten mit dem gleichen DSCP/Overlay-Klassenprofil laufen wie die jeweilige App-Klasse.
- Repräsentative Größe: MTU/Packet Size beeinflusst Loss; Tests sollten reale Paketgrößen abdecken.
- Messpunkte: nicht nur Site-to-Hub, sondern auch Site-to-SaaS/Cloud-Gateway, wenn das Ihr Ziel ist.
- Frequenz und Fenster: kurze Intervalle für Echtzeit, längere für Bulk; Perzentile sind oft besser als Mittelwerte.
Pfadwahl im SD-WAN: Von „Best Path“ zu kontrollierbaren Policies
Dynamic Path Selection ist die Logik, die anhand der SLA Metriken entscheidet, welcher Underlay-Pfad genutzt wird. Dabei gibt es mehrere Modi: Active/Active (Lastverteilung), Active/Standby (präferierter Pfad mit Backup), oder per Application Steering (verschiedene Apps auf verschiedenen Pfaden). Für QoS ist entscheidend, dass die Pfadwahl nicht nur auf „geringste Latenz“ optimiert, sondern stabil bleibt. Zu aggressive Schwellenwerte führen zu Flapping: Traffic springt zwischen Pfaden, Jitter steigt, TCP-Sessions brechen, und Voice/Video leidet trotz „intelligenter“ Auswahl.
- Policy-First: Anwendungen definieren Anforderungen; Pfadwahl folgt diesen Anforderungen.
- Stabilität: Hysterese, Hold-Down-Timer und „degraded“-Zustände verhindern Flapping.
- Failover-Qualität: Backup-Pfade müssen nicht nur „up“, sondern SLA-fähig sein.
- Asymmetrie vermeiden: Hin- und Rückweg sollten möglichst konsistent sein, sonst entstehen Einweg-Probleme.
Application Awareness: Warum „Port-basiert“ nicht mehr reicht
SD-WAN lebt davon, dass es Anwendungen erkennt und differenziert behandeln kann. Port-basiertes Matching ist in modernen Umgebungen zu ungenau: Viele Apps nutzen HTTPS, dynamische Ports oder CDNs, und Verschlüsselung verdeckt Inhalte. Deshalb nutzen SD-WAN-Plattformen typischerweise DPI, App-Signaturen, SNI/Cert-Infos oder Endpoint-Identitäten, um Traffic zu klassifizieren. Für QoS bedeutet das: Die App-Erkennung muss zuverlässig sein, sonst werden Anwendungen falsch gesteuert und landen auf falschen Pfaden oder in falschen Queues.
- DPI/Signaturen: erkennt Apps trotz gemeinsamer Ports (z. B. TCP/443).
- App-Gruppen: SaaS, UC, Business Apps, Bulk – erleichtert Policy-Design.
- Unknown Apps: Default-Policy muss sinnvoll sein, sonst entsteht Best-Effort-Chaos.
QoS-Klassen im SD-WAN: Overlay-Klassen vs. Underlay-DSCP
Viele SD-WAN-Lösungen arbeiten mit eigenen Overlay-Klassen (z. B. Real-Time, Interactive, Bulk). Diese Klassen müssen auf Underlay-Markings (DSCP/PCP) abgebildet werden, damit Provider-Queues – sofern vorhanden – greifen. Gleichzeitig darf man die Realität nicht ignorieren: Im öffentlichen Internet wird DSCP häufig nicht respektiert oder sogar genullt. Daraus folgt ein realistisches Modell: Im MPLS/Private WAN kann DSCP durchgängig wirken; im Internet wirkt DSCP oft nur auf der ersten Meile oder im eigenen CPE, und die Hauptwirkung entsteht durch Shaping, lokale Queueing und kluge Pfadwahl.
- Overlay Class: bestimmt Policy-Steering, FEC/Duplizierung (falls genutzt) und lokale Scheduler.
- Underlay DSCP: kann im Managed WAN Wirkung haben, im Internet oft begrenzt.
- Trust Boundaries: an WAN-Edges Markings normalisieren, damit Premiumklassen nicht missbraucht werden.
Underlay-Shaping: Warum SD-WAN ohne Traffic Shaping selten „smooth“ wird
Auch im SD-WAN bleibt Shaping eine der wichtigsten Maßnahmen, um Queueing kontrollierbar zu machen. Besonders im Upstream (Upload) entstehen die größten Echtzeitprobleme: Cloud-Sync, Backups oder große Uploads füllen CPE-Queues, Bufferbloat steigt, Voice/Video jittert. SD-WAN kann zwar auf einen anderen Pfad ausweichen, aber wenn alle Pfade den gleichen Engpass (z. B. letzte Meile) teilen, hilft nur: Egress Shaping knapp unter der realen Rate, kombiniert mit einer klaren Echtzeitqueue (limitierte LLQ) und AQM/ECN für Best Effort.
- Queue im eigenen Einflussbereich: Shaping sorgt dafür, dass Congestion im SD-WAN Edge entsteht, nicht beim Provider.
- Bufferbloat reduzieren: kurze Queues und AQM/ECN senken RTT-Spitzen.
- Realtime schützen: Voice-Queue kurz halten und strikt budgetieren.
Advanced Funktionen: FEC, Packet Duplication und Forwarding-Strategien
Viele SD-WAN-Plattformen bieten Mechanismen, die über klassische QoS hinausgehen: Forward Error Correction (FEC), Packet Duplication oder Packet Ordering. Diese Funktionen können QoE bei Voice/Video verbessern, insbesondere auf jitter- oder lossanfälligen Internetpfaden. Sie sind jedoch kein Ersatz für saubere Pfadwahl und Shaping. FEC kostet zusätzliche Bandbreite; Duplication verdoppelt Traffic und kann Congestion verstärken, wenn Links knapp sind. Ein professionelles Design setzt solche Features gezielt ein: nur für kritische Anwendungen, nur bei nachweislich volatileren Pfaden und nur mit Headroom-Budgets.
- FEC: schützt gegen moderaten random Loss, kostet Bandbreite und benötigt Buffering.
- Duplication: reduziert effektiven Loss, kann aber Links schneller überlasten.
- Policy-Bedingungen: aktivieren nur bei „degraded“-Zuständen oder für bestimmte App-Klassen.
SLA-Design pro Anwendung: Von „eine Schwelle für alle“ zu SLOs
Ein häufiger Fehler ist, eine generische SLA-Schwelle zu definieren und alle Apps daran zu messen. In der Praxis braucht jede App-Kategorie eigene Ziele: Voice braucht sehr niedrigen Jitter und minimalen Loss, Video braucht stabile Bandbreite und geringe Loss-Spitzen, SaaS braucht gute RTT-Perzentile, Bulk braucht vor allem Throughput. Ein sauberes SD-WAN QoS-Design formuliert diese Ziele als SLOs (mit Perzentilen und Zeitfenstern), verknüpft sie mit Pfadwahl und definiert klare Fallbacks, wenn kein Pfad das Ziel erfüllt.
- Voice SLO: strenges Jitter-/Loss-Ziel, schneller Failover, stabiler Pfad (keine Flaps).
- Video SLO: stabile Loss- und Delay-Perzentile, ggf. FEC bei Bedarf.
- SaaS SLO: RTT p95/p99 und Packet Loss p95 als Fokus, weniger auf Peak-Throughput.
- Bulk SLO: Throughput, darf in Scavenger-Klassen laufen und ausweichen.
Typische Failure Patterns im SD-WAN QoS
Viele Probleme lassen sich auf wiederkehrende Muster zurückführen. Häufig ist nicht „die SD-WAN-Lösung schlecht“, sondern die Mess- oder Policy-Logik ist nicht stabil genug, oder Underlay-Constraints werden ignoriert. Wer diese Muster früh erkennt, kann SD-WAN QoS deutlich schneller stabilisieren.
- Path Flapping: zu aggressive SLA-Schwellen, keine Hysterese, Probes zu nervös.
- Voice leidet trotz „best path“: Underlay-Queue beim Provider, kein Shaping; Bufferbloat im Upstream.
- App falsch erkannt: DPI/Signaturen unvollständig; Traffic landet auf falschem Pfad oder in falscher Klasse.
- DSCP wirkt nicht: Internetpfad nullt Markings; lokale QoS/Steering muss kompensieren.
- FEC/Duplication verschlimmert: Links ohne Headroom werden überlastet, Loss steigt.
Monitoring und Nachweis: QoS im SD-WAN messbar machen
SD-WAN liefert oft sehr gute Dashboards, aber die entscheidende Frage ist: Stimmen Probe-Werte mit dem realen App-Erlebnis überein? Für belastbaren Betrieb sollten Sie Probe-Metriken (Latenz/Jitter/Loss) mit realen Flow-/App-Metriken korrelieren, und zusätzlich die lokalen Queue-KPIs am Edge betrachten (Queue-Delay, Drops, Shaper-Auslastung). Besonders wichtig sind Perzentile und kurze Zeitfenster: Viele Probleme treten in „Bad Minutes“ auf, nicht im Tagesmittel.
- Probe vs. App: Abweichungen zeigen, ob Probes repräsentativ sind.
- Edge Queue Health: Queue-Delay/Drops pro Klasse als Frühindikator.
- Path Events: Policy-Switches, Failover, brownout/blackout – mit QoE korrelieren.
- Perzentile: p95/p99 statt Durchschnitt, um Peaks sichtbar zu machen.
Blueprint: QoS im SD-WAN sauber planen
Ein praxiserprobtes Vorgehen beginnt mit einem App-Klassenmodell und SLOs pro Kategorie (Voice, Video, SaaS, Business, Bulk). Danach definieren Sie SLA Probes so, dass sie repräsentativ sind: passende Markings, passende Paketgrößen, sinnvolle Frequenz, klare Messpunkte (Site-to-Hub und Site-to-Cloud). Anschließend bauen Sie Pfadwahl-Policies mit Stabilitätsmechanismen (Hysterese, Hold-Down, degraded states) und klaren Fallbacks. Parallel implementieren Sie Underlay-Shaping und lokale QoS am Edge, damit Congestion kontrollierbar ist und Echtzeit nicht an Bufferbloat scheitert. Optional aktivieren Sie FEC/Duplication gezielt für kritische Apps und nur mit Headroom. Abschließend etablieren Sie Monitoring, das Probe-Metriken, Pfadwechsel, Queue-Health und reale App-KPIs zusammenführt. So wird QoS im SD-WAN zu einem stabilen, messbaren System, das SLA Probes, Pfadwahl und Application Awareness sinnvoll vereint.