Routes

Le route Google Cloud definiscono i percorsi che il traffico di rete segue da un'istanza virtuale (VM) a altre destinazioni. Queste destinazioni possono trovarsi all'interno della rete Virtual Private Cloud (VPC) di Google Cloud (ad esempio in un'altra VM) o all'esterno.

In una rete VPC, una route è costituita da un singolo prefisso destinazione in formato CIDR e da un singolo hop successivo. Quando un'istanza in una rete VPC invia un pacchetto, Google Cloud lo consegna all'hop successivo della route se l'indirizzo di destinazione del pacchetto rientra nell'intervallo di destinazione della route.

Questa pagina fornisce una panoramica del funzionamento delle route in Google Cloud.

Routing in Google Cloud

Ogni rete VPC utilizza un meccanismo di routing virtuale distribuito e scalabile. Nessun dispositivo fisico è assegnato alla rete. Alcuni route possono essere applicati in modo selettivo, ma la tabella di routing per una rete VPC è definita a livello di rete VPC.

Ogni istanza VM ha un controller che viene tenuto al corrente di tutti i percorsi applicabili dalla tabella di routing della rete. Ogni pacchetto che esce da una VM viene inviato all'hop successivo appropriato di una route applicabile in base a un ordine di routing. Quando aggiungi o elimini un percorso, l'insieme di modifiche viene propagato ai controller VM utilizzando un design eventualmente coerente.

Tipi di route

Le tabelle seguenti riepilogano la classificazione delle route nelle reti VPC da parte di Google Cloud.

Tipo e destinazione Hop successivo Note
Route basate su criteri: le route basate su criteri vengono valutate prima di qualsiasi altro tipo di route.
Route basata su criteri
Le route basate su criteri possono essere applicate ai pacchetti in base all'indirizzo IP di origine, all'indirizzo IP di destinazione, al protocollo o a una combinazione di questi.

Le route basate su criteri possono essere applicate a tutte le VM della rete, a determinate VM selezionate in base al tag di rete o al traffico che entra nella rete VPC tramite i collegamenti VLAN per Cloud Interconnect (in una sola regione o in tutte le regioni).

Le route basate su criteri non vengono mai scambiate tramite il peering di rete VPC.
Route di subnet: tutti i tipi di route di subnet vengono valutati dopo le route basate su criteri, ma prima delle route personalizzate.
Route della subnet locale
Creata automaticamente per ogni intervallo di indirizzi IP della subnet 		Rete VPC

Creati, aggiornati e rimossi automaticamente da Google Cloud durante gli eventi del ciclo di vita della sottorete.

Le route di subnet locali si applicano all'intera rete VPC.
Route di subnet di peering
Rappresenta un intervallo di indirizzi IP di una subnet in un'altra rete VPC connessa tramite il peering di rete VPC 		Hop successivo nella rete VPC peer

Il peering di rete VPC offre opzioni per scambiare route di subnet.

Creati, aggiornati e rimossi automaticamente da Google Cloud durante gli eventi del ciclo di vita della sottorete.

Le route di subnet di peering importate si applicano all'intera rete VPC.
Percorso della subnet di Network Connectivity Center
Rappresenta un intervallo di indirizzi IP di una subnet in uno spoke VPC (un'altra rete VPC connessa all'hub di Network Connectivity Center) 		Hub Network Connectivity Center

Gli amministratori degli spoke di Network Connectivity Center possono escludere l'esportazione delle route di subnet.

Creati, aggiornati e rimossi automaticamente da Google Cloud durante gli eventi del ciclo di vita della sottorete.

Le route di subnet di Network Connectivity Center importate si applicano all'intera rete VPC.
Route personalizzate: le route personalizzate vengono valutate dopo le route basate su criteri e dopo le route di subnet.
Percorso statico locale
Supporta varie destinazioni 		Inoltra i pacchetti a un hop successivo della route statica Per informazioni dettagliate su ogni hop successivo della route statica, consulta le considerazioni relative a:
Route dinamica locale
Destinazioni che non sono in conflitto con route di subnet o route statiche		 Peer di una sessione BGP su un router Cloud Le route vengono aggiunte e rimosse automaticamente in base alle route apprese dai router Cloud nella rete VPC.

Le route vengono applicate alle VM in base alla modalità di routing dinamico della rete VPC.
Route statica di peering, route dinamica di peering
Route statiche o dinamiche in un'altra rete VPC connessa utilizzando il peering di rete VPC 		Hop successivo nella rete VPC peer

Il peering di rete VPC fornisce opzioni per lo scambio di route statiche.

Le route statiche di peering importate si applicano all'intera rete VPC.

Il peering di rete VPC offre opzioni per lo scambio di route dinamiche.

Le route dinamiche di peering si applicano a una o a tutte le regioni della rete VPC in base alla modalità di routing dinamico della rete VPC che esporta le route.
Route dinamiche di Network Connectivity Center
Route dinamiche importate dagli spoke ibride di Network Connectivity Center situati in reti VPC diverse 		Hub Network Connectivity Center

Un hub di Network Connectivity Center può avere sia spoke VPC sia spoke ibridi.

Le route dinamiche di Network Connectivity Center si applicano a una o a tutte le regioni della rete VPC in base alla modalità di routing dinamico della rete VPC contenente lo spoke ibrido.
Percorsi generati dal sistema
Route predefinite generate dal sistema
0.0.0.0/0 per IPv4
::/0 per IPv6		 default-internet-gateway Si applica all'intera rete VPC

Possono essere rimossi o sostituiti

Route di subnet

Ogni subnet ha almeno una route per ogni intervallo di indirizzi IP associato alla subnet. Per saperne di più sugli intervalli IP delle subnet, consulta Subnet.

Tipi di route di subnet

Una rete VPC può includere i seguenti tipi di route di subnet:

  • Route di subnet per le subnet nella stessa rete VPC, denominate route di subnet locali.
  • Route di subnet di Network Connectivity Center importati dagli spoke VPC di un hub di Network Connectivity Center.
  • Route di subnet di peering importate dalle reti connesse tramite il peering di rete VPC.

Gli intervalli di destinazione per tutti i tipi di route di subnet devono essere univoci. Per ulteriori informazioni, consulta:

Ciclo di vita delle route delle subnet

Tutti gli intervalli di indirizzi IP che fanno parte di una subnet, ovvero intervalli di indirizzi IPv4 principali, intervalli di indirizzi IPv4 secondari e intervalli di indirizzi IPv6, hanno un percorso di subnet corrispondente. Google Cloud crea ed elimina le route delle subnet in questi scenari:

  • Apporta una modifica alla configurazione della subnet, ad esempio:

    • Aggiungi o elimina una sottorete.
    • Espandi un intervallo IPv4 principale.
    • Aggiungi o elimina un intervallo IPv4 secondario.
    • Aggiungi o elimina un intervallo IPv6.

  • Google Cloud aggiunge una nuova regione, che aggiunge automaticamente una nuova subnet alle reti VPC in modalità automatica. Per informazioni sugli intervalli di indirizzi IPv4 per ogni subnet in base alla regione, consulta Intervalli IPv4 in modalità automatica.

Route dinamiche

I router Cloud ordinano alla rete VPC di creare, aggiornare e rimuovere le route dinamiche in base ai messaggi BGP (Border Gateway Protocol) ricevuti, ai criteri di route BGP applicabili (anteprima) e alle route personalizzate acquisite dal router Cloud.

Le route dinamiche vengono create in una o in tutte le regioni in base alla modalità di routing dinamico e alla modalità di selezione del percorso migliore della rete VPC che contiene il router Cloud. Per ulteriori informazioni, consulta quanto segue:

L'hop successivo di una route dinamica può essere uno dei seguenti:

Se un hop successivo per una route dinamica diventa inaccessibile, il router Cloud che gestisce la sessione BGP indica alla rete VPC di rimuovere la route dinamica. Per ulteriori informazioni, consulta la sezione Modifiche dello stato BGP.

Tipi di route dinamiche

Una rete VPC può includere i seguenti tipi di route dinamiche:

Google Cloud risolve i conflitti tra route dinamiche e route di subnet come descritto in Interazioni con le route dinamiche.

Route predefinite generate dal sistema

Una route predefinita ha la destinazione più ampia possibile: 0.0.0.0/0 per IPv4 e ::/0 per IPv6. Google Cloud utilizza una route predefinita per inviare un pacchetto solo quando il pacchetto non corrisponde a una route più specifica nell'ordine di routing.

L'assenza di una route predefinita non isola necessariamente la tua rete da internet perché i percorsi di routing speciali per i bilanciatori del carico di rete passthrough esterni e il forwarding del protocollo esterno non dipendono da una route predefinita.

Quando crei una rete VPC, Google Cloud aggiunge alla rete VPC un percorso predefinito IPv4 generato dal sistema. La route predefinita IPv4 generata dal sistema è una route statica locale con un hop successivo di destinazione e gateway internet predefinito 0.0.0.0/0. Una route statica locale con destinazione 0.0.0.0/0 e hop successivo del gateway internet predefinito fornisce un percorso agli indirizzi IPv4 esterni, inclusi gli indirizzi IPv4 su internet. Le seguenti risorse di esempio utilizzano questo percorso:

  • VM con indirizzi IPv4 esterni assegnati alle interfacce di rete, quando i pacchetti inviati hanno sorgenti corrispondenti all'indirizzo IPv4 interno primario dell'interfaccia di rete.
  • Un gateway Cloud NAT pubblico configurato per fornire servizi NAT alle subnet utilizzate dalle interfacce di rete della VM. A seconda degli intervalli di indirizzi IPv4 della subnet per i quali è configurato il gateway Cloud NAT, le origini dei pacchetti possono corrispondere a uno dei seguenti valori:
    • Un indirizzo IPv4 interno da un intervallo di indirizzi IP alias dell'interfaccia di rete della VM (indipendentemente dal fatto che l'interfaccia di rete abbia o meno un indirizzo IPv4 esterno) oppure
    • L'indirizzo IPv4 interno principale dell'interfaccia di rete della VM se all'interfaccia di rete non è stato assegnato un indirizzo IPv4 esterno.

Quando crei una subnet con un intervallo di indirizzi IPv6 esterno, Google Cloud aggiunge una route predefinita IPv6 generata dal sistema alla rete VPC se non ne esiste già una. La route predefinita IPv6 generata dal sistema è una route statica locale con una destinazione ::/0 e un hop successivo gateway internet predefinito. Una route statica locale con l'hop successivo di destinazione e del gateway internet predefinito ::/0 fornisce un percorso agli indirizzi IPv6 esterni, inclusi gli indirizzi IPv6 su internet. Questo percorso può essere utilizzato da:

  • VM con intervalli di indirizzi IPv6 esterni /96 assegnati alle relative interfacce di rete, quando i pacchetti inviati hanno origini in questo intervallo di indirizzi /96.

A volte l'accesso alle API Google globali dipende da un route predefinito IPv4 o IPv6 locale con hop successivo del gateway internet predefinito:

  • Se accedi alle API e ai servizi Google globali inviando pacchetti a un endpoint Private Service Connect per le API Google globali, la tua rete VPC non richiede una route predefinita con hop successivo del gateway internet predefinito. Google Cloud aggiunge un percorso di routing speciale all'endpoint.

  • Se accedi alle API e ai servizi Google globali inviando pacchetti agli indirizzi IPv4 o IPv6 per i domini predefiniti, agli indirizzi IPv4 o IPv6 per private.googleapis.com o agli indirizzi IPv4 o IPv6 per restricted.googleapis.com, puoi utilizzare le route IPv4 e IPv6 predefinite con i hop successivi del gateway internet predefiniti oppure puoi creare e utilizzare route statiche IPv4 e IPv6 con destinazioni più specifiche e hop successivi del gateway internet predefiniti:

Interazioni con i route

Le sezioni che seguono descrivono le interazioni tra le route di subnet e altri tipi di route.

Interazioni tra route di subnet e route statiche

Google Cloud applica le seguenti regole per le route delle subnet locali, le route delle subnet in peering e le route delle subnet di Network Connectivity Center a meno che la subnet corrispondente non sia stata configurata come subnet ibrida.

  • Google Cloud non ti consente di creare una nuova route statica se la destinazione della nuova route statica corrisponde esattamente o rientra nella destinazione di una route di sottorete locale, di peering o di Network Connectivity Center esistente. Ad esempio:

    • Se esiste un route di subnet locale, di peering o di Network Connectivity Center con destinazione 10.70.1.0/24, non puoi creare un nuovo route statico per 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 o qualsiasi altra destinazione che rientra in 10.70.1.0/24.

    • Se esiste un route di subnet locale o di peering con destinazione 2001:0db8:0a0b:0c0d::/64, non puoi creare un nuovo route statico per 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96 o qualsiasi altra destinazione che rientra in 2001:0db8:0a0b:0c0d::/64.

  • Google Cloud non ti consente di apportare modifiche alle subnet che hanno come risultato un intervallo di indirizzi IP della subnet corrispondente esattamente o contenente la destinazione di una route statica locale o di peering esistente. Ad esempio:

    • Se la rete VPC ha una route statica con destinazione 10.70.1.128/25, non puoi creare una nuova subnet con un intervallo di indirizzi IPv4 principale o secondario di 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro intervallo di indirizzi IP contenente tutti gli indirizzi IPv4 in 10.70.1.128/25.

    • Se la tua rete VPC ha una route statica con destinazione 2001:db8:a0b:c0d:e0f:f0e::/96, Google Cloud vieta la creazione di una nuova route di subnet locale o in peering con un intervallo di indirizzi IPv6 di 2001:db8:a0b:c0d::/64 o qualsiasi altro intervallo contenente tutti gli indirizzi IPv6 in 2001:db8:a0b:c0d:e0f:f0e::/96.

Interazioni tra route di subnet e route dinamiche

Google Cloud applica le seguenti regole a meno che una subnet non sia stata configurata come subnet ibrida.

  • Google Cloud non crea una route dinamica se un router Cloud invia un prefisso che corrisponde esattamente o rientra nella destinazione di una route di subnet locale, di peering o di Network Connectivity Center esistente. Ad esempio:

    • Se esiste una route di subnet locale, di peering o di Network Connectivity Center con destinazione 10.70.1.0/24 e se un router Cloud nella rete VPC, una rete VPC con peering o una rete contenente uno spoke ibrido di Network Connectivity Center riceve 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro prefisso che rientra in 10.70.1.0/24, Google Cloud non crea route dinamiche locali, di peering o di Network Connectivity Center per i prefissi in conflitto ricevuti.

    • Se esiste una route di subnet locale, di peering o di Network Connectivity Center con destinazione 2001:0db8:0a0b:0c0d::/64 e se un router Cloud nella rete VPC, una rete VPC con peering o una rete contenente uno spoke ibrido di Network Connectivity Center riceve 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 o qualsiasi altro prefisso che rientra in 2001:0db8:0a0b:0c0d::/64, Google Cloud non crea route dinamiche locali, di peering o di Network Connectivity Center per i prefissi in conflitto ricevuti.

  • Google Cloud rimuove qualsiasi route dinamico esistente se una modifica alle subnet comporta la creazione di una nuova route di subnet locale, di peering o di Network Connectivity Center la cui destinazione corrisponde esattamente a quella della route dinamica locale, di peering o di Network Connectivity Center esistente o la contiene. Ad esempio:

    • Se la rete VPC ha una route dinamica locale, di peering o di Network Connectivity Center con destinazione 10.70.1.128/25, Google Cloud rimuove la route dinamica quando viene creata una nuova route di sottorete locale, di peering o di Network Connectivity Center per 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro intervallo di indirizzi IP contenente tutti gli indirizzi IPv4 in 10.70.1.128/25.

    • Se la tua rete VPC ha una route dinamica locale, di peering o di Network Connectivity Center con destinazione 2001:db8:a0b:c0d::/96, Google Cloud rimuove la route dinamica quando viene creata una nuova route di sottorete locale, di peering o di Network Connectivity Center per 2001:db8:a0b:c0d::/64.

Applicabilità e ordine

Route applicabili

Ogni istanza, tunnel Cloud VPN e collegamento VLAN ha un insieme di route applicabili, ovvero route che si applicano a quella risorsa specifica. Le route applicabili sono un sottoinsieme di tutte le route nella rete VPC.

I seguenti tipi di route si applicano sempre a tutte le istanze VM, ai collegamenti VLAN e ai tunnel Cloud VPN:

I seguenti tipi di route possono essere configurati in modo da applicarsi solo a determinate istanze VM, a collegamenti VLAN o a tunnel Cloud VPN:

  • Le route basate su criteri possono essere applicate a:

    • Tutte le istanze VM, i collegamenti VLAN e i tunnel Cloud VPN
    • Solo le istanze VM identificate dal tag di rete
    • Solo i collegamenti VLAN in una determinata regione

  • Le route statiche possono essere applicate a:

    • Tutte le istanze VM, i collegamenti VLAN e i tunnel Cloud VPN
    • Solo le istanze VM identificate dal tag di rete

  • Le route dinamiche possono essere applicate a istanze VM, collegamenti VLAN e tunnel Cloud VPN nella regione contenente il successivo hop della route dinamica o in tutte le regioni, in base alla modalità di routing dinamico della rete VPC.

Percorsi di routing speciali

Le reti VPC hanno route speciali per determinati servizi. Questi percorsi di routing speciali non vengono visualizzati nella tabella delle route della rete VPC. Non puoi rimuovere percorsi di routing speciali. Tuttavia, puoi consentire o negare i pacchetti utilizzando le regole firewall VPC o i criteri firewall.

Percorsi per i bilanciatori del carico di rete passthrough esterni e l'inoltro di protocolli esterni

I bilanciatori del carico di rete passthrough esterni e il inoltro di protocollo esterno utilizzano i sistemi Maglev per instradare i pacchetti dai client su internet alle VM di backend e alle istanze di destinazione nella rete VPC. Questi sistemi Maglev indirizzano i pacchetti con destinazioni corrispondenti alla destinazione della regola di inoltro esterno.

Ogni regola di forwarding per un bilanciatore del carico di rete passthrough esterno o per il forwarding del protocollo esterno fornisce anche un percorso di instradamento per le VM di backend o l'istanza di destinazione per inviare i pacchetti a destinazioni esterne alla rete VPC:

  • I pacchetti inviati dalle VM di backend o dalle istanze di destinazione possono essere pacchetti di risposta in uscita (inviati al client) o pacchetti in uscita che avviano una nuova connessione.
  • Le origini dei pacchetti devono corrispondere all'indirizzo IP della regola di forwarding. Il protocollo e la porta di origine del pacchetto non devono corrispondere alla specifica del protocollo e della porta della regola di regola di forwarding.
  • I percorsi di routing delle regole di inoltro non dipendono da una route predefinita o dall'utilizzo dell'hop successivo del gateway internet predefinito.
  • Non è necessario attivare l'IP forwarding per le VM di backend e le istanze target.

Percorsi tra i front-end e i backend di Google

I bilanciatori del carico delle applicazioni esterni e i bilanciatori del carico di rete proxy esterni utilizzano Google Front End (GFE). I GFE di secondo livello aprono connessioni TCP alle VM di backend e inviano pacchetti dalle seguenti origini:

  • 35.191.0.0/16
  • 130.211.0.0/22

Google Cloud utilizza le route nella rete di Google per inviare i pacchetti da questi intervalli di origine alle VM di backend nella rete VPC. Ogni rete VPC include percorsi di routing che consentono alle VM di inviare pacchetti di risposta a 35.191.0.0/16 e 130.211.0.0/22.

Percorsi per i controlli di integrità

I controlli di integrità per tutti i bilanciatori del carico e per la riparazione automatica dei gruppi di istanze gestite inviano pacchetti alle VM di backend dagli intervalli di indirizzi IP dei probe del controllo di integrità.

Google Cloud utilizza le route nella rete di Google per inviare pacchetti dai sistemi di controllo di integrità dell'integrità alle VM nella rete VPC. Ogni rete VPC include percorsi di routing che consentono alle VM di inviare pacchetti di risposta ai sistemi di probe di controllo di integrità.

Percorsi per Identity-Aware Proxy (IAP)

L'inoltro TCP tramite IAP utilizza 35.235.240.0/20 come intervallo solo interno con hop successivi interamente all'interno della rete di Google. Google non pubblica percorsi per 35.235.240.0/20 su internet.

Le route nella rete di Google inviano pacchetti da 35.235.240.0/20 alle VM nella rete VPC quando utilizzi il forwarding TCP IAP. Ogni rete VPC include percorsi di routing che consentono alle VM di inviare pacchetti di risposta a 35.235.240.0/20.

Percorsi per Cloud DNS e Service Directory

Le seguenti funzionalità di Cloud DNS e Service Directory utilizzano35.199.192.0/19 come intervallo solo interno con hop successivi interamente all'interno della rete di Google. Google non pubblica percorsi per 35.199.192.0/19 su internet.

Le route nella rete di Google inviano pacchetti da 35.199.192.0/19 alle VM nella rete VPC quando utilizzi queste funzionalità di Cloud DNS e Service Directory. Ogni rete VPC include percorsi di routing che consentono alle VM di inviare pacchetti di risposta a 35.199.192.0/19.

Percorsi per l'accesso VPC serverless

Accesso VPC serverless utilizza35.199.224.0/19 come intervallo solo interno con hop successivi interamente all'interno della rete di Google. Google non pubblica percorsi per 35.199.224.0/19 su internet.

Le route nella rete di Google inviano i pacchetti da 35.199.224.0/19 alle istanze del connettore di accesso VPC serverless. Ogni rete VPC include percorsi di routing che consentono alle istanze del connettore di inviare pacchetti di risposta a 35.199.224.0/19.

Percorsi per gli endpoint Private Service Connect per le API di Google globali

Quando crei un endpoint Private Service Connect per le API Google globali, Google Cloud aggiunge una route per l'endpoint alla tua rete VPC. La destinazione della route è l'indirizzo IP interno globale dell'endpoint.

Ordine di routing

Potrebbe essere presente più di un percorso applicabile per un determinato pacchetto. I passaggi che seguono modellano la procedura utilizzata per selezionare un percorso.

  1. Percorsi di routing speciali: alcuni percorsi di routing speciali di Google Cloud non mostrati nella tabella delle route della rete VPC. Per maggiori dettagli, vedi Percorsi di routing speciali.

    Se è applicabile un percorso di routing speciale, il modello di selezione del percorso contiene solo il percorso speciale. Tutti gli altri percorsi vengono ignorati e la valutazione si interrompe in questo passaggio.

  2. Route basate su criteri: le route basate su criteri vengono valutate dopo i percorsi di routing speciali, ma prima di altri tipi di route. Se nella rete VPC non esistono route basate su criteri, Google Cloud salta questo passaggio e passa al passaggio sulle route delle subnet.

    Google Cloud valuta le route basate su criteri in base alla loro priorità. Google Cloud valuta la sorgente e la destinazione di un pacchetto per ogni route basata su criteri, a partire dalla route o dalle route basate su criteri con la priorità più elevata. Se le caratteristiche di un pacchetto non corrispondono a una route basata su criteri, Google Cloud ignora questa route e continua a valutare la route basata su criteri successiva nell'elenco ordinato. La route basata su criteri successiva da valutare potrebbe condividere la stessa priorità della route basata su criteri ignorata o avere una priorità inferiore.

    • Se le caratteristiche di un pacchetto non corrispondono a nessuna route basata su criteri dopo aver valutato tutte le route basate su criteri nel modello di selezione delle route, Google Cloud ignora tutte le route basate su criteri e passa al passaggio Route subnet.

    • Se le caratteristiche di un pacchetto corrispondono a una route basata su criteri con priorità più elevata, Google Cloud ignora innanzitutto tutte le route basate su criteri con priorità inferiore. Se nell'elenco rimangono due o più route basate su criteri, Google Cloud valuta ciascuna delle route basate su criteri rimanenti con priorità identiche. Google Cloud ignora le route basate su criteri rimanenti se le caratteristiche di un pacchetto non corrispondono. Dopo questo passaggio, il modello di selezione dei percorsi potrebbe contenere uno o più percorsi basati su criteri.

    • Se il modello di selezione delle route include due o più route basate su criteri con priorità massima corrispondenti, Google Cloud seleziona una singola route basata su criteri utilizzando un algoritmo interno. La route basata su criteri selezionata potrebbe non essere la corrispondenza più specifica per l'origine o la destinazione del pacchetto. Per evitare questa ambiguità, ti consigliamo di creare route basati su criteri con priorità univoche.

    • Se il modello di selezione delle route include una sola route basata su criteri con priorità massima configurata per ignorare altre route basate su criteri, Google Cloud ignora tutte le route basate su criteri e passa al passaggio Route delle sottoreti.

    • Se il modello di selezione delle route include una sola route basata su criteri di massima priorità che non è configurata per ignorare altre route basate su criteri, Google Cloud invia il pacchetto all'hop successivo bilanciatore del carico di rete passthrough interno e ignora tutte le route non basate su criteri.

  3. Route per le subnet: Google Cloud determina se la destinazione del pacchetto rientra nell'intervallo di destinazione di una route per subnet locale, di peering o di Network Connectivity Center nella rete VPC.

    • Se la destinazione di un pacchetto non corrisponde all'intervallo di destinazione di una route subnet locale, di peering o di Network Connectivity Center, Google Cloud ignora tutte le route subnet e passa al passaggio Destinazione più specifica.

    • Se la destinazione di un pacchetto corrisponde all'intervallo di destinazione di una route della subnet locale, di peering o di Network Connectivity Center nella rete VPC, il comportamento è diverso a seconda che la subnet sia stata configurata come subnet ibrida:

      • Per la maggior parte delle subnet, Google Cloud utilizza esclusivamente la route della subnet, tentando di inviare il pacchetto a una risorsa all'interno della subnet, come un'interfaccia di rete della VM o una regola di forwarding interna. Tutti gli altri percorsi vengono ignorati e la valutazione si interrompe in questo passaggio. Se non è presente alcuna risorsa che utilizza la destinazione del pacchetto o se la risorsa è un'istanza VM arrestata, il pacchetto viene eliminato.

      • Tuttavia, se il percorso della sottorete corrispondente proviene da una sottorete ibrida, Google Cloud tenta di individuare una risorsa di destinazione corrispondente nella sottorete, ad esempio un'interfaccia di rete della VM o una regola di forwarding interna:

        • Se nella subnet esiste una risorsa, Google Cloud utilizza esclusivamente la route della subnet, tentando di inviare il pacchetto alla risorsa. Tutti gli altri percorsi vengono ignorati e la valutazione si interrompe in questo passaggio. Se non è presente alcuna risorsa alla destinazione del pacchetto, il pacchetto viene eliminato. Se la risorsa è una VM non in esecuzione, il pacchetto viene perso.

        • Se una risorsa non esiste nella subnet, Google Cloud ignora tutti i route della subnet, incluso il route della subnet corrispondente, e passa al passaggio Destinazione più specifica.

  4. Destinazione più specifica: all'inizio di questo passaggio, il modello di selezione delle route non contiene percorsi di routing speciali, route basati su criteri e route di subnet locali, di peering o di Network Connectivity Center.

    Google Cloud determina quale delle route applicabili rimanenti ha la destinazione più specifica che contiene l'indirizzo IP di destinazione del pacchetto. Google Cloud ignora tutte le altre route con destinazioni meno specifiche. Ad esempio, 10.240.1.0/24 è una destinazione più specifica rispetto a 10.240.0.0/16.

    Al termine di questo passaggio, il modello di selezione degli itinerari contiene solo itinerari personalizzati con destinazioni identiche.

  5. Seleziona solo il tipo di route personalizzata più favorevole: in questo passaggio, Google Cloudrimuove tutte le route personalizzate tranne il tipo di route personalizzata più favorevole. Le route personalizzate locali sono preferite alle route dinamiche di Network Connectivity Center e le route dinamiche di Network Connectivity Center sono preferite alle route personalizzate dei peering.

    La seguente tabella riassume la logica utilizzata da Google Cloud in questo passaggio.

    Categoria route personalizzata Che cosa succede
    Route dinamiche e statiche locali

    Se il modello di route contiene almeno una route dinamica locale o statica locale per la destinazione, Google Cloud rimuove i seguenti tipi di route personalizzate, se sono presenti nel modello di route:

    • Percorsi dinamici di Network Connectivity Center da spoke ibride, in reti VPC diverse
    • Route dinamiche di peering (importate da altre reti VPC connesse tramite il peering di rete VPC)
    Route dinamiche di Network Connectivity Center Se tutte le seguenti condizioni sono soddisfatte, Google Cloud rimuove tutte le route dinamiche e statiche di peering dal modello di route:
    • Il tuo modello di route non contiene route personalizzate locali per la destinazione
    • La modalità di itinerario contiene almeno un itinerario dinamico di Network Connectivity Center per la destinazione
    • Il percorso dinamico di Network Connectivity Center proviene da uno spoke ibrido in un'altra rete VPC
    Route dinamiche e statiche di peering Il tipo di route personalizzata meno favorevole contiene route personalizzate per il peering. Le route personalizzate per il peering per la destinazione vengono utilizzate solo quando il modello di route non contiene route personalizzate locali o route dinamiche di Network Connectivity Center per la destinazione.

  6. Seleziona gli hop successivi per le route personalizzate di peering da una singola rete VPC: gli hop successivi per la stessa destinazione devono trovarsi nella stessa rete VPC. Questo passaggio si applica solo se il modello di route contiene route statiche o dinamiche di peering importate da due o più reti VPC diverse connesse tramite il peering di rete VPC.

    Google Cloud utilizza un algoritmo interno per importare route personalizzate per il peering da una singola rete VPC. La rete peer selezionata da Google Cloud potrebbe cambiare se la tua rete VPC esegue il peering con una nuova rete VPC o se si disconnette da una rete VPC peer esistente.

  7. Ignora route statiche e dinamiche con hop successivi inutilizzabili: questo passaggio modella le situazioni in cui Google Cloud ignora gli hop successivi inattivi o non validi.

    • Specifica dell'indirizzo IP della VM dell'hop successivo non valida: il next-hop-address di una route statica deve corrispondere a un indirizzo IP assegnato a una VM nella rete VPC della route. L'indirizzo IP deve essere assegnato all'interfaccia di rete della VM come uno dei seguenti:

      • Un indirizzo IPv4 interno principale
      • Un indirizzo IPv6 interno
      • Un indirizzo IPv6 esterno

      Se l'indirizzo IP specificato da next-hop-address corrisponde a un tipo diverso di risorsa (ad esempio un intervallo IP alias) o non corrisponde a nessuna risorsa, Google Cloud ignora la route.

    • VM hop successivo arrestata o eliminata: Google Cloud ignora ogni route statica la cui istanza VM hop successivo è stata arrestata o eliminata. Questo comportamento si applica ai percorsi i cui hop successivi sono specificati utilizzando next-hop-instance o next-hop-address. Per ulteriori informazioni, consulta Comportamento quando le istanze vengono interrotte o eliminate.

    • Specifica dell'indirizzo IP del bilanciatore del carico dell'hop successivo non valida: per le route statiche con un bilanciatore del carico dell'hop successivo specificato dall'indirizzo IP, l'indirizzo IP deve corrispondere a una regola di forwarding di un bilanciatore del carico di rete passthrough interno che si trova nella rete VPC della route o in una rete VPC in coppia. Se l'indirizzo IP dell'hop successivo corrisponde alla regola di forwarding di un tipo diverso di bilanciatore del carico o non corrisponde a nessuna regola di forwarding, Google Cloud ignora la route.

    • Tunnel VPN classica con hop successivo non stabilito: Google Cloud ignora ogni route statica con un tunnel VPN classica con hop successivo che non ha un'associazione di sicurezza (SA) di fase 1 attiva (IKE). Per maggiori dettagli, consulta Ordine delle route nella documentazione della VPN classica.

    • Route dinamica con hop successivo non funzionale: anche prima che la sessione BGP responsabile della programmazione di una route dinamica vada in down, Google Cloud ignora una route dinamica se il tunnel Cloud VPN, il collegamento VLAN o la VM dell'appliance router dell'hop successivo non è funzionale. In genere, questa situazione si verifica solo per alcuni secondi prima che la route dinamica venga rimossa quando la sessione BGP del router Cloud corrispondente si arresta in modo anomalo.

    Google Cloud non convalida se il sistema operativo guest di una VM di hop successivo o di una VM di backend per un bilanciatore del carico di hop successivo sta elaborando i pacchetti. Per ulteriori informazioni, consulta Considerazioni comuni agli hop successivi delle istanze e dei bilanciatori del carico di rete passthrough interni.

  8. Ignora le route a bassa priorità: questo passaggio modella il modo in cui Google Cloud ignora tutte le route tranne quelle con la priorità più alta.

    Dopo questo passaggio, il modello di percorso potrebbe essere vuoto o contenere uno o più percorsi. Se il modello non è vuoto, tutti i percorsi al suo interno hanno le seguenti caratteristiche:

    • Priorità identiche
    • Hop successivi che non sono stati ignorati
    • Destinazioni identiche
    • Tipi di route che non sono route basate su criteri o di subnet

  9. Seleziona gli hop successivi per le route dinamiche di Network Connectivity Center da una singola rete VPC: gli hop successivi per la stessa destinazione devono trovarsi nella stessa rete VPC. Questo passaggio si applica solo se il modello di route contiene route dinamiche di Network Connectivity Center importate da due o più spoke ibride situate in reti VPC diverse.

    Google Cloud utilizza un algoritmo interno per importare le route dinamiche del Network Connectivity Center dagli spoke ibridi situati in un'unica rete VPC. Gli spoke ibride selezionati potrebbero cambiare se aggiungi o rimuovi spoke ibride dall'hub di Network Connectivity Center. Per evitare questa ambiguità, assicurati che le route dinamiche di Network Connectivity Center abbiano priorità univoche quando si applica quanto segue:

    • Le route hanno destinazioni identiche.
    • Le route vengono importate da due o più spoke ibridi in reti VPC diverse.

  10. Seleziona solo la categoria di preferenza più favorevole: Google Cloud non esegue il multipath con costi uguali (ECMP) tra le route che appartengono a categorie di preferenza diverse, come definito in questo passaggio.

    Categoria di preferenze Tipo di route e tipo di hop successivo
    Prima preferenza (la più preferita) Una o più route statiche con istanze di hop successivo (next-hop-instance o next-hop-address) o tunnel VPN classica di hop successivo.
    Seconda preferenza Uno o più percorsi dinamici di un unico tipo.
    Terza scelta Una singola route statica con bilanciatore del carico di rete passthrough interno come hop successivo.
    Quarta preferenza (meno preferita) Una o più route statiche con hop successivo default-internet-gateway.

    In questo passaggio, se esistono due o più route statiche con bilanciatore del carico di hop successivo, Google Cloud seleziona una singola route statica utilizzando un algoritmo interno. Google Cloud non esegue ECMP tra più bilanciatori del carico. Per ulteriori informazioni, consulta Considerazioni per i nodi successivi del bilanciatore del carico di rete passthrough interno.

    Dopo questo passaggio, il modello di percorso potrebbe essere vuoto o contenere uno o più percorsi. Se il modello non è vuoto, tutti i percorsi al suo interno hanno le seguenti caratteristiche:

    • Categoria di preferenze identica
    • Priorità identiche
    • Hop successivi che non sono stati ignorati
    • Hop successivi in una rete VPC
    • Destinazioni identiche
    • Tipi di route che non sono route basate su criteri o di subnet

  11. Invia o elimina pacchetto: a seconda del numero di route rimanenti nel modello di route, Google Cloud invia o elimina il pacchetto:

    • Se il modello di route contiene una singola route, Google Cloud invia il pacchetto all'hop successivo, con la seguente eccezione:

      I bilanciatori del carico di rete passthrough interni dell'hop successivo per i quali non è stato attivato l'accesso globale non sono accessibili dalle regioni esterne alla regione del bilanciatore del carico. Di conseguenza, se per un bilanciatore del carico di hop successivo non è stato attivato l'accesso globale, Google Cloud elimina tutti i pacchetti inviati dalle istanze VM, dai collegamenti VLAN e dai tunnel Cloud VPN in regioni diverse da quella del bilanciatore del carico. Per modificare questo comportamento, attiva l'accesso globale.

    • Se il modello di percorso contiene due o più percorsi, Google Cloud esegue ECMP, distribuendo i pacchetti tra gli hop successivi. La selezione dell'hop successivo dipende da un calcolo dell'hash e dal numero di hop successivi. Google Cloud utilizza un hash di cinque tuple se il pacchetto contiene informazioni sulla porta; in caso contrario, utilizza un hash di tre tuple. Se il modello di route cambia man mano che vengono inviati i pacchetti successivi, Google Cloud potrebbe indirizzarli a un hop successivo diverso anche se l'hash è lo stesso.

    • Se il modello di route è vuoto, Google Cloud elimina il pacchetto con un messaggio ICMP di tipo 3, codice 0 (rete non raggiungibile).

Passaggi successivi