Présentation de Cloud Router

Cloud Router est un service Google Cloud entièrement distribué et géré qui programme des routes dynamiques personnalisées et qui évolue avec votre trafic réseau. Cloud Router fonctionne à la fois avec les anciens réseaux et avec les réseaux cloud privés virtuels (VPC).

Cloud Router n'est pas une option de connectivité, mais un service qui fonctionne sur des connexions Cloud VPN ou Cloud Interconnect pour fournir un routage dynamique à l'aide du protocole BGP (Border Gateway Protocol) pour vos réseaux VPC. Cloud Router n'est pas compatible avec les connexions par appairage direct ou par appairage opérateur.

Cloud Router n'est pas un appareil physique susceptible de provoquer un goulot d'étranglement. Il ne peut pas être utilisé seul. Toutefois, il est requis ou recommandé dans les cas suivants :

  • Requis pour Cloud NAT
  • Requis pour Cloud Interconnect et les VPN haute disponibilité
  • Recommandé comme option de configuration pour les VPN classiques

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 des informations de topologie via le protocole BGP.

Les modifications de topologie se répercutent automatiquement entre votre réseau VPC et votre réseau sur site. Lorsque vous utilisez Cloud Router, vous n'avez pas besoin de configurer des routes statiques.

Tâches logicielles Cloud Router

Les routeurs Cloud Router sont mis en œuvre par une ou deux tâches logicielles, en fonction de leur interface :

  • Si un routeur Cloud Router possède au moins deux interfaces, chacune étant connectée à un tunnel Cloud VPN dans la même paire de tunnels VPN haute disponibilité (connectée à la même passerelle VPN haute disponibilité), Google Cloud utilise deux tâches logicielles pour mettre en œuvre le routeur Cloud Router et assurer la redondance logicielle.
  • Dans toutes les autres situations, Google Cloud met en œuvre le routeur Cloud Router à l'aide d'une seule tâche logicielle.

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 des routes statiques, les réseaux découvrent automatiquement et rapidement les changements de topologie via BGP. Des modifications sont mises en œuvre de manière fluide, 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 Cloud Router et votre routeur ou passerelle sur site.

Routage statique pour les tunnels Cloud VPN

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

  • Une modification de la configuration d'un réseau d'un côté ou de l'autre d'un tunnel Cloud VPN nécessite la création et la suppression manuelles des routes statiques correspondant à cette modification. En outre, la convergence des modifications des routes statiques peut prendre beaucoup de temps.
  • Lorsque vous créez un tunnel Cloud VPN pour utiliser des routes statiques, vous devez spécifier la liste des préfixes IP de chaque côté du tunnel avant sa création. Cela signifie que chaque fois que les routes doivent changer, vous devez supprimer et recréer le tunnel Cloud VPN et configurer de 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.

Vous pouvez éviter d'avoir à modifier la configuration des routes statiques et des tunnels Cloud VPN en déployant Cloud Router. Cloud Router est appairé à votre passerelle Cloud VPN via BGP pour échanger des informations de topologie. En réalité, les modifications de la topologie de votre réseau Google Cloud se propagent automatiquement vers votre réseau, et inversement, à l'aide de BGP. Vous n'avez donc pas besoin de configurer des routes statiques pour vos tunnels Cloud VPN.

Exigences du routage dynamique pour Cloud Interconnect et Cloud VPN

Vous devez disposer d'un routeur cloud existant avant de pouvoir effectuer les opérations suivantes :

Lorsque vous créez un routeur cloud, vous pouvez choisir le numéro ASN côté Google. Si vous ne spécifiez pas de numéro ASN, Google Cloud en choisit un. Cependant, vous devez spécifier manuellement le numéro ASN de votre routeur (pair) sur site dans les paramètres de configuration de Cloud Router.

Vous pouvez spécifier des adresses BGP des manières suivantes :

  • Pour l'interconnexion dédiée, vous pouvez spécifier des plages d'adresses ou demander à Google Cloud de les sélectionner. Pour plus d'informations, consultez la page Créer des rattachements Cloud Interconnect (VLAN).
  • Pour l'interconnexion partenaire, vous ne spécifiez jamais l'adressage BGP.
  • Pour les VPN haute disponibilité et les VPN classiques utilisant le routage dynamique, vous pouvez spécifier les adresses IP BGP lorsque vous créez l'interface BGP sur Cloud Router.

Mode de routage dynamique

Cette section décrit des exemples de routage dynamique régional et global. Pour en savoir plus sur les modes de routage dynamique des réseaux VPC, consultez la page Présentation du réseau VPC.

Pour obtenir plus d'informations sur le mode de routage dynamique et les équilibreurs de charge, consultez la page Équilibrage de charge TCP/UDP interne et réseaux connectés.

Exemple de routage dynamique régional

Avec le routage dynamique régional, vous pouvez disposer d'un tunnel Cloud VPN et de VM dans une seule région Google Cloud. Le tunnel étend votre réseau sur site à un réseau VPC. Les VM d'autres régions devront peut-être se connecter au réseau sur site, mais elles ne pourront 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, la visibilité de Cloud Router sur les ressources est limitée à la région us-west1. Les 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)

Exemple 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 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 de us-west1 annonce des sous-réseaux dans deux régions différentes : us-west1 et us-central1. Les 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.

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 Google Cloud atteint, les routes et les règles du pare-feu de votre réseau VPC déterminent la manière dont Google Cloud 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. Cloud Router annonce automatiquement les nouveaux sous-réseaux. 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.

Vous devez spécifier des annonces de routage personnalisées dans les cas suivants :

  • Pour annoncer des adresses IP en dehors de la plage d'adresses IP principale d'un sous-réseau ou de l'une de ses plages d'adresses IP secondaires. Par exemple, pour annoncer des adresses IP externes.
  • Pour annoncer des routes d'un autre réseau VPC connecté à votre réseau VPC à l'aide de l'appairage de réseaux VPC. Dans ce cas, les routes de sous-réseau et les routes personnalisées importées sur un réseau appairé ne sont pas automatiquement annoncées par un routeur cloud de votre réseau VPC. Pour les annoncer, vous devez créer des annonces de routage personnalisées sur le routeur cloud de votre réseau VPC et vous assurer que les connexions d'appairage du réseau VPC sont configurées pour échanger les routes personnalisées.

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. Ainsi, 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é

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 situées en dehors de la plage d'adresses IP d'un sous-réseau, telles que des 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 de alias-subnet. Si vous créez des sous-réseaux dans la région 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 Google Cloud qui diffuse à des clients sur votre réseau sur site. Lorsque vous effectuez des opérations de maintenance sur l'application, vous pouvez associer à nouveau l'adresse IP statique à une autre VM afin de minimiser le 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 ou des 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 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 en différents sous-réseaux. Vous configurez donc deux sessions BGP qui annoncent des plages d'adresses IP différentes. Grâce à l'utilisation de deux sessions BGP différentes, le trafic destiné à l'un des sous-réseaux ne se dirige pas par inadvertance vers un autre sous-réseau. L'exemple qui suit 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.

Routes dynamiques personnalisées apprises

Lorsqu'un routeur cloud reçoit plusieurs sauts suivants pour le même préfixe de destination, Google Cloud utilise des métriques de routage et, dans certains cas, la longueur du chemin AS pour créer des routes dynamiques personnalisées dans votre réseau VPC. Cette section décrit ce processus.

Effets du mode de routage dynamique

Le mode de routage dynamique d'un réseau VPC détermine la façon dont les routes dynamiques personnalisées tirées de Cloud Router sont appliquées.

  • En mode de routage dynamique régional, Cloud Router crée une route dynamique personnalisée pour la destination et le saut suivant dans la même région que Cloud Router. Cloud Router définit la priorité de cette route dynamique personnalisée sur la priorité de base, que Cloud Router dérive du MED annoncé par votre routeur local.

  • En mode de routage dynamique global, Cloud Router crée une route dynamique personnalisée pour la destination et le saut suivant dans chaque région Google Cloud. Dans la région qui contient le routeur cloud ayant appris cette route, Cloud Router définit la priorité de la route dynamique personnalisée sur la priorité de base. Dans toutes les autres régions, Cloud Router définit la priorité sur la priorité de base et ajoute un coût régional approprié.

Vous pouvez définir la priorité de routage des routes vers Google Cloud exportées vers votre routeur sur site. Cependant, cette priorité de route peut être remplacée par votre routeur sur site, selon sa configuration. Par exemple, si votre routeur sur site modifie la priorité de la route.

Pour les routes vers le routeur sur site apprises par Cloud Router, Cloud Router obtient la longueur de chemin AS et les valeurs MED puis calcule une priorité de base, comme décrit dans les deux sections suivantes.

Préfixage et longueur du chemin AS

Le préfixage de chemin AS permet à un saut suivant pour une destination (préfixe) d'être intentionnellement relégué au second plan afin de sélectionner un autre saut suivant pour la même destination (préfixe) avec un chemin AS plus court. La valeur MED n'est prise en compte que lorsque les longueurs des chemins AS des sauts suivants sont identiques.

Google Cloud peut se servir du chemin AS pour sélectionner un saut suivant entre les sessions BGP mises en œuvre par la même tâche logicielle Cloud Router.

Comment Google Cloud utilise le chemin AS

Le préfixage de chemin AS n'est pas pertinent pour le plan de contrôle et le réseau VPC. La longueur du chemin AS n'est prise en compte que dans les tâches logicielles Cloud Router, comme décrit dans les scénarios suivants.

Si une tâche logicielle Cloud Router unique apprend la même destination à partir de plusieurs sessions BGP :

  • La tâche logicielle sélectionne la session BGP à saut suivant avec le chemin AS le plus court.
  • La tâche logicielle envoie des informations sur la destination, le saut suivant et les valeurs MED au plan de contrôle Cloud Router.
  • Le plan de contrôle utilise ces informations pour créer une ou plusieurs routes candidates. La priorité de base de chaque candidat est définie sur la valeur MED reçue.

Si plusieurs tâches logicielles Cloud Router apprennent la même destination à partir de plusieurs sessions BGP :

  • Chaque tâche logicielle sélectionne une session BGP à saut suivant avec le chemin AS le plus court.
  • Chaque tâche logicielle envoie des informations sur la destination, le saut suivant et les valeurs MED au plan de contrôle Cloud Router.
  • Le plan de contrôle utilise ces informations pour créer au moins deux routes candidates. La priorité de base de chaque candidat est définie sur la valeur MED reçue.

Le plan de contrôle Cloud Router installe ensuite une ou plusieurs routes dynamiques personnalisées dans le réseau VPC, en fonction du mode de routage dynamique de celui-ci. En mode de routage dynamique global, la priorité de chaque route dynamique régionale personnalisée est ajustée dans des régions différentes de la région Cloud Router. Consultez la section Ordre de routage pour en savoir plus sur la manière dont Google Cloud sélectionne une route.

Priorité de base et valeur MED

Cloud Router utilise la valeur MED annoncée par votre routeur pair pour calculer une priorité de base :

  • Si la valeur MED du préfixe d'une destination est comprise entre 0 et 231 -1 (inclus), Cloud Router définit la priorité de base sur la valeur MED.
  • Si la valeur MED du préfixe d'une destination est comprise entre 231  et 232 -1 (inclus), Cloud Router définit la priorité de base sur 231 -1.

La valeur de priorité finale définie par Cloud Router lors de la création de routes dynamiques personnalisées dans un réseau VPC dépend du mode de routage dynamique du réseau. Pour plus d'informations, consultez la section Effets du mode de routage dynamique.

Routes statiques

Consultez la section Ordre de routage dans la documentation sur le routage VPC.

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

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

Pour plus d'informations, consultez la section Routes applicables dans la documentation sur le VPC.

Publier une route apprise d'une session BGP vers une autre session BGP

Cloud Router n'est actuellement pas compatible avec les annonces de routage statique, ni avec les routes sur site apprises d'une session BGP vers une autre. Toute tentative de configuration de ce type peut entraîner la suppression de la route.

Pour plus d'informations sur la façon d'échanger correctement des itinéraires dynamiques avec plusieurs réseaux VPC, consultez la section Certains préfixes IP ne se propagent pas ou ne sont pas disponibles sur la page de dépannage de Cloud Router.

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. Lorsque vous disposez 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 100 et la valeur doit être un entier positif. Cloud Router considère une priorité de base annoncée qui a une valeur numérique de 1 comme la route de priorité la plus élevée. Cette valeur passe avant les priorités inférieures qui ont une valeur de 2 ou plus.

La priorité de base des routes annoncées permet de définir des priorités pour les routes. Par exemple, vous pouvez avoir un tunnel Cloud VPN et une connexion d'Interconnexion dédiée qui relie votre réseau VPC et vos réseaux locaux. Vous pouvez définir la priorité de base des routes annoncées de sorte que le trafic privilégie l'Interconnexion dédiée. Si la connexion Cloud Interconnect 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 Google Cloud distantes) ou qu'il 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 du 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. Imaginons par exemple que vous disposez de deux connexions entre votre réseau VPC et votre réseau sur site, comme deux tunnels Cloud 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. En l'absence de coûts régionaux, le trafic est dirigé équitablement sur les deux connexions, ce qui entraîne des performances de réseau inégales.

Cloud Router ajoute des coûts régionaux lorsqu'il propage les routes apprises vers des régions Google Cloud distantes. Cela permet de maintenir la symétrie entre le trafic entrant et sortant, entre le réseau VPC et les réseaux 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.

Si 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 Cloud VPN dotés de leurs propres routeurs cloud. Un tunnel est 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 leurs régions respectives. Mais que se passe-t-il si vous souhaitez atteindre des VM qui ne se trouvent pas dans ces régions, comme des VM 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 la région europe-west1, mais avec des métriques de routage différentes. Le routeur cloud de la région us-central1 annonce des routes vers europe-west1 avec une métrique de routage inférieure à celle vers us-west1 en raison de la distance, de la latence et d'autres facteurs. L'exemple suppose que le coût régional pour la région 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, de sorte que le trafic entrant vers us-west1 privilégie le tunnel principal, comme illustré 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 la région us-west1 privilégie le tunnel de secours avec une métrique de routage de 51 par rapport au tunnel us-central1, qui a une métrique de routage 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.

Si tous les tunnels ou toutes les connexions Cloud Interconnect d'une région sont d'une priorité égale, 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 Cloud 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 Cloud VPN. Spécifiez une priorité de base de 10,051 pour les routes du tunnel Cloud VPN afin que le tunnel n'ait plus la priorité. L'ensemble du trafic entrant utilise donc 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 passe par le tunnel Cloud VPN uniquement en cas d'échec de la connexion.

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

Il vous faudra aussi 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 routes annoncées.

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 Google Cloud VPC incluent automatiquement une route par défaut, 0.0.0.0/0, qui envoie le trafic vers 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, puis affichez Default internet gateway dans le saut suivant.

Redémarrage progressif

Cloud Router se plie aux messages de redémarrage progressif envoyés par votre routeur sur site. Si vous avez activé le redémarrage progressif sur votre routeur sur site, il peut envoyer une notification à Cloud Router chaque fois qu'il doit installer des mises à jour logicielles ou effectuer des opérations de maintenance. Cloud Router conserve les routes dynamiques personnalisées apprises de votre routeur sur site pendant la période définie par le paramètre du compteur de redémarrage progressif de votre routeur sur site.

Pour plus d'informations sur les compteurs de redémarrage progressif, consultez la section Paramètres des timers BGP.

Paramètres des timers BGP

Cloud Router et votre routeur sur site maintiennent la communication à l'aide des paramètres de timer suivants :

Timer keepalive
Il s'agit de l'intervalle entre les pulsations BGP périodiques échangées entre un routeur cloud et le routeur pair sur site correspondant. Conjointement avec le timer de préservation, le timer keepalive indique à chaque routeur la disponibilité de l'autre. Réglez le timer du message keepalive de votre routeur sur site sur 20 secondes.
Timer de préservation
Ce timer effectue le suivi du temps minimal écoulé depuis que la dernière pulsation keepalive réussie a été détectée. Il indique la durée pendant laquelle le routeur cloud ou votre routeur sur site doit attendre avant de supprimer les routes apprises de l'autre routeur. Réglez le délai d'attente de votre routeur sur site sur 60 secondes.
Timer de redémarrage progressif

Il s'agit de la durée pendant laquelle votre routeur sur site attend, sans pulsations périodiques keepalive, après avoir reçu une notification de redémarrage de la part du routeur cloud correspondant, avant de pouvoir espérer de nouvelles pulsations keepalive. Si votre routeur sur site ne reçoit pas de nouvelles pulsations keepalive, il supprime les routes qu'il a apprises du routeur cloud.

Nous vous recommandons de définir ce timer sur 1 seconde sur votre routeur sur site si vous souhaitez qu'il se comporte de la même manière que Cloud Router.

Cloud Router retire les routes dynamiques personnalisées apprises des périphériques sur site lorsqu'il détermine qu'un tunnel Cloud VPN du saut suivant est défaillant ou qu'une connexion Cloud Interconnect est défaillante. Si vous paramétrez le délai de redémarrage progressif du routeur sur site sur une valeur supérieure à une seconde, il se pourrait que votre routeur sur site envoie le trafic retour à un saut suivant qui n'est plus actif, au lieu de passer à un saut suivant secondaire qui a été configuré et qui est actif.

Timer stalepath

Ce paramètre détermine la durée pendant laquelle un routeur attend avant de supprimer les routes apprises après qu'un message de fin d'enregistrement (EPR) est reçu de l'autre routeur. Ce compteur démarre lorsque la session BGP est réinitialisée après un redémarrage progressif, mais le préfixe en question n'a pas reçu de message de mise à jour. Nous vous recommandons de le définir sur 300 secondes sur votre routeur sur site pour qu'il corresponde au paramètre de Cloud Router.

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 Cloud VPN routé de manière dynamique n'entre plus dans le tunnel. Les routes statiques du tunnel continuent 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.

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 timer 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.

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

Redémarrage de session BGP et ID de routeur BGP

Cloud Router sélectionne son adresse IP d'interface la plus élevée pour son ID de routeur BGP et conserve cet ID tant que l'adresse est disponible. Si vous supprimez l'interface Cloud Router utilisée pour l'ID de routeur BGP, Cloud Router doit sélectionner un nouvel ID de routeur. Cette sélection entraîne le redémarrage de toutes vos sessions BGP. L'ID de routeur peut également changer si Cloud Router redémarre pour une maintenance périodique.

Et ensuite ?

Pour résoudre les problèmes courants rencontrés avec Cloud Router, consultez la documentation sur le dépannage.

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

Produit Routage Documentation
Interconnexion dédiée Statique Non compatible
Interconnexion dédiée Dynamique Créer des rattachements de VLAN
VPN standard Basé sur des règles, statique Créer un VPN classique à l'aide d'un routage statique
VPN classique ou VPN haute disponibilité Dynamique Créer un VPN classique à l'aide d'un routage dynamique
Créer une passerelle VPN haute disponibilité vers une passerelle VPN pair
Créer des passerelles VPN haute disponibilité entre deux réseaux Google Cloud