Considérations relatives à la conception du réseau Azure VMware Solution

Azure VMware Solution offre un environnement de cloud privé VMware auquel les utilisateurs et les applications peuvent accéder à partir d’environnements ou de ressources locaux et Basés sur Azure. Les services réseau tels qu’Azure ExpressRoute et les connexions de réseau privé virtuel (VPN) fournissent la connectivité.

Il existe plusieurs considérations relatives à la mise en réseau à examiner avant de configurer 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 de 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, les problèmes de connectivité peuvent se produire quand Azure VMware Solution n’observe pas AS-Path Prepend et utilise donc le routage ECMP (Equal-Cost MultiPath) 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.

Conditions préalables

Pour AS-Path Prepend, tenez compte des conditions préalables suivantes :

• Le point clé est que vous devez préfixer des numéros de système autonome public (ASN) pour influencer la manière dont la solution Azure VMware dirige le trafic retour vers l'environnement local. Si vous utilisez un ASN privé , Azure VMware Solution ignore le prépendant et le comportement ECMP mentionné précédemment se produit. Même si vous utilisez un ASN BGP privé localement, il est toujours possible de configurer vos appareils locaux pour utiliser un ASN public lors de la préfixation des itinéraires sortants, afin de garantir la compatibilité avec Azure VMware Solution.
• Concevez votre chemin de trafic pour que les ASN privés suivent les ASN 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 à Azure VMware Solution via Azure ExpressRoute Global Reach.
• Les mêmes bloc d’adresses sont publiés à partir de deux ou plusieurs circuits.
• Vous souhaitez utiliser AS-Path Prepend pour forcer la solution Azure VMware à préférer un circuit à un autre.
• Utilisez des numéros ASN publics de 2 octets ou de 4 octets.

ASN privés réservés dans Azure VMware Solution

Azure VMware Solution utilise des numéros de système autonomes privés (ASN) spécifiques pour son infrastructure réseau sous-jacente. Pour éviter les conflits et garantir une intégration réseau transparente, les clients ne doivent pas utiliser les ASN suivants dans leurs configurations réseau.

ASN réservés pour les réseaux sous-jacents

Les ASN suivants sont réservés à l’infrastructure Azure VMware Solution interne et doivent être évités par les clients :

• ASN de niveau 2 : 65300 – 65340

• ASN de niveau 1 : 65200 – 65240

• ASN de transport (passerelles T0) : 64513 (bords NSX), 64600 – 64940

• ASN de gestion : 65000 – 65412, 398656-398670, 400572-400581

Impact de l’utilisation des ASN réservés

L’utilisation de l’un des ASN répertoriés ci-dessus dans votre environnement peut entraîner des défaillances de session BGP, des conflits de routage réseau ou des interruptions de service. Vérifiez que vos affectations ASN ne chevauchent pas ces valeurs réservées.

Machines virtuelles de gestion et itinéraires par défaut à partir d’un emplacement local

Important

Les machines virtuelles de gestion Azure VMware Solution 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 vers Azure VMware Solution pour l’inspection du trafic Internet

Certains déploiements nécessitent l’inspection de tout le trafic de sortie d’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 d’Azure VMware Solution. Dans ce cas, vous pouvez injecter un itinéraire par défaut à partir de l’appliance virtuelle réseau (NVA) 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 la nva dans azure est à l’origine de l’itinéraire par défaut (0.0.0.0/0). Azure Route Server propage l’itinéraire vers Azure VMware Solution via ExpressRoute.

Important

L'itinéraire par défaut que l'appliance virtuelle de réseau (NVA) publie sera propagé 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 Connecter les environnements locaux à 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 de réseau tierce partie :

• Les organisations ont besoin d’échanger du trafic entre Azure VMware Solution et le réseau local via une NVA (généralement un pare-feu).
• ExpressRoute Global Reach n’est pas disponible dans une région particulière pour interconnecter les circuits ExpressRoute d’Azure VMware Solution et le réseau local.

Il existe deux topologies que vous pouvez appliquer pour répondre à toutes les exigences de ces scénarios : le réseau virtuel supernet et le réseau virtuel spoke de transit.

Important

L’option préférée pour connecter Azure VMware Solution et les environnements locaux est une connexion ExpressRoute Global Reach directe. Les modèles décrits dans cet article ajoutent de la complexité à l’environnement.

Topologie de conception de supernet

Si les deux circuits ExpressRoute (vers Azure VMware Solution et en local) sont arrêtés dans la même passerelle ExpressRoute, vous pouvez supposer que la passerelle va acheminer les paquets entre eux. Toutefois, une passerelle ExpressRoute n’est pas conçue pour le faire. Vous devez rediriger le trafic vers une NVA qui peut acheminer le trafic.

Il existe deux conditions pour aiguiller le trafic réseau vers une appliance virtuelle réseau :

• La NVA doit publier un supernet pour les préfixes Azure VMware Solution et les préfixes locaux.

  Vous pouvez utiliser un supernet qui inclut à la fois Azure VMware Solution et des préfixes locaux. Vous pouvez également utiliser des préfixes individuels pour Azure VMware Solution et localement (toujours moins spécifiques que les préfixes réels publiés sur ExpressRoute). N’oubliez pas que tous les préfixes de supernet publiés sur Route Server sont propagés à la fois à Azure VMware Solution et en 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, redirigent le trafic depuis le sous-réseau de passerelle vers la NVA.

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 la NVA.
• Si votre environnement local a un grand nombre d’itinéraires qui changent, la configuration BGP (Border Gateway Protocol) et UDR dans le supernet peut avoir besoin d’être mise à jour.
• Étant donné qu’une passerelle ExpressRoute unique traite le trafic réseau dans les deux sens, les performances peuvent être limitées.
• Il existe une limite de réseau virtuel Azure de 400 UDR.

Le diagramme suivant montre comment la NVA (appliance virtuelle de réseau) doit publier des préfixes plus génériques (moins spécifiques), incluant les réseaux sur site et Azure VMware Solution. Soyez prudent avec cette approche. La NVA 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 de transit en étoile

Remarque

Si les 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 moins spécifiques pour attirer le trafic vers la passerelle ExpressRoute, deux NVAs différentes dans des réseaux virtuels séparés peuvent s’échanger des itinéraires entre eux. Les réseaux virtuels peuvent propager ces itinéraires vers leurs circuits ExpressRoute respectifs via BGP et Azure Route Server. Chaque NVA a un contrôle total sur les préfixes propagés à 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 au réseau local.

Important

Un protocole d’encapsulation, tel que VXLAN ou IPsec, est requis entre les NVAs. L'encapsulation est nécessaire car la carte réseau (NIC) des NVA apprendrait les itinéraires du Serveur de routes Azure avec la NVA comme tronçon suivant et créerait une boucle de routage.

Il existe une alternative à l’utilisation d’une superposition. Appliquez des NICs secondaires dans la NVA qui n’apprennent pas les itinéraires du Serveur de routes Azure. Ensuite, configurez les UDR afin qu’Azure puisse acheminer le trafic vers l’environnement distant via ces cartes réseau. Vous trouverez plus de détails dans la topologie et la connectivité réseau à 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 NVA. Les NVAs 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 NVAs, ce qui signifie que les NVAs se trouvent également dans le chemin de données. Selon le type d’appliance virtuelle réseau que vous utilisez, il 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 :

• Concepts de mise en réseau et d’interconnexion d’Azure VMware Solution
• Planifier le déploiement d’Azure VMware Solution
• Tutoriel : Liste de contrôle de planification de la mise en réseau pour Azure VMware Solution