Um VXLAN-Gateways zu besprechen, müssen wir zunächst VXLAN selbst erläutern. Herkömmliche VLANs (Virtual Local Area Networks) verwenden 12-Bit-VLAN-IDs zur Netzwerksegmentierung und unterstützen bis zu 4096 logische Netzwerke. Dies ist für kleine Netzwerke ausreichend, doch in modernen Rechenzentren mit Tausenden von virtuellen Maschinen, Containern und Multi-Tenant-Umgebungen reichen VLANs nicht mehr aus. Daher wurde VXLAN von der Internet Engineering Task Force (IETF) in RFC 7348 definiert. Ziel ist es, die Layer-2-Broadcast-Domäne (Ethernet) mithilfe von UDP-Tunneln auf Layer-3-Netzwerke (IP) zu erweitern.
Vereinfacht gesagt kapselt VXLAN Ethernet-Frames in UDP-Pakete und fügt eine 24-Bit-VXLAN-Netzwerkkennung (VNI) hinzu. Theoretisch unterstützt es 16 Millionen virtuelle Netzwerke. Dies entspricht der „Identitätskarte“ jedes virtuellen Netzwerks, die es ihnen ermöglicht, sich im physischen Netzwerk frei zu bewegen, ohne sich gegenseitig zu stören. Die Kernkomponente von VXLAN ist der VXLAN-Tunnelendpunkt (VTEP), der für das Kapseln und Entkapseln von Paketen zuständig ist. Der VTEP kann als Software (z. B. Open vSwitch) oder als Hardware (z. B. der ASIC-Chip im Switch) implementiert sein.
Warum ist VXLAN so beliebt? Weil es perfekt auf die Anforderungen von Cloud Computing und SDN (Software-Defined Networking) abgestimmt ist. In öffentlichen Clouds wie AWS und Azure ermöglicht VXLAN die nahtlose Erweiterung der virtuellen Netzwerke von Mandanten. In privaten Rechenzentren unterstützt es Overlay-Netzwerkarchitekturen wie VMware NSX oder Cisco ACI. Stellen Sie sich ein Rechenzentrum mit Tausenden von Servern vor, auf denen jeweils Dutzende von VMs (virtuellen Maschinen) laufen. VXLAN ermöglicht es diesen VMs, sich als Teil desselben Layer-2-Netzwerks zu erkennen und so die reibungslose Übertragung von ARP-Broadcasts und DHCP-Anfragen sicherzustellen.
VXLAN ist jedoch kein Allheilmittel. Der Betrieb in einem L3-Netzwerk erfordert eine L2-zu-L3-Konvertierung, und hier kommt das Gateway ins Spiel. Das VXLAN-Gateway verbindet das virtuelle VXLAN-Netzwerk mit externen Netzwerken (wie traditionellen VLANs oder IP-Routing-Netzwerken) und gewährleistet so den Datenfluss von der virtuellen in die reale Welt. Der Weiterleitungsmechanismus ist das Herzstück des Gateways und bestimmt, wie Pakete verarbeitet, geroutet und verteilt werden.
Der VXLAN-Weiterleitungsprozess gleicht einem filigranen Ballett, bei dem jeder Schritt von der Quelle zum Ziel eng miteinander verknüpft ist. Schauen wir uns das Schritt für Schritt an.
Zunächst sendet der Quellhost (z. B. eine VM) ein Paket. Dieses Standard-Ethernet-Frame enthält die Quell-MAC-Adresse, die Ziel-MAC-Adresse, das VLAN-Tag (falls vorhanden) und die Nutzdaten. Nach dem Empfang dieses Frames prüft der Quell-VTEP die Ziel-MAC-Adresse. Befindet sich die Ziel-MAC-Adresse in seiner MAC-Tabelle (die er durch Lernen oder Flooding erhalten hat), weiß er, an welchen entfernten VTEP er das Paket weiterleiten muss.
Der Kapselungsprozess ist entscheidend: Der VTEP fügt einen VXLAN-Header (einschließlich VNI, Flags usw.) hinzu, dann einen äußeren UDP-Header (mit einem Quellport basierend auf einem Hash des inneren Frames und einem festen Zielport von 4789), einen IP-Header (mit der Quell-IP-Adresse des lokalen VTEP und der Ziel-IP-Adresse des entfernten VTEP) und schließlich einen äußeren Ethernet-Header. Das gesamte Paket erscheint nun als UDP/IP-Paket, sieht aus wie normaler Datenverkehr und kann im L3-Netzwerk geroutet werden.
Im physischen Netzwerk wird das Paket von einem Router oder Switch weitergeleitet, bis es den Ziel-VTEP erreicht. Der Ziel-VTEP entfernt den äußeren Header, prüft den VXLAN-Header auf Übereinstimmung der VNI und stellt dann den inneren Ethernet-Frame an den Zielhost zu. Handelt es sich bei dem Paket um unbekannten Unicast-, Broadcast- oder Multicast-Verkehr (BUM), repliziert der VTEP das Paket mithilfe von Flooding an alle relevanten VTEPs und nutzt dabei Multicast-Gruppen oder die Replikation von Unicast-Headern (HER).
Das Kernprinzip des Weiterleitungsmodells ist die Trennung von Steuerungs- und Datenebene. Die Steuerungsebene nutzt Ethernet VPN (EVPN) oder den Flood-and-Learn-Mechanismus, um MAC- und IP-Zuordnungen zu lernen. EVPN basiert auf dem BGP-Protokoll und ermöglicht es virtuellen Terminalservern (VTEPs), Routing-Informationen wie MAC-VRF (Virtual Routing and Forwarding) und IP-VRF auszutauschen. Die Datenebene ist für die eigentliche Weiterleitung zuständig und verwendet VXLAN-Tunnel für eine effiziente Übertragung.
In der Praxis wirkt sich die Weiterleitungseffizienz jedoch direkt auf die Leistung aus. Traditionelles Flooding kann insbesondere in großen Netzwerken leicht Broadcast-Stürme verursachen. Daher ist eine Gateway-Optimierung erforderlich: Gateways verbinden nicht nur interne und externe Netzwerke, sondern fungieren auch als Proxy-ARP-Agenten, beheben Routenlecks und gewährleisten die kürzesten Weiterleitungspfade.
Zentralisiertes VXLAN-Gateway
Ein zentrales VXLAN-Gateway, auch zentralisiertes Gateway oder L3-Gateway genannt, wird typischerweise am Rand oder im Kern eines Rechenzentrums eingesetzt. Es fungiert als zentraler Knotenpunkt, über den der gesamte VNI- oder Subnetz-übergreifende Datenverkehr geleitet werden muss.
Prinzipiell fungiert ein zentrales Gateway als Standardgateway und stellt Layer-3-Routingdienste für alle VXLAN-Netzwerke bereit. Betrachten wir zwei VNIs: VNI 10000 (Subnetz 10.1.1.0/24) und VNI 20000 (Subnetz 10.2.1.0/24). Möchte VM A in VNI 10000 auf VM B in VNI 20000 zugreifen, erreicht das Paket zunächst den lokalen VTEP. Dieser erkennt, dass sich die Ziel-IP-Adresse nicht im lokalen Subnetz befindet und leitet das Paket an das zentrale Gateway weiter. Das Gateway dekapselt das Paket, trifft eine Routing-Entscheidung und kapselt es anschließend wieder in einen Tunnel zum Ziel-VNI ein.
Die Vorteile liegen auf der Hand:
○ Einfache VerwaltungDie gesamte Routing-Konfiguration wird auf ein oder zwei Geräten zentralisiert, sodass Betreiber nur wenige Gateways benötigen, um das gesamte Netzwerk abzudecken. Dieser Ansatz eignet sich für kleine und mittlere Rechenzentren oder Umgebungen, die VXLAN zum ersten Mal einsetzen.
○RessourceneffizientGateways sind typischerweise leistungsstarke Hardware (wie der Cisco Nexus 9000 oder der Arista 7050), die große Datenmengen verarbeiten kann. Die Steuerungsebene ist zentralisiert, was die Integration mit SDN-Controllern wie dem NSX Manager ermöglicht.
○Strenge SicherheitskontrolleDer Datenverkehr muss das Gateway passieren, was die Implementierung von ACLs (Zugriffskontrolllisten), Firewalls und NAT ermöglicht. Stellen Sie sich ein Multi-Tenant-Szenario vor, in dem ein zentrales Gateway den Mandantendatenverkehr problemlos isolieren kann.
Die Mängel dürfen jedoch nicht ignoriert werden:
○ Einzelner AusfallpunktFällt das Gateway aus, ist die L3-Kommunikation im gesamten Netzwerk lahmgelegt. Obwohl VRRP (Virtual Router Redundancy Protocol) zur Redundanz eingesetzt werden kann, birgt es dennoch Risiken.
○LeistungsengpassDer gesamte Ost-West-Verkehr (Kommunikation zwischen Servern) muss das Gateway umgehen, was zu einem suboptimalen Pfad führt. Beispielsweise kann es in einem Cluster mit 1000 Knoten bei einer Gateway-Bandbreite von 100 Gbit/s während der Spitzenzeiten zu Engpässen kommen.
○Schlechte SkalierbarkeitMit zunehmender Netzwerkgröße steigt die Gateway-Last exponentiell an. Ein praktisches Beispiel: Ein Finanzrechenzentrum nutzte ein zentralisiertes Gateway. Anfangs lief alles reibungslos, doch nachdem sich die Anzahl der VMs verdoppelt hatte, schnellte die Latenz von Mikrosekunden auf Millisekunden in die Höhe.
Anwendungsszenario: Geeignet für Umgebungen, die eine hohe Verwaltungseinfachheit erfordern, wie z. B. private Unternehmens-Clouds oder Testnetzwerke. Die ACI-Architektur von Cisco verwendet häufig ein zentralisiertes Modell in Kombination mit einer Leaf-Spine-Topologie, um den effizienten Betrieb der Kern-Gateways zu gewährleisten.
Verteiltes VXLAN-Gateway
Ein verteiltes VXLAN-Gateway, auch bekannt als verteiltes Gateway oder Anycast-Gateway, lagert die Gateway-Funktionalität auf jeden Leaf-Switch oder Hypervisor-VTEP aus. Jeder VTEP fungiert als lokales Gateway und übernimmt die L3-Weiterleitung für das lokale Subnetz.
Das Prinzip ist flexibler: Jeder VTEP wird mithilfe des Anycast-Mechanismus mit derselben virtuellen IP-Adresse (VIP) wie das Standardgateway konfiguriert. Subnetzübergreifende Pakete von VMs werden direkt über den lokalen VTEP geroutet, ohne einen zentralen Knotenpunkt zu durchlaufen. EVPN ist hier besonders nützlich: Über BGP EVPN lernt der VTEP die Routen entfernter Hosts und verwendet MAC/IP-Bindung, um ARP-Flooding zu vermeiden.
Beispielsweise möchte VM A (10.1.1.10) auf VM B (10.2.1.10) zugreifen. Das Standardgateway von VM A ist die virtuelle IP-Adresse (VIP) des lokalen VTEP (10.1.1.1). Der lokale VTEP leitet die Daten an das Zielsubnetz weiter, kapselt das VXLAN-Paket und sendet es direkt an den VTEP von VM B. Dadurch werden Pfad und Latenz minimiert.
Herausragende Vorteile:
○ Hohe SkalierbarkeitDie Verteilung der Gateway-Funktionalität auf jeden Knoten erhöht die Netzwerkgröße, was für größere Netzwerke von Vorteil ist. Große Cloud-Anbieter wie Google Cloud verwenden einen ähnlichen Mechanismus, um Millionen von VMs zu unterstützen.
○Überragende LeistungDer Ost-West-Verkehr wird lokal verarbeitet, um Engpässe zu vermeiden. Testdaten zeigen, dass der Durchsatz im verteilten Modus um 30–50 % gesteigert werden kann.
○Schnelle FehlerbehebungEin einzelner VTEP-Ausfall betrifft nur den lokalen Host, andere Knoten bleiben unbeeinträchtigt. Dank der schnellen Konvergenz von EVPN beträgt die Wiederherstellungszeit nur wenige Sekunden.
○Gute Nutzung der RessourcenNutzen Sie den vorhandenen Leaf-Switch-ASIC-Chip für die Hardwarebeschleunigung, wobei Weiterleitungsraten im Tbit/s-Bereich erreicht werden.
Welche Nachteile gibt es?
○ Komplexe KonfigurationJeder VTEP erfordert die Konfiguration von Routing, EVPN und weiteren Funktionen, was die Erstbereitstellung zeitaufwändig macht. Das Betriebsteam muss mit BGP und SDN vertraut sein.
○Hohe HardwareanforderungenVerteiltes Gateway: Nicht alle Switches unterstützen verteilte Gateways; Broadcom Trident- oder Tomahawk-Chips sind erforderlich. Software-Implementierungen (wie OVS auf KVM) sind weniger leistungsfähig als Hardware-Implementierungen.
○Herausforderungen hinsichtlich der Konsistenz„Verteilt“ bedeutet, dass die Zustandssynchronisierung auf EVPN basiert. Schwankungen in der BGP-Sitzung können zu einem Routing-Blackhole führen.
Anwendungsszenario: Ideal für Hyperscale-Rechenzentren oder öffentliche Clouds. Der verteilte Router von VMware NSX-T ist ein typisches Beispiel. In Kombination mit Kubernetes unterstützt er nahtlos Container-Netzwerke.
Zentralisiertes VxLAN-Gateway vs. verteiltes VxLAN-Gateway
Nun zum Höhepunkt: Was ist besser? Die Antwort lautet: „Es kommt darauf an“, aber wir müssen die Daten und Fallstudien eingehend analysieren, um Sie zu überzeugen.
Aus Performance-Sicht sind verteilte Systeme deutlich überlegen. In einem typischen Rechenzentrums-Benchmark (basierend auf Spirent-Testgeräten) betrug die durchschnittliche Latenz eines zentralisierten Gateways 150 µs, während die eines verteilten Systems nur 50 µs erreichte. Auch beim Durchsatz erzielen verteilte Systeme problemlos Leitungsgeschwindigkeit, da sie Spine-Leaf Equal Cost Multi-Path (ECMP)-Routing nutzen.
Skalierbarkeit ist ein weiterer entscheidender Faktor. Zentralisierte Netzwerke eignen sich für Netzwerke mit 100 bis 500 Knoten; darüber hinaus sind verteilte Netzwerke im Vorteil. Nehmen wir beispielsweise Alibaba Cloud. Deren VPC (Virtual Private Cloud) nutzt verteilte VXLAN-Gateways, um Millionen von Nutzern weltweit mit einer Latenz von unter 1 ms pro Region zu unterstützen. Ein zentralisierter Ansatz wäre längst gescheitert.
Wie sieht es mit den Kosten aus? Eine zentralisierte Lösung bietet geringere Anfangsinvestitionen, da nur wenige High-End-Gateways benötigt werden. Eine verteilte Lösung erfordert hingegen, dass alle Endknoten VXLAN-Offloading unterstützen, was zu höheren Kosten für Hardware-Upgrades führt. Langfristig gesehen bietet eine verteilte Lösung jedoch niedrigere Betriebs- und Wartungskosten, da Automatisierungstools wie Ansible die Konfiguration im Batch-Verfahren ermöglichen.
Sicherheit und Zuverlässigkeit: Zentralisierte Systeme ermöglichen zwar einen zentralen Schutz, bergen aber ein hohes Risiko von Einzelangriffen. Verteilte Systeme sind widerstandsfähiger, benötigen jedoch eine robuste Steuerungsebene, um DDoS-Angriffe zu verhindern.
Ein Fallbeispiel aus der Praxis: Ein E-Commerce-Unternehmen nutzte ein zentralisiertes VXLAN für den Aufbau seiner Website. Zu Spitzenzeiten schnellte die CPU-Auslastung des Gateways auf 90 % hoch, was zu Beschwerden der Nutzer über Latenzzeiten führte. Der Wechsel zu einem verteilten Modell löste das Problem und ermöglichte es dem Unternehmen, seine Kapazitäten problemlos zu verdoppeln. Im Gegensatz dazu bestand eine kleine Bank auf einem zentralisierten Modell, da sie Compliance-Audits priorisierte und die zentrale Verwaltung als einfacher empfand.
Generell gilt: Wer höchste Netzwerkleistung und Skalierbarkeit benötigt, sollte auf einen verteilten Ansatz setzen. Bei begrenztem Budget und wenig Erfahrung im Management ist ein zentralisierter Ansatz praktikabler. Mit dem Aufkommen von 5G und Edge Computing werden verteilte Netzwerke zukünftig an Bedeutung gewinnen, zentralisierte Netzwerke bleiben aber in bestimmten Anwendungsfällen, wie beispielsweise der Vernetzung von Zweigstellen, weiterhin wertvoll.
Mylinking™ Netzwerk-PaketbrokerUnterstützung für VxLAN, VLAN, GRE, MPLS Header Stripping
Unterstützte das Entfernen des VxLAN-, VLAN-, GRE- und MPLS-Headers aus dem ursprünglichen Datenpaket und die Weiterleitung der Ausgabe.
Veröffentlichungsdatum: 09.10.2025
