Google PCNE: Routing, Network Connectivity Center en Segmentatie — 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

Dit gedeelte behandelt routering, Network Connectivity Center (NCC) en segmentatiepatronen in Google Cloud. Het richt zich op hoe routes worden aangemaakt en geselecteerd, hoe VPC’s en organisaties met elkaar verbonden kunnen worden met behoud van isolatie, hoe schaalbare transit- en service-insertion-ontwerpen gebouwd kunnen worden, en hoe storingen gevalideerd en beperkt kunnen worden.

Basisprincipes en beheer van routering

• Routetypes

  • Door het systeem gegenereerde subnetroutes: Eén per primair en secundair subnetbereik; hebben altijd de hoogste voorkeur voor hun exacte prefixes.
  • Standaardroute naar de internetgateway: Automatisch aangemaakt in nieuwe VPC’s; kan worden verwijderd of overschreven.
  • Statische routes: Aangepaste prefixes met next hops zoals de standaard internetgateway, een specifieke instance, een interne TCP/UDP load balancer (ILB) als next hop, of een Cloud VPN-tunnel. Policy-based routes voegen match-condities toe (tags, serviceaccounts, protocol/poort) en sturen verkeer naar een instance of ILB als next hop voor geavanceerde service-insertion.
  • Dynamische routes: Geleerd via Cloud Router over BGP van Cloud VPN of Cloud Interconnect. Hun bereik wordt bepaald door de dynamische routeringsmodus van de VPC (regionaal of globaal).

• Routeselectie

  • Eerst de langste prefix-match.
  • Als meerdere routes dezelfde prefixlengte hebben, wint de route met de laagste numerieke prioriteit (standaard 1000 voor aangepaste routes). Vermijd overlappingen van gelijke prefixes over statische/dynamische paden; ontwerp het systeem zo dat één pad eenduidig de voorkeur krijgt.
  • Gelijke standen na prioriteit worden opgelost via platforminterne tie-breakers; vertrouw hier niet op.

• Next-hop-keuzes en service-insertion

  • Om egress te centraliseren of L3/L7-services in te voegen, wijs je een 0.0.0.0/0 statische route of policy-based routes naar een ILB als next hop waarvan de backends network virtual appliances (NVA’s) zijn.
  • Wanneer appliances omzeild moeten worden voor Google API’s door instances zonder externe IP’s, schakel dan Private Google Access in op de subnets en voeg aangepaste statische routes toe voor de gepubliceerde Google API’s VIP-bereiken naar de standaard internetgateway. Dit behoudt private toegang tot Google-services, terwijl ander egress-verkeer het NGFW-pad volgt.

• Dynamische routeringsmodus en multi-region-gedrag

  • Regionaal: Routes die door een Cloud Router worden geleerd, worden alleen geïnstalleerd voor subnets in dezelfde regio.
  • Globaal: Routes die waar dan ook worden geleerd, worden geïnstalleerd voor alle regio’s in de VPC, wat eenvoudige multi-region-connectiviteit en verminderde operationele overhead voor hub-and-spoke-ontwerpen mogelijk maakt. Voor gebruikers en workloads in de buurt van us-east1 en europe-west1, stelt een enkele VPC met regionale subnets en globale dynamische routering hen in staat om privé te communiceren via RFC1918 met optimale efficiëntie.

• Beheer van route-advertenties

  • Cloud Router kan alle subnets of een aangepaste set prefixes (inclusief een standaardroute) adverteren naar on-premises. Beheer de selectie van inkomende on-prem-paden met standaard BGP-tools (MED, AS-path prepending, local preference on-prem). Voor een actief/stand-by-configuratie richting on-premises, stel een lagere MED in op het primaire pad en een hogere MED op het stand-by-pad.
  • Vermijd het adverteren van dezelfde prefix vanaf verschillende on-prem-peers met verschillende ASN’s naar dezelfde Cloud Router; voor dual-homed ECMP of een zuivere failover, gebruik hetzelfde peer-ASN op redundante on-prem-routers.

VPC-interconnectiviteit en -segmentatie

• VPC Network Peering

  • Maakt private RFC1918-connectiviteit mogelijk tussen VPC’s met lage latentie en zonder data-plane-appliances. Het wisselt standaard subnetroutes uit en kan optioneel aangepaste routes (statisch en dynamisch) importeren/exporteren om de bereikbaarheid uit te breiden naar resources achter Cloud VPN/Interconnect. Er is geen transitieve routering: routes die van een peer worden geleerd, worden niet opnieuw geëxporteerd naar een andere peer.
  • Faalmodi en limieten: Geen overlappende CIDR’s; firewallregels blijven per VPC onafhankelijk; de bandbreedte is hoog maar geen vervanging voor load balancers; asymmetrische routering over een mesh-peering wordt niet ondersteund. Om drie VPC’s in een driehoek te verbinden, configureer je een volledige mesh van peering-paren; Sales↔Finance en Marketing↔Finance maken Sales↔Marketing niet mogelijk, tenzij dat paar ook is gepeerd.
  • Adresplanning: Bij het peeren van een auto-mode VPC (die 10.128.0.0/9 reserveert), maak de peer aan in custom mode met een niet-overlappende CIDR zoals 10.0.0.0/9.

• Shared VPC en multi-project-connectiviteit

  • Een hostproject is eigenaar van de VPC; serviceprojecten koppelen aan geselecteerde subnets. Dit centraliseert netwerken en hybride connectiviteit (Cloud Routers, Cloud NAT, Interconnect) en maakt tegelijkertijd gedelegeerd applicatie-eigendom per project mogelijk. Plaats VLAN-attachments en Cloud Routers voor Dedicated Interconnect in het hostproject om kostenefficiënte, gecentraliseerde on-prem-connectiviteit te bieden aan alle serviceprojecten.
  • Least privilege: Netwerkbeheerders (Network Admins) beheren routering en subnets; Beveiligingsbeheerders (Security Admins) beheren firewallregels en -beleid. Als je met Network Admin-rechten geen firewalls kunt bijwerken, vraag dan Security Admin-rechten aan binnen de scope van de Shared VPC.
  • Segmentatie: Deel alleen de specifieke subnets die een serviceproject nodig heeft. Dit sluit aan bij de best practices van Google om de blootstelling van routes tussen Productie en Staging strak te beheren.

• Controles voor netwerkisolatie

  • VPC-grenzen: Geen routering tussen VPC’s zonder expliciete peering, VPN of Private Service Connect. Gebruik afzonderlijke VPC’s voor afdelingen of tenants die volledig geïsoleerd moeten zijn; peer alleen diegenen die connectiviteit nodig hebben om de operationele overhead te minimaliseren.
  • Firewallbeleid: Gebruik hiërarchisch firewallbeleid op organisatie-/mapniveau voor consistente guardrails en per-VPC-regels voor lokale uitzonderingen. De standaardinstelling ‘ingress deny/egress allow’ kan worden aangescherpt.
  • Perimeters: Gebruik VPC Service Controls om de toegang tot Google API’s te beperken en de risico’s op data-exfiltratie over projecten en netwerken te beperken.
  • Blootstelling aan IPv6: Voor publieke IPv6-toegang, wijs IPv6 toe aan een globale externe HTTP(S)-loadbalancer die als frontend voor je service fungeert. De backends blijven privé.

Network Connectivity Center en transit-architecturen

• NCC hub-and-spoke

  • De hub levert een control-plane voor routing tussen spokes. Spokes omvatten VLAN attachments (Interconnect), HA VPN-tunnels, router appliance spokes en ondersteunde VPC-spokes voor site-to-site data transfer. NCC-routetabellen bepalen welke prefixes worden geïmporteerd/geëxporteerd en welke spokes ze ontvangen, wat nauwkeurige segmentatie mogelijk maakt.
  • Site-to-site data transfer stelt on-prem-locaties in staat elkaar te bereiken via de backbone van Google, waarbij de hub als transit wordt gebruikt, waardoor de noodzaak voor transit van derden wordt verminderd en de operaties worden vereenvoudigd.

• Router appliance spokes en NVA’s van derden

  • Router appliance spokes onboarden virtuele routers/firewalls die op Compute Engine worden gehost als transit- of inline-services. Gebruik ILB als next hop om schaalbaarheid en health-checked failover over meerdere appliances te realiseren.
  • HA-ontwerp: Implementeer ten minste twee appliances in verschillende zones; plaats ze waar mogelijk achter een ILB met een MIG; schakel IP forwarding in op instances; gebruik symmetric steering met ILB als next hop; verdeel de belasting met policy-based routes op basis van tags of service accounts.
  • Afwegingen voor doorvoer en storingen: NVA’s worden beperkt door het instance type en de NIC-bandbreedte; plan voor horizontale schaalbaarheid. Een storing van een appliance of een mislukte health check activeert de verwijdering door de ILB en een snelle failover, maar zorg ervoor dat de route convergence timers en health thresholds zijn afgestemd om ‘flaps’ te voorkomen.

• Afwegingen van transit-topologie

  • Hub-and-spoke met NCC: Centraal beleid, hoge schaalbaarheid, duidelijke controle over de blast-radius; vereist een ontwerp van de routetabel en een duidelijke import/export-intentie.
  • Full mesh peering: Eenvoudig voor een klein aantal VPC’s, geen centrale transit, maar schaalt slecht en kan geen transitiviteit of service insertion bieden.
  • Gecentraliseerde egress: Eenvoudige beveiligingshandhaving via één NGFW of NAT; kan latency toevoegen en een knelpunt worden; beperk dit met regionale egress-punten en autoscaling.
  • Mesh VPN met Cloud Routers: Flexibel en snel te implementeren; operationele overhead stijgt met het aantal peers; overweeg NCC om te consolideren.

• Overwegingen voor Cloud VPN

  • Als het on-prem-apparaat geen BGP ondersteunt, gebruik dan policy-based Cloud VPN met statische routes en zorgvuldig afgebakende traffic selectors; plan een uiteindelijke migratie naar HA VPN met BGP om de overhead op de lange termijn te minimaliseren.
  • Voor active/standby-tunnels richting on-prem, manipuleer MED of AS-path on-prem. Voor dubbele on-prem-routers die verbinding maken met één Cloud Router, geef de voorkeur aan identieke peer-ASN’s om de installatie van beide paden en ECMP mogelijk te maken; het gebruik van verschillende peer-ASN’s resulteert er doorgaans in dat slechts één pad wordt geselecteerd.

Operations: validatie, analyse en inperking van storingen

• Connectiviteitsvalidatie en route-analyse

  • Gebruik de Connectivity Tests van het Network Intelligence Center om het datapad te traceren over VM’s, load balancers, VPC-peering, Cloud VPN en Interconnect, en valideer firewallregels en routes.
  • Analyseer effectieve routes per VM/subnet om next hops en dynamische prefixes te bevestigen; verifieer dat de scope van de dynamische routeringsmodus overeenkomt met de bedoeling.
  • Geef bij prestatie- of gebruikerservaringsproblemen de voorkeur aan globale HTTP(S) load balancing om de latentie voor wereldwijde gebruikers te verminderen via anycast ingress en edge termination; network load balancers zijn regionaal en verbeteren de globale latentie niet.

• Inperking van storingen en reductie van de ‘blast radius’

  • Segmenteer via VPC’s, NCC-routetabellen en Shared VPC-subnets per project om onbedoelde verspreiding van storingen of misconfiguraties te voorkomen.
  • Vermijd transitieve afhankelijkheden via peering; waar transit vereist is, gebruik NCC en gecontroleerde import/export om de bereikbaarheid te beperken.
  • Gebruik gecentraliseerde firewall-policies op organisatieniveau voor basis deny/allow en lokale policies voor applicatie-uitzonderingen; test wijzigingen met Connectivity Tests.
  • Waar inline beveiliging vereist is, implementeer een next-hop ILB met health checks en policy-based routing voor een graceful failover. Zorg ervoor dat kritieke Google API’s bereikbaar zijn via Private Google Access of Cloud NAT zonder afhankelijk te zijn van externe IP’s.
  • Monitor BGP-sessies en routewijzigingen; standaardiseer metrics (MED, local preference) en adresplannen om route-oscillatie en asymmetrische flows te voorkomen.

• Korte configuratievoorbeelden

  • Maak een statische route om verkeer door een inline ILB te sturen:

undefined

• Geef de voorkeur aan een van de twee BGP-paden inbound naar on-prem met behulp van MED (op de on-prem router):

undefined

Praktisch Probleemscenario

Acme Retail is actief in een Google Cloud-organisatie met meerdere projecten, met twee gebruikerspopulaties in de buurt van us-east1 en europe-west1. Ze hebben behoefte aan private, goedkope communicatie tussen workloads in verschillende regio’s, gecentraliseerde on-prem connectiviteit en inline URL-filtering voor internet-egress, terwijl de Financiële afdeling geïsoleerd moet blijven van Engineering.

1. Bouw een enkele Shared VPC in een hostproject met regionale subnets in us-east1 en europe-west1, en stel de dynamische routeringsmodus in op global.

• Rationale: Eén VPC maakt directe RFC1918-communicatie tussen regio’s mogelijk zonder de overhead van peering. Globale dynamische routering installeert geleerde hybride routes in alle regio’s, wat de operations vereenvoudigt en efficiënte intra-VPC-flows garandeert.

2. Deel alleen de benodigde subnets met elk serviceproject; plaats Finance en Engineering in afzonderlijke serviceprojecten.

• Rationale: Delen op subnetniveau zorgt voor organisatorische segmentatie en minimaliseert onbedoelde blootstelling van routes. Finance blijft geïsoleerd door simpelweg de subnets van Engineering niet te delen en door afzonderlijke scopes voor firewall-policies.

3. Termineer Dedicated Interconnect in het hostproject en koppel Cloud Routers; adverteer alleen de noodzakelijke prefixes met behulp van custom advertisements.

• Rationale: Gecentraliseerde hybride connectiviteit verlaagt de kosten en complexiteit, terwijl de controle behouden blijft over wat on-prem bereikt. Custom advertisements voorkomen overmatige blootstelling en beperken de ‘blast radius’.

4. Voeg een inline L7 URL-filtering appliance toe achter een regionale internal TCP/UDP load balancer; stuur egress-verkeer met een 0.0.0.0/0 statische route naar de ILB next hop in elke regio.

• Rationale: ILB next hop plus health checks biedt HA service insertion met symmetrische flows over de appliances. Statische routes met een hogere prioriteit dan de default route zorgen ervoor dat al het egress-verkeer wordt gefilterd.

5. Zorg ervoor dat instances zonder externe IP’s de Google API’s rechtstreeks kunnen bereiken: schakel Private Google Access in op alle subnets en voeg statische routes voor de Google API’s VIP-ranges toe naar de default internet gateway om de appliance te omzeilen.

• Rationale: Private Google Access behoudt private toegang tot BigQuery en Pub/Sub; custom routes voorkomen onnodige ‘hairpinning’ via het filter, wat kosten en latentie vermindert.

6. Houd Finance geïsoleerd: weiger verkeer tussen projecten in hiërarchische firewall-policies en configureer geen peering tussen Finance en Engineering. Waar samenwerking tussen Engineering en Analytics nodig is, creëer een specifiek gepaired VPC-paar met niet-overlappende CIDR’s.

• Rationale: VPC-grenzen, de afwezigheid van peering en firewall-policies op organisatieniveau dwingen isolatie af. Gerichte peering biedt lage operationele overhead voor specifieke connectiviteit tussen afdelingen zonder transitiviteit.

7. Valideer en monitor: gebruik Connectivity Tests om de bereikbaarheid tussen regio’s en de appliance-insertie te verifiëren; monitor de BGP-status en routetabellen van Cloud Router; implementeer MED op on-prem routers voor active/standby failover als er meerdere tunnels bestaan.

• Rationale: Proactieve validatie detecteert misconfiguraties vroegtijdig. BGP-controles houden on-prem paden deterministisch tijdens onderhoud of storingen, terwijl telemetrie van NCC/Cloud Router het troubleshooten versnelt.

Dit ontwerp voldoet aan de eisen van Acme Retail met minimale kosten en hoge efficiëntie: private multi-region routing in één VPC, gecentraliseerde hybride connectiviteit, gecontroleerde service insertion en sterke organisatorische segmentatie.

← Private Connectiviteit naar Google en Beheerde Services · Alle domeinen · GKE →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Google →