En immersion dans le routage Virtual WAN

Azure Virtual WAN est une solution réseau qui permet de créer facilement des topologies réseau sophistiquées : elle englobe le routage à travers les régions Azure entre les réseaux virtuels Azure et les emplacements locaux via un VPN point à site, un VPN de site à site, des appliances ExpressRoute et SDWAN intégrées, y compris l’option de sécurisation du trafic. Dans la plupart des cas, il n'est pas nécessaire que vous ayez une compréhension approfondie du fonctionnement du routage interne de Virtual WAN, mais dans certaines situations, il peut être utile d’en comprendre les concepts.

Ce document explore les exemples de scénarios Virtual WAN expliquant certains des comportements que les organisations peuvent rencontrer lors de l’interconnexion de leurs réseaux virtuels et branches dans des réseaux complexes. Les scénarios présentés dans cet article ne sont en aucun cas des suggestions de conception ; il s’agit simplement d’exemples de topologies destinés à illustrer certaines fonctionnalités Virtual WAN.

Scénario 1 : topologie avec préférence de routage par défaut

Le premier scénario de cet article analyse une topologie avec deux hubs Virtual WAN, ExpressRoute, vpn et connectivité SDWAN. Dans chaque hub, des réseaux virtuels sont connectés directement (réseaux virtuels 11 et 21) et indirectement par le biais d’une appliance virtuelle réseau (réseaux virtuels 121, 122, 221 et 222). Le réseau virtuel 12 échange des informations de routage avec le hub 1 via BGP (voir le peering BGP avec un hub virtuel) et le réseau virtuel 22 est configuré avec des routes statiques pour montrer les différences entre les deux options.

Dans chaque hub, les appliances VPN et SDWAN servent un double objectif : d'une part, elles annoncent leurs propres préfixes individuels (10.4.1.0/24sur VPN dans le hub 1 et 10.5.3.0/24 sur SDWAN dans le hub 2), et d'autre part, elles annoncent les mêmes préfixes que les circuits ExpressRoute dans la même région (10.4.2.0/24 dans le hub 1 et 10.5.2.0/24 dans le hub 2). Cette différence servira à illustrer le fonctionnement de la préférence de routage du hub Virtual WAN.

Toutes les connexions de réseau virtuel et de branche sont associées et propagées vers la table de routage par défaut. Bien que les hubs soient sécurisés (il existe un Pare-feu Azure déployé dans chaque hub), ils ne sont pas configurés pour sécuriser le trafic privé ou Internet. Ceci entraînerait la propagation de toutes les connexions à la None table de routage, ce qui supprimerait tous les itinéraires non statiques de la Default table de routage et éliminerait l’objectif de cet article, car le panneau de routage effectif dans le portail serait presque vide (à l’exception des itinéraires statiques pour envoyer le trafic au pare-feu Azure).

Important

Le diagramme précédent montre deux hubs virtuels sécurisés, mais cette topologie n’est pas encore prise en charge par Routing Intent. Pour plus d’informations, consultez Comment configurer l’intention de routage et les stratégies de routage d’un hub Virtual WAN.

Hors de la boîte de dialogue, les hubs Virtual WAN échangent des informations entre eux afin que la communication entre les régions soit activée. Vous pouvez inspecter les itinéraires effectifs dans Virtual WAN tables de routage : par exemple, l’image suivante montre les itinéraires effectifs dans hub 1 :

Ces itinéraires effectifs sont ensuite publiés par Virtual WAN aux branches et les injectent dans les réseaux virtuels connectés aux hubs virtuels, ce qui rend l’utilisation des itinéraires définis par l’utilisateur inutile. Lors de l’inspection des itinéraires effectifs dans un hub virtuel, les champs « Type de tronçon suivant » et « Origine » indiquent l’origine des itinéraires. Par exemple, un type de tronçon suivant « Réseau virtuel connexion » indique que le préfixe est défini dans un réseau virtuel directement connecté à Virtual WAN (réseaux virtuels 11 et 12 dans la capture d’écran précédente)

Le NVA du VNet 12 injecte la route 10.1.20.0/22 via BGP, comme l'implique le Next Hop Type "HubBgpConnection" (voir BGP Peering avec Virtual Hub). Cet itinéraire récapitulatif couvre les rayons indirects VNet 121 (10.1.21.0/24) et VNet 122 (10.1.22.0/24). Les VNets et les branches du concentrateur distant sont visibles avec un saut suivant de hub2, et on peut voir dans le chemin AS que le numéro de système autonome 65520 a été ajouté deux fois à ces routes inter-centres.

Dans hub 2, il existe une appliance virtuelle réseau SDWAN intégrée. Pour plus de détails sur les NVAs supportés pour cette intégration, veuillez consulter la page À propos des NVAs dans un hub Virtual WAN. Notez que la route vers la branche 10.5.3.0/24 SDWAN a un tronçon suivant de VPN_S2S_Gateway. Ce type de tronçon suivant peut indiquer aujourd’hui des itinéraires provenant d’une passerelle Azure Réseau virtuel ou de nvAs intégrés dans le hub.

Dans hub 2, l’itinéraire pour 10.2.20.0/22 vers les rayons indirects VNet 221 (10.2.21.0/24) et VNet 222 (10.2.2.22.0/24) est installé en tant qu’itinéraire statique, comme indiqué par l’origine defaultRouteTable. Si vous vérifiez les itinéraires effectifs pour hub 1, cet itinéraire n’apparaît pas. La raison est que les itinéraires statiques ne sont pas propagés via BGP, mais doivent être configurés dans chaque hub. Par conséquent, un itinéraire statique est requis dans hub 1 pour fournir une connectivité entre les réseaux virtuels et les branches du hub 1 vers les spokes indirects dans hub 2 (réseaux virtuels 221 et 222) :

Une fois la route statique ajoutée, le hub 1 contient également la route 10.2.20.0/22 :

Scénario 2 : Préférence de routage Global Reach et Hub

Même si hub 1 connaît le préfixe ExpressRoute du circuit 2 (10.5.2.0/24) et hub 2 connaît le préfixe ExpressRoute du circuit 1 (10.4.2.0/24), les itinéraires ExpressRoute provenant de régions distantes ne sont pas publiés vers des liens ExpressRoute locaux. Par conséquent, ExpressRoute Global Reach est nécessaire pour que les emplacements ExpressRoute communiquent entre eux :

Important

Le diagramme précédent montre deux hubs virtuels sécurisés, mais cette topologie n’est pas encore prise en charge par Routing Intent. Pour plus d’informations, consultez Comment configurer l’intention de routage et les stratégies de routage d’un hub Virtual WAN.

Comme expliqué dans Préférence de routage du hub virtuel, Virtual WAN favorise par défaut les itinéraires provenant d’ExpressRoute. Étant donné que les itinéraires sont annoncés du hub 1 au circuit ExpressRoute 1, du circuit ExpressRoute 1 au circuit 2, et du circuit ExpressRoute 2 au hub 2 (et vice versa), les hubs virtuels préfèrent ce chemin à la liaison inter-hubs plus directe. Les itinéraires effectifs dans hub 1 montrent ceci :

Comme vous pouvez le voir dans les itinéraires, ExpressRoute Global Reach ajoutera plusieurs fois le numéro de système autonome ExpressRoute (12076) avant de renvoyer les itinéraires à Azure pour rendre ces itinéraires moins préférables. Toutefois, Virtual WAN priorité de routage du hub par défaut d’ExpressRoute ignore la longueur du chemin d’accès AS lors de la prise de décision de routage.

Les itinéraires effectifs dans hub 2 seront similaires :

La préférence de routage peut être modifiée en VPN ou AS-Path tel qu’expliqué dans la préférence de routage du hub virtuel. Par exemple, vous pouvez définir la préférence sur VPN, comme illustré dans cette image :

Avec une préférence de routage de hub de VPN, les routes effectives dans le hub 1 ressemblent à ceci :

L'image précédente montre que la route vers 10.4.2.0/24 a maintenant un tronçon suivant de VPN_S2S_Gateway, alors qu'avec la préférence de routage par défaut d'ExpressRoute, il était de 3ExpressRouteGateway. Toutefois, dans hub 2, l’itinéraire pour 10.5.2.0/24 apparaître toujours avec un tronçon suivant , ExpressRoutecar dans ce cas, l’itinéraire alternatif ne provient pas d’un passerelle VPN mais d’une appliance virtuelle réseau intégrée dans le hub :

Toutefois, le trafic entre les hubs préfère toujours les itinéraires provenant d’ExpressRoute. Pour utiliser la connexion directe plus efficace entre les concentrateurs virtuels, la préférence de route peut être réglée sur "AS Path" sur les deux concentrateurs :

Maintenant, les itinéraires pour les spokes distants et les branches dans hub 1 auront un tronçon suivant Remote Hub comme prévu :

Vous pouvez voir que le préfixe IP du hub 2 (192.168.2.0/23) est toujours accessible via le lien Global Reach, mais cela ne doit pas avoir d’impact sur le trafic, car aucun trafic ne doit être adressé aux appareils du hub 2. Il pourrait s’agir d’un problème s’il y avait des NVA dans les deux hubs établissant des tunnels SDWAN entre eux.

Cependant, notez que 10.4.2.0/24 est maintenant préféré à la passerelle VPN. Cela peut se produire si les itinéraires publiés via UN VPN ont un chemin AS plus court que les itinéraires publiés via ExpressRoute. Après avoir configuré l’appareil VPN local pour prédéfinis son numéro de système autonome (65501) sur les itinéraires VPN pour rendre le hub 1 moins préférable, hub 1 sélectionne désormais ExpressRoute comme tronçon suivant pour 10.4.2.0/24:

Le hub 2 affichera un tableau similaire pour les routes effectives, où les VNets et les branches de l'autre hub apparaissent maintenant avec Remote Hub comme tronçon suivant :

Scénario 3 : connexion croisée des circuits ExpressRoute aux deux hubs

Pour ajouter des liens directs entre les régions Azure et les emplacements locaux connectés via ExpressRoute, il est souvent souhaitable de connecter un circuit ExpressRoute unique à plusieurs hubs Virtua  WAN dans une topologie parfois dite en « nœud papillon », comme dans la topologie suivante :

Important

Le diagramme précédent montre deux hubs virtuels sécurisés, mais cette topologie n’est pas encore prise en charge par Routing Intent. Pour plus d’informations, consultez Comment configurer l’intention de routage et les stratégies de routage d’un hub Virtual WAN.

Virtual WAN affiche que les deux circuits sont connectés aux deux hubs :

Revenir à la préférence de routage du hub par défaut d’ExpressRoute, les itinéraires vers les branches distantes et les réseaux virtuels dans hub 1 affichent à nouveau ExpressRoute comme tronçon suivant. Cette fois-ci, la raison n'est pas Global Reach, mais le fait que les circuits ExpressRoute renvoient les publications d'itinéraire qu'ils reçoivent d'un hub à l'autre. Par exemple, les itinéraires effectifs du hub 1 avec la préférence de routage hub d’ExpressRoute sont les suivants :

Le fait de changer à nouveau la préférence de routage du hub en AS Path ramène les itinéraires entre hubs au chemin optimal utilisant la connexion directe entre les hubs 1 et 2 :

Étapes suivantes

Pour plus d’informations sur Virtual WAN, consultez :

• FAQ sur Virtual WAN