SD-WAN Troubleshooting: Underlay Loss, SLA Monitoring und Pfadwahl

SD-WAN Troubleshooting ist in vielen Unternehmen der entscheidende Faktor, ob eine SD-WAN-Einführung als Erfolg wahrgenommen wird oder als „Black Box“, die im Incident schwer beherrschbar ist. Der Grund: SD-WAN verschiebt das klassische Denken von „ein WAN-Link, ein Router, eine Route“ hin zu einer dynamischen Pfadwahl über mehrere Underlays (MPLS, Internet, 4G/5G), gesteuert durch SLA Monitoring, Applikationsidentifikation und Policies. Genau dadurch entstehen neue Fehlerbilder: Voice/Video ist ab und zu schlecht, obwohl „die Bandbreite reicht“; bestimmte Standorte verlieren intermittierend Konnektivität, obwohl die Tunnel „up“ sind; oder die Pfadwahl springt scheinbar willkürlich zwischen Links, was Latenz, Jitter und Paketverlust verstärkt. Professionelles SD-WAN Troubleshooting bedeutet deshalb, Underlay Loss und Quality-Probleme sauber zu messen, die Logik des SLA Monitorings zu verstehen und die tatsächliche Pfadwahl (und ihre Gründe) nachzuweisen – statt nur „Tunnel up/down“ zu betrachten. Dieser Artikel zeigt eine praxiserprobte Methodik, mit der Sie SD-WAN-Störungen schnell eingrenzen: vom Underlay über die Overlay-Tunnel bis zur Policy-Entscheidung, inklusive typischer Fallstricke wie asymmetrische Pfade, NAT, MTU/PMTUD und Monitoring-Fehlinterpretationen.

Das Grundmodell: Underlay vs. Overlay vs. Policy Engine

Fast jedes SD-WAN-Problem lässt sich schneller lösen, wenn Sie drei Ebenen strikt trennen. Viele Incidents eskalieren, weil Teams Underlay-Symptome als Overlay-Probleme interpretieren oder umgekehrt.

• Underlay: Physischer WAN-Zugang und IP-Transport (MPLS, Internet, LTE/5G). Hier entstehen Loss, Jitter, Latenz, MTU-Probleme, ISP-Routing-Änderungen und lokale Lastspitzen.
• Overlay: SD-WAN-Tunnel (häufig IPsec, GRE-ähnliche Mechaniken oder proprietäre Encapsulation) zwischen Edges und Hubs/Cloud-Gateways. Hier sehen Sie Tunnel-Health, Rekeys, Session-Timeouts, NAT-T und Encapsulation-Overhead.
• Policy Engine: SLA Monitoring und Pfadwahl-Logik: Welche Applikation darf welchen Pfad nutzen? Wann wird gefailovert? Gibt es Forward Error Correction (FEC), Packet Duplication oder Jitter Buffering?

Ein sauberer Workflow beweist zuerst „Underlay ist schlecht“ oder „Underlay ist gut“, dann „Overlay ist stabil“ oder „Overlay ist instabil“, und erst danach „Policy wählt falsch“ oder „Policy wählt korrekt, aber Underlay erfüllt SLA nicht“.

Underlay Loss: Warum Paketverlust nicht gleich Paketverlust ist

Paketverlust ist im SD-WAN der häufigste Treiber für Quality-Probleme, aber er hat unterschiedliche Ursachen – und diese Ursachen brauchen unterschiedliche Gegenmaßnahmen. Der wichtigste Schritt ist, Loss als Muster zu verstehen: dauerhaft, burstig, richtungsabhängig, oder nur für bestimmte Paketgrößen.

• Dauerhafter Loss: häufig Congestion, fehlerhafte Shaping-Profile, Provider-Überlast, schlechtes Funk-LTE.
• Bursty Loss (Microbursts): kurze Peaks, die in 60s-Metriken unsichtbar sind; typisch bei Uploads, Backup-Fenstern, Cloud-Sync.
• Richtungsabhängiger Loss: Upstream ok, Downstream schlecht (oder umgekehrt); typisch bei asymmetrischem Routing oder Last auf nur einem Segment.
• Size-dependent Loss: kleine Pakete ok, große Pakete droppen (MTU/PMTUD-Blackholes, Fragmentation-Probleme).

Der häufigste Underlay-Fehler: Congestion ohne sichtbare „Bandbreiten-Auslastung“

Viele Teams schauen nur auf Mbps. Im WAN ist jedoch PPS (Packets per Second) und Queueing oft relevanter als reine Bandbreite. Ein Link kann in Mbps „halb leer“ sein, aber trotzdem Drops erzeugen, wenn viele kleine Pakete oder Bursts die Puffer füllen. Deshalb sind Queue-Drops und Latenz-unter-Last (Bufferbloat) entscheidende Signale.

• Indiz: Latenz und Jitter steigen bei Upload/Backup, parallel steigen Drops/Discards auf dem WAN-Interface.
• Fix-Richtung: Shaping korrekt auf Provider-Speed (nicht auf „best case“), QoS für Echtzeit, ggf. ECN/AQM wenn unterstützt.

SLA Monitoring: Was wirklich gemessen wird (und was nicht)

SLA Monitoring wirkt auf dem Papier simpel: Latenz, Jitter, Loss messen und den besten Pfad wählen. In der Realität hängt die Aussagekraft stark davon ab, wie gemessen wird: Probe-Intervalle, Messziel (Hub, Cloud-Gateway, Internet-Target), DSCP-Markierungen, Probe-Paketgröße und die Frage, ob die Messung repräsentativ für echte Applikationspakete ist.

• Probe vs. Real Traffic: SLA-Probes sind oft kleine UDP/ICMP-Pakete. Ein Pfad kann Probes gut behandeln, aber echte TCP/QUIC-Flows unter Last droppen.
• Messziel beeinflusst Ergebnis: Messung zu Hub A sagt nichts über Pfad zu SaaS B aus, wenn Internet-Routing differiert.
• Sampling kann Bursts übersehen: Wenn Probes zu selten sind, wirken Microbursts wie „nicht existent“.
• QoS-Klassen beachten: Wenn Probes in Best Effort laufen, aber Voice in EF, sind SLA-Ergebnisse schwer vergleichbar.

Praxisregel: Ein SLA-Graph ist ein Indiz, kein Beweis. Für RCA müssen Sie SLA-Signale mit Interface-Countern (Drops/Discards) und Applikationsmetriken (p95/p99, Retransmissions) korrelieren.

Pfadwahl: Warum „falscher Pfad“ oft die korrekte Policy-Entscheidung ist

Wenn Nutzer melden „SD-WAN nimmt den falschen Link“, steckt dahinter häufig eine Policy, die in dem Moment genau das getan hat, wofür sie gebaut wurde. Die Herausforderung ist, die Entscheidungsgrundlage sichtbar zu machen: Welche SLA-Schwelle wurde verletzt? Welche Applikationsklasse wurde erkannt? Gab es einen Brownout-State (degraded) statt Down? Wurde Traffic dupliziert oder FEC aktiviert?

• Policy basiert auf Schwellen: Ein Link kann „up“ sein, aber SLA verletzt. Pfadwechsel ist dann korrekt.
• Hysterese und Dampening: Gute SD-WAN-Policies vermeiden Flapping durch Hold-down-Timer und Hysterese. Das kann aber wie „zu spät“ wirken.
• Per-App vs. per-Flow: Einige Systeme pinnen Flows an einen Pfad (Flow Pinning), andere können pro Paket steuern. Das beeinflusst, wie schnell sich ein Wechsel auswirkt.
• Stateful Middleboxes: Firewalls/NATs können asymmetrische Pfadwechsel bestrafen (Sessions brechen), obwohl SLA „besser“ ist.

Typische SD-WAN Fehlerbilder und die schnellste Einordnung

Viele Incidents lassen sich in wenigen Minuten einer Fehlerklasse zuordnen, wenn Sie die Muster kennen.

• Voice/Video ruckelt, Daten „gehen“: Jitter/Loss oder QoS-Mismatch im Underlay; ggf. falsches DSCP Trust oder Policer-Drops.
• Tunnel up, aber Apps timeouten: MTU/PMTUD, DNS, oder stateful Geräte im Pfad; häufig size-dependent Loss.
• Nur ein Standort betroffen: lokales Underlay (ISP Access), Lastspitzen im LAN, fehlerhaftes Shaping, LTE-Funkqualität, falsche NAT/Port-Policies.
• Nur SaaS betroffen: Internet-Routing/Peering, DNS-Resolver, Proxy/CDN-PoP; SLA zu Hub misst das nicht korrekt.
• Pfad flapped ständig: zu aggressive SLA-Schwellen, fehlende Hysterese, instabiles Underlay, oder fehlerhafte Probes.

MTU und Encapsulation: Der SD-WAN Klassiker, der wie „Random Timeout“ aussieht

SD-WAN nutzt häufig Encapsulation (z. B. IPsec). Dadurch schrumpft die effektive MTU. Wenn Underlay und Overlay-MTU nicht sauber abgestimmt sind, entstehen Blackholes: große Pakete verschwinden, kleine funktionieren. Besonders empfindlich ist IPv6, weil PMTUD zwingend ist und ICMPv6 „Packet Too Big“ durch Firewalls häufig zu hart gefiltert wird. Als Referenz für IPv6 PMTUD dient RFC 8201.

• Indiz: große Uploads, bestimmte TLS-Handshakes, oder SMB/Storage über SD-WAN brechen, während Ping ok ist.
• Nachweis: PCAP zeigt TCP Retransmissions ohne Fortschritt; ICMP PTB fehlt; Overlay-MTU kleiner als Host-MTU.
• Fix-Richtung: MTU konsistent setzen, MSS-Clamping für TCP an Edges, ICMPv6 PTB gezielt erlauben.

NAT, Firewalls und State: Pfadwechsel kann Sessions brechen

SD-WAN ist dynamisch. Statefull Middleboxes mögen Dynamik nicht, wenn der Rückweg plötzlich anders aussieht. Häufige Ursachen:

• Asymmetrisches Routing nach Failover: Hinweg über Link A, Rückweg über Link B; stateful NAT/Firewall sieht nur eine Richtung.
• NAT Port Exhaustion: Bei Internet-Breakout kann NAT zum Engpass werden; sporadische Timeouts entstehen.
• Session Timeouts: Rekey/Idle-Timeouts an Firewalls oder Providern; SD-WAN interpretiert das als Loss.

Die praktische Konsequenz: Bei Pfadwahl-Fehlerbildern müssen Sie nicht nur „SLA besser“ betrachten, sondern auch „State bleibt gültig“. In manchen Designs ist ein stabiler Pfad mit etwas höherer Latenz besser als ein „optimaler“ Pfad, der Sessions bricht.

SLA-Design richtig kalibrieren: Schwellen, Probes und Hysterese

Viele SD-WAN-Fehler entstehen nicht durch kaputte Links, sondern durch unpassende SLA-Parameter. Ein gut kalibriertes SLA-Design ist realistisch, robust und service-spezifisch.

• Schwellen pro Applikation: Voice braucht niedriges Jitter/Loss, Bulk-Transfer braucht eher Stabilität und Durchsatz.
• Probe-Frequenz: zu selten übersieht Bursts; zu häufig belastet Links und erzeugt Noise. Hotspots häufiger, ruhige Sites seltener.
• Hysterese/Hold-down: verhindert Pfadflapping; ohne Hysterese wird ein „wackliger“ Link zur Dauerstörung.
• Messziele diversifizieren: nicht nur Hub, sondern ggf. SaaS/Internet-Targets, wenn Internet-Breakout relevant ist.

Observability-Korrelation: SLA-Metriken mit echten Netzwerk- und App-Signalen verbinden

In SD-WAN ist die schnellste RCA oft die Korrelation aus drei Signalquellen: Underlay-Counters, SD-WAN-SLA-Metriken und Applikationssignalen (Traces/Metriken). Wenn Sie diese Korrelation konsequent betreiben, erkennen Sie schnell, ob die Störung im Transport, im Overlay oder in der Policy liegt.

• Underlay: Interface errors/discards/drops, Queue-Drops, PPPoE/LTE Link Events.
• SD-WAN: SLA loss/jitter/latency pro Pfad, Policy Decisions, Path Change Events, Brownout Flags.
• Applikation: p95/p99 Latenz, Retransmissions, Timeout-Rate, DNS-Latenz. Bei verteilten Systemen helfen Traces (z. B. OpenTelemetry: OpenTelemetry Dokumentation).

Wenn SLA sagt „Link ok“, aber App p99 explodiert, messen Sie wahrscheinlich am falschen Ziel oder mit unrepräsentativen Probes. Wenn SLA schlecht ist, aber Underlay keine Drops zeigt, ist oft die Messmethode, DSCP-Klasse oder ein path-spezifischer ISP-Effekt die Ursache.

Beweisführung mit Packet Captures: gezielt, kurz, mehrpunktfähig

Packet Captures sind im SD-WAN besonders dann wertvoll, wenn Sie MTU/PMTUD, asymmetrische Pfade, Rekey-Probleme oder QoS-Markierungen beweisen müssen. Wichtig ist, nicht „alles“ zu capturen, sondern zielgerichtet: betroffene 5-Tuples, nur ein Zeitfenster, und idealerweise an zwei Punkten (vor und nach dem SD-WAN-Edge).

• Was Sie im PCAP suchen: Retransmissions, Out-of-Order, DSCP-Markierungen, ICMP PTB, Rekey/ESP-Verhalten.
• Ring Buffer: bei intermittierenden Fehlern rotierende Captures, um den Fehlerzeitpunkt einzufangen.
• Tooling: tcpdump Manpage und Wireshark Dokumentation.

Provider-Interaktion: Underlay Loss beweisbar machen

SD-WAN macht Underlays austauschbar – aber nicht automatisch gut. Wenn Underlay Loss oder Jitter ISP-seitig ist, brauchen Sie belastbare Nachweise, die über „es ist langsam“ hinausgehen.

• Zeitfenster und Häufigkeit: Wann tritt Loss auf? Tageszeit? Nur unter Last?
• Richtung: Upstream vs. Downstream; ist Loss symmetrisch?
• Hop-Lokalisierung: Traceroute/Path-Tests getrennt pro Link; idealerweise Messpunkte nahe am Edge und nahe am Hub.
• Interface-Counter: Zeigen, ob Loss bereits am Customer Edge entsteht (Drops) oder erst im Provider-Netz (keine lokalen Drops, aber end-to-end Loss).

Damit wird aus einem Gefühl eine RCA-These: „Loss entsteht hinter dem Demarc“ oder „Drops entstehen bereits im lokalen Shaper“.

Mitigation im Incident: Stabilisieren ohne die Policy zu zerstören

Im Incident brauchen Sie oft eine schnelle Stabilisierung. Wichtig ist, dass Mitigationen den Betrieb beruhigen, aber nicht dauerhaft die Sicherheits- und Steuerlogik aushebeln.

• Pfad flapping stoppen: Hysterese erhöhen, SLA-Schwellen realistisch setzen, „brownout“ statt „hard failover“ nutzen, wenn verfügbar.
• Voice priorisieren: QoS Trust und Queueing prüfen, Echtzeitverkehr auf den stabilsten Pfad pinnen.
• MTU kurzfristig entschärfen: MSS-Clamping für TCP, ICMPv6 PTB erlauben, Tunnel-MTU korrekt setzen.
• Auslöser isolieren: Backup-Fenster, große Uploads, Scan- oder Storm-Events drosseln, um Underlay zu beruhigen.
• Fallback-Pfad definieren: Für kritische Apps einen konservativen Pfad als Notbetrieb, bis Underlay stabil ist.

Runbook-Baustein: SD-WAN Troubleshooting in 15 Minuten

• Minute 0–3: Symptom präzisieren: Loss/Jitter/Latenz, welche Apps betroffen, welche Standorte, welche Zeitfenster. Klären: East-West (site-to-site) oder Internet-Breakout?
• Minute 3–6: Underlay prüfen: Interface Drops/Errors/Discards, Shaping-Profile, aktuelle Link-Events. Prüfen, ob Loss burstig oder dauerhaft ist.
• Minute 6–9: SLA Monitoring prüfen: Wie wird gemessen (Ziel, Interval, DSCP, Paketgröße)? Welche Pfade verletzen welche Schwellen? Gibt es Brownout-Events?
• Minute 9–12: Pfadwahl beweisen: Welche Applikation nutzt welchen Pfad? Gab es Flaps? Gibt es Asymmetrie/NAT/State-Probleme nach Failover?
• Minute 12–15: Mitigation: Flapping dämpfen, kritische Apps auf stabilen Pfad pinnen, MTU/MSS entschärfen, Provider-Nachweise sichern. Danach verifizieren: SLA stabiler, App p95/p99 sinkt, Nutzerimpact reduziert.

Weiterführende Quellen

• RFC 8201 für IPv6 PMTUD (relevant für SD-WAN-Encapsulation und MTU-Blackholes)
• RFC 2863 für IF-MIB Interfacecounter (Errors/Discards) als Grundlage für Underlay-Diagnosen
• RFC 7011 für IPFIX/Flow Telemetry als Werkzeug zur Lokalisierung von Pfad- und Traffic-Hotspots
• OpenTelemetry Dokumentation für Logs/Metrics/Traces-Korrelation, um Policy-Entscheidungen und Applikationsimpact besser zu belegen
• tcpdump Manpage und Wireshark Dokumentation für zielgerichtete Captures bei MTU/PMTUD, QoS-Markierungen und Rekey-/Tunnel-Analysen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.