Cette page a été traduite par l'API Cloud Translation.

Dépannage

Ce guide de dépannage peut vous aider à résoudre les problèmes courants que vous pourriez rencontrer lors de l'utilisation de Cloud Interconnect :

Dépannage d'ordre général
Dedicated Interconnect
Interconnexion partenaire
VPN haute disponibilité sur Cloud Interconnect
MACsec pour Cloud Interconnect
interconnexion cross-cloud

Pour connaître les réponses aux questions fréquentes relatives à l'architecture et aux fonctionnalités de Cloud Interconnect, consultez l'article Questions fréquentes relatives à Cloud Interconnect.

Pour connaître la définition des termes employés sur cette page, consultez la page Termes clés de Cloud Interconnect.

Important : BFD ne peut être activé que sur les rattachements de VLAN provisionnés qui utilisent Dataplane version 2. Vous pouvez afficher la version dataplaneVersion pour un rattachement de VLAN en consultant les détails du rattachement de l'une des manières suivantes :

API : utilisez la méthode interconnectAttachments.get. Vous pouvez utiliser cette méthode sur des rattachements de VLAN pour une interconnexion dédiée ou une interconnexion partenaire.
Google Cloud CLI : utilisez la commande gcloud compute interconnects attachments describe ATTACHMENT-NAME où ATTACHMENT-NAME est le nom du rattachement de VLAN pour une interconnexion dédiée ou partenaire.

Dans le résultat de l'API ou la commande de gcloud CLI, recherchez le champ dataplaneVersion avec une valeur de 2. Si le champ est absent de la sortie, le rattachement de VLAN utilise la version 1 et ne peut pas être utilisé avec BFD. Pour en savoir plus, contactez l'équipe responsable de votre compte.

Pour trouver des informations de journalisation et de surveillance et afficher les métriques Cloud Interconnect, consultez la page Surveiller les connexions.

Dépannage d'ordre général

Rechercher des interruptions de service Cloud Interconnect

Vous pouvez consulter les perturbations connues dans le tableau de bord d'état de Google Cloud. Vous pouvez également vous abonner au flux JSON ou au flux RSS concernant les incidents cloud pour recevoir des notifications push.
Vous êtes informé des événements de maintenance ayant une incidence sur vos connexions par interconnexion dédiée. Pour en savoir plus, consultez la section Événements de maintenance de l'infrastructure.
Vous êtes informé des événements de maintenance qui affectent vos rattachements de VLAN d'interconnexions partenaires. Les notifications pour l'interconnexion partenaire sont envoyées de la même manière que les notifications pour les connexions par interconnexion dédiée, à quelques différences mineures. Pour en savoir plus, consultez la section Événements de maintenance de l'infrastructure.

Impossible de vous connecter aux ressources d'autres régions

Par défaut, les réseaux de cloud privé virtuel (VPC) sont régionaux, ce qui signifie que le routeur cloud ne diffuse que les sous-réseaux de sa région. Pour vous connecter à d'autres régions, sélectionnez le mode routage dynamique "mondial" sur votre réseau VPC. Cela permettra au routeur cloud de diffuser tous les sous-réseaux.

Pour en savoir plus, consultez Mode de routage dynamique dans la documentation de Cloud Router.

Impossible d'atteindre les VM d'un réseau VPC appairé

Dans ce scénario, vous avez configuré une connexion Cloud Interconnect entre votre réseau sur site et un réseau VPC, le réseau A. Vous avez également configuré l'appairage de réseaux VPC entre le réseau A et un autre réseau VPC, le réseau B. Cependant, vous ne pouvez pas atteindre les VM du réseau B depuis votre réseau sur site.

Cette configuration n'est pas compatible, comme décrit dans les restrictions de la présentation de l'appairage de réseaux VPC.

Toutefois, vous pouvez utiliser des annonces de plages d'adresses IP personnalisées provenant de routeurs Cloud de votre réseau VPC pour partager des routes vers des destinations du réseau appairé. En outre, vous devez configurer les connexions d'appairage de réseaux VPC pour importer et exporter des routes personnalisées.

Pour plus d'informations sur les routes publicitaires entre les réseaux sur site et les réseaux appairés VPC, consultez les ressources suivantes :

Annoncer des plages d'adresses IP personnalisées
Dépannage de l'utilisation de l'appairage de réseaux VPC

Sous-réseaux manquants dans une connexion

Pour annoncer tous les sous-réseaux disponibles, spécifiez les routes manquantes avec des routes annoncées personnalisées et annoncez toutes les routes de sous-réseau entre les régions avec le routage dynamique global. Pour ce faire, procédez comme suit :

Spécifiez des routes annoncées personnalisées sur un routeur Cloud Router et sur la session BGP (Border Gateway Protocol).

Pour saisir les routes manquantes, définissez les paramètres suivants :
```
--set-advertisement-groups = ADVERTISED_GROUPS
--set-advertisement-ranges = ADVERTISED_IP_RANGES
```
Remplacez les éléments suivants :
- ADVERTISED_GROUPS : groupe défini par Google que Cloud Router annonce de manière dynamique. Ce paramètre peut avoir la valeur all_subnets, qui imite le comportement par défaut d'un routeur cloud.
- ADVERTISED_IP_RANGES : contenu du nouveau tableau de plages d'adresses IP. Ce paramètre peut regrouper une ou plusieurs valeurs de votre choix.
Pour plus d'informations et d'exemples, consultez la section Annoncer des plages d'adresses IP personnalisées.
Activez le mode de routage dynamique global.

Impossible de pinguer le routeur cloud

Si vous ne parvenez pas à pinguer le routeur cloud depuis votre routeur sur site, recherchez votre produit dans le tableau suivant et suivez la procédure de dépannage pour ce produit. Les VM ne peuvent pas atteindre 169.254.0.0/16.

Procédure de dépannage	Dedicated Interconnect	Interconnexion partenaire avec un partenaire de couche 3	Interconnexion partenaire avec un partenaire de couche 2
Dans le cas d'une interconnexion partenaire, il est possible que le routeur cloud ne puisse pas être pingué, car certains partenaires filtrent le trafic sur la plage d'adresses IP (`169.254.0.0/16`) du routeur cloud. Pour les partenaires de couche 3, BGP est automatiquement configuré par le partenaire. Si BGP ne fonctionne pas, contactez votre partenaire.	Non applicable	Oui	Non applicable
Vérifiez que votre appareil local a appris l'adresse MAC appropriée pour le côté Google Cloud de la connexion. Pour en savoir plus, consultez la section Dépannage de l'ARP.	Oui	Non applicable	Non applicable
Vérifiez que votre routeur cloud possède une interface et un pair BGP. Le routeur cloud ne peut pas être pingué, sauf si l'interface et le pair BGP sont entièrement configurés, y compris le numéro ASN distant. Pour l'interconnexion dédiée, consultez la section La session BGP ne fonctionne pas. Pour l'interconnexion partenaire de couche 2, Google a ajouté automatiquement l'interface et le pair BGP pour le routeur cloud, mais vous devez configurer le numéro ASN distant.	Oui	Non applicable	Oui

Dépannage de l'ARP

Pour l'interconnexion dédiée, vous pouvez trouver l'adresse MAC appropriée en exécutant la commande gcloud suivante :

  gcloud compute interconnects get-diagnostics INTERCONNECT_NAME

Le paramètre googleSystemID contient l'adresse MAC qui doit figurer dans la table ARP de votre appareil pour les adresses IP attribuées au routeur cloud.

  result:
    links:
    — circuitId: SAMPLE-0
      googleDemarc: sample-local-demarc-0
      lacpStatus:
        googleSystemId: ''
        neighborSystemId: ''
        state: DETACHED
      receivingOpticalPower:
        value: 0.0
      transmittingOpticalPower:
        value: 0.0
    macAddress: 00:00:00:00:00:00

Si votre appareil n'a pas appris d'adresse MAC, vérifiez que l'ID et l'adresse IP de VLAN corrects sont configurés sur la sous-interface.

Pour une interconnexion partenaire, si l'adresse MAC affichée sur votre appareil est incorrecte, vérifiez que vous n'avez pas créé de liaison entre les segments de couche 2 des deux rattachements de VLAN. Le côté Google Cloud de la connexion Cloud Interconnect est configuré avec ip proxy-arp, ce qui permet de répondre à toutes les requêtes ARP et peut amener votre routeur sur site à apprendre des entrées ARP incorrectes.

Impossible de créer un rattachement de VLAN

Si vous tentez de créer un rattachement de VLAN pour une interconnexion dédiée ou une interconnexion partenaire qui enfreint une règle d'administration, un message d'erreur s'affiche. Pour consulter l'exemple de message d'erreur suivant, exécutez la commande gcloud compute interconnects attachments partner create :

ERROR: (gcloud.compute.interconnects.attachments.partner.create) Could not fetch resource:
- Constraint constraints/compute.restrictPartnerInterconnectUsage violated for projects/example-project. projects/example-project/global/networks/example-network is not allowed to use the Partner Interconnect.

Pour en savoir plus, consultez la page Restreindre l'utilisation de Cloud Interconnect et contactez votre administrateur d'entreprise.

Partager des connexions avec d'autres projets de votre organisation

Vous pouvez partager une connexion, telle qu'un rattachement de VLAN ou une connexion d'interconnexion dédiée, dans un projet hôte à l'aide d'un VPC partagé.

Pour en savoir plus sur la configuration d'un réseau VPC partagé, consultez la page Provisionner le VPC partagé.

Pour en savoir plus sur la configuration des rattachements dans un réseau VPC partagé, consultez la page Options de connexion à plusieurs réseaux VPC.

Dedicated Interconnect

Google ne peut pas vous pinguer durant le processus de provisionnement de la connexion

Vérifiez que vous utilisez la bonne configuration IP et LACP. Lors du test, Google vous envoie différentes configurations IP de test pour votre routeur sur site, selon que votre commande intègre un bundle d'une ou plusieurs liaisons. Ne configurez pas de rattachements de VLAN pour ces tests.

Pour les groupes comportant plusieurs liaisons

Le premier ensemble d'adresses IP envoyé par Google permet de tester la connectivité de plusieurs circuits sur chaque liaison individuelle. Vous devez configurer les adresses IP de test sur toutes les liaisons physiques (sans LACP configuré), comme indiqué dans les e-mails que vous avez reçus. Google doit réussir à pinguer toutes ces adresses IP pour que le premier test soit concluant.
Avant d'effectuer le deuxième test, supprimez toutes les adresses IP utilisées lors du premier test. Configurez le canal de port avec LACP, même si votre connexion ne comporte qu'une seule liaison. Google pingue l'adresse du canal de port. Ne modifiez pas la configuration LACP de votre canal de port une fois que la connexion a réussi le test final. Cependant, vous devez supprimer l'adresse IP de test de l'interface du canal de port.

Pour les groupes ne comportant qu'une liaison

Google vous envoie l'adresse IP de production finale pour que vous puissiez tester la connectivité d'un seul circuit. Vous devez configurer l'adresse IP sur l'interface du bundle (avec LACP configuré en mode actif ou passif), comme indiqué dans l'e-mail que vous avez reçu. Google doit réussir à pinguer l'adresse IP de l'interface du bundle pour que ce test soit concluant. Configurez le canal de port avec LACP, même si votre connexion ne comporte qu'une seule liaison.

Impossible de pinguer le routeur cloud

Vérifiez que vous pouvez pinguer l'adresse IP du canal de port de Google. Cette adresse correspond à la valeur googleIpAddress visible lorsque vous affichez les informations sur la connexion.
Vérifiez que la sous-interface du routeur sur site est associée au bon VLAN. Les informations VLAN doivent correspondre aux détails fournis par le rattachement de VLAN.
Vérifiez que la sous-interface de votre routeur sur site dispose de la bonne adresse IP. Lorsque vous créez un rattachement de VLAN, celui-ci attribue une paire d'adresses IP locales de liaison : une pour une interface sur un routeur cloud (cloudRouterIpAddress), et l'autre pour une sous-interface sur le canal de port de votre routeur sur site, et non sur le canal de port lui-même (customerRouterIpAddress).
Si vous testez les performances de vos rattachements de VLAN, ne pinguez pas le routeur cloud. Créez plutôt une instance de machine virtuelle (VM) Compute Engine sur votre réseau VPC, puis utilisez-la. Pour en savoir plus, consultez la section relative aux tests des performances.

La session BGP ne fonctionne pas

Activez le protocole BGP multi-saut sur votre routeur sur site en utilisant au moins deux sauts.
Vérifiez que la bonne adresse IP voisine est configurée sur votre routeur sur site. Utilisez l'adresse IP du pair BGP (cloudRouterIpAddress) attribuée par le rattachement de VLAN.
Vérifiez que le numéro ASN local sur votre routeur sur site correspond à celui du pair sur le routeur cloud. En outre, vérifiez que le numéro ASN local sur le routeur cloud correspond au numéro ASN du pair sur votre routeur sur site.
Chaque rattachement se voit attribuer un masque CIDR /29 unique dans l'espace d'adresses 169.254.0.0/16 au sein de votre réseau VPC. Une adresse IP dans le masque CIDR /29 est allouée au routeur cloud, l'autre est alloué à votre routeur sur site.

Vérifiez que les adresses IP correctes sont allouées à l'interface de votre routeur sur site et à son voisin BGP. Une erreur fréquente consiste à configurer un masque /30 sur votre interface de routeur sur site, au lieu d'un masque /29. Toutes les autres adresses du masque CIDR /29 sont réservées par Google Cloud.

Assurez-vous que vous n'avez pas alloué d'autres adresses IP de ce masque CIDR à l'interface de rattachement de VLAN sur votre routeur.

Impossible d'accéder aux VM de votre réseau VPC

Vérifiez que vous pouvez pinguer le canal de port et le rattachement de VLAN.
Vérifiez que votre session BGP est active.
Vérifiez que votre routeur sur site diffuse et reçoit des routes.
Vérifiez l'absence de chevauchement entre vos annonces de routage sur site et les plages de réseau Google Cloud.
Définissez la taille de la MTU sur les mêmes valeurs pour le routeur sur site, le VPC et le rattachement de VLAN.

Le trafic IPv6 ne passe pas par le rattachement de VLAN

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

Vérifiez que les routes IPv6 sont correctement annoncées. Si les routes IPv6 ne sont pas annoncées, consultez Résoudre les problèmes liés aux routes BGP et à la sélection de routes.
Examinez les règles de pare-feu pour vous assurer que vous autorisez le trafic IPv6.
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.
Déterminez si vous avez dépassé les quotas et les limites pour les routes apprises dans Cloud Router. 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.
Vérifiez que tous les composants liés à la configuration IPv6 ont été correctement configurés.
- Le réseau VPC a activé l'utilisation des adresses IPv6 internes avec l'option --enable-ula-internal-ipv6.
- 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.
- Le rattachement de VLAN est configuré pour utiliser le type de pile IPV4_IPV6.
- Le pair BGP a activé IPv6 et les adresses de saut suivant IPv6 correctes sont configurées pour la session BGP.
  - Pour afficher l'état et les routes Cloud Router, consultez la page Afficher l'état et les routes du routeur Cloud Router.
  - Pour afficher la configuration de la session BGP, consultez la page Afficher la configuration de la session BGP.

Impossible de créer un rattachement de VLAN avec le type de pile IPv4 et IPv6 (double pile)

La création d'un rattachement de VLAN avec le type de pile IPv4 et IPv6 (double pile) échoue avec le message d'erreur suivant :

Cannot create a dual stack interconnect attachment. Dual stack attachment can only be used
with a provisioned interconnect attachments that have Dataplane version 2.

Pour résoudre ce problème :

Consultez le tableau Toutes les installations hébergées en colocation pour connaître les régions compatibles avec la création de rattachements sur Dataplane v2.
Si la région n'est pas répertoriée, recréez le rattachement dans une région compatible.

Impossible de modifier un rattachement de VLAN existant pour utiliser le type de pile IPv4 et IPv6 (double pile)

La mise à jour d'un rattachement de VLAN existant pour utiliser le type de pile IPv4 et IPv6 (double pile) échoue avec le message d'erreur suivant :

Cannot create a dual stack interconnect attachment. Dual stack attachment can only
be used with a provisioned interconnect attachments that have Dataplane version 2.

Pour résoudre ce problème :

Vérifiez la version Dataplane du rattachement et assurez-vous qu'il utilise Dataplane version 1. Consultez la section Vérifier la version Dataplane d'un rattachement.
Recréez le rattachement dans une région compatible avec la création de tous les rattachements sur Dataplane v2. Pour obtenir la liste des régions, consultez la page Toutes les installations hébergées en colocation.

Tester les performances de vos rattachements de VLAN

Si vous devez tester les performances de vos rattachements de VLAN, utilisez une VM dans votre réseau VPC. Ajoutez les outils de performance dont vous avez besoin sur la VM. Évitez de spécifier l'adresse IP de liaison locale du routeur cloud pour effectuer des tests de latence (tels qu'un ping ICMP ou un MTU de chemin d'accès). L'utilisation de Cloud Router peut produire des résultats imprévisibles.

Obtenir des diagnostics

Pour obtenir des informations techniques actualisées et détaillées sur le côté Google Cloud d'une connexion par interconnexion dédiée à la demande, consultez la page Obtenir des diagnostics.

Interconnexion partenaire

La session BGP ne fonctionne pas (connexions de couche 2)

Vérifiez que votre routeur sur site a été configuré avec une session BGP sur vos routeurs cloud. Pour en savoir plus, consultez la section Configurer des routeurs sur site pour l'interconnexion partenaire.
Activez le protocole BGP multi-saut sur votre routeur sur site en utilisant au moins deux sauts.
Vérifiez que la bonne adresse IP voisine est configurée sur votre routeur sur site. Utilisez l'adresse IP du pair BGP (cloudRouterIpAddress) attribuée par le rattachement de VLAN.
Vérifiez que le numéro ASN local sur votre routeur sur site correspond au numéro ASN du pair sur le routeur cloud (16550). En outre, vérifiez que le numéro ASN local sur le routeur cloud correspond au numéro ASN du pair sur votre routeur sur site.

La session BGP ne fonctionne pas (connexions de couche 3)

Votre routeur cloud doit être configuré avec le numéro ASN de votre fournisseur de services. Contactez votre fournisseur de services pour obtenir de l'aide.

Rattachement de VLAN désactivé pour une connexion d'interconnexion partenaire

L'état d'un rattachement de VLAN peut être désactivé, même si la configuration Google Cloud et la connexion d'interconnexion partenaire ne présentent pas de problème.

Assurez-vous d'avoir configuré au moins quatre sauts pour le protocole EBGP multisauts sur votre routeur sur site. Vous pouvez consulter un exemple de configuration dans la section Configurer des routeurs sur site.

Problème de clé d'association dans une connexion d'interconnexion partenaire

Lorsque vous essayez de configurer une connexion d'interconnexion partenaire, vous pouvez obtenir un message d'erreur tel que "Google - État du fournisseur non disponible". Pour résoudre ce problème, procédez comme suit :

Assurez-vous que la clé d'association a été générée par le rattachement de VLAN côté client (type PARTNER). La clé est une longue chaîne aléatoire utilisée par Google pour identifier le rattachement. La région Google Cloud de destination et le domaine de disponibilité de périphérie sont encodés dans la clé d'association au format suivant:
```
<random_string>/<region_name>/<domain>
```
Le champ domain contient la chaîne any si le rattachement de VLAN n'est pas restreint à un domaine particulier ou si vous ne spécifiez pas le domaine de disponibilité de périphérie. Pour en savoir plus sur les clés d'association, consultez la section Clé d'association.
Assurez-vous que le domaine de disponibilité de périphérie de la connexion d'interconnexion partenaire correspond au domaine spécifié par la clé d'association.

Vous ne pouvez pas pinguer Cloud Router (connexions de couche 2)

Vérifiez que la sous-interface du routeur sur site est associée au bon rattachement de VLAN. Les informations de ce rattachement doivent correspondre aux détails fournis par votre fournisseur de services.
Vérifiez que la sous-interface de votre routeur sur site dispose de la bonne adresse IP. Après avoir configuré le rattachement de VLAN, le fournisseur de services attribue une paire d'adresses IP locales de liaison : une pour une interface sur le routeur cloud associé (cloudRouterIpAddress), et l'autre pour une sous-interface sur le canal de port de votre routeur sur site, et non sur le canal de port lui-même (customerRouterIpAddress).
Si vous testez les performances de vos rattachements, ne pinguez pas le routeur cloud. Créez plutôt une VM, puis utilisez-la dans votre réseau VPC. Pour en savoir plus, consultez la section sur les tests de performances.

Perte de la puissance optique sur le port de connexion d'interconnexion partenaire

En cas de perte de puissance optique sur un port, vous pouvez rencontrer l'un des problèmes suivants :

Perte de connectivité de couche 3 (perte d'une session BGP) ou impossibilité d'accéder à vos instances de VM Google Cloud.
Dégradation des performances de votre groupe de liaisons. Ce problème survient si plusieurs ports 10GE sont regroupés et si seuls certains liens d'un groupe fonctionnent.

La perte de puissance optique sur un port signifie que le matériel n'est pas en mesure de détecter un signal en provenance de l'autre extrémité. Cela peut être dû à l'un des problèmes suivants :

Un émetteur-récepteur défectueux
Un système de transport défectueux
Un problème de fibre physique

Pour résoudre ce problème, contactez votre fournisseur d'interconnexion partenaire et/ou de circuits. Ils peuvent effectuer les opérations suivantes :

Vérifier que leur émetteur-récepteur fonctionne.
Exécuter une boucle fixe dans la salle Meet-Me (MMR) pour vérifier si les niveaux de luminosité de leur appareil fonctionnent comme prévu.
Vérifiez si les problèmes sont de leur côté ou de celui de Google. Le meilleur moyen d'isoler l'interface consiste à placer une boucle bidirectionnelle à la démarcation. Les interfaces de chaque côté transmettent la lumière à la démarcation, où elle sera renvoyée en boucle à elle-même. Le côté défectueux sera le côté de la démarcation qui n'est pas net.
Nettoyez et réinstallez toute la fibre du côté défectueux.

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

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.

Le trafic IPv6 est inopérant après avoir fait passer un rattachement en double pile

Affichez l'état du routeur Cloud Router et vérifiez que status: UP s'affiche.

Si BGP n'est pas opérationnel, procédez comme suit :
1. Vérifiez que votre routeur sur site (ou le routeur de votre partenaire, si vous avez recours à un partenaire de couche 3) est configuré avec une session BGP IPv6, et que cette session utilise les bonnes adresses IPv6.
2. Affichez la configuration de la session BGP et vérifiez que bgpPeers.enable affiche 'TRUE' pour votre routeur Cloud Router.
Si BGP est opérationnel, affichez les routes Cloud Router pour vérifier que les routes IPv6 attendues (best_routes) sont bien affichées.

Si ces routes best_routes ne s'affichent pas, vérifiez que votre routeur sur site (ou le routeur de votre partenaire, si vous avez recours à un partenaire de couche 3) est configuré avec les bonnes routes IPv6.

Pour tout autre problème

Adressez-vous à votre fournisseur de services pour obtenir une assistance supplémentaire. Si nécessaire, il contactera Google pour résoudre les problèmes associés au réseau côté Google.

VPN haute disponibilité sur Cloud Interconnect

Lorsque vous déployez un VPN haute disponibilité sur Cloud Interconnect, vous créez deux niveaux opérationnels :

Le niveau Cloud Interconnect, qui inclut les rattachements de VLAN et le routeur Cloud Router pour Cloud Interconnect.
Le niveau VPN haute disponibilité, qui inclut les passerelles et les tunnels VPN haute disponibilité, ainsi que le routeur Cloud Router pour les VPN haute disponibilité.

Chaque niveau nécessite son propre routeur Cloud Router :

Cloud Router pour Cloud Interconnect est utilisé exclusivement pour échanger des préfixes de passerelle VPN entre les rattachements de VLAN. Ce routeur Cloud Router n'est utilisé que par les rattachements de VLAN du niveau Cloud Interconnect. Il ne peut pas être utilisé au niveau du VPN haute disponibilité.
Le routeur Cloud Router pour le VPN haute disponibilité échange des préfixes entre votre réseau VPC et votre réseau sur site. Vous configurez le routeur Cloud Router pour le VPN haute disponibilité et ses sessions BGP de la même manière que pour un déploiement VPN haute disponibilité standard.

Vous créez le niveau VPN haute disponibilité au-dessus du niveau Cloud Interconnect. Par conséquent, le niveau de VPN haute disponibilité nécessite que le niveau Cloud Interconnect, qui repose sur l'interconnexion dédiée ou partenaire, soit correctement configuré et opérationnel.

Pour résoudre un problème de déploiement VPN haute disponibilité via Cloud Interconnect, commencez par résoudre les problèmes liés au niveau d'interconnexion Cloud Interconnect. Après avoir vérifié que Cloud Interconnect fonctionne correctement, dépannez le niveau de VPN haute disponibilité.

Impossible de créer un rattachement de VLAN chiffré

La création du rattachement de VLAN chiffré échoue avec le message d'erreur suivant :

  Cannot create an interconnect attachment with IPSEC encryption.
  IPSEC encryption can only be used with a provisioned interconnect attachments
  that have Dataplane version 2.

Pour résoudre ce problème, procédez comme suit :

Consultez le tableau Toutes les installations hébergées en colocation pour connaître les régions compatibles avec la création de rattachements sur Dataplane v2.
Si la région n'est pas répertoriée, recréez le rattachement dans une région compatible.

Impossible d'établir une session BGP pour le routeur Cloud Router pour Cloud Interconnect

Pour détecter si la session BGP associée au rattachement de VLAN est indisponible, exécutez la commande suivante :

   gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

Remplacez INTERCONNECT_ROUTER_NAME par le nom du routeur Cloud Router que vous avez créé pour le niveau Cloud Interconnect de votre VPN haute disponibilité sur le déploiement Cloud Interconnect.

Pour résoudre ce problème, procédez comme suit :

Suivez les étapes décrites dans les sections Tester les connexions et Obtenir des diagnostics pour vous assurer que la connexion Cloud Interconnect sous-jacente est opérationnelle.
Vérifiez que l'interface de la session BGP pointe vers le rattachement approprié.
Vérifiez les adresses IP configurées pour l'interface de session BGP sur le routeur Cloud ROuter et sur le routeur sur site.
Vérifiez que les numéros ASN sont correctement configurés sur le routeur Cloud Router et le routeur sur site.
Vérifiez que l'état de la connexion Cloud Interconnect et du rattachement de VLAN est défini sur admin-enabled.

Impossible d'établir un tunnel VPN haute disponibilité

Pour vérifier l'état du tunnel, exécutez la commande suivante :

gcloud compute vpn-tunnels describe VPN_TUNNEL_NAME

Remplacez VPN_TUNNEL_NAME par le nom du tunnel VPN haute disponibilité.

Pour résoudre ce problème, procédez comme suit :

Étant donné que le tunnel VPN est acheminé via un rattachement de VLAN, vérifiez que la session BGP associée au rattachement de VLAN est établie. Si ce n'est pas le cas, consultez la section Impossible d'établir une session BGP pour le routeur Cloud pour Cloud Interconnect.
Vérifiez si la clé PSK et les algorithmes de chiffrement sont correctement configurés à la fois sur les passerelles Cloud VPN et sur les passerelles VPN sur site.
Vérifiez que l'annonce BGP du routeur sur site inclut les adresses de passerelle VPN sur site. Si ce n'est pas le cas, ajustez la configuration BGP du routeur sur site pour annoncer les adresses.
Vérifiez que les routes vers les passerelles VPN sur site n'ont pas été supprimées en raison de conflits avec les routes BGP existantes. En cas de conflits, ajustez les adresses de passerelle VPN ou les routes annoncées.
Vérifiez que l'annonce BGP de Cloud Router inclut les adresses de passerelle VPN haute disponibilité. Vérifiez cela à partir du routeur sur site ou en inspectant le champ advertisedRoutes du pair BGP. Pour afficher le champ advertisedRoutes, exécutez la commande suivante :
```
gcloud compute routers get-status INTERCONNECT_ROUTER_NAME
```
Remplacez INTERCONNECT_ROUTER_NAME par le nom du routeur Cloud Router que vous avez créé pour le niveau Cloud Interconnect de votre VPN haute disponibilité sur le déploiement Cloud Interconnect.

Si les adresses de passerelle VPN haute disponibilité ne sont pas annoncées, assurez-vous que les rattachements de VLAN sont associés au routeur Cloud Interconnect chiffré. Vérifiez que chaque rattachement de VLAN est configuré avec les adresses IPv4 internes régionales attendues (--ipsec-internal-addresses).

Impossible d'établir une session BGP pour le routeur Cloud Router pour le VPN haute disponibilité

Pour vérifier si la session BGP associée au rattachement de VLAN est indisponible, exécutez la commande suivante :

gcloud compute routers get-status VPN_ROUTER_NAME

Remplacez VPN_ROUTER_NAME par le nom du routeur Cloud Router que vous avez créé pour le niveau VPN haute disponibilité sur le déploiement Cloud Interconnect.

Pour résoudre ce problème, procédez comme suit :

Étant donné que le trafic BGP est acheminé via le tunnel VPN, vérifiez que celui-ci est établi. Si ce n'est pas le cas, suivez la procédure décrite dans la section Impossible d'établir un tunnel VPN haute disponibilité.
Vérifiez que l'interface de session BGP du routeur Cloud Router pointe vers le tunnel VPN approprié.
Vérifiez que les adresses IP de l'interface de session BGP sont correctement configurées sur le routeur Cloud Router et l'appareil VPN sur site.
Vérifiez que les numéros ASN sont correctement configurés sur le routeur Cloud Router et le routeur sur site.

Le trafic VPC n'atteint pas les réseaux sur site, ou inversement

Le trafic généré à partir d'une VM, tel que ping ou iperf, ne peut pas atteindre le réseau sur site, ou le réseau sur site ne peut pas atteindre le trafic généré à partir d'une VM.

Pour résoudre ce problème, procédez comme suit :

Comme le trafic de VM est acheminé via le tunnel VPN, assurez-vous que la route de la VM vers le tunnel VPN est envoyée par le routeur Cloud Router.
Vérifiez que la session Cloud Router pour le VPN haute disponibilité est établie. Si ce n'est pas le cas, consultez la section Impossible d'établir une session BGP pour le routeur Cloud Router pour les VPN haute disponibilité.

Perte de paquets ou débit faible

Le trafic provenant des VM sur les réseaux VPC vers les réseaux sur site ou le trafic provenant des réseaux sur site vers les réseaux VPC est supprimé.

Vous observez une perte de paquets ou un faible débit via ping, iperf et d'autres outils de surveillance réseau.

Pour résoudre ce problème, procédez comme suit :

Vérifiez si le rattachement de VLAN est surchargé de trafic. Si tel est le cas, répartissez le trafic sur d'autres rattachements de VLAN ou mettez à jour leur capacité.
Vérifiez si le VPN haute disponibilité est surchargé de trafic. Le cas échéant, créez des tunnels VPN supplémentaires sur le rattachement de VLAN pour redistribuer le trafic.
Assurez-vous qu'il n'y a pas de pics de trafic inattendus ou soudains. Les flux TCP peuvent être affectés par d'autres flux, tels que le trafic UDP intensif.
Vérifiez si les paquets qui dépassent la MTU du tunnel sont fragmentés. Vérifiez que la MTU est correctement définie avec vos rattachements de VLAN et que le trafic UDP n'est pas limité par MSS.

Impossible de supprimer un rattachement de VLAN chiffré

Le message d'erreur suivant s'affiche lorsque vous essayez de supprimer un rattachement de VLAN chiffré pour une interconnexion dédiée ou partenaire:

ResourceInUseByAnotherResourceException

Pour résoudre ce problème, assurez-vous d'abord de supprimer toutes les passerelles et tous les tunnels VPN haute disponibilité associés au rattachement de VLAN chiffré. Pour en savoir plus, consultez la section Supprimer un VPN haute disponibilité via Cloud Interconnect.

Types d'adresses IP incompatibles entre les rattachements de VLAN chiffrés

Lorsque vous essayez de créer une passerelle VPN haute disponibilité à utiliser dans un déploiement VPN haute disponibilité via Cloud Interconnect, vous obtenez l'erreur suivante :

One of the VLAN attachments has private IP address type, while the other one
has public IP address type; they must have same IP address type.

Cette erreur se produit lorsque vous spécifiez deux rattachements de VLAN chiffrés pour une passerelle VPN haute disponibilité, et que leurs schémas d'adressage IP sont différents pour les interfaces de tunnel VPN haute disponibilité. Les types d'adresses IP doivent correspondre sur les deux rattachements de VLAN.

Lors de la création d'une passerelle VPN, spécifiez des rattachements de VLAN utilisant à la fois des adresses IP privées ou des adresses IP publiques. Si vous rencontrez cette erreur lors de la création d'une passerelle VPN, essayez de recréer le rattachement de VLAN avec le type d'adresse approprié.

Rattachement de VLAN manquant dans l'interface de passerelle VPN haute disponibilité

Si elle est déployée pour un VPN haute disponibilité via Cloud Interconnect, une passerelle VPN haute disponibilité doit comporter un rattachement de VLAN chiffré pour ses deux interfaces.

Si vous ne spécifiez qu'un seul rattachement de VLAN, l'erreur suivante s'affiche :

VPN Gateway should have VLAN attachment specified in both interfaces or in none.

Pour résoudre ce problème, créez la passerelle VPN haute disponibilité et spécifiez deux rattachements de VLAN.

Type de rattachement de VLAN non valide

Les rattachements de VLAN chiffrés doivent être de type DEDICATED ou PARTNER.

Si vous spécifiez un type non valide pour un rattachement de VLAN chiffré, le message d'erreur suivant s'affiche :

VLAN attachment should have type DEDICATED or PARTNER.

Pour résoudre ce problème, créez uniquement des rattachements de VLAN chiffrés de type DEDICATED ou PARTNER.

Valeur de MTU incorrecte pour un rattachement de VLAN

Lorsque vous créez un rattachement de VLAN chiffré pour une interconnexion dédiée, le message d'erreur suivant s'affiche :

Wrong MTU value [mtuValue] for VLAN attachment.
The supported MTU for IPsec packets for HA VPN over Cloud Interconnect is 1440.

Pour résoudre ce problème, recréez le rattachement avec la valeur correcte 1440, qui est la valeur par défaut.