Peering di rete VPC

Il peering di rete VPC di Google Cloud connette due reti Virtual Private Cloud (VPC) in modo che le risorse in ciascuna rete possano comunicare tra loro. Le reti VPC in peering possono trovarsi nello stesso progetto, in progetti diversi della stessa organizzazione o in progetti diversi di organizzazioni diverse.

Specifiche

Il peering di rete VPC consente di:

Connettività

  • Il peering di rete VPC supporta la connessione alle reti VPC, non alle reti legacy.
  • Il peering di rete VPC fornisce connettività IPv4 e IPv6 interna tra coppie di reti VPC. Il traffico in peering (tra reti in peering) ha la stessa latenza, velocità effettiva e disponibilità del traffico all'interno della stessa rete VPC.
    • Il peering di rete VPC non fornisce il routing transitivo. Ad esempio, se le reti VPC net-a e net-b sono connesse tramite peering di rete VPC, e anche le reti VPC net-a e net-c sono connesse tramite peering di rete VPC, il peering di rete VPC non fornisce connettività tra net-b e net-c.
    • Non puoi connettere due reti VPC in modalità automatica usando il peering di rete VPC. Questo perché le reti VPC in peering scambiano sempre route di subnet che utilizzano indirizzi IPv4 interni privati e ciascuna subnet in una rete VPC in modalità automatica utilizza un intervallo di indirizzi IP della subnet che rientra nel blocco CIDR 10.128.0.0/9.
    • Puoi connettere una rete VPC in modalità personalizzata a una rete VPC in modalità automatica purché la rete VPC in modalità personalizzata non abbia intervalli di indirizzi IP della subnet che rientrano in 10.128.0.0/9.
  • Il peering di rete VPC fornisce anche una certa connettività IPv6 esterna agli intervalli di indirizzi IPv6 esterni di destinazione delle seguenti risorse quando le route verso questi indirizzi IPv6 esterni di destinazione vengono scambiate dal peering di rete VPC:
    • Interfacce di rete di istanze di macchine virtuali (VM) a doppio stack
    • Regole di forwarding per il forwarding del protocollo esterno
    • Regole di forwarding per bilanciatori del carico di rete passthrough esterni
  • Il peering di rete VPC supporta la connettività sia IPv4 che IPv6. Puoi configurare il peering di rete VPC su una rete VPC che contiene subnet a doppio stack.

Amministrazione

  • Le reti VPC in peering rimangono separate dal punto di vista amministrativo. Solo le route vengono scambiate, in base alla configurazione del peering.
  • Per stabilire la connettività in peering, un amministratore di rete per ogni rete VPC deve creare una connessione in peering con l'altra rete VPC. Un amministratore di rete di entrambe le reti VPC può disconnettere una connessione in peering.
  • Ogni lato di un'associazione di peering viene impostato in modo indipendente. Il peering sarà attivo solo quando la configurazione di entrambi i lati corrisponde. Entrambe le parti possono scegliere di eliminare l'associazione di peering in qualsiasi momento.
  • La creazione di una connessione in peering non ti concede alcun ruolo di Identity and Access Management (IAM) sull'altra rete VPC. Ad esempio, se disponi del ruolo Amministratore rete Compute o Amministratore sicurezza Compute per una rete, non diventi un amministratore di rete o un amministratore della sicurezza per l'altra rete.

Autorizzazioni IAM

  • Le autorizzazioni IAM per la creazione e l'eliminazione del peering di rete VPC sono incluse nel ruolo Amministratore rete Compute (roles/compute.networkAdmin).
  • Puoi utilizzare un ruolo personalizzato se include le seguenti autorizzazioni:
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

Sicurezza della rete

Il peering di rete VPC non scambia regole firewall VPC o criteri firewall.

Per le regole firewall VPC:

  • Le regole firewall le cui destinazioni sono definite utilizzando tag di rete vengono risolte solo nelle istanze nella rete VPC della regola firewall. Anche se un amministratore della sicurezza di una rete VPC in peering può utilizzare lo stesso tag di rete per definire le destinazioni delle regole firewall in una rete VPC in peering, le destinazioni delle regole firewall nella rete VPC in peering non includono istanze nella tua rete VPC. Allo stesso modo, le regole firewall in entrata le cui origini sono definite utilizzando tag di rete vengono risolte solo nelle istanze nella rete VPC della regola firewall.

  • Le regole firewall le cui destinazioni sono definite utilizzando account di servizio vengono risolte solo per le istanze nella rete VPC della regola firewall. Soggetto alle autorizzazioni IAM, un amministratore della sicurezza di una rete VPC in peering potrebbe essere in grado di utilizzare lo stesso account di servizio per definire le destinazioni delle regole firewall in una rete VPC in peering, ma le destinazioni delle regole firewall nella rete VPC in peering non includono istanze nella tua rete VPC. Analogamente, le regole firewall in entrata le cui origini sono definite tramite account di servizio vengono risolte solo nelle istanze nella rete VPC della regola firewall.

Le regole nei criteri firewall di rete possono utilizzare tag sicuri, diversi dai tag di rete, per identificare destinazioni e origini:

  • Se utilizzato per specificare una destinazione per una regola in entrata o in uscita in un criterio firewall di rete, un tag può identificare solo le destinazioni nella rete VPC a cui è limitato l'ambito del tag.

  • Se utilizzato per specificare un'origine per una regola in entrata in un criterio firewall di rete, un tag può identificare le origini sia nella rete VPC a cui è limitato l'ambito del tag sia nelle reti VPC in peering che sono connesse alla rete VPC a cui è limitato l'ambito del tag. Per ulteriori informazioni, consulta la sezione Tag per i firewall.

Ogni rete VPC contiene regole firewall implicite. A causa delle regole firewall di negazione in entrata implicite, gli amministratori della sicurezza per ciascuna rete VPC devono creare regole firewall di autorizzazione in entrata o regole nei criteri firewall. Le origini di queste regole possono includere intervalli di indirizzi IP di una rete VPC in peering.

A causa delle regole firewall di autorizzazione in uscita implicite, non è necessario creare regole o regole firewall di autorizzazione in uscita nei criteri firewall per consentire i pacchetti verso le destinazioni nella rete VPC in peering, a meno che le reti non includano regole di negazione in uscita.

Supporto DNS

Le risorse in una rete VPC in peering non possono utilizzare nomi DNS interni di Compute Engine creati da una rete VPC locale.

Una rete VPC in peering non può utilizzare zone private gestite di Cloud DNS autorizzate solo per una rete VPC locale. Per rendere i nomi DNS disponibili per le risorse in una rete VPC in peering, utilizza una delle seguenti tecniche:

Supporto del bilanciatore del carico interno

I client in una rete VPC locale possono accedere ai bilanciatori del carico interni in una rete VPC peer. Per ulteriori informazioni, consulta le sezioni Utilizzare il peering di rete VPC della seguente documentazione sui bilanciatori del carico:

Le reti in peering possono scambiare route statiche che utilizzano bilanciatori del carico di rete passthrough interni come hop successivi. Per saperne di più, consulta Opzioni di scambio di routing.

Gruppo di peering e quote

Le quote di peering VPC dipendono da un concetto chiamato gruppo di peering. Ogni rete VPC ha il proprio gruppo di peering composto da se stessa e da tutte le altre reti VPC a essa connesse tramite il peering di rete VPC. Nello scenario più semplice, se due reti VPC, net-a e net-b, sono connesse in peering tra loro, esistono due gruppi di peering: uno dal punto di vista di net-a e l'altro dal punto di vista di net-b.

Per ulteriori informazioni sulle quote di peering di rete VPC, vedi:

Opzioni di scambio percorso

Quando una rete VPC condivide route locali con una rete VPC in peering, esporta le route. La rete VPC in peering può quindi import le route. Le route di subnet, ad eccezione delle route di subnet IPv4 che utilizzano indirizzi IPv4 pubblici utilizzati privatamente, vengono sempre scambiate.

La configurazione del peering di rete VPC consente di controllare quanto segue:

  • Se vengono scambiate le route IPv6.
  • Se vengono esportate o importate le route per le subnet che utilizzano indirizzi IPv4 pubblici utilizzati privatamente.
  • Se le route statiche e dinamiche vengono esportate o importate.

Puoi aggiornare la configurazione prima che venga stabilito il peering o mentre la connettività in peering è attiva.

Il peering di rete VPC non fornisce:

  • Un metodo granulare per controllare lo scambio di route di subnet specifiche, route statiche e dinamiche.
  • Supporto per lo scambio di route basate su criteri.

Opzioni per lo scambio di route di subnet

La seguente tabella descrive le opzioni di scambio di route per le route subnet:

Tipo di route Condizioni di esportazione route Condizioni di importazione delle route
Route di subnet IPv4 (intervalli di subnet IPv4 primari e secondari) che utilizzano intervalli di indirizzi IPv4 privati Sempre esportato

Non può essere disattivato		 Sempre importata

Non può essere disattivata
Route di subnet IPv4 (intervalli di subnet IPv4 primari e secondari) che utilizzano intervalli di indirizzi IPv4 pubblici utilizzati privatamente Esportato per impostazione predefinita

L'esportazione è controllata utilizzando il flag --export-subnet-routes-with-public-ip 		Importazione non eseguita per impostazione predefinita

L'importazione è controllata utilizzando il flag --import-subnet-routes-with-public-ip
Intervalli di subnet IPv6 interne
(ipv6-access-type=INTERNAL) 		Non esportate per impostazione predefinita

L'esportazione è abilitata mediante l'impostazione --stack-type=IPV4_IPV6 		Non importata per impostazione predefinita

L'importazione è abilitata tramite l'impostazione --stack-type=IPV4_IPV6
Intervalli di subnet IPv6 esterne
(ipv6-access-type=EXTERNAL) 		Non esportate per impostazione predefinita

L'esportazione è abilitata mediante l'impostazione --stack-type=IPV4_IPV6 		Non importata per impostazione predefinita

L'importazione è abilitata tramite l'impostazione --stack-type=IPV4_IPV6

Opzioni per lo scambio di route statiche

La seguente tabella descrive le opzioni di scambio di route per le route statiche.

Tipo di route Condizioni di esportazione route Condizioni di importazione delle route
Route statiche con tag di rete (tutti i tipi di hop successivo) Impossibile esportare Impossibile importare
Route statiche che utilizzano l'hop successivo del gateway internet predefinito Impossibile esportare Impossibile importare
Route statiche IPv4, senza tag di rete, che utilizzano un hop successivo diverso dal gateway internet predefinito Esportazione non eseguita per impostazione predefinita

L'esportazione è controllata mediante il flag --export-custom-routes 		Importazione non eseguita per impostazione predefinita

L'importazione è controllata mediante il flag --import-custom-routes
Route statiche IPv6, senza tag di rete, che utilizzano un'istanza VM come hop successivo Esportazione non eseguita per impostazione predefinita

L'esportazione è controllata utilizzando il flag --export-custom-routes quando il tipo di stack del peering è impostato su --stack-type=IPV4_IPV6 		Non importato per impostazione predefinita

L'importazione è controllata usando il flag --import-custom-routes quando il tipo di stack del peering è impostato su --stack-type=IPV4_IPV6

Opzioni per lo scambio di route dinamiche

La seguente tabella descrive le opzioni di scambio di route per le route dinamiche.

Tipo di route Condizioni di esportazione route Condizioni di importazione delle route
Route IPv4 dinamiche Esportazione non eseguita per impostazione predefinita

L'esportazione è controllata mediante il flag --export-custom-routes 		Importazione non eseguita per impostazione predefinita

L'importazione è controllata mediante il flag --import-custom-routes
Route IPv6 dinamiche Esportazione non eseguita per impostazione predefinita

L'esportazione è controllata utilizzando il flag --export-custom-routes quando il tipo di stack del peering è impostato su --stack-type=IPV4_IPV6 		Non importato per impostazione predefinita

L'importazione è controllata usando il flag --import-custom-routes quando il tipo di stack del peering è impostato su --stack-type=IPV4_IPV6

Vantaggi dello scambio di route statiche e dinamiche

Quando una rete VPC esporta route statiche e dinamiche e l'altra rete VPC importa queste route, la rete di importazione può inviare pacchetti direttamente all'hop successivo per ogni route statica o dinamica importata il cui hop successivo si trova nella rete VPC peer.

Un amministratore di rete di una rete VPC locale controlla l'esportazione delle route statiche e dinamiche di quella rete insieme tramite il flag --export-custom-routes. Un amministratore di rete della rete VPC in peering corrispondente controlla l'importazione di queste route statiche e dinamiche utilizzando il flag --import-custom-routes. Per maggiori informazioni, consulta Route ignorate, Interazioni di route di subnet di subnet e peering e Interazioni di route statiche e subnet.

L'importazione di route statiche e dinamiche da una rete VPC in peering può essere utile nei seguenti scenari:

  • Se la rete VPC in peering contiene cluster GKE basati su route e devi inviare pacchetti ai pod in questi cluster. Gli indirizzi IP dei pod vengono implementati come intervalli di destinazione per le route statiche che si trovano nella rete VPC in peering.
  • Se devi fornire connettività tra una rete on-premise e una rete VPC in peering. Supponiamo che una rete VPC locale contenga route dinamiche con un tunnel Cloud VPN dell'hop successivo, un collegamento Cloud Interconnect (VLAN) o un'appliance router che si connette a una rete on-premise. Per fornire un percorso dalla rete VPC in peering alla rete on-premise, un amministratore di rete per la rete VPC locale abilita l'esportazione delle route personalizzate, mentre un amministratore di rete per la rete VPC in peering consente l'importazione di route personalizzate. Per fornire un percorso dalla rete on-premise alla rete VPC in peering, un amministratore di rete per la rete VPC locale deve utilizzare annunci pubblicitari di route personalizzati del router Cloud sul router Cloud che gestisce la sessione BGP per il tunnel Cloud VPN, il collegamento Cloud Interconnect (VLAN) o l'appliance router che si connette alla rete on-premise. I contenuti di questi annunci di route personalizzati devono includere gli intervalli di indirizzi IP della subnet della rete VPC in peering.

Percorsi ignorati

Anche quando una rete VPC importa una route, può ignorare la route importata in situazioni come le seguenti:

  • Quando la rete VPC locale ha una route con una destinazione identica o più specifica (subnet mask più lunga), la rete VPC locale utilizza sempre la sua route locale.

  • Quando la rete VPC locale non contiene la route più specifica per la destinazione di un pacchetto, ma due o più reti VPC in peering contengono la stessa destinazione più specifica per il pacchetto, Google Cloud utilizza un algoritmo interno per selezionare un hop successivo da una sola delle reti VPC in peering. Questa selezione avviene prima che venga considerata la priorità delle route e non puoi configurare il comportamento. Come best practice, evita questa configurazione perché l'aggiunta o la rimozione di reti VPC in peering può comportare modifiche indesiderate all'ordine di routing.

Per ulteriori dettagli sulle situazioni precedenti, consulta Ordine di routing.

Per i peering a doppio stack, se una rete VPC locale che importa route IPv6 non ha subnet a doppio stack, non puoi utilizzare nessuna delle route IPv6 che riceve dalle reti VPC in peering. Inoltre, se il vincolo del criterio dell'organizzazione constraints/compute.disableAllIpv6 è stato configurato, un amministratore di rete potrebbe non essere in grado di creare subnet a doppio stack.

Interazioni con route di subnet e subnet di peering

Le route di subnet IPv4 nelle reti VPC in peering non possono sovrapporsi:

  • Il peering vieta route di subnet IPv4 identiche. Ad esempio, due reti VPC in peering non possono avere entrambe una route di subnet IPv4 la cui destinazione sia 100.64.0.0/10.
  • Il peering impedisce che una route di subnet sia contenuta all'interno di una route subnet di peering. Ad esempio, se la rete VPC locale ha una route di subnet la cui destinazione è 100.64.0.0/24, nessuna delle reti VPC in peering può avere una route di subnet la cui destinazione è 100.64.0.0/10.

Google Cloud applica le condizioni precedenti per le route di subnet IPv4 nei seguenti casi:

  • Quando connetti le reti VPC per la prima volta utilizzando il peering di rete VPC.
  • Mentre le reti sono in peering.
  • Quando modifichi la configurazione del peering, ad esempio abilitando l'importazione di route IPv4 di subnet, con indirizzi IP pubblici utilizzati privatamente.

Mentre colleghi le reti in peering, Google Cloud restituisce un errore se una delle seguenti operazioni genera una sovrapposizione:

Le route di subnet IPv6 (interne ed esterne) sono uniche per definizione. Due reti VPC non possono usare gli stessi intervalli di subnet IPv6 interne o esterne. Ad esempio, se una rete VPC utilizza fc:1000:1000:1000::/64 come intervallo di subnet IPv6, nessun'altra rete VPC in Google Cloud può utilizzare fc:1000:1000:1000::/64, a prescindere dal fatto che le reti VPC siano connesse tramite peering di rete VPC.

Interazioni con subnet e route statiche

Google Cloud richiede che le route di subnet e le route di subnet di peering abbiano gli intervalli IPv4 o IPv6 di destinazione più specifici. All'interno di qualsiasi rete VPC, una route statica locale non può avere una destinazione che corrisponda esattamente a o che rientri in una route di subnet locale. Per una discussione più dettagliata su questo scenario, consulta Interazioni con route statiche.

Questo concetto è esteso al peering di rete VPC dalle due regole seguenti:

  • Una route statica locale non può avere una destinazione che corrisponda esattamente a una route della subnet di peering o che rientri in una route. Se esiste una route statica locale, Google Cloud applica quanto segue:

    • Non puoi stabilire una nuova connessione in peering a una rete VPC che contiene già una route subnet che corrisponde esattamente a o contiene la destinazione della route statica locale se la configurazione del peering genera l'importazione della route della subnet in conflitto. Ad esempio:

      • Se esiste una route statica locale con la destinazione 10.0.0.0/24, non puoi stabilire una nuova connessione in peering a una rete VPC che contiene una route di subnet IPv4 la cui destinazione corrisponde esattamente a 10.0.0.0/24 o contiene 10.0.0.0/24 (ad esempio, 10.0.0.0/8).

      • Quando il tipo di stack di peering previsto è IPV4_IPV6, se esiste una route statica locale con la destinazione 2001:0db8:0a0b:0c0d::/96, non puoi stabilire una nuova connessione in peering a una rete VPC che contiene una route di subnet IPv6 la cui destinazione corrisponde esattamente a o contiene 2001:0db8:0a0b:0c0d::/96. In questa situazione, l'unico intervallo di indirizzi IPv6 della subnet possibile è 2001:0db8:0a0b:0c0d::/64, perché gli intervalli di indirizzi IPv6 della subnet in Google Cloud devono utilizzare lunghezze della subnet mask a 64 bit.

    • Non puoi aggiornare una connessione in peering esistente se la configurazione del peering aggiornata genera l'importazione della route della subnet in conflitto. Ad esempio:

      • Supponiamo che due reti VPC siano già in peering, ma che al momento non esportano e importano route di subnet IPv4 utilizzando intervalli di indirizzi IPv4 pubblici utilizzati privatamente. Una route statica locale con la destinazione 11.0.0.0/24 esiste nella prima rete VPC, mentre una route subnet con la destinazione 11.0.0.0/8 esiste nella rete VPC in peering. Non puoi configurare contemporaneamente la rete VPC in peering per esportare le route delle subnet utilizzando indirizzi IPv4 pubblici utilizzati privatamente e configurare la prima rete VPC per importare le route di subnet utilizzando indirizzi IPv4 pubblici utilizzati privatamente.

      • Supponiamo che due reti VPC siano già in peering e che il tipo di stack di peering sia solo IPv4. Nella prima rete VPC esiste una route statica locale con la destinazione 2001:0db8:0a0b:0c0d::/96, mentre nella rete VPC in peering esiste una route IPv6 con la destinazione 2001:0db8:0a0b:0c0d::/64. Non puoi modificare il tipo di stack di peering in IPV4_IPV6.

    • Al contrario, se le reti VPC sono già connesse tramite peering di rete VPC, non puoi eseguire le seguenti operazioni:

      • Creare una nuova route statica locale la cui destinazione corrisponderebbe esattamente a una route della subnet di peering importata.

      • Crea un nuovo intervallo di indirizzi di subnet nella rete VPC in peering se questo intervallo corrisponde esattamente a o contenere una route statica locale esistente.

  • Una route statica di peering non può avere una destinazione che corrisponde esattamente o rientra in una route di subnet locale. Se esiste una route subnet locale, Google Cloud vieta quanto segue:

    • Non puoi stabilire una nuova connessione in peering a una rete VPC che contiene già una route statica che corrisponde esattamente o rientra nella destinazione della route di subnet della rete VPC locale, se la configurazione di peering comporta l'importazione della route statica dal peer. Esempi:

      • Se esiste una route subnet locale per 10.0.0.0/8, non puoi stabilire una connessione in peering a una rete VPC con una route statica la cui destinazione corrisponde esattamente a 10.0.0.0/8 o rientra in 10.0.0.0/8 (ad esempio, 10.0.0.0/24).

      • Quando il tipo di stack di peering previsto è IPV4_IPV6, se esiste una route subnet locale per 2001:0db8:0a0b:0c0d::/64, non puoi stabilire una connessione in peering a una rete VPC con una route statica la cui destinazione corrisponde esattamente a 2001:0db8:0a0b:0c0d::/64 o rientra in 2001:0db8:0a0b:0c0d::/64 (ad esempio, 2001:0db8:0a0b:0c0d::/96).

    • Non puoi aggiornare una connessione in peering esistente se la configurazione di peering aggiornata comporta l'importazione della route statica in conflitto.

    • Al contrario, se le reti VPC sono già connesse tramite peering di rete VPC, non puoi eseguire le seguenti operazioni:

      • Creare una nuova route di subnet locale la cui destinazione corrisponderebbe esattamente a o conterrà una route statica di peering importata.
      • Crea una nuova route statica nella rete VPC in peering la cui destinazione corrisponderebbe esattamente a una route della subnet locale esistente o vi adatta.

Effetti della modalità di routing dinamico

La modalità di routing dinamico di una rete VPC determina le regioni in cui i prefissi appresi dai router Cloud in quella rete vengono applicati come route dinamiche locali. Per maggiori dettagli su questo comportamento, vedi Effetti della modalità di routing dinamico.

Questo concetto è esteso al peering di rete VPC. La modalità di routing dinamico della rete VPC in exporting, la rete che contiene i router Cloud che hanno appreso i prefissi per queste route dinamiche, determina le regioni in cui le route dinamiche di peering possono essere programmate nelle reti peer:

  • Se la modalità di routing dinamico della rete VPC esportata è a livello di regione, la rete esporta le route dinamiche solo nella stessa regione dei router Cloud che hanno appreso i prefissi.

  • Se la modalità di routing dinamico della rete VPC esportata è globale, la rete esporta le route dinamiche in tutte le regioni.

In entrambi i casi, la modalità di routing dinamico della rete VPC di importazione non è pertinente.

Per un esempio che illustra questo comportamento, consulta Rete VPC locale e rete VPC peer con connettività on-premise.

Interazioni con subnet e route dinamiche

I conflitti tra route di subnet locali o di peering e route dinamiche vengono risolti come descritto in Interazioni con route dinamiche.

Esempi di peering di rete VPC

I seguenti esempi mostrano due scenari comuni di peering di rete VPC.

Rete VPC locale e rete VPC peer con connettività on-premise

In questo esempio, viene impostato il seguente peering di rete:

  • network-a è connesso in peering a network-b e network-b è connesso in peering a network-a.
  • network-a contiene due subnet, ognuna delle quali si trova in una regione separata. network-b contiene una singola subnet.
  • network-b è connesso a una rete on-premise con tunnel Cloud VPN utilizzando il routing dinamico. Gli stessi principi valgono anche nel caso in cui i tunnel vengano sostituiti con collegamenti VLAN di Cloud Interconnect.
  • La connessione in peering per network-b è configurata con il flag --export-custom-routes, mentre la connessione in peering per network-a è configurata con il flag --import-custom-routes.

Per fornire connettività da on-premise alle subnet in network-a e network-b, il router Cloud in network-b deve essere configurato in modo da utilizzare la pubblicità di route personalizzata. Ad esempio, il router Cloud pubblicizza solo il prefisso personalizzato custom-prefix-1, che include gli intervalli di subnet da network-b e gli intervalli di subnet da network-a.

Il router Cloud in us-west1 apprende on-premises-prefix da un router on-premise. on-premises-prefix non crea conflitti perché è più ampia delle route della subnet e della subnet di peering. In altre parole, on-premises-prefix non corrisponde esattamente a e non si adatta in nessuna route subnet o subnet di peering.

La tabella seguente riassume la configurazione di rete specificata nell'esempio precedente:

Nome rete Componente di networking Intervallo IPv4 Intervallo IPv6 Regione

network-a

subnet-a

10.0.0.0/24

fc:1000:1000:1000::/64

us-west1

network-a

subnet-b

10.0.1.0/24

fc:1000:1000:1001::/64

europe-north 1

network-b

subnet-c

10.0.2.0/23

fc:1000:1000:1002::/64

us-west1

network-b

Router Cloud

10.0.0.0/22

fc:1000:1000:1000::/64

us-west1

Rete on-premise

Router on-premise

10.0.0.0/8

fc:1000:1000:1000::/56

N/A

Indipendentemente dalla modalità di routing dinamico di network-a, si applicano le seguenti caratteristiche di routing:

  • Quando la modalità di routing dinamico di network-b è globale, i On-premises prefix appresi dal router Cloud in network-b vengono aggiunti come route dinamiche in tutte le regioni di network-b e come route dinamiche di peering in tutte le regioni di network-a. Se le regole firewall sono configurate correttamente, vm-a1, vm-a2 e vm-b possono comunicare con una risorsa on-premise con l'indirizzo IPv4 10.5.6.7 (o l'indirizzo IPv6 fc:1000:1000:10a0:29b::).

  • Se la modalità di routing dinamico di network-b viene modificata in regionale, i On-premises prefix rilevati dal router Cloud in network-b vengono aggiunti solo come route dinamiche nella regione us-west1 di network-b e come route dinamiche di peering nella regione us-west1 di network-a. Se le regole firewall sono configurate correttamente, solo vm-a1 e vm-b possono comunicare con una risorsa on-premise con indirizzo IPv4 10.5.6.7 (o indirizzo IPv6 fc:1000:1000:10a0:29b::) perché questa è l'unica VM nella stessa regione del router Cloud.

Rete di trasporto pubblico

Nell'esempio seguente, network-b funge da rete di trasporto pubblico.

  • network-a è connesso in peering a network-b e network-b è connesso in peering con network-a.
  • network-c è connesso in peering a network-b e network-b è connesso in peering con network-c.
  • network-b è connesso a una rete on-premise con i tunnel Cloud VPN tramite il routing dinamico. Gli stessi principi valgono nel caso in cui i tunnel vengano sostituiti con collegamenti VLAN di Cloud Interconnect.
    • Per fornire connettività da on-premise alle subnet in network-a, network-b e network-c, il router Cloud in network-b è configurato in modo da utilizzare la pubblicità di route personalizzata. Ad esempio, il router Cloud pubblicizza route di subnet da network-b oltre a prefissi personalizzati che coprono le route di subnet in network-a e network-c.
    • Soggetto alle interazioni di subnet e route dinamiche, il router Cloud in network-b apprende i prefissi on-premise e crea route dinamiche in network-b.
  • Le connessioni in peering da network-b a network-a e da network-b a network-c sono configurate con il flag --export-custom-routes. Le connessioni in peering da network-a a network-b e da network-c a network-b sono configurate con il flag --import-custom-routes.

Se i firewall sono configurati correttamente, si possono verificare i seguenti scenari di connettività:

  • Le istanze VM in network-a possono raggiungere altre VM in network-b e i sistemi on-premise.
  • Le istanze VM in network-c possono raggiungere altre VM in network-b e i sistemi on-premise.
  • Le istanze VM in network-b possono raggiungere altre VM sia in network-a che network-c, nonché sistemi nella rete on-premise.

Poiché il peering di rete VPC non è transitivo, le istanze VM in network-a e network-c non possono comunicare tra loro a meno che non connetti anche le reti network-a e network-c utilizzando il peering di rete VPC.

Prezzi

Al peering di rete VPC si applicano i prezzi di rete standard.

Passaggi successivi