Troubleshoot Network Connectivity Center

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 spokes hybrides, des spokes VPC, des spokes de passerelle NCC ou de la propagation des connexions Private Service Connect.

Pour en savoir plus sur les limites connues, consultez la section Remarques concernant Network Connectivity Center sur la page de 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 Utiliser des spokes.

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.

Absence de trafic de transfert de données entre deux réseaux nonGoogle Cloud

Dans ce contexte, un réseau non-Google Cloud fait référence à votre centre de données sur site, à une filiale ou au réseau d'un autre fournisseur de services cloud.

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 :

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 Configurer un routeur externe pour éviter les emplacements non compatibles.

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

Vous pouvez utiliser l'analyse de configuration Tests de connectivité pour évaluer la joignabilité des réseaux suivants :

É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 Tester la connectivité d'un réseau non-Google Cloud vers un réseau non-Google Cloud .

Pour en savoir plus, consultez la présentation de Tests de connectivité.

Résoudre les problèmes liés aux spokes hybrides

Le problème suivant peut se produire dans les appareils de routeur, les rattachements de VLAN et les spokes de VPN.

Les sous-réseaux de hub configurés ne sont pas annoncés sur un réseau sur site

Si les sous-réseaux de hub configurés ne sont pas annoncés sur le réseau sur site, vérifiez que le tableau de routage du hub du groupe de spokes hybrides ne présente pas les problèmes suivants :

  • Si les sous-réseaux s'affichent dans la table de routage du hub, procédez comme suit :

  • Si les sous-réseaux ne figurent pas dans la table de routage du hub, procédez comme suit :

    • Vérifiez les plages d'adresses IP d'exportation incluses et exclues sur le spoke VPC des sous-réseaux. Si le sous-réseau est filtré par des plages d'exportation à inclure ou à exclure, vous pouvez mettre à jour le spoke VPC.

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 :

É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'appliance 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 Adresses IP et instances d'appliance de routeur.
  • 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 en savoir plus, consultez 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é à un ou plusieurs spokes existants à l'aide de l'appairage de réseaux VPC.
  • Subnets overlap with existing VPC spokes.
  • Les sous-réseaux chevauchent les pairs des spokes VPC existants.
  • Vous avez dépassé le quota de spokes VPC.
  • Vous avez dépassé le quota de routes par hub pour la table de routage.
  • Plus de 16 filtres d'exportation sont spécifiés.
  • 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, vous devez respecter une période d'attente d'au moins 10 minutes avant de pouvoir créer un spoke pour le même réseau VPC associé à un autre hub. Cette période d'attente n'est pas nécessaire si le réseau VPC est ajouté en tant que spoke au même hub.

É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 :

  • Des sous-réseaux se chevauchent dans d'autres spokes VPC ou pairs de spokes VPC.
  • Vous avez dépassé le quota de routes par hub pour la table de routage.
  • Subnets in the VPC network are larger than one or more filters specified.

The VPC spoke is created but dataplane connectivity is missing

If your VPC spoke is showing as created, but dataplane connectivity is missing, it could be due to one of the following reasons:

  • Le spoke se trouve dans un projet différent du hub et l'administrateur du hub n'a pas accepté la proposition de spoke.
  • 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.

Échec de la mise à jour du spoke VPC

Assurez-vous que les mises à jour de vos spokes respectent tous les quotas et limites de Network Connectivity Center. Sinon, la mise à jour du spoke échouera.

Si un spoke VPC ou un spoke VPC producteur se trouve dans un projet différent de celui contenant le hub, et si un administrateur de hub n'a pas activé l'acceptation automatique des propositions provenant du projet de spoke, un administrateur de hub doit accepter ou refuser une mise à jour proposée. Pour savoir comment vérifier l'état de la proposition de mise à jour du spoke, consultez Vérifier l'état d'un spoke VPC.

Résoudre les erreurs de propagation de connexion Private Service Connect

Avant de vous pencher sur les problèmes, familiarisez-vous avec les pages suivantes :

VM in one spoke can't access the Private Service Connect connection in another spoke

Si une VM d'un VPC spoke ne parvient pas à accéder au point de terminaison Private Service Connect d'un autre spoke, assurez-vous que les conditions suivantes sont remplies :

  • Le champ --export_psc est activé dans le hub.

    To check if the --export_psc field is enabled in the hub, use the gcloud 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 hub
    • PROJECT_ID : ID du projet dans lequel réside le hub

  • L'adresse IP du point de terminaison Private Service Connect ne figure dans aucune plage d'exclusion d'exportation du spoke d'hébergement. Les points de terminaison Private Service Connect qui se trouvent dans la plage d'exclusion d'exportation ne sont pas propagés.

    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 spoke
    • PROJECT_ID: the project ID where the spoke resides

  • Vous n'avez pas dépassé le quota d'utilisation de Network Connectivity Center.

  • Le psc_connection_status du point de terminaison est à l'état ACCEPTED. Pour en savoir plus sur les états de connexion, consultez États de connexion.

  • L'état de la connexion propagée du point de terminaison dans le spoke contenant la VM est READY. Si aucun état ne s'affiche, consultez les raisons dans la section Vous ne voyez pas l'état de certains rayons cibles de cette page. Vous pouvez vérifier l'état de la connexion propagée à l'aide de la commande gcloud network-connectivity hubs query-status :

    gcloud

    gcloud network-connectivity hubs query-status HUB_NAME\
    --filter='psc_propagation_status.source_spoke="SOURCE_SPOKE_NAME" AND psc_propagation_status.target_spoke="TARGET_SPOKE_NAME" AND psc_propagation_status.source_forwarding_rule="ENDPOINT_NAME"

    Remplacez les valeurs suivantes :

    • HUB_NAME : nom du hub pour lequel vous souhaitez vérifier l'état de propagation de la connexion
    • SOURCE_SPOKE_NAME : nom du spoke source
    • TARGET_SPOKE_NAME : nom du spoke cible
    • ENDPOINT_NAME : nom du point de terminaison.

    Pour en savoir plus sur l'utilisation de ces indicateurs, consultez la page de la commande gcloud network-connectivity hubs query-status.

  • Le réseau VPC hôte du point de terminaison Private Service Connect (source) est un spoke VPC dans le hub.

  • L'adresse IP du point de terminaison Private Service Connect est une adresse RFC 1918.

Vous avez épuisé le quota de producteur

Si le message d'erreur PRODUCER_QUOTA_EXHAUSTED s'affiche, vous pouvez demander au producteur de services de demander une augmentation du quota PSC_ILB_CONSUMER_FORWARDING_RULES_PER_PRODUCER_NETWORK. Pour en savoir plus, consultez la section Par réseau de la documentation sur le VPC.

Vous avez dépassé la limite de connexions propagées du producteur

Si vous voyez un message d'erreur indiquant que vous avez dépassé la limite de connexions propagées d'un rattachement de service, vous pouvez demander au producteur de services d'augmenter la limite. Lorsqu'un producteur de services met à jour la limite de connexions propagées, Google Cloud vérifie automatiquement si des connexions propagées en attente peuvent être créées.

L'espace d'adresses IP NAT du producteur est épuisé

Si le message d'erreur PRODUCER_NAT_IP_SPACE_EXHAUSTED s'affiche, cela signifie que vous devrez peut-être demander au producteur de services d'ajouter des sous-réseaux NAT. Pour savoir comment ajouter des sous-réseaux, consultez Ajouter ou supprimer des sous-réseaux d'un service publié.

Vous avez épuisé le quota du client

Si le message d'erreur CONSUMER_QUOTA_EXHAUSTED s'affiche, contactez le propriétaire du réseau VPC consommateur et demandez une augmentation du quota PSC_PROPAGATED_CONNECTIONS_PER_VPC_NETWORK.

Vous ne pouvez pas voir l'état de certains spokes cibles

Si l'état de certains spokes cibles ne s'affiche pas, cela peut être dû à l'une des raisons suivantes :

  • Le spoke cible n'est pas un spoke VPC. Seuls les spokes VPC, y compris les réseaux VPC qui sont des spokes VPC et qui contiennent également des spokes hybrides, peuvent recevoir des connexions propagées. Un spoke hybride dans un réseau VPC de routage qui n'est pas également un spoke VPC ne peut pas recevoir de connexions propagées.

  • Network Connectivity Center n'affiche l'état de propagation que pour chaque spoke VPC. Si un réseau VPC est à la fois un spoke VPC et contient des spokes hybrides, vérifiez l'état de propagation de son spoke VPC pour déterminer si les spokes hybrides contenus ont une connectivité aux points de terminaison Private Service Connect propagés.

  • Si un réseau VPC est à la fois le réseau VPC de producteur Private Service Connect et un spoke VPC sur un hub qui propage ses points de terminaison, Network Connectivity Center ne propage pas ses points de terminaison vers le réseau VPC de producteur lui-même.

  • La propagation n'est pas autorisée par la topologie du hub. Par exemple, si le hub est configuré pour utiliser la topologie en étoile, les conditions suivantes sont également remplies :

    • Les points de terminaison Private Service Connect du groupe central sont propagés à tous les autres spokes VPC.
    • Les points de terminaison Private Service Connect du groupe Edge ne sont propagés qu'aux spokes VPC du groupe Center.

Résoudre les problèmes d'échange de routes des spokes VPC

Des spokes VPC et hybrides sont associés au même hub, mais la connectivité du plan de données est manquante

Si les spokes VPC et les spokes hybrides sont associés au même hub, mais que la connectivité du plan de données est manquante, cela peut être dû à l'une des raisons suivantes :

  • Le spoke est un spoke interprojet et l'administrateur du hub n'a pas accepté la proposition de spoke.
  • Tous les sous-réseaux du réseau VPC sont filtrés et exclus de la connectivité.
  • La propagation automatique des sous-réseaux VPC n'est pas activée ou la publicité des routes personnalisées n'est pas configurée.
  • Le quota de routes dynamiques est épuisé.

La table de routage de hub n'affiche pas certaines routes dynamiques ou en affiche des superflues

Il est possible que la table de routage du hub n'affiche pas correctement les routes dynamiques pour l'une des raisons suivantes :

  • Des routes BGP ont été annoncées ou retirées au cours des cinq à dix dernières minutes, et la table de routage du hub n'a pas encore été mise à jour.
  • Le quota de routes dynamiques est épuisé.

Échec de la création d'un spoke hybride

Si la création d'un spoke hybride échoue, cela peut être dû à l'une des raisons suivantes :

  • Le réseau VPC de routage peut être un spoke VPC existant vers le même hub ou un autre hub.
  • Le réseau VPC de routage peut être associé implicitement à un autre hub en raison d'un spoke hybride existant connecté à ce hub. Les associations hybrides d'un réseau VPC ne peuvent devenir des spokes que pour un seul hub.

Échec de la création d'un spoke VPC

La création d'un spoke VPC peut échouer si le spoke VPC est implicitement associé à un hub en tant que réseau VPC de routage.

Message d'erreur

Si vous essayez de créer un spoke et que le message d'erreur An internal error occurred s'affiche, contactez l'assistanceGoogle Cloud pour obtenir de l'aide.

Résoudre les problèmes liés aux spokes de passerelle NCC

Vous pouvez afficher les services et les routeurs connectés à votre passerelle NCC à l'aide de la commande gcloud network-connectivity spokes describe sur la ressource spoke de la passerelle NCC.

gcloud

  gcloud network-connectivity spokes describe SPOKE_NAME \
      --region REGION

Remplacez les éléments suivants :

  • SPOKE_NAME : nom du spoke de passerelle NCC
  • REGION : région dans laquelle se trouve le spoke

Le résultat ressemble à ce qui suit :

createTime: '2022-11-25T06:06:11.572019860Z'
hub: projects/PROJECT/locations/REGION/hubs/HUB
gateway:
  ipRangeReservation: 10.1.2.0/24
  asn: 65123
  routers:
    projects/PROJECT/locations/REGION/routers/ROUTER

name: projects/PROJECT/locations/REGION/spokes/SPOKE
state: ACTIVE
uniqueId: 8ca10af0-ee69-43c2-b0b4-61e8f53d410b
updateTime: '2023-12-27T21:26:47.786506888Z'

Vous pouvez afficher la table de routage VPC de l'application et la route de table de routage de hub créée qui est propagée à votre table de routage VPC avec le hub comme saut suivant à l'aide de la commande gcloud compute routes list :

gcloud

  gcloud compute routes list \
      --filter="network=NETWORK"

Remplacez NETWORK par le nom du réseau VPC.

Le résultat ressemble à ce qui suit :

NAME                                                  NETWORK  DEST_RANGE    NEXT_HOP  PRIORITY
ncc-static-route-7296f3a4-cdc2-4560-a905-95cdb1d6833e  vpc-1    17.0.0.0/8   hub       0

Vous pouvez afficher la table de routage du hub pour le groupe de spokes et voir la même route créée pointant vers le spoke NCC Gateway à l'aide de la commande gcloud network-connectivity hubs route-tables routes list :

gcloud

  gcloud network-connectivity hubs route-tables routes list --hub=HUB_NAME \
      --route_table

Remplacez HUB_NAME par le nom du hub.

La table de routage de hub n'affiche pas les routes annoncées de passerelle

Si votre table de routage de hub n'affiche pas certaines des routes annoncées par la passerelle avec le spoke de passerelle comme prochain saut, cela peut être dû au fait que les routes ne sont pas installées dans le plan de données. Cela peut entraîner des problèmes de connectivité entre les spokes VPC et les applications sur site connectées via le spoke de passerelle NCC. Essayez de supprimer et de créer des routes annoncées de passerelle en procédant comme suit :

  1. Supprimer la route annoncée
  2. Créer une route annoncée de passerelle NCC

  3. Affichez la route annoncée associée à la passerelle NCC à l'aide de la commande gcloud beta network-connectivity spokes gateways advertised-routes list :

    gcloud

    gcloud beta network-connectivity spokes gateways advertised-routes list
    --region=REGION

    Remplacez REGION par la région dans laquelle se trouve le spoke.

  4. Vérifiez la route annoncée de la passerelle dans la table de routage du hub à l'aide de la commande gcloud network-connectivity hubs route-tables list :

    gcloud

    gcloud network-connectivity hubs route-tables list \
    --hub=HUB_NAME

    Remplacez HUB_NAME par le nom du hub pour lequel vous souhaitez lister la table de routage.

    Le résultat renvoyé ressemble à ceci : Une entrée pour la route annoncée par votre passerelle doit figurer dans le résultat.

    gcloud  network-connectivity hubs route-tables routes list --hub=HUB_NAME --route_table PROD
IP_CIDR_RANGE  STATE    TYPE      NEXT_HOP   HUB       ROUTE_TABLE     PRIORITY
10.0.0.0/8     ACTIVE   NCC_GW    NCC-GW-1   HUB_NAME  PROD            100

Pour les problèmes liés à Cloud Router, consultez Résoudre les problèmes liés aux messages de journal Cloud Router.

Pour les problèmes liés à Cloud Interconnect, consultez la page de dépannage de Cloud Interconnect.