Panoramica del router Cloud
Il router Cloud è un servizio Google Cloud completamente distribuito e gestito che utilizza il protocollo BGP (Border Gateway Protocol) per pubblicizzare intervalli di indirizzi IP. Programma route dinamiche personalizzate in base agli annunci BGP che riceve da un peer. Invece di un dispositivo fisico o un appliance, ogni router Cloud è costituito da attività software che fungono da speaker e risponditori BGP. Un router Cloud funge anche da piano di controllo per Cloud NAT. Il router Cloud fornisce servizi BGP per i seguenti prodotti Google Cloud:
- Dedicated Interconnect
- Partner Interconnect
- Cloud VPN, in particolare VPN ad alta disponibilità
- appliance router (parte di Network Connectivity Center)
Ogni router Cloud funziona con almeno uno dei prodotti per la connettività di rete elencati in precedenza.
Quando connetti una rete on-premise o multi-cloud a Google Cloud, il router Cloud utilizza BGP per scambiare dinamicamente le route tra la tua rete VPC di Google Cloud e la rete remota. Le modifiche al prefisso e all'hop successivo si propagano automaticamente tra la tua rete VPC e l'altra rete senza bisogno di route statiche.
Puoi anche utilizzare il router Cloud per connettere due reti VPC in Google Cloud. In questo scenario, connetti le reti VPC utilizzando due VPN ad alta disponibilità e due router Cloud, una VPN ad alta disponibilità e il relativo router Cloud associato su ogni rete.
Il peering diretto e il peering con operatori non utilizzano i router Cloud.
Specifiche
Un router Cloud può pubblicizzare route di subnet VPC e prefissi personalizzati nelle sue sessioni BGP. A meno che non configuri pubblicità di route personalizzate, un router Cloud pubblicizza solo le route di subnet VPC. Le pubblicità di route personalizzate consentono inoltre di configurare un router Cloud in modo da omettere le route di subnet VPC pubblicitarie.
La modalità di routing dinamico di una rete VPC, a livello di area geografica o globale, determina quale subnet VPC instrada i router Cloud della rete. Per maggiori dettagli, consulta Pubblicità di percorso predefinita.
La modalità di routing dinamico controlla inoltre il modo in cui ogni router Cloud applica i prefissi appresi come route dinamiche personalizzate in una rete VPC. Per maggiori dettagli su questo comportamento, consulta Effetti della modalità di routing dinamico.
Quando configuri BGP per Cloud Interconnect, VPN ad alta disponibilità ed appliance router, puoi facoltativamente configurare le sessioni di peering del router per l'autenticazione MD5.
Numero di sistema autonomo (ASN)
Quando crei un router Cloud, scegli l'ASN lato Google per tutte le sessioni BGP utilizzate dal router Cloud. Le indicazioni per ogni prodotto per la connettività di rete elencati nella sezione Risorse aggiuntive forniscono dettagli su come ciascun prodotto utilizza l'ASN.
Indirizzi IP di peering BGP
Le sessioni BGP per i seguenti prodotti di connettività di rete utilizzano indirizzi IPv4 link-local nell'intervallo 169.254.0.0/16 come indirizzi IP di peering BGP:
- Per Dedicated Interconnect, puoi specificare indirizzi candidati locali tramite link per gli indirizzi di peering BGP oppure Google Cloud può selezionare automaticamente gli indirizzi link-locali non utilizzati.
- Per Partner Interconnect, Google Cloud seleziona automaticamente gli indirizzi IPv4 locali non collegati che non utilizzano.
- Per la VPN ad alta disponibilità e la VPN classica che utilizzano il routing dinamico, puoi specificare gli indirizzi IP di peering BGP quando crei l'interfaccia BGP sul router Cloud.
Le appliance dei router utilizzano indirizzi IPv4 interni delle VM Google Cloud come indirizzi IP BGP. Per i dettagli, consulta Creazione di istanze di appliance router.
Accesso ai bilanciatori del carico interni
Per i dettagli su come accedere ai bilanciatori del carico interni da una rete on-premise connessa, consulta la pagina relativa ai bilanciatori del carico interni e delle reti connesse nella documentazione di Cloud Load Balancing.
Supporto IPv6
Il router Cloud supporta il protocollo BGP multiprotocollo (MP-BGP) e può scambiare i prefissi IPv6 tramite le sessioni IPv4 BGP. Le sessioni IPv6 BGP non sono supportate.
Il router Cloud pubblicizza i prefissi IPv6 per le reti VPC che includono subnet a doppio stack. Per impostazione predefinita, gli intervalli di subnet IPv6 interni sono pubblicizzati automaticamente. Gli intervalli di subnet IPv6 esterni non vengono pubblicizzati automaticamente, ma puoi pubblicizzarli manualmente utilizzando gli annunci di route personalizzati.
Puoi abilitare lo scambio di prefissi IPv6 nelle sessioni BGP create per i tunnel VPN ad alta disponibilità. Per maggiori dettagli, consulta i seguenti documenti:
- Crea una VPN ad alta disponibilità con un gateway VPN peer
- Crea una VPN ad alta disponibilità connesso a un altro gateway VPN ad alta disponibilità
- Abilita o disabilita lo scambio di prefissi IPv6 nelle sessioni IPv4 BGP
Per maggiori dettagli sulla visualizzazione delle route IPv6, consulta Modalità pubblicitarie route.
Limiti IPv6
Lo scambio del prefisso IPv6 non è supportato nelle sessioni BGP per le seguenti risorse:
- Collegamenti VLAN Dedicated Interconnect
- Collegamenti VLAN partner Interconnect
- Tunnel VPN classici
- Appliance router (parte di Network Connectivity Center)
Attività software del router Cloud
I router Cloud vengono implementati da una, due o, in rari casi, da tre attività software.
La tabella seguente fornisce scenari di esempio e il numero di attività software utilizzate da Google Cloud per implementare il router Cloud in ogni scenario.
- Per le configurazioni ad alta disponibilità elencate nella tabella, vengono utilizzate due attività software per fornire la ridondanza del software.
- Per i collegamenti VLAN, un'attività software separata gestisce ogni dominio di disponibilità perimetrale con collegamenti.
| Scenario di esempio | Numero di attività software utilizzate per implementare il router Cloud |
|---|---|
| Una o più interfacce, ognuna collegata a un tunnel VPN classico. | Uno |
| Una o più interfacce, ciascuna collegata a un collegamento VLAN, in cui i collegamenti VLAN si trovano nello stesso dominio di disponibilità perimetrale. | Uno |
Qualsiasi numero di interfacce, ciascuna collegata a un tunnel VPN ad alta disponibilità, in cui i tunnel sono tutti collegati allo stesso numero di interfaccia su uno o più gateway VPN ad alta disponibilità, ad esempio due tunnel, ognuno collegato a interface 0 su diversi gateway VPN ad alta disponibilità. |
Uno |
| Almeno due interfacce, una collegata a un collegamento VLAN in un singolo dominio di disponibilità perimetrale e l'altra connessa a un singolo tunnel VPN ad alta disponibilità, in cui il numero di domini relativi alla disponibilità perimetrale e quello del gateway VPN sono uguali. Ad esempio, il primo dominio di disponibilità perimetrale in una coppia di domini di disponibilità perimetrale e la prima interfaccia gateway VPN. | Uno |
Almeno due interfacce, ognuna collegata a un'istanza di appliance di router, dove una delle interfacce è configurata come interfaccia ridondante. Per
creare un'interfaccia ridondante, utilizza il flag
redundant-interface (Google Cloud CLI) o il campo redundantInterface
(API Compute Engine). L'appliance router fa parte di Network Connectivity Center. |
Due |
| Almeno due interfacce, ciascuna collegata a un collegamento VLAN, in cui i collegamenti VLAN si trovano in domini di disponibilità perimetrale diversi. | Due |
Almeno due interfacce, ciascuna collegata a un tunnel VPN ad alta disponibilità, in cui ogni tunnel è collegato a numeri di interfaccia gateway VPN ad alta disponibilità, ad esempio un tunnel collegato a interface 0 di un gateway VPN ad alta disponibilità e un altro tunnel collegato a interface 1 dello stesso gateway o di un altro gateway.
|
Due |
Un router Cloud con almeno quanto segue:
|
Tre |
Manutenzione di software e riavvii automatici delle attività
Google Cloud esegue eventi di manutenzione regolari per rilasciare nuove funzionalità e migliorare l'affidabilità. Durante la manutenzione viene eseguito il provisioning di nuove attività software. I log del router on-premise indicano che le sessioni BGP gestite da tali attività software sono diminuite e si sono riprese (flap BGP).
La manutenzione del router Cloud è un processo automatico ed è progettata in modo da non interrompere il routing. Gli eventi di manutenzione non dovrebbero durare più di 60 secondi. Prima della manutenzione, il router Cloud invia una bella notifica di riavvio (un pacchetto TCP FIN) al router on-premise.
Se il router on-premise può elaborare eventi di riavvio graceful, registra un evento di riavvio controllato durante la manutenzione del router Cloud. Per i router on-premise che non supportano il riavvio controllato, assicurati che il timer di blocco del router on-premise sia impostato su 60 secondi. Per maggiori dettagli, consulta Gestire i timer BGP.
Gli eventi di manutenzione del router Cloud non vengono annunciati in anticipo perché i percorsi non vengono persi sui router on-premise configurati correttamente. Per informazioni dettagliate sugli eventi di manutenzione completati, consulta la sezione Identificare gli eventi di manutenzione del router.
Per informazioni sul funzionamento corretto del riavvio con BFD (Bidirectional Forwarding Detection), consulta Riavvio rapido e BFD.
Indirizza le modalità pubblicitarie
Utilizzando BGP e un prodotto per la connettività di rete elencato nella sezione Risorse aggiuntive, un router Cloud pubblicizza gli intervalli di indirizzi IP sulla tua rete on-premise. In questo modo, i client nella rete on-premise possono inviare e ricevere pacchetti dalle risorse della rete VPC.
Il router Cloud offre due modalità pubblicitarie per la route: annunci di route predefinite e annunci di route personalizzati.
Annuncio di percorso predefinito
L'utilizzo della pubblicità di route predefinita configura un router Cloud o una sessione BGP per pubblicizzare i prefissi per i seguenti tipi di intervalli di indirizzi IP di subnet. La modalità di routing dinamico della rete VPC determina se gli intervalli di indirizzi IP delle subnet pubblicizzati provengono solo dalla stessa regione del router Cloud o se provengono da tutte le regioni:
Modalità di routing dinamico per area geografica: ogni router Cloud nella rete VPC pubblicizza gli intervalli di subnet IPv4 principali e secondari nella stessa regione del router Cloud. Se vengono soddisfatte le condizioni per la pubblicità IPv6, il router Cloud pubblicizza gli intervalli di subnet IPv6 interni (
ipv6-access-type=INTERNAL) nella stessa regione del router Cloud.Modalità di routing dinamico globale: ogni router Cloud nella rete VPC pubblicizza intervalli di subnet IPv4 primari e secondari da tutte le regioni della rete VPC. Se vengono soddisfatte le condizioni per la pubblicità IPv6, il router Cloud pubblicizza gli intervalli di subnet IPv6 interni (
ipv6-access-type=INTERNAL) da tutte le regioni della rete VPC.
Se pubblicizzi annunci IPv4 pubblici utilizzati privatamente, i sistemi on-premise potrebbero non essere in grado di accedere alle risorse Internet che utilizzano tali indirizzi IPv4 pubblici.
Gli annunci di route di subnet vengono aggiornati automaticamente, come descritto nella sezione Aggiornamenti automatici per gli annunci di route di subnet.
Annuncio di percorso personalizzato
La pubblicità personalizzata del percorso ti consente di controllare i prefissi pubblicizzati da un router Cloud. Puoi specificare annunci di route personalizzati
(inclusi i prefissi di percorso predefiniti, 0.0.0.0/0 o ::/0) per tutte le sessioni BGP
su un router Cloud o in base a sessioni BGP. Esistono due categorie di annunci di route personalizzate:
Puoi pubblicizzare solo prefissi IPv4 e IPv6 personalizzati. Questo tipo di pubblicità personalizzata omette le route di subnet che verranno pubblicizzate utilizzando la pubblicità di route predefinita.
Puoi pubblicizzare prefissi IPv4 e IPv6 personalizzati oltre ai route di subnet. Questo tipo di pubblicità personalizzata include gli stessi percorsi di subnet pubblicizzati utilizzando Annuncio di percorso predefinito.
Se scegli di pubblicizzare route di subnet, i loro annunci vengono aggiornati automaticamente come descritto in Aggiornamenti automatici per gli annunci di route di subnet.
Se le condizioni per la pubblicità IPv6 sono soddisfatte, il router Cloud pubblicizza gli intervalli di subnet IPv6 interni ogni volta che scegli di pubblicizzare le route di subnet. Devi aggiungere degli intervalli di subnet IPv6 esterni al tuo elenco di prefissi personalizzati per poterli pubblicizzare.
Per il numero massimo di prefissi personalizzati che possono essere pubblicizzati in ogni sessione BGP, consulta la pagina sul numero massimo di annunci di route personalizzati per sessione BGP nella pagina dei limiti del router Cloud. Questo valore massimo si applica agli annunci personalizzati per l'intero router Cloud e singolarmente per sessione BGP.
Per maggiori informazioni, consulta i seguenti documenti:
Prefissi pubblicizzati effettivi
La modalità pubblicitaria del percorso può essere configurata sia sull'intero router Cloud sia sulle singole sessioni BGP del router Cloud. La tabella seguente descrive quali prefissi vengono pubblicizzati nella sessione BGP, in base alla modalità pubblicitaria selezionata del router Cloud e della sessione BGP.
| Modalità per il router Cloud | Modalità per sessione BGP | Prefissi pubblicizzati effettivi nella sessione BGP |
|---|---|---|
| predefinito | predefinito | La sessione BGP eredita la configurazione del router Cloud. Le route di subnet sono pubblicizzate come descritto in Annuncio di route predefinito. |
| custom | predefinito | La sessione BGP eredita la configurazione del router Cloud. Le route personalizzate configurate sull'intero router Cloud sono pubblicizzate come descritto in Annuncio di route personalizzato. Le route personalizzate possono contenere alcune o tutte le route di subnet. |
| valore predefinito o personalizzato | custom | La sessione BGP non eredita la configurazione del router Cloud. Le route personalizzate configurate nella sessione BGP stessa sono pubblicizzate come descritto in Annuncio di route personalizzato. Le route personalizzate possono contenere alcune o tutte le route di subnet. |
Aggiornamenti automatici per gli annunci di route di subnet
Il router Cloud aggiorna automaticamente gli annunci di route di subnet nelle seguenti situazioni:
Quando crei una subnet solo IPv4
Quando crei una subnet a doppio stack con IPv6 interno abilitato
Quando elimini una subnet
Quando attivi l'IPv6 interno su una subnet solo IPv4 esistente
Quando modifichi gli intervalli IPv4 secondari di una subnet
Condizioni per la pubblicità IPv6
Il router Cloud può pubblicizzare route IPv6 quando tutte le seguenti condizioni sono soddisfatte:
- Il prodotto per la connettività di rete utilizzato con il router Cloud, come il gateway VPN ad alta disponibilità, è configurato per l'utilizzo del tipo di stack doppio IPv4 e IPv6.
- La sessione BGP è configurata in modo specifico per abilitare lo scambio di prefissi IPv6. Vedi Attivare o disattivare lo scambio di prefissi IPv6.
Per pubblicizzare gli intervalli di subnet IPv6 interni, la rete VPC deve avere un intervallo IPv6 interno assegnato (ULA) e deve essere creata almeno una subnet a doppio stack con un intervallo di subnet IPv6 interno.
Prefissi e priorità pubblicizzati
Quando un router Cloud pubblicizza i prefissi per un peer BGP, include una priorità per ciascun prefisso nella pubblicità (messaggio BGP). La priorità pubblicizzata viene implementata come MED.
Puoi controllare quali prefissi router Cloud Router in tutte o in alcune delle sue sessioni BGP. Puoi controllare la priorità annunciata (MED) definendo una priorità di base per i prefissi.
Se la tua rete VPC utilizza la modalità di routing dinamico a livello di regione, a meno che non pubblicizzi intervalli personalizzati, ogni router Cloud pubblicizza solo gli intervalli di subnet nella stessa regione del router Cloud. Ogni intervallo viene pubblicizzato come prefisso e il MED è la priorità di base.
Se la tua rete VPC utilizza la modalità di routing dinamico globale, a meno che non pubblicizzi intervalli personalizzati, ogni router Cloud pubblicizza gli intervalli di subnet della sua regione locale come prefissi il cui MED corrisponde alla priorità di base. Inoltre, i router Cloud pubblicizzano gli intervalli di subnet di aree geografiche diverse come prefissi i cui MED corrispondono alla priorità di base più un costo per area geografica. Google Cloud calcola automaticamente un costo per area geografica in base a fattori come prestazioni della rete, distanza e larghezza di banda disponibile tra le aree geografiche. Ogni costo per regione ha un valore specifico per una coppia di regioni: la regione della subnet e la regione del router Cloud pubblicitario.
Quando i router on-premise ricevono i prefissi pubblicizzati e le relative priorità, creano route che vengono utilizzate per inviare pacchetti alla rete VPC.
Indicazioni per le priorità di base
Quando configuri una sessione BGP su un router Cloud, puoi specificare una priorità annunciata di base per la sessione BGP. La priorità pubblicizzata di base si applica a tutti i prefissi (destinazioni) pubblicizzati dalla sessione BGP.
Le priorità di base sono i numeri interi compresi tra 0 e 65535.
La priorità di base più alta è 0. La priorità di base predefinita è 100.
Se non specifichi una priorità di base, verrà utilizzata la priorità predefinita.
Le priorità di base consentono di controllare quali tunnel Cloud VPN o i collegamenti VLAN sono utilizzati da sistemi on-premise per inviare pacchetti alla tua rete VPC. Puoi creare attivo/attivo, attivo/passivo o una combinazione personalizzata di queste topologie utilizzando la priorità di base. Per un esempio che utilizza i tunnel VPN ad alta disponibilità, consulta Opzioni di routing attive/attive e attive/passive per la VPN ad alta disponibilità nella documentazione di Cloud VPN.
Quando scegli le priorità di base, tieni presente quanto segue:
I costi da area geografica a regione sono compresi tra
201e9999compresi. Il valore dipende dalla distanza, dalla latenza e da altri fattori tra due regioni. Google genera i valori di costo per area geografica e non puoi modificarli.Le priorità di base per le sessioni BGP tra i router Cloud in una regione devono essere comprese tra
0e200compresi. Poiché i costi da regione a regione sono almeno201, se usi le priorità di base di201o più, potresti assegnare accidentalmente un tunnel Cloud VPN o un collegamento VLAN a una priorità inferiore a quella prevista. Un'altra sessione BGP in un'altra area geografica potrebbe pubblicizzare lo stesso prefisso con una priorità complessiva più elevata (MED, che equivale alla priorità di base più il costo per regione). Se non imposti con attenzione le priorità di base in altre aree geografiche, potresti causare la distribuzione del traffico on-premise alla tua rete VPC mediante un tunnel Cloud VPN o un collegamento VLAN imprevisti.Le priorità di base di
10,200o più garantiscono che la priorità pubblicizzata complessiva di un prefisso (MED, priorità di base più costo per regione) sia sempre inferiore a qualsiasi altro prefisso pubblicizzato con priorità di base pari o inferiore a200.
Per ulteriori informazioni sull'impostazione di una priorità di base, consulta Aggiornare la priorità di base della route annunciata.
Esempi
Questa sezione fornisce esempi che mostrano in che modo i costi regionali per le regioni influenzano i MED pubblicizzati quando utilizzi il routing dinamico globale.
VPN ad alta disponibilità con tunnel attivi/attivi
In questo esempio, hai una rete VPC con quanto segue:
- Una subnet in ciascuna delle seguenti regioni:
us-central1,europe-west1eus-west-1 - Un router Cloud che gestisce due sessioni BGP per due tunnel VPN ad alta disponibilità in
us-central1 - Un router Cloud che gestisce due sessioni BGP per due tunnel VPN ad alta disponibilità in
us-west1
Per un'illustrazione di questo esempio, consulta il seguente diagramma, che include valori di esempio per il costo per singola regione.
Supponiamo che ogni sessione BGP abbia la priorità base predefinita di 100.
Le seguenti tabelle mostrano come vengono utilizzate le priorità di base e i costi da regione a regione per calcolare i valori MED pubblicizzati per il traffico dalla tua rete on-premise a ogni subnet.
10.0.1.0/24 (us-central1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.1.0/24, che si trova in us-central1.
Il traffico dalla tua rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-central1 perché le sue sessioni BGP hanno il numero MED pubblicizzato più basso.
| Tunnel VPN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 e central-tunnel-1 |
100 | 0 | 100 | Prima scelta |
west-tunnel-0 e west-tunnel-1 |
100 | 250 | 350 | Seconda scelta |
10.0.2.0/24 (europe-west1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.2.0/24, che si trova in europe-west1.
Il traffico dalla tua rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-central1 perché le sue sessioni BGP hanno il numero MED pubblicizzato più basso.
| Tunnel VPN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 e central-tunnel-1 |
100 | 300 | 400 | Prima scelta |
west-tunnel-0 e west-tunnel-1 |
100 | 350 | 450 | Seconda scelta |
10.0.3.0/24 (us-west1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.3.0/24, che si trova in us-west1.
Il traffico dalla tua rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-west1 perché le sue sessioni BGP hanno il numero MED pubblicizzato più basso.
| Tunnel VPN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 e central-tunnel-1 |
100 | 250 | 350 | Seconda scelta |
west-tunnel-0 e west-tunnel-1 |
100 | 0 | 100 | Prima scelta |
VPN ad alta disponibilità con tunnel attivi/passivi
Questo esempio utilizza la stessa topologia dell'esempio precedente, ma con priorità di base modificate per ottenere una coppia di tunnel VPN ad alta disponibilità/passiva in ogni area geografica:
- Un tunnel principale la cui sessione BGP ha la priorità di base predefinita
100 - Un tunnel secondario la cui sessione BGP ha una priorità inferiore a
351
Le seguenti tabelle mostrano come vengono utilizzate le priorità di base e i costi da regione a regione per calcolare i valori MED pubblicizzati per il traffico dalla tua rete on-premise a ogni subnet.
10.0.1.0/24 (us-central1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.1.0/24, che si trova in us-central1.
Il traffico dalla tua rete on-premise utilizza il tunnel VPN principale in us-central1 perché la sua sessione BGP ha il numero MED pubblicizzato più basso. Se questo tunnel non è disponibile, il traffico utilizza il tunnel principale in us-west1.
| Tunnel VPN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 |
100 | 0 | 100 | Prima scelta |
central-tunnel-1 |
351 | 0 | 351 | Terza scelta |
west-tunnel-0 |
100 | 250 | 350 | Seconda scelta |
west-tunnel-1 |
351 | 250 | 601 | Quarta scelta |
10.0.2.0/24 (europe-west1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.2.0/24, che si trova in europe-west1.
Il traffico dalla tua rete on-premise utilizza il tunnel VPN principale in us-central1 perché la sua sessione BGP ha il numero MED pubblicizzato più basso. Se questo tunnel non è disponibile, il traffico utilizza il tunnel principale in us-west1.
| Tunnel VPN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 |
100 | 300 | 400 | Prima scelta |
central-tunnel-1 |
351 | 300 | 651 | Terza scelta |
west-tunnel-0 |
100 | 350 | 450 | Seconda scelta |
west-tunnel-1 |
351 | 350 | 701 | Quarta scelta |
10.0.3.0/24 (us-west1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.3.0/24, che si trova in us-west1.
Il traffico dalla tua rete on-premise utilizza il tunnel VPN principale in us-west1 perché la sua sessione BGP ha il numero MED pubblicizzato più basso. Se questo tunnel non è disponibile, il traffico utilizza il tunnel principale in us-central1.
| Tunnel VPN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 |
100 | 250 | 350 | Seconda scelta |
central-tunnel-1 |
351 | 250 | 601 | Quarta scelta |
west-tunnel-0 |
100 | 0 | 100 | Prima scelta |
west-tunnel-1 |
351 | 0 | 351 | Terza scelta |
Dedicated Interconnect preferito a livello globale
Questo esempio è simile a quelli precedenti, ad eccezione del fatto che hai sostituito i due tunnel Cloud VPN nella regione us-west1 con due collegamenti VLAN.
Per un'illustrazione di questo esempio, guarda il diagramma seguente.
Vuoi dare la priorità ai collegamenti VLAN. Specifica priorità di base maggiori per i tunnel VPN ad alta disponibilità nella regione us-central1 per darne una priorità.
Le seguenti tabelle mostrano come vengono utilizzate le priorità di base e i costi da regione a regione per calcolare i valori MED pubblicizzati per il traffico dalla tua rete on-premise a ogni subnet.
10.0.1.0/24 (us-central1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.1.0/24, che si trova in us-central1.
Il traffico dalla tua rete on-premise utilizza il collegamento VLAN in
us-west1 perché le sue sessioni BGP hanno il numero MED pubblicizzato più basso.
| Tunnel VPN o collegamento VLAN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 e central-tunnel-1 |
351 | 0 | 351 | Seconda scelta |
west-attachment-0 e west-attachment-1 |
100 | 250 | 350 | Prima scelta |
10.0.2.0/24 (europe-west1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.2.0/24, che si trova in europe-west1.
Il traffico dalla tua rete on-premise utilizza il collegamento VLAN in
us-west1 perché le sue sessioni BGP hanno il numero MED pubblicizzato più basso.
| Tunnel VPN o collegamento VLAN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 e central-tunnel-1 |
351 | 300 | 651 | Seconda scelta |
west-attachment-0 e west-attachment-1 |
100 | 350 | 450 | Prima scelta |
10.0.3.0/24 (us-west1)
Questa tabella mostra le sessioni BGP che pubblicizzano l'intervallo di indirizzi IP della subnet
10.0.3.0/24, che si trova in us-west1.
Il traffico dalla tua rete on-premise utilizza il collegamento VLAN in
us-west1 perché le sue sessioni BGP hanno il numero MED pubblicizzato più basso.
| Tunnel VPN o collegamento VLAN | Priorità di base | Costo per regione | MED pubblicizzato | Ranking del percorso |
|---|---|---|---|---|
central-tunnel-0 e central-tunnel-1 |
351 | 250 | 601 | Seconda scelta |
west-attachment-0 e west-attachment-1 |
100 | 0 | 100 | Prima scelta |
Route dinamiche personalizzate apprese
Quando un router Cloud riceve più hop successivi per lo stesso prefisso di destinazione, Google Cloud utilizza le metriche delle route e, in alcuni casi, la lunghezza del percorso AS per creare route dinamiche personalizzate nella rete VPC. Nelle sezioni che seguono viene descritta questa procedura.
Effetti della modalità di routing dinamico
La modalità di routing dinamico di una rete VPC determina la modalità di applicazione delle route dinamiche personalizzate apprese dai router Cloud:
In modalità di routing dinamico a livello di regione, il router Cloud crea una route dinamica personalizzata per la destinazione e l'hop successivo nella stessa regione del router Cloud. Il router Cloud imposta la priorità per quella route dinamica personalizzata sulla priorità di base, che il router Cloud deriva dal discriminatore multi-exit (MED) pubblicizzato dal router on-premise.
In modalità di routing dinamico globale, il router Cloud crea un percorso dinamico personalizzato per la destinazione e l'hop successivo in ogni regione Google Cloud. Nella regione che contiene il router Cloud che ha imparato la route, il router Cloud imposta la priorità per la route dinamica personalizzata sulla priorità di base. In tutte le altre aree geografiche, il router Cloud imposta la priorità sulla priorità di base più un costo adeguato per regione.
Puoi definire la priorità delle route a Google Cloud esportate nel router on-premise. Tuttavia, il router on-premise potrebbe sostituire questa priorità di percorso, a seconda della sua configurazione, ad esempio se il router on-premise modifica la priorità di routing.
Per le route to-premise apprese dal router Cloud, il router Cloud riceve la lunghezza del percorso AS e i valori MED, quindi calcola una priorità di base come descritto nelle due sezioni successive.
Pre-percorso AS e lunghezza del percorso AS
L'annullamento del percorso AS è un mezzo per cui un hop successivo per una destinazione (prefisso) viene intenzionalmente ridotto in modo che venga selezionato un hop successivo diverso per la stessa destinazione con una lunghezza del percorso AS minore. MED viene considerato solo quando le lunghezze dei percorsi AS degli hop successivi sono uguali.
Google Cloud può utilizzare il percorso AS per selezionare un hop successivo tra le sessioni BGP implementate dalla stessa attività software del router Cloud.
In che modo Google Cloud utilizza il percorso AS
La precedenza dei percorsi AS non è rilevante per il piano di controllo e la rete VPC. La lunghezza del percorso AS viene presa in considerazione solo all'interno di ogni attività software del router Cloud, come descritto nei seguenti scenari.
Se una singola attività software del router Cloud impara la stessa destinazione da due o più sessioni BGP:
- L'attività software sceglie una sessione BGP dell'hop successivo con la lunghezza del percorso AS più breve.
- L'attività software invia le informazioni sulla destinazione, sull'hop successivo e sulla MED al piano di controllo del router Cloud.
- Il piano di controllo utilizza le informazioni per creare una o più route candidati. La priorità di base di ogni candidato è impostata sul valore MED ricevuto.
Se due o più attività software del router Cloud imparano la stessa destinazione da due o più sessioni BGP:
- Ogni attività software sceglie una sessione BGP dell'hop successivo con la lunghezza del percorso AS più breve.
- Ogni attività software invia informazioni sulla destinazione, sull'hop successivo e sull'MED al piano di controllo del router Cloud.
- Il piano di controllo utilizza le informazioni per creare due o più route candidati. La priorità di base di ogni candidato è impostata sul valore MED ricevuto.
Il piano di controllo del router Cloud installa quindi una o più route dinamiche personalizzate nella rete VPC, in base alla modalità di routing dinamico della rete VPC. Nella modalità di routing dinamico globale, la priorità di ogni route dinamica personalizzata viene modificata in regioni diverse dalla regione del router Cloud. Per maggiori dettagli su come Google Cloud seleziona una route, consulta la sezione Ordine di routing nella documentazione VPC.
Priorità di base, MED e origine
Il router Cloud utilizza il valore MED pubblicizzato dal router peer per calcolare la priorità di base:
- Se il valore MED per il prefisso di una destinazione è compreso tra
0e231 -1(inclusi), il router Cloud imposta la priorità di base sul valore MED. - Se il valore MED del prefisso di una destinazione è compreso tra
231e232 -1(inclusi), il router Cloud imposta la priorità di base su231 -1.
Affinché MED abbia effetto durante la selezione del percorso migliore tra più route apprese per la stessa destinazione, il valore dell'attributo dell'origine BGP per le route ricevute deve essere lo stesso. In caso contrario, la selezione avviene in base al valore dell'attributo origine, che precede il passaggio di confronto MED nel miglior processo di selezione del percorso (RFC 4271).
Il router Cloud pubblicizza le route BGP per i suoi peer con il valore dell'attributo origine impostato su Incomplete. Questo è il tipo di origine meno preferito nella selezione della route.
Il valore di priorità finale impostato dal router Cloud quando crea route dinamiche personalizzate in una rete VPC dipende dalla modalità di routing dinamico della rete. Per maggiori informazioni, consulta Effetti della modalità di routing dinamico.
Route statiche
Quando un'istanza invia un pacchetto, Google Cloud tenta di selezionare un percorso dal set di route applicabili in base all'ordine di routing. Per i dettagli, consulta la sezione Ordine di routing nella documentazione VPC.
Intervalli IP sovrapposti
Nei casi in cui hai una subnet VPC e una pubblicità di route on-premise con intervalli IP sovrapposti, Google Cloud indirizza il traffico in uscita in base ai propri intervalli IP.
Per saperne di più, consulta Route applicabili nella documentazione di VPC.
Trasferimento dati site-to-site
Se devi trasferire dati tra due siti esterni a Google Cloud, utilizza il Network Connectivity Center. Network Connectivity Center funziona con il router Cloud per consentirti di pubblicizzare dinamicamente le route tra le sessioni BGP.
Il router Cloud da solo non supporta questa funzionalità (in modo dinamico o configurando pubblicità di route personalizzate che corrispondono ai prefissi appresi). Se aggiungi una route di route personalizzata a una sessione BGP e questa si sovrappone a una route appresa da un'altra sessione BGP, la route appresa potrebbe essere eliminata.
Limiti per le route apprese
Esistono due limiti per i percorsi appresi. Questi limiti non definiscono direttamente un numero massimo di route apprese. ma il loro numero massimo di prefissi di destinazione univoci garantiti. Per informazioni su questi limiti, consulta Limiti.
Le route IPv4 e IPv6 vengono conteggiate per lo stesso valore massimo e non hanno limiti separati.
Per monitorare l'utilizzo in base a questi limiti, utilizza le seguenti metriche:
router.googleapis.com/dynamic_routes/learned_routes/used_unique_destinationsrouter.googleapis.com/dynamic_routes/learned_routes/unique_destinations_limitrouter.googleapis.com/dynamic_routes/learned_routes/any_dropped_unique_destinations
Per informazioni sui messaggi di log relativi a questi limiti, sulle metriche che puoi utilizzare per monitorarli e su come risolvere i problemi, consulta la pagina Verificare quote e limiti nella pagina Risoluzione dei problemi.
Percorso predefinito
Quando non è specificata alcuna route per una determinata destinazione IP, il traffico viene inviato a una route predefinita, che funge da ultima risorsa quando non esistono altre opzioni. Ad esempio, le reti VPC di Google Cloud includono automaticamente una route predefinita che invia il traffico al gateway Internet. La route predefinita solo per IPv4 è 0.0.0.0/0 e per il doppio stack IPv4 e IPv6 è 0.0.0.0/0, ::/0.
A volte, potresti voler che il traffico venga indirizzato alla tua rete on-premise per impostazione predefinita. Per farlo, puoi pubblicizzare una route predefinita dal tuo router on-premise al router Cloud. Con il router Cloud, non è necessario creare e gestire le route statiche. Se pubblicizzi una route predefinita dalla tua rete on-premise, controlla che abbia la priorità su altre route predefinite create automaticamente (ha un valore MED inferiore). Vai alla pagina Route e visualizza la priorità per le route con 0.0.0.0/0 nell'intervallo IP di destinazione e visualizza Default internet gateway nell'hop successivo.
Tunnel Cloud VPN ridondante
Se il gateway on-premise non supporta il riavvio controllato, un errore in entrambi i lati della sessione BGP provoca la mancata riuscita della sessione e il traffico viene interrotto. Una volta superato il timeout BGP, che è di 60 secondi per il router Cloud, le route vengono ritirate da entrambi i lati.
Senza il supporto del riavvio controllato, il deployment di due gateway on-premise con un unico tunnel fornisce ridondanza e failover ciascuno. Questa configurazione consente a un tunnel e ai suoi dispositivi di andare offline per upgrade o manutenzione di software senza interrompere il traffico. Inoltre, in caso di errore di un tunnel, l'altro può mantenere attivi i percorsi e il traffico.
Eventi di manutenzione
Il router Cloud viene sottoposto a operazioni di manutenzione periodica che richiedono meno di 60 secondi. Il router Cloud non è disponibile durante gli eventi di manutenzione. Il timer di blocco BGP determina per quanto tempo le route apprese vengono conservate quando il router BGP in peering non è disponibile. Il timer di blocco BGP viene negoziato in modo da essere il valore più basso dei due valori su entrambi i lati. Il router Cloud utilizza un valore di 60 secondi (per impostazione predefinita) per il timer di blocco BGP. Ti consigliamo di impostare un tempo di attesa per il BGP su un router on-premise (peer) di almeno 60 secondi. Di conseguenza, entrambi i router mantengono i propri percorsi durante questi upgrade e il traffico continua a fluire.
Durante i cicli di manutenzione del gateway Cloud VPN con un singolo gateway Cloud VPN, l'uso del router Cloud aggiunge circa 20 secondi al tempo di recupero del tunnel perché la sessione BGP viene reimpostata e le route devono essere reimparate. I tempi di recupero del gateway Cloud VPN sono in genere di circa un minuto. Se sono presenti gateway Cloud VPN ridondanti, il traffico non viene interessato perché viene rimosso un solo gateway Cloud VPN alla volta.
Riavvio dell'ID router BGP e della sessione BGP
Il router Cloud seleziona il suo indirizzo IP con l'interfaccia più alta per il suo ID router BGP e lo conserva per tutto il tempo in cui è disponibile. Se elimini l'interfaccia del router Cloud che viene utilizzata per l'ID router BGP, il router Cloud deve selezionare un nuovo ID router. Questa selezione determina il riavvio di tutte le sessioni BGP. L'ID router può cambiare anche se il router Cloud viene riavviato per manutenzione periodica.
Risorse aggiuntive
Per ulteriori informazioni sull'utilizzo del routing statico e dinamico con un servizio supportato, consulta la seguente documentazione.
| Prodotto | Routing | Documentazione |
|---|---|---|
| Dedicated Interconnect | Richiede il routing dinamico con il router Cloud | Creazione di collegamenti VLAN |
| Partner Interconnect | Richiede il routing dinamico con il router Cloud | Creazione di collegamenti VLAN |
| Appliance router | Richiede il routing dinamico con il router Cloud | Creazione di istanze dell'appliance router |
| VPN ad alta disponibilità | Richiede il routing dinamico con il router Cloud |
Creazione di un gateway VPN ad alta disponibilità connesso a un gateway VPN peer Creazione di una VPN ad alta disponibilità tra reti Google Cloud |
| VPN classica | Il routing dinamico con il router Cloud è facoltativo | Creazione di una VPN classica con routing dinamico Creazione di una VPN classica con routing statico |
Passaggi successivi
Per creare la topologia di rete con il router Cloud, consulta le best practice.
Per trovare le definizioni della terminologia del router Cloud, consulta i termini chiave.
Per risolvere i problemi quando utilizzi il router Cloud, consulta la sezione Risoluzione dei problemi.