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.

Route predefinite generate dal sistema

Quando crei un VPC rete, include una IPv4 generato dal sistema predefinito percorso (0.0.0.0/0). Quando crei un doppio stack una subnet con un'istanza Intervallo di indirizzi IPv6 in una rete VPC, un indirizzo IPv6 generato dal sistema la route predefinita (::/0) viene aggiunta alla rete, se non è già presente esistono. Le route predefinite hanno i seguenti scopi:

• Le route predefinite IPv4 e IPv6 definiscono un percorso Da rete VPC a IP esterno indirizzi IP su internet.

• La route predefinita può fungere da percorso alle API e ai servizi Google. Per Per ulteriori informazioni, consulta Configurare l'accesso privato Google. e Accedi alle API da VM con indirizzi IP esterni. La route predefinita non viene utilizzata se accedi alle API di Google tramite Endpoint Private Service Connect.

Google Cloud utilizza solo una route predefinita se una route con un destinazione non si applica a un pacchetto. Per informazioni su come impostare la specificità e la priorità del percorso vengono utilizzate per selezionare un percorso, vedi routing .

Se vuoi isolare completamente la tua rete da internet o se per sostituire la route predefinita con una route personalizzata, puoi eliminare la route predefinita route:

• Solo IPv4: se vuoi indirizzare il traffico internet a un altro hop successivo, puoi sostituire la route predefinita con una route statica o dinamica personalizzata. Per Ad esempio, potresti sostituirla con una route statica personalizzata il cui hop successivo è una VM proxy.

• IPv4 e IPv6: se elimini la route predefinita e non la sostituisci, i pacchetti destinati a intervalli IP non coperti da altre route vengono è caduto.

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.

Le route subnet hanno sempre le destinazioni più specifiche. Non possono essere viene sostituito da altri percorsi, anche se un altro percorso ha una priorità più alta. Questo è perché Google Cloud considera la specificità della destinazione prima della priorità quando selezioni un percorso. Google Cloud utilizza 0 come priorità per tutti route di subnet.

Interazioni con route statiche

Le route di subnet locali e le route di subnet di peering importate interagiscono con delle route statiche nei seguenti modi:

• Google Cloud non consente di creare una route statica personalizzata con un destinazione uguale o più ristretta rispetto a qualsiasi route subnet o route di subnet di peering. Ad esempio:

  • Se esiste una route di subnet locale o una route di subnet di peering 10.70.1.0/24 destinazione, non puoi creare una nuova route statica personalizzata per 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 o qualsiasi altro destinazioni che rientrano in 10.70.1.0/24.

  • Se esiste una route di subnet locale o una route di subnet di peering 2001:0db8:0a0b:0c0d::/64 destinazione, non puoi crearne una nuova personalizzata route statica per 2001:0db8:0a0b:0c0d::/64 o qualsiasi destinazione adatta all'interno di 2001:0db8:0a0b:0c0d::/64, ad esempio 2001:0db8:0a0b:0c0d::/96.

• Al contrario, Google Cloud non consente di creare una nuova route di subnet una route subnet di peering la cui destinazione corrisponde esattamente o è più ampia di (contiene) una route statica personalizzata esistente. Ad esempio:

  • Se la tua rete VPC ha una route statica personalizzata per destinazione 10.70.1.128/25, Google Cloud vieta la creazione di qualsiasi route di subnet o route di subnet di peering che ha un intervallo di indirizzi IPv4 della subnet 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro che contiene tutti gli indirizzi IPv4 in 10.70.1.128/25.

  • Se la tua rete VPC ha una route statica personalizzata per destinazione 2001:0db8:0a0b:0c0d::/96, Google Cloud vieta creazione di qualsiasi route di subnet a doppio stack o route di subnet di peering che Intervallo di indirizzi IPv6 di 2001:0db8:0a0b:0c0d::/64 o qualsiasi altro intervallo che contiene tutti gli indirizzi IPv6 in 2001:0db8:0a0b:0c0d::/96.

Interazioni con route dinamiche

Le route di subnet locali e le route di subnet di peering importate interagiscono con i router Cloud nei seguenti modi:

• Quando i router Cloud apprendono un prefisso che corrisponde esattamente al di una subnet esistente o di una subnet di peering Google Cloud non crea alcuna route dinamica personalizzata per prefisso in conflitto. Ad esempio, quando una subnet o una route subnet di peering con la destinazione 10.70.1.0/24 esiste, se i router Cloud La rete VPC riceve il prefisso 10.70.1.0/24 tramite BGP, Google Cloud utilizza la route subnet o subnet di peering e non crea una route dinamica personalizzata per 10.70.1.0/24.

  • Quando una route subnet o subnet di peering la cui destinazione esattamente corrisponde a un prefisso appreso dai router Cloud viene creata la rete VPC, Google Cloud rimuove route dinamica personalizzata per il prefisso in conflitto in modo da liberare spazio per la subnet o la route della subnet di peering.

• Quando i router Cloud apprendono i prefissi che si adattano alla destinazione di una subnet esistente o di una subnet di peering, Google Cloud creare route dinamiche personalizzate per i prefissi in conflitto. Ad esempio: quando esiste una subnet o una subnet di peering con destinazione 10.70.1.0/24, se i router Cloud nella rete VPC ricevono Prefissi 10.70.1.0/25 e 10.70.1.128/25 tramite BGP, Google Cloud utilizza la subnet della subnet o della subnet di peering e non crea valori personalizzati route dinamiche per 10.70.1.0/25 e 10.70.1.128/25.

  • Quando una route subnet o subnet di peering la cui destinazione contiene prefissi appresi dai router Cloud nel VPC viene creata la rete, Google Cloud rimuove le route dinamiche personalizzate per i prefissi in conflitto per fare spazio alla subnet una route subnet.

Ciclo di vita delle route di subnet

Le route subnet vengono create, aggiornate ed eliminate quando crei, modifichi o Elimina le subnet o i relativi intervalli di indirizzi IP:

• Quando aggiungi una subnet, Google Cloud crea una route subnet corrispondente per nell'intervallo di indirizzi IP principali.

  • Se espandi l'indirizzo IP principale di una subnet intervallo, Google Cloud aggiorna la destinazione della route di subnet corrispondente.

  • Se aggiungi o rimuovi un intervallo di indirizzi IP secondari in una subnet, Google Cloud crea o elimina una route subnet corrispondente per l'intervallo secondario.

• Creazione di reti VPC in modalità automatica automaticamente una subnet per gli intervalli IP principali di ciascuno le subnet create. Puoi eliminare queste subnet solo se converti l'impostazione rete VPC dalla modalità personalizzata alla modalità personalizzata.

• Non puoi eliminare una route subnet se non modifichi o elimini la subnet:

  • Quando rimuovi un intervallo secondario da una subnet, la route della subnet l'intervallo secondario viene eliminato automaticamente.

  • Quando elimini una subnet, vengono instradate tutte le route sia per l'istanza principale vengono eliminati automaticamente. Non puoi eliminare la subnet per l'intervallo principale della subnet in altro modo.

Il numero di route di subnet in una rete VPC è limitato per il numero massimo di intervalli IP di subnet (primari e secondari).

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:

• Un collegamento VLAN supportato da Dedicated Interconnect o una connessione Partner Interconnect connessione

• Un tunnel Cloud VPN, tunnel VPN ad alta disponibilità o una VPN classica configurata per usare calcolo itinerario

• Un'istanza VM dell'appliance router nel Network Connectivity Center

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:

• Il timer di riavvio graceful del router peer è scaduto (se il peer BGP supporta il riavvio graceful).

• Il timer di sospensione del router Cloud è scaduto. Lo Blocco del router Cloud timer è proporzionale al valore configurabile keepalive del router Cloud timer.

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:

• Opzioni per lo scambio di route statiche personalizzate

• Opzioni per lo scambio di route dinamiche personalizzate

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 quotas.

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 dalla VM di Compute Engine alle istanze o a pacchetti ricevuti dalla VLAN Cloud Interconnect allegati. Le route basate su criteri si applicano solo se un pacchetto corrisponde della 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 ulteriori 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 un 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 sulla 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 . 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.

• Destinazioni di forwarding di Cloud DNS che utilizzano il routing privato
• Server dei nomi alternativi di Cloud DNS che utilizzano il routing privato
• Accesso alla rete privata per Service Directory

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.

1. Destinazione più specifica:Google Cloud determina quale dei 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. Il modello più specifico una destinazione può essere qualsiasi tipo di percorso; mentre la subnet route, route di subnet in peering e i percorsi di routing speciali sono i più specifici definizione di Kubernetes.

   Dopo questo passaggio, il modello di selezione delle route non contiene percorsi di routing speciali. o route basate su criteri. Include solo i percorsi con le informazioni destinazioni.

2. Hop successivi in una singola rete VPC: questo passaggio riguarda solo applicabile se la rete VPC di cui si verifica il comportamento della route la modellazione è connessa a una o più reti VPC tramite 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.

3. Ignora le route statiche personalizzate i cui hop successivi non sono in esecuzione: "step" crea due situazioni in cui Google Cloud ignora gli hop successivi che considera non in esecuzione. Questo passaggio si applica solo ai route statiche. Le route dinamiche personalizzate vengono aggiunte e rimosse automaticamente utilizzando gli annunci BGP.

   • Google Cloud ignora ogni istanza VM dell'hop successivo (next-hop-instance o next-hop-address) se la VM dell'hop successivo è stata interrotto o eliminato. Per ulteriori dettagli, consulta Comportamento quando le istanze vengono arrestato o eliminato in Considerazioni per l'hop successivo Istanze. Se il modello di route contiene route statiche le cui VM dell'hop successivo vengono arrestate o eliminate, rimuovile dal modello.

   • Google Cloud ignora ogni route statica personalizzata che utilizza un hop VPN classica tunnel se il tunnel non ha un Associazione di sicurezza (SA) di fase 1 (IKE). Per ulteriori dettagli, consulta la sezione Ordine di route nella documentazione della VPN classica. Se il modello di route contiene route statiche i cui hop successivi sono VPN classica tunnel senza SA IKE stabilite, rimuovile dal tuo model.

4. 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

5. 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 personalizzate con un'istanza dell'hop successivo in esecuzione (next-hop-instance o next-hop-address) oppure IKE SA stabilita per l'hop successivo VPN classica tunnel
   Seconda scelta	Route dinamiche personalizzate apprese da qualsiasi sessione BGP di qualsiasi Router Cloud
   Terza scelta	Una singola route statica personalizzata con un bilanciatore del carico di rete passthrough interno hop successivo Google Cloud utilizza un algoritmo interno per selezionare una singola Bilanciatore del carico di rete passthrough interno dell'hop successivo, ignorando l'altro bilanciatore del carico di rete passthrough interno gli hop successivi con la stessa priorità. Per ulteriori dettagli, consulta e più bilanciatori del carico di rete passthrough interni per l'hop successivo" nel Considerazioni sul bilanciatore del carico di rete passthrough interno hop successivi.
   Quarta scelta	una route statica personalizzata che utilizza Hop successivo: default-internet-gateway

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

6. Invia o elimina un pacchetto: ciò che accade 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 volta che viene inviato, 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.

Route statiche

Puoi creare route statiche in due modi:

• Puoi creare route statiche manualmente utilizzando Console Google Cloud, gcloud compute routes create o il API routes.insert.

• Se utilizzi la console Google Cloud per creare un tunnel VPN classica che non utilizza il routing dinamico, Cloud VPN potrebbe creare automaticamente le route statiche corrispondenti. Per ulteriori informazioni, vedi Reti e tunnel Cloud VPN di routing.

Puoi scambiare route statiche con una rete VPC in peering come descritte in Opzioni per lo scambio di immagini statiche personalizzate route nel documentazione sul peering di rete VPC.

Parametri route

Le route statiche supportano i seguenti attributi:

• Nome e Descrizione. Questi campi identificano il percorso. Un nome è obbligatorio, mentre la descrizione è facoltativa. Ogni route nel progetto deve hanno un nome univoco.

• Rete. Ogni route deve essere associata esattamente a uno rete VPC.

• Hop successivo. L'hop successivo identifica la risorsa di rete a cui i pacchetti vengono inviati. Tutti i tipi di hop successivo supportano le destinazioni IPv4 e alcuni di questi supportano le destinazioni IPv6. Per ulteriori informazioni, vedi Hop e funzionalità.

• Intervallo di destinazione. L'intervallo di destinazione è un singolo CIDR IPv4 o IPv6 notazione

  Le destinazioni delle route statiche devono seguire le regole descritte in Interazioni con route statiche e Subnet e una route statica interazioni. La più ampia la possibile destinazione per una route statica IPv4 è 0.0.0.0/0. La più ampia la possibile destinazione per una route statica IPv6 è ::/0.

• Priorità. Numeri più bassi indicano priorità più alte. Il più alto la priorità possibile è 0, mentre la priorità più bassa possibile è 65,535.

• Tag di rete. Puoi fare in modo che una route statica venga applicata solo a una VM selezionata di istanze gestite nella rete VPC, identificate da una rete . Se non specifichi un tag di rete, Google Cloud applica la route statica a tutte le istanze nel in ogni rete. Le route statiche con tag non vengono mai scambiate quando si utilizza Peering di rete VPC.

Hop e funzionalità successivi

La tabella seguente riassume il supporto delle funzionalità di route statiche in base al tipo di hop successivo:

Progetto hop successivo e rete

Un hop successivo della route statica è associato sia a una rete VPC di un progetto:

• Rete: ad eccezione di quanto indicato nella tabella seguente, l'hop successivo La rete VPC deve corrispondere alla rete VPC della route.

• Progetto: ad eccezione di quanto indicato nella tabella seguente, l'hop successivo deve trovarsi nel progetto che contiene il VPC dell'hop successivo (un progetto autonomo o un progetto host del VPC condiviso). Ancora qualche possono trovarsi nei progetti di servizio del VPC condiviso.

Considerazioni comuni agli hop successivi del bilanciatore del carico di rete passthrough interno dell'istanza

Il routing basato su istanza si riferisce a una route statica con un hop successivo che è una VM (next-hop-instance o next-hop-address).

Il bilanciatore del carico di rete passthrough interno come hop successivo si riferisce a una route statica con un hop successivo un bilanciatore del carico di rete passthrough interno (next-hop-ilb).

Quando configuri il routing basato su istanze o un bilanciatore del carico di rete passthrough interno come hop successivo, tieni in considerazione le seguenti linee guida:

• Devi configurare le VM di backend o l'istanza dell'hop successivo per l'inoltro pacchetti da qualsiasi indirizzo IP di origine. Per configurare l'inoltro, attiva IP di inoltro (can-ip-forward) su una per VM quando crei la VM. Per le VM create automaticamente nell'ambito di un gruppo di istanze gestite, abilita l'IP forwarding nel modello di istanza utilizzata dal gruppo di istanze. Questa modifica alla configurazione deve essere apportata in oltre a qualsiasi configurazione del sistema operativo necessaria per l'instradamento dei pacchetti.

• Il software in esecuzione sulla VM di backend o sull'istanza dell'hop successivo deve essere configurate in modo appropriato. Ad esempio, VM di appliance di terze parti che agiscono i router o i firewall devono essere configurati in base alle instructions.

• Le VM di backend o l'istanza dell'hop successivo devono disporre di un firewall appropriato . Devi configurare le regole firewall che si applicano ai pacchetti che vengono vengono indirizzate correttamente. Tieni presente che:

  • Regole firewall in entrata applicabili alle istanze che eseguono il routing devono includere gli indirizzi IP delle origini dei pacchetti instradati. La una regola implicita di negazione del traffico in entrata blocca tutti i pacchetti in entrata, quindi devi e creare regole firewall di autorizzazione in entrata personalizzate.
  • Regole firewall in uscita applicabili alle istanze che eseguono il routing devono includere gli indirizzi IP delle destinazioni dei pacchetti instradati. La regola implicita di autorizzazione in uscita lo consente, a meno che tu non abbia creato una specifica e la regola di negazione in uscita per eseguirne l'override.
  • Considera se la VM di backend o l'istanza dell'hop successivo Eseguire Network Address Translation (NAT) durante la creazione del firewall le regole del caso.

  Per ulteriori informazioni, consulta Firewall implicito. .

• La regione di origine di un pacchetto inviato da una VM di backend o un'istanza di hop successivo è la regione in cui si trova la VM di backend o l'istanza dell'hop successivo. Per Ad esempio, i pacchetti elaborati dalle VM di backend o dalle istanze dell'hop successivo in us-west1 possono essere inviati a destinazioni accessibili solo in us-west1 anche se le la VM di backend o l'istanza dell'hop successivo ha ricevuto originariamente il pacchetto da una risorsa in una regione diversa da us-west1. Esempi di risorse che Le risorse accessibili solo nella stessa regione di una VM che invia un pacchetto includono:

  • bilanciatori del carico di rete passthrough interni, bilanciatori del carico delle applicazioni interni e Bilanciatori del carico di rete proxy interni regionali con accesso globale disattivato
  • Tunnel Cloud VPN, VLAN Cloud Interconnect e VM dell'appliance router di connettività di rete la rete VPC utilizza il routing dinamico a livello di regione

Considerazioni sulle istanze dell'hop successivo

• Hop successivo per nome istanza e zona (next-hop-instance): quando crea una route statica con un'istanza dell'hop successivo specificata dall'istanza nome e zona, Google Cloud richiede che un'istanza con quel nome esiste nella zona specificata e soddisfa quanto segue:

  • L'istanza si trova nello stesso progetto della route.
  • L'istanza ha un'interfaccia di rete (NIC) nella route Rete VPC (non rete VPC in peering).

  Finché è una route statica il cui hop successivo è specificato dal nome dell'istanza zona esistente, si applica quanto segue:

  • Google Cloud aggiorna automaticamente la programmazione per l'hop successivo uno dei seguenti casi:

  • l'indirizzo IPv4 interno principale dell'istanza dell'hop successivo cambia oppure

  • Sostituisci l'istanza dell'hop successivo e l'istanza sostitutiva ha nome, si trova nella stessa zona e nello stesso progetto e ha un'interfaccia di rete alla rete VPC della route.

  • Google Cloud non aggiorna la programmazione per l'hop successivo nella i seguenti casi:

  • Quando l'istanza viene eliminata

  • L'intervallo di indirizzi IPv6 assegnato alle modifiche al NIC dell'istanza

  • Quando l'assegnazione dell'indirizzo IPv4 o IPv6 dell'istanza è stata annullata

• IP istanza hop successivo (next-hop-address): quando crei una route statica con una di hop specificato da un indirizzo IP, puoi inserire uno dei seguenti valori:
  • L'indirizzo IPv4 interno principale dell'istanza.
  • Un indirizzo IPv6 interno o esterno proveniente dall'intervallo di indirizzi IPv6 /96 assegnato all'interfaccia di rete di un'istanza VM a doppio stack (anteprima). Se inserisci un indirizzo IPv6 interno, Google consiglia di utilizzare il primo indirizzo (/128) dell'intervallo di indirizzi IPv6 interni /96 del NIC.

  Google Cloud verifica che l'indirizzo IP della VM dell'hop successivo rientri in una di una subnet nella rete VPC della route. Tuttavia, Google Cloud programma la route solo se l'indirizzo dell'hop successivo è uno di le seguenti:

  • Un indirizzo IPv4 interno primario assegnato al NIC di una VM nella stessa rete VPC della route (non è un VPC in peering rete)
  • Un indirizzo IPv6 compreso nell'intervallo di indirizzi IPv6 /96 assegnato al NIC di un VM a doppio stack nella stessa rete VPC della route (non una rete VPC in peering)

  Google Cloud aggiorna automaticamente la programmazione per l'hop successivo quando viene spostato su un'altra VM, a condizione che la VM sostitutiva soddisfi gli stessi requisiti.

• Istanze dell'hop successivo nei progetti di servizio del VPC condiviso: quando specifica una VM dell'hop successivo in base all'indirizzo IP, la VM può trovarsi nella stesso progetto della route (un progetto autonomo o un host del VPC condiviso) progetto) oppure la VM può trovarsi in un progetto di servizio VPC condiviso. Se specifichi una VM dell'hop successivo in base al nome dell'istanza e alla zona, la VM dell'hop successivo deve trovarsi nello stesso progetto della route e del VPC (un progetto autonomo o un progetto host del VPC condiviso).

• Costi e latenza tra regione: quando utilizzi una VM come hop successivo, hop successivo si trova in una zona di una regione. La route che utilizza l'hop successivo è disponibile per tutte le istanze nella stessa rete VPC o e selezionare istanze con un tag di rete corrispondente. Google Cloud non considera la distanza regionale per le route che utilizzano un'istanza come hop successivo, è possibile creare una route che invia traffico a una VM dell'hop successivo regione diversa. L'invio di pacchetti da una regione all'altra aggiunge i dati in uscita i costi di trasferimento dei dati e introduce la latenza di rete.

• Nessun controllo di integrità, nessuna convalida della configurazione: Google Cloud non verifica mai se un'istanza dell'hop successivo soddisfa tutti i requisiti descritti in le considerazioni comuni all'istanza e al bilanciatore del carico di rete passthrough interno hop. Disabilita l'interfaccia di rete della VM tramite la configurazione del sistema operativo guest dell'istanza non causa di ignorare l'istanza dell'hop successivo.

• Nessun hashing simmetrico durante il collegamento di due reti VPC: Google Cloud non offre l'hashing simmetrico se ne vengono utilizzati due o più VM dell'hop successivo con più interfacce di rete in una configurazione soddisfa tutti i seguenti criteri:

  • Le VM hanno un'interfaccia di rete in una rete VPC a un'altra interfaccia in una seconda rete VPC.
  • In ogni rete VPC esiste un insieme di almeno due route statiche personalizzate per la stessa destinazione in cui ogni route nel set fa riferimento a una VM univoca dell'hop successivo.

  Se utilizzi due o più VM con più interfacce per connetterti reti VPC e hai bisogno che le stesse VM elaborino di pacchetti per una determinata connessione in entrambe le direzioni, è necessaria una simmetria , che è supportato solo dai bilanciatori del carico di rete passthrough interni con l'hop successivo. Per per maggiori dettagli sull'hashing simmetrico, consulta l'articolo sull'hashing simmetrico nei bilanciatori del carico di rete passthrough interni come hop successivi documentazione.

• Comportamento quando istanze vengono arrestate o eliminate: Google Cloud non impedisce all'arresto o all'eliminazione di una VM dell'hop successivo della route statica (specificata da nome e zona o indirizzo interno). Quando una VM dell'hop successivo non viene in esecuzione, il routing per la destinazione dipende dalla presenza o meno di altre route per la stessa destinazione esiste e se questi altri percorsi hanno hop in esecuzione. Per illustrare questo comportamento, considera quanto segue: esempi:
  • I pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono inviati al hop successivo di route-vm-b nella seguente situazione in cui l'hop successivo per la route con priorità massima non è in esecuzione. Questa procedura si verifica perché Google Cloud ignora gli hop successivi che non sono in esecuzione prima di considerare il passaggio Ignora le route a bassa priorità della ordine di routing:
  • route-vm-a, destinazione 192.168.168.0/24, priorità 10, VM hop successivo viene interrotto
  • route-vm-b, destinazione 192.168.168.0/24, priorità 20, VM hop successivo è in esecuzione

  • route-vm-c, destinazione 192.168.168.0/24, priorità 30, VM hop successivo è in esecuzione

  • I pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono eliminati in questo esempio successivo in cui tutte le VM dell'hop successivo per le route 192.168.168.0/24 vengono non è attiva, anche se un percorso per il 192.168.0.0/16 più ampio ha una della VM dell'hop successivo in esecuzione. I pacchetti vengono eliminati Google Cloud ignora le route con subnet più ampie (subnet mask più breve) length) nel passaggio destinazione più specifica, che avviene prima di ignorare le route statiche personalizzate i cui hop successivi non sono in esecuzione passaggio dell'ordine di routing:

  • route-vm-x, destinazione 192.168.168.0/24, priorità 10, VM hop successivo viene interrotto

  • route-vm-y, destinazione 192.168.168.0/24, priorità 20, VM hop successivo viene interrotto

  • route-vm-z, destinazione 192.168.0.0/16, priorità 0, VM dell'hop successivo corrente corsa

Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno

• Regole di forwarding supportate. Google Cloud supporta solo l'hop successivo le regole di forwarding del bilanciatore del carico di rete passthrough interno. Google Cloud non supporta regole di forwarding dell'hop utilizzate da altri bilanciatori del carico, forwarding del protocollo come endpoint Private Service Connect.

• Metodi di specifica e rete e progetto della regola di forwarding. Puoi specifica una regola di forwarding per l'hop successivo utilizzando uno dei tre metodi seguenti. Il metodo di specifica utilizzato determina se l'inoltro della regola deve corrispondere alla rete della route e in quale progetto La regola di forwarding può trovarsi:

  • Tramite il nome della regola di forwarding (--next-hop-ilb) e la regione (--next-hop-ilb-region): quando specifichi l'inoltro dell'hop successivo regola per nome e regione, la rete della regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding deve trovarsi nello stesso progetto che contiene (un progetto autonomo o un progetto host del VPC condiviso).

  • Tramite il link alle risorse della regola di forwarding: la risorsa della regola di forwarding utilizza il formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dove PROJECT_ID è il l'ID del progetto che contiene la regola di forwarding. REGION è la regione della regola di forwarding e FORWARDING_RULE_NAME è il nome della regola di forwarding. Quando specifichi una regola di forwarding per l'hop successivo tramite il relativo link della risorsa, la rete della regola di forwarding deve corrispondere al VPC della route in ogni rete. La regola di forwarding può trovarsi sia nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o progetto host del VPC condiviso) o di un servizio VPC condiviso progetto.

  • Tramite un indirizzo IPv4 di una regola di forwarding: quando specifichi un hop successivo dalla regola di forwarding tramite il relativo indirizzo IPv4, la rete può essere la rete VPC della route oppure una rete VPC in peering. È possibile trovare la regola di forwarding nel progetto che contiene la rete della regola di forwarding o (un progetto autonomo o un progetto host del VPC condiviso) oppure una Progetto di servizio VPC condiviso.

• Effetto dell'accesso globale. Route statiche personalizzate utilizzando il bilanciatore del carico di rete passthrough interno gli hop successivi sono programmati in tutte le regioni. Indica se l'hop successivo è utilizzabile dipende dalla dimensione globale del bilanciatore del carico di accesso. Con impostazioni globali abilitato, l'hop successivo del bilanciatore del carico è accessibile in tutte le regioni la rete VPC. Se l'accesso globale è disattivato, il carico l'hop successivo del bilanciatore è accessibile solo nella stessa regione del carico con il bilanciatore del carico di rete passthrough esterno regionale. Se l'accesso globale è disabilitato, i pacchetti inviati da un'altra regione che utilizza un hop successivo del bilanciatore del carico di rete passthrough interno.

• Quando tutti i backend sono in stato non integro. Quando tutti i backend di un il bilanciatore del carico di rete passthrough interno non supera i controlli di integrità, le route che utilizzano quel bilanciatore del carico hop successivo sono ancora attivi. I pacchetti elaborati dalla rotta vengono inviati a uno dei backend del bilanciatore del carico dell'hop successivo in base al traffico la distribuzione dei contenuti.

• Regole di forwarding che utilizzano un indirizzo IP interno comune (--purpose=SHARED_LOADBALANCER_VIP) non sono supportati. Hop successivo bilanciatori del carico di rete passthrough interni e regole di forwarding del bilanciatore del carico di rete passthrough interno con un IP comune indirizzo si escludono a vicenda. Un bilanciatore del carico di rete passthrough interno dell'hop successivo deve utilizzare un bilanciatore univoco per la regola di forwarding del bilanciatore del carico, in modo che viene fatto riferimento in modo inequivocabile a un solo servizio di backend (un bilanciatore del carico). È possibile che le regole di forwarding utilizzino un indirizzo IP interno comune fare riferimento a servizi di backend diversi (bilanciatori del carico di rete passthrough interni diversi).

• Più percorsi con le stesse destinazioni e priorità, ma diverse bilanciatori del carico di rete passthrough interni con l'hop successivo. Google Cloud non distribuisce mai il traffico tra due o più bilanciatori del carico di rete passthrough interni per l'hop successivo utilizzando ECMP. Invece, Google Cloud seleziona solo un bilanciatore del carico di rete passthrough interno dell'hop successivo utilizzando una un algoritmo interno deterministico. Per evitare questa ambiguità, puoi utilizzare tag di rete univoci per ogni route.

  

• Più route con destinazioni, priorità e hop successivo uguali bilanciatori del carico di rete passthrough interni. Senza un tag di rete, Google Cloud non consentono di creare più route statiche che hanno la stessa combinazione destinazione, priorità e bilanciatore del carico di rete passthrough interno. Con i tag di rete, creare più route statiche con la stessa combinazione di destinazione, della priorità e hop successivo del bilanciatore del carico di rete passthrough interno.

Considerazioni sugli hop successivi nei tunnel VPN classica

• Costi e latenza tra regione: Google Cloud non considera distanza regionale per le route che usano una VPN classica dell'hop successivo tunnel. Invio del traffico a un tunnel VPN classica dell'hop successivo in un'altra regione aggiunge costi di trasferimento di dati in uscita e introduce una latenza di pochi millisecondi. Come best practice, usa una VPN ad alta disponibilità tunnel con dinamico calcolo itinerario poiché la configurazione considera la distanza a livello di regione.

• Comportamento quando i tunnel VPN classica non sono in esecuzione: Personalizzato le route statiche i cui hop successivi sono tunnel VPN classica non automaticamente quando i tunnel della VPN classica non vengono in esecuzione. Per maggiori dettagli su cosa succede quando i tunnel non sono in esecuzione, consulta Quando i tunnel vengono abbassa nella documentazione della VPN classica.

Passaggi successivi

• Per creare e gestire le route, vedi Utilizzare le route.
• Per una panoramica delle reti VPC di Google Cloud, consulta reti VPC.
• Per creare, modificare o eliminare reti VPC, consulta Creare e modificare per gestire le reti VPC.