February 15, 2026

Multi-Cloud-Networking: Underlay/Overlay aufs OSI-Modell mappen

Multi-Cloud-Networking: Underlay/Overlay aufs OSI-Modell mappen – das klingt zunächst nach Theorie, ist in der Praxis aber ein sehr wirksames Werkzeug für Architekturentscheidungen, Fehlersuche und Governance. Sobald Anwendungen über mehrere Clouds, Rechenzentren und SaaS-Anbindungen verteilt sind, wird die Netzwerklandschaft schnell unübersichtlich: Transit-Gateways, Virtual WANs, Cloud Routers, VPNs, Interconnects, Private Links, Service Meshes und Load Balancer erzeugen eine Schichtung aus physischen und virtuellen Komponenten. Genau hier hilft das OSI-Modell als gemeinsame Sprache. Es ermöglicht, Underlay (die transportierende Basis) und Overlay (die logisch darübergelegte Verbindungsebene) sauber zu unterscheiden, Abhängigkeiten sichtbar zu machen und Risiken gezielt zu isolieren. Wer Underlay/Overlay konsequent auf OSI-Schichten abbildet, kann typische Multi-Cloud-Probleme wie MTU-Mismatches, asymmetrische Pfade, Routing-Leaks, NAT-Nebenwirkungen, TLS-Inspektion oder DNS-Inkonsistenzen schneller eingrenzen. Gleichzeitig wird klar, an welcher Stelle Observability, Security Controls und Change-Prozesse ansetzen müssen, um Betriebssicherheit und Skalierbarkeit über Cloud-Grenzen hinweg zu gewährleisten.

Table of Contents

Warum Underlay/Overlay in Multi-Cloud oft verwechselt wird

In klassischen Netzen war das Underlay häufig „das Netzwerk“: Layer 2/3, Links, Router, IGP, BGP. In Multi-Cloud-Umgebungen verschiebt sich diese Wahrnehmung, weil Cloud-Anbieter Teile des Underlays abstrahieren oder als Managed Service anbieten. Dadurch entsteht ein häufiger Denkfehler: Man behandelt Cloud-Konnektivität wie einen monolithischen Tunnel und übersieht, dass darunter mehrere voneinander abhängige Schichten existieren. Ein typisches Beispiel ist ein IPsec-VPN zwischen Clouds. Auf dem Papier ist es „ein Tunnel“, operativ aber eine Kette aus physischer Trasse (bis zur Cloud-Edge), Provider-Transport, Cloud-Gateway, Crypto-Stack, Routing-Policies, NAT-Regeln und darüber liegende Applikationsprotokolle. Das OSI-Modell zwingt dazu, diese Kette zu entflechten.

Underlay: Alles, was die Pakete tatsächlich transportiert (physische und logische Transportpfade, L3-Routing, Provider-Backbones, Cloud-Backbones, Interconnects).
Overlay: Logik, die über dem Transport eine eigene Konnektivitätsebene bildet (Tunnels, VXLAN/EVPN, GRE, IPsec, SD-WAN-Overlays, Service-Mesh-Encapsulation, Applikations-Routing).

OSI als „Mapping-Layer“: Ein praktisches Modell für Multi-Cloud

Die zentrale Idee ist nicht, jede Cloud-Komponente „genau“ auf eine OSI-Schicht zu nageln, sondern eine konsistente Zuordnung zu schaffen, mit der Teams Ursachen schneller lokalisieren und Verantwortlichkeiten klarer abgrenzen. Besonders hilfreich ist eine zweigleisige Sicht:

Transport-Sicht: Welche OSI-Schichten werden benötigt, damit Pakete überhaupt ankommen (L1–L4)?
Service-Sicht: Welche Schichten bestimmen Identität, Policy und Verhalten für Anwendungen (L5–L7)?

In Multi-Cloud ist diese Trennung wichtig, weil viele Störungen nicht an „Kabeln“ scheitern, sondern an Session-Verhalten, DNS, Zertifikaten oder L7-Routing – und dennoch Symptome wie „Timeout“ oder „Packet Loss“ erzeugen.

Underlay auf OSI-Schichten abbilden

Layer 1: Physische Realität trotz Cloud-Abstraktion

Auch wenn Cloud „virtuell“ wirkt: Das Underlay beginnt physisch. Für Multi-Cloud bedeutet Layer 1 vor allem: Wie erreichen Daten deine Cloud-Edge? Relevante Elemente sind Cross-Connects, Provider-Leitungen, PoPs, Glasfasertrassen, sowie die physische Redundanz der Anbindung (diverse Trassen, getrennte Meet-Me-Rooms, getrennte Provider). Bei Cloud-Interconnect-Produkten ist die physische Topologie ein Kernbestandteil der Verfügbarkeit. Dokumentiere daher Fault Domains und Redundanzpfade explizit, selbst wenn ein Teil davon „Managed“ ist.

Trassen- und Standortdiversität (z. B. zwei Carrier, zwei PoPs)
Cross-Connect-Redundanz und getrennte Patchfelder
Kapazitätsgrenzen pro physischem Port/Link (Engpässe zeigen sich später als Latenz/Jitter)

Layer 2: Ethernet ist oft indirekt, aber nicht irrelevant

Im Cloud-Kontext ist Layer 2 häufig verborgen oder bewusst begrenzt. Trotzdem taucht L2 in hybriden und Multi-Cloud-Szenarien wieder auf, etwa bei Metro-Ethernet, beim Colocation-Interconnect oder in Virtualisierungslayern. Operativ relevant sind L2-Themen vor allem dann, wenn du VLANs, Trunking oder L2-Extender nutzt – oder wenn Cloud-Anbindungen auf Ethernet-Frames basieren. Typische Fehlerbilder sind Duplex-/Auto-Negotiation-Probleme, VLAN-Mismatch oder MAC-Learning-Grenzen in Zwischenkomponenten.

Layer 3: IP-Routing als Rückgrat des Underlays

Layer 3 ist das eigentliche Fundament für Multi-Cloud-Konnektivität: IP-Adressierung, Routing, Summarization, VRFs und Policies. Wenn Underlay/Overlay nicht sauber getrennt sind, kommt es zu Routing-Leaks, asymmetrischen Pfaden oder „Blackholing“. Besonders wichtig ist, dass du Routing-Domains definierst: Welche Präfixe gehören zu welcher Cloud/VPC/VNet, welche zu On-Prem, welche zu Shared Services?

Adressierungsplan mit Aggregation (Summarization) zur Begrenzung von Routing-Churn
BGP-Policies und Filterregeln (Import/Export), um Route Leaks zu verhindern
Klare Abgrenzung von „Transit“ vs. „Spoke“ (z. B. Hub-and-Spoke)

Für die Praxis ist ein Blick in die Routing-Grundlagen und BGP-Spezifikation hilfreich, etwa über den RFC Editor als zentrale Quelle für Internet-Standards.

Layer 4: Transportverhalten entscheidet über Stabilität

Viele Multi-Cloud-Probleme zeigen sich als L4-Symptome: TCP-Retransmissions, Timeouts, Verbindungsabbrüche oder UDP-Paketverluste. Dabei liegt die Ursache häufig tiefer (MTU, Fragmentierung, Policy, NAT, Tunnel-Overhead). Layer 4 ist deshalb ein wichtiger Diagnoseschritt: Wenn die Transportebene instabil ist, sind L7-Signale oft irreführend. Plane Underlay so, dass typische L4-Risiken minimiert werden:

MTU-End-to-End konsistent (inklusive Tunnel-Overhead) festlegen
Asymmetrie vermeiden, die Stateful Devices (NAT/Firewall) bricht
Health Checks und Load Balancer so gestalten, dass sie echte Pfade testen

Overlay auf OSI-Schichten abbilden

Overlay als „virtuelles Netzwerk“: Tunnels, Fabrics und Encapsulation

Overlays beginnen häufig auf Layer 3, wirken aber über mehrere OSI-Schichten hinweg. Ein VXLAN-Overlay kapselt Layer-2-Segmente in UDP/IP, IPsec kapselt und verschlüsselt IP-Pakete, SD-WAN packt Policies und Pfadsteuerung darüber. Wichtig ist: Overlay ist nicht „zusätzlich“, sondern oft die eigentliche Logik, die Segmentierung und Mandantenfähigkeit ermöglicht.

VXLAN: Kapselt Ethernet in UDP/IP, nutzt typischerweise eine Underlay-L3-Fabric; als Standardreferenz bietet sich die VXLAN-Spezifikation (RFC 7348) an.
IPsec: Schützt Daten auf Network Layer/Transportnähe, je nach Modus; als Einstieg dient eine IPsec-Architekturreferenz (RFC 4301).
GRE: Einfaches Tunneling, operativ oft wegen MTU und fehlender Security kritisch.

Layer 5: Session-Kontinuität über Cloud-Grenzen

Die Session-Schicht ist in modernen Architekturen selten als separates Protokoll sichtbar, aber konzeptionell zentral: Verbindungszustand, Wiederaufnahme, Failover-Verhalten, Sticky Sessions, Token-basierte Sessions oder Re-Auth-Mechanismen. In Multi-Cloud sind Session-Probleme häufig, weil Pfade wechseln: SD-WAN-Policies, Anycast-Edges, Load Balancer oder DNS-basierte Steuerung können dazu führen, dass Folgepakete in einer anderen Region oder Cloud landen.

Stateful Komponenten (NAT, Firewalls, LBs) domainweise isolieren
Session Resumption (z. B. TLS) und Retry-Logik bewusst testen
Idempotente APIs fördern, um Retries risikoärmer zu machen

Layer 6: Verschlüsselung und Datenformate als Betriebsfaktor

In Multi-Cloud ist Layer 6 praktisch immer präsent: TLS/mTLS, Zertifikate, Cipher-Suites, Kompression, Serialisierung (JSON/Protobuf) und damit verbundene Latenz- und Debugging-Effekte. Besonders kritisch wird es, wenn du Traffic an mehreren Stellen terminierst oder inspizierst (z. B. Edge WAF, internes Gateway, Service Mesh). Jede Terminierung erzeugt neue Failure Modes: Zertifikatsketten, SNI-Routing, Clock-Skew, Rotationsfehler.

Als robuste Grundlage lohnt sich die Orientierung an Empfehlungen zur TLS-Konfiguration, z. B. über den OWASP Cheat Sheet Series für praxisnahe Security-Standards.

Layer 7: Anwendungsrouting, Gateways und globale Steuerung

Layer 7 ist in Multi-Cloud häufig der eigentliche Orchestrator: API Gateways, Ingress Controller, Service Mesh Control Planes, WAF/CDN, globale Load Balancer und DNS-Policies steuern, wohin Requests gehen. Dadurch entsteht ein wichtiger Grundsatz: Ein stabiler Underlay/Overlay-Pfad garantiert noch keine stabile Anwendung, wenn L7-Routing-Regeln oder Abhängigkeiten unklar sind.

Globale Traffic-Steuerung (Geo, Weighting, Failover) mit klaren Kriterien
Dependency Chains sichtbar machen (Upstreams, Backends, Third Parties)
Fehlerklassifizierung nach Statuscodes, Timeouts und Retry-Mechanik

Das zentrale Bindeglied: MTU, Overhead und Fragmentierung richtig behandeln

Kaum ein Thema erzeugt so viele schwer zu diagnostizierende Multi-Cloud-Probleme wie MTU und Kapselungs-Overhead. Overlays „kosten“ Bytes; wenn das nicht eingeplant ist, entstehen Fragmentierung, Drops oder unerklärliche Performanceeinbrüche. Praktisch bedeutet das: Du brauchst eine End-to-End-MTU-Strategie, die Underlay und Overlay gemeinsam berücksichtigt.

Eine einfache Daumenregel ist: Effektive MTU = Underlay-MTU minus Overhead. Der Overhead hängt vom Tunneltyp ab. Formal lässt sich das so ausdrücken:

$MTU_effektiv = MTU_underlay - Overhead_overlay$

Wichtig ist weniger die exakte Zahl als der Prozess: Miss Path MTU, teste mit realen Paketgrößen und dokumentiere die zulässige MSS für TCP. In Cloud-Hybriden sind MTU-Inkonsistenzen besonders häufig, weil verschiedene Anbieter und Provider unterschiedliche Defaults haben.

Routing- und Policy-Grenzen: Underlay stabil halten, Overlay flexibel machen

Ein bewährtes Multi-Cloud-Prinzip ist die klare Aufgabenteilung:

Underlay: Stabil, wenige Protokolle, klare Redundanz, konservative Changes.
Overlay: Flexibel, segmentierend, mandantenfähig, schneller iterierbar.

Das erfordert definierte Policy-Grenzen. Wenn Overlay-Routen unkontrolliert ins Underlay „leaken“, wird jede Änderung am Overlay zur potenziellen Core-Störung. Nutze daher Filter, Limits und Aggregation:

Max-Prefix und Default-Route-Strategien pro Domain
Explizite Import/Export-Policies und Route Tags (z. B. Communities)
Summarization an Domain-Grenzen, um Routing-Explosionen zu vermeiden

Observability nach OSI: Welche Telemetrie Underlay und Overlay wirklich braucht

Multi-Cloud-Networking scheitert selten an fehlenden Tools, sondern an fehlender Schichtung: Man misst L7, wenn das Problem in L3 liegt, oder man sieht Paketverluste, ohne die zugehörige Domain zu kennen. OSI-Mapping hilft, Telemetrie gezielt zu planen.

Underlay-Telemetrie (L1–L4)

Latenz/Jitter/Loss pro Pfad (aktive Messung), ergänzt durch passive Counters
Interface- und Link-Metriken, soweit verfügbar (auch in Colocation/Provider-Edge)
Routing-Health: BGP/IGP Sessions, Route Changes, Convergence-Zeiten
Flow-Sicht: NetFlow/sFlow/IPFIX, um Verkehrsmuster und Hotspots zu erkennen

Overlay-Telemetrie (L3–L7)

Tunnel-Status, Rekey-Events (IPsec), Encapsulation Drops, MTU-Fehler
Policy-Entscheidungen: Welche Route/Which Path wurde gewählt und warum?
TLS-Metriken: Handshake-Zeit, Fehlercodes, Zertifikatslaufzeiten
Service-Telemetrie: Requests, Errors, SLOs, Traces über Zonen hinweg

Für die Korrelation über Domains hinweg ist ein einheitlicher Telemetrie-Standard hilfreich. Als Einstieg bietet sich die Dokumentation zu OpenTelemetry an, um Metriken, Logs und Traces konsistent zu erfassen.

Cloud-spezifische Bausteine korrekt einordnen, ohne sich in Produktnamen zu verlieren

Produktnamen ändern sich, Konzepte bleiben. Für das OSI-Mapping genügt es, typische Bausteine wiederzuerkennen: „Transit“, „Private Link“, „WAN Hub“, „Interconnect“, „Cloud Router“. Für die praktische Orientierung sind offizielle Cloud-Quellen dennoch nützlich:

Beim Mapping kannst du diese Fragen stellen: Ist das Feature eher Underlay (Transport, Routing, Backbone) oder Overlay (Encapsulation, Encryption, Segmentierung)? Auf welcher OSI-Schicht treten die häufigsten Failure Modes auf? Und wo liegt die operative Ownership (NetOps, SecOps, Platform, App)?

Security in Multi-Cloud: Zonenmodell statt Einzellösungen

Security wird in Multi-Cloud häufig als Sammlung von Tools umgesetzt: hier eine Firewall, dort ein WAF, zusätzlich mTLS, dazu IAM. Aus OSI-Sicht ist ein Zonenmodell robuster: Definiere Security Domains, die sich an Underlay/Overlay und OSI-Schichten orientieren.

Network-Zonen (L3/L4): VRFs, Segments, East/West vs. North/South, zentrale Policy-Gateways
Identity-Zonen (L5–L7): Service Identity, Zertifikats- und Key-Management, AuthN/AuthZ
Edge-Zonen (L7): WAF/CDN/Rate Limiting, Bot-Mitigation, DDoS-Strategie

Wichtig ist, dass Sicherheitskontrollen nicht „unsichtbare“ Fault Domains erzeugen. TLS-Inspektion, zentrale Certificate Authorities oder gemeinsame NAT-Gateways können sonst zum Shared Fate werden.

Troubleshooting-Logik: Symptome nach OSI sortieren, Underlay/Overlay getrennt prüfen

Im Incident hilft ein wiederholbares Vorgehen: Erst Underlay stabilisieren, dann Overlay verifizieren, dann L7 validieren. Eine kompakte Diagnose-Checkliste kann so aussehen:

L1/L2: Gibt es harte Link-Indikatoren (Down/Up, Errors) entlang der physischen Anbindung oder Colocation?
L3: Sind die erwarteten Routen vorhanden, korrekt gefiltert und stabil? Gibt es Asymmetrie?
L4: Siehst du Retransmissions, erhöhte RTT oder Timeouts? Passt MTU/MSS?
Overlay: Ist der Tunnel up, gibt es Rekey/Flaps, Drops durch Encapsulation oder Crypto?
L6/L7: Sind TLS/DNS/HTTP-Signale konsistent? Gibt es Policy-Änderungen am Gateway oder WAF?

Der Vorteil dieser Schichtung: Du vermeidest, L7-Fehlerbilder zu „überinterpretieren“, wenn die Transportebene bereits instabil ist. Gleichzeitig zwingt sie dazu, das Overlay nicht als Blackbox zu behandeln, sondern als eigene Domain mit messbaren Zuständen.

Designprinzipien für robuste Multi-Cloud-Fault-Domains

Zum Abschluss des Themenkomplexes ist es hilfreich, Fault Domains bewusst in das Underlay/Overlay-Design einzuweben. Multi-Cloud skaliert dann gut, wenn Fehler lokal bleiben und Changes kontrolliert ausgerollt werden.

Regionale Isolation: Hubs, Gateways und DNS-Policies pro Region/Zone trennen, statt global zu zentralisieren.
Staged Rollouts: Änderungen zuerst in einer Canary-Domain testen (eine Region, ein Hub, ein Segment).
Shared Services entkoppeln: DNS, PKI, Logging, Identity redundant und zonal betreiben, wo möglich.
Klare Ownership: Underlay (NetOps), Overlay (Platform/NetOps), L7-Steuerung (App/Platform) mit eindeutigen Schnittstellen.

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.