Présentation de Cloud Router

Cloud Router est un service Google Cloud entièrement distribué et géré qui utilise le protocole BGP (Border Gateway Protocol) pour annoncer des plages d'adresses IP. Il programme des routes dynamiques personnalisées en fonction des annonces BGP reçues d'un pair. Au lieu d'un appareil physique ou d'un dispositif matériel, chaque routeur cloud est mis en œuvre par des tâches logicielles qui agissent en tant que speakers et répondeurs BGP. Un routeur cloud sert également de plan de contrôle pour Cloud NAT. Cloud Router fournit des services BGP pour les produits Google Cloud suivants :

Nous vous recommandons également d'utiliser Cloud Router pour les VPN classiques si votre passerelle VPN sur site est compatible avec BGP.

Lorsque vous connectez votre réseau sur site à Google Cloud, Cloud Router utilise BGP pour échanger de manière dynamique des routes entre votre réseau VPC Google Cloud et votre réseau sur site. Les modifications de préfixe et de saut suivant se propagent automatiquement entre votre réseau VPC et votre réseau sur site sans nécessiter de routes statiques.

Chaque routeur cloud fonctionne avec l'un des produits de connectivité réseau répertoriés précédemment. L'appairage direct et l'appairage opérateur n'utilisent pas les routeurs cloud.

Spécifications

Un routeur cloud peut annoncer des routes de sous-réseau et des préfixes personnalisés sur ses sessions BGP. À moins que vous ne configuriez des annonces de routage personnalisées, un routeur cloud n'annonce que des routes de sous-réseau. Les annonces de routage personnalisées vous permettent également de configurer un routeur cloud pour qu'il n'annonce pas certaines routes de sous-réseau.

Le mode de routage dynamique d'un réseau VPC détermine les routes de sous-réseau annoncées par les routeurs cloud de ce réseau :

  • Lorsque vous utilisez le mode de routage dynamique régional, chaque routeur cloud du réseau VPC n'annonce que les routes de sous-réseau situées dans la même région que le routeur cloud.

  • Lorsque vous utilisez le mode de routage dynamique global, chaque routeur cloud du réseau VPC annonce toutes les routes de sous-réseau situées dans toutes les régions du réseau VPC.

Le mode de routage dynamique contrôle également la manière dont chaque routeur cloud applique les préfixes appris en tant que routes dynamiques personnalisées dans un réseau VPC. Pour en savoir plus sur ce comportement, consultez la section Effets du mode de routage dynamique.

Numéro de système autonome (ASN)

Lorsque vous créez un routeur cloud, vous choisissez le numéro ASN côté Google pour toutes les sessions BGP utilisées par le routeur cloud. Les instructions correspondant à chaque produit de connectivité réseau, répertoriées dans la section Utiliser Cloud Router, fournissent des détails sur la manière dont chaque produit utilise le numéro ASN.

Adresses IP BGP

Les sessions BGP pour les produits de connectivité réseau suivants utilisent des adresses IP de liaison locale comprises dans la plage 169.254.0.0/16 en tant qu'adresses IP BGP :

  • Pour l'interconnexion dédiée, vous pouvez spécifier des candidats pour les adresses IP BGP de liaison locale, ou Google Cloud peut sélectionner automatiquement des adresses de liaison locale inutilisées.
  • Pour l'interconnexion partenaire, Google Cloud sélectionne automatiquement des adresses de liaison locale inutilisées.
  • 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.

Les appareils de routeur utilisent des adresses IP internes de VM Google Cloud comme adresses IP BGP. Pour en savoir plus, consultez la section Créer des instances d'appareils de routeur.

Accès aux équilibreurs de charge internes

Pour en savoir plus sur l'accès aux équilibreurs de charge internes à partir d'un réseau sur site connecté, consultez la page Équilibreurs de charge internes et réseaux connectés dans la documentation de Cloud Load Balancing.

Tâches logicielles Cloud Router

Les routeurs Cloud Router sont mis en œuvre par une, deux ou dans de rares cas, trois tâches logicielles.

Le tableau suivant fournit des exemples de scénarios et indique le nombre de tâches logicielles utilisées par Google Cloud pour mettre en œuvre le routeur Cloud Router dans chaque scénario.

  • Pour les configurations de haute disponibilité répertoriées dans le tableau, deux tâches logicielles sont utilisées pour assurer la redondance logicielle.
  • Pour les rattachements de VLAN, une tâche logicielle distincte gère chaque domaine de disponibilité de périphérie avec des rattachements.
Exemple de scénario Nombre de tâches logicielles utilisées pour mettre en œuvre le routeur Cloud Router
Une ou plusieurs interfaces, chacune étant connectée à un tunnel VPN classique. Un
Une ou plusieurs interfaces dont chacune est connectée à un rattachement de VLAN, les rattachements de VLAN se trouvant dans le même domaine de disponibilité de périphérie. Un
Un nombre quelconque d'interfaces dont chacune est connectée à un tunnel VPN haute disponibilité, les tunnels étant connectés au même numéro d'interface sur une ou plusieurs passerelles VPN haute disponibilité (par exemple, deux tunnels, connectés à interface 0 sur différentes passerelles VPN haute disponibilité). Un
Deux interfaces ou plus, l'une connectée à un rattachement de VLAN dans un seul domaine de disponibilité de périphérie et l'autre connectée à un seul tunnel VPN haute disponibilité, le domaine de disponibilité de périphérie et les numéros d'interface de passerelle VPN étant identiques (par exemple, le premier domaine de disponibilité de périphérie d'une paire de domaines de disponibilité de périphérie et la première interface de passerelle VPN). Un
Au moins deux interfaces, chacune connectée à une instance de dispositif de routeur, où l'une des interfaces est configurée en tant qu'interface redondante. Pour créer une interface redondante, utilisez l'option redundant-interface (outil de ligne de commande gcloud) ou le champ redundantInterface (API Compute Engine). Le dispositif de routeur fait partie de Network Connectivity Center, disponible en version Bêta. Deux
Deux interfaces ou plus dont chacune est connectée à un rattachement de VLAN, les rattachements de VLAN se trouvant dans des domaines de disponibilité de périphérie différents. Deux
Deux interfaces ou plus dont chacune est connectée à un tunnel VPN haute disponibilité, chaque tunnel étant connecté à des numéros d'interface de passerelle VPN haute disponibilité différents (par exemple un tunnel connecté à l'interface 0 d'une passerelle VPN haute disponibilité et un autre tunnel connecté à l'interface 1 de cette même passerelle ou d'une autre passerelle). Deux
Un routeur Cloud Router avec au moins les éléments suivants :
  • Une interface connectée à un rattachement de VLAN dans le edge availability domain 0 et/ou une interface connectée à un tunnel VPN haute disponibilité connecté à l'interface 0 d'une passerelle VPN haute disponibilité.
  • Une interface connectée à un rattachement de VLAN dans le edge availability domain 1 et/ou une interface connectée à un tunnel VPN haute disponibilité connecté à l'interface 1 d'une passerelle VPN haute disponibilité.
  • Une interface connectée à un tunnel VPN classique.
Trois

Maintenance des logiciels et redémarrage automatique des tâches

Google Cloud exécute régulièrement des événements de maintenance pour lancer de nouvelles fonctionnalités et améliorer la fiabilité. Lors de la maintenance, de nouvelles tâches logicielles sont provisionnées. Les journaux de votre routeur sur site indiquent que les sessions BGP gérées par ces tâches logicielles ont été interrompues puis rétablies (une oscillation BGP).

La maintenance de Cloud Router est un processus automatique qui est conçu pour ne pas interrompre le routage. Les événements de maintenance ne devraient pas prendre plus de 60 secondes. Avant la maintenance, Cloud Router envoie une notification de redémarrage en douceur (un paquet TCP FIN) au routeur sur site.

Si votre routeur sur site est capable de traiter les événements de redémarrage en douceur, il consigne un événement de redémarrage en douceur lors de la maintenance Cloud Router. Pour les routeurs sur site non compatibles avec le redémarrage en douceur, assurez-vous que le timer de préservation du routeur sur site est défini sur 60 secondes. Pour en savoir plus, consultez la section Gérer les timers BGP.

Les événements de maintenance de Cloud Router ne sont pas annoncés à l'avance, car les routes ne sont pas perdues sur les routeurs sur site correctement configurés. Pour en savoir plus sur les événements de maintenance ayant eu lieu, consultez la page Identifier les événements de maintenance du routeur.

Redémarrage automatique des tâches lorsque les identifiants du routeur changent

Les tâches logicielles Cloud Router utilisent un identifiant interne basé sur la dernière interface de la liste d'interface du routeur cloud. Si vous supprimez cette interface, Google Cloud redémarre les tâches logicielles Cloud Router pour leur attribuer de nouveaux identifiants. Par conséquent, la suppression d'une session BGP peut parfois entraîner le redémarrage de toutes les autres sessions BGP comme si un événement de maintenance logicielle s'était produit. Dans ce cas, les routes sont conservées sur les routeurs sur site correctement configurés.

L'identifiant interne n'est pas visible par vous et peut parfois changer lors de la maintenance des logiciels et du redémarrage automatique des tâches.

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. Votre réseau sur site envoie des paquets à vos réseaux VPC dont l'adresse IP de destination 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.

Annonces de routage 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.

Spécifiez 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 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 Router de votre réseau VPC. Pour les annoncer, vous devez créer des annonces de routage personnalisées sur le routeur Cloud Router de votre réseau VPC. Vous devez également vous assurer que les connexions d'appairage de réseaux 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.

Annonces de routage 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 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 les sous-réseaux que vous souhaitez exposer. Toutefois, lorsque vous annoncez les sous-réseaux de manière sélective, vous devez ajouter manuellement les nouveaux sous-réseaux à l'annonce de routage personnalisée. Cloud Router n'annoncera 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 de la session BGP ignore et remplace l'annonce de routage du routeur Cloud Router.

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 d'annonces de routage

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 le schéma 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.
Annonce de routage par défaut Cloud Router (cliquez pour agrandir)

Annonce d'adresse IP externe

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 le schéma 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.
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 le schéma 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 Router.
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.
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. Les sections suivantes décrivent 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 dérivée 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. Toutefois, votre routeur sur site peut remplacer cette priorité de route en fonction de sa configuration (par exemple, si votre routeur sur site modifie la priorité de 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. Pour plus d'informations sur la façon dont Google Cloud sélectionne une route, consultez la section Ordre de routage dans la documentation concernant les VPC.

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

Lorsqu'une instance envoie un paquet, Google Cloud tente de sélectionner une route à partir de l'ensemble de routes applicables en fonction de l'ordre de routage. Pour plus d'informations, consultez la section Ordre de routage dans la documentation concernant les VPC.

Chevauchement d'adresses IP

Si vous avez 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 savoir comment échanger correctement les routes dynamiques avec plusieurs réseaux VPC, consultez la section Certains préfixes IP sur site ne sont pas disponibles sur la page de dépannage de Cloud Router.

Limites concernant les routes apprises

Il existe deux limites pour les routes apprises. Ces limites ne définissent pas directement un nombre maximal de routes apprises. Elles définissent plutôt le nombre maximal de préfixes de destination uniques : Pour plus d'informations sur ces limites, consultez la page Limites.

Pour surveiller votre utilisation par rapport à ces limites, utilisez les métriques suivantes :

  • router.googleapis.com/dynamic_routes/learned_routes/used_unique_destinations
  • router.googleapis.com/dynamic_routes/learned_routes/unique_destinations_limit
  • router.googleapis.com/dynamic_routes/learned_routes/any_dropped_unique_destinations

Pour en savoir plus sur les messages de journal concernant ces limites, sur les métriques que vous pouvez utiliser pour les surveiller et sur comment résoudre les problèmes, consultez la section Vérifier les quotas et les limites de la page Dépannage.

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 routeurs Cloud Router annoncent les 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 routeur Cloud Router des annonces.

Lorsque vos routeurs sur site reçoivent les préfixes annoncés et leurs priorités, ils 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 les tunnels Cloud VPN ou les rattachements de VLAN sur site qui envoient des 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é dans la documentation de Cloud VPN.

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

  • 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 de 200 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

Pour une illustration de cet exemple, consultez le schéma suivant qui inclut des valeurs fournies à titre d'exemple pour le coût régional.

VPN haute disponibilité avec tunnels actifs/actifs.
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 tunnel 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 tunnel 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 tunnel 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 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.

Pour une illustration de cet exemple, consultez le schéma suivant.

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

Vous souhaitez donner la priorité aux rattachements de VLAN. 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 le rattachement de VLAN dans la région us-west1 car ses sessions BGP ont le MED le plus bas annoncé.

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 le rattachement de VLAN dans la région us-west1 car ses sessions BGP ont le MED le plus bas annoncé.

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 le rattachement de VLAN dans la région us-west1 car ses sessions BGP ont le MED le plus bas annoncé.

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.

Il peut arriver que vous souhaitiez 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.

Utiliser Cloud Router

Pour utiliser Cloud Router avec un produit de connectivité réseau, reportez-vous à la documentation de ce produit. Les étapes de création d'un routeur cloud ou d'utilisation d'un routeur cloud existant sont incluses dans les étapes suivantes.

Produit Routage Documentation
Interconnexion dédiée Nécessite le routage dynamique avec Cloud Router Créer des rattachements de VLAN
Interconnexion partenaire Nécessite le routage dynamique avec Cloud Router Créer des rattachements de VLAN
Appareils de routeur Nécessite le routage dynamique avec Cloud Router Créer des instances d'appareils de routeur
VPN haute disponibilité Nécessite le routage dynamique avec Cloud Router Créer une passerelle VPN haute disponibilité vers une passerelle VPN de pairs
Créer un VPN haute disponibilité entre les réseaux Google Cloud
VPN standard Le routage dynamique avec Cloud Router est facultatif Créer un VPN classique à l'aide du routage dynamique
Créer un VPN classique à l'aide d'un routage statique

Étape suivante

  • Pour vous aider à créer la topologie de votre réseau, consultez la section Bonnes pratiques relatives à Cloud Router.

  • Pour connaître la définition des termes utilisés avec Cloud Router, consultez la page Termes clés.

  • Pour résoudre les problèmes liés à l'utilisation de Cloud Router, consultez la page Dépannage.