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 préfixes d'adresses IP. Il programme des routes dynamiques 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 constitué 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 :

Chaque routeur cloud fonctionne avec au moins l'un des produits de connectivité réseau répertoriés précédemment.

Lorsque vous connectez un réseau sur site ou multicloud à Google Cloud, Cloud Router utilise le protocole BGP pour échanger les routes de manière dynamique entre votre réseau VPC Google Cloud et le réseau distant. Les modifications de préfixe et de saut suivant se propagent automatiquement entre votre réseau VPC et l'autre réseau sans nécessiter de routes statiques.

Vous pouvez également utiliser Cloud Router pour connecter deux réseaux VPC dans Google Cloud. Dans ce scénario, vous connectez les réseaux VPC en utilisant deux VPN haute disponibilité et deux routeurs cloud, avec un VPN haute disponibilité et le routeur Cloud Router associé sur chaque réseau.

L'appairage direct et l'appairage opérateur n'utilisent pas les routeurs cloud.

Spécifications

Un routeur Cloud Router peut annoncer des routes de sous-réseau VPC (cloud privé virtuel) et des préfixes personnalisés sur ses sessions BGP (Border Gateway Protocol). À moins que vous ne configuriez le mode d'annonce personnalisé, un routeur Cloud Router n'annonce que des routes de sous-réseau VPC. Le mode d'annonce personnalisé vous permet également de configurer un routeur Cloud Router pour qu'il n'annonce pas les routes de sous-réseau VPC.

Le mode de routage dynamique d'un réseau VPC (régional ou mondial) détermine les routes de sous-réseau VPC que les routeurs Cloud Router de ce réseau annoncent. Pour en savoir plus, consultez la section Mode d'annonce par défaut.

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.

Lorsque vous configurez BGP pour Cloud Interconnect, le VPN haute disponibilité et le dispositif de routeur, vous pouvez éventuellement configurer les sessions d'appairage du routeur pour qu'elles utilisent l'authentification MD5.

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 listé dans la section Ressources supplémentaires fournissent des détails sur la manière dont chaque produit utilise le numéro ASN.

Adresses d'appairage BGP

Les sessions BGP pour les produits suivants utilisent des adresses IPv4 de liaison locale comprises dans la plage 169.254.0.0/16 en tant qu'adresses d'appairage BGP :

  • Pour l'interconnexion dédiée, vous pouvez spécifier les adresses IPv4 de liaison locale candidates pour les adresses d'appairage BGP, ou Google Cloud peut sélectionner automatiquement des adresses IPv4 de liaison locale inutilisées.
  • Pour l'interconnexion partenaire, Google Cloud sélectionne automatiquement des adresses IPv4 de liaison locale inutilisées.
  • Pour les VPN haute disponibilité et les VPN classiques utilisant le routage dynamique, vous pouvez spécifier les adresses d'appairage BGP lorsque vous [créez l'interface BGP sur Cloud Router](/network-connectivity/docs/router/how-to/configuring-bgp).

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

Cloud Router est également compatible avec les adresses IPv6 pour l'appairage BGP. Avec la configuration des pairs BGP IPv6, vous pouvez créer des sessions BGP IPv6 sur des tunnels VPN haute disponibilité et des rattachements de VLAN d'interconnexion dédiée. La prise en charge des sessions BGP IPv6 est en version Preview.

Pour les tunnels VPN haute disponibilité, vous pouvez utiliser des adresses locales uniques (ULA) IPv6 comprises dans la plage fdff:1::/64 en tant qu'adresses d'appairage BGP. Les adresses d'appairage pour les sessions BGP IPv6 doivent utiliser une longueur de masque de 126 ou une valeur de nombre de bits inférieure, telle que /122. Lorsque vous configurez une session BGP IPv6 dans un VPN haute disponibilité, vous pouvez configurer les adresses IPv6 d'appairage manuellement ou demander à Google Cloud de les attribuer automatiquement pour vous.

Pour l'interconnexion dédiée, les adresses IPv6 d'appairage sont automatiquement attribuées à partir de la plage d'adresses unicast globales (GUA) appartenant à Google 2600:2d00:0:1::/64. Vous ne pouvez pas spécifier de plage candidate pour ces adresses IPv6 d'appairage ou configurer ces adresses IPv6 d'appairage manuellement.

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 réseau passthrough internes et réseaux connectés dans la documentation de Cloud Load Balancing.

Compatibilité IPv6

Cloud Router prend en charge l'échange de route IPv6 sur les sessions BGP IPv4 via BGP multiprotocole (MP-BGP). Cloud Router prend également en charge l'échange de routes IPv6 via l'appairage BGP IPv6. Toutefois, la prise en charge des sessions BGP IPv6 est en version Preview.

Cloud Router annonce les préfixes IPv6 pour les réseaux VPC qui incluent des sous-réseaux à double pile. Par défaut, les plages de sous-réseaux IPv6 internes sont annoncées automatiquement. Les plages de sous-réseaux IPv6 externes ne sont pas annoncées automatiquement, mais vous pouvez les annoncer manuellement à l'aide de routes annoncées personnalisées.

Vous pouvez créer les types de sessions BGP suivants :

  • Sessions BGP IPv4 qui échangent uniquement des routes IPv4
  • Sessions BGP IPv6 qui échangent uniquement des routes IPv6 (Preview)
  • Sessions BGP IPv4 qui échangent des routes IPv4, mais également des routes IPv6 à l'aide de MP-BGP
  • Sessions BGP IPv6 qui échangent des routes IPv6, mais également des routes IPv4 à l'aide de MP-BGP (Preview)
  • Sessions BGP IPv4 et sessions IPv6 qui s'exécutent en parallèle sur le même tunnel VPN haute disponibilité ou le même rattachement de VLAN d'interconnexion dédiée ; la session BGP IPv4 échange uniquement des routes IPv4 et la session BGP IPv6 échange uniquement des routes IPv6.

Pour en savoir plus, consultez les documents suivants:

Pour en savoir plus sur les annonces de routage IPv6, consultez la section Modes d'annonce de routage.

Limites de l'IPv6

L'appairage BGP IPv6 et l'échange de route IPv6 ne sont pas disponibles pour les ressources suivantes :

  • Rattachements de VLAN d'interconnexion partenaire
  • Tunnels VPN classiques
  • Dispositif de routeur (qui fait partie du Network Connectivity Center)
  • Rattachements de VLAN Cross-Cloud Interconnect

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 (CLI Google Cloud) ou le champ redundantInterface (API Compute Engine). Dispositif de routeur (qui fait partie du Network Connectivity Center) 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, le routeur 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 plus d'informations, 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.

Pour en savoir plus sur le fonctionnement du redémarrage en douceur avec la détection de transfert bidirectionnel (BFD), consultez la section Redémarrage en douceur et BFD.

Modes d'annonce de routage

En utilisant BGP et un produit listé dans la section Ressources supplémentaires, un routeur Cloud Router annonce les plages d'adresses sur votre réseau sur site. Cela permet aux clients de votre réseau sur site d'envoyer et de recevoir des paquets à partir des ressources de votre réseau VPC.

Cloud Router propose deux modes d'annonce de routage : le mode d'annonce par défaut et le mode d'annonce personnalisé.

Mode d'annonce par défaut

Le mode d'annonce par défaut configure un routeur Cloud Router ou une session BGP pour annoncer des préfixes pour les types de plages d'adresses de sous-réseau suivants. Le mode de routage dynamique du réseau VPC détermine si les plages d'adresses de sous-réseau annoncées proviennent uniquement de la même région que le routeur Cloud Router ou de toutes les régions :

Si vous annoncez des adresses IPv4 publiques utilisées en mode privé, les systèmes sur site risquent de ne pas pouvoir accéder aux ressources Internet qui utilisent ces adresses IPv4 publiques.

Les annonces de routage de sous-réseau sont mises à jour automatiquement, comme décrit dans la section Mises à jour automatiques pour les annonces de routage de sous-réseau.

Mode d'annonce personnalisé

Le mode d'annonce personnalisé vous permet de contrôler les préfixes annoncés par un routeur Cloud Router. Vous pouvez spécifier des routes annoncées personnalisées (en incluant les préfixes de routage par défaut, 0.0.0.0/0 pour les routes IPv4 ou ::/0 pour les routes IPv6) pour toutes les sessions BGP sur un routeur Cloud Router, ou individuellement pour chaque session BGP. Il existe deux catégories de routes annoncées personnalisées :

  • Vous ne pouvez annoncer que des préfixes personnalisés IPv4 et IPv6. Ce type de route annoncées personnalisée omet les routes de sous-réseau qui seraient annoncées à l'aide du mode d'annonce par défaut.

  • Vous pouvez annoncer des préfixes personnalisés IPv4 et IPv6 en plus des routes de sous-réseau. Ce type de route annoncée personnalisée inclut les mêmes routes de sous-réseau annoncées à l'aide du mode d'annonce par défaut.

Si vous choisissez d'annoncer les routes de sous-réseau, leurs annonces sont mises à jour automatiquement, comme décrit dans la section Mises à jour automatiques pour les annonces de routage de sous-réseau.

Si les conditions pour l'annonce de routage IPv6 sont remplies, Cloud Router annonce les plages de sous-réseaux IPv6 internes dès que vous choisissez d'annoncer les routes de sous-réseau. Vous devez ajouter toutes les plages de sous-réseaux IPv6 externes à votre liste de routes personnalisées pour les annoncer.

Pour connaître le nombre maximal de routes annoncées personnalisées pouvant être annoncées sur chaque session BGP, consultez le nombre maximal de routes annoncées personnalisées par session BGP sur la page concernant les limites de Cloud Router. Cette limite s'applique aux routes annoncées personnalisées pour l'ensemble du routeur Cloud Router et individuellement par session BGP.

Pour en savoir plus, consultez les documents suivants :

Préfixes annoncés effectifs

Le mode d'annonce de routage est configurable à la fois sur l'ensemble du routeur Cloud Router et sur les sessions BGP individuelles du routeur. Le tableau suivant décrit les préfixes annoncés sur la session BGP, en fonction du mode d'annonce sélectionné du routeur Cloud Router et de la session BGP.

Mode de Cloud Router Mode de session BGP Préfixes annoncés effectifs sur la session BGP
default default La session BGP hérite de la configuration du routeur Cloud Router. Les routes de sous-réseau sont annoncées comme décrit dans la section Mode d'annonce par défaut.
personnalisé default La session BGP hérite de la configuration du routeur Cloud Router. Les routes personnalisées configurées sur l'ensemble du routeur Cloud Router sont annoncées, comme décrit dans la section Mode d'annonce personnalisé. Les routes annoncées peuvent contenir tout ou partie des routes de sous-réseau.
par défaut ou personnalisé personnalisé La session BGP n'hérite pas de la configuration du routeur Cloud Router. Les routes annoncées personnalisées configurées sur la session BGP elle-même sont annoncées comme décrit dans la section Mode d'annonce personnalisé. Les routes annoncées peuvent contenir tout ou partie des routes de sous-réseau.

Mises à jour automatiques pour les annonces de routage de sous-réseau

Cloud Router met automatiquement à jour les annonces de routage de sous-réseau dans les situations suivantes :

Conditions pour l'annonce de routage IPv6

Cloud Router peut annoncer des routes IPv6 lorsque toutes les conditions suivantes sont remplies :

  • Le produit utilisé avec Cloud Router, tel que la passerelle VPN haute disponibilité, est configuré pour utiliser le type IPv4 et IPv6 à double pile.

  • La session BGP IPv4 est spécifiquement configurée pour permettre l'échange de route IPv6, ou la session BGP IPv6 (Preview) est configurée et activée.

    Pour en savoir plus sur la configuration des sessions BGP, consultez la page Établir des sessions BGP.

Pour annoncer des plages de sous-réseaux IPv6 internes, votre réseau VPC doit disposer d'une plage IPv6 interne attribuée (ULA) et vous devez avoir créé au moins un sous-réseau à double pile avec une plage de sous-réseaux IPv6 interne.

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 (Border Gateway Protocol) sur un routeur 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 spécifier 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 de région à région, et vous ne pouvez pas les modifier.

  • Les priorités de base entre les routeurs Cloud Router d'une région sont recommandées 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 10200 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 IPv4 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 IPv4 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 IPv4 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 IPv4 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 IPv4 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 IPv4 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 IPv4 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 IPv4 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 IPv4 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

Routes apprises

Les routes apprises sont des routes utilisées par Cloud Router pour atteindre un autre réseau. L'autre réseau peut être votre réseau sur site, un réseau d'un autre fournisseur de services cloud ou un autre réseau VPC. Les routes apprises sont parfois appelées routes reçues.

Dans Google Cloud, il existe deux types de routes apprises :

  • Routes apprises des routeurs externes via BGP

  • Routes que vous configurez manuellement pour une session BGP individuelle (routes apprises personnalisées)

À l'aide des deux types de routes apprises, Cloud Router crée des routes dynamiques dans votre réseau VPC. Chaque route dynamique créée par Cloud Router est dérivée d'une ou de plusieurs de ces routes apprises.

Si Cloud Router possède plusieurs routes apprises pour le même préfixe de destination, il utilise des métriques de routage et, dans certains cas, la longueur du chemin AS pour créer des routes dynamiques. Les sections suivantes donnent davantage d'informations sur ce processus et les routes apprises en général.

Routes apprises personnalisées

Comme décrit dans la section précédente, vous pouvez configurer une session BGP pour disposer de routes apprises personnalisées. Lorsque vous configurez des routes apprises personnalisées, Cloud Router se comporte comme s'il avait appris ces routes à partir d'un pair BGP.

Les routes apprises personnalisées peuvent être utiles si vous souhaitez éviter les limites des routes statiques. Par exemple, les routes statiques ne peuvent pas détecter une perte de joignabilité dans le saut suivant d'une route. En revanche, les routes apprises personnalisées peuvent détecter une perte de joignabilité. Elles réagissent en conséquence pour éviter de perdre du trafic sans notification.

Pour plus d'informations, reportez-vous à la section Routes apprises personnalisées.

Effets du mode de routage dynamique

Le mode de routage dynamique d'un réseau VPC détermine la façon dont les routes apprises 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 sur site.

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

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, valeur MED et origine

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.

Pour que la valeur MED s'applique lors de la sélection du meilleur chemin entre plusieurs routes apprises pour la même destination, la valeur de l'attribut d'origine BGP pour les routes reçues doit être identique. Sinon, la sélection est effectuée en fonction de la valeur de l'attribut d'origine, qui précède l'étape de comparaison MED du processus de sélection du meilleur chemin (RFC 4271).

Cloud Router annonce les routes BGP vers ses pairs avec la valeur d'attribut d'origine définie sur Incomplete. Cette valeur est le type d'origine le moins privilégié dans la sélection des routes.

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 de plages d'adresses IPv4 ou IPv6

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

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

Transfert de données de site à site

Si vous devez transférer des données entre deux sites externes à Google Cloud, utilisez Network Connectivity Center. Network Connectivity Center fonctionne avec Cloud Router pour vous permettre d'annoncer de manière dynamique les routes entre les sessions BGP.

Cloud Router seul n'est pas compatible avec cette fonctionnalité (de manière dynamique ou en configurant des routes annoncées personnalisées qui correspondent aux préfixes appris). Si vous ajoutez une route annoncée personnalisée à une session BGP et que cette route chevauche une route apprise d'une autre session BGP, la route apprise peut être supprimée.

Limites concernant les routes apprises

Plusieurs limites affectent les routes apprises. Pour en savoir plus, consultez la section Limites.

Les routes IPv4 et IPv6 sont comptabilisées dans le même maximum et n'ont pas de limites distinctes.

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 la manière de résoudre les problèmes, consultez la section Vérifier les quotas et les limites de la page Dépannage.

Route par défaut

Si aucune route n'est spécifiée pour une destination IPv4 ou IPv6 particulière, le trafic est envoyé à une route par défaut, ce qui constitue le dernier recours lorsqu'il n'existe aucune autre option. Par exemple, les réseaux Google Cloud VPC incluent automatiquement une route par défaut qui envoie le trafic vers la passerelle Internet. La route par défaut est 0.0.0.0/0 pour IPv4 et ::/0 pour IPv6.

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.

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

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.

Événements de maintenance

Cloud Router fait l'objet d'une maintenance périodique, qui prend moins de 60 secondes. Cloud Router n'est pas disponible pendant les événements de maintenance. 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 (par défaut) pour le compteur de préservation BGP. Nous vous recommandons de définir le compteur de préservation BGP sur votre routeur sur site (pair) sur 60 secondes ou plus. 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.

Identifiant BGP (ID du routeur)

Chaque routeur Cloud Router possède un identifiant BGP, également appelé ID de routeur. L'identifiant BGP est unique à chaque routeur Cloud Router de votre cloud privé virtuel, conformément à la norme RFC 6286.

Généralement, l'identifiant BGP est attribué automatiquement, mais vous pouvez configurer votre routeur Cloud Router avec une plage d'identifiants BGP explicite. Si vous choisissez d'attribuer votre propre plage d'identifiants BGP, un identifiant BGP stable est attribué à votre routeur Cloud Router dans la plage sélectionnée. Un routeur Cloud Router qui n'est pas configuré avec une plage d'identifiants BGP se voit attribuer un identifiant BGP basé sur son adresse d'interface IPv4 la plus élevée.

La prise en charge des sessions BGP et des plages d'identifiants BGP IPv6 est en version Preview.

Lorsque vous ajoutez la première interface IPv6 à un routeur Cloud Router non configuré avec une plage d'identifiants BGP, une plage d'identifiants BGP est attribuée automatiquement.

Pour en savoir plus, consultez la section Configurer la plage d'identifiants BGP pour Cloud Router.

Redémarrage de la session BGP

L'identifiant BGP d'un routeur Cloud Router actif peut changer pour l'une des raisons suivantes :

  • Vous mettez à jour ou supprimez manuellement la plage d'identifiants BGP configurée.
  • Vous supprimez une interface IPv4 du routeur Cloud Router et aucune plage d'identifiants BGP ne lui a été attribué.

Lorsque l'identifiant BGP d'un routeur Cloud Router actif change, chaque session BGP sur ce routeur redémarre.

La plage d'identifiants d'un routeur Cloud Router peut également changer lorsque le routeur est redémarré pour une maintenance périodique et qu'aucune plage d'identifiants BGP ne lui a été attribuée.

Autres ressources

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 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 avec Cloud Router, consultez la page Bonnes pratiques.

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