Cet article s’adresse aux architectes réseau qui souhaitent concevoir des réseaux étendus définis par logiciel (SD-WAN) pour connecter des installations locales entre elles et avec Azure. Il décrit une architecture qui permet aux clients Azure de profiter de leurs investissements existants dans la plateforme, en construisant des superpositions SD-WAN efficaces et globales au-dessus du réseau principal Microsoft.
Scénarios applicables
Les recommandations formulées dans cet article sont indépendantes du fournisseur et s’appliquent à toute technologie SD-WAN non Microsoft qui remplit deux conditions de base :
- Le recours à des protocoles de tunneling qui utilisent le protocole TCP (Transmission Control Protocol) ou le protocole UDP (User Datagram Protocol) en tant que transport sous-jacent, comme le ESP IPSec en mode tunnel avec parcours NAT.
- Prise en charge du protocole BGP (Border Gateway Protocol) v4 pour l’échange de routages avec des entités externes. Aucune hypothèse n’est faite sur le protocole de routage utilisé par les appareils SD-WAN non Microsoft pour échanger des informations de routage entre eux.
Les clients qui suivent ces recommandations peuvent utiliser la technologie SD-WAN de leur choix pour atteindre les objectifs suivants :
- Intégrer des produits SD-WAN dans un réseau en étoile Azure existant, en automatisant l’échange de routages entre le réseau virtuel Azure et les appareils SD-WAN.
- Optimiser la connectivité (avec les centres de données Azure et locaux) pour les branches avec des répartitions Internet locales. La portée du réseau principal Microsoft, combinée à sa capacité, sa résilience et sa stratégie de routage de « patate froide » suggère qu’il peut être utilisé comme un réseau sous-jacent hautes performances pour les SD-WAN globaux.
- Utiliser le réseau principal Microsoft pour tout le trafic Azure vers Azure (entre les régions et les zones géographiques).
- Utiliser des réseaux MPLS (Multi-Protocol-Label-Switching) existants en tant que réseaux sous-jacents hautes performances. Il peut également être utilisé pour remplacer un réseau MPLS existant selon une approche progressive qui minimise l’impact sur l’entreprise.
Dans les sections suivantes, nous considérons que le lecteur est familiarisé avec les bases du paradigme SD-WAN et avec l’architecture du réseau principal Microsoft. Le réseau principal Microsoft interconnecte les régions Azure entre elles et avec l’Internet public.
Architecture
Les organisations présentes à l’échelle mondiale et disposant d’une empreinte Azure dans plusieurs régions utilisent généralement une combinaison de services de connectivité pour implémenter leurs réseaux d’entreprise et se connecter au réseau principal Microsoft :
- Les services de connectivité dédiés, tels que les IPVPN MPLS, peuvent être utilisés sur les plus grands sites, tels que les centres de données ou les sièges sociaux.
- Les grands sites peuvent inclure une connectivité dédiée au réseau principal Microsoft via des circuits ExpressRoute, à l’aide de l’un des modèles de connectivité pris en charge. Plus spécifiquement, un site peut utiliser des circuits point à point dédiés pour se connecter à l’emplacement de peering ExpressRoute le plus proche. Ou il peut appliquer son IPVPN MPLS pour accéder aux circuits ExpressRoute fournis par l’opérateur MPLS.
- Les succursales qui disposent uniquement d’une connectivité Internet peuvent utiliser des VPN IPSec pour se connecter au centre de données local le plus proche et utiliser la connexion ExpressRoute de ce centre de données pour accéder aux ressources Azure. Elles peuvent également utiliser des VPN IPSec pour se connecter directement aux réseaux en étoile Azure.
Les projets SD-WAN peuvent avoir des étendues différentes en ce qui concerne les services de réseau traditionnels qu’ils entendent remplacer. Certaines organisations peuvent vouloir respecter les liens dédiés ou les MPLS pour les grandes installations et déployer un SD-WAN uniquement pour remplacer les VPN IPSec basés sur Internet hérités dans de petits sites. D’autres peuvent souhaiter étendre leur SD-WAN à des sites connectés à MPLS et utiliser le réseau MPLS existant en tant que réseau sous-jacent hautes performances. Enfin, d’autres encore peuvent souhaiter ignorer leurs IPVPN MPLS ou tout service de connectivité dédié, pour adopter le paradigme SD-WAN. Elles peuvent ainsi créer l’ensemble de leur réseau d’entreprise en tant que superposition logique sur des réseaux sous-jacents publiques ou partagés (l’Internet public et le réseau principal Microsoft).
L’architecture décrite dans cet article prend en charge toutes les étendues répertoriées précédemment et repose sur les principes suivants :
- Les appareils SD-WAN sont déployés en tant qu’appliances virtuelles réseau (NVA) dans le réseau en étoile de chaque région Azure et configurés en tant que hubs SD-WAN qui terminent les tunnels à partir de sites locaux.
- Les appareils SD-WAN dans Azure sont configurés pour établir des tunnels entre eux, créant ainsi une superposition hub-à-hub entièrement maillée capable de transporter efficacement le trafic entre les régions Azure et relayer le trafic entre des sites locaux géographiquement distants, sur le réseau principal Microsoft.
- Les appareils SD-WAN sont déployés sur tous les sites locaux couverts par la solution SD-WAN et configurés pour établir des tunnels vers les appliances virtuelles réseau SD-WAN dans les régions Azure les plus proches. Différents sites peuvent utiliser différents services de transport comme sous-couche pour les tunnels, tels que l’Internet public, la connectivité ExpressRoute, etc.
- Le trafic d’un site vers n’importe quelle destination, que ce soit dans Azure ou dans un autre site local, est acheminé vers les appliances virtuelles réseau SD-WAN dans la région Azure la plus proche. Il est ensuite acheminé à travers la superposition hub à hub.
Les produits SD-WAN peuvent utiliser des protocoles et des fonctionnalités propriétaires pour détecter, une fois établis dynamiquement, des tunnels directs entre deux sites qui peuvent offrir de meilleures performances que le relais du trafic via des appliances virtuelles réseau SD-WAN dans Azure.
L’architecture de haut niveau d’un SD-WAN global qui utilise le réseau principal Microsoft, l’Internet public et des connexions ER dédiées comme réseaux sous-jacents est illustrée dans l’image suivante.
Figure 1 : Architecture de haut niveau d'un SD-WAN global qui utilise le backbone de Microsoft, l'internet public et des connexions ER dédiées comme sous-couches. La ligne noire en pointillés montre comment le trafic entre deux sites locaux peut être acheminé via des NVA SD-WAN déployés dans des régions Azure géographiquement proches des sites. Le backbone de Microsoft, en raison de sa portée, de sa capacité et de sa stratégie de routage « cold potato », peut conduire à des performances nettement meilleures/prévisibles que l'internet public, en particulier pour les connexions longue distance.
Produits SD-WAN dans des réseaux en étoile Azure
Cette section fournit des recommandations relatives au déploiement d’appareils CPE SD-WAN non-Microsoft en tant qu’appliances virtuelles réseau dans un réseau en étoile Azure existant.
Appliances virtuelles SD-WAN dans le réseau virtuel hub
La topologie en étoile est celle que Microsoft recommande pour créer des réseaux évolutifs dans une région Azure à l’aide de réseaux virtuels gérés par le client. Le réseau virtuel hub héberge des composants partagés tels que des appliances virtuelles réseau non-Microsoft et des services natifs qui fournissent des fonctions réseau, telles que le pare-feu, l’équilibrage de charge et la connectivité à des sites locaux via des VPN de site à site ou ExpressRoute. Le réseau virtuel hub est l’emplacement naturel pour les appliances virtuelles réseau SD-WAN, qui sont en fin de compte des passerelles non-Microsoft fournissant un accès aux réseaux distants.
Les appliances virtuelles réseau SD-WAN doivent être déployées dans des réseaux virtuels hub de la façon suivante :
- Un seul contrôleur d’interface réseau (NIC) est utilisé pour tout le trafic SD-WAN. D’autres cartes réseau, notamment une carte réseau de gestion, peuvent être ajoutées pour répondre aux exigences de sécurité et de conformité ou respecter les instructions du fournisseur pour les déploiements Azure.
- La carte réseau utilisée pour le trafic SD-WAN doit être associée à un sous-réseau dédié. La taille de ce dernier doit être définie en fonction du nombre d’appliances virtuelles réseau SD-WAN déployées pour répondre aux exigences de haute disponibilité (HA) et de mise à l’échelle ou de débit, décrites plus loin dans cet article.
- Les groupes de sécurité réseau (NSG) doivent être associés à la carte réseau du trafic SD-WAN, directement ou au niveau du sous-réseau. Cette association permet d’établir des connexions à partir de sites locaux distants via les ports TCP/UDP utilisés par la solution SD-WAN.
- Le transfert IP doit être activé sur la carte réseau utilisée pour le trafic SD-WAN.
Serveur de routes Azure dans le réseau virtuel hub
Le serveur de routes Azure automatise l’échange de routes entre les appliances virtuelles réseau SD-WAN et la pile SDN (Software Defined Networking) dans Azure. Le serveur de routes prend en charge le protocole BGP comme protocole de routage dynamique. En établissant des contigüités BGP entre le serveur de routes et les appliances virtuelles réseau SD-WAN :
- Les routes pour tous les sites locaux connectés au SD-WAN sont injectées dans les tables de routes du réseau virtuel et apprises par toutes les machines virtuelles Azure.
- Les routes pour tous les préfixes IP inclus dans l’espace d’adressage des réseaux virtuels sont propagés à tous les sites connectés à SD-WAN.
Le serveur de routes doit être configuré comme suit.
- Il doit être déployé dans un sous-réseau dédié au sein du réseau virtuel hub conformément à Créer et configurer un serveur de routes en utilisant le Portail Azure.
- Pour activer l’échange automatique de routes pour tous les réseaux virtuels spoke, l’appairage de réseaux virtuels doit être configuré pour permettre aux réseaux virtuels spoke d’utiliser la passerelle et le serveur de routes du réseau virtuel hub. Détails disponibles dans le FORUM aux questions sur serveur de routes Azure.
- À mesure que le serveur de routes et les appliances virtuelles réseau SD-WAN sont associés à différents sous-réseaux, les sessions BGP entre le premier et les secondes doivent être configurées avec la prise en charge des tronçons multiples pour eBGP. Il est possible de définir un nombre de tronçons compris entre 2 et le maximum pris en charge par l’appliance virtuelle réseau SD-WAN. Pour les détails de la configuration des contigüités BGP pour le serveur de routes, consultez Créer et configurer un serveur de routes en utilisant le Portail Azure.
- Deux routes
/32statiques doivent être configurés sur l’appliance virtuelle réseau SD-WAN pour les points de terminaison BGP exposés par le serveur de routes. Cette configuration garantit que la table de route de l’appliance virtuelle réseau contient toujours des routes pour ses homologues BGP à tronçons multiples (pas directement connectés).
Le serveur de routes ne se trouve pas dans le chemin de données. Il s’agit d’une entité de plan de contrôle. Il propage les itinéraires entre l’appliance virtuelle réseau SD-WAN et la pile SDN de réseau virtuel, mais le transfert réel du trafic entre l’appliance virtuelle réseau SD-WAN et les machines virtuelles du réseau virtuel est effectué par la pile SDN Azure, comme le montre la figure suivante. Pour obtenir ce comportement de routage, le serveur de routes injecte toutes les routes qu’il apprend des appliances virtuelles réseau SD-WAN avec le tronçon suivant défini sur l’adresse de l’appliance virtuelle réseau.
Pour le moment, le serveur de routes ne prend pas en charge le protocole IPv6. Cette architecture concerne uniquement le protocole IPv4.
Figure 2. Le serveur de routes prend en charge la propagation de routes entre le CPE SD-WAN et la pile SDN de réseau virtuel, mais il ne transfère pas le trafic entre le CPE SD-WAN et les machines virtuelles du réseau virtuel.
Haute disponibilité pour les appliances virtuelles réseau SD-WAN avec le serveur de routes
Le serveur de routes dispose d’une haute disponibilité intégrée. Deux nœuds de calcul prennent en charge une seule instance du serveur de routes. Ils sont déployés dans différentes zones de disponibilité, pour les régions qui prennent en charge les zones de disponibilité ou dans le même groupe à haute disponibilité. Ils exposent deux points de terminaison BGP. La haute disponibilité pour les appliances virtuelles réseau SD-WAN est assurée par le déploiement de plusieurs instances dans différentes zones de disponibilité, pour les régions qui les prennent en charge ou dans le même groupe à haute disponibilité. Chaque appliance virtuelle réseau SD-WAN établit deux sessions BGP avec les deux points de terminaison exposés par le serveur de routes.
L’architecture décrite dans cet article ne s’appuie pas sur équilibreurs de charge Azure. Plus précisément :
Aucun équilibreur de charge public n’expose les points de terminaison de tunnel SD-WAN. Chaque appliance virtuelle réseau SD-WAN expose son propre point de terminaison de tunnel. Les homologues distants établissent plusieurs tunnels, un pour chaque appliance virtuelle réseau SD-WAN dans Azure.
Aucun équilibreur de charge interne ne répartit le trafic provenant de machines virtuelles Azure vers les appliances virtuelles réseau SD-WAN. Le serveur de routes et la pile Azure SDN prennent en charge le routage multivoie à coût identique (ECMP). Si plusieurs appliances virtuelles réseau établissent des contigüités BGP avec le serveur de routes et annoncent des routes pour les mêmes destinations (comme dans les réseaux locaux et distants connectés au SD-WAN) en utilisant le même degré de préférence, le serveur de routes :
- Injecte plusieurs routes pour ces destinations dans la table de route du réseau virtuel.
- Définit chaque route pour utiliser une appliance virtuelle réseau différente comme tronçon suivant.
La pile SDN distribue ensuite le trafic vers ces destinations sur tous les tronçons suivants disponibles.
L’architecture hautes disponibilité qui en résulte est présentée dans la figure suivante :
Figure 3. Le serveur de routes prend en charge le routage multivoie à coût identique (ECMP). Les équilibreurs de charge Azure ne sont pas nécessaires lorsque plusieurs appliances virtuelles réseau SD-WAN sont utilisées à des fins de disponibilité et/ou d’évolutivité.
Haute disponibilité n-active ou mise en veille active
Lorsque vous utilisez plusieurs appliances virtuelles réseau SD-WAN et que vous les appairez avec le serveur de routes, BGP pilote le basculement. Si une appliance virtuelle réseau SD-WAN se trouve hors connexion, elle arrête la publication de routes vers le serveur de routes. Les routes apprises à partir de l’appareil en échec sont ensuite retirés de la table de route du réseau virtuel. Par conséquent, si une appliance virtuelle réseau SD-WAN ne fournit plus de connectivité aux sites SD-WAN distants en raison d’une erreur, dans l’appareil lui-même ou dans la superposition, elle ne s’affiche plus comme un tronçon suivant potentiel vers les sites distants dans la table de routes du réseau virtuel. Tout le trafic est acheminé vers les appareils sains restants. Pour plus d’informations sur la propagation de routes entre les appliances virtuelles réseau SD-WAN et le serveur de routes, consultez Routes publiées par un homologue BGP vers le serveur de routes.
Figure 4. Basculement piloté par BGP. Si l’appliance virtuelle réseau SD-WAN n°0 se trouve hors connexion, ses sessions BGP avec le serveur de routes se ferment. L’appliance virtuelle réseau SD-WAN #0 est retirée de la table de route du réseau virtuel comme tronçon suivant potentiel pour le trafic sortant d’Azure vers un site local.
Le basculement piloté par BGP et le routage ECMP activent naturellement les architectures haute disponibilité N-active avec N appareils traitant simultanément le trafic. Toutefois, vous pouvez également utiliser BGP pour implémenter des architectures haute disponibilité actives et passives : configurez l’appareil passif pour annoncer au serveur de routes les routes avec un degré de préférence inférieur à celui de son homologue actif. Le serveur de routes exclut les routes reçues depuis l’appareil passif s’il reçoit depuis l’appareil actif des routes pour les mêmes destinations avec un degré de préférence plus élevé. Il raccorde uniquement ces dernières routes dans la table de route du réseau virtuel.
Si l’appareil actif échoue ou retire certaines de ses routes, le serveur de routes :
- Sélectionne les routes correspondantes annoncées par l’appareil passif.
- Raccorde les routes dans la table de route du réseau virtuel.
Les seuls attributs BGP que les appliances virtuelles réseau SD-WAN peuvent utiliser pour exprimer un degré de préférence pour les routes qu’elles annoncent au serveur de routes est le chemin AS.
Nous vous recommandons d’utiliser les architectures haute disponibilité N-active, car elles permettent une utilisation optimale des ressources (il n’y a aucune appliance virtuelle réseau SD-WAN en veille) et une scalabilité horizontale. Pour augmenter le débit, plusieurs appliances virtuelles réseau peuvent s’exécuter en parallèle, dans la limite du nombre maximum d’homologues BGP pris en charge par le serveur de routes. Pour plus d’informations, consultez Homologues BGP. Toutefois, le modèle haute disponibilité N-actif nécessite que les appliances virtuelles réseau SD-WAN agissent comme des routeurs de couche 3 sans état. Lorsqu’il existe plusieurs tunnels vers un site, les connexions TCP peuvent être acheminées de manière asymétrique. Autrement dit, les flux ORIGINAL et REPLY de la même connexion TCP peuvent être acheminés via différents tunnels et différentes appliances virtuelles réseau. La figure suivante présente un exemple de connexion TCP acheminée de manière asymétrique. Ces asymétries de routage sont possibles pour les connexions TCP lancées sur le réseau virtuel ou sur le site local.
Figure 5. Routage asymétrique dans les architectures haute disponibilité actives/actives. Les appliances virtuelles réseau SD-WAN n°0 et n°1 annoncent la même route pour la destination 192.168.1.0/24 (site SD-WAN distant) avec la même longueur de chemin AS vers le serveur de routes. Le flux ORIGINAL (depuis le site SD-WAN distant vers Azure, chemin rouge) est acheminé via le tunnel terminé, côté Azure, par l’appliance virtuelle réseau SD-WAN n°1. Le CPE SD-WAN local sélectionne ce tunnel. La pile SDN Azure achemine le flux REPLY (depuis Azure vers le site SD-WAN distant, chemin vert) vers l’appliance virtuelle réseau SD-WAN n°0, qui est l’un des tronçons suivants potentiels pour 192.168.1.0/24, selon la table de route du réseau virtuel. On ne peut pas garantir que le tronçon suivant choisi par la pile SDN Azure soit toujours le même CPE SD-WAN qui a reçu le flux ORIGINAL.
Les architectures haute disponibilité active et passive doivent uniquement être prises en compte lorsque les appliances virtuelles réseau SD-WAN dans Azure exécutent d’autres fonctions réseau qui nécessitent une symétrie de routage, notamment le pare-feu avec état. Nous vous déconseillons cette approche en raison de ses effets sur la scalabilité. L’exécution de fonctions réseau supplémentaires sur des appliances virtuelles réseau SD-WAN accroît la consommation des ressources. En même temps, l’architecture HA active et passive permet à une seule appliance virtuelle réseau de traiter le trafic à un instant T. En d’autres termes, il est seulement possible d’augmenter l’ensemble de la couche SD-WAN jusqu’à la taille maximale de la machine virtuelle Azure qu’elle prend en charge, mais pas de la réduire. Exécutez des fonctions réseau avec état qui nécessitent une symétrie de routage sur des clusters d’appliances virtuelles réseaux distincts qui s’appuient sur équilibreur de charge standard pour une haute disponibilité n-active.
Considérations relatives à la connectivité ExpressRoute
L’architecture décrite dans cet article permet aux clients d’adopter pleinement le paradigme SD-WAN et de créer leur réseau d’entreprise en tant que superposition logique sur l’Internet public et le réseau principal Microsoft. Elle prend également en charge l’utilisation de circuits ExpressRoute dédiés pour répondre à des scénarios spécifiques, décrits plus loin.
Scénario n°1 : coexistence d’ExpressRoute et de SD-WAN
Les solutions SD-WAN peuvent coexister avec la connectivité ExpressRoute lorsque les appareils SD-WAN ne sont déployés que sur un sous-ensemble de sites. Par exemple, certaines organisations peuvent déployer des solutions SD-WAN pour remplacer des VPN IPSec traditionnels sur des sites disposant uniquement d’une connectivité Internet. Elles utilisent ensuite des services MPLS et des circuits ExpressRoute pour de grands sites et des centres de données, comme le montre la figure suivante.
Figure 6 . Les solutions SD-WAN peuvent coexister avec la connectivité ExpressRoute lorsque les appareils CPE SD-WAN ne sont déployés que sur un sous-ensemble de sites.
Dans ce scénario de coexistence, les appliances virtuelles réseau SD-WAN déployées dans Azure doivent être capables d’acheminer le trafic entre les sites connectés au SD-WAN et les sites connectés aux circuits ExpressRoute. Le serveur de routes peut être configuré pour propager des routes entre des passerelles de réseau virtuel ExpressRoute et des appliances virtuelles réseau SD-WAN dans Azure en activant la fonctionnalité AllowBranchToBranch, comme indiqué ici. La propagation des routes entre la passerelle de réseau virtuel ExpressRoute et les appliances virtuelles réseau SD-WAN se fait via BGP. Le serveur de routes établit des sessions BGP avec les deux et propage à chaque homologue les routes apprises de l’autre. La plateforme gère les sessions BGP entre le serveur de routes et la passerelle de réseau virtuel ExpressRoute. Il est inutile de les configurer explicitement, il suffit d’activer l’indicateur AllowBranchToBranch lors du déploiement du serveur de routes.
Figure 7. La propagation des routes entre la passerelle de réseau virtuel ExpressRoute et les appliances virtuelles réseau SD-WAN se fait via BGP. Le serveur de routes établit des sessions BGP avec les deux et propage des routes dans les deux sens lorsqu’il est configuré sur « AllowBranchToBranch=TRUE ». Il agit comme un réflecteur de route, autrement dit, il ne fait pas partie du chemin de données.
Ce scénario de coexistence entre SD-WAN et ExpressRoute permet des migrations de réseaux MPLS vers SD-WAN. Il fournit un chemin entre les sites MPLS existants et les sites SD-WAN nouvellement migrés, ce qui élimine la nécessité d’acheminer le trafic à travers des centres de données locaux. Ce modèle peut être utilisé non seulement pendant les migrations, mais aussi dans le cas de certaines fusions et acquisitions d’entreprises, afin d’assurer une interconnexion transparente de réseaux disparates.
Scénario n°2 : Expressroute en tant que sous-couche SD-WAN
Si vos sites locaux disposent d’une connectivité ExpressRoute, vous pouvez configurer des appareils SD-WAN pour établir des tunnels vers les appliances virtuelles réseau du hub SD-WAN s’exécutant dans Azure sur le circuit ou les circuits ExpressRoute. La connectivité ExpressRoute peut être effectuée via des circuits point à point ou un réseau MPLS. Vous pouvez utiliser à la fois le peering privé ExpressRoute et le peering Microsoft.
Peering privé
Lorsque vous utilisez le peering privé ExpressRoute comme sous-couche, tous les sites SD-WAN locaux établissent des tunnels vers les appliances virtuelles réseau du hub SD-WAN dans Azure. Aucune propagation de route n’est nécessaire dans ce scénario entre les appliances virtuelles SD-WAN et la passerelle de réseau virtuel ExpressRoute (autrement dit, le serveur de routes doit être configuré avec l’indicateur « AllowBranchToBranch » défini sur false).
Cette approche requiert une configuration BGP adéquate sur les routeurs côté client ou fournisseur qui terminent la connexion ExpressRoute. En fait, les routeurs Microsoft Enterprise Edge (MSEE) annoncent toutes les routes pour les réseaux virtuels connectés au circuit (directement ou via l’appairage de réseaux virtuels). Mais pour transférer le trafic destiné aux réseaux virtuels via un tunnel SD-WAN, le site local doit apprendre ces routes à partir de l’appareil SD-WAN, et non du circuit ER.
Par conséquent, les routeurs côté client ou fournisseur qui terminent la connexion ExpressRoute doivent filtrer les routes reçus d’Azure. Les seules routes configurées dans la couche inférieure doivent être celles permettant aux appareils SD-WAN locaux d’atteindre les appliances virtuelles réseau du hub SD-WAN dans Azure. Les clients qui souhaitent utiliser le peering privé ExpressRoute en tant que sous-couche SD-WAN doivent s’assurer de pouvoir configurer leurs appareils de routage en conséquence. Cela s’avère particulièrement utile pour les clients qui n’ont pas de contrôle direct sur leurs appareils de périphérie pour ExpressRoute. Par exemple, lorsque le circuit ExpressRoute est fourni par un opérateur MPLS au-dessus d’un service IPVPN.
Figure 8. Peering privé ExpressRoute en tant que sous-couche SD-WAN. Dans ce scénario, les routeurs côté client et fournisseur reçoivent les routes pour le réseau virtuel qui terminent la connexion ExpressRoute, dans les sessions BGP de peering privé ER et le CPE SD-WAN. Seul ce dernier doit propager les routes Azure au LAN local.
Peering Microsoft
Vous pouvez également utiliser le peering Microsoft ExpressRoute en tant que sous-couche pour les tunnels SD-WAN. Dans ce scénario, les appliances virtuelles réseau du hub SD-WAN dans Azure exposent uniquement les points de terminaison de tunnel public, qui sont utilisés par les deux CPE SD-WAN dans des sites connectés à Internet, le cas échéant, et par des CPE SD-WAN dans des sites connectés à Expressroute. Bien que les conditions préalables du peering Microsoft ExpressRoute soient plus complexes que celles du peering privé, nous recommandons d’utiliser cette option en tant que sous-couche compte tenu des deux avantages suivants :
Il ne nécessite pas de passerelles de réseau virtuel ExpressRoute dans le réseau virtuel hub. Elle supprime la complexité, réduit les coûts et permet à la solution SD-WAN d’évoluer au-delà des limites de bande passante de la passerelle elle-même lorsque vous n’utilisez pas ExpressRoute FastPath.
Il offre une séparation nette entre les routes superposées et les routes sous-jacentes. Les MSEEs annoncent uniquement les préfixes publics du réseau Microsoft à la périphérie du client ou du fournisseur. Vous pouvez gérer ces routes dans un VRF distinct et les propager uniquement vers un segment DMZ du LAN du site. Les appareils SD-WAN propagent les routes pour le réseau d’entreprise du client dans la superposition, y compris les routes pour les réseaux virtuels. Les clients qui envisagent cette approche doivent s’assurer de pouvoir configurer leurs appareils de routage en conséquence ou demander le service approprié à leur opérateur MPLS.
Considérations à propos des MPLS
La migration des réseaux d’entreprise MPLS traditionnels vers des architectures de réseau plus modernes basées sur le paradigme SD-WAN demande des efforts importants et un temps considérable. L’architecture décrite dans cet article permet des migrations SD-WAN par étapes. Deux scénarios de migration classiques sont abordés plus loin.
Désactivation de MPLS par phases
Les clients qui souhaitent créer un SD-WAN sur l’Internet public et le réseau principal Microsoft, et désactiver complètement les IPVPN MPLS ou d’autres services de connectivité dédiés, peuvent consulter le scénario de coexistence ExpressRoute et SD-WAN décrit dans la section précédente pendant la migration. Il permet aux sites connectés à SD-WAN d’atteindre des sites toujours connectés à l’ancien MPLS. Dès qu’un site est migré vers les appareils SD-WAN et CPE, sa liaison MPLS peut être désactivée. Le site peut accéder à l’ensemble du réseau de l’entreprise via ses tunnels SD-WAN vers les régions Azure les plus proches.
Figure 9. Le scénario de « coexistence ExpressRoute et SD-WAN » permet la désactivation de MPLS par phases.
Lorsque tous les sites sont migrés, l’IPVPN MPLS peut être mis hors service, ainsi que les circuits ExpressRoute qui le connectent au réseau principal Microsoft. Les passerelles de réseau virtuel ExpressRoute ne sont plus nécessaires et peuvent être déprovisionnées. Les appliances virtuelles réseau du hub SD-WAN de chaque région deviennent alors le seul point d’entrée dans le réseau en étoile de cette région.
Intégration MPLS
Les organisations qui estiment que les réseaux publics et partagés ne sont pas en mesure de fournir les performances et la fiabilité souhaitées peuvent décider d’utiliser un réseau MPLS existant en tant que réseau sous-jacent de classe entreprise. Deux options se présentent :
- Un sous-ensemble de sites tels que les centres de données ou les grandes succursales.
- Un sous-ensemble de connexions, généralement sensibles à la latence ou dont le trafic est critique.
Le scénario Expressroute en tant que réseau sous-jacent SD-WAN décrit précédemment permet l’intégration SD-WAN et MPLS. Le peering Microsoft ExpressRoute doit être privilégié par rapport au peering privé pour les raisons évoquées précédemment. En outre, lorsque le peering Microsoft est utilisé, le réseau MPLS et l’Internet public deviennent des sous-couches fonctionnellement équivalentes. Ils fournissent un accès à tous les points de terminaison de tunnel SD-WAN exposés par des appliances virtuelles virtuelles hub SD-WAN dans Azure. Un CPE SD-WAN déployé sur un site avec une connectivité Internet et MPLS peut établir plusieurs tunnels vers les hubs SD-WAN dans Azure sur les deux réseaux sous-jacents. Ils peuvent ensuite acheminer différentes connexions à travers différents tunnels, sur la base de politiques au niveau de l’application gérées par le plan de contrôle SD-WAN.
Figure 10. Le scénario « ExpressRoute en tant que sous-couche SD-WAN » permet l’intégration SD-WAN et MPLS.
Préférence de routage du serveur de routes
Dans les deux scénarios MPLS abordés dans les deux sections précédentes, certains sites de succursales peuvent être connectés à la fois à l’IPVPN MPLS et au SD-WAN. Par conséquent, les instances de serveur de routes déployées dans les réseaux virtuels hub peuvent apprendre les mêmes routes à partir des passerelles ExpressRoute et des appliances virtuelles réseau SD-WAN. La préférence de routage du serveur de routes permet de contrôler le chemin à privilégier et à intégrer dans les tables de routes des réseaux virtuels. La préférence de routage est utile lorsque le préfixe AS Path ne peut pas être utilisé. Par exemple, les services IPVPN MPLS qui ne prennent pas en charge les configurations BGP personnalisées sur les PE qui terminent les connexions ExpressRoute.
Considérations relatives aux limites et à la conception du serveur de routes
Le serveur de routes est la pierre angulaire de l’architecture décrite dans cet article. Il propage les routes entre les appliances virtuelles réseau SD-WAN déployées dans des réseaux virtuels et la pile SDN Azure sous-jacente. Il fournit une approche basée sur BGP pour exécuter plusieurs appliances virtuelles réseau SD-WAN pour la haute disponibilité et la scalabilité horizontale. Lors de la conception de SD-WAN de grande envergure basés sur cette architecture, les limites de scalabilité du serveur de routes doivent être prises en compte.
Vous trouverez dans les sections suivantes des conseils sur la scalabilité maximale et sur la façon de gérer chaque limite.
Routes annoncées par un homologue BGP au serveur de routes
Le serveur de routes ne fixe pas de limite explicite au nombre de routes pouvant être annoncées aux passerelles de réseau virtuel ExpressRoute lorsque l’indicateur AllowBranchToBranch est défini. Cependant, les passerelles ExpressRoute propagent les routes qu’elles apprennent du serveur de routes aux circuits ExpressRoute auxquels elles sont connectées.
Le nombre de routes que les passerelles ExpressRoute peuvent annoncer aux circuits ExpressRoute via le peering privé est limité, comme indiqué dans Abonnement Azure et limites, quotas et contraintes du service. Lors de la conception de solutions SD-WAN basées sur les conseils fournis dans cet article, il est essentiel de s’assurer que les routes SD-WAN n’entraînent pas le dépassement de cette limite. Si c’est le cas, les sessions BGP entre les passerelles ExpressRoute et les circuits ExpressRoute sont interrompues et la connectivité entre les réseaux virtuels et les réseaux distants connectés via ExpressRoute est perdue.
Le nombre total de routes annoncées aux circuits par les passerelles ExpressRoute est la somme du nombre de routes apprises du serveur de routes et du nombre de préfixes qui composent l’espace d’adressage du réseau en étoile Azure. Pour éviter les pannes dues à l’interruption de sessions BGP, nous vous recommandons la mise en œuvre des atténuations suivantes :
- Utilisez les fonctionnalités des appareils SD-WAN natifs pour limiter le nombre de routes annoncées au serveur de routes, si cette fonctionnalité est disponible.
- Utilisez les alertes Azure Monitor pour détecter de manière proactive les pics dans le nombre de routes annoncés par les passerelles ExpressRoute. La métrique à surveiller est appelée Nombre de routes publiés auprès du pair, comme indiqué dans la supervision ExpressRoute.
Pairs BGP
Le serveur de routes peut établir des sessions BGP avec un nombre maximum de pairs BGP. Cette limite détermine le nombre maximum des appliances virtuelles réseau SD-WAN qui peuvent établir des contigüités BGP avec le serveur de routes, et donc le débit agrégé maximum qui peut être pris en charge sur tous les tunnels SD-WAN. Seuls les SD-WAN de grande envergure sont censés atteindre cette limite. Il n’existe aucune solution pour la contourner, si ce n’est la création de plusieurs réseaux en étoile, chacun disposant de ses propres passerelles et serveurs de routes.
Participation de machines virtuelles
Les passerelles de réseaux virtuels et les serveurs de routes configurent les routes qu’ils apprennent de leurs homologues distants pour toutes les machines virtuelles de leur propre réseau virtuel et des réseaux virtuels appairés directement. Pour protéger le serveur de routes d’une consommation excessive de ressources due aux mises à jour de routage vers les machines virtuelles, Azure définit une limite pour le nombre de machines virtuelles qui peuvent exister dans un seul réseau en étoile. Il n’existe aucune solution pour la contourner, si ce n’est la création de plusieurs réseaux en étoile, chacun avec ses propres passerelles et serveurs de routage, dans la même région.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Principaux auteurs :
- Federico Guerrini | Architecte senior de solutions cloud
- Khush Kaviraj | Architecte de solutions cloud
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.