Netzwerkvirtualisierung mit VXLAN und Linux

VXLAN steht für „Virtual eXtensible Local Area Network“. Standardisiert in RFC 7348 im August 2014 ist VXLAN heute auch als virtuelle Netzwerkschnittstelle in aktuellen Linuxkerneln verfügbar. Doch worum geht es bei VXLAN?

Worum geht es bei VXLAN?

Liest man die Stichworte „Virtual“ und „LAN“, denken die meisten zu Recht an VLAN. Hierbei wird ein großes physisches Netzwerk logisch in kleinere Netzwerke aufgeteilt. Dazu werden die entsprechenden Verbindungen mit VLAN-Tags markiert. Dies kann entweder beim sendenden Host (tagged VLAN) oder beispielsweise durch den Switch (portbasiertes VLAN) erfolgen. Diese Markierungen erfolgen bereits auf Layer 2, dem Data Link Layer im OSI Schichtenmodell. Hierdurch lassen sie sich bereits auf sehr niedriger Netzwerkebene sinnvoll auswerten und so unerwünschte Kommunikation im Netzwerk unterdrückt werden. Die Norm IEEE 802.1Q definiert für das VLAN-Tag 12 Bit Breite, somit ergeben sich grundsätzlich 4096 mögliche VLAN-Netzwerke auf einer Ethernet-Installation.

VXLAN wurde entwickelt, um diese Beschränkung zu umgehen. Mit VXLAN wird eine auf OSI-Layer 3 bzw. Layer 4 basierende Übertragungstechnik eingeführt, die virtuelle Layer-2-Umgebungen schafft. Mit der VXLAN-Logik sind rund 16 Millionen (2 hoch 24) VXLAN-Layer-2-Netzwerke möglich, die ihrerseits wieder 4096 VLAN-Netzwerkabschnitte abbilden können. Dies sollte zunächst auch für sehr große Ethernet-Installationen ausreichen.

Wie kann man ein solches VXLAN einrichten?

Eine VXLAN-Schnittstelle stellt man im Anschluss mit beispielsweise

ip link add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth0 

zur Verfügung. Dieses Kommando legt das Gerät „vxlan0“ als VXLAN mit der ID 42 auf dem physikalischen Interface „eth0“ an. Mehrere VXLAN werden auf Basis ihrer ID unterschieden. Die Anweisung „group <ip-adresse>“  legt die Übertragung auf Multicast und die zugehörige Multicast-Gruppe fest. Alternativ könnte hier auch mit dem Kommando „remote“ eine IP des Zielhostes auf Basis des zugrunde liegenden Netzwerkes (eth0)  gegeben werden (Unicast-Betrieb). Mit weiteren Anweisungen lassen sich auch die Quell- und Zielports für die auf dem darunterliegenden IP-Netzwerkes auf „eth0“ festlegen. Standard nach IANA ist der UDP-Port 4789.

Mit der Befehlszeile

ip addr add 10.0.0.1/24 dev vxlan0 

gibt man der neu erschaffenen VXLAN-Netzwerkschnittstelle eine feste IP-Adresse, hier im Beispiel 10.0.0.1

Der Befehl

ip link set up dev vxlan0 

schaltet die neu angelegte Netzwerkschnittstelle „vxlan0“ scharf. Damit existiert ein virtuelles Netzwerk auf Basis von IP-Multicast auf dem physikalischen Interface „eth0“.

Das Interface „vxlan0“ verhält sich nun prinzipiell genauso wie eine Ethernet-Schnittstelle. Alle weiteren Rechner, die die VXLAN ID 42 und Multicast-Gruppe 239.1.1.1 auswählen, werden damit teil dieses virtuellen Ethernets. Auf diesem könnte man nun auch wieder verschiedene VLAN einrichten, beispielsweise mit

ip link add link vxlan0 name vlan1 type vlan id 1 

ein neues VLAN auf der VXLAN-Schnittstelle aufsetzen. In diesem Falle bräuchte man der vxlan-Schnittstelle keine IP-Adresse zu geben.

Was lässt sich damit in der Praxis machen?

Grundsätzlich eignet sich VXLAN für den Einsatzfall, in einem sehr großen Ethernet, etwa in Cloud-Umgebungen, die Grenze von 4096 VLAN zu überwinden.

Einsatz als Testumgebung für Netzwerkdienste

Alternativ lässt sich VXLAN sehr gut in Testumgebungen oder virtualisierten Umgebungen einsetzen, in denen man die volle Kontrolle über das zu nutzende Layer-2-Netzwerk benötigt. Möchte man Netzwerkinfrastruktur-Komponenten bzw. deren Konfiguration testen, bietet sich ein solches, komplett isoliertes Netzwerk an. Auch kann man so von Virtualisierungsumgebungen eingefügte Kontrollstrukturen, die besonders für solche Tests hinderlich sind, umgehen. Mein erster Praxiskontakt zu VXLAN war beim Test eines komplexeren DHCP-Setups auf mehreren virtuellen Maschinen in OpenStack. Auf den vom OpenStack gelieferten Netzwerkschnittstellen war der Test für mich unmöglich, da ich zum einen nur beschränkten Zugriff auf die Netzwerkkonfigurationen auf Seite des Virtualisierungshosts hatte und OpenStack dhcp-Pakete aus dem Netzwerkstream ausfiltert. Dieses Problem ließ sich elegant durch Aufsetzen des Testnetzes auf VXLAN umgehen. Gleichzeitig war so sichergestellt, dass der DHCP-Test keinen Einfluss auf andere Teile des OpenStack-Netzes hatte. Außerdem blieb so die von OpenStack gelieferte Ethernet-Verbindung zu Wartungs- und Beobachtungszwecke dauerhaft nutzbar.

Es sind beispielsweise im Unicast-Betrieb auch Szenarien denkbar, bei denen ein über VXLAN aufgespanntes Layer-2-Netzwerk über mehrere Standorte transportiert wird. Es gibt Switches oder Router, die VXLAN unterstützen und als VTEP (VXLAN Tunnel Endpoints) dienen können. Diese setzt man beispielsweise ein, um zwei Multicast-VXLAN-Netzwerke per Unicast zwischen den VTEP zu verbinden und so transparent ein großes VXLAN aufspannen.

Ist VXLAN sicher?

VXLAN legt auf eine bestehende Ethernet-Infrastruktur eine weitere Layer-2-Infrastruktur. Diese arbeitet mit UDP-Paketen im Unicast oder Multicast. Eine Verschlüsselung auf VXLAN-Ebene ist nicht vorgesehen und müsste bei Bedarf über darüber liegende Protokollebenen geleistet werden. Hier kommen IPSec-Lösungen oder beispielsweise TLS in Frage. Grundsätzlich ist ein VXLAN auf einer vergleichbaren Sicherheitsebene wie die meisten anderen Netzwerkprotokolle auf Layer 2.

Mögliche Probleme?

Bei VXLAN kann möglicherweise dem Anwender ein „alter Bekannter“ in Form von MTU-Problemen wieder begegnen. Ein Standard-Ethernet-Frame hat eine Länge von 1.518 Bytes. Damit bleiben nach Abzug des Ethernet-Headers 1.500 Bytes für Nutzlast. VXLAN erweitert den Ethernet-Header um 50 Bytes, weshalb die verfügbare Nutzlast auf 1.450 Bytes sinkt. Dies sollte beim Setzen der MTU beachtet werden. Sogenannte Jumbo-Frames werden entsprechend beeinflusst. Hier sind die zusätzlichen 50 Bytes ebenfalls mit in Betracht zu ziehen.

Was bietet credativ?

Gerne unterstützen und beraten wir Sie bei der Gestaltung und Betrieb Ihrer Netzwerkumgebung. Wir arbeiten unter anderem im Bereich DevOps, Netzwerk-Infrastruktur und Netzwerkdesign. Die credativ GmbH verfügt über Mitarbeiter mit Expertise in hochkomplexen Netzwerksetups für Rechenzentren auf realer Hardware ebenso wie in virtueller Umgebung. Unser Schwerpunkt liegt auf der Umsetzung mit Open-Source-Software.