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, Virtual Private Cloud) Google Cloud (par exemple, au sein d'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 : Instances et équilibreurs de charge réseau internes à stratégie directe Instances de saut suivant Équilibreurs de charge réseau internes à stratégie directe utilisés comme sauts suivants Sauts suivants du tunnel VPN classique
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 des routeurs cloud 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.	Une option permettant d'ignorer l'évaluation d'autres routes basées sur des règles Un équilibreur de charge réseau interne à stratégie directe	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 :

Les routes IPv4 et IPv6 par défaut définissent un chemin sortant du réseau VPC vers des adresses IP externes sur Internet.
Si vous accédez aux API et aux services Google sans utiliser de point de terminaison Private Service Connect, la route par défaut peut servir de chemin d'accès aux API et services Google. Pour en savoir plus, consultez les pages Configurer l'accès privé à Google et Accéder aux API à partir de VM avec des adresses IP externes.

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.
- Si vous étendez la plage d'adresses IP principale d'un sous-réseau, Google Cloud met à jour la destination de la route de sous-réseau correspondante.
- Si vous ajoutez ou supprimez une plage d'adresses IP secondaire dans un sous-réseau, Google Cloud crée ou détruit une route de sous-réseau correspondante pour la plage secondaire.
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 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 et des routes apprises personnalisées 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 :

Un rattachement de VLAN reposant sur une connexion par interconnexion dédiée ou par interconnexion partenaire
Un tunnel Cloud VPN, soit un tunnel VPN haute disponibilité, soit un VPN classique configuré pour utiliser le routage dynamique
Une instance de VM d'appliance de routeur dans Network Connectivity Center

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 :

Le timer de redémarrage en douceur du routeur pair a expiré (si le pair BGP est compatible avec le redémarrage en douceur).
Le timer de préservation du routeur cloud a expiré. Le timer de préservation de Cloud Router est proportionnel au timer keepalive de Cloud Router configurable.

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

Les routes d'appairage de sous-réseau définissent des chemins d'accès à des ressources dans des sous-réseaux d'un autre réseau VPC 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 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 les pages suivantes :

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 Chemins de retour pour les équilibreurs de charge. 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 à partir d'instances de VM Compute Engine ou reçus par des 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 une destination identique à celle d'une route de sous-réseau locale ou d'appairage, ou comprise dans cette destination. 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 retour spéciaux

Les réseaux VPC disposent de routes spéciales pour certains services. Ces routes sont définies en dehors de votre réseau VPC, au sein du réseau de production de Google. Elles n'apparaissent pas dans votre table de routage de réseau VPC. Vous ne pouvez pas les supprimer ni les remplacer, même si vous supprimez ou remplacez une route par défaut de votre réseau VPC. Toutefois, vous pouvez autoriser ou refuser les paquets à l'aide de règles de pare-feu VPC, de stratégies de pare-feu réseau ou de stratégies de pare-feu hiérarchiques.

Chemins de retour pour les équilibreurs de charge

Google Cloud utilise des routes spéciales en dehors de votre réseau VPC pour distribuer des paquets entre :

Les systèmes clients et les backends d'équilibreur de charge (pour les équilibreurs de charge réseau à stratégie externe)
Les systèmes proxy et les backends d'équilibreur de charge (pour les équilibreurs de charge proxy externes)
Vérifications d'état et backends d'équilibreur de charge

Chemins entre les proxys et les backends Google Front End (GFE)

Les équilibreurs de charge d'application externes globaux, les équilibreurs de charge d'application classiques, les équilibreurs de charge réseau proxy classiques et les équilibreurs de charge réseau proxy externes globaux utilisent des systèmes Google Front End (GFE) en tant que proxys.

Lorsqu'un client envoie une requête à l'équilibreur de charge, les GFE interrompent cette première connexion TCP. Les GFE ouvrent ensuite une deuxième connexion TCP vers les VM de backend. Google Cloud utilise des routes définies en dehors de votre réseau VPC pour acheminer les paquets entre les proxys GFE et les VM de backend.

Chemins d'accès aux backends de l'équilibreur de charge réseau passthrough externe

Pour les équilibreurs de charge réseau passthrough externes, Google Cloud utilise des routes définies en dehors de votre réseau VPC pour acheminer les paquets entre les clients et les VM de backend.

Vérifications d'état pour tous les types d'équilibreurs de charge

Les paquets envoyés depuis les systèmes de vérification d'état Google Cloud utilisent des sources de paquets décrites dans la section Plages d'adresses IP de vérification d'état et règles de pare-feu.

IAP

Google Cloud inclut des routes vers et depuis 35.235.240.0/20 dans chaque réseau VPC pour assurer le transfert TCP avec IAP. Le réseau de production de Google utilise 35.235.240.0/20 comme plage à usage interne uniquement. Les sauts suivants pour 35.235.240.0/20 se trouvent entièrement dans le réseau de production de Google.

Cloud DNS et Annuaire des services

Google Cloud inclut des routes vers et depuis 35.199.192.0/19 dans chaque réseau VPC pour accepter les cibles de transfert Cloud DNS qui utilisent le routage privé, les serveurs de noms alternatifs Cloud DNS qui utilisent le routage privé et l'accès réseau privé pour l'Annuaire des services. Le réseau de production de Google utilise 35.199.192.0/19 comme plage à usage interne uniquement. Les sauts suivants pour 35.199.192.0/19 se trouvent entièrement dans le réseau de production de Google.

Accès au VPC sans serveur

Google Cloud inclut des routes vers et depuis 35.199.224.0/19 dans chaque réseau VPC pour permettre l'accès au VPC sans serveur. Le réseau de production de Google utilise 35.199.224.0/19 comme plage à usage interne uniquement. Les sauts suivants pour 35.199.224.0/19 se trouvent entièrement dans le réseau de production de Google.

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écrites dans la section précédente.

Chemins de retour spéciaux : les chemins de retour spéciaux ne sont pas affichés dans la table de routage de votre réseau VPC. Les routes que vous configurez dans un réseau VPC ne s'appliquent pas aux paquets de réponse pour certains équilibreurs de charge Google Cloud, systèmes de vérification de l'état, Identity-Aware Proxy (IAP) et proxys Cloud DNS. Pour plus d'informations, consultez la section Chemins de retour spéciaux.

Si un chemin de retour spécial s'applique, votre modèle de sélection de route ne contient que le chemin de retour spécial. Toutes les autres routes sont ignorées, et l'évaluation s'arrête à cette étape.
Routes basées sur des règles: les routes basées sur des règles sont évaluées après les chemins de retour 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 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 à évaluer la route suivante basée sur des règles dans la liste triée. La route suivante basée sur des règles à évaluer peut partager la même priorité que la route ignorée basée sur des règles, 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 de destination la plus spécifique.
- Si les caractéristiques d'un paquet correspondent à une route basée sur une stratégie et à priorité élevée, Google Cloud ignore d'abord toutes les routes basées sur des règles de priorité inférieure. S'il reste au moins deux routes basées sur des règles, Google Cloud évalue chacune des routes basées sur des règles restantes ayant des priorités identiques. Google Cloud ignore les routes restantes basées sur des règles 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 avec une priorité la plus élevée, 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 correspondre exactement à 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.
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 retour 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 aucune route basée sur des règles. Il n'inclut que les routes ayant les destinations les plus spécifiques.
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.
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.
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

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` ou`next-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.

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 créer des routes statiques manuellement à l'aide de Google Cloud Console, de gcloud compute routes create ou de l'API routes.insert.
Si vous utilisez la console Google Cloud pour créer un tunnel VPN classique qui n'utilise pas le routage dynamique, Cloud VPN peut créer automatiquement des routes statiques correspondantes. Pour en savoir plus, consultez Réseaux et options de routage pour les tunnels.

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.

Remarque : Pour les réseaux VPC en mode automatique, ne créez pas de routes statiques personnalisées dont les destinations s'inscrivent dans la plage 10.128.0.0/9. Cette plage contient les plages d'adresses IP de sous-réseau actuelles et futures pour les sous-réseaux créés automatiquement. Les routes statiques avec des destinations comprises dans la plage 10.128.0.0/9 qui existent dans un réseau en mode automatique peuvent être désactivées de manière inattendue lorsqu'une nouvelle région Google Cloud devient disponible. Cela se produit parce qu'une nouvelle route de sous-réseau est créée pour la plage d'adresses IP principale du sous-réseau créé automatiquement dans la nouvelle région. Pour plus d'informations, consultez les pages Plages d'adresses IP en mode automatique et Remarques concernant les réseaux VPC en mode automatique.

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 IPv6 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	ECMP¹
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 principale de son interface réseau. Pour en savoir plus, consultez Considérations liées aux instances de prochain saut.
É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.

¹ 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 interne 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 IPv4 interne, Google Cloud vérifie que l'adresse IPv4 de la VM de prochain saut correspond à la plage IPv4 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 saut est une adresse IPv4 interne principale attribuée à la carte d'interface réseau d'une VM du réseau VPC de la route (et non d'un réseau VPC appairé).

Google Cloud met automatiquement à jour la programmation du prochain saut lorsque l'adresse IPv4 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).
Même destination et plusieurs équilibreurs de charge réseau internes à stratégie directe comme saut suivant. Si vous créez deux routes statiques personnalisées ou plus avec la même destination et que vous utilisez différents équilibreurs de charge réseau internes à stratégie directe en tant que sauts suivants, Google Cloud ne répartit jamais le trafic entre les équilibreurs de charge utilisés en tant que saut suivant à l'aide d'ECMP. Si les routes ont des priorités uniques, Google Cloud utilise comme saut suivant l'équilibreur de charge réseau interne à stratégie directe de la route ayant la priorité la plus élevée. Si les routes ont des priorités égales, Google Cloud ne sélectionne qu'un seul équilibreur de charge réseau interne à stratégie directe comme saut suivant. Dans ce dernier cas, comme illustré dans le diagramme ci-dessous, Google Cloud utilise un algorithme interne déterministe pour sélectionner une seule règle de transfert de saut suivant (forwarding-rule-a), en ignorant les autres routes ayant la même priorité.
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 destinations avec le même équilibreur de charge réseau interne à stratégie directe comme saut suivant.

Avec des tags d'instance :

Si vous appliquez des tags d'instance (également appelés tags réseau), vous pouvez utiliser le même équilibreur de charge réseau interne à stratégie directe comme saut suivant pour plusieurs routes statiques personnalisées avec la même destination et la même priorité.

Sans tags d'instance : sans tags d'instance, vous ne pouvez pas créer plusieurs routes statiques personnalisées ayant la même combinaison de destination, de priorité et d'équilibreur de charge réseau interne à stratégie directe utilisé comme saut suivant. Par exemple, route-x, route-y et route-z peuvent être créés, mais route-x-copy ne peut pas être créé.
Les routes statiques sans tag d'instance ne peuvent pas être créées avec la même destination, la même priorité et le même équilibreur de charge réseau interne à stratégie directe en tant que saut suivant.
Tags d'instance.

Vous pouvez spécifier des tags d'instance (également appelés tags réseau) pour que la route de saut suivant ne s'applique qu'aux instances clientes qui ont été configurées avec le tag. Cela vous permet de sélectionner les instances clientes dotées d'une route de saut suivant avec tags et l'ensemble des appareils vers lesquels acheminer le trafic.

Vous n'avez pas besoin de répartir les différentes instances clientes dans des réseaux VPC distincts. Chacune d'elles pointe vers son équilibreur de charge réseau interne à stratégie directe préféré afin d'interfacer un ensemble d'appareils.

Remarque : Les routes avec tag ne sont ni exportées, ni importées via l'appairage.
Plusieurs routes vers le même préfixe de destination. Avec les tags, vous pouvez spécifier plusieurs routes vers la même destination avec différents équilibreurs de charge internes en tant que sauts suivants. Vous pouvez utiliser des propriétés ou des tags différents pour ces mêmes routes de destination.

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

Pour créer et gérer des routes, consultez la page Utiliser des routes.
Pour en savoir plus sur les réseaux VPC Google Cloud, consultez la page Réseaux VPC.
Pour créer, modifier et supprimer des réseaux VPC, consultez la page Créer et gérer des réseaux VPC.