Google PCNE: Connettività ibrida, Cloud Router e BGP — 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

La connettività ibrida su Google Cloud abilita la comunicazione privata e controllata tra le reti VPC e le reti esterne, come i data center on-premise o altri cloud. I componenti fondamentali sono i gateway HA VPN e Cloud VPN, Cloud Router con BGP per il routing dinamico e Interconnect con i collegamenti VLAN (VLAN attachment). I progetti devono bilanciare larghezza di banda, latenza, affidabilità, complessità operativa e costi, seguendo al contempo un comportamento di routing deterministico e l’isolamento dei domini di errore. Questa sezione tratta la logica di progettazione e operativa, le modalità di guasto comuni e la risoluzione sistematica dei problemi.

Connettività ibrida: HA VPN, Cloud Router e Interconnect

HA VPN e Cloud VPN
- HA VPN è una VPN IPsec regionale ad alta disponibilità che supporta IKEv2 e richiede Cloud Router per il routing dinamico (eBGP). Un gateway HA VPN ha due interfacce; per lo SLA e l’ECMP, è necessario creare due tunnel per interfaccia verso endpoint peer distinti.
- Classic Cloud VPN supporta IKEv1 o IKEv2 e tunnel statici o basati su route; non supporta lo SLA di HA VPN. Utilizzarlo solo quando i peer non dispongono di BGP o è necessario utilizzare selettori basati su policy.
- Il gateway peer è il dispositivo/IP VPN remoto. Per HA VPN, definire un gateway VPN peer con uno o più IP pubblici per modellare interfacce o dispositivi distinti per la ridondanza.
- Progettazione per lo SLA: Per avere diritto allo SLA del 99,99% di HA VPN, implementare tunnel ridondanti su dispositivi o interfacce on-premise indipendenti e utilizzare il routing dinamico. Classic VPN non è supportato da SLA.
- Scalabilità del throughput: Un singolo tunnel IPsec ha un throughput finito. Utilizzare l’ECMP su più tunnel per aumentare il throughput aggregato. Ciò si ottiene terminando tunnel aggiuntivi su IP pubblici peer univoci.
Cloud Router e BGP
- Cloud Router è un servizio regionale del piano di controllo che stabilisce sessioni BGP con tunnel VPN o collegamenti VLAN (VLAN attachment) di Interconnect e scambia le route in modo dinamico.
- La modalità di routing dinamico (a livello di VPC) determina dove le route dinamiche apprese sono utilizzabili e quali route delle subnet VPC vengono annunciate (advertise):
  - Regionale: apprende e utilizza/importa le route dinamiche solo nella stessa regione.
  - Globale: apprende e utilizza/importa le route dinamiche in tutte le regioni; annuncia (advertise) tutte le route delle subnet VPC (globali) ai peer.
Dedicated Interconnect e Partner Interconnect
- Dedicated Interconnect fornisce circuiti fisici da 10 Gbps o 100 Gbps direttamente a Google in una struttura di colocation. Si ottiene una Letter of Authorization – Connecting Facility Assignment (LOA‑CFA) per abilitare i cross-connect. Creare collegamenti VLAN (VLAN attachment, o interconnect attachment) che mappano i tag 802.1Q a una connettività L3 regionale associata a un Cloud Router.
- Partner Interconnect fornisce connettività logica tramite un service provider. Si richiedono i collegamenti VLAN (VLAN attachment) al partner; la larghezza di banda viene fornita sull’edge del partner. È comunque necessario associare i collegamenti a Cloud Router per il BGP.
- Ridondanza e SLA: Utilizzare due collegamenti nella stessa regione, posizionati su domini di disponibilità perimetrali (edge availability domain) distinti (e, se applicabile, su interconnessioni fisiche distinte) per raggiungere SLA più elevati (ad es. 99,99%). Un singolo collegamento o link riduce lo SLA. Per Partner Interconnect, lo SLA complessivo dipende anche dal partner.
Cross-connect e collegamenti VLAN
- I cross-connect sono le connessioni fisiche in fibra tra il proprio rack/apparato e il rack di Google in una meet-me room. Presentare la LOA-CFA al proprio provider per completarli.
- I collegamenti VLAN (VLAN attachment) sono la demarcazione logica L2 verso una regione VPC. Ogni collegamento:
  - Si associa esattamente a una VPC e a una regione tramite un Cloud Router.
  - Viene configurato in coppia per la ridondanza e l’ECMP.
  - Trasporta solo traffico L3; nessuna estensione L2.

Breve esempio:

Creare Cloud Router e BGP per un collegamento (attachment) o un peer 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

Comportamento del routing e del BGP

Routing dinamico e statico a confronto
- Il routing dinamico con Cloud Router fornisce apprendimento automatico delle route, convergenza ed ECMP. Scala e riduce l’overhead operativo man mano che le reti crescono.
- Il routing statico è appropriato quando i peer non dispongono di BGP o per percorsi deterministici e con ambito ristretto. In VPC, le route statiche hanno una priorità numerica; i valori più bassi sono preferiti tra le route statiche con la stessa lunghezza di prefisso.
- Selezione della route in un VPC:
  - Vince la corrispondenza del prefisso più lungo (longest prefix match).
  - Le route di subnet non possono essere sovrascritte da route personalizzate.
  - Per prefissi di uguale lunghezza, le route statiche vengono selezionate in base alla priorità più bassa. Tra le route dinamiche, Cloud Router ha già risolto i percorsi migliori prima di installarli. La route predefinita di sistema è quella con la preferenza più bassa.
Sessioni BGP, advertisement e import/export
- Cloud Router esporta le subnet VPC per impostazione predefinita o un set personalizzato di prefissi. È possibile annunciare (advertise) 0.0.0.0/0 o prefissi aggregati quando necessario, ma ciò attira il traffico on-premise verso il Cloud se le policy lo consentono; progettare con attenzione.
- Cloud Router importa qualsiasi prefisso on-premise consentito e lo installa come route dinamica in base alla modalità di routing dinamico del VPC.
- La priorità della route annunciata (advertised route priority) per singolo peer consente di influenzare il modo in cui i router on-premise preferiscono un percorso Google rispetto a un altro; un valore di priorità più basso si traduce in un MED più preferito verso il peer.
ASN, MED e configurazione active-standby
- Utilizzare un ASN privato univoco per ogni dominio amministrativo, a meno che non siano giustificati ASN pubblici. Per più router on-premise in peering con lo stesso VPC per gli stessi prefissi:
  - Per abilitare l’ECMP o un percorso migliore (best-path) coerente, utilizzare lo stesso ASN remoto on-premise su tutti i router che annunciano gli stessi prefissi. ASN remoti diversi possono impedire l’installazione a costo uguale (equal-cost) su Cloud Router.
  - Per la configurazione active/standby, manipolare il MED (più basso è più preferito) dal lato on-premise, oppure regolare la priorità della route annunciata per singolo peer di Cloud Router in modo che l’ambiente on-premise preferisca il percorso primario. L’AS-path prepending è uno strumento alternativo ma più grossolano.
Progettazione multipath
- Cloud Router supporta l’ECMP su più percorsi BGP uguali sia per gli allegati (attachment) HA VPN che Interconnect. Assicurarsi che gli attributi (lunghezza dell’AS-path, MED, local-pref) siano uguali e che i next hop siano distinti. Per HA VPN, terminare i tunnel su IP peer distinti. Per Interconnect, utilizzare allegati (attachment) ridondanti.

Resilienza, rilevamento e servizi di egress

BFD e rilevamento dei guasti
- Il BFD accelera il rilevamento dei guasti per le sessioni BGP su HA VPN e Interconnect. Abilitare il BFD su entrambi i lati con intervalli compatibili per ottenere un rilevamento inferiore al secondo o di pochi secondi, a seconda delle esigenze di stabilità. Combinare con IKE DPD sui tunnel IPsec. Assicurarsi che i dispositivi peer possano elaborare un traffico di controllo più frequente.
- Attenzione al rilevamento asimmetrico: un BFD aggressivo unito a link congestionati può causare instabilità (flap) delle sessioni; iniziare con timer conservativi e monitorare.
Pattern di topologia ridondante
- HA VPN: Utilizzare un gateway HA VPN per regione e terminare i tunnel su due dispositivi o interfacce on-premise distinti. Creare almeno quattro tunnel (due per interfaccia) e un Cloud Router per regione. Mantenere coerenti gli ASN remoti quando si offre l’ECMP.
- Interconnect: Utilizzare almeno due allegati (attachment) in ogni regione su domini di disponibilità edge (edge availability domain) distinti. Per Dedicated Interconnect, distribuire i link su dispositivi e strutture edge diversi, ove possibile.
Cloud NAT, indirizzi esterni ed egress per carichi di lavoro privati
- Cloud NAT è un servizio di egress gestito e regionale per risorse senza IP esterni. Non esegue SNAT su istanze che hanno IP esterni; queste escono direttamente. Selezionare subnet o tutte le subnet di una regione per coprire i carichi di lavoro privati.
- Dimensionare i pool di IP del NAT per le connessioni simultanee e le porte effimere; scegliere l’allocazione manuale o automatica degli IP. Abilitare il logging per la diagnostica.
- Per raggiungere le API di Google in modo privato:
  - In-VPC: abilitare Private Google Access sulle subnet in modo che le VM senza IP esterni possano raggiungere le API di Google tramite gli IP virtuali di Google.
  - Da on-premise: utilizzare endpoint Private Service Connect per le API di Google e DNS ibrido in modo che i client on-premise risolvano e raggiungano le API tramite link ibridi privati, evitando internet.
- Se una route predefinita punta a un firewall di terze parti ma si desidera che i carichi di lavoro privati lo bypassino per le API di Google, utilizzare Private Service Connect oppure installare route statiche a priorità più alta per gli intervalli IP pubblicati delle API di Google verso il gateway internet predefinito, in combinazione con Private Google Access sulle subnet.
Integrazione DNS ibrida
- Utilizzare le zone private di Cloud DNS per la risoluzione dei nomi all’interno del VPC. Estendere all’ambiente on-premise con:
  - Inoltro in entrata (inbound forwarding): i resolver on-premise inoltrano le richieste a Cloud DNS per le zone private ospitate nel VPC.
  - Inoltro in uscita (outbound forwarding): i resolver del VPC inoltrano domini selezionati al DNS on-premise.
  - Zone di peering (peering zones) per la risoluzione tra VPC in ambienti Shared VPC o multi-progetto.
- Per la raggiungibilità privata delle API, creare una zona privata che mappi i nomi host delle API a endpoint Private Service Connect o agli opportuni VIP privati di Google quando si utilizza Private Google Access, e assicurarsi che tali nomi siano risolvibili dall’ambiente on-premise tramite l’inoltro DNS.

Pianificazione e risoluzione dei problemi

Compromessi tra larghezza di banda, latenza e costi
- VPN: la più veloce da implementare, costo fisso più basso, throughput per tunnel limitato, overhead di CPU/crittografia per bit più elevato e latenza tipicamente maggiore rispetto ai collegamenti privati.
- Dedicated Interconnect: throughput più elevato e costo per bit più basso con latenza prevedibile; costi fissi e tempi di realizzazione più alti (cross-connect, colocation).
- Partner Interconnect: una via di mezzo; sfrutta la presenza del provider; SLA e latenza dipendono dal percorso del partner.
- Posizionare gli attachment e i gateway a livello regionale vicino ai carichi di lavoro per minimizzare la latenza. Usare Shared VPC per centralizzare la connettività in un progetto host servendo al contempo più progetti di servizio.
- Considerare la simmetria del traffico, i requisiti di ispezione e i domini di guasto. Evitare singoli punti di guasto (single points of failure) nell’ultimo miglio on-premise e nei percorsi del provider.
Diagnosi sistematica dei problemi di tunnel, BGP e routing
1. Creazione del tunnel
  - Verificare la compatibilità della versione IKE: HA VPN richiede IKEv2; se il peer supporta solo IKEv1 o VPN basata su policy, usare Classic VPN.
  - Controllare i segreti condivisi, le proposte (crittografia, gruppi DH), NAT-T e la raggiungibilità delle porte UDP 500/4500.
  - Confermare gli IP dei peer e che ogni tunnel punti a un’interfaccia peer distinta per la ridondanza.
2. Stato della sessione BGP
  - Confermare gli stati BGP su entrambe le estremità; esaminare lo stato del Cloud Router. Se BFD è abilitato ma le sessioni sono instabili, allentare i timer.
  - Convalidare la configurazione dell’ASN; aspettative non corrispondenti possono impedire l’ECMP или causare sorprese nella scelta del percorso migliore.
  - Assicurarsi che l’indirizzamento IP per le sessioni BGP utilizzi gli indirizzi link-local o RFC1918 corretti configurati sull’interfaccia del tunnel o dell’attachment.
3. Scambio e propagazione delle route
  - Controllare la modalità di advertisement del Cloud Router (DEFAULT vs CUSTOM). Assicurarsi che le subnet o gli aggregati previsti vengano esportati.
  - Ispezionare le route ricevute sul Cloud Router; valutare AS-path e MED. Se si intende una configurazione attivo/standby, assicurarsi che il MED o la priorità della route annunciata riflettano tale intenzione.
  - Verificare la modalità di routing dinamico del VPC (REGIONAL vs GLOBAL) in modo che le route apprese compaiano dove necessario. Ricordare che le route di subnet non possono essere sovrascritte.
  - In caso di conflitti, se una route statica e una dinamica corrispondono alla stessa lunghezza del prefisso, vince la route statica con la priorità più bassa. Regolare o rimuovere le route statiche sovrapposte quando non intenzionali.
4. Convalida del data plane
  - Usare VPC Flow Logs e i log di Cloud NAT per confermare il percorso di egress e la traduzione degli indirizzi. Se una VM esce ancora con il suo IP esterno, rimuovere tale IP esterno per forzare il NAT.
  - Per Interconnect, verificare lo stato operativo dell’attachment e che entrambi gli attachment siano abilitati a livello amministrativo e associati al Cloud Router corretto.
  - Confermare che le regole del firewall permettano il traffico BGP e applicativo; ricordare che gli intervalli di origine degli health check di Google devono essere autorizzati a raggiungere i backend dei load balancer.
5. Specifiche per l’attivazione di Interconnect
  - Ottenere il LOA-CFA dalla console o dall’email di contatto del NOC. Confermare i livelli di segnale ottico del cross-connect e il tagging delle VLAN con il provider prima dell’attivazione del BGP.

Scenario pratico di un problema

Contoso Manufacturing sta migrando i carichi di lavoro ERP su Google Cloud, mantenendo online le fabbriche on-premise. Requisiti: connettività privata da 20 Gbps con failover in meno di un secondo, controllo centralizzato del routing, egress on-premise attivo/standby verso il Cloud, accesso privato alle API di Google senza passare per Internet pubblico e overhead operativo minimo.

Approccio:

Implementare due collegamenti Dedicated Interconnect nella stessa area metropolitana attraverso domini di disponibilità e strutture edge distinti; creare due VLAN attachment per regione (primario e secondario) e associarli a un Cloud Router regionale.
- Motivazione: Dedicated Interconnect fornisce il throughput aggregato richiesto e una latenza prevedibile. Collegamenti e attachment ridondanti isolano i guasti e si qualificano per uno SLA più elevato. Attachment multipli abilitano l’ECMP e la manutenzione senza perdita di traffico.
Configurare un singolo Cloud Router per regione con due peer BGP — uno per attachment — e abilitare BFD.
- Motivazione: Un singolo router semplifica la gestione del control plane pur supportando l’ECMP su più next hop. BFD riduce il rilevamento dei guasti a pochi secondi, migliorando l’RTO di convergenza per l’applicazione ERP.
Standardizzare l’uso dello stesso ASN remoto on-premise su entrambi i router edge delle fabbriche che si collegano in peering a Google e annunciare prefissi identici da ciascuno.
- Motivazione: ASN remoti corrispondenti consentono al Cloud Router di installare percorsi a costo uguale e di bilanciare il carico quando desiderato. Se fossero usati ASN diversi, potrebbe essere installato solo un set di route, vanificando il multipath.
Implementare la preferenza attivo/standby da on-premise a Google usando il MED, e da Google a on-premise usando la priorità della route annunciata dal Cloud Router; impostare valori più bassi sui percorsi primari.
- Motivazione: Una policy a doppio lato assicura una direzionalità deterministica: le fabbriche preferiscono l’area metropolitana primaria per raggiungere il Cloud, e il VPC di Contoso preferisce il DC primario della fabbrica per il traffico di ritorno. Ciò evita asimmetrie non intenzionali.
Abilitare Private Service Connect per le API di Google nello Shared VPC e creare una zona DNS privata che mappi i nomi host delle API all’endpoint PSC; configurare l’inoltro in entrata di Cloud DNS in modo che i resolver on-premise possano risolvere questi nomi privatamente.
- Motivazione: PSC fornisce un accesso privato alle API di Google all’interno del VPC. Il DNS ibrido rende questi endpoint raggiungibili dalle fabbriche tramite Interconnect, eliminando l’esposizione a Internet e le dipendenze dal firewall per i servizi di supporto dell’ERP.
Per il backup VPN, aggiungere un gateway HA VPN in ogni regione con due tunnel verso dispositivi on-premise distinti; abilitare BFD sulle sessioni BGP e consentire l’ECMP.
- Motivazione: Se Interconnect subisce un’interruzione, HA VPN mantiene la raggiungibilità privata. Doppi tunnel per dispositivo mantengono la continuità di SLA e throughput, e BFD accelera il failover.
Per l’egress di carichi di lavoro privati verso Internet e destinazioni non-Google, configurare Cloud NAT a livello regionale sulle subnet dell’ERP; non assegnare IP esterni alle VM.
- Motivazione: Cloud NAT scala la traduzione senza l’overhead di gestione delle VM e preserva l’indirizzamento privato. La rimozione degli IP esterni garantisce che il NAT venga utilizzato e semplifica i controlli di egress.
Convalidare il routing e il failover con test graduali: scollegare un attachment, poi un router on-premise, quindi simulare il degrado del link; monitorare BGP, BFD e gli SLO delle applicazioni. Regolare i timer BFD se si verificano instabilità.
- Motivazione: L’iniezione controllata di guasti verifica che il design soddisfi gli obiettivi di ripristino e previene sorprese in produzione. La regolazione dei timer bilancia stabilità e reattività.