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:
- Route per una panoramica generale delle route 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 uno spoke VPC può utilizzare un hop successivo in uno spoke VPC 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 hop successivo bilanciatore del carico di rete passthrough interno all'indirizzo IP dell'hop successivo specificato.
- I requisiti di connettività NCC sono stati soddisfatti.
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 di route statiche, vedi Progetto e rete dell'hop successivo.
Identificare il 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 esegue la ricerca esclusiva di 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 dell'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 NCC (importata dall'hub): Google Cloud esegue la ricerca esclusiva di 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 uno spoke VPC diverso.
Per i dettagli su come trovare un bilanciatore del carico di rete passthrough interno in un altro spoke VPC può essere trovato, vedi Requisiti NCC per la connettività.
Se vuoi utilizzare un bilanciatore del carico di rete passthrough interno dell'hop successivo in una rete VPC di routing (che contiene 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 spoke VPC, vedi Considerazioni per lo scambio di route dinamiche con gli spoke VPC.
Se l'indirizzo IP dell'hop successivo si trova nell'intervallo di destinazione di una route di subnet di peering (importata da un'altra rete che utilizza il peering di rete VPC): Google Cloud esegue la ricerca esclusiva di un bilanciatore del carico di rete passthrough interno il cui indirizzo IP della regola di forwarding si trova nella subnet corrispondente della rete VPC con 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 dell'hop successivo valido può diventare operativa: quando viene trovato un bilanciatore del carico di rete passthrough interno dell'hop successivo valido, Google Cloud inizia a utilizzare l'hop successivo del bilanciatore del carico di rete passthrough interno.
Modifica della configurazione NCC: lo spostamento di uno spoke VPC 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 connettività NCC
Per trovare un bilanciatore del carico di rete passthrough interno dell'hop successivo in un altro spoke VPC, la subnet utilizzata dalla regola di forwarding del bilanciatore del carico di rete passthrough interno deve essere accessibile nello spoke VPC in cui è definita la route statica. Devono essere vere 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 spoke VPC e il relativo bilanciatore del carico di rete passthrough interno dell'hop successivo può esistere in qualsiasi spoke VPC.
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 quello 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 edge.
Se la route statica si trova in uno spoke VPC del gruppo di spoke centrale, il relativo bilanciatore del carico di rete passthrough interno dell'hop successivo può trovarsi in qualsiasi spoke VPC (nel gruppo di spoke edge 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ù, vedi Connettività VPC con filtri di esportazione.
Effetto dell'accesso globale
I bilanciatori del carico di rete passthrough interni dell'hop successivo per cui l'accesso globale non è abilitato non sono raggiungibili dalle regioni esterne alla regione del bilanciatore del carico. Se Google Cloud ha identificato un bilanciatore del carico dell'hop successivo all'indirizzo IP dell'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 dalla regione 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