Configuration de Q-in-Q
Cette rubrique décrit les manières de connecter votre équipement réseau sur site à un fournisseur de services Cloud (CSP) qui utilise Q-in-Q, comme Azure ExpressRoute. En outre, étant donné que certains CSP exigent Q-in-Q, mais que tous les périphériques réseau ne le prennent pas en charge, ou le mélange de balises uniques et multiples sur une interface physique unique (« Q-in-Q sélectif »), cette rubrique comprend des moyens de configurer la gestion des balises VLAN à couches multiples sur les périphériques réseau sans prise en charge native de Q-in-Q.
Aperçu
Q-in-Q, également connu sous le nom de 802.1ad, est un protocole couramment utilisé par les fournisseurs de services de réseau (NSP) pour offrir plus de flexibilité de couche 2. Q-in-Q permet d’insérer plusieurs balises VLAN dans une seule trame Ethernet. L’empilement de plusieurs balises VLAN dans une trame permet d’isoler les domaines de routage, car les balises supplémentaires identifient et séparent le trafic des clients. En utilisant une balise VLAN différente pour chaque client, le trafic est identifié dans la trame et est transféré de manière transparente dans le réseau du fournisseur de services.
Important
Afin de différencier les balises selon la norme 802.1ad, la balise interne utilise couramment EtherType 0x8100 et la balise externe 0x88a8. La configuration par défaut pour la plupart des fournisseurs de réseaux Q-in-Q est que les EtherTypes internes et externes sont 0x8100. La spécification Megaport des trames à double balisage est de 0x8100 pour les balises internes et externes.
Avec Q-in-Q, lorsqu’un paquet voyage d’un NSP ou d’un réseau de fournisseur vers le VLAN d’un fournisseur de services Cloud (ou autre), des balises VLAN internes (C-Tags) qui identifient le trafic du 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 VLAN en son sein. Dans cette configuration, une seule VXC peut transporter plusieurs balises VLAN entre les deux points de terminaison du réseau.
Pour plus de détails sur Q-in-Q, voir Connexion d’une VXC et le post de blog MegaportQ&uestions-réponses sur Q-in-Q : Partie 1. Pour plus de détails sur la configuration de Q-in-Q pour Azure, voir le post de blog MegaportQ&uestions-réponses sur Q-in-Q : Partie 2.
Comprendre Q-in-Q avec les VXC Megaport
Une VXC (connexion transversale virtuelle) est un circuit de couche 2 point à point entre deux points de terminaison qui est mis en correspondance avec un ID VLAN à chaque extrémité. Éventuellement, avec des balises VLAN A et B-End indépendamment mises en correspondance à travers le réseau Megaport.
Cette illustration montre un Azure ExpressRoute avec un peering privé et un peering Microsoft activés. Une VXC connecte une périphérie client à une périphérie Microsoft sur un VLAN 1000 (S-Tag). La périphérie client prend en charge Q-in-Q. Le peering privé fonctionne sur le VLAN 100 (C-Tag) et le peering Microsoft fonctionne sur le 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 prennent pas en charge Q-in-Q ?
Cette section décrit les moyens de se connecter à un service B-End qui nécessite Q-in-Q même si l’équipement réseau qui termine votre connexion Megaport ne le prend pas en charge de façon native.
| Alternatives à la tunnelisation Q-in-Q | Méthode | Inconvénients | ||
|---|---|---|---|---|
| Single Azure peering VLAN (VLAN de peering Azure unique) | Vous pouvez configurer la VXC de sorte que Megaport supprime l’exigence Q-in-Q en remappant l’un des ID de VLAN de B-End pour le peering privé ou le peering Microsoft au VLAN client côté Megaport (A-End). | Vous pouvez utiliser un seul type de peering Microsoft par VXC. | ||
| Untag the VXC attached to the customer Port (Supprimer la balise de la VXC rattachée au port client) | Vous pouvez configurer la VXC sans balise pour supprimer automatiquement la S-Tag (balise S). | La suppression du balisage d’un VLAN limite le port à une seule connexion VXC. L’utilisation de cette méthode signifie que votre port ne pourra configurer qu’une seule cible B-End, mais qu’il recevra toutes les C-Tags (balises C)/balises internes de ce pair comme balisage unique/dot1q. | ||
| Deploy a Megaport Cloud Router (Déployer un Megaport Cloud Router) | Vous pouvez déployer un Megaport Cloud Router (MCR) pour gérer automatiquement les exigences Q-in-Q pour un ou les deux types de peering. | Coût supplémentaire du MCR et de la VXC supplémentaire au MCR. |
Une VXC se connectant à Microsoft ExpressRoute peut contenir une ou deux balises VLAN internes. Il s’agit des balises C configurées dans la console Microsoft Azure pour le type de peering spécifié. Notez que Q-in-Q est une exigence dans ce scénario, même si un seul périphérique Microsoft (primaire ou secondaire) ou un seul type de peering (privé ou Microsoft) est utilisé. Les équipements réseau qui prennent en charge Q-in-Q peuvent accéder à ces balises internes en supprimant la balise VLAN externe (S-Tag). Si votre équipement réseau ne prend pas en charge Q-in-Q, il ne peut pas accéder aux balises internes.
Remarque
Il existe d’autres solutions de contournement de Q-in-Q, comme le traitement côté client via plusieurs périphériques pour désencapsuler les trames Q-in-Q, ou l’utilisation de câbles de bouclage dans un seul périphérique pour gérer cela via une mise en cascade à travers plusieurs ports avec différentes configurations VLAN pour les balises intérieures et extérieures. Toutefois, cette méthode n’est généralement pas recommandée dans les réseaux de production.
VLAN de peering Azure unique
Pour les connexions Microsoft Azure ExpressRoute, Megaport utilise une clé de service Microsoft (et la sélection associée de points de terminaison cibles primaires et secondaires) et offre la possibilité de rompre le C-Tag (balise C) encapsulé pour un type de peering Azure spécifié. Vous activez cette fonctionnalité en définissant l’option Configure single Azure peering VLAN (Configurer le VLAN de peering Azure unique) dans le volet Connection Details (Détails de la connexion) d’une nouvelle connexion ExpressRoute, après avoir sélectionné un port B-End cible primaire ou secondaire.
Conseil
Nous recommandons d’utiliser l’option Single Azure Peering VLAN (VLAN de peering Azure unique). Cette option fournit une fonctionnalité complète et l’implémentation la plus simple. Avec le VLAN Azure unique, vous pouvez utiliser le peering privé ou Microsoft avec un seul circuit ER sans avoir besoin d’un équipement compatible avec Q-in-Q, d’un MCR ou d’un port non balisé. Notez que vous ne pouvez avoir qu’un seul type de peering (privé ou Microsoft) par VXC avec cette option, vous avez donc besoin de deux VXC pour utiliser les deux types de peering.
En activant la fonctionnalité VLAN de peering Azure unique, vous pouvez spécifier un VLAN de peering Azure unique qui correspondra à la valeur que vous définissez (dans une étape ultérieure) pour le type de peering sélectionné pour la configuration d’Azure ExpressRoute (via le portail Microsoft Azure ou une autre méthode de configuration). Pour plus de détails, voir Tutoriel : Créer et modifier le peering d’un circuit ExpressRoute à l’aide du portail Azure.
Si vous laissez le champ Preferred A-End VLAN (VLAN A-End préféré) vide, un VLAN choisi au hasard sera attribué à votre VXC lorsque vous passerez la commande. Sinon, entrez un VLAN et un contrôle de validation sera effectué pour vérifier que ce VLAN est disponible.
Cet exemple montre qu’une valeur C-tag Azure de 200 (pour un type de peering privé ou Microsoft sur le circuit ExpressRoute associé) est mappée de manière transparente à une valeur VLAN de VXC à balise unique de 3001. En d’autres termes, le périphérique du client relié à l’interface Megaport physique n’a pas besoin d’être configuré pour des paramètres Q-in-Q, car le VLAN dot1q 3001 sera conféré au périphérique de périphérie B-End associé, côté Microsoft, comme correctement libellé.
Dans cette configuration, il est possible d’utiliser des points de terminaison primaires et secondaires de Microsoft ExpressRoute sur un circuit ExpressRoute donné pour établir une correspondance avec différentes balises VLAN sur un seul port côté client. Ceci est conforme aux fins de l’accord de niveau de service (SLA) d’Azure ExpressRoute. Toutefois, nous vous recommandons d’utiliser la diversité de port et de périphérique (zonal) sur un seul site, ou de répartir les connexions ExpressRoute primaires/secondaires sur deux sites équipés de Megaport afin de garantir l’absence de point de défaillance unique dans la configuration.
Pour plus de détails sur l’accord de niveau de service (SLA) d’Azure ExpressRoute, voir SLA pour Azure ExpressRoute.
Avec cette méthode, il n’est pas possible d’utiliser plus d’un type d’échange de trafic sur l’une ou l’autre des VXC primaires ou secondaires côté ExpressRoute, car cette traduction de balises ne peut se produire qu’une seule fois par chemin de circuit VXC. D’autres solutions de contournement sont détaillées dans les sections suivantes. Toutefois, notez que la segmentation de la bande passante entre plusieurs types de peering sur une seule paire de circuits ExpressRoute n’est pas actuellement 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 les solutions de contournement qui poursuivent l’exemple de Microsoft ExpressRoute. Notez que ces solutions de contournement ne sont pas propres aux points de terminaison Azure et peuvent également être utilisées pour d’autres connexions sur Megaport où le B-End peut spécifier ou exiger que Q-in-Q transporte plusieurs VLAN C-Tag/internes dans un seul VLAN de VXC S-Tag/externe. L’exemple Microsoft ExpressRoute est utilisé pour la continuité du scénario client.
Configurer la VXC comme non balisée pour gérer automatiquement le S-Tag
Remarque
En utilisant cette méthode, le Megaport du client ne pourra configurer qu’une seule cible B-End, mais il recevra toutes les balises inner/C de ce pair en tant que balises single/dot1q.
Vous pouvez configurer la VXC de sorte que le Megaport supprime le VLAN extérieur (S-Tag) et présente l’un ou les deux VLAN intérieurs (C-Tag/s) pour le Private Peering, le Microsoft Peering, ou les deux, au Megaport du client.
Actuellement, ce processus ne permet qu’un seul VXC par connexion de circuit ExpressRoute (en choisissant la présentation par port primaire ou secondaire), bien que les deux types de peering puissent être pris en charge par ce VXC car ils seront présentés au port du client comme un ou deux VLAN dot1q (privé, peering Microsoft, 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 niveau du port client A-End. Pour plus de détails, consultez Connexion à Microsoft Azure ExpressRoute.
Remarque
Chaque abonnement ExpressRoute comprend deux cibles de ports à l’emplacement de périphérie choisi par Microsoft. Pour prendre en charge les circuits ExpressRoute primaire et secondaire, vous aurez besoin de deux ports Megaport dans cette configuration. Les balises VLAN Azure VNET sont les mêmes sur les deux ports. Megaport ne peut pas modifier la balise VLAN sur les circuits primaires et secondaires et il ne peut pas délivrer le même VLAN deux fois sur la même interface physique.
Remarque
Si vous ne configurez que le peering privé ou public sur la configuration Azure ExpressRoute, seul le VLAN associé à la clé de service ExpressRoute sera disponible sur la VXC configurée, mappée un à un avec le port client.
Déployer un MCR (Megaport Cloud Router)
Le Megaport Cloud Router (MCR) prend en charge l’activation multi-cloud et multi-région, y compris Q-in-Q pour se connecter à plusieurs 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ées lors du provisionnement de votre peering privé et public vers Azure Cloud dans le Portail Megaport. Cette illustration montre un exemple de configuration :
Lorsque plusieurs VXC Azure sur un MCR remplissent 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 reste une interface logique distincte.