Panoramica del router Cloud
Il router Cloud è un servizio Google Cloud completamente distribuito e gestito che utilizza il Border Gateway Protocol (BGP) per pubblicizzare i prefissi IP. Programma route dinamiche in base agli annunci BGP che riceve da un peer. Anziché un dispositivo o un'appliance fisica, ogni router Cloud è costituito da attività software che agiscono da speaker BGP e che rispondono. 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 la 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 rete VPC di Google Cloud e la rete remota. Le modifiche ai prefissi e all'hop successivo si propagano automaticamente tra la 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, connetterai le reti VPC utilizzando due VPN ad alta disponibilità e due router Cloud, una VPN ad alta disponibilità e il 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 (Virtual Private Cloud) e prefissi personalizzati sulle sue sessioni BGP (Border Gateway Protocol). A meno che non configuri la modalità di pubblicità personalizzata, un router Cloud annuncia solo route di subnet VPC. La modalità pubblicità personalizzata consente anche di configurare un router Cloud in modo da omettere le route delle subnet VPC.
La modalità di routing dinamico di una rete VPC (a livello di regione o globale) determina quale subnet VPC instrada i router Cloud nella rete pubblicizzata. Per maggiori dettagli, consulta Modalità pubblicitaria predefinita.
La modalità di routing dinamico controlla anche il modo in cui ogni router Cloud applica i prefissi appresi come route dinamiche in una rete VPC. Per maggiori dettagli su questo comportamento, vedi Effetti della modalità di routing dinamico.
Quando configuri BGP per Cloud Interconnect, VPN ad alta disponibilità e appliance router, puoi facoltativamente configurare le sessioni di peering del router in modo da utilizzare 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 istruzioni per ogni prodotto elencate nella sezione Risorse aggiuntive forniscono dettagli su come ogni prodotto utilizza l'ASN.
Indirizzi di peering BGP
Le sessioni BGP per i seguenti prodotti utilizzano indirizzi IPv4 locali rispetto al collegamento nell'intervallo 169.254.0.0/16 come indirizzi di peering BGP:
- Per Dedicated Interconnect, puoi specificare indirizzi locali rispetto al collegamento IPv4 candidati per gli indirizzi di peering BGP oppure Google Cloud può selezionare automaticamente indirizzi locali al link IPv4 non utilizzati.
- Per Partner Interconnect, Google Cloud seleziona automaticamente gli indirizzi IPv4 e locali rispetto al collegamento non utilizzati.
- Per la VPN ad alta disponibilità e la VPN classica che utilizzano il routing dinamico, puoi specificare gli indirizzi 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 BGP. Per maggiori dettagli, consulta Creazione di istanze dell'appliance router.
Il router Cloud supporta anche gli indirizzi IPv6 per il peering BGP. Con la configurazione dei peer BGP IPv6, puoi creare sessioni BGP IPv6 su tunnel VPN ad alta disponibilità e collegamenti VLAN di Dedicated Interconnect.
Per i tunnel VPN ad alta disponibilità, puoi utilizzare indirizzi locali univoci IPv6 (ULA) nell'intervallo fdff:1::/64 come indirizzi di peering BGP.
Gli indirizzi di peering per le sessioni BGP IPv6 devono utilizzare una lunghezza di maschera pari a 126 o un valore di conteggio bit inferiore, ad esempio /122.
Quando configuri una sessione BGP IPv6 nella VPN ad alta disponibilità, puoi configurare gli indirizzi IPv6 di peering manualmente o fare in modo che Google Cloud li assegni automaticamente.
Per Dedicated Interconnect, gli indirizzi IPv6 di peering vengono assegnati automaticamente dall'intervallo di indirizzi unicast globali (GUA) di proprietà di Google 2600:2d00:0:1::/64. Non puoi specificare un intervallo candidato per questi indirizzi IPv6 di peering o configurare manualmente questi indirizzi IPv6 di peering.
Accesso ai bilanciatori del carico interni
Per maggiori dettagli su come accedere ai bilanciatori del carico interni da una rete on-premise connessa, vedi Bilanciatori del carico di rete passthrough interni e reti connesse nella documentazione di Cloud Load Balancing.
Supporto IPv6
Il router Cloud supporta lo scambio di route IPv6 tramite peering BGP IPv6 o su sessioni BGP IPv4 utilizzando BGP multiprotocollo (MP-BGP).
Il router Cloud annuncia prefissi IPv6 per le reti VPC che includono subnet a doppio 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 pubblicizzarli manualmente utilizzando route annunciate personalizzate.
Puoi creare i seguenti tipi di sessioni BGP:
- Sessioni BGP IPv4 che scambiano solo route IPv4
- Sessioni BGP IPv6 che scambiano solo route IPv6
- Sessioni BGP IPv4 che scambiano route IPv4 ma anche route IPv6 tramite MP-BGP
- Sessioni BGP IPv6 che scambiano route IPv6 ma anche route IPv4 tramite MP-BGP
- Sia le sessioni BGP IPv4 sia le sessioni IPv6 eseguite in parallelo sullo stesso tunnel VPN ad alta disponibilità o collegamento VLAN Dedicated Interconnect ; la sessione BGP IPv4 scambia solo route IPv4, e la sessione BGP IPv6 scambia solo route IPv6
Per maggiori dettagli, consulta i seguenti documenti:
- Stabilisci sessioni BGP
- Crea una VPN ad alta disponibilità connesso a un gateway VPN peer
- Crea gateway VPN ad alta disponibilità per connettere le reti VPC
- Crea collegamenti VLAN (Dedicated Interconnect)
- Configura BGP multiprotocollo nelle sessioni BGP IPv4 e IPv6
Per dettagli sugli annunci di route IPv6, consulta Modalità di pubblicità di route.
Limitazioni IPv6
Il peering BGP IPv6 e lo scambio di route IPv6 non sono supportati per le seguenti risorse:
- Collegamenti VLAN Partner Interconnect
- Tunnel VPN classica
- Appliance router (parte di Network Connectivity Center)
- Collegamenti VLAN Cross-Cloud Interconnect
Attività software del router Cloud
I router Cloud vengono implementati tramite una, due o, in rari casi, tre attività software.
La selezione della lunghezza del percorso AS è pertinente solo all'interno di ogni singola attività software del router Cloud. Le attività software dei singoli router Cloud preferiscono indipendentemente lunghezze dei percorsi AS più brevi prima di considerare il valore del discriminator multi-uscita (MED).
Ogni attività software invia i percorsi migliori per un determinato prefisso a un piano di controllo del router Cloud, quindi il piano di controllo invia i percorsi migliori alla rete VPC.
Nei casi in cui è coinvolta più di un'attività software del router Cloud, il percorso migliore di una determinata attività software per un prefisso potrebbe avere una lunghezza del percorso AS diversa rispetto al percorso migliore per lo stesso prefisso in un'altra attività software.
Quando si configurano tunnel VPN ad alta disponibilità e collegamenti VLAN di Cloud Interconnect con uno SLA, sono necessarie più attività software per il router Cloud. Pertanto, per garantire risultati prevedibili, Google consiglia di:
- Pubblicizza prefissi on-premise con la stessa lunghezza del percorso AS
- Utilizza i valori MED solo per influenzare la priorità delle route dinamiche risultanti
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, ciascuna connessa a un tunnel VPN ad alta disponibilità, in cui i tunnel sono tutti 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à. |
Uno |
| Almeno due interfacce, una connessa a un collegamento VLAN in un singolo dominio di disponibilità perimetrale e l'altra connessa a un singolo tunnel VPN ad alta disponibilità, dove i numeri del dominio di disponibilità perimetrale e dei numeri delle interfacce dei gateway VPN sono uguali, 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 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à, dove ogni tunnel è connesso a diversi numeri di interfaccia del gateway VPN ad alta disponibilità, ad esempio un tunnel connesso a interface 0 di un gateway VPN ad alta disponibilità e un altro tunnel connesso a interface 1 dello stesso gateway o di un gateway diverso.
|
Due |
Un router Cloud con almeno i seguenti elementi:
|
Tre |
Manutenzione del software e riavvii delle attività automatizzate
Google Cloud esegue regolarmente eventi di manutenzione per rilasciare nuove funzionalità. 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 si sono arrestate e si sono ripresentate (un flap BGP).
La manutenzione del router Cloud è un processo automatico
ed è progettato 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 FIN TCP) al router on-premise.
Se il router on-premise può elaborare eventi di riavvio graceful, registra un evento di riavvio graceful durante la manutenzione del router Cloud. Per i router on-premise che non supportano il riavvio graceful, assicurati che il timer di sospensione 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 informazioni dettagliate sugli eventi di manutenzione completati, consulta Identificare gli eventi di manutenzione del router.
Per informazioni sul funzionamento del riavvio graceful con Bidirectional Forwarding Detection (BFD), consulta Riavvio controllato e BFD.
Modalità di pubblicità percorso
Utilizzando BGP e un prodotto elencato nella sezione Risorse aggiuntive, un router Cloud annuncia intervalli di indirizzi 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à di annuncio di route: modalità pubblicitaria predefinita e modalità pubblicità personalizzata.
Modalità pubblicitaria predefinita
Utilizzando la modalità pubblicità predefinita, configura un router Cloud o una sessione BGP per pubblicizzare i prefissi per i seguenti tipi di intervalli di indirizzi di subnet. La modalità di routing dinamico della rete VPC consente di stabilire se gli intervalli di indirizzi di subnet pubblicizzati provengono solo dalla stessa regione del router Cloud o se provengono da tutte le regioni:
Modalità di routing dinamico a livello di regione: ogni router Cloud nella rete VPC annuncia intervalli di subnet IPv4 primarie e secondarie nella stessa regione del router Cloud. Se le condizioni per la pubblicità di route IPv6 sono 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 annuncia intervalli di subnet IPv4 primarie e secondarie di tutte le regioni della rete VPC. Se le condizioni per la pubblicità di route IPv6 sono 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 questi indirizzi IPv4 pubblici.
Gli annunci di route subnet vengono aggiornati automaticamente, come descritto in Aggiornamenti automatici per gli annunci di route di subnet.
Modalità pubblicitaria personalizzata
La modalità pubblicitaria personalizzata ti consente di controllare i prefissi annunciati da un router Cloud. Puoi specificare route annunciate personalizzate (inclusi i prefissi di route predefiniti, 0.0.0.0/0 per le route IPv4 o ::/0 per le route IPv6) per tutte le sessioni BGP su un router Cloud o per sessione BGP. Esistono due categorie di route annunciate personalizzate:
Puoi pubblicizzare solo i prefissi IPv4 e IPv6 personalizzati. Questo tipo di route pubblicizzata personalizzata omette le route di subnet che verrebbero annunciate utilizzando la modalità pubblicità predefinita.
Puoi pubblicizzare i prefissi IPv4 e IPv6 personalizzati oltre alle route subnet. Questo tipo di route pubblicizzata personalizzata include le stesse route di subnet annunciate utilizzando la modalità pubblicitaria predefinita.
Se scegli di pubblicizzare le route di subnet, questi vengono aggiornati automaticamente come descritto in Aggiornamenti automatici per la pubblicità delle route di subnet.
Se le condizioni per la pubblicità di route IPv6 sono soddisfatte, il router Cloud annuncia intervalli di subnet IPv6 interne 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 pubblicizzarle.
Per il numero massimo di route annunciate personalizzate che possono essere annunciate in ogni sessione BGP, consulta Numero massimo di route annunciate personalizzate per sessione BGP nella pagina Limiti del router Cloud. Questo valore massimo si applica alle route annunciate personalizzate per l'intero router Cloud e singolarmente per sessione BGP.
Per ulteriori informazioni, consulta i seguenti documenti:
Prefissi annunci effettivi
La modalità di annuncio di route è configurabile sia sull'intero router Cloud sia su 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 router Cloud | Modalità per sessione BGP | Prefissi annunciati effettivi nella sessione BGP |
|---|---|---|
| predefinita | predefinita | La sessione BGP eredita la configurazione del router Cloud. Le route subnet sono annunciate come descritto in Modalità pubblicitaria predefinita. |
| personalizzata | predefinita | La sessione BGP eredita la configurazione del router Cloud. Le route personalizzate configurate sull'intero router Cloud sono annunciate come descritto in Modalità pubblicità personalizzata. Le route annunciate potrebbero contenere alcune o tutte le route di subnet. |
| predefinita o personalizzata | personalizzata | La sessione BGP non eredita la configurazione del router Cloud. Le route annunciate personalizzate e configurate nella sessione BGP stessa sono annunciate 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 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 abiliti l'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 le route IPv6 quando sono soddisfatte tutte le seguenti condizioni:
Il prodotto utilizzato con il router Cloud, ad esempio il gateway VPN ad alta disponibilità, è configurato per utilizzare il tipo di stack IPv4 e IPv6 (doppio stack).
La sessione BGP IPv6 è configurata e abilitata oppure la sessione BGP IPv4 è configurata specificamente per abilitare lo scambio di route IPv6 .
Per saperne di più sulla configurazione delle sessioni BGP, consulta Stabilire sessioni BGP.
Per pubblicizzare 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 prefissi a un peer BGP, include una priorità per ogni prefisso nell'annuncio (messaggio BGP). La priorità annunciata viene implementata come MED.
Puoi controllare i prefissi annunciati 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 non pubblicizzi intervalli personalizzati, ciascun router Cloud pubblicizza solo gli intervalli di subnet nella stessa regione del router Cloud. Ogni intervallo viene pubblicizzato come prefisso con il MED che rappresenta 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 annuncia intervalli di subnet dalla propria regione locale come prefissi il cui MED corrisponde alla priorità di base. Inoltre, i router Cloud pubblicizzano intervalli di subnet di regioni diverse come prefissi i cui MED corrispondono alla priorità di base più un costo per regione a livello di regione. Google Cloud calcola automaticamente un costo da regione a regione in base a fattori come le prestazioni della rete, la distanza e la larghezza di banda disponibile tra le regioni. Ogni costo tra regioni ha un valore specifico per una coppia di regioni: quella della subnet e quella del router Cloud per la pubblicità.
Quando i router on-premise ricevono i prefissi annunciati e le relative priorità, creano route utilizzate per inviare pacchetti alla rete VPC.
Indicazioni per le priorità di base
Quando configuri una sessione BGP (Border Gateway Protocol) su un router Cloud, puoi specificare una priorità annunciata di base per la sessione BGP. La priorità annunciata di base si applica a tutti i prefissi (destinazioni) pubblicizzati dalla 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 specificare quali tunnel Cloud VPN o collegamenti VLAN vengono utilizzati dai sistemi on-premise per inviare pacchetti alla tua rete VPC. Puoi creare una combinazione attiva-attiva, attiva-passiva o una combinazione personalizzata di queste topologie utilizzando la priorità base. Per un esempio di utilizzo di tunnel VPN ad alta disponibilità, consulta 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 per regione sono compresi tra
201e9999, 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.Si consiglia di impostare le priorità di base tra i router Cloud in un'area geografica comprese tra
0e200inclusi. Poiché i costi da regione a regione sono almeno pari a201, se utilizzi priorità di base pari o superiori a201, potresti assegnare accidentalmente un tunnel Cloud VPN o una VLAN con una priorità inferiore rispetto a quella voluta. Un'altra sessione BGP in una regione diversa potrebbe pubblicizzare lo stesso prefisso con una priorità complessiva più elevata (MED, che equivale alla priorità di base più il costo regione per regione). Se non imposti attentamente le priorità di base in altre regioni, potresti far sì che il traffico on-premise venga inviato alla tua rete VPC tramite un tunnel Cloud VPN o un collegamento VLAN imprevisto.Le priorità di base pari o superiori a
10200garantiscono 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 pari o inferiore a200.
Per ulteriori informazioni sull'impostazione di una priorità di base, consulta Aggiornamento della priorità delle route annunciate di base.
Esempi
Questa sezione fornisce esempi che mostrano come i costi da regione a regione 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 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 tabelle seguenti 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 pubblicizzano l'intervallo di indirizzi IPv4 della subnet 10.0.1.0/24, che si trova in us-central1.
Il traffico proveniente dalla rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-central1 perché le sue sessioni BGP hanno il MED più basso pubblicizzato.
| Tunnel VPN | Priorità di base | Costo da regione a regione | MED pubblicizzato | 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 pubblicizzano l'intervallo di indirizzi IPv4 della subnet 10.0.2.0/24, che si trova in europe-west1.
Il traffico proveniente dalla rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-central1 perché le sue sessioni BGP hanno il MED più basso pubblicizzato.
| Tunnel VPN | Priorità di base | Costo da regione a regione | MED pubblicizzato | 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 pubblicizzano l'intervallo di indirizzi IPv4 della subnet 10.0.3.0/24, che si trova in us-west1.
Il traffico proveniente dalla rete on-premise utilizza il tunnel VPN ad alta disponibilità in us-west1 perché le sue sessioni BGP hanno il MED più basso pubblicizzato.
| Tunnel VPN | Priorità di base | Costo da regione a regione | MED pubblicizzato | 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
100 - Un tunnel secondario la cui sessione BGP ha una priorità inferiore, pari a
351
Le tabelle seguenti 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 pubblicizzano l'intervallo di indirizzi IPv4 della subnet 10.0.1.0/24, che si trova in us-central1.
Il traffico proveniente dalla rete on-premise utilizza il tunnel VPN principale in us-central1 perché la sua sessione BGP ha il MED più basso pubblicizzato. Se questo tunnel non è disponibile, il traffico utilizza il tunnel principale in us-west1.
| Tunnel VPN | Priorità di base | Costo da regione a 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 IPv4 della subnet 10.0.2.0/24, che si trova in europe-west1.
Il traffico proveniente dalla rete on-premise utilizza il tunnel VPN principale in us-central1 perché la sua sessione BGP ha il MED più basso pubblicizzato. Se questo tunnel non è disponibile, il traffico utilizza il tunnel principale in us-west1.
| Tunnel VPN | Priorità di base | Costo da regione a 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 IPv4 della subnet 10.0.3.0/24, che si trova in us-west1.
Il traffico proveniente dalla rete on-premise utilizza il tunnel VPN principale in us-west1 perché la sua sessione BGP ha il MED più basso pubblicizzato. Se questo tunnel non è disponibile, il traffico utilizza il tunnel principale in us-central1.
| Tunnel VPN | Priorità di base | Costo da regione a 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, tranne per il fatto che hai sostituito i due tunnel Cloud VPN nella regione us-west1 con due collegamenti VLAN.
Per un'illustrazione di questo esempio, osserva il seguente diagramma.
Vuoi dare la priorità ai collegamenti VLAN. Puoi specificare priorità di base più grandi per i tunnel VPN ad alta disponibilità nella regione us-central1 in modo da ridurne la priorità.
Le tabelle seguenti 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 pubblicizzano l'intervallo di indirizzi IPv4 della subnet 10.0.1.0/24, che si trova in us-central1.
Il traffico proveniente dalla tua 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 | MED pubblicizzato | 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 pubblicizzano l'intervallo di indirizzi IPv4 della subnet 10.0.2.0/24, che si trova in europe-west1.
Il traffico proveniente dalla tua 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 | MED pubblicizzato | 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 pubblicizzano l'intervallo di indirizzi IPv4 della subnet 10.0.3.0/24, che si trova in us-west1.
Il traffico proveniente dalla tua 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 | MED pubblicizzato | 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 può essere la tua rete on-premise, una rete in un altro provider di servizi cloud o un'altra rete VPC. Le route apprese a volte sono denominate route ricevute.
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 tua rete VPC. Ogni route dinamica creata dal router Cloud deriva da una o più route apprese.
Se il router Cloud ha più route apprese per lo stesso prefisso di destinazione, utilizza le metriche di route e, in alcuni casi, la lunghezza del percorso AS per creare route dinamiche. Le seguenti sezioni descrivono ulteriori informazioni su questo processo e sulle route apprese in generale.
Route apprese personalizzate
Come descritto nella sezione precedente, puoi configurare una sessione BGP per avere 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 i limiti 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 connettività e reagiscono di conseguenza per evitare di perdere traffico senza notifica.
Per maggiori 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 l'hop di destinazione e successivo nella stessa regione del router Cloud. Il router Cloud imposta la priorità della route dinamica sulla priorità di base, che il router Cloud ricava dal discriminatore di uscita multiplo (MED) pubblicizzato dal router on-premise.
In modalità di routing dinamico globale, il router Cloud crea una route dinamica per l'hop di destinazione e successivo in ogni regione di Google Cloud. Nell'area geografica 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 appropriato tra regioni.
Puoi definire la priorità delle route a Google Cloud esportate sul router on-premise. Tuttavia, il router on-premise potrebbe sostituire questa priorità delle route, a seconda della sua configurazione.
Per le route to-on-premise apprese dal router Cloud, il router Cloud ottiene la lunghezza del percorso AS e i valori MED e calcola una priorità di base come descritto nelle due sezioni successive.
Lunghezza del percorso AS in anteposizione e lunghezza del percorso AS
L'anticipazione del percorso AS è un mezzo mediante il quale viene ridotta intenzionalmente la priorità di un hop successivo per una destinazione (prefisso) in modo che venga selezionato un hop successivo diverso per la stessa destinazione con una lunghezza del percorso AS più breve. Il MED viene considerato solo quando la lunghezza del percorso dell'AS degli hop successivi è la stessa.
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
Il percorso dell'AS in sospeso non è pertinente al piano di controllo e alla rete VPC. La lunghezza del percorso dell'AS viene considerata solo all'interno di ciascuna 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 dell'hop successivo con la lunghezza del percorso AS più breve.
- L'attività software invia le informazioni sulla destinazione, sull'hop successivo e sul MED al piano di controllo del router Cloud.
- Il piano di controllo utilizza le informazioni per creare una o più route candidati. La priorità base di ogni candidato viene impostata sul MED ricevuto.
Se due o più attività software del router Cloud apprendono la stessa destinazione da due o più sessioni BGP:
- Ogni attività software sceglie una sessione BGP dell'hop successivo con la lunghezza del percorso dell'AS più breve.
- Ogni attività software invia le informazioni sulla destinazione, sull'hop successivo e sul MED al piano di controllo del router Cloud.
- Il piano di controllo utilizza le informazioni per creare due o più route candidati. La priorità base di ogni candidato viene impostata sul MED ricevuto.
Il piano di controllo del router Cloud installa quindi 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, vedi 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
0e231 -1(inclusi), il router Cloud imposta la priorità di base sul valore MED. - Se il valore MED per il prefisso di una destinazione è compreso tra
231e232 -1(inclusi), il router Cloud imposta la priorità di base su231 -1.
Affinché il MED abbia effetto durante la selezione migliore del percorso 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 di origine, che precede il passaggio di confronto MED nel processo di selezione del percorso migliore (RFC 4271).
Il router Cloud pubblicizza le route BGP ai peer con il valore dell'attributo origine impostato su Incomplete. Questo valore è il tipo di origine meno
preferito nella selezione della route.
Il valore di priorità finale che il router Cloud imposta durante la creazione di 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 dall'insieme di route applicabili in base all'ordine di routing. Per maggiori dettagli, consulta la sezione Ordine di routing nella documentazione di VPC.
Sovrapposizione di intervalli di indirizzi IPv4 o IPv6
Se hai una subnet VPC e un annuncio di route on-premise con intervalli di indirizzi sovrapposti, Google Cloud indirizza il traffico in uscita in base agli intervalli di indirizzi.
Per ulteriori informazioni, consulta Route applicabili nella documentazione del VPC.
Trasferimento dati site-to-site
Se hai bisogno di trasferire dati tra due siti esterni a Google Cloud, utilizza Network Connectivity Center. Network Connectivity Center funziona con il router Cloud per farti annunciare dinamicamente le route tra le sessioni BGP.
Il router Cloud da solo non supporta questa funzionalità (né dinamicamente né configurando route annunciate personalizzate che corrispondono ai prefissi appresi). Se aggiungi una route annunciata personalizzata a una sessione BGP e questa route annunciata si sovrappone a una route appresa da un'altra sessione BGP, questa potrebbe essere eliminata.
Limiti per le route apprese
Esistono diversi limiti che influiscono sulle route apprese. Per maggiori informazioni, consulta la sezione Limiti.
Le route IPv4 e IPv6 vengono conteggiate ai fini dello stesso valore 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_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 utilizzabili per monitorarli e su come risolvere i problemi, consulta Controllare quote e limiti nella pagina Risoluzione dei problemi.
Route predefinita
Se non viene specificata alcuna route per una determinata destinazione IPv4 o IPv6, il traffico viene inviato a una route predefinita, che è l'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 per IPv4 è 0.0.0.0/0 e per IPv6 è ::/0.
A volte potresti volere che il traffico sia indirizzato per impostazione predefinita alla rete on-premise. Per farlo, puoi pubblicizzare una route predefinita dal router on-premise al router Cloud. Con il router Cloud, non devi 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 più basso). 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 provoca l'errore della sessione e l'interruzione del traffico. Una volta superato il timeout BGP, pari a 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 fornisce ridondanza e failover. Questa configurazione consente a un tunnel e ai suoi dispositivi di andare offline per gli upgrade o la manutenzione del software senza interrompere il traffico. Inoltre, in caso di errore di un tunnel, l'altro può mantenere le route attive e il traffico.
Eventi di manutenzione
La manutenzione periodica del router Cloud richiede meno di 60 secondi. Il router Cloud non è disponibile durante gli eventi di manutenzione. Il timer di attesa BGP determina per quanto tempo vengono conservate le route apprese quando il router BGP in peering non è disponibile. Il timer di attesa BGP viene negoziato in modo che sia il più basso dei due valori da entrambi i lati. Il router Cloud usa un valore di 60 secondi (per impostazione predefinita) per il timer di blocco BGP. Ti consigliamo di impostare il timer di attesa BGP sul router on-premise (peer) su un valore pari o superiore a 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 dei 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 riapprese. In genere, i tempi di ripristino dei gateway Cloud VPN sono di circa un minuto. Se sono presenti gateway Cloud VPN ridondanti, il traffico non è interessato perché viene disattivato un solo gateway Cloud VPN alla volta.
Identificatore BGP (ID router)
Ogni router Cloud ha un identificatore BGP, chiamato anche ID router. L'identificatore BGP è univoco per ciascun router Cloud nel tuo VPC, come richiesto dal documento RFC 6286.
In genere, l'identificatore BGP viene assegnato automaticamente, ma puoi configurare il router Cloud con un intervallo di identificatori BGP esplicito. Se scegli di assegnare il tuo intervallo di identificatori BGP, al router Cloud viene assegnato un identificatore BGP stabile all'interno dell'intervallo selezionato. A un router Cloud non configurato con un intervallo di identificatori BGP viene assegnato un identificatore BGP in base all'indirizzo dell'interfaccia IPv4 più alto.
Quando aggiungi la prima interfaccia IPv6 a un router Cloud che non è configurato con un intervallo di identificatori BGP, viene assegnato automaticamente un intervallo di identificatori BGP.
Per maggiori informazioni, consulta Configurare l'intervallo di identificatori BGP per il router Cloud.
Riavvii delle sessioni BGP
L'identificatore BGP di un router Cloud attivo può cambiare per uno dei seguenti motivi:
- Aggiorna o rimuovi manualmente l'intervallo di identificatori BGP configurato.
- Rimuovi un'interfaccia IPv4 dal router Cloud e non ha un intervallo di identificatori BGP assegnato.
Quando l'identificatore BGP di un router Cloud attivo cambia, ogni sessione BGP su quel router Cloud viene riavviata.
L'intervallo di identificatori di un router Cloud può cambiare anche quando il router viene riavviato per la manutenzione periodica e non ha un intervallo di identificatori BGP assegnato.
Risorse aggiuntive
Per ulteriori informazioni sull'uso 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 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 tramite router Cloud è facoltativo | Creazione di una VPN classica mediante 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 del router Cloud, consulta Termini chiave.
Per risolvere i problemi relativi all'utilizzo del router Cloud, consulta Risoluzione dei problemi.