Questo documento descrive come Network Connectivity Center (NCC) supporta le route statiche negli spoke VPC.
Prima di leggere questa pagina, assicurati di conoscere le seguenti risorse:
- Percorsi per una panoramica generale dei percorsi in Google Cloud
- Route statiche per una panoramica delle route statiche
Introduzione
A differenza delle route di subnet e delle route dinamiche, gli hub NCC non scambiano route statiche. Un hub, invece, offre una maggiore flessibilità di configurazione per le route statiche create in ogni spoke VPC.
Una route statica in una VPC spoke può utilizzare un hop successivo in una VPC spoke diversa se sono vere tutte le seguenti condizioni:
- La route statica non utilizza un tag di rete.
- L'intervallo di destinazione della route statica è un intervallo IPv4.
- L'hop successivo specificato della route statica è un indirizzo IPv4 di un bilanciatore del carico di rete passthrough interno.
- Google Cloud è in grado di identificare un bilanciatore del carico di rete passthrough interno come hop successivo all'indirizzo IP dell'hop successivo specificato.
- Sono stati soddisfatti i requisiti di connettività NCC.
La flessibilità di configurazione aggiuntiva per le route statiche si applica solo agli spoke VPC, non alle reti VPC che sono puramente reti VPC di routing (che contengono solo spoke ibridi).
Per un confronto con altri tipi di hop successivi delle route statiche, vedi Progetto e rete dell'hop successivo.
Identificazione del bilanciatore del carico di rete passthrough interno dell'hop successivo
Google Cloud tenta di trovare un bilanciatore del carico di rete passthrough interno per una route statica che ha un indirizzo IP del bilanciatore del carico di rete passthrough interno dell'hop successivo utilizzando la seguente procedura:
Se l'indirizzo IP dell'hop successivo si trova nell'intervallo di destinazione di una route di subnet locale: Google Cloud cerca esclusivamente un bilanciatore del carico di rete passthrough interno il cui indirizzo IP della regola di forwarding si trova nella subnet locale corrispondente. Se viene trovato un bilanciatore del carico di rete passthrough interno con hop successivo, sia la route statica che l'hop successivo si trovano nella stessa rete VPC.
Se l'indirizzo IP dell'hop successivo si trova nell'intervallo di destinazione di una route subnet NCC (importata dall'hub): Google Cloud cerca esclusivamente un bilanciatore del carico di rete passthrough interno il cui indirizzo IP della regola di forwarding si trova nella subnet corrispondente di un altro spoke VPC. Se viene trovato un bilanciatore del carico di rete passthrough interno con hop successivo, la route statica si trova in uno spoke VPC e l'hop successivo si trova in un altro spoke VPC.
Per informazioni dettagliate su come trovare un bilanciatore del carico di rete pass-through interno in un altro VPC spoke, consulta Requisiti di NCC per la connettività.
Se vuoi utilizzare un bilanciatore del carico di rete passthrough interno di hop successivo in una rete VPC di routing (contenente spoke ibridi), devi aggiungere la rete VPC di routing all'hub come spoke VPC. Per ulteriori limitazioni relative all'utilizzo di una rete VPC di routing come VPC spoke, consulta Limitazioni dello scambio di route dinamiche.
Se l'indirizzo IP dell'hop successivo si trova nell'intervallo di destinazione di una route di subnet in peering (importata da un'altra rete che utilizza il peering di rete VPC): Google Cloud cerca esclusivamente un bilanciatore del carico di rete passthrough interno il cui indirizzo IP della regola di forwarding si trova nella subnet corrispondente della rete VPC in peering. Se viene trovato un bilanciatore del carico di rete passthrough interno dell'hop successivo, la route statica si trova in una rete VPC e l'hop successivo si trova nella rete VPC con peering.
Se non viene trovato alcun bilanciatore del carico di rete passthrough interno dell'hop successivo, i pacchetti inviati all'intervallo di destinazione della route statica vengono eliminati.
Aggiornamenti al bilanciatore del carico di rete passthrough interno dell'hop successivo
Google Cloud tenta continuamente di identificare un bilanciatore del carico di rete passthrough interno dell'hop successivo. Nelle seguenti situazioni di esempio, l'hop successivo per una route statica viene aggiornato automaticamente.
Sostituzione del bilanciatore del carico di rete passthrough interno dell'hop successivo: quando l'hop successivo per una route statica è l'indirizzo IP di un bilanciatore del carico di rete passthrough interno, puoi eliminare il bilanciatore del carico di rete passthrough interno dell'hop successivo senza dover prima eliminare la route statica. Se Google Cloud trova un bilanciatore del carico di rete passthrough interno sostitutivo con lo stesso indirizzo IP, Google Cloud passa all'hop successivo del bilanciatore del carico di rete passthrough interno sostitutivo.
Una route statica esistente senza un bilanciatore del carico di rete passthrough interno di hop successivo valido può diventare operativa: quando viene trovato un bilanciatore del carico di rete passthrough interno di hop successivo valido, Google Cloud inizia a utilizzare quell'hop successivo del bilanciatore del carico di rete passthrough interno.
La modifica della configurazione NCC: lo spostamento di una VPC spoke in un gruppo di spoke diverso o la modifica dei filtri di esportazione può comportare la mancata individuazione di un bilanciatore del carico di rete passthrough interno dell'hop successivo o l'individuazione e l'utilizzo di un bilanciatore del carico di rete passthrough interno dell'hop successivo diverso.
Requisiti NCC per la connettività
Per trovare un bilanciatore del carico di rete passthrough interno di hop successivo in un altro VPC spoke, la subnet utilizzata dalla regola di forwarding del bilanciatore del carico di rete passthrough interno deve essere accessibile nel VPC spoke in cui è definita la route statica. Devono essere soddisfatte entrambe le seguenti condizioni:
La topologia hub deve consentire lo scambio di route di subnet che contengono il bilanciatore del carico di rete passthrough interno dell'hop successivo.
Se utilizzi la topologia mesh, tutti gli spoke VPC fanno parte dello stesso gruppo di spoke. La route statica può esistere in qualsiasi VPC spoke e il bilanciatore del carico di rete passthrough interno dell'hop successivo può esistere in qualsiasi VPC spoke.
Se utilizzi la topologia a stella, si applicano i seguenti requisiti:
Se la route statica si trova in uno spoke VPC del gruppo di spoke edge, il bilanciatore del carico di rete passthrough interno dell'hop successivo può trovarsi in questo spoke VPC edge o in qualsiasi spoke VPC del gruppo di spoke centrale. L'hop successivo non può trovarsi in uno spoke VPC diverso del gruppo di spoke perimetrali.
Se la route statica si trova in uno spoke VPC del gruppo di spoke centrale, il bilanciatore del carico di rete passthrough interno dell'hop successivo può trovarsi in qualsiasi spoke VPC (nel gruppo di spoke periferici o nel gruppo di spoke centrale).
L'intervallo di subnet utilizzato dalla regola di forwarding del bilanciatore del carico di rete passthrough interno deve essere esportato nell'hub. Per saperne di più, consulta Connettività VPC con filtri di esportazione.
Effetto dell'accesso globale
I bilanciatori del carico di rete passthrough interni dell'hop successivo per i quali non è abilitato l'accesso globale non sono raggiungibili dalle regioni esterne alla regione del bilanciatore del carico. Se Google Cloud ha identificato un bilanciatore del carico di hop successivo all'indirizzo IP di hop successivo specificato e i requisiti di connettività NCC sono soddisfatti, ma il bilanciatore del carico non ha l'accesso globale abilitato, Google Cloud elimina tutti i pacchetti inviati da istanze VM, collegamenti VLAN e tunnel Cloud VPN in regioni diverse da quella del bilanciatore del carico.
Per modificare questo comportamento e rendere raggiungibile il bilanciatore del carico hop successivo da tutte le regioni, abilita l'accesso globale.