Systemadministratoren stehen vor der Herausforderung, skalierbare Netzwerke unter Einhaltung der entsprechenden Sicherheits- und Verfügbarkeitsanforderungen zu planen. Einige Serversysteme müssen sich in einer redundant ausgelegten Infrastruktur in einem Subnetz befinden. Dazu kommen virtualisierte Systeme, die innerhalb desselben Subnetzes zwischen mehreren Standorten migrierbar sein sollen, sei es im Live-Betrieb oder im Disaster-Recovery-Fall. Zusätzlich sollen aktuelle Netze noch den steigenden Bandbreitenbedarf decken können.

Die benötigte Sicherheit lässt sich in klassischen Szenarien meist über die Implementierung von virtuellen lokalen Netzen (VLANs) zur Verkleinerung der Broadcast-Domänen in Kombination mit Firewall-Regeln beziehungsweise statischen Paketfiltern (sogenannten Access Control Lists; ACLs) auf Routern oder Layer-3-Switches erreichen. In einigen Fällen kommt auf Routing-Ebene noch eine Routing-Virtualisierung auf Basis von Virtual Routing and Forwarding (VRF) zum Einsatz, um eine Multi-Mandantenfähigkeit abbilden zu können.

Für die nötige Skalierbarkeit finden meist geroutete Netze Verwendung. Dies dient der Vermeidung von Layer-2-Schleifen. In reinen Layer-2-Netzen kommen dazu Verfahren wie das in IEEE 802.1d definierte Spanning Tree beziehungsweise dessen Erweiterung Rapid Spanning Tree (IEEE 802.1w) oder Multiple Spanning Tree (IEEE 802.1s) zum Einsatz. Alle drei haben den Vorteil, dass sie die Schleifenfreiheit gewährleisten. Layer-2-Schleifen führen zu einer Überlast auf Switches und können komplex in der Fehlersuche sein.

Die Schleifenfreiheit wird bei redundanten Links über geblockte Pfade sichergestellt, was allerdings zu Lasten des maximalen Durchsatzes geht. Denn so lassen sich die maximalen, kombinierten beziehungsweise lastverteilten Datenraten nicht ausnutzen. Zusätzlich bieten einige Switches nur eine begrenzte Anzahl an Spanning-Tree-Instanzen, was die Skalierbarkeit bei Verfahren begrenzt, die je VLAN eine dedizierte Instanz betreiben, wie es zum Beispiel bei Rapid-per-VLAN in Spanning Tree der Fall ist.

Um diesen Problemen zu begegnen, besteht die Möglichkeit eines gerouteten Designs, wie in Bild 1 dargestellt. Hierbei gibt es wiederum unterschiedliche Varianten: zum Beispiel ein hierarchisches Drei-Layer-Modell mit Core-, Distribution- und Access-Switches. Im klassischen Campus-Netz kommt zunehmend auch ein sogenannter Routed-Access zur Anwendung, bei dem VLANs nur lokal auf dem jeweiligen Access-Switch respektive Access-Switch-Stack realisiert sind.

Alternativ gibt es in Rechenzentren noch das sogenannte Spine-Leaf-Modell, bei dem mehrere zentrale Switche, die sogenannten Spines, über geroutete Links mit den Leafs verbunden sind, an denen wiederum die jeweiligen Server hängen. Diese Leafs sind meist als sogenannte Top-of-Rack-Switches ausgeführt. Normalerweise würden IT-Verantwortliche die benötigten VLANs jeweils auf einen Top-of-Rack-Switch beschränken und bereits auf dessen Uplink-Ebene routen, um die positiven Eigenschaften der Routing-Protokolle für Redundanz und Lastverteilung über mehrere geroutete Links zu erreichen. Dies führt jedoch dazu, dass die VLANs nur auf das Rack beschränkt sind. Das spricht wiederum gegen die benötigte Flexibilität für die genannten Redundanz- und Virtualisierungslösungen.

Viele Dienste in Rechenzentren benötigen noch immer direkte Layer-2-Konnektivität. Ein Beispiel stellt etwa vMotion von VMware dar, das eine Live-Migration von virtuellen Maschinen von einer Hardware auf eine andere ermöglicht. Dies wäre in gerouteten Designs in unterschiedlichen Racks nicht möglich. Eine IP-basierte Readressierung ist nämlich in den meisten Fällen nicht praktikabel.

In lokalen Netzen von Endanwendern spielt dies keine große Rolle, da es für den Host in der Regel keine Bedeutung hat, in welchem IP-Subnetz er sich befindet, solange er die notwendigen Serverdienste über sein Gateway erreicht und Firewalls ihn nicht blocken. Dies reicht jedoch in Rechenzentren nicht aus. Wie lässt sich also sicherstellen, dass – trotz gerouteten Designs – sowohl redundante Serverdienste in verteilten Rechenzentren miteinander über Layer 2 kommunizieren können als auch dass virtuelle Maschinen in der Lage sind, ohne Anpassung der IP-Adresse zwischen Racks umzuziehen?

Die Antwort sind sogenannte Overlay-Protokolle wie in Bild 2 zu sehen, die die bestehende VLAN-Struktur abstrahieren. Eine Option dabei stellt "Virtual eXtensible Local Area Network" (VXLAN) [1] dar, das die Möglichkeit bietet, ein Subnetz respektive eine Layer-2-Broadcast-Domäne im Overlay-Netz mit einem Layer-3-Underlay-Netz zu erweitern. So lassen sich die Vorteile von gerouteten Designs wie Equal Cost Multi Pathing (ECMP) – also die gleichmäßige Lastverteilung zwischen unterschiedlichen Pfaden – mit der Flexibilität einer direkten Layer-2-Kopplung verbinden. Somit wäre auch wieder Redundanz innerhalb eines Subnetzes und sogar in unterschiedlichen Standorten möglich. VXLAN definiert die IETF grundlegend im RFC7348.

Als Beispiel für VXLAN als Overlay kann ein virtuelles Serversystem dienen, das redundant aufgebaut ist und die virtuelle IPv4-Adresse 192.0.2.1 verwendet. Diese ist je nach Status an Server A am Standort A mit der realen IPv4-Adresse 192.0.2.2 oder Server B am Standort B mit der IPv4-Adresse 192.0.2.3 gebunden. Fällt Server A aus, übernimmt Server B die Kommunikation von und zu der IPv4-Adresse 192.0.2.1. Dies erfolgt mithilfe einer Gratuitous-Address-Resolution-Protocol-(Gratuitous ARP)-Nachricht per Broadcast an alle Hosts im Subnetz. Das hat zur Folge, dass in der ARP-Tabelle die MAC-Adresse für 192.0.2.1 an Server B gebunden wird. Ohne VXLAN ginge dies jedoch mit den eingangs genannten Gefährdungen und Einschränkungen einher. Natürlich wäre es von Vorteil, wenn die Layer-2-Kopplung nicht zwingend notwendig und die Failover- und Lastverteilungsmechanismen direkt auf den Clients implementiert, aber von Serverseite zentral steuerbar wären. Dies würde die Layer-2-Kopplung für Serverdienste obsolet machen.

Neben diesen Vorteilen bietet VXLAN noch die Möglichkeit einer Erweiterung der maximalen Anzahl an virtuellen Netzen. Klassische VLANs auf Basis von IEEE 802.1Q bieten maximal 4094 Segmente – VXLAN bis zu 16 Millionen. Die Technologie erreicht dies, indem sie die Ethernet-Frames der Hosts in UDP-Segmente verpackt, in unserem Fall von den Serversystemen an Standort A und Standort B. Hierfür hat die IANA VXLAN die eigene UDP-Portnummer 4789 zugewiesen. Zusätzlich kommt der sogenannte VXLAN-Header zum Einsatz. Die Identifizierung des VXLAN-Segments kann über einen 24 Bit langen VXLAN Network Identifier (VNI) stattfinden, der den äußeren Identifikator der Zugehörigkeit zu einem Layer-2-Segment darstellt.

Die jeweiligen Tunnelendpunkte nennen sich "VXLAN Tunnel End Point" (VTEP). VLANs werden auf diesen VTEPs zu den VNIs zugeordnet. VTEPs können sowohl auf einem Hypervisor, also der Virtualisierungsschicht zwischen Hardware und virtueller Maschine, als auch auf einem Switch oder Router implementiert sein.

Die Hosts, die über VXLAN-Overlay kommunizieren möchten, benötigen keinen dedizierten Agenten. Das ist von Vorteil, da dies bei Appliances nicht möglich wäre beziehungsweise den Verlust von Herstellersupport nach sich ziehen könnte. Somit bemerkt der Host keinen Unterschied zwischen einer direkten Layer-2-Verbindung und einer VXLAN-basierten Kopplung, da das Transportnetz für ihn transparent ist. Das Wissen über das Overlay ist den VTEPs vorbehalten. Sie kennen die Overlay-Struktur und müssen jeweils über eine erreichbare IP-Adresse im Underlay verfügen, um die VTEPs miteinander kommunizieren lassen zu können.

Es gibt jedoch auch unterschiedliche Verfahren im Underlay-Netz: In einigen Fällen ist Multicasting für ein dynamisches Peering der VTEPs notwendig. Die Routing-Protokolle im Underlay ermöglichen lediglich noch die Verbindung zwischen den VTEPs. Dies bietet eine hohe Flexibilität.

Um zu verstehen, wie VXLAN konkret arbeitet, müssen wir uns zunächst vor Augen führen, wie Ethernet-Switches arbeiten. Diese bauen auf der sogenannten Control-Plane zunächst MAC-Adress-Tabellen auf. Dies geschieht anhand von gelernten Layer-2-Quelladressen auf den jeweiligen Ports. Bei einer unbekannten MAC-Adresse erfolgt im Normalfall ein "Unknown Unicast Flooding". Dies entspricht einer Verteilung des Frames auf allen Ports, mit Ausnahme des Quellports. Nachdem die MAC-Adressen gelernt und die entsprechenden Forwarding-Tabellen etabliert sind, kann eine Weiterleitung der Ethernet-Frames auf der sogenannten Data-Plane erfolgen.

In VXLAN kommen andere Methoden zur Anwendung, um die Tabellen für die Weiterleitungsentscheidung zu erstellen. Während bei klassischen Ethernet-Switches als Ziel des Lernens eine Zuordnung von MAC-Adresse zu Zielport angedacht ist, muss bei VXLAN die Ziel- MAC-Adresse zur VTEP-IP zugeordnet sein. Erst im Nachgang können spätere Unicast-Frames zur jeweiligen Ziel-MAC-Adresse in VXLAN-Frames gekapselt und gezielt an den Ziel-VTEP zugestellt werden.

Die erste, aber auch ineffizienteste und zugleich unsicherste Variante stellt das sogenannte "Data Plane Learning" dar. Dies wird über Quell-Adress-Lernen erreicht, was den Nachteil mit sich bringt, dass das zugrunde liegende Netzwerk Multicast-fähig sein muss. Dies ist jedoch in einigen Fällen, insbesondere WAN- oder Public-Cloud-Netzen, nicht der Fall. Für die Weiterleitung von sogenannten BUM-Frames, also unbekannten Unicasts, Broadcasts und Multicast-Frames im Overlay-Segment kommt Multicasting im Underlay-Netz zur Anwendung. Diese Methode ist auch als "Flood-and-Learn" bekannt, wobei die teilnehmenden VTEPs für das jeweilige VNI einer zu definierenden Multicast-Gruppe beitreten. VTEPs senden wiederum Traffic an diese Multicast-Adresse.

Eine Alternative stellt das sogenannte Multiprotocol Border Gateway Protocol (MP-BGP) in Kombination mit dem Framework Ethernet Virtual Private Network (EVPN) als Control-Plane-Protokoll dar. MP-BGP EVPN ist sowohl für die Discovery von VTEPs, als auch das Lernen der MAC-Adressen zuständig. Dieses Protokoll optimiert das Lernen der MAC-Adressen und vermeidet das Fluten von Layer-2-Frames über das Overlay-Netzwerk. Dies wird dadurch erreicht, dass zunächst jeder VTEP ein sogenanntes Local Learning der MAC-Adresse durchführt, wie dies auch bereits in klassischen Layer-2-Netzen der Fall ist. Als BGP-Update über MP-BGP EVPN kommt es dann zu einer Verteilung der gelernten MAC-Adresse gemeinsam mit der zugehörigen IP-Adresse an die anderen VTEPs. Diese nennt sich auch Network-Layer-Reachability-Information.

Über die Korrelation dieser Information mit der IP-Adresse des Quell-VTEPs dieses BGP-Updates und dem zugehörigen VNI kann später in rückwärtiger Richtung das Forwarding erfolgen. Der Bezug der IP-Adress-Information zur MAC-Adresse ist auf Basis des Address Resolution Protocols (ARP) möglich.

Es besteht also bei MP-BGP EVPN keine zwingende Notwendigkeit für Multicasting im Underlay-Netz. Es kommt ein Unicast-basiertes MP-BGP-Peering über den TCP-Port 179 zum Einsatz. Diese Peerings unterstützen bei IBGP (Internal BGP) im Standard bereits mehrere Hops. Die VXLAN-VTEPS können sich also auch multiple Hops entfernt voneinander befinden, was das Deployment sehr flexibel macht. Bei EBGP (External BGP) bedarf es noch etwas Handarbeit des Administrators in Form einer expliziten Konfiguration, bevor diese Möglichkeit besteht.

Die sogenannte Multi-Hop-Funktionalität bezieht sich in diesem Fall auf die Time To Live (TTL) im IP-Header. Diese entspricht weitestgehend einer Interpretation des Hop-Counts. Die TTL für BGP-Pakete einer eBGP-Sitzung befindet sich in der Grundkonfiguration auf "1", wodurch sich die Peers im selben Subnetz befinden müssen. Sollte dies nicht möglich oder gewünscht sein, muss der Administrator auf dem Router BGP-Multi-Hop aktivieren, um eine Erhöhung der TTL zu bewirken. Im Fall eines iBGP-Peerings ist Multi-Hop in der Grundkonfiguration erlaubt, da in diesem Fall höhere TTLs zugrunde liegen.

Die Network-Layer-Reachability-Informationen sind also nur zwischen den fest angelegten MP-BGP-Peers austauschbar, was aus Sicht der IT-Sicherheit vorteilhaft ist. Potenzielle Angreifer-VTEPs können also nicht ohne Wei- teres eine Nachbarschaft aufbauen. Zum anderen besteht auch noch die Möglichkeit der Authentifizierung der VTEPs über eine MD5-Authentifizierung der BGP-Session oder auf Basis von TCP-Authentication-Options (TCP-AO) sogar mit moderneren Methoden. Ziel von TCP-AO ist konkret eine Absicherung gegen Blind Insertions und Replay-Attacken. In Flood-and-Learn-VXLAN-Netzen könnten gegebenenfalls unautorisierte VTEPs Daten in das Netzwerk injizieren.

Des Weiteren löst MP-BGP EVPN noch das Problem einer suboptimalen Datenweiterleitung. In unserem Beispiel müsste das Serversystem an Standort B über das Default-Gateway in Standort A kommunizieren, um aus dem VLAN heraus eine Kommunikationsbeziehung aufzubauen. Dies ist über ein verteiltes Anycast-Gateway auf jedem VTEP in einem VNI möglich.

Dies bedeutet konkret, dass jeder VTEP als Gateway mit derselben virtuellen Gateway-IP-Adresse und derselben virtuellen MAC-Adresse fungieren kann, um IP-Pakete von lokal angebundenen Hosts in andere Subnetze zu routen. Die Pakete müssen nicht mehr über das WAN zwischen den Standorten fließen. Interessant ist auch das Leistungsmerkmal ARP-Suppression. Bei diesem speichert der lokale VTEP IP- und MAC-Informationen des angeschlossenen VNIs zwischen und beantwortet entsprechende Anfragen. Sendet ein an diesen VTEP angebundener Host einen ARP-Request, prüft zunächst dieser lokale VTEP, ob er einen Eintrag in seinem Cache hat. Falls ja, beantwortet er den ARP-Request direkt selbst.

Kommt IBGP zum Einsatz, sind einige Besonderheiten zu beachten: IBGP-Peers müssen im Normalfall mit allen anderen IBGP-Peers eine Routing-Beziehung haben, da Routing-Informationen von IBGP-Nachbarn nicht an andere IBGP-Nachbarn weitergeleitet werden. Dies erzeugt natürlich bei großen Umgebungen einen enormen administrativen Aufwand. In einem solchen Fall kann eine Art Hub-and-Spoke-Design – bei IBGP als Route-Reflector bezeichnet – zum Einsatz kommen.

Der zugehörige VXLAN-Header ist insgesamt 8 Byte groß und besteht aus 8-Bit-Flags, 24 und 8 Bit langen reservierten Feldern sowie den 24 Bit umfassenden VXLAN Network Identifier (VNI). Beim Senden soll in den Flags das I-Bit für ein valides VNI auf "1" und die R-Flags auf "0" gesetzt sein. Alle reservierten Bits sollten ebenfalls beim Versenden den Wert "0" haben. Der VNI definiert das individuelle VXLAN-Overlay-Netzwerk.

Problematisch und auch aus anderen Tunnel-Lösungen bekannt ist jedoch der Zusammenhang mit der maximalen Paketgröße, der Maximum Transmission Unit (MTU) [2]. Der zusätzliche Header vergrößert die übertragenen Frames. VTEPs dürfen gemäß RFC 7348 Traffic an der Quelle nicht fragmentieren und am VTEP der Senke dürfen fragmentierte Pakete "silent gedropped" werden. Daher ist die MTU falls möglich zu vergrößern beziehungsweise an den Overhead von VXLAN anzupassen. Durch die Ausdehnung des Layer-2-Segments vergrößern sich jedoch auch einige Angriffsvektoren. Bei Layer-2-Trunks kommt unter anderem VLAN-Hopping zu den Vektoren hinzu.

Auch die Angriffsfläche für Attacken wie ARP-Spoofing vergrößert sich natürlich. In Multi-Mandanten-Netzen haben Attacken wie VLAN-Hopping katastrophale Auswirkungen. Die integrierten Sicherheitsmechanismen des BGP-Protokolls für MP-BGP EVPN empfehlen sich gegenüber Flood-and-Learn-basierten VXLAN-Netzen. Zusätzlich sollte Beachtung finden, dass nicht alle Switches und Hypervisoren VXLAN unterstützen. Selbst wenn sie dies grundlegend tun, muss eine Prüfung der unterstützten Control-Plane-Methoden der jeweiligen Komponente erfolgen. Auf der anderen Seite lassen einige andere Methoden zur Überwindung von Layer-3-Grenzen, wie das relativ alte Layer 2 Tunneling Protocol (L2TP), nur Punkt-zu-Punkt-Verbindungen zu.

Ein weiterer Kritikpunkt ist die fehlende native Integration von Verschlüsselungsmethoden. Diese müsste zwischen den VTEPs über zusätzliche Verschlüsselungsverfahren implementiert sein, was die Komplexität weiter steigert.

Zudem verfügt VXLAN auch nicht über fest zugewiesene Protocol Identifier. So kann ein VXLAN-Tunnel nicht mehrere Payload-Typen transportieren. Zudem sind im VXLAN-Header bereits alle Felder fest zugewiesen. Dies erschwert perspektivische Erweiterungen. Das Problem der fehlenden Erweiterbarkeit adressiert das noch recht neue Protokoll GENEVE (Generic Network Virtualization Encapsulation), das im RFC 8926 beschrieben ist. VMware setzt dieses in seiner Netzwerkvirtualisierung NSX-T bereits ein. Jedoch fehlt es GENEVE derzeit noch an Hardware-Implementierungen. Cisco Systems bietet seit einiger Zeit die ersten Hardware-Switches mit GENEVE-Unterstützung. Es bleibt also abzuwarten, ob sich in Zukunft weitere Hersteller anschließen.

Ein klassisches VLAN-Stretching für die Layer-2-Kopplung von Standorten stellt zwar eine schnelle Lösung dar, bringt jedoch einige Probleme mit sich. Um den steigenden Anforderungen an Bandbreite und Skalierbarkeit gerecht zu werden sowie gleichzeitig die Flexibilität von Layer-2-Kopplungen für virtualisierte Umgebungen zu erhalten, bietet sich VXLAN an. Es schafft eine Layer-2-Konnektivität in einer Layer-3-Struktur. Trotz all der Möglichkeiten sollten Sie aber immer prüfen, ob und an welchem Stellen des eigenen Netzwerks Sie VXLAN benötigen. Besser wären Lösungen, die nicht auf die Spreizung der Layer-2-Broadcastdomänen angewiesen sind.