Informazioni sulle connessioni in peering

Questa pagina fornisce una panoramica dell'amministrazione delle connessioni in peering di rete VPC.

Connessione in peering

Una connessione in peering collega due reti Virtual Private Cloud (VPC). Per stabilire una connessione in peering, ogni parte crea separatamente una configurazione di peering che fa riferimento all'altra rete.

Avvii la richiesta di connessione a un'altra rete VPC creando una configurazione di peering. Dopo che l'altra rete ha una configurazione corrispondente per il peering con la tua rete, la connessione in peering viene stabilita e lo stato del peering viene modificato in ACTIVE in entrambe le reti. Lo stato del peering rimane INACTIVE se l'altra rete non ha una configurazione di peering corrispondente, il che indica che la tua rete non è connessa all'altra.

La creazione di una connessione in peering non ti concede alcun ruolo Identity and Access Management nell'altra rete VPC. Ad esempio, se hai il ruolo Amministratore rete Compute (roles/compute.networkAdmin) o Amministratore sicurezza Compute (roles/compute.securityAdmin) per una rete, non diventi amministratore di rete o amministratore della sicurezza per l'altra rete.

Una volta stabilita la connessione in peering, le due reti VPC scambiano sempre le route di subnet IPv4 che utilizzano intervalli di indirizzi IPv4 privati. Per ulteriori informazioni sulle opzioni di scambio delle route, consulta le seguenti sezioni:

• Opzioni per lo scambio di route di subnet
• Opzioni per lo scambio di route statiche
• Opzioni per lo scambio di route dinamiche

Modalità di connessione

La modalità di connessione determina la modalità di amministrazione di una connessione in peering. Il peering di rete VPC supporta due modalità di connessione:

• Modalità indipendente (impostazione predefinita)
• Modalità di consenso

Per le implementazioni standard, in genere è preferibile la modalità indipendente. Tuttavia, per le implementazioni che supportano un servizio critico in cui l'eliminazione accidentale della connessione in peering causerebbe un'interruzione del servizio, ti consigliamo di utilizzare la modalità di consenso. Questa modalità richiede l'accordo di entrambe le reti e impedisce modifiche unilaterali allo stato effettivo della connessione in peering.

Quando crei una connessione in peering, entrambe le configurazioni di peering devono specificare la stessa modalità di connessione: indipendente o di consenso.

Per modificare la modalità di peering di una connessione esistente da indipendente a di consenso, è necessario aggiornare entrambe le configurazioni di peering. La modifica della modalità di connessione da di consenso a indipendente non è supportata.

Modalità indipendente

Quando una connessione in peering è in modalità indipendente (impostazione predefinita), entrambe le reti possono aggiornare o eliminare la connessione in qualsiasi momento. Puoi facoltativamente limitare questo comportamento aggiornando la modalità di connessione a di consenso.

Modalità di consenso

La modalità di consenso impedisce modifiche accidentali e unilaterali al comportamento della rete. Quando una connessione in peering è in modalità di consenso, ogni richiesta di aggiornamento o eliminazione della connessione in peering richiede l'accordo di entrambe le reti.

Configurare la modalità di consenso per una connessione

Puoi configurare una connessione in peering nuova o esistente per utilizzare la modalità di consenso impostando il parametro update_strategy:

• Nuova connessione. Entrambe le reti devono impostare la strategia di aggiornamento su CONSENSUS. Se la strategia di aggiornamento non è specificata, la connessione viene creata in modalità indipendente.

• Connessione esistente. Entrambe le reti devono modificare la strategia di aggiornamento in CONSENSUS. Finché entrambi i valori non corrispondono, la strategia di aggiornamento effettiva rimane INDEPENDENT e sono consentite richieste di aggiornamento ed eliminazione unilaterali.

  Le richieste in attesa di aggiornamento della modalità di connessione non causano tempi di inattività e la connessione rimane attiva durante l'elaborazione della richiesta.

Inoltre, per configurare la modalità di consenso per una connessione, ogni opzione di scambio di route nella configurazione deve avere lo stesso valore del flag complementare nella configurazione del peer. Se i valori dei seguenti flag non corrispondono, la richiesta di creazione o aggiornamento della connessione viene rifiutata.

Flag locale	Flag peer complementare
import_custom_route	export_custom_route
export_custom_route	import_custom_route
import_subnet_routes_with_public_ip	export_subnet_routes_with_public_ip
export_subnet_routes_with_public_ip	import_subnet_routes_with_public_ip
stack_type	stack_type

Ad esempio, se la tua rete importa route personalizzate, la rete peer deve esportare route personalizzate. Se uno di questi valori non corrisponde per una connessione esistente, entrambe le reti possono aggiornarli prima o durante la modifica della modalità di connessione.

Per annullare una richiesta in attesa di configurazione della modalità di consenso per una connessione esistente, la rete richiedente deve reimpostare la strategia di aggiornamento su INDEPENDENT.

Per ulteriori informazioni, consulta Creare una connessione in peering in modalità di consenso e Aggiornare una connessione alla modalità di consenso
mode.

Aggiornare una connessione in modalità di consenso

Entrambe le parti di una connessione in peering possono inviare una richiesta di aggiornamento. Una richiesta di aggiornamento in attesa non causa tempi di inattività e la connessione rimane attiva. Se è in corso una richiesta di eliminazione, tutte le richieste di aggiornamento (inclusa l'accettazione o l'annullamento di una richiesta di aggiornamento in attesa) vengono rifiutate.

Per aggiornare una connessione in peering configurata con la modalità di consenso, l'amministratore della rete locale aggiorna prima la configurazione locale. Poi, l'amministratore della rete peer deve apportare un aggiornamento complementare alla configurazione del peer. Ad esempio, se aggiorni il flag --export-custom-routes a true, la rete peer deve impostare il flag --import-custom-routes su true. Lo stato effettivo della connessione in peering non cambia finché la rete peer non aggiorna la configurazione corrispondente.

Dopo l'aggiornamento della configurazione di peering locale, nessuna delle due parti della connessione può inviare ulteriori richieste di aggiornamento finché l'aggiornamento iniziale non viene accettato o annullato. Gli aggiornamenti parziali non sono supportati: se una richiesta aggiorna più parametri, tutti devono essere accettati o annullati. Per annullare un aggiornamento, la rete richiedente reimposta ogni parametro modificato al valore precedente.

Il seguente diagramma mostra come cambia lo stato di una connessione in peering quando viene inviata una richiesta di aggiornamento.

Aggiornamento di una connessione in peering in modalità di consenso (fai clic per ingrandire).

Nel diagramma precedente, dopo che la rete A ha inviato la richiesta di aggiornamento, lo stato di aggiornamento della connessione cambia da IN_SYNC a PENDING_PEER_ACKNOWLEDGMENT nella configurazione locale e a PENDING_LOCAL_ACKNOWLEDGMENT nella configurazione del peer.

Per tornare allo stato IN_SYNC, la rete B deve apportare la modifica complementare oppure la rete A deve annullare la richiesta. Per ulteriori informazioni su questi stati di connessione, consulta Stato della connessione.

Per aggiornare una connessione in peering, consulta Aggiornare una connessione (modalità di consenso).

Eliminare una connessione in modalità di consenso

Per eliminare una connessione in peering in modalità di consenso, entrambe le parti della connessione devono inviare una richiesta di eliminazione. Puoi annullare una richiesta di eliminazione prima o dopo che sia stata accettata dalla rete peer.

Per le richieste di eliminazione si applicano le seguenti condizioni:

• Se è in attesa una richiesta di aggiornamento, puoi comunque eliminare la connessione in peering.
• Se è in attesa una richiesta di eliminazione, tutte le richieste di aggiornamento, inclusa l'accettazione o l'annullamento di un aggiornamento in attesa, vengono rifiutate. Per completare un aggiornamento in attesa, devi prima annullare la richiesta di eliminazione.

Per ulteriori informazioni, consulta Eliminare una connessione (modalità di consenso).

Stato della connessione

Il comando gcloud compute networks describe mostra sia lo stato effettivo di una connessione in peering sia la configurazione di peering locale.

Puoi visualizzare lo stato effettivo della connessione esaminando il campo peerings.connectionStatus. La seguente tabella descrive gli stati di configurazione disponibili. Il segno di spunta indica che il campo è disponibile.

Campo	Modalità indipendente	Modalità di consenso	Descrizione
trafficConfiguration			Mostra le opzioni di scambio di route effettive della connessione in peering.
updateStrategy			Mostra la modalità di connessione effettiva: either INDEPENDENT or CONSENSUS.
consensusState.deleteStatus			UNSPECIFIED: non sono in attesa richieste requestRemovePeering per questa connessione in peering. Il campo deleteStatus non viene visualizzato nell'output quando lo stato è UNSPECIFIED. LOCAL_DELETE_REQUESTED: il proprietario di questo peering ha richiesto l'eliminazione della connessione in peering. PEER_DELETE_REQUESTED: il proprietario del peering corrispondente ha richiesto l'eliminazione della connessione in peering. DELETE_ACKNOWLEDGED: entrambi i proprietari del peering di questa connessione hanno richiesto l'eliminazione della connessione in peering. Le successive removePeering richieste avranno esito positivo per entrambi i peering. LOCAL_CANCEL_REQUESTED: la connessione in peering era nello stato DELETE_ACKNOWLEDGED ma la rete locale ha annullato l'eliminazione. PEER_CANCEL_REQUESTED: la connessione in peering era nello stato DELETE_ACKNOWLEDGED ma la rete peer ha annullato l'eliminazione.
consensusState.updateStatus			IN_SYNC: nessun proprietario del peering ha aggiornamenti in attesa. PENDING_PEER_ACKNOWLEDGMENT: il proprietario del peering locale ha apportato una modifica, ma il proprietario del peering corrispondente non ha applicato le modifiche corrispondenti al proprio peering. PENDING_LOCAL_ACKNOWLEDGMENT: il proprietario del peering corrispondente ha apportato una modifica, ma il proprietario del peering locale non ha applicato le modifiche corrispondenti a questo peering.

Per elencare tutte le configurazioni di peering in un Google Cloud progetto, consulta Elencare le connessioni in peering.

Passaggi successivi

• Per creare e gestire le connessioni in peering di rete VPC, consulta Configurare e gestire il peering di rete VPC.