Google PCNE: Hybride Connectiviteit, Cloud Router en BGP — Studiegids

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

Onderdeel van de Google Professional Cloud Network Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Hybride connectiviteit op Google Cloud maakt private, gecontroleerde communicatie mogelijk tussen VPC-netwerken en externe netwerken, zoals on-premise datacenters of andere clouds. De kerncomponenten zijn HA VPN- en Cloud VPN-gateways, Cloud Router met BGP voor dynamische routering, en Interconnect met VLAN-attachments. Ontwerpen moeten een balans vinden tussen bandbreedte, latency, betrouwbaarheid, operationele complexiteit en kosten, terwijl deterministisch routeringsgedrag en isolatie van storingsdomeinen worden gevolgd. Dit gedeelte behandelt ontwerp- en operationele overwegingen, veelvoorkomende storingsmodi en systematische probleemoplossing.

Hybride Connectiviteit: HA VPN, Cloud Router en Interconnect

HA VPN en Cloud VPN
- HA VPN is een regionale, hoogbeschikbare IPsec VPN die IKEv2 ondersteunt en Cloud Router vereist voor dynamische routering (eBGP). Een HA VPN-gateway heeft twee interfaces; voor SLA en ECMP, bouw twee tunnels per interface naar afzonderlijke peer-eindpunten.
- Classic Cloud VPN ondersteunt IKEv1 of IKEv2 en statische of route-gebaseerde tunnels; het ondersteunt de HA VPN SLA niet. Gebruik het alleen wanneer peers geen BGP hebben of wanneer u policy-based selectors moet gebruiken.
- Peer-gateway is het externe VPN-apparaat/IP-adres. Voor HA VPN, definieer een peer VPN-gateway met een of meer publieke IP’s om afzonderlijke interfaces of apparaten voor redundantie te modelleren.
- SLA-ontwerp: Om in aanmerking te komen voor de 99,99% SLA van HA VPN, implementeer redundante tunnels over onafhankelijke on-premise apparaten of interfaces en gebruik dynamische routering. Classic VPN wordt niet ondersteund door een SLA.
- Doorvoerschalering: Een enkele IPsec-tunnel heeft een eindige doorvoercapaciteit. Gebruik ECMP over meerdere tunnels om de totale doorvoercapaciteit te verhogen. Bereik dit door extra tunnels te termineren op unieke publieke IP’s van de peer.
Cloud Router en BGP
- Cloud Router is een regionale control-plane-service die BGP-sessies opzet met VPN-tunnels of Interconnect VLAN-attachments en routes dynamisch uitwisselt.
- De dynamische routeringsmodus (op VPC-niveau) bepaalt waar geleerde dynamische routes bruikbaar zijn en welke VPC-subnetroutes worden geadverteerd:
  - Regional: leer en gebruik/importeer dynamische routes alleen in dezelfde regio.
  - Global: leer en gebruik/importeer dynamische routes in alle regio’s; adverteer alle VPC-subnetroutes (globaal) naar peers.
Dedicated Interconnect en Partner Interconnect
- Dedicated Interconnect levert fysieke 10 Gbps of 100 Gbps circuits rechtstreeks naar Google in een colocatie-faciliteit. U verkrijgt een Letter of Authorization – Connecting Facility Assignment (LOA-CFA) om cross-connects mogelijk te maken. Maak VLAN-attachments (interconnect attachments) aan die 802.1Q-tags koppelen aan regionale L3-connectiviteit die is geassocieerd met een Cloud Router.
- Partner Interconnect biedt logische connectiviteit via een serviceprovider. U vraagt VLAN-attachments aan bij de partner; de bandbreedte wordt geleverd op de edge van de partner. Associeer de attachments nog steeds met Cloud Router voor BGP.
- Redundantie en SLA: Gebruik twee attachments in dezelfde regio, geplaatst op afzonderlijke edge availability domains (en, indien van toepassing, afzonderlijke fysieke interconnects) om hogere SLA’s te bereiken (bijv. 99,99%). Een enkele attachment of link verlaagt de SLA. Voor Partner Interconnect is de algehele SLA ook afhankelijk van de partner.
Cross-connects en VLAN-attachments
- Cross-connects zijn de fysieke glasvezelverbindingen tussen uw cage/apparatuur en de cage van Google in een meet-me room. Overhandig de LOA-CFA aan uw provider om ze te voltooien.
- VLAN-attachments zijn de logische L2-demarcatie naar een VPC-regio. Elke attachment:
  - Is geassocieerd met precies één VPC en regio via een Cloud Router.
  - Wordt in paren geconfigureerd voor redundantie en ECMP.
  - Vervoert alleen L3-verkeer; geen L2-extensie.

Kort voorbeeld:

Maak Cloud Router en BGP aan voor een attachment of HA VPN-peer: 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

Routing en BGP-gedrag

Dynamische versus statische routing
- Dynamische routing met Cloud Router zorgt voor automatisch leren van routes, convergentie en ECMP. Het schaalt en vermindert de operationele overhead naarmate netwerken groeien.
- Statische routing is geschikt wanneer peers geen BGP hebben of voor nauw afgebakende, deterministische paden. In een VPC hebben statische routes een numerieke prioriteit; lagere waarden hebben de voorkeur bij statische routes met dezelfde prefixlengte.
- Route-selectie in een VPC:
  - De langste prefix-match wint.
  - Subnet-routes kunnen niet worden overschreven door aangepaste routes.
  - Bij gelijke prefixlengtes worden statische routes geselecteerd op basis van de laagste prioriteit. Bij dynamische routes heeft Cloud Router de beste paden al bepaald voordat deze worden geïnstalleerd. De standaardroute van het systeem heeft de laagste voorkeur.
BGP-sessies, advertisement en import/export
- Cloud Router exporteert standaard VPC-subnets of een aangepaste set prefixes. U kunt 0.0.0.0/0 of geaggregeerde prefixes adverteren wanneer dat nodig is, maar dit trekt on-prem verkeer naar de cloud als het beleid dit toestaat; ontwerp dit weloverwogen.
- Cloud Router importeert alle toegestane on-premises prefixes en installeert deze als dynamische routes volgens de dynamische routingmodus van de VPC.
- Met de prioriteit van geadverteerde routes per peer kunt u beïnvloeden hoe on-prem routers het ene Google-pad boven het andere verkiezen; een lagere prioriteitswaarde vertaalt zich naar een meer geprefereerde MED richting de peer.
ASN’s, MED en active-standby
- Gebruik een uniek privé-ASN per administratief domein, tenzij openbare ASN’s gerechtvaardigd zijn. Voor meerdere on-prem routers die peeren met dezelfde VPC voor dezelfde prefixes:
  - Om ECMP of een consistent ‘best-path’ mogelijk te maken, gebruikt u hetzelfde on-prem remote ASN op alle routers die dezelfde prefixes adverteren. Verschillende remote ASN’s kunnen de installatie van ’equal-cost’ paden op Cloud Router verhinderen.
  - Voor active/standby, manipuleer de MED (lager heeft meer voorkeur) vanaf de on-prem kant, of pas de prioriteit van geadverteerde routes per peer van Cloud Router aan zodat on-prem de primaire verbinding verkiest. AS-path prepending is een alternatief, maar grofmaziger instrument.
Multipath-ontwerp
- Cloud Router ondersteunt ECMP over meerdere gelijke BGP-paden voor zowel HA VPN als Interconnect attachments. Zorg voor gelijke attributen (AS-path-lengte, MED, local-pref) en afzonderlijke ’next hops’. Voor HA VPN, termineer tunnels op afzonderlijke peer-IP’s. Voor Interconnect, gebruik redundante attachments.

Veerkracht, Detectie en Egress-Services

BFD en storingsdetectie
- BFD versnelt storingsdetectie voor BGP-sessies op HA VPN en Interconnect. Schakel BFD aan beide kanten in met compatibele intervallen om detectie binnen een subseconde of enkele seconden te bereiken, afhankelijk van uw stabiliteitsbehoeften. Combineer dit met IKE DPD op IPsec-tunnels. Zorg ervoor dat uw peer-apparaten het frequentere controleverkeer kunnen verwerken.
- Pas op voor asymmetrische detectie: agressieve BFD in combinatie met overbelaste verbindingen kan sessies laten ‘flappen’; begin met conservatieve timers en monitor de verbinding.
Redundante topologiepatronen
- HA VPN: Gebruik één HA VPN-gateway per regio en termineer tunnels naar twee afzonderlijke on-prem apparaten of interfaces. Bouw ten minste vier tunnels (twee per interface) en een Cloud Router per regio. Houd de remote ASN’s consistent wanneer u ECMP aanbiedt.
- Interconnect: Gebruik ten minste twee attachments in elke regio, verspreid over afzonderlijke ’edge availability domains’. Voor Dedicated Interconnect, implementeer verbindingen in verschillende ’edge devices’ en faciliteiten waar mogelijk.
Cloud NAT, externe adressen en egress voor private workloads
- Cloud NAT is een regionale, beheerde egress-oplossing voor resources zonder externe IP’s. Het past geen SNAT toe op instances die wel externe IP’s hebben; die gaan rechtstreeks naar buiten. Selecteer subnets of alle subnets in een regio om private workloads te dekken.
- Dimensioner NAT IP-pools voor gelijktijdige verbindingen en ’ephemeral ports’; kies voor handmatige of automatische IP-toewijzing. Schakel logging in voor diagnose.
- Om Google API’s privé te bereiken:
  - In-VPC: schakel Private Google Access in op subnets zodat VM’s zonder externe IP’s Google API’s kunnen bereiken via de virtuele IP’s van Google.
  - Vanaf on-prem: gebruik Private Service Connect-eindpunten voor Google API’s en hybride DNS zodat on-prem clients de API’s kunnen resolven en bereiken via private hybride verbindingen, en zo het internet vermijden.
- Als een standaardroute naar een firewall van een derde partij wijst, maar u wilt dat private workloads deze omzeilen voor Google API’s, gebruik dan Private Service Connect of installeer statische routes met een hogere prioriteit voor de gepubliceerde Google API IP-reeksen naar de standaard internetgateway, in combinatie met Private Google Access op de subnets.
Hybride DNS-integratie
- Gebruik Cloud DNS private zones voor naamresolutie binnen de VPC. Breid dit uit naar on-prem met:
  - Inbound forwarding: on-prem resolvers sturen verzoeken door naar Cloud DNS voor private zones die in de VPC worden gehost.
  - Outbound forwarding: VPC-resolvers sturen verzoeken voor geselecteerde domeinen door naar on-prem DNS.
  - Peering zones voor cross-VPC-resolutie in Shared VPC- of multi-projectomgevingen.
- Voor private bereikbaarheid van API’s, maak een private zone aan die API-hostnamen koppelt aan Private Service Connect-eindpunten of aan de juiste private VIP’s van Google bij gebruik van Private Google Access, en zorg ervoor dat die namen vanaf on-prem resolvable zijn via DNS-forwarding.

Planning en Troubleshooting

Afwegingen tussen bandbreedte, latency en kosten
- VPN: snelst te implementeren, laagste vaste kosten, beperkte doorvoer per tunnel, hogere per-bit CPU/crypto overhead en doorgaans hogere latency vergeleken met private links.
- Dedicated Interconnect: hoogste doorvoer en laagste kosten per bit met voorspelbare latency; hogere vaste kosten en langere levertijd (cross-connects, colocatie).
- Partner Interconnect: de middenweg; maakt gebruik van de footprint van de provider; SLA en latency zijn afhankelijk van het pad van de partner.
- Plaats attachments en gateways regionaal dicht bij workloads om latency te minimaliseren. Gebruik Shared VPC om connectiviteit te centraliseren in een hostproject terwijl meerdere serviceprojecten worden bediend.
- Houd rekening met verkeerssymmetrie, inspectievereisten en ‘failure domains’. Vermijd ‘single points of failure’ in de on‑prem ’last‑mile’ en providerpaden.
Systematische diagnose van tunnel-, BGP- en routeringsproblemen
1. Totstandkoming van de tunnel
  - Verifieer compatibiliteit van de IKE-versie: HA VPN vereist IKEv2; als de peer alleen IKEv1 of policy‑based VPN ondersteunt, gebruik dan Classic VPN.
  - Controleer ‘shared secrets’, ‘proposals’ (encryptie, DH-groepen), NAT‑T en de bereikbaarheid van UDP-poorten 500/4500.
  - Bevestig de peer-IP’s en dat elke tunnel naar een afzonderlijke peer-interface wijst voor redundantie.
2. Status van de BGP-sessie
  - Bevestig de BGP-statussen aan beide kanten; onderzoek de status van de Cloud Router. Als BFD is ingeschakeld maar sessies ‘flappen’ (instabiel zijn), versoepel dan de timers.
  - Valideer de ASN-configuratie; niet-overeenkomende verwachtingen kunnen ECMP voorkomen of verrassingen in de ‘best‑path’-selectie veroorzaken.
  - Zorg ervoor dat de IP-adressering voor BGP-sessies de juiste link-local- of RFC1918-adressen gebruikt die zijn geconfigureerd op de tunnel- of attachment-interface.
3. Uitwisseling en propagatie van routes
  - Controleer de ‘advertisement mode’ van de Cloud Router (DEFAULT vs CUSTOM). Zorg ervoor dat de verwachte subnets of aggregaties worden geëxporteerd.
  - Inspecteer de ontvangen routes op de Cloud Router; evalueer AS‑path, MED. Als een active/standby-opzet de bedoeling is, zorg er dan voor dat de MED of de prioriteit van de geadverteerde route die intentie weerspiegelt.
  - Verifieer de dynamische routeringsmodus van de VPC (REGIONAL vs GLOBAL) zodat geleerde routes verschijnen waar dat nodig is. Onthoud dat subnetroutes niet kunnen worden overschreven.
  - Bij conflicten, als een statische route en een dynamische route dezelfde prefixlengte hebben, wint de statische route met de laagste prioriteit. Pas overlappende statische routes aan of verwijder ze als dit onbedoeld is.
4. Validatie van het datavlak
  - Gebruik VPC Flow Logs en Cloud NAT-logs om het egress-pad en de adresvertaling te bevestigen. Als een VM nog steeds uitgaand verkeer stuurt met zijn externe IP, verwijder dan dat externe IP om NAT af te dwingen.
  - Voor Interconnect, verifieer de operationele staat van de attachment en dat beide attachments ‘admin‑enabled’ zijn en gekoppeld zijn aan de juiste Cloud Router.
  - Bevestig dat firewallregels BGP- en applicatieverkeer toestaan; onthoud dat de bronbereiken van Google-healthchecks toegang moeten hebben tot de backends van de load balancer.
5. Specifieke aandachtspunten bij de ingebruikname van Interconnect
  - Verkrijg de LOA‑CFA via de console of het NOC-contact-e-mailadres. Bevestig de lichtniveaus van de cross‑connect en VLAN-tagging met de provider voordat BGP wordt geactiveerd.

Praktijkscenario

Contoso Manufacturing migreert ERP-workloads naar Google Cloud terwijl de on‑prem fabrieken online blijven. Vereisten: 20 Gbps private connectiviteit met failover binnen een subseconde, gecentraliseerd routeringsbeheer, active/standby on‑prem egress naar de Cloud, private toegang tot Google API’s zonder publiek internet, en minimale operationele overhead.

Aanpak:

Implementeer twee Dedicated Interconnect-verbindingen in dezelfde metro, verspreid over verschillende ’edge availability domains’ en faciliteiten; creëer twee VLAN-attachments per regio (primair en secundair) en koppel deze aan een regionale Cloud Router.
- Rationale: Dedicated Interconnect levert de vereiste geaggregeerde doorvoer en voorspelbare latency. Redundante verbindingen en attachments isoleren storingen en komen in aanmerking voor een hogere SLA. Meerdere attachments maken ECMP en onderhoud zonder verkeersverlies mogelijk.
Configureer één Cloud Router per regio met twee BGP-peers—één per attachment—en schakel BFD in.
- Rationale: Eén enkele router vereenvoudigt het beheer van het controlevlak en ondersteunt tegelijkertijd ECMP over meerdere ’next hops’. BFD reduceert de detectietijd van storingen tot enkele seconden, wat de RTO voor convergentie van de ERP-applicatie verbetert.
Standaardiseer op hetzelfde on‑prem remote ASN op beide edge routers van de fabriek die peeren met Google, en adverteer identieke prefixes vanaf elk.
- Rationale: Overeenkomende remote ASN’s stellen de Cloud Router in staat om ’equal‑cost paths’ te installeren en load-balancing toe te passen indien gewenst. Als verschillende ASN’s zouden worden gebruikt, zou mogelijk slechts één set routes worden geïnstalleerd, wat multipath tenietdoet.
Implementeer een active/standby-voorkeur van on‑prem naar Google met behulp van MED, en van Google naar on‑prem met behulp van de ‘advertised route priority’ van de Cloud Router; stel lagere waarden in op de primaire paden.
- Rationale: Een tweezijdig beleid zorgt voor deterministische directionaliteit: de fabrieken geven de voorkeur aan de primaire metro om de Cloud te bereiken, en Contoso’s VPC geeft de voorkeur aan het primaire fabrieks-datacenter voor retourverkeer. Dit voorkomt onbedoelde asymmetrie.
Schakel Private Service Connect voor Google API’s in de Shared VPC in en creëer een private DNS-zone die API-hostnamen naar het PSC-eindpunt mapt; configureer Cloud DNS ‘inbound forwarding’ zodat on‑prem resolvers deze namen privaat kunnen resolven.
- Rationale: PSC biedt private, in‑VPC toegang tot Google API’s. Hybride DNS maakt deze eindpunten bereikbaar vanuit de fabrieken via Interconnect, waardoor blootstelling aan het internet en afhankelijkheden van firewalls voor de ondersteunende diensten van de ERP worden geëlimineerd.
Voeg voor VPN-backup een HA VPN-gateway toe in elke regio met twee tunnels naar verschillende on‑prem apparaten; schakel BFD in op BGP-sessies en sta ECMP toe.
- Rationale: Als Interconnect is verstoord, handhaaft HA VPN de private bereikbaarheid. Dubbele tunnels per apparaat zorgen voor continuïteit van SLA en doorvoer, en BFD versnelt de failover.
Configureer voor private workload-egress naar het internet en niet‑Google-bestemmingen regionale Cloud NAT op ERP-subnets; wijs geen externe IP’s toe aan de VM’s.
- Rationale: Cloud NAT schaalt de adresvertaling zonder beheeroverhead voor VM’s en behoudt private adressering. Het verwijderen van externe IP’s garandeert dat NAT wordt gebruikt en vereenvoudigt de egress-controles.
Valideer de routering en failover met gefaseerde tests: verbreek één attachment, dan één on‑prem router, en simuleer vervolgens linkdegradatie; monitor BGP, BFD en de SLO’s van de applicatie. Pas BFD-timers aan als er ‘flaps’ optreden.
- Rationale: Gecontroleerde ‘fault injection’ verifieert dat het ontwerp voldoet aan de hersteldoelstellingen en voorkomt verrassingen in productie. Het aanpassen van timers balanceert stabiliteit en reactiesnelheid.