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 réseau perd-elle la connectivité Internet après qu’elle publie l’itinéraire par défaut (0.0.0.0/0) vers le serveur de routage ?
Lorsque votre appliance virtuelle réseau publie l’itinéraire par défaut, le serveur de routage le programme pour toutes les machines virtuelles du réseau virtuel, y compris l’appliance virtuelle 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 l’appliance virtuelle réseau perd-elle sa connectivité au serveur de routage 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.
Pourquoi ne puis-je pas effectuer un test ping TCP de mon appliance virtuelle réseau vers l’adresse IP de l’homologue BGP du serveur de routage après avoir configuré le peering BGP entre eux ?
Dans certains appliances virtuelles réseau, vous devez ajouter un itinéraire statique au sous-réseau du serveur de routage pour pouvoir effectuer un test TCP ping sur le serveur de routage à partir de l’appliance virtuelle réseau et éviter le flapping de peering BGP. Par exemple, si le serveur de routage est dans la version 10.0.255.0/27 et que votre appliance virtuelle réseau est dans la version 10.0.1.0/24, vous devez ajouter l’itinéraire suivant à la table de routage dans l’appliance virtuelle réseau :
| 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 perdre la connectivité à mon réseau local via ExpressRoute et/ou VPN Azure quand je déploie un serveur de routage sur un réseau virtuel qui a déjà une passerelle ExpressRoute et/ou une passerelle VPN Azure ?
Lorsque vous déployez un serveur de routage 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 la maintenance pour déployer un serveur de routage dans votre environnement de production.
Problèmes liés au plan de contrôle
Pourquoi mon réseau local connecté à la passerelle VPN Azure ne reçoit-il pas l’itinéraire par défaut publié par le serveur de routage ?
Bien que la passerelle VPN Azure puisse recevoir l’itinéraire par défaut de ses homologues BGP, y compris le serveur de routage, 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 routage même si le peering BGP est en cours ?
L’ASN que le serveur de routage utilise est 65515. Veillez à configurer un autre ASN pour votre appliance virtuelle réseau afin qu’une session eBGP puisse être établie entre votre appliance virtuelle réseau et votre serveur de routage afin que la propagation de l’itinéraire puisse se produire automatiquement. Veillez à activer « multi-tronçon » dans votre configuration BGP, car votre appliance virtuelle réseau et le serveur de routage se trouvent dans différents sous-réseaux du réseau virtuel.
Le peering BGP entre ma NVA et le serveur de routage est en cours. Je peux voir des routes correctement échangées entre eux. Pourquoi les routes de la NVA ne sont-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 appliance virtuelle réseau et votre serveur de routage :
Le serveur de routage expose deux adresses IP homologues BGP, qui sont hébergées sur deux machines virtuelles qui partagent la responsabilité d’envoyer les itinéraires à toutes les autres machines virtuelles exécutées dans 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 dans un réseau virtuel différent de celui qui héberge votre appliance virtuelle réseau et le serveur de routage. 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 routage sur 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 routage, les informations sur plusieurs chemins sont perdues dans l’échange BGP entre ExpressRoute et le serveur d’itinéraires, et par conséquent, le trafic d’Azure traverse uniquement l’une des connexions ExpressRoute.
Étape suivante
Pour savoir comment créer et configurer le Serveur de routes Azure, consultez :