Considérations relatives à la conception du réseau d’Azure VMware Solution
Azure VMware Solution offre un environnement de cloud privé VMware auquel les utilisateurs et applications peuvent accéder à partir de ressources ou d’environnements locaux et Azure. Les services de mise en réseau tels qu’Azure ExpressRoute et les connexions de réseau privé virtuel (VPN) fournissent la connectivité.
Plusieurs considérations relatives à la mise en réseau doivent être examinées avant que vous configuriez votre environnement Azure VMware Solution. Cet article fournit des solutions pour les cas d’usage que vous pouvez rencontrer lorsque vous utilisez Azure VMware Solution pour configurer vos réseaux.
Compatibilité d’Azure VMware Solution avec AS-Path Prepend
Azure VMware Solution a des considérations relatives à l’utilisation d’AS-Path Prepend pour les configurations ExpressRoute redondantes. Si vous exécutez deux chemins ExpressRoute ou plus entre un site local et Azure, tenez compte des instructions suivantes pour influencer le trafic hors d’Azure VMware Solution vers votre emplacement local via ExpressRoute GlobalReach.
En raison d’un routage asymétrique, des problèmes de connectivité peuvent se produire quand Azure VMware Solution n’observe pas-AS-Path Prepend et utilise donc le routage multichemin à coût égal (ECMP) pour envoyer le trafic vers votre environnement sur les deux circuits ExpressRoute. Ce comportement peut poser des problèmes avec les dispositifs d'inspection de pare-feu avec état placés derrière des circuits ExpressRoute existants.
Prérequis
Pour AS-Path Prepend, prenez en compte les conditions préalables suivantes :
- Le point clé est que vous devez prédéfini les numéros ASN publics pour influencer la façon dont Azure VMware Solution achemine le trafic vers l’environnement local. Si vous prédéfinissez avec un ASN privé, Azure VMware Solution ignorera le préfixage, et le comportement ECMP mentionné précédemment se produira. Même si vous utilisez un ASN BGP privé local, il est toujours possible de configurer vos appareils locaux afin d’utiliser un ASN public lors de l'ajout de routes sortantes, afin de garantir la compatibilité avec Azure VMware Solution.
- Concevez votre chemin de trafic pour que les ASN privés suivent les AS publics afin qu'ils soient honorés par Azure VMware Solution. Le circuit ExpressRoute d’Azure VMware Solution ne supprime aucun ASN privé qui existe dans le chemin après le traitement de l’ASN public.
- Les deux circuits ou tous les circuits sont connectés via Azure VMware Solution Azure ExpressRoute Global Reach.
- Les mêmes blocages sont publiés à partir de deux ou plusieurs circuits.
- Utilisez AS-Path Prepend pour forcer la solution Azure VMware à préférer un circuit à un autre.
- Utilisez des numéros ASN publics de 2 ou 4 octets.
Machines virtuelles de gestion et itinéraires par défaut à partir de l’environnement local
Important
Les machines virtuelles de gestion Azure VMware Solution de gestion ne respectent pas un itinéraire par défaut à partir d’un emplacement local pour les destinations RFC1918.
Si vous effectuez un routage vers vos réseaux locaux en utilisant uniquement un itinéraire par défaut publié vers Azure, le trafic des machines virtuelles vCenter Server et NSX Manager utilisées vers des destinations locales avec des adresses IP privées ne suit pas cet itinéraire.
Pour atteindre vCenter Server et NSX Manager à partir d’un emplacement local, fournissez des itinéraires spécifiques pour permettre au trafic d’avoir un chemin de retour vers ces réseaux. Par exemple, publiez les résumés RFC1918 (10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16).
Itinéraire par défaut pour Azure VMware Solution pour l’inspection du trafic Internet
Certains déploiements nécessitent l’inspection de tout le trafic de sortie de Azure VMware Solution vers Internet. Bien qu’il soit possible de créer des appliances virtuelles réseau dans Azure VMware Solution, il existe des cas d’usage où ces appliances existent déjà dans Azure et peuvent être appliquées pour inspecter le trafic Internet à partir de Azure VMware Solution. Dans ce cas, vous pouvez injecter un itinéraire par défaut à partir de l’appliance virtuelle réseau dans Azure pour attirer le trafic à partir de Azure VMware Solution et inspecter le trafic avant de l’envoyer à l’Internet public.
Le diagramme suivant décrit une topologie hub-and-spoke de base connectée à un cloud Azure VMware Solution et à un réseau local via ExpressRoute. Le diagramme montre comment l’appliance virtuelle réseau dans Azure est à l’origine de l’itinéraire par défaut (0.0.0.0/0). Le Serveur de routes Azure propage l’itinéraire vers Azure VMware Solution via ExpressRoute.
Important
La route par défaut que NVA annonce sera propagée au réseau sur site. Vous devez ajouter des itinéraires définis par l’utilisateur (UDR) pour vous assurer que le trafic de Azure VMware Solution transite par l’appliance virtuelle réseau.
La communication entre Azure VMware Solution et le réseau local se produit généralement via ExpressRoute Global Reach, comme décrit dans la rubrique Environnements locaux homologues vers Azure VMware Solution.
Connectivité entre Azure VMware Solution et un réseau local
Il existe deux scénarios principaux pour la connectivité entre Azure VMware Solution et un réseau local via une appliance virtuelle réseau tierce :
- Les organisations ont besoin d’échanger du trafic entre Azure VMware Solution et le réseau local via une appliance virtuelle réseau (généralement un pare-feu).
- ExpressRoute Global Reach n’est pas disponible sur une région particulière pour interconnecter les circuits ExpressRoute de Azure VMware Solution et du réseau local.
Il existe deux topologies que vous pouvez appliquer pour répondre à toutes les exigences de ces scénarios : le supernet et le réseau virtuel spoke de transit.
Important
L’option recommandée pour connecter des environnements Azure VMware Solution et locaux est une connexion ExpressRoute Global Reach directe. Les modèles décrits dans cet article ajoutent une complexité à l’environnement.
Topologie de conception surnet
Si les circuits ExpressRoute (vers Azure VMware Solution et le réseau local) se terminent dans la même passerelle ExpressRoute, vous pouvez partir du principe que la passerelle va acheminer les paquets entre eux. Toutefois, une passerelle ExpressRoute n’est pas conçue pour ce faire. Vous devez aiguiller le trafic vers une appliance virtuelle réseau qui peut acheminer le trafic.
Il existe deux conditions pour aiguiller le trafic réseau vers une appliance virtuelle réseau :
L’appliance virtuelle réseau doit publier un surnet pour les préfixes Azure VMware Solution et les préfixes locaux.
Vous pouvez utiliser un supernet qui comprend des préfixes Azure VMware Solution et locaux. Ou vous pouvez utiliser des préfixes individuels pour Azure VMware Solution et le réseau local (toujours moins spécifiques que les préfixes réels publiés sur ExpressRoute). Gardez à l’esprit que tous les préfixes surnet publiés sur le serveur de routes sont propagés à la fois vers Azure VMware Solution et le réseau local.
Les itinéraires définis par l’utilisateur dans le sous-réseau de passerelle qui correspondent exactement aux préfixes publiés à partir de Azure VMware Solution et du réseau local, aiguillent le trafic depuis le sous-réseau de passerelle vers l’appliance virtuelle réseau.
Cette topologie entraîne une surcharge de gestion élevée pour les grands réseaux qui changent au fil du temps. Tenez compte des limitations suivantes :
- Chaque fois qu’un segment de charge de travail est créé dans Azure VMware Solution, il peut être nécessaire d’ajouter des itinéraires définis par l’utilisateur pour garantir que le trafic de Azure VMware Solution transite par l’appliance virtuelle réseau.
- Si votre environnement local comporte un grand nombre de routes qui changent, il peut être nécessaire de mettre à jour la configuration du protocole BGP (Border Gateway Protocol) et de l’UDR dans le supernet.
- Comme une seule passerelle ExpressRoute traite le trafic réseau dans les deux sens, les performances peuvent être limitées.
- Il existe une limite Réseau virtuel Azure de 400 itinéraires définis par l’utilisateur.
Le diagramme suivant montre comment l’appliance virtuelle réseau doit publier des préfixes qui sont plus génériques (moins spécifiques) et qui incluent les réseaux locaux et Azure VMware Solution. Soyez prudent avec cette approche. L’appliance virtuelle réseau pourrait potentiellement attirer du trafic qu’elle ne devrait pas, car elle annonce des plages plus larges (par exemple, l’ensemble 10.0.0.0/8 du réseau).
Topologie de réseau virtuel spoke transit
Remarque
Si des préfixes publicitaires moins spécifiques ne sont pas possibles en raison des limites décrites précédemment, vous pouvez implémenter une autre conception qui utilise deux réseaux virtuels distincts.
Avec cette topologie, au lieu de propager des itinéraires qui sont moins spécifiques pour attirer le trafic vers la passerelle ExpressRoute, deux appliances virtuelles réseau de différents réseaux virtuels peuvent s’échanger des itinéraires entre eux. Les réseaux virtuels peuvent propager ces itinéraires à leurs circuits ExpressRoute respectifs via BGP et Serveur de routes Azure. Chaque appliance virtuelle réseau dispose d’un contrôle total sur les préfixes qui sont effectivement propagés vers chaque circuit ExpressRoute.
Le diagramme suivant montre comment un seul 0.0.0.0/0 est publié pour Azure VMware Solution. Il montre également comment les préfixes Azure VMware Solution individuels sont propagés vers le réseau local.
Important
Un protocole d’encapsulation, tel que VXLAN ou IPsec, est requis entre les appliances virtuelles réseau. L'encapsulation est nécessaire car la carte réseau (NIC) des NVA apprendrait les routes du Serveur de routes Azure avec NVA comme prochain saut et créerait une boucle de routage.
Il existe une alternative à l’utilisation d’une superposition. Appliquez des cartes réseau secondaires dans l’appliance virtuelle réseau qui n’apprennent pas les itinéraires du Serveur de routes Azure. Ensuite, configurez des UDR pour qu’Azure puisse acheminer le trafic vers l’environnement distant sur ces NIC. Vous trouverez plus de détails dans Topologie réseau et connectivité à l’échelle de l’entreprise pour Azure VMware Solution.
Cette topologie nécessite une configuration initiale complexe. La topologie fonctionne ensuite comme prévu avec une surcharge de gestion minimale. Les complexités de l’installation sont les suivantes :
- Il y a un coût supplémentaire pour l’ajout d’un réseau virtuel de transit qui comprend un Serveur de routes Azure, une passerelle ExpressRoute et une autre appliance virtuelle réseau. Les appliances virtuelles réseau peuvent également avoir besoin d’utiliser des machines virtuelles de grande taille pour répondre aux exigences de débit.
- Un tunneling IPsec ou VXLAN est nécessaire entre les deux NVA, ce qui signifie que les NVA se trouvent également dans le chemin de données. Selon le type d’appliance virtuelle réseau que vous utilisez, cela peut entraîner une configuration personnalisée et complexe sur ces appliances virtuelles réseau.
Étapes suivantes
Après avoir appris les considérations relatives à la conception réseau pour Azure VMware Solution, envisagez d’explorer les articles suivants :