Routes

Le route di Google Cloud definiscono i percorsi seguiti dal traffico di rete da un percorso di una macchina virtuale (VM) ad 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 è composta da una singola destinazione in formato CIDR e 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 routing virtuale scalabile e distribuito meccanismo di attenzione. Nessun dispositivo fisico assegnato alla rete. Alcune possono essere applicate in modo selettivo, ma la modalità di routing tabella per un La rete VPC è definita a livello di rete VPC.

Ogni istanza VM ha un controller che viene mantenuto informato di tutte le route dalla tabella di routing della rete. Ogni pacchetto in uscita da una VM viene consegnato 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 subnet
Vengono creati automaticamente per ogni indirizzo IP della subnet intervallo 		Rete VPC
Inoltra i pacchetti alle VM e ai bilanciatori del carico interni

Creato, aggiornato e rimosso automaticamente da Google Cloud durante gli eventi del ciclo di vita delle subnet.

Le route di subnet locali si applicano all'intero VPC in ogni rete.
Route personalizzate
Route statico
Supporta varie destinazioni 		Inoltra i pacchetti a una route statica hop successivo Per dettagli su ogni route statica hop successivo, considera le seguenti considerazioni:
Percorso dinamico
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 percorsi appresi dai router Cloud nella tua rete VPC.

Le route si applicano alle VM in base alla rete VPC routing dinamico predefinita.
Route di 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.

Creato, aggiornato e rimosso automaticamente da Google Cloud durante gli eventi del ciclo di vita delle subnet.

Le route della subnet di peering importate si applicano all'intero VPC in ogni rete.
Route statiche e dinamiche di peering
Route statiche o dinamiche in un'altra rete VPC connesse tramite peering di rete VPC 		Hop successivo nella rete VPC peer

Il peering di rete VPC fornisce opzioni per e scambiano route statiche.

Le route statiche di peering importate si applicano all'intero VPC in ogni rete.

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

Le route dinamiche di peering importate si applicano a una o a tutte le regioni di alla rete VPC in base modalità di routing dinamico della rete VPC 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 dello spoke di Network Connectivity Center possono escludi l'esportazione delle route di subnet.

Creato, aggiornato e rimosso automaticamente da Google Cloud durante gli eventi del ciclo di vita delle subnet.

Le route di subnet di Network Connectivity Center importate si applicano all'intero rete VPC.
Route basate su criteri
Route basato 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 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 usa solo una route predefinita per consegnare pacchetto quando non corrisponde a una route più specifica nel routing ordine.

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 locale route statica con una destinazione 0.0.0.0/0 e un gateway internet predefinito nell'hop successivo. 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 risorse di esempio seguenti 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 pubblico Cloud NAT configurato per fornire servizi NAT alle subnet utilizzate dalle interfacce di rete delle VM. A seconda degli intervalli di indirizzi IPv4 della subnet, il gateway Cloud NAT se configurato per la pubblicazione, le origini dei pacchetti possono corrispondere a una delle seguenti:
    • Un indirizzo IPv4 interno da un intervallo di indirizzi IP alias della VM di rete (a prescindere dal fatto che l'interfaccia di rete abbia un'interfaccia indirizzo IPv4) o
    • L'indirizzo IPv4 interno principale dell'interfaccia di rete della VM se all'interfaccia di rete non è 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 ha 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 /96 intervalli di indirizzi IPv6 esterni assegnati alla rete interfacce, quando i pacchetti inviati hanno origini in quell'indirizzo /96 intervallo.

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 Google globale API, La rete VPC non richiede una route predefinita con nell'hop successivo del gateway internet. Google Cloud aggiunge un routing speciale all'endpoint.

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

    • 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 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 ulteriori informazioni sugli intervalli IP di 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 importate da VPC di un hub di Network Connectivity Center.

Interazioni con route statiche

Google Cloud applica le seguenti regole per route di subnet locali, route di subnet e route di subnet di Network Connectivity Center a meno che non vengano specificate la subnet è stata configurata come subnet ibrida.

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

    • Se esiste una route di subnet locale, di peering o di Network Connectivity Center con 10.70.1.0/24 destinazione, non puoi creare una nuova route statica 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 una route di subnet locale o di peering con 2001:0db8:0a0b:0c0d::/64 destinazione, non puoi creare un nuovo elemento statico percorso per 2001:0db8:0a0b:0c0d::/64, 2001:0db8:0a0b:0c0d::/96 o qualsiasi altro altra destinazione che rientra in 2001:0db8:0a0b:0c0d::/64.

  • Google Cloud non ti consente di apportare modifiche alle subnet che generano un intervallo di indirizzi IP corrisponde esattamente a o contiene la destinazione di un modello una route statica. 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 2001:db8:a0b:c0d:e0f:f0e::/96 destinazione, Google Cloud vieta la creazione di una nuova route di subnet locale o di peering con un IPv6 intervallo di indirizzi 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 route dinamiche

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 acquisito da una Sessione BGP di un router Cloud se il prefisso corrisponde esattamente a o rientra nella destinazione di un modello di rete Route di subnet di Network Connectivity Center. 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 eventuali route dinamiche locali o di peering esistenti cambia le subnet comporta la creazione di un una nuova route di subnet locale, di peering o di Network Connectivity Center la cui destinazione corrisponde esattamente a o contiene la destinazione del traffico locale o di peering esistente una route dinamica. 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 la destinazione 2001:db8:a0b:c0d::/96, Google Cloud rimuove la route dinamica quando una nuova subnet locale, di peering o di Network Connectivity Center la route per 2001:db8:a0b:c0d::/64 è stata creata.

Ciclo di vita delle route di subnet

Tutti gli intervalli di indirizzi IP che fanno parte di una subnet: indirizzo IPv4 principale intervalli di indirizzi IPv4 secondari e intervalli di indirizzi IPv6, hanno la route 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 subnet.
    • 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 del router Cloud installa le route dinamiche a livello di regione in base alla modalità di routing dinamico del VPC dell'audiodescrizione:

  • 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 delle 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, vedi Opzioni per lo scambio di subnet route.

Le route delle subnet locali e delle subnet di peering non possono sovrapporsi. Per ulteriori informazioni, vedi Route subnet e subnet di peering e interazioni.

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

Peering di route statiche e dinamiche

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

Il numero di route statiche per gruppo di peering e di route dinamiche per regione per un gruppo di peering è limitato dalla route statica e dinamica per rete quote.

Applicabilità e ordine

Route applicabili

Ogni istanza ha un insieme di route applicabili, che sono un sottoinsieme di tutte le route nella rete VPC. Le route applicabili sono il possibile traffico in uscita percorsi che un pacchetto può seguire quando inviato dall'istanza.

  • Per il routing di ritorno ai bilanciatori del carico proxy si applicano percorsi di routing speciali, sistemi di controllo di integrità e altri servizi Google. Per ulteriori informazioni, vedi percorsi di percorso speciali. Questi percorsi non vengono mostrati in qualsiasi tabella di route.

  • Le route basate su criteri possono essere applicate ai pacchetti inviati da Compute Engine alle istanze VM o a pacchetti ricevuti dai collegamenti VLAN di Cloud Interconnect. Le route basate su criteri si applicano solo se un pacchetto soddisfa i criteri del una route basata su criteri.

  • Le route di subnet locali e di peering si applicano a tutte le istanze. Fatta eccezione per route basate su criteri, nessun altro tipo di route può avere una destinazione o che rientri nella destinazione di una route di subnet locale o di peering. Per maggiori informazioni i dettagli sulla risoluzione dei conflitti tra subnet, statiche e dinamiche vedi Interazioni con route statiche e subnet e Interazioni con subnet e route dinamiche.

  • Le route statiche personalizzate possono essere applicate a tutte le istanze o a istanze specifiche. Le route statiche con un attributo tag si applicano alle istanze che hanno lo stesso tag di rete. Se il percorso non include tag di rete, la route si applica a tutte le istanze nella rete.

  • Le route dinamiche si applicano alle istanze in base alla modalità di routing dinamico la 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

Bilanciatori del carico di rete passthrough esterni e protocollo esterno l'uso dell'inoltro Maglev per instradare i pacchetti dai client su internet alle VM di backend delle tue istanze VM nella tua rete VPC. Questi sistemi Maglev instradano i pacchetti con destinazioni corrispondenti a quella dell'inoltro esterno personalizzata.

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 pacchetto devono corrispondere all'indirizzo IP della regola di forwarding. Protocollo pacchetti e la porta di origine non devono corrispondere al protocollo e alla porta della regola di forwarding la specifica del container.
  • I percorsi di routing delle regole di forwarding non dipendono da una route predefinita o dall'uso di dall'hop successivo del gateway internet predefinito.
  • Non è necessario che l'IP forwarding sia abilitato per le VM di backend e le istanze di destinazione.

Percorsi tra i frontend Google e i backend

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

  • 35.191.0.0/16
  • 130.211.0.0/22

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

Percorsi per i controlli di integrità

Controlli di integrità per tutti i bilanciatori del carico e per il gruppo di istanze gestite riparazione automatica invia pacchetti alle VM di backend dall'indirizzo IP del probe del controllo di integrità intervalli di classificazione.

Google Cloud utilizza le route nella rete Google per consegnare i pacchetti da i sistemi di probe del controllo di integrità sulle VM nel tuo VPC in ogni rete. Ogni rete VPC include percorsi di routing che consentono alle VM per inviare pacchetti di risposta ai sistemi di probe del 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. Ciascuna La 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 utilizzano 35.199.192.0/19 come intervallo solo interno con hop successivi completamente all'interno della rete Google. Google non pubblica i percorsi verso 35.199.192.0/19 su su internet.

Le route nella rete Google consegnano pacchetti da 35.199.192.0/19 alle VM nel tuo rete VPC quando utilizzi questi servizi Cloud DNS Service Directory. Ogni rete VPC include il routing percorsi che consentono alle VM di inviare pacchetti di risposta a 35.199.192.0/19.

Percorsi per l'accesso VPC serverless

L'accesso VPC serverless utilizza 35.199.224.0/19 come intervallo solo interno con hop successivi completamente all'interno della rete Google. Google non pubblica i percorsi verso 35.199.224.0/19 su su internet.

Le route nella rete Google consegnano pacchetti da 35.199.224.0/19 a Istanze del connettore di accesso VPC serverless. Ogni VPC La rete include percorsi di routing che consentono alle istanze del connettore di inviare la risposta pacchetti in 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 la selezione delle route di rete VPC il comportamento predefinito, a partire dall'insieme di route applicabili descritte nei 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: le route basate su criteri vengono valutate dopo speciali ma prima di altri tipi di route. Se non esistono route basate su criteri esiste nella rete VPC, Google Cloud salta questo passaggio e continua con il passaggio della destinazione più specifica.

    Google Cloud valuta le route basate su criteri esclusivamente in base alla loro priorità. Google Cloud valuta l'origine e la destinazione di un pacchetto route basata su criteri, che inizia con la route basata su criteri con la massima priorità route. 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. Il prossimo basata su criteri da valutare potrebbe condividere la stessa priorità della disconosciuta basata su criteri, oppure potrebbe 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 continua a nel passaggio della destinazione più specifica.

    • Se le caratteristiche di un pacchetto corrispondono a una route, Google Cloud ignora innanzitutto tutte le istanze e route basate su criteri. 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 qualsiasi route basate su criteri rimanenti se le caratteristiche di un pacchetto non corrispondono li annotino. Dopo questo passaggio, il modello di selezione delle route potrebbe contenere uno o più route basate su criteri.

    • Se il modello di selezione del percorso include due o più corrispondenze route basate su criteri a priorità massima, Google Cloud seleziona una un'unica 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 basate 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 valuta le route non basate su criteri nella destinazione più specifica e ignora tutte le route basate su criteri.

    • Se il modello di selezione del percorso include solo una singola priorità più alta route basata su criteri che non è configurata per saltare altre route basate su criteri route, Google Cloud consegna il pacchetto all'hop successivo Network Load Balancer passthrough interno e ignora tutte le route non basate su criteri.

  3. Destinazione più specifica: Google Cloud determina quale tra le route applicabili hanno la destinazione più specifica che contiene all'indirizzo IP di destinazione del pacchetto. Google Cloud ignora tutti altri percorsi con destinazioni meno specifiche. Ad esempio, 10.240.1.0/24 è una destinazione più specifica di 10.240.0.0/16.

    Dopo questo passaggio, il modello di selezione delle route non contiene percorsi di routing speciali. e nessuna route basata su criteri. Include solo le route con il destinazioni specifiche.

  4. Hop successivi in una singola transazione 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 seleziona gli hop successivi che si trovano tutti in un unico 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 nel VPC locale anche se esistono hop successivi per la stessa destinazione in uno o più in reti VPC peer.

    • Se in nessuna delle route nel modello di route sono presenti hop successivi all'interno della sezione La rete VPC che stai modellando e tutti gli hop successivi esistono più reti peer, Google Cloud utilizza un algoritmo interno per selezionare una singola rete peer con gli hop successivi per la configurazione destinazioni. La priorità della route non viene considerata in questo momento. Inoltre, se la tua rete VPC esegue il peering con una nuova o se si disconnette da un VPC peer esistente rete VPC selezionata per gli hop successivi, modifica.

    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.

  5. Ignorare dati statici e dinamici con hop successivi inutilizzabili: questo passaggio modella le situazioni in cui Google Cloud ignora gli hop successivi non attivi o non validi.

    • Specifica dell'indirizzo IP della VM dell'hop successivo non valida: indirizzi IP specificati da utilizzando next-hop-address deve risolversi in uno dei 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 un indirizzo IP la route statica di peering ha un bilanciatore del carico dell'hop successivo in base all'indirizzo IP, l'indirizzo IP dell'hop deve risolversi in una regola di forwarding per un bilanciatore del carico di rete passthrough interno situato nella rete VPC della route o in una rete VPC rete VPC. 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 la ignora.

    • Bilanciatore del carico di rete passthrough interno dell'hop successivo inaccessibile: se un bilanciatore del carico di rete locale o ha un bilanciatore del carico per l'hop successivo e se la risorsa Google Cloud l'invio del pacchetto si trova in una regione diversa da quella di caricamento regione del bilanciatore del carico, Google Cloud ignora la route se nella regola di forwarding non è abilitato l'accesso globale. La route viene ignorata se l'hop successivo è specificato da nome o indirizzo IP.

    • Tunnel VPN classica dell'hop successivo non stabilito: Google Cloud ignora ogni route statica locale o di peering la cui Il tunnel VPN classica non ha una Fase 1 attiva (IKE) Security Association (SA). Per ulteriori dettagli, consulta la sezione Ordine di 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.

  6. 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 delle route potrebbe essere vuoto oppure contengono una o più route. Se il modello contiene effettivamente delle route, di questi percorsi hanno tutte queste caratteristiche:

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

  7. 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 hop successivo.

    Categoria di preferenza Combinazione di categoria e hop successivo
    Prima scelta (preferenza massima) Route statiche locali o di peering con istanze dell'hop successivo (next-hop-instance o next-hop-address) o successiva hop tra i tunnel VPN classica.
    Seconda scelta Route dinamiche locali o di peering.
    Terza scelta

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

    Tieni presente che Google Cloud non è in grado di bilanciare il carico tra route statiche con diversi hop successivi del bilanciatore del carico di rete passthrough interno. Per maggiori informazioni informazioni, consulta Considerazioni sulle hop successivi del bilanciatore del carico di rete passthrough interno.
    Quarta scelta Route statiche locali con hop successivo default-internet-gateway.

    Alla fine di questo passaggio, potrebbero esserci zero percorsi, uno, due o più route nel modello di percorso.

  8. Invia o elimina pacchetto: ciò che succede dipende dal numero di route rimanenti nel modello di route:

    • Se il modello di route è vuoto, il pacchetto viene eliminato con un modello ICMP errore di destinazione o rete non raggiungibile. Google Cloud mai torna a una route meno specifica che potrebbe avere un hop successivo funzionante.

    • Se il modello di route contiene una singola route, Google Cloud invia la richiesta all'hop successivo. Per gli hop successivi delle VM, Google Cloud verificare che l'hop successivo della VM possa elaborare i pacchetti. Per maggiori dettagli, vedi Successivamente alle considerazioni comuni all'istanza e al bilanciatore del carico di rete passthrough interno hop. Se la route singola è una route di subnet o route subnet di peering e non sono presenti risorse Google Cloud a all'indirizzo IP di destinazione del pacchetto, il pacchetto viene ignorato.

    • Se il modello di route contiene due o più route, le route condividono stessa destinazione più specifica, si trovano in un rete VPC, hanno hop successivi che non sono noti verso il basso, hanno la stessa priorità più alta e appartengono a un solo tipo di route 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 degli hash vengono eseguiti per ogni pacchetto l'ora di 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 quando vengono inviati pacchetti successivi, Google Cloud potrebbe i pacchetti in un hop successivo diverso anche se l'hash è lo stesso.

Passaggi successivi