Route

Le route 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 VPC (Virtual Private Cloud) di Google Cloud (ad esempio in un'altra VM) o all'esterno.

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 lo consegna all'hop successivo della route se l'indirizzo di destinazione del pacchetto rientra nell'intervallo di destinazione della route.

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

Routing in Google Cloud

Ogni rete VPC usa un meccanismo di routing virtuale scalabile e distribuito. Non esiste un 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 informato su tutte le route applicabili dalla tabella di routing della rete. Ogni pacchetto che lascia 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 alla fine coerente.

Tipi di route

Le seguenti tabelle riepilogano in che modo 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 rimossa o sostituita
Route della subnet
Creata automaticamente per ogni intervallo di indirizzi IP delle 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 di subnet locali si applicano all'intera rete VPC.
Route personalizzate
Route statica
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 per:
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 di subnet di peering
Rappresenta un intervallo di indirizzi IP di subnet in una rete VPC diversa connessa tramite peering di rete VPC 		Hop successivo nella rete VPC peer

Il peering di rete VPC fornisce 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 di subnet di peering importate si applicano all'intera rete VPC.
Peering di route statiche e dinamiche
Route statiche o dinamiche in una rete VPC diversa connessa tramite peering di rete VPC 		Hop successivo nella rete VPC peer

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

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

Il peering di rete VPC fornisce 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 rete VPC diversa connessa all'hub di Network Connectivity Center) 		Hub Network Connectivity Center

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

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

Le route di subnet di Network Connectivity Center importate si applicano all'intera rete VPC.
Route basate su criteri
Route basate su criteri
Le route basate su criteri possono essere applicate ai pacchetti in base all'indirizzo IP di origine, all'indirizzo IP di destinazione, al protocollo o a una combinazione di questi.

Le route basate su criteri vengono valutate prima di 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 i collegamenti VLAN di Cloud Interconnect da te specificati.

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

Route predefinite generate dal sistema

Quando crei una rete VPC, questa include una route predefinita IPv4 generata dal sistema (0.0.0.0/0). Quando crei una sottorete a doppio stack con un intervallo di indirizzi IPv6 esterno in una rete VPC, viene aggiunta alla rete una route predefinita IPv6 (::/0) generata dal sistema, se non esiste già. Le route predefinite hanno questi 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 la specificità della destinazione e la priorità delle route vengono utilizzate per selezionare una route, consulta Ordine di routing.

Se vuoi isolare completamente la rete da internet o se devi sostituire la route predefinita con una 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 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 eliminati.

Route di subnet

Le route di subnet definiscono i percorsi delle risorse, ad esempio 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 di subnet corrispondente per ciascuno degli intervalli di indirizzi IP secondari. Se la subnet include un intervallo IPv6, esiste una route di subnet corrispondente per l'intervallo di indirizzi IPv6. Per ulteriori informazioni sugli intervalli IP di subnet, consulta Subnet.

Le route di subnet hanno sempre le destinazioni più specifiche. Non possono essere sostituite da altre route, anche se un'altra route 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 di subnet.

Interazioni con route statiche

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

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

    • Se esiste una route di subnet locale o di una 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 rientra in 10.70.1.0/24.

    • Se esiste una route di subnet locale o di una 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, ad esempio 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 a 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 impedisce la creazione di qualsiasi route di subnet o route di subnet di peering con un intervallo di indirizzi IPv4 della subnet principale o secondaria di 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 impedisce la creazione di qualsiasi route di subnet a doppio stack o di subnet di peering con un intervallo di indirizzi IPv6 di 2001:0db8:0a0b:0c0d::/64 o qualsiasi altro intervallo che contenga tutti gli indirizzi IPv6 in 2001:0db8:0a0b:0c0d::/96.

Interazioni con le 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 rilevano un prefisso che corrisponde esattamente alla destinazione di una route esistente o di una subnet di peering, Google Cloud non crea alcuna route dinamica personalizzata per il prefisso in conflitto. Ad esempio, quando esiste una route di subnet di peering o di subnet 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 subnet della subnet di peering e non crea alcuna route dinamica personalizzata per 10.70.1.0/24.

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

  • Quando i router Cloud apprendono i prefissi che si adattano all'interno della destinazione di una subnet o di una route di subnet di peering esistente, Google Cloud non crea route dinamiche personalizzate per i prefissi in conflitto. Ad esempio, quando esiste una subnet o una route di 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 subnet della subnet o la route 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 di subnet o di 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 di subnet vengono create, aggiornate ed eliminate quando crei, modifichi o elimini le subnet o i relativi intervalli di indirizzi IP delle subnet:

  • Quando aggiungi una subnet, Google Cloud crea una route di 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 in modalità automatica in modalità personalizzata.

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

    • Quando rimuovi un intervallo secondario da una subnet, la route della subnet per quell'intervallo secondario viene eliminata automaticamente.

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

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 in base ai messaggi BGP (Border Gateway Protocol) ricevuti, ai criteri di route BGP applicabili (Anteprima) e alle route apprese personalizzate del router Cloud che configuri. Il piano di controllo del router Cloud installa route dinamiche a livello di regione in base alla modalità di routing dinamico della rete VPC:

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

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

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

Se un hop successivo per una route dinamica diventa inaccessibile, il router Cloud che gestisce la sua sessione BGP indica alla rete VPC di rimuovere la route dinamica dopo che è soddisfatta una delle seguenti condizioni:

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

Route di subnet di peering

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

Le route di subnet locale e di subnet di peering non possono sovrapporsi. Per maggiori informazioni, consulta Interazioni delle route di subnet e subnet di peering.

Il numero di route di subnet per gruppo di peering è controllato dagli intervalli di subnet per rete per quota di 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, vedi:

Il numero di route statiche per gruppo di peering e di route dinamiche per regione per gruppo di peering è limitato da 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 quando viene inviato dall'istanza.

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

  • Le route basate su criteri possono essere applicate ai pacchetti inviati dalle 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 nella destinazione di una route di subnet locale o di peering. Per ulteriori dettagli sulla risoluzione dei conflitti tra subnet, route statiche e dinamiche, consulta 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 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 appaiono nella tabella delle route di rete VPC. Non puoi rimuovere percorsi di routing speciali. Tuttavia, puoi consentire o negare i pacchetti utilizzando le regole o i criteri firewall VPC.

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

I bilanciatori del carico di rete passthrough esterni e l'inoltro del protocollo esterno utilizzano i sistemi Maglev per instradare i pacchetti dai client su internet alle VM di backend e scegliere come target le istanze nella tua rete VPC. Questi sistemi Maglev instradano i pacchetti che hanno destinazioni che corrispondono a quella della regola di inoltro esterno.

Ogni regola di forwarding per un bilanciatore del carico di rete passthrough esterno o per il forwarding del protocollo esterno fornisce anche un percorso di routing per le VM di backend o l'istanza di destinazione al fine di 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 possono essere pacchetti in uscita che avviano una nuova connessione.
  • Le origini dei pacchetti devono corrispondere all'indirizzo IP della regola di forwarding. Il protocollo del pacchetto e la porta di origine non devono corrispondere al protocollo e alla specifica della porta della regola di forwarding.
  • I percorsi di routing della regola di forwarding non dipendono da una route predefinita o dall'utilizzo dell'hop successivo del gateway internet predefinito.
  • Non è necessario abilitare l'IP forwarding per le VM di backend e le istanze di destinazione.

Percorsi tra frontend e backend Google

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

  • 35.191.0.0/16
  • 130.211.0.0/22

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

Google Cloud utilizza le route nella rete Google per inviare i pacchetti dai sistemi 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 tramite IAP utilizza 35.235.240.0/20 come intervallo solo per uso interno con hop successivi interamente all'interno della rete Google. Google non pubblica route per 35.235.240.0/20 su internet.

Le route nella rete Google consegnano i 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 che si trovano interamente all'interno della rete Google. Google non pubblica route per 35.199.192.0/19 su internet.

Le route nella rete Google consegnano i 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 all'interno interamente della rete Google. Google non pubblica route per 35.199.224.0/19 su internet.

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

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

Quando crei un endpoint Private Service Connect per le API di 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 mostrati nella tabella delle route di rete VPC. Per maggiori dettagli, consulta Percorsi di routing speciali.

    Se è applicabile un percorso di routing speciale, il modello di selezione della route contiene solo quello speciale. Tutte le altre route vengono ignorate e la valutazione si interrompe in questo passaggio.

  2. Route basate su criteri:le route basate su criteri vengono valutate dopo percorsi di routing speciali, ma prima di altri tipi di route. Se nella rete VPC non sono presenti route basate su criteri, Google Cloud ignora questo passaggio e passa 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 dalla route o dalle route basate su criteri con la massima priorità. 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 valutare la route basata su criteri successiva nell'elenco ordinato. La prossima route basata su criteri da valutare potrebbe condividere la stessa priorità della route basata su criteri disconosciuta 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 fino 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 prima ignora tutte le route basate su criteri a priorità inferiore. Se nell'elenco rimangono due o più route basate su criteri, Google Cloud valuta ciascuna delle restanti route basate su criteri con priorità identiche. Google Cloud ignora le 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à massima e 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 ignorare 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 che contiene l'indirizzo IP di destinazione del pacchetto. Google Cloud ignora tutte le altre route con destinazioni meno specifiche. Ad esempio, 10.240.1.0/24 è una destinazione più specifica rispetto a 10.240.0.0/16. La destinazione più specifica potrebbe essere qualsiasi tipo di route; tuttavia, le route di subnet, le route di subnet di peering e i percorsi di routing speciali sono le più specifiche 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 stai 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 rete nel gruppo di peering. Il requisito modellato in questo passaggio è che Google Cloud selezioni gli hop successivi che si trovano tutti in un'unica rete VPC.

    • Se una o più route nel tuo modello di route hanno 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 sono presenti hop successivi per la stessa destinazione in una o più reti VPC peer.

    • Se nessuna delle route nel tuo modello di route ha hop successivi all'interno della rete VPC che stai modellando e tutti gli hop successivi sono presenti 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 è considerata in questo momento. Inoltre, se i peer di rete VPC 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 sono 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 maggiori dettagli, consulta Comportamento quando le istanze vengono arrestate o eliminate nella sezione Considerazioni per le 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 (SA) di fase 1 (IKE). Per ulteriori dettagli, consulta Ordine delle route nella documentazione relativa a VPN classica. Se il modello di route contiene route statiche i cui hop successivi sono tunnel VPN classica senza SA IKE stabiliti, rimuovi queste route dal tuo modello.

  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 della route potrebbe essere vuoto o contenere una o più route. Se il modello contiene route, tutte le route avranno tutte le seguenti caratteristiche:

    • Destinazioni identiche e più specifiche
    • Hop successivi in un'unica rete VPC: la rete VPC locale o un'unica rete VPC peer
    • Hop successivi che non sono noti per essere inattivi
    • Priorità uguali e massime

  5. Seleziona solo la categoria di preferenza più favorevole: Google Cloud evita il routing ECMP tra i diversi tipi di hop successivi. Puoi modellare questo comportamento prendendo in considerazione il sistema delle categorie di preferenze descritto nella seguente tabella. Questo passaggio perfeziona il modello di route in modo che contenga solo route dello stesso tipo di route 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 di hop successivo in esecuzione (next-hop-instance o next-hop-address) o con un tunnel VPN classica di hop successivo stabilito da 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 hop successivo del 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 "Stessa destinazione e più bilanciatori del carico di rete passthrough interni per l'hop successivo" nella sezione Considerazioni per gli hop successivi del bilanciatore del carico di rete passthrough interno.
    Quarta scelta Una route statica personalizzata che utilizza l'hop successivo default-internet-gateway

    Alla fine di questo passaggio, il modello di route può includere zero route, una o due o più route.

  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 ignorato a causa di un errore di destinazione ICMP o di 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 verifica 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 e delle istanze. Se la singola route è una route di subnet o una route di subnet di peering e non è presente alcuna risorsa Google Cloud all'indirizzo IP di destinazione del pacchetto, il pacchetto viene ignorato.

    • Se il modello di route contiene due o più route, condividono la stessa destinazione più specifica, si trovano in un'unica rete VPC, hanno hop successivi non noti per essere inattivi, hanno la stessa priorità più alta e appartengono a un tipo di route e a una combinazione di hop successivo (categoria di preferenza). Google Cloud distribuisce i pacchetti tra gli hop successivi implementando un equal-cost multipath (ECMP) utilizzando un algoritmo di hashing. I calcoli dell'hash vengono eseguiti per ogni pacchetto al momento dell'invio, in base al numero attuale di hop successivi. Google Cloud utilizza un hash a cinque tuple se il pacchetto contiene informazioni sulla porta, altrimenti un hash a tre tuple. Se il modello di route cambia durante l'invio dei pacchetti successivi, Google Cloud potrebbe indirizzare quei 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 di route

Le route statiche supportano i seguenti attributi:

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

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

  • Hop successivo. L'hop successivo identifica la risorsa di rete a cui vengono inviati i pacchetti. Tutti i tipi di hop successivi supportano le destinazioni IPv4 e alcuni di questi supportano le destinazioni IPv6. Per maggiori informazioni, consulta la sezione 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 le 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à maggiori. La priorità più alta possibile è 0, mentre la priorità più bassa possibile è 65,535.

  • Tag di rete. Puoi applicare una route statica a solo istanze VM selezionate 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 dell'hop successivo per nome e zona (next-hop-instance)
Invia pacchetti a una VM dell'hop successivo che sia identificata per nome e nella zona e si trova nello stesso progetto della route. Per maggiori 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 principale della sua interfaccia di rete. Per ulteriori informazioni, consulta Considerazioni sulle istanze dell'hop successivo.
Bilanciatore del carico di rete passthrough interno dell'hop successivo in base al nome della regola di forwarding e alla regione (next-hop-ilb)
Invia i pacchetti ai backend di un bilanciatore del carico di rete passthrough interno identificati 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 dell'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 pacchetti a un tunnel VPN classica dell'hop successivo utilizzando il routing basato su criteri o la VPN basata su route. Per maggiori informazioni, consulta le Considerazioni sugli hop successivi del tunnel VPN classico.
1 La tecnologia ECMP (Equal-cost multipath) indica che due o più route statiche possono condividere lo stesso intervallo di destinazione e la stessa priorità. Sebbene sia 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 e rete hop successivo

Un hop successivo di una route statica è associato sia a una rete VPC che 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 essere individuati nei progetti di servizio VPC condiviso.

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

Considerazioni comuni sugli hop successivi del bilanciatore del carico di rete passthrough interno e di istanze

Il routing basato su istanze è una route statica con un hop successivo che corrisponde a 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, prendi in considerazione 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 l'inoltro, 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'inoltro IP nel modello di istanza utilizzato dal gruppo di istanze. Questa modifica alla configurazione deve essere oltre alla configurazione del sistema operativo necessaria per il routing dei pacchetti.

  • Il software in esecuzione sulla VM di backend o sull'istanza dell'hop successivo deve essere configurato correttamente. Ad esempio, le VM dell'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 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 del traffico in entrata blocca tutti i pacchetti in entrata, quindi devi creare almeno una regola firewall di autorizzazione in entrata personalizzata.
    • 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 regola di negazione specifica in uscita per sostituirla.
    • Tieni presente se la VM di backend o l'istanza Next Hop sta eseguendo la Network Address Translation (NAT) durante la creazione delle regole firewall.

    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 di 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 ricevuto originariamente il pacchetto da una risorsa in una regione diversa da us-west1. Esempi di 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, collegamenti VLAN di Cloud Interconnect e VM dell'appliance router di Network Connectivity se la rete VPC utilizza il routing dinamico a livello di regione

Considerazioni sulle istanze dell'hop successivo

  • Hop successivo in base al nome e alla zona dell'istanza (next-hop-instance): quando crei una route statica in cui è specificata un'istanza dell'hop successivo in base al nome e alla zona dell'istanza, Google Cloud richiede che un'istanza con questo nome esista nella zona specificata e soddisfi i seguenti requisiti:

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

    Se 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 delle modifiche dell'istanza dell'hop successivo; oppure

    • Sostituisci l'istanza dell'hop successivo e l'istanza di sostituzione 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'indirizzo IPv4 o IPv6 dell'istanza non è assegnato

  • Indirizzo IP interno dell'istanza dell'hop successivo (next-hop-address): quando crei una route statica con un'istanza dell'hop successivo specificata da un indirizzo IPv4 interno, Google Cloud verifica che l'indirizzo IPv4 della VM dell'hop successivo rientri in un intervallo IPv4 della subnet di una subnet nella rete VPC della route. Tuttavia, Google Cloud programma la route solo se l'indirizzo dell'hop successivo è un indirizzo IPv4 interno primario assegnato a un NIC della VM nella rete VPC della route (non una rete VPC in peering).

    Google Cloud aggiorna automaticamente la programmazione per l'hop successivo quando l'indirizzo IPv4 dell'hop successivo viene spostato su una VM diversa, a condizione che la VM sostitutiva soddisfi gli stessi requisiti.

  • Istanze di hop successivo nei progetti di servizio VPC condivisi: 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 come progetto host del VPC condiviso) oppure la VM può essere situata in un progetto di servizio condiviso. Quando specifichi una VM dell'hop successivo in base al nome e alla 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 da regione a 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 prende in considerazione 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 comporta l'aggiunta dei costi di trasferimento dei dati in uscita e la latenza della rete.

  • Nessun controllo di integrità, nessuna convalida della configurazione: Google Cloud non controlla mai se un'istanza di hop successivo soddisfa tutti i requisiti descritti nella sezione Considerazioni comuni agli hop successivi del bilanciatore del carico di rete passthrough interno e di istanze. Se disabiliti l'interfaccia di rete della VM mediante la configurazione del sistema operativo guest dell'istanza, non Google Cloud ignora 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 che hanno più interfacce di rete in una configurazione che soddisfa tutti i seguenti criteri:

    • Le VM hanno un'interfaccia di rete 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, che utilizzano la stessa priorità, in cui ogni route nell'insieme fa riferimento a una VM univoca dell'hop successivo.

    Se utilizzi due o più VM con più interfacce per connettere le reti VPC e hai bisogno che la stessa VM elabori pacchetti per una determinata connessione in entrambe le direzioni, devi utilizzare l'hashing simmetrico, supportato solo dai bilanciatori del carico di rete passthrough interni dell'hop successivo. Per maggiori dettagli sull'hashing simmetrico, consulta la documentazione relativa all'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 della route statica (specificata dal nome e dalla zona o dall'indirizzo interno). Quando una VM dell'hop successivo non è in esecuzione, il routing per la destinazione dipende dall'esistenza o meno di altre route per la stessa destinazione e dalla presenza di hop successivi in esecuzione per queste altre route. Per illustrare questo comportamento, considera i seguenti esempi:

    • 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, la VM dell'hop successivo è stata arrestata
    • route-vm-b, destinazione 192.168.168.0/24, priorità 20, la VM dell'hop successivo è in esecuzione

    • route-vm-c, destinazione 192.168.168.0/24, priorità 30, la VM dell'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 non sono in esecuzione, anche se una route per la 192.168.0.0/16 più ampia ha una VM dell'hop successivo in esecuzione. I pacchetti vengono ignorati 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 avviene 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, la VM dell'hop successivo è stata arrestata

    • route-vm-y, destinazione 192.168.168.0/24, priorità 20, la VM dell'hop successivo è stata arrestata

    • route-vm-z, destinazione 192.168.0.0/16, priorità 0, la 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 per l'hop successivo. Google Cloud non supporta le regole di forwarding dell'hop successivo utilizzate da altri bilanciatori del carico, forwarding del protocollo o come endpoint Private Service Connect.

  • Metodi di specifica e rete e progetto di regola di forwarding 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ò essere collocata 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 per l'hop successivo in base al nome e alla 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 link alla risorsa della regola di forwarding: il link alla risorsa 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 per l'hop successivo tramite il relativo link alle risorse, la rete della regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding può essere situata nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host del VPC condiviso) oppure in un progetto di servizio VPC condiviso.

    • In base a un indirizzo IPv4 di una regola di forwarding: quando specifichi una regola di forwarding dell'hop successivo in base al relativo indirizzo IPv4, la rete della regola di forwarding può essere o la rete VPC della route o una rete VPC in peering. La regola di forwarding può essere situata nel progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host del VPC condiviso) oppure in un progetto di servizio 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. L'utilizzo dell'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 un 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 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 per l'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 univoco a un solo servizio di backend (un bilanciatore del carico). È possibile che le regole di forwarding utilizzano un indirizzo IP interno comune per fare riferimento a diversi servizi di backend (bilanciatori del carico di rete passthrough interni diversi).

  • Più route con le stesse destinazioni e priorità, ma bilanciatori del carico di rete passthrough interni diversi dell'hop successivo. Google Cloud distribuisce mai il traffico tra due o più bilanciatori del carico di rete passthrough interni di hop successivo utilizzando ECMP. Google Cloud seleziona invece un solo bilanciatore del carico di rete passthrough interno per l'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 un bilanciatore del carico di rete passthrough interno diverso 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 relative agli hop successivi del tunnel VPN classica

  • Costi e latenza da regione a regione: Google Cloud non prende in considerazione la distanza regionale per le route che utilizzano un tunnel VPN classica dell'hop successivo. L'invio del traffico a un tunnel VPN classica dell'hop successivo in un'altra regione aggiunge i costi di trasferimento dei dati in uscita e introduce la latenza di rete. Come best practice, utilizza invece un tunnel VPN ad alta disponibilità con il routing dinamico perché la configurazione prende in considerazione la distanza regionale.

  • Comportamento quando i tunnel VPN classiche non sono in esecuzione:le route statiche personalizzate i cui hop successivi sono tunnel VPN classica non vengono rimosse automaticamente quando 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 relativa alla VPN classica.

Passaggi successivi