FAQ sur Virtual WAN

Article
04/02/2024

Azure Virtual WAN est-il en disponibilité générale ?

Oui, Azure Virtual WAN est en disponibilité générale. Toutefois, le service Virtual WAN est constitué de plusieurs fonctionnalités et scénarios. Il existe des fonctionnalités ou scénarii dans le service Virtual WAN pour lequel Microsoft applique la balise Préversion. Dans ce cas, la fonctionnalité spécifique, ou le scénario lui-même, sont en préversion. Si vous n’utilisez pas de fonctionnalité d’aperçu spécifique, la prise en charge standard en disponibilité générale s’applique. Pour plus d’informations sur la prise en charge de la préversion, consultez Avenant aux conditions d’utilisation pour les préversions de Microsoft Azure.

Quels sont les emplacements et les régions disponibles ?

Pour plus d’informations, consultez Emplacements et régions disponibles.

L’utilisateur doit-il disposer d’une architecture hub-and-spoke avec des appareils SD-WAN/VPN pour utiliser Azure Virtual WAN ?

Virtual WAN propose de nombreuses fonctionnalités regroupées dans un seul écran, notamment : connectivité VPN site/site à site, connectivité utilisateur/P2S, connectivité ExpressRoute, connectivité Réseau virtuel, interconnectivité VPN ExpressRoute, connectivité transitive de réseau virtuel à réseau virtuel, routage centralisé, sécurité avec le Pare-feu Azure et le gestionnaire de pare-feu, supervision, chiffrement ExpressRoute, etc. Tous ces cas d’usage ne doivent pas nécessairement être réunis pour commencer à utiliser Azure Virtual WAN. Vous pouvez commencer avec un seul cas d’usage.

Virtual WAN repose sur une architecture hub-and-spoke avec des fonctionnalités de mise à l’échelle et de performances intégrées. Les branches (appareils VPN/SD-WAN), les utilisateurs (clients Azure VPN, openVPN ou IKEv2), les circuits ExpressRoute et les réseaux virtuels sont les spokes (« rayons ») du ou des hubs (« moyeux ») virtuels. Tous les hubs sont connectés selon un maillage complet dans un réseau étendu virtuel standard, ce qui permet à l’utilisateur d’utiliser facilement le réseau principal Microsoft pour se connecter à n’importe quel spoke. Pour l’architecture hub-and-spoke avec des appareils SD-WAN/VPN, les utilisateurs peuvent soit la configurer manuellement dans le portail Azure Virtual WAN, soit utiliser le Virtual WAN Partner CPE (SD-WAN/VPN) pour configurer la connectivité à Azure.

Les partenaires Virtual WAN assurent l’automatisation de la connectivité, c’est-à-dire la capacité d’exporter les informations sur l’appareil dans Azure, de télécharger la configuration Azure et d’établir la connectivité avec le hub Azure Virtual WAN. Pour la connectivité VPN point à site/utilisateur, nous prenons en charge le client Azure VPN, le client OpenVPN ou le client IKEv2.

Pouvez-vous désactiver des hubs entièrement maillés dans un réseau Virtual WAN ?

Il existe deux types de réseaux Virtual WAN : De base et Standard. Dans le réseau WAN virtuel de base, les hubs ne sont pas maillés. Dans un réseau Virtual WAN standard, les hubs sont maillés et automatiquement connectés lorsque le WAN virtuel est configuré pour la première fois. L’utilisateur n’a besoin d’effectuer aucune action spécifique. L’utilisateur n’a pas non plus à désactiver ou activer la fonctionnalité pour obtenir des hubs maillés. Le réseau Virtual WAN vous offre de nombreuses options de routage pour diriger le trafic entre n’importe quels spokes (VNet, VPN ou ExpressRoute). Il assure la facilité d’utilisation des hubs entièrement maillés, ainsi que la flexibilité du routage du trafic selon vos besoins.

Comment les zones de disponibilité et la résilience sont-elles gérées dans Virtual WAN ?

Virtual WAN est une collection de hubs et de services mis à votre disposition dans le hub. L’utilisateur peut avoir autant de WAN virtuels qu’il en a besoin. Dans un hub Virtual WAN, il existe plusieurs services tels que VPN, ExpressRoute, etc. Chacun de ces services est automatiquement déployé dans les zones de disponibilité (hormis Pare-feu Azure) si la région prend en charge les zones de disponibilité. Si une région devient une zone de disponibilité après le déploiement initial dans le hub, l’utilisateur peut recréer les passerelles, ce qui déclenche le déploiement d’une zone de disponibilité. Toutes les passerelles sont approvisionnées dans un hub sous la forme active-active, ce qui implique une résilience intégrée au sein d’un hub. Les utilisateurs peuvent se connecter à plusieurs hubs s’ils souhaitent une résilience entre les régions.

Actuellement, le Pare-feu Azure peut être déployé pour prendre en charge les zones de disponibilité à l’aide du Portail Azure Firewall Manager, de PowerShell ou de l’interface CLI. Il n’existe actuellement aucun moyen de configurer un pare-feu existant à déployer sur plusieurs zones de disponibilité. Vous devez supprimer et redéployer votre Pare-feu Azure.

Alors que le concept de Virtual WAN est global, la ressource Virtual WAN réelle est basée sur Resource Manager et déployée de manière régionale. Si la région du WAN virtuel présente elle-même un problème, tous les hubs de ce WAN virtuel continueront à fonctionner en l’état, mais l’utilisateur ne pourra pas créer de nouveaux hubs tant que la région du WAN virtuel ne sera pas disponible.

Quel client le VPN utilisateur Virtual WAN Azure (point à site) prend en charge ?

Virtual WAN prend en charge le client Azure VPN, le client OpenVPN ou tout client IKEv2. L’authentification Microsoft Entra est prise en charge avec Azure VPN Client. Le système d’exploitation client doit être au minimum Windows 10 version 17763.0. Un ou plusieurs clients OpenVPN peuvent prendre en charge l’authentification basée sur les certificats. Une fois l’authentification basée sur les certificats sélectionnée dans la passerelle, vous voyez le fichier .ovpn* à télécharger sur votre appareil. IKEv2 prend en charge l’authentification par certificat et RADIUS.

Pour un VPN utilisateur (point à site), pourquoi le pool de clients P2S est divisé en deux routes ?

Chaque passerelle a deux instances. Le fractionnement se fait de sorte que chaque instance de passerelle puisse allouer indépendamment les adresses IP des clients pour les clients connectés et que le trafic provenant du réseau virtuel soit redirigé vers l’instance de passerelle appropriée afin d’éviter un saut d’instance inter-passerelle.

Comment ajouter des serveurs DNS pour les clients P2S ?

Il existe deux options pour ajouter des serveurs DNS pour les clients P2S. La première méthode est préférable car elle ajoute les serveurs DNS personnalisés à la passerelle à la place du client.

Utilisez le script PowerShell suivant pour ajouter les serveurs DNS personnalisés. Remplacez les valeurs de votre environnement.

// Define variables
$rgName = "testRG1"
$virtualHubName = "virtualHub1"
$P2SvpnGatewayName = "testP2SVpnGateway1"
$vpnClientAddressSpaces = 
$vpnServerConfiguration1Name = "vpnServerConfig1"
$vpnClientAddressSpaces = New-Object string[] 2
$vpnClientAddressSpaces[0] = "192.168.2.0/24"
$vpnClientAddressSpaces[1] = "192.168.3.0/24"
$customDnsServers = New-Object string[] 2
$customDnsServers[0] = "7.7.7.7"
$customDnsServers[1] = "8.8.8.8"
$virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName
$vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name

// Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway
createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers

// Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway
$P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName
$updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers 

// Re-generate Vpn profile either from PS/Portal for Vpn clients to have the specified dns servers

Ou, si vous utilisez Azure VPN Client pour Windows 10, vous pouvez modifier le fichier XML du profil téléchargé et ajouter les balises <dnsservers><dnsserver></dnsserver></dnsservers> avant de l’importer.
```
   <azvpnprofile>
   <clientconfig>

       <dnsservers>
           <dnsserver>x.x.x.x</dnsserver>
           <dnsserver>y.y.y.y</dnsserver>
       </dnsservers>

   </clientconfig>
   </azvpnprofile>
```

Pour un VPN utilisateur (point à site), combien de clients sont pris en charge ?

Le tableau ci-dessous décrit le nombre de connexions simultanées et le débit agrégé de la passerelle VPN point à site pris en charge à différentes unités d’échelle.

Unité de mise à l'échelle	Instances de passerelle	Connexions simultanées prises en charge	Débit agrégé
1	2	500	0,5 Gbits/s
2	2	500	1 Gbit/s
3	2	500	1,5 Gbits/s
4	2	1 000	2 Gbit/s
5	2	1 000	2,5 Gbits/s
6	2	1 000	3 Gbits/s
7	2	5 000	3,5 Gbits/s
8	2	5 000	4 Gbits/s
9	2	5 000	4,5 Gbits/s
10	2	5 000	5 Gbit/s
11	2	10000	5,5 Gbits/s
12	2	10000	6 Gbits/s
13	2	10000	6,5 Gbits/s
14	2	10000	7 Gbits/s
15	2	10000	7,5 Gbits/s
16	2	10000	8 Gbits/s
17	2	10000	8,5 Gbits/s
18	2	10000	9 Gbits/s
19	2	10000	9,5 Gbits/s
20	2	10000	10 Gbits/s
40	4	20000	20 Gbits/s
60	6	30000	30 Gbits/s
80	8	40000	40 Gbits/s
100	10	50000	50 Gbit/s
120	12	60000	60 Gbits/s
140	14	70000	70 Gbit/s
160	16	80000	80 Gbit/s
180	18	90000	90 Gbits/s
200	20	100000	100 Gbits/s

Supposons que l’utilisateur choisisse l’unité d’échelle 1. Chaque unité d’échelle implique le déploiement d’une passerelle active-active et chacune des instances (dans ce cas, 2) prend en charge jusqu’à 500 connexions. Comme vous pouvez obtenir 500 connexions * 2 par passerelle, cela ne signifie pas que vous planifiez 1000 au lieu de 500 pour cette unité d’échelle. Il peut être nécessaire de traiter les instances. Au cours de cette opération, la connectivité pour les 500 supplémentaires peut être interrompue si vous avez dépassé le nombre de connexions recommandé.

Pour les passerelles avec des unités d’échelle supérieures à 20, des paires supplémentaires à haute disponibilité d’instances de passerelle sont déployées afin de fournir une capacité supplémentaire pour connecter des utilisateurs. Chaque paire d’instances prend en charge jusqu’à 10 000 utilisateurs supplémentaires. Par exemple, si vous déployez une passerelle avec 100 unités d’échelle, 5 paires de passerelles (10 instances totales) sont déployées, et jusqu’à 50 000 (10 000 utilisateurs x 5 paires de passerelles) utilisateurs simultanés peuvent se connecter.

En outre, veillez à planifier les temps d’arrêt au cas où vous décideriez d’effectuer un scale-up ou un scale-down dans l’unité d’échelle, ou de modifier la configuration de point à site sur la passerelle VPN.

Que sont les unités d’échelle de passerelle Virtual WAN ?

Une unité d’échelle est une unité définie pour choisir un débit agrégé d’une passerelle dans le hub virtuel. 1 unité d’échelle de VPN = 500 Mbit/s 1 unité d’échelle d’ExpressRoute = 2 Gbits/s Exemple : 10 unités d’échelle de VPN représente un débit de 500 Mbits/s * 10 = 5 Gbits/s.

Quelle est la différence entre une passerelle de réseau virtuel Azure (passerelle VPN) et une passerelle VPN Azure Virtual WAN ?

WAN virtuel fournit une connectivité de site à site à grande échelle et est conçu pour le débit, l’évolutivité et la facilité d’utilisation. Lorsque vous connectez un site à une passerelle VPN Virtual WAN, il est différent d’une passerelle de réseau virtuel normale qui utilise le type de passerelle « VPN site à site ». Lorsque vous souhaitez connecter des utilisateurs distants à Virtual WAN, vous utilisez le type de passerelle « VPN point à site ». Les passerelles VPN point à site et site à site sont des entités séparées dans le hub Virtual WAN et doivent être déployées individuellement. De même, lorsque vous connectez un circuit ExpressRoute à un hub Virtual WAN, il utilise une ressource différente pour la passerelle ExpressRoute que la passerelle de réseau virtuel normale utilisant le type de passerelle « ExpressRoute ».

Virtual WAN prend en charge un débit agrégé pouvant atteindre 20 Gbits/s pour VPN et ExpressRoute. Virtual WAN dispose également d’une automatisation pour la connectivité avec un écosystème de partenaires d’appareils de branche CPE. Les appareils de branche CPE intègrent une automatisation qui provisionne et se connecte automatiquement à Azure Virtual WAN. Ces périphériques sont disponibles à partir d’un écosystème croissant des partenaires SD-WAN et VPN. Consultez la liste des partenaires préférés.

En quoi Virtual WAN est-il différent d’une passerelle de réseau virtuel Azure ?

Un VPN de passerelle de réseau virtuel est limité à 100 tunnels. Pour les connexions, vous devez utiliser un WAN virtuel pour le VPN à grande échelle. Vous pouvez connecter jusqu’à 1 000 connexions de branche par hub virtuel avec un agrégat de 20 Gbits/s par hub. Une connexion est un tunnel actif-actif entre l’appareil VPN local et le hub virtuel. Vous pouvez également disposer de plusieurs hubs virtuels par région, ce qui signifie que vous pouvez connecter plus de 1 000 branches à une seule région Azure en déployant plusieurs hubs WAN virtuels dans cette région Azure, chacun avec sa propre passerelle VPN de site à site.

Quel est l’algorithme et les paquets recommandés par seconde par instance de site à site dans le hub Virtual WAN ? Combien de tunnels sont pris en charge par instance ? Quel est le débit maximal pris en charge dans un tunnel unique ?

Virtual WAN prend en charge 2 instances actives de passerelle VPN de site à site dans un hub virtuel. Cela signifie qu’il existe 2 ensembles actifs/actifs de passerelle VPN dans un hub virtuel. Pendant les opérations de maintenance, chaque instance est mise à niveau une par une. C’est la raison pour laquelle un utilisateur peut subir une courte diminution du débit global d’une passerelle VPN.

Bien qu’un VPN Virtual WAN prenne en charge de nombreux algorithmes, pour optimiser les performances, nous recommandons l’algorithme GCMAES256 tant pour le chiffrement que pour l’intégrité IPSEC. Les algorithmes AES256 et SHA256 étant considérés comme moins performants, une dégradation des performances, par exemple, sur le plan de la latence et des rejets de paquets est prévisible pour des types d’algorithmes similaires.

Les paquets par seconde, ou PPS, sont un facteur du nombre total de paquets et du débit pris en charge par instance. Un exemple permet de mieux comprendre. Supposons qu’une instance de passerelle VPN de site à site d’une unité d’échelle de 1 500 Mbits/s est déployée dans un hub WAN virtuel. En supposant une taille de paquet de 1400, le PPS attendu pour cette instance de passerelle VPN est au maximum = [(500 Mbits/s * 1024 * 1024) /8/1400] ~ 47000.

Virtual WAN présente des concepts de connexion VPN, de connexion de liaison et de tunnels. Une connexion VPN unique est constituée de connexions de liaison. Virtual WAN prend en charge jusqu’à 4 connexions de liaison dans une connexion VPN. Chaque connexion de liaison est constituée de deux tunnels IPsec qui se terminent dans deux instances d’une passerelle VPN active/active déployée dans un hub virtuel. Le nombre total de tunnels pouvant se terminer dans une instance active unique est de 1 000, ce qui implique également que le débit pour 1 instance sera agrégé sur tous les tunnels qui se connectent à cette instance. Chaque tunnel a également des valeurs de débit spécifiques. Si plusieurs tunnels sont connectés à une passerelle d’unité d’échelle de valeur inférieure, il est préférable d’évaluer le besoin par tunnel et le plan d’une passerelle VPN qui est une valeur agrégée pour le débit sur tous les tunnels se terminant dans l’instance VPN.

Valeurs des différentes unités d’échelle prises en charge dans Virtual WAN

Unité d'échelle	Débit maximal par tunnel (Mbits/s)	PPS max. par tunnel	Débit maximal par instance (Mbits/s)	PPS maximal par instance
1	500	47 000	500	47 000
2	1 000	94 000	1 000	94 000
3	1500	140K	1500	140K
4	1500	140K	2000	187 000
5	1500	140K	2 500	234 000
6	1500	140K	3000	281 000
7	2300	215 000	3 500	328 000
8	2300	215 000	4000	374 000
9	2300	215 000	4500	421 000
10	2300	215 000	5 000	468 000
11	2300	215 000	5500	515 000
12	2300	215 000	6000	562 000
13	2300	215 000	6500	609 000
14	2300	215 000	7000	655 000
15	2300	215 000	7500	702 000
16	2300	215 000	8000	749 000
17	2300	215 000	8500	796 000
18	2300	215 000	9000	843 000
19	2300	215 000	9500	889 000
20	2300	215 000	10000	936 000

Notes

Tous les nombres sont basés sur l’algorithme GCM.

Quels sont les fournisseurs d’appareils (partenaires Virtual WAN) pris en charge ?

À ce stade, de nombreux partenaires prennent en charge l’expérience Virtual WAN entièrement automatisée. Pour plus d’informations, consultez Partenaires WAN virtuel.

Quelles sont les étapes d’automatisation des partenaires Virtual WAN ?

Pour découvrir les étapes d’automatisation des partenaires, consultez l’article Partenaires Virtual WAN.

Est-il nécessaire d’utiliser un périphérique de partenaire préféré ?

Non. Vous pouvez utiliser n’importe quel appareil prenant en charge les VPN et qui respecte les exigences Azure pour la prise en charge de IPsec IKEv2/IKEv1. Virtual WAN possède également des solutions de partenaires CPE qui automatisent la connectivité à Azure Virtual WAN, ce qui facilite la configuration des connexions VPN IPsec à grande échelle.

Comment les partenaires WAN virtuel automatisent-ils la connectivité avec le WAN virtuel Azure ?

Les solutions de connectivité à définition logicielle gèrent généralement leurs appareils de branche à l’aide d’un contrôleur ou un centre de provisionnement des appareils. Le contrôleur peut utiliser des API Azure pour automatiser la connectivité au WAN virtuel Azure. L’automatisation comprend le chargement des informations de branche, le téléchargement de la configuration Azure, la configuration de tunnels IPsec dans des hubs virtuels Azure et la configuration automatique de la connectivité de l’appareil de branche à Azure Virtual WAN. Lorsque vous avez des centaines de branches, la connexion à l’aide de partenaires CPE Virtual WAN est simple, car l’expérience d’intégration n’a plus besoin de configurer et de gérer une connectivité IPsec à grande échelle. Pour plus d’informations, consultez Virtual WAN partner automation (Automation de partenaire WAN virtuel).

Que se passe-t-il si j’utilise un appareil qui n’est pas dans la liste des partenaires Virtual WAN ? Puis-je toujours l’utiliser pour me connecter au VPN Azure Virtual WAN ?

Oui, si l’appareil prend en charge IPsec IKEv1 ou IKEv2. Les partenaires Virtual WAN automatisent la connectivité de l’appareil aux points de terminaison du VPN Azure. Cela implique l’automatisation d’étapes telles que « chargement des informations de branche », « IPsec et configuration » et « connectivité ». Comme votre appareil ne vient pas d’un écosystème de partenaires Virtual WAN, vous devez vous-même récupérer la configuration d’Azure et mettre à jour votre appareil pour configurer la connectivité IPsec.

Comment les nouveaux partenaires qui ne figurent pas dans votre liste de partenaires de lancement sont-ils intégrés ?

Toutes les API de réseau étendu virtuel sont OpenAPI. Vous pouvez consulter la documentation Automatisation des partenaires Virtual WAN pour évaluer la faisabilité technique. Un partenaire idéal dispose d’un appareil qui peut être approvisionné pour une connectivité IPsec IKEv1 ou IKEv2. Une fois que l’entreprise a terminé le travail d’automatisation pour son appareil CPE en fonction des instructions d’automatisation fournies ci-dessus, vous pouvez accéder à azurevirtualwan@microsoft.com pour être listé ici azurevirtualwan@microsoft.com. Si, comme client, vous souhaitez qu’une certaine solution d’entreprise soit listée comme partenaire Virtual WAN, demandez à l’entreprise de contacter Virtual WAN en envoyant un e-mail à azurevirtualwan@microsoft.com.

Comment Virtual WAN prend en charge les appareils SD-WAN ?

Les partenaires Virtual WAN automatisent la connectivité IPsec vers les points de terminaison du VPN Azure. Si le partenaire Virtual WAN est un fournisseur de SD-WAN, il est nécessaire que le contrôleur SD-WAN gère l’automatisation et la connectivité IPsec vers les points de terminaison de VPN Azure. Si l’appareil SD-WAN nécessite son propre point de terminaison au lieu du VPN Azure pour toutes les fonctionnalités SD-WAN propriétaires, vous pouvez déployer le point de terminaison SD-WAN dans un réseau virtuel Azure et le faire coexister avec Azure Virtual WAN.

Virtual WAN prend en charge le peering BGP et a également la capacité de déployer des appliances virtuelles réseau dans un hub Virtual WAN.

Combien de périphériques VPN peuvent se connecter à un même hub ?

Chaque hub virtuel prend en charge jusqu’à 1000 connexions. Chaque connexion se compose de quatre liens et chaque connexion de lien prend en charge deux tunnels qui sont dans une configuration actif-actif. Les tunnels se terminent par une passerelle VPN de hub virtuel Azure. Les liens représentent le lien du fournisseur de services Internet physique au niveau de l’appareil de branche/VPN.

Qu’est-ce qu’une connexion de branche à Azure Virtual WAN ?

Une connexion à partir d’un appareil VPN ou de branche dans Azure Virtual WAN est une connexion VPN qui connecte virtuellement le site VPN et la passerelle Azure VPN dans un hub virtuel.

Que se passe-t-il si le périphérique VPN local n’a qu’un seul tunnel vers une passerelle VPN Azure Virtual WAN ?

Une connexion Azure Virtual WAN est composée de 2 tunnels. Une passerelle VPN Virtual WAN est déployée sur un hub virtuel en mode actif-actif, ce qui implique l’existence de tunnels distincts partant des appareils locaux et qui se terminent sur des instances distinctes. Cette recommandation s’adresse à tous les utilisateurs. Cependant, si l’utilisateur choisit de n’avoir qu’un seul tunnel vers une des instances de passerelle VPN Virtual WAN, et si pour une raison quelconque (maintenance, application de correctifs, etc.), l’instance de passerelle est placée hors connexion, le tunnel est déplacé vers la deuxième instance active et l’utilisateur peut être amené à se reconnecter. Les sessions BGP ne sont pas déplacées d’une instance à l’autre.

Que se passe-t-il lors de la réinitialisation d’une passerelle dans une passerelle VPN WAN virtuelle ?

Le bouton Réinitialiser la passerelle doit être utilisé si vos appareils locaux fonctionnent tous comme prévu, mais que la connexion VPN de site à site dans Azure est dans un état Déconnecté. Les passerelles VPN Virtual WAN sont toujours déployées dans un état Actif-Actif pour la haute disponibilité. Cela signifie qu’il y a toujours plus d’une instance déployée dans une passerelle VPN à un moment donné. Quand le bouton Réinitialiser la passerelle est utilisé, il redémarre les instances de la passerelle VPN de façon séquentielle, de sorte que vos connexions ne sont pas interrompues. Il y aura un court intervalle de temps pendant lequel les connexions vont passer d’une instance à l’autre, mais cet intervalle devrait être inférieur à une minute. En outre, notez que la réinitialisation des passerelles ne changera pas vos adresses IP publiques.

Ce scénario s’applique uniquement aux connexions S2S.

L’appareil VPN local peut-il se connecter à plusieurs hubs ?

Oui. Au départ, le flux du trafic s’effectue de l’appareil local vers le périmètre réseau de Microsoft le plus proche, puis vers le hub virtuel.

Existe-t-il des nouvelles ressources de Resource Manager disponibles pour le WAN virtuel ?

Oui, Virtual WAN possède de nouvelles ressources Resource Manager. Pour plus d'informations, consultez la Vue d’ensemble.

Puis-je déployer et utiliser l’appliance virtuelle de mon réseau favori (dans un réseau virtuel NVA) avec le WAN virtuel Azure ?

Oui, vous pouvez connecter le réseau virtuel VNet de l’appliance virtuelle (NVA) au WAN virtuel Azure.

Puis-je créer une appliance virtuelle réseau à l’intérieur du hub virtuel ?

Une appliance virtuelle réseau peut être déployée dans un hub virtuel. Pour connaître la procédure à suivre, consultez À propos des appliances virtuelles réseau dans un hub Virtual WAN.

Un réseau virtuel spoke peut-il avoir une passerelle de réseau virtuel ?

Non. Le réseau virtuel spoke ne peut pas avoir de passerelle de réseau virtuel s’il est connecté au hub virtuel.

Un réseau virtuel spoke peut-il avoir un serveur de route Azure ?

Nombre Le réseau virtuel spoke ne peut pas avoir de serveur de routes s’il est connecté au hub virtuel WAN.

La prise en charge de BGP est-elle assurée dans la connectivité VPN ?

Oui, BGP est pris en charge. Quand vous créez un site VPN, vous pouvez fournir les paramètres BGP qu’il contient. Cela implique que toutes les connexions créées dans Azure pour ce site sont activées pour BGP.

Y a-t-il des informations de licence ou de tarification pour le WAN virtuel ?

Oui. Consultez la page Tarification.

Est-il possible de construire le WAN virtuel Azure avec un modèle Resource Manager ?

La configuration simple d’un Virtual WAN avec un hub et un site VPN peut être créée en utilisant un modèle de démarrage rapide. Virtual WAN est principalement un service piloté par REST ou le portail.

Est-ce que les réseaux virtuels spoke qui sont connectés à un hub virtuel peuvent communiquer entre eux (transit V2V) ?

Oui. Le réseau Virtual WAN standard prend en charge la connectivité transitive de réseau virtuel à réseau virtuel via le hub Virtual WAN auquel les réseaux virtuels sont connectés. Dans la terminologie Virtual WAN, nous faisons référence à ces chemins en tant que « transit de réseau virtuel Virtual WAN local » pour les réseaux virtuels connectés à un hub Virtual WAN dans une seule région, et en tant que « transit de réseau virtuel Virtual WAN global » pour les réseaux virtuels connectés via plusieurs hubs Virtual WAN dans deux régions ou plus.

Dans certains scénarios, les réseaux virtuels spoke peuvent également être directement appairés les uns aux autres via l’appairage de réseaux virtuels, en plus du transit de réseau virtuel Virtual WAN local ou global. Dans ce cas, l’appairage de réseaux virtuels est prioritaire sur la connexion transitive via le hub Virtual WAN.

La connectivité de branche à branche est-elle autorisée dans le WAN virtuel ?

Oui, la connectivité de branche à branche est autorisée dans le WAN virtuel. Une branche est conceptuellement applicable au site VPN, aux circuits ExpressRoute ou aux utilisateurs de VPN point à site/utilisateur. La connectivité de branche à branche est activée par défaut et peut être trouvée dans les paramètres de configuration WAN. Ainsi, les utilisateurs/branches VPN peuvent se connecter à d’autres branches VPN, et la connectivité de transit est également activée entre les utilisateurs ExpressRoute et VPN.

Le trafic branche à branche traverse-t-il Azure Virtual WAN ?

Oui. Le trafic branche à branche traverse Azure Virtual WAN.

Virtual WAN nécessite-t-il ExpressRoute à partir de chaque site ?

Non. Virtual WAN ne nécessite pas ExpressRoute à partir de chaque site. Vos sites peuvent être connectés à un réseau de fournisseur à l’aide d’un circuit ExpressRoute. Pour les sites qui sont connectés via ExpressRoute à un hub virtuel, et via VPN IPsec au même hub, le hub virtuel fournit une connectivité de transit entre les utilisateurs ExpressRoute et VPN.

Existe-t-il une limite de débit réseau ou de connexions lors de l’utilisation d’Azure Virtual WAN ?

Le débit réseau s’exprime par service dans un hub Virtual WAN. Dans chaque hub, le débit agrégé VPN peut atteindre jusqu’à 20 Gbits/s, le débit agrégé ExpressRoute jusqu’à 20 Gbits/s et le débit agrégé VPN utilisateur/VPN de point à site jusqu’à 200 Gbits/s. Le routeur dans le hub virtuel prend en charge jusqu’à 50 Gbits/s pour les flux de trafic de réseau virtuel à réseau virtuel, et supporte une charge de travail totale de 2 000 machines virtuelles parmi tous les réseaux virtuels connectés à un même hub virtuel.

Pour sécuriser la capacité initiale sans avoir à attendre que le hub virtuel soit mis à l’échelle lorsque plus de débit est nécessaire, vous pouvez définir la capacité minimale ou modifier si nécessaire. Consultez À propos des paramètres du hub virtuel - capacité du hub. Pour déterminer les conséquences financières, consultez le coût d’une unité d’infrastructure de routage dans la page des tarifs d’Azure Virtual WAN.

Lorsque des sites VPN se connectent à un hub, ils le font à l’aide de connexions. Virtual WAN prend en charge jusqu’à 1 000 connexions ou 2 000 tunnels IPsec par hub virtuel. Lorsque les utilisateurs distants se connectent au hub virtuel, ils se connectent à la passerelle VPN P2S, qui prend en charge jusqu’à 100 000 utilisateurs en fonction de l’unité d’échelle (bande passante) choisie pour la passerelle VPN P2S dans le hub virtuel.

Puis-je utiliser NAT-T sur mes connexions VPN ?

Oui, NAT Traversal (NAT-T) est pris en charge. La passerelle VPN Virtual WAN n’assure AUCUNE fonctionnalité de type NAT sur les paquets internes vers/à partir des tunnels IPsec. Dans cette configuration, vérifiez que l’appareil local lance le tunnel IPsec.

Comment configurer une unité d’échelle sur un paramètre spécifique comme 20 Gbits/s ?

Accédez à la passerelle VPN à l’intérieur d’un hub sur le portail, puis cliquez sur l’unité d’échelle pour la remplacer par le paramètre approprié.

Virtual WAN autorise-t-il l’appareil en local à utiliser plusieurs ISP en parallèle, ou faut-il toujours un tunnel VPN unique ?

Les solutions d’appareils locaux peuvent appliquer des stratégies de trafic pour diriger le trafic entre plusieurs tunnels dans le hub Azure Virtual WAN (passerelle VPN dans le hub virtuel).

Qu’est-ce que l’architecture de transit global ?

Pour plus d’informations, consultez Architecture du réseau de transit global et Virtual WAN.

Comment le trafic est-il acheminé sur la dorsale principale d’Azure ?

Le trafic suit le modèle suivant : appareil de branche -> ISP -> périmètre réseau de Microsoft -> Microsoft DC (réseau virtuel du hub) -> périmètre réseau de Microsoft -> ISP -> appareil de branche

Dans ce modèle, de quoi avez-vous besoin sur chaque site ? Seulement d’une connexion Internet ?

Oui. Une connexion Internet et un appareil physique qui prend en charge IPsec, de préférence parmi nos partenaires Virtual WAN intégrés. Si vous le souhaitez, vous pouvez gérer manuellement la configuration et la connectivité à Azure à partir de l’appareil de votre choix.

Comment activer la route par défaut (0.0.0.0/0) d’une connexion (VPN, ExpressRoute ou Réseau virtuel) ?

Un hub virtuel peut propager un itinéraire par défaut appris à une connexion de réseau virtuel/VPN site à site/ExpressRoute si l’indicateur est « Activé » sur la connexion. Cet indicateur est visible lorsque l’utilisateur modifie une connexion de réseau virtuel, une connexion VPN ou une connexion ExpressRoute. Par défaut, cet indicateur est désactivé lorsqu’un site ou un circuit ExpressRoute est connecté à un hub. Il est activé par défaut lorsqu’une connexion de réseau virtuel est ajoutée pour connecter un réseau virtuel à un hub virtuel.

L’itinéraire par défaut ne provient pas du hub Virtual WAN ; il est propagé s’il est déjà appris par le hub Virtual WAN suite au déploiement d’un pare-feu dans le hub, ou si le tunneling forcé est activé sur un autre site connecté. Une route par défaut ne se propage pas entre les hubs (inter-hub).

Est-il possible de créer plusieurs hubs Virtual WAN dans la même région ?

Oui. Les clients peuvent désormais créer plusieurs hubs dans la même région pour la même instance Azure Virtual WAN.

Comment le hub virtuel d’une instance Virtual WAN sélectionne-t-il le meilleur chemin pour une route à partir de plusieurs hubs ?

Pour plus d’informations, consultez la page Préférence de routage du hub virtuel.

Le hub Virtual WAN autorise-t-il la connectivité entre les circuits ExpressRoute ?

Le transit entre ER et ER s’effectue toujours via Global Reach. Les passerelles de hub virtuel sont déployées dans les régions DC ou Azure. Lorsque deux circuits ExpressRoute se connectent via Global Reach, il n’est pas nécessaire que le trafic fasse tout le chemin à partir des routeurs de périphérie vers le contrôleur de domaine du hub virtuel.

Existe-il un concept de poids dans les circuits ExpressRoute Azure Virtual WAN ou les connexions VPN ?

Lorsque plusieurs circuits ExpressRoute sont connectés à un hub virtuel, le poids du routage sur la connexion fournit un mécanisme permettant à ExpressRoute dans le hub virtuel de préférer un circuit à l’autre. Aucun mécanisme ne permet de définir un poids sur une connexion VPN. Azure préfère toujours une connexion ExpressRoute à une connexion VPN au sein d’un hub individuel.

Un réseau étendu virtuel préfère-t-il ExpressRoute à un VPN pour le trafic sortant d’Azure ?

Oui. Virtual WAN préfère ExpressRoute à un VPN pour le trafic sortant d’Azure. Toutefois, vous pouvez configurer la préférence de routage du hub virtuel pour changer la préférence par défaut. Pour connaître la procédure à suivre, consultez Configurer la préférence de routage de hub virtuel.

Lorsqu’un hub Virtual WAN dispose d’un circuit ExpressRoute et d’un site VPN qui lui est connecté, qu’est-ce qui ferait qu’une route de connexion VPN serait préférable à ExpressRoute ?

Quand un circuit ExpressRoute est connecté à un hub virtuel, les routeurs Microsoft Edge constituent le premier nœud pour la communication entre l’environnement local et Azure. Ces routeurs de périphérie communiquent avec les passerelles ExpressRoute du WAN virtuel qui, à leur tour, apprennent les routes auprès du routeur de hub virtuel qui contrôle toutes les routes entre les diverses passerelles dans Virtual WAN. Les routeurs Microsoft Edge traitent les routes ExpressRoute de hub virtuel avec une préférence plus élevée que les routes apprises à partir de l’environnement local.

Quelle qu’en soit la raison, si la connexion VPN devient le support principal à partir duquel le hub virtuel apprend les routes (par exemple dans les scénarios de basculement entre ExpressRoute et VPN), à moins que le site VPN n’ait un chemin AS plus long, le hub virtuel continuera de partager les routes apprises via le VPN avec la passerelle ExpressRoute. De ce fait, les routeurs Microsoft Edge préféreront les routes VPN aux routes locales.

Lorsque deux hubs (hub 1 et 2) sont connectés et qu’un circuit ExpressRoute est connecté comme un nœud papillon aux deux hubs, quel est le chemin d’un réseau virtuel connecté au hub 1 lui permettant d’atteindre un réseau virtuel connecté dans le hub 2 ?

Le comportement actuel consiste à préférer le chemin du circuit ExpressRoute à la connectivité de hub à hub pour la connectivité de réseau virtuel à réseau virtuel. Toutefois, cela n’est pas recommandé dans une configuration de réseau WAN virtuel. Pour résoudre cette situation, vous pouvez effectuer l’une des deux opérations suivantes :

Configurer plusieurs circuits ExpressRoute (différents fournisseurs) pour effectuer une connexion à un seul hub et utilisent la connectivité de hub à hub fournie par Virtual WAN pour les flux de trafic inter-régionaux.
Configurez AS-Path comme préférence de routage hub pour votre hub virtuel. Ainsi, le trafic entre les deux hubs passe par le routeur Virtual Hub de chaque hub et utilise le chemin hub-to-hub au lieu du chemin ExpressRoute (qui passe par les routeurs Microsoft Edge). Pour plus d’informations, consultez Configurer la préférence de routage de hub virtuel.

Quand un circuit ExpressRoute est connecté en tant que « nœud papillon » (ou « bow-tie ») à un hub Virtual WAN et à un réseau virtuel autonome, quel est le chemin pour que le réseau virtuel autonome atteigne le hub Virtual WAN ?

Le comportement actuel consiste à préférer le chemin du circuit ExpressRoute pour la connectivité VNet (non-Virtual WAN) autonome vers Virtual WAN. Nous recommandons au client de créer une connexion Réseau virtuel pour connecter directement le réseau virtuel autonome au hub Virtual WAN. Ensuite, le trafic de réseau virtuel à réseau virtuel traverse le routeur du hub Virtual WAN au lieu du chemin ExpressRoute (qui traverse les routeurs Microsoft Enterprise Edge/MSEE).

Remarque

Depuis le 1er février 2024, la fonctionnalité du back-end de la bascule ci-dessous n'a pas été appliquée dans toutes les régions. Par conséquent, vous pouvez voir l'option de la bascule. Toutefois, l'activation ou la désactivation de la bascule n'aura aucun effet. La fonctionnalité du back-end devrait être disponible dans les prochaines semaines.

Dans le portail Azure, les boutons bascules Autoriser le trafic depuis des réseaux Virtual WAN distants et Autoriser le trafic depuis des réseaux non-Virtual WAN permettent la connectivité entre le réseau virtuel autonome (VNet 4) et les réseaux virtuels spoke directement connectés au hub Virtual WAN (VNet 2 et VNet 3). Pour autoriser cette connectivité, les deux boutons bascules doivent être activés : le bouton bascule Autoriser le trafic depuis des réseaux Virtual WAN distants pour la passerelle ExpressRoute dans le réseau virtuel autonome et le bouton bascule Autoriser le trafic depuis des réseaux non-Virtual WAN pour la passerelle ExpressRoute dans le hub Virtual WAN. Dans le diagramme ci-dessous, si ces deux boutons bascules sont activés, la connectivité est autorisée entre le réseau virtuel autonome 4 et les réseaux virtuels directement connectés au hub 2 (VNet 2 et VNet 3). Si un serveur de routes Azure est déployé dans le réseau virtuel autonome 4 et que branche à branche est activé pour le serveur de routes, la connectivité sera bloquée entre le réseau virtuel 1 et le réseau virtuel autonome 4.

L'activation ou la désactivation du bouton de la bascule affecte uniquement le flux de trafic suivant : le trafic transitant entre le hub Virtual WAN et les réseaux virtuels autonomes via le circuit ExpressRoute. L’activation ou la désactivation de la bascule n’entraînera pas de temps d’arrêt pour aucun des autres flux de trafic (par exemple, le flux du site local vers le réseau virtuel spoke 2 ne sera pas impacté, le flux du réseau virtuel 2 vers le réseau virtuel 3 ne sera pas impacté, etc.).

Des hubs peuvent-ils être créés dans différents groupes de ressources dans Virtual WAN ?

Oui. Cette option est actuellement disponible avec PowerShell uniquement. Le portail Virtual WAN exige que les hubs se trouvent dans le même groupe de ressources que la ressource Virtual WAN proprement dite.

Quel est l’espace d’adressage de hub recommandé lors de la création d’un hub ?

L’espace d’adressage de hub Virtual WAN recommandé est /23. Le hub Virtual WAN attribue des sous-réseaux à différentes passerelles (ExpressRoute, VPN site à site, VPN point à site, pare-feu Azure, routeur de hub virtuel). Pour les scénarios dans lesquels les appliances virtuelles réseau sont déployées à l’intérieur d’un hub virtuel, un sous-réseau /28 est généralement mis en œuvre pour les instances d’appliance virtuelle réseau. Toutefois, si l’utilisateur devait configurer plusieurs appliances virtuelles réseau, un sous-réseau /27 peut être attribué. Par conséquent, en gardant à l’esprit une architecture future, si les hubs Virtual WAN sont déployés avec une taille minimale de /24, l’espace d’adressage de hub recommandé que l’utilisateur peut entrer au moment de la création est /23.

IPv6 est-il pris en charge dans Virtual WAN ?

La version IPv6 n’est pas prise en charge dans le hub Virtual WAN et ses passerelles. Si vous disposez d’un réseau virtuel qui prend en charge IPv4 et IPv6, et que vous voulez le connecter à Virtual WAN, ce scénario n’est pas pris en charge actuellement.

Pour le scénario VPN utilisateur point à site avec « breakout » Internet via le Pare-feu Azure, vous devrez probablement désactiver la connectivité IPv6 sur votre appareil client pour forcer le trafic vers le hub Virtual WAN. Cela est dû au fait que les appareils modernes utilisent par défaut des adresses IPv6.

Quelle est la version d’API recommandée pour une utilisation par les scripts qui automatisent différentes fonctionnalités de Virtual WAN ?

La version minimale 05-01-2022 (1er mai 2022) est requise.

Existe-t-il des limites pour Virtual WAN ?

Consultez la section Limites applicables à Virtual WAN dans la page sur les limites d’abonnement et de service.

Quelles sont les différences entre les types de Virtual WAN (de base et standard) ?

Consultez Réseaux Virtual WAN de base et standard. Pour connaître les tarifs, consultez la page Tarification.

Est-ce que Virtual WAN stocke des données client ?

Non. Virtual WAN ne stocke pas de données client.

Existe-t-il des fournisseurs de services managés capables de gérer Virtual WAN pour les utilisateurs en tant que service ?

Oui. Pour obtenir la liste des solutions de fournisseurs de services managés (MSP) activées via la Place de marché Azure, consultez Offres de la Place de marché Azure par les partenaires MSP de mise en réseau Azure.

Quelle est la différence entre le routage du hub Virtual WAN et le serveur de routes Azure dans un réseau virtuel ?

Le hub Virtual WAN et le Serveur de routes Azure fournissent des fonctionnalités de peering BGP (Border Gateway Protocol) qui peuvent être utilisées par des appliances virtuelles réseau (NVA) pour publier des adresses IP de la NVA vers les réseaux virtuels Azure de l’utilisateur. Les options de déploiement diffèrent dans le sens où le serveur de routes Azure est généralement déployé par un réseau virtuel de hub client autogéré, tandis qu’Azure Virtual WAN fournit un service de hub entièrement maillé sans interaction auquel les clients connectent leurs divers points de terminaison spokes (Azure VNet, branches locales avec VPN de site à site ou SDWAN, utilisateurs distants avec connexions VPN de point à site/utilisateur distant et connexions privées avec ExpressRoute) et bénéficient du peering BGP pour les appliances virtuelles réseau déployées dans le réseau virtuel spoke avec d’autres fonctionnalités vWAN telles que la connectivité de transit entre réseaux virtuels, la connectivité de transit entre VPN et ExpressRoute, le routage personnalisé/avancé, l’association et la propagation personnalisées des routes, l’intention/les stratégies de routagee pour une sécurité interrégion, le hub sécurisé/pare-feu Azure, etc. Pour plus d’informations sur le peering BGP de Virtual WAN, consultez Comment homologuer BGP avec un hub virtuel.

Si j’utilise un fournisseur de sécurité tiers (Zscaler, iBoss ou Check Point) pour sécuriser mon trafic Internet, pourquoi ne puis-je pas voir le site VPN associé au fournisseur de sécurité tiers dans le portail Azure ?

Lorsque vous choisissez de déployer un fournisseur partenaire de sécurité pour protéger l’accès à Internet pour vos utilisateurs, le fournisseur de sécurité tiers crée un site VPN en votre nom. Étant donné que le fournisseur de sécurité tiers est créé automatiquement par le fournisseur et que ce n’est pas un site VPN créé par l’utilisateur, ce site VPN n’apparaîtra pas dans le portail Azure.

Pour plus d’informations sur les options disponibles pour les fournisseurs de sécurité tiers et sur la configuration de ce dernier, consultez Déployer un fournisseur de partenaires de sécurité.

Les communautés BGP générées par le réseau local seront-elles conservées dans Virtual WAN ?

Oui, les communautés BGP générées par le réseau local seront conservées dans Virtual WAN. Vous pouvez utiliser vos propres ASN publics ou privés pour vos réseaux locaux. Vous ne pouvez pas utiliser les plages réservées par Azure ou IANA :

Numéros ASN réservés par Azure :
- ASN publics : 8074, 8075, 12076
- ASN privés : 65515, 65517, 65518, 65519, 65520
- ASN réservés par l’IANA : 23456, 64496-64511, 65535-65551

Est-il possible de modifier l’ASN pour une passerelle VPN ?

Non. Virtual WAN ne prend pas en charge les modifications ASN pour des passerelles VPN.

Dans Virtual WAN, quelles sont les performances estimées par la référence SKU de passerelle ExpressRoute ?

Unité d'échelle	Connexions par seconde	Mégabits par seconde	Paquets par seconde
1 unité d’échelle	14 000	2 000	200 000
2 unités d’échelle	28 000	4 000	400 000
3 unités d’échelle	42 000	6 000	600 000
4 unités d’échelle	56 000	8,000	800 000
5 unités d’échelle	70 000	10 000	1 000 000
6 unités d’échelle	84 000	12,000	1 200 000
7 unités d’échelle	98 000	14 000	1 400 000
8 unités d’échelle	112 000	16 000	1 600 000
9 unités d’échelle	126 000	18 000	1 800 000
10 unités d'échelle	140 000	20 000	2 000 000

Les unités d’échelle 2-10 maintiennent le débit agrégé pendant les opérations de maintenance. Cependant, l’unité d’échelle 1 peut subir une légère variation de débit lors d’une opération de maintenance.

Si je connecte un circuit local ExpressRoute à un hub Virtual WAN, est-ce que je ne serai en mesure d’accéder qu’aux régions du même emplacement de métro que le circuit local ?

Les circuits locaux ne peuvent être connectés qu’aux passerelles ExpressRoute dans leur région Azure correspondante. Toutefois, il n’existe aucune limitation pour acheminer le trafic vers des réseaux virtuels spoke dans d’autres régions.

Pourquoi un message et un bouton « Mettre à jour le routeur vers la dernière version du logiciel » s’affichent-ils dans le portail ?

Remarque

À compter de janvier 2024, l’équipe Virtual WAN a commencé la mise à niveau des hubs virtuels vers la version la plus récente. Si vous n’avez pas mis à niveau votre hub et que vous remarquez maintenant que la version du routeur de votre hub indique « latest » (« la plus récente »), cela signifie alors que votre hub a été mis à niveau par l’équipe Virtual WAN.

L’infrastructure basée sur les services cloud à l’échelle d’Azure est dépréciée. Comme résultat, l’équipe Virtual WAN travaille à la mise à niveau des routeurs virtuels depuis leur infrastructure Cloud Services actuelle vers des déploiements basés sur des Virtual Machine Scale Sets. Tous les hubs virtuels nouvellement créés sont automatiquement déployés sur l’infrastructure la plus récente basée sur le groupe de machines virtuelles identiques. Si vous accédez à la ressource de votre hub Virtual WAN et que vous voyez ce message et ce bouton, vous pouvez mettre à niveau votre routeur vers la dernière version en cliquant sur le bouton. Si vous souhaitez tirer parti des nouvelles fonctionnalités de Virtual WAN, telles que le peering BGP avec le hub, vous devrez mettre à jour votre routeur de hub virtuel via le Portail Azure. Si le bouton n’est pas visible, veuillez ouvrir un cas de support.

Vous pourrez mettre à jour votre routeur de hub virtuel seulement si toutes les ressources (passerelles/tables de routage/connexions VNet) de votre hub sont dans un état Réussite. Vérifiez que tous vos réseaux virtuels spoke sont dans des abonnements actifs/activés et que vos réseaux virtuels spoke ne sont pas supprimés. En outre, comme cette opération nécessite le déploiement de nouveaux routeurs de hubs virtuels basés sur des groupes de machines virtuelles identiques, vous serez confronté à un temps d’arrêt attendu de 1 à 2 minutes pour le trafic de réseau virtuel à réseau virtuel via le même hub et de 5 à 7 minutes pour tous les autres flux de trafic via le hub. Au sein d’une seule ressource Virtual WAN, les hubs doivent être mis à jour un par un plutôt que plusieurs à la fois. Lorsque la version du routeur indique « Latest », la mise à jour du hub est terminée. Il n’y aura aucun changement de comportement de routage après cette mise à jour.

Il existe plusieurs points à noter avec la mise à niveau du routeur de hub virtuel :

Si vous avez déjà configuré le peering BGP entre votre hub Virtual WAN et une appliance virtuelle réseau dans un réseau virtuel spoke, vous devez supprimer, puis recréer l’homologue BGP. Étant donné que les adresses IP du routeur de hub virtuel changent après la mise à niveau, vous devrez également reconfigurer votre appliance virtuelle réseau pour effectuer un peering avec les nouvelles adresses IP du routeur du hub virtuel. Ces adresses IP sont représentées en tant que champ « virtualRouterIps » dans le JSON de ressource du hub virtuel.
Si vous avez une appliance virtuelle réseau (NVA) dans le hub virtuel, vous allez devoir travailler avec votre partenaire NVA pour obtenir des instructions sur la mise à niveau de votre hub Virtual WAN.
Si votre hub virtuel est configuré avec plus de 15 unités d’infrastructure de routage, effectuez un scale-in de votre hub virtuel sur 2 unités d’infrastructure de routage avant de tenter la mise à niveau. Vous pouvez effectuer un scale-out de votre hub sur plus de 15 unités d’infrastructure de routage après la mise à niveau de votre hub.

Si la mise à jour échoue pour une raison quelconque, l’ancienne version de votre hub sera automatiquement récupérer pour garantir qu’il y a toujours une configuration opérationnelle.

Autres informations à connaître :

L’utilisateur doit avoir un rôle Propriétaire ou Contributeur pour voir un état précis de la version du routeur du hub. Si un rôle Lecteur sur la ressource et l’abonnement Virtual WAN est attribué à un utilisateur, le portail Azure indique à cet utilisateur que le routeur du hub doit être mis à niveau vers la dernière version, même si la version du hub est déjà la plus récente.
Si vous modifiez l’état d’abonnement de votre réseau virtuel spoke de désactivé à activé, puis mettez à niveau le hub virtuel, vous devrez mettre à jour votre connexion au réseau virtuel après la mise à niveau du hub virtuel (par exemple, vous pouvez configurer la connexion au réseau virtuel pour qu’elle se propage à une étiquette factice).
Si votre hub est connecté à un grand nombre de réseaux virtuels spoke (60 ou plus), vous pouvez noter qu’un ou plusieurs peerings de réseaux virtuels spoke passent à un état d’échec après la mise à niveau. Pour restaurer ces peerings de réseaux virtuels à un état de réussite après la mise à niveau, vous pouvez configurer les connexions de réseau virtuel pour qu’elles se propagent sur une étiquette factice. Sinon, vous pouvez supprimer et recréer ces connexions de réseau virtuel respectives.

Existe-t-il une limite d’itinéraire pour les clients OpenVPN se connectant à une passerelle VPN Azure P2S ?

La limite d’itinéraire pour les clients OpenVPN est de 1 000.

Comment le contrat SLA Virtual WAN est-il calculé ?

Virtual WAN est une plateforme de mise en réseau en tant que service qui a un contrat SLA de 99,95 %. Toutefois, Virtual WAN combine de nombreux composants différents tels que Pare-feu Azure, VPN de site à site, ExpressRoute, VPN point à site et Virtual WAN Hub/Appliances virtuelles réseau intégrées.

Le contrat SLA de chaque composant est calculé individuellement. Par exemple, si ExpressRoute a un temps d’arrêt de 10 minutes, la disponibilité d’ExpressRoute est calculée comme étant (Minutes disponibles maximales - temps d’arrêt) / Minutes disponibles maximales * 100.

Pouvez-vous modifier l’espace d’adressage de réseau virtuel dans un réseau virtuel spoke connecté au hub ?

Oui, cette opération peut être effectuée automatiquement sans mise à jour, ni réinitialisation requise sur la connexion de peering. Vous trouverez plus d’informations sur la façon de modifier l’espace d’adressage du réseau virtuel ici.

Maintenance de passerelle contrôlée par le client Virtual WAN

Quels sont les services inclus dans l’étendue de la configuration de la maintenance des passerelles réseau ?

Pour Virtual WAN, vous pouvez configurer des fenêtres de maintenance des passerelles VPN site à site et des passerelles ExpressRoute.

Quelle maintenance est prise en charge ou non par la maintenance contrôlée par le client ?

Les services Azure passent par des mises à jour de maintenance périodiques pour améliorer les fonctionnalités, la fiabilité, les performances et la sécurité. Une fois que vous avez configuré une fenêtre de maintenance pour vos ressources, la maintenance du système d’exploitation invité et du service est effectuée pendant cette fenêtre. Ces mises à jour concernent la plupart des éléments de maintenance qui préoccupent les clients.

Les mises à jour de l’infrastructure du matériel hôte et du centre de données sous-jacents ne sont pas couvertes par la maintenance contrôlée par le client. En outre, s’il existe un problème de sécurité de gravité élevé susceptible de mettre en danger nos clients, Azure peut avoir besoin de remplacer le contrôle client de la fenêtre de maintenance et de déployer la modification. Il s’agit d’occurrences rares qui ne seraient utilisées que dans des cas extrêmes.

Puis-je recevoir une notification avancée de la maintenance ?

À ce stade, la notification préalable ne peut pas être activée pour la maintenance des ressources de passerelle réseau.

Puis-je configurer une fenêtre de maintenance inférieure à cinq heures ?

À ce stade, vous devez configurer une fenêtre minimale de cinq heures dans le fuseau horaire de votre choix.

Puis-je configurer une planification de maintenance qui ne se répète pas tous les jours ?

À ce stade, vous devez configurer une fenêtre de maintenance quotidienne.

Les ressources de configuration de maintenance doivent-elles se trouver dans la même région que la ressource de passerelle ?

Oui.

Dois-je déployer une unité d’échelle de passerelle minimale pour être éligible à la maintenance contrôlée par le client ?

Nombre

Combien de temps faut-il pour que la stratégie de configuration de maintenance devienne effective une fois qu’elle est affectée à la ressource de passerelle ?

Les passerelles réseau peuvent mettre jusqu’à 24 heures pour suivre la planification de maintenance après que la stratégie de maintenance a été associée à la ressource de passerelle.

Comment planifier des fenêtres de maintenance lors de l’utilisation d’un VPN et d’ExpressRoute dans un scénario de coexistence ?

Lorsque vous travaillez avec VPN et ExpressRoute dans un scénario de coexistence ou chaque fois que vous avez des ressources agissant en tant que sauvegardes, nous vous recommandons de configurer des fenêtres de maintenance distinctes. Cette approche garantit que la maintenance n’affecte pas vos ressources de sauvegarde en même temps.

J’ai planifié une fenêtre de maintenance pour une date ultérieure pour l’une de mes ressources. Les activités de maintenance seront-elles suspendues sur cette ressource jusqu’à ce moment-là ?

Non, les activités de maintenance ne seront pas suspendues sur votre ressource pendant la période précédant la fenêtre de maintenance planifiée. Pendant les jours non couverts dans votre planification de maintenance, la maintenance continue comme d’habitude sur la ressource.

Étapes suivantes

Pour plus d’informations sur Virtual WAN, consultez la À propos de Virtual WAN.