Routes

Les routes Google Cloud définissent les chemins d'accès du trafic réseau depuis une instance de machine virtuelle (VM) vers d'autres destinations. Ces destinations peuvent se trouver à l'intérieur de votre réseau cloud privé virtuel (VPC) Google Cloud (par exemple, dans une autre VM) ou à l'extérieur de celui-ci.

Dans un réseau VPC, une route se compose d'un seul préfixe de destination au format CIDR et d'un saut suivant unique. Lorsqu'une instance d'un réseau VPC envoie un paquet, Google Cloud le transmet au saut suivant de la route, à condition que l'adresse de destination du paquet se trouve dans la plage de destination de la route.

Cette page offre un aperçu du fonctionnement des routes dans Google Cloud.

Routage dans Google Cloud

Chaque réseau VPC utilise un mécanisme de routage virtuel distribué et évolutif. Aucun appareil physique n'est attribué au réseau. Certaines routes peuvent être appliquées de manière sélective, mais la table de routage d'un réseau VPC est définie au niveau du réseau VPC.

Chaque instance de VM dispose d'un contrôleur qui reçoit en permanence des informations sur toutes les routes applicables depuis la table de routage du réseau. Chaque paquet quittant une VM est acheminé vers le saut suivant approprié d'une route applicable, en fonction d'un ordre de routage. Lorsque vous ajoutez ou supprimez une route, l'ensemble des modifications est propagé aux contrôleurs des VM selon un modèle de cohérence à terme.

Types de routes

Les tableaux suivants récapitulent comment Google Cloud classe les routes dans les réseaux VPC.

Type et destination Saut suivant Remarques
Routes générées par le système
Routes par défaut générées par le système
0.0.0.0/0 pour IPv4
::/0 pour IPv6		 default-internet-gateway S'applique à l'ensemble du réseau VPC

Peut être supprimée ou remplacée
Route de sous-réseau
Créée automatiquement pour chaque plage d'adresses IP du sous-réseau		 Réseau VPC
Transmet les paquets aux VM et aux équilibreurs de charge internes

Il est créé, mis à jour et supprimé automatiquement par Google Cloud lors des événements de cycle de vie d'un sous-réseau.

Les routes de sous-réseau locales s'appliquent à l'ensemble du réseau VPC.
Routes personnalisées
Route statique
Accepte différentes destinations		 Transmet les paquets à un saut suivant de route statique Pour plus d'informations sur chaque saut suivant de route statique, consultez les caractéristiques des éléments suivants :
Route dynamique
Destinations qui n'entrent pas en conflit avec les routes de sous-réseau ou les routes statiques		 Pair d'une session BGP sur un routeur cloud Les routes sont ajoutées et supprimées automatiquement en fonction des routes apprises par les routeurs Cloud Router de votre réseau VPC.

Les routes s'appliquent aux VM conformément au mode de routage dynamique du réseau VPC.
Routes d'appairage de réseaux VPC
Route d'appairage de sous-réseau
Représente une plage d'adresses IP de sous-réseau dans un autre réseau VPC connecté à l'aide de l'appairage de réseaux VPC. 		Saut suivant dans le réseau VPC appairé

L'appairage de réseaux VPC fournit des options d'échange de routes de sous-réseau.

Il est créé, mis à jour et supprimé automatiquement par Google Cloud lors des événements de cycle de vie d'un sous-réseau.

Les routes d'appairage de sous-réseau importées s'appliquent à l'ensemble du réseau VPC.
Routes d'appairage statiques et dynamiques
Routes statiques ou dynamiques dans un autre réseau VPC connecté à l'aide de l'appairage de réseaux VPC. 		Saut suivant dans le réseau VPC appairé

L'appairage de réseaux VPC fournit des options pour échanger des routes statiques.

Les routes statiques d'appairage importées s'appliquent à l'ensemble du réseau VPC.

L'appairage de réseaux VPC fournit des options d'échange de routes dynamiques.

Les routes dynamiques d'appairage importées s'appliquent à une région ou à toutes les régions du réseau VPC, conformément au mode de routage dynamique du réseau VPC qui exporte les routes.
Routes Network Connectivity Center
Route du sous-réseau de Network Connectivity Center
Représente une plage d'adresses IP de sous-réseau dans un spoke de VPC (un réseau VPC différent connecté au hub Network Connectivity Center) 		Hub Network Connectivity Center

Les administrateurs de spoke Network Connectivity Center peuvent exclure l'exportation de routes de sous-réseau.

Il est créé, mis à jour et supprimé automatiquement par Google Cloud lors des événements de cycle de vie d'un sous-réseau.

Les routes de sous-réseau de Network Connectivity Center importées s'appliquent à l'ensemble du réseau VPC.
Routes basées sur des règles
Route basée sur des règles
Les routes basées sur des règles peuvent s'appliquer à des paquets en fonction de l'adresse IP source, de l'adresse IP de destination, du protocole ou d'une combinaison de ces éléments.

Les routes basées sur des règles sont évaluées avant les autres. Les routes basées sur des règles peuvent s'appliquer à toutes les VM du réseau, à certaines VM sélectionnées par tag réseau ou au trafic entrant dans le réseau VPC via des rattachements de VLAN Cloud Interconnect que vous spécifiez.

Les routes basées sur des règles ne sont pas échangées via l'appairage de réseaux VPC.

Routes par défaut générées par le système

Lorsque vous créez un réseau VPC, celui-ci inclut une route par défaut IPv4 générée par le système (0.0.0.0/0). Lorsque vous créez un sous-réseau à double pile avec une plage d'adresses IPv6 externe dans un réseau VPC, une route IPv6 par défaut générée par le système (::/0) est ajoutée à ce réseau si elle n'existe pas déjà. Les routes par défaut répondent aux objectifs suivants :

Google Cloud n'utilise une route par défaut que si une route avec une destination plus spécifique ne s'applique pas à un paquet. Pour savoir comment la spécificité de destination et la priorité de routage sont utilisées pour sélectionner une route, consultez la section Ordre de routage.

Vous pouvez supprimer la route par défaut pour la remplacer par une route personnalisée, ou si vous souhaitez isoler complètement votre réseau d'Internet :

  • Vous pouvez remplacer la route par défaut par une route statique ou dynamique personnalisée si vous souhaitez acheminer le trafic Internet vers un saut suivant différent. Par exemple, vous pouvez la remplacer par une route statique personnalisée dont le saut suivant est une machine virtuelle proxy.

  • IPv4 et IPv6 : si vous supprimez la route par défaut sans la remplacer, les paquets destinés aux plages d'adresses IP non couvertes par d'autres routes sont supprimés.

Routes de sous-réseau

Les routes de sous-réseau définissent des chemins d'accès à des ressources telles que des VM et des équilibreurs de charge internes dans un réseau VPC.

Chaque sous-réseau comporte au moins une route de sous-réseau dont la destination correspond à la plage d'adresses IPv4 principale du sous-réseau. Si le sous-réseau comporte des plages d'adresses IP secondaires, il existe une route de sous-réseau correspondant à chacune de ses plages d'adresses IP secondaires. Si le sous-réseau comporte une plage IPv6, il existe une route de sous-réseau correspondant à la plage d'adresses IPv6. Pour en savoir plus sur les plages d'adresses IP de sous-réseau, consultez la section Sous-réseaux.

Les routes de sous-réseau ont toujours les destinations les plus spécifiques. Elles ne peuvent pas être remplacées par d'autres routes, même si une autre route a une priorité plus élevée. En effet, Google Cloud prend en considération la spécificité de destination avant la priorité pour sélectionner une route. Google Cloud utilise 0 comme priorité pour toutes les routes de sous-réseau.

Interactions avec les routes statiques

Les routes de sous-réseau locales et les routes d'appairage de sous-réseau importées interagissent avec les routes statiques personnalisées des manières suivantes :

  • Google Cloud ne vous permet pas de créer une route statique personnalisée ayant une destination identique ou plus étroite qu'une route de sous-réseau ou une route d'appairage de sous-réseau. Exemple :

    • Si une route de sous-réseau locale ou une route d'appairage de sous-réseau existe pour la destination 10.70.1.0/24, vous ne pouvez pas créer de route statique personnalisée pour 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 ou toute autre destination comprise dans 10.70.1.0/24.

    • Si une route de sous-réseau locale ou une route d'appairage de sous-réseau existe pour la destination 2001:0db8:0a0b:0c0d::/64, vous ne pouvez pas créer de nouvelle route statique personnalisée pour 2001:0db8:0a0b:0c0d::/64 ou toute destination comprise dans 2001:0db8:0a0b:0c0d::/64, par exemple 2001:0db8:0a0b:0c0d::/96.

  • En revanche, Google Cloud ne vous permet pas de créer une route de sous-réseau ou une route d'appairage de sous-réseau dont la destination correspond exactement à une route statique personnalisée existante, ou est plus large que celle-ci (c'est-à-dire que la destination contient cette route statique personnalisée existante). Exemple :

    • Si votre réseau VPC dispose d'une route statique personnalisée pour la destination 10.70.1.128/25, Google Cloud interdit la création de routes de sous-réseau ou de routes d'appairage de sous-réseau dont la plage d'adresses IPv4 de sous-réseau principal ou secondaire est 10.70.1.128/25, 10.70.1.0/24 ou toute autre plage contenant toutes les adresses IPv4 de la plage 10.70.1.128/25.

    • Si votre réseau VPC dispose d'une route statique personnalisée pour la destination 2001:0db8:0a0b:0c0d::/96, Google Cloud interdit la création de routes de sous-réseau ou de routes d'appairage de sous-réseau à double pile dont la plage d'adresses IPv6 est 2001:0db8:0a0b:0c0d::/64, ou toute autre plage contenant toutes les adresses IPv6 de la plage 2001:0db8:0a0b:0c0d::/96.

Interactions avec les routes dynamiques

Les routes de sous-réseau locales et les routes d'appairage de sous-réseau importées interagissent avec les routeurs Cloud des manières suivantes :

  • Lorsque les routeurs cloud apprennent un préfixe qui correspond exactement à la destination d'une route de sous-réseau ou d'appairage de sous-réseau existante, Google Cloud ne crée aucune route dynamique personnalisée pour le préfixe en conflit. Par exemple, lorsqu'il existe une route de sous-réseau ou d'appairage de sous-réseau avec la destination 10.70.1.0/24, si les routeurs cloud du réseau VPC reçoivent le préfixe 10.70.1.0/24 via BGP, Google Cloud utilise la route de sous-réseau ou d'appairage de sous-réseau et ne crée aucune route dynamique personnalisée pour 10.70.1.0/24.

    • Lorsqu'une route de sous-réseau ou d'appairage de sous-réseau dont la destination correspond exactement à un préfixe appris par les routeurs cloud dans le réseau VPC est créée, Google Cloud supprime la route dynamique personnalisée pour le préfixe en conflit afin de libérer de l'espace pour la route de sous-réseau ou d'appairage de sous-réseau.

  • Lorsque les routeurs cloud apprennent des préfixes qui sont compris dans la destination d'une route de sous-réseau ou d'appairage de sous-réseau existante, Google Cloud ne crée aucune route dynamique personnalisée pour les préfixes en conflit. Par exemple, lorsqu'il existe une route de sous-réseau ou d'appairage de sous-réseau avec la destination 10.70.1.0/24, si les routeurs cloud du réseau VPC reçoivent les préfixes 10.70.1.0/25 et 10.70.1.128/25 via BGP, Google Cloud utilise la route de sous-réseau ou d'appairage de sous-réseau et ne crée aucune route dynamique personnalisée pour 10.70.1.0/25 et 10.70.1.128/25.

    • Lorsqu'une route de sous-réseau ou d'appairage de sous-réseau dont la destination contient les préfixes appris par les routeurs cloud du réseau VPC est créée, Google Cloud supprime les routes dynamiques personnalisées pour les préfixes en conflit afin de libérer de l'espace pour la route de sous-réseau ou d'appairage de sous-réseau.

Cycle de vie des routes de sous-réseau

Les routes de sous-réseau sont créées, mises à jour et supprimées lorsque vous créez, modifiez ou supprimez des sous-réseaux ou leurs plages d'adresses IP de sous-réseau :

  • Lorsque vous ajoutez un sous-réseau, Google Cloud crée une route de sous-réseau correspondant à la plage d'adresses IP principale du sous-réseau.

  • Les réseaux VPC en mode automatique créent une route de sous-réseau pour les plages d'adresses IP principales de chacun de leurs sous-réseaux créés automatiquement. Vous ne pouvez supprimer ces sous-réseaux que si vous basculez le réseau VPC du mode automatique vers le mode personnalisé.

  • Vous ne pouvez pas supprimer une route de sous-réseau sans modifier ou supprimer le sous-réseau :

    • Lorsque vous supprimez une plage secondaire d'un sous-réseau, la route de sous-réseau de cette plage secondaire est automatiquement supprimée.

    • Lorsque vous supprimez un sous-réseau, toutes les routes de sous-réseau des plages principales et secondaires sont automatiquement supprimées. Il n'existe aucune autre façon de supprimer la route de sous-réseau de la plage principale du sous-réseau.

Le nombre de routes de sous-réseau dans un réseau VPC est limité par le nombre maximal de plages d'adresses IP de sous-réseau (principales et secondaires).

Routes dynamiques

Les routeurs cloud demandent au réseau VPC de créer, de mettre à jour et de supprimer des routes dynamiques en fonction des messages BGP (Border Gateway Protocol) qu'il reçoit, des règles de routage BGP applicables (bêta) et des routes apprises personnalisées de Cloud Router que vous configurez. Le plan de contrôle Cloud Router installe des routes dynamiques au niveau régional en fonction du mode de routage dynamique du réseau VPC :

  • Si un réseau VPC utilise le mode de routage dynamique régional, les routeurs Cloud Router de chaque région ne créent des routes dynamiques que dans la même région que le routeur Cloud Router.

  • Si un réseau VPC utilise le mode de routage dynamique global, les routeurs Cloud Router de chaque région créent des routes dynamiques dans toutes les régions du réseau VPC.

Le saut suivant d'une route dynamique peut être l'un des suivants :

Si un saut suivant pour une route dynamique devient inaccessible, le routeur Cloud Router qui gère sa session BGP demande au réseau VPC de supprimer la route dynamique une fois l'une des conditions suivantes remplie :

Google Cloud résout les conflits entre les routes dynamiques et les routes d'appairage et de sous-réseau locales, comme décrit dans la section Interactions avec les routes dynamiques.

Routes d'appairage de sous-réseau

Pour certaines ressources, les routes d'appairage de sous-réseau définissent des chemins d'accès aux ressources des sous-réseaux d'un autre réseau VPC qui sont connectés via l'appairage de réseaux VPC. Pour plus d'informations, consultez la section Options d'échange des routes de sous-réseau.

Les routes de sous-réseau locales et d'appairage de sous-réseau ne peuvent pas se chevaucher. Pour en savoir plus, consultez la section Interactions des routes de sous-réseau et des routes d'appairage de sous-réseau.

Le nombre de routes de sous-réseau par groupe d'appairage est contrôlé par les plages de sous-réseaux par réseau et par quota de groupe d'appairage.

Appairage de routes statiques et dynamiques

Lorsque vous utilisez l'appairage de réseaux VPC pour connecter deux réseaux VPC, vous pouvez exporter des routes statiques et dynamiques d'un réseau vers l'autre. Pour en savoir plus, consultez cette page :

Le nombre de routes statiques par groupe d'appairage et de routes dynamiques par région et par groupe d'appairage est limité par les quotas de routes statiques et dynamiques par réseau.

Applicabilité et ordre

Routes applicables

Chaque instance possède un ensemble de routes applicables, qui constituent un sous-ensemble de toutes les routes du réseau VPC. Les routes applicables représentent les chemins de sortie possibles qu'un paquet peut emprunter lorsqu'il est envoyé depuis l'instance.

  • Des chemins de retour spéciaux s'appliquent lors du réacheminement vers les équilibreurs de charge proxy, les systèmes de vérification d'état et d'autres services Google. Pour en savoir plus, consultez la section relative aux chemins de routage spéciaux. Ces routes ne sont affichées dans aucune table de routage.

  • Les routes basées sur des règles peuvent s'appliquer aux paquets envoyés depuis des instances de VM Compute Engine ou aux paquets reçus par les rattachements de VLAN Cloud Interconnect. Les routes basées sur des règles ne s'appliquent que si un paquet correspond aux critères des routes basées sur des règles.

  • Les routes de sous-réseau locales et d'appairage s'appliquent à toutes les instances. À l'exception des routes basées sur des règles, aucun autre type de route ne peut avoir de destination correspondant à une route d'appairage de sous-réseau locale ou comprise dans celle-ci. Pour plus d'informations sur la résolution des conflits entre les routes de sous-réseau, statiques et dynamiques, consultez les pages Interactions des routes de sous-réseau et des routes statiques et Interactions des routes de sous-réseau et des routes dynamiques.

  • Les routes statiques personnalisées s'appliquent à toutes les instances ou à des instances spécifiques. Les routes statiques avec un attribut de tag s'appliquent aux instances qui comportent le même tag réseau. Si la route ne comporte pas de tag réseau, elle s'applique à toutes les instances du réseau.

  • Les routes dynamiques s'appliquent aux instances basées sur le mode de routage dynamique du réseau VPC.

Chemins de routage spéciaux

Les réseaux VPC disposent de routes spéciales pour certains services. Ces chemins de routage spéciaux n'apparaissent pas dans votre table de routage de réseau VPC. Vous ne pouvez pas supprimer de chemins de routage spéciaux. Toutefois, vous pouvez autoriser ou refuser des paquets à l'aide de règles de pare-feu VPC ou de stratégies de pare-feu.

Chemins d'accès pour les équilibreurs de charge réseau passthrough externes et le transfert de protocole externe

Les équilibreurs de charge réseau passthrough externes et le transfert de protocole externe utilisent des systèmes Maglev pour acheminer les paquets des clients sur Internet aux VM de backend et aux instances cibles de votre réseau VPC. Ces systèmes Maglev acheminent les paquets dont les destinations correspondent à celles de la règle de transfert externe.

Chaque règle de transfert pour un équilibreur de charge réseau passthrough externe ou pour le transfert de protocole externe fournit également un chemin de routage pour ses VM de backend ou son instance cible afin d'envoyer des paquets à des destinations en dehors du réseau VPC:

  • Les paquets envoyés par des VM de backend ou des instances cibles peuvent être des paquets de réponse sortants (renvoyés au client) ou des paquets sortants qui initient une nouvelle connexion.
  • Les sources des paquets doivent correspondre à l'adresse IP de la règle de transfert. Le protocole de paquet et le port source ne doivent pas nécessairement correspondre au protocole et aux spécifications de port de la règle de transfert.
  • Les chemins de routage des règles de transfert ne dépendent pas d'une route par défaut ni de l'utilisation du saut suivant de la passerelle Internet par défaut.
  • Le transfert IP n'a pas besoin d'être activé sur les VM de backend ni sur les instances cibles.

Chemins entre les interfaces et les backends Google

Les équilibreurs de charge d'application externes et les équilibreurs de charge réseau proxy externes utilisent des Google Front End (GFE). Les GFE de deuxième couche ouvrent des connexions TCP vers vos VM backend et envoient des paquets à partir des sources suivantes:

  • 35.191.0.0/16
  • 130.211.0.0/22

Google Cloud utilise les routes du réseau de Google pour distribuer les paquets depuis ces plages sources vers les VM de backend de votre réseau VPC. Chaque réseau VPC inclut des chemins de routage qui permettent aux VM d'envoyer des paquets de réponse à 35.191.0.0/16 et 130.211.0.0/22.

Chemins d'accès pour les vérifications d'état

Les vérifications de l'état pour tous les équilibreurs de charge et pour l'autoréparation des groupes d'instances gérés envoient des paquets à vos VM de backend à partir des plages d'adresses IP des vérifications d'état.

Google Cloud utilise des routes du réseau de Google pour distribuer les paquets provenant des systèmes de test de vérification d'état aux VM de votre réseau VPC. Chaque réseau VPC inclut des chemins d'acheminement qui permettent aux VM d'envoyer des paquets de réponse aux systèmes de sonde de vérification d'état.

Chemins d'accès pour Identity-Aware Proxy (IAP)

Le transfert TCP avec IAP utilise 35.235.240.0/20 comme plage à usage interne uniquement avec des sauts suivants qui se trouvent entièrement dans le réseau de Google. Google ne publie pas de routes vers 35.235.240.0/20 sur Internet.

Les routes du réseau de Google distribuent les paquets depuis la plage d'adresses 35.235.240.0/20 vers les VM de votre réseau VPC lorsque vous utilisez le transfert TCP d'IAP. Chaque réseau VPC inclut des chemins d'acheminement qui permettent aux VM d'envoyer des paquets de réponse à 35.235.240.0/20.

Chemins d'accès à Cloud DNS et à l'Annuaire des services

Les fonctionnalités suivantes de Cloud DNS et de l'Annuaire des services utilisent 35.199.192.0/19 comme plage à usage interne uniquement avec des sauts suivants qui se trouvent entièrement dans le réseau de Google. Google ne publie pas de routes vers 35.199.192.0/19 sur Internet.

Les routes du réseau de Google transmettent les paquets depuis 35.199.192.0/19 aux VM de votre réseau VPC lorsque vous utilisez ces fonctionnalités Cloud DNS et de l'Annuaire des services. Chaque réseau VPC inclut des chemins d'acheminement qui permettent aux VM d'envoyer des paquets de réponse à 35.199.192.0/19.

Chemins d'accès au VPC sans serveur

L'accès au VPC sans serveur utilise 35.199.224.0/19 comme plage à usage interne uniquement avec des sauts suivants qui se trouvent entièrement dans le réseau de Google. Google ne publie pas de routes vers 35.199.224.0/19 sur Internet.

Les routes du réseau de Google distribuent les paquets depuis la plage 35.199.224.0/19 vers les instances de connecteur d'accès au VPC sans serveur. Chaque réseau VPC inclut des chemins de routage qui permettent aux instances de connecteur d'envoyer des paquets de réponse à 35.199.224.0/19.

Chemins d'accès aux points de terminaison Private Service Connect pour les API Google globales

Lorsque vous créez un point de terminaison Private Service Connect pour les API Google globales, Google Cloud ajoute une route pour le point de terminaison à votre réseau VPC. La destination de la route est l'adresse IP interne globale du point de terminaison.

Ordre de routage

Le processus suivant modélise le comportement de sélection des routes du réseau VPC, en commençant par l'ensemble de routes applicables décrit dans la section précédente.

  1. Chemins de routage spéciaux: certains chemins de routage spéciaux Google Cloud qui ne sont pas affichés dans votre table de routage de réseau VPC. Pour plus d'informations, consultez la section Chemins de routage spéciaux.

    Si un chemin d'acheminement spécial est applicable, votre modèle de sélection de route ne contient que le chemin spécial. Toutes les autres routes sont ignorées, et l'évaluation s'arrête à cette étape.

  2. Routes basées sur des règles: les routes basées sur des règles sont évaluées après les chemins de routage spéciaux, mais avant d'autres types de routes. Si aucune route basée sur des règles n'existe dans le réseau VPC, Google Cloud ignore cette étape et passe à l'étape de destination la plus spécifique.

  • Google Cloud évalue les routes basées sur des règles uniquement en fonction de leur priorité. Google Cloud évalue la source et la destination d'un paquet pour chaque route basée sur des règles, en commençant par la ou les routes basées sur des règles ayant la priorité la plus élevée. Si les caractéristiques d'un paquet ne correspondent pas à une route basée sur des règles, Google Cloud ignore cette route basée sur des règles et continue d'évaluer la route suivante basée sur des règles dans la liste triée. La route suivante basée sur des règles peut partager la même priorité que la route ignorée basée sur des règles, ou elle peut avoir une priorité inférieure.

    • Si les caractéristiques d'un paquet ne correspondent pas à une route basée sur des règles après l'évaluation de toutes les routes basées sur des règles dans votre modèle de sélection de route, Google Cloud ignore toutes les routes basées sur des règles et continue à l'étape de destination la plus spécifique.

    • Si les caractéristiques d'un paquet correspondent à une route basée sur des règles de priorité élevée, Google Cloud ignore d'abord toutes les routes basées sur des règles de priorité inférieure. S'il reste deux routes basées sur des règles dans la liste, Google Cloud évalue chacune des routes restantes basées sur des règles ayant des priorités identiques. Google Cloud ignore toutes les routes basées sur des règles restantes si les caractéristiques d'un paquet ne correspondent pas. Après cette étape, votre modèle de sélection de route peut contenir une ou plusieurs routes basées sur des règles.

    • Si votre modèle de sélection de route inclut au moins deux routes basées sur des règles à la priorité la plus élevée correspondantes, Google Cloud sélectionne une seule route basée sur des règles à l'aide d'un algorithme interne. La route basée sur des règles sélectionnée peut ne pas être la correspondance la plus spécifique pour la source ou la destination du paquet. Pour éviter cette ambiguïté, nous vous recommandons de créer des routes basées sur des règles ayant des priorités uniques.

    • Si votre modèle de sélection de route n'inclut qu'une seule route prioritaire basée sur des règles et configurée pour ignorer d'autres routes basées sur des règles, Google Cloud évalue les routes non basées sur des règles à l'étape de destination la plus spécifique et ignore toutes les routes basées sur des règles.

    • Si votre modèle de sélection de route n'inclut qu'une seule route prioritaire basée sur des règles et qui n'est pas configurée pour ignorer d'autres routes basées sur des règles, Google Cloud transmet le paquet à l'équilibreur de charge réseau passthrough interne de prochain saut et ignore toutes les routes non basées sur des règles.

  1. Destination la plus spécifique : Google Cloud détermine quelles routes applicables ont la destination la plus spécifique contenant l'adresse IP de destination du paquet. Google Cloud ignore toutes les autres routes avec des destinations moins spécifiques. Par exemple, 10.240.1.0/24 est une destination plus spécifique que 10.240.0.0/16. La destination la plus spécifique peut être n'importe quel type de route. Cependant, les routes de sous-réseau, les routes d'appairage de sous-réseau et les chemins de routage spéciaux sont les plus spécifiques par définition.

    Après cette étape, votre modèle de sélection de route ne contient aucun chemin de retour spécial ni routage basé sur des règles. Il n'inclut que les routes ayant les destinations les plus spécifiques.

  2. Sauts suivants dans un seul réseau VPC : cette étape ne s'applique que si le réseau VPC dont vous modélisez le comportement de route est connecté à un ou plusieurs réseaux VPC à l'aide de l'appairage de réseaux VPC. Avec l'appairage de réseaux VPC, des routes personnalisées avec des destinations identiques peuvent exister dans plusieurs des réseaux du groupe d'appairage. L'exigence modélisée à cette étape est que Google Cloud sélectionne les sauts suivants qui se trouvent tous dans un seul réseau VPC.

    • Si une ou plusieurs routes de votre modèle de routage présentent des sauts suivants dans le réseau VPC que vous modélisez, ignorez toutes les routes qui présentent des sauts suivants dans les réseaux appairés. Dans ce cas, Google Cloud n'utilise que les sauts suivants dans le réseau VPC local, même si les sauts suivants pour la même destination existent dans un ou plusieurs réseaux VPC appairés.

    • Si aucune des routes de votre modèle de routage ne comporte de sauts suivants dans le réseau VPC que vous modélisez, et que tous les sauts suivants existent dans plusieurs réseaux appairés, Google Cloud utilise un algorithme interne pour sélectionner un seul réseau pair avec les sauts suivants pour les destinations les plus spécifiques. La priorité des routes n'est pas prise en compte à ce stade. En outre, si votre réseau VPC est appairé à un nouveau réseau VPC ou s'il se déconnecte d'un réseau VPC appairé existant, le réseau VPC sélectionné pour les sauts suivants peut changer.

    Après cette étape, votre modèle de sélection de route ne contient que les routes ayant les destinations les plus spécifiques et les sauts suivants pour ces routes se trouvent tous dans un seul réseau VPC.

  3. Ignorer les routes statiques personnalisées dont les prochains sauts ne sont pas en cours d'exécution : cette étape modélise deux situations dans lesquelles Google Cloud ignore les prochains sauts qu'il considère comme n'étant pas en cours d'exécution. Cette étape ne s'applique qu'aux routes statiques personnalisées. Les routes dynamiques personnalisées sont automatiquement ajoutées et supprimées à l'aide d'annonces BGP.

    • Google Cloud ignore chaque instance de VM du saut suivant (next-hop-instance ou next-hop-address) si la VM du saut suivant a été arrêtée ou supprimée. Pour en savoir plus, consultez le paragraphe Comportement lorsque des instances sont arrêtées ou supprimées de la section Considérations liées aux instances de saut suivant. Si votre modèle de routage contient des routes statiques dont les VM de saut suivant sont arrêtées ou supprimées, supprimez ces routes de votre modèle.

    • Google Cloud ignore chaque route statique personnalisée qui utilise un tunnel VPN classique de saut suivant si le tunnel ne dispose pas d'une association de sécurité de phase 1 (IKE). Pour en savoir plus, consultez la page Ordre de priorité des routes dans la documentation sur les VPN classiques. Si votre modèle de routage contient des routes statiques dont les sauts suivants sont des tunnels VPN classiques sans associations de sécurité IKE établies, supprimez ces routes de votre modèle.

  4. Ignorer les routes à faible priorité : cette étape modélise la manière dont Google Cloud supprime toutes les routes, à l'exception de celles dont la priorité est la plus élevée.

    Après cette étape, votre modèle de sélection de route peut être vide ou contenir une ou plusieurs routes. Si votre modèle contient des routes, toutes les routes présentent toutes les caractéristiques suivantes :

    • Destinations identiques et les plus spécifiques
    • Sauts suivants dans un seul réseau VPC (le réseau VPC local ou un seul réseau VPC appairé)
    • Sauts suivants qui ne sont pas considérés comme indisponibles
    • Priorités identiques et les plus élevées

  5. Ne sélectionner que la catégorie de préférence la plus adaptée : Google Cloud évite le routage ECMP entre différents types de sauts suivants. Vous pouvez modéliser ce comportement en tenant compte du système de catégorie des préférences décrit dans le tableau suivant. Cette étape permet d'affiner votre modèle de routage pour qu'il ne contienne que des routes ayant le même type ou la même combinaison de type de route et de saut suivant.

    Catégorie de préférence Combinaison de catégorie et de saut suivant
    Premier choix (priorité la plus élevée) Routes statiques personnalisées avec une instance de saut suivant en cours d'exécution (next-hop-instance ounext-hop-address) ou un tunnel VPN classique de saut suivant établi par une association de sécurité IKE.
    Deuxième choix Routes dynamiques personnalisées apprises à partir de n'importe quelle session BGP d'un routeur Cloud.
    Troisième choix Pour une même route statique personnalisée utilisant un équilibreur de charge réseau interne à stratégie directe comme saut suivant,
    Google Cloud utilise un algorithme interne pour sélectionner un seul équilibreur de charge réseau interne à stratégie directe comme saut suivant, en ignorant les autres équilibreurs de charge réseau internes à stratégie directe utilisables comme saut suivant avec la même priorité Pour plus d'informations, consultez le paragraphe "Même destination avec plusieurs équilibreurs de charge réseau internes à stratégie directe comme saut suivant possible" dans Considérations liées aux équilibreurs de charge réseau internes à stratégie directe utilisables comme sauts suivants.
    Quatrième choix Une route statique personnalisée utilisant le saut suivant default-internet-gateway.

    À la fin de cette étape, il pourrait y avoir zéro route, une route, deux routes ou plusieurs routes dans le modèle de routage.

  6. Envoi ou suppression de paquets : ce qui se produit dépend du nombre de routes restant dans le modèle de routage :

    • Si le modèle de routage est vide, le paquet est supprimé avec une erreur de destination ICMP ou de réseau inaccessible. Google Cloud ne revient jamais à une route moins spécifique qui pourrait avoir un saut suivant opérationnel.

    • Si le modèle de routage contient une seule route, Google Cloud envoie le paquet au saut suivant. Pour les sauts suivants de VM, Google Cloud ne vérifie pas que le saut suivant de la VM peut traiter des paquets. Pour en savoir plus, consultez la section Remarques courantes sur les instances et les équilibreurs de charge réseau internes à stratégie directe utilisables comme sauts suivants. Si la route unique est une route de sous-réseau ou une route d'appairage de sous-réseau et qu'il n'existe aucune ressource Google Cloud à l'adresse IP de destination du paquet, le paquet est supprimé.

    • Si le modèle de routage contient deux routes ou plus, les routes partagent la même destination la plus spécifique et sont situées dans un réseau VPC unique. Leurs sauts suivants ne sont pas considérés comme indisponibles, elles partagent la même priorité la plus élevée et appartiennent à une seule combinaison de type de route et de saut suivant (catégorie de préférence). Google Cloud répartit les paquets entre les sauts suivants en mettant en œuvre un routage ECMP (Equal-Cost Multi-Path) à l'aide d'un algorithme de hachage. Les calculs de hachage sont effectués pour chaque paquet au moment de l'envoi, en fonction du nombre actuel de sauts suivants. Google Cloud utilise un hachage à cinq tuples si le paquet contient des informations de port ; sinon, il utilise un hachage à trois tuples. Si le modèle de routage change à mesure que les paquets suivants sont envoyés, Google Cloud peut diriger ces paquets vers un saut suivant différent, même si le hachage est identique.

Routes statiques

Vous pouvez créer des routes statiques de deux manières :

Vous pouvez échanger des routes statiques avec un réseau VPC appairé, comme décrit dans la section Options d'échange de routes statiques personnalisées de la documentation sur l'appairage de réseaux VPC.

Paramètres des routes

Les routes statiques sont compatibles avec les attributs suivants :

  • Nom et Description : ces champs permettent d'identifier la route. Le nom est requis, mais la description est facultative. Chaque route de votre projet doit posséder un nom qui lui est propre.

  • Réseau Chaque route doit être associée à un seul réseau VPC.

  • Saut suivant : le prochain saut identifie la ressource réseau à laquelle les paquets sont envoyés. Tous les types de prochains sauts sont compatibles avec les destinations IPv4, et certains d'entre eux sont compatibles avec les destinations IPv6. Pour en savoir plus, consultez Prochains sauts et caractéristiques.

  • Plage de destination : La plage de destination est une notation CIDR IPv4 ou IPv6 unique.

    Les destinations des routes statiques doivent respecter les règles décrites dans la section Interactions avec les routes statiques et Interactions des routes de sous-réseau et des routes statiques. La destination la plus large possible pour une route statique IPv4 est 0.0.0.0/0. La destination la plus large possible pour une route statique IPv4 est ::/0.

  • Priorité : des nombres inférieurs indiquent une priorité plus élevée. La priorité la plus élevée possible est 0, et la priorité la plus faible est 65,535.

  • Tags réseau vous pouvez rendre une route statique applicable uniquement à certaines instances de VM du réseau VPC identifiées par un tag réseau. Si vous ne spécifiez pas de tag réseau, Google Cloud rend la route statique applicable à toutes les instances du réseau. Les routes statiques avec des tags ne sont jamais échangées lors de l'utilisation de l'appairage de réseaux VPC.

Prochains sauts et caractéristiques

Le tableau suivant récapitule la compatibilité des caractéristiques des routes statiques par type de prochain saut :

Type du saut suivant IPv4 IPv6 ECMP1
Passerelle de prochain saut (next-hop-gateway)
Spécifiez une passerelle Internet par défaut pour définir un chemin d'accès vers des adresses IP externes.
Instance de prochain saut par nom et zone (next-hop-instance)
Envoyez des paquets à une VM de prochain saut qui est identifiée par un nom et une zone, et se trouve dans le même projet que la route. Pour en savoir plus, consultez Considérations liées aux instances de prochain saut.
Instance de prochain saut par adresse (next-hop-address)
Envoyez des paquets à une VM de prochain saut identifiée par l'adresse IPv4 interne principale, ou une adresse IPv6 interne ou externe, de son interface réseau. Pour en savoir plus, consultez Considérations liées aux instances de prochain saut.		 (aperçu)
Équilibreur de charge réseau passthrough interne utilisé en tant que prochain saut par nom et région de règle de transfert (next-hop-ilb)
Envoyez des paquets aux backends d'un équilibreur de charge réseau passthrough interne identifié par le nom et la région de la règle de transfert. Pour en savoir plus, consultez Considérations liées aux équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut.
Équilibreur de charge réseau passthrough interne utilisé en tant que prochain saut par adresse (next-hop-ilb)
Envoyez des paquets aux backends d'un équilibreur de charge réseau passthrough interne qui est identifié par l'adresse IP de la règle de transfert de l'équilibreur de charge. Pour en savoir plus, consultez Considérations liées aux équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut.
Tunnel VPN classique utilisé en tant que prochain saut (next-hop-vpn-tunnel)
Envoyez des paquets à un tunnel VPN classique utilisé en tant que prochain saut à l'aide du routage basé sur des règles ou d'un VPN basé sur des routes. Pour en savoir plus, consultez la section Considérations liées aux prochains sauts du tunnel VPN classique.
1 Le routage ECMP (Equal-Cost Multi-Path) signifie qu'au moins deux routes statiques peuvent partager la même plage de destination et la même priorité. Bien que vous puissiez créer au moins deux routes statiques dans un réseau VPC avec la même destination, la même priorité et le même prochain saut de la passerelle Internet par défaut, l'effet est identique à celui d'une seule route statique utilisant le prochain saut de la passerelle Internet par défaut pour cette destination et cette priorité.

Projet et réseau du prochain saut

Le prochain saut d'une route statique est associé à la fois à un réseau VPC et à un projet :

  • Réseau : sauf indication contraire dans le tableau ci-dessous, le réseau VPC du prochain saut doit correspondre au réseau VPC de la route.

  • Projet : sauf indication contraire dans le tableau ci-dessous, le prochain saut doit être situé dans le projet contenant le réseau VPC du prochain saut (un projet autonome ou un projet hôte de VPC partagé). Certains prochains sauts peuvent être situés dans des projets de service de VPC partagé.

Type du saut suivant Peut se trouver dans un réseau VPC appairé Peut se trouver dans un projet de service de VPC partagé
Passerelle de prochain saut (next-hop-gateway)
Instance de prochain saut par nom (next-hop-instance)
Instance de prochain saut par adresse (next-hop-address)
Équilibreur de charge réseau passthrough interne utilisé en tant que prochain saut par nom et région de règle de transfert (next-hop-ilb)
Équilibreur de charge réseau passthrough interne utilisé en tant que prochain saut par adresse (next-hop-ilb)
Tunnel VPN classique utilisé en tant que prochain saut (next-hop-vpn-tunnel)

Remarques courantes sur les instances et les équilibreurs de charge réseau internes à stratégie directe utilisables comme sauts suivants

Le routage basé sur une instance fait référence à une route statique dont le saut suivant est une instance de VM (next-hop-instance ou next-hop-address).

Équilibreur de charge réseau interne à stratégie directe utilisé comme saut suivant fait référence à une route statique dont le saut suivant est un équilibreur de charge réseau interne à stratégie directe (next-hop-ilb).

Lorsque vous configurez le routage basé sur une instance ou lorsque vous configurez un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant, tenez compte des instructions suivantes :

  • Vous devez configurer les VM de backend ou l'instance de saut suivant pour qu'elles transmettent des paquets issus de n'importe quelle adresse IP source. Pour configurer le transfert, activez le transfert IP (can-ip-forward) par VM lors de la création de la VM. Pour les VM créées automatiquement dans un groupe d'instances géré, activez le transfert IP dans le modèle d'instance utilisé par le groupe d'instances. Vous devez ajouter cette modification de configuration à toute configuration du système d'exploitation nécessaire au routage des paquets.

  • Les logiciels exécutés sur la VM de backend ou sur l'instance de saut suivant doivent être correctement configurés. Par exemple, les VM de dispositifs tiers qui agissent en tant que routeurs ou pare-feu doivent être configurées conformément aux instructions du fabricant.

  • Les VM de backend ou l'instance de saut suivant doivent disposer de règles de pare-feu appropriées. Vous devez configurer les règles de pare-feu qui s'appliquent aux paquets en cours d'acheminement. Tenez bien compte des éléments suivants :

    • Les règles de pare-feu d'entrée applicables aux instances qui exécutent des fonctions de routage doivent inclure les adresses IP des sources des paquets routés. La règle implicite d'entrée interdite bloque tous les paquets entrants. Vous devez donc a minima créer des règles de pare-feu personnalisées autorisant certaines entrées.
    • Les règles de pare-feu de sortie applicables aux instances qui exécutent des fonctions de routage doivent inclure les adresses IP des destinations des paquets routés. La règle implicite de sortie autorisée permet cette opération, sauf si vous avez créé une règle de refus du trafic sortant spécifique pour la remplacer.
    • Vérifiez si la VM de backend ou l'instance de saut suivant effectue la traduction d'adresse réseau (NAT, Network Address Translation) lors de la création de vos règles de pare-feu.

    Pour en savoir plus, consultez la section Règles de pare-feu implicites.

  • La région source d'un paquet envoyé par une VM de backend ou une instance de prochain saut est la région où se trouve la VM de backend ou l'instance de prochain saut. Par exemple, les paquets traités par des VM de backend ou des instances de prochain saut dans us-west1 peuvent être envoyés à des destinations qui ne sont accessibles que dans us-west1, même si la VM de backend ou l'instance de prochain saut a initialement reçu le paquet d'une ressource située dans une région différente de us-west1. Voici des exemples de ressources accessibles uniquement dans la même région qu'une VM envoyant un paquet :

    • Équilibreurs de charge réseau passthrough internes, équilibreurs de charge d'application internes et équilibreurs de charge réseau proxy internes régionaux avec accès mondial désactivé
    • Tunnels Cloud VPN, rattachements de VLAN Cloud Interconnect et VM d'appliance de routeur de connectivité réseau si le réseau VPC utilise le routage dynamique régional

Considérations liées aux instances de saut suivant

  • Prochain saut par nom et zone d'instance (next-hop-instance) : lorsque vous créez une route statique qui comporte une instance de prochain saut spécifiée par un nom et une zone, Google Cloud requiert qu'une instance portant ce nom existe dans la zone spécifiée et réponde aux critères suivants :

    • L'instance est située dans le même projet que la route.
    • L'instance possède une interface réseau (carte d'interface réseau) dans le réseau VPC de la route (et non dans un réseau VPC appairé).

    Tant qu'il existe une route statique dont le prochain saut est spécifié par le nom et la zone de l'instance, les règles suivantes s'appliquent :

    • Google Cloud met automatiquement à jour la programmation du prochain saut dans les cas suivants :

    • L'adresse IPv4 interne principale de l'instance de prochain saut change.

    • Vous remplacez l'instance de prochain saut et l'instance de remplacement porte le même nom, se trouve dans la même zone et le même projet, et dispose d'une interface réseau dans le réseau VPC de la route.

    • Google Cloud ne met pas à jour la programmation du prochain saut dans les cas suivants :

    • Lorsque l'instance est supprimée.

    • La plage d'adresses IPv6 attribuée à la carte d'interface réseau de l'instance change.

    • Lorsque l'adresse IPv4 ou IPv6 de l'instance n'est pas attribuée.

  • Adresse IP de l'instance de prochain saut (next-hop-address) : lorsque vous créez une route statique qui comporte une instance de prochain saut spécifiée par une adresse IP, vous pouvez saisir l'un des éléments suivants :

    • L'adresse IPv4 interne principale de l'instance.
    • Une adresse IPv6 interne ou externe provenant de la plage d'adresses IPv6 /96 attribuée à l'interface réseau d'une instance de VM à double pile (Preview). Si vous saisissez une adresse IPv6 interne, Google vous recommande d'utiliser la première adresse (/128) de la plage d'adresses IPv6 interne /96 de la carte d'interface réseau.

    Google Cloud vérifie que l'adresse IP de la VM de prochain saut correspond à la plage de sous-réseau d'un sous-réseau du réseau VPC de la route. Toutefois, Google Cloud ne programme la route que si l'adresse de prochain suivant correspond à l'une des adresses suivantes :

    • Une adresse IPv4 interne principale attribuée à la carte d'interface réseau d'une VM située dans le même réseau VPC que la route (et non un réseau VPC appairé)
    • Une adresse IPv6 de la plage d'adresses IPv6 /96 attribuée à la carte d'interface réseau d'une VM à double pile située dans le même réseau VPC que la route (et non un réseau VPC appairé)

    Google Cloud met automatiquement à jour la programmation du prochain saut lorsque l'adresse IP du prochain saut est déplacée vers une autre VM, à condition que la VM de remplacement réponde aux mêmes exigences.

  • Instances de prochain saut dans les projets de service de VPC partagé : lorsque vous spécifiez une VM de prochain saut par adresse IP, la VM peut être située soit dans le même projet que la route (projet autonome ou projet hôte de VPC partagé), soit dans un projet de service de VPC partagé. Lorsque vous spécifiez une VM de prochain saut par nom et zone d'instance, celle-ci doit être située dans le même projet que la route et le réseau VPC (projet autonome ou projet hôte de VPC partagé).

  • Coûts et latence entre régions : lorsque vous utilisez une VM en tant que saut suivant, le saut suivant est situé dans une zone d'une région. La route qui utilise le saut suivant est disponible pour toutes les instances du même réseau VPC ou pour sélectionner des instances avec un tag réseau correspondant. Google Cloud ne tient pas compte de la distance régionale pour les routes qui utilisent une instance comme saut suivant. Il est donc possible de créer une route qui envoie du trafic vers une VM de saut suivant dans une autre région. L'envoi de paquets d'une région à une autre ajoute des coûts de transfert de données sortant et entraîne une latence du réseau.

  • Aucune vérification de l'état, aucune validation de configuration : Google Cloud ne vérifie jamais si une instance de saut suivant répond à toutes les exigences décrites dans la section Remarques courantes sur les instances et équilibreurs de charge réseau internes à stratégie directe utilisés comme sauts suivants. Le fait de désactiver l'interface réseau de la VM en configurant le système d'exploitation invité de l'instance n'entraîne pas le fait que Google Cloud ignore l'instance de saut suivant.

  • Aucun hachage symétrique lors de la connexion de deux réseaux VPC : Google Cloud n'offre pas de hachage symétrique lors de l'utilisation d'au moins deux VM de saut suivant ayant plusieurs interfaces réseau dans une configuration qui répond à tous les critères suivants :

    • Les VM disposent d'une interface réseau dans un réseau VPC et d'une autre interface dans un deuxième réseau VPC.
    • Chaque réseau VPC contient un ensemble d'au moins deux routes statiques personnalisées pour la même destination, avec la même priorité, où chaque route de l'ensemble fait référence à une unique VM de saut suivant.

    Si vous utilisez au moins deux VM avec plusieurs interfaces pour connecter des réseaux VPC et que vous avez besoin que la même VM traite les paquets pour une connexion donnée dans les deux sens, vous avez besoin du hachage symétrique, qui n'est compatible qu'avec les équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut. Pour en savoir plus sur le hachage symétrique, consultez la documentation sur le hachage symétrique dans les équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut.

  • Comportement lors de l'arrêt ou de la suppression d'instances : Google Cloud ne vous empêche pas d'arrêter ou de supprimer une VM de prochain saut d'une route statique (spécifiée par nom et zone ou adresse interne). Lorsqu'une VM de prochain saut n'est pas en cours d'exécution, le routage pour la destination dépend de si d'autres routes existent pour la même destination et comportent des sauts suivants en cours d'exécution. Pour illustrer ce comportement, examinons les exemples suivants :

    • Les paquets dont les destinations correspondent à 192.168.168.0/24 sont envoyés au prochain saut de route-vm-b dans la situation suivante, où le prochain saut pour la route ayant la priorité la plus élevée n'est pas en cours d'exécution. Ce routage se produit car Google Cloud ignore les prochains sauts qui ne sont pas en cours d'exécution avant d'envisager d'ignorer les routes à faible priorité de l'ordre de routage :
    • route-vm-a, destination 192.168.168.0/24, priorité 10, VM de prochain saut arrêtée
    • route-vm-b, destination 192.168.168.0/24, priorité 20, VM de prochain saut en cours d'exécution

    • route-vm-c, destination 192.168.168.0/24, priorité 30, VM de prochain saut en cours d'exécution

    • Les paquets dont les destinations correspondent à 192.168.168.0/24 sont supprimés dans l'exemple suivant, dans lequel toutes les VM de prochain saut pour les routes 192.168.168.0/24 ne sont pas en cours d'exécution, même si une route pour la destination plus large 192.168.0.0/16 dispose d'une VM de prochain saut en cours d'exécution. Les paquets sont supprimés, car Google Cloud ignore les routes avec des plages de destination plus larges (longueur de masque de sous-réseau plus courte) au niveau de la destination la plus spécifique qui a lieu avant l'étape permettant d'ignorer les routes statiques personnalisées dont les prochains sauts ne sont pas en cours d'exécution de l'ordre de routage :

    • route-vm-x, destination 192.168.168.0/24, priorité 10, VM de prochain saut arrêtée

    • route-vm-y, destination 192.168.168.0/24, priorité 20, VM de prochain saut arrêtée

    • route-vm-z, destination 192.168.0.0/16, priorité 0, VM de prochain saut en cours d'exécution

Considérations liées aux équilibreurs de charge réseau internes à stratégie directe utilisés en tant que saut suivant

  • Règles de transfert compatibles. Google Cloud n'accepte que les règles de transfert des équilibreurs de charge réseau passthrough internes utilisés comme prochain saut. Google Cloud n'est pas compatible avec les règles de transfert de prochain saut utilisées par d'autres équilibreurs de charge, transferts de protocole ou points de terminaison Private Service Connect.

  • Méthodes de spécification, réseau et projet des règles de transfert. Vous pouvez spécifier une règle de transfert de prochain saut à l'aide de l'une des trois méthodes suivantes. La méthode de spécification que vous utilisez détermine si le réseau de la règle de transfert doit correspondre au réseau de la route et le projet dans lequel se trouve la règle de transfert :

    • Par nom (--next-hop-ilb) et région (--next-hop-ilb-region) de règle de transfert : lorsque vous spécifiez une règle de transfert de prochain saut par nom et par région, le réseau de la règle de transfert doit correspondre au réseau VPC de la route. La règle de transfert doit se trouver dans le projet qui contient le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé).

    • Par lien de ressource de règle de transfert : le lien de ressource d'une règle de transfert utilise le format /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, où PROJECT_ID est l'ID du projet contenant la règle de transfert, REGION est la région de la règle de transfert et FORWARDING_RULE_NAME est le nom de la règle de transfert. Lorsque vous spécifiez une règle de transfert de prochain saut par son lien de ressource, le réseau de la règle de transfert doit correspondre au réseau VPC de la route. La règle de transfert peut se trouver soit dans le projet contenant le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé), soit dans un projet de service de VPC partagé.

    • Par adresse IPv4 de règle de transfert : lorsque vous spécifiez une règle de transfert de prochain saut par son adresse IPv4, le réseau de la règle de transfert peut être soit le réseau VPC de la route, soit un réseau VPC appairé. La règle de transfert peut se trouver soit dans le projet contenant le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé), soit dans un projet de service de VPC partagé.

  • Effet de l'accès mondial : Les routes statiques personnalisées utilisant des équilibreurs de charge réseau internes à stratégie directe en tant que saut suivant sont programmées dans toutes les régions. La possibilité d'utilisation du saut suivant dépend du paramètre d'accès mondial de l'équilibreur de charge. Lorsque l'accès mondial est activé, le saut suivant de l'équilibreur de charge est accessible dans toutes les régions du réseau VPC. Lorsque l'accès mondial est désactivé, le saut suivant de l'équilibreur de charge n'est accessible que dans la même région que l'équilibreur de charge. Lorsque l'accès mondial est désactivé, les paquets envoyés depuis une autre région vers une route utilisant un équilibreur de charge réseau interne à stratégie directe comme saut suivant sont supprimés.

  • Lorsque tous les backends sont considérés comme non opérationnels. Lorsque tous les backends d'un équilibreur de charge réseau interne à stratégie directe échouent aux vérifications d'état, les routes qui utilisent cet équilibreur de charge en tant que saut suivant restent en vigueur. Les paquets traités par la route sont envoyés à l'un des backends d'équilibreur de charge de saut suivant selon la distribution du trafic.

  • Les règles de transfert qui utilisent une adresse IP interne commune (--purpose=SHARED_LOADBALANCER_VIP) ne sont pas compatibles. Les équilibreurs de charge réseau internes à stratégie directe utilisés en tant que saut suivant et les règles de transfert de l'équilibreur de charge réseau interne à stratégie directe avec adresse IP commune sont des caractéristiques exclusives. Un équilibreur de charge réseau interne à stratégie directe utilisé en tant que saut suivant doit utiliser une adresse IP propre à la règle de transfert de l'équilibreur de charge, de sorte qu'un seul service de backend (un équilibreur de charge) soit clairement référencé. Il est possible que les règles de transfert utilisent une adresse IP interne commune pour faire référence à différents services de backend (différents équilibreurs de charge réseau internes à stratégie directe).

  • Plusieurs routes avec les mêmes destinations et priorités, mais différents équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut. Google Cloud ne distribue jamais le trafic entre au moins deux équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut à l'aide d'ECMP. À la place, Google Cloud ne sélectionne qu'un seul équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut à l'aide d'un algorithme interne déterministe. Pour éviter cette ambiguïté, vous pouvez utiliser des tags réseau uniques pour chaque route.

    Google Cloud sélectionne un seul saut suivant lorsque des routes statiques avec différents équilibreurs de charge réseau internes à stratégie directe utilisables en tant que saut suivant ont la même priorité et la même destination.

  • Plusieurs routes avec les mêmes destinations, priorités et équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut. Sans tag réseau, Google Cloud ne vous permet pas de créer plusieurs routes statiques ayant la même combinaison de destination, de priorité et d'équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut. Avec les tags réseau, vous pouvez créer plusieurs routes statiques ayant la même combinaison de destination, de priorité et d'équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut.

Considérations liées aux sauts suivants du tunnel VPN classique

  • Coûts et latence entre régions : Google Cloud ne tient pas compte de la distance régionale pour les routes qui utilisent un tunnel VPN classique de saut suivant. L'envoi de trafic vers un tunnel VPN classique de prochain saut dans une autre région entraîne des coûts de transfert de données sortant et une latence du réseau. Il est recommandé d'utiliser un tunnel VPN haute disponibilité avec routage dynamique, car cette configuration tient compte de la distance régionale.

  • Comportement lorsque les tunnels VPN classiques ne sont pas en cours d'exécution : les routes statiques personnalisées dont les prochains sauts sont des tunnels VPN classiques ne sont pas automatiquement supprimées lorsque les tunnels VPN classiques ne sont pas en cours d'exécution. Pour plus de détails sur ce qui se passe lorsque les tunnels ne sont pas en cours d'exécution, consultez la section Cas où les tunnels sont indisponibles dans la documentation sur les VPN classiques.

Étapes suivantes