Présentation de Cloud Router

Cloud Router est un service cloud Google entièrement distribué et géré. Il évolue avec votre trafic réseau : il ne s'agit pas d'un périphérique physique qui pourrait causer un goulot d'étranglement.

Lorsque vous étendez votre réseau sur site vers Google Cloud, Cloud Router vous permet d'échanger de manière dynamique des routes entre vos réseaux Google Cloud et votre réseau sur site. Cloud Router est appairé à votre routeur ou passerelle VPN sur site. Les routeurs échangent les informations en matière de topologie via le protocole BGP (Border Gateway Protocol). Les modifications de topologie se propagent automatiquement entre votre réseau VPC et votre réseau sur site. Vous n'avez pas besoin de configurer des routes statiques.

Cloud Router fonctionne à la fois avec les anciens réseaux et avec les réseaux cloud privés virtuels (VPC).

Routage statique ou routage dynamique

Avec les routes statiques, vous devez créer ou gérer une table de routage. Un changement de topologie sur l'un des réseaux nécessite la mise à jour manuelle des routes statiques. En outre, les routes statiques ne peuvent pas rediriger automatiquement le trafic en cas de défaillance d'un lien.

Le routage statique convient aux petits réseaux avec des topologies stables. Vous bénéficiez par ailleurs d'un contrôle strict sur les tables de routage. Les routeurs n'envoient pas d'annonces entre les réseaux.

Avec Cloud Router, vous pouvez utiliser BGP pour échanger des informations de routage entre les réseaux. Au lieu de configurer manuellement les routes statiques, les réseaux découvrent automatiquement et rapidement les changements de topologie via BGP. Les modifications sont mises en œuvre de manière transparente sans perturber le trafic. Cette méthode d'échange de routes via BGP est appelée routage dynamique.

Le routage dynamique convient aux réseaux de toutes les tailles. Cela vous évite de maintenir des routes statiques. De plus, si un lien échoue, le routage dynamique peut automatiquement rediriger le trafic, si cela est possible. Pour activer le routage dynamique, créez un routeur cloud. Ensuite, configurez une session BGP entre le routeur cloud et votre routeur ou passerelle sur site.

Routage statique pour les tunnels VPN

Sans Cloud Router, vous ne pouvez configurer votre VPN qu'avec des routes statiques. Les inconvénients de l'utilisation de routes statiques sont les suivants :

  • Une modification de la configuration d'un réseau de part ou d'autre du tunnel VPN nécessite la création et la suppression manuelles des routes statiques correspondant à cette modification. De plus, la convergence des modifications des routes statiques peut prendre beaucoup de temps.
  • Lorsqu'un tunnel VPN est créé pour utilisation avec des routes statiques, la liste des préfixes IP de chaque côté du tunnel doit être spécifiée avant la création du tunnel. Cela signifie que chaque fois que les routes doivent changer, le tunnel VPN doit être mis à jour (supprimé et recréé) avec les nouvelles routes, ce qui perturbe le trafic existant.
  • Il n'existe aucun moyen standard de configurer des routes statiques. Les différents fournisseurs utilisent différentes commandes.

Dans l'exemple suivant, votre réseau combiné se compose de votre réseau cloud Google et de 29 sous-réseaux (un par rack) sur le réseau sur site de l'autre côté du tunnel VPN. Dans le cadre de cet exemple, supposons que votre entreprise se développe de telle sorte que vous devez ajouter un nouveau sous-réseau de machines chaque semaine. Cette semaine, vous ajoutez le sous-réseau 10.0.30.0/24, comme indiqué dans le schéma suivant :

Cloud Router pour les VPN avec réseau VPC (cliquez pour agrandir)
VPN sans Cloud Router (cliquez pour agrandir)

Dans ce scénario, le VPN basé sur une route statique nécessite les modifications suivantes :

  1. Des routes statiques doivent être ajoutées à Google Cloud Platform pour atteindre le nouveau sous-réseau sur site.
  2. Le tunnel VPN doit être supprimé et recréé pour inclure le nouveau sous-réseau sur site.

Les modifications de configuration des routes statiques et des tunnels VPN peuvent être évitées en déployant un routeur cloud. Ce routeur cloud est appairé à votre passerelle VPN via BGP pour échanger des informations de topologie. En effet, les modifications de la topologie de votre réseau Google Cloud Platform se propagent automatiquement sur votre propre réseau et inversement via BGP, ce qui vous évite de configurer des routes statiques pour vos tunnels VPN.

Routage dynamique pour les tunnels VPN dans les réseaux VPC

Les réseaux VPC permettent de segmenter à l'échelle régionale l'espace d'adresses IP du réseau en préfixes (sous-réseaux) et de contrôler à partir de quel préfixe l'adresse IP interne d'une instance de VM est allouée. Pour éviter la gestion statique de ces sous-réseaux, y compris la charge liée à l'ajout et à la suppression des routes statiques associées pour votre VPN, activez le routage dynamique pour votre tunnel VPN avec Cloud Router.

Un routeur cloud appartient à un réseau VPC et à une région spécifiques. Cloud Router annonce les sous-réseaux de son réseau VPC vers la passerelle sur site via BGP. Il annonce les sous-réseaux de sa région locale ou tous les sous-réseaux du réseau, en fonction du mode de routage dynamique du réseau VPC. Cloud Router apprend également les routes locales via BGP et permet à l'infrastructure réseau de sélectionner la meilleure route pour atteindre les préfixes associés.

L'exemple suivant présente Cloud Router avec des réseaux VPC en mode personnalisé. Si vous utilisez des réseaux VPC en mode automatique, Cloud Router annonce automatiquement le préfixe /20 de la région.

Le schéma suivant montre deux sous-réseaux régionaux différents dans un réseau VPC, et 30 sous-réseaux dans le réseau sur site. Les deux réseaux sont connectés via un tunnel Cloud VPN. Dans ce scénario, de nouveaux sous-réseaux sont ajoutés dans les deux réseaux :

  1. Un nouveau sous-réseau 192.168.1.0/24 dans la région us-east-1 du réseau GCP
  2. Un nouveau sous-réseau 10.0.30.0/24 sur site pour gérer le trafic croissant dans votre centre de données
Cloud Router pour les VPN avec réseau VPC (cliquez pour agrandir)
Cloud Router pour les VPN avec réseau VPC (cliquez pour agrandir)

Pour propager automatiquement les modifications de configuration de réseau, le tunnel VPN s'appuie sur Cloud Router pour établir une session BGP avec la passerelle VPN sur site, qui doit accepter BGP. Les nouveaux sous-réseaux sont annoncés de manière transparente entre les réseaux. Les instances des nouveaux sous-réseaux peuvent commencer à envoyer et à recevoir du trafic immédiatement.

Pour configurer BGP, une adresse IP supplémentaire doit être attribuée à chaque extrémité du tunnel VPN. Ces deux adresses IP doivent être des adresses IP de liaison locale, appartenant à la plage d'adresses IP 169.254.0.0/16. Ces adresses ne font pas partie de l'espace d'adresses IP de l'un ou l'autre des réseaux. Ces deux adresses servent exclusivement à établir une session BGP.

Routage dynamique pour les tunnels VPN dans les anciens réseaux

Dans les réseaux existants, les modifications de configuration de réseau sont automatiquement propagées sans qu'il soit nécessaire de reconfigurer les routes statiques et de redémarrer le tunnel VPN, comme dans l'exemple précédent.

La session BGP informe chaque routeur des modifications locales. Pour configurer BGP, une adresse IP supplémentaire doit être attribuée à chaque extrémité du tunnel VPN. Ces deux adresses IP doivent être des adresses IP de liaison locale, appartenant à la plage d'adresses IP169.254.0.0/16. Ces adresses ne font pas partie de l'espace d'adresses IP de part et d'autre du tunnel et servent exclusivement à configurer des pairs BGP afin d'établir une session BGP.

Vous devez configurer deux adresses IP de liaison locale (toutes deux issues du même sous-réseau) et un masque de réseau des deux côtés du tunnel. Une fois que vous avez effectué ces modifications des deux côtés du tunnel, une session BGP est établie.

Encore une fois, si un réseau comporte des tunnels VPN dans plusieurs régions, un routeur cloud doit être créé dans chaque région dans laquelle le routage dynamique est souhaité. Un seul routeur cloud peut être utilisé pour plusieurs passerelles VPN et plusieurs tunnels dans la région du réseau à laquelle appartient le routeur.

Mode de routage dynamique

Le mode de routage dynamique d'un réseau VPC détermine les sous-réseaux visibles par les routeurs cloud. Vous pouvez définir le mode de routage dynamique comme global ou régional :

  • Avec le routage dynamique global, un routeur cloud annonce tous les sous-réseaux du réseau VPC vers le routeur sur site. Cloud Router propage les routes apprises du routeur sur site vers toutes les régions.
  • Avec le routage dynamique régional, un routeur cloud annonce et propage les routes dans sa région locale.

Le mode de routage dynamique est configuré sur le réseau VPC. Lorsque vous créez ou modifiez un réseau VPC, vous pouvez définir le mode de routage dynamique comme global ou régional. Toutes les instances de Cloud Router dans le réseau VPC utilisent le mode de routage dynamique du réseau. Par défaut, le mode est régional.

Si vous modifiez le mode de routage dynamique pour un réseau VPC, prenez en compte les conséquences, telles que l'interruption de connexions existantes ou l'activation de routes non souhaitées. Par exemple, si vous passez au routage dynamique régional, les instances de VM capables de se connecter aux tunnels VPN et les interconnexions d'une autre région risquent de perdre leur connexion. Si vous passez au routage dynamique global, Cloud Router peut annoncer des instances de VM provenant de régions que vous n'aviez pas prévues. Pour afficher ou configurer le mode de routage dynamique, consultez la section Définir le routage dynamique régional ou global.

Exemple de routage dynamique régional

Avec le routage dynamique régional, vous pouvez disposer d'un tunnel Cloud VPN et d'instances de VM dans une seule région GCP. Le tunnel étend votre réseau sur site à un réseau VPC. Les instances de VM d'autres régions peuvent avoir besoin de se connecter au réseau sur site, mais elles ne peuvent pas atteindre le tunnel. Pour contourner cette contrainte, vous pouvez créer des routes statiques. Cependant, le maintien de routes statiques peut entraîner des erreurs et perturber le trafic.

Dans l'exemple suivant, Cloud Router n'a de visibilité sur les ressources que dans la région us-west1. Les instances de VM d'autres régions, telles que us-central1, ne peuvent pas atteindre le tunnel Cloud VPN.

Routage dynamique régional Cloud Router (cliquez pour agrandir)
Routage dynamique régional Cloud Router (cliquez pour agrandir)

Exemples de routage dynamique global

Grâce au routage dynamique global, Cloud Router dispose d'une visibilité sur les ressources de toutes les régions. Par exemple, si vous avez des instances de VM dans une région, elles peuvent atteindre automatiquement un tunnel Cloud VPN dans une autre région sans routes statiques à maintenir.

L'exemple suivant présente un réseau VPC avec routage dynamique global. Le routeur cloud dans us-west1 annonce des sous-réseaux dans deux régions différentes : us-west1 et us-central1. Les instances de VM des deux régions s'informent de manière dynamique sur les hôtes sur site.

Routage dynamique global Cloud Router (cliquez pour agrandir)
Routage dynamique global Cloud Router (cliquez pour agrandir)

Pour les topologies redondantes, le routage dynamique (BGP) fournit suffisamment d'informations au VPC et aux réseaux sur site pour que le trafic soit réacheminé en cas d'échec du chemin. Si une connexion dans une région rencontre un problème, le trafic peut basculer vers une autre région.

L'exemple suivant présente deux tunnels Cloud VPN dans deux régions différentes. Les instances de VM (10.128.0.0/20) utilisent tunnel-us-west1 dans la région us-west1 pour atteindre les deux sous-réseaux du réseau sur site. De même, les instances de VM (10.138.0.0/20) dans la région us-central1 utilisent le tunnel tunnel-us-central1.

Routage dynamique global Cloud Router (cliquez pour agrandir)
Routage dynamique global Cloud Router (cliquez pour agrandir)

Les routes sont configurées de sorte que les instances de VM préfèrent leurs tunnels locaux (tunnels de leur région). Cloud Router définit différentes pondérations pour les routes locales et distantes avec la même destination. En cas de défaillance d'un tunnel, Cloud Router peut rediriger le trafic de manière appropriée.

Dans l'exemple suivant, tunnel-us-west1 est défaillant. Le trafic en provenance et à destination des instances de VM (10.128.0.0/20) est redirigé via tunnel-us-central1 au lieu d'être supprimé.

Routage dynamique global Cloud Router (cliquez pour agrandir)
Routage dynamique global Cloud Router (cliquez pour agrandir)

Annonces de routage

Par le biais de BGP, Cloud Router annonce les adresses IP que les clients de votre réseau sur site peuvent atteindre. Le réseau sur site envoie des paquets au réseau VPC avec une adresse IP de destination qui correspond à la plage d'adresses IP annoncée. Une fois que vous avez atteint GCP, les routes et les règles de pare-feu du réseau VPC déterminent la manière dont GCP traite les paquets.

Vous pouvez utiliser les annonces par défaut de Cloud Router ou spécifier explicitement les plages CIDR à annoncer. Si vous n'indiquez aucune annonce, Cloud Router utilise les valeurs par défaut.

Par défaut

Par défaut, Cloud Router annonce les sous-réseaux de sa région pour le routage dynamique régional ou tous les sous-réseaux d'un réseau VPC pour le routage dynamique global. Les nouveaux sous-réseaux sont automatiquement annoncés par Cloud Router. De plus, si un sous-réseau possède une plage d'adresses IP secondaires pour la configuration d'adresses IP d'alias, Cloud Router annonce les adresses IP principales et secondaires.

Chaque session BGP pour un routeur cloud comporte également une annonce par défaut. Par défaut, Cloud Router propage ses annonces de routage vers toutes ses sessions BGP. Si vous configurez des annonces de routage personnalisées sur un routeur cloud, ses sessions BGP héritent de ces annonces personnalisées.

Pour annoncer des adresses IP en dehors de la plage d'un sous-réseau, telles que des adresses IP externes réservées, vous devez spécifier des annonces personnalisées. En outre, lorsque vous utilisez des annonces personnalisées, vous pouvez annoncer de manière sélective des sous-réseaux ou des parties d'un sous-réseau. De cette façon, vous pouvez empêcher l'annonce de certains sous-réseaux. Si vous n'avez pas besoin de ces fonctionnalités, utilisez les annonces par défaut.

Personnalisées

Lorsque vous configurez des annonces de routage personnalisées, vous spécifiez explicitement les routes annoncées par un routeur cloud. Dans la plupart des cas, les annonces personnalisées sont utiles pour compléter l'annonce de sous-réseau par défaut avec des adresses IP personnalisées. Les adresses IP personnalisées sont des adresses n'appartenant pas à la plage d'adresses IP d'un sous-réseau, telles que les adresses IP externes réservées. Sans annonce de routage personnalisée, vous devez créer et gérer des routes statiques pour les adresses IP personnalisées.

Lorsque vous configurez des annonces de routage personnalisées, vous pouvez choisir d'annoncer tous les sous-réseaux, ce qui émule le comportement par défaut. Vous pouvez choisir de ne pas annoncer tous les sous-réseaux, mais plutôt des sous-réseaux spécifiques ou certains blocs CIDR au sein d'un sous-réseau. Par exemple, vous pouvez empêcher Cloud Router d'annoncer des sous-réseaux particuliers. Pour ce faire, vous n'annoncez que ceux que vous souhaitez exposer. Toutefois, lorsque vous annoncez des sous-réseaux de manière sélective, vous devez ajouter manuellement de nouveaux sous-réseaux à l'annonce de routage personnalisée. Cloud Router n'annonce pas automatiquement les nouveaux sous-réseaux.

Vous pouvez spécifier des annonces de routage personnalisées sur un routeur cloud ou sur une session BGP. Les annonces de routage personnalisées sur le routeur cloud s'appliquent à toutes ses sessions BGP. Toutefois, si vous spécifiez une annonce de routage personnalisée sur une session BGP, l'annonce de routage du routeur cloud est ignorée et remplacée par l'annonce de la session.

Vous pouvez spécifier un maximum de 200 plages CIDR pour chaque routeur cloud et chaque session BGP possède la même limite de 200.

Exemples

Les exemples suivants illustrent le comportement par défaut du routeur cloud, ainsi que des scénarios dans lesquels les annonces de routage personnalisées peuvent être utiles. Ces exemples supposent qu'une connexion existe entre le VPC et les réseaux sur site, comme un tunnel VPN IPsec ou une interconnexion dédiée.

Annonce de routage par défaut

Pour le routage dynamique régional, Cloud Router annonce les sous-réseaux de sa région. Dans l'exemple suivant, Cloud Router annonce les sous-réseaux de la région us-central1. Il annonce également la plage d'adresses IP secondaires du sous-réseau alias-subnet. Si vous créez des sous-réseaux dans us-central1, Cloud Router les annonce automatiquement. Cloud Router n'annonce pas les adresses IP qui ne font pas partie de la plage d'adresses IP d'un sous-réseau, telles que les adresses IP externes.

Annonce de routage par défaut Cloud Router (cliquez pour agrandir)
Annonce de routage par défaut Cloud Router (cliquez pour agrandir)

Vous pouvez utiliser une adresse IP statique externe pour une application GCP servant des clients sur votre réseau sur site. Lorsque vous effectuez une maintenance sur l'application, vous pouvez associer à nouveau l'adresse IP statique à une autre instance de VM afin de minimiser les temps d'arrêt. Avec les annonces par défaut de Cloud Router, vous devez configurer et gérer une route statique. Au lieu de cela, vous pouvez passer par des annonces personnalisées pour annoncer l'adresse IP externe via BGP.

Dans l'exemple suivant, le routeur cloud annonce l'adresse IP externe 1.2.3.4 du serveur proxy. L'adresse IP externe est associée à l'adresse IP interne 10.20.0.2 du serveur. Cloud Router n'annonce pas l'adresse IP interne du serveur proxy ni aucune instance de VM dans le sous-réseau my-subnet. Les clients sur site ne connaissent que l'adresse IP externe du serveur proxy.

Annonce d'adresse IP externe (cliquez pour agrandir)
Annonce d'adresse IP externe (cliquez pour agrandir)

Pour plus d'informations, consultez la section Annoncer des plages d'adresses IP personnalisées.

Restreindre les annonces de sous-réseau

Vous pouvez empêcher l'annonce d'instances afin qu'elles soient cachées. Dans l'exemple suivant, Cloud Router annonce subnet-1 et subnet-2. Les clients du réseau sur site peuvent atteindre les instances de VM de ces sous-réseaux, mais pas celles du sous-réseau unadvertised-subnet.

Annoncer des sous-réseaux spécifiques sur le routeur cloud (cliquez pour agrandir)
Annoncer des sous-réseaux spécifiques sur le routeur cloud (cliquez pour agrandir)

Pour plus d'informations, consultez la section Annoncer des sous-réseaux VPC spécifiques.

Annonce de routage par session BGP

Supposons que vous disposez de ressources de production et de test dans votre VPC et vos réseaux sur site, et que vous les avez organisées dans différents sous-réseaux. Par conséquent, vous configurez deux sessions BGP qui annoncent des plages d'adresses IP différentes. Grâce à l'utilisation de deux sessions BGP différentes, le trafic lié à un sous-réseau ne se dirige pas par inadvertance vers un autre sous-réseau. L'exemple suivant présente deux sessions BGP : prod-bgp qui n'annonce que prod-subnet, et test-bgp qui n'annonce que test-subnet.

Annoncer des sous-réseaux spécifiques sur une session BGP (cliquez pour agrandir)
Annoncer des sous-réseaux spécifiques sur une session BGP (cliquez pour agrandir)

Pour plus d'informations, consultez la section Annoncer des plages d'adresses IP personnalisées ou Annoncer des sous-réseaux VPC spécifiques.

Meilleur chemin pour le trafic sortant de GCP vers votre réseau sur site

Si Cloud Router reçoit plusieurs routes pour la même destination, GCP s'appuie sur des métriques de routage et, dans certains cas, sur la longueur du chemin AS pour déterminer le meilleur chemin. La liste suivante décrit l'algorithme utilisé pour le trafic sortant avec un ou plusieurs routeurs cloud gérant les routes dynamiques pour un réseau VPC.

  1. Si vous disposez de plusieurs sessions BGP sur un même routeur cloud, la sortie est déterminée par la première condition remplie :
    1. L'ensemble du trafic sortant est envoyé à la route avec la longueur de chemin AS la plus faible.
    2. Si la longueur du chemin AS est la même pour toutes les routes, l'ensemble du trafic sortant est envoyé à celle ayant la valeur MED (Multi-Exit Discriminator) la plus faible (métrique de routage la plus faible).
    3. Si la longueur du chemin AS et la valeur MED (métrique de routage) sont les mêmes pour toutes les routes, le trafic sortant est équilibré sur toutes les routes à l'aide du chemin ECMP (Equal-Cost Multi-Path).
  2. Si vous utilisez plusieurs routeurs cloud dans la même région, GCP ne s'appuie que sur les métriques de routage pour déterminer le meilleur chemin. La longueur du chemin AS n'est pas prise en compte. La sortie est déterminée par la première condition remplie :
    1. L'ensemble du trafic sortant est envoyé à la route ayant la valeur MED (Multi-Exit Discriminator) la plus faible (métrique de routage la plus faible).
    2. Si la valeur MED (métrique de routage) est la même pour toutes les routes, le trafic sortant est équilibré sur toutes les routes à l'aide du chemin ECMP (Equal-Cost Multi-Path).
  3. Les routes statiques sont prioritaires sur les routes dynamiques Cloud Router en cas de conflit. Une route statique avec le même préfixe et la même métrique de routage qu'une route dynamique est toujours prioritaire. Par conséquent, les routes dynamiques en conflit sont ignorées.

Plages d'adresses IP se chevauchant entre un sous-réseau VPC et une annonce de routage sur site

Dans les cas où vous disposez d'un sous-réseau VPC et d'une annonce de routage sur site avec des plages d'adresses IP qui se chevauchent, GCP dirige le trafic sortant en fonction de ses plages d'adresses IP.

Si la plage d'adresses IP du sous-réseau est plus étendue que l'annonce de routage sur site ou identique, GCP ignore l'annonce sur site. L'ensemble du trafic sortant GCP destiné à la plage d'adresses IP du sous-réseau est dirigé vers le sous-réseau VPC. Par exemple, si vous disposez d'un sous-réseau avec la plage d'adresses IP 10.2.0.0/16 et d'un routeur sur site annonçant 10.2.1.0/24, GCP ignore l'annonce sur site et dirige le trafic 10.2.0.0/16 vers le sous-réseau VPC.

Si la plage d'adresses IP du sous-réseau est moins étendue que l'annonce de routage sur site, le trafic sortant GCP est dirigé vers le sous-réseau VPC si l'adresse IP de destination appartient à la plage d'adresses IP du sous-réseau. Tout le reste du trafic sortant qui correspond à l'annonce sur site est dirigé vers le réseau sur site. Par exemple, si vous disposez d'un sous-réseau avec la plage d'adresses IP 10.2.0.0/16 et d'un routeur sur site annonçant 10.0.0.0/8, GCP dirige le trafic destiné à 10.0.0.0/8 vers le réseau sur site, sauf si la destination correspond à 10.2.0.0/16, que GCP dirige vers le sous-réseau.

Métriques de routage

Lorsque Cloud Router annonce ou propage des routes, il s'appuie sur des métriques de routage pour spécifier la priorité des routes. En présence de plusieurs chemins entre votre réseau VPC et votre réseau sur site, les métriques de routage déterminent le chemin privilégié. Cette valeur est équivalente à la valeur MED (Multi-Exit Discriminator). Une métrique de routage (MED) inférieure indique une priorité plus élevée.

Une métrique de routage est composée d'une priorité de base des routes annoncées et d'un coût régional. La priorité de base est une valeur spécifiée par l'utilisateur, tandis que le coût régional est une valeur générée par Google que vous ne pouvez pas modifier. Le coût régional représente le coût de la communication entre deux régions d'un réseau VPC. Cloud Router additionne ces deux valeurs pour générer une métrique de routage.

Pour le routage dynamique régional, Cloud Router ne prenant en charge que les routes de sa région, il n’ajoute aucun coût régional aux métriques de routage. Cloud Router n'utilise que la priorité de base des routes annoncées.

Pour le routage dynamique global, tous les routeurs cloud annoncent et propagent les mêmes routes. Cependant, chaque routeur cloud peut utiliser des métriques de routage différentes en raison des coûts régionaux.

Priorité de base des routes annoncées

Lors du calcul des métriques de routage, Cloud Router commence par la valeur de priorité de base des routes annoncées, puis ajoute les coûts régionaux éventuels. Cette valeur de base est la métrique de routage minimale pour les routes annoncées. Lorsque vous configurez une session BGP sur un routeur cloud, vous pouvez spécifier une priorité de base des routes annoncées, qui s'applique à toutes les routes de cette session. Par défaut, la valeur de priorité annoncée de base est de 100.

La priorité de base des routes annoncées permet de définir des priorités pour les routes. Par exemple, vous pouvez disposer d'un tunnel VPN et d'une interconnexion dédiée connectant vos réseaux VPC et sur site. Vous pouvez définir la priorité de base des routes annoncées de sorte que le trafic préfère l’interconnexion dédiée. Si l'interconnexion n'est pas disponible, le trafic traverse le tunnel. Pour plus d'informations, consultez les exemples de topologies.

Coût régional

Lorsqu'un routeur cloud annonce des routes depuis des régions autres que la sienne (routes depuis des régions GCP distantes) ou propage des routes vers des régions distantes, il ajoute un coût régional.

Le coût régional peut aller de 201 à 9999 inclus. La valeur dépend de la distance, de la latence et d'autres facteurs entre deux régions. Google génère la valeur de coût régional, et vous ne pouvez pas la modifier. Pour plus d'informations sur les coûts régionaux, consultez les exemples de topologies.

Les coûts régionaux permettent de hiérarchiser les chemins en fonction de la proximité de la région. Par exemple, imaginons que vous disposez de deux connexions entre votre VPC et votre réseau sur site, telles que deux tunnels VPN avec leurs propres routeurs cloud. Une connexion se trouve dans la région us-central1 et l'autre dans la région europe-west1. En ajoutant un coût régional aux métriques de routage, le trafic entre les réseaux de la région us-central1 donne la priorité au tunnel us-central1. De même, le trafic entre les réseaux de la région europe-west1 donne la priorité au tunnel europe-west1. Sans coûts régionaux, le trafic sera acheminé équitablement sur les deux connexions, ce qui entraînera des performances de réseau inégales.

Cloud Router ajoute des coûts régionaux lorsqu'il propage les routes apprises vers les régions GCP distantes. Cela contribue à maintenir la symétrie entre le trafic entrant et sortant entre les réseaux VPC et sur site. Cloud Router ajoute des coûts régionaux à la valeur MED annoncée par votre routeur sur site.

Valeurs de priorité de base suggérées

Pour ajuster les priorités entre les routes d'une même région, utilisez des valeurs inférieures à 201. Vous vous assurez ainsi que les coûts régionaux n'ont aucune incidence sur la priorité des routes. Une route d'une autre région (région distante) ne peut pas présenter une priorité inférieure à 201. Si vous utilisez des valeurs plus élevées, les coûts régionaux pourraient avoir une incidence sur la priorité de vos routes. Par exemple, supposons que vous disposez d'une connexion principale et d'une connexion de secours. Si vous définissez une priorité de base trop élevée pour la connexion de secours, vous allez peut-être involontairement privilégier les routes d'autres régions.

Pour retirer globalement à une route sa priorité dans un réseau VPC, utilisez une valeur supérieure à 10 200. Vous vous assurez ainsi que toutes les autres routes avec une valeur inférieure à 201 sont prioritaires quels que soient les coûts régionaux.

Dans les cas où toutes les routes d'une région sont d'une priorité égale, vous pouvez utiliser la valeur par défaut de 100.

Exemples de topologies

Les exemples suivants décrivent l'influence des coûts régionaux sur les métriques de routage lorsque vous utilisez le routage dynamique global.

Supposons que vous disposez d'un réseau VPC avec deux tunnels VPN dotés de leurs propres routeurs cloud. Un tunnel se trouve dans la région us-central1 et l'autre dans la région us-west1. Par défaut, le trafic entrant dans ces régions utilise les tunnels correspondants dans leur région respective. Cependant, que se passe-t-il si vous souhaitez atteindre des instances de VM n'appartenant pas à ces régions, telles que des instances de la région europe-west1 ? Le schéma suivant montre l'impact des coûts régionaux sur les métriques de routage.

Métriques de routage Cloud Router pour les routes annoncées (cliquez pour agrandir)
Métriques de routage Cloud Router pour les routes annoncées (cliquez pour agrandir)

Les deux routeurs cloud annoncent des routes vers europe-west1, mais avec des métriques de routage différentes. Le routeur cloud de la région us-central1 annonce les routes à destination de la région europe-west1 avec une métrique de routage inférieure à us-west1 en raison de la distance, de la latence et d'autres facteurs. L'exemple suppose que le coût régional pour europe-west1 est de 300 via us-central1 et de 350 via us-west1. Le trafic entrant utilise le tunnel us-central1, dont la métrique de routage est plus faible. Sa métrique de routage est de 350 contre 400 pour le tunnel us-west1.

De même, Cloud Router ajoute un coût régional à la valeur MED des routes apprises (spécifiée par votre routeur sur site). Par défaut, le trafic sortant de la région europe-west1 utilise également le tunnel us-central1, car sa métrique de routage est plus faible. De cette façon, les trafics entrant et sortant conservent une symétrie.

Métriques de routage Cloud Router pour les routes apprises (cliquez pour agrandir)
Métriques de routage Cloud Router pour les routes apprises (cliquez pour agrandir)

Priorités des routes dans une région

À des fins de redondance dans la région us-west1, supposons que vous créez un tunnel de secours. Vous spécifiez une priorité de base plus élevée pour le tunnel de secours afin que le trafic entrant vers us-west1 privilégie le tunnel principal, comme dans l'exemple suivant :

Priorités de base pour les routes d'une région (cliquez pour agrandir)
Priorités de base pour les routes d'une région (cliquez pour agrandir)

En cas de défaillance du tunnel principal, le trafic entrant vers us-west1 privilégie le tunnel de secours avec une métrique de routage de 51 par rapport au tunnel us-central1, dont la métrique de routage est de 400 :

Priorités de base pour les routes d'une région (cliquez pour agrandir)
Priorités de base pour les routes d'une région (cliquez pour agrandir)

De même, pour le trafic sortant du réseau VPC vers votre réseau sur site, appliquez des valeurs MED inférieures à 201 pour donner la priorité à un chemin par rapport à un autre. Sinon, le trafic sortant du réseau VPC vers votre réseau sur site pourrait ne pas être symétrique avec le trafic entrant.

Dans les cas où tous les tunnels ou toutes les interconnexions d'une région sont de même priorité, vous pouvez utiliser la priorité de base des routes par défaut de 100.

Route privilégiée au niveau global

Supposons que vous disposez d'une interconnexion dédiée et d'un tunnel VPN dans différentes régions. Vous souhaitez donner la priorité à l'interconnexion dédiée, car elle est plus rentable pour vos charges de travail que le tunnel VPN. Spécifiez une priorité de base de 10 051 pour les routes du tunnel VPN afin de retirer la priorité. En conséquence, l'ensemble du trafic entrant utilise l’interconnexion dédiée, indépendamment des coûts régionaux. Les métriques de routage pour l'interconnexion dédiée ne dépasseront pas 10 051. Le trafic ne passe par le tunnel VPN qu'en cas d'échec de l'interconnexion.

Priorités de base pour les routes globales (cliquez pour agrandir)
Priorités de base pour les routes globales (cliquez pour agrandir)

Vous devrez également procéder aux mêmes ajustements sur votre routeur sur site afin que le trafic sortant du réseau VPC vers le réseau sur site privilégie toujours l'interconnexion dédiée.

Pour plus d'informations sur la définition d'une priorité de base, consultez la section Établir des sessions BGP ou Mettre à jour la priorité de base des routages présentés.

Route par défaut

Si aucune route n'est spécifiée pour une destination IP particulière, le trafic est envoyé à une route par défaut, qui agit en dernier recours lorsqu'il n'existe aucune autre option. Par exemple, les réseaux VPC de GCP incluent automatiquement une route par défaut (0.0.0.0/0) qui envoie le trafic à la passerelle Internet.

Dans certains cas, vous souhaiterez peut-être que le trafic soit dirigé vers votre réseau sur site par défaut. Pour ce faire, vous pouvez annoncer une route par défaut à partir de votre routeur sur site vers Cloud Router. Avec Cloud Router, vous n'avez pas besoin de créer et de gérer des routes statiques. Si vous annoncez une route par défaut à partir de votre réseau sur site, vérifiez qu'elle est prioritaire sur les autres routes par défaut créées automatiquement (valeur MED inférieure). Accédez à la page Routes et affichez la priorité pour les routes avec 0.0.0.0/0 dans la plage d'adresses IP de destination et la passerelle Default internet gateway dans le saut suivant.

Redémarrage progressif

Le redémarrage progressif est activé pour Cloud Router. Le redémarrage progressif permet au périphérique BGP sur site de se déconnecter, puis d'effectuer une récupération au cours de la période de redémarrage, sans interrompre le flux du trafic. Cette fonctionnalité protège contre les interruptions lorsque les agents BGP ont besoin de mises à niveau logicielles et d'autres types de maintenance, ou échouent temporairement.

Activez le redémarrage progressif sur votre périphérique BGP s'il l'accepte.

Tunnel Cloud VPN avec redémarrage progressif

Dans l'exemple suivant, si Cloud Router nécessite une mise à jour de maintenance, elle peut être effectuée sans perturber le trafic tant que le routeur est remis en ligne au cours de la période de redémarrage progressif.

Redémarrage progressif et Cloud Router (cliquez pour agrandir)
Redémarrage progressif et Cloud Router (cliquez pour agrandir)

Paramètres des compteurs BGP

Utilisez les valeurs par défaut pour tous les compteurs BGP du routeur sur site, à l'exception du compteur de redémarrage progressif.

Sur la plupart des routeurs tiers, le compteur de redémarrage progressif est défini sur 120 secondes. Ce paramètre est insuffisant, car une défaillance du routeur sur site peut déclencher un redémarrage progressif dans Cloud Router, ce qui peut entraîner des délais de convergence des routes.

Définissez plutôt cette valeur sur 1 seconde, c'est-à-dire la durée pendant laquelle le routeur sur site doit attendre avant de tenter de rétablir une session BGP après sa réinitialisation. À la fin de la période de redémarrage, Cloud Router efface les routes apprises pendant la session BGP ayant échoué.

Le paramètre stalepath-timer détermine la durée pendant laquelle un routeur attend avant de supprimer les routes obsolètes après qu'un message de fin d'enregistrement (EOR) est reçu du routeur en redémarrage. Définissez ce paramètre sur la valeur par défaut pour Cloud Router, qui est de 300 secondes.

Tunnels Cloud VPN redondants

Si la passerelle sur site n'est pas compatible avec le redémarrage progressif, toute défaillance d'un côté ou de l'autre de la session BGP entraîne l'échec de la session et l'interruption du trafic. Une fois le délai d'attente BGP dépassé, à savoir 60 secondes pour Cloud Router, les routes sont retirées des deux côtés. Le trafic VPN routé de manière dynamique n'entrera plus dans le tunnel. Les routes statiques du tunnel continueront d'être desservies.

Sans redémarrage progressif possible, le déploiement de deux passerelles sur site, avec un tunnel chacune, permet la redondance et le basculement. Cette configuration permet à un tunnel et à ses périphériques de se déconnecter pour les mises à niveau logicielles ou la maintenance sans interrompre le trafic. De plus, en cas de défaillance d'un tunnel, l'autre peut maintenir les routes actives et le trafic fluide.

L'exemple suivant présente une seule zone pour le routeur cloud, mais avec deux adresses IP. Les deux adresses sont des interfaces Ethernet distinctes dans la même tâche Cloud Router. Chaque interface est utilisée pour une session BGP particulière avec une passerelle sur site spécifique. Dans ce cas d'utilisation précis, étant donné que ces tunnels VPN sont créés à des fins de redondance, les deux sessions BGP échangent exactement le même ensemble de préfixes de route, mais avec des sauts suivants différents qui pointent vers des tunnels VPN différents.

Redondance sans redémarrage progressif (cliquez pour agrandir)
Redondance sans redémarrage progressif (cliquez pour agrandir)

Cycles de mise à niveau

Cloud Router est mis à niveau régulièrement, ce qui prend moins de 60 secondes. Cloud Router n'est pas disponible pendant la mise à niveau. Le compteur de préservation BGP détermine la durée pendant laquelle les routes apprises sont conservées lorsque le routeur BGP appairé n'est pas disponible. Le compteur de préservation BGP est négocié de façon à être la plus faible des deux valeurs des deux côtés. Cloud Router utilise une valeur de 60 secondes pour le compteur de préservation BGP. Nous vous recommandons de définir votre compteur de préservation BGP pair sur au moins 60 secondes (la valeur par défaut est de 3 minutes). Ainsi, les deux routeurs conservent leurs routes pendant ces mises à niveau et le trafic continue de circuler.

Lors des cycles de maintenance de passerelle VPN avec une seule passerelle VPN, l'utilisation de Cloud Router ajoute environ 20 secondes à la durée de récupération du tunnel, car la session BGP est réinitialisée et les routes doivent être réapprises. La durée de récupération de la passerelle VPN est généralement d’une minute environ. En présence de passerelles VPN redondantes, le trafic n'est pas impacté, car une seule passerelle VPN est désactivée à la fois.

Étapes suivantes

Pour plus d'informations sur l'utilisation du routage statique et dynamique avec un service compatible, consultez la documentation suivante :

Produit Routage Documentation
Interconnexion dédiée Statique Non compatible
Interconnexion dédiée Dynamique Créer des rattachements de VLAN
Cloud VPN Basé sur des règles Créer un tunnel VPN avec des routes basées sur des règles
Cloud VPN Statique Créer un tunnel VPN avec des routes statiques
Cloud VPN Dynamique Créer un tunnel VPN avec des routes dynamiques
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…