Spoke VPC
Network Connectivity Center fornisce connettività tra reti VPC su larga scala con il supporto degli spoke VPC. Gli spoke VPC riducono la complessità operativa della gestione delle singole connessioni in peering di rete VPC in coppia tramite l'utilizzo di spoke VPC e un modello di gestione della connettività centralizzata. Gli spoke VPC possono esportare e importare tutte le route delle subnet da altri spoke VPC in un hub di Network Connectivity Center. In questo modo viene garantita la connettività completa tra tutti i carichi di lavoro presenti in tutte queste reti VPC. Il traffico di rete tra VPC rimane all'interno della Google Cloud rete e non passa per internet, il che contribuisce a garantire privacy e sicurezza.
Gli spoke VPC possono trovarsi nello stesso progetto e nella stessa organizzazione o in un progetto e un'organizzazione diversi rispetto all'hub del Network Connectivity Center. Uno spoke VPC può essere connesso a un solo hub alla volta.
Per informazioni su come creare uno spoke VPC, consulta Creare uno spoke VPC.
Confronto con il peering di rete VPC
Gli spoke VPC supportano i requisiti delle aziende di medie e grandi dimensioni fornendo connettività delle route delle subnet IPv4 e IPv6 e connettività delle route dinamiche IPv4 utilizzando spoke ibride.
Una rete VPC può essere contemporaneamente uno spoke VPC di Network Connectivity Center e connessa a un'altra rete VPC tramite il peering di rete VPC, a condizione che la rete VPC in peering non sia essa stessa uno spoke VPC.
Tieni presente quanto segue quando utilizzi gli spoke VPC di Network Connectivity Center e il peering di rete VPC:
Le route delle subnet di peering in uno spoke VPC non vengono esportate nell'hub.
Network Connectivity Center non fornisce connettività alle risorse di una rete VPC connessa a uno spoke VPC tramite il peering di rete VPC, con la seguente eccezione:
- Una rete VPC del producer di servizi in peering per l'accesso privato ai servizi può essere aggiunta come spoke VPC del producer (anteprima).
Funzionalità | Peering di rete VPC | Spoke VPC |
---|---|---|
Reti VPC | ||
Intervalli di subnet (route di subnet) | ||
Route statiche e dinamiche |
Prefissi route dinamici univoci per tabella route hub per regione. Lo scambio di route statiche non è supportato. |
|
Esportare i filtri |
I filtri specifici non sono supportati. Consulta Opzioni di scambio route nella documentazione del peering di rete VPC. |
Fino a 16 intervalli CIDR supportati per spoke VPC. |
Inter-VPC NAT |
Non supportata |
Supportato |
Propagazione della connessione Private Service Connect |
Non supportata |
Supportato (Anteprima) |
Connettività dello spoke VPC del producer da altre reti VPC |
Non supportata |
Supportato (Anteprima) |
Indirizzi IP |
Indirizzi IPv4 interni, inclusi indirizzi IPv4 privati e indirizzi IPv4 pubblici utilizzati privatamente. Vedi Intervalli IPv4 validi. Indirizzi IPv6 interni ed esterni. |
Solo indirizzi IPv4 interni privati, esclusi gli indirizzi IPv4 pubblici utilizzati privatamente. Vedi Intervalli IPv4 validi. Indirizzi IPv6 interni ed esterni (anteprima). |
Famiglie di indirizzi IP |
Configurazioni supportate:
|
Configurazioni supportate:
|
Rendimento e throughput (rispetto ad altri meccanismi di connettività VPC) |
Latenza più bassa, velocità effettiva più elevata (equivalente VM-VM). |
Latenza più bassa, velocità effettiva più elevata (equivalente VM-VM). |
Spoke VPC in un progetto diverso da un hub
Con Network Connectivity Center, puoi collegare reti VPC, rappresentate come spoke VPC, a un singolo hub in un altro progetto, incluso un progetto in un'altra organizzazione. In questo modo puoi connettere le tue reti VPC a più progetti e organizzazioni su larga scala.
Puoi essere uno dei seguenti tipi di utenti:
- Un amministratore dell'hub che possiede un hub in un progetto
- Un amministratore di spoke della rete VPC o un amministratore di rete che vuole aggiungere la propria rete VPC in un progetto diverso come spoke all'hub
L'amministratore dell'hub controlla chi può creare uno spoke VPC in un progetto diverso associato al proprio hub utilizzando le autorizzazioni Identity and Access Management (IAM). L'amministratore dello spoke della rete VPC crea uno spoke in un progetto diverso dall'hub. Questi raggi sono inattivi al momento della creazione. L'amministratore dell'hub deve esaminarli e può accettare o rifiutare il raggio. Se l'amministratore dell'hub accetta lo spoke, questo diventa attivo.
Network Connectivity Center accetta sempre automaticamente gli spoke creati nello stesso progetto dell'hub.
Per informazioni dettagliate su come gestire gli hub con spoke VPC in un progetto diverso dall'hub, consulta la Panoramica della gestione degli hub. Per informazioni dettagliate per gli amministratori degli spoke, consulta la Panoramica dell'amministrazione degli spoke.
Interazione con Spoke e Controlli di servizio VPC
Network Connectivity Center supporta i Controlli di servizio VPC per gli spoke tra progetti e organizzazioni. Per uno spoke in un progetto diverso dall'hub, quando viene aggiunto un nuovo perimetro dei Controlli di servizio VPC, non puoi aggiungere nuovi spoke che violano il perimetro. Tuttavia, gli spoke esistenti aggiunti prima di aggiungere il perimetro dei Controlli di servizio VPC continuano a funzionare.
Connettività VPC con filtri di esportazione
Network Connectivity Center ti consente di limitare la connettività di tutte le reti VPC spoke a un sottoinsieme di subnet nella VPC spoke. Puoi limitare la connettività nel seguente modo:
- Per gli intervalli di subnet IPv4:
- Puoi configurare lo spoke in modo che pubblicizzi tutti gli intervalli IPv4 della subnet o nessuno di questi intervalli.
- Puoi specificare intervalli di indirizzi IPv4 da impedire di essere pubblicizzati e stabilire un elenco di intervalli CIDR che possono essere pubblicizzati dalla rete VPC. In alternativa, puoi specificare solo un elenco di intervalli CIDR consentiti, bloccando così tutti gli intervalli tranne quelli consentiti.
- Per gli intervalli di subnet IPv6 (Anteprima):
- Puoi configurare lo spoke in modo che pubblicizzi tutti i suoi intervalli di subnet IPv6 o nessuno di questi intervalli.
Puoi utilizzare i filtri di esportazione per configurare gli spoke VPC in modo che scambino solo intervalli di subnet IPv4, solo intervalli di subnet IPv6 o intervalli di subnet IPv4 e IPv6. Considera uno spoke la cui rete VPC ha una combinazione di tipi di stack di subnet. Se configuri lo spoke per esportare solo gli intervalli di subnet IPv6, gli intervalli IPv6 delle subnet a doppio stack e solo IPv6 vengono scambiati, ma non vengono scambiati gli intervalli di subnet IPv4 delle subnet a doppio stack e solo IPv4.
Escludi intervalli di esportazione
Puoi impedire la pubblicità di un intervallo di indirizzi IPv4 utilizzando il flag --exclude-export-ranges
in Google Cloud CLI o il campo excludeExportRanges
nell'API. Gli intervalli di indirizzi IPv4 che corrispondono all'intervallo specificato non vengono esportati nell'hub. Questo filtraggio è utile quando hai subnet che devono essere private all'interno della rete VPC o che potrebbero sovrapporsi ad altre subnet nella tabella di route dell'hub.
Includi intervalli di esportazione
Puoi stabilire quali intervalli di indirizzi IP possono essere pubblicizzati
da uno spoke VPC utilizzando il flag --include-export-ranges
o il campo includeExportRanges
nell'API. Puoi specificare quanto segue:
- Per annunciare tutti gli intervalli di subnet IPv4, puoi specificare
ALL_PRIVATE_IPV4_RANGES
. - Per pubblicizzare solo intervalli di subnet IPv4 specifici, puoi specificare un elenco di intervalli CIDR.
- Per annunciare tutti gli intervalli di subnet IPv6, puoi specificare
ALL_IPV6_RANGES
.
Per gli intervalli di indirizzi IPv4, puoi stabilire una connettività più precisa se utilizzi un filtro di esportazione per l'inclusione insieme al filtro di esportazione per l'esclusione. Questo filtro determina se un determinato intervallo di subnet può essere pubblicizzato dalla rete VPC.
Considerazioni
Tieni presente quanto segue quando utilizzi i filtri di esportazione degli intervalli di esclusione e inclusione:
Gli intervalli di inclusione devono essere esclusivi tra loro, il che significa che non devono sovrapporsi. Ad esempio, supponiamo che esistano tre intervalli di indirizzi IP:
Range 1
:10.100.64.0/18
Range 2
:10.100.250.0/21
Range 3
:10.100.100.0/22
Range 1
erange 2
sono intervalli di inclusione validi perché non si sovrappongono. Tuttavia,range 3
è inferiore arange 1
, il che può causare sovrapposizioni, quindirange 3
non è valido.Poiché Network Connectivity Center dispone già di filtri di esportazione per escludere disponibili nel criterio di configurazione di rete, sia i filtri di esportazione per includere che quelli per escludere incidono sugli intervalli CIDR di configurazione di rete validi. Quando vengono utilizzati sia i filtri di esportazione che includono sia quelli che escludono, gli intervalli di indirizzi IP inclusi devono essere un superinsieme degli intervalli di indirizzi IP esclusi.
Per impostazione predefinita, tutti i criteri di connettività VPC hanno un intervallo CIDR incluso di
0.0.0.0/0
, il che significa che se non specifichi il filtro di inclusione durante la creazione dello spoke VPC, Network Connectivity Center imposta l'intervallo di inclusione predefinito su tutti gli indirizzi IPv4 privati validi come definito in Intervalli IPv4 validi.Per perfezionare un intervallo di inclusione, puoi aggiungere più intervalli di esclusione. Ad esempio, se specifichi
10.1.0.0/16
come intervallo di inclusione e10.1.100.0/24
e10.1.200.0/24
come intervalli di esclusione, il risultato è una connettività perfezionata con la combinazione di filtri di inclusione ed esclusione. Sono inclusi10.1.0.0/24
,10.1.99.0/24
,10.1.101.0/24
,10.1.199.0/24
e10.1.201.0/24
.10.1.255.0/24
Gli intervalli di sottoreti esistenti continuano a funzionare come previsto. Gli intervalli che si sovrappongono a quelli inclusi e esclusi durante la creazione di nuovi intervalli di subnet generano un errore.
Esempi di nuovi intervalli di subnet non validi
Gli esempi seguenti mostrano intervalli di sottoreti non validi:
Intersezione con intervallo di esclusione: supponiamo che esistano i seguenti intervalli di indirizzi IP.
Intervallo incluso:
10.0.0.0/8
Exclude range 4
:10.1.1.0/24
Subnet range 4
:10.1.0.0/16
In questo caso, l'intervallo di inclusione contiene
subnet range 4
. Tuttavia, è un superinsieme diexclude range 4
. Di conseguenza,subnet range 4
non è valido.Sovrapposizione con l'intervallo di inclusione: supponiamo che esistano i seguenti intervalli di indirizzi IP.
Intervallo incluso:
10.1.1.0/24
Subnet range 5
:10.1.0.0/16
Subnet range 5
si sovrappone all'intervallo di inclusione, quindi non è valido.
Se inserisci un intervallo di subnet non valido durante la procedura di creazione della subnet, viene visualizzato un errore Invalid IPCidrRange
simile al seguente:
Invalid IPCidrRange:CIDR_RANGE conflicts with existing subnetworkSUBNET_RANGE in regionREGION
Topologie preimpostate
Network Connectivity Center ti consente di specificare la configurazione di connettività desiderata su tutti gli spoke VPC. Puoi scegliere una delle seguenti due topiarie predefinite:
- Topologia mesh
- Topologia a stella
Quando crei un hub utilizzando il comando gcloud network-connectivity hubs create
, scegli la topologia mesh o a stella preimpostata. Se la topologia non è specificata, viene applicata la topologia mesh. Una volta impostata durante la creazione dell'hub, non puoi modificare la topologia
di un determinato hub.
Per modificare le impostazioni di topologia di uno spoke, puoi eliminarlo e crearne uno nuovo con un nuovo hub che utilizza una topologia diversa.
Topologia mesh
La topologia mesh fornisce connettività di rete su larga scala tra gli spoke VPC. Questa topologia consente a tutti gli spoke di connettersi e comunicare tra loro. Le subnet all'interno di questi spoke VPC sono completamente raggiungibili, a meno che non specifichi i filtri di esportazione da escludere. Per impostazione predefinita, quando due o più reti VPC per i carichi di lavoro sono configurate per partecipare a un hub di Network Connectivity Center come spoke, Network Connectivity Center crea automaticamente una rete mesh completa tra ogni spoke.
Tutti i raggi all'interno della topologia mesh appartengono a un unico gruppo predefinito. La topologia mesh è supportata sui tipi di spoke VPC e ibridi.
Il seguente diagramma mostra la connettività della topologia mesh in Network Connectivity Center.

Topologia a stella
Quando utilizzi la topologia a stella per la connettività, gli spoke di bordo e le relative subnet associate raggiungono solo gli spoke centrali designati, mentre gli spoke centrali possono raggiungere tutti gli altri spoke. In questo modo viene garantita la segmentazione e la separazione della connettività tra le reti VPC perimetrali.
Poiché gli spoke VPC possono essere collegati a un hub in un progetto diverso, gli spoke VPC possono provenire da domini amministrativi diversi. Questi spoke che si trovano in un progetto diverso dall'hub potrebbero non dover comunicare con tutti gli altri spoke nell'hub di Network Connectivity Center.
Puoi scegliere la topologia a stella per i seguenti casi d'uso:
Carichi di lavoro in esecuzione in reti VPC diverse che non richiedono connettività tra loro, ma richiedono l'accesso solo alle reti VPC tramite la rete VPC dei servizi condivisi centrali.
Controllo della sicurezza della comunicazione su più reti VPC che richiede che il traffico passi attraverso un insieme di appliance virtuali di rete (NVA) centralizzate.
Il seguente diagramma mostra la connettività con topologia a stella in Network Connectivity Center.
center-vpc-a
e center-vpc-b
sono associati al gruppo centrale, mentre
edge-vpc-c
e edge-vpc-d
sono associati al gruppo di bordo. In questo caso,
l'utilizzo della topologia a stella consente a edge-vpc-c
e edge-vpc-d
di essere
collegati a center-vpc-a
e center-vpc-b
e di propagare le loro subnet al
gruppo centrale, ma di non essere collegati tra loro (nessuna raggiungibilità diretta
tra edge-vpc-c
e edge-vpc-d
). Nel frattempo, center-vpc-a
e center-vpc-b
sono collegati tra loro e a edge-vpc-c
e
edge-vpc-d
, consentendo così la raggiungibilità completa dai VPC del gruppo centrale ai VPC del gruppo perimetrale.

Gruppi di spoke
Un gruppo di raggi è un sottoinsieme di raggi collegati a un mozzo. Per configurare Network Connectivity Center utilizzando la topologia a stella, devi separare tutti gli spoke VPC in due diversi gruppi, noti anche come domini di routing:
- Un gruppo di spoke centrali che comunicano con tutti gli altri spoke collegati all'hub
- Un gruppo di raggi esterni, che comunicano solo con i raggi appartenenti al gruppo centrale
Uno spoke VPC può appartenere a un solo gruppo alla volta. I gruppi vengono creati automaticamente quando crei un hub.
Un amministratore dell'hub può aggiornare un gruppo di spoke utilizzando il comando gcloud network-connectivity hubs groups update
. L'amministratore dell'hub può aggiungere un elenco di ID progetto o di numeri di progetto per attivare l'accettazione automatica per i raggi. Quando l'accettazione automatica è attivata, lo spoke del progetto con accettazione automatica viene collegato automaticamente all'hub senza che sia necessaria la revisione delle singole proposte di spoke.
Puoi elencare i gruppi center ed edge come risorse nidificate per un hub specifico utilizzando il comando gcloud network-connectivity hubs groups list --hub
.
Per gli hub creati con topologia mesh, l'output restituisce il gruppo predefinito.
Per gli hub creati con topologia a stella, l'output restituisce gruppi centrali e periferici.
Per informazioni dettagliate su come configurare la topologia mesh o a stella per i tuoi spoke VPC, consulta Configurare un hub.
Limitazioni
Questa sezione descrive le limitazioni degli spoke VPC in generale e quando sono collegati a un hub in un altro progetto. Queste limitazioni si applicano anche agli spoke VPC producer (anteprima).
Limiti degli spoke VPC
- Le reti VPC possono connettersi tra loro in modo esclusivo tramite l'hub di Network Connectivity Center o tramite il peering di rete VPC.
- Non puoi utilizzare il peering di rete VPC tra due spoke VPC connessi allo stesso hub Network Connectivity Center. Tuttavia, tieni presente quanto segue:
- Uno spoke VPC producer richiede una connessione di peering a uno spoke VPC sullo stesso hub. La connettività tramite Network Connectivity Center non è stabilita tra lo spoke VPC producer e lo spoke VPC in peering.
- Puoi avere uno spoke VPC collegato a Network Connectivity Center con un peering tramite il peering di rete VPC con un VPC separato che non fa parte di Network Connectivity Center.
- Le VPC connesse tra loro utilizzando Network Connectivity Center e il peering di rete VPC in qualsiasi combinazione non sono transitive.
- Lo scambio di route statiche tra i spoke VPC non è supportato.
- Le route che rimandano agli indirizzi IP virtuali dei bilanciatori del carico di rete passthrough interni in altri spoke VPC non sono supportate.
- L'aggiornamento di
export range filters
dopo la creazione dello spoke VPC non è supportato. - I bilanciatori del carico di rete passthrough interni basati su IPv6 non sono raggiungibili tra gli spoke VPC.
- Lo scambio di route dinamici IPv6 non è supportato.
- Le reti VPC in modalità automatica non sono supportate come spoke VPC. Puoi passare dalla modalità automatica a una rete VPC personalizzata che ti consente di definire manualmente i prefissi della subnet per ogni regione della tua rete VPC. Una volta aggiornato, non puoi annullare questa azione.
Limitazioni dello scambio di percorsi dinamici
Solo IPv4: Network Connectivity Center supporta solo lo scambio di route dinamici IPv4. Lo scambio di route dinamiche IPv6 non è supportato.
Compatibilità dei raggi ibrida con la topologia a stella: un hub configurato per utilizzare la topologia a stella applica le seguenti limitazioni ai suoi raggi ibrida:
- Gli spoke ibride con trasferimento di dati site-to-site abilitato sono supportati solo nel gruppo di spoke centrale.
- Gli spoke ibridi senza trasferimento di dati da sito a sito abilitato possono trovarsi nel gruppo di spoke centrale o nel gruppo di spoke perimetrale.
Reti VPC di routing che sono anche spoke VPC: Network Connectivity Center supporta due o più reti VPC di routing nello stesso hub solo se nessuna di queste è anche uno spoke VPC. Se un hub di Network Connectivity Center ha una singola rete VPC di routing, questa rete VPC di routing può essere facoltativamente anche uno spoke VPC:
Se devi rendere disponibili le connessioni Private Service Connect propagate per le reti on-premise tramite gli spoke ibridi dell'hub, anche la singola rete VPC di routing dell'hub deve essere collegata come spoke VPC.
Se non devi rendere disponibili le connessioni Private Service Connect propagate alle reti on-premise tramite gli spoke ibridi dell'hub, ti consigliamo di non configurare una rete VPC di routing come spoke VPC in modo che l'hub possa supportare due o più reti VPC di routing.
Regole di interazione delle route dinamiche: all'interno di una rete VPC di routing, per ogni destinazione route dinamica univoca con un hop successivo in uno spoke ibrido, devi assicurarti che tutte le altre route dinamiche, indipendentemente dalla priorità, le cui destinazioni corrispondono esattamente o rientrano nella destinazione route dinamica univoca, abbiano tunnel Cloud VPN o VLAN di hop successivo anche in uno spoke ibrido. Inoltre, devi assicurarti che questi spoke ibride utilizzino la stessa impostazione di trasferimento dati da sito a sito (attivata o disattivata).
Se solo alcuni hop successivi per le route dinamiche con una destinazione comune si trovano negli spoke ibride, Network Connectivity Center non può scambiare in modo affidabile le route dinamiche che utilizzano questa destinazione con gli spoke VPC nell'hub. Di conseguenza, gli spoke VPC potrebbero non ricevere queste route dinamiche.
Network Connectivity Center non esegue ECMP tra tutti i hop successivi dei route dinamici a spoke ibridi se per alcuni spoke ibridi è abilitato il trasferimento di dati da sito a sito, ma per altri è disabilitato. Se i percorsi dinamici con una destinazione comune si trovano in spoke ibridi senza impostazioni di trasferimento di dati site-to-site corrispondenti, gli hop successivi per il trasferimento di dati site-to-site o per la connettività tra gli spoke VPC e le reti on-premise potrebbero non essere quelli previsti.
Regole di interazione tra route dinamiche e route statiche: all'interno di una rete VPC di routing, per ogni destinazione univoca della route dinamica che ha un hop successivo in uno spoke ibrido, devi assicurarti che non esistano route statiche locali, indipendentemente dalla priorità, le cui destinazioni corrispondano esattamente alla destinazione della route dinamica o rientrino al suo interno.
Se una route statica locale nella rete VPC di routing ha la stessa destinazione di una route dinamica ibrida dello spoke, gli spoke VPC potrebbero perdere la connettività con la destinazione della route dinamica.
Se una route statica locale in una rete VPC di routing ha una destinazione che rientra nella destinazione di una route dinamica dello spoke ibrida, gli spoke VPC perdono la connettività con la destinazione della route statica.
Periodo di attesa dopo l'eliminazione di uno spoke VPC
Per un nuovo spoke per la stessa rete VPC collegato a un hub diverso, devi attendere il periodo di attesa di almeno 10 minuti. Se non è consentito un periodo di attesa adeguato, la nuova configurazione potrebbe non essere applicata. Questo periodo di attesa non è necessario se la rete VPC viene aggiunta come spoke allo stesso hub.
Quote e limiti
Quando utilizzi lo scambio di route dinamiche, monitora attentamente l'utilizzo del numero di route dinamiche per hub. Questa quota conteggia l'utilizzo solo in base alla destinazione (prefisso), senza tenere conto della priorità o dell'hop successivo di una route dinamica. Quando l'utilizzo di questa quota supera il suo limite, Network Connectivity Center elimina i percorsi in base alla destinazione. Se una destinazione viene eliminata, tutte le route dinamiche con quella destinazione, indipendentemente dalla priorità o dall'hop successivo, non vengono più inviate all'hub.
Per informazioni dettagliate sulle quote, consulta Quote e limiti.
Fatturazione
Ore di spoke
Le ore di spoke vengono addebitate al progetto in cui si trova la risorsa spoke eseguono
seguono i prezzi standard delle ore di spoke. Le ore del raggio vengono addebitate solo quando il raggio è nello stato ACTIVE
.
Traffico in uscita
Il traffico in uscita viene addebitato al progetto della risorsa spoke da cui ha origine il traffico. I prezzi sono gli stessi indipendentemente dal fatto che il traffico superi i confini del progetto.
Accordo sul livello del servizio
Per informazioni sull'accordo sul livello del servizio di Network Connectivity Center, consulta Accordo sul livello del servizio (SLA) di Network Connectivity Center.
Prezzi
Per informazioni sui prezzi, consulta la pagina relativa ai prezzi di Network Connectivity Center.
Passaggi successivi
- Per creare hub e spoke, consulta Utilizzare hub e spoke.
- Per visualizzare un elenco di partner le cui soluzioni sono integrate con Network Connectivity Center, consulta Partner di Network Connectivity Center.
- Per trovare soluzioni ai problemi comuni, consulta la sezione Risoluzione dei problemi.
- Per informazioni dettagliate sui comandi API e
gcloud
, consulta API e riferimenti.