Lorsqu'il s'agit de migrer une infrastructure réseau, de nombreuses entreprises sont confrontées au défi de garantir la continuité de leurs activités tout en minimisant les interruptions de service.

Avec la nécessité d’avoir des transitions aussi transparentes que possible, influencer temporairement le routage des flux en jouant sur la précision des routes permet de favoriser certains chemins réseau pendant que d’autres sont migrés ou modifiés.

Dans cet article, je vous présente un cas simple de migration réseau dans AWS entre deux Transit Gateway faisant office de passerelle entre un réseau privé virtuel et des bureaux reliés par VPN.

Un routeur, ça gère des routes et ça transfère des millions de petits paquets sur ce qui lui paraît être la meilleure route pour atteindre une destination.

Jusqu’ici je ne vous apprends rien.

Mais comment déterminer quelle est la “meilleure” route ? 🤔

Le premier critère est le plus souvent le niveau de précision de la route. Plus une route désigne un petit nombre d’IP de destination, plus elle est précise.

Parmi les autres critères possibles, on peut trouver la méthode d’apprentissage de la route (statique ou dynamique), le débit du lien et sa qualité, etc. Évidemment, un critère de choix est l’état de la route. Si le routeur désigné par la route la plus précise ne répond plus, il va falloir se rabattre sur une autre route qui sera peut-être moins précise, mais fonctionnelle.

C’est exactement sur ces paramètres que nous allons jouer pour privilégier des routes plutôt que d’autres.

Voici un schéma de notre infrastructure d’un classicisme absolu 😉

On y retrouve un réseau (VPC) contenant deux sous-réseaux (1 privé et 1 public), relié à nos bureaux via un VPN rattaché à une Transit Gateway.

Notre objectif est de remplacer la Transit Gateway ainsi que le VPN, car nous avons accumulé de la dette technique sur cette infrastructure et il est plus efficace de la reconstruire. Cependant ; nous devons faire cela sans interruption de service, car chaque paquet est précieux 😁

La première étape est de construire la nouvelle infrastructure sans modifier le routage actuel.

On crée donc une nouvelle Transit Gateway avec son attachement distinct au VPC et un nouveau tunnel VPN jusqu’à nos bureaux. Tant que nous ne mettons pas à jour la table de routage du VPC et celle du routeur On Premise, les flux empruntent toujours l’ancien chemin.

À ce stade, si nous changeons la route côté VPC pour désigner la nouvelle Transit Gateway et que l’équipe en charge des routeurs On Premise fait de même, nous allons avoir une interruption. Il n’est pas possible de modifier une route dans un VPC, il faut la supprimer puis en créer une nouvelle. Mais le réseau va vite, très vite et pendant le laps de temps où il n’y aura plus de route, des paquets seront perdus et des sessions coupées.

Afin de contourner ce problème, nous allons nous assurer que l’ancienne Transit Gateway reste prioritaire sur la nouvelle jusqu’à ce que nous ayons fini de la mettre en place. Cela va se traduire par la création de deux routes temporaires dans notre table de routage de VPC présentant la plage IP de nos bureaux en deux sous-ensembles. Ainsi, chaque sous-ensemble contenant la moitié des IP, ces routes seront plus précises que celle englobant tout notre réseau.

Maintenant que nous sommes assurés que ces deux routes temporaires vont être privilégiées pour le routage de notre trafic, nous allons pouvoir modifier la route “globale” pour que cette dernière désigne la nouvelle Transit Gateway sans impacter les flux.

Nous sommes maintenant prêts à basculer le trafic entre les deux Transit Gateway. Les deux prochaines étapes peuvent être réalisées dans n’importe quel ordre.

Pour initier la bascule, nous allons modifier les routes côté routeur On Premise pour qu’il envoie le trafic à destination de notre VPC privé dans AWS au travers du tunnel VPN porté par la nouvelle Transit Gateway.

Nous nous retrouvons donc à présent avec un routage asymétrique, ce qui n’est pas toujours idéal, mais dans notre cas, c'est temporaire (on va se méfier du temporaire qui dure, donc on va y remédier au plus vite 😉). Pour cela, il nous suffit de supprimer les deux routes temporaires que nous avions ajoutées dans la table de routage de notre VPC.

À ce moment, le trafic est intégralement redirigé dans les deux sens au travers de la nouvelle Transit Gateway.

Après quelques tests pour vous assurer qu’aucune route n’a été perdue dans l’opération, il ne reste plus qu’à faire un peu de nettoyage.

Le principe qui privilégie les routes précises est très commun et on le retrouve évidemment dans le fonctionnement du service AWS Transit Gateway. En revanche, le fonctionnement de la bascule entre deux routes de précision inégale avec la Transit Gateway diffère du fonctionnement des routeurs traditionnels.

Un routeur classique, si une route ne fonctionne plus, va automatiquement vérifier parmi les autres routes qu’il connaît si une ou plusieurs d’entre elles permettent également de joindre la destination, puis y transférer le trafic.

Une Transit Gateway, non. Et c’est très probablement pour cette raison que ce service n’est pas présenté comme un routeur virtuel. Une Transit Gateway associe un statut à chaque route (active ou blackhole) pour déterminer quoi faire du trafic correspondant. Dans le cas où une route est inactive et tombe en statut blackhole, tous les paquets associés seront simplement supprimés sans vérifier qu’une autre route plus générale puisse permettre de joindre la destination.

Vous pouvez monitorer les paquets entrant dans ce cas de figure via la métrique CloudWatch PacketDropCountBlackhole.

L’utilisation de routage dynamique avec BGP peut vous permettre de contourner ce phénomène, car la route inactive disparaîtra automatiquement des tables de routage.

Évidemment, le cas abordé était simple avec seulement deux réseaux, mais c’est parfaitement applicable à des infrastructures bien plus grandes et complexes.

De même, j’ai parlé dans cet article des services réseau proposés par AWS, mais cette méthode fonctionne également que vous soyez sur des infrastructures On Premise ou chez un autre fournisseur de service cloud avec des fonctionnalités similaires.

Pour aller plus loin, si vous utilisez du routage statique, vous pouvez jeter un œil à cet article qui parle de l’utilisation des PrefixList pour le routage et les ouvertures de flux dans les security group.