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 i prefissi IP. Programma le route dinamiche in base agli annunci BGP che riceve da un peer. Ogni router Cloud è costituito da attività software che fungono da oratori e risponditori BGP anziché da un dispositivo fisico o da un'appliance. Un router Cloud funge anche da piano di controllo per Cloud NAT. Il router Cloud fornisce servizi BGP per i seguenti prodotti Google Cloud:
- Cloud 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 di 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 rete VPC di Google Cloud e la rete remota. Le modifiche di prefisso e di 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, devi connettere le reti VPC utilizzando due VPN ad alta disponibilità e due router Cloud, una VPN ad alta disponibilità e il router Cloud associato su ciascuna 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 sulle sue sessioni BGP. A meno che non configuri la modalità pubblicità personalizzata, un router Cloud annuncia solo route di subnet VPC. La modalità pubblicità personalizzata consente 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 regione o globale) determina quale subnet VPC instrada i router Cloud in quella rete. Per maggiori dettagli, consulta Modalità pubblicità predefinita.
La modalità di routing dinamico controlla anche in che modo ogni router Cloud applica i prefissi appresi come route dinamiche 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à e appliance router, puoi configurare facoltativamente le sessioni di peering del router in modo che utilizzino l'autenticazione MD5.
ASN (Autonomous System Number)
Quando crei un router Cloud, scegli l'ASN lato Google per tutte le sessioni BGP utilizzate dal router Cloud. Le indicazioni per ciascun prodotto per la connettività di rete elencato nella sezione Risorse aggiuntive forniscono dettagli su come ogni prodotto utilizza l'ASN.
Indirizzi IP del peering BGP
Le sessioni BGP per i seguenti prodotti per la connettività di rete utilizzano indirizzi IPv4 locali rispetto al collegamento nell'intervallo 169.254.0.0/16
come indirizzi IP di peering BGP:
- Per Dedicated Interconnect, puoi specificare gli indirizzi candidati locali rispetto al collegamento per gli indirizzi di peering BGP oppure Google Cloud può selezionare automaticamente gli indirizzi locali rispetto al collegamento non utilizzati.
- Per Partner Interconnect, Google Cloud seleziona automaticamente gli indirizzi IPv4 locali inutilizzati.
- Per VPN ad alta disponibilità e 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 router utilizzano gli indirizzi IPv4 interni delle VM Google Cloud come indirizzi IP BGP. Per maggiori dettagli, consulta Creazione di istanze di appliance router.
Accesso ai bilanciatori del carico interni
Per maggiori dettagli su come accedere ai bilanciatori del carico interni da una rete on-premise connessa, consulta Bilanciatori del carico interni e reti connesse nella documentazione di Cloud Load Balancing.
Supporto IPv6
Il router Cloud supporta BGP multiprotocollo (MP-BGP) e può scambiare i prefissi IPv6 sulle sessioni IPv4 BGP. Le sessioni solo IPv6 native non sono supportate.
Il router Cloud annuncia i prefissi IPv6 per le reti VPC che includono subnet a due stack. Per impostazione predefinita, gli intervalli di subnet IPv6 interni vengono pubblicizzati automaticamente. Gli intervalli di subnet IPv6 esterni non vengono pubblicizzati automaticamente, ma puoi annunciarli manualmente utilizzando le route annunciate personalizzate.
Puoi abilitare lo scambio di prefissi IPv6 nelle sessioni BGP create per i tunnel VPN ad alta disponibilità e i collegamenti VLAN. Per maggiori dettagli, consulta i seguenti documenti:
- Crea una VPN ad alta disponibilità su un gateway VPN peer
- Crea una VPN ad alta disponibilità su un altro gateway VPN ad alta disponibilità
- Crea collegamenti VLAN (Dedicato)
- Abilita o disabilita lo scambio di prefissi IPv6 nelle sessioni IPv4 BGP
Per maggiori dettagli sugli annunci di route IPv6, consulta Modalità annuncio route.
Limitazioni IPv6
Lo scambio di prefissi IPv6 non è supportato nelle sessioni BGP per le seguenti risorse:
- Collegamenti VLAN Partner Interconnect
- Tunnel VPN classica
- 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, ciascuna connessa a un tunnel VPN classica. | Uno |
Una o più interfacce, ciascuna connessa a un collegamento VLAN, in cui i collegamenti VLAN si trovano nello stesso dominio di disponibilità perimetrale. | Uno |
Un numero qualsiasi di interfacce, ognuna connessa a un tunnel VPN ad alta disponibilità, in cui i tunnel sono connessi allo stesso numero di interfaccia su uno o più gateway VPN ad alta disponibilità, ad esempio due tunnel, ciascuno connesso a interface 0 su gateway VPN ad alta disponibilità diversi. |
Uno |
Almeno due interfacce, una connessa a un collegamento VLAN in un singolo dominio di disponibilità perimetrale e un'altra connessa a un singolo tunnel VPN ad alta disponibilità, in cui i numeri di interfaccia del dominio di disponibilità perimetrale e del gateway VPN sono gli stessi, ad esempio il primo dominio di disponibilità perimetrale in una coppia di domini di disponibilità perimetrale e la prima interfaccia del gateway VPN. | Uno |
Almeno due interfacce, ciascuna connessa a un'istanza dell'appliance di router in cui 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 connessa a un collegamento VLAN, in cui i collegamenti VLAN si trovano in domini di disponibilità perimetrale diversi. | Due |
Almeno due interfacce, ciascuna connessa a un tunnel VPN ad alta disponibilità, in cui ogni tunnel è connesso a diversi numeri di interfaccia del gateway VPN ad alta disponibilità, ad esempio un tunnel connesso all'elemento interface 0 di un gateway VPN ad alta disponibilità e un altro tunnel connesso a interface 1 dello stesso gateway o a un gateway diverso.
|
Due |
Un router Cloud con almeno quanto segue:
|
Tre |
Manutenzione del 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 queste attività software non sono andate a buon fine e sono tornate indietro (un 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 richiedere più di 60 secondi. Prima della manutenzione, il router Cloud invia una notifica di riavvio graceful (un pacchetto TCP FIN
) al router on-premise.
Se il router on-premise è in grado di elaborare eventi di riavvio graceful, registra un evento di riavvio graceful temporaneo durante la manutenzione del router Cloud. Per i router on-premise che non supportano il riavvio graceful, assicurati che il timer di blocco del router on-premise sia impostato su 60 secondi. Per maggiori dettagli, vedi Gestire i timer BGP.
Gli eventi di manutenzione del router Cloud non vengono annunciati in anticipo perché le route non vengono perse sui router on-premise configurati correttamente. Per ottenere dettagli sugli eventi di manutenzione completati, consulta Identificare gli eventi di manutenzione del router.
Per informazioni sul funzionamento del riavvio graceful con il protocollo BFD (Bidirectional Forwarding Detection), consulta Riavvio controllato e BFD.
Modalità annuncio percorso
Utilizzando BGP e un prodotto per la connettività di rete elencato nella sezione Risorse aggiuntive, un router Cloud annuncia gli intervalli di indirizzi IP alla rete on-premise. In questo modo, i client nella rete on-premise possono inviare e ricevere pacchetti dalle risorse nella tua rete VPC.
Il router Cloud offre due modalità annuncio di route: modalità annuncio predefinita e modalità pubblicità personalizzata.
Modalità pubblicità predefinita
L'utilizzo della modalità pubblicità predefinita consente di configurare 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 controlla se gli intervalli di indirizzi IP della subnet pubblicizzati provengono solo dalla stessa regione del router Cloud o da tutte le regioni:
Modalità di routing dinamico a livello di regione: ogni router Cloud nella rete VPC pubblicizza intervalli di subnet IPv4 principali e secondari nella stessa regione del router Cloud. Se le condizioni per la pubblicità di route IPv6 vengono soddisfatte, il router Cloud annuncia 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 principali e secondari da tutte le regioni della rete VPC. Se le condizioni per la pubblicità di route IPv6 vengono soddisfatte, il router Cloud annuncia intervalli di subnet IPv6 interni (
ipv6-access-type=INTERNAL
) da tutte le regioni nella rete VPC.
Se pubblicizzi indirizzi IPv4 pubblici utilizzati privatamente, i sistemi on-premise potrebbero non essere in grado di accedere alle risorse internet che utilizzano gli indirizzi IPv4 pubblici.
Gli annunci di route subnet vengono aggiornati automaticamente, come descritto in Aggiornamenti automatici per gli annunci di route di subnet.
Modalità pubblicità personalizzata
La modalità pubblicità personalizzata ti offre il controllo sui prefissi pubblicizzati da un router Cloud. Puoi specificare route annunciate personalizzate
(inclusi i prefissi di route predefiniti, 0.0.0.0/0
o ::/0
) per tutte le sessioni BGP
su un router Cloud o sulla base di una sessione per BGP. Esistono due categorie di route annunciate personalizzate:
Puoi pubblicizzare solo prefissi IPv4 e IPv6 personalizzati. Questo tipo di route pubblicizzata personalizzata omette le route di subnet che verranno pubblicizzate utilizzando la modalità pubblicità predefinita.
Puoi pubblicizzare prefissi IPv4 e IPv6 personalizzati oltre alle route di subnet. Questo tipo di route pubblicizzata personalizzata include le stesse route di subnet pubblicizzate utilizzando la modalità pubblicità predefinita.
Se scegli di pubblicizzare route di subnet, i relativi annunci vengono aggiornati automaticamente come descritto in Aggiornamenti automatici per gli annunci relativi alle route di subnet.
Se le condizioni per la pubblicità di route IPv6 vengono soddisfatte, il router Cloud annuncia intervalli di subnet IPv6 interni ogni volta che scegli di pubblicizzare le route di subnet. Devi aggiungere eventuali intervalli di subnet IPv6 esterni al tuo elenco di route personalizzate per pubblicizzarli.
Per il numero massimo di route annunciate personalizzate che possono essere pubblicizzate su ogni sessione BGP, vedi Numero massimo di route annunciate personalizzate per sessione BGP nella pagina dei limiti del router Cloud. Questo valore massimo si applica alle route annunciate personalizzate per l'intero router Cloud e singolarmente per ogni sessione BGP.
Per saperne di più, consulta i seguenti documenti:
Prefissi annunci efficaci
La modalità annuncio di route è configurabile sia sull'intero router Cloud sia sulle singole sessioni BGP del router Cloud. La seguente tabella 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 effettivi pubblicizzati nella sessione BGP |
---|---|---|
predefinita | predefinita | La sessione BGP eredita la configurazione del router Cloud. Le route di subnet sono annunciate come descritto in Modalità pubblicità predefinita. |
custom | predefinita | La sessione BGP eredita la configurazione del router Cloud. Le route personalizzate configurate sull'intero router Cloud sono pubblicizzate come descritto nella modalità pubblicità personalizzata. Le route annunciate potrebbero contenere alcune o tutte le route di subnet. |
predefinita o personalizzata | custom | La sessione BGP non eredita la configurazione del router Cloud. Le route annunciate personalizzate configurate nella sessione BGP stessa sono pubblicizzate come descritto in Modalità pubblicità personalizzata. Le route annunciate potrebbero 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 subnet nelle situazioni seguenti:
Quando crei una subnet solo IPv4
Quando crei una subnet a doppio stack con IPv6 interno abilitato
Quando elimini una subnet
Quando abiliti IPv6 interno su una subnet solo IPv4 esistente
Quando modifichi gli intervalli IPv4 secondari di una subnet
Condizioni per annuncio di route 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, ad esempio il gateway VPN ad alta disponibilità, è configurato per l'utilizzo del tipo a doppio stack 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 devi aver creato almeno una subnet a doppio stack con un intervallo di subnet IPv6 interno.
Prefissi e priorità pubblicizzati
Quando un router Cloud annuncia dei prefissi per un peer BGP, include una priorità per ogni prefisso nell'annuncio (messaggio BGP). La priorità pubblicizzata è implementata come MED.
Puoi controllare quale prefisso viene pubblicizzato dal router Cloud per tutte o alcune delle sue sessioni BGP. Puoi controllare la priorità pubblicizzata (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 tu non pubblicizzi intervalli personalizzati, ogni router Cloud annuncia solo gli intervalli di subnet nella stessa regione del router Cloud. Ogni intervallo è pubblicizzato come prefisso, dove MED è la priorità di base.
Se la tua rete VPC utilizza la modalità di routing dinamico globale, a meno che tu non pubblicizzi intervalli personalizzati, ogni router Cloud pubblicizza gli intervalli di subnet dalla rispettiva regione locale come prefissi il cui MED corrisponde alla priorità di base. Inoltre, i router Cloud pubblicizzano intervalli di subnet di diverse aree geografiche come prefissi i cui MED corrispondono alla priorità di base più il costo da una regione all'altra. Google Cloud calcola automaticamente un costo da una regione all'altra in base a fattori come le prestazioni della rete, la distanza e la larghezza di banda disponibile tra le regioni. Ogni costo da una regione all'altra 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 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à di base pubblicizzata per la sessione BGP. La priorità di base pubblicizzata si applica a tutti i prefissi (destinazioni) pubblicizzati da quella sessione BGP.
Le priorità di base sono numeri interi da 0
a 65535
.
La priorità di base più alta possibile è 0
. La priorità di base predefinita è 100
.
Se non specifichi una priorità di base, viene utilizzata la priorità predefinita.
Le priorità di base consentono di controllare quali tunnel Cloud VPN o collegamenti VLAN utilizzano sistemi on-premise per inviare pacchetti alla tua rete VPC. Puoi creare una combinazione di queste topologie attiva/attiva, attiva/passiva o personalizzata utilizzando la priorità di base. Per un esempio di utilizzo dei tunnel VPN ad alta disponibilità, consulta le opzioni di routing attivo/attivo e attivo/passivo per VPN ad alta disponibilità nella documentazione di Cloud VPN.
Quando scegli le priorità di base, tieni presente quanto segue:
I costi da una regione all'altra sono compresi tra
201
e9999
, inclusi. Il valore dipende dalla distanza, dalla latenza e da altri fattori tra due regioni. Google genera i valori di costo da regione a regione e non puoi modificarli.Le priorità di base per le sessioni BGP tra i router Cloud in un'area geografica devono essere comprese tra
0
e200
inclusi. Poiché i costi da una regione all'altra sono almeno201
, se utilizzi priorità di base pari o superiori a201
, potresti assegnare accidentalmente una priorità inferiore a quella prevista per un tunnel Cloud VPN o un collegamento VLAN. Un'altra sessione BGP in un'altra regione potrebbe pubblicizzare lo stesso prefisso con una priorità complessivamente più elevata (MED, che equivale a priorità di base più costo da regione a regione). Se non imposti attentamente le priorità di base in altre regioni, potresti causare la distribuzione del traffico on-premise alla tua rete VPC tramite un tunnel Cloud VPN o un collegamento VLAN imprevisto.Le priorità di base pari o superiori a
10,200
assicurano che la priorità complessiva pubblicizzata di un prefisso (MED, priorità di base più costo da regione a regione) sia sempre inferiore a qualsiasi altro prefisso pubblicizzato con una priorità di base di200
o inferiore.
Per ulteriori informazioni sull'impostazione di una priorità di base, vedi Aggiornamento della priorità di route annunciata di base.
Esempi
Questa sezione fornisce esempi che mostrano in che modo i costi da regione a regione influiscono sui valori 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-west1
eus-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 una illustrazione di questo esempio, consulta il diagramma seguente, che include valori di esempio per il costo da regione a regione.
Supponiamo che ogni sessione BGP abbia la priorità di base predefinita di 100
.
Le seguenti tabelle mostrano come vengono utilizzati la priorità di base e il costo da regione a regione per calcolare i valori MED pubblicizzati per il traffico dalla rete on-premise a ogni subnet.
10.0.1.0/24 (us-central1)
Questa tabella mostra le sessioni BGP che annunciano l'intervallo di indirizzi IP della subnet 10.0.1.0/24
, che si trova in us-central1
.
Il traffico dalla rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-central1
perché le relative sessioni BGP hanno il MED pubblicizzato più basso.
Tunnel VPN | Priorità di base | Costo da regione a regione | Pubblicità MED | Ranking del percorso |
---|---|---|---|---|
central-tunnel-0 ,central-tunnel-1 |
100 | 0 | 100 | Prima scelta |
west-tunnel-0 ,west-tunnel-1 |
100 | 250 | 350 | Seconda scelta |
10.0.2.0/24 (europe-west1)
Questa tabella mostra le sessioni BGP che annunciano l'intervallo di indirizzi IP della subnet 10.0.2.0/24
, che si trova in europe-west1
.
Il traffico dalla rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-central1
perché le relative sessioni BGP hanno il MED pubblicizzato più basso.
Tunnel VPN | Priorità di base | Costo da regione a regione | Pubblicità MED | Ranking del percorso |
---|---|---|---|---|
central-tunnel-0 ,central-tunnel-1 |
100 | 300 | 400 | Prima scelta |
west-tunnel-0 ,west-tunnel-1 |
100 | 350 | 450 | Seconda scelta |
10.0.3.0/24 (us-west1)
Questa tabella mostra le sessioni BGP che annunciano l'intervallo di indirizzi IP della subnet 10.0.3.0/24
, che si trova in us-west1
.
Il traffico dalla rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-west1
perché le relative sessioni BGP hanno il MED pubblicizzato più basso.
Tunnel VPN | Priorità di base | Costo da regione a regione | Pubblicità MED | Ranking del percorso |
---|---|---|---|---|
central-tunnel-0 ,central-tunnel-1 |
100 | 250 | 350 | Seconda scelta |
west-tunnel-0 ,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à attiva/passiva in ogni regione:
- Un tunnel principale la cui sessione BGP ha la priorità di base predefinita di
100
- Un tunnel secondario la cui sessione BGP ha una priorità più bassa (
351
)
Le seguenti tabelle mostrano come vengono utilizzati la priorità di base e il costo da regione a regione per calcolare i valori MED pubblicizzati per il traffico dalla rete on-premise a ogni subnet.
10.0.1.0/24 (us-central1)
Questa tabella mostra le sessioni BGP che annunciano l'intervallo di indirizzi IP della subnet 10.0.1.0/24
, che si trova in us-central1
.
Il traffico dalla rete on-premise utilizza il tunnel VPN principale in us-central1
perché la relativa sessione BGP ha il MED pubblicizzato più basso. Se il tunnel non è disponibile, il traffico utilizza il tunnel principale in us-west1
.
Tunnel VPN | Priorità di base | Costo da regione a regione | Pubblicità MED | 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 annunciano l'intervallo di indirizzi IP della subnet 10.0.2.0/24
, che si trova in europe-west1
.
Il traffico dalla rete on-premise utilizza il tunnel VPN principale in us-central1
perché la relativa sessione BGP ha il MED pubblicizzato più basso. Se il tunnel non è disponibile, il traffico utilizza il tunnel principale in us-west1
.
Tunnel VPN | Priorità di base | Costo da regione a regione | Pubblicità MED | 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 annunciano l'intervallo di indirizzi IP della subnet 10.0.3.0/24
, che si trova in us-west1
.
Il traffico dalla rete on-premise utilizza il tunnel VPN principale in us-west1
perché la relativa sessione BGP ha il MED pubblicizzato più basso. Se il tunnel non è disponibile, il traffico utilizza il tunnel principale in us-central1
.
Tunnel VPN | Priorità di base | Costo da regione a regione | Pubblicità MED | 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 a livello globale
Questo esempio è simile agli esempi precedenti, tranne per il fatto che hai sostituito i due tunnel Cloud VPN nell'area geografica us-west1
con due collegamenti VLAN.
Per un'illustrazione di questo esempio, vedi il diagramma seguente.
Vuoi assegnare la priorità ai collegamenti VLAN. Devi specificare priorità di base più grandi per i tunnel VPN ad alta disponibilità nella regione us-central1
per ridurne la priorità.
Le seguenti tabelle mostrano come vengono utilizzati la priorità di base e il costo da regione a regione per calcolare i valori MED pubblicizzati per il traffico dalla rete on-premise a ogni subnet.
10.0.1.0/24 (us-central1)
Questa tabella mostra le sessioni BGP che annunciano l'intervallo di indirizzi IP della subnet 10.0.1.0/24
, che si trova in us-central1
.
Il traffico dalla rete on-premise utilizza il collegamento VLAN in us-west1
perché le relative sessioni BGP hanno il MED pubblicizzato più basso.
Tunnel VPN o collegamento VLAN | Priorità di base | Costo da regione a regione | Pubblicità MED | Ranking del percorso |
---|---|---|---|---|
central-tunnel-0 ,central-tunnel-1 |
351 | 0 | 351 | Seconda scelta |
west-attachment-0 ,west-attachment-1 |
100 | 250 | 350 | Prima scelta |
10.0.2.0/24 (europe-west1)
Questa tabella mostra le sessioni BGP che annunciano l'intervallo di indirizzi IP della subnet 10.0.2.0/24
, che si trova in europe-west1
.
Il traffico dalla rete on-premise utilizza il collegamento VLAN in us-west1
perché le relative sessioni BGP hanno il MED pubblicizzato più basso.
Tunnel VPN o collegamento VLAN | Priorità di base | Costo da regione a regione | Pubblicità MED | Ranking del percorso |
---|---|---|---|---|
central-tunnel-0 ,central-tunnel-1 |
351 | 300 | 651 | Seconda scelta |
west-attachment-0 ,west-attachment-1 |
100 | 350 | 450 | Prima scelta |
10.0.3.0/24 (us-west1)
Questa tabella mostra le sessioni BGP che annunciano l'intervallo di indirizzi IP della subnet 10.0.3.0/24
, che si trova in us-west1
.
Il traffico dalla rete on-premise utilizza il collegamento VLAN in us-west1
perché le relative sessioni BGP hanno il MED pubblicizzato più basso.
Tunnel VPN o collegamento VLAN | Priorità di base | Costo da regione a regione | Pubblicità MED | Ranking del percorso |
---|---|---|---|---|
central-tunnel-0 ,central-tunnel-1 |
351 | 250 | 601 | Seconda scelta |
west-attachment-0 ,west-attachment-1 |
100 | 0 | 100 | Prima scelta |
Route apprese
Le route apprese sono route che il router Cloud utilizza per raggiungere un'altra rete. L'altra rete potrebbe essere la tua rete on-premise, una rete in un altro provider di servizi cloud o un'altra rete VPC. I percorsi appresi sono a volte denominati percorsi rilevati.
In Google Cloud esistono due tipi di route apprese:
Route apprese dai router esterni tramite BGP
Route configurate manualmente per una singola sessione BGP (route apprese personalizzate)
Utilizzando entrambi i tipi di route apprese, il router Cloud crea route dinamiche nella rete VPC. Ogni route dinamica creata dal router Cloud deriva da una o più di queste route apprese.
Se il router Cloud ha più route apprese per lo stesso prefisso di destinazione, il router Cloud utilizza le metriche di route e, in alcuni casi, la lunghezza del percorso AS per creare route dinamiche. Le seguenti sezioni descrivono di più su questo processo e sulle route apprese in generale.
Route apprese personalizzate
Come descritto nella sezione precedente, puoi configurare una sessione BGP in modo che abbia route apprese personalizzate. Quando configuri route apprese personalizzate, il router Cloud si comporta come se avesse appreso queste route da un peer BGP.
Le route apprese personalizzate possono essere utili se vuoi evitare le limitazioni delle route statiche. Ad esempio, le route statiche non possono rilevare una perdita di raggiungibilità nell'hop successivo di una route. Al contrario, le route apprese personalizzate possono rilevare una perdita di raggiungibilità e reagiscono di conseguenza per evitare di perdere traffico senza notifica.
Per ulteriori informazioni, consulta Route apprese personalizzate.
Effetti della modalità di routing dinamico
La modalità di routing dinamico di una rete VPC determina il modo in cui vengono applicate le route apprese:
In modalità di routing dinamico a livello di regione, il router Cloud crea una route dinamica per la destinazione e l'hop successivo nella stessa regione del router Cloud. Il router Cloud imposta la priorità per quella route dinamica sulla priorità di base, che il router Cloud deriva dal discriminatore multi-uscita (MED) pubblicizzato dal router on-premise.
In modalità di routing dinamico globale, il router Cloud crea una route dinamica per la destinazione e l'hop successivo in ogni regione Google Cloud. Nella regione che contiene il router Cloud che ha appreso la route, il router Cloud imposta la priorità della route dinamica sulla priorità di base. In tutte le altre regioni, il router Cloud imposta la priorità sulla priorità di base più un costo tra regione e regione appropriato.
Puoi definire la priorità delle route verso Google Cloud esportate nel router on-premise. Tuttavia, il tuo router on-premise potrebbe sostituire questa priorità di route, a seconda della sua configurazione, ad esempio se il router on-premise modifica la priorità della route.
Per le route to on-premise apprese dal router Cloud, il router Cloud riceve la lunghezza del percorso AS e i valori MED e calcola una priorità di base come descritto nelle prossime due sezioni.
Premessa del percorso AS e lunghezza del percorso AS
La prependenza del percorso AS è un mezzo per mezzo del quale un hop successivo per una destinazione (prefisso) viene intenzionalmente ridotta in modo da selezionare un hop successivo diverso per la stessa destinazione con una lunghezza del percorso AS più breve. MED viene considerata solo quando le lunghezze del percorso 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 del percorso AS non è pertinente per il piano di controllo e la rete VPC. La lunghezza del percorso AS viene considerata solo all'interno di ogni attività software del router Cloud, come descritto negli scenari seguenti.
Se una singola attività software del router Cloud apprende la stessa destinazione da due o più sessioni BGP:
- L'attività software sceglie una sessione BGP con hop successivo con la lunghezza del percorso AS più breve.
- L'attività software invia le informazioni su destinazione, hop successivo e MED al piano di controllo del router Cloud.
- Il piano di controllo utilizza le informazioni per creare una o più route candidate. La priorità di base di ogni candidato è impostata sul valore MED ricevuto.
Se due o più attività software del router Cloud apprendono la stessa destinazione da due o più sessioni BGP:
- Ogni attività software seleziona una sessione BGP dell'hop successivo con la lunghezza del percorso AS più breve.
- Ogni attività software invia le informazioni su destinazione, hop successivo e MED al piano di controllo del router Cloud.
- Il piano di controllo utilizza le informazioni per creare due o più route candidate. La priorità di base di ogni candidato è impostata sul valore MED ricevuto.
Quindi il piano di controllo del router Cloud installa una o più route dinamiche nella rete VPC, in base alla modalità di routing dinamico della rete VPC. In modalità di routing dinamico globale, la priorità di ogni route dinamica a livello di regione viene regolata in regioni diverse da quella del router Cloud. Per maggiori dettagli su come Google Cloud seleziona una route, consulta Ordine di routing nella documentazione di VPC.
Priorità di base, MED e origine
Il router Cloud utilizza il valore MED pubblicizzato dal router peer per calcolare una priorità di base:
- Se il valore MED per il prefisso di una destinazione è compreso tra
0
e231 -1
(inclusi), il router Cloud imposta la priorità di base al valore MED. - Se il valore MED per il prefisso di una destinazione è compreso tra
231
e232 -1
(inclusi), il router Cloud imposta la priorità di base su231 -1
.
Affinché MED abbia effetto durante la selezione migliore del percorso tra più route apprese per la stessa destinazione, il valore dell'attributo di origine BGP per le route ricevute deve essere lo stesso. In caso contrario, la selezione avviene in base al valore dell'attributo di origine, che precede la fase di confronto MED nel processo di selezione del percorso migliore (RFC 4271).
Il router Cloud annuncia le route BGP ai suoi peer con il valore dell'attributo di origine impostato su Incomplete
. Questo valore è il tipo di origine meno preferito nella selezione della route.
Il valore di priorità finale impostato dal router Cloud quando crea route dinamiche in una rete VPC dipende dalla modalità di routing dinamico della rete. Per ulteriori informazioni, consulta Effetti della modalità di routing dinamico.
Route statiche
Quando un'istanza invia un pacchetto, Google Cloud tenta di selezionare una route dal set di route applicabili in base all'ordine di routing. Per maggiori dettagli, consulta la sezione Ordine di routing nella documentazione di VPC.
Intervalli IP sovrapposti
Nei casi in cui tu abbia una subnet VPC e una pubblicità di route on-premise con intervalli IP sovrapposti, Google Cloud indirizza il traffico in uscita in base agli intervalli IP corrispondenti.
Per ulteriori informazioni, consulta Route applicabili nella documentazione di VPC.
Trasferimento dati site-to-site
Se devi trasferire dati tra due siti esterni a Google Cloud, utilizza 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 di per sé non supporta questa funzionalità (in modo dinamico o configurando route annunciate personalizzate che corrispondono ai prefissi appresi). Se aggiungi una route pubblicizzata 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 diversi limiti che interessano le route apprese. Per ulteriori informazioni, consulta i limiti.
Le route IPv4 e IPv6 vengono conteggiate per lo stesso limite massimo e non hanno limiti separati.
Per monitorare l'utilizzo rispetto ai limiti, usa le seguenti metriche:
router.googleapis.com/dynamic_routes/learned_routes/used_unique_destinations
router.googleapis.com/dynamic_routes/learned_routes/unique_destinations_limit
router.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 Controllare quote e limiti nella pagina Risoluzione dei problemi.
Route predefinita
Quando non viene 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
, mentre per IPv4 e IPv6 a doppio stack è 0.0.0.0/0, ::/0
.
A volte potresti voler indirizzare il traffico alla tua rete on-premise per impostazione predefinita. Per farlo, puoi pubblicizzare una route predefinita dal router on-premise al router Cloud. Con il router Cloud, non è necessario creare e gestire route statiche. Se pubblicizzi una route predefinita dalla tua rete on-premise, verifica 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
in
Intervallo IP di destinazione e visualizza Default internet gateway
in Hop successivo.
Tunnel Cloud VPN ridondanti
Se il gateway on-premise non supporta il riavvio graceful, un errore su entrambi i lati della sessione BGP causa l'errore della sessione e il traffico viene interrotto. Dopo il superamento del timeout BGP, ovvero di 60 secondi per il router Cloud, le route vengono ritirate da entrambi i lati.
Senza il supporto riavvio graceful, il deployment di due gateway on-premise con un tunnel ciascuno offre ridondanza e failover. Questa configurazione consente a un tunnel e ai suoi dispositivi di andare offline per eseguire upgrade o manutenzione del software senza interrompere il traffico. Inoltre, se un tunnel non funziona, l'altro può mantenere le route attive e il flusso del traffico.
Eventi di manutenzione
Il router Cloud è sottoposto a manutenzione periodica, che richiede meno di 60 secondi. Il router Cloud non è disponibile durante gli eventi di manutenzione. Il timer di blocco BGP determina per quanto tempo vengono conservate le route apprese quando il router BGP in peering non è disponibile. Il timer di blocco BGP viene negoziato in modo che sia il più basso dei due valori di 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 il timer di blocco BGP sul router on-premise (peer) su 60 secondi o più. Di conseguenza, entrambi i router conservano le proprie route 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'utilizzo del router Cloud aggiunge circa 20 secondi al tempo di recupero del tunnel perché la sessione BGP viene reimpostata e le route devono essere riapprese. I tempi di recupero del gateway Cloud VPN sono in genere circa un minuto. Se sono presenti gateway Cloud VPN ridondanti, il traffico non è interessato perché viene rimosso un solo gateway Cloud VPN alla volta.
Riavvii dell'ID router BGP e della sessione BGP
Il router Cloud seleziona l'indirizzo IP di interfaccia più alto per l'ID router BGP e lo conserva per tutto il tempo in cui l'indirizzo è disponibile. Se elimini l'interfaccia del router Cloud 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 la manutenzione periodica.
Risorse aggiuntive
Per ulteriori informazioni sull'utilizzo del routing statico e dinamico con un servizio supportato, consulta la documentazione seguente.
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 di router |
VPN ad alta disponibilità | Richiede il routing dinamico con il router Cloud |
Creazione di un gateway VPN ad alta disponibilità verso 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 utilizzando il routing dinamico Creazione di una VPN classica utilizzando il routing statico |
Passaggi successivi
Per aiutarti a creare la tua topologia di rete con il router Cloud, consulta le best practice.
Per trovare le definizioni della terminologia dei router Cloud, consulta i Termini chiave.
Per risolvere i problemi relativi all'utilizzo del router Cloud, consulta la sezione Risoluzione dei problemi.