Overlay-Diagramme: EVPN/VXLAN, SD-WAN, SASE als eigene Ebenen

Overlay-Diagramme sind in modernen IT-Netzwerken unverzichtbar, weil sich die entscheidenden Funktionen immer häufiger von der physischen Infrastruktur (Underlay) entkoppeln. EVPN/VXLAN im Rechenzentrum, SD-WAN zwischen Standorten und SASE für sicheren Internet- und Cloud-Zugriff arbeiten alle nach demselben Grundprinzip: Ein logisches Netz wird über ein Transportnetz gelegt. Wer diese Ebenen in einem einzigen „Masterdiagramm“ vermischt, produziert schnell unlesbare Spaghetti-Pläne – und verliert im Betrieb den Überblick darüber, wo ein Problem tatsächlich entsteht: im Underlay (Link/MTU/Routing), im Overlay (Tunnel/Control-Plane/Policies) oder an den Service-Kontrollpunkten (Firewall, SWG, ZTNA). Genau deshalb sollten Overlays als eigene Diagramm-Ebene dokumentiert werden: mit klaren Leitfragen, konsistenten Symbolen und eindeutigen Boundaries. In diesem Artikel erfahren Sie, wie Sie Overlay-Diagramme für EVPN/VXLAN, SD-WAN und SASE sauber strukturieren, welche Inhalte hinein gehören (und welche nicht), und wie Sie daraus wartbare Artefakte für Architektur, Betrieb und Audit-Readiness machen.

Warum Overlays eigene Diagramme brauchen

Overlays lösen ein reales Problem: Skalierung und Flexibilität. VXLAN ermöglicht große L2/L3-Segmente über IP-Fabrics, EVPN standardisiert die Control-Plane dafür. SD-WAN abstrahiert Standortanbindungen und steuert Pfade anhand von Policies und Linkqualität. SASE verschiebt Security- und Access-Funktionen näher an Nutzer und Internet/Cloud und ersetzt klassische „Backhaul-zum-DC“-Modelle. Diese Systeme sind jedoch mehrschichtig: Sie haben Underlay-Transport, Overlay-Tunnel, Control-Plane (z. B. EVPN über BGP, SD-WAN Controller) und Service-Policies (Segmentierung, Security, QoS). Ein einziges Diagramm kann diese Schichten nicht gleichzeitig lesbar abbilden.

• Fehlerlokalisierung: Underlay-Probleme (MTU, Routing, Loss) sehen anders aus als Overlay-Probleme (Tunnel down, Control-Plane instabil, Policy-Mismatch).
• Änderungsrisiko: Overlay-Änderungen betreffen oft viele Standorte/Segmente gleichzeitig; Diagramme müssen Scope und Blast Radius zeigen.
• Kommunikation: Security, Netzwerk und Plattformteams benötigen unterschiedliche Sichten auf dasselbe System.
• Auditfähigkeit: Nachweise entstehen leichter, wenn Control-Plane, Segmentierung und Kontrollpunkte klar getrennt dokumentiert sind.

Das Grundmodell: Underlay, Overlay, Services als Layered Views

Ein praxistauglicher Ansatz ist die Aufteilung in drei Diagrammklassen, die Sie konsequent trennen und miteinander verlinken:

• Underlay-Diagramm: physische oder L3-Transporttopologie (Fabric, WAN-Links, Internet-Uplinks), inklusive Routing Domains und Redundanz.
• Overlay-Diagramm: Tunnel-Topologie und Control-Plane (VXLAN VTEPs, EVPN Route Types konzeptionell, SD-WAN Tunnels, Controller-Beziehungen).
• Service-/Policy-Diagramm: Segmentierung (VRFs/Segments), Security-Kontrollpunkte, Traffic-Flows (kritische Services), SASE Policies.

Der zentrale Vorteil: Jede Sicht hat eine Leitfrage. Das Overlay-Diagramm beantwortet nicht „welches Kabel“, sondern „welche logische Verbindung über welche Endpunkte“. Das Service-Diagramm beantwortet nicht „welcher Tunnel“, sondern „welcher Zugriff ist erlaubt und wo wird er kontrolliert“.

Overlay-Diagramm-Standards: Was in jedes Overlay-Diagramm gehört

Damit Overlay-Diagramme teamweit funktionieren, benötigen Sie einen Minimalstandard. Das Ziel ist nicht maximaler Detailgrad, sondern schnelle Orientierung. Diese Elemente sollten in jeder Overlay-Sicht verpflichtend sein:

• Scope: Region/Site/Datacenter/Cloud-Region, Umgebung (Prod/Non-Prod) und betroffene Tenants/VRFs.
• Overlay-Endpunkte: VTEPs, SD-WAN Edges, SASE Connectoren/PoPs als klare Symbole.
• Control-Plane: Controller/Route Reflectors/Peers als eigene Objekte und Linien (nicht mit Datenpfaden verwechseln).
• Data-Plane: Tunnel/Encapsulation als Linien, mit Typ (VXLAN, IPsec, GRE/UDP, vendor-spezifisch).
• Metadaten: Owner, Last updated, Version, Link zur Source of Truth (IPAM/CMDB/NetBox) und zu Runbooks.

EVPN/VXLAN: Overlay-Diagramme für die Datacenter-Fabric

EVPN/VXLAN wird häufig falsch dokumentiert: Entweder als L2-Plan (VLANs und Trunks), obwohl VXLAN über L3 transportiert, oder als L3-Plan (Spine-Leaf Routing), ohne die Overlay-Segmente sichtbar zu machen. Ein gutes EVPN/VXLAN Overlay-Diagramm trennt Underlay und Overlay: Underlay zeigt IP-Fabric und BGP/IGP, Overlay zeigt VTEPs, VNIs, VRFs und das Control-Plane-Prinzip. Sie müssen nicht jeden Route Type ausmalen, aber Sie sollten zeigen, wer mit wem Control-Plane spricht und welche Segmente darüber bereitgestellt werden.

Leitfragen für EVPN/VXLAN-Overlay-Diagramme

• Welche Geräte sind VTEPs, welche sind reine Underlay-Router?
• Wie ist die EVPN Control-Plane aufgebaut (iBGP/eBGP, RR-Design, Cluster-Grenzen)?
• Welche VRFs und VNIs (L2VNI/L3VNI) existieren auf hoher Ebene?
• Wo liegen Gateways (Distributed Gateway/Anycast) und wo sind Boundaries (DC-Edge, Firewall-Service-Insertion)?

Was Sie im EVPN/VXLAN-Overlay-Diagramm zeigen sollten

• Fabric als Underlay-Container: Spine/Leaf als Rollen, Underlay-Routing nur als Hinweis (z. B. „eBGP Underlay“).
• VTEP-Marker: Leaves/VTEP-fähige Geräte klar kennzeichnen.
• EVPN Peering: BGP-EVPN Sessions als Control-Plane-Linien, RR falls vorhanden.
• Segmente als Container: VRFs und deren VNIs als Kacheln/Boxen, nicht als Text an jedem Link.
• Service-Insertion: falls Firewalls/LBs in den Pfad eingebunden sind, als separate Service-Ebene verlinken.

Für VXLAN als Protokoll ist eine neutrale Primärreferenz RFC 7348 (VXLAN). Für EVPN als BGP-basierte Control-Plane eignet sich RFC 7432 (BGP MPLS-Based EVPN) als grundlegender Einstieg in EVPN-Konzepte.

Typische Fehler in EVPN/VXLAN-Diagrammen

• VLAN-Listen überall: VXLAN abstrahiert VLANs; zeigen Sie VNIs/VRFs als Segmente und verlinken Sie auf den VLAN/VNI-Katalog.
• Underlay und Overlay vermischt: Control-Plane-Linien (BGP EVPN) dürfen nicht wie Datenpfade aussehen.
• Kein Boundary-Design: DC-Edge, DCI, Internet/Partner-Exit fehlt; dabei entstehen dort die meisten Incidents.
• Keine Multi-Tenant-Sicht: VRFs/Segments sind nicht sichtbar; Security- und Operationsfragen bleiben unbeantwortet.

SD-WAN: Overlay-Diagramme für Tunnels, Controller und Path Selection

SD-WAN ist ein klassisches Overlay: Standorte werden über mehrere Underlays (MPLS, DIA, LTE/5G) verbunden, während ein Controller/Orchestrator Policies und Path Selection steuert. Ein SD-WAN-Overlay-Diagramm muss deshalb drei Dinge sichtbar machen: die Edge-Topologie (Sites, Hubs), die Tunnel-Topologie (Overlay-Tunnels über Underlays) und die Steuerung (Controller/Management Plane). Besonders wichtig ist die Trennung zwischen „Management/Control“ und „Data Plane“: Viele Betriebsfehler entstehen, weil zwar Datenpfade funktionieren, aber Controller-Konnektivität instabil ist – oder umgekehrt.

Leitfragen für SD-WAN-Overlay-Diagramme

• Welche Rolle hat ein Standort: Spoke, Hub, Regional Hub, Internet Breakout?
• Welche Underlays existieren (Carrier A/B, DIA, LTE), und wie viele Overlay-Tunnels werden darüber gebaut?
• Wie funktioniert Path Selection: nach Loss/Jitter/Latency (SLA) oder nach statischen Präferenzen?
• Wo sind die Security-Kontrollpunkte: lokal am Edge, zentral im Hub, oder als SASE-Integration?

Was Sie im SD-WAN-Overlay-Diagramm zeigen sollten

• Site-Container: pro Standort ein Block mit Edge(s), lokalem Breakout und optionalen Services.
• Overlay-Tunnels: Linien zwischen Edges/Hubs, mit Kennzeichnung „Overlay“; Underlay-Links separat und optional abstrakt.
• Controller/Orchestrator: als Management-/Control-Plane, verbunden mit Edges (separate Linienart).
• Segments/VRFs: wenn SD-WAN segmentiert (z. B. Corp/Guest/IoT), als eigene Overlay-Segmente darstellen.
• Failover-Intent: primär/backup oder active/active als visuelle Konvention (Linienarten).

Wie Sie Underlay und Overlay in SD-WAN sinnvoll kombinieren

• Underlay als Rahmen: zeigen Sie pro Standort, welche Transportarten existieren (MPLS/DIA/LTE), ohne jedes Carrier-Detail auszuschreiben.
• Overlay als logische Vollmesh-/Hub-Spoke-Sicht: welche Standorte sprechen direkt, welche über Hubs?
• SLA-Policies als Annotation: z. B. „Voice bevorzugt Pfad mit Loss<1%, Jitter<30ms“ als Kurzlabel.

SASE: Overlay-Diagramme für Security-as-a-Service und Identity-basierte Zugriffe

SASE wird oft missverstanden als „ein neues Tool“. In Wirklichkeit ist es ein Architekturprinzip: Netzwerk- und Security-Funktionen werden als Cloud-Service bereitgestellt, häufig über Points of Presence (PoPs), und Zugriffe werden stärker identitäts- und policybasiert (Zero Trust). SASE-Diagramme müssen deshalb nicht nur „Traffic geht ins Internet“ zeigen, sondern die Kontrollpunkte und Policy-Entscheidungen: Wer darf worauf zugreifen, über welchen PoP, mit welcher Authentisierung, und wie sind Standorte/Remote User angebunden?

Leitfragen für SASE-Overlay-Diagramme

• Welche Nutzerpfade gibt es: Branch-to-Internet, Remote User, Branch-to-Cloud, Branch-to-DC?
• Welche SASE-Funktionen sind im Einsatz: SWG (Secure Web Gateway), CASB, ZTNA, FWaaS, DLP?
• Wo liegen die PoPs und wie erfolgt die Anbindung (IPsec/GRE/Agent/Client Connector)?
• Welche Identity Provider und Geräte-Compliance-Checks steuern Zugriff (MFA, posture, Zertifikate)?

Was in ein SASE-Overlay-Diagramm gehört

• PoP-Cloud: als globaler Service-Container mit regionalen PoPs (nur die relevanten Regionen zeigen).
• On-Ramps: Branch Connector (IPsec/GRE), Remote User Client, Cloud Connector (VPC/VNet) als klare Endpunkte.
• Policy-Entscheidung: Identity/Device-Posture als eigenes Element (IdP, MDM, MFA), nicht nur „Firewall-Icon“.
• Servicepfade: Internet, SaaS, Private Apps (DC/Cloud) als Ziele, inklusive kurzer Kontrollhinweise („inspected“, „bypassed“ nur wenn begründet).
• Logging/Monitoring: Verweise auf Logquellen und Runbooks (z. B. „ZTNA auth fail“, „SWG block policy“).

Für eine praxisnahe Einführung in SASE-Begriffe und Funktionsbausteine kann eine neutrale Übersicht wie Cloudflare: What is SASE? hilfreich sein, um Teams auf gemeinsame Terminologie zu bringen.

Overlay-Segmentierung: EVPN Tenants, SD-WAN Segments, SASE Policies

Ein wiederkehrendes Muster: Overlays bringen neue Segmentierungsmechanismen. In EVPN/VXLAN sind es VRFs/VNIs, in SD-WAN Segmente/VRFs, in SASE oft policybasierte Zugriffsprofile. Diagramme sollten Segmentierung als eigene Ebene behandeln, damit Security-Reviews und Betrieb nicht zwischen Gerätenamen und Tunnelstrichen suchen müssen.

• Segment-Container: je Tenant/Zone ein klarer Rahmen (Prod/Non-Prod/Mgmt/Partner).
• Boundaries: wo wird segmentübergreifend kommuniziert (Firewall/Policy Engine), nicht „irgendwo im Netz“.
• Ausnahmen: befristete Cross-Segment-Flows als explizite Annotation („Exception bis Datum X“).

Kontroll- und Fehlergrenzen: Was Overlay-Diagramme für Betriebsteams leisten müssen

Overlay-Dokumentation ist dann gut, wenn sie beim Debugging sofort den richtigen Suchraum öffnet. Dazu müssen Sie Kontroll- und Fehlergrenzen sichtbar machen: Wo kann es scheitern, und wie zeigt sich das? Ein praktischer Ansatz ist, jede Overlay-Sicht mit „typischen Failure Domains“ zu ergänzen.

Typische Failure Domains in Overlays

• Underlay-Transport: MTU/MSS, Loss/Jitter, Routing-Stabilität, ECMP-Asymmetrie
• Overlay-Tunnel: IPsec-Rekey, Tunnel-Flaps, Encapsulation-Overhead
• Control-Plane: BGP EVPN Sessions, RR-Design, SD-WAN Controller Reachability
• Policy: Segment-Zuordnung, Security-Policies, Route Leaks/Exports, SASE Access Policies

Diagramm-Boundaries und Symbolik: So bleibt es lesbar

Overlay-Diagramme werden schnell unlesbar, wenn Control-Plane und Data-Plane gleich aussehen oder wenn Overlays als „Wolke“ ohne Endpunkte gezeichnet werden. Nutzen Sie bewusst unterschiedliche Linienarten und Container:

• Container: Underlay, Overlay, Segment/Policy als getrennte Rahmen
• Linienarten: solid = Data Plane, dashed = Control Plane, dotted = Management/Telemetry
• Endpunkt-Symbole: VTEP/Edge/PoP Connector als eigene Icons
• Legende: immer vorhanden, damit neue Leser sofort starten können

Für Cloud-nahe Darstellungen sind offizielle Icon-Sets hilfreich, weil sie eine gemeinsame Symbolsprache schaffen, z. B. AWS Architecture Icons oder Azure Architecture Icons.

Source of Truth und Verlinkung: Overlay-Diagramme als Verweisschicht

Overlay-Diagramme sollten nicht versuchen, alle Detaildaten zu enthalten (alle VNI-IDs, alle Site-Prefixe, alle Policy-Regeln). Stattdessen funktionieren sie am besten als „Verweisschicht“: Sie zeigen Struktur und Intent und verlinken auf führende Datenquellen (IPAM/DCIM/CMDB), Konfig-Repositories, Runbooks und Monitoring-Dashboards. So bleiben sie schlank und aktuell.

• IPAM/CMDB: Prefixe, VRFs, Sites, Circuits, Ownership
• Policy-Katalog: Segmentierung, erlaubte Flows, Ausnahmeprozesse
• Runbooks: Tunnel down, Rekey fail, Control-Plane issues, MTU-Probleme
• Monitoring: SLIs/SLOs, Tunnel-Health, Control-Plane Sessions, Loss/Jitter pro Pfad

Wenn Sie NetBox als technische Source of Truth einsetzen, ist die NetBox Dokumentation ein guter Ausgangspunkt für ein konsistentes Datenmodell und Verlinkungen.

Governance: Overlays als Living Documentation pflegen

Overlays ändern sich ständig: neue Sites, neue Cloud-Regionen, neue Segmente, neue Policies. Ohne Prozesskopplung veralten Diagramme schnell. Der wirksamste Hebel ist eine Definition of Done: Wenn ein Change Overlays betrifft, wird das entsprechende Overlay-Diagramm aktualisiert. Zusätzlich helfen Review-Zyklen für kritische Domains (Edge, DC-Transit, SASE Policies).

• Definition of Done: Diagramm-Update ist Pflicht bei neuen Tunnels, neuen Segments, neuen Control-Plane-Beziehungen
• Review-Zyklus: risikobasiert (z. B. monatlich Edge/SASE, quartalsweise DC-Fabric)
• Ownership: pro Overlay-Domain ein Owner (EVPN Team, SD-WAN Team, SASE/SecOps)
• Versionierung: Änderungen nachvollziehbar (z. B. Git/Docs-as-Code oder klare Versionsstände)

Wenn Sie Change- und Knowledge-Management strukturiert verankern möchten, kann ein ITIL-orientierter Rahmen helfen, z. B. ITIL Best Practices.

Typische Anti-Pattern bei Overlay-Diagrammen

• „Overlay als Wolke“: keine Endpunkte, keine Sessions; Lösung: VTEPs/Edges/PoPs klar darstellen.
• Control-Plane und Data-Plane identisch: führt zu falscher Fehlersuche; Lösung: Linienarten und Legende.
• Zu viel Detail: alle IDs und Listen im Diagramm; Lösung: Segmente als Container und Details verlinken.
• Keine Boundaries: unklar, wo Segmentierung und Policies greifen; Lösung: Policy-/Service-Ebene separat zeichnen.
• Keine Betriebsbezüge: keine Runbooks/Monitoring-Links; Lösung: Evidence-by-Design über Verlinkung.

Pragmatischer Start: Ein Overlay-Diagrammset, das sofort Nutzen bringt

Wenn Sie neu starten oder Diagrammchaos bereinigen, beginnen Sie mit den kritischsten Sichten. Die Erfahrung zeigt: Drei bis fünf Diagramme pro Domain reichen zunächst, wenn sie sauber gepflegt sind.

• EVPN/VXLAN: Fabric Underlay (hoch), EVPN Overlay (VTEPs/RR/VRFs), DC-Edge/Boundaries
• SD-WAN: Site Roles (Hub/Spoke), Overlay Tunnels + SLA Path Selection, Controller Reachability
• SASE: On-Ramps (Branch/Remote/Cloud), PoP-Regionen, Policy-/Identity-Flow zu Internet/SaaS/Private Apps

Checkliste: Overlay-Diagramme für EVPN/VXLAN, SD-WAN und SASE als eigene Ebenen

• Overlay-Diagramme sind von Underlay- und Service-/Policy-Diagrammen getrennt (Layered Views)
• Jedes Diagramm hat eine Leitfrage (Tunnel/Control-Plane/Segmente) und einen klaren Scope
• Control-Plane und Data-Plane sind visuell unterscheidbar (Linienarten, Legende)
• EVPN/VXLAN: VTEPs, EVPN BGP-Beziehungen, VRFs/VNIs und Boundaries (DC-Edge, Service-Insertion) sind sichtbar
• SD-WAN: Site-Rollen, Overlay-Tunnels, Underlays (abstrakt), Controller-Plane und Failover-Intent sind sichtbar
• SASE: PoPs, On-Ramps, Identity/Policy-Entscheidungen und Zielkategorien (Internet/SaaS/Private Apps) sind sichtbar
• Segmentierung wird als Container/Policy-Ebene dokumentiert (Tenants/Segments/Zonen) statt als Textlisten
• Diagramme verlinken auf Source of Truth und Runbooks statt Daten zu duplizieren (IPAM/CMDB, Monitoring)
• Metadaten sind verpflichtend (Owner, Last updated, Version) und Updates sind Teil der Done-Kriterien
• Outbound-Links nutzen Primärquellen und neutrale Referenzen (RFC 7348, RFC 7432, Cloud Icon Sets, ITIL)

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.