Configuration du Q-in-Q
Ce sujet décrit les moyens de connecter votre équipement réseau sur site à un fournisseur de services cloud (CSP) qui utilise Q-in-QLe tunneling 802.1Q (également connu sous le nom de Q-in-Q ou 802.1ad) est une technique utilisée par les fournisseurs de niveau 2 OSI pour les clients. 802.1ad permet d’avoir à la fois une étiquette interne et une étiquette externe, l’étiquette externe (parfois appelée S-tag pour fournisseur de services) pouvant être retirée pour exposer les étiquettes internes (C-tag ou client) qui segmentent les données.
, tel qu’Azure ExpressRoute. De plus, comme certains CSP exigent le Q-in-Q, mais que tous les appareils réseau ne le prennent pas en charge, ou le mélange de balises simples et multiples sur une interface physique unique (“Q-in-Q sélectif”), ce sujet inclut des méthodes pour configurer la gestion de plusieurs balises VLAN de couche sur des appareils réseau sans support natif du Q-in-Q.
Aperçu
Le Q-in-Q, également connu sous le nom de 802.1ad, est un protocole couramment utilisé par les fournisseurs de services réseau (NSP) pour fournir plus de flexibilité de couche 2. Le Q-in-Q permet d’insérer plusieurs balises VLAN dans une seule trame Ethernet. Empiler plusieurs balises VLAN dans une trame permet l’isolation des domaines de routage, car les balises supplémentaires identifient et séparent le trafic client. En utilisant une balise VLAN différente pour chaque client, le trafic est identifié dans la trame et est transféré à travers le réseau du fournisseur de services.
Important
Pour différencier les balises VLAN sous la norme 802.1ad, l’intérieur utilise couramment EtherType 0x8100 et l’extérieur utilise 0x88a8. La configuration par défaut pour le Q-in-Q de la plupart des fournisseurs réseau est pour les deux EtherTypes intérieurs et extérieurs d’être 0x8100. La spécification Megaport des trames à double balisage est pour les balises intérieures et extérieures d’être 0x8100.
Avec le Q-in-Q, à mesure qu’un paquet se déplace d’un réseau de NSP ou de transporteur vers un VLAN de fournisseur de services cloud (ou autre), des balises VLAN internes (C-Tags) qui identifient le trafic client sont insérées à l’intérieur des balises VLAN externes (S-Tags) fournies par le fournisseur de services. Le S-Tag fournit un seul VLAN qui encapsule plusieurs VLANs à l’intérieur. Dans cette configuration, un seul VXC peut transporter les multiples balises VLAN entre les deux points de terminaison réseau.
Pour plus d’informations sur le Q-in-Q, voir Connexion d’un VXC et le billet de blog Megaport Q & A pour le Q-in-Q: Partie 1. Pour plus d’informations sur la configuration du Q-in-Q pour Azure, voir le billet de blog Megaport Q & A pour le Q-in-Q: Partie 2.
Comprendre le Q-in-Q avec les Megaport VXCs
Un Virtual Cross Connect (VXC) est un circuit point à point de couche 2 entre deux points de terminaison qui est mappé avec un ID VLAN à chaque extrémité, avec des balises VLAN A et B de fin pouvant être mappées de manière indépendante à travers le réseau Megaport.
Cette image montre un Azure ExpressRoute avec peering privé et Microsoft Peering activés. Un VXC connecte un client aux bords Microsoft sur VLAN 1000 (S-Tag). Le client prend en charge le Q-in-Q. Le peering privé fonctionne sur VLAN 100 (C-Tag) et le Microsoft Peering fonctionne sur VLAN 200 (C-Tag) pour établir des connexions de couche 3 et un peering BGP avec Azure.
Que faire si mes routeurs ou commutateurs ne supportent pas le Q-in-Q?
Cette section décrit les moyens de se connecter à un service B-End nécessitant le Q-in-Q même lorsque l’équipement réseau terminant votre connexion Megaport ne le supporte pas nativement.
| Alternatives au Q-in-Q | Méthode | Inconvénients | ||
|---|---|---|---|---|
| Unique VLAN de peering Azure | Vous pouvez configurer le VXC afin que Megaport supprime l’exigence de Q-in-Q en remappant l’un des IDs VLAN B-End pour le Peering Privé ou Microsoft Peering vers le VLAN Megaport côté client (A-End). | Vous ne pouvez utiliser qu’un seul type de peering Microsoft par VXC. | ||
| Retirer la balise du VXC attaché au Port client | Vous pouvez configurer le VXC comme non étiqueté pour supprimer automatiquement le S-Tag. | Supprimer l’étiquette d’un VLAN limite le Port à une seule connexion VXC. Employer cette méthode signifie que votre Port ne pourra configurer qu’une seule cible B-End, bien qu’il recevra toutes les balises intérieures/C-Tags de ce pair en tant que balisé unique/dot1q. | ||
| Déployer un Megaport Cloud Router | Vous pouvez déployer un Megaport Cloud Router (MCR) pour gérer automatiquement les exigences du Q-in-Q pour l’un ou les deux types de peering. | Coût supplémentaire du MCR et VXC supplémentaire vers MCR. |
Un VXC se connectant à Microsoft ExpressRoute peut contenir une ou deux balises VLAN internes. Ce sont les tags C configurés dans la console Microsoft Azure pour le type de peering spécifié. Notez que le Q-in-Q est une exigence dans ce scénario, même si un seul dispositif périphérique Microsoft (primaire ou secondaire) ou un type de peering (privé ou Microsoft) est employé. L’équipement réseau qui supporte le Q-in-Q est capable d’accéder à ces balises internes en retirant la balise VLAN externe (S-Tag). Si votre équipement réseau ne supporte pas le Q-in-Q, il ne peut pas accéder aux balises internes.
Remarque
D’autres solutions de contournement du Q-in-Q existent, telles que la gestion côté client via plusieurs appareils pour désencapsuler les trames Q-in-Q, ou l’utilisation de câbles de bouclage dans un seul appareil pour gérer cela via des cascades à travers plusieurs ports avec différentes configurations VLAN pour les balises internes et externes. Cependant, cela est généralement déconseillé dans les réseaux de production.
Unique VLAN de peering Azure
Pour les connexions Microsoft Azure ExpressRoute, Megaport utilise une clé de service Microsoft (et une sélection de cibles primaires et secondaires associées) et fournit la possibilité de décapsuler le C-Tag encapsulé pour un type de peering Azure spécifié. Vous activez cette fonctionnalité en activant le Configure Single Azure Peering VLAN dans le panneau Détails de la connexion d’une nouvelle connexion ExpressRoute, après avoir sélectionné un port cible primaire ou secondaire B-End.
Conseil
Nous recommandons d’utiliser l’option Unique VLAN de peering Azure. Cette option offre une fonctionnalité complète et la mise en œuvre la plus simple. Avec l’Unique VLAN Azure, vous pouvez utiliser à la fois le peering privé ou Microsoft avec un seul circuit ER sans avoir besoin d’un équipement capable de Q-in-Q, d’un MCR, ou d’un port non étiqueté. Notez que vous pouvez avoir un seul type de peering (privé ou Microsoft) par VXC avec cette option, vous aurez donc besoin de deux VXCs pour utiliser les deux types de peering.
En activant la fonctionnalité Unique VLAN de peering Azure, vous pouvez spécifier un unique VLAN de peering Azure qui correspondra à la valeur que vous configurerez (dans une étape ultérieure) pour la configuration du type de Peering pour la configuration Azure ExpressRoute (via le portail Microsoft Azure ou autre méthode de configuration). Pour plus d’informations, voir Tutoriel: Créer et modifier le peering pour un circuit ExpressRoute en utilisant le portail Azure.
Si vous laissez le champ VLAN A-End Préféré vide, un VLAN choisi aléatoirement sera attribué pour votre VXC lorsque vous passerez commande, sinon, entrez un VLAN et une vérification de validation sera effectuée pour s’assurer que ce VLAN est disponible.
Cet exemple montre qu’une valeur de C-tag Azure de 200 (pour soit un type de peering Privé ou Microsoft sur le circuit ExpressRoute associé) est mappée de manière transparente à une valeur VLAN VXC à balisage unique de 3001. C’est-à-dire que l’appareil client connecté à l’interface physique Megaport n’a pas besoin d’être configuré pour des réglages Q-in-Q, car le VLAN dot1q 3001 sera transféré à l’appareil périphérique côté Microsoft B-End correctement étiqueté.
Dans cette configuration, il est possible d’utiliser à la fois les points d’extrémité primaires et secondaires de Microsoft ExpressRoute sur un circuit ExpressRoute donné pour mapper à différentes balises VLAN sur un seul port côté client. Cela est conforme pour les objectifs de l’Accord de Niveau de Service (SLA) Azure ExpressRoute. Cependant, nous recommandons de recourir soit à la diversité de port et d’appareil (zonal) sur un seul site, soit de répartir les connexions primaires/secondaires ExpressRoute sur deux emplacements activés Megaport pour s’assurer qu’aucun point de défaillance unique n’existe avec la configuration.
Pour plus d’informations sur le SLA Azure ExpressRoute, voir Service Level Agreements (SLA) for Online Services.
Avec cette méthode, il n’est pas possible d’utiliser plus d’un type de peering sur l’un ou l’autre des VXCs face à l’ExpressRoute primaire ou secondaire, car cette traduction de balise ne peut se produire qu’une fois par circuit VXC. D’autres solutions de contournement sont détaillées dans les sections suivantes, toutefois, notez que la segmentation de bande passante entre plusieurs types de peering sur une seule paire de circuits ExpressRoute n’est actuellement pas prise en charge par Microsoft. Dans la plupart des cas, il est préférable de déployer deux paires ExpressRoute pour atteindre cet objectif de configuration.
Remarque
Les sections suivantes décrivent des solutions de contournement qui continuent avec l’exemple Microsoft ExpressRoute. Notez que ces solutions de contournement ne sont pas uniques aux points de terminaison Azure et peuvent également être utilisées pour d’autres connexions à travers Megaport où le B-End pourrait spécifier ou exiger le Q-in-Q pour transporter plusieurs C-Tag/VLAN internes au sein d’un seul S-Tag/VLAN externe VXC. L’exemple Microsoft ExpressRoute est utilisé pour la continuité du scénario client.
Configurez le VXC comme non étiqueté pour gérer automatiquement le S-Tag
Remarque
Employer cette méthode signifie que le Port client ne pourra configurer qu’une seule cible B-End, bien qu’il recevra toutes les balises intérieures/C-Tags de ce pair en tant que VLAN balisé unique/dot1q.
Vous pouvez configurer le VXC de telle sorte que Megaport retire le VLAN externe (S-Tag) et présente une ou les deux balises VLAN internes (C-Tag/s) pour le Peering Privé, le Microsoft Peering, ou les deux, au Port client. Actuellement, ce processus ne permet qu’un seul VXC par Connexion de Circuit ExpressRoute (en sélectionnant entre la présentation de port primaire ou secondaire), bien que les deux types de peering puissent être pris en charge à travers ce VXC car ils seront présentés au port client comme un ou deux VLANs dot1q (Privé, Microsoft Peering, ou les deux).
Important
Le port client recevra les balises VLAN internes telles que définies sur le portail Azure sous le type de peering spécifié au port client A-End. Pour plus d’informations, voir Connexion à Microsoft Azure ExpressRoute.
Remarque
Chaque abonnement ExpressRoute inclut deux cibles de port à l’emplacement Microsoft edge choisi. Pour prendre livraison des deux circuits ExpressRoute primaires et secondaires, vous aurez besoin de deux ports de Megaport dans cette configuration. Les balises VLAN Azure VNET sont les mêmes sur les deux ports. Megaport ne peut pas changer la balise VLAN sur les circuits primaires et secondaires et il ne peut pas livrer la même balise VLAN deux fois sur la même interface physique.
Remarque
Si vous configurez uniquement le peering privé ou public sur la configuration Azure ExpressRoute, seul le VLAN associé à la clé de service ExpressRoute sera disponible sur le VXC configuré, mappé un-à-un avec le port client.
Déployez un Megaport Cloud Router
Le Megaport Cloud Router (MCR) supporte le multicloud, l’activation multi-région, y compris le support pour le Q-in-Q pour se connecter à de multiples destinations cloud. Les S-Tags, ou balises externes, appartiennent au VLAN A-End associé à votre MCR et transporteront de manière transparente vos C-Tags. Les S-Tags sont automatiquement configurés lors du provisioning de votre peering privé et public vers Azure Cloud dans le Megaport Portal. Cette image montre un exemple de configuration:
Lorsque plusieurs VXCs Azure sur un MCR utilisent la même balise VLAN 100 (peering privé) et la même balise VLAN 200 (peering public), le MCR gère le tunnel Q-in-Q pour chaque VXC Azure qui se termine sur le MCR. Chaque VLAN Azure est toujours une interface logique distincte.