Présentation du centre de connectivité réseau

Le centre de connectivité réseau repose sur un modèle de réseau en étoile (hub-and-spoke) pour la gestion de la connectivité réseau dans Google Cloud. Cette approche permet de réduire la complexité opérationnelle grâce à un modèle simple de gestion de la connectivité. Le hub est associé au réseau de Google pour offrir une connectivité fiable à la demande.

Pour les définitions de hub et de spoke, consultez la section Hubs et spokes dans la suite de ce document.

Le centre de connectivité réseau vous permet d'interconnecter vos réseaux sur site en utilisant le réseau de Google comme réseau de transfert de données. Les réseaux sur site peuvent être constitués de centres de données sur site, de filiales et de bureaux distants.

Les réseaux sur site se connectent à un centre de connectivité réseau à l'aide de spokes auxquels des ressources de spoke Google Cloud compatibles sont associées. Un spoke peut, par exemple, contenir des tunnels VPN haute disponibilité pour une passerelle Cloud VPN située à proximité du réseau sur site.

Le schéma suivant illustre différents types de ressources de spokes connectées à un hub Network Connectivity Center. Le hub est associé à un réseau VPC.

Concept du centre de connectivité réseau
Concept du centre de connectivité réseau (cliquez pour agrandir)

Transfert de données via le réseau de Google

Le centre de connectivité réseau permet de connecter différents sites d'entreprise situés en dehors de Google Cloud en utilisant le réseau de Google en tant que réseau étendu (WAN). Ce type de trafic est appelé trafic de transfert de données.

Les sites externes peuvent être, par exemple, des réseaux de filiales, des centres de données privés, ou encore des charges de travail hébergées par d'autres fournisseurs cloud. Ces sites se connectent à un hub Network Connectivity Center en utilisant des ressources de connectivité hybride cloud existantes telles que Cloud VPN, l'interconnexion dédiée, l'interconnexion partenaire ou une sélection de partenaires d'appliances de routeur.

L'utilisation du centre de connectivité réseau permet de bénéficier instantanément de la couverture mondiale et de la fiabilité du réseau de Google. Cette fonctionnalité permet à votre entreprise de profiter de l'ensemble des bonnes pratiques de Google en matière de fiabilité et d'ingénierie du trafic.

Transfert de données via le réseau de Google
Transfert de données via le réseau de Google (cliquez pour agrandir)

Fonctionnement

Les sections suivantes décrivent le fonctionnement du centre de connectivité réseau et de ses composants.

Hubs et spokes

Le centre de connectivité réseau se compose de ressources hub et spoke. Vous pouvez ajouter une ou plusieurs étiquettes à une ressource hub ou satellite pour l'identifier.

Hub

Un hub est une ressource Google Cloud globale à laquelle vous pouvez associer plusieurs spokes. Il permet d'interconnecter facilement des spokes pour autoriser le transfert de données entre ces éléments. Un hub permet le transfert de données entre différents emplacements sur site et un réseau de cloud privé virtuel (VPC) via les spokes associés.

Cette approche permet de réduire la complexité opérationnelle grâce à un modèle simple de gestion centralisée de la connectivité. Un hub, combiné au réseau de Google, fournit une connectivité fiable à la demande.

Spoke

Un spoke est une ressource réseau Google Cloud connectée à un hub. Le spoke fait partie intégrante du hub, il n'est pas possible de le créer sans créer le hub au préalable. Un spoke achemine le trafic vers des blocs d'adresses réseau distants et permet l'interconnexion de plusieurs réseaux distants.

Vous ne pouvez associer qu'un seul type de ressource à chaque spoke. Pour obtenir la liste des types de ressources, consultez la section suivante.

Types de ressources de spoke

Le centre de connectivité réseau permet d'associer les ressources Google Cloud suivantes aux spokes. Vous ne pouvez disposer que d'un seul type de ressource dans un spoke, mais vous pouvez associer plusieurs instances du même type de ressource au même spoke.

  • Tunnels VPN haute disponibilité
  • Rattachements de VLAN
  • Instances de l'appliance de routeur que vous ou certains partenaires déployez dans Google Cloud

Vous configurez une instance d'appliance de routeur en tant que pair BGP d'un routeur cloud. Vous pouvez créer une instance d'appliance de routeur en configurant une VM Compute Engine, en activant l'appairage BGP vers Cloud Router et en exécutant l'image de votre choix, par exemple une appliance virtuelle de réseau tiers.

Haute disponibilité pour les ressources de spoke (obligatoire)

Chaque type de ressource possède des exigences différentes en matière de haute disponibilité. Configurez les types de ressources que vous prévoyez d'utiliser en lisant les informations des sections suivantes.

Haute disponibilité pour Cloud Interconnect

Pour que Network Connectivity Center fonctionne correctement avec les ressources Cloud Interconnect, vous devez configurer plusieurs connexions par interconnexion, chacune dans un domaine de disponibilité de périphérie distinct.

Pour plus d'informations sur la configuration des ressources Cloud Interconnect pour la haute disponibilité, consultez la documentation suivante :

Haute disponibilité pour Cloud VPN

Pour que Network Connectivity Center fonctionne correctement avec les ressources Cloud VPN, vous devez configurer plusieurs interfaces et tunnels de passerelles VPN haute disponibilité pour obtenir un contrat de niveau de service garantissant une disponibilité de 99,99 %. Pour en savoir plus, consultez la présentation de Cloud VPN.

Haute disponibilité pour l'appliance de routeur

Pour que Network Connectivity Center fonctionne correctement avec les instances d'appliance de routeur associées à un satellite, vous devez procéder comme suit:

Si vous placez toutes les instances d'appliance de routeur dans un seul satellite, utilisez le chemin ECMP (Equal-Cost Multi-Path) pour annoncer le même ensemble de préfixes à partir de deux instances d'appliance de routeur. Pour annoncer des préfixes différents pour chaque satellite, ajoutez chaque instance d'appliance de routeur à un satellite différent.

Vous ne pouvez pas créer de configuration interrégionale dans un seul satellite.

ECMP est le résultat de l'annonce d'un ou de plusieurs préfixes identiques, avec les mêmes MED et le même chemin AS, selon le cas, à partir d'au moins deux instances d'appliance de routeur. Les conseils concernant la sélection des routes dans les réseaux VPC s'appliquent aux instances d'appliance de routeur comme pour les autres ressources Google Cloud.

Pour plus d'informations sur la configuration des instances d'appliance de routeur pour la haute disponibilité, consultez la section Exigences relatives à la disponibilité de 99,9 %.

Échange de routes

Le centre de connectivité réseau fournit une connectivité maillée complète pour chaque spoke qui y est associé, en propageant toutes les routes que chaque spoke a apprises vers tous les autres spokes associés au même hub.

Topologie d'un centre de connectivité réseau
Topologie d'un centre de connectivité réseau (cliquez pour agrandir)

Dans la topologie précédente, les spokes A, B et C sont associés au même hub et utilisent Cloud Router pour annoncer les préfixes dans le hub.

Pour autoriser le trafic de site à site interrégional via des hubs et des spokes, vous devez activer le routage global sur le réseau VPC associé au hub et aux spokes. Si tous les spokes sont situés dans la même région, le routage global n'est pas nécessaire. En effet, en pareil cas, le trafic de site à site fonctionne sans qu'il soit nécessaire d'activer le routage global.

Le tableau suivant montre comment le hub propage les annonces de préfixe vers d'autres spokes.

Routes du spoke A Routes du spoke B Routes du spoke C
Routes exportées vers le spoke A 10.3.0.0/16 est accessible via le spoke B. 10.4.0.0/16 est accessible via le spoke C.
Routes exportées vers le spoke B 10.2.0.0/16 est accessible via le spoke A. 10.4.0.0/16 est accessible via le spoke C.
Routes exportées vers le spoke C 10.2.0.0/16 est accessible via le spoke A. 10.3.0.0/16 est accessible via le spoke B.

Conflits de routage

Lors du choix de l'ordre des routes, considérez que les routes installées par un hub de centre de connectivité réseau sont traitées comme des routes dynamiques. Pour plus d'informations sur la résolution des conflits de routage, consultez la section Applicabilité et ordre de priorité des routes dans la documentation sur les VPC.

Afin d'assurer la sélection du meilleur chemin parmi les annonces reçues, Google Cloud utilise les valeurs MED pour en déterminer la priorité. Pour plus d'informations, consultez la section Remarques concernant le routage.

Compatibilité avec les configurations réseau existantes

Le centre de connectivité réseau n'affecte que la communication entre les spokes. Il n'a pas d'incidence sur la communication entre Cloud VPN (ou Cloud Interconnect) et les réseaux VPC.

  • Toutes les VM d'un même réseau VPC apprennent toujours toutes les routes annoncées par un tunnel Cloud VPN ou une connexion d'interconnexions.
  • Toutes les routes de sous-réseau d'un même réseau VPC sont toujours annoncées sur tous les tunnels Cloud VPN et toutes les connexions d'interconnexion de ce réseau VPC.
  • La propagation de la route précédente a toujours lieu sur les réseaux utilisant l'appairage de réseaux VPC. Pour les exceptions, consultez la section Remarques concernant le routage.

En outre, Network Connectivity Center n'affecte pas la manière dont les routes sont annoncées sur les réseaux utilisant l'appairage de réseaux VPC. Toutes les routes annoncées à partir d'un tunnel Cloud VPN ou d'un rattachement de VLAN peuvent toujours être exportées vers un réseau appairé. Toutes les routes de sous-réseau du réseau appairé sont annoncées sur le réseau sur site via un tunnel Cloud VPN ou un rattachement de VLAN.

Remarques

Cette section décrit les éléments à prendre en compte avant de configurer le centre de connectivité réseau, ainsi que les considérations qui s'appliquent aux ressources associées à un hub et au routage des données par le biais de hubs et de spokes.

Pour en savoir plus sur les quotas et limites applicables au centre de connectivité réseau, consultez la page Quotas et limites.

Hubs, spokes et réseaux VPC

Lorsque vous ajoutez le premier spoke à un hub, ce hub est associé au projet et au réseau dont dépend le spoke. Il ne peut y avoir qu'une seule instance de hub par réseau VPC. Le réseau VPC associé au hub ne peut pas être un ancien réseau VPC.

Les ressources telles que les tunnels Cloud VPN et les rattachements de VLAN associés à un spoke doivent appartenir au même réseau VPC que le hub.

Les réseaux VPC partagés gèrent les hubs et les spokes différemment.

Les considérations suivantes s'appliquent également aux hubs et aux spokes :

  • Seuls les tunnels VPN haute disponibilité sont acceptés en tant que rattachements à des spokes. Les tunnels VPN classiques ne sont pas acceptés.
  • Lors de la création de tunnels VPN haute disponibilité rattachés à un spoke de centre de connectivité réseau, la création de passerelles VPN haute disponibilité Google Cloud vers Google Cloud entre différentes régions du même projet Google Cloud n'est pas acceptée. Il s'agit d'une limitation liée au VPN haute disponibilité, et non d'une limitation du centre de connectivité réseau.
  • Nous mettons tout en œuvre pour optimiser le trafic de transfert de données entre les sites, mais aucune bande passante minimale n'est garantie.
  • Le centre de connectivité réseau n'est disponible que dans les emplacements compatibles (à quelques exceptions près).

Compatibilité avec l'appairage de réseaux VPC

Vous pouvez utiliser l'appairage de réseaux VPC pour appairer le réseau associé au hub avec un ou plusieurs de vos autres réseaux VPC. Toutefois, pour que le réseau appairé au réseau du hub puisse envoyer du trafic vers les réseaux sur site associés au hub ou en recevoir depuis ceux-ci, vous devez également effectuer les opérations suivantes :

  1. Utilisez des annonces de routage personnalisées pour annoncer les sous-réseaux VPC pairs à des réseaux sur site associés au hub.
  2. Activez l'importation et l'exportation des routes personnalisées. Cela permet de rendre les routes provenant des réseaux sur site associés au hub visibles depuis les sous-réseaux des réseaux VPC appairés au réseau VPC associé au hub.

Compatibilité avec les réseaux VPC partagés

Lorsque vous utilisez des réseaux VPC partagés, vous devez créer le hub dans le projet hôte.

Pour en savoir plus sur le rôle networkconnectivity.googleapis.com/spokeAdmin que vous pouvez attribuer aux administrateurs des projets de service, consultez la page Contrôle des accès.

Remarques concernant l'API

Remarques concernant le routage

  • Les préfixes de routage doivent être annoncés exclusivement au sein d'un hub ou en dehors d'un hub. Par exemple, si le même préfixe est annoncé par deux tunnels Cloud VPN, l'un dans un hub et l'autre en dehors de ce même hub, le transfert de données peut ne pas aboutir si le tunnel en dehors du hub est choisi par la fonction de sélection du meilleur chemin.
  • AS-path permet de sélectionner le meilleur chemin au sein d'une tâche Cloud Router unique. Sinon, seule la valeur MED sert à hiérarchiser les routes. Pour plus d'informations, consultez la section consacrée à AS-path dans la présentation de Cloud Router.

Attribuer des numéros ASN aux spokes

Pour simplifier la configuration, nous vous recommandons d'attribuer des numéros ASN aux spokes comme suit :

  • Utilisez un seul numéro de système autonome Google (router.bgp.asn) sur Cloud Router pour toutes les ressources de spokes associées à un seul hub. Par exemple, les tunnels VPN haute disponibilité associés à un spoke utilisent ce numéro ASN Google sur le routeur cloud qu'ils utilisent pour l'appairage. Suivez les recommandations pour la numérotation des ASN dans la documentation de création d'un routeur cloud.
  • Attribuez un numéro ASN de pairs unique à chaque spoke associé au même hub (router.bgpPeers.asn). Dans chaque spoke, vérifiez que tous les numéros ASN de pairs sont identiques. Comme deux pairs annoncent le même préfixe avec des numéros ASN ou des chemins AS différents, seul le numéro ASN et le chemin AS d'un seul pair est annoncé pour ce préfixe.
  • Nous vous recommandons de configurer la détection de boucle de chemin AS sur vos routeurs pairs, bien que cette fonctionnalité soit presque toujours activée par défaut. Dans certains cas, elle ne peut pas être désactivée. par exemple, lorsque le routeur pair est un routeur Cloud Router, ou éventuellement lors de l'utilisation des fonctionnalités de routage d'autres fournisseurs cloud.

    Lorsque la détection de boucle de chemin AS est activée, si deux spokes sont configurés avec le même numéro ASN de pair, la détection de boucle de chemin AS sur un routeur pair de l'un des spokes supprime l'intégralité des annonces de préfixe provenant de l'autre spoke.

Dans l'exemple suivant, les routeurs pairs dans les spokes suivants annoncent des préfixes et des numéros ASN différents :

  • Spoke A ; routeur pair 1, numéro ASN 65001, annonce les préfixes 10.1.0.0/16 et 10.2.0.0/16
  • Spoke A : routeur pair 2, ASN 65002, annonce les préfixes 10.1.0.0/16 et 10.3.0.0/16
  • Spoke B ; routeur pair 3, ASN 65003, annonce les préfixes 10.1.0.0/16 et 10.4.0.0/16

Cloud Router annonce ensuite les préfixes suivants à un pair sur le spoke C :

  • 10.1.0.0/16, mais le chemin AS peut commencer par l'un des numéros ASN suivants : 65001, 65002 ou 65003
  • 10.2.0.0/16 avec un chemin AS commençant par 65001
  • 10.3.0.0/16 avec un chemin AS commençant par 65002
  • 10.4.0.0/16 avec un chemin AS commençant par 65003

En vous assurant que chaque préfixe ne fait l'objet d'une annonce que par un seul satellite, et que tous les pairs d'un même satellite ont le même numéro ASN, cette ambiguïté est évitée.

Annonces de routage

  • S'il existe des annonces de routage en double provenant de différents spokes pour les mêmes sous-réseaux et avec la même priorité, Cloud Router utilise ECMP pour répartir le trafic entre tous les sauts suivants. Dans ce cas, les connexions par interconnexion reçoivent plus de trafic que les connexions Cloud VPN, qui reçoivent plus de trafic que les VM agissant en tant qu'instances d'appliance de routeur.
  • Problème connu. S'il existe des annonces de routage en double provenant des ressources des spokes participants, telles que les tunnels VPN haute disponibilité, ou encore de ressources similaires ne faisant pas partie de ces spokes, le trafic dans les spokes participants peut utiliser ECMP vers tous les sauts suivants disponibles. Cela se produit même si les sauts suivants ne sont ni des hubs participants, ni les spokes eux-mêmes. Ce comportement sera corrigé dans une version ultérieure du centre de connectivité réseau.
  • 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.

Sessions BGP

  • Les sessions BGP des tunnels VPN haute disponibilité annoncent des plages d'adresses IP identiques.
  • Les attributs BGP acceptés sont les suivants :
    • La propagation du chemin AS et des valeurs MED dans des pièces jointes hybrides est acceptée.
    • Les communautés BGP ne sont pas acceptées.

Étapes suivantes