Konfigurieren von Q-in-Q
Unter diesem Thema wird beschrieben, wie Sie Ihre lokalen Netzwerkgeräte mit einem Clouddienstanbieter (CSP) verbinden können, der Q-in-Q verwendet, wie z. B. Azure ExpressRoute. Da einige CSPs Q-in-Q erfordern, aber nicht alle Netzwerkgeräte dies oder den Mix aus einzelnen und mehreren Tags auf einer einzelnen physikalischen Schnittstelle („selektives Q-in-Q“) unterstützen, werden unter diesem Thema außerdem Möglichkeiten zur Konfiguration der Verarbeitung von Multilayer-VLAN-Tags auf Netzwerkgeräten ohne native Q-in-Q-Unterstützung beschrieben.
Übersicht
Q-in-Q, auch bekannt als 802.1ad, ist ein Protokoll, das häufig von NSPs (Network Service Provider) verwendet wird, um mehr Layer 2-Flexibilität zu bieten. Mit Q-in-Q können mehrere VLAN-Tags in einen einzigen Ethernet-Frame eingefügt werden. Durch das Stacking von mehreren VLAN-Tags in einem Frame können Routing-Domänen isoliert werden, da die zusätzlichen Tags den Kundendatenverkehr identifizieren und trennen. Durch die Verwendung unterschiedlicher VLAN-Tags für jeden Kunden wird der Datenverkehr innerhalb des Frames identifiziert und durch das Netzwerk des Dienstanbieters übertragen.
Wichtig
Um die VLAN-Tags gemäß dem Standard 802.1ad voneinander zu unterscheiden, verwendet das innere üblicherweise EtherType 0x8100 und das äußere 0x88a8. Die Standardkonfiguration für Q-in-Q sieht bei den meisten Netzwerkhersteller vor, dass sowohl für das innere als auch das äußere Tag EtherTyp 0x8100 verwendet wird. Die Megaport-Spezifikation von Double-Tagged-Frames lautet sowohl für das innere als auch das äußere Tag 0x8100.
Mit Q-in-Q werden auf dem Weg eines Pakets von einem NSP-Netzwerk oder einem Netzbetreiber zum VLAN eines Cloud- oder anderen Dienstanbieters in die vom Dienstanbieter bereitgestellten äußeren VLAN-Tags (S-Tags) innere VLAN-Tags (C-Tags) eingefügt, mit denen der Kundendatenverkehr identifiziert wird. Das S-Tag bietet ein einzelnes VLAN, das mehrere VLANs in sich kapselt. In dieser Konfiguration kann ein einzelner VXC die Multi-VLAN-Tags zwischen den beiden Netzwerkendpunkten übertragen.
Weitere Informationen zu Q-in-Q finden Sie unter Verbinden eines VXC und im Megaport-Blogbeitrag Q & A für Q-in-Q: Teil 1. Weitere Informationen zur Konfiguration von Q-in-Q für Azure finden Sie im Megaport-Blogbeitrag Q & A für Q-in-Q: Teil 2.
Erläuterungen zu Q-in-Q mit Megaport-VXCs
Ein VXC (Virtual Cross Connect) ist eine Punkt-zu-Punkt-Verbindung auf Layer 2 zwischen zwei Endpunkten, denen an jedem Ende eine VLAN-ID zugeordnet ist, wobei optional A-Ende- und B-Ende-VLAN-Tags unabhängig im Megaport-Netzwerk zugeordnet werden.
Die folgende Abbildung zeigt eine Azure ExpressRoute-Verbindung mit privatem Peering und aktiviertem Microsoft Peering. Ein VXC verbindet einen Kunden-Edge mit einem Microsoft-Edge auf VLAN 1000 (S-Tag). Die Kunden-Edge unterstützt Q-in-Q. Das private Peering läuft auf VLAN 100 (C-Tag) und Microsoft Peering läuft auf VLAN 200 (C-Tag), um eine Layer 3-Verbindung und BGP-Peering mit Azure herzustellen.
Was ist, wenn meine Router oder Switches Q-in-Q nicht unterstützen?
In diesem Abschnitt wird beschrieben, wie Sie eine Verbindung zu einem B-Ende-Dienst herstellen können, der Q-in-Q erfordert, auch wenn die Netzwerkgeräte, die Ihre Megaport-Verbindung terminieren, dies nicht nativ unterstützen.
| Q-in-Q-Alternativen | Methode | Nachteile | ||
|---|---|---|---|---|
| Einzelnes Azure-Peering-VLAN | Sie können den VXC so konfigurieren, dass Megaport die Q-in-Q-Anforderung aufhebt. Dazu müssen Sie eine Neuzuordnung einer der VLAN-IDs des B-Endes für Private oder Microsoft Peering zum kundenseitigen Megaport-VLAN (A-Ende) vornehmen. | Sie können nur einen einzigen Microsoft-Peering-Typ pro VXC verwenden. | ||
| Tag des mit dem Kundenport verbundenen VXC entfernen | Sie können den VXC als nicht getaggt konfigurieren, um das S-Tag automatisch zu entfernen. | Das Untagging eines VLAN beschränkt den Port auf eine einzelne VXC-Verbindung. Die Verwendung dieser Methode bedeutet, dass Ihr Port nur ein einziges B-Ende-Ziel konfigurieren kann, obwohl er alle inneren C-Tags von diesem Peer als mit „single/dot1q“ getaggt empfängt. | ||
| Megaport Cloud Routers bereitstellen | Sie können einen Megaport Cloud Router (MCR) bereitstellen, um die Q-in-Q-Anforderungen für einen oder beide Peering-Typen automatisch zu verwalten. | Zusätzliche Kosten für den MCR und zusätzliche VXC zum MCR. |
Eine VXC-Verbindung zu Microsoft ExpressRoute kann ein oder zwei innere VLAN-Tags enthalten. Diese sind die in der Microsoft Azure-Konsole konfigurierten C-Tags für den angegebenen Peering-Typ. Beachten Sie, dass Q-in-Q in diesem Szenario eine Voraussetzung ist, auch wenn nur ein einziges Microsoft-Edge-Gerät (primär oder sekundär) oder ein Peering-Typ (privat oder Microsoft) verwendet wird. Netzwerkgeräte, die Q-in-Q unterstützen, können auf diese inneren Tags zugreifen, indem sie das äußere VLAN-Tag (S-Tag) entfernen. Wenn Ihre Netzwerkgeräte Q-in-Q nicht unterstützen, können diese nicht auf die inneren Tags zugreifen.
Hinweis
Es gibt weitere Q-in-Q-Workarounds, wie z. B. die Handhabung über mehrere Geräte auf der Kundenseite, um die Q-in-Q-Frames zu entkapseln, oder die Verwendung von Loopback-Kabeln innerhalb eines einzigen Geräts, um dies über eine Kaskadierung durch mehrere Ports mit unterschiedlichen VLAN-Konfigurationen für innere und äußere Tags zu verwalten. In Produktionsnetzwerken wird dies jedoch generell nicht empfohlen.
Einzelnes Azure-Peering-VLAN
Für Microsoft Azure ExpressRoute-Verbindungen verwendet Megaport einen Microsoft-Dienstschlüssel (und die damit verbundene Auswahl des primären und sekundären Zielendpunkts) und bietet die Möglichkeit, den eingekapselten C-Tag für einen bestimmten Azure-Peering-Typ herauszubrechen (break out). Sie aktivieren diese Funktionalität, indem Sie im Fenster „Connection Details“ (Verbindungsdetails) einer neuen ExpressRoute-Verbindung die Option „Configure Single Azure Peering VLAN“ (Einzelnes Azure-Peering-VLAN konfigurieren) aktivieren, nachdem Sie einen primären oder sekundären B-Ende-Zielport ausgewählt haben.
Tipp
Wir empfehlen die Verwendung der Option „Single Azure Peering VLAN“ (Einzelnes Azure Peering-VLAN). Diese Option bietet volle Funktionalität und die einfachste Implementierung. Mit Single Azure VLAN können Sie sowohl privates als auch Microsoft-Peering mit einer einzigen ER-Leitung nutzen, ohne dass Sie Q-in-Q-fähige Geräte, einen MCR oder einen nicht getaggten Port benötigen. Beachten Sie, dass Sie mit dieser Option pro VXC nur einen Peering-Typ (Private oder Microsoft) verwenden können, sodass Sie zwei VXCs benötigen, um beide Peering-Typen zu verwenden.
Durch die Aktivierung der VLAN-Funktion „Single Azure Peering VLAN“ (Einzelnes Azure-Peering-VLAN) können Sie ein einzelnes Azure-Peering-VLAN angeben, das mit dem Wert übereinstimmt, den Sie (in einem späteren Schritt) bei der Azure ExpressRoute-Konfiguration für den ausgewählten Peering-Typ konfigurieren (über das Microsoft Azure-Portal oder eine andere Konfigurationsmethode). Weitere Informationen finden Sie unter Tutorial: Erstellen und Ändern des Peerings für eine ExpressRoute-Leitung mithilfe des Azure-Portals.
Wenn Sie das Feld „Preferred A-End VLAN“ (Bevorzugtes A-Ende-VLAN) leer lassen, wird Ihrer VXC-Verbindung bei der Bestellung ein zufällig ausgewähltes VLAN zugewiesen. Andernfalls geben Sie ein VLAN an, für das eine Validierungsprüfung durchgeführt wird, um sicherzustellen, dass dieses VLAN verfügbar ist.
Das Beispiel zeigt, dass ein Azure-C-Tag-Wert von 200 (entweder für einen privaten oder Microsoft-Peering-Typ auf der zugehörigen ExpressRoute-Leitung) transparent einem einfach getaggten VXC-VLAN mit dem Wert 3001 zugeordnet wird. Das heißt, für das Kundengerät, das an die physische Megaport-Schnittstelle angebunden ist, müssen keine Q-in-Q-Einstellungen konfiguriert werden, da dot1q-VLAN 3001 dem zugehörigen Microsoft-seitigen B-Ende-Edge-Gerät als korrekt gekennzeichnet zugeordnet wird.
In dieser Konfiguration ist es möglich, sowohl den primären als auch den sekundären Microsoft ExpressRoute-Endpunkt auf einer bestimmten ExpressRoute-Leitung zu verwenden, um verschiedene VLAN-Tags einem einzigen kundenseitigen Port zuzuordnen. Dies ist konform mit den Anforderungen des SLA (Service Level Agreement) für Azure ExpressRoute. Wir empfehlen jedoch, entweder (zonale) Port- und Gerätediversität an einem Standort bereitzustellen oder die primären/sekundären ExpressRoute-Verbindungen auf zwei Megaport-fähige Standorte aufzuteilen, um sicherzustellen, dass bei der Konfiguration kein Single Point of Failure existiert.
Weitere Informationen zum SLA für Azure ExpressRoute finden Sie unter SLA für Azure ExpressRoute.
Mit dieser Methode ist es nicht möglich, mehr als einen Peering-Typ über die primäre oder sekundäre ExpressRoute zu VXCs zu verwenden, da diese Tag-Übersetzung nur einmal pro VXC-Leitungspfad erfolgen darf. Weitere Möglichkeiten zur Problemumgehung werden in den folgenden Abschnitten beschrieben. Beachten Sie jedoch, dass die Segmentierung der Bandbreite zwischen mehreren Peering-Typen auf einem einzelnen ExpressRoute-Leitungspaar derzeit von Microsoft nicht unterstützt wird. In den meisten Fällen ist es vorzuziehen, zwei ExpressRoute-Paare bereitzustellen, um dieses Konfigurationsziel zu erreichen.
Hinweis
In den folgenden Abschnitten werden Problemumgehungen beschrieben, die mit dem Microsoft ExpressRoute-Beispiel fortfahren. Beachten Sie, dass diese Problemumgehungen nicht nur für Azure-Endpunkte gelten, sondern auch für andere Verbindungen über Megaport verwendet werden können, bei denen das B-Ende möglicherweise Q-in-Q angibt oder erfordert, um mehrere C-Tag/innere VLANs innerhalb eines einzelnen S-Tag/äußeren VXC-VLAN zu übertragen. Das Microsoft ExpressRoute-Beispiel wird für die Kontinuität des Kundenszenarios verwendet.
Konfigurieren des VXC als nicht getaggt für automatische S-Tag-Verwaltung
Hinweis
Der Einsatz dieser Methode bedeutet, dass der Kunden-Megaport nur ein einziges B-Ende-Ziel konfigurieren kann, obwohl er alle inneren/C-Tags von diesem Peer als single/dot1q getaggt empfängt.
Sie können den VXC so konfigurieren, dass Megaport das äußere VLAN (S-Tag) entfernt und dem Kunden-Megaport eines der beiden oder beide inneren VLANs (C-Tag/s) für Private Peering, Microsoft Peering oder beides präsentiert.
Derzeit erlaubt dieser Prozess nur eine VXC pro ExpressRoute Circuit-Verbindung (Auswahl zwischen primärer oder sekundärer Port-Präsentation), obwohl beide Peering-Typen über diese VXC unterstützt werden können, da sie dem Kundenport als ein oder zwei dot1q-VLANs (Private Peering, Microsoft Peering oder beides) präsentiert werden.
Wichtig
Der Kundenport empfängt die inneren VLAN-Tags, wie sie im Azure-Portal unter dem angegebenen Peering-Typ für den Kundenport des A-Endes definiert sind. Weitere Informationen dazu finden Sie unter Verbinden mit Microsoft Azure ExpressRoute.
Hinweis
Jedes ExpressRoute-Abonnement umfasst zwei Port-Ziele am gewählten Microsoft Edge-Anbindungsstelle. Um Datenverkehr sowohl von der primären als auch der sekundären ExpressRoute-Leitung entgegennehmen zu können, benötigen Sie in dieser Konfiguration zwei Ports von Megaport. Die Azure VNET-VLAN-Tags sind an beiden Ports gleich. Megaport kann das VLAN-Tag auf der primären und der sekundären Verbindung nicht ändern, und es kann das gleiche VLAN nicht zweimal auf der gleichen physischen Schnittstelle verarbeiten.
Hinweis
Wenn Sie nur privates oder öffentliches Peering auf der Azure ExpressRoute-Konfiguration konfigurieren, ist nur das VLAN, das mit dem ExpressRoute-Dienstschlüssel verbunden ist, auf dem konfigurierten VXC verfügbar, der dem Kundenport 1:1 zugeordnet ist.
Bereitstellen eines Megaport Cloud Router
Der Megaport Cloud Router (MCR) unterstützt die Aktivierung mehrerer Clouds und Regionen, einschließlich der Unterstützung von Q-in-Q zur Verbindung mit mehreren Cloudzielen. Die S-Tags oder äußeren Tags gehören zu dem A-Ende-VLAN, das mit Ihrem MCR verbunden ist, und übertragen transparent Ihre C-Tags. Die S-Tags werden automatisch konfiguriert, wenn Sie das private und öffentliche Peering zu Azure Cloud im Megaport Portal bereitstellen. Die folgende Abbildung zeigt eine Beispielkonfiguration:
Wenn mehrere Azure-VXCs auf einem MCR das gleiche VLAN 100-Tag (privates Peering) und das gleiche VLAN 200-Tag (öffentliches Peering) auffüllen, verwaltet der MCR den Q-in-Q-Tunnel für jeden Azure-VXC, der auf dem MCR endet. Jedes Azure-VLAN ist weiterhin eine separate logische Schnittstelle.