4. VXLAN
VXLAN (virtuelles erweiterbares lokales Netzwerk, Virtual eXtensible Local Area Network) adressiert die oben genannten Anforderungen der Schicht-2- und Schicht-3-Rechenzentrums-Netzwerkinfrastruktur in Gegenwart von VMs in einer Mehrbenutzer-Umgebung. Es läuft über die bestehende Netzwerkinfrastruktur und bietet ein Mittel, ein Schicht-2-Netzwerk zu "strecken". Kurz gesagt, VXLAN ist ein Schicht-2-Overlay-Schema auf einem Schicht-3-Netzwerk. Jedes Overlay wird als VXLAN-Segment (VXLAN Segment) bezeichnet. Nur VMs innerhalb desselben VXLAN-Segments können miteinander kommunizieren. Jedes VXLAN-Segment wird durch eine 24-Bit-Segment-ID identifiziert, die als "VXLAN-Netzwerkidentifikator (VXLAN Network Identifier, VNI)" bezeichnet wird. Dies ermöglicht bis zu 16 M VXLAN-Segmenten, innerhalb derselben Verwaltungsdomäne zu koexistieren.
Der VNI identifiziert den Gültigkeitsbereich des inneren MAC-Frames, der von der einzelnen VM stammt. Daher könnten Sie überlappende MAC-Adressen über Segmente hinweg haben, aber niemals Verkehr "überkreuzen", da der Verkehr unter Verwendung des VNI isoliert ist. Der VNI befindet sich in einem äußeren Header, der den von der VM stammenden inneren MAC-Frame kapselt. In den folgenden Abschnitten wird der Begriff "VXLAN-Segment" austauschbar mit dem Begriff "VXLAN-Overlay-Netzwerk" verwendet.
Aufgrund dieser Kapselung könnte VXLAN auch als Tunneling-Schema bezeichnet werden, um Schicht-2-Netzwerke über Schicht-3-Netzwerke zu überlagern. Die Tunnel sind zustandslos, sodass jeder Frame gemäß einer Reihe von Regeln gekapselt wird. Der Endpunkt des Tunnels (VXLAN-Tunnelendpunkt, VXLAN Tunnel End Point oder VTEP), der in den folgenden Abschnitten diskutiert wird, befindet sich im Hypervisor auf dem Server, der die VM hostet. Daher sind die VNI- und VXLAN-bezogene Tunnel-/äußere Header-Kapselung nur dem VTEP bekannt -- die VM sieht sie nie (siehe Abbildung 1). Beachten Sie, dass es möglich ist, dass VTEPs auch auf einem physischen Switch oder physischen Server sein könnten und in Software oder Hardware implementiert werden könnten. Ein Anwendungsfall, bei dem der VTEP ein physischer Switch ist, wird in Abschnitt 6 über VXLAN-Bereitstellungsszenarien diskutiert.
Die folgenden Abschnitte diskutieren typische Verkehrsflussszenarien in einer VXLAN-Umgebung unter Verwendung einer Art von Kontrollschema -- Datenebenen-Lernen (Data Plane Learning). Hier wird die Zuordnung der MAC der VM zur IP-Adresse des VTEP über Quelladresslernen entdeckt. Multicast wird zum Übertragen von Frames mit unbekanntem Ziel, Broadcast und Multicast verwendet.
Zusätzlich zu einer lernbasierten Kontrollebene gibt es andere mögliche Schemata für die Verteilung der VTEP-IP- zu VM-MAC-Zuordnungsinformationen. Optionen könnten eine zentrale Autoritäts-/Verzeichnis-basierte Suche durch die einzelnen VTEPs, Verteilung dieser Zuordnungsinformationen an die VTEPs durch die zentrale Autorität usw. umfassen. Diese werden manchmal als Push- bzw. Pull-Modelle charakterisiert. Dieses Dokument wird sich auf das Datenebenen-Lernschema als Kontrollebene für VXLAN konzentrieren.
4.1. Unicast VM-to-VM Communication (Unicast-VM-zu-VM-Kommunikation)
Betrachten Sie eine VM innerhalb eines VXLAN-Overlay-Netzwerks. Diese VM ist sich VXLAN nicht bewusst. Um mit einer VM auf einem anderen Host zu kommunizieren, sendet sie wie gewohnt einen MAC-Frame, der für das Ziel bestimmt ist. Der VTEP auf dem physischen Host sucht nach dem VNI, dem diese VM zugeordnet ist. Es bestimmt dann, ob sich der Ziel-MAC auf demselben Segment befindet und ob es eine Zuordnung der Ziel-MAC-Adresse zum entfernten VTEP gibt. Wenn ja, wird ein äußerer Header, der aus einem äußeren MAC, einem äußeren IP-Header und einem VXLAN-Header besteht (siehe Abbildung 1 in Abschnitt 5 für das Frame-Format), dem ursprünglichen MAC-Frame vorangestellt. Das gekapselte Paket wird zum entfernten VTEP weitergeleitet. Bei Empfang überprüft der entfernte VTEP die Gültigkeit des VNI und ob es eine VM auf diesem VNI gibt, die eine MAC-Adresse verwendet, die mit der inneren Ziel-MAC-Adresse übereinstimmt. Wenn ja, wird das Paket seiner Kapselungsheader entledigt und an die Ziel-VM weitergegeben. Die Ziel-VM erfährt nie vom VNI oder dass der Frame mit einer VXLAN-Kapselung transportiert wurde.
Zusätzlich zur Weiterleitung des Pakets an die Ziel-VM lernt der entfernte VTEP die Zuordnung vom inneren Quell-MAC zur äußeren Quell-IP-Adresse. Es speichert diese Zuordnung in einer Tabelle, sodass, wenn die Ziel-VM ein Antwortpaket sendet, keine "unbekannte Ziel"-Flutung des Antwortpakets erforderlich ist.
Die Bestimmung der MAC-Adresse der Ziel-VM vor der Übertragung durch die Quell-VM wird wie bei Nicht-VXLAN-Umgebungen durchgeführt, außer wie in Abschnitt 4.2 beschrieben. Broadcast-Frames werden verwendet, sind aber in einem Multicast-Paket gekapselt, wie in Abschnitt 4.2 detailliert beschrieben.
4.2. Broadcast Communication and Mapping to Multicast (Broadcast-Kommunikation und Zuordnung zu Multicast)
Betrachten Sie die VM auf dem Quellhost, die versucht, mit der Ziel-VM unter Verwendung von IP zu kommunizieren. Unter der Annahme, dass sie sich beide im selben Subnetz befinden, sendet die VM einen Address Resolution Protocol (ARP) Broadcast-Frame. In der Nicht-VXLAN-Umgebung würde dieser Frame unter Verwendung von MAC-Broadcast über alle Switches gesendet, die dieses VLAN tragen.
Mit VXLAN wird ein Header einschließlich des VXLAN-VNI am Anfang des Pakets zusammen mit dem IP-Header und dem UDP-Header eingefügt. Dieses Broadcast-Paket wird jedoch an die IP-Multicast-Gruppe gesendet, auf der dieses VXLAN-Overlay-Netzwerk realisiert wird.
Um dies zu bewirken, müssen wir eine Zuordnung zwischen dem VXLAN-VNI und der IP-Multicast-Gruppe haben, die es verwenden wird. Diese Zuordnung erfolgt auf der Verwaltungsebene und wird den einzelnen VTEPs über einen Verwaltungskanal bereitgestellt. Unter Verwendung dieser Zuordnung kann der VTEP IGMP-Mitgliedschaftsberichte an den vorgelagerten Switch/Router bereitstellen, um die VXLAN-bezogenen IP-Multicast-Gruppen nach Bedarf beizutreten/zu verlassen. Dies ermöglicht das Beschneiden der Blattknoten für bestimmte Multicast-Verkehrsadressen basierend darauf, ob ein Mitglied auf diesem Host verfügbar ist, das die spezifische Multicast-Adresse verwendet (siehe [RFC4541]). Darüber hinaus bietet die Verwendung von Multicast-Routing-Protokollen wie Protocol Independent Multicast - Sparse Mode (PIM-SM siehe [RFC4601]) effiziente Multicast-Bäume innerhalb des Schicht-3-Netzwerks.
Der VTEP wird (*,G)-Beitritte verwenden. Dies ist erforderlich, da die Menge der VXLAN-Tunnelquellen unbekannt ist und sich häufig ändern kann, da die VMs auf verschiedenen Hosts hochfahren/herunterfahren. Eine Nebenbemerkung hier ist, dass, da jeder VTEP sowohl als Quelle als auch als Ziel für Multicast-Pakete fungieren kann, ein Protokoll wie bidirektionales PIM (BIDIR-PIM -- siehe [RFC5015]) effizienter wäre.
Die Ziel-VM sendet eine Standard-ARP-Antwort unter Verwendung von IP-Unicast. Dieser Frame wird zurück zum VTEP gekapselt, der die ursprüngliche VM verbindet, unter Verwendung von IP-Unicast-VXLAN-Kapselung. Dies ist möglich, da die Zuordnung des Ziel-MAC der ARP-Antwort zur VXLAN-Tunnelendpunkt-IP zuvor über die ARP-Anfrage gelernt wurde.
Beachten Sie, dass Multicast-Frames und "unbekannte MAC-Ziel"-Frames ebenfalls unter Verwendung des Multicast-Baums gesendet werden, ähnlich wie Broadcast-Frames.
4.3. Physical Infrastructure Requirements (Anforderungen an die physische Infrastruktur)
Wenn IP-Multicast innerhalb der Netzwerkinfrastruktur verwendet wird, kann ein Multicast-Routing-Protokoll wie PIM-SM von den einzelnen Schicht-3-IP-Routern/Switches innerhalb des Netzwerks verwendet werden. Dies wird verwendet, um effiziente Multicast-Weiterleitungsbäume zu erstellen, sodass Multicast-Frames nur an diejenigen Hosts gesendet werden, die angefordert haben, sie zu empfangen.
Ebenso gibt es keine Anforderung, dass das tatsächliche Netzwerk, das die Quell-VM und die Ziel-VM verbindet, ein Schicht-3-Netzwerk sein sollte: VXLAN kann auch über Schicht-2-Netzwerke funktionieren. In beiden Fällen kann eine effiziente Multicast-Replikation innerhalb des Schicht-2-Netzwerks unter Verwendung von IGMP-Snooping erreicht werden.
VTEPs dürfen (MUST NOT) VXLAN-Pakete fragmentieren. Zwischenrouter können gekapselte VXLAN-Pakete aufgrund der größeren Frame-Größe fragmentieren. Der Ziel-VTEP kann (MAY) solche VXLAN-Fragmente stillschweigend verwerfen. Um eine Ende-zu-Ende-Verkehrslieferung ohne Fragmentierung sicherzustellen, wird empfohlen (RECOMMENDED), dass die MTUs (Maximum Transmission Units) über die physische Netzwerkinfrastruktur auf einen Wert gesetzt werden, der die größere Frame-Größe aufgrund der Kapselung aufnimmt. Andere Techniken wie Path MTU Discovery (siehe [RFC1191] und [RFC1981]) können (MAY) ebenfalls verwendet werden, um diese Anforderung zu erfüllen.