In klassischen Rechenzentren bildet das IEEE-802.1Q-VLAN seit Jahrzehnten die Grundlage für Layer-2-Segmentierung.
Jedes VLAN besitzt einen 12-Bit-Tag, was theoretisch 4.094 nutzbare Segmente erlaubt. In kleinen bis mittelgroßen
Umgebungen ist das vollkommen ausreichend. In modernen, mandantenfähigen Rechenzentren und insbesondere in
Cloud-Infrastrukturen stößt dieses Modell jedoch schnell an seine Grenzen.
Das erste Problem ist das schiere Skalierungslimit: 4.094 VLANs reichen in einem öffentlichen Cloud-Rechenzentrum
mit Tausenden von Kunden nicht aus, wenn jeder Kunde mehrere isolierte Netzwerksegmente benötigt. Das zweite Problem
ist die Reichweite: VLANs sind an die Spanning Tree-Topologie und die physischen Grenzen des Switching-Fabrics
gebunden. In einem modernen Leaf-Spine-Fabric, der auf geroutetem IP basiert, können klassische Layer-2-Domains
nicht einfach über Routing-Grenzen hinweg gespannt werden.
Dazu kommt das Problem der MAC-Tabellen-Skalierung auf Core-Switches: Wenn Tausende von VMs in einem gemeinsamen
Layer-2-Segment kommunizieren, müssen die Switches alle MAC-Adressen lernen und vorhalten. Das belastet den
CAM-Speicher der Hardware erheblich.
Die Antwort auf diese Herausforderungen sind Overlay-Netzwerke. Die Idee ist simpel: Layer-2-Frames werden in
IP-Pakete eingepackt (enkapsuliert) und über ein bestehendes Layer-3-Underlay-Netzwerk transportiert. Das
Underlay ist ein einfaches, routingfähiges IP-Netz – beispielsweise ein OSPF- oder BGP-basiertes Spine-Leaf-Fabric.
Das Overlay bildet darüber virtuelle Layer-2-Segmente, die vollständig unabhängig von der physischen Topologie sind.
VXLAN (Virtual Extensible LAN) ist heute der dominante Standard für solche Overlay-Netzwerke und wird von nahezu
allen modernen Switches, Hypervisoren und Software-Routern unterstützt. Selbst im Homelab lässt sich VXLAN
sinnvoll einsetzen, etwa um mehrere Proxmox-Nodes in einem gemeinsamen virtuellen Layer-2-Segment zusammenzuführen,
ohne physische Switche mit VLAN-Trunks zwischen den Nodes konfigurieren zu müssen.
2. VXLAN-Grundlagen
VXLAN ist in RFC 7348 definiert und löst das Skalierungsproblem klassischer VLANs auf elegante Weise. Statt eines
12-Bit-VLAN-Tags verwendet VXLAN einen 24-Bit-Identifier, den sogenannten VNI (VXLAN Network Identifier). Damit
sind theoretisch über 16 Millionen eigenständige Layer-2-Segmente möglich – mehr als genug für jeden denkbaren
Anwendungsfall.
2.1 VNI – VXLAN Network Identifier
Der VNI ist das VXLAN-Äquivalent zur VLAN-ID. Er identifiziert eindeutig das virtuelle Layer-2-Segment, zu dem
ein Paket gehört. VMs oder Container, die sich im selben VNI befinden, kommunizieren transparent auf Layer 2,
so als ob sie am selben physischen Switch hingen – unabhängig davon, auf welchem physischen Host sie laufen und
wie weit diese Hosts im IP-Netz voneinander entfernt sind. Im Homelab könnte VNI 100 z. B. das
Management-Netz repräsentieren und VNI 200 das Produktions-Netz für VMs.
2.2 VTEP – VXLAN Tunnel Endpoint
Der VTEP (VXLAN Tunnel Endpoint) ist die Instanz, die VXLAN-Enkapsulierung und -Dekapsulierung durchführt. In
einer virtualisierten Umgebung ist der VTEP typischerweise ein virtuelles Netzwerk-Interface auf dem Hypervisor-Host.
In einer hardwarebasierten Umgebung übernimmt diese Funktion der physische Switch. Ein VTEP hat immer eine
IP-Adresse im Underlay-Netz – die sogenannte VTEP-IP. Sie ist gleichzeitig die Quelladresse der UDP-Pakete,
die VXLAN-enkapsulierte Frames transportieren. Typischerweise wird dafür eine Loopback-Adresse verwendet,
da diese unabhängig von einem bestimmten physischen Interface ist und auch bei einem Link-Failover erhalten bleibt.
2.3 MAC-in-UDP – Das Enkapsulierungsformat
VXLAN kapselt den originalen Ethernet-Frame inklusive des Layer-2-Headers in einen UDP-Payload ein. Das
resultierende Paket hat folgende Struktur:
Der UDP-Zielport 4789 ist der von der IANA offiziell zugewiesene Port für VXLAN. Der UDP-Quellport wird
typischerweise durch Hashing der inneren Frame-Header variiert (z. B. Inner-IP-5-Tuple: Src-IP, Dst-IP,
Protokoll, Src-Port, Dst-Port), um ECMP-Lastverteilung (Equal-Cost Multi-Path) im Underlay-Netz zu
ermöglichen. So verteilen sich unterschiedliche Flows gleichmäßig über mehrere parallele Uplinks, ohne dass
Pakete innerhalb eines Flows umgeordnet werden.
Der VXLAN-Header selbst ist 8 Byte groß. Das erste Byte enthält ein Flag-Feld, von dem aktuell primär das
I-Flag (VNI Present) genutzt wird. Die Bytes 4 bis 6 enthalten den 24-Bit-VNI, das letzte Byte ist reserviert.
2.4 Overhead und MTU
VXLAN fügt einem Paket insgesamt 50 Byte Overhead hinzu: 14 Byte Outer-Ethernet-Header, 20 Byte Outer-IP-Header,
8 Byte UDP-Header und 8 Byte VXLAN-Header. Um Fragmentierung zu vermeiden, sollte die MTU im Underlay-Netz auf
mindestens 1550 Byte gesetzt werden, wenn im Overlay Standard-Ethernet mit 1500-Byte-MTU verwendet wird. In
der Praxis werden häufig Jumbo Frames mit 9000 Byte MTU im Underlay eingesetzt – das eliminiert das
MTU-Problem vollständig und gibt auch für zukünftige Overhead-Erweiterungen ausreichend Puffer.
3. Flood & Learn vs. EVPN
VXLAN definiert den Enkapsulierungsmechanismus, löst aber nicht das Problem der Control Plane: Woher weiß ein
VTEP, hinter welcher VTEP-IP sich eine bestimmte Ziel-MAC-Adresse verbirgt? Für dieses Problem gibt es
mehrere Ansätze.
3.1 Flood & Learn mit Multicast
Der ursprüngliche Ansatz aus RFC 7348 ist Flood & Learn über IP-Multicast. Jeder VNI wird einer Multicast-Gruppe
im Underlay zugeordnet. Wenn ein VTEP einen Frame für eine unbekannte MAC-Adresse senden muss, enkapsuliert er
ihn in ein Multicast-Paket, das alle VTEPs des betreffenden VNI empfangen. Diese dekapsulieren den Frame,
lernen dabei die Quell-MAC und Quell-VTEP-IP und können bei Bedarf antworten. Die Antwort erreicht den
ursprünglichen VTEP als Unicast, der daraufhin die Ziel-MAC-zu-VTEP-Zuordnung in seiner Forwarding-Tabelle
speichert.
Der Nachteil: Das Underlay muss PIM (Protocol Independent Multicast) und IGMP unterstützen, was in
Leaf-Spine-Fabrics zusätzlichen Konfigurationsaufwand bedeutet. Zudem erzeugt BUM-Traffic (Broadcast, Unknown
Unicast, Multicast) erhebliche Last, da er zu allen VTEPs eines VNI geflutet wird – auch wenn dort keine VMs
dieses VNI laufen. Skalierbarkeit und Effizienz leiden darunter erheblich.
Eine Alternative ohne Multicast ist Ingress Replication (auch Head-End Replication genannt): Der sendende VTEP
vervielfältigt BUM-Pakete selbst und sendet individuelle Unicast-Kopien an alle bekannten VTEPs eines VNI.
Das vermeidet Multicast im Underlay, erzeugt aber CPU- und Bandbreitenlast auf dem sendenden VTEP. Im Homelab
mit zwei oder drei Nodes ist das jedoch vollkommen vertretbar.
3.2 EVPN als moderne Control Plane
EVPN (Ethernet VPN, RFC 7432 und RFC 8365) ist der heute empfohlene Ansatz für produktive VXLAN-Umgebungen.
Anstatt MAC-Adressen durch Flooding zu lernen, werden sie proaktiv über ein Routing-Protokoll – typischerweise
MP-BGP – zwischen den VTEPs ausgetauscht. Jeder VTEP gibt bekannt, welche MAC-Adressen (und optional
IP-Adressen) er lokal bedient. Alle anderen VTEPs empfangen diese Information und tragen sie in ihre lokalen
Forwarding-Tabellen ein.
Das Ergebnis: BUM-Traffic wird drastisch reduziert, da die meisten Unicast-Ziele direkt ohne vorheriges
Flooding angesprochen werden können. Die Infrastruktur skaliert besser, die Konvergenz ist schneller und das
Verhalten ist vorhersehbarer. EVPN ermöglicht zudem Distributed Anycast Gateway, optimiertes ARP-Suppression
und Layer-3-VPN-Integration in einem einheitlichen Kontrollprotokoll.
4. EVPN mit BGP
EVPN nutzt MP-BGP (Multiprotocol BGP, RFC 4760) als Transportprotokoll für Erreichbarkeitsinformationen. BGP
wird um die neue Address Family EVPN (AFI 25, SAFI 70) erweitert. Über diese Address Family werden
EVPN-spezifische Route-Typen ausgetauscht. BGP eignet sich ideal für diesen Zweck, da es bereits in den
meisten großen Netzwerken vorhanden ist, gut skaliert und eine differenzierte Import-/Export-Steuerung über
Route Targets erlaubt.
4.1 Route Type 2 – MAC/IP Advertisement Route
Route Type 2 ist der wichtigste EVPN-Route-Typ. Er kündigt eine MAC-Adresse an, optional zusammen mit der
zugehörigen IP-Adresse (ARP-Binding). Das ermöglicht anderen VTEPs sowohl die Layer-2-Weiterleitung (anhand
der MAC) als auch die direkte Layer-3-Weiterleitung (anhand der IP) ohne vorherigen ARP-Request.
Das Unterdrücken von ARP-Requests im Netz bezeichnet man als ARP Suppression und ist ein wesentlicher
Vorteil von EVPN gegenüber Flood & Learn: Anstatt einen ARP-Request zu fluten, beantwortet der lokale
VTEP diesen direkt aus seiner BGP-gelernten Tabelle.
Ein RT-2-Präfix enthält unter anderem: Ethernet Segment Identifier (ESI), Ethernet Tag ID,
MAC-Adresslänge, MAC-Adresse, IP-Adresslänge, IP-Adresse (optional) sowie den VNI als Label-Attribut.
4.2 Route Type 3 – Inclusive Multicast Ethernet Tag Route
Route Type 3 dient der BUM-Traffic-Übermittlung ohne Multicast-Underlay. Jeder VTEP kündigt über RT-3 an,
dass er BUM-Traffic für einen bestimmten VNI via Ingress Replication empfangen möchte. Der BGP-Next-Hop
enthält die VTEP-IP. Alle anderen VTEPs, die diese Route empfangen, fügen den Ankündigenden ihrer
BUM-Replication-Liste für diesen VNI hinzu. Damit entsteht eine vollständige Mesh-Topologie für BUM-Traffic,
die vollständig durch den BGP-Prozess verwaltet wird – ohne manuelle Konfiguration von Multicast-Gruppen
oder statischen Peer-Listen.
4.3 Route Distinguisher und Route Target
Wie in klassischen L3-VPNs verwendet EVPN Route Distinguisher (RD) zur eindeutigen Identifikation von
Präfixen verschiedener VTEPs in der BGP-Tabelle und Route Target (RT) zur Import-/Export-Steuerung.
VTEPs, die denselben VNI bedienen, müssen kompatible Route Targets konfigurieren, damit die gegenseitige
Übernahme der BGP-EVPN-Routen funktioniert. In der Praxis wird häufig Auto-Derivation verwendet: RD und RT
werden automatisch aus der BGP-Router-ID und dem VNI berechnet, was manuelle Fehler vermeidet.
5. Praxisbeispiel mit FRRouting
Das folgende Beispiel zeigt eine minimale VXLAN/EVPN-Konfiguration auf Basis von FRRouting (frr) auf Linux.
Es gibt zwei Hosts (VTEP1 und VTEP2), die jeweils ein VXLAN-Interface für VNI 1000 betreiben und sich per
eBGP über ihre Loopback-Adressen verbinden. Diese Konstellation ist typisch für ein Homelab mit zwei
Proxmox- oder Debian-Servern.
5.1 Systemvoraussetzungen
Beide Hosts laufen mit Linux (Debian 12 oder Ubuntu 22.04), FRRouting ab Version 8.x und einem Kernel ab
Version 5.4. Zwischen den beiden Hosts gibt es IP-Konnektivität über das Underlay-Interface (hier eth0).
# Loopback-Adresse setzen (als VTEP-IP)
ip addr add 192.168.100.1/32 dev lo
# VXLAN-Interface erstellen
ip link add vxlan1000 type vxlan \
id 1000 \
local 192.168.100.1 \
dstport 4789 \
nolearning
# Linux Bridge erstellen und VXLAN-Interface einbinden
ip link add br1000 type bridge
ip link set br1000 ageing 0
ip link set vxlan1000 master br1000
ip link set vxlan1000 up
ip link set br1000 up
# ARP-Suppression via EVPN aktivieren
bridge link set dev vxlan1000 neigh_suppress on
bridge link set dev vxlan1000 learning off
5.3 FRRouting-Konfiguration auf VTEP1
! /etc/frr/frr.conf auf VTEP1
frr version 8.5
frr defaults datacenter
hostname vtep1
log syslog informational
ip router-id 192.168.100.1
! Statische Route zum Underlay-Peer (alternativ: OSPF)
ip route 192.168.100.2/32 10.0.0.2
! BGP-Konfiguration
router bgp 65001
bgp router-id 192.168.100.1
no bgp ebgp-requires-policy
neighbor 192.168.100.2 remote-as 65002
neighbor 192.168.100.2 update-source lo
address-family l2vpn evpn
neighbor 192.168.100.2 activate
advertise-all-vni
exit-address-family
!
5.4 FRRouting-Konfiguration auf VTEP2
! /etc/frr/frr.conf auf VTEP2
frr version 8.5
frr defaults datacenter
hostname vtep2
log syslog informational
ip router-id 192.168.100.2
ip route 192.168.100.1/32 10.0.0.1
router bgp 65002
bgp router-id 192.168.100.2
no bgp ebgp-requires-policy
neighbor 192.168.100.1 remote-as 65001
neighbor 192.168.100.1 update-source lo
address-family l2vpn evpn
neighbor 192.168.100.1 activate
advertise-all-vni
exit-address-family
!
Wenn auf beiden Hosts ein Linux-Netzwerk-Namespace mit einer IP-Adresse im selben Subnetz an die Bridge
br1000 angebunden ist, sollten beide Endpoints sich gegenseitig per Ping erreichen, sobald FRRouting die
RT-2- und RT-3-Routen ausgetauscht hat.
# Auf VTEP1: Namespace erstellen und an Bridge binden
ip netns add ns-tenant-a
ip link add veth0 type veth peer name veth0-br
ip link set veth0 netns ns-tenant-a
ip link set veth0-br master br1000
ip link set veth0-br up
ip netns exec ns-tenant-a ip addr add 10.100.0.1/24 dev veth0
ip netns exec ns-tenant-a ip link set veth0 up
# Auf VTEP2: analog mit 10.100.0.2/24
# Test:
ip netns exec ns-tenant-a ping 10.100.0.2
6. VXLAN in Proxmox SDN
Proxmox VE ab Version 7.0 enthält ein integriertes SDN-Modul (Software Defined Networking), das
VXLAN-Zonen mit optionaler EVPN-Integration unterstützt. Das SDN-Modul abstrahiert die manuelle
Linux-Kernel- und FRRouting-Konfiguration vollständig und bietet eine grafische Oberfläche sowie eine
REST-API. Für den Homelab-Betrieb ist das SDN-Modul eine enorme Vereinfachung gegenüber manueller
Konfiguration.
6.1 SDN-Konzepte in Proxmox
Proxmox SDN kennt drei Kernkonzepte: Zones, VNets und Subnets. Eine Zone definiert den Netzwerktyp
(Simple, VLAN, QinQ, VXLAN oder EVPN). Ein VNet ist ein virtuelles Netzwerk innerhalb einer Zone –
vergleichbar einem VLAN oder VNI. Es erscheint als auswählbare Bridge in der VM-Konfiguration.
Ein Subnet definiert optional den IP-Adressbereich und Gateway eines VNet und ermöglicht
IPAM-Integration für automatische IP-Vergabe.
6.2 VXLAN-Zone ohne EVPN
Eine einfache VXLAN-Zone ohne EVPN nutzt Ingress Replication mit einer statisch konfigurierten Liste
von Peer-VTEP-IPs. Die Konfiguration erfolgt in der Proxmox-Weboberfläche unter
Datacenter → SDN → Zones. Hier wird der Typ "VXLAN" gewählt und die IP-Adressen aller Nodes als Peers
eingetragen. Proxmox generiert daraus die Konfigurationsdateien:
# Aequivalente Konfiguration in /etc/pve/sdn/zones.cfg
zone: vxlan-zone1
type vxlan
peers 10.0.0.1,10.0.0.2,10.0.0.3
mtu 1450
# VNet-Definition in /etc/pve/sdn/vnets.cfg
vnet: vnet100
zone vxlan-zone1
tag 1000
Nach dem Speichern und Anwenden via "Apply" generiert Proxmox automatisch die entsprechenden
Linux-Bridge- und VXLAN-Interfaces auf allen Cluster-Nodes. Die VMs können dann das VNet
"vnet100" als Netzwerkadapter auswählen.
6.3 EVPN-Zone in Proxmox
Für größere Umgebungen oder Setups, bei denen keine statische Peer-Liste gepflegt werden soll,
empfiehlt sich eine EVPN-Zone. Proxmox konfiguriert dabei automatisch FRRouting auf jedem Node.
Es wird ein BGP-ASN für die Zone sowie die VTEP-IPs der Nodes definiert. Optional kann ein
dedizierter Route-Reflector konfiguriert werden, damit nicht jeder Node eine BGP-Session zu jedem
anderen Node aufbauen muss (Full-Mesh vermeiden).
# /etc/pve/sdn/zones.cfg – EVPN-Zone
zone: evpn-zone1
type evpn
vrf-vxlan 4000
controller evpn-ctrl1
mac 8a:0a:00:00:00:01
Proxmox schreibt daraufhin die FRRouting-Konfiguration nach /etc/frr/frr.conf und startet den
frr-Dienst neu. VMs, die mit einem VNet der EVPN-Zone verbunden sind, kommunizieren automatisch
über VXLAN/EVPN – der Administrator muss keine manuellen Bridge- oder Routing-Konfigurationen
vornehmen.
6.4 Distributed Anycast Gateway
Wenn einem VNet ein Subnet mit Gateway zugewiesen wird, konfiguriert Proxmox automatisch ein
Distributed Anycast Gateway: Alle Nodes in der EVPN-Zone verwenden dieselbe MAC-Adresse (die
konfigurierte Zone-MAC, z. B. 8a:0a:00:00:00:01) für das Gateway-Interface des
jeweiligen VNet. VMs können ihren Default-Gateway lokal auf dem jeweiligen Hypervisor-Node
auflösen und nutzen, ohne dass Traffic zu einem zentralen Router laufen muss. Das reduziert
Latenz und vermeidet Trampoline-Routing – besonders wichtig wenn VMs eines Tenants auf
verschiedenen Nodes laufen und miteinander kommunizieren.
7. Troubleshooting
Wenn VXLAN/EVPN nicht wie erwartet funktioniert, helfen folgende Kommandos bei der Diagnose. Die typischen
Fehlerquellen sind: falsche MTU im Underlay, fehlende oder fehlerhafte BGP-Session, falsch konfigurierte
Route Targets sowie Firewall-Regeln, die UDP-Port 4789 blockieren.
7.1 Bridge FDB – Forwarding Database prüfen
Die Bridge Forwarding Database zeigt, welche MAC-Adressen dem VXLAN-Interface bekannt sind und über welche
Remote-VTEP-IP sie erreichbar sind. Im EVPN-Betrieb sollten hier Einträge erscheinen, die über BGP gelernt
wurden – erkennbar an der Remote-VTEP-IP im Dst-Feld.
# FDB des VXLAN-Interfaces anzeigen
bridge fdb show dev vxlan1000
# Erwartete Ausgabe fuer EVPN-gelernten Eintrag:
# aa:bb:cc:dd:ee:ff dst 192.168.100.2 self
# 00:00:00:00:00:00 dst 192.168.100.2 self permanent
# (All-Zero-Eintraege sind BUM-Replication-Ziele aus RT-3)
7.2 VXLAN-Interface-Details
# Detaillierte Infos zum VXLAN-Interface
ip -d link show vxlan1000
# Relevante Felder in der Ausgabe:
# vxlan id 1000 – VNI
# local 192.168.100.1 – lokale VTEP-IP
# dstport 4789 – UDP-Zielport
# nolearning – Data-Plane-Learning deaktiviert (korrekt fuer EVPN)
# proxy – ARP-Proxy aktiv (wenn neigh_suppress gesetzt)
7.3 ARP- und Neighbor-Tabelle der Bridge
# Neighbor-Tabelle der Bridge (fuer ARP-Suppression)
bridge neigh show dev br1000
# EVPN-gelernte Nachbarn (IP-zu-MAC-Bindung aus RT-2)
ip neigh show dev br1000
7.4 tcpdump auf VTEP-Interface
# UDP-Port 4789 auf dem physischen Interface mitschneiden
tcpdump -i eth0 -n udp port 4789
# Mit erweiterter Ausgabe (neuere tcpdump-Versionen)
tcpdump -i eth0 -n udp port 4789 -v
# Nur Pakete von/zu einer bestimmten VTEP-IP
tcpdump -i eth0 -n "udp port 4789 and host 192.168.100.2"
7.5 BGP EVPN Routen in FRRouting debuggen
# Alle EVPN-Routen anzeigen
vtysh -c "show bgp l2vpn evpn"
# Nur RT-2 (MAC/IP Advertisement) Routen
vtysh -c "show bgp l2vpn evpn route type macip"
# Nur RT-3 (IMET/BUM Replication) Routen
vtysh -c "show bgp l2vpn evpn route type multicast"
# VNI-Tabelle: welche VNIs sind lokal bekannt?
vtysh -c "show vxlan vni"
# Detaillierte VNI-Infos inkl. Remote-VTEPs
vtysh -c "show evpn vni detail"
# BGP-Neighbor-Status fuer EVPN-Peer
vtysh -c "show bgp neighbors 192.168.100.2"
7.6 Häufige Fehlerquellen
Wenn die BGP-Session steht, aber keine RT-2-Routen ausgetauscht werden, ist advertise-all-vni
in der FRRouting-Konfiguration häufig vergessen, oder das VXLAN-Interface ist noch nicht aktiv wenn
FRRouting startet. In diesem Fall hilft ein Neustart von FRRouting nach dem Hochfahren der
VXLAN-Interfaces oder die Verwendung eines systemd-Service mit expliziten
After=-Abhängigkeiten auf das Bridge-Interface.
Wenn Pakete das VXLAN-Interface verlassen, aber beim Empfänger nicht ankommen, liegt es häufig an einer
zu kleinen MTU im Underlay. Ein schneller Test:
# ICMP-Test mit gesetztem DF-Bit und maximaler Ethernet-Payload-Groesse
ping -M do -s 1472 192.168.100.2
# VXLAN-Overhead: 50 Byte → Underlay-MTU mindestens 1550 Byte
# Empfehlung fuer produktive Umgebungen: Jumbo Frames (9000 Byte) im Underlay
Firewall-Regeln sind ein weiterer typischer Stolperstein: UDP-Port 4789 muss zwischen allen VTEP-IPs
ungehindert passieren dürfen. In iptables- oder nftables-basierten Umgebungen ist zu prüfen, ob die
Regel in der INPUT-Chain des Hosts greift – nicht nur in FORWARD. Proxmox-Hosts mit aktivierter
Proxmox-Firewall müssen explizit eine Regel für UDP 4789 auf dem Host-Level freischalten.