Questions-réponses sur Q-in-Q : deuxième partie

Découvrez comment Megaport simplifie la connectivité directe avec Microsoft Azure ExpressRoute via VLAN Q-in-Q. Explorez les meilleures pratiques de configuration, les options de peering et les avantages pour des connexions privées, fiables et optimisées pour vos environnements multicloud.

Suite à notre dernier article (http://www.megaport.com/blog/q-in-q-questions-answered-part-1/) dans lequel nous avons présenté le concept des balises VLAN empilées (Q-in-Q), nous nous concentrerons dans cette deuxième partie sur Microsoft Azure et l’offre de produits ExpressRoute fournissant une connectivité directe dans l’environnement de cloud public Azure. Si vous souhaitez implémenter Microsoft ExpressRoute for Azure et que vous envisagez de choisir Megaport comme fournisseur de solutions de connectivité, cet article vous fournira des exemples réels d’implémentations client allant du développement et des tests à petite échelle à des charges de travail de production à haute disponibilité.

Q : Comment provisionner une connexion ExpressRoute via Megaport ?

Le diagramme suivant montre l’ensemble du processus, résumé en quelques étapes simples:

Q : Comment demander/générer une clé Microsoft Azure ExpressRoute (clé de service) ?

Les dernières évolutions à ce niveau concernaient la demande de clé de service via le portail Azure Resource Manager (ARM). Regardez ici notre vidéo indiquant les étapes à suivre pour demander la clé de service. Si vous souhaitez utiliser PowerShell pour créer des scripts de certaines fonctions ou les automatiser, suivez la documentation Azure sur https://docs.microsoft.com/fr-fr/azure/expressroute/expressroute-howto-circuit-arm ou regardez notre vidéo sur le processus de configuration de PowerShell (Classic). Grâce à des changements récents, il est possible de connecter les VNets ASM (classic) et ARM à un seul circuit ER – voir les étapes dans le guide https://docs.microsoft.com/fr-fr/azure/expressroute/expressroute-howto-move-arm sous la section « Pour activer l’accès du circuit ExpressRoute pour les deux modèles de déploiement ».

Q : Puis-je utiliser un seul circuit ExpressRoute avec plusieurs abonnements ?

Oui, vous pouvez utiliser un seul circuit ExpressRoute fourni via Megaport avec jusqu’à dix abonnements. Consultez https://docs.microsoft.com/fr-fr/azure/expressroute/expressroute-howto-linkvnet-arm pour en savoir plus sur le partage efficace des circuits ER.

Q : Puis-je utiliser un seul circuit ExpressRoute avec plusieurs VNets ?

La limite par défaut des VNets pour un circuit ExpressRoute créé en tant que type « Standard » est de dix. Toutefois, si vous utilisez l’option SKU Premium, cela dépendra de la taille de circuit demandée (min. 20, voir https://docs.microsoft.com/fr-fr/azure/azure-resource-manager/management/azure-subscription-service-limits#networking-limits). Cependant, l’option récente du peering VNet vous permet de connecter deux réseaux virtuels ou plus dans la même région via le réseau principal Azure. Une fois appairés, les deux réseaux virtuels apparaîtront en tant que réseau virtuel unique à diverses fins de connectivité. Voir https://docs.microsoft.com/fr-fr/azure/virtual-network/tutorial-connect-virtual-networks-portal pour en savoir plus sur cette configuration. C’est une fonctionnalité très utile car elle permet de contourner la limite VNet par défaut imposée aux circuits ExpressRoute sans avoir à passer au niveau Premium.

Q : Comment fonctionne Microsoft Azure ExpressRoute avec les services VXC de Megaport ?

Les connexions Azure via Megaport sont fournies via un VLAN Q-in-Q vers le routeur Microsoft primaire ou secondaire dans une région Azure donnée. Dans la balise externe unique (S-tag) définie via le portail Megaport, jusqu’à trois balises internes (C-tags) sont définies sur le portail Azure : le peering privé Azure, le peering public Azure et le peering Microsoft qui achemine le trafic Office 365. Il revient à Microsoft d’autoriser ou non la disponibilité de ce troisième type de peering – voir https://docs.microsoft.com/fr-fr/microsoft-365/enterprise/azure-expressroute?redirectSourcePath=%252fen-us%252farticle%252fAzure-ExpressRoute-for-Office-365-6d2534a2-c19c-4a99-be5e-33a0cee5d3bd&view=o365-worldwide pour obtenir plus de détails. Megaport fournit une connectivité de couche 2 point à point entre Azure ExpressRoute et un client Megaport (une interface Ethernet/un port fourni par Megaport). Les sessions BGP de couche 3 sont établies directement entre Azure et les clients Megaport.

Q : Le « VLAN A END » est-il de mon côté ou du côté Microsoft ?

Le VLAN « A END » que vous devez spécifier sur le portail Megaport est de votre côté, et non du côté Microsoft – il s’agit là du VLAN « B END » qui est uniquement pertinent entre Megaport et Microsoft à l’emplacement source du trafic (routeur primaire/secondaire). Cet ID VLAN « A END » est représenté par la « balise externe » sur le diagramme ci-dessus.

Q : Dois-je utiliser le même ID VLAN pour les balises VLAN internes ?

En général, il est recommandé d’utiliser différents ID VLAN pour les balises internes (ou client). Les balises VLAN internes sont demandées soit via le portail Azure Resource Manager, soit via PowerShell une fois que la demande ExpressRoute a été provisionnée. Par exemple, vous pouvez utiliser le VLAN 2000 (« balise externe ») en tant que VLAN Megaport et configurer 20/30/40 pour les VLAN publics/privés/Microsoft sur le portail Azure. Chaque trame est balisée deux fois pour vous avec la « balise interne » et la « balise externe », c’est-à-dire Q-in-Q, et votre équipement réseau doit rompre les « balises internes » pour supprimer la balise 2000 (« balise externe »). Il est possible de demander à Megaport de supprimer la balise externe en sélectionnant « Suppr. la balise pour ce VLAN » lors de la création de la première VXC sur votre port. Toutefois, l’utilisation de ce port sera alors limitée à cette seule VXC. Ce n’est donc pas recommandé en tant que solution à long terme car il sera alors plus difficile d’ajouter d’autres services pour votre port (tels qu’une VXC Azure secondaire, des VXC privées, une connexion IX ou autre).

Q : Dois-je configurer les circuits primaire et secondaire sur l’utilisation d’ExpressRoute ?

Sur le plan technique, vous n’avez pas besoin de configurer le circuit secondaire. Remarque importante : sur le portail Azure, vous devrez définir l’adressage IP pour les présentations de routeurs primaire et secondaire, et cela doit correspondre à la terminaison de circuit que vous sélectionnez en saisissant votre clé de service sur le portail Megaport. Microsoft exige que les circuits primaire et secondaire soient tous deux connectés avec une session BGP en direct pour être couverts par le SLA ExpressRoute (voir https://azure.microsoft.com/fr-fr/support/legal/sla/expressroute/v1_0/).

Q : Comment définir la configuration de peering BGP depuis mon routeur vers un routeur ExpressRoute ?

Microsoft fournit des exemples de configuration pour les routeurs Cisco et Juniper. Veuillez consulter le site suivant : https://docs.microsoft.com/fr-fr/azure/expressroute/expressroute-config-samples-routing.

Q : Je souhaite configurer un peering public Azure. Où puis-je obtenir des adresses IP routables publiquement et un numéro de système autonome (ASN) ?

Si votre réseau est situé dans la région Asie-Pacifique, contactez l’Asia Pacific Network Information Centre (APNIC) – https://www.apnic.net/get-ip et le support technique APNIC : https://www.apnic.net/get-ip/helpdesk. Si votre réseau est situé dans la région Amérique du Nord, contactez l’American Registry for Internet Numbers (ARIN) – https://www.arin.net/resources/request.html. Si votre réseau est situé dans la région Europe, contactez le RIPE Network Coordination Centre (RIPE NCC) – https://www.ripe.net/manage-ips-and-asns/ipv4/request-an-ipv4-22-from-the-last-8 et https://www.ripe.net/manage-ips-and-asns/as-numbers.

Q : Comment configurer un circuit ExpressRoute très diversifié en utilisant les VXC Megaport ?

Vous trouverez ci-dessous un exemple de configuration ExpressRoute très diversifiée utilisant les trois types de peering présentés sur deux Megaports physiques :

Pour la configuration du scénario ci-dessus, voir ci-dessous (remarque : les exemples de configuration sont présentés à titre indicatif et ne peuvent pas prendre en compte les facteurs spécifiques à votre réseau) :

Pile de commutateurs Cisco 3850 – IOS XE

vlan 45
name Megaport_Azure-Pri
vlan 55
name Megaport_Azure-Sec
!
interface TenGigabitEthernet1/0/24
Description Megaport Primary
switchport mode trunk
no cdp enable
!
interface TenGigabitEthernet2/0/24
description Megaport Secondary
switchport mode trunk
no cdp enable
!
interface Port-channel101
switchport access vlan 45
switchport trunk native vlan 45
switchport trunk allowed vlan 45
switchport mode dot1q-tunnel
!
interface Port-channel102
switchport access vlan 55
switchport trunk native vlan 55
switchport trunk allowed vlan 55
switchport mode dot1q-tunnel
!

Cisco Nexus 9000 – Commutateur d’agrégation #1

vlan 100
name AzurePri-Link1
vlan 101
name AzurePub-Link1
vlan 102
name MSFT-Link1
!
interface port-channel101
switchport mode trunk
switchport trunk native vlan 45 
!
interface Vlan100
no shutdown
vrf member AzurePriv01 ip address 10.x.x.x/30
!
interface Vlan101
no shutdown
vrf member AzurePublic01 ip address y.y.y.v/30
!
interface Vlan102
no shutdown
vrf member MSFT01 ip address y.y.y.w/30
!
interface port-channel1
switchport mode trunk
switchport trunk allowed vlan {lower-upper}
!

Cisco Nexus 9000 – Commutateur d’agrégation #2

vlan 100
name AzurePri-Link2
vlan 101
name AzurePub-Link2
vlan 102
name MSFT-Link2
!
interface port-channel102
switchport mode trunk
switchport trunk native vlan 55 
!
interface Vlan100
no shutdown
vrf member AzurePriv02 ip address 10.x.x.y/30
!
interface Vlan101
no shutdown
vrf member AzurePublic02 ip address y.y.y.x/30
!
interface Vlan102
no shutdown
vrf member MSFT02 ip address y.y.y.y/30
!
interface port-channel1
switchport mode trunk
switchport trunk allowed vlan {lower-upper}
!