Peering di rete VPC

Il peering di rete VPC di Google Cloud connette due reti Virtual Private Cloud (VPC) in modo che le risorse di ogni rete possano comunicare tra loro:

  • Tutte le subnet possono comunicare utilizzando indirizzi IPv4 interni.
  • Le subnet a doppio stack possono anche comunicare tramite indirizzi IPv6 interni o esterni.

Le reti VPC in peering possono essere nello stesso progetto, in progetti diversi della stessa organizzazione o in progetti diversi di organizzazioni diverse.

Il peering di rete VPC offre i seguenti vantaggi:

Vantaggi del peering di rete VPC

Il peering di rete VPC offre i seguenti vantaggi:

  • Latenza di rete: la connettività che utilizza solo indirizzi interni fornisce una latenza minore rispetto alla connettività che utilizza indirizzi esterni.
  • Sicurezza della rete: i proprietari dei servizi non devono esporre i propri servizi alla rete Internet pubblica e gestire i rischi associati.
  • Costo della rete: Google Cloud addebita i prezzi della larghezza di banda in uscita per le reti che utilizzano indirizzi IP esterni per la comunicazione anche se il traffico si trova nella stessa zona. Se invece le reti sono in peering possono utilizzare indirizzi IP interni per comunicare e risparmiare su tali costi. I prezzi standard della rete continuano a essere applicati a tutto il traffico.

Per informazioni sulla creazione di connessioni in peering, consulta Utilizzare il peering di rete VPC.

Specifiche

Il peering di rete VPC ha le seguenti specifiche:

Specifiche generali:

  • Il peering di rete VPC funziona con Compute Engine, GKE e nell'ambiente flessibile di App Engine.
    • Per impostazione predefinita, il peering di rete VPC con GKE è supportato se utilizzato con gli alias IP. Se non usi gli alias IP, puoi esportare le route personalizzate in modo che i container GKE siano raggiungibili dalle reti in peering.
  • Solo le reti VPC sono supportate per il peering di rete VPC. Il peering non è supportato per le reti legacy.
  • 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. Tuttavia, per IPv6, vengono scambiate solo le route dinamiche.
  • Una determinata rete VPC può peer con più reti VPC, ma esiste un limite.

Separazione amministrativa:

  • Le reti VPC in peering rimangono separate a livello amministrativo. Route, firewall, VPN e altri strumenti di gestione del traffico vengono amministrati e applicati separatamente in ciascuna rete VPC.
  • Per stabilire la connettività in peering, un amministratore di rete per ogni rete VPC deve creare una connessione in peering all'altra rete VPC. Un amministratore di rete per una delle reti VPC può scollegare una connessione in peering.
  • Ogni lato di un'associazione di peering è configurato in modo indipendente. Il peering sarà attivo solo quando la configurazione da entrambi i lati corrisponde. Entrambi i lati possono decidere di eliminare l'associazione di peering in qualsiasi momento.
  • La creazione di una connessione in peering non ti concede alcun ruolo IAM sull'altra rete VPC. Ad esempio, se hai il ruolo Amministratore rete Compute o il ruolo Amministratore sicurezza sicurezza per una rete, non diventi un amministratore di rete o un amministratore sicurezza per l'altra rete.

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 i ruoli personalizzati a condizione che includano le autorizzazioni roles/compute.networkAdmin.

Scambio di route:

  • Il peering e l'opzione di importazione ed esportazione di route personalizzate possono essere configurate per una rete VPC anche prima della creazione dell'altra. Anche se lo scambio di percorsi avviene solo dopo che entrambi i lati sono stati configurati.
  • I peer VPC esportano sempre le route delle subnet.
  • I peer VPC importano sempre route di subnet se la subnet utilizza indirizzi IP privati. Se la subnet utilizza indirizzi IP pubblici utilizzati privatamente, le reti in peering devono importare esplicitamente route di subnet IP private utilizzate privatamente per riceverle da altre reti. Per ulteriori informazioni sugli indirizzi IP privati e sugli indirizzi IP pubblici utilizzati privatamente, consulta l'articolo Intervalli validi.
  • Non puoi disabilitare lo scambio di route di subnet o selezionare quali route di subnet vengono scambiate. Dopo aver stabilito il peering, tutte le risorse all'interno degli indirizzi IP delle subnet sono accessibili su reti in peering diretto. Il peering di rete VPC non fornisce controlli di route granulari per filtrare gli intervalli CIDR di subnet raggiungibili nelle reti in peering. Devi utilizzare le regole firewall per filtrare il traffico, se necessario. I seguenti tipi di endpoint e risorse sono raggiungibili tramite qualsiasi rete in peering diretto:
    • IP interni di macchine virtuali (VM) in tutte le subnet
    • IP interni con bilanciamento del carico in tutte le subnet
  • Puoi scambiare route personalizzate (route statiche e dinamiche), a seconda che le configurazioni di peering siano state configurate per importarle o esportarle. Per saperne di più, consulta Importazione ed esportazione di route personalizzate.
  • Le route di subnet e statiche sono globali. Le route dinamiche possono essere regionali o globali, a seconda della modalità di routing dinamico della rete VPC.
  • Un intervallo CIDR subnet in una rete VPC in peering non può sovrapporsi a un route statico in un'altra rete in peering. Questa regola riguarda sia le route di subnet sia le route statiche. Google Cloud verifica la presenza di sovrapposizioni nelle seguenti circostanze e genera un errore quando si verifica una sovrapposizione.
    • Quando esegui il peering per la prima volta delle reti VPC
    • Quando crei una route statica in una rete VPC in peering
    • Quando crei una nuova subnet in una rete VPC in peering
  • Una route dinamica può sovrapporsi a una route di subnet in una rete peer. Per le route dinamiche, gli intervalli di destinazione che si sovrappongono a una route di subnet dalla rete peer vengono ignorati. Google Cloud utilizza la route di subnet.

Limitazioni:

  • Solo le reti in peering diretto possono comunicare. Il peering transitivo non è supportato. In altre parole, se la rete VPC N1 è in peering con N2 e N3, ma N2 e N3 non sono connesse direttamente, la rete VPC N2 non può comunicare con la rete VPC N3 tramite peering di rete VPC.
  • Non puoi utilizzare un tag o un account di servizio di una rete in peering nell'altra rete in peering.
  • I nomi DNS interni di Compute Engine creati in una rete non sono accessibili alle reti in peering. Utilizza l'indirizzo IP per raggiungere le istanze VM nella rete in peering.

Importazione ed esportazione di route personalizzate

Sicurezza della rete

Il peering di rete VPC non scambia alcuna regola firewall VPC o criteri firewall gerarchici. Le regole firewall in una rete VPC non possono specificare destinazioni o origini utilizzando tag di rete o account di servizio dall'altra rete VPC. Tuttavia, lo stesso tag di destinazione può essere utilizzato in entrambe le reti.

Ogni rete VPC contiene regole firewall implicite. A causa delle regole firewall implicite di negazione del firewall in entrata, gli amministratori della sicurezza per una rete VPC locale devono creare regole del firewall per il traffico in entrata o criteri firewall gerarchici appropriati. Queste regole o questi criteri consentono i pacchetti dagli intervalli di indirizzi IP di origine richiesti nella rete VPC in peering.

A causa delle regole firewall consentite per il traffico in uscita, non è necessario creare regole firewall in uscita o criteri firewall gerarchici per consentire i pacchetti verso le destinazioni nella rete VPC in peering. Tuttavia, se gli amministratori della sicurezza per la rete VPC locale hanno creato regole di negazione esplicite per il traffico in uscita, devi creare regole o criteri di autorizzazione in uscita.

Supporto DNS

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

Una rete VPC in peering non può utilizzare le zone private gestite di Cloud DNS autorizzate solo per una rete VPC locale. Per rendere disponibili i nomi DNS 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 a bilanciatori del carico TCP/UDP interni in una rete VPC peer. Per saperne di più, consulta Utilizzo del peering di rete VPC per il bilanciatore del carico TCP/UDP interno. Le reti in peering possono scambiare route statiche personalizzate utilizzando bilanciatori del carico TCP/UDP interni come hop successivi. Per ulteriori informazioni, consulta Opzioni di scambio di route.

I client in una rete VPC locale possono accedere ai bilanciatori del carico HTTP(S) interni in una rete VPC peer. Per saperne di più, consulta Utilizzo del peering di rete VPC per il bilanciamento del carico HTTP(S) interno.

Limiti di peering di rete VPC

I limiti di peering di rete VPC controllano quanto segue:

  • Il numero di risorse, ad esempio istanze di macchine virtuali (VM) o regole di forwarding interno che possono essere presenti in un gruppo di peering.
  • Il numero di reti a cui può connettersi una determinata rete VPC.

I limiti 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 collegate utilizzando il peering di rete VPC. Nello scenario più semplice, se due reti VPC, net-a e net-b, sono connesse in peering tra loro, ci sono due gruppi di peering: uno dal punto di vista di net-a e l'altro dal punto di vista di net-b.

Per saperne di più, consulta Limiti di peering di rete VPC.

Opzioni di scambio di route

Quando una rete VPC condivide route locali con una rete VPC in peering, esporta le route. La rete VPC in peering può quindi importare 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 ti consente di controllare quanto segue:

  • Scambio delle 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 personalizzate vengono esportate o importate.

Puoi aggiornare la configurazione prima che sia stato stabilito il peering o quando la connettività di peering è attiva.

Opzioni per lo scambio di route di subnet

Nella tabella seguente sono descritte le opzioni di scambio delle route per le route delle subnet:

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

Impossibile disattivare		 Sempre importato

Impossibile disattivare
Route di subnet IPv4 (intervalli di subnet IPv4 principali e secondari) che utilizzano intervalli di indirizzi IPv4 pubblici utilizzati privatamente Esportazione per impostazione predefinita

L'esportazione viene controllata utilizzando il flag --export-subnet-routes-with-public-ip 		Non importa per impostazione predefinita

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

L'esportazione è abilitata impostando --stack-type=IPV4_IPV6 		Non importa 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 è abilitata impostando --stack-type=IPV4_IPV6 		Non importa per impostazione predefinita

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

Opzioni per lo scambio di route statiche personalizzate

La seguente tabella descrive le opzioni di scambio delle route per le route statiche personalizzate:

Tipo di percorso Condizioni di esportazione route Condizioni di importazione route
Route statiche personalizzate con tag di rete (tutti i tipi di hop successivo) Impossibile esportare Impossibile importare
Route statiche personalizzate utilizzando l'hop successivo del gateway Internet predefinito Impossibile esportare Impossibile importare
Route statiche IPv4 personalizzate, senza tag di rete, che utilizzano l'indirizzo IPv4 privato di un bilanciatore del carico TCP/UDP interno come hop successivo Sempre esportato (come route IPv4 di subnet)

Non può essere disabilitato 		Sempre importato (ad esempio, route IPv4 di subnet)

Non può essere disabilitato
Route statiche IPv4 personalizzate, senza tag di rete, che utilizzano il nome di regola di forwarding di un bilanciatore del carico TCP/UDP interno come hop successivo Non esportato per impostazione predefinita

L'esportazione viene controllata utilizzando il flag --export-custom-routes 		Non importa per impostazione predefinita

L'importazione è controllata tramite il flag --import-custom-routes
Route statiche IPv4 personalizzate, senza tag di rete, che utilizzano altri tipi di hop successivi Non esportato per impostazione predefinita

L'esportazione viene controllata utilizzando il flag --export-custom-routes 		Non importa per impostazione predefinita

L'importazione è controllata tramite il flag --import-custom-routes

Opzioni per lo scambio di route dinamiche

La seguente tabella descrive le opzioni di scambio dei percorsi per le route dinamiche:

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

L'esportazione viene controllata utilizzando il flag --export-custom-routes 		Non importa per impostazione predefinita

L'importazione è controllata tramite il flag --import-custom-routes
Route IPv6 dinamiche Non esportato per impostazione predefinita

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

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

Scambio di route personalizzato

Quando una rete VPC esporta route personalizzate e l'altra rete importa route personalizzate, la rete di importazione può inviare pacchetti direttamente all'hop successivo per ciascuna route personalizzata importata nella rete VPC peer. Le route dinamiche personalizzate e personalizzate personalizzate vengono apprese insieme e non possono essere configurate in modo indipendente. Le modifiche in una rete si riflettono nell'altra, in base a determinate condizioni. Per ulteriori informazioni, in questo documento, consulta Route ignorate, interazioni di subnet e peering di subnet e interazioni statiche e di subnet.

L'importazione di route personalizzate 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 tali cluster: gli indirizzi IP dei pod sono implementati come intervalli di destinazione per le route statiche personalizzate che si trovano nella rete VPC in peering.
  • Se la rete VPC in peering contiene route a risorse on-premise e devi accedere a tali risorse nella rete VPC locale: devi anche creare route per gli intervalli di indirizzi IP della subnet della rete VPC locale nella rete on-premise. Per soddisfare questo requisito aggiuntivo, puoi utilizzare la pubblicità delle route personalizzate del router Cloud nella rete VPC in peering.

Importante: i router Cloud non pubblicizzano route di subnet di peering quando utilizzano la modalità pubblicitaria predefinita. Devi quindi utilizzare pubblicità di route personalizzate per pubblicizzare route di subnet di peering (o intervalli aggregati di route di subnet di peering).

Route ignorate

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

  • Quando la rete VPC locale ha una route con una destinazione identica o più specifica (maschera di subnet più lunga), la rete VPC locale utilizza sempre la propria 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 che la priorità del percorso venga considerata e non puoi configurare il comportamento. Come best practice, evita questa configurazione perché l'aggiunta o la rimozione di reti VPC in peering può causare 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 può essere utilizzata nessuna delle route IPv6 ricevute dalle reti VPC in peering. Inoltre, se è stato impostato il vincolo relativo ai criteri dell'organizzazione constraints/compute.disableAllIpv6, un amministratore di rete potrebbe non essere in grado di creare subnet a doppio stack.

Interazioni di route di subnet e 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 è 100.64.0.0/10.
  • Il peering impedisce che una route di subnet sia contenuta in una route di subnet in 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.
  • Quando le reti sono in peering.
  • Quando apporti una modifica alla configurazione del peering, ad esempio per abilitare l'importazione delle route IPv4 della subnet con indirizzi IP pubblici utilizzati privatamente.

Durante il peering delle reti, Google Cloud restituisce un errore se una delle seguenti operazioni genera una sovrapposizione:

Le route di subnet IPv6 sono univoche per definizione, indipendentemente dal peering:

Interazioni di 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 a una route di subnet locale. Per una discussione più dettagliata su questo scenario, consulta Interazioni con route statiche personalizzate.

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

  • Una route statica locale non può avere una destinazione che corrisponde esattamente a una route di subnet di peering o che si adatta a questa. 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 di subnet che corrisponde esattamente a o la destinazione della route statica locale, se la configurazione di peering determina l'importazione della route di 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 con una route di subnet la cui destinazione corrisponda esattamente a 10.0.0.0/24 o contiene 10.0.0.0/24 (ad esempio 10.0.0.0/8).

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

      Ad esempio, se esiste una route statica locale con la destinazione 11.0.0.0/24 e una route di subnet con destinazione 11.0.0.0/8 esiste nella rete VPC in peering, non puoi configurare la rete VPC in peering per esportare le route di subnet utilizzando indirizzi IPv4 pubblici utilizzati privatamente e configurare la rete VPC locale per importare le route di subnet utilizzando indirizzi IPv4 pubblici utilizzati privatamente.

    • 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 di subnet di peering importata.
      • Crea un nuovo intervallo di indirizzi di subnet nella rete VPC in peering se questo intervallo corrisponde esattamente a una route statica locale esistente.

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

    • Non puoi stabilire una nuova connessione di peering a una rete VPC che contiene già una route statica che corrisponde esattamente alla destinazione della route di subnet della rete VPC locale, se la configurazione di peering determina l'importazione della route personalizzata dal peer.

      Ad esempio, se esiste una route di 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).

    • Non puoi aggiornare una connessione in peering esistente se la configurazione di peering aggiornata determina 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 corrisponde esattamente a o contiene una route statica di peering importata.
      • Crea una nuova route statica nella rete VPC in peering la cui destinazione corrisponde o si adatta esattamente a una route di subnet locale esistente.

Effetti della modalità di routing dinamico

La modalità di routing dinamico della rete locale determina le aree geografiche in cui i prefissi appresi dai router Cloud vengono applicati come route dinamiche personalizzate. Per maggiori dettagli su questo comportamento, consulta Effetti della modalità di routing dinamico.

Il concetto è esteso al peering di rete VPC. La rete VPC contenente il router Cloud esporta le route dinamiche. La modalità di routing dinamico della rete di esportazione determina il comportamento:

  • Se la modalità di routing dinamico di una rete VPC è a livello di regione, le route dinamiche della rete vengono create solo nella stessa regione del router Cloud che ha imparato i prefissi. In questo caso, le route dinamiche includono sia le route locali sia quelle dinamiche che la rete VPC esporta nelle reti peer,

  • Se la modalità di routing dinamico di una rete VPC è globale, le relative route dinamiche locali e le eventuali route dinamiche che la rete esporta nelle reti peer vengono create in tutte le aree geografiche.

Se hai reti peer che includono istanze VM con più interfacce di rete, potresti dover modificare il criterio di routing predefinito basato sulla destinazione in un criterio di routing basato sull'origine. Per ulteriori informazioni, consulta la pagina Configurare il routing dei criteri.

In questo documento, consulta Rete VPC locale e rete VPC peer con connettività on-premise per informazioni sulla modalità di routing dinamico della rete pertinente.

Interazioni di 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 personalizzate.

Esempi di peering di rete VPC

Gli esempi seguenti illustrano 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 è in peering con network-b e network-b è in peering con network-a.
    • network-a contiene una subnet il cui intervallo di indirizzi IPv4 principale è 10.0.0.0/24 in us-west1.
    • network-a contiene una subnet il cui intervallo di indirizzi IPv4 principale è 10.0.1.0/24 in europe-north1.
    • network-b contiene una subnet il cui intervallo di indirizzi IPv4 principale è 10.0.2.0/23 in us-west1.
  • network-b si connette a una rete on-premise con i tunnel Cloud VPN utilizzando il routing dinamico. (gli stessi principi valgono anche se i tunnel vengono sostituiti con collegamenti VLAN per Cloud Interconnect).
    • Per fornire la connettività dagli ambienti 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 personalizzate. Ad esempio, il router Cloud pubblicizza solo il prefisso personalizzato 10.0.0.0/22, che include l'intervallo di subnet 10.0.2.0/23 da network-b e gli intervalli di subnet 10.0.0.0/24 e 10.0.1.0/24 da network-a.
    • Il router Cloud in us-west1 apprende il prefisso 10.0.0.0/8 da un router on-premise. 10.0.0.0/8 non crea alcun conflitto perché è più ampio di le route delle subnet e delle subnet di peering. In altre parole, 10.0.0.0/8 non corrisponde esattamente e non all'interno di alcuna route di subnet di peering o di subnet.
  • La connessione in peering per network-b è configurata per esportare le sue route personalizzate, mentre la connessione in peering per network-a è configurata per importare le sue route personalizzate.

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 prefissi on-premise (10.0.0.0/8) rilevati dal router Cloud in network-b vengono aggiunti come route dinamiche in tutte le aree geografiche di network-b e come route dinamiche di peering in tutte le aree geografiche 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 IP 10.5.6.7.

  • Se la modalità di routing dinamico di network-b viene modificata in prefissi a livello di regione, on-premise (10.0.0.0/8) appresi 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 l'indirizzo IP 10.5.6.7, perché è l'unica VM nella stessa area geografica del router Cloud.

Rete di trasporto pubblico

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

  • network-a è in peering con network-b e network-b è in peering con network-a
  • network-c è in peering con network-b e network-b è in peering con network-c
  • network-b è connesso a una rete on-premise con tunnel Cloud VPN utilizzando il routing dinamico. Gli stessi principi sono validi anche se i tunnel sono stati sostituiti con collegamenti VLAN per Cloud Interconnect.
    • Per fornire la connettività dagli on-premise alle subnet in network-a, network-b e network-c, il router Cloud in network-b deve essere configurato in modo da utilizzare un annuncio di route personalizzato. Ad esempio, il router Cloud pubblicizza le route di subnet di network-b più i prefissi personalizzati che coprono le route di subnet in network-a e network-c.
    • Soggetto alle interazioni di route dinamiche e di subnet, 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 state configurate per esportare le route personalizzate. Le connessioni in peering da network-a a network-b e da network-c a network-b sono state configurate per importare le route personalizzate.

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

  • Le istanze VM in network-a possono raggiungere altre VM nei sistemi network-b e on-premise.
  • Le istanze VM in network-c possono raggiungere altre VM nei sistemi network-b e on-premise.
  • Le istanze VM in network-b possono raggiungere altre VM sia in network-a che network-c, nonché nei 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 tramite il peering di rete VPC.

Passaggi successivi