SD-WAN Diagramme: Underlay, Overlay, Policies und DIA Breakouts

SD-WAN Diagramme sind in modernen WAN-Umgebungen das wichtigste Werkzeug, um Komplexität beherrschbar zu machen: Sie trennen Underlay und Overlay, machen Policies nachvollziehbar und zeigen, wo und wie Direct Internet Access (DIA) Breakouts tatsächlich stattfinden. Ohne diese Trennung entstehen typische „SD-WAN-Spaghetti“: Standorte sind irgendwie verbunden, irgendwo gibt es Tunnel, irgendwo entscheidet „die Policy“ – aber niemand kann im Incident schnell sagen, warum ein Flow gerade über LTE statt Broadband läuft, warum Voice-Traffic in Region A lokal ausbricht und in Region B zentral, oder warum ein bestimmter SaaS-Dienst plötzlich über einen Hub getunnelt wird. Gute SD-WAN Diagramme beantworten präzise Fragen: Welche Underlay-Transporte existieren pro Site (MPLS, Internet, LTE/5G)? Wie ist das Overlay aufgebaut (Full Mesh, Hub-and-Spoke, Regional Hubs)? Welche Traffic-Klassen gibt es, welche SLA-/SLO-Ziele gelten und welche Pfadwahl-Regeln steuern das? Wo sitzen Security Controls (Firewall, Proxy, SASE) und wie ist DIA Breakout geregelt? Dieser Artikel zeigt, wie Sie SD-WAN Diagramme professionell strukturieren und zeichnen – mit klaren Ebenen, wiederverwendbaren Templates, nachvollziehbaren Policy-Views und einem Diagramm-Portfolio, das Betrieb, Onboarding und Audits gleichermaßen unterstützt.

Warum SD-WAN ohne saubere Diagramm-Ebenen schwer zu betreiben ist

SD-WAN bringt Vorteile (schnelle Rollouts, zentrale Policies, bessere Pfadwahl), aber es bringt auch neue Fehlerklassen: Overlay-Kontrollplane, SLA-basierte Entscheidungen, mehrere Underlay-Links pro Site, dynamische Breakouts und oft eine enge Kopplung an Security-Services. Ohne Diagramme, die diese Ebenen trennen, wird Troubleshooting zum Ratespiel. Typische Symptome:

• Underlay/Overlay vermischt: Providerleitungen und Tunnel werden in einer einzigen Ebene gezeichnet – Pfade sind nicht interpretierbar.
• Policies bleiben „magisch“: es gibt Traffic-Klassen, aber niemand sieht, welche Regel wo greift.
• DIA ist unklar: „lokaler Internetzugang“ ist definiert, aber nicht sichtbar, welche Sites welche Breakout-Variante nutzen.
• Failure Domains fehlen: scheinbare Redundanz (zwei Links) ist in Wahrheit eine gemeinsame Trasse/Carrier oder ein gemeinsamer Hub.
• Onboarding dauert: neue Engineers verstehen die Plattform, aber nicht den konkreten Design-Intent.

Die Lösung ist ein bewusstes Diagramm-Portfolio: One Diagram per Question, mit Layered Views für Underlay, Overlay, Policy und Egress.

Das SD-WAN Diagramm-Portfolio: Welche Views Sie wirklich brauchen

Ein einzelnes SD-WAN Diagramm kann nie alles leisten. Ein praxistaugliches Portfolio besteht aus folgenden Sichten:

• SD-WAN Global Overview: Sites, Hubs, Regionen, Controller/Orchestrator (abstrahiert), grobe Topologie (Hub-Spoke/Partial Mesh).
• Underlay Transport Map: pro Site die physischen/Provider-Links (MPLS, Broadband, LTE/5G), inklusive Failure Domains.
• Overlay Topology Map: Tunnel/Overlay-Edges, Hub-and-Spoke, Regional Hubs, optional Full Mesh nur dort, wo nötig.
• Policy & Traffic Class View: Applikations-/Traffic-Klassen, SLA-Ziele, Pfadwahl-Regeln, Markierungen (DSCP) und Exceptions.
• DIA Breakout View: lokaler Egress, zentraler Egress, SASE/Proxy-Exit – mit Trust Boundaries und Logging-Hinweisen.
• Hybrid/Cloud On-Ramp View: Anbindung an DC/Cloud, BGP/Static Routes, Shared Services (DNS/PKI/Identity) und Region-Failover.

Wenn Sie Diagramme versionierbar halten möchten, kann Diagram-as-Code helfen (z. B. Mermaid, PlantUML). Wichtiger als das Werkzeug ist, dass jede View eine klare Fragestellung beantwortet.

Underlay sauber zeichnen: Providerlinks als Realität, nicht als „Wolke“

Das Underlay ist die physische Grundlage: echte Leitungen, echte Provider, echte Ausfallbilder. Ein Underlay-Diagramm muss deshalb mehr zeigen als nur „Internet“ und „MPLS“. Es soll erklären, welche Transportarten existieren und welche Abhängigkeiten sie teilen.

Was in ein Underlay-Diagramm gehört

• Linktypen: MPLS, Internet Broadband, DIA, LTE/5G, ggf. Satellite – als unterschiedliche Linienarten.
• Provider/Demarc: Carrier-A/B, Übergabepunkte (CPE/Demarc) als Failure Domain Marker.
• Bandbreitenklasse: nicht jede Zahl, aber z. B. „100M/1G“ oder „Primary/Secondary“.
• Regionale Abhängigkeiten: bei zentralen Hubs: welche Links sind regional gebündelt?

Failure Domains markieren

• Shared Carrier: zwei Links, aber gleicher Carrier → kein echter Diversity.
• Shared Last Mile: unterschiedliche Verträge, aber gleiche Trasse/PoP.
• Shared Power/CPE: beide Links hängen am selben Gerät/PDU.

Diese Markierungen sind entscheidend für Resilienz und Incident-Analyse und sollten im Underlay-View konsequent sichtbar sein.

Overlay verständlich zeichnen: Tunnel, Hubs und Regionen

Das Overlay ist die logische SD-WAN-Topologie: welche Edges bauen Tunnel zu welchen Hubs oder Peers auf, und wie wird Traffic über diese Tunnel geführt. Ein guter Overlay-View abstrahiert die Anzahl einzelner Tunnel und zeigt stattdessen Muster:

• Hub-and-Spoke: Sites (Spokes) verbinden zu Regional Hubs; Inter-Region über Hub-Hub oder Cloud Backbone.
• Partial Mesh: nur definierte Site-Gruppen meshen direkt (z. B. große DCs oder kritische Produktionsstandorte).
• Control Plane: Orchestrator/Controller als Management-Elemente (ohne zu tief in Vendor-Details zu gehen).
• Overlay Segmentation: getrennte VPNs/VRFs/Segments (z. B. Corp, Guest, IoT) als eigene Layer oder separate Diagramme.

Best Practice: Zeichnen Sie Overlay-Links als „Overlay Tunnel Class“ (z. B. „IPsec Overlay“) statt jeden einzelnen Tunnel zu labeln. Details gehören in Inventar/SoT oder in eine tabellarische Doku.

Policy-Views: Traffic-Klassen und SLA-basierte Pfadwahl nachvollziehbar machen

SD-WAN ist primär Policy-getrieben. Ein Diagramm, das Policies nicht sichtbar macht, ist nur halb nützlich. Der Trick ist, Policies nicht als Textwüste zu dokumentieren, sondern als strukturierte View: Traffic-Klassen → SLA → Pfadpräferenz → Fallback.

Traffic-Klassen als „Contract“

• Business Critical: Voice/Video, ERP, Produktionssysteme
• Standard: Office/SaaS, allgemeiner Datenverkehr
• Best Effort: Guest, Updates, Bulk Transfers

SLA-Metriken, die sich bewährt haben

• Latenz, Packet Loss, Jitter als Kernmetriken
• Brownout Detection: „Link up, aber schlecht“ als eigenes Ereignis
• Failover-Zeit: Zeit bis zur Pfadumschaltung

Pfadwahl als Regelkette darstellen

• Primärpfad (z. B. MPLS für Voice)
• SLA-Thresholds (z. B. Loss > 1% → Pfadwechsel)
• Fallback (z. B. Broadband, dann LTE)
• Exceptions (z. B. bestimmte SaaS immer DIA lokal)

Als Ergänzung zur Policy-View ist es hilfreich, die Begriffe SLI/SLO sauber zu verwenden. Für SLO-Konzepte bietet Google SRE – Service Level Objectives eine klare, allgemein anwendbare Definition.

DIA Breakouts: Lokaler Internetzugang ohne Unschärfe dokumentieren

DIA (Direct Internet Access) ist einer der häufigsten Gründe für SD-WAN, aber auch eine häufige Quelle für Sicherheits- und Compliance-Fragen. Diagramme müssen deshalb klar unterscheiden, welche Breakout-Modelle wo gelten.

Lokaler DIA Breakout

• Beschreibung: Internetzugang direkt am Standort über lokalen Provider.
• Vorteile: geringe Latenz zu SaaS, weniger Hub-Bandbreite.
• Risiken: Policy-Drift, ungleiches Logging, lokale Compliance-Anforderungen.
• Diagramm-Regel: lokaler Egress als eigener Kontrollpunkt (NAT/Firewall/Proxy) markieren, nicht als „Internet-Wolke“ ohne Boundary.

Zentraler Egress über Hub

• Beschreibung: Sites tunneln Internettraffic zum Hub, dort Security Stack (FW/Proxy) und Egress.
• Vorteile: einheitliche Policy und Evidence, zentrales Logging.
• Nachteile: Hairpinning, Latenz, Hub als potenzieller Bottleneck.
• Diagramm-Regel: zentrale Egress-Hubs als eigene Knoten mit Kapazitäts-/Redundanzhinweis.

Breakout über SASE/Proxy

• Beschreibung: Internetzugang über Cloud Security Service (SASE), policy- und identity-basiert.
• Vorteile: konsistente Controls global, gute Sichtbarkeit.
• Nachteile: zusätzliche Abhängigkeit, komplexe Fehlerdiagnose ohne Service Maps.
• Diagramm-Regel: SASE als Trust Boundary mit klaren Kontrollpunkten (Inspection, Auth, Logging) darstellen.

Für sicherheitsorientierte Mindestkontrollen sind die CIS Controls eine robuste Referenz (Zugriff, Logging, Change-Disziplin), die sich gut in DIA- und Breakout-Dokumentation übersetzen lässt.

Segmentierung im SD-WAN: VRFs, VPNs und Security-Zonen sichtbar machen

Viele SD-WAN-Designs tragen mehrere logische Netze über dasselbe Underlay: Corp, Guest, IoT, OT, Management. Diagramme müssen daher Segmentierung explizit zeigen, sonst entstehen gefährliche Annahmen („alles ist getrennt“).

• Separate Overlays: pro Segment eigene Tunnel-/Policy-Domäne oder logisch getrennte VRFs/VPNs.
• Inter-Segment Controls: wenn Segmente kommunizieren dürfen, muss der Kontrollpunkt sichtbar sein (Firewall, Service Chain).
• Mapping: wie werden VLANs/Subnetze am Edge in Segmente gemappt (z. B. VRF mapping, policy-based).

Eine gute Praxis ist, Segmentierung in einem eigenen „Security-Zones“-Diagramm zu zeigen, statt sie in Underlay/Overlay-Views zu verstecken.

Hybrid- und Cloud On-Ramps: SD-WAN endet nicht am Hub

SD-WAN ist selten isoliert. Meist verbindet es Standorte mit Rechenzentren, Cloud-Regionen und SaaS. Deshalb braucht es eine eigene View für On-Ramps:

• DC Hubs: Interconnect zu Core/DC-Fabric, Security Stack, Routing Boundary (BGP/Static).
• Cloud On-Ramps: direkte Anbindung an Cloud Netzwerkdomänen (z. B. VPC/VNet Hubs), inklusive Egress/Ingress Entscheidungen.
• DNS/Identity Dependencies: Resolver/SSO/PKI als kritische Services sichtbar.
• Fallback: VPN-Fallback oder zweiter Hub, inkl. Prioritäten.

Wenn Sie Cloud-Topologien einbeziehen, helfen Primärquellen der Provider als Outbound-Links, z. B. AWS VPC oder Azure VNet, um Begriffe und Bausteine konsistent zu halten.

Layout-Regeln: SD-WAN Diagramme lesbar gestalten

Lesbarkeit ist bei SD-WAN besonders wichtig, weil Underlay und Overlay häufig unterschiedliche Topologien besitzen. Bewährte Layout-Regeln:

• Underlay und Overlay trennen: entweder als zwei Diagramme oder als klar getrennte Layer im selben Dokument.
• Regionen clustern: Sites nach Region gruppieren, Hubs zentral pro Region darstellen.
• Linienmuster: Underlay-Links (Provider) vs. Overlay-Tunnel (IPsec) visuell unterscheiden.
• Policies als Legende: Traffic-Klassen, SLA-Thresholds und Breakout-Regeln als Legendenblock statt in jede Kante zu schreiben.
• „Wenige Labels, klare Bedeutung“: lieber eine konsistente Label-Syntax als viele individuelle Textfelder.

Diagramme operationalisieren: Versionierung, Reviews und Drift

SD-WAN ist dynamisch: neue Sites, neue Policies, neue Breakout-Entscheidungen. Diagramme veralten schnell, wenn sie nicht als Betriebsartefakt behandelt werden. Ein praxistaugliches Modell:

• Definition of Done: jede neue Site, Policy-Klasse oder DIA-Änderung erfordert Diagrammupdate.
• PR/MR-Workflow: Diagrammänderungen werden reviewed (WAN Owner + Security bei Breakout-Änderungen).
• CI Checks: Broken Links, Metadatenpflicht, ggf. Diagramm-Rendering (Diagram-as-Code).
• Drift-Check: Abgleich zwischen dokumentierten Policies und Plattform-Config/Telemetry (Reports statt stiller Abweichung).

Referenzen: GitHub Pull Requests, GitLab Merge Requests, CI: GitHub Actions.

Typische Anti-Pattern bei SD-WAN Diagrammen

• Unterlay als „Internet Cloud“: keine Failure Domains sichtbar; Lösung: Providerlinks und Diversity markieren.
• Overlay ohne Topologie: nur „SD-WAN verbindet alles“; Lösung: Hub/Spoke/Regional Hubs klar darstellen.
• Policies nur als Text: schwer nutzbar; Lösung: Policy-View mit Traffic-Klassen, SLA, Pfadpräferenz.
• DIA ohne Kontrollpunkte: Breakout ist nicht auditfähig; Lösung: Trust Boundaries (FW/Proxy/SASE) sichtbar machen.
• Segmentierung implizit: führt zu Sicherheitslücken; Lösung: Segmente als eigene Layer/Views.
• Keine Maintenance: Diagramme veralten; Lösung: DoD, Reviews, CI und Drift-Reports.

Checkliste: SD-WAN Diagramme für Underlay, Overlay, Policies und DIA Breakouts

• Das Hauptkeyword „SD-WAN Diagramme“ ist als Portfolio umgesetzt (Global Overview, Underlay Map, Overlay Map, Policy View, DIA Breakout View, Hybrid/Cloud On-Ramps)
• Underlay ist realistisch dargestellt (MPLS/Broadband/LTE, Provider/Demarc) und Failure Domains sind markiert
• Overlay zeigt die echte Topologie (Hub-Spoke, Regional Hubs, Partial Mesh) und Segmente/VRFs sind sichtbar
• Policy-View macht Traffic-Klassen, SLA-Thresholds und Pfadwahl-Regeln nachvollziehbar (inkl. Fallback)
• DIA Breakouts sind eindeutig (lokal vs. zentral vs. SASE) und Trust Boundaries/Kontrollpunkte (FW/Proxy/NAT) sind markiert
• Segmentierung und Inter-Segment Controls sind dokumentiert (keine implizite Trennung)
• Hybrid-Views zeigen DC/Cloud On-Ramps, Routing Boundaries und kritische Abhängigkeiten (DNS/Identity/PKI)
• Layout-Regeln sind konsequent (Linienmuster, Region-Cluster, Legende, minimale Labels, Whitespace)
• Diagramme sind „living“ (Definition of Done, PR/MR-Reviews, CI Checks, Drift-Abgleich)
• Outbound-Links sind gesetzt: SRE SLOs, CIS Controls, Mermaid, GitHub Pull Requests

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.