Google PCNE: Instradamento, Network Connectivity Center e segmentazione — Guida allo studio

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

Fa parte della Google Professional Cloud Network Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Questa sezione illustra il routing, il Network Connectivity Center (NCC) e i pattern di segmentazione in Google Cloud. Si concentra su come le route vengono create e selezionate, come interconnettere VPC e organizzazioni preservando l’isolamento, come costruire design scalabili per il transito e l’inserimento di servizi (service-insertion) e come convalidare e contenere i guasti.

Fondamenti e controllo del routing

• Tipi di route

  • Route di sottorete generate dal sistema: una per ogni intervallo di sottorete primario e secondario; sempre le più preferite per i loro prefissi esatti.
  • Route predefinita verso l’internet gateway: creata automaticamente nei nuovi VPC; può essere rimossa o sovrascritta.
  • Route statiche: prefissi personalizzati con next hop come l’internet gateway predefinito, un’istanza specifica, un bilanciatore del carico TCP/UDP interno (ILB) come next hop o un tunnel Cloud VPN. Le route basate su policy (policy-based routes) aggiungono condizioni di corrispondenza (tag, account di servizio, protocollo/porta) e indirizzano il traffico verso un’istanza o un ILB come next hop per l’inserimento avanzato di servizi.
  • Route dinamiche: apprese tramite Cloud Router via BGP da Cloud VPN o Cloud Interconnect. Il loro ambito è controllato dalla modalità di routing dinamico del VPC (regionale o globale).

• Selezione della route

  • Prima la corrispondenza del prefisso più lungo (longest prefix match).
  • Se più route hanno la stessa lunghezza del prefisso, vince la priorità di route con il valore numerico più basso (predefinito 1000 per le route personalizzate). Evitare sovrapposizioni di prefissi uguali tra percorsi statici e dinamici; progettare in modo da preferirne uno in modo inequivocabile.
  • Gli spareggi oltre la priorità vengono risolti tramite meccanismi interni alla piattaforma; non fare affidamento su di essi.

• Scelte del next-hop e inserimento di servizi

  • Per centralizzare l’uscita (egress) o inserire servizi L3/L7, puntare una route statica 0.0.0.0/0 o delle policy-based routes verso un ILB come next hop i cui backend sono appliance virtuali di rete (NVA).
  • Quando le appliance devono essere bypassate per le API di Google da istanze senza IP esterni, abilitare l’Accesso Privato Google (Private Google Access) sulle sottoreti e aggiungere route statiche personalizzate per gli intervalli VIP delle API di Google pubblicate verso l’internet gateway predefinito. Ciò preserva l’accesso privato ai servizi Google mentre l’altro traffico in uscita segue il percorso del NGFW.

• Modalità di routing dinamico e comportamento multi-regionale

  • Regionale: le route apprese da un Cloud Router vengono installate solo per le sottoreti nella stessa regione.
  • Globale: le route apprese ovunque vengono installate per tutte le regioni nel VPC, abilitando una connettività multi-regionale semplice e riducendo l’overhead operativo per i design hub-and-spoke. Per utenti e carichi di lavoro vicini a us-east1 e europe-west1, un singolo VPC con sottoreti regionali e routing dinamico globale consente loro di comunicare privatamente su RFC1918 con efficienza ottimale.

• Controllo dell’advertisement delle route

  • Cloud Router può annunciare (advertise) tutte le sottoreti o un set personalizzato di prefissi (inclusa una route predefinita) verso l’ambiente on-premise. Controllare la selezione del percorso in entrata dall’on-premise (inbound-on-prem) utilizzando strumenti BGP standard (MED, AS-path prepending, local preference on-prem). Per una configurazione attivo/standby verso l’on-premise, impostare un MED più basso sul percorso primario e un MED più alto su quello di standby.
  • Evitare di annunciare lo stesso prefisso da peer on-premise diversi con ASN differenti allo stesso Cloud Router; per ECMP dual-homed o un failover pulito, utilizzare lo stesso ASN del peer sui router on-premise ridondanti.

Interconnettività e segmentazione dei VPC

• VPC Network Peering

  • Abilita la connettività privata RFC1918 tra VPC con bassa latenza e senza appliance sul data plane. Scambia le route delle sottoreti per impostazione predefinita e può opzionalmente importare/esportare route personalizzate (statiche e dinamiche) per estendere la raggiungibilità alle risorse dietro Cloud VPN/Interconnect. Non esiste routing transitivo: le route apprese da un peer non vengono riesportate a un altro peer.
  • Modalità di guasto e limiti: nessun CIDR sovrapposto; le regole firewall rimangono indipendenti per ogni VPC; la larghezza di banda è elevata ma non sostituisce i bilanciatori del carico; il routing asimmetrico attraverso un peering a mesh non è supportato.
  • Per connettere tre VPC in un triangolo, configurare una mesh completa di coppie di peering; Vendite↔Finanza e Marketing↔Finanza non abilitano la comunicazione Vendite↔Marketing a meno che anche quella coppia non sia in peering.
  • Pianificazione degli indirizzi: quando si effettua il peering con un VPC in modalità automatica (che riserva 10.128.0.0/9), creare il VPC peer in modalità personalizzata con un CIDR non sovrapposto, come 10.0.0.0/9.

• Shared VPC e connettività multi-progetto

  • Un progetto host possiede il VPC; i progetti di servizio si collegano a sottoreti selezionate. Questo centralizza il networking e la connettività ibrida (Cloud Routers, Cloud NAT, Interconnect) consentendo al contempo la delega della proprietà delle applicazioni per progetto. Posizionare gli allegati VLAN (VLAN attachment) e i Cloud Router per Dedicated Interconnect nel progetto host per fornire una connettività on-premise centralizzata ed efficiente in termini di costi a tutti i progetti di servizio.
  • Principio del privilegio minimo (Least privilege): i Network Admin gestiscono il routing e le sottoreti; i Security Admin gestiscono le regole e le policy firewall. Se non è possibile aggiornare i firewall con il ruolo di Network Admin, richiedere il ruolo di Security Admin nell’ambito dello Shared VPC.
  • Segmentazione: condividere solo le sottoreti specifiche richieste da un progetto di servizio. Questo si allinea con le best practice di Google per controllare strettamente l’esposizione delle route tra gli ambienti di Produzione e Staging.

• Controlli di isolamento della rete

  • Confini del VPC: nessun routing tra VPC senza peering esplicito, VPN o Private Service Connect. Utilizzare VPC separati per dipartimenti o tenant che devono essere completamente isolati; effettuare il peering solo di quelli che necessitano di connettività per minimizzare l’overhead operativo.
  • Policy firewall: utilizzare policy firewall gerarchiche a livello di organizzazione/cartella per avere linee guida (guardrail) coerenti e regole per-VPC per le eccezioni locali. L’impostazione predefinita di negazione in ingresso (ingress deny) e permesso in uscita (egress allow) può essere resa più restrittiva.
  • Perimetri: utilizzare VPC Service Controls per limitare l’accesso alle API di Google e mitigare i rischi di esfiltrazione dei dati tra progetti e reti.
  • Esposizione IPv6: per l’accesso pubblico IPv6, assegnare un indirizzo IPv6 a un bilanciatore del carico HTTP(S) esterno globale che funge da frontend per il servizio. I backend rimangono privati.

Network Connectivity Center e architetture di transito

• Hub-and-spoke con NCC

  • L’hub fornisce un control plane per il routing tra gli spoke. Gli spoke includono VLAN attachment (Interconnect), tunnel HA VPN, spoke di router appliance e spoke VPC supportati per il trasferimento dati site-to-site. Le tabelle di routing di NCC controllano quali prefissi vengono importati/esportati e quali spoke li ricevono, consentendo una segmentazione precisa.
  • Il trasferimento dati site-to-site consente ai siti on-premise di raggiungersi a vicenda tramite la backbone di Google utilizzando l’hub come transito, riducendo la necessità di transito di terze parti e semplificando le operazioni.

• Spoke di router appliance e NVA di terze parti

  • Gli spoke di router appliance integrano router/firewall virtuali ospitati su Compute Engine come servizi di transito o inline. Utilizzare l’ILB come next hop per ottenere scalabilità e failover con health check tra più appliance.
  • Progettazione HA: distribuire almeno due appliance in zone diverse; posizionarle dietro un ILB con un MIG ove possibile; abilitare l’IP forwarding sulle istanze; utilizzare lo steering simmetrico con l’ILB come next hop; distribuire il carico utilizzando route basate su policy in base a tag o service account.
  • Compromessi tra throughput e guasti: gli NVA sono limitati dal tipo di istanza e dalla larghezza di banda della NIC; pianificare la scalabilità orizzontale. Il guasto di un’appliance o il fallimento di un health check innesca la rimozione dall’ILB e un failover rapido, ma è necessario assicurarsi che i timer di convergenza delle route e le soglie degli health check siano ottimizzati per evitare “flap” (instabilità).

• Compromessi delle topologie di transito

  • Hub-and-spoke con NCC: policy centralizzata, alta scalabilità, controllo chiaro del blast radius; richiede la progettazione delle tabelle di routing e la definizione degli intenti di importazione/esportazione.
  • Peering full mesh: semplice per un numero ridotto di VPC, nessun transito centrale, ma scala con difficoltà e non può fornire transitività o inserimento di servizi (service insertion).
  • Egress centralizzato: applicazione semplice della sicurezza tramite un unico NGFW o NAT; può aggiungere latenza e diventare un collo di bottiglia (choke point); mitigare con punti di egress regionali e autoscaling.
  • VPN mesh con Cloud Router: flessibile e veloce da implementare; il carico operativo aumenta con il numero di peer; considerare l’uso di NCC per consolidare.

• Considerazioni su Cloud VPN

  • Se il dispositivo on-premise non dispone di BGP, utilizzare una Cloud VPN basata su policy con route statiche e traffic selector definiti con cura; pianificare una futura migrazione a HA VPN con BGP per minimizzare il carico operativo a lungo termine.
  • Per tunnel active/standby verso l’ambiente on-premise, manipolare il MED o l’AS-path sul lato on-premise.
  • Per doppi router on-premise che si connettono a un singolo Cloud Router, preferire ASN di peer identici per consentire l’installazione di entrambi i percorsi e l’ECMP; l’uso di ASN di peer diversi comporta comunemente la selezione di un solo percorso.

Operazioni: validazione, analisi e contenimento delle interruzioni

• Validazione della connettività e analisi delle route

  • Usare i Connectivity Tests del Network Intelligence Center per tracciare il percorso dei dati attraverso VM, load balancer, VPC peering, Cloud VPN e Interconnect, validando le regole firewall e le route.
  • Analizzare le route effettive per VM/subnet per confermare i next hop e i prefissi dinamici; verificare che l’ambito della modalità di routing dinamico sia allineato con l’obiettivo.
  • Per problemi di performance o di esperienza utente, preferire il bilanciamento del carico HTTP(S) globale per ridurre la latenza per gli utenti di tutto il mondo tramite ingress anycast e terminazione edge; i network load balancer sono regionali e non migliorano la latenza globale.

• Contenimento delle interruzioni e riduzione del blast radius

  • Segmentare tramite VPC, tabelle di route di NCC e subnet di Shared VPC per progetto per prevenire la propagazione involontaria di guasti o errori di configurazione.
  • Evitare dipendenze transitive tramite peering; dove è richiesta la transitività, usare NCC e un’importazione/esportazione controllata per limitare la raggiungibilità.
  • Usare policy firewall centralizzate a livello di organizzazione per le regole deny/allow di base e policy locali per le eccezioni applicative; testare le modifiche con i Connectivity Tests.
  • Dove è richiesta la sicurezza inline, implementare un ILB next-hop con health check e routing basato su policy per un failover controllato. Assicurarsi che le API critiche di Google siano raggiungibili tramite Private Google Access o Cloud NAT senza dipendere da IP esterni.
  • Monitorare le sessioni BGP e le modifiche alle route; standardizzare le metriche (MED, local preference) e i piani di indirizzamento per evitare l’oscillazione delle route e i flussi asimmetrici.

• Brevi esempi di configurazione

  • Creare una route statica per indirizzare il traffico attraverso un ILB inline:
    • gcloud compute routes create egress-via-ngfw –network my-vpc –destination-range 0.0.0.0/0 –next-hop-ilb ngfw-ilb –priority 900
  • Preferire uno dei due percorsi BGP in entrata verso l’on-premise usando MED (sul router on-premise):
    • route-map FROM_GCP permit 10
    • set metric 20
    • router bgp 65000
    • neighbor 169.254.x.y route-map FROM_GCP in

Scenario pratico di un problema

Acme Retail opera in un’organizzazione Google Cloud multi-progetto con due popolazioni di utenti vicine a us-east1 e europe-west1. Hanno bisogno di una comunicazione privata a basso costo tra i carichi di lavoro (workload) in diverse regioni, di una connettività on-premise centralizzata e di un filtraggio URL inline per il traffico in uscita (egress) verso Internet, mantenendo al contempo il reparto Finance isolato da quello Engineering.

1. Creare un singolo Shared VPC in un progetto host con subnet regionali in us-east1 e europe-west1, e impostare la modalità di routing dinamico su global.

• Motivazione: Un unico VPC abilita la comunicazione diretta RFC1918 tra regioni senza l’overhead del peering. Il routing dinamico globale installa le route ibride apprese in tutte le regioni, semplificando le operazioni e garantendo flussi intra-VPC efficienti.

2. Condividere solo le subnet necessarie con ciascun progetto di servizio; collocare Finance e Engineering in progetti di servizio separati.

• Motivazione: La condivisione a livello di subnet fornisce segmentazione organizzativa e minimizza l’esposizione involontaria delle route. Il reparto Finance rimane isolato semplicemente non condividendo le subnet di Engineering e tramite ambiti di policy firewall separati.

3. Terminare Dedicated Interconnect nel progetto host e collegare i Cloud Router; annunciare (advertise) solo i prefissi necessari utilizzando advertisement personalizzati.

• Motivazione: La connettività ibrida centralizzata riduce costi e complessità, mantenendo il controllo su ciò che raggiunge l’ambiente on-premise. Gli advertisement personalizzati prevengono la sovraesposizione e contengono il blast radius.

4. Inserire un’appliance di filtraggio URL L7 inline dietro un internal TCP/UDP load balancer regionale; indirizzare il traffico in uscita (egress) con una route statica 0.0.0.0/0 verso il next hop dell’ILB in ogni regione.

• Motivazione: Il next hop dell’ILB, unito agli health check, fornisce un inserimento di servizi ad alta disponibilità (HA) con flussi simmetrici tra le appliance. Le route statiche con priorità più alta rispetto a quella predefinita assicurano che tutto il traffico in uscita venga filtrato.

5. Assicurarsi che le istanze senza IP esterni possano raggiungere direttamente le API di Google: abilitare Private Google Access su tutte le subnet e aggiungere route statiche per gli intervalli VIP delle API di Google verso il gateway Internet predefinito per bypassare l’appliance.

• Motivazione: Private Google Access preserva l’accesso privato a BigQuery e Pub/Sub; le route personalizzate prevengono l’hairpinning non necessario attraverso il filtro, riducendo costi e latenza.

6. Mantenere Finance isolato: negare il traffico tra progetti nelle policy firewall gerarchiche e non configurare peering tra Finance e Engineering. Dove è necessaria una collaborazione Engineering↔Analytics, creare una coppia di VPC dedicati in peering con CIDR non sovrapposti.

• Motivazione: I confini del VPC, l’assenza di peering e le policy firewall a livello di organizzazione impongono l’isolamento. Il peering mirato offre un basso overhead operativo per una connettività dipartimentale specifica senza transitività.

7. Validare e monitorare: usare i Connectivity Tests per verificare la raggiungibilità tra regioni e l’inserimento dell’appliance; monitorare lo stato di salute (health) del BGP del Cloud Router e le tabelle di route; implementare MED sui router on-premise per il failover attivo/standby in caso di tunnel multipli.

• Motivazione: La validazione proattiva rileva precocemente gli errori di configurazione. I controlli BGP mantengono deterministici i percorsi on-premise durante la manutenzione o i guasti, mentre la telemetria di NCC/Cloud Router accelera il troubleshooting.

Questo progetto soddisfa i requisiti di Acme Retail con un costo minimo e un’alta efficienza: routing privato multi-regionale in un unico VPC, connettività ibrida centralizzata, inserimento controllato di servizi e una forte segmentazione organizzativa.

← Connettività privata a Google e ai servizi gestiti · Tutti i domini · GKE →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →