Découvrez les étapes de dépannage qui pourraient vous être utiles en cas de problème lors de l'utilisation du centre de connectivité réseau, des segments hybrides, des segments VPC et de la propagation de la connexion Private Service Connect.
Pour en savoir plus sur les problèmes connus, consultez la section Remarques de la page "Présentation".
Problèmes courants avec la syntaxe de commande
Lorsque vous mettez à jour un spoke, vous devez spécifier l'emplacement dans lequel il se trouve.
Associer des ressources aux spokes
Pour plus d'informations sur les exigences, les recommandations et les éléments à prendre en compte pour créer des spokes et y associer des ressources, consultez la section Créer un spoke.
Les routes ne sont pas réparties entre les régions
Si les routes ne sont pas réparties correctement entre les régions, vérifiez que le mode de routage dynamique du réseau VPC est défini sur global
.
Data transfer traffic doesn't flow between two non-Google Cloud networks
In this context, a non-Google Cloud network refers to your on-premises data center, a branch office, or another cloud provider's network.
Si le trafic de transfert de données ne se situe pas entre deux emplacements, vérifiez que les ressources suivantes sont correctement configurées et fonctionnent :
- Vérifiez le fonctionnement des tunnels VPN haute disponibilité ou des rattachements de VLAN qui sont ajoutés en tant que spokes.
- Vérifiez les routes programmées entre les deux emplacements.
- Vérifiez que les attributions ASN sont configurées comme décrit dans la section Exigences ASN pour les ressources Spoke.
- Vérifiez que le champ de transfert de données de site à site est défini sur
true
pour chaque spoke.
Annonces de routage en double à partir de sessions BGP
S'il existe des annonces de routage en double (certaines provenant de sessions BGP participant au transfert de données et d'autres de sessions ne participant pas au transfert de données), le trafic de transfert de données peut utiliser ECMP pour distribuer le trafic à tous les sauts suivants disponibles, même si ces sauts suivants ne participent pas explicitement au transfert de données.
Interconnect connection to an unsupported location (non-Google Cloud network)
Pour obtenir un exemple de configuration des annonces de routage lorsqu'une de vos connexions par interconnexion redondantes est adressée à un emplacement non compatible, consultez la section Annonce de routage optimale pour Network Connectivity Center.
Résoudre les problèmes de connectivité réseau à l'aide de Tests de connectivité
Les tests de connectivité se présentent comme un outil de diagnostic qui vous permet de vérifier la connectivité entre les points de terminaison de votre réseau. Cet outil analyse votre configuration et, dans certains cas, procède à la vérification de l'exécution.
Pour analyser les configurations réseau, Tests de connectivité simule le chemin de transfert attendu d'un paquet via votre réseau cloud privé virtuel (VPC), vos tunnels Cloud VPN, vos rattachements de VLAN ou vos instances de routeur.
Vous pouvez utiliser l'analyse de configuration "Tests de connectivité" pour évaluer la joignabilité entre :
- Deux réseaux non-Google Cloud connectés via Network Connectivity Center. Dans ce contexte, un réseau autre que Google Cloud est généralement votre centre de données sur site, une filiale ou le réseau d'un autre fournisseur cloud.
- Deux réseaux VPC connectés via un hub Network Connectivity Center.
Étant donné que Tests de connectivité n'a pas accès à votre configuration réseau sur site, il ne peut pas vérifier la configuration des routes et des règles de pare-feu sur votre routeur sur site. Ainsi, le trafic de votre réseau sur site à votre réseau VPC est toujours considéré comme valide par l'analyse de la configuration de Tests de connectivité, et seules les configurations de Google Cloud sont validées.
Pour exécuter Tests de connectivité entre deux réseaux sur site connectés via Network Connectivity Center, consultez la section Exécuter Tests de connectivité.
Pour en savoir plus, consultez la présentation de Tests de connectivité.
Troubleshoot Router appliance
Les solutions et problèmes suivants sont propres à l'appareil de routeur.
La documentation sur le dépannage de Cloud Router s'applique également à l'appareil de routeur, ainsi qu'aux problèmes décrits dans les sections suivantes.
Pour en savoir plus, consultez les ressources suivantes :
- Résoudre les problèmes liés aux sessions BGP
- Résoudre les problèmes liés à l'appairage BGP
- Résoudre les problèmes liés aux routes BGP et à la sélection des routes
- Résoudre les problèmes liés aux messages de journal Cloud Router
Échec de l'établissement de sessions BGP
Si vous ne parvenez pas à établir des sessions BGP entre Cloud Router et l'appareil de routeur, vérifiez les points suivants :
- Assurez-vous qu'une VM agissant en tant qu'instance d'appareil de routeur est configurée dans le cadre d'un spoke dans le Network Connectivity Center. Pour configurer une instance d'appareil de routeur dans le cadre d'un spoke, consultez la section Utiliser des spokes.
- Vérifiez les paramètres de votre pare-feu pour vous assurer que le port TCP
179
est autorisé. Pour configurer les paramètres de pare-feu pour l'appareil de routeur, consultez la section Créer des instances d'appareils de routeur. - Veillez à ce que ni l'instance Cloud Router ni l'instance de votre appareil de routeur n'utilisent des adresses de liaison locale (c'est-à-dire
169.254.x.x
) pouvant s'appairer. Pour plus d'informations, consultez les recommandations pour l'allocation d'adresses IP. - Assurez-vous que Cloud Router a établi deux sessions BGP distinctes pour votre instance d'appareil de routeur, l'une dans chaque interface Cloud Router. L'instance d'appareil de routeur doit annoncer les mêmes routes sur les deux sessions BGP. Si l'une de vos sessions BGP est interrompue et que la VM d'appareil de routeur perd la communication avec Cloud Router, vérifiez la configuration de vos interfaces Cloud Router. Pour en savoir plus, consultez la page Créer des instances d'appareils de routeur.
Problèmes liés aux adresses IP internes pour les sessions BGP sur les instances d'appareils de routeur
Si vous rencontrez des problèmes liés à la configuration des adresses IP pour les instances d'appareils de routeur, assurez-vous d'avoir configuré des adresses IP internes RFC 1918 pour les sessions BGP entre Cloud Router et les VM agissant en tant qu'instances d'appareils de routeur.
Les instances d'appareils de routeur n'utilisent pas les adresses 169.254.x.x
pour les sessions BGP. À la place, elles doivent utiliser les adresses IP figurant dans le même sous-réseau VPC que le routeur Cloud Router. Pour plus d'informations, consultez la page Créer des instances d'appareils de routeur.
Résoudre les problèmes liés aux spokes VPC
Autorisations
If permission is denied when creating a spoke in a different project from the
hub, check with the hub administrator to confirm
that you have been granted the required networkconnectivity.groups.use
permission on the hub.
Échecs de création de spokes VPC
Si la création de votre spoke VPC a échoué, cela peut être dû à l'une des raisons suivantes :
- Le réseau VPC est déjà appairé avec un ou plusieurs des satellites existants à l'aide de l'appairage de réseaux VPC.
- Subnets overlap with existing VPC spokes.
- Les sous-réseaux chevauchent les appairages des spokes VPC existants.
- Vous avez dépassé le quota de liens VPC.
- Vous avez dépassé le quota de routes par hub pour la table de routage.
- Vous avez spécifié plus de 16 filtres d'exportation.
- Subnets in the VPC network are larger than one or more filters specified.
Pour les erreurs liées aux quotas, consultez la page Quotas et limites.
Échecs de création d'un spoke VPC après la suppression d'un spoke
Après avoir supprimé un spoke, les périodes d'attente suivantes s'appliquent :
- Vous devez attendre un intervalle d'au moins 10 minutes avant de créer un spoke pour le même réseau VPC associé au même hub.
- Pour un nouveau spoke pour le même réseau VPC associé à un autre hub, la période d'attente à respecter est d'au moins 24 heures.
- Il est possible que les filtres de création d'un spoke pour le même réseau VPC ne soient pas appliqués correctement. La solution consiste à supprimer le spoke, à attendre un délai plus long, puis à recréer le spoke.
Échecs de création de sous-réseau dans un spoke VPC
Si vous rencontrez un échec de création de sous-réseau dans un spoke VPC, cela peut être dû à l'une des raisons suivantes :
- Il existe des sous-réseaux qui se chevauchent dans d'autres spokes VPC ou des pairs de spokes VPC.
- Vous avez dépassé le quota de routes par hub pour la table de routage.
- Les sous-réseaux du réseau VPC sont plus volumineux qu'un ou plusieurs filtres spécifiés.
Le spoke VPC est créé, mais la connectivité du plan de données est manquante
If your VPC spoke is showing as created, but dataplane connectivity is missing, it could be due to one of the following reasons:
- The spoke is in a different project from the hub and the hub administrator has not accepted the spoke proposal.
- All subnets in the VPC network are filtered and excluded from connectivity.
- Les sous-réseaux de destination sont filtrés en fonction des filtres de spoke VPC correspondants.
La table de routage de hub n'affiche pas certains sous-réseaux dans les spokes VPC
Si votre table de routage de hub n'affiche pas certains sous-réseaux dans les spokes VPC, cela peut être dû à l'une des raisons suivantes :
- The subnets are filtered using export filters.
- Les sous-réseaux ont été créés au cours des 5 à 10 dernières minutes, et la table de routage du hub n'a pas encore été actualisée.
La VM d'un rayon ne peut pas accéder à la connexion Private Service Connect d'un autre rayon
If a VM in one VPC spoke can't access the Private Service Connect endpoint (Preview) in another spoke, check for the following issues:
Assurez-vous que la connexion Private Service Connect cible un rattachement de service basé sur un point de terminaison Private Service Connect d'équilibreur de charge réseau passthrough interne. Pour en savoir plus, consultez À propos de l'accès aux services publiés via des points de terminaison.
To get data associated with a forwarding rule in a project, use the
gcloud compute forwarding-rules describe
command.gcloud
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \ --region=REGION_ID --project=PROJECT_ID --format='get(target)'
Remplacez les valeurs suivantes :
FORWARDING_RULE_NAME
: nom de la règle de transfert.REGION_ID
: ID de la régionPROJECT_ID
: ID du projet dans lequel se trouve la règle
Assurez-vous que le champ
--export_psc
est activé dans le hub.To check if the
--export_psc
field is enabled in the hub, use thegcloud network-connectivity hubs describe
command.gcloud
gcloud network-connectivity hubs describe HUB_NAME \ --project=PROJECT_ID --format='get(export_psc)'
Remplacez les valeurs suivantes :
HUB_NAME
: nom du hubPROJECT_ID
: ID du projet où se trouve le hub
Verify that the address of the Private Service Connect endpoint is not in any export exclude range of the hosting spoke. Private Service Connect endpoints that reside within the export exclude range are not propagated.
To check the specified exclude export ranges of a spoke, use the
gcloud network-connectivity spokes describe
command.gcloud
gcloud network-connectivity spokes describe SPOKE_NAME \ --global \ --project=PROJECT_ID \ --format='get(linked_vpc_network.exclude_export_ranges)'
Remplacez les valeurs suivantes :
SPOKE_NAME
: le nom du spokePROJECT_ID
: the project ID where the spoke resides
Make sure that you have not exceeded the Network Connectivity Center usage quota.
Message d'erreur
Si vous essayez de créer un rayon et que vous recevez le message d'erreur An
internal
error occurred
, contactez l'assistance Google Cloud pour obtenir de l'aide.