Questo documento descrive come Network Connectivity Center 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 Network Connectivity Center 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 un VPC spoke può utilizzare un hop successivo in un VPC spoke diverso 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à di Network Connectivity Center.
La maggiore flessibilità di configurazione 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 hop successivo, sia la route statica sia 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 di subnet Network Connectivity Center (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 dell'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 Network Connectivity Center 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 dinamici.
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 l'hop successivo del bilanciatore del carico di rete passthrough interno.
Modifica della configurazione di Network Connectivity Center: lo spostamento di un 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 di Network Connectivity Center 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 del next hop può trovarsi in quello spoke VPC edge o in qualsiasi spoke VPC del gruppo di spoke hub. L'hop successivo non può trovarsi in un VPC spoke diverso del gruppo di spoke edge.
Se la route statica si trova in uno spoke VPC del gruppo di spoke hub, il bilanciatore del carico di rete passthrough interno del suo hop successivo può trovarsi in qualsiasi spoke VPC (nel gruppo di spoke edge o nel gruppo di spoke hub).
L'intervallo di subnet utilizzato dalla regola di forwarding del bilanciatore del carico di rete passthrough interno deve essere esportato nell'hub. Per maggiori informazioni, 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 hop successivo specificato e i requisiti di connettività di Network Connectivity Center 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 dell'hop successivo da tutte le regioni, abilita l'accesso globale.