Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Dépannage

Utilisez le guide suivant pour résoudre les problèmes courants liés à Cloud Router :

Pour obtenir de l'aide supplémentaire, consultez la documentation suivante :

Problèmes de configuration

L'établissement de la session BGP a échoué

Vérifiez que les paramètres de votre routeur BGP sur site et ceux de votre routeur cloud sont corrects. Pour en savoir plus, consultez les journaux de Cloud Router.

Si vous créez un tunnel Cloud VPN, vérifiez que l'état du tunnel est ESTABLISHED. Si ce n'est pas le cas, consultez la page Dépannage de Cloud VPN pour résoudre le problème.

Adresses IP pour les sessions BGP

Les adresses IP que vous pouvez utiliser pour une session BGP dépendent du produit de connectivité réseau que vous utilisez. Pour en savoir plus, consultez la section Adresses IP BGP.

Valeur incorrecte pour le champ resource.bgp.asn

Vous pouvez obtenir l'erreur suivante :

"Valeur non valide pour le champ resource.bgp.asn : ######. Le numéro ASN local est en conflit avec le numéro ASN pair spécifié par un routeur de la même région et du même réseau."

Le routeur Cloud Router tente d'établir une session BGP avec un périphérique sur site possédant le même numéro ASN que le routeur cloud. Pour résoudre ce problème, modifiez le numéro ASN de votre périphérique ou de votre routeur cloud.

iBGP ne fonctionne pas entre les routeurs cloud d'une même région

Bien que vous puissiez créer deux routeurs cloud avec le même numéro ASN, iBGP n'est pas accepté.

Problèmes avec Cloud Router

Des réinitialisations BGP provenant de Google Cloud apparaissent sur votre routeur

Les tâches du routeur Cloud Router sont des processus logiciels du plan de contrôle Google Cloud qui sont normalement transférés d'une machine à l'autre. Au cours de ces migrations, le routeur Cloud Router peut être indisponible pendant 60 secondes maximum. Les migrations normales n'entraînent pas la suppression du trafic.

Le routeur Cloud Router ne se trouve pas dans le chemin de données et n'agit pas en tant que commutateur de couche 3, mais en tant que gestionnaire de la programmation de routage. Le routage est en fait géré par le rattachement de VLAN ou le tunnel Cloud VPN.

Le message NOTIFICATION_RECEIVED s'affiche dans les journaux Cloud Router.

Un message NOTIFICATION_RECEIVED s'affiche dans les journaux Cloud Router lorsque le routeur cloud a reçu un message NOTIFICATION du pair BGP. Le message NOTIFICATION indique à Cloud Router qu'il doit arrêter la session BGP.

Lorsque Cloud Router reçoit un message NOTIFICATION de son pair BGP, il ferme la connexion BGP avec ce pair et supprime toutes les routes apprises.

Le pair BGP peut envoyer des messages NOTIFICATION pour diverses raisons. Par exemple, le pair peut envoyer un message "Timer de préservation expiré".

Le message CONFIG_DISABLED s'affiche dans les journaux Cloud Router.

Un message CONFIG_DISABLED indique que Cloud Router a intentionnellement arrêté la session BGP. En arrêtant la session BGP, Cloud Router tente de communiquer immédiatement un état d'erreur à son pair.

Ce message peut apparaître pour l'une des raisons suivantes :

  • Un utilisateur a désactivé la session BGP à l'aide de l'API Cloud Router, de Google Cloud Console ou de Google Cloud CLI. Consultez la section Désactiver ou supprimer des sessions BGP.
  • Pour une session BGP configurée pour Cloud VPN, le tunnel VPN associé à la session BGP n'a pas établi d'association de sécurité IKE et enfant. Pour résoudre les problèmes de connectivité VPN, consultez la page Dépannage de Cloud VPN.
  • Dans le cas d'une session BGP configurée pour Cloud Interconnect, le rattachement de VLAN n'est pas configuré ou est à l'état administrateur. Pour résoudre le problème, consultez la page Dépannage de la documentation Cloud Interconnect.
  • Pour une session BGP compatible avec BFD, le minuteur de détection du contrôle BFD sur le routeur cloud a expiré. Dans ce cas, la session BGP est arrêtée. Pour en savoir plus sur les états des sessions BFD, consultez la page Messages de diagnostic et états des sessions BFD.

Un message LINK_DOWN s'affiche dans les journaux Cloud Router lorsque la liaison entre le routeur périphérique d'appairage de Google et votre rattachement de VLAN pour Cloud Interconnect est interrompue. Le routeur périphérique d'appairage est un équipement réseau géré par Google au sein de l'installation hébergée en colocation où vous avez provisionné votre connexion Cloud Interconnect.

Le message LINK_DOWN indique que l'état du pair BGP correspondant est en panne. Ce message ne s'applique qu'aux sessions BGP basées sur Cloud Interconnect.

Oscillations BGP du routeur sur site

L'oscillation BGP peut être causée par divers problèmes, y compris les opérations de maintenance de logiciels et de redémarrage automatique des tâches de Cloud Router.

Pour en savoir plus sur les événements de maintenance ayant eu lieu, consultez la page Identifier les événements de maintenance du routeur. Pour en savoir plus sur les autres événements Cloud Router, consultez la page Afficher les journaux et les métriques Cloud Router.

Un événement de maintenance Cloud Router n'indique pas un problème si votre routeur sur site est configuré comme suit :

  • Le routeur sur site peut traiter les événements de redémarrage en douceur.
  • Le timer de préservation du routeur sur site est réglé sur au moins 60 secondes.

Pour obtenir une présentation complète des paramètres des timers, consultez la section Gérer les timers BGP.

Pour obtenir de l'aide sur la surveillance de la connectivité, consultez la section Vérifier la connectivité entre le routeur sur site et le routeur cloud.

Problèmes d'authentification

Les sections suivantes décrivent les problèmes qui peuvent survenir avec l'authentification MD5.

L'état du pair BGP est MD5_AUTH_INTERNAL_PROBLEM.

Parfois, l'état d'un pair BGP comprend les valeurs suivantes :

  • md5AuthEnabled : true
  • statusReason : MD5_AUTH_INTERNAL_PROBLEM

La première valeur indique que vous avez correctement configuré l'authentification MD5. Cependant, la seconde valeur (statusReason) sur MD5_AUTH_INTERNAL_PROBLEM indique qu'une erreur interne a empêché la configuration de l'authentification MD5. Pour cette raison, l'état de la session BGP est DOWN. Dans ce cas, vous n'avez rien à faire. Cloud Router tente de récupérer et de rétablir la session. Si la sauvegarde prend plus d'une heure, contactez l'assistance Google Cloud.

Pour savoir comment vérifier l'état du pair, consultez la section Vérifier l'état de l'authentification.

Cloud Router et les pairs utilisent des clés MD5 différentes

Lorsque vous configurez l'authentification MD5, le routeur Cloud Router et son routeur pair doivent utiliser la même clé d'authentification secrète. Si une incohérence se produit, les deux routeurs ne peuvent pas communiquer. Si vous pensez qu'il y a une incohérence, une solution consiste à mettre à jour la clé utilisée par le routeur Cloud Router. Pour en savoir plus sur cette modification, consultez la page Mettre à jour la clé d'authentification.

Si vous n'êtes pas sûr qu'il y a eu une non-concordance, recherchez des solutions de dépannage dans la documentation de votre routeur pair. De nombreux routeurs contiennent des journaux qui enregistrent ou non une incohérence de clé.

La clé MD5 générée automatiquement est plus longue que celle compatible avec l'appareil sur site

Vous pouvez générer automatiquement la clé MD5 en cliquant sur Générer et copier dans la console d'interface utilisateur. Pour en savoir plus, consultez la section Ajouter l'authentification à une session existante. Si la clé MD5 générée automatiquement est plus longue que celle compatible avec votre environnement sur site, vous pouvez la configurer manuellement via l'interface utilisateur, gcloud ou l'API.

Problèmes de traitement des routes

Les routes sur site sans valeur MED sont prioritaires

Si le routeur Cloud Router reçoit une route sur site sans valeur MED, il suit le comportement décrit dans le document RFC 4271. Le routeur Cloud Router traite la route avec la priorité la plus élevée en supposant l'application de la valeur MED la plus basse possible (0).

Vous ne pouvez pas envoyer ni apprendre les valeurs MED via une connexion d'interconnexion partenaire de couche 3

Si vous utilisez une connexion d'interconnexion partenaire dans laquelle un fournisseur de services de couche 3 gère les sessions BGP, Cloud Router ne peut pas apprendre les valeurs MED à partir de votre routeur sur site ni envoyer de valeurs MED à ce routeur. En effet, les valeurs MED ne peuvent pas transiter par des systèmes autonomes. Via ce type de connexion, vous ne pouvez pas définir de priorités de routage pour les routes annoncées par Cloud Router sur votre routeur sur site. En outre, vous ne pouvez pas définir de priorités de routage pour les routes annoncées par votre routeur sur site sur votre réseau VPC.

Certains préfixes IP sur site ne sont pas disponibles

Si certains préfixes IP sur site ne sont pas disponibles, vérifiez les quotas et les limites, ou les plages de sous-réseaux qui se chevauchent.

Vérifier les quotas et les limites

Vérifiez que vos routeurs cloud n'ont pas dépassé les limites des routes apprises. Pour afficher le nombre de routes apprises par un routeur cloud, affichez son état.

Pour en savoir plus sur les limites, les messages de journal et les métriques associées, et la résolution des problèmes, consultez le tableau suivant.

Limites Conseils
À propos des limites

Il existe deux limites pour les routes apprises. Ces limites ne définissent pas directement un nombre maximal de routes apprises. Elles définissent plutôt le nombre maximal de préfixes de destination uniques :

  • Nombre maximal de destinations uniques pour les routes apprises pouvant être appliquées aux sous-réseaux d'une région donnée par tous les routeurs Cloud Router de la même région
  • Nombre maximal de destinations uniques pour les routes apprises pouvant être appliquées aux sous-réseaux d'une région donnée par les routeurs cloud de différentes régions

La première limite est pertinente, quel que soit le mode de routage dynamique utilisé par le réseau VPC. La seconde limite n'a de sens que si le réseau VPC utilise le mode de routage dynamique global. Pour en savoir plus sur les limites de Cloud Router, consultez la page Limites.

Journaux Lorsque vous rencontrez l'une de ces limites, un message limit-exceeded s'affiche dans Cloud Logging. Pour en savoir plus sur la création d'une requête avancée permettant d'afficher ce message, consultez la requête associée dans la documentation de journalisation de Cloud Router.
Métriques

Vous pouvez également utiliser les métriques suivantes pour comprendre vos limites et votre utilisation actuelles. Ces métriques sont précédées du préfixe router.googleapis.com/dynamic_routes/learned_routes/ :

  • used_unique_destinations

    Nombre de destinations uniques actuellement utilisées dans ce réseau VPC. Si le routage dynamique global est activé, cette métrique affiche à la fois l'utilisation globale et régionale.

  • unique_destinations_limit

    Nombre de destinations uniques autorisées à annoncer sur ce réseau VPC. Si le routage dynamique global est activé, cette métrique affiche à la fois les limites globales et régionales.

  • any_dropped_unique_destinations

     : indique si des destinations ont été supprimées pour ce réseau VPC en raison d'un dépassement de limite de quota de routage (une ou les deux).

Ces métriques sont disponibles via la ressource surveillée gce_network_region. Pour en savoir plus sur les métriques Cloud Router et la façon de les afficher, consultez la section Métriques sur la page Afficher les journaux et les métriques.

Résolution des problèmes

Vous pouvez effectuer les opérations suivantes pour résoudre les problèmes liés aux limites de routes. Lorsque le nombre de routes dépasse largement les limites, il est judicieux d'effectuer les deux opérations suivantes :

  • Configurer vos routeurs sur site pour agréger les routes que vous exportez, afin que ces routes annoncent moins de destinations (CIDR).
  • Contacter l'assistance. L'assistance peut vous aider à réinitialiser vos routeurs cloud, si nécessaire, ou à augmenter les limites.

Vérifier les plages de sous-réseaux qui se chevauchent

Assurez-vous que les plages d'adresses IP d'un sous-réseau VPC ne chevauchent pas complètement les annonces de routage de votre réseau sur site. Le chevauchement des plages d'adresses IP peut entraîner la suppression de routes. Cela s'applique également aux routes statiques personnalisées qui chevauchent une route dynamique apprise par un routeur Cloud Router. Les préfixes reçus par les routeurs cloud sont ignorés (les routes dynamiques personnalisées ne sont pas créées) dans les scénarios suivants :

  • Lorsque le préfixe appris correspond exactement à une plage d'adresses IP principale ou secondaire d'un sous-réseau de votre réseau VPC.
  • Lorsque le préfixe appris correspond exactement à la destination d'une route statique personnalisée de votre réseau VPC.
  • Lorsque le préfixe appris est plus spécifique (masque de sous-réseau plus long) qu'une plage d'adresses IP principale ou secondaire d'un sous-réseau de votre réseau VPC.
  • Lorsque le préfixe appris est plus spécifique (masque de sous-réseau plus long) que la destination d'une route statique personnalisée de votre réseau VPC.

Pour en savoir plus, consultez la section Applicabilité et ordre des routes dans la présentation des routes VPC.

Les routes apprises d'un réseau sur site ne se propagent pas vers d'autres réseaux VPC

Un seul routeur cloud donné ne peut pas réannoncer les routes apprises d'un pair BGP sur les autres pairs BGP, y compris vers les routeurs cloud d'autres réseaux VPC.

Par exemple, dans la topologie en étoile suivante, Cloud Router ne peut pas accepter l'annonce de routage entre plusieurs réseaux VPC.

Cloud Router Hub et Spoke
Topologie Cloud Router en étoile (cliquez pour agrandir)

Pour consulter les recommandations concernant les topologies de réseaux dans Google Cloud, consultez la page Bonnes pratiques et architectures de référence pour la conception de VPC.

En outre, pour créer et gérer les topologies en étoile dans Google Cloud, vous pouvez utiliser Network Connectivity Center.

Les préfixes ne sont pas importés dans les sessions BGP (préfixage du chemin AS)

Le préfixage de chemin AS n'est pas pertinent pour le plan de contrôle et le réseau VPC. La longueur du chemin AS n'est prise en compte que dans les tâches logicielles Cloud Router, comme décrit dans les scénarios suivants.

Si une tâche logicielle Cloud Router unique apprend la même destination à partir de plusieurs sessions BGP :

  • La tâche logicielle sélectionne la session BGP à saut suivant avec le chemin AS le plus court.
  • La tâche logicielle envoie des informations sur la destination, le saut suivant et les valeurs MED au plan de contrôle Cloud Router.
  • Le plan de contrôle utilise ces informations pour créer une ou plusieurs routes candidates. La priorité de base de chaque candidat est définie sur la valeur MED reçue.

Si plusieurs tâches logicielles Cloud Router apprennent la même destination à partir de plusieurs sessions BGP :

  • Chaque tâche logicielle sélectionne une session BGP à saut suivant avec le chemin AS le plus court.
  • Chaque tâche logicielle envoie des informations sur la destination, le saut suivant et les valeurs MED au plan de contrôle Cloud Router.
  • Le plan de contrôle utilise ces informations pour créer au moins deux routes candidates. La priorité de base de chaque candidat est définie sur la valeur MED reçue.

Le plan de contrôle Cloud Router installe ensuite une ou plusieurs routes dynamiques personnalisées dans le réseau VPC, en fonction du mode de routage dynamique de celui-ci. En mode de routage dynamique global, la priorité de chaque route dynamique régionale personnalisée est ajustée dans des régions différentes de la région Cloud Router. Pour plus d'informations sur la façon dont Google Cloud sélectionne une route, consultez la section Ordre de routage dans la documentation concernant les VPC.

Sur une VM à plusieurs cartes réseau, chaque carte reçoit des routes différentes

Il s'agit d'un comportement normal. Vous devez configurer chaque carte d'interface réseau pour une VM dotée de plusieurs cartes d'interface réseau au sein d'un réseau VPC unique. Chaque routeur cloud crée des routes dynamiques personnalisées dans un réseau VPC. Ainsi, les routes apprises par un routeur cloud ne s'appliquent qu'à une seule interface réseau d'une VM dotée de plusieurs cartes d'interface réseau. Les paquets envoyés à partir de l'interface réseau d'une VM utilisent uniquement les routes applicables au réseau VPC pour cette interface.

Le trafic est routé de manière asymétrique

Le trafic est routé de manière asymétrique lorsque les trafics entrant et sortant utilisent des chemins différents. Par exemple, vous avez peut-être deux tunnels Cloud VPN. Le trafic sortant de votre réseau VPC passe peut-être par le premier tunnel, tandis que le trafic entrant sur votre réseau VPC passe par le second tunnel.

Le routage asymétrique se produit lorsque les chemin privilégiés qui sont annoncés par votre routeur local et votre routeur cloud ne s'alignent pas. Pour le trafic entrant sur votre réseau VPC, Cloud Router permet de configurer la priorité des routes annoncées. Pour plus d'informations, consultez la section Routes dynamiques personnalisées apprises.

Consultez la documentation de votre appareil pour savoir comment fonctionne la sélection du meilleur chemin BGP, car d'autres attributs (tels que l'ID de routeur ou le numéro ASN d'origine) peuvent l'affecter. Par exemple, consultez les ressources suivantes :

Pour le trafic sortant de votre réseau VPC, vérifiez les préférences locales ou les valeurs MED de votre routeur sur site.

La route par défaut (0.0.0.0/0 ou ::/0) envoie du trafic à la passerelle Internet

Lorsque vous créez un réseau VPC, Google Cloud crée automatiquement une route par défaut avec une priorité de 1000 et dont le saut suivant est la passerelle Internet par défaut.

Les routes avec un saut suivant de la passerelle Internet par défaut ne peuvent être utilisées que par des VM qui répondent aux conditions d'accès à Internet.

L'utilisation de routes avec un saut suivant de la passerelle Internet par défaut est également requise pour accéder aux API et services Google, par exemple lorsque vous utilisez l'accès privé à Google.

Les exemples suivants décrivent des situations susceptibles de bloquer le trafic vers Internet ou vers les API et services Google :

  • Si vous supprimez la route par défaut créée automatiquement (la route avec un saut suivant de la passerelle Internet par défaut).
  • Si vous remplacez la route par défaut créée automatiquement et que le saut suivant de la route de remplacement est différent de la passerelle Internet par défaut.
  • Si Cloud Router apprend une route avec la destination 0.0.0.0/0 ou ::/0 qui a une priorité plus élevée que la route par défaut créée automatiquement.

Le saut suivant n'est pas clair

Pour en savoir plus sur le fonctionnement de l'algorithme Google Cloud de sélection des routes, consultez la section Applicabilité et ordre dans la documentation sur les routes des VPC.

Le trafic IPv6 n'est pas acheminé

Si vous rencontrez des difficultés pour vous connecter à des hôtes IPv6, procédez comme suit :

  1. Vérifiez que les routes IPv4 sont correctement annoncées. Si les routes IPv4 ne sont pas annoncées, suivez les procédures générales de dépannage répertoriées dans ce document.
  2. Examinez les règles de pare-feu pour vous assurer que vous autorisez le trafic IPv6 entre votre réseau VPC et votre réseau sur site.
  3. Vérifiez qu'il n'existe pas de plages de sous-réseaux IPv6 qui se chevauchent dans votre réseau VPC et sur votre réseau sur site. Consultez la section Vérifier les plages de sous-réseaux qui se chevauchent.
  4. Déterminez si vous avez dépassé les quotas et les limites pour les routes apprises. Si vous avez dépassé votre quota pour les routes apprises, les préfixes IPv6 sont supprimés avant les préfixes IPv4. Consultez la page Vérifier les quotas et les limites.
  5. Vérifiez que tous les composants nécessitant une configuration IPv6 ont été correctement configurés.
    • Le sous-réseau VPC est configuré pour utiliser le type de pile IPV4_IPV6.
    • Le sous-réseau VPC possède --ipv6-access-type défini sur INTERNAL.
    • Les VM Compute Engine du sous-réseau sont configurées avec des adresses IPv6.
    • La passerelle VPN haute disponibilité est configurée pour utiliser le type de pile IPV4_IPV6.
    • Le pair BGP est activé pour utiliser IPv6, et les adresses de saut suivant IPv6 correctes sont configurées pour la session BGP.

Étapes suivantes