Route

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

In una rete VPC, una route è costituita da un singolo prefisso 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 degli itinerari in Google Cloud.

Routing in Google Cloud

Ogni rete VPC utilizza un meccanismo di routing virtuale distribuito e scalabile. 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 di tutte le route applicabili dalla tabella di routing della rete. Ogni pacchetto che esce da una VM viene inviato all'hop successivo appropriato di una route applicabile in base a un ordine di routing. Quando aggiungi o elimini una route, l'insieme delle modifiche viene propagato ai controller VM utilizzando una progettazione coerente nel tempo.

Tipi di route

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

Tipo e destinazione Hop successivo Note
Route basate su policy: le route basate su policy vengono valutate prima di qualsiasi altro tipo di route.
Route basata 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 elementi.

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 per Cloud Interconnect (in una sola regione o in tutte le regioni).

Le route basate su criteri non vengono mai scambiate tramite il peering di rete VPC.
Route di subnet: tutti i tipi di route di subnet vengono valutati dopo le route basate su norme, ma prima delle route personalizzate.
Route subnet locale
Creata automaticamente per ogni intervallo di indirizzi IP della subnet 		Rete VPC

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

Le route di subnet locali si applicano all'intera 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 offre opzioni per lo scambio di route di subnet.

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

Le route subnet di peering importate si applicano all'intera rete VPC.
Route di subnet di Network Connectivity Center
Rappresenta un intervallo di indirizzi IP di subnet in uno spoke VPC (una rete VPC diversa connessa all'hub Network Connectivity Center) 		Hub Network Connectivity Center

Gli amministratori degli spoke 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 della subnet.

Le route di subnet di Network Connectivity Center importate si applicano all'intera rete VPC.
Route personalizzate: le route personalizzate vengono valutate dopo le route basate su criteri e dopo le route di subnet.
Percorso statico locale
Supporta varie destinazioni 		Inoltra i pacchetti a un hop successivo di una route statica Per informazioni dettagliate su ogni hop successivo della route statica, consulta le considerazioni per:
Route dinamica locale
Destinazioni che non sono in conflitto con le route di subnet o le 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 vengono applicate alle VM in base alla modalità di routing dinamico della rete VPC.
Route statica di peering, route dinamica di peering
Route statiche o dinamiche in una rete VPC diversa connessa utilizzando il 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 offre opzioni per lo scambio di route dinamiche.

Le route dinamiche di peering 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 dinamica di Network Connectivity Center
Route dinamiche importate dagli spoke ibridi di Network Connectivity Center che si trovano in reti VPC diverse 		Hub Network Connectivity Center

Un hub Network Connectivity Center può avere sia spoke VPC sia spoke ibridi.

Le route dinamiche di Network Connectivity Center si applicano a una regione o a tutte le regioni della rete VPC in base alla modalità di routing dinamico della rete VPC che contiene lo spoke ibrido.
Itinerari generati 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

Ogni subnet ha almeno una route di subnet per ogni intervallo di indirizzi IP associato alla subnet. Per saperne di più sugli intervalli IP delle subnet, vedi Subnet.

Tipi di route di subnet

Una rete VPC può includere i seguenti tipi di route di subnet:

  • Route subnet per le subnet nella stessa rete VPC, denominate route subnet locali.
  • Route subnet di Network Connectivity Center importate dagli spoke VPC di un hub Network Connectivity Center.
  • Route subnet di peering importate da reti connesse tramite peering di rete VPC.

Gli intervalli di destinazione per tutti i tipi di route di subnet devono essere univoci. Per saperne di più, consulta:

Route di subnet ibrida

Le route di subnet locali e le route di subnet di peering possono essere route di subnet ibride se la subnet corrispondente è configurata come subnet ibrida.

Ciclo di vita delle route di subnet

Tutti gli intervalli di indirizzi IP che fanno parte di una subnet (intervalli di indirizzi IPv4 primari, intervalli di indirizzi IPv4 secondari e intervalli di indirizzi IPv6) hanno una route di subnet corrispondente. Google Cloud crea ed elimina le route di subnet in questi scenari:

  • Apporti una modifica alla configurazione della subnet, ad esempio:

    • Aggiungi o elimina una subnet.
    • Espandi un intervallo IPv4 principale.
    • Aggiungi o elimina un intervallo IPv4 secondario.
    • Aggiungi o elimina un intervallo IPv6.

  • Google Cloud aggiunge una nuova regione, che aggiunge automaticamente una nuova subnet alle reti VPC in modalità automatica. Per informazioni sugli intervalli di indirizzi IPv4 per ogni subnet in base alla regione, consulta intervalli IPv4 in modalità automatica.

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, alle norme di routing BGP applicabili (anteprima) e alle route personalizzate apprese dal router Cloud.

Le route dinamiche vengono create in una regione o in tutte le regioni in base alla modalità di routing dinamico e alla modalità di selezione del percorso migliore della rete VPC che contiene il router Cloud. Per ulteriori informazioni, consulta le seguenti risorse:

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. Per ulteriori informazioni, vedi Modifiche dello stato BGP.

Tipi di route dinamiche

Una rete VPC può includere i seguenti tipi di route dinamiche:

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

Route predefinite generate dal sistema

Una route predefinita ha la destinazione più ampia possibile: 0.0.0.0/0 per IPv4 e ::/0 per IPv6. Google Cloud Solo utilizza una route predefinita per recapitare un pacchetto quando il pacchetto non corrisponde a una route più specifica nell'ordine di routing.

L'assenza di una route predefinita non isola necessariamente la tua rete da internet perché i percorsi di routing speciali per i bilanciatori del carico di rete passthrough esterni e l'inoltro di protocollo esterno non dipendono da una route predefinita.

Quando crei una rete VPC,Google Cloud aggiunge una route predefinita IPv4 generata dal sistema alla rete VPC. La route predefinita IPv4 generata dal sistema è una route statica locale con una destinazione 0.0.0.0/0 e un hop successivo del gateway internet predefinito. Una route statica locale con la destinazione 0.0.0.0/0 e l'hop successivo del gateway internet predefinito fornisce un percorso per indirizzi IPv4 esterni, inclusi gli indirizzi IPv4 su internet. Le seguenti risorse di esempio utilizzano questo percorso:

  • VM con indirizzi IPv4 esterni assegnati alle interfacce di rete, quando i pacchetti che inviano hanno origini corrispondenti all'indirizzo IPv4 interno principale dell'interfaccia di rete.
  • Un gateway Cloud NAT pubblico configurato per fornire servizi NAT alle subnet utilizzate dalle interfacce di rete delle VM. Per NAT44 e NAT64, i gateway Cloud NAT pubblici dipendono sempre da una route statica IPv4 locale che utilizza l'hop successivo del gateway internet predefinito. Per ulteriori informazioni sul traffico che può essere tradotto dai gateway Cloud NAT pubblici, consulta le specifiche generali.

Quando crei una subnet con un intervallo di indirizzi IPv6 esterno,Google Cloud aggiunge una route predefinita IPv6 generata dal sistema alla rete VPC, se non ne ha già una. La route predefinita IPv6 generata dal sistema è una route statica locale con una destinazione ::/0 e un hop successivo del gateway internet predefinito. Una route statica locale con la destinazione ::/0 e l'hop successivo del gateway internet predefinito fornisce un percorso per gli indirizzi IPv6 esterni, inclusi gli indirizzi IPv6 su internet. Questo percorso può essere utilizzato da:

  • VM con intervalli di indirizzi IPv6 esterni /96 assegnati alle interfacce di rete, quando i pacchetti che inviano hanno origini in quell'intervallo di indirizzi /96.

L'accesso alle API di Google globali a volte dipende da una route predefinita IPv4 o IPv6 locale con hop successivo del gateway internet predefinito:

  • Se accedi alle API e ai servizi Google globali inviando pacchetti a un endpoint Private Service Connect per le API Google globali, la tua rete VPC non richiede una route predefinita con hop successivo del gateway internet predefinito. Google Cloud aggiunge un percorso di routing speciale all'endpoint.

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

Interazioni con gli itinerari

Le sezioni seguenti descrivono le interazioni tra le route di subnet e altri tipi di route.

Interazioni tra route di subnet e route statiche

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

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

    • Se esiste una route di subnet locale, di peering o di Network Connectivity Center con la destinazione 10.70.1.0/24, non puoi creare una nuova route statica per 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 o qualsiasi altra destinazione che rientri in 10.70.1.0/24.

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

  • Google Cloud non consente di apportare modifiche alle subnet che comportano un intervallo di indirizzi IP della subnet che corrisponde esattamente o contiene la destinazione di una route statica locale o di peering esistente. Ad esempio:

    • Se la tua rete VPC ha una route statica con destinazione 10.70.1.128/25, non puoi creare una nuova subnet con un intervallo di indirizzi IPv4 primario o secondario di 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro intervallo di indirizzi IP che contenga tutti gli indirizzi IPv4 in 10.70.1.128/25.

    • Se la tua rete VPC ha una route statica con la destinazione 2001:db8:a0b:c0d:e0f:f0e::/96,impedisce la creazione di una nuova route di subnet locale o in peering con un intervallo di indirizzi IPv6 di 2001:db8:a0b:c0d::/64 o qualsiasi altro intervallo che contenga tutti gli indirizzi IPv6 in 2001:db8:a0b:c0d:e0f:f0e::/96. Google Cloud

Interazioni tra route di subnet e route dinamiche

Google Cloud applica le seguenti regole a meno che una subnet non sia stata configurata come subnet ibrida.

  • Google Cloud non crea una route dinamica se un router Cloud invia un prefisso che corrisponde esattamente o rientra nella destinazione di una route di subnet locale, di peering o Network Connectivity Center esistente. Ad esempio:

    • Se esiste una route di subnet locale, di peering o di Network Connectivity Center con la destinazione 10.70.1.0/24 e se un router Cloud nella rete VPC, in una rete VPC con peering o in una rete contenente uno spoke ibrido di Network Connectivity Center riceve 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro prefisso che rientra in 10.70.1.0/24, Google Cloud non crea route dinamiche locali, di peering o di Network Connectivity Center per i prefissi in conflitto ricevuti.

    • Se esiste una route di subnet locale, di peering o di Network Connectivity Center con la destinazione 2001:0db8:0a0b:0c0d::/64 e se un router Cloud nella rete VPC, in una rete VPC con peering o in una rete contenente uno spoke ibrido di Network Connectivity Center riceve 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 o qualsiasi altro prefisso che rientra in 2001:0db8:0a0b:0c0d::/64, Google Cloud non crea route dinamiche locali, di peering o di Network Connectivity Center per i prefissi in conflitto ricevuti.

  • Google Cloud rimuove qualsiasi route dinamica esistente se qualsiasi modifica alle subnet comporta la creazione di una nuova route di subnet locale, di peering o di Network Connectivity Center la cui destinazione corrisponde esattamente o contiene la destinazione della route dinamica locale, di peering o di Network Connectivity Center esistente. Ad esempio:

    • Se la tua rete VPC ha una route dinamica locale, di peering o di Network Connectivity Center con la destinazione 10.70.1.128/25,Google Cloud rimuove la route dinamica quando viene creata una nuova route di subnet locale, di peering o di Network Connectivity Center per 10.70.1.128/25, 10.70.1.0/24 o qualsiasi altro intervallo di indirizzi IP che contenga tutti gli indirizzi IPv4 in 10.70.1.128/25.

    • Se la tua rete VPC ha una route dinamica locale, di peering o di Network Connectivity Center con la destinazione 2001:db8:a0b:c0d::/96, Google Cloud rimuove la route dinamica quando viene creata una nuova route di subnet locale, di peering o di Network Connectivity Center per 2001:db8:a0b:c0d::/64.

Applicabilità e ordine

Route applicabili

Ogni istanza, tunnel Cloud VPN e collegamento VLAN ha un insieme di route applicabili, ovvero route che si applicano a quella risorsa specifica. Le route applicabili sono un sottoinsieme di tutte le route nella rete VPC.

I seguenti tipi di route si applicano sempre a tutte le istanze VM, a tutti i collegamenti VLAN e a tutti i tunnel Cloud VPN:

I seguenti tipi di route possono essere configurati per essere applicati solo a determinate istanze VM, collegamenti VLAN o tunnel Cloud VPN:

  • Le route basate su policy possono essere applicate a:

    • Tutte le istanze VM, tutti i collegamenti VLAN e tutti i tunnel Cloud VPN
    • Solo le istanze VM identificate dai tag di rete
    • Solo i collegamenti VLAN in una regione specifica

  • Le route statiche possono essere applicate a:

    • Tutte le istanze VM, tutti i collegamenti VLAN e tutti i tunnel Cloud VPN
    • Solo le istanze VM identificate dai tag di rete

  • Le route dinamiche possono essere applicate a istanze VM, collegamenti VLAN e tunnel Cloud VPN nella regione contenente l'hop successivo della route dinamica o in tutte le regioni, in base alla modalità di routing dinamico della rete VPC.

Percorsi di routing speciali

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

Percorsi per i bilanciatori del carico di rete passthrough esterni e l'inoltro di protocollo esterno

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

Ogni regola di forwarding per un bilanciatore del carico di rete passthrough esterno o per il forwarding del protocollo esterno fornisce anche un percorso di routing per le VM di backend o l'istanza di destinazione per inviare pacchetti a destinazioni al di fuori della rete VPC:

  • I pacchetti inviati dalle VM di backend o dalle istanze di destinazione possono essere pacchetti di risposta in uscita (inviati di nuovo al client) oppure 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 alla specifica di protocollo e porta della regola di forwarding.
  • I percorsi di routing delle regole di inoltro non dipendono da una route predefinita o dall'utilizzo dell'hop successivo del gateway internet predefinito.
  • Le VM di backend e le istanze di destinazione non devono avere l'IP forwarding abilitato.

Percorsi tra i Google Front End e i backend

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

  • 35.191.0.0/16 e 130.211.0.0/22 per IPv4
  • 2600:2d00:1:1::/64 per IPv6

Google Cloud utilizza le route nella rete di Google per distribuire i pacchetti da questi intervalli di origine alle VM di backend nella tua rete VPC. Ogni rete VPC include percorsi di routing che consentono alle VM di inviare pacchetti di risposta agli intervalli.

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 dagli intervalli di indirizzi IP dei probe del controllo di integrità.

Google Cloud utilizza le route nella rete di Google per recapitare i pacchetti dai sistemi di probe di controllo di integrità dell'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 di controllo di integrità.

Percorsi per Identity-Aware Proxy (IAP)

L'inoltro TCP tramite IAP utilizza 35.235.240.0/20 per IPv4 e 2600:2d00:1:7::/64 per IPv6 come intervalli solo interni con hop successivi interamente all'interno della rete di Google. Google non pubblica route a questi intervalli su internet.

Le route nella rete di Google inviano pacchetti da 35.235.240.0/20 o 2600:2d00:1:7::/64 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 questi intervalli.

Percorsi per Cloud DNS e Service Directory

Le seguenti funzionalità di Cloud DNS e Service Directory utilizzano 35.199.192.0/19 come intervallo solo interno con hop successivi interamente all'interno della rete di Google. Google non pubblica itinerari per 35.199.192.0/19 su internet.

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

Percorsi per l'accesso VPC serverless

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

Le route nella rete di Google inviano 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

Potrebbe esserci più di un percorso applicabile per un determinato pacchetto. I seguenti passaggi descrivono la procedura che Google Cloud utilizza per selezionare un percorso.

  1. Percorsi di routing speciali: alcuni Google Cloud percorsi di routing speciali non mostrati nelle tabelle di route di rete VPC. Per maggiori dettagli, vedi Percorsi di routing speciali.

    Se è applicabile un percorso di routing speciale, il modello di selezione dell'itinerario contiene solo il percorso speciale. Tutti gli altri percorsi vengono ignorati e la valutazione si interrompe in questo passaggio.

  2. Route basate su policy: le route basate su policy vengono valutate dopo i percorsi di routing speciali, ma prima degli altri tipi di route. Se nella rete VPC non esistono route basate su criteri, Google Cloud questo passaggio viene ignorato e si continua con il passaggio relativo alle route subnet.

    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 priorità più alta. Se le caratteristiche di un pacchetto non corrispondono a una route basata su criteri, Google Cloud ignora la route basata su criteri e continua a valutare la route basata su criteri successiva nell'elenco ordinato. La successiva route basata su criteri da valutare potrebbe condividere la stessa priorità della route basata su criteri ignorata oppure avere una priorità inferiore.

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

    • Se le caratteristiche di un pacchetto corrispondono a una route basata su criteri con priorità più elevata, Google Cloud ignora prima tutte le route basate su criteri con priorità inferiore. Se nell'elenco rimangono due o più route basate su criteri, Google Cloud valuta ciascuna delle route basate su criteri rimanenti con priorità identiche. Google Cloud ignora le 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 corrispondenti con priorità più alta, Google Cloud seleziona una singola route basata su criteri utilizzando un algoritmo interno. La route basata su policy 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 una sola route basata su criteri con priorità più alta configurata per ignorare altre route basate su criteri, Google Cloudignora tutte le route basate su criteri e continua con il passaggio route di subnet.

    • Se il modello di selezione delle route include una sola route basata su policy con la priorità più alta che non è configurata per ignorare altre route basate su policy, Google Cloud il pacchetto viene inviato al bilanciatore del carico di rete passthrough interno dell'hop successivo e vengono ignorate tutte le route non basate su policy.

  3. Route subnet: Google Cloud determina se la destinazione del pacchetto rientra nell'intervallo di destinazione di una route subnet locale, di peering o di Network Connectivity Center nella rete VPC.

    • Nessuna route di subnet corrispondente: se la destinazione di un pacchetto non corrisponde all'intervallo di destinazione di alcuna route di subnet, Google Cloud ignora tutte le route di subnet. Rimuovi tutte le route subnet dal modello di selezione delle route e continua con il passaggio Destinazione più specifica per valutare le route statiche e dinamiche.

    • Route subnet regolare corrispondente: per la maggior parte delle subnet, se la destinazione di un pacchetto corrisponde all'intervallo di destinazione di una route subnet regolare,Google Cloud utilizza esclusivamente la route subnet. Google CloudIgnora tutte le altre route e la valutazione si interrompe a questo passaggio. Se la destinazione del pacchetto non è associata a una risorsa o appartiene a un'istanza VM arrestata, il pacchetto viene eliminato.

    • Route di subnet ibrida corrispondente: se la destinazione di un pacchetto corrisponde all'intervallo di destinazione di una route di subnet ibrida e la destinazione corrisponde a un indirizzo IP associato a un'istanza VM in esecuzione o a una regola di forwarding interno, Google Cloudil pacchetto viene instradato utilizzando la route di subnet ibrida. Google CloudVengono ignorate tutte le altre route e la valutazione si interrompe a questo passaggio.

      Se la destinazione non corrisponde a una VM in esecuzione o a una regola di forwarding interno, consulta la sezione Risorse non corrispondenti nelle subnet ibride.

  4. Destinazione più specifica: all'inizio di questo passaggio, Google Cloud ha ignorato tutti i percorsi di routing speciali, le route basate su criteri e le route subnet.

    Google Cloud determina quali route statiche o dinamiche applicabili hanno la destinazione più specifica che contiene l'indirizzo IP di destinazione del pacchetto. Google Cloud Ignora tutte le route tranne quelle con la destinazione più specifica. Ad esempio, 10.240.1.0/24 è una destinazione più specifica di 10.240.0.0/16.

    Al termine di questo passaggio, il modello di selezione dell'itinerario contiene solo itinerari statici o dinamici con destinazioni identiche.

  5. Seleziona solo il tipo di route personalizzata più favorevole: in questo passaggio, Google Cloud vengono rimosse tutte le route personalizzate tranne il tipo di route personalizzata più favorevole. Le route personalizzate locali sono preferite rispetto alle route dinamiche di Network Connectivity Center e le route dinamiche di Network Connectivity Center sono preferite rispetto alle route personalizzate di peering.

    La seguente tabella riepiloga la logica utilizzata da Google Cloud in questo passaggio.

    Categoria di route personalizzata Che cosa succede
    Route dinamiche locali e route statiche locali

    Se il modello di route contiene almeno una route dinamica locale o una route statica locale per la destinazione, Google Cloud rimuove i seguenti tipi di route personalizzate, se presenti nel modello di route:

    • Route dinamiche di Network Connectivity Center dagli spoke ibridi, in reti VPC diverse
    • Route dinamiche di peering (importate da altre reti VPC connesse tramite peering di rete VPC)
    Route dinamiche di Network Connectivity Center Se sono soddisfatte tutte le seguenti condizioni, Google Cloud rimuove tutte le route dinamiche di peering e statiche di peering dal modello di route:
    • Il tuo modello di route non contiene route personalizzate locali per la destinazione
    • La modalità di routing contiene almeno una route dinamica Network Connectivity Center per la destinazione
    • La route dinamica di Network Connectivity Center proviene da uno spoke ibrido in una rete VPC diversa
    Route dinamiche di peering e route statiche di peering Il tipo di route personalizzata meno favorevole contiene route personalizzate di peering. Le route personalizzate di peering per la destinazione vengono utilizzate solo quando il modello di route non contiene route personalizzate locali o route dinamiche di Network Connectivity Center per la destinazione.

  6. Seleziona gli hop successivi per le route personalizzate di peering da una singola rete VPC: gli hop successivi per la stessa destinazione devono trovarsi nella stessa rete VPC. Questo passaggio si applica solo se il modello di route contiene route dinamiche o statiche di peering importate da due o più reti VPC diverse connesse tramite peering di rete VPC.

    Google Cloud utilizza un algoritmo interno per importare route personalizzate di peering da una singola rete VPC. La rete peer che Google Cloud seleziona potrebbe cambiare se la tua rete VPC esegue il peering con una nuova rete VPC o se si disconnette da una rete VPC peer esistente.

  7. Ignora route statiche e dinamiche con hop successivi inutilizzabili: questo passaggio simula situazioni in cui Google Cloud ignora gli hop successivi non funzionanti o non validi.

    • Specifica dell'indirizzo IP della VM hop successivo non valida: il next-hop-address di una route statica deve corrispondere a un indirizzo IP assegnato a una VM nella rete VPC della route. L'indirizzo IP deve essere assegnato all'interfaccia di rete della VM come uno dei seguenti:

      • Un indirizzo IPv4 interno principale
      • Un indirizzo IPv6 interno
      • Un indirizzo IPv6 esterno

      Se l'indirizzo IP specificato da next-hop-address corrisponde a un tipo diverso di risorsa (ad esempio un intervallo IP alias) o non corrisponde ad alcuna risorsa,Google Cloud ignora la route.

    • VM hop successivo arrestata o eliminata: Google Cloud ignora ogni route statica la cui istanza VM hop successivo è stata arrestata o eliminata. Questo comportamento si applica alle route i cui hop successivi sono specificati utilizzando next-hop-instance o next-hop-address. Per ulteriori informazioni, vedi Comportamento quando le istanze vengono arrestate o eliminate.

    • Specifica dell'indirizzo IP del bilanciatore del carico dell'hop successivo non valida: per le route statiche che hanno un bilanciatore del carico dell'hop successivo specificato dall'indirizzo IP, l'indirizzo IP deve corrispondere a una regola di forwarding di un bilanciatore del carico di rete passthrough interno che si trova nella rete VPC della route o in una rete VPC con peering. Se l'indirizzo IP dell'hop successivo corrisponde alla regola di forwarding di un tipo diverso di bilanciatore del carico o non corrisponde a nessuna regola di forwarding, Google Cloud ignora la route.

    • Tunnel VPN classica con hop successivo non stabilito: Google Cloud ignora ogni route statica con un tunnel VPN classica con hop successivo che non ha un'associazione di sicurezza (SA) di fase 1 (IKE) attiva. Per maggiori dettagli, consulta Ordine delle route nella documentazione di VPN classica.

    • Route dinamica con hop successivo non funzionante: anche prima che la sessione BGP responsabile della programmazione di una route dinamica non sia più attiva, Google Cloud ignora una route dinamica se il tunnel Cloud VPN, l'collegamento VLAN o la VM dell'appliance router dell'hop successivo non è funzionante. Questa situazione in genere esiste solo per pochi secondi prima che la route dinamica venga rimossa quando la sessione BGP del router Cloud corrispondente non è più disponibile.

    Google Cloud non verifica se il sistema operativo guest di una VM hop successivo o di una VM di backend per un bilanciatore del carico hop successivo sta elaborando i pacchetti. Per ulteriori informazioni, consulta Considerazioni comuni agli hop successivi del bilanciatore del carico di rete passthrough interno e delle istanze.

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

    Dopo questo passaggio, il modello di itinerario potrebbe essere vuoto o contenere uno o più itinerari. Se il modello non è vuoto, tutti i percorsi del modello hanno le seguenti caratteristiche:

    • Priorità identiche
    • Hop successivi non ignorati
    • Destinazioni identiche
    • Tipi di route che non sono route basate su policy o subnet

  9. Seleziona gli hop successivi per le route dinamiche di Network Connectivity Center da una singola rete VPC: gli hop successivi per la stessa destinazione devono trovarsi nella stessa rete VPC. Questo passaggio si applica solo se il modello di route contiene route dinamiche di Network Connectivity Center importate da due o più spoke ibridi che si trovano in reti VPC diverse.

    Google Cloud utilizza un algoritmo interno per importare le route dinamiche di Network Connectivity Center dagli spoke ibridi che si trovano in una singola rete VPC. Gli spoke ibridi selezionati potrebbero cambiare se aggiungi o rimuovi spoke ibridi dall'hub Network Connectivity Center. Per evitare questa ambiguità, assicurati che le route dinamiche di Network Connectivity Center abbiano priorità univoche quando si verifica quanto segue:

    • Le route hanno destinazioni identiche.
    • Le route vengono importate da due o più spoke ibridi in reti VPC diverse.

  10. Seleziona solo la categoria di preferenza più favorevole: Google Cloud non esegue il routing ECMP (Equal-cost multipath) tra le route che appartengono a categorie di preferenza diverse, come definito in questo passaggio.

    Categoria di preferenza Tipo di route e tipo di hop successivo
    Prima preferenza (la più preferita) Una o più route statiche con istanze di hop successivo (next-hop-instance o next-hop-address) o tunnel VPN classica di hop successivo.
    Seconda preferenza Una o più route dinamiche di un unico tipo.
    Terza scelta Una singola route statica con bilanciatore del carico di rete passthrough interno come hop successivo.
    Quarta preferenza (meno preferita) Una o più route statiche con hop successivo default-internet-gateway.

    In questo passaggio, quando esistono due o più route statiche con bilanciatore del carico dell'hop successivo, Google Cloud seleziona una singola route statica utilizzando un algoritmo internoGoogle Cloud non esegue ECMP tra più bilanciatori del carico. Per ulteriori informazioni, consulta Considerazioni per gli hop successivi del bilanciatore del carico di rete passthrough interno.

    Dopo questo passaggio, il modello di itinerario potrebbe essere vuoto o contenere uno o più itinerari. Se il modello non è vuoto, tutti i percorsi nel modello hanno le seguenti caratteristiche:

    • Categoria di preferenze identica
    • Priorità identiche
    • Hop successivi non ignorati
    • Hop successivi in una rete VPC
    • Destinazioni identiche
    • Tipi di route che non sono route basate su policy o subnet

  11. Invia o rilascia pacchetto: a seconda del numero di percorsi rimanenti nel modello di percorso, Google Cloud invia o rilascia il pacchetto:

    • Se il modello di route contiene una sola route, Google Cloud invia il pacchetto all'hop successivo, con la seguente eccezione:

      I bilanciatori del carico di rete passthrough interni dell'hop successivo che non hanno l'accesso globale abilitato non sono raggiungibili dalle regioni esterne alla regione del bilanciatore del carico. Di conseguenza, se un bilanciatore del carico di hop successivo non ha l'accesso globale abilitato, Google Cloud elimina tutti i pacchetti inviati da istanze VM, collegamenti VLAN e tunnel Cloud VPN in regioni diverse da quella del bilanciatore del carico. Per modificare questo comportamento, attiva l'accesso globale.

    • Se il modello di percorso contiene due o più percorsi, Google Cloud esegue ECMP, distribuendo i pacchetti tra gli hop successivi. La selezione dell'hop successivo dipende da un calcolo hash e dal numero 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 man mano che vengono inviati i pacchetti successivi, Google Cloud potrebbe indirizzare questi pacchetti a un hop successivo diverso anche se l'hash è lo stesso.

    • Se il modello di route è vuoto, Google Cloud elimina il pacchetto con un messaggio ICMP di tipo 3, codice 0 (rete non raggiungibile).

Risorse senza corrispondenza nelle subnet ibride

Se il modello di route contiene una route di subnet ibrida e la destinazione del pacchetto corrisponde a un indirizzo IP associato a una VM arrestata o non associato ad alcuna risorsa nella subnet ibrida, Google Cloud utilizza un processo diverso per instradare il pacchetto. I seguenti passaggi descrivono la procedura utilizzata da Google Cloud per instradare questi pacchetti:

  1. Identifica la rete VPC che contiene la subnet ibrida:

    • La subnet ibrida e la risorsa che invia pacchetti alla subnet ibrida potrebbero utilizzare la stessa rete VPC. In questo caso, la subnet ibrida crea una route di subnet locale corrispondente nella rete VPC.

    • La subnet ibrida e la risorsa che invia pacchetti alla subnet ibrida potrebbero trovarsi in reti VPC diverse connesse tramite peering di rete VPC. In questo caso, la subnet ibrida crea una route subnet di peering corrispondente nella rete VPC utilizzata dalla risorsa che invia i pacchetti.

  2. Inizia con tutte le route della rete VPC che contiene la subnet ibrida e poi rimuovi le seguenti route:

    • Tutte le route basate su policy
    • Tutte le route subnet
    • Tutte le route statiche con tag di rete
    • Tutte le route le cui destinazioni sono più ampie e contengono la route della subnet ibrida corrispondente nel primo modello di route

  3. Esegui i passaggi Destinazione più specifica e Seleziona solo la categoria di preferenza più favorevole nell'ordine di routing.

  4. Utilizza le seguenti regole per determinare se Google Cloud invia o elimina il pacchetto:

    • Se il modello di route contiene una singola route e l'hop successivo della route si trova nella stessa regione della subnet ibrida, Google Cloud invia il pacchetto all'hop successivo.

    • Se il modello di route contiene due o più route, Google Cloud esegue ECMP tra queste route. Quando un hop successivo si trova nella stessa regione della subnet ibrida, Google Cloud invia il pacchetto all'hop successivo.

    • Google Cloud elimina il pacchetto con un messaggio ICMP di tipo 3, codice 0 (rete non raggiungibile) se il modello di route è vuoto o se un hop successivo si trova in una regione diversa da quella della subnet ibrida.

    Le seguenti route hanno hop successivi in regioni diverse da quella della subnet ibrida, pertanto comportano sempre l'eliminazione dei pacchetti:

    • Route dinamiche apprese dai router Cloud in regioni diverse da quella della subnet ibrida, anche se la modalità di routing dinamico della rete VPC che contiene i router Cloud è globale
    • Route statiche con hop successivi in regioni diverse da quella della subnet ibrida, inclusi tutti i bilanciatori del carico di rete passthrough interni in regioni diverse, anche se hanno l'accesso globale abilitato

Passaggi successivi