VXLAN

Entstehung und Beteiligte

VXLAN wurde von Ingenieuren bei VMware, Cisco, Broadcom und weiteren Unternehmen entwickelt. RFC 7348 veröffentlichte 2014 das Verfahren als informatorischen Standard.

Welches Problem sollte gelöst werden?

Rechenzentren benötigten mehr isolierte Segmente als die rund 4094 VLANs und wollten Layer-2-Netze über geroutete Layer-3-Fabrics ausdehnen. Virtuelle Maschinen sollten flexibel verschoben werden.

Technische Hürden und Lösungen

VXLAN kapselt Ethernet in UDP und benötigt Tunnelendpunkte. BUM-Verkehr, Lernen und Verteilung der Endpunktinformationen waren zunächst schwierig. EVPN mit BGP ersetzte viele flood-and-learn-Ansätze durch eine kontrollierte Steuerungsebene.

Standardisierung und Einordnung

Cloud- und Plattformtechnik entstand aus Rechenzentrum, Virtualisierung, verteilten Systemen und automatisierter Softwareauslieferung. Die grundlegenden Probleme sind nicht neu: Ressourcen müssen geteilt, Ausfälle abgefangen, Änderungen reproduzierbar und Lastspitzen bewältigt werden. Neu ist die hohe Automatisierung und die Möglichkeit, Infrastruktur über Programmierschnittstellen in kurzer Zeit zu erzeugen oder zu verwerfen.

Technik im praktischen Betrieb

Im praktischen Cloudbetrieb müssen Automatisierung und Kosten gemeinsam beobachtet werden. Ressourcen entstehen schnell, verschwinden aber nicht immer automatisch. Tags, Limits, Richtlinien und getrennte Konten oder Projekte schaffen Verantwortlichkeit. Verfügbarkeit sollte über mehrere Fehlerdomänen geplant und mit realen Wiederanlaufproben belegt werden. Ein Anbieter übernimmt Gebäude, Hardware und Teile der Plattform; Konfiguration, Identitäten, Daten, Anwendungen und Backups bleiben je nach Dienstmodell ganz oder teilweise beim Kunden.

Warum das Thema heute noch relevant ist

Viele Cloudbegriffe klingen neu, beschreiben aber bekannte verteilte Systeme unter stärkerer Automatisierung. Die Geschichte hilft, Marketing und Architektur zu trennen. Ein Dienst bleibt von Netz, Speicher, Konsens und Identitäten abhängig, auch wenn diese Schichten nicht sichtbar sind. Betreiber sollten deshalb Ausfallmodelle, Datenexport und Abhängigkeiten dokumentieren. Je bequemer ein verwalteter Dienst ist, desto wichtiger wird die Frage, welche Kontrolle bewusst an den Anbieter abgegeben wurde.

Daten und Meilensteine

• VXLAN verwendet eine 24-Bit-VNI.
• Damit sind rund 16 Millionen logische Segmente möglich.
• UDP 4789 ist der standardisierte Zielport.
• EVPN kann MAC- und IP-Erreichbarkeit per BGP verteilen.

Was ist VXLAN?

VXLAN (Virtual Extensible LAN, RFC 7348) ist ein Tunnelprotokoll, das Layer-2-Ethernet-Frames in UDP-Pakete einpackt und über ein Layer-3-IP-Netz transportiert. Das Ziel: Riesige, skalierbare Layer-2-Domänen aufzubauen, die physische Grenzen und Layer-3-Grenzen überschreiten.

Das Schlüsselproblem von VLAN: nur 4094 mögliche VLAN-IDs, keine Skalierung über Routing-Grenzen hinweg. VXLAN löst beides: Der VNI (VXLAN Network Identifier) ist 24 Bit groß — 16,7 Millionen virtuelle Netzsegmente. Perfekt für Multi-Tenant-Cloud-Infrastruktur.

VTEP, VNI und Paketstruktur

Kernelement ist der VTEP (VXLAN Tunnel Endpoint) — jeder Hypervisor/Switch/Router, der VXLAN kapseln und entkapseln kann. VTEPs haben eine reguläre IP-Adresse im Underlay-Netzwerk.

Paket-Aufbau: Outer Ethernet → Outer IP (Src: VTEP-A, Dst: VTEP-B) → UDP (Port 4789) → VXLAN Header (8 Byte, enthält 24-Bit VNI) → Inner Ethernet Frame → VM-Payload.

Overhead: +50 Byte. Bei Jumbo-Frames (9000 Byte) kein Problem. Bei Standard-1500-Byte-MTU muss entweder Jumbo-Frames im Underlay oder MSS-Clamping konfiguriert werden.

EVPN als Control-Plane

Ohne Control-Plane würden VTEPs MAC-Adressen durch Flooding lernen (wie ein normaler Switch). Bei Tausenden VMs und hunderten VTEPs erzeugt das enormen Overhead.

EVPN (Ethernet VPN, RFC 7432) nutzt MP-BGP als Control-Plane für VXLAN. VTEPs verteilen MAC- und IP-Adressen über BGP-EVPN-Updates, ohne zu fluten. Vorteile: Skalierbarkeit (Millionen MACs), schnelles Convergence, Integration mit IPv4/IPv6 Routing, Multi-Tenancy mit VRFs pro VNI.

VXLAN+EVPN ist heute der Standard für Data-Center-Fabrics bei Arista, Cisco, Juniper, Cumulus, Nokia.

VXLAN in Cloud-Umgebungen

AWS VPC, Azure VNet, Google Cloud VPC, OpenStack Neutron — alle nutzen VXLAN oder VXLAN-ähnliche Overlay-Technologien intern. Kunden sehen "virtuelle Netze" ohne zu wissen, dass darunter VXLAN läuft.

Kubernetes-CNI-Plugins wie Flannel (VXLAN-Mode), Calico, Cilium nutzen VXLAN für Pod-Kommunikation über Nodes hinweg. GENEVE (Generic Network Virtualization Encapsulation, RFC 8926) ist eine flexible Erweiterung von VXLAN und wird zunehmend von modernen CNIs genutzt.