Route

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

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

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

Routing in Google Cloud

Ogni rete VPC usa un meccanismo di routing virtuale scalabile e distribuito. Nessun dispositivo fisico assegnato alla rete. Alcune route possono essere applicate 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 mantenuto informato di tutte le route applicabili 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 una route, l'insieme di modifiche viene propagato ai controller VM utilizzando una progettazione a coerenza finale.

Tipi di route

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

Tipo e destinazione Hop successivo Notes
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
Creata automaticamente per ogni intervallo di indirizzi IP della subnet 		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 delle 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 maggiori dettagli su ogni hop successivo della route statica, consulta le considerazioni relative a:
Route dinamica
Destinazioni che non sono in conflitto con route di subnet o route statiche		 Peer di una sessione BGP su un router Cloud Le route vengono aggiunte e rimosse automaticamente in base alle route apprese dai router Cloud nella tua rete VPC.

Le route si applicano alle VM in base alla modalità di routing dinamico della rete VPC.
Route di peering di rete VPC
Route subnet di peering
Rappresenta un intervallo di indirizzi IP di subnet in un'altra rete VPC connessa tramite peering di rete VPC 		Hop successivo nella rete VPC peer

Il peering di rete VPC offre opzioni per 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'intera rete VPC.
Route statiche e dinamiche di peering
Route statiche o dinamiche in un'altra rete VPC connessa tramite peering di rete VPC 		Hop successivo nella rete VPC peer

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

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

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

Le route dinamiche di peering 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 (una diversa rete VPC connessa all'hub di Network Connectivity Center) 		Hub Network Connectivity Center

Gli amministratori dello spoke di Network Connectivity Center possono escludere l'esportazione di 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'intera rete VPC.
Route basate su criteri
Route basate su criteri
Le route basate su criteri possono essere applicate ai pacchetti in base a indirizzo IP di origine, indirizzo IP di destinazione, protocollo o una combinazione di questi.

Le route basate su criteri vengono valutate prima di valutare altre route. Le route basate su criteri possono essere applicate a tutte le VM nella rete, a determinate VM selezionate in base al tag di rete o al traffico che entra nella rete VPC tramite collegamenti VLAN di Cloud Interconnect da te specificati.

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

Route predefinite generate dal sistema

Quando crei una rete VPC, include una route predefinita IPv4 generata dal sistema (0.0.0.0/0). Quando crei una subnet a doppio stack con un intervallo di indirizzi IPv6 esterno in una rete VPC, viene aggiunta alla rete una route predefinita IPv6 generata dal sistema (::/0), se la route non esiste già. Le route predefinite hanno i seguenti scopi:

Google Cloud utilizza solo una route predefinita se una route con una destinazione più specifica non si applica a un pacchetto. Per informazioni su come vengono utilizzate la specificità della destinazione e la priorità della route per selezionare una route, consulta la sezione Ordine di routing.

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

  • Solo IPv4: se vuoi instradare il traffico internet a un hop successivo diverso, puoi sostituire la route predefinita con una route statica o dinamica personalizzata. Ad esempio, potresti sostituirlo 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 che non sono coperti da altre route vengono eliminati.

Route subnet

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

Ogni subnet ha almeno una route di subnet la cui destinazione corrisponde all'intervallo IPv4 principale della subnet. Se la subnet ha intervalli IP secondari, esiste una route della subnet corrispondente a ciascuno dei suoi intervalli di indirizzi IP secondari. Se la subnet ha un intervallo IPv6, esiste una route della subnet corrispondente per l'intervallo di indirizzi IPv6. Per ulteriori informazioni sugli intervalli IP di subnet, consulta Subnet.

Le route subnet hanno sempre le destinazioni più specifiche. Non possono essere ignorate da altre route, anche se un'altra ha una priorità più alta. Questo perché Google Cloud considera la specificità della destinazione prima della priorità quando seleziona una route. Google Cloud utilizza 0 come priorità per tutte le route subnet.

Interazioni con route statiche

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

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

    • Se esiste una route subnet locale o una route subnet di peering per la destinazione 10.70.1.0/24, 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 altra destinazione che rientri in 10.70.1.0/24.

    • Se esiste una route subnet locale o una route subnet di peering per la destinazione 2001:0db8:0a0b:0c0d::/64, non puoi creare una nuova route statica personalizzata per 2001:0db8:0a0b:0c0d::/64 o qualsiasi destinazione che rientra in 2001:0db8:0a0b:0c0d::/64, come 2001:0db8:0a0b:0c0d::/96.

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

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

    • Se la tua rete VPC ha una route statica personalizzata per la destinazione 2001:0db8:0a0b:0c0d::/96, Google Cloud vieta la creazione di qualsiasi route di subnet a doppio stack o di subnet di peering che abbia un intervallo di indirizzi IPv6 di 2001:0db8:0a0b:0c0d::/64 o qualsiasi altro intervallo contenente 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 alla destinazione di una route di subnet o di subnet di peering esistente, Google Cloud non crea alcuna route dinamica personalizzata per il prefisso in conflitto. Ad esempio, quando esiste una subnet o una route subnet di peering con destinazione 10.70.1.0/24, se i router Cloud nella rete VPC ricevono il prefisso 10.70.1.0/24 tramite BGP, Google Cloud utilizza la route della subnet o della subnet di peering e non crea alcuna route dinamica personalizzata per 10.70.1.0/24.

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

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

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

Ciclo di vita delle route di subnet

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

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

  • Le reti VPC in modalità automatica creano una route di subnet per gli intervalli IP principali di ciascuna delle subnet create automaticamente. Puoi eliminare queste subnet solo se converti la rete VPC dalla modalità automatica 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 per l'intervallo secondario viene eliminata automaticamente.

    • Quando elimini una subnet, tutte le route delle subnet per gli intervalli principali e secondari vengono eliminate automaticamente. Non puoi eliminare in altro modo la route della subnet per l'intervallo principale della subnet.

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

Route dinamiche

I router Cloud indicano alla rete VPC di creare, aggiornare e rimuovere le route dinamiche basate sui messaggi BGP (Border Gateway Protocol) ricevuti, i criteri di route BGP applicabili (anteprima) e le route apprese personalizzate del router Cloud che configuri. Il piano di controllo del router Cloud installa le 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 di ogni regione creano route dinamiche solo nella stessa regione del router Cloud.

  • Se una rete VPC utilizza la modalità di routing dinamico globale, i router Cloud di 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 alla rete VPC di rimuovere la route dinamica dopo che si verifica una delle seguenti condizioni:

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

Route delle subnet di peering

Le route delle subnet di peering definiscono i percorsi alle risorse nelle subnet in un'altra rete VPC connesse tramite il peering di rete VPC. Per ulteriori informazioni, consulta Opzioni per lo scambio di route di subnet.

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

Il numero di route subnet per gruppo di peering è controllato dagli intervalli di subnet per rete 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 nell'altra. Per ulteriori informazioni, consulta:

Il numero di route statiche per gruppo di peering e 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 ha un insieme di route applicabili, che sono un sottoinsieme di tutte le route nella rete VPC. Le route applicabili sono i possibili percorsi in uscita che un pacchetto può seguire.

  • Per il routing di ritorno a bilanciatori del carico proxy, sistemi di controllo di integrità e altri servizi Google, si applicano percorsi di routing speciali. Per ulteriori informazioni, vedi percorsi di routing speciali. Queste route non vengono mostrate in nessuna tabella delle route.

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

  • Le route di subnet locali e di peering si applicano a tutte le istanze. Ad eccezione delle route basate su criteri, nessun altro tipo di route può avere una destinazione che corrisponda o rientri all'interno della destinazione di una route di subnet locale o di peering. Per ulteriori dettagli sulla risoluzione dei conflitti tra route di subnet, statiche e dinamiche, consulta Interazioni di subnet e route statiche e Interazioni di 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 di tag si applicano alle istanze che hanno lo stesso tag di rete. Se la route non ha un tag di rete, si applica a tutte le istanze nella rete.

  • Le route dinamiche si applicano alle istanze in base alla modalità di routing dinamico della rete VPC.

Percorsi di routing speciali

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

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

I bilanciatori del carico di rete passthrough esterni e il forwarding del protocollo esterno utilizzano i sistemi Maglev per instradare i pacchetti dai client su internet alle VM di backend e alle istanze di destinazione nella tua rete VPC. Questi sistemi Maglev instradano pacchetti con destinazioni corrispondenti a quella della regola di forwarding 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 per le rispettive VM di backend o istanze di destinazione per inviare pacchetti a destinazioni al di fuori della rete VPC:

  • I pacchetti inviati dalle VM di backend o dalle istanze di destinazione possono essere pacchetti di risposta in uscita (inviati di nuovo al client) o pacchetti in uscita che avviano una nuova connessione.
  • Le origini pacchetto devono corrispondere all'indirizzo IP della regola di forwarding. Il protocollo dei pacchetti e la porta di origine non devono corrispondere al protocollo e alle specifiche della porta della regola di forwarding.
  • I percorsi di routing delle regole di forwarding non dipendono da una route predefinita o dall'uso dell'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

I 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 dalle seguenti origini:

  • 35.191.0.0/16
  • 130.211.0.0/22

Google Cloud utilizza le route nella rete Google per consegnare i pacchetti da questi intervalli di origine alle VM di backend nella tua 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 tue VM di backend dagli intervalli di indirizzi IP dei probe del controllo di integrità.

Google Cloud utilizza le route nella rete di Google per consegnare i pacchetti dai sistemi di probe del controllo di integrità alle VM nella tua rete VPC. Ogni rete VPC include percorsi di routing che consentono alle VM di 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 che si trovano interamente all'interno della rete di Google. Google non pubblica le route per 35.235.240.0/20 su internet.

Le route nella rete di Google consegnano pacchetti da 35.235.240.0/20 alle VM nella tua rete VPC quando utilizzi 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 utilizzano 35.199.192.0/19 come intervallo solo interno con hop successivi interamente all'interno della rete di Google. Google non pubblica le route per 35.199.192.0/19 su internet.

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

Percorsi per l'accesso VPC serverless

L'accesso VPC serverless utilizza 35.199.224.0/19 come intervallo solo interno con hop successivi che si trovano interamente all'interno della rete di Google. Google non pubblica le route per 35.199.224.0/19 su internet.

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

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

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

Ordine di routing

Il seguente processo modella il comportamento di selezione delle route di 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 visualizzati nella tabella di route di rete VPC. Per i dettagli, vedi Percorsi di routing speciali.

    Se è applicabile un percorso di routing speciale, il modello di selezione delle route 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 per percorsi di routing speciali, ma prima di altri tipi di route. Se nella rete VPC non esistono route basate su criteri, Google Cloud salta questo passaggio e va a quello 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 per ogni route basata su criteri, a partire da quella o da una route basata su criteri con priorità più alta. Se le caratteristiche di un pacchetto non corrispondono a una route basata su criteri, Google Cloud ignora la route basata su criteri e continua a valutare la successiva route basata su criteri nell'elenco ordinato. La successiva route basata su criteri da valutare potrebbe condividere la stessa priorità della route basata su criteri disconosciuta oppure 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 al passaggio della destinazione più specifica.

    • Se le caratteristiche di un pacchetto corrispondono a una route basata su criteri con priorità più alta, Google Cloud ignora prima tutte le route basate su criteri a priorità inferiore. Se nell'elenco rimangono due o più route basate su criteri, Google Cloud valuta ognuna delle restanti route basate su criteri che hanno priorità identiche. Google Cloud ignora eventuali route basate su criteri rimanenti se le caratteristiche di un pacchetto non corrispondono. Dopo questo passaggio, il modello di selezione delle route potrebbe contenere una o più route basate su criteri.

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

    • Se il modello di selezione delle route include solo una singola route basata su criteri con priorità più alta configurata per saltare altre route basate su criteri, Google Cloud valuta le route non basate su criteri nel passaggio della destinazione più specifica e ignora tutte le route basate su criteri.

    • Se il modello di selezione delle route include solo una singola route basata su criteri con priorità massima che non è configurata per saltare altre route basate su criteri, Google Cloud consegna il pacchetto al bilanciatore del carico di rete passthrough interno dell'hop successivo e ignora tutte le route non basate su criteri.

  1. Destinazione più specifica:Google Cloud determina quale delle route applicabili ha la destinazione più specifica contenente l'indirizzo IP di destinazione del pacchetto. Google Cloud ignora tutte le altre route con destinazioni meno specifiche. Ad esempio, 10.240.1.0/24 è una destinazione più specifica di 10.240.0.0/16. La destinazione più specifica potrebbe essere qualsiasi tipo di route; tuttavia, le route subnet, le route di subnet di peering e i percorsi di routing speciali sono quelli più specifici per definizione.

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

  2. Hop successivi in una singola rete VPC: questo passaggio è applicabile solo se la rete VPC di cui si sta modellando il comportamento delle route è connessa a una o più reti VPC utilizzando il peering di rete VPC. Con il peering di rete VPC, le route personalizzate con destinazioni identiche potrebbero esistere in più di una delle reti nel gruppo di peering. Il requisito modellato in questo passaggio è che Google Cloud selezioni gli hop successivi che sono tutti in un'unica rete VPC.

    • Se una o più route nel tuo modello di route contengono hop successivi all'interno della rete VPC che stai modellando, ignora tutte le route che hanno hop successivi nelle reti peer. In questo caso, 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 include 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à della route non viene considerata in questo momento. Inoltre, se la tua rete VPC fa 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 queste route si trovano tutti in un'unica rete VPC.

  3. Ignora le route statiche personalizzate i cui hop successivi non sono in esecuzione: questo passaggio modella due situazioni in cui Google Cloud ignora gli hop successivi che considera non in esecuzione. Questo passaggio si applica solo alle route statiche personalizzate. le route dinamiche personalizzate vengono aggiunte e rimosse automaticamente usando 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 arrestata o eliminata. Per ulteriori dettagli, consulta Comportamento quando le istanze vengono arrestate o eliminate nella sezione Considerazioni sulle istanze dell'hop successivo. 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 tunnel VPN classica dell'hop successivo se il tunnel non ha un'associazione di sicurezza IKE (Fase 1). Per ulteriori dettagli, consulta la sezione Ordine delle route nella documentazione della VPN classica. Se il modello di route contiene route statiche i cui hop successivi sono tunnel VPN classica senza SA IKE stabilite, rimuovi queste route dal modello.

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

    Dopo questo passaggio, il modello di selezione delle route potrebbe essere vuoto o contenere una o più route. Se il tuo modello contiene route, tutte avranno tutte le seguenti caratteristiche:

    • Destinazioni identiche e più specifiche
    • Hop successivi in una rete VPC: la rete VPC locale o una singola rete VPC
    • 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 questo comportamento considerando il sistema di categorie di preferenze descritto nella tabella seguente. Questo passaggio perfeziona il modello di route in modo che contenga solo route dello stesso tipo o combinazione di tipo di route e tipo di 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) o un tunnel VPN classica di hop successivo stabilito IKE SA
    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
    Google Cloud utilizza un algoritmo interno per selezionare un singolo bilanciatore del carico di rete passthrough interno per l'hop successivo, ignorando gli altri hop successivi del bilanciatore del carico di rete passthrough interno con la stessa priorità. Per maggiori dettagli, consulta "Bilanciatori del carico di rete passthrough interni per la stessa destinazione e più hop successivo" nella sezione Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno.
    Quarta scelta Una route statica personalizzata che utilizza l'hop successivo default-internet-gateway

    Al termine di questo passaggio, il modello di route potrebbe contenere zero route, una o due o più route.

  6. Invia o elimina pacchetto: ciò che accade dipende dal numero di route restanti nel modello di route:

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

    • Se il modello di route contiene una singola route, Google Cloud invia il pacchetto all'hop successivo. Per gli hop successivi della VM, Google Cloud non convalida che l'hop successivo della VM possa elaborare i pacchetti. Per maggiori dettagli, consulta Considerazioni comuni agli hop successivi del bilanciatore del carico di rete passthrough interno delle istanze e degli hop successivi. Se la route singola è una route subnet o una route subnet di peering e non sono presenti risorse Google Cloud all'indirizzo IP di destinazione del pacchetto, il pacchetto viene eliminato.

    • Se il modello di route contiene due o più route, condividono la stessa destinazione più specifica, si trovano in una singola rete VPC, hanno hop successivi che non sono noti essere inattivi, hanno la stessa priorità massima e appartengono a un tipo di route e a una combinazione di hop successiva (categoria di preferenza). Google Cloud distribuisce i pacchetti tra gli hop successivi implementando il modello ECMP (equal-cost multipath) utilizzando un algoritmo di hashing. I calcoli degli hash vengono eseguiti per ogni pacchetto nel momento in cui viene inviato, in base al numero attuale di hop successivi. Google Cloud utilizza un hash a cinque tuple se il pacchetto contiene informazioni sulla porta; in caso contrario, utilizza un hash a tre tuple. Se il modello di route cambia con l'invio di pacchetti successivi, Google Cloud potrebbe indirizzare questi pacchetti a un hop successivo diverso anche se l'hash è lo stesso.

Route statiche

Puoi creare route statiche in due modi:

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

Parametri route

Le route statiche supportano i seguenti attributi:

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

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

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

  • Intervallo di destinazione. L'intervallo di destinazione è una singola notazione CIDR IPv4 o IPv6

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

  • Priorità. Numeri più bassi indicano priorità più alte. La priorità più alta 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 determinate istanze VM nella rete VPC, identificate da un tag di rete. Se non specifichi un tag di rete, Google Cloud applica la route statica a tutte le istanze nella rete. Le route statiche con tag non vengono mai scambiate quando si utilizza il 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:

Tipo di hop successivo IPv4 IPv6 ECMP1
Gateway dell'hop successivo (next-hop-gateway)
Specifica un gateway internet predefinito per definire un percorso per gli indirizzi IP esterni.
Istanza hop successivo per nome e zona (next-hop-instance)
Invia i pacchetti a una VM dell'hop successivo identificata dal nome e dalla zona e che si trova nello stesso progetto della route. Per ulteriori informazioni, consulta Considerazioni sulle istanze dell'hop successivo.
Istanza hop successivo per indirizzo (next-hop-address)
Invia pacchetti a una VM dell'hop successivo identificata dall'indirizzo IPv4 interno principale, o da un indirizzo IPv6 interno o esterno, della sua interfaccia di rete. Per ulteriori informazioni, vedi Considerazioni per le istanze dell'hop successivo.		 (anteprima)
Hop successivo del bilanciatore del carico di rete passthrough interno mediante il nome e la regione della regola di forwarding (next-hop-ilb)
Invia i pacchetti ai backend di un bilanciatore del carico di rete passthrough interno identificato dal nome e dalla regione della regola di forwarding. Per maggiori informazioni, consulta Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno.
Bilanciatore del carico di rete passthrough interno con hop successivo per indirizzo (next-hop-ilb)
Invia pacchetti ai backend di un bilanciatore del carico di rete passthrough interno identificato dall'indirizzo IP della regola di forwarding del bilanciatore del carico. Per maggiori informazioni, consulta Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno.
Tunnel VPN classica dell'hop successivo (next-hop-vpn-tunnel)
Invia i pacchetti a un tunnel della VPN classica dell'hop successivo utilizzando il routing basato su criteri o una VPN basata su route. Per maggiori informazioni, consulta Considerazioni sugli hop successivi del tunnel VPN classico.
1ECMP (Equal-cost multipath) significa che due o più route statiche possono condividere lo stesso intervallo di destinazione e la stessa priorità. Anche se è possibile creare due o più route statiche in una rete VPC con la stessa destinazione, la stessa priorità e l'hop successivo del gateway internet predefinito, l'effetto è lo stesso di avere una singola route statica che utilizza l'hop successivo del gateway internet predefinito per quella destinazione e priorità.

Progetto hop successivo e rete

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

  • Rete: ad eccezione di quanto indicato nella tabella seguente, la rete VPC dell'hop successivo 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 la rete VPC dell'hop successivo (un progetto autonomo o un progetto host del VPC condiviso). Alcuni hop successivi possono trovarsi nei progetti di servizio del VPC condiviso.

Tipo di hop successivo Può trovarsi in una rete VPC in peering Può trovarsi in un progetto di servizio del VPC condiviso
Gateway dell'hop successivo (next-hop-gateway)
Istanza dell'hop successivo per nome (next-hop-instance)
Istanza dell'hop successivo in base all'indirizzo (next-hop-address)
Hop successivo del bilanciatore del carico di rete passthrough interno mediante il nome e la regione della regola di forwarding (next-hop-ilb)
Bilanciatore del carico di rete passthrough interno con hop successivo in base all'indirizzo (next-hop-ilb)
Tunnel VPN classica dell'hop successivo (next-hop-vpn-tunnel)

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 è un'istanza 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 che è 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 presente le seguenti linee guida:

  • Devi configurare le VM di backend o l'istanza dell'hop successivo per inoltrare i pacchetti da qualsiasi indirizzo IP di origine. Per configurare il forwarding, abilita l'inoltro IP (can-ip-forward) in base alla VM quando crei la VM. Per le VM create automaticamente come parte di un gruppo di istanze gestite, abilita l'IP forwarding nel modello di istanza utilizzato dal gruppo di istanze. Questa modifica alla configurazione deve essere apportata 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 configurato in modo appropriato. Ad esempio, le VM di appliance di terze parti che fungono da router o firewall devono essere configurate in base alle istruzioni del produttore.

  • Le VM di backend o l'istanza dell'hop successivo devono avere regole firewall appropriate. Devi configurare le regole firewall che si applicano ai pacchetti instradati. Tieni presente che:

    • Le regole firewall in entrata applicabili alle istanze che eseguono funzioni di routing devono includere gli indirizzi IP delle origini dei pacchetti instradati. La regola di negazione in entrata implicita blocca tutti i pacchetti in entrata, quindi devi almeno creare regole firewall di autorizzazione in entrata personalizzate.
    • Le regole firewall in uscita applicabili alle istanze che eseguono funzioni di 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 regola di negazione in uscita per sostituirla.
    • Quando crei le regole firewall, considera se la VM di backend o l'istanza dell'hop successivo sta eseguendo la Network Address Translation (NAT).

    Per maggiori informazioni, consulta Regole firewall implicite.

  • La regione di origine di un pacchetto inviato da una VM di backend o da un'istanza dell'hop successivo è la regione in cui si trova la VM di backend o l'istanza dell'hop successivo. 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 la VM di backend o l'istanza dell'hop successivo hanno originariamente ricevuto il pacchetto da una risorsa in una regione diversa da us-west1. Ecco alcuni esempi di risorse accessibili solo nella stessa regione di una VM che invia un pacchetto:

    • 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, allegati VLAN Cloud Interconnect e VM dell'appliance router connettività di rete se la rete VPC utilizza il routing dinamico

Considerazioni sulle istanze dell'hop successivo

  • Hop successivo per nome istanza e zona (next-hop-instance): quando crei una route statica con un'istanza di hop successivo specificata dal nome e dalla zona dell'istanza, Google Cloud richiede che un'istanza con questo nome esista nella zona specificata e soddisfi i requisiti seguenti:

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

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

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

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

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

    • Google Cloud non aggiorna la programmazione per l'hop successivo nei 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

  • Indirizzo IP dell'istanza dell'hop successivo (next-hop-address): quando crei una route statica con un'istanza dell'hop successivo specificata 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 un intervallo di subnet di una subnet nella rete VPC della route. Tuttavia, Google Cloud programma la route solo se l'indirizzo dell'hop successivo è uno dei seguenti:

    • Un indirizzo IPv4 interno primario assegnato al NIC di una VM nella stessa rete VPC della route (non una rete VPC in peering)
    • Un indirizzo IPv6 nell'intervallo di indirizzi IPv6 /96 assegnato al NIC di una 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 l'indirizzo IP dell'hop successivo 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 specifichi una VM dell'hop successivo in base all'indirizzo IP, la VM può trovarsi o nello stesso progetto della route (un progetto autonomo o un progetto host del VPC condiviso) oppure la VM può trovarsi in un progetto di servizio del VPC condiviso. Quando specifichi una VM dell'hop successivo per nome e zona dell'istanza, la VM dell'hop successivo deve trovarsi nello stesso progetto della route e della rete VPC (un progetto autonomo o un progetto host del VPC condiviso).

  • Costi e latenza tra regione: quando utilizzi una VM come hop successivo, l'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 per selezionare le istanze con un tag di rete corrispondente. Google Cloud non considera la distanza regionale per le route che utilizzano un'istanza come hop successivo, quindi è possibile creare una route che invia il traffico a una VM dell'hop successivo in una regione diversa. L'invio di pacchetti da una regione all'altra aggiunge costi di trasferimento di dati in uscita e introduce 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 nella sezione Considerazioni comuni agli hop successivi dell'istanza e del bilanciatore del carico di rete passthrough interno. La disabilitazione dell'interfaccia di rete della VM configurando il sistema operativo guest dell'istanza non fa sì che Google Cloud ignori l'istanza dell'hop successivo.

  • Nessun hashing simmetrico durante la connessione di due reti VPC: Google Cloud non offre l'hashing simmetrico quando si utilizzano due o più VM dell'hop successivo con più interfacce di rete in una configurazione che soddisfa tutti i seguenti criteri:

    • Le VM hanno un'interfaccia in una rete VPC e 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, con la stessa priorità, 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 connettere le reti VPC e richiedi che la stessa VM elabori pacchetti per una determinata connessione in entrambe le direzioni, hai bisogno dell'hashing simmetrico, supportato solo dai bilanciatori del carico di rete passthrough interni dell'hop successivo. Per maggiori dettagli sull'hashing simmetrico, consulta la documentazione sull'hashing simmetrico nei bilanciatori del carico di rete passthrough interni come hop successivi.

  • Comportamento in caso di arresto o eliminazione delle istanze:Google Cloud non ti impedisce di arrestare o eliminare una VM dell'hop successivo di una route statica (specificata da nome e zona o indirizzo interno). Quando una VM dell'hop successivo non è in esecuzione, il routing per la destinazione dipende dalla presenza o meno di altre route per la stessa esatta destinazione e dalla presenza di hop successivi in esecuzione. Per illustrare questo comportamento, considera gli esempi seguenti:

    • I pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono inviati all'hop successivo di route-vm-b nella seguente situazione in cui l'hop successivo per la route con priorità più alta non è in esecuzione. Questo routing si verifica perché Google Cloud ignora gli hop successivi non in esecuzione prima di considerare il passaggio Ignora le route a bassa priorità dell'ordine di routing:
    • route-vm-a, destinazione 192.168.168.0/24, priorità 10, VM dell'hop successivo arresto
    • route-vm-b, destinazione 192.168.168.0/24, priorità 20, VM dell'hop successivo in esecuzione

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

    • I pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono eliminati in questo prossimo esempio in cui tutte le VM dell'hop successivo per le route 192.168.168.0/24 non sono in esecuzione, anche se una route per l'elemento 192.168.0.0/16 più ampio ha una VM dell'hop successivo in esecuzione. I pacchetti vengono eliminati perché Google Cloud ignora le route con intervalli di destinazione più ampi (lunghezza della subnet mask più breve) nel passaggio della destinazione più specifica, che si verifica prima del passaggio Ignora le route statiche personalizzate i cui hop successivi non sono in esecuzione dell'ordine di routing:

    • route-vm-x, destinazione 192.168.168.0/24, priorità 10, VM dell'hop successivo arresto

    • route-vm-y, destinazione 192.168.168.0/24, priorità 20, VM dell'hop successivo arresto

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

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

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

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

    • In base al nome della regola di forwarding (--next-hop-ilb) e alla regione (--next-hop-ilb-region): quando specifichi una regola di forwarding dell'hop successivo 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 la rete della regola di forwarding (un progetto autonomo o un progetto host del VPC condiviso).

    • Tramite il link alle risorse della regola di forwarding: il link alle risorse di una regola di forwarding utilizza il formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dove PROJECT_ID è 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. Quando specifichi una regola di forwarding dell'hop successivo tramite il relativo link delle risorse, la rete della regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding può trovarsi o nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host del VPC condiviso) o in un progetto di servizio del VPC condiviso.

    • Tramite un indirizzo IPv4 della regola di forwarding: quando specifichi una regola di inoltro dell'hop successivo tramite il relativo indirizzo IPv4, la rete della regola di forwarding può essere la rete VPC della route o una rete VPC in peering. La regola di forwarding può trovarsi nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host del VPC condiviso) o in un progetto di servizio del VPC condiviso.

  • Effetto dell'accesso globale. Le route statiche personalizzate che utilizzano gli hop successivi del bilanciatore del carico di rete passthrough interno sono programmate in tutte le regioni. La possibilità di utilizzare l'hop successivo dipende dall'impostazione di accesso globale del bilanciatore del carico. Con l'accesso globale abilitato, l'hop successivo del bilanciatore del carico è accessibile in tutte le regioni della rete VPC. Se l'accesso globale è disabilitato, l'hop successivo del bilanciatore del carico è accessibile solo nella stessa regione del bilanciatore del carico. Se l'accesso globale è disabilitato, i pacchetti inviati da un'altra regione a una route utilizzando l'hop successivo del bilanciatore del carico di rete passthrough interno vengono eliminati.

  • Quando tutti i backend sono in stato non integro. Quando tutti i backend di un bilanciatore del carico di rete passthrough interno non superano i controlli di integrità, le route che utilizzano l'hop successivo del bilanciatore del carico sono ancora attive. I pacchetti elaborati dalla route vengono inviati a uno dei backend del bilanciatore del carico dell'hop successivo in base alla distribuzione del traffico.

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

  • Più route con le stesse destinazioni e priorità, ma diversi bilanciatori del carico di rete passthrough interni per 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. Google Cloud seleziona invece solo un bilanciatore del carico di rete passthrough interno dell'hop successivo utilizzando un algoritmo interno deterministico. Per evitare questa ambiguità, puoi utilizzare tag di rete univoci per ogni route.

    Google Cloud seleziona un singolo hop successivo quando le route statiche con diversi hop successivi del bilanciatore del carico di rete passthrough interno hanno la stessa priorità e destinazione.

  • Più route con le stesse destinazioni, priorità e bilanciatori del carico di rete passthrough interni per l'hop successivo. Senza un tag di rete, Google Cloud non consente di creare più route statiche con la stessa combinazione di destinazione, priorità e hop successivo del bilanciatore del carico di rete passthrough interno. Con i tag di rete, puoi creare più route statiche con la stessa combinazione di destinazione, 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 prende in considerazione la distanza regionale per le route che utilizzano un tunnel della VPN classica dell'hop successivo. L'invio del traffico a un tunnel VPN classica di un hop successivo in un'altra regione aggiunge costi di trasferimento di dati in uscita e introduce latenza di rete. Come best practice, utilizza invece un tunnel VPN ad alta disponibilità con routing dinamico, perché questa configurazione considera la distanza regionale.

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

Passaggi successivi