Scénario : Homologation BGP avec un hub virtuel
Le routeur de hub Azure Virtual WAN, également appelé routeur de hub virtuel, agit en tant que gestionnaire d’itinéraires et permet de simplifier l’opération de routage dans et entre hubs virtuels. En d’autres termes, un routeur de hub virtuel effectue les opérations suivantes :
- Simplifie la gestion du routage en étant le moteur de routage central qui communique avec les passerelles telles que VPN, ExpressRoute, P2S et les appliances virtuelles réseau (NVA).
- Active les scénarios de routage avancés des tables de routage personnalisées, d’association et de propagation des itinéraires.
- Agit en tant que routeur pour le trafic qui transite entre et vers les réseaux virtuels connectés à un hub virtuel.
À présent, le routeur de hub virtuel offre également la possibilité d’appairer et d’échanger des informations de routage directement via le protocole de routage Border Gateway Protocol (BGP). Une NVA ou un point de terminaison BGP configuré dans un réseau virtuel connecté à un hub virtuel peut être appairé directement avec le routeur de hub virtuel s’il prend en charge le protocole de routage BGP et garantit que l’ASN sur la NVA est configuré pour être différent de l’ASN du hub virtuel.
Avantages et considérations
Principaux avantages
- Vous n’avez plus besoin de mettre à jour manuellement la table de routage sur votre NVA chaque fois que vos adresses de réseau virtuel sont mises à jour.
- Vous n’avez plus besoin de mettre à jour les itinéraires définis par l’utilisateur manuellement, ni de supprimer les anciennes, dès lors que votre NVA en annonce de nouveaux.
- Les NVA dans les réseaux virtuels connectés à un hub virtuel peuvent apprendre les itinéraires de passerelle de hub virtuel (VPN, ExpressRoute ou NVA managées).
- Vous pouvez appairer plusieurs instances de votre NVA avec un routeur de hub virtuel. Vous pouvez configurer des attributs BGP dans votre NVA et, en fonction de votre conception (actif/actif ou actif/passif), laissez le routeur de hub virtuel déterminer quelle instance de NVA est active ou passive.
Considérations
Vous ne pouvez pas appairer un routeur de hub virtuel avec un Serveur de routes Azure approvisionné dans un réseau virtuel.
Le routeur de hub virtuel prend en charge les ASN 16 bits (2 octets) uniquement.
La connexion de réseau virtuel qui possède le point de terminaison de connexion BGP NVA doit toujours être associée et propagée vers defaultRouteTable. Les tables de routage personnalisées ne sont pas prises en charge pour le moment.
Le routeur de hub virtuel prend en charge la connectivité de transit entre les réseaux virtuels connectés aux hubs virtuels. Cette fonctionnalité n’a rien à voir avec le Peering BGP, car Virtual WAN prend déjà en charge la connectivité de transit. Exemples :
- VNET1 : NVA1 connectée au hub virtuel 1 -> (connectivité de transit) -> VNET2 : NVA2 connectée au hub virtuel 1.
- VNET1 : NVA1 connectée au hub virtuel 1 -> (connectivité de transit) -> VNET2 : NVA2 connectée au hub virtuel 2.
Vous pouvez utiliser vos propres numéros ASN publics ou privés dans votre appliance virtuelle réseau. Vous ne pouvez pas utiliser les plages réservées par Azure ou l’IANA. Les ASN suivants sont réservés par Azure ou l’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
- Numéros ASN réservés par Azure :
En échangeant des itinéraires BGP avec votre appliance virtuelle réseau et en les propageant vers votre réseau virtuel, le routeur de hub virtuel facilite directement la diffusion des itinéraires à partir d’un site local par le biais des passerelles hébergées par le hub virtuel (passerelle VPN, ExpressRoute ou d’appliance virtuelle réseau managée).
Le peering BGP est uniquement pris en charge avec une adresse IP affectée à une interface de l’appliance virtuelle réseau. Le peering avec des bouclages n’est pas pris en charge.
Le routeur de hub virtuel présente les limites suivantes :
Ressource Limite Nombre d’itinéraires que chaque pair BGP peut publier sur le hub virtuel. Le hub ne peut accepter qu’un nombre maximal de 10 000 itinéraires (total) à partir de ses ressources connectées. Par exemple, si un hub virtuel a un total de 6 000 itinéraires à partir des réseaux virtuels connectés, des branches, des hubs virtuels, etc., lorsqu’un nouveau Peering BGP est configuré avec une NVA, celle-ci ne peut publier que jusqu’à 4 000 itinéraires. Nombre d’homologues BGP Un maximum de 8 homologues BGP peuvent être connectés à un hub Virtual WAN unique Les itinéraires provenant d’une appliance virtuelle réseau dans un réseau virtuel qui sont plus spécifiques que l’espace d’adressage du réseau virtuel, lorsqu’ils sont publiés sur le hub virtuel via BGP, ne sont pas propagés plus loin localement.
Actuellement, nous prenons uniquement en charge 4 000 routes de l’appliance virtuelle réseau vers le hub virtuel.
Le trafic destiné aux adresses du réseau virtuel directement connectées au hub virtuel ne peut pas être configuré pour être acheminé par le biais de l’appliance virtuelle réseau en utilisant le Peering BGP entre le hub et l’appliance virtuelle réseau. Ceci est dû au fait que le hub virtuel apprend automatiquement les itinéraires système associés aux adresses dans le réseau virtuel spoke lors de la création de la connexion au réseau virtuel spoke. Ces itinéraires système appris automatiquement sont préférés aux itinéraires appris par le hub via BGP.
Le Peering BGP entre une appliance virtuelle réseau (NVA) dans un réseau virtuel spoke et un hub virtuel sécurisé (hub avec une solution de sécurité intégrée) est pris en charge si l’intention de routage est configurée sur le hub. La fonctionnalité Peering BGP n’est pas prise en charge pour des hubs virtuels sécurisés où l’intention de routage n’est pas configurée.
Pour que l’appliance virtuelle réseau échange des itinéraires avec des sites connectés VPN et ER, le routage de branche à branche doit être activé.
Lors de la configuration du Peering BGP avec le hub, vous voyez deux adresses IP. Le peering avec ces deux adresses est obligatoire. Si aucun peering n’est établi avec les deux adresses, des problèmes de routage peuvent se produire. Les mêmes itinéraires doivent être annoncés à ces deux adresses. Annoncer des itinéraires différents causera des problèmes de routage.
L’adresse IP du tronçon suivant sur les routes en cours de publication de l’appliance virtuelle réseau vers le serveur de routage de hub virtuel doit être identique à l’adresse IP de l’appliance virtuelle réseau, l’adresse IP configurée sur le pair BGP. La publication d’une adresse IP différente comme tronçon suivant N’est PAS prise en charge sur le WAN virtuel pour le moment.
Scénarios de Peering BGP
Cette section décrit les scénarios dans lesquels la fonctionnalité de Peering BGP peut être utilisée pour configurer le routage.
Connectivité de réseau virtuel de transit
Dans ce scénario, le hub virtuel nommé « Hub 1 » est connecté à plusieurs réseaux virtuels. L’objectif est d’établir un routage entre les réseaux virtuels VNET1 et VNET5.
Étapes de configuration sans Peering BGP
Les étapes suivantes sont requises lorsque le Peering BGP n’est pas utilisé sur le hub virtuel :
Configuration du hub virtuel
- Dans la table defaultRouteTable du Hub 1, configurez l’itinéraire statique pour VNET5 (sous-réseau 10.2.1.0/24) pointant vers la connexion VNET2.
- Sur la connexion de réseau virtuel du Hub 1 pour VNET2, configurez l’itinéraire statique pour VNET5 pointant vers l’adresse IP de la NVA de VNET2 (sous-réseau 10.2.0.5).
- Sur Hub 1, propagez les itinéraires des connexions pour VNET1 et VNET2 vers defaultRouteTable, puis associez-les à defaultRouteTable.
Configuration du réseau virtuel
- Sur VNET5, configurez un itinéraire défini par l’utilisateur (UDR) pour qu’il pointe vers l’adresse IP de la NVA de VNET2.
Étapes de configuration avec Peering BGP
Dans la configuration précédente, la maintenance des itinéraires statiques et des UDR peut devenir complexe si la configuration de VNET5 change fréquemment. Pour résoudre ce problème, la fonctionnalité de Peering BGP avec un hub virtuel peut être utilisée et la configuration du routage doit être modifiée en suivant les étapes suivantes :
Configuration du hub virtuel
- Sur Hub 1, configurez la NVA de VNET2 en tant que pair BGP. Configurez également la NVA de VNET2 pour obtenir un Peering BGP avec Hub 1.
- Sur Hub 1, propagez les itinéraires des connexions pour VNET1 et VNET2 vers defaultRouteTable, puis associez-les à defaultRouteTable.
Configuration du réseau virtuel
- Sur VNET5, configurez un itinéraire défini par l’utilisateur (UDR) pour qu’il pointe vers l’adresse IP de la NVA de VNET2.
Itinéraires effectifs
Le tableau suivant montre quelques entrées des itinéraires effectifs de Hub 1 dans defaultRouteTable. Notez que l’itinéraire pour VNET5 (sous-réseau 10.2.1.0/24). Il confirme que VNET1 et VNET5 pourront communiquer entre eux.
| Préfixe de destination | Tronçon suivant | Origine | Chemin ASN |
|---|---|---|---|
| 10.2.0.0/24 | eastusconn | ID de connexion du réseau virtuel | - |
| 10.2.1.0/24 | ID de connexion de pair BGP pour NVA | ID de connexion de pair BGP pour NVA | 65510 |
| 10.4.1.0/24 | Hub 2 | Hub 2 | - |
Cette configuration du routage à l’aide de la fonctionnalité supprime la nécessité d’entrées d’itinéraires statiques sur le hub virtuel. Par conséquent, la configuration est plus simple et les tables de routage sont mises à jour de manière dynamique lorsque la configuration des réseaux virtuels connectés (comme VNET5) change.
Connectivité de réseau virtuel de branche
Dans ce scénario, le site local nommé « NVA Branch 1 » a un VPN configuré pour se terminer sur la NVA de VNET2. L’objectif est de configurer le routage entre la NVA branche 1 et le réseau virtuel VNET1.
Étapes de configuration sans Peering BGP
Les étapes suivantes sont requises lorsque le Peering BGP n’est pas utilisé sur le hub virtuel :
Configuration du hub virtuel
- Dans la table defaultRouteTable du Hub 1, configurez l’itinéraire statique pour NVA Branch 1 pointant vers la connexion VNET2.
- Sur la connexion de réseau virtuel du Hub 1 pour VNET2, configurez l’itinéraire statique pour NVA Branch 1 pointant vers l’adresse IP de la NVA de VNET2 (10.2.0.5).
- Sur Hub 1, propagez les itinéraires des connexions pour VNET1 et VNET2 vers defaultRouteTable, puis associez-les à defaultRouteTable.
Configuration du réseau virtuel
- Peering BGP entre NVA de VNET2 et NVA Branch 1, et publications d’itinéraires pour VNET1 de NVA de VNET2 sur NVA Branch 1.
Étapes de configuration avec Peering BGP
Au fil du temps, les préfixes de destination dans NVA Branch 1 peuvent changer. Il peut également y avoir de nombreux sites comme NVA Branch 1 qui ont besoin d’une connectivité à VNET1. Cela entraînerait la nécessité de mettre à jour les itinéraires statiques sur le Hub 1 et la connexion VNET2, ce qui peut devenir fastidieux. Dans ce cas, nous pouvons utiliser la fonctionnalité de Peering BGP avec un hub virtuel. Les étapes de configuration de la connectivité de routage seraient alors les suivantes.
Configuration du hub virtuel
- Sur Hub 1, configurez la NVA de VNET2 en tant que pair BGP. Configurez également la NVA de VNET2 pour obtenir un Peering BGP avec Hub 1.
- Sur Hub 1, propagez les itinéraires des connexions pour VNET1 et VNET2 vers defaultRouteTable, puis associez-les à defaultRouteTable.
Configuration du réseau virtuel
- Peering BGP entre NVA de VNET2 et NVA Branch 1, et publications d’itinéraires pour VNET1 de NVA de VNET2 sur NVA Branch 1.
Itinéraires effectifs
Le tableau ci-dessous montre quelques entrées des itinéraires effectifs de Hub 1 dans defaultRouteTable. Notez que l’itinéraire pour NVA Branch 1 (sous-réseau 192.168.1.0/24) est appris via le Peering BGP avec la NVA.
| Préfixe de destination | Tronçon suivant | Origine | Chemin ASN |
|---|---|---|---|
| 10.2.0.0/24 | eastusconn | ID de connexion du réseau virtuel | - |
| 192.168.1.0/24 | ID de connexion de pair BGP pour NVA | ID de connexion de pair BGP pour NVA | 65510 |
Pour gérer les changements de réseau dans NVA Branch 1 ou pour établir une connectivité entre de nouveaux sites comme NVA Branch 1, aucune configuration supplémentaire n’est requise sur Hub 1, car le Peering BGP entre Hub 1 et NVA met à jour les tables de routage de manière dynamique. La configuration et la maintenance sont donc simplifiées.