Optimiser le routage ExpressRoute

En présence de plusieurs circuits ExpressRoute, vous pouvez vous connecter à Microsoft par le biais de plusieurs chemins d’accès. Par conséquent, le routage pourrait ne pas être optimal. Autrement dit, votre trafic peut emprunter un chemin d’accès plus long pour atteindre Microsoft ; Microsoft peut faire de même pour atteindre votre réseau. Plus le chemin d’accès réseau est long, plus la latence est élevée. La latence a un impact direct sur les performances d’application ainsi que sur l’expérience utilisateur. Cet article aborde ce problème et explique comment optimiser le routage à l’aide des technologies de routage standard.

Sélection du chemin pour le Peering Microsoft

Il est important de s’assurer que lors de l’utilisation du Peering Microsoft, le trafic transite par le chemin souhaité si vous disposez d’au moins un circuit ExpressRoute. Vous devez également vous assurer que les chemins d’accès à Internet utilisent un internet Exchange (IX) ou un fournisseur de services Internet (ISP). BGP utilise un algorithme de sélection de chemin optimal basé sur un certain nombre de facteurs, notamment la correspondance de préfixe la plus longue (LPM). Pour vous assurer que le trafic destiné à Azure à travers Microsoft traverse le chemin ExpressRoute, vous devez implémenter l’attribut Préférence locale. Ce paramètre garantit que le chemin d’accès est toujours préféré sur ExpressRoute.

Notes

La préférence locale par défaut est généralement 100. Les préférences locales plus élevées sont privilégiées.

Examinez l’exemple de scénario suivant :

Dans l’exemple ci-dessus, pour préférer les chemins ExpressRoute, configurez la préférence locale comme suit.

Configuration Cisco IOS-XE du point de vue R1 :

• R1(config)#route-map prefer-ExR permit 10

• R1(config-route-map)#set local-preference 150

• R1(config)#router BGP 345

• R1(config-router)#neighbor 1.1.1.2 remote-as 12076

• R1(config-router)#neighbor 1.1.1.2 activate

• R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in

Configuration Junos du point de vue R1 :

• user@R1# set protocols bgp group ibgp type internal
• user@R1# set protocols bgp group ibgp local-preference 150

Routage non optimal entre le client et Microsoft

Voici un exemple de problème de routage. Imaginez que vous disposez de deux bureaux aux États-Unis, un à Los Angeles et un à New York. Vos bureaux sont connectés sur un réseau étendu (WAN), qui peut être votre propre réseau principal ou le VPN IP de votre fournisseur de services. Vous disposez de deux circuits ExpressRoute, l’un dans USA Ouest et l’autre dans USA Est. Les deux sont également connectés sur le WAN. Vous avez bien évidemment deux chemins d’accès pour vous connecter au réseau Microsoft.

Imaginez à présent que vous déployiez un service Azure (par exemple, Azure App Service) dans les régions USA Ouest et USA Est. Vous voulez donc connecter les utilisateurs de Los Angeles à la région Azure USA Ouest et les utilisateurs de New York à la région Azure USA Est. La raison de cette configuration est que votre administrateur de service annonce que les utilisateurs de chaque bureau accèdent aux services Azure à proximité pour des expériences optimales. Malheureusement, le plan fonctionne bien pour les utilisateurs de la côte Est, mais pas pour ceux de la côte Ouest.

La raison de ce problème et que sur chaque circuit ExpressRoute, nous publions le préfixe 23.100.0.0/16 dans la région Azure USA Est et le préfixe 13.100.0.0/16 dans la région Azure USA Ouest. Si vous ne savez pas à quelle région correspond chaque préfixe, vous ne pourrez pas le traiter différemment. Votre réseau WAN peut penser que les deux préfixes sont plus proches des régions USA Est et USA Ouest et donc router les utilisateurs des deux bureaux vers le circuit ExpressRoute dans la région USA Est. Au final, vous risquez d’avoir des utilisateurs mécontents dans vos bureaux de Los Angeles.

Solution : utilisez des communautés BGP

Pour optimiser le routage pour les utilisateurs des deux bureaux, vous devez savoir faire la différence entre le préfixe de la région Azure USA Ouest et celui de la région Azure USA Est. Nous encodons ces informations à l’aide des valeurs de communauté BGP. Nous avons affecté une valeur de Communauté BGP unique à chaque région Azure, par exemple 12076:51004 pour USA Est et 12076:51006 pour USA Ouest. À présent que vous savez à quelles régions Azure correspondent les préfixes, vous pouvez configurer les préférences de circuit ExpressRoute. Étant donné que nous utilisons le protocole BGP pour échanger des informations de routage, vous pouvez utiliser les préférences locales du protocole BGP pour influencer le routage.

Dans notre exemple, vous pouvez affecter, dans la région USA Ouest, une valeur de préférence locale supérieure à celle de la région USA Est (13.100.0.0/16) et vice-versa dans la région USA Est (23.100.0.0/16). Cette configuration permet de garantir que, lorsque les deux chemins d’accès à Microsoft sont disponibles, vos utilisateurs de Los Angeles prendront le circuit ExpressRoute dans la région USA Ouest pour se connecter à Azure dans cette région, tandis que vos utilisateurs de New York prendront le circuit ExpressRoute dans la région USA Est vers Azure dans cette région. Le routage est optimisé des deux côtés.

Notes

La même technique peut être appliquée pour le routage entre le client et le réseau virtuel Azure, en utilisant les préférences locales lors de l’utilisation du peering privé. Microsoft ne balise par les valeurs de communauté BGP sur les préfixes publiés à partir d’Azure sur votre réseau. Toutefois, étant donné que vous savez à quel déploiement de réseau virtuel correspond quel bureau, vous pouvez configurer vos routeurs en conséquence pour privilégier un circuit ExpressRoute plutôt qu’un autre.

Routage non optimal entre Microsoft et le client

Voici un autre exemple dans lequel les connexions en provenance de Microsoft prennent un chemin plus long pour atteindre votre réseau. Dans ce cas, vous utilisez des serveurs Exchange locaux et Exchange Online dans un environnement hybride. Vos bureaux sont connectés à un réseau étendu. Vous publiez vers Microsoft les préfixes des serveurs locaux de vos deux bureaux par le biais des deux circuits ExpressRoute.

Dans certains cas, tels que la migration de boîte aux lettres, Exchange Online lance les connexions aux serveurs locaux. La connexion à votre bureau de Los Angeles est routée au circuit ExpressRoute dans la région USA Est, puis retraverse l’ensemble du pays avant d’atteindre la côte ouest. L’origine du problème est similaire au premier cas. En l’absence d’indicateur, le réseau Microsoft ne peut pas déterminer quel préfixe est le plus proche de USA Est et USA Ouest. Malheureusement, il choisit le mauvais chemin vers votre bureau de Los Angeles.

Solution : ajoutez le préfixe AS PATH

Il existe deux solutions à ce problème. La première étape est de publier votre préfixe locale pour votre bureau de Los Angeles 177.2.0.0/31 sur le circuit ExpressRoute dans USA Ouest. Ensuite, vous publiez votre préfixe local pour votre bureau de New York, 177.2.0.2/31 sur le circuit ExpressRoute dans USA Est. Par conséquent, Microsoft ne dispose que d’un seul chemin d’accès pour se connecter à chacun de vos sites. Il n’existe aucune ambiguïté et le routage est optimisé. Avec cette conception, vous devez réfléchir à votre stratégie de basculement. Dans le cas où le chemin d’accès à Microsoft via ExpressRoute est interrompu, vous devez vous assurer qu’Exchange Online peut toujours se connecter à vos serveurs locaux.

La deuxième solution est de continuer à publier les deux préfixes sur les deux circuits ExpressRoute, tout en nous indiquant quel préfixe correspond à chacun de vos bureaux. Étant donné que nous prenons en charge l’ajout de préfixe AS PATH BGP, vous pouvez configurer l’AS PATH pour influencer le routage. Dans cet exemple, vous pouvez allonger le chemin AS PATH pour 172.2.0.0/31 dans la région USA Est pour que nous privilégiions le circuit ExpressRoute dans la région USA Ouest pour le trafic destiné à ce préfixe. De même, vous pouvez allonger le chemin AS PATH pour 172.2.0.2/31 dans la région USA Ouest pour que nous privilégiions le circuit ExpressRoute dans la région USA Est. Le routage est optimisé pour les deux bureaux. Grâce à cette conception, si un circuit ExpressRoute est défaillant, Exchange Online peut toujours vous joindre via un autre circuit ExpressRoute ainsi que par le biais de votre réseau étendu.

Important

Nous supprimons les numéros AS privés dans le chemin AS PATH pour les préfixes reçus dans le cadre de l’appairage Microsoft lors d’un appairage avec un numéro AS privé. Vous devez effectuer un appairage avec un numéro AS public et ajouter des numéros AS publics au chemin AS PATH pour influencer le routage pour l’appairage Microsoft.

Remarque

Bien que les exemples fournis ici s’appliquent au Peering Microsoft, nous prenons en charge les mêmes fonctionnalités pour le Peering privé. En outre, le préfixe AS Path fonctionne au sein d’un même circuit ExpressRoute pour influencer la sélection des chemins principaux et secondaires.

Routage non optimal entre des réseaux virtuels

Avec ExpressRoute, vous pouvez établir une communication réseau virtuel-réseau virtuel (également appelée « VNet ») en les reliant à un circuit ExpressRoute. Lorsque vous les reliez à plusieurs circuits ExpressRoute, un routage non optimal peut se produire entre les réseaux virtuels. Prenons un exemple. Vous disposez de deux circuits ExpressRoute, l’un dans USA Ouest et l’autre dans USA Est. Dans chaque région, vous avez deux réseaux virtuels. Vos serveurs web sont déployés sur un réseau virtuel et les serveurs d’applications sur l’autre. À des fins de redondance, vous reliez les deux réseaux virtuels de chaque région à la fois au circuit ExpressRoute local et au circuit ExpressRoute distant. Comme illustré ci-dessous, chaque réseau virtuel est doté de deux chemins d’accès menant vers l’autre réseau virtuel. Les réseaux virtuels ne font pas la distinction entre le circuit ExpressRoute local et le circuit ExpressRoute distant. Étant donné que le routage ECMP (Equal-cost multi-path routing) est utilisé pour équilibrer la charge du trafic entre les réseaux virtuels, certains flux de trafic emprunteront le chemin le plus long et seront routés au niveau du circuit ExpressRoute distant.

Solution : attribuer plus de poids à la connexion locale

La solution est simple. Étant donné que vous savez où se trouvent les réseaux virtuels et les circuits, vous pouvez nous indiquer le chemin à privilégier pour chaque réseau virtuel. Spécifiquement pour cet exemple, vous attribuez plus de poids à la connexion locale qu’à la connexion à distance (consultez l’exemple de configuration ici). Lorsqu’un réseau virtuel reçoit le préfixe de l’autre réseau virtuel sur plusieurs connexions, il préfère la connexion avec le plus de poids pour envoyer le trafic destiné à ce préfixe.

Notes

Vous pouvez également modifier le routage entre le réseau virtuel et votre réseau sur site, si vous disposez de plusieurs circuits ExpressRoute, en configurant le poids attribué à une connexion au lien d’ajouter un préfixe AS PATH, technique décrite dans le second scénario ci-dessus. Pour chaque préfixe, nous examinerons toujours le poids attribué à la connexion avant la longueur du chemin AS pour décider du mode d’envoi du trafic.

Étapes suivantes

• Découvrez comment concevoir ExpressRoute pour la haute disponibilité.
• Apprenez-en davantage sur la conception ExpressRoute pour la récupération d’urgence.