Begriff
Overlay Network
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Du hast zwei Server in verschiedenen Rechenzentren (oder Clouds). Sie können sich nur über das öffentliche Internet erreichen. Du willst aber, dass die Container auf Server A und Server B so tun, als wären sie im gleichen Raum (LAN). Du baust ein Overlay Network. Das ist ein virtueller Tunnel. Der Container schickt ein Paket an "10.0.0.5". Der Server verpackt dieses Paket in ein normales Internet-Paket (UDP), schickt es an Server B. Server B packt es aus und gibt es an Container B. Für die Container sieht alles flach und einfach aus. Die komplexe Realität (Router, Internet) wird "überlagert" (Overlay).
Merksatz: Ein virtuelles Netzwerk, das auf einer bestehenden physischen Netzwerkinfrastruktur (Underlay) aufgebaut ist, indem es Pakete einkapselt (Tunneling), um Verbindungen unabhängig von der Topologie des Underlays zu ermöglichen.
In Docker Swarm / Kubernetes ist das Standard.
docker network create -d overlay my-net.
Wenn du das machst, können Container auf verschiedenen Hosts miteinander sprechen.
Der User (Entwickler) merkt nicht, dass da Tunneling passiert.
Er pingt einfach den Hostnamen.
1. VXLAN (Virtual Extensible LAN)
Das Standard-Protokoll (RFC 7348).
Es nimmt ein Ethernet-Frame (L2) und packt es in ein UDP-Paket (Port 4789).
Vorteil: Du kannst 16 Millionen Netzwerke (VNI) haben (VLAN konnte nur 4096).
Nachteil: MTU Issues.
Das VXLAN-Header kostet 50 Bytes.
Wenn dein Container 1500 Bytes sendet, wird das Paket 1550 Bytes groß. Das passt nicht durchs Internet (MTU 1500). Es wird fragmentiert -> Langsam!
Lösung: Container MTU auf 1450 setzen (com.docker.network.driver.mtu).
2. BGP & Direct Routing (Calico)
Overlay ist langsam (Encapsulation kostet CPU). Coole Tools wie Calico versuchen, ohne Overlay auszukommen. Sie nutzen BGP (das Routing-Protokoll des Internets), um den echten Routern im Rechenzentrum beizubringen: "Die IP 10.0.0.5 ist auf Server A". Dann routen die echten Router das Paket native. Das ist "Wire Speed" (so schnell wie Kabel), aber erfordert, dass du Zugriff auf die Router hast (geht nicht in AWS VPC einfach so).
3. Encryption (WireGuard)
VXLAN ist unverschlüsselt. Wer das Kabel anzapft, liest mit. Moderne CNIs (Cilium, Calico) bieten "Transparent Encryption". Sie nutzen WireGuard oder IPsec, um den Tunnel zu verschlüsseln. Das macht das Overlay zum VPN.
1. Underlay MTU & Path MTU Discovery (PMTUD)
Das berüchtigste Problem bei Overlay-Netzwerken ist das MTU Blackholing. Ein Ethernet-Frame hat standardmäßig eine MTU von 1500 Bytes. Wenn Flannel (VXLAN) das Paket einkapselt, fügt es 50 Bytes Header hinzu (8B VXLAN + 8B UDP + 20B IP + 14B MAC). Das Paket wird 1550 Bytes groß. Das physische Router-Underlay schneidet Pakete > 1500 stumm weg (Drop). Das TCP-Syn-Ack kommt durch (weil es klein ist), aber sobald Daten (Payload) fließen, hängt die SSH/HTTP Connection stumm ("Connection Timeout"). Die Lösung in der Produktion: Entweder man setzt Jumbo-Frames ($9000$ MTU) auf allen physischen Switches des Rechenzentrums. Oder man zwingt die Container-veth-Interfaces hart auf eine MTU von $1450$. Alternativ verlässt man sich auf PMTUD (ICMP Type 3 Code 4 "Fragmentation Needed"), was aber oft von Firewalls blockiert wird, woraufhin das Blackholing wieder zuschlägt.
2. eBPF & XDP (Cilium Replacement)
Klassische Overlays nutzen den Linux TCP/IP Stack. Ein Paket von Pod A zu Pod B traversiert den internen Network-Stack extrem teuer: veth -> iptables (NAT) -> bridge -> vxlan-encap -> iptables -> eth0.
Moderne CNI-Plugins wie Cilium verwerfen iptables und oft auch VXLAN-Tunnels komplett.
Sie hooken Hooks direkt in den Netzwerk-Treiber der physischen Kartekarte mittels XDP (eXpress Data Path) via eBPF.
Anstatt das Paket hoch in den Linux-Kernel zu routern, fängt das eBPF C-Programm das Paket auf der Netzwerkkarte ab, schaut in seine interne eBPF-Map ("Wohin muss IP 10.0.0.5?"), modifiziert den L2-MAC Header direkt im RAM der Netzwerkkarte und jagt es im Bruchteil einer Mikrosekunde ("Wire Speed") Native über das Underlay weiter. CNI Latenz fällt um bis zu 400%.
3. IPinIP vs. VXLAN
In Kubernetes unterscheidet man zwischen L3-Tunneling und L2-Tunneling. IP-in-IP (oft in Calico genutzt) ist ein L3 Protokoll (IP-Paket versteckt in IP-Paket). Es ist extrem simpel, spart ca. 30 Byte Header-Overhead gegenüber VXLAN. Es funktioniert aber nur, wenn das Underlay echtes L3 Routing erlaubt (AWS VPC unterstützt IP-in-IP oft nicht von Haus aus!). VXLAN ist ein L2-in-L3 Tunnel. Es simuliert einen gigantischen, virtuellen Layer-2 Ethernet-Switch über das gesamte Rechenzentrum hinweg. Broadcasts (ARP) können über UDP-Multicast verteilt werden (was Cloud-Provider hassen). Dadurch eignet es sich auch für VM-Migrationen (vMotion), bei denen die virtuelle MAC-Adresse zwingend über Servergrenzen hinweg gleichbleiben muss.
Quick-Check
Underlay?
Das physische Netzwerk (Kabel, Switches, echte IPs). Das Overlay liegt auf dem Underlay. Wenn das Underlay kaputt ist (Kabel durchgeschnitten), geht das Overlay auch nicht.Warum UDP?
TCP-in-TCP Tunneling ("TCP Meltdown") ist katastrophal. Wenn das innere Paket verloren geht, wiederholt der innere TCP-Stack. Wenn das äußere auch wiederholt, potenziert sich die Latenz. Deshalb nutzt man für Tunnel immer UDP (Fire & Forget).Geneve Protokoll?
Der Nachfolger von VXLAN. Flexibler für Metadaten (Security Policies, Tracing IDs). Wird von OVN (Open Virtual Network) und modernen Clouds genutzt.