VMware vSwitch und Double-Tagging (QinQ)

VMware vSwitch und Double-Tagging (QinQ)

Beim Versuch, doppelt markierte Daten über einen vSwitch zu übergeben, tritt ein Problem auf.

Eine physische Schnittstelle auf dem VMWare-Hostcomputer empfängt doppelt getaggten Datenverkehr – das äußere Tag unterscheidet mehrere Switches (spiegelt Remote-Tags) und die inneren Tags stammen vom internen Datenverkehr der Switches selbst. Der interne Datenverkehr kann sowohl getaggt als auch ungetaggt sein, je nachdem, ob der gespiegelte Port ein Zugriffsport oder ein Trunk war.

Ein vSwitch ist mit mehreren Netzwerken konfiguriert (jedes für ein anderes äußeres Tag von einem anderen Switch) und ein Gastcomputer sollte nur (einzelnen) getaggten Datenverkehr sehen.

Das Problem besteht darin, dass der Gastcomputer keinen Datenverkehr empfängt, der (auf dem PHY) als doppelt markiert empfangen wurde. Wenn der ursprüngliche interne Datenverkehr nicht markiert war (PHY auf dem Hostcomputer empfängt nur 1-Tag), sieht der Gast diesen Datenverkehr korrekt.

Ich habe auch einen Test durchgeführt und ein Netzwerk auf dem vSwitch mit Tag 4095 konfiguriert, an das jeglicher getaggter Datenverkehr weitergeleitet werden soll (VGT). Auch hier empfängt die Gastmaschine nur den einzelnen getaggten Datenverkehr, der von phy empfangen wird. Der einzige Unterschied besteht darin, dass der Gast ihn als getaggt sieht. Dies beweist, dass das Gastbetriebssystem getaggten Datenverkehr korrekt sieht, und führt mich zu dem Schluss, dass das Problem beim vSwitch liegt.

Gibt es also eine Möglichkeit, den vSwitch zu zwingen, die inneren Tags zu ignorieren und den Datenverkehr unabhängig vom inneren Tag an den Gast weiterzuleiten?

Betroffen ist vSphere/vcenter/ESXi-Version 5.1.0.

Antwort1

Ich habe die Dokumentation durchgesehen und keine Erwähnung der Unterstützung für QinQ VLAN-Tagging gefunden (802.1ad) für vSwitches oder Distributed Switches und muss feststellen, dass es in vSphere nicht unterstützt wird. Ich hatte große Hoffnungen, dass Ciscos virtueller Nexus 1000v-Switch QinQ unterstützen würde, aber esAuchscheint, dass es nicht unterstützt wird. Anscheinend ist QinQ-Unterstützung nicht einmal in der Nexus 5000-Serie verfügbar, aber es sieht so aus, als ob sie in derNexus 7000-Serie.

Ich würde dies mit dem Support von VMware und Cisco bestätigen, bevor ich irgendwelche Designentscheidungen treffe, aber es scheint, als wäre dies keine mögliche Konfiguration.

Antwort2

Das Problem liegt eigentlich im VMware-Konzept, wie es getaggten Datenverkehr auf der bestehenden Portgruppe handhabt. Wenn es das äußere VLAN entfernt, verwirft es auch alle inneren VLANs, falls vorhanden. Die einzige Lösung besteht darin, zu verhindern, dass VMware Pakete abhört/ändert, wenn sie ankommen – das heißt, es sollten keine VLANs hinzugefügt oder entfernt werden. Ich habe dies erreicht, indem ich in jeder Portgruppe ein vDSW und VLAN-Trunking verwendet habe. In einem solchen Setup erhält die VM doppelt getaggten Datenverkehr unverändert. Für Spiegelung und Datenverkehrsanalyse ist dies akzeptabel, aber für Produktionssysteme ist dies keine praktikable Lösung. Auf v(D)SW sollte eine Art VLAN-Tunneling-Option verfügbar sein.

verwandte Informationen