6. VXLAN Deployment Scenarios (VXLAN-Bereitstellungsszenarien)
VXLAN wird typischerweise in Rechenzentren auf virtualisierten Hosts bereitgestellt, die über mehrere Racks verteilt sein können. Die einzelnen Racks können Teile eines anderen Schicht-3-Netzwerks sein oder sie könnten sich in einem einzigen Schicht-2-Netzwerk befinden. Die VXLAN-Segmente/Overlay-Netzwerke werden auf diesen Schicht-2- oder Schicht-3-Netzwerken überlagert.
Betrachten Sie Abbildung 3, die zwei virtualisierte Server zeigt, die an eine Schicht-3-Infrastruktur angeschlossen sind. Die Server könnten sich auf demselben Rack, auf verschiedenen Racks oder möglicherweise über Rechenzentren innerhalb derselben Verwaltungsdomäne befinden. Es gibt vier VXLAN-Overlay-Netzwerke, die durch die VNIs 22, 34, 74 und 98 identifiziert werden. Betrachten Sie den Fall von VM1-1 in Server 1 und VM2-4 auf Server 2, die sich im selben VXLAN-Overlay-Netzwerk befinden, das durch VNI 22 identifiziert wird. Die VMs wissen nichts über die Overlay-Netzwerke und die Transportmethode, da die Kapselung und Entkapselung transparent an den VTEPs auf den Servern 1 und 2 erfolgen. Die anderen Overlay-Netzwerke und die entsprechenden VMs sind VM1-2 auf Server 1 und VM2-1 auf Server 2, beide auf VNI 34; VM1-3 auf Server 1 und VM2-2 auf Server 2 auf VNI 74; und schließlich VM1-4 auf Server 1 und VM2-3 auf Server 2 auf VNI 98.
+------------+-------------+
| Server 1 |
| +----+----+ +----+----+ |
| |VM1-1 | |VM1-2 | |
| |VNI 22 | |VNI 34 | |
| | | | | |
| +---------+ +---------+ |
| |
| +----+----+ +----+----+ |
| |VM1-3 | |VM1-4 | |
| |VNI 74 | |VNI 98 | |
| | | | | |
| +---------+ +---------+ |
| Hypervisor VTEP (IP1) |
+--------------------------+
|
|
|
| +-------------+
| | Layer 3 |
|---| Network |
| |
+-------------+
|
|
+-----------+
|
|
+------------+-------------+
| Server 2 |
| +----+----+ +----+----+ |
| |VM2-1 | |VM2-2 | |
| |VNI 34 | |VNI 74 | |
| | | | | |
| +---------+ +---------+ |
| |
| +----+----+ +----+----+ |
| |VM2-3 | |VM2-4 | |
| |VNI 98 | |VNI 22 | |
| | | | | |
| +---------+ +---------+ |
| Hypervisor VTEP (IP2) |
+--------------------------+
Abbildung 3: VXLAN-Bereitstellung - VTEPs über ein Schicht-3-Netzwerk
Ein Bereitstellungsszenario ist, wenn der Tunnelendpunkt ein physischer Server ist, der VXLAN versteht. Ein alternatives Szenario ist, wenn Knoten in einem VXLAN-Overlay-Netzwerk mit Knoten in Legacy-Netzwerken kommunizieren müssen, die VLAN-basiert sein könnten. Diese Knoten können physische Knoten oder virtuelle Maschinen sein. Um diese Kommunikation zu ermöglichen, kann ein Netzwerk VXLAN-Gateways umfassen (siehe Abbildung 4 unten mit einem Switch, der als VXLAN-Gateway fungiert), die Verkehr zwischen VXLAN- und Nicht-VXLAN-Umgebungen weiterleiten.
Betrachten Sie Abbildung 4 für die folgende Diskussion. Für eingehende Frames auf der VXLAN-verbundenen Schnittstelle entfernt das Gateway den VXLAN-Header und leitet ihn basierend auf der Ziel-MAC-Adresse des inneren Ethernet-Frames an einen physischen Port weiter. Entkapselte Frames mit der inneren VLAN-ID sollten (SHOULD) verworfen werden, es sei denn, sie sind explizit konfiguriert, um an die Nicht-VXLAN-Schnittstelle weitergegeben zu werden. In umgekehrter Richtung werden eingehende Frames für die Nicht-VXLAN-Schnittstellen basierend auf der VLAN-ID im Frame einem bestimmten VXLAN-Overlay-Netzwerk zugeordnet. Sofern nicht explizit konfiguriert, um im gekapselten VXLAN-Frame weitergegeben zu werden, wird diese VLAN-ID entfernt, bevor der Frame für VXLAN gekapselt wird.
Diese Gateways, die VXLAN-Tunnelterminierungsfunktionen bereitstellen, könnten ToR/Zugangs-Switches oder Switches höher in der Rechenzentrum-Netzwerktopologie sein -- z. B. Core- oder sogar WAN-Edge-Geräte. Der letzte Fall (WAN-Edge) könnte einen Provider Edge (PE) Router umfassen, der VXLAN-Tunnel in einer Hybrid-Cloud-Umgebung terminiert. Beachten Sie in all diesen Fällen, dass die Gateway-Funktionalität in Software oder Hardware implementiert werden könnte.
+---+-----+---+ +---+-----+---+
| Server 1 | | Non-VXLAN |
(VXLAN enabled)<-----+ +---->| server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
|Server 2 | | | | Non-VXLAN |
(VXLAN enabled)<-----+ +---+-----+---+ +---->| server |
+-------------+ | |Switch acting| | +-------------+
|---| as VXLAN |-----|
+---+-----+---+ | | Gateway |
| Server 3 | | +-------------+
(VXLAN enabled)<-----+
+-------------+ |
|
+---+-----+---+ |
| Server 4 | |
(VXLAN enabled)<-----+
+-------------+
Abbildung 4: VXLAN-Bereitstellung - VXLAN-Gateway
6.1. Inner VLAN Tag Handling (Handhabung innerer VLAN-Tags)
Die Handhabung innerer VLAN-Tags in VTEP und VXLAN-Gateway sollte Folgendem entsprechen:
Entkapselte VXLAN-Frames mit dem inneren VLAN-Tag sollten (SHOULD) verworfen werden, es sei denn, sie sind anders konfiguriert. Auf der Kapselungsseite sollte (SHOULD NOT) ein VTEP kein inneres VLAN-Tag auf Tunnelpaketen enthalten, es sei denn, es ist anders konfiguriert. Wenn ein VLAN-getaggtes Paket ein Kandidat für VXLAN-Tunneling ist, sollte (SHOULD) der kapselnde VTEP das VLAN-Tag entfernen, es sei denn, es ist anders konfiguriert.