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 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 utilizza 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 viene definita a livello di rete VPC.

Ogni istanza VM ha un controller che viene informato di tutte le route applicabili dalla tabella di routing della rete. Ogni pacchetto lasciato 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 finale coerente.

Tipi di percorso

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 di subnet
Rete VPC
Inoltra i pacchetti alle VM e ai bilanciatori del carico interni

Creati, aggiornati e rimossi automaticamente da Google Cloud durante gli eventi del ciclo di vita delle subnet.

Le route di subnet locali si applicano all'intera rete VPC.

Percorsi personalizzati
Route statica
Supporta varie destinazioni
Inoltra i pacchetti a un hop successivo di 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 di 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 fornisce opzioni per lo scambio di route di subnet.

Creati, aggiornati e rimossi 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 regione 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 di Network Connectivity Center

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

Creati, aggiornati e rimossi automaticamente da Google Cloud durante gli eventi del ciclo di vita delle subnet.

Le route di subnet importate da Network Connectivity Center 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 valutare altre route. Le route basate su criteri possono essere applicate a tutte le VM nella rete, a determinate VM selezionate dal tag di rete o al traffico in entrata 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 subnet a doppio stack con un intervallo di indirizzi IPv6 esterno in una rete VPC, viene aggiunta a questa rete una route predefinita IPv6 generata dal sistema (::/0), 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 vengono utilizzate la specificità della destinazione e la priorità della route per selezionare una route, consulta l'articolo sull'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 personalizzata statica o dinamica. 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, vengono eliminati i pacchetti destinati a intervalli IP non coperti da altre route.

Route di subnet

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

Ogni subnet ha almeno una route la cui destinazione corrisponde all'intervallo IPv4 principale della subnet. Se la subnet include intervalli IP secondari, esiste una route di subnet corrispondente a 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 saperne di più sugli intervalli IP di subnet, consulta Subnet.

Le route di subnet hanno sempre le destinazioni più specifiche. Non possono essere sostituite da altri percorsi, anche se un altro percorso ha una priorità più alta. Questo perché Google Cloud considera la specificità della destinazione prima della priorità quando 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 le route statiche personalizzate nei modi seguenti:

  • Google Cloud non consente di creare una route statica personalizzata con una destinazione uguale o più stretta rispetto a qualsiasi route 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 rientri 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 rientri 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 impedisce la creazione di qualsiasi route di subnet o di subnet di peering con un intervallo di indirizzi IPv4 di subnet principale o secondaria di 10.70.1.128/25, 10.70.1.0/24 o di 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 2001:0db8:0a0b:0c0d::/64 o qualsiasi altro intervallo contenente tutti gli indirizzi IPv6 in 2001:0db8:0a0b:0c0d::/96.

Interazioni con le route dinamiche

Le route di subnet locali e quelle 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 subnet di peering o di una subnet esistente, Google Cloud non crea alcuna route dinamica personalizzata per il prefisso in conflitto. Ad esempio, quando esiste una subnet di peering o una 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 subnet o la route di 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 una subnet la cui destinazione corrisponde esattamente a un prefisso riconosciuto dai router Cloud nella rete VPC, Google Cloud rimuove la route dinamica personalizzata per il prefisso in conflitto per fare spazio alla subnet o al route della subnet di peering.
  • Quando i router Cloud apprendono i prefissi che si adattano alla destinazione di una subnet di peering o di una subnet esistente, Google Cloud non crea route dinamiche personalizzate per i prefissi in conflitto. Ad esempio, se esiste una route di subnet di peering o di una subnet 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 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 acquisiti dai router Cloud nella rete VPC, Google Cloud rimuove le route dinamiche personalizzate per i prefissi in conflitto per fare spazio alla subnet della subnet o alla 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:

  • 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 da modalità automatica in modalità personalizzata.

  • Non puoi eliminare una route di subnet a meno che non la modifichi o elimini:

    • 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 route della subnet 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 e alle 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 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 in subnet in un'altra rete VPC connessa tramite il peering di rete VPC. Per maggiori informazioni, consulta Opzioni per lo scambio di route di subnet.

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

Il numero di route di subnet per gruppo di peering è controllato dagli intervalli di subnet per rete per quota del gruppo di peering.

Route statiche e dinamiche di peering

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

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

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

  • Le route basate su criteri possono essere applicate ai pacchetti inviati dalle istanze VM di Compute Engine o ai pacchetti 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. Fatta eccezione per le route basate su criteri, nessun altro tipo di route può avere una destinazione corrispondente o che rientra nella 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 delle route statiche e di subnet e Interazioni delle route dinamiche e di subnet.

  • 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 reso speciali

Le reti VPC hanno route speciali per determinati servizi. Queste route sono definite all'esterno della tua rete VPC, nella rete di produzione di Google. Non vengono visualizzati nella tabella delle route della rete VPC. Non puoi rimuoverle o eseguirne l'override, anche se elimini o sostituisci una route predefinita nella tua rete VPC. Tuttavia, puoi consentire o negare i pacchetti utilizzando le regole firewall VPC, i criteri firewall di rete o i criteri firewall gerarchici.

Percorsi di ritorno del bilanciatore del carico

Google Cloud utilizza route speciali all'esterno della tua rete VPC per consegnare pacchetti tra:

  • Sistemi client e backend del bilanciatore del carico (per bilanciatori del carico di rete passthrough esterni)
  • Sistemi proxy e backend del bilanciatore del carico (per bilanciatori del carico proxy esterni)
  • probe di controllo di integrità e backend del bilanciatore del carico
Percorsi tra proxy e backend Google Front End (GFE)

I bilanciatori del carico delle applicazioni esterni globali, i bilanciatori del carico delle applicazioni classici, i bilanciatori del carico di rete proxy classici e i bilanciatori del carico di rete con proxy esterno globale utilizzano i sistemi Google Front End (GFE) come proxy.

Quando un client invia una richiesta al bilanciatore del carico, i GFE terminano la prima connessione TCP. I GFE aprono quindi una seconda connessione TCP alle VM di backend. Google Cloud utilizza route definite all'esterno della rete VPC per instradare i pacchetti tra i proxy GFE e le VM di backend.

Percorsi dei backend del bilanciatore del carico di rete passthrough esterno

Per i bilanciatori del carico di rete passthrough esterni, Google Cloud utilizza route definite all'esterno della tua rete VPC per instradare i pacchetti tra client e VM di backend.

Controlli di integrità per tutti i tipi di bilanciatori del carico

I pacchetti inviati dai sistemi di probe per il controllo di integrità di Google Cloud utilizzano origini pacchetto documentate in Intervalli IP e regole firewall di probe.

IAP

Google Cloud include route da e verso 35.235.240.0/20 in ogni rete VPC per supportare l'inoltro TCP tramite IAP. La rete di produzione di Google utilizza 35.235.240.0/20 come intervallo solo per uso interno. Gli hop successivi per 35.235.240.0/20 sono interamente all'interno della rete di produzione di Google.

Cloud DNS e Service Directory

Google Cloud include route da e verso 35.199.192.0/19 in ogni rete VPC per supportare le destinazioni di forwarding di Cloud DNS che utilizzano il routing privato, i server dei nomi alternativi che utilizzano il routing privato di Cloud DNS e l'accesso alla rete privata per Service Directory. La rete di produzione di Google utilizza 35.199.192.0/19 come intervallo solo per uso interno. Gli hop successivi per 35.199.192.0/19 sono interamente all'interno della rete di produzione di Google.

Accesso VPC serverless

Google Cloud include route da e verso 35.199.224.0/19 in ogni rete VPC per supportare l'accesso VPC serverless. La rete di produzione di Google utilizza 35.199.224.0/19 come intervallo solo per uso interno. Gli hop successivi per 35.199.224.0/19 sono interamente all'interno della rete di produzione di Google.

Ordine di routing

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

  1. Percorsi di ritorno speciali: i percorsi di ritorno speciali non vengono mostrati nella tabella delle route della tua rete VPC. Le route configurate in una rete VPC non si applicano ai pacchetti di risposta per determinati bilanciatori del carico di Google Cloud, sistemi di controllo di integrità, Identity-Aware Proxy (IAP) e proxy Cloud DNS. Per maggiori dettagli, consulta Percorsi di reso speciali.

    Se è applicabile un percorso di reso speciale, il modello di selezione del percorso contiene solo il percorso di reso 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 ritorno 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 al passaggio della destinazione più specifica.

    • Google Cloud valuta le route basate su criteri esclusivamente in base alla loro priorità. Google Cloud valuta l'origine e la destinazione di un pacchetto per ogni route basata su criteri, a partire dalla route o dalle route basate su criteri con priorità più alta. 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 successiva route basata su criteri da valutare potrebbe avere la stessa priorità della route basata su criteri disconosciuta oppure avere una priorità più bassa.

    • Se le caratteristiche di un pacchetto non corrispondono a nessuna route basata su criteri dopo aver valutato tutte le route basate su criteri nel modello di selezione delle route, Google Cloud ignora tutte le route basate su criteri e passa al passaggio della destinazione più specifica.

    • Se le caratteristiche di un pacchetto corrispondono a una route basata su criteri con priorità massima, 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 ciascuna delle restanti route basate su criteri con 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 tuo modello di selezione delle route include due o più route basate su criteri con la 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 tuo modello di selezione delle route include solo una singola route basata su criteri con priorità massima che è 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 tuo modello di selezione delle route include solo una singola route basata su criteri con priorità massima e 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.

  3. 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 di 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 ritorno speciali sono le più specifiche per definizione.

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

  4. 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, 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 si trovano tutti in un'unica rete VPC.

    • Se una o più delle 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 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 tuo modello di route presenta 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 è considerata in questo momento. Inoltre, se i peer della tua 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.

  5. Ignora 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 utilizzando gli annunci BGP.

    • Google Cloud ignora ogni istanza VM dell'hop successivo (next-hop-instance o next-hop-address) se la VM dell'hop successivo è stata arrestata o eliminata. Per maggiori 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 sono state 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) (IKE) di 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 stabiliti, rimuovile dal modello.

  6. Ignora le route a bassa priorità: questo passaggio definisce 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 modello contiene route, tutte hanno tutte le seguenti caratteristiche:

    • Destinazioni identiche e più specifiche
    • Hop successivi in una singola rete VPC: la rete VPC locale o una singola rete VPC peer
    • Hop successivi non notoriamente inattivi
    • Priorità più elevate identiche
  7. Seleziona solo la categoria di preferenza più favorevole: Google Cloud evita il routing ECMP tra diversi tipi di hop successivi. Puoi modellare questo comportamento prendendo in considerazione il sistema delle categorie di preferenze descritto nella tabella seguente. 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 (la preferenza massima) Route statiche personalizzate con un'istanza di hop successivo in esecuzione (next-hop-instance o next-hop-address) o il tunnel VPN classica dell'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 dell'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 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 può contenere zero route, una o due o più route.

  8. Invio o rimozione di 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 con una destinazione ICMP o un errore di rete non raggiungibile. Google Cloud non torna mai a 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 di istanze e bilanciatore del carico di rete passthrough interno. 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 una singola rete VPC, hanno hop successivi non funzionanti, che hanno la stessa priorità più alta e appartengono a una combinazione di tipo di route e hop successivo (categoria di preferenza). Google Cloud distribuisce i pacchetti tra gli hop successivi che implementano l'equal-cost multipath (ECMP) utilizzando un algoritmo di hashing. I calcoli 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; in caso contrario, utilizza un hash a tre tuple. Se il modello di route cambia quando vengono inviati 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 uno dei due modi seguenti:

Puoi scambiare route statiche con una rete VPC in peering come descritto in Opzioni per lo scambio di route statiche personalizzate nella documentazione relativa al 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, mentre la descrizione è facoltativa. Ogni route nel 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, mentre alcuni di questi supportano le destinazioni IPv6. Per maggiori informazioni, consulta 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 le route statiche e Interazioni con route statiche e subnet. 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à. I numeri più bassi indicano priorità più elevate. La priorità più alta possibile è 0, mentre la priorità più bassa è 65,535.

  • Tag di rete. Puoi fare in modo che una route statica venga applicata solo a 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 successivi e funzionalità

La tabella seguente riassume il supporto della funzionalità di route statica per il tipo di hop successivo:

Tipo di hop successivo IPv4 IPv6 ECMP1
Gateway 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 pacchetti a una VM dell'hop successivo che sia identificata per nome e nella zona e si trova nello stesso progetto della route. Per ulteriori informazioni, consulta Considerazioni sulle istanze di hop successivo.
Istanza hop successivo in base all'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 di 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 pacchetti ai backend di un bilanciatore del carico di rete passthrough interno identificato in base al nome e alla regione della regola di forwarding. Per ulteriori 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 ulteriori 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 classico dell'hop successivo utilizzando il routing basato su criteri o una VPN basata su route. Per ulteriori informazioni, consulta Considerazioni sugli hop successivi per il tunnel VPN classica.
1ECMP (Equal-cost multipath) indica che due o più route statiche possono condividere lo stesso intervallo di destinazione e la stessa priorità. Anche se puoi 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, il risultato è un'unica route statica che utilizza l'hop successivo del gateway internet predefinito per quella destinazione e priorità.

Progetto hop successivo e rete

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 in basso, 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 posizionati 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 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 agli hop successivi di istanze e bilanciatore del carico di rete passthrough interno

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, considera 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. Devi apportare questa modifica alla configurazione oltre all'eventuale 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 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 implicita di negazione del traffico in entrata blocca tutti i pacchetti in entrata, pertanto devi creare almeno 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 di autorizzazione in uscita implicita lo consente, a meno che tu non abbia creato una regola di negazione specifica per il traffico in uscita per sostituirla.
    • Prendi in considerazione se la VM di backend o l'istanza Next Hop sta eseguendo 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 di 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, Application Load Balancer interni e bilanciatori del carico di rete proxy interni regionali con accesso globale disattivato
    • Tunnel Cloud VPN, collegamenti VLAN per Cloud Interconnect e VM dell'appliance Router per la connettività di rete, se la rete VPC utilizza il routing dinamico a livello di regione

Considerazioni sulle istanze di hop successivo

  • Hop successivo per nome e zona dell'istanza (next-hop-instance): quando crei una route statica con un'istanza dell'hop successivo specificata in base al nome e alla zona dell'istanza, Google Cloud richiede che esista un'istanza con questo nome 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 in base al nome dell'istanza e alla 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 NIC dell'istanza
      • Quando viene annullata l'assegnazione dell'indirizzo IPv4 o IPv6 dell'istanza
  • 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 principale 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 nello stesso progetto della route (un progetto autonomo o in un progetto host di VPC condiviso) oppure la VM può trovarsi in un progetto di servizio VPC 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 tra regioni: 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 a livello di regione 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 un'altra regione. L'invio di pacchetti da un'area geografica all'altra comporta un aumento dei costi per il trasferimento dei dati in uscita e una latenza di rete.

  • Nessun controllo di integrità, nessuna convalida della configurazione: Google Cloud non controlla 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. 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 con 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, 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 reti VPC e hai bisogno 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 documentazione sugli 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 tramite nome e zona o indirizzo interno). Quando una VM dell'hop successivo non è in esecuzione, il routing della destinazione dipende dall'esistenza o meno di altre route per la stessa destinazione e dall'eventuale presenza di hop successivi in esecuzione su 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 la massima priorità non è in esecuzione. Questo routing si verifica perché Google Cloud ignora gli hop successivi non in esecuzione prima di considerare il passaggio Ignorare 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 ignorati nell'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 dell'hop successivo. Google Cloud non supporta le regole di forwarding per l'hop successivo utilizzate da altri bilanciatori del carico, forwarding del protocollo o come endpoint Private Service Connect.

  • Metodi di specifica e rete e progetto regola di forwarding forwarding. Puoi specificare una regola di forwarding per l'hop successivo utilizzando uno dei tre metodi seguenti. Il metodo di specifica che utilizzi 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:

    • Per nome della regola di forwarding (--next-hop-ilb) e regione (--next-hop-ilb-region): quando specifichi una regola di forwarding dell'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).

    • Link alla risorsa della regola di forwarding: il link delle 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 di forwarding. 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ò trovarsi sia 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 VPC condiviso.

    • In base a un indirizzo IPv4 della 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ò trovarsi sia 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 VPC condiviso.

  • Effetto dell'accesso globale. Le route statiche personalizzate utilizzando gli hop successivi del bilanciatore del carico di rete passthrough interno sono programmati in tutte le regioni. L'utilizzo dell'hop successivo dipende dall'impostazione di accesso globale del bilanciatore del carico. Se l'accesso globale è abilitato, l'hop successivo del bilanciatore del carico è accessibile in tutte le aree geografiche 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 ignorati.

  • 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 dell'hop successivo deve utilizzare un indirizzo IP univoco per la regola di forwarding del bilanciatore del carico in modo che venga fatto riferimento a un solo servizio di backend (un bilanciatore del carico) in modo univoco. È 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).

  • Stessa destinazione e più bilanciatori del carico di rete passthrough interni per l'hop successivo. Se crei due o più route statiche personalizzate con la stessa destinazione, utilizzando hop successivi del bilanciatore del carico di rete passthrough interno diversi, Google Cloud mai distribuisce il traffico tra gli hop successivi del bilanciatore del carico utilizzando ECMP. Se le route hanno priorità univoche, Google Cloud utilizza il bilanciatore del carico di rete passthrough interno dell'hop successivo rispetto alla route con la priorità più alta. Se le route hanno uguali priorità, Google Cloud seleziona comunque un solo bilanciatore del carico di rete passthrough interno dell'hop successivo. In quest'ultima situazione, come illustrato nel diagramma seguente, Google Cloud utilizza un algoritmo interno deterministico per selezionare una singola regola di forwarding dell'hop successivo (forwarding-rule-a), ignorando le altre route con la stessa priorità.

    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ù destinazioni e lo stesso bilanciatore del carico di rete passthrough interno per l'hop successivo.

    Con i tag di istanza:

    Se utilizzi tag di istanza (chiamati anche tag di rete), puoi utilizzare lo stesso bilanciatore del carico di rete passthrough interno dell'hop successivo per più route statiche personalizzate con la stessa destinazione e priorità.

    Senza tag di istanza: senza tag di istanza, non puoi creare più route statiche personalizzate con la stessa combinazione di destinazione, priorità e hop successivo del bilanciatore del carico di rete passthrough interno. Ad esempio, è possibile creare tutti i criteri route-x, route-y e route-z, ma non è possibile creare route-x-copy.

    Non è possibile creare route statiche che non hanno tag di istanza con la stessa destinazione, la stessa priorità e l'hop successivo del bilanciatore del carico di rete passthrough interno.
  • Tag istanza.

    Puoi specificare i tag di istanza (chiamati anche tag di rete) in modo che la route dell'hop successivo si applichi solo alle istanze client configurate con il tag. In questo modo puoi selezionare le istanze client che vengono completate con la route dell'hop successivo con tag e il set di appliance a cui indirizzare il traffico.

    Non è necessario separare le diverse istanze client in reti VPC separate, ognuna delle quali punta al proprio bilanciatore del carico di rete passthrough interno preferito per frontend di un set di appliance.

  • Più route allo stesso prefisso di destinazione. Con i tag di istanza, puoi specificare più route per la stessa destinazione con bilanciatori del carico interni diversi come hop successivi. Puoi utilizzare tag di istanza diversi o priorità diverse per queste stesse route di destinazione.

Considerazioni sugli hop successivi per il tunnel VPN classica

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

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