Google PCNE: Connectivité hybride, Cloud Router et BGP — Guide d'étude

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Network Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La connectivité hybride sur Google Cloud permet une communication privée et contrôlée entre les réseaux VPC et les réseaux externes tels que les datacenters sur site ou d’autres clouds. Les briques de base sont les passerelles HA VPN et Cloud VPN, Cloud Router avec BGP pour le routage dynamique, et Interconnect avec les rattachements de VLAN. Les architectures doivent équilibrer la bande passante, la latence, la fiabilité, la complexité opérationnelle et le coût, tout en respectant un comportement de routage déterministe et l’isolation des domaines de défaillance. Cette section couvre le raisonnement derrière la conception et l’exploitation, les modes de défaillance courants et le dépannage systématique.

Connectivité hybride : HA VPN, Cloud Router et Interconnect

HA VPN et Cloud VPN
- HA VPN est un VPN IPsec régional à haute disponibilité qui prend en charge IKEv2 et nécessite Cloud Router pour le routage dynamique (eBGP). Une passerelle HA VPN possède deux interfaces ; pour le SLA et l’ECMP, construisez deux tunnels par interface vers des points de terminaison pairs distincts.
- Classic Cloud VPN prend en charge IKEv1 ou IKEv2 et les tunnels statiques ou basés sur des routes ; il ne prend pas en charge le SLA de HA VPN. Utilisez-le uniquement lorsque les pairs ne disposent pas de BGP ou si vous devez utiliser des sélecteurs basés sur des règles (policy-based).
- La passerelle paire (peer gateway) est l’appareil/IP VPN distant. Pour HA VPN, définissez une passerelle VPN paire avec une ou plusieurs adresses IP publiques pour modéliser des interfaces ou des appareils distincts pour la redondance.
- Conception pour le SLA : Pour être éligible au SLA de 99,99 % de HA VPN, déployez des tunnels redondants sur des appareils ou des interfaces sur site indépendants et utilisez le routage dynamique. Classic VPN n’est pas couvert par un SLA.
- Mise à l’échelle du débit : Un seul tunnel IPsec a un débit limité. Utilisez l’ECMP sur plusieurs tunnels pour augmenter le débit agrégé. Pour ce faire, terminez des tunnels supplémentaires sur des adresses IP publiques paires uniques.
Cloud Router et BGP
- Cloud Router est un service de plan de contrôle régional qui établit des sessions BGP avec des tunnels VPN ou des rattachements de VLAN Interconnect et échange des routes de manière dynamique.
- Le mode de routage dynamique (au niveau du VPC) régit où les routes dynamiques apprises sont utilisables et quelles routes de sous-réseaux VPC sont annoncées :
  - Régional : apprendre et utiliser/importer les routes dynamiques uniquement dans la même région.
  - Global : apprendre et utiliser/importer les routes dynamiques dans toutes les régions ; annoncer toutes les routes de sous-réseaux VPC (globales) aux pairs.
Dedicated Interconnect et Partner Interconnect
- Dedicated Interconnect fournit des circuits physiques de 10 Gbit/s ou 100 Gbit/s directement vers Google dans une installation de colocation. Vous obtenez une Letter of Authorization – Connecting Facility Assignment (LOA-CFA) pour permettre les interconnexions (cross-connects). Créez des rattachements de VLAN (VLAN attachments) qui mappent les balises 802.1Q à une connectivité L3 régionale associée à un Cloud Router.
- Partner Interconnect fournit une connectivité logique via un fournisseur de services. Vous demandez des rattachements de VLAN au partenaire ; la bande passante est fournie sur la périphérie (edge) du partenaire. Associez toujours les rattachements à un Cloud Router pour BGP.
- Redondance et SLA : Utilisez deux rattachements dans la même région, placés sur des domaines de disponibilité de périphérie (edge availability domains) distincts (et des interconnexions physiques distinctes, le cas échéant) pour atteindre des SLA plus élevés (par ex., 99,99 %). Un seul rattachement ou lien réduit le SLA. Pour Partner Interconnect, le SLA global dépend également du partenaire.
Interconnexions (cross-connects) et rattachements de VLAN
- Les interconnexions (cross-connects) sont les connexions physiques par fibre optique entre votre baie/équipement et la baie de Google dans une salle de rencontre (meet-me room). Présentez la LOA-CFA à votre fournisseur pour les réaliser.
- Les rattachements de VLAN (VLAN attachments) sont la démarcation logique L2 vers une région VPC. Chaque rattachement :
  - S’associe à un seul VPC et une seule région via un Cloud Router.
  - Est configuré par paires pour la redondance et l’ECMP.
  - Ne transporte que du trafic L3 ; pas d’extension L2.

Exemple court :

Créer un Cloud Router et une session BGP pour un rattachement ou un pair HA VPN : gcloud compute routers create cr-us-east1 –region=us-east1 –network=my-vpc –asn=65010 gcloud compute routers add-bgp-peer cr-us-east1 –region=us-east1 –peer-name=onprem-peer1 –peer-asn=65020 –interface=if-1 –peer-ip-address=169.254.0.2 –advertise-mode=DEFAULT –enable-bfd

Comportement du routage et de BGP

Routage dynamique ou statique
- Le routage dynamique avec Cloud Router permet l’apprentissage automatique des routes, la convergence et l’ECMP. Il s’adapte et réduit la charge opérationnelle à mesure que les réseaux se développent.
- Le routage statique est approprié lorsque les pairs ne disposent pas de BGP ou pour des chemins déterministes à portée limitée. Dans un VPC, les routes statiques ont une priorité numérique ; les valeurs les plus basses sont préférées parmi les routes statiques ayant la même longueur de préfixe.
- Sélection des routes dans un VPC :
  - La correspondance de préfixe la plus longue l’emporte.
  - Les routes de sous-réseau ne peuvent pas être remplacées par des routes personnalisées.
  - Pour des longueurs de préfixe égales, les routes statiques sont sélectionnées par la priorité la plus basse. Parmi les routes dynamiques, Cloud Router a déjà résolu les meilleurs chemins avant de les installer. La route par défaut du système est la moins prioritaire.
Sessions BGP, annonce, et import/export
- Cloud Router exporte par défaut les sous-réseaux du VPC ou un ensemble personnalisé de préfixes. Vous pouvez annoncer 0.0.0.0/0 ou des préfixes agrégés si nécessaire, mais cela attire le trafic sur site vers le Cloud si les politiques le permettent ; concevez cela de manière délibérée.
- Cloud Router importe tous les préfixes sur site autorisés et les installe en tant que routes dynamiques selon le mode de routage dynamique du VPC.
- La priorité de route annoncée par pair vous permet d’influencer la manière dont les routeurs sur site préfèrent un chemin Google plutôt qu’un autre ; une valeur de priorité plus faible se traduit par un MED plus préférentiel vers le pair.
ASN, MED et actif/passif
- Utilisez un ASN privé unique par domaine administratif, sauf si des ASN publics sont justifiés. Pour plusieurs routeurs sur site en peering avec le même VPC pour les mêmes préfixes :
  - Pour activer l’ECMP ou un meilleur chemin cohérent, utilisez le même ASN distant sur site sur tous les routeurs annonçant les mêmes préfixes. Des ASN distants différents peuvent empêcher l’installation à coût égal sur Cloud Router.
  - Pour une configuration actif/passif, manipulez le MED (plus la valeur est basse, plus elle est préférée) depuis le côté sur site, ou ajustez la priorité de route annoncée par pair de Cloud Router pour que le côté sur site préfère le chemin principal. Le AS-path prepending est une alternative, mais c’est un outil moins précis.
Conception à chemins multiples
- Cloud Router prend en charge l’ECMP sur plusieurs chemins BGP égaux pour les rattachements HA VPN et Interconnect. Assurez-vous que les attributs sont égaux (longueur de l’AS-path, MED, local-pref) et que les sauts suivants (next hops) sont distincts. Pour HA VPN, terminez les tunnels sur des adresses IP de pairs distinctes. Pour Interconnect, utilisez des rattachements redondants.

Résilience, détection et services de sortie (egress)

BFD et détection de pannes
- BFD accélère la détection de pannes pour les sessions BGP sur HA VPN et Interconnect. Activez BFD des deux côtés avec des intervalles compatibles pour obtenir une détection inférieure à la seconde ou de quelques secondes, selon vos besoins de stabilité. Combinez-le avec IKE DPD sur les tunnels IPsec. Assurez-vous que vos équipements pairs peuvent traiter un trafic de contrôle plus fréquent.
- Méfiez-vous de la détection asymétrique : un BFD agressif combiné à des liaisons congestionnées peut provoquer des instabilités de session (flapping) ; commencez avec des temporisateurs conservateurs et surveillez.
Modèles de topologie redondante
- HA VPN : Utilisez une passerelle HA VPN par région et terminez les tunnels sur deux équipements ou interfaces sur site distincts. Construisez au moins quatre tunnels (deux par interface) et un Cloud Router par région. Maintenez la cohérence des ASN distants lorsque vous proposez l’ECMP.
- Interconnect : Utilisez au moins deux rattachements dans chaque région sur des domaines de disponibilité de périphérie (edge availability domains) distincts. Pour Dedicated Interconnect, déployez les liaisons sur des équipements et dans des installations de périphérie différents lorsque cela est possible.
Cloud NAT, adresses externes et sortie des charges de travail privées
- Cloud NAT est un service de sortie (egress) régional et géré pour les ressources sans adresse IP externe. Il n’effectue pas de SNAT sur les instances qui ont des adresses IP externes ; celles-ci sortent directement. Sélectionnez des sous-réseaux ou tous les sous-réseaux d’une région pour couvrir les charges de travail privées.
- Dimensionnez les pools d’adresses IP de NAT pour les connexions simultanées et les ports éphémères ; choisissez une allocation d’IP manuelle ou automatique. Activez la journalisation pour le diagnostic.
- Pour atteindre les API Google de manière privée :
  - Dans le VPC : activez Private Google Access sur les sous-réseaux pour que les VM sans adresse IP externe puissent atteindre les API Google via les adresses IP virtuelles de Google.
  - Depuis un environnement sur site : utilisez des points de terminaison Private Service Connect pour les API Google et un DNS hybride pour que les clients sur site résolvent et atteignent les API via des liaisons hybrides privées, en évitant Internet.
- Si une route par défaut pointe vers un pare-feu tiers mais que vous souhaitez que les charges de travail privées le contournent pour les API Google, utilisez soit Private Service Connect, soit installez des routes statiques de plus haute priorité pour les plages d’adresses IP publiées des API Google vers la passerelle Internet par défaut, en combinaison avec Private Google Access sur les sous-réseaux.
Intégration DNS hybride
- Utilisez les zones privées de Cloud DNS pour la résolution de noms au sein du VPC. Étendez-la à l’environnement sur site avec :
  - Transfert entrant (inbound) : les résolveurs sur site transfèrent les requêtes à Cloud DNS pour les zones privées hébergées dans le VPC.
  - Transfert sortant (outbound) : les résolveurs du VPC transfèrent les requêtes pour des domaines sélectionnés vers le DNS sur site.
  - Zones de peering pour la résolution inter-VPC dans les environnements Shared VPC ou multi-projets.
- Pour l’accessibilité privée des API, créez une zone privée mappant les noms d’hôte des API aux points de terminaison Private Service Connect ou aux VIP privées appropriées de Google lors de l’utilisation de Private Google Access, et assurez-vous que ces noms sont résolvables depuis l’environnement sur site via le transfert DNS.

Planification et Dépannage

Compromis entre bande passante, latence et coût
- VPN : le plus rapide à déployer, coût fixe le plus bas, débit par tunnel limité, surcharge CPU/crypto par bit plus élevée et latence généralement plus élevée par rapport aux liaisons privées.
- Dedicated Interconnect : débit le plus élevé et coût par bit le plus bas avec une latence prévisible ; coûts fixes et délais de mise en œuvre plus élevés (interconnexions, colocation).
- Partner Interconnect : solution intermédiaire ; tire parti de l’empreinte du fournisseur ; le SLA et la latence dépendent du chemin du partenaire.
- Placer les rattachements et les passerelles régionalement proches des charges de travail pour minimiser la latence. Utiliser un VPC partagé (Shared VPC) pour centraliser la connectivité dans un projet hôte tout en desservant plusieurs projets de service.
- Tenir compte de la symétrie du trafic, des exigences d’inspection et des domaines de défaillance. Éviter les points de défaillance uniques dans les chemins du dernier kilomètre sur site et du fournisseur.
Diagnostic systématique des problèmes de tunnel, de BGP et de routage
1. Établissement du tunnel
  - Vérifier la compatibilité de la version IKE : HA VPN nécessite IKEv2 ; si le pair ne prend en charge que IKEv1 ou un VPN basé sur des stratégies (policy-based), utiliser Classic VPN.
  - Vérifier les secrets partagés, les propositions (chiffrement, groupes DH), NAT-T et l’accessibilité des ports UDP 500/4500.
  - Confirmer les adresses IP des pairs et que chaque tunnel pointe vers une interface de pair distincte pour la redondance.
2. Santé de la session BGP
  - Confirmer les états BGP aux deux extrémités ; examiner l’état du Cloud Router. Si BFD est activé mais que les sessions sont instables (flap), assouplir les temporisateurs.
  - Valider la configuration de l’ASN ; des attentes non concordantes peuvent empêcher l’ECMP ou causer des surprises dans le choix du meilleur chemin.
  - S’assurer que l’adressage IP pour les sessions BGP utilise les adresses link-local ou RFC1918 correctes configurées sur l’interface du tunnel ou du rattachement.
3. Échange et propagation des routes
  - Vérifier le mode d’annonce du Cloud Router (DEFAULT vs CUSTOM). S’assurer que les sous-réseaux ou agrégats attendus sont exportés.
  - Inspecter les routes reçues sur le Cloud Router ; évaluer l’AS-path, le MED. Si un mode actif/passif est prévu, s’assurer que le MED ou la priorité de la route annoncée reflète cette intention.
  - Vérifier le mode de routage dynamique du VPC (REGIONAL vs GLOBAL) pour que les routes apprises apparaissent là où c’est nécessaire. Rappelez-vous que les routes de sous-réseau ne peuvent pas être surchargées.
  - En cas de conflit, si une route statique et une route dynamique correspondent à la même longueur de préfixe, la route statique avec la priorité la plus basse l’emporte. Ajuster ou supprimer les routes statiques qui se chevauchent si ce n’est pas intentionnel.
4. Validation du plan de données
  - Utiliser les VPC Flow Logs et les journaux Cloud NAT pour confirmer le chemin de sortie et la traduction d’adresse. Si une VM sort toujours avec son adresse IP externe, supprimer cette IP externe pour forcer le NAT.
  - Pour Interconnect, vérifier l’état opérationnel du rattachement et que les deux rattachements sont activés administrativement et associés au bon Cloud Router.
  - Confirmer que les règles de pare-feu autorisent le trafic BGP et applicatif ; rappelez-vous que les plages sources des vérifications de santé de Google doivent être autorisées à atteindre les backends du load balancer.
5. Spécificités de la mise en service d’Interconnect
  - Obtenir le LOA-CFA depuis la console ou par e-mail de contact du NOC. Confirmer les niveaux de lumière de l’interconnexion et le marquage VLAN (VLAN tagging) avec le fournisseur avant la mise en service de BGP.

Scénario de Problème Pratique

Contoso Manufacturing migre ses charges de travail ERP vers Google Cloud tout en maintenant ses usines sur site en ligne. Exigences : connectivité privée de 20 Gbit/s avec basculement en moins d’une seconde, contrôle de routage centralisé, sortie sur site actif/passif vers le Cloud, accès privé aux API Google sans passer par l’internet public, et surcharge opérationnelle minimale.

Approche :

Déployer deux liaisons Dedicated Interconnect dans la même métropole à travers des domaines de disponibilité de périphérie et des installations distincts ; créer deux rattachements VLAN par région (primaire et secondaire) et les associer à un Cloud Router régional.
- Justification : Dedicated Interconnect fournit le débit agrégé requis et une latence prévisible. Les liaisons et rattachements redondants isolent les pannes et sont éligibles à un SLA plus élevé. Plusieurs rattachements permettent l’ECMP et la maintenance sans perte de trafic.
Configurer un seul Cloud Router par région avec deux pairs BGP — un par rattachement — et activer BFD.
- Justification : Un seul routeur simplifie la gestion du plan de contrôle tout en prenant en charge l’ECMP sur plusieurs sauts suivants. BFD réduit la détection des pannes à quelques secondes, améliorant le RTO de convergence pour l’application ERP.
Standardiser sur le même ASN distant sur site sur les deux routeurs de périphérie d’usine qui communiquent avec Google, et annoncer des préfixes identiques depuis chacun.
- Justification : Des ASN distants correspondants permettent au Cloud Router d’installer des chemins à coût égal et de répartir la charge lorsque cela est souhaité. Si des ASN différents étaient utilisés, un seul ensemble de routes pourrait être installé, annulant le multi-chemin.
Implémenter une préférence actif/passif depuis le site vers Google en utilisant le MED, et de Google vers le site en utilisant la priorité de route annoncée du Cloud Router ; définir des valeurs plus basses sur les chemins primaires.
- Justification : Une politique bilatérale assure une directionnalité déterministe : les usines préfèrent la métropole primaire pour atteindre le Cloud, et le VPC de Contoso préfère le DC de l’usine primaire pour le trafic de retour. Cela évite une asymétrie non intentionnelle.
Activer Private Service Connect pour les API Google dans le VPC partagé et créer une zone DNS privée mappant les noms d’hôte des API au point de terminaison PSC ; configurer la redirection entrante de Cloud DNS pour que les résolveurs sur site puissent résoudre ces noms en privé.
- Justification : PSC fournit un accès privé, au sein du VPC, aux API Google. Le DNS hybride rend ces points de terminaison accessibles depuis les usines via Interconnect, éliminant l’exposition à internet et les dépendances au pare-feu pour les services de support de l’ERP.
Pour la sauvegarde VPN, ajouter une passerelle HA VPN dans chaque région avec deux tunnels vers des appareils sur site distincts ; activer BFD sur les sessions BGP et autoriser l’ECMP.
- Justification : Si Interconnect est défaillant, HA VPN maintient l’accessibilité privée. Deux tunnels par appareil maintiennent le SLA et la continuité du débit, et BFD accélère le basculement.
Pour la sortie des charges de travail privées vers internet et les destinations non-Google, configurer un Cloud NAT régional sur les sous-réseaux ERP ; ne pas attribuer d’adresses IP externes aux VM.
- Justification : Cloud NAT met à l’échelle la traduction sans la surcharge de gestion des VM et préserve l’adressage privé. La suppression des IP externes garantit que le NAT est utilisé et simplifie les contrôles de sortie.
Valider le routage et le basculement avec des tests par étapes : déconnecter un rattachement, puis un routeur sur site, puis simuler une dégradation de la liaison ; surveiller BGP, BFD et les SLO applicatifs. Ajuster les temporisateurs BFD en cas d’instabilité (flaps).
- Justification : L’injection de fautes contrôlée vérifie que la conception atteint les objectifs de récupération et prévient les surprises en production. L’ajustement des temporisateurs équilibre la stabilité et la réactivité.