Konfigurieren von Q-in-Q
Dieses Thema beschreibt Möglichkeiten, Ihre On-Premises-Netzwerkgeräte mit einem Cloud Service Provider (CSP) zu verbinden, der Q-in-Q802.1Q Tunneling (auch bekannt als Q-in-Q oder 802.1ad) ist eine von OSI-Layer-2-Providern für Kunden eingesetzte Technik. 802.1ad sieht sowohl ein inneres als auch ein äußeres Tag vor, wobei das äußere (manchmal als S-Tag für Service Provider bezeichnet) entfernt werden kann, um die inneren (C-Tag oder Kunden-Tag) Tags freizulegen, die die Daten segmentieren.
verwendet, wie etwa Azure ExpressRoute. Darüber hinaus enthält dieses Thema Konfigurationsmöglichkeiten für die Handhabung mehrerer VLAN-Tagschichten auf Netzwerkgeräten ohne native Q-in-Q-Unterstützung, da einige CSPs Q-in-Q erfordern, aber nicht alle Netzwerkgeräte es unterstützen oder das Mischen von einzelnen und mehreren Tags auf einer einzigen physikalischen Schnittstelle („selective Q-in-Q“).
Übersicht
Q-in-Q, auch bekannt als 802.1ad, ist ein Protokoll, das von Network Service Providern (NSPs) häufig eingesetzt wird, um mehr Flexibilität auf Layer 2 zu bieten. Q-in-Q ermöglicht es, mehrere VLAN-Tags in einen einzigen Ethernet-Frame einzufügen. Durch das Stapeln mehrerer 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 eines unterschiedlichen VLAN-Tags für jeden Kunden wird der Verkehr innerhalb des Frames identifiziert und im gesamten Netzwerk des Service Providers übertragen.
Wichtig
Zur Unterscheidung der VLAN-Tags gemäß dem 802.1ad-Standard verwendet das innere üblicherweise den EtherType 0x8100 und das äußere 0x88a8. Die Standardkonfiguration für Q-in-Q der meisten Netzwerkhersteller sieht vor, dass sowohl der innere als auch der äußere EtherType 0x8100 ist. Die Spezifikation von Megaport für doppelt getaggte Frames sieht vor, dass sowohl innere als auch äußere Tags 0x8100 sind.
Bei Q-in-Q werden, wenn ein Paket von einem NSP- oder Carriernetz zu dem VLAN eines Cloud- (oder eines anderen) Service Providers gelangt, innere VLAN-Tags (C-Tags), die den Kundendatenverkehr identifizieren, innerhalb der äußeren VLAN-Tags (S-Tags) eingefügt, die vom Service Provider bereitgestellt werden. Das S-Tag stellt ein einzelnes VLAN bereit, das mehrere VLANs darin kapselt. In dieser Konfiguration kann ein einzelner VXC die mehreren VLAN-Tags zwischen den beiden Netzwerkendpunkten transportieren.
Weitere Informationen zu Q-in-Q finden Sie unter Verbinden eines VXC und im Megaport blog post Q & A for Q-in-Q: Part 1. Weitere Informationen zur Konfiguration von Q-in-Q für Azure finden Sie im Megaport blog post Q & A for Q-in-Q: Part 2.
Q-in-Q mit Megaport VXCs verstehen
Ein Virtual Cross Connect (VXC) ist eine Point-to-Point-Layer-2-Verbindung zwischen zwei Endpunkten, die an jedem Ende mit einer VLAN-ID gemappt ist, optional mit A- und B-End-VLAN-Tags, die unabhängig über das Megaport Netzwerk gemappt werden.
Diese Abbildung zeigt eine Azure ExpressRoute mit aktiviertem privatem Peering und Microsoft Peering. Ein VXC verbindet eine kundenseitige Edge mit einer Microsoft-Edge über VLAN 1000 (S-Tag). Die kundenseitige 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 Layer-3-Verbindungen und BGP-Peering mit Azure herzustellen.
Was ist, wenn meine Router oder Switches Q-in-Q nicht unterstützen?
In diesem Abschnitt werden Möglichkeiten beschrieben, eine Verbindung zu einem B-End-Service herzustellen, der Q-in-Q erfordert, selbst wenn die Netzwerkausrüstung, die Ihre Megaport Verbindung terminiert, dies nicht nativ unterstützt.
| Q-in-Q-Alternativen | Methode | Nachteile | ||
|---|---|---|---|---|
| Einzelnes Azure-Peering-VLAN | Sie können den VXC so konfigurieren, dass Megaport die Q-in-Q-Anforderung entfernt, indem eine der B-End-VLAN-IDs für Private Peering oder Microsoft Peering auf das kundenseitige Megaport-VLAN (A-End) umgemappt wird. | Sie können pro VXC nur einen einzelnen Microsoft-Peering-Typ verwenden. | ||
| Den an den Kunden-Port angeschlossenen VXC untaggen | Sie können den VXC als untagged konfigurieren, um das S-Tag automatisch zu entfernen. | Das Untaggen eines VLANs beschränkt den Port auf eine einzelne VXC Verbindung. Die Verwendung dieser Methode bedeutet, dass Ihr Port nur ein einzelnes B-End-Ziel konfigurieren kann, obwohl er alle inneren/C-Tags von diesem Peer als single/dot1q getaggt empfängt. | ||
| Einen Megaport Cloud Router 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 ein zusätzlicher VXC zum MCR. |
Ein VXC, der mit Microsoft ExpressRoute verbunden ist, kann ein oder zwei innere VLAN-Tags enthalten. Dies sind die C-Tags, die in der Microsoft Azure-Konsole für den angegebenen Peering-Typ konfiguriert sind. Beachten Sie, dass Q-in-Q in diesem Szenario erforderlich ist, selbst wenn nur ein einzelnes Microsoft-Edge-Gerät (primär oder sekundär) oder ein Peering-Typ (privat oder Microsoft) verwendet wird. Netzwerkausrüstung, die Q-in-Q unterstützt, kann auf diese inneren Tags zugreifen, indem sie das äußere VLAN-Tag (S-Tag) entfernt. Wenn Ihre Netzwerkausrüstung Q-in-Q nicht unterstützt, kann sie nicht auf die inneren Tags zugreifen.
Hinweis
Es gibt weitere Q-in-Q-Workarounds, z. B. die Verarbeitung auf Kundenseite über mehrere Geräte zum Dekapseln der Q-in-Q-Frames oder die Verwendung von Loopback-Kabeln innerhalb eines einzelnen Geräts, um dies per Kaskadierung über mehrere Ports mit unterschiedlichen VLAN-Konfigurationen für innere und äußere Tags zu steuern. Dies wird jedoch in Produktionsnetzwerken im Allgemeinen nicht empfohlen.
Einzelnes Azure-Peering-VLAN
Für Microsoft Azure ExpressRoute-Verbindungen verwendet Megaport einen Microsoft Service Key (und die zugehörige Auswahl des primären und sekundären Zielendpunkts) und bietet die Möglichkeit, das gekapselte C-Tag für einen angegebenen Azure-Peering-Typ „aufzubrechen“. Sie aktivieren diese Funktion, indem Sie im Bereich Verbindungsdetails einer neuen ExpressRoute-Verbindung nach Auswahl eines primären oder sekundären B-End-Ports die Option Single Azure Peering VLAN konfigurieren aktivieren.
Tipp
Wir empfehlen die Verwendung der Option Single 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 einem einzigen ER-Circuit nutzen – ohne Q-in-Q-fähige Geräte, ohne einen MCR und ohne untagged Port. Beachten Sie, dass Sie mit dieser Option pro VXC nur einen Peering-Typ (privat oder Microsoft) haben können, sodass Sie zwei VXCs benötigen, um beide Peering-Typen zu verwenden.
Durch Aktivieren der Funktion Single Azure VLAN Peering VLAN können Sie ein einzelnes Azure-Peering-VLAN angeben, das mit dem Wert übereinstimmt, den Sie (in einem späteren Schritt) für die ausgewählte Peering-Typ-Konfiguration in der Azure ExpressRoute-Konfiguration (über das Microsoft Azure-Portal oder eine andere Konfigurationsmethode) konfigurieren. Weitere Informationen finden Sie unter Tutorial: Create and modify peering for an ExpressRoute circuit using the Azure portal.
Wenn Sie das Feld Preferred A-End VLAN (Bevorzugtes A-Ende-VLAN) leer lassen, wird bei Auftragserteilung ein zufällig ausgewähltes VLAN für Ihren VXC zugewiesen. Andernfalls geben Sie ein VLAN ein, und es wird eine Validierungsprüfung durchgeführt, um sicherzustellen, dass dieses VLAN verfügbar ist.
Dieses Beispiel zeigt, dass ein Azure-C-Tag-Wert von 200 (für entweder einen Private- oder Microsoft-Peering-Typ auf dem zugehörigen ExpressRoute-Circuit) transparent auf einen einfach getaggten VXC-VLAN-Wert von 3001 gemappt wird. Das heißt, das an die physische Megaport Schnittstelle angeschlossene Kundengerät muss nicht für Q-in-Q konfiguriert werden, da das dot1q-VLAN 3001 dem zugehörigen, Microsoft-seitig ausgerichteten B-End-Edge-Gerät korrekt gekennzeichnet übergeben wird.
In dieser Konfiguration ist es möglich, sowohl den primären als auch den sekundären Microsoft ExpressRoute-Endpunkt auf einem gegebenen ExpressRoute-Circuit zu verwenden, um auf unterschiedliche VLAN-Tags an einem einzelnen kundenseitigen Port zu mappen. Dies ist im Sinne der Azure ExpressRoute Service Level Agreement (SLA) konform. Wir empfehlen jedoch, entweder Port- und Geräte-Diversität an einem einzelnen Standort (zonal) einzusetzen oder die primären/sekundären ExpressRoute-Verbindungen auf zwei Megaport-fähige Standorte aufzuteilen, um sicherzustellen, dass keine Single Point of Failure in der Konfiguration besteht.
Weitere Informationen zur Azure ExpressRoute SLA finden Sie unter SLA for Azure ExpressRoute.
Mit dieser Methode ist es nicht möglich, mehr als einen Peering-Typ über einen der primären oder sekundären, zur ExpressRoute gerichteten VXCs zu verwenden, da diese Tag-Übersetzung pro VXC-Strecke nur einmal erfolgen kann. Weitere Workarounds werden in den folgenden Abschnitten beschrieben; beachten Sie jedoch, dass die Segmentierung von Bandbreite zwischen mehreren Peering-Typen auf einem einzelnen ExpressRoute-Circuit-Paar 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
Die folgenden Abschnitte beschreiben Workarounds, die das Beispiel Microsoft ExpressRoute fortführen. Beachten Sie, dass diese Workarounds nicht auf Azure-Endpunkte beschränkt sind und auch für andere Verbindungen über Megaport verwendet werden können, bei denen das B-End Q-in-Q vorgibt oder erfordert, um mehrere C-Tags/innere VLANs innerhalb eines einzelnen S-Tags/äußeren VXC-VLANs zu transportieren. Das Beispiel Microsoft ExpressRoute dient der Kontinuität des Kundenszenarios.
Konfigurieren Sie den VXC als untagged, um das S-Tag automatisch zu handhaben
Hinweis
Die Verwendung dieser Methode bedeutet, dass der Kunden-Port nur ein einzelnes B-End-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 eines oder beide inneren VLANs (C-Tag/s) für Private Peering, Microsoft Peering oder beide an den Kunden-Port präsentiert.
Derzeit erlaubt dieser Prozess nur einen VXC pro ExpressRoute-Circuit-Verbindung (Auswahl aus primärer oder sekundärer Port-Präsentation), obwohl beide Peering-Typen über diesen VXC unterstützt werden können, da sie dem Kundenport als ein oder zwei dot1q-VLANs (Private, Microsoft Peering oder beide) präsentiert werden.
Wichtig
Der Kundenport erhält die inneren VLAN-Tags wie im Azure-Portal unter dem angegebenen Peering-Typ am A-End-Kundenport definiert. Weitere Informationen finden Sie unter Verbindung zu Microsoft Azure ExpressRoute herstellen.
Hinweis
Jede ExpressRoute-Subscription umfasst zwei Port-Ziele am gewählten Microsoft-Edge-Standort. Um sowohl den primären als auch den sekundären ExpressRoute-Circuit zu erhalten, benötigen Sie in dieser Konfiguration zwei Ports von Megaport. Die Azure VNET-VLAN-Tags sind auf beiden Ports gleich. Megaport kann das VLAN-Tag auf den primären und sekundären Circuits nicht ändern und kann dasselbe VLAN nicht zweimal auf derselben physischen Schnittstelle liefern.
Hinweis
Wenn Sie in der Azure ExpressRoute-Konfiguration nur privates oder öffentliches Peering konfigurieren, steht auf dem konfigurierten VXC nur das VLAN zur Verfügung, das dem ExpressRoute Service Key zugeordnet ist, eins-zu-eins gemappt mit dem Kundenport.
Bereitstellen eines Megaport Cloud Router
Der Megaport Cloud Router (MCR) unterstützt Multi-Cloud- und Multi-Region-Enablement, einschließlich Unterstützung für Q-in-Q, um sich mit mehreren Cloud-Zielen zu verbinden. Die S-Tags, also die äußeren Tags, gehören zum A-End-VLAN, das Ihrem MCR zugeordnet ist, und transportieren Ihre C-Tags transparent. Die S-Tags werden beim Provisionieren Ihres Private und Public Peering zur Azure Cloud im Megaport Portal automatisch konfiguriert. Diese Abbildung zeigt eine Beispielkonfiguration:
Wenn mehrere Azure-VXCs auf einem MCR dasselbe VLAN-100-Tag (privates Peering) und dasselbe VLAN-200-Tag (öffentliches Peering) belegen, verwaltet MCR den Q-in-Q-Tunnel für jeden Azure-VXC, der auf dem MCR terminiert. Jedes Azure-VLAN ist weiterhin eine separate logische Schnittstelle.