Peering di rete VPC

Il peering di reti VPC Google Cloud connette due reti VPC (Virtual Private Cloud) in modo che le risorse di ciascuna rete possano comunicare tra loro. Le reti VPC con 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 ti consente di svolgere le seguenti operazioni:

Connettività

  • Il peering di rete VPC supporta la connessione di reti VPC, non di reti legacy.
  • Il peering di rete VPC fornisce connettività IPv4 e IPv6 interna tra coppie di reti VPC. Il traffico in peering (traffico che scorre 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 il peering di rete VPC e anche le reti VPC net-a e net-c sono connesse tramite il 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 utilizzando il peering di rete VPC. Questo perché le reti VPC con peer scambiano sempre route di subnet che utilizzano indirizzi IPv4 interni privati e ogni subnet in una rete VPC in modalità automatica utilizza un intervallo di indirizzi IP di subnet che rientra nel blocco CIDR 10.128.0.0/9.
    • Puoi collegare una rete VPC in modalità personalizzata a una rete VPC in modalità automatica, a condizione che la rete VPC in modalità personalizzata non abbia intervalli di indirizzi IP delle subnet che rientrano in 10.128.0.0/9.
  • Il peering di reti VPC fornisce anche una certa connettività IPv6 esterna agli intervalli di indirizzi IPv6 esterni di destinazione delle seguenti risorse quando le route per questi indirizzi IPv6 esterni di destinazione vengono scambiate dal peering di reti VPC:
    • Interfacce di rete delle istanze di macchine virtuali (VM) dual-stack
    • Regole di forwarding per il forwarding del protocollo esterno
    • Regole di inoltro per i bilanciatori del carico di rete passthrough esterni
  • Il peering di rete VPC supporta la connettività IPv4 e IPv6. Puoi configurare il peering di rete VPC su una rete VPC contenente subnet a doppio stack.

Amministrazione

  • Le reti VPC in peering rimangono separate dal punto di vista amministrativo. Vengono scambiate solo le route, in base alla configurazione del peering.
  • Per stabilire la connettività di peering, un amministratore di rete per ogni rete VPC deve creare una connessione di peering con l'altra rete VPC. Un amministratore di rete di una delle reti VPC può scollegare una connessione di peering.
  • Ogni lato di un'associazione di peering viene configurato in modo indipendente. Il peering sarà attivo solo quando la configurazione di entrambe le parti corrisponde. Ciascuna delle parti può scegliere di eliminare l'associazione di peering in qualsiasi momento.
  • La creazione di una connessione in peering non ti concede alcun ruolo IAM (Identity and Access Management) sull'altra rete VPC. Ad esempio, se disponi del ruolo Amministratore rete Compute o del ruolo Amministratore della sicurezza Compute per una rete, non diventi Amministratore di rete o 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 di 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

Le reti VPC connesse tramite il peering di rete VPC scambiano solo route, in base alle opzioni di scambio route configurate da un amministratore di rete di ogni rete VPC.

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

Per le regole firewall VPC:

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

  • Le regole firewall i cui target sono definiti utilizzando gli account di servizio vengono risolte solo nelle istanze della rete VPC della regola firewall. In base alle autorizzazioni IAM, un amministratore della sicurezza di una rete VPC con peering potrebbe essere in grado di utilizzare lo stesso account di servizio per definire i target delle regole firewall in una rete VPC con peering, ma i target delle regole firewall nella rete VPC con peering non includono le istanze nella tua rete VPC. Analogamente, le regole firewall in entrata le cui origini sono definite utilizzando gli account di servizio vengono risolte solo nelle istanze della 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 si applica il tag.

  • Se utilizzato per specificare una sorgente per una regola di ingresso in un criterio del firewall di rete, un tag può identificare le sorgenti sia nella rete VPC a cui si applica il tag che in tutte le reti VPC in peering collegate alla rete VPC a cui si applica il tag. Per ulteriori informazioni, consulta la sezione Tag per i firewall.

Ogni rete VPC contiene regole firewall implicite. A causa delle regole firewall di immissione con divieto implicito, gli amministratori della sicurezza di ogni rete VPC devono creare regole firewall di immissione consentite o regole nelle policy firewall. Le origini di queste regole possono includere intervalli di indirizzi IP di una rete VPC con peering.

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

Supporto DNS

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

Una rete VPC con peering non può utilizzare le zone private gestite da Cloud DNS autorizzate solo per una rete VPC locale. Per rendere disponibili i nomi DNS alle risorse in una rete VPC connessa 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 del bilanciatore del carico:

Le reti con peering possono scambiarsi route statiche che utilizzano bilanciatori del carico di rete passthrough interni come hop successivi. Per ulteriori informazioni, consulta la sezione Opzioni di scambio route.

Gruppo di peering e quote

Le quote di peering VPC dipendono da un concetto chiamato gruppo di peering. Ogni rete VPC ha un proprio gruppo di peering costituito da se stessa e da tutte le altre reti VPC connesse tramite il peering di rete VPC. Nello scenario più semplice, se due reti VPC, net-a e net-b, sono collegate 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 del peering di rete VPC, consulta:

Limitazioni

Il peering di rete VPC presenta i seguenti limiti.

Gli intervalli IP delle subnet non possono sovrapporsi tra le reti VPC in peering

Nessun intervallo IP di una subnet può corrispondere esattamente, contenere o rientrare in un altro intervallo IP di una subnet in una rete VPC in peering. Al momento del peering, Google Cloud controlla se esistono subnet con intervalli IP sovrapposti. Se sono presenti, il peering non va a buon fine. Per le reti già in peering, se esegui un'azione che comporta la creazione di un nuovo percorso della subnet, Google Cloud richiede che il nuovo percorso della subnet abbia un intervallo di indirizzi IP di destinazione unico.

Prima di creare nuove subnet, puoi elencare le route dalle connessioni in peering per assicurarti che l'intervallo di indirizzi IPv4 della nuova subnet non sia già in uso.

Questo limite e i controlli corrispondenti di Google Cloud si applicano anche a scenari come i seguenti:

  • La tua rete VPC, network-1, è in peering con una seconda rete VPC, network-2.
  • network-2 è in peer anche con una terza rete VPC, network-3.
  • network-3 non è connessa in peering con network-1.

In questo caso, devi coordinarti con un amministratore di rete per network-2. Chiedi all'amministratore di rete di network-2 elencare le route di peering nella sua rete VPC.

Per ulteriori informazioni sui controlli di sovrapposizione, consulta Interazioni tra route di subnet e subnet di peering.

I nomi DNS interni non vengono risolti nelle reti con peering

I nomi DNS interni di Compute Engine creati in una rete non sono accessibili alle reti con peering. Per raggiungere le istanze VM nella rete connessa in peering, utilizza l'indirizzo IP della VM.

I tag e gli account di servizio non sono utilizzabili nelle reti connesse in peer

Non puoi fare riferimento a un tag o a un account di servizio appartenenti a una VM di una rete in una regola firewall dell'altra rete. Ad esempio, se una regola di ingresso in una rete in peering filtra la sorgente in base a un tag, si applica solo al traffico VM proveniente da quella rete, non ai suoi peer, anche se una VM in una rete in peering ha quel tag. Questa situazione vale anche per gli account di servizio.

Opzioni di scambio di route

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

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

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

Puoi aggiornare la configurazione prima dell'instaurazione del peering o mentre la connettività del peering è attiva.

Il peering di rete VPC non fornisce:

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

Opzioni per lo scambio di route di subnet

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

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

Non può essere disattivato		 Importato sempre

Non può essere disattivato
Route di subnet IPv4 (intervalli di subnet IPv4 principali 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 		Non importato per impostazione predefinita

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

L'esportazione è attivata impostando --stack-type=IPV4_IPV6 		Non importato per impostazione predefinita

L'importazione è attivata impostando --stack-type=IPV4_IPV6
Intervalli di subnet IPv6 esterni
(ipv6-access-type=EXTERNAL) 		Non esportato per impostazione predefinita

L'esportazione è attivata impostando --stack-type=IPV4_IPV6 		Non importato per impostazione predefinita

L'importazione è attivata impostando --stack-type=IPV4_IPV6

Opzioni per lo scambio di route statici

La tabella seguente descrive le opzioni di scambio di percorsi per i percorsi statici.

Tipo di route Condizioni di esportazione dei route Condizioni di importazione dei percorsi
Route statiche con tag di rete (tutti i tipi di hop successivi) Impossibile esportare Non può essere importato
Route statiche che utilizzano l'hop successivo del gateway internet predefinito Impossibile esportare Non può essere importato
Route IPv4 statiche, senza tag di rete, che utilizzano un hop successivo diverso dal gateway internet predefinito Non esportato per impostazione predefinita

L'esportazione è controllata utilizzando il flag --export-custom-routes 		Non importato per impostazione predefinita

L'importazione è controllata utilizzando il flag --import-custom-routes
Route statiche IPv6, senza tag di rete, che utilizzano un'istanza VM come hop successivo Non esportato 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 utilizzando il flag --import-custom-routes quando il tipo di stack del peering è impostato su --stack-type=IPV4_IPV6

Opzioni per lo scambio di percorsi dinamici

La tabella seguente descrive le opzioni di scambio dei percorsi per percorsi dinamici.

Tipo di route Condizioni di esportazione dei route Condizioni di importazione dei percorsi
Route IPv4 dinamiche Non esportato per impostazione predefinita

L'esportazione è controllata utilizzando il flag --export-custom-routes 		Non importato per impostazione predefinita

L'importazione è controllata utilizzando il flag --import-custom-routes
Route IPv6 dinamiche Non esportato 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 utilizzando 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 le importa, la rete di importazione può inviare i 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 della rete utilizzando il flag --export-custom-routes. Un amministratore di rete della rete VPC con peering corrispondente controlla l'importazione di queste route statiche e dinamiche utilizzando il flag --import-custom-routes. Per ulteriori informazioni, consulta Route ignorate, Interazioni tra route di subnet e route di subnet di peering e Interazioni tra route di subnet e route statiche.

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

  • Se la rete VPC in peer contiene cluster GKE basati su route e devi inviare pacchetti ai pod di questi cluster. Gli indirizzi IP dei pod vengono implementati come intervalli di destinazione per le route statiche situate 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 di 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 con peering alla rete on-premise, un amministratore di rete per la rete VPC locale attiva l'esportazione delle route personalizzate e un amministratore di rete per la rete VPC con peering attiva l'importazione delle route personalizzate. Per fornire un percorso dalla rete on-premise alla rete VPC in coppia, un amministratore di rete per la rete VPC locale deve configurare la modalità di annuncio personalizzato del router Cloud sul router Cloud che gestisce la sessione BGP per il tunnel Cloud VPN, il collegamento VLAN di Cloud Interconnect o l'appliance router che si connette alla rete on-premise. I contenuti di queste route pubblicizzate personalizzate 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ò ignorarla in situazioni come le seguenti:

  • Quando la rete VPC locale ha una route con una destinazione identica o più specifica (maschera di sottorete 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 viene effettuata prima di considerare la priorità del percorso e non puoi configurare il comportamento. Come buona prassi, evita questa configurazione perché l'aggiunta o la rimozione di reti VPC connesse in peer può comportare modifiche indesiderate all'ordine di routing.

Per maggiori 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 è possibile utilizzare nessuna delle route IPv6 che riceve dalle reti VPC in peering. Inoltre, se è stato impostato il vincolo delle norme dell'organizzazione constraints/compute.disableAllIpv6, un amministratore di rete potrebbe non essere in grado di creare reti sottostanti dual-stack.

Interazioni tra route di subnet e route di subnet di peering

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

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

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

  • Quando colleghi le reti VPC per la prima volta utilizzando il peering di rete VPC.
  • Mentre le reti sono in peering.
  • Quando apporti una modifica alla configurazione del peering, ad esempio attivando l'importazione di route IPv4 di subnet con indirizzi IP pubblici utilizzati privatamente.

Durante l'accoppiamento delle reti, Google Cloud restituisce un errore se una delle seguenti operazioni comporta un'interferenza:

I route di subnet IPv6 (interni ed esterni) sono univoci per definizione. Nessuna delle due reti VPC può utilizzare gli stessi intervalli di subnet IPv6 interni o esterni. 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, indipendentemente dal fatto che le reti VPC siano connesse tramite il peering di rete VPC.

Interazioni tra 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 corrisponde esattamente o si inserisce in una route della subnet locale. Per una discussione più dettagliata su questo scenario, consulta Interazioni con i percorsi statici.

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

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

    • Non puoi stabilire una nuova connessione di peering con una rete VPC che contiene già una route della subnet che corrisponde esattamente alla destinazione della route statica locale o la contiene se la configurazione del peering comporta 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 di 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 di peering a una rete VPC contenente una route della subnet IPv6 la cui destinazione corrisponde esattamente a 2001:0db8:0a0b:0c0d::/96 o la contiene. 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 di subnet mask a 64 bit.

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

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

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

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

      • Crea una nuova route statica locale la cui destinazione corrisponde esattamente o rientra in una route della subnet di peering importata.

      • Crea un nuovo intervallo di indirizzi della subnet nella rete VPC in peering se l'intervallo corrisponde esattamente o contiene una route statica locale esistente.

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

    • Non puoi stabilire una nuova connessione di peering con una rete VPC che contiene già una route statica che corrisponde esattamente alla destinazione della route della subnet della rete VPC locale o che si inserisce al suo interno, se la configurazione del peering comporta l'importazione della route statica dal peer. Ad esempio:

      • Se esiste una route per la subnet locale per 10.0.0.0/8, non puoi stabilire una connessione in peering con 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 della subnet locale per 2001:0db8:0a0b:0c0d::/64, non puoi stabilire una connessione di peering con 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 di peering esistente se la configurazione del peering aggiornata comporta l'importazione della route statica in conflitto.

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

      • Crea un nuovo percorso della subnet locale la cui destinazione corrisponde esattamente o contiene una route statica di peering importata.
      • Crea una nuova route statica nella rete VPC in peering la cui destinazione corrisponde esattamente o rientra in una route della subnet locale esistente.

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 nella rete vengono applicati come route dinamiche locali. Per informazioni dettagliate su questo comportamento, consulta Effetti della modalità di routing dinamico.

Questo concetto è esteso al peering di rete VPC. La modalità di routing dinamico della rete VPC di esportazione, ovvero 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 di esportazione è regionale, 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 di esportazione è 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 tra subnet e route dinamiche

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

Esempi di peering di rete VPC

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

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

In questo esempio, è configurato il seguente peering di rete:

  • network-a è connessa in peering con network-b e network-b è connessa in peering con network-a.
  • network-a contiene due subnet, ognuna 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 se i tunnel vengono sostituiti con i collegamenti VLAN Cloud Interconnect.
  • La connessione di peering per network-b è configurata con il flag --export-custom-routes e la connessione di peering per network-a è configurata con il flag --import-custom-routes.
Rete in peering con routing dinamico globale.
Rete in peering con accesso alla rete on-premise con routing dinamico globale (fai clic per ingrandire).

Per fornire connettività on-premise alle subnet in network-a e network-b, il router Cloud in network-b deve essere configurato per utilizzare la modalità di annuncio personalizzato. Ad esempio, router Cloud pubblicizza solo il prefisso personalizzato custom-prefix-1, che include gli intervalli di subnet da network-b e 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 di subnet e di subnet di peering. In altre parole, on-premises-prefix non corrisponde esattamente e non rientra in alcuna route di 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/D

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, le route On-premises prefix imparate dal router Cloud in network-b vengono aggiunte 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 del firewall sono configurate correttamente, vm-a1, vm-a2 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::).

  • Se la modalità di routing dinamico di network-b viene modificata in regionale, le route On-premises prefix apprese dal router Cloud in network-b vengono aggiunte 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 del firewall sono configurate correttamente, solo vm-a1 e vm-b possono dialogare con una risorsa on-premise con indirizzo IPv4 10.5.6.7 (o indirizzo IPv6 fc:1000:1000:10a0:29b::) perché è l'unica VM nella stessa regione del router Cloud.

Rete di trasporto pubblico con più peering

Considera uno scenario in cui network-b è connesso a una rete on-premise e funge da rete di transito per altre due reti, network-a e network-c. Per consentire alle VM di entrambe le reti di accedere a network-b e alla sua rete on-premise collegata utilizzando solo indirizzi IP interni, è necessaria la seguente configurazione:

  • network-a è connesso in peering con network-b e network-b è connesso in peering con network-a.
  • network-c è connesso in peering con network-b e network-b è connesso in peering con network-c.
  • network-b è connesso a una rete on-premise con tunnel Cloud VPN che utilizzano il routing dinamico. Gli stessi principi valgono se i tunnel sono stati sostituiti con i collegamenti VLAN Cloud Interconnect.
    • Per fornire connettività on-premise alle subnet in network-a, network-b e network-c, il router Cloud in network-b è configurato per utilizzare la modalità di annuncio personalizzato. Ad esempio, router Cloud pubblicizza le route di subnet da network-b più i prefissi personalizzati che coprono le route di subnet in network-a e network-c.
    • In base alle interazioni tra sottoreti e route dinamiche, il router Cloud in network-b apprende i prefissi on-premise e crea route dinamiche in network-b.
  • Le connessioni peering da network-b a network-a e da network-b a network-c sono configurate con il flag --export-custom-routes. Le connessioni di peering da network-a a network-b e da network-c a network-b sono configurate con il flag --import-custom-routes.
Una rete VPC di transito contenente un tunnel VPN in peering con altre due reti VPC.
Rete di transito VPC (fai clic per ingrandire).

Se i firewall sono configurati correttamente, sono possibili i seguenti scenari di connettività:

  • Le istanze VM in network-a possono raggiungere altre VM in network-b e nei sistemi on-premise.
  • Le istanze VM in network-c possono raggiungere altre VM in network-b e nei sistemi on-premise.
  • Le istanze VM in network-b possono raggiungere altre VM sia in network-a che in network-c, nonché i 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 colleghi 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