Routes

Le route Google Cloud definiscono i percorsi seguiti dal traffico di rete da un'istanza virtuale (VM) a altre destinazioni. Queste destinazioni possono essere all'interno la tua rete Virtual Private Cloud (VPC) di Google Cloud (ad esempio, a 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 un la rete VPC invia un pacchetto, Google Cloud invia pacchetto all'hop successivo della route se l'indirizzo di destinazione del pacchetto si trova all'interno nell'intervallo di destinazione del percorso.

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 propagati ai controller VM utilizzando una soluzione la progettazione.

Tipi di route

Le tabelle seguenti riepilogano il modo in cui Google Cloud classifica le route reti VPC.

Tipo e destinazione Hop successivo Note
Route generate 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

Può essere rimosso o sostituito
Route della subnet
Creata automaticamente per ogni intervallo di indirizzi IP della subnet 		Rete VPC
Inoltra i pacchetti alle VM e ai bilanciatori del carico interni

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 personalizzate
Route statico
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
Destinazioni che non sono in conflitto con route delle 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 si applicano alle VM in base alla rete VPC routing dinamico predefinita.
Percorsi del peering di rete VPC
Route subnet di peering
Rappresenta un intervallo di indirizzi IP di una subnet in un VPC diverso rete connessa tramite peering di rete VPC 		Hop successivo nella rete VPC peer

Il peering di rete VPC fornisce opzioni per con lo scambio di 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.
Route statiche e dinamiche del 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'intero VPC in ogni rete.

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

Le route dinamiche di peering importate 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 di Network Connectivity Center
Route di subnet di Network Connectivity Center
Rappresenta un intervallo di indirizzi IP di una subnet in uno spoke VPC (un'altra rete VPC connessa a Network Connectivity Center) hub) 		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 basate su criteri
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 sono valutato prima che altre route valutati. Le route basate su criteri possono essere applicate a tutte le VM nella rete, determinate VM selezionate per tag di rete o per il traffico che entra Rete VPC tramite VLAN Cloud Interconnect allegati da te specificati.

Le route basate su criteri non vengono mai scambiate tramite il peering di rete VPC.

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 internet perché percorsi speciali per i bilanciatori del carico di rete passthrough esterni e i bilanciatori del carico di rete esterni il forwarding del protocollo non dipende da una route predefinita.

Quando crei un VPC , Google Cloud aggiunge un indirizzo predefinito IPv4 generato dal sistema al percorso rete VPC. 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 predefinita l'hop successivo del gateway internet fornisce un percorso all'IPv4 esterno indirizzi IP, inclusi gli indirizzi IPv4 su internet. Le seguenti risorse di esempio utilizzano questo percorso:

  • VM con indirizzi IPv4 esterni assegnati alle proprie interfacce di rete, quando i pacchetti che inviano hanno origini corrispondenti all'interfaccia di rete principale all'indirizzo IPv4 interno.
  • 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. Lo stato generato dal sistema La route predefinita IPv6 è una route statica locale con destinazione ::/0 e e l'hop successivo del gateway internet predefinito. Una route statica locale con ::/0 l'hop successivo del gateway internet predefinito e della destinazione fornisce un percorso all'esterno Indirizzi IPv6, inclusi gli indirizzi IPv6 su 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 di Google globali dipende da un protocollo IPv4 o IPv6 locale route 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 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 ad API e 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:

    • Se le VM hanno solo indirizzi IP interni, consulta Routing opzioni per Accesso privato Google.
    • Se le VM hanno indirizzi IP esterni, consulta Routing opzioni.

Route di subnet

Le route subnet definiscono i percorsi di risorse come VM e bilanciatori del carico interni una rete VPC.

Ogni subnet ha almeno una route subnet la cui destinazione corrisponde all'istanza principale Intervallo IPv4 della subnet. Se la subnet ha intervalli IP secondari, è presente una route di subnet corrispondente a ciascuno dei suoi intervalli di indirizzi IP secondari. Se una subnet ha un intervallo IPv6, esiste una route di subnet corrispondente per di indirizzi IP esterni. Per saperne di più sugli intervalli IP delle subnet, consulta Subnet.

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

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

Interazioni con route statiche

Google Cloud applica le seguenti regole per le route delle subnet locali, le route delle subnet di 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 rientri 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 che corrisponde esattamente o contiene la destinazione di una route statica locale o di peering esistente. Ad esempio:

    • Se la tua 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 principali o secondari di 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro intervallo di indirizzi IP contenente tutte le indirizzi 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 con i percorsi dinamici

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

  • Google Cloud non crea una route dinamica per un prefisso appreso da una sessione BGP di un router Cloud se il prefisso 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 10.70.1.0/24 e se è presente un router Cloud Una rete VPC o una rete VPC in peering riceve 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro prefisso adatto 10.70.1.0/24, Google Cloud non crea creatività dinamiche locali o di peering per i prefissi in conflitto ricevuti.

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

  • Google Cloud rimuove qualsiasi route dinamica locale o di peering esistente se qualsiasi 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 o contiene la destinazione della route dinamica locale o di peering esistente. Ad esempio:

    • Se la tua rete VPC ha una route dinamica locale o di peering con la destinazione 10.70.1.128/25, Google Cloud rimuove una route dinamica quando una nuova route di subnet 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 che contiene tutti gli indirizzi IPv4 in 10.70.1.128/25 creato.

    • Se la tua rete VPC ha una route dinamica locale o di peering 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.

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 route di subnet in questi scenari:

  • Crei una configurazione di subnet modifica, 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 automatica in modalità VPC. Per informazioni sull'indirizzo IPv4 per ogni subnet in base alla regione, intervalli IPv4 in modalità automatica.

Route dinamiche

Router Cloud indica alla rete VPC di creare, aggiornare e rimuovere route basate sui messaggi BGP (Border Gateway Protocol) ricevuti, applicabile Route BGP norme (Anteprima) e un router Cloud personalizzato colto route che che configuri. Il piano di controllo di Cloud Router installa route dinamiche a livello di regione in base alla modalità di routing dinamico della rete VPC:

  • Se una rete VPC utilizza la modalità di routing dinamico a livello di regione, I router Cloud in ogni regione creano route dinamiche solo nella stessa regione regione Cloud come router Cloud.

  • Se una rete VPC utilizza la modalità di routing dinamico globale, I router Cloud in ogni regione creano route dinamiche in tutte le regioni della rete VPC.

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 sua sessione BGP indica rete VPC per rimuovere la route dinamica dopo uno dei le seguenti condizioni sono soddisfatte:

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

Route di subnet di peering

Le route delle subnet di peering definiscono i percorsi delle risorse nelle subnet in un'altra ad altre reti VPC connesse tramite Peering di rete VPC. Per ulteriori informazioni, consulta Opzioni per lo scambio di route per le sottoreti.

Le route delle subnet locali e delle subnet di peering non possono sovrapporsi. Per ulteriori informazioni, consulta la sezione Interazioni tra route di subnet e subnet peering.

Il numero di route subnet per gruppo di peering è controllato dalla rete di subnet per quota gruppo di peering.

Route statiche e dinamiche di peering

Quando utilizzi il peering di rete VPC per connettere due reti VPC, puoi esportare route statiche e dinamiche da una rete e importarle nell'altra. Per ulteriori informazioni, vedi:

Il numero di route statiche per gruppo di peering e di route dinamiche per regione per gruppo di peering è limitato dalle quote di route statiche e dinamiche per rete.

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, Collegamenti VLAN Cloud Interconnect e tunnel Cloud VPN:

I seguenti tipi di route possono essere configurati per essere applicati solo a determinate VM istanze, collegamenti VLAN o tunnel Cloud VPN:

  • Le route basate su criteri si possono applicare a:

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

  • Le route statiche si possono applicare 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 i tunnel Cloud VPN nella regione contenente il percorso all'hop successivo della route o a tutte le regioni, in base alla modalità di routing dinamico del rete VPC.

Percorsi di routing speciali

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

Percorsi per i bilanciatori del carico di rete passthrough esterni e il forwarding del protocollo esterno

I bilanciatori del carico di rete passthrough esterni e il inoltro di protocolli esterni 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 routing che le VM di backend o istanza di destinazione inviino pacchetti verso destinazioni esterne alla rete VPC:

  • I pacchetti inviati dalle VM di backend o dalle istanze di destinazione possono essere in uscita di risposta (restituiti al client) o possono essere pacchetti in uscita che avviano una nuova connessione.
  • Le origini pacchetti devono corrispondere all'indirizzo IP della regola di forwarding. Il protocollo del pacchetto e la porta di origine non devono corrispondere alla specifica del protocollo e della porta della regola di inoltro.
  • 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 abilitare l'IP forwarding per le VM di backend e le istanze di destinazione.

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 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 con IAP utilizza 35.235.240.0/20 come intervallo solo interno con hop successivi completamente all'interno della rete Google. Google non pubblica i percorsi verso 35.235.240.0/20 su su internet.

Le route nella rete Google consegnano pacchetti da 35.235.240.0/20 alle VM nel tuo rete VPC quando si utilizza l'inoltro 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 Directory dei servizi. 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 Google globale API, Google Cloud aggiunge una route per l'endpoint al tuo VPC in ogni rete. La destinazione della route è l'indirizzo IP interno globale del endpoint.

Ordine di routing

Il seguente processo modella il comportamento di selezione delle route della rete VPC, a partire dall'insieme di route applicabili descritto nella sezione precedente.

  1. Percorsi di routing speciali: alcuni percorsi di routing speciali di Google Cloud non come mostrato nella tabella delle route di 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. Tutte le altre route vengono ignorate e la valutazione si ferma in questo passaggio.

  2. Route basate su criteri: basate su criteri vengono valutate dopo speciali percorsi di routing, ma prima di altri tipi di route. Se nella rete VPC non sono presenti route basate su criteri, Google Cloud salta questo passaggio e continua il passaggio relativo alle route 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 basata su criteri e continua a valuta la successiva route basata su criteri 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 vengono lasciate due o più route basate su criteri nella di Google Cloud, Google Cloud valuta tutte le altre soluzioni basate su criteri percorsi 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 delle route potrebbe contenere uno o più route basate 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. L'elemento selezionato basata su criteri potrebbe non essere la corrispondenza più specifica per sorgente o destinazione. Per evitare questa ambiguità, ti consigliamo di creare route basati su criteri con priorità univoche.

    • Se il modello di selezione del percorso include solo una singola priorità più alta basata su criteri, configurata per saltare altre route basate su criteri route, Google Cloud ignora tutte le route basate su criteri e continua il passaggio relativo alle route subnet.

    • 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. Subnet route: Google Cloud determina se un pacchetto rientra nell'intervallo di destinazione di un o la route di subnet di Network Connectivity Center nella rete VPC.

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

    • Se la destinazione di un pacchetto corrisponde all'intervallo di destinazione di una route di 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 subnet di routing, il tentativo di inviare il pacchetto a una risorsa nella subnet come un'interfaccia di rete VM o una regola di forwarding interno. Tutti gli altri percorsi vengono ignorati e la valutazione si interrompe in questo passaggio. In caso contrario sia presente utilizzando la destinazione del pacchetto o se la risorsa è un'istanza VM arrestata, il pacchetto viene eliminato.

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

        • Se nella subnet esiste una risorsa, Google Cloud utilizza esclusivamente la route della subnet, tentando di inviare 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 tutte le route di subnet, inclusa la route di subnet corrispondente, e continua con il passaggio Più .

  4. Destinazione più specifica: al all'inizio di questo passaggio, il modello di selezione del percorso non contiene percorsi di routing, nessuna route basata su criteri o locale Route di subnet di Network Connectivity Center.

    Google Cloud determina quali delle route applicabili rimanenti sono la destinazione più specifica che contiene l'indirizzo IP di destinazione un 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 dei percorsi conterrà solo i percorsi personalizzati più specifici.

  5. Hop successivi in un singolo Rete VPC: questo passaggio è applicabile solo se Rete VPC il cui comportamento delle route stai modellando è connessa a una o più reti VPC peering di rete VPC. Con il peering di rete VPC, le route personalizzate destinazioni identiche possono esistere in più reti del gruppo di peering. Il requisito modellato in questo passaggio è che Google Cloud selezioni gli hop successivi che si trovano tutti in un'unica rete VPC.

    • Se per uno o più percorsi nel modello di percorso sono presenti hop successivi rete VPC che stai modellando, ignora tutte le route con hop successivi nelle reti peer. In questa situazione, Google Cloud utilizza solo gli hop successivi nella rete VPC locale, anche se esistono hop successivi per la stessa destinazione in una o più reti VPC peer.

    • Se nessuna delle route nel modello di route ha hop successivi all'interno della rete VPC che stai modellando e tutti gli hop successivi esistono in più reti peer, Google Cloud utilizza un algoritmo interno per selezionare una singola rete peer con gli hop successivi per le destinazioni più specifiche. La priorità del percorso non viene presa in considerazione in questo momento. Inoltre, se la rete VPC esegue il peering con una nuova rete VPC o se si disconnette da una rete VPC peer esistente, la rete VPC selezionata per gli hop successivi potrebbe cambiare.

    Dopo questo passaggio, il modello di selezione delle route contiene solo le route con le destinazioni più specifiche e gli hop successivi per questi percorsi sono tutti in una singola rete VPC.

  6. 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: gli indirizzi IP specificati utilizzando next-hop-address devono risolvere in una delle seguenti configurazioni nella stessa rete VPC della route:

      • Un indirizzo IPv4 interno principale dell'interfaccia di rete di una VM.
      • Un indirizzo IPv6 interno o esterno dell'interfaccia di rete di una VM

    • VM hop successivo non in esecuzione: Google Cloud ignora ogni istanza locale o route statica di peering la cui istanza VM dell'hop successivo è stata arrestata o eliminata. Questo comportamento si applica alle route configurate con next-hop-instance o next-hop-address. Per ulteriori informazioni, consulta la sezione Comportamento quando le istanze vengono interrotto o eliminato nella sezione Considerazioni per l'hop successivo Istanze.

    • Specifica dell'indirizzo IP del bilanciatore del carico di rete passthrough interno dell'hop successivo non valida: se una route statica locale o in peering ha un bilanciatore del carico dell'hop successivo in base all'indirizzo IP, l'indirizzo IP dell'hop successivo deve risolvere in una regola di inoltro per un bilanciatore del carico di rete passthrough interno, situato nella rete VPC della route o in una rete VPC in peering. Se l'indirizzo IP dell'hop successivo viene risolto in un regola di forwarding per un tipo diverso di bilanciatore del carico o non viene risolta una regola di forwarding, Google Cloud ignora la route.

    • Bilanciatore del carico di rete passthrough interno di hop successivo non accessibile: se una route statica locale o di peering ha un bilanciatore del carico di hop successivo e se la risorsa Google Cloud che invia il pacchetto si trova in una regione diversa da quella del bilanciatore del carico, Google Cloud ignora la route se la regola di inoltro non ha l'accesso globale abilitato. La route viene ignorata indipendentemente dal fatto che l'hop successivo sia specificato per nome o indirizzo IP.

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

    • Route dinamica con hop successivo non funzionante: anche prima della sessione BGP responsabile della programmazione di una route dinamica locale o di peering smette di Google Cloud ignora un tunnel Cloud VPN dell'hop successivo, Collegamento VLAN Cloud Interconnect o VM dell'appliance router se l'hop successivo non funziona. Questa situazione in genere esiste solo per un secondi prima che la route dinamica venga rimossa quando La sessione BGP del router Cloud non è attiva.

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

    Dopo questo passaggio, il modello di selezione dei percorsi potrebbe essere vuoto o contenere uno o più percorsi. Se il modello contiene percorsi, tutti i percorsi devono avere tutte queste caratteristiche:

    • Destinazioni identiche e più specifiche
    • Hop successivi tutti in una rete VPC: la rete VPC locale o una singola rete VPC peer
    • Hop successivi che non risultano fermi
    • Priorità identiche e massime

  8. Seleziona solo la categoria di preferenza più favorevole: Google Cloud evita il routing ECMP tra diversi tipi di hop successivi. Puoi modellare il comportamento del pubblico considerando il sistema di categorie di preferenze descritto seguente. Questa fase perfeziona il modello di percorso in modo che contenga solo di percorsi dello stesso tipo o di una combinazione di questi di hop successivo.

    Categoria di preferenza Combinazione di categoria e hop successivo
    Prima scelta (preferenza più alta) Route statiche locali o di peering con istanze di hop successivo (next-hop-instance o next-hop-address) o tunnel VPN classica di hop successivo.
    Seconda scelta Route dinamiche locali o di peering.
    Terza scelta

    Route statiche locali o di peering con bilanciatore del carico di rete passthrough interno come hop successivo (indipendentemente da come viene specificato l'hop successivo).

    Tieni presente che Google Cloud non esegue il bilanciamento del carico tra più route statiche con hop successivi del bilanciatore del carico di rete passthrough interno diversi. Per maggiori informazioni informazioni, consulta Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno.
    Quarta scelta Route statiche locali con hop successivo default-internet-gateway.

    Al termine di questo passaggio, nel modello di percorso potrebbero non essere presenti percorsi, uno o più percorsi.

  9. Invia o elimina pacchetto: cosa succede dipende dal numero di percorsi rimanenti nel modello di percorso:

    • Se il modello di route è vuoto, il pacchetto viene ignorato con un errore ICMP di destinazione o rete non raggiungibile.

    • Se il modello di route contiene una singola route, Google Cloud invia il pacchetto all'hop successivo. Per gli hop successivi delle VM, Google Cloud verificare che l'hop successivo della VM possa elaborare i pacchetti. Per ulteriori informazioni, consulta Considerazioni comuni agli hop successivi delle istanze e dei bilanciatori del carico di rete passthrough interni.

    • Se il modello di route contiene due o più route, queste condividono la stessa destinazione più specifica, si trovano in un'unica rete VPC, hanno hop successivi che non sono noti come inattivi, hanno la stessa priorità massima e appartengono a un tipo di route e a una combinazione di hop successivo (categoria di preferenza). Google Cloud distribuisce i pacchetti tra gli hop successivi implementando la funzionalità costo pari multipath (ECMP) utilizzando un algoritmo di hashing. I calcoli dell'hash vengono eseguiti per ogni pacchetto al momento dell'invio, in base al numero corrente di hop successivi. Google Cloud utilizza un hash a cinque tuple se il pacchetto contiene una porta informazioni; altrimenti utilizza un hash a 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.

Passaggi successivi