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 s'exécute sur des connexions Cloud VPN ou d'interconnexion pour fournir un routage dynamique à l'aide de 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 (Multi-Exit Discriminator) 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.

Priorités et préfixes annoncés

Lorsqu'un Cloud Router annonce les préfixes à un pair BGP, il inclut une priorité pour chaque préfixe de l'annonce (message BGP). La priorité annoncée est mise en œuvre en tant que MED.

Vous pouvez contrôler les préfixes annoncés par Cloud Router sur l'ensemble ou une partie de ses sessions BGP. Vous contrôlez la priorité annoncée (MED) en définissant une priorité de base pour les préfixes.

  • Si votre réseau VPC utilise le mode de routage dynamique régional, sauf si vous annoncez des plages personnalisées, chaque Cloud Router n'annonce que les plages de sous-réseaux de la même région que Cloud Router. Chaque plage est présentée sous forme de préfixe, le MED étant la priorité de base.

  • Si votre réseau VPC utilise le mode de routage dynamique global, sauf si vous annoncez des plages personnalisées, chaque Cloud Router annonce les plages de sous-réseau de sa région locale en tant que préfixes dont le MED correspond à la priorité de base. De plus, les Cloud Router annoncent des plages de sous-réseaux provenant de différentes régions sous la forme de préfixes, dont les MED correspondent à la priorité de base plus un coût régional. Google Cloud calcule automatiquement un coût régional en fonction de facteurs tels que les performances réseau, la distance et la bande passante disponible entre les régions. Chaque coût régional comporte une valeur spécifique à une paire de régions : la région du sous-réseau et la région du Cloud Router des annonces.

Lorsque les préfixes annoncés et leurs priorités sont reçus par vos routeurs sur site, vos routeurs sur site créent des routes permettant d'envoyer des paquets à votre réseau VPC.

Conseils pour les priorités de base

Lorsque vous configurez une session BGP sur un Cloud Router, vous pouvez spécifier une priorité de base annoncée pour la session BGP. La priorité de base annoncée s'applique à tous les préfixes (destinations) annoncés par cette session BGP.

Les priorités de base sont des nombres entiers allant de 0 à 65535. La priorité de base la plus élevée possible est 0. La priorité de base par défaut est 100. Si vous ne spécifiez pas de priorité de base, celle par défaut est utilisée.

Les priorités de base vous permettent de contrôler quels tunnels Cloud VPN ou rattachements Cloud Interconnect (VLAN) utilisent des envois de paquets à votre réseau VPC. Vous pouvez créer des combinaisons actives/actives, actives/passives ou une combinaison personnalisée de ces topologies à l'aide de la priorité de base. Pour obtenir un exemple d'utilisation de tunnels VPN haute disponibilité, consultez la section Options de routage actif/actif et actif/passif pour le VPN haute disponibilité.

Lorsque vous choisissez les priorités de base, tenez compte des points suivants :

  • Les coûts régionaux sont compris entre 201 et 9999, inclus. La valeur dépend de la distance, de la latence et d'autres facteurs entre deux régions. Google génère les valeurs de coûts régionaux, et vous ne pouvez pas les modifier.

  • Les priorités de base des sessions BGP entre les routeurs Cloud Router d'une région doivent être comprises entre 0 et 200, inclus. Étant donné que les coûts régionaux sont au moins de 201, si vous utilisez des priorités de base de 201 ou plus, vous pouvez attribuer accidentellement une priorité inférieure à vos attentes à un tunnel Cloud VPN ou un rattachement de VLAN Cloud Interconnect. Une autre session BGP d'une région différente peut annoncer le même préfixe avec une priorité globale plus élevée (MED, ce qui correspond à une priorité de base plus un coût régional). Sans définir avec soin les priorités de base d'autres régions, vous risquez d'acheminer le trafic sur site vers votre réseau VPC via un tunnel Cloud VPN inattendu ou un rattachement de VLAN Cloud Interconnect.

  • Les priorités de base de 10,200 ou plus assurent que la priorité globale annoncée d'un préfixe (MED, priorité de base plus coût régional) est toujours inférieure à celle de tout autre préfixe annoncé avec une priorité de base de200 ou moins.

Pour plus d'informations sur la définition d'une priorité de base, consultez la section Mettre à jour la priorité de base des routes annoncées.

Exemples

Cette section fournit des exemples illustrant l'influence des coûts régionaux sur les MED annoncés lorsque vous utilisez le routage dynamique global.

VPN haute disponibilité avec tunnels actifs/actifs

Dans cet exemple, vous disposez d'un réseau VPC avec les éléments suivants :

  • Un sous-réseau dans chacune des régions suivantes : us-central1, europe-west1 et us-west-1
  • Un Cloud Router qui gère deux sessions BGP pour deux tunnels VPN haute disponibilité dans us-central1
  • Un Cloud Router qui gère deux sessions BGP pour deux tunnels VPN haute disponibilité dans us-west1

Le schéma suivant illustre cet exemple. Le schéma comprend des exemples de valeurs pour le coût régional.

VPN haute disponibilité avec tunnels actifs/actifs (cliquez pour agrandir)
VPN haute disponibilité avec tunnels actifs/actifs (cliquez pour agrandir)

Supposons que chaque session BGP dispose de la priorité de base par défaut de 100.

Les tables suivantes montrent comment utiliser les priorités de base et le coût régional pour calculer les valeurs MED annoncées pour le trafic entre votre réseau sur site et chaque sous-réseau.

10.0.1.0/24 (us-central1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.1.0/24, qui se trouve dans us-central1.

Le trafic provenant de votre réseau sur site utilise le VPN haute disponibilité dans la région us-central1, car ses sessions BGP ont le MED le plus bas proposé.

Tunnel VPN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0,
central-tunnel-1
100 0 100 Premier choix
west-tunnel-0,
west-tunnel-1
100 250 350 Second choix

10.0.2.0/24 (europe-west1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.2.0/24, qui se trouve dans europe-west1.

Le trafic provenant de votre réseau sur site utilise le VPN haute disponibilité dans la région us-central1, car ses sessions BGP ont le MED le plus bas proposé.

Tunnel VPN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0,
central-tunnel-1
100 300 400 Premier choix
west-tunnel-0,
west-tunnel-1
100 350 450 Second choix

10.0.3.0/24 (us-west1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.3.0/24, qui se trouve dans us-west1.

Le trafic provenant de votre réseau sur site utilise le VPN haute disponibilité dans la région us-west1, car ses sessions BGP ont le MED le plus bas proposé.

Tunnel VPN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0,
central-tunnel-1
100 250 350 Second choix
west-tunnel-0,
west-tunnel-1
100 0 100 Premier choix

VPN haute disponibilité avec tunnels actifs/passifs

Cet exemple utilise la même topologie que dans l'exemple précédent, mais avec des priorités de base modifiées afin d'obtenir une paire de tunnels VPN haute disponibilité actifs/passifs dans chaque région :

  • Un tunnel principal dont la session BGP a la priorité de base par défaut de 100
  • Un tunnel secondaire dont la session BGP a une priorité inférieure de 351

Les tables suivantes montrent comment utiliser les priorités de base et le coût régional pour calculer les valeurs MED annoncées pour le trafic entre votre réseau sur site et chaque sous-réseau.

10.0.1.0/24 (us-central1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.1.0/24, qui se trouve dans us-central1.

Le trafic provenant de votre réseau sur site utilise le tunnel VPN principal dans us-central1, car sa session BGP a le MED le plus bas annoncé. Si ce tunnel n'est pas disponible, le trafic utilise le tunnel principal dans us-west1.

Tunnel VPN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0 100 0 100 Premier choix
central-tunnel-1 351 0 351 Troisième choix
west-tunnel-0 100 250 350 Second choix
west-tunnel-1 351 250 601 Quatrième choix

10.0.2.0/24 (europe-west1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.2.0/24, qui se trouve dans europe-west1.

Le trafic provenant de votre réseau sur site utilise le tunnel VPN principal dans us-central1, car sa session BGP a le MED le plus bas annoncé. Si ce tunnel n'est pas disponible, le trafic utilise le tunnel principal dans us-west1.

Tunnel VPN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0 100 300 400 Premier choix
central-tunnel-1 351 300 651 Troisième choix
west-tunnel-0 100 350 450 Second choix
west-tunnel-1 351 350 701 Quatrième choix

10.0.3.0/24 (us-west1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.3.0/24, qui se trouve dans us-west1.

Le trafic provenant de votre réseau sur site utilise le tunnel VPN principal dans us-west1, car sa session BGP a le MED le plus bas annoncé. Si ce tunnel n'est pas disponible, le trafic utilise le tunnel principal dans us-central1.

Tunnel VPN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0 100 250 350 Second choix
central-tunnel-1 351 250 601 Quatrième choix
west-tunnel-0 100 0 100 Premier choix
west-tunnel-1 351 0 351 Troisième choix

Interconnexion dédiée préférée mondialement

Cet exemple est semblable aux exemples précédents, à la différence que vous avez remplacé les deux tunnels Cloud VPN dans la région us-west1 par deux rattachements de VLAN Cloud Interconnect.

Le schéma suivant illustre cet exemple.

Interconnexion dédiée préférée mondialement (cliquez pour agrandir)
Interconnexion dédiée préférée mondialement (cliquez pour agrandir)

Vous souhaitez donner la priorité aux rattachements de VLAN de l'interconnexion dédiée. Spécifiez les priorités de base plus importantes pour les tunnels VPN haute disponibilité dans la région us-central1 afin de retirer leur priorité.

Les tables suivantes montrent comment utiliser les priorités de base et le coût régional pour calculer les valeurs MED annoncées pour le trafic entre votre réseau sur site et chaque sous-réseau.

10.0.1.0/24 (us-central1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.1.0/24, qui se trouve dans us-central1.

Le trafic provenant de votre réseau sur site utilise l'interconnexion dédiée dans la région us-west1, car ses sessions BGP ont la version MED la plus basse annoncée.

Tunnel VPN ou rattachement de VLAN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0,
central-tunnel-1
351 0 351 Second choix
west-attachment-0,
west-attachment-1
100 250 350 Premier choix

10.0.2.0/24 (europe-west1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.2.0/24, qui se trouve dans europe-west1.

Le trafic provenant de votre réseau sur site utilise l'interconnexion dédiée dans la région us-west1, car ses sessions BGP ont la version MED la plus basse annoncée.

Tunnel VPN ou rattachement de VLAN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0,
central-tunnel-1
351 300 651 Second choix
west-attachment-0,
west-attachment-1
100 350 450 Premier choix

10.0.3.0/24 (us-west1)

Cette table présente les sessions BGP qui annoncent la plage d'adresses IP du sous-réseau 10.0.3.0/24, qui se trouve dans us-west1.

Le trafic provenant de votre réseau sur site utilise l'interconnexion dédiée dans la région us-west1, car ses sessions BGP ont la version MED la plus basse annoncée.

Tunnel VPN ou rattachement de VLAN Priorité de base Coût régional MED annoncé Classement des chemins d'accès
central-tunnel-0,
central-tunnel-1
351 250 601 Second choix
west-attachment-0,
west-attachment-1
100 0 100 Premier choix

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.

Cloud Router définit cette valeur sur 1 seconde. Pour votre routeur sur site, définissez le compteur de redémarrage progressif sur une valeur adaptée à vos besoins. Chaque routeur communique sa valeur de compteur de redémarrage progressif au pair via le message OPEN lors de l'établissement d'une session BGP.

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.

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.

Étape suivante

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