Questions fréquentes sur Cloud Interconnect

Ce document aborde les questions fréquentes relatives aux fonctionnalités et à l'architecture de Cloud Interconnect, regroupées au sein des sections principales suivantes :

Trafic sur Cloud Interconnect

Cette section aborde les questions relatives aux types de trafic, à la bande passante et au chiffrement sur Cloud Interconnect.

Quels types de paquets sont acheminés sur Cloud Interconnect ?

Le circuit Cloud Interconnect transporte des trames Ethernet 802.1q avec des paquets IPv4 dans la charge utile. Ces trames sont également appelés trames Ethernet avec tag VLAN.

La valeur du champ de l'ID de VLAN (VID) 12 bits de l'en-tête 802.1q est identique à la valeur de l'ID de VLAN attribuée par Google Cloud lors de la création d'un rattachement d'interconnexion (VLAN). Pour en savoir plus, consultez les documents suivants :

Comment chiffrer le trafic sur Cloud Interconnect ?

En fonction du service auquel vous accédez via Cloud Interconnect, votre trafic peut déjà être chiffré sans qu'aucune action particulière ne soit requise de votre part. Par exemple, si vous accédez à l'une des API Google Cloud accessibles via Cloud Interconnect, ce trafic est déjà chiffré avec TLS de la même manière que si les API étaient accessibles via l'Internet public.

Vous pouvez également utiliser la solution TLS pour les services que vous créez. Il peut s'agir, par exemple, d'un service que vous proposez sur une instance Compute Engine ou sur un pod Google Kubernetes Engine compatible avec le protocole HTTPS.

Si vous avez besoin d'un chiffrement au niveau de la couche IP, vous pouvez créer une ou plusieurs passerelles VPN autogérées (non Google Cloud) dans votre réseau cloud privé virtuel et attribuer une adresse IP privée à chaque passerelle. Par exemple, vous pouvez exécuter un VPN StrongSwan sur une instance Compute Engine. Vous pouvez ensuite raccorder les tunnels IPsec à ces passerelles VPN via Cloud Interconnect depuis des installations sur site.

Pour en savoir plus, consultez la documentation sur le chiffrement en transit dans Google Cloud.

Puis-je créer un pipeline 100G sur une interconnexion dédiée ?

Oui. Votre connexion à Google peut évoluer selon vos besoins.

Une connexion Cloud Interconnect consiste en un ou plusieurs circuits déployés en tant que regroupement de liaisons de canaux de port Ethernet (LAG). Les circuits d'une connexion peuvent atteindre 10 Gbit/s ou 100 Gbit/s, mais pas les deux.

Une connexion peut avoir l'une des capacités maximales suivantes :

  • Huit circuits de 10 Gbit/s (80 Gbit/s au total)
  • Deux circuits de 100 Gbit/s (200 Gbit/s au total)

Les interconnexions dédiées ou partenaires acceptent des capacités de rattachement d'interconnexion (VLAN) allant de 50 Mbit/s à 50 Gbit/s. Le débit de rattachement maximal autorisé pour l'interconnexion partenaire est de 50 Gbit/s. Toutefois, il est possible que certains débits ne soient pas disponibles, suivant l'offre du partenaire choisi dans la zone sélectionnée.

Vous pouvez commander plusieurs connexions et les utiliser en mode actif/actif en exploitant les capacités de routage BGP de Cloud Router.

Pour obtenir une liste détaillée des capacités, quotas et limites, consultez les pages Tarifs et Quotas de Cloud Interconnect.

Puis-je atteindre des instances en utilisant IPv6 sur Cloud Interconnect ?

VPC ne propose pas de fonctionnalité native permettant d'acheminer le trafic IPv6 vers des instances.

Puis-je spécifier l'adresse IP d'appairage BGP ?

  • Pour une interconnexion partenaire, non. Les adresses IP d'appairage sont sélectionnées par Google.
  • Pour une interconnexion dédiée, vous pouvez spécifier une plage d'adresses IP (bloc CIDR) dans laquelle Google fait une sélection lorsque vous créez un rattachement d'interconnexion (VLAN). Ce bloc CIDR doit être compris dans la plage d'adresses IP de liaison locale (169.254.0.0/16).

Puis-je accéder aux API Google via Cloud Interconnect à partir d'installations sur site ? Quels services ou quelles API sont disponibles ?

Deux options s'offrent à vous pour accéder aux API Google.

L'option 1 vous permet d'activer l'accès privé à Google pour un ou plusieurs sous-réseaux du réseau VPC et de déployer une ou plusieurs instances de proxy inverse dans ces sous-réseaux. Ces proxy inverses ne présentent qu'une adresse IP privée VPC configurée et ne sont donc accessibles qu'à l'aide du lien Cloud Interconnect à partir d'installations sur site. Cette solution accorde l'accès à la plupart des API Cloud, des API de développement et des services Google Cloud.

Consultez la section Configurer l'accès privé à Google pour le VPC pour en savoir plus et pour accéder à la liste des services GCP compatibles avec l'accès privé à Google.

L'option 2 vous permet d'exploiter l'accès privé à Google pour les hôtes sur site. Dans ce cas, les requêtes des hôtes sur site doivent être envoyées à restricted.googleapis.com, qui pointe en permanence vers la plage d'adresses IP 199.36.153.4/30, également appelée plage VIP limitée.

Ajoutez une route personnalisée sur Cloud Router pour annoncer la plage VIP limitée. Cela garantit que le trafic vers la plage VIP limitée (en tant que destination) est routé depuis les installations sur site vers les points de terminaison de l'API sur Cloud Interconnect. Seuls les services et les API Google compatibles avec la plage VIP limitée sont accessibles avec cette solution.

Pour obtenir les informations les plus récentes relatives aux détails de la configuration et aux services compatibles, consultez la page Configurer l'accès privé à Google pour les hôtes sur site.

Puis-je utiliser Cloud Interconnect en tant que canal privé pour accéder à tous les services G Suite via un navigateur ?

Depuis décembre 2018, il n'est plus possible d'accéder aux applications G Suite via Cloud Interconnect.

Pourquoi mes sessions BGP oscillent-elles en continu après un certain intervalle ?

Recherchez un masque de sous-réseau incorrect sur votre plage d'adresses IP BGP sur site. Par exemple, au lieu de configurer 169.254.10.0/29, vous avez peut-être configuré 169.254.10.0/30.

Puis-je envoyer et apprendre des valeurs MED via une connexion d'interconnexion partenaire de couche 3 (L3) ?

Si vous utilisez une connexion d'interconnexion partenaire où un partenaire L3 gère BGP pour vous, 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. Cela signifie que, via ce type de connexion, vous ne pouvez pas définir de priorités pour les routes annoncées par Cloud Router sur votre routeur sur site, et vous ne pouvez pas définir de priorités pour les routes annoncées par votre routeur sur site sur votre réseau VPC.

Architecture Cloud Interconnect

Cette section traite des questions courantes qui se posent lors de la conception ou de l'utilisation d'une architecture Cloud Interconnect.

Puis-je renommer des connexions par interconnexion dédiée ou les déplacer vers un autre projet ?

Non. Une fois que vous avez nommé une connexion par interconnexion dédiée, vous ne pouvez plus la renommer ni la déplacer vers un autre projet Google Cloud. Vous devez supprimer la connexion et la recréer sous un nouveau nom ou dans un projet différent.

Puis-je utiliser Cloud Interconnect pour me connecter à l'Internet public ?

À compter de décembre 2018, les routes Internet ne sont pas annoncées sur Cloud Interconnect.

Comment puis-je me connecter à Google Cloud si je me trouve dans un emplacement POP non répertorié sur la page Choisir l'emplacement d'une installation hébergée en colocation ?

Deux options s'offrent à vous, après quoi vous pouvez suivre le processus normal de commande et de provision pour une interconnexion dédiée :

  • Vous pouvez commander des lignes louées à un opérateur pour vous connecter depuis votre point de présence (POP) à l'une des Zones des installations hébergées en colocation Cloud Interconnect de Google. En règle générale, il est préférable que vous contactiez votre fournisseur existant d'installation hébergée en colocation et que vous obteniez la liste des fournisseurs "réseau". Un fournisseur réseau est un fournisseur qui dispose déjà d'une infrastructure dans le bâtiment où vous vous trouvez, ce qui rend cette option moins chère et plus rapide que celle qui consiste à faire appel à un autre fournisseur devant créer une infrastructure pour vous accueillir dans votre emplacement POP existant.
  • L'autre option consiste à utiliser Partner Interconnect avec un partenaire opérateur qui peut vous fournir un circuit de boucle locale. Les fournisseurs de colocation ne peuvent généralement pas fournir ce type de service, car ils disposent d'emplacements fixes dans lesquels vous devez déjà être présent.

Si j'utilise une interconnexion partenaire, l'interconnexion est-elle visible dans le projet dans lequel je crée le rattachement d'interconnexion (VLAN) ?

Lorsque vous utilisez le service d'interconnexion partenaire, l'objet d'interconnexion est créé dans le projet partenaire et n'est pas visible dans votre projet. Le rattachement d'interconnexion (VLAN) est toujours visible dans votre projet, comme avec Cloud Interconnect.

Comment créer une architecture redondante qui exploite Cloud Interconnect ?

Selon le contrat de niveau de service souhaité, des architectures spécifiques doivent être mises en œuvre pour une interconnexion dédiée comme pour une interconnexion partenaire.

Vous pouvez accéder aux topologies pour les architectures de production avec un contrat de niveau de service à 99,99 % et pour les applications non critiques avec un contrat de niveau de service à 99,9 % à l'adresse /network-connectivity/docs/interconnect/docs/tutorials.

Ces niveaux de contrat de niveau de service font référence à la disponibilité de Cloud Interconnect, qui correspond à la disponibilité de la connexion routée entre l'emplacement sur site et le réseau VPC. Par exemple, si vous créez un service sur des instances Compute Engine accessibles via Cloud Interconnect, la disponibilité du service dépend de la disponibilité combinée du service Cloud Interconnect et du service Compute Engine.

  • Pour une interconnexion dédiée, une seule interconnexion (ensemble LACP) dispose d'un contrat de niveau de service sans garantie de disponibilité.
  • Pour une interconnexion partenaire, un seul rattachement d'interconnexion (VLAN) dispose d'un contrat de niveau de service sans garantie de disponibilité.

Les problèmes d'échec d'interconnexion unique/groupée sont traités à un niveau de priorité de demande d'assistance qui ne peut être supérieur à P3 : impact moyen – Utilisation du service partiellement perturbée. Ne vous attendez donc pas à une résolution rapide, ni à une analyse plus poussée de l'origine du problème.

En raison d'événements de maintenance planifiés ou non planifiés, des liaisons simples ou des groupes peuvent être drainés pendant de longues périodes, c'est-à-dire pendant plusieurs heures ou même plusieurs jours.

Puis-je transférer le trafic sur Cloud Interconnect entre mon ancienne application sur site et mes backends équilibreurs de charge internes ?

Dans ce scénario, vous avez déployé une application composée de deux niveaux : un niveau sur site qui n'a pas encore été migré vers Google Cloud (ancien niveau) et un niveau cloud s'exécutant sur des instances VPC qui sont également des backends d'un équilibreur de charge interne (ILB) Google Cloud.

Vous pouvez utiliser Cloud Interconnect pour transférer le trafic entre ces deux niveaux d'applications tant que vous mettez en œuvre les routes nécessaires entre Cloud Router et votre routeur sur site. Le routeur cloud que vous utilisez pour le service Cloud Interconnect gérant le trafic de cette application doit se trouver dans la même région que le sous-réseau contenant les backends ILB. En effet, l'ILB n'accepte que le routage régional et l'accès à ILB est perdu lorsque le routage global pour le VPC utilise un tunnel situé en dehors de la région où se trouvent les backends ILB. Pour en savoir plus, consultez la section Utiliser Cloud VPN et Cloud Interconnect.

Si le trafic sur site accède au réseau VPC depuis une autre région, vous pouvez déployer un ILB avec les backends correspondants dans l'autre région ou acheminer le trafic vers un proxy inverse à partir duquel la plage VIP ILB peut être atteinte.

Puis-je déplacer une ou plusieurs instances de Cloud Interconnect entre des organisations ou des projets Google Cloud ?

Si vous souhaitez déplacer un projet vers une nouvelle organisation Google Cloud, vous pouvez ouvrir une demande d'assistance. L'assistance Cloud peut alors faciliter le déplacement.

Les interconnexions dédiées et les rattachements d'interconnexion (VLAN) ne sont pas affectés par les changements d'organisation tant que le projet reste identique.

Dans le cas de modifications de projet, si vous effectuez une activation de Cloud Interconnect et que vous disposez d'un mandat, mais que l'activation n'est pas encore terminée, annulez l'activation en cours et créez-en une dans le projet approprié. Google émet un nouveau mandat que vous pouvez ensuite transmettre à votre fournisseur de répartiteur. Pour connaître la procédure à suivre, consultez les sections Commander une connexion et Récupérer les mandats LOA-CFA.

Toutefois, un service Cloud Interconnect actif ne peut pas être déplacé entre des projets, car il s'agit d'un objet enfant du projet et il n'est pas possible de migrer automatiquement des objets entre projets. Si possible, vous devriez faire une demande pour obtenir un nouveau Cloud Interconnect.

Comment utiliser le même service Cloud Interconnect pour connecter plusieurs réseaux VPC à plusieurs projets au sein de la même organisation Google Cloud ?

Pour une interconnexion dédiée ou une interconnexion partenaire, vous pouvez vous servir d'un VPC partagé ou d'un appairage de réseaux VPC pour partager un seul rattachement entre plusieurs réseaux VPC. Pour connaître la procédure à suivre, consultez la page Autoriser plusieurs réseaux VPC à accéder au même rattachement de VLAN.

Pour une interconnexion dédiée, vous pouvez créer plusieurs rattachements, un pour chaque projet ou réseau VPC auquel vous souhaitez vous connecter.

Dans le cas d'une interconnexion partenaire, si vous ne pouvez pas utiliser le VPC partagé ou l'appairage de réseaux VPC (parce que vous devez séparer les réseaux VPC, par exemple), vous devez créer des rattachements de VLAN supplémentaires. Cette opération peut entraîner des coûts supplémentaires.

Interconnexion partenaire

Si vous avez plusieurs rattachements d'interconnexion (VLAN), y compris dans différents projets, vous pouvez les associer à une connexion par interconnexion partenaire provisionnée par le même fournisseur de services ou à des connexions par interconnexion partenaire provisionnées par d'autres fournisseurs de services.

Interconnexion dédiée

Si vous avez plusieurs projets, vous pouvez attribuer à chacun son propre rattachement d'interconnexion (VLAN) et son propre routeur cloud lors de la configuration de tous les rattachements pour qu'ils utilisent la même interconnexion dédiée physique dans un projet spécifié.

Le rattachement d'interconnexion (VLAN), en plus d'être un VLAN avec un ID 802.1q, représente l'objet enfant d'un Cloud Interconnect existant dans un projet.

Dans ce modèle, chaque réseau VPC présente sa propre configuration de routage. Si vous souhaitez centraliser les règles de routage, consultez la page Présentation du VPC partagé et la section Considérations relatives au VPC partagé afin de raccorder le rattachement d'interconnexion (VLAN) au réseau VPC du projet hôte VPC partagé. Votre projet hôte dispose d'un quota pour le nombre maximal de rattachements d'interconnexion (VLAN) par connexion Cloud Interconnect. Pour en savoir plus, consultez la page Quotas et limites associée à Cloud Interconnect.

Puis-je utiliser un Cloud Interconnect unique pour connecter plusieurs emplacements sur site à mon réseau VPC ?

Vous pouvez facilement effectuer cette opération. Par exemple, si ces emplacements font partie d'un réseau VPN MPLS, qu'il soit autogéré ou géré par un opérateur, vous pouvez "ajouter logiquement" le réseau VPC en tant que site supplémentaire en utilisant une approche semblable à l'option A VPN MPLS Inter-AS (voir RFC 4364, paragraphe 10).

Cette solution est décrite dans la réponse permettant de faire apparaître un réseau VPC dans le service VPN MPLS d'un partenaire. En exploitant les fonctionnalités BGP de Cloud Router, il est possible d'injecter des routes VPC dans une structure centrale IP existante en utilisant des techniques et des architectures similaires à celles utilisées pour importer des routes Internet.

Puis-je "associer" physiquement Cloud Interconnect et une interconnexion provenant d'un autre fournisseur cloud?

Si vous utilisez déjà un autre fournisseur cloud offrant un service fonctionnellement équivalent à Cloud Interconnect, aucune configuration convenue entre les fournisseurs cloud ne permet d'associer physiquement deux interconnexions, l'une fournie par Google Cloud et l'autre par l'autre fournisseur cloud. Cependant, vous pouvez connecter l'espace d'adressage privé du réseau VPC et le réseau d'un autre fournisseur cloud.

Si le point de transfert de service de l'autre fournisseur cloud se situe au même emplacement que Cloud Interconnect, vous pouvez provisionner votre propre routeur à cet emplacement pour raccorder les deux services d'interconnexion. Le routeur connectera ensuite le réseau VPC et le réseau de l'autre fournisseur cloud. Cette configuration vous permet d'acheminer directement des données depuis les deux réseaux cloud vers votre réseau sur site dans les meilleurs délais.

Certains opérateurs d'interconnexion partenaire sont en mesure de proposer ce service sous forme de service géré, basé sur un routeur virtuel. Si Google Cloud et l'autre fournisseur cloud reçoivent les services d'interconnexion dans des emplacements différents, vous devez fournir un circuit reliant les deux emplacements.

Comment connecter AWS et Google Cloud sans devoir placer d'équipement dans une installation hébergée en colocation à proximité du réseau périphérique de Google ?

Megaport propose sa propre solution de routeur cloud pour les clients Google Cloud qui ne souhaitent pas installer de matériel à proximité du réseau périphérique de Google. Consultez les instructions de configuration pour découvrir comment configurer ce produit avec Google Cloud.

Rattachements d'interconnexion (VLAN)

Cette section aborde les questions relatives aux rattachements d'interconnexion (VLAN).

Comment choisir l'ID de VLAN utilisé pour un rattachement d'interconnexion (VLAN) ?

Dans le cas d'un rattachement d'interconnexion créé avec une interconnexion partenaire, le partenaire choisit l'ID de VLAN lors du processus de création du rattachement ou vous permet de le choisir. Consultez votre partenaire pour savoir s'il vous permet de choisir l'ID de VLAN pour les rattachements d'interconnexion.

Dans le cas d'un rattachement d'interconnexion créé avec une interconnexion dédiée, deux possibilités s'offrent à vous : utiliser la commande gcloud compute interconnects attachments create avec l'option --vlan ou suivre les instructions de Google Cloud Console.

L'exemple suivant illustre l'utilisation de la commande gcloud pour définir l'ID de VLAN sur 5 :

gcloud compute interconnects attachments dedicated create my-attachment \
  --router my-router \
  --interconnect my-interconnect \
  --vlan 5 \
  --region us-central1

Pour accéder à des instructions complètes, consultez l'un des documents suivants :

Puis-je utiliser le routeur cloud avec plusieurs rattachements d'interconnexion ?

Oui, cette configuration est disponible.

Puis-je configurer des rattachements dont la bande passante combinée dépasse la bande passante de ma connexion Cloud Interconnect ?

Oui, mais la création de rattachements dont la bande passante combinée est supérieure à celle de la connexion Cloud Interconnect ne vous fournit pas davantage de bande passante que la bande passante maximale spécifiée pour cette connexion.

MPLS

Cette section aborde les questions relatives à Cloud Interconnect et à MPLS.

Puis-je utiliser Cloud Interconnect pour recevoir un LSP MPLS au sein de mon réseau VPC ?

Depuis décembre 2018, VPC n'offre plus de fonctionnalité native dans Google Cloud permettant de recevoir un LSP MPLS.

Dans le cas d'un service VPN MPLS autogéré, puis-je faire en sorte que mon réseau VPC apparaisse comme un site supplémentaire ?

Si vous gérez vous-même un service VPN MPLS, vous pouvez faire en sorte que votre réseau VPC apparaisse comme un site supplémentaire qui consiste en un VPN autogéré.

Ce scénario suppose que vous n'achetez pas de service VPN MPLS auprès d'un fournisseur. Vous disposez plutôt d'un environnement VPN MPLS dans lequel vous gérez et configurez vous-même les routeurs P et PE du réseau MPLS.

Pour que votre réseau VPC apparaisse en tant que site supplémentaire dans votre service VPN MPLS autogéré, procédez comme suit :

  1. Connectez l'un de vos appareils de périphérie PE VPN MPLS à votre appareil de périphérie d'appairage pour interconnexion dédiée à l'aide d'un modèle très semblable à l'option A VPN MPLS Inter-AS (voir RFC 4364, paragraphe 10). En d'autres termes, vous pouvez raccorder le VPN MPLS-VPN requis, par exemple VRF_A, à votre appareil de périphérie PE, puis utiliser le mappage VLAN-VRF pour "joindre" le rattachement d'interconnexion Google Cloud (VLAN) à ce VPN, avec pour effet de mapper le VLAN sur VRF_A au niveau de l'appareil de périphérie PE.

  2. Créez une session BGP IPv4 standard entre le routeur PE et Cloud Router pour vous assurer que les routes sont échangées. Les routes envoyées par Cloud Router n'apparaîtront que dans la table de routage VPN (à l'intérieur de VRF_A) et non dans la table de routage globale de l'appareil de périphérie PE.

    Vous pouvez gérer les chevauchements de plages d'adresses IP en créant plusieurs VPN distincts, par exemple, VRF_A et VRF_B, chacun ayant une session BGP sur Cloud Router dans un réseau VPC spécifique (par exemple, VPC_A et VPC_B). Cette procédure ne nécessite aucune encapsulation MPLS entre votre appareil de périphérie PE et l'appareil de périphérie d'appairage pour une interconnexion dédiée.

Puis-je faire en sorte que mon réseau VPC apparaisse en tant que site supplémentaire dans mon VPN MPLS provenant d'un opérateur qui est également partenaire d'une interconnexion partenaire ?

Si vous achetez un service VPN MPLS auprès d'un opérateur également partenaire officiel d'une interconnexion partenaire, vous pouvez faire en sorte que votre réseau VPC apparaisse en tant que site supplémentaire dans votre VPN MPLS.

Dans ce cas, le fournisseur gère et configure les routeurs P et PE de son réseau MPLS. Comme une interconnexion partenaire utilise exactement le même modèle de connectivité qu'une interconnexion dédiée, l'opérateur peut utiliser un modèle très semblable à l'option A VPN MPLS Inter-AS (voir RFC 4364, paragraphe 10).

En fait, l'opérateur vous fournit un service d'interconnexion partenaire de couche 3, puis "lie" votre rattachement d'interconnexion (VLAN) au VPN MPLS approprié sur l'appareil de périphérie de l'opérateur. Pour en savoir plus, consultez la page Présentation de l'interconnexion partenaire. S'agissant d'un modèle de service de couche 3, la session BGP est établie entre votre routeur cloud et votre VRF à l'intérieur de l'appareil de périphérie de l'opérateur.