Résoudre les problèmes liés à Azure Route Server
Découvrez comment résoudre certains des problèmes courants liés au Serveur de routes Azure.
Problèmes de connectivité
Pourquoi mon appliance virtuelle de réseau (NVA) rencontre-t-elle des problèmes d’accès à Internet après avoir publié l’itinéraire par défaut (0.0.0.0/0) sur le Serveur de routes ?
Lorsque votre NVA publie l’itinéraire par défaut, le Serveur de routes la programme pour toutes les machines virtuelles du réseau virtuel, y compris la NVA elle-même. Cet itinéraire par défaut définit la NVA comme tronçon suivant pour tout le trafic Internet. Si votre NVA a besoin d’une connexion Internet, vous devez configurer un itinéraire défini par l’utilisateur (UDR) pour remplacer cet itinéraire par défaut de la NVA et joindre l’UDR au sous-réseau sur lequel la NVA est hébergée. Sinon, l’ordinateur hôte NVA continue d’envoyer le trafic Internet, y compris celui envoyé par la NVA à elle-même. Pour plus d’informations, consultez Itinéraires définis par l’utilisateur.
| Routage | Tronçon suivant |
|---|---|
| 0.0.0.0/0 | Internet |
Pourquoi la NVA perd-elle sa connectivité au Serveur de routes après avoir forcé tout le trafic vers un pare-feu à l’aide d’un itinéraire défini par l’utilisateur (UDR) sur GatewaySubnet ?
Si vous souhaitez inspecter votre trafic local à l’aide d’un pare-feu, vous pouvez forcer tout le trafic local vers le pare-feu à l’aide d’un itinéraire défini par l’utilisateur (UDR) sur GatewaySubnet (table de routage associée au GatewaySubnet qui a l’UDR). Toutefois, cette UDR peut interrompre la communication entre le Serveur de routes et la passerelle en forçant leur trafic de plan de contrôle (BGP) au pare-feu (ce problème se produit si vous inspectez le trafic destiné au réseau virtuel qui a le Serveur de routes). Pour éviter ce problème, vous devez ajouter un autre UDR à la table de routage GatewaySubnet afin d’exclure le trafic du plan de contrôle d’être forcé vers le pare-feu (au cas où l’ajout d’une règle BGP au pare-feu n’est pas souhaité/possible) :
| Routage | Tronçon suivant |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | VirtualNetwork |
10.0.0.0/16 est l’espace d’adressage du réseau virtuel et 10.0.1.0/27 est l’espace d’adressage de RouteServerSubnet. 10.0.2.1 est l’adresse IP du pare-feu.
J’ai ajouté un itinéraire défini par l’utilisateur (UDR) avec le type de tronçon suivant comme passerelle réseau virtuel, mais cet UDR ne prend pas effet. Est-ce normal ?
Oui. Ce comportement est normal. Les itinéraires définis par l’utilisateur avec le type de tronçon suivant Passerelle réseau virtuel ne sont pas pris en charge pour les sous-réseaux dans le réseau virtuel Serveur de routes et les réseaux virtuels appairés. Toutefois, si vous souhaitez configurer votre tronçon suivant comme appliance virtuelle réseau (NVA) ou Internet, l’ajout d’un itinéraire défini par l’utilisateur avec le type de tronçon suivant VirtualAppliance ou Internet est pris en charge.
Dans les itinéraires effectifs de l’interface réseau de ma machine virtuelle, pourquoi ai-je un itinéraire défini par l’utilisateur (UDR) avec le type de tronçon suivant défini sur Aucun ?
Si vous publiez un itinéraire de votre appliance virtuelle réseau (NVA) vers le serveur de routage qui correspond exactement au préfixe d’un autre itinéraire défini par l’utilisateur, le tronçon suivant de l’itinéraire publié doit être valide. Si le tronçon suivant publié est un équilibreur de charge sans pool principal configuré, cet itinéraire non valide est prioritaire sur l’itinéraire défini par l’utilisateur. Dans les itinéraires effectifs de votre interface réseau, l’itinéraire annoncé non valide s’affiche en tant qu’itinéraire défini par l’utilisateur avec le type de tronçon suivant défini sur Aucun.
Pourquoi est-ce que je perds la connectivité après l’association d’une stratégie de point de terminaison de service à RouteServerSubnet ou GatewaySubnet ?
Si vous associez une stratégie de point de terminaison de service à RouteServerSubnet ou GatewaySubnet, la communication peut être interrompue entre la plateforme de gestion sous-jacente d’Azure et ces services Azure respectifs (Serveur de routes et passerelle VPN/ExpressRoute). Cela peut entraîner l’entrée de ces ressources Azure dans un état non sain, entraînant une perte de connectivité entre vos charges de travail locales et Azure.
Pourquoi est-ce que je perds la connectivité après avoir utilisé le DNS personnalisé au lieu du DNS par défaut (DNS fourni par Azure) pour le réseau virtuel du serveur de routes ?
Pour le réseau virtuel dans lequel le serveur de routes est déployé, si vous n’utilisez pas le DNS par défaut (fourni par Azure), vérifiez que votre configuration DNS personnalisée est en mesure de résoudre les noms de domaine public. De cette façon, vous êtes assuré que les services Azure (serveur de routes et passerelle VPN/ExpressRoute) peuvent communiquer avec le plan de gestion sous-jacent d’Azure. Consultez la note relative aux règles génériques dans la documentation Azure DNS Private Resolver.
Pourquoi est-ce que je ne parviens pas à effectuer un test ping TCP depuis ma NVA vers l’adresse IP de l’homologue BGP sur le Serveur de routes après avoir configuré les homologations BGP entre elles ?
Dans certaines NVA, vous devez ajouter un itinéraire statique au sous-réseau du Serveur de routes pour pouvoir effectuer un test ping TCP sur le Serveur de routes à partir de la NVA et éviter le bagottement de l’homologation BGP. Par exemple, si le Serveur de routes est dans la plage 10.0.255.0/27 et que votre NVA se trouve dans la plage 10.0.1.0/24, vous devez ajouter l’itinéraire suivant à la table de routage dans la NVA :
| Routage | Tronçon suivant |
|---|---|
| 10.0.255.0/27 | 10.0.1.1 |
10.0.1.1 est l’adresse IP de passerelle par défaut dans le sous-réseau où votre NVA (ou plus précisément, une des cartes réseau) est hébergée.
Pourquoi est-ce que je perds la connectivité à mon réseau local via ExpressRoute et/ou VPN Azure lorsque je déploie un Serveur de routes sur un réseau virtuel qui possède déjà la passerelle ExpressRoute et/ou la passerelle VPN Azure ?
Lorsque vous déployez un Serveur de routes sur un réseau virtuel, nous devons mettre à jour le plan de contrôle entre les passerelles et le réseau virtuel. Pendant cette mise à jour, les machines virtuelles du réseau virtuel perdent temporairement leur connectivité au réseau local. Nous vous recommandons vivement de planifier une maintenance pour déployer un Serveur de routes dans votre environnement de production.
Problèmes liés au plan de contrôle
Pourquoi mon réseau local connecté à une passerelle VPN Azure ne reçoit-il pas l’itinéraire par défaut publié par le Serveur de routes ?
Bien que la passerelle VPN Azure puisse recevoir l’itinéraire par défaut à partir de ses homologues BGP, y compris le Serveur de routes, elle ne publie pas l’itinéraire par défaut vers d’autres homologues.
Pourquoi ma NVA ne reçoit-elle pas d’itinéraires du Serveur de routes même si l’homologation BGP est opérationnelle ?
L’ASN utilisé par le Serveur de routes est 65515. Veillez à configurer un autre ASN pour votre NVA afin qu’une session eBGP puisse être établie entre votre NVA et Serveur de routes afin que la propagation des itinéraires puisse se produire automatiquement. Veillez à activer « multi-hop » dans votre configuration BGP, car votre NVA et le Serveur de routes se trouvent dans des sous-réseaux différents du réseau virtuel.
L’homologation BGP entre ma NVA et le Serveur de routes est opérationnelle. Je peux voir des routes correctement échangées entre eux. Pourquoi les routes de la NVA ne se trouvent-elles pas dans la table de routage effective de ma machine virtuelle ?
Si votre machine virtuelle se trouve dans le même réseau virtuel que votre NVA et le Serveur de routes :
Le Serveur de routes expose deux adresses IP d’homologue BGP, qui sont hébergées sur deux machines virtuelles partageant la responsabilité d’envoyer des itinéraires à toutes les autres machines virtuelles exécutées sur votre réseau virtuel. Chaque NVA doit configurer deux sessions BGP identiques (par exemple, utiliser le même numéro AS, le même chemin AS et publier le même ensemble d’itinéraires) sur les deux machines virtuelles afin que vos machines virtuelles sur le réseau virtuel puissent recevoir des informations de routage cohérentes à partir du Serveur de routes Azure.
Si vous avez deux instances de la NVA ou plus, vous pouvez publier différents chemins AS pour la même route à partir de différentes instances d’appliance virtuelle réseau si vous souhaitez désigner une instance de NVA comme étant active et une autre comme étant passive.
Si votre machine virtuelle se trouve sur un autre réseau virtuel que celui qui héberge votre NVA et le Serveur de routes. Vérifiez si le peering de réseaux virtuels est activé entre les deux réseaux virtuels et si l’option Utiliser le Serveur de routes distant est activée sur le réseau virtuel de votre machine virtuelle.
Pourquoi la fonction ECMP (Equal-Cost Multi-Path) de mon ExpressRoute est-elle désactivée après le déploiement du Serveur de routes vers le réseau virtuel ?
Lorsque vous publiez les mêmes itinéraires de votre réseau local vers Azure sur plusieurs connexions ExpressRoute, normalement, ECMP est activé par défaut pour le trafic destiné à ces itinéraires d’Azure vers votre réseau local. Actuellement, lorsque vous déployez le Serveur de routes, les informations de chemins d’accès multiples sont perdues dans l’échange BGP entre ExpressRoute et le Serveur de routes, de sorte que le trafic à partir d’Azure traverse uniquement l’une des connexions ExpressRoute.
Étape suivante
Pour savoir comment créer et configurer le Serveur de routes Azure, consultez :