Site icon bintorosoft.com

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

Red Snapper

Close up of network equipment showing cables and server connections

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.

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.

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.

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.

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?

Typische SD-WAN Fehlerbilder und die schnellste Einordnung

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

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.

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:

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.

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.

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).

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.

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.

Runbook-Baustein: SD-WAN Troubleshooting in 15 Minuten

Weiterführende Quellen

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:

Lieferumfang:

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.

 

Exit mobile version