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 basées sur des règles: les routes basées sur des règles sont évaluées avant tout autre type de route.
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 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 pour Cloud Interconnect (dans une seule région ou dans toutes les régions).

Les routes basées sur des règles ne sont jamais échangées via l'appairage de réseaux VPC.
Routes de sous-réseau: tous les types de routes de sous-réseau sont évalués après les routes basées sur des règles, mais avant les routes personnalisées.
Route de sous-réseau local
Créée automatiquement pour chaque plage d'adresses IP du sous-réseau 		Réseau VPC

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.
Route de sous-réseau d'appairage
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.
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 personnalisées: les routes personnalisées sont évaluées après les routes basées sur des règles et après les routes de sous-réseau.
Route statique locale
Compatible avec 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 locale
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.
Route statique d'appairage, route dynamique d'appairage
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 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.
Route dynamique Network Connectivity Center
Route dynamique importée à partir de spokes hybrides Network Connectivity Center situés dans différents réseaux VPC 		Hub Network Connectivity Center

Un hub Network Connectivity Center peut comporter à la fois des spokes VPC et des spokes hybrides.

Les routes dynamiques Network Connectivity Center 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 contient le spoke hybride.
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

Routes de sous-réseau

Chaque sous-réseau comporte au moins une route de sous-réseau pour chaque plage d'adresses IP associée au sous-réseau. Pour en savoir plus sur les plages d'adresses IP de sous-réseau, consultez la section Sous-réseaux.

Types de routes de sous-réseau

Un réseau VPC peut inclure les types de routes de sous-réseau suivants:

  • Routes de sous-réseau pour les sous-réseaux d'un même réseau VPC, appelées routes de sous-réseau locales.
  • Routes de sous-réseau Network Connectivity Center importées à partir des spokes VPC d'un hub Network Connectivity Center.
  • Routes d'appairage de sous-réseau importées à partir de réseaux connectés à l'aide de l'appairage de réseaux VPC.

Les plages de destination de tous les types de routes de sous-réseau doivent être uniques. Pour en savoir plus, consultez les pages suivantes :

Cycle de vie des routes de sous-réseau

Toutes les plages d'adresses IP faisant partie d'un sous-réseau (plages d'adresses IPv4 principales, plages d'adresses IPv4 secondaires et plages d'adresses IPv6) disposent d'une route de sous-réseau correspondante. Google Cloud crée et supprime des routes de sous-réseau dans les scénarios suivants:

  • Vous modifiez la configuration du sous-réseau, par exemple:

    • Ajoutez ou supprimez un sous-réseau.
    • Étendez une plage IPv4 principale.
    • Ajoutez ou supprimez une plage d'adresses IPv4 secondaire.
    • Ajoutez ou supprimez une plage d'adresses IPv6.

  • Google Cloud ajoute une région, ce qui ajoute automatiquement un sous-réseau aux réseaux VPC en mode automatique. Pour en savoir plus sur les plages d'adresses IPv4 de chaque sous-réseau par région, consultez la section Plages d'adresses IPv4 en mode automatique.

Routes dynamiques

Les routeurs Cloud Router 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.

Les routes dynamiques sont créées dans une région ou dans toutes les régions en fonction du mode de routage dynamique et du mode de sélection du meilleur chemin du réseau VPC contenant le routeur Cloud Router. Pour en savoir plus, consultez les ressources suivantes :

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. Pour en savoir plus, consultez la section Changements d'état BGP.

Types de routes dynamiques

Un réseau VPC peut inclure les types de routes dynamiques suivants:

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

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

Une route par défaut a la destination la plus large possible: 0.0.0.0/0 pour IPv4 et ::/0 pour IPv6. Google Cloud n'utilise une route par défaut que pour acheminer un paquet lorsqu'il ne correspond pas à une route plus spécifique dans l'ordre de routage.

L'absence de route par défaut n'isole pas nécessairement votre réseau d'Internet, car les chemins de routage spéciaux pour les équilibreurs de charge réseau passthrough externes et le transfert de protocole externe ne dépendent pas d'une route par défaut.

Lorsque vous créez un réseau VPC, Google Cloud ajoute une route par défaut IPv4 générée par le système au réseau VPC. La route par défaut IPv4 générée par le système est une route statique locale dont la destination est 0.0.0.0/0 et le saut suivant est la passerelle Internet par défaut. Une route statique locale avec la destination 0.0.0.0/0 et le saut suivant de la passerelle Internet par défaut fournit un chemin d'accès aux adresses IP externes, y compris les adresses IP sur Internet. Les exemples de ressources suivants utilisent ce chemin:

  • VM dont les interfaces réseau sont associées à des adresses IPv4 externes, lorsque les sources des paquets qu'elles envoient correspondent à l'adresse IPv4 interne principale de l'interface réseau.
  • Une passerelle Cloud NAT publique configurée pour fournir des services NAT aux sous-réseaux utilisés par les interfaces réseau des VM. Selon les plages d'adresses IPv4 de sous-réseau que la passerelle Cloud NAT est configurée pour diffuser, les sources de paquets peuvent correspondre à l'une des options suivantes :
    • Une adresse IPv4 interne issue d'une plage d'adresses IP d'alias de l'interface réseau de la VM (que l'interface réseau dispose ou non d'une adresse IPv4 externe)
    • Adresse IPv4 interne principale de l'interface réseau de la VM si aucune adresse IPv4 externe n'y est attribuée.

Lorsque vous créez un sous-réseau avec une plage d'adresses IPv6 externes, Google Cloud ajoute une route par défaut IPv6 générée par le système au réseau VPC s'il n'en a pas déjà une. La route par défaut IPv6 générée par le système est une route statique locale dont la destination est ::/0 et dont le saut suivant est la passerelle Internet par défaut. Une route statique locale avec la destination ::/0 et le saut suivant de la passerelle Internet par défaut fournit un chemin d'accès aux adresses IPv6 externes, y compris les adresses IPv6 sur Internet. Ce chemin peut être utilisé par les éléments suivants:

  • VM avec des plages d'adresses IPv6 externes /96 attribuées à leurs interfaces réseau, lorsque les sources des paquets qu'elles envoient se trouvent dans cette plage d'adresses /96.

L'accès aux API Google globales parfois dépend d'une route IPv4 ou IPv6 locale par défaut avec un saut suivant de la passerelle Internet par défaut:

  • Si vous accédez aux API et services Google mondiaux en envoyant des paquets à un point de terminaison Private Service Connect pour les API Google mondiales, votre réseau VPC n'a pas besoin d'une route par défaut avec un saut suivant de passerelle Internet par défaut. Google Cloud ajoute un chemin de routage spécial au point de terminaison.

  • Si vous accédez aux API et services Google globaux en envoyant des paquets à des adresses IPv4 ou IPv6 pour les domaines par défaut, les adresses IPv4 ou IPv6 pour private.googleapis.com, ou les adresses IPv4 ou IPv6 pour restricted.googleapis.com, vous pouvez utiliser des routes IPv4 et IPv6 par défaut qui ont des sauts suivants de passerelle Internet par défaut, ou vous pouvez créer et utiliser des routes IPv4 et IPv6 statiques qui ont des destinations plus spécifiques et des sauts suivants de passerelle Internet par défaut:

    • Si vos VM ne disposent que d'adresses IP internes, consultez les options de routage pour l'accès privé à Google.
    • Si vos VM disposent d'adresses IP externes, consultez la section Options de routage.

Interactions avec les routes

Les sections suivantes décrivent les interactions entre les routes de sous-réseau et les autres types de routes.

Interactions entre les routes de sous-réseau et les routes statiques

Google Cloud applique les règles suivantes pour les routes de sous-réseau locales, les routes de sous-réseau d'appairage et les routes de sous-réseau Network Connectivity Center sauf si le sous-réseau correspondant a été configuré en tant que sous-réseau hybride.

  • Google Cloud ne vous permet pas de créer une route statique si la destination de la nouvelle route statique correspond exactement à la destination d'une route de sous-réseau locale, d'appairage ou Network Connectivity Center existante, ou s'inscrit dans celle-ci. Exemple :

    • Si une route de sous-réseau locale, d'appairage ou Network Connectivity Center existe avec la destination 10.70.1.0/24, vous ne pouvez pas créer de route statique 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 d'appairage existe avec la destination 2001:0db8:0a0b:0c0d::/64, vous ne pouvez pas créer de route statique pour 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96 ou toute autre destination comprise dans 2001:0db8:0a0b:0c0d::/64.

  • Google Cloud ne vous permet pas d'apporter de modifications aux sous-réseaux qui se traduisent par une plage d'adresses IP de sous-réseau correspondant exactement à la destination d'une route statique locale ou d'appairage existante, ou qui la contient. Exemple :

    • Si votre réseau VPC dispose d'une route statique dont la destination est 10.70.1.128/25, vous ne pouvez pas créer de sous-réseau dont la plage d'adresses IPv4 principale ou secondaire est 10.70.1.128/25, 10.70.1.0/24 ou toute autre plage d'adresses IP contenant toutes les adresses IPv4 de la plage 10.70.1.128/25.

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

Interactions entre les routes de sous-réseau et les routes dynamiques

Google Cloud applique les règles suivantes sauf si un sous-réseau a été configuré en tant que sous-réseau hybride.

  • Google Cloud ne crée pas de route dynamique si Cloud Router envoie un préfixe qui correspond exactement ou est compris dans la destination d'une route de sous-réseau locale, d'appairage ou de sous-réseau Network Connectivity Center existante. Exemple :

    • Si une route de sous-réseau locale, d'appairage ou de Network Connectivity Center existe avec la destination 10.70.1.0/24, et si Cloud Router du réseau VPC, un réseau VPC appairé ou un réseau contenant un rayon hybride de Network Connectivity Center reçoit 10.70.1.128/25, 10.70.1.0/24 ou tout autre préfixe qui s'inscrit dans 10.70.1.0/24, Google Cloud ne crée aucune route dynamique locale, d'appairage ou du Network Connectivity Center pour les préfixes en conflit reçus.

    • Si une route de sous-réseau locale, d'appairage ou de Network Connectivity Center existe avec la destination 2001:0db8:0a0b:0c0d::/64, et si Cloud Router du réseau VPC, un réseau VPC appairé ou un réseau contenant un rayon hybride de Network Connectivity Center reçoit 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 ou tout autre préfixe qui s'inscrit dans 2001:0db8:0a0b:0c0d::/64, Google Cloud ne crée aucune route dynamique locale, d'appairage ou du Network Connectivity Center pour les préfixes en conflit reçus.

  • Google Cloud supprime toute route dynamique existante si une modification des sous-réseaux entraîne la création d'une route de sous-réseau locale, d'appairage ou de Network Connectivity Center dont la destination correspond exactement à celle de la route dynamique locale, d'appairage ou de Network Connectivity Center existante ou la contient. Exemple :

    • Si votre réseau VPC dispose d'une route dynamique locale, d'appairage ou du Network Connectivity Center avec la destination 10.70.1.128/25, Google Cloud supprime la route dynamique lorsqu'une nouvelle route de sous-réseau locale, d'appairage ou du Network Connectivity Center pour 10.70.1.128/25, 10.70.1.0/24 ou toute autre plage d'adresses IP contenant toutes les adresses IPv4 de 10.70.1.128/25 est créée.

    • Si votre réseau VPC comporte une route dynamique locale, d'appairage ou de Network Connectivity Center avec la destination 2001:db8:a0b:c0d::/96, Google Cloud supprime la route dynamique lorsqu'une nouvelle route de sous-réseau locale, d'appairage ou du Network Connectivity Center pour 2001:db8:a0b:c0d::/64 est créée.

Applicabilité et ordre

Routes applicables

Chaque instance, tunnel Cloud VPN et rattachement VLAN possède un ensemble de routes applicables, c'est-à-dire des routes qui s'appliquent à cette ressource spécifique. Les routes applicables constituent un sous-ensemble de toutes les routes du réseau VPC.

Les types de routes suivants s'appliquent toujours à toutes les instances de VM, aux rattachements de VLAN et aux tunnels Cloud VPN:

Les types de routes suivants peuvent être configurés pour ne s'appliquer qu'à certaines instances de VM, rattachements de VLAN ou tunnels Cloud VPN:

  • Les routes basées sur des règles peuvent s'appliquer aux éléments suivants:

    • Toutes les instances de VM, les rattachements de VLAN et les tunnels Cloud VPN
    • Seules les instances de VM identifiées par un tag réseau
    • Uniquement les rattachements de VLAN dans une région spécifique

  • Les routes statiques peuvent s'appliquer aux éléments suivants:

    • Toutes les instances de VM, les rattachements de VLAN et les tunnels Cloud VPN
    • Seules les instances de VM identifiées par un tag réseau

  • Les routes dynamiques peuvent s'appliquer aux instances de VM, aux rattachements VLAN et aux tunnels Cloud VPN dans la région contenant le prochain saut de la route dynamique ou dans toutes les régions, en fonction du 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 la table de routage de votre réseau VPC. Vous ne pouvez pas supprimer de chemins de routage spéciaux. Toutefois, vous pouvez autoriser ou refuser les 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 vers les VM de backend et les instances cibles de votre réseau VPC. Ces systèmes Maglev acheminent les paquets dont les destinations correspondent à celle 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 d'acheminement pour que ses VM de backend ou son instance cible envoient des paquets vers des destinations en dehors du réseau VPC:

  • Les paquets envoyés par les VM de backend ou les instances cibles peuvent être des paquets de réponse sortants (envoyés au client) ou des paquets sortants qui initient une nouvelle connexion.
  • Les sources de 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 aux spécifications de protocole et 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 backend et les instances cibles.

Chemins entre les interfaces Google Front End et les backends

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 de backend et envoient des paquets à partir des sources suivantes:

  • 35.191.0.0/16
  • 130.211.0.0/22

Google Cloud utilise des routes dans le réseau de Google pour distribuer des paquets à partir de 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 aux vérifications d'état

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

Google Cloud utilise des routes dans le réseau de Google pour distribuer des paquets provenant des systèmes de vérification d'état aux VM de votre réseau VPC. Chaque réseau VPC inclut des chemins d'adressage qui permettent aux VM d'envoyer des paquets de réponse aux systèmes de vérification de l'état d'état.

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

Le transfert TCP à l'aide d'IAP utilise 35.235.240.0/20 comme plage à usage interne uniquement, avec des sauts suivants entièrement situés sur 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 transmettent les paquets de 35.235.240.0/20 aux VM de votre réseau VPC lorsque vous utilisez le transfert TCP IAP. Chaque réseau VPC inclut des chemins de routage qui permettent aux VM d'envoyer des paquets de réponse à 35.235.240.0/20.

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

Les fonctionnalités Cloud DNS et Annuaire des services suivantes utilisent 35.199.192.0/19 comme plage à usage interne uniquement, avec des sauts suivants entièrement situés sur 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 des paquets de 35.199.192.0/19 aux VM de votre réseau VPC lorsque vous utilisez ces fonctionnalités Cloud DNS et Annuaire des services. Chaque réseau VPC inclut des chemins d'adressage qui permettent aux VM d'envoyer des paquets de réponse à 35.199.192.0/19.

Parcours pour l'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 entièrement situés 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 transmettent des paquets de 35.199.224.0/19 aux 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 un routage pour le point de terminaison à votre réseau VPC. La destination du routage est l'adresse IP interne globale du point de terminaison.

Ordre de routage

Il peut y avoir plusieurs routes applicables pour un paquet donné. Les étapes suivantes modélisent le processus utilisé pour sélectionner un itinéraire.

  1. Chemins de routage spéciaux: certains chemins de routage spéciaux Google Cloud ne s'affichent pas dans la table de routage de votre réseau VPC. Pour en savoir plus, consultez la section Chemins de routage spéciaux.

    Si un chemin de routage spécial est applicable, votre modèle de sélection de route ne contient que le chemin spécial. Tous les autres chemins sont ignorés, 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 Routes de sous-réseau.

    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 de 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 à évaluer la route basée sur des règles suivante dans la liste triée. La prochaine route basée sur des règles à évaluer peut partager la même priorité que la route basée sur des règles ignorée, ou 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 des routes de sous-réseau.

    • Si les caractéristiques d'un paquet correspondent à une route basée sur des règles de priorité la plus élevée, Google Cloud ignore d'abord toutes les routes basées sur des règles de priorité inférieure. Si au moins deux routes basées sur des règles restent 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 à celles-ci. 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 de priorité la plus élevée correspondantes, Google Cloud en sélectionne une seule à l'aide d'un algorithme interne. La route basée sur les règles sélectionnée n'est pas nécessairement 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 ignore toutes les routes basées sur des règles et passe à l'étape Routes de sous-réseau.

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

  3. Routes de sous-réseau: Google Cloud détermine si la destination du paquet se trouve dans la plage de destination d'une route de sous-réseau locale, d'appairage ou du Network Connectivity Center dans le réseau VPC.

    • Si la destination d'un paquet ne correspond pas à la plage de destination d'une route de sous-réseau local, d'appairage ou du Network Connectivity Center, Google Cloud ignore toutes les routes de sous-réseau et passe à l'étape de destination la plus spécifique.

    • Si la destination d'un paquet correspond à la plage de destination d'une route de sous-réseau locale, d'appairage ou de Network Connectivity Center dans le réseau VPC, le comportement est différent selon que le sous-réseau a été configuré en tant que sous-réseau hybride:

      • Pour la plupart des sous-réseaux, Google Cloud utilise exclusivement la route du sous-réseau, en essayant d'envoyer le paquet à une ressource du sous-réseau, comme une interface réseau de VM ou une règle de transfert interne. Tous les autres itinéraires sont ignorés, et l'évaluation s'arrête à cette étape. Si aucune ressource n'utilise la destination du paquet ou si la ressource est une instance de VM arrêtée, le paquet est supprimé.

      • Toutefois, si la route de sous-réseau correspondante provient d'un sous-réseau hybride, Google Cloud tente de localiser une ressource de destination correspondante dans le sous-réseau, comme une interface réseau de VM ou une règle de transfert interne:

        • Si une ressource existe dans le sous-réseau, Google Cloud utilise exclusivement la route de sous-réseau, en essayant d'envoyer le paquet à la ressource. Tous les autres chemins sont ignorés, et l'évaluation s'arrête à cette étape. Si aucune ressource n'est présente à la destination du paquet, le paquet est supprimé. Si la ressource est une VM qui n'est pas en cours d'exécution, le paquet est également supprimé.

        • Si une ressource n'existe pas dans le sous-réseau, Google Cloud ignore toutes les routes de sous-réseau, y compris la route de sous-réseau correspondante, et passe à l'étape Destination la plus spécifique.

  4. Destination la plus spécifique: au début de cette étape, votre modèle de sélection de route ne contient aucun chemin de routage spécial, aucune route basée sur des règles, aucune route de sous-réseau locale, d'appairage ou Network Connectivity Center.

    Google Cloud détermine quelles routes applicables restantes 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 fin de cette étape, votre modèle de sélection de route ne contient que des routes personnalisées avec des destinations identiques.

  5. Ne sélectionner que le type de route personnalisée le plus adapté: à cette étape, Google Cloud supprime toutes les routes personnalisées, à l'exception du type de route personnalisée le plus adapté. Les routes personnalisées locales sont préférées aux routes dynamiques Network Connectivity Center, et les routes dynamiques Network Connectivity Center sont préférées aux routes personnalisées d'appairage.

    Le tableau suivant récapitule la logique utilisée par Google Cloud à cette étape.

    Catégorie de route personnalisée Qu'est-ce qui change ?
    Routes dynamiques et statiques locales

    Si votre modèle de routage contient au moins une route dynamique locale ou statique locale pour la destination, Google Cloud supprime les types de routes personnalisées suivants, le cas échéant:

    • Routes dynamiques Network Connectivity Center à partir de spokes hybrides, dans différents réseaux VPC
    • Routes dynamiques d'appairage (importées à partir d'autres réseaux VPC connectés à l'aide de l'appairage de réseaux VPC)
    Routes dynamiques de Network Connectivity Center Si toutes les conditions suivantes sont remplies, Google Cloud supprime toutes les routes dynamiques et statiques d'appairage du modèle de routage :
    • Votre modèle de calcul d'itinéraire ne contient pas de routes personnalisées locales pour la destination.
    • Votre mode de calcul de route contient au moins une route dynamique Network Connectivity Center pour la destination.
    • La route dynamique Network Connectivity Center provient d'un spoke hybride dans un autre réseau VPC
    Routes d'appairage dynamiques et statiques Le type de route personnalisée le moins favorable contient des routes personnalisées d'appairage. Les routes personnalisées d'appairage pour la destination ne sont utilisées que lorsque le modèle de routage ne contient pas de routes personnalisées locales ni de routes dynamiques Network Connectivity Center pour la destination.

  6. Sélectionner les sauts suivants pour les routes personnalisées d'appairage à partir d'un seul réseau VPC : les sauts suivants pour la même destination doivent se trouver sur le même réseau VPC. Cette étape seulement s'applique si votre modèle de routage contient des routes d'appairage dynamiques ou statiques importées à partir de deux réseaux VPC différents connectés à l'aide de l'appairage de réseaux VPC.

    Google Cloud utilise un algorithme interne pour importer des routes personnalisées d'appairage à partir d'un seul réseau VPC. Le réseau appairé sélectionné par Google Cloud peut changer 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.

  7. Ignorer les routes statiques et dynamiques avec les prochains sauts inutilisables: cette étape modélise les situations dans lesquelles Google Cloud ignore les sauts suivants qui sont indisponibles ou non valides.

    • Spécification de l'adresse IP de la VM de prochain saut non valide: le next-hop-address d'une route statique doit correspondre à une adresse IP attribuée à une VM dans le réseau VPC de la route. L'adresse IP doit être attribuée à l'interface réseau de la VM comme suit:

      • Une adresse IPv4 interne principale
      • Une adresse IPv6 interne
      • Une adresse IPv6 externe

      Si l'adresse IP spécifiée par next-hop-address correspond à un autre type de ressource (comme une plage d'adresses IP d'alias) ou ne correspond à aucune ressource, Google Cloud ignore la route.

    • VM de saut suivant arrêtée ou supprimée: Google Cloud ignore chaque route statique dont l'instance de VM de saut suivant a été arrêtée ou supprimée. Ce comportement s'applique aux routes dont les sauts suivants sont spécifiés à l'aide de next-hop-instance ou de next-hop-address. Pour en savoir plus, consultez la section Comportement lorsque des instances sont arrêtées ou supprimées.

    • Spécification d'adresse IP d'un équilibreur de charge de saut suivant non valide: pour les routes statiques dont un équilibreur de charge de saut suivant est spécifié par adresse IP, l'adresse IP doit correspondre à une règle de transfert d'un équilibreur de charge réseau passthrough interne situé sur le réseau VPC de la route ou sur un réseau VPC appairé. Si l'adresse IP du saut suivant correspond à la règle de transfert d'un autre type d'équilibreur de charge ou ne correspond à aucune règle de transfert, Google Cloud ignore la route.

    • Tunnel VPN classique de saut suivant non établi : Google Cloud ignore chaque route statique avec un tunnel VPN classique de saut suivant qui ne dispose pas d'une association de sécurité (SA) de phase 1 (IKE) active. Pour en savoir plus, consultez la page Ordre de priorité des routes dans la documentation sur les VPN classiques.

    • Route dynamique avec un saut suivant non fonctionnel: même avant que la session BGP responsable de la programmation d'une route dynamique ne tombe en panne, Google Cloud ignore une route dynamique si son tunnel Cloud VPN de prochain saut, son rattachement VLAN ou sa VM d'appareil de routeur ne sont pas fonctionnels. Cette situation ne dure généralement que quelques secondes avant que le routage dynamique ne soit supprimé lorsque la session BGP du routeur cloud correspondante est arrêtée.

    Google Cloud ne vérifie pas si l'OS invité d'une VM de saut suivant ou d'une VM de backend pour un équilibreur de charge de saut suivant traite des paquets. Pour en savoir plus, consultez la section Remarques courantes sur les instances et les équilibreurs de charge réseau passthrough internes utilisables comme sauts suivants.

  8. 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 route peut être vide ou contenir une ou plusieurs routes. Si votre modèle n'est pas vide, toutes les routes de votre modèle présentent les caractéristiques suivantes:

    • Priorités identiques
    • Sauts suivants qui n'ont pas été ignorés
    • Destinations identiques
    • Types de routes qui ne sont pas des routes basées sur des règles ni des routes de sous-réseau

  9. Sélectionner les sauts suivants pour les routes dynamiques Network Connectivity Center à partir d'un seul réseau VPC: les sauts suivants pour une même destination doivent se trouver sur le même réseau VPC. Cette étape seulement s'applique si votre modèle de routage contient des routes dynamiques Network Connectivity Center importées à partir de deux ou plusieurs spokes hybrides situés dans des réseaux VPC différents.

    Google Cloud utilise un algorithme interne pour importer les routes dynamiques de Network Connectivity Center à partir de rayons hybrides situés dans un seul réseau VPC. Les spokes hybrides sélectionnés peuvent changer si vous ajoutez ou supprimez des spokes hybrides du hub Network Connectivity Center. Pour éviter cette ambiguïté, assurez-vous que les routes dynamiques de Network Connectivity Center ont des priorités uniques lorsque les conditions suivantes sont remplies:

    • Les routes ont des destinations identiques.
    • Les routes sont importées depuis deux spokes hybrides ou plus dans différents réseaux VPC.

  10. Ne sélectionner que la catégorie de préférence la plus adaptée: Google Cloud n'effectue pas de routage ECMP (Equal Cost Multipath) entre les routes appartenant à différentes catégories de préférences, comme défini à cette étape.

    Catégorie de préférence Type de route et type de saut suivant
    Première préférence (la plus appréciée) Une ou plusieurs routes statiques avec des instances de saut suivant (next-hop-instance ou next-hop-address) ou des tunnels VPN classiques de saut suivant.
    Deuxième préférence Une ou plusieurs routes dynamiques d'un même type.
    Troisième choix Une seule route statique avec un équilibreur de charge réseau passthrough interne en tant que saut suivant.
    Quatrième préférence (la moins appréciée) Une ou plusieurs routes statiques avec saut suivant default-internet-gateway.

    À cette étape, lorsqu'au moins deux routes statiques avec un équilibreur de charge de saut suivant existent, Google Cloud sélectionne une seule route statique à l'aide d'un algorithme interne. Google Cloud n'effectue pas d'ECMP entre plusieurs équilibreurs de charge. Pour en savoir plus, consultez la section Considérations liées aux équilibreurs de charge réseau passthrough internes utilisés comme sauts suivants.

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

    • Catégorie de préférences identique
    • Priorités identiques
    • Sauts suivants qui n'ont pas été ignorés
    • Sauts suivants dans un seul réseau VPC
    • Destinations identiques
    • Types de routes qui ne sont pas des routes basées sur des règles ni des routes de sous-réseau

  11. Envoi ou suppression de paquets: en fonction du nombre de routes restantes dans le modèle de routage, Google Cloud envoie ou supprime le paquet:

    • Si votre modèle de routage ne contient qu'une seule route, Google Cloud envoie le paquet au saut suivant, à l'exception de ce qui suit:

      Les équilibreurs de charge réseau passthrough internes utilisés en tant que saut suivant dont l'accès mondial n'est pas activé ne sont pas accessibles depuis les régions situées en dehors de la région de l'équilibreur de charge. Par conséquent, si l'accès mondial n'est pas activé pour un équilibreur de charge de saut suivant, Google Cloud supprime tous les paquets envoyés depuis des instances de VM, des rattachements VLAN et des tunnels Cloud VPN dans des régions différentes de celle de l'équilibreur de charge. Pour modifier ce comportement, activez l'accès global.

    • Si votre modèle de routage contient au moins deux routes, Google Cloud effectue une ECMP, en répartissant les paquets entre les sauts suivants. La sélection du saut suivant dépend d'un calcul de hachage et du nombre 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.

    • Si votre modèle de routage est vide, Google Cloud supprime le paquet avec un message ICMP de type 3, code 0 (réseau inaccessible).

Étape suivante