Um VXLAN-Gateways zu besprechen, müssen wir zunächst VXLAN selbst betrachten. Herkömmliche VLANs (Virtual Local Area Networks) verwenden 12-Bit-VLAN-IDs zur Aufteilung von Netzwerken und unterstützen bis zu 4096 logische Netzwerke. Dies funktioniert gut für kleine Netzwerke, aber in modernen Rechenzentren mit Tausenden von virtuellen Maschinen, Containern und Multi-Tenant-Umgebungen reichen VLANs nicht aus. VXLAN wurde geboren und von der Internet Engineering Task Force (IETF) in RFC 7348 definiert. Sein Zweck ist die Erweiterung der Layer-2-Broadcast-Domäne (Ethernet) über Layer-3-Netzwerke (IP) mithilfe von UDP-Tunneln.
Vereinfacht ausgedrückt: VXLAN kapselt Ethernet-Frames in UDP-Pakete und fügt einen 24-Bit-VXLAN-Netzwerk-Identifikator (VNI) hinzu. Dadurch werden theoretisch 16 Millionen virtuelle Netzwerke unterstützt. Dies entspricht der Vergabe eines „Personalausweises“ für jedes virtuelle Netzwerk, der es den Netzwerken ermöglicht, sich frei im physischen Netzwerk zu bewegen, ohne sich gegenseitig zu stören. Die Kernkomponente von VXLAN ist der VXLAN Tunnel End Point (VTEP), der für die Kapselung und Entkapselung von Paketen verantwortlich ist. VTEP kann als Software (z. B. Open vSwitch) oder Hardware (z. B. der ASIC-Chip auf dem 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 virtueller 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 betrachten und gewährleistet so die reibungslose Übertragung von ARP-Broadcasts und DHCP-Anfragen.
VXLAN ist jedoch kein Allheilmittel. Der Betrieb in einem L3-Netzwerk erfordert eine L2-zu-L3-Konvertierung. Hier kommt das Gateway ins Spiel. Das VXLAN-Gateway verbindet das virtuelle VXLAN-Netzwerk mit externen Netzwerken (wie herkömmlichen VLANs oder IP-Routing-Netzwerken) und stellt so den Datenfluss von der virtuellen in die reale Welt sicher. 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 bis zum Ziel eng miteinander verknüpft ist. Lassen Sie uns ihn Schritt für Schritt aufschlüsseln.
Zunächst wird ein Paket vom Quellhost (z. B. einer VM) gesendet. Dabei handelt es sich um einen Standard-Ethernet-Frame, der die Quell-MAC-Adresse, die Ziel-MAC-Adresse, den VLAN-Tag (falls vorhanden) und die Nutzdaten enthält. Nach Erhalt dieses Frames prüft der Quell-VTEP die Ziel-MAC-Adresse. Befindet sich die Ziel-MAC-Adresse in seiner MAC-Tabelle (ermittelt durch Lernen oder Flooding), weiß er, an welchen Remote-VTEP das Paket weitergeleitet werden 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 Remote-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, überprüft den VXLAN-Header auf Übereinstimmung mit dem VNI und übermittelt anschließend den inneren Ethernet-Frame an den Zielhost. Handelt es sich bei dem Paket um unbekannten Unicast-, Broadcast- oder Multicast-Verkehr (BUM), repliziert der VTEP das Paket mittels Flooding an alle relevanten VTEPs. Dabei werden Multicast-Gruppen oder die Unicast-Header-Replikation (HER) verwendet.
Der Kern des Weiterleitungsprinzips ist die Trennung von Kontrollebene und Datenebene. Die Kontrollebene nutzt Ethernet VPN (EVPN) oder den Flood-and-Learn-Mechanismus, um MAC- und IP-Zuordnungen zu erlernen. EVPN basiert auf dem BGP-Protokoll und ermöglicht VTEPs den Austausch von Routing-Informationen wie MAC-VRF (Virtual Routing and Forwarding) und IP-VRF. Die Datenebene ist für die eigentliche Weiterleitung verantwortlich und nutzt VXLAN-Tunnel für eine effiziente Übertragung.
In der Praxis wirkt sich die Weiterleitungseffizienz jedoch direkt auf die Leistung aus. Herkömmliches Flooding kann leicht zu Broadcast-Stürmen führen, insbesondere in großen Netzwerken. Dies macht eine Gateway-Optimierung erforderlich: Gateways verbinden nicht nur interne und externe Netzwerke, sondern fungieren auch als Proxy-ARP-Agenten, behandeln Routenlecks und gewährleisten kürzeste Weiterleitungswege.
Zentralisiertes VXLAN-Gateway
Ein zentralisiertes VXLAN-Gateway, auch zentralisiertes Gateway oder L3-Gateway genannt, wird typischerweise in der Edge- oder Core-Ebene eines Rechenzentrums eingesetzt. Es fungiert als zentraler Hub, über den der gesamte VNI- oder Subnetz-übergreifende Datenverkehr laufen muss.
Grundsätzlich fungiert ein zentrales Gateway als Standard-Gateway und stellt Layer-3-Routing-Dienste 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). Wenn VM A in VNI 10000 auf VM B in VNI 20000 zugreifen möchte, erreicht das Paket zunächst den lokalen VTEP. Der lokale VTEP erkennt, dass sich die Ziel-IP-Adresse nicht im lokalen Subnetz befindet und leitet sie an das zentrale Gateway weiter. Das Gateway entkapselt das Paket, trifft eine Routing-Entscheidung und kapselt es anschließend erneut in einen Tunnel zum Ziel-VNI ein.
Die Vorteile liegen auf der Hand:
○ Einfache VerwaltungAlle Routing-Konfigurationen sind auf einem 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 mittelgroße Rechenzentren oder Umgebungen, in denen VXLAN zum ersten Mal eingesetzt wird.
○RessourceneffizientGateways sind in der Regel Hochleistungshardware (wie Cisco Nexus 9000 oder Arista 7050), die enorme Datenmengen verarbeiten kann. Die Steuerungsebene ist zentralisiert, was die Integration mit SDN-Controllern wie NSX Manager erleichtert.
○Starke SicherheitskontrolleDer Datenverkehr muss über das Gateway geleitet werden, was die Implementierung von ACLs (Access Control Lists), Firewalls und NAT erleichtert. Stellen Sie sich ein Szenario mit mehreren Mandanten vor, in dem ein zentrales Gateway den Mandantendatenverkehr problemlos isolieren kann.
Doch die Mängel sind nicht zu übersehen:
○ Einzelner FehlerpunktFällt das Gateway aus, ist die L3-Kommunikation im gesamten Netzwerk lahmgelegt. VRRP (Virtual Router Redundancy Protocol) kann zwar zur Redundanz eingesetzt werden, birgt aber dennoch Risiken.
○LeistungsengpassDer gesamte Ost-West-Verkehr (Kommunikation zwischen Servern) muss das Gateway umgehen, was zu einem suboptimalen Pfad führt. Wenn beispielsweise in einem Cluster mit 1.000 Knoten die Gateway-Bandbreite 100 Gbit/s beträgt, kommt es während der Spitzenzeiten wahrscheinlich zu Überlastungen.
○Schlechte SkalierbarkeitMit zunehmender Netzwerkgröße steigt die Gateway-Auslastung exponentiell an. Ein Beispiel aus der Praxis: Ein Finanzrechenzentrum nutzt ein zentrales Gateway. Anfangs lief es reibungslos, doch nachdem sich die Anzahl der VMs verdoppelt hatte, stieg die Latenz von Mikrosekunden auf Millisekunden.
Anwendungsszenario: Geeignet für Umgebungen, die eine einfache Verwaltung 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 einen effizienten Betrieb der Kern-Gateways zu gewährleisten.
Verteiltes VXLAN-Gateway
Ein verteiltes VXLAN-Gateway, auch als Distributed Gateway oder Anycast-Gateway bezeichnet, verlagert die Gateway-Funktionalität auf jeden Leaf-Switch oder Hypervisor-VTEP. 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 (VIP) wie das Standard-Gateway konfiguriert. Von VMs gesendete Cross-Subnet-Pakete werden direkt über den lokalen VTEP geroutet, ohne einen zentralen Punkt durchlaufen zu müssen. EVPN ist hier besonders nützlich: Durch BGP EVPN lernt der VTEP die Routen entfernter Hosts und verwendet MAC/IP-Binding, um ARP-Flooding zu vermeiden.
Beispiel: VM A (10.1.1.10) möchte auf VM B (10.2.1.10) zugreifen. Das Standard-Gateway von VM A ist die VIP des lokalen VTEP (10.1.1.1). Der lokale VTEP leitet das Paket an das Zielsubnetz weiter, kapselt es ein und sendet es direkt an den VTEP von VM B. Dieser Prozess minimiert Pfad und Latenz.
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 LeistungUm Engpässe zu vermeiden, wird der Ost-West-Verkehr lokal verarbeitet. 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 unberührt. In Kombination mit der schnellen Konvergenz von EVPN beträgt die Wiederherstellungszeit nur wenige Sekunden.
○Gute RessourcennutzungNutzen Sie den vorhandenen Leaf-Switch-ASIC-Chip zur Hardwarebeschleunigung mit Weiterleitungsraten im Tbps-Bereich.
Was sind die Nachteile?
○ Komplexe KonfigurationJeder VTEP erfordert die Konfiguration von Routing, EVPN und anderen Funktionen, was die anfängliche Bereitstellung 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. Softwareimplementierungen (wie OVS auf KVM) sind nicht so leistungsfähig wie Hardware.
○KonsistenzherausforderungenVerteilt bedeutet, dass die Statussynchronisierung auf EVPN basiert. Wenn die BGP-Sitzung schwankt, kann dies zu einem Routing-Black Hole 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 uns eingehend mit den Daten und Fallstudien befassen, um Sie zu überzeugen.
Aus Performance-Sicht sind verteilte Systeme deutlich leistungsfähiger. In einem typischen Rechenzentrums-Benchmark (basierend auf Spirent-Testgeräten) betrug die durchschnittliche Latenz eines zentralen Gateways 150 μs, während die eines verteilten Systems nur 50 μs betrug. In Bezug auf den Durchsatz können verteilte Systeme problemlos Line-Rate-Forwarding erreichen, da sie Spine-Leaf Equal Cost Multi-Path (ECMP)-Routing nutzen.
Skalierbarkeit ist ein weiteres Problem. Zentralisierte Netzwerke eignen sich für Netzwerke mit 100 bis 500 Knoten; darüber hinaus gewinnen verteilte Netzwerke die Oberhand. Nehmen wir zum Beispiel Alibaba Cloud. Ihre VPC (Virtual Private Cloud) nutzt verteilte VXLAN-Gateways, um Millionen von Benutzern weltweit zu unterstützen, mit einer Latenz von unter 1 ms in einer einzelnen Region. Ein zentralisierter Ansatz wäre längst gescheitert.
Wie sieht es mit den Kosten aus? Eine zentralisierte Lösung erfordert geringere Anfangsinvestitionen und benötigt nur wenige High-End-Gateways. Bei einer verteilten Lösung müssen alle Leaf-Knoten VXLAN-Offload unterstützen, was zu höheren Kosten für Hardware-Upgrades führt. Langfristig bietet eine verteilte Lösung jedoch geringere Betriebs- und Wartungskosten, da Automatisierungstools wie Ansible die Batch-Konfiguration ermöglichen.
Sicherheit und Zuverlässigkeit: Zentralisierte Systeme ermöglichen einen zentralen Schutz, bergen aber ein hohes Risiko einzelner Angriffspunkte. Verteilte Systeme sind widerstandsfähiger, benötigen aber eine robuste Kontrollebene, um DDoS-Angriffe zu verhindern.
Eine Fallstudie aus der Praxis: Ein E-Commerce-Unternehmen nutzte zentralisiertes VXLAN zum Aufbau seiner Website. In Spitzenzeiten stieg die CPU-Auslastung des Gateways auf 90 %, was zu Nutzerbeschwerden über Latenz führte. Die Umstellung auf ein verteiltes Modell löste das Problem, sodass das Unternehmen seine Größe problemlos verdoppeln konnte. Eine kleine Bank hingegen bestand auf einem zentralisierten Modell, da sie Compliance-Audits priorisierte und eine zentrale Verwaltung einfacher fand.
Wenn Sie extreme Netzwerkleistung und Skalierbarkeit anstreben, ist ein verteilter Ansatz generell die richtige Wahl. Bei begrenztem Budget und mangelnder Erfahrung Ihres Managementteams ist ein zentralisierter Ansatz praktikabler. Mit dem Aufkommen von 5G und Edge Computing werden verteilte Netzwerke in Zukunft an Popularität gewinnen, zentralisierte Netzwerke werden jedoch in bestimmten Szenarien, beispielsweise bei der Vernetzung von Zweigstellen, weiterhin wertvoll sein.
Mylinking™ Netzwerk-Paketbrokerunterstützt VxLAN, VLAN, GRE, MPLS Header Stripping
Unterstützt den VxLAN-, VLAN-, GRE- und MPLS-Header, der im ursprünglichen Datenpaket entfernt und als Ausgabe weitergeleitet wurde.
Beitragszeit: 09.10.2025
