Présentation des spokes VPC

Cette page présente la prise en charge des spokes de cloud privé virtuel (VPC) dans Network Connectivity Center.

Spokes VPC

Network Connectivity Center fournit une connectivité réseau inter-VPC à grande échelle, compatible avec les spokes VPC. Les spokes VPC réduisent la complexité des opérations de gestion des connexions d'appairage individuelles entre deux réseaux VPC grâce à l'utilisation de spokes VPC et d'un modèle de gestion centralisée de la connectivité. Les spokes VPC peuvent exporter et importer toutes les routes de sous-réseau à partir d'autres spokes VPC sur un hub Network Connectivity Center. Cela garantit une connectivité complète entre toutes les charges de travail qui se trouvent dans ces réseaux VPC. Le trafic réseau inter-VPC reste à l'intérieur du réseau Google Cloud et ne transite pas par Internet, ce qui contribue à garantir la confidentialité et la sécurité.

Les spokes VPC peuvent se trouver dans le même projet et la même organisation, ou dans un projet et une organisation différents du hub Network Connectivity Center. Un spoke VPC ne peut être connecté qu'à un seul hub à la fois.

Pour en savoir plus sur la création d'un spoke VPC, consultez la section Créer un spoke VPC.

Comparaison avec l'appairage de réseaux VPC

Les spokes VPC répondent aux exigences des entreprises moyennes et grandes en fournissant une connectivité de route de sous-réseau IPv4 et IPv6, ainsi qu'une connectivité de route dynamique IPv4 à l'aide de spokes hybrides.

Un réseau VPC peut être à la fois un spoke VPC Network Connectivity Center et être connecté à un autre réseau VPC à l'aide de l'appairage de réseaux VPC, à condition que le réseau VPC appairé ne soit pas lui-même un spoke VPC.

Lorsque vous utilisez des spokes VPC Network Connectivity Center et l'appairage de réseaux VPC, gardez à l'esprit les points suivants :

Fonctionnalité Appairage de réseaux VPC Spokes VPC
Réseaux VPC

Appairages par réseau VPC

Spokes VPC actifs par hub

Plages de sous-réseaux (routes de sous-réseau)

Plages de sous-réseaux par groupe d'appairage

Routes de sous-réseau par table de routage

Routes statiques et dynamiques

Routes statiques par groupe d'appairage

Routes dynamiques par région et par groupe d'appairage

Préfixes de routes dynamiques uniques par table de routage de hub et par région.

L'échange de route statique n'est pas accepté.

Filtres d'exportation

Les filtres spécifiques ne sont pas acceptés. Consultez la section Options d'échange de routage dans la documentation sur l'appairage de réseaux VPC.

Jusqu'à 16 plages CIDR acceptées par spoke VPC.

Inter-VPC NAT

Non compatible

Compatible

Propagation de la connexion Private Service Connect

Non compatible

Compatible

Connectivité des spokes VPC de producteur à partir d'autres réseaux VPC

Non compatible

Compatible

Adressage IP

Adresses IPv4 internes, y compris les adresses IPv4 privées et les adresses IPv4 publiques utilisées en mode privé. Consultez la section Plages IPv4 valides.

Adresses IPv6 internes et externes.

Adresses IPv4 internes privées uniquement, à l'exclusion des adresses IPv4 publiques utilisées en mode privé. Consultez la section Plages IPv4 valides.

Adresses IPv6 internes et externes.
Familles d'adresses IP Configurations compatibles :
  • Échanger uniquement des plages de sous-réseaux IPv4
  • Échanger des plages de sous-réseaux IPv4 et IPv6
 Configurations compatibles :
  • Échanger uniquement des plages de sous-réseaux IPv4
  • Échanger des plages de sous-réseaux IPv4 et IPv6
  • Échanger uniquement des plages de sous-réseaux IPv6
Performances et débit (par rapport à d'autres mécanismes de connectivité VPC)

Latence la plus faible, débit le plus élevé (équivalent VM à VM)

Latence la plus faible, débit le plus élevé (équivalent VM à VM)

Spokes VPC dans un projet différent d'un hub

En utilisant Network Connectivity Center, vous pouvez associer des réseaux VPC, représentés par des spokes VPC, à un seul hub dans un autre projet, y compris un projet d'une autre organisation. Cela vous permet de connecter vos réseaux VPC à plusieurs projets et organisations à grande échelle.

Vous pouvez utiliser les types d'utilisateurs suivants :

  • Administrateur de hub propriétaire d'un hub dans un projet
  • Un administrateur de spoke dans un réseau VPC ou un administrateur réseau qui souhaite ajouter son réseau VPC dans un autre projet en tant que spoke vers le hub

L'administrateur du hub contrôle qui peut créer un spoke VPC dans un autre projet associé à son hub à l'aide des autorisations IAM (Identity and Access Management). L'administrateur de spoke dans le réseau VPC crée un spoke dans un projet différent du hub. Ces spokes sont inactifs lors de leur création. L'administrateur du hub doit les examiner, et peut accepter ou refuser le spoke. Si l'administrateur du hub accepte le spoke, celui-ci devient actif.

Network Connectivity Center accepte toujours automatiquement les spokes créés dans le même projet que le hub.

Pour en savoir plus sur la gestion des hubs comportant des spokes VPC dans un projet différent du hub, consultez la section Présentation de l'administration de Hub. Pour obtenir des informations détaillées concernant les administrateurs de spoke, consultez la section Présentation de l'administration de Spoke.

Interaction du spoke avec VPC Service Controls

Network Connectivity Center est compatible avec VPC Service Controls pour les spokes inter-projets et inter-organisations. Pour un spoke dans un projet différent du hub, lorsqu'un nouveau périmètre VPC Service Controls est ajouté, vous ne pouvez pas ajouter de spokes qui ne respectent pas le périmètre. Toutefois, les spokes existants que vous avez ajoutés avant d'ajouter le périmètre VPC Service Controls continuent de fonctionner.

Connectivité VPC avec filtres d'exportation

Network Connectivity Center vous permet de limiter la connectivité de tous les spokes de réseaux VPC à un sous-ensemble de sous-réseaux dans le VPC du spoke. Vous pouvez limiter la connectivité comme suit :

  • Vous pouvez configurer le spoke pour qu'il diffuse toutes ses plages de sous-réseaux ou aucune.
  • Vous pouvez modifier les plages d'adresses de sous-réseau exportées (aperçu).
  • Vous pouvez spécifier des plages d'adresses à ne pas annoncer et établir une liste de plages CIDR pouvant être annoncées à partir du réseau VPC. Vous pouvez également spécifier uniquement une liste de plages CIDR autorisées, ce qui bloque toutes les plages, à l'exception des plages autorisées.

Vous pouvez utiliser des filtres d'exportation pour configurer les spokes VPC afin qu'ils n'échangent que des plages de sous-réseaux IPv4, que des plages de sous-réseaux IPv6 ou les deux. Prenons l'exemple d'un spoke dont le réseau VPC comporte différents types de pile de sous-réseau. Si vous configurez le spoke pour qu'il n'exporte que les plages de sous-réseaux IPv6, les plages IPv6 des sous-réseaux à double pile et IPv6 uniquement sont échangées, mais pas les plages de sous-réseaux IPv4 des sous-réseaux IPv4 uniquement et à double pile.

Exclure des plages d'exportation

Vous pouvez empêcher l'annonce d'une plage d'adresses IP à l'aide de l'option --exclude-export-ranges dans Google Cloud CLI ou du champ excludeExportRanges dans l'API. Toutes les plages d'adresses IP correspondant à la plage spécifiée sont exclues de l'exportation vers le hub. Ce filtrage est utile lorsque vous disposez de sous-réseaux qui doivent être privés dans le réseau VPC ou qui sont susceptibles de chevaucher d'autres sous-réseaux de la table de routage du hub.

Inclure les plages d'exportation

Vous pouvez définir les plages d'adresses IP autorisées à être annoncées à partir d'un spoke VPC à l'aide de l'option --include-export-ranges ou du champ includeExportRanges dans l'API. Vous pouvez spécifier les éléments suivants :

  • Pour annoncer toutes les plages de sous-réseaux IPv4, vous pouvez spécifier ALL_PRIVATE_IPV4_RANGES.
  • Pour n'annoncer que des plages de sous-réseaux spécifiques, vous pouvez spécifier une liste de plages CIDR.
  • Pour annoncer toutes les plages de sous-réseaux IPv6, vous pouvez spécifier ALL_IPV6_RANGES.

Établissez une connectivité plus précise en utilisant un filtre d'exportation d'inclusion en plus du filtre d'exportation d'exclusion. Ce filtrage détermine si une plage de sous-réseau spécifique peut être annoncée à partir du réseau VPC.

Remarques

Tenez compte des points suivants lorsque vous utilisez les filtres d'exportation de plages d'exclusion et d'inclusion :

  • Les plages d'inclusion doivent être exclusives les unes des autres, ce qui signifie qu'elles ne doivent pas se chevaucher. Par exemple, supposons qu'il existe trois plages d'adresses IPv4 :

    Plage 1 : 10.100.64.0/18

    Plage 2 : 10.100.250.0/21

    Plage 3 : 10.100.100.0/22

    Les plages 1 et 2 sont des plages d'inclusion valides, car elles ne se chevauchent pas. Toutefois, la plage 3 est contenue dans la plage 1. Elle n'est donc pas valide.

    Si vous utilisez IPv6, supposons que vous disposez des trois plages d'adresses IPv6 suivantes :

    Plage 1 : 2001:db8::/32

    Plage 2 : 2001:db9::/32

    Plage 3 : 2001:db8:1000::/48

    Les plages 1 et 2 sont des plages d'inclusion valides, car elles ne se chevauchent pas. Toutefois, la plage 3 est contenue dans la plage 1. Elle n'est donc pas valide.

  • Étant donné que Network Connectivity Center dispose déjà de filtres d'exportation d'exclusion disponibles dans la règle de configuration réseau, les filtres d'exportation d'inclusion et d'exclusion affectent les plages CIDR des configurations réseau valides. Lorsque des filtres d'exportation d'inclusion et d'exclusion sont utilisés, les plages d'adresses IP d'inclusion doivent être un sur-ensemble des plages d'adresses IP d'exclusion.

  • Si vous ne spécifiez pas de filtre d'inclusion lorsque vous créez le spoke VPC, Network Connectivity Center définit la plage d'inclusion par défaut sur toutes les adresses IPv4 privées valides, comme défini dans Plages IPv4 valides.

  • Pour affiner une plage d'inclusion, vous pouvez ajouter plusieurs plages d'exclusion. Par exemple, si vous spécifiez 10.1.0.0/16 en tant que plage d'inclusion et 10.1.100.0/24 et 10.1.200.0/24 en tant que plages d'exclusion, le résultat est une connectivité affinée avec la combinaison des filtres d'inclusion et d'exclusion. Cette plage inclut tout, de 10.1.0.0/24 à 10.1.99.0/24, de 10.1.101.0/24 à 10.1.199.0/24 et de 10.1.201.0/24 à 10.1.255.0/24.

  • Les plages de sous-réseaux existantes continuent de fonctionner comme prévu. Les chevauchements avec les plages d'inclusion et d'exclusion lors de la création de plages de sous-réseaux entraînent une erreur.

Exemples de plages de sous-réseaux non valides

Les exemples suivants montrent des plages de sous-réseaux non valides :

  • Chevauchement avec la plage d'exclusion

    Dans ce cas, la plage d'inclusion suivante contient la plage de sous-réseaux 4, qui est un sur-ensemble de la plage d'exclusion 4. Cela signifie que la plage de sous-réseaux 4 n'est pas valide.

    Plage d'inclusion : 10.0.0.0/8

    Plage d'exclusion 4 : 10.1.1.0/24

    Plage de sous-réseaux 4 : 10.1.0.0/16

  • Chevauchement avec la plage d'inclusion

    La plage de sous-réseaux 5 chevauche la plage d'inclusion. Elle n'est donc pas valide.

    Plage d'inclusion : 10.1.1.0/24

    Plage de sous-réseaux 5 : 10.1.0.0/16

    Lorsque vous saisissez une plage de sous-réseau non valide lors du processus de création du sous-réseau, vous obtenez une erreur Invalid IPCidrRange semblable à celle-ci :

    Invalid IPCidrRange: CIDR_RANGE conflicts with existing subnetwork SUBNET_RANGE in region REGION

Topologies prédéfinies

Network Connectivity Center vous permet de spécifier la configuration de connectivité souhaitée sur tous les spokes VPC. Vous pouvez choisir l'une des deux topologies prédéfinies suivantes:

Pour en savoir plus sur les topologies de connectivité, consultez Topologies de connectivité prédéfinies.

Pour en savoir plus sur la configuration de la topologie maillée ou en étoile pour vos spokes VPC, consultez la section Configurer un hub.

Limites

Cette section décrit les limites des spokes VPC en général, et lorsqu'ils sont associés à un hub dans un autre projet. Ces limites s'appliquent également aux spokes VPC du producteur.

Limites des spokes VPC

  • Les réseaux VPC peuvent se connecter les uns aux autres de manière exclusive via le hub Network Connectivity Center ou via l'appairage de réseaux VPC.
  • Vous ne pouvez pas utiliser l'appairage de réseaux VPC entre deux spokes VPC connectés au même hub Network Connectivity Center. Toutefois, tenez compte des points suivants :
    • Un spoke VPC de producteur nécessite une connexion d'appairage à un spoke VPC sur le même hub. La connectivité via Network Connectivity Center n'est pas établie entre le spoke VPC de producteur et son spoke VPC appairé.
    • Vous pouvez disposer d'un spoke VPC connecté à Network Connectivity Center qui est appairé via l'appairage de réseaux VPC avec un VPC distinct qui ne fait pas partie de Network Connectivity Center.
  • Les VPC connectés à l'aide de Network Connectivity Center et de l'appairage de réseaux VPC dans une combinaison ne sont pas transitifs.
  • L'échange de routes statiques entre les spokes VPC n'est pas accepté.
  • Les routes pointant vers des adresses IP virtuelles d'équilibreur de charge réseau passthrough interne dans d'autres spokes VPC ne sont pas acceptées.
  • Les équilibreurs de charge réseau passthrough internes basés sur IPv6 ne sont pas accessibles entre les spokes VPC.
  • L'échange de routes dynamiques IPv6 n'est pas accepté.
  • Les réseaux VPC en mode automatique ne sont pas acceptés en tant que spokes VPC. Vous pouvez passer du mode automatique à un réseau VPC personnalisé qui vous permet de définir manuellement les préfixes de sous-réseau pour chaque région de votre réseau VPC. Une fois la mise à jour effectuée, cette action est irréversible.

Limites de l'échange de routes dynamiques

  • IPv4 uniquement : Network Connectivity Center n'accepte que l'échange de routes dynamiques IPv4. L'échange de routes dynamiques IPv6 n'est pas accepté.

  • Compatibilité des spokes hybrides avec la topologie en étoile : un hub configuré pour utiliser la topologie en étoile impose les limites suivantes à ses spokes hybrides :

    • Les spokes hybrides pour lesquels le transfert de données de site à site est activé ne sont compatibles qu'avec le groupe de spokes centraux.
    • Les spokes hybrides pour lesquels le transfert de données de site à site n'est pas activé peuvent appartenir au groupe de spokes centraux ou au groupe de spokes périphériques.

  • Réseaux VPC de routage qui sont également des spokes VPC : Network Connectivity Center n'accepte au moins deux réseaux VPC de routage sur le même hub que si tous les réseaux VPC de routage ne sont pas également des spokes VPC. Si un hub Network Connectivity Center ne possède qu'un seul réseau VPC de routage, ce réseau VPC de routage peut également être un spoke VPC (facultatif) :

    • Si vous devez rendre les connexions Private Service Connect propagées disponibles pour les réseaux sur site via les spokes hybrides du hub, le réseau VPC de routage unique du hub doit également être connecté en tant que spoke VPC.

    • Si vous n'avez pas besoin de rendre les connexions Private Service Connect propagées disponibles pour les réseaux sur site via les spokes hybrides du hub, nous vous recommandons de ne pas configurer de réseau VPC de routage en tant que spoke VPC afin que le hub puisse prendre en charge deux réseaux VPC de routage ou plus.

  • Règles d'interaction des routes dynamiques : dans un réseau VPC de routage, pour chaque destination de route dynamique unique avec un saut suivant dans un spoke hybride, vous devez vous assurer que toutes les autres routes dynamiques, quelle que soit leur priorité, dont les destinations correspondent exactement à la destination de route dynamique unique ou s'y inscrivent, ont également des tunnels Cloud VPN ou des rattachements de VLAN de saut suivant dans un spoke hybride. De plus, vous devez vous assurer que ces spokes hybrides utilisent le même paramètre de transfert de données de site à site (activé ou désactivé).

    • Si seuls certains sauts suivants pour les routes dynamiques avec une destination commune se trouvent dans des spokes hybrides, Network Connectivity Center ne peut pas échanger de manière fiable les routes dynamiques qui utilisent cette destination avec les spokes VPC du hub. Par conséquent, les spokes VPC peuvent ne pas recevoir ces routes dynamiques.

    • Network Connectivity Center n'effectue pas d'ECMP entre tous les prochains sauts des routes dynamiques de spokes hybrides si certains spokes hybrides ont le transfert de données de site à site activé, mais que d'autres l'ont désactivé. Si des routes dynamiques avec une destination commune se trouvent dans des spokes hybrides sans paramètres de transfert de données de site à site correspondants, les prochains sauts pour le transfert de données de site à site ou pour la connectivité entre les spokes VPC et les réseaux sur site peuvent ne pas être ceux attendus.

  • Règles d'interaction entre les routes dynamiques et statiques : dans un réseau VPC de routage, pour chaque destination de route dynamique unique dont le prochain saut se trouve dans un spoke hybride, vous devez vous assurer qu'aucune route statique locale n'existe, quelle que soit sa priorité, dont les destinations correspondent exactement à la destination de la route dynamique ou s'y trouvent.

    • Si une route statique locale dans le réseau VPC de routage a la même destination qu'une route dynamique de spoke hybride, les spokes VPC peuvent perdre la connectivité à la destination de la route dynamique.

    • Si une route statique locale dans un réseau VPC de routage a une destination qui correspond à la destination d'une route dynamique de spoke hybride, les spokes VPC perdent la connectivité à la destination de la route statique.

Période d'attente après la suppression d'un spoke VPC

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 10 minutes. Si la période d'attente n'est pas respectée, la nouvelle configuration peut ne pas prendre effet. 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.

Quotas et limites

Lorsque vous utilisez l'échange de routes dynamiques, surveillez attentivement votre utilisation du nombre de routes dynamiques par hub. Ce quota ne comptabilise l'utilisation que par destination (préfixe) uniquement, sans tenir compte de la priorité ni du prochain saut d'une route dynamique. Lorsque l'utilisation de ce quota dépasse sa limite, Network Connectivity Center supprime les routes par destination. Si une destination est supprimée, toutes les routes dynamiques avec cette destination ne sont plus envoyées au hub, quelle que soit leur priorité ou leur saut suivant.

Pour obtenir des informations détaillées sur les quotas, consultez la page Quotas et limites.

Facturation

Heures spoke

Les heures spoke sont facturées en fonction du projet dans lequel réside la ressource de spoke et suit les tarifs des heures de spoke standards. Les heures spoke ne sont facturées que lorsque le spoke est à l'état ACTIVE.

Trafic sortant

Le trafic de sortie est facturé dans le projet de la ressource spoke d'où provient le trafic. Le prix est le même, que le trafic dépasse les limites du projet ou non.

Contrat de niveau de service

Pour en savoir plus sur le contrat de niveau de service de Network Connectivity Center, consultez le Contrat de niveau de service de Network Connectivity Center.

Tarifs

Pour en savoir plus sur les tarifs, consultez la page Tarifs du Network Connectivity Center.

Étapes suivantes