Panoramica del router Cloud
Router Cloud è un servizio Google Cloud completamente distribuito e gestito che utilizza Bordo Gateway Protocol (BGP) per pubblicizzare i prefissi IP. Si programma route dinamiche basate su BGP annunci che riceve da un peer. Anziché un dispositivo o un apparecchio fisico, ogni Il router Cloud è costituito da attività software che agiscono da relatori e risponditori BGP. R Il router Cloud funge anche da piano di controllo Cloud NAT Il router Cloud fornisce 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 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 al prefisso e all'hop successivo si propagano automaticamente tra tra la rete VPC e l'altra rete, senza la necessità 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à 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 le route di subnet Virtual Private Cloud (VPC) e prefissi personalizzati nelle sue sessioni BGP (Border Gateway Protocol). A meno che non configuri la modalità pubblicità personalizzata, Un router Cloud pubblicizza solo route di subnet VPC. La modalità pubblicitaria personalizzata ti consente anche di configurare un router Cloud per omettere la pubblicità delle route di subnet VPC.
La modalità di routing dinamico di un La rete VPC (a livello di regione o globale) determina quale subnet VPC instrada i router Cloud in quella rete fai pubblicità. Per maggiori dettagli, vedi Modalità pubblicitaria predefinita.
La modalità di routing dinamico controlla anche il modo in cui viene applicato ogni router Cloud come route dinamiche in una rete VPC. Per informazioni su questo comportamento, vedi Effetti della modalità di routing dinamico.
Quando configuri BGP per Cloud Interconnect, la VPN ad alta disponibilità Appliance router, puoi facoltativamente configurare le sessioni di peering del router per utilizzare l'autenticazione MD5.
ASN (Autonomous System Number)
Quando crei un router Cloud, scegli il lato Google ASN per tutte le sessioni BGP usato dal router Cloud. Le indicazioni per ogni prodotto elencato nella sezione Risorse aggiuntive fornisce dettagli su come ogni prodotto utilizza l'ASN.
Indirizzi di peering BGP
Le sessioni BGP per i seguenti prodotti utilizzano il protocollo IPv4 locale rispetto al collegamento
indirizzi nell'intervallo 169.254.0.0/16 come indirizzi di peering BGP:
- Per Dedicated Interconnect, puoi specificare Indirizzi IPv4 locali rispetto al collegamento per gli indirizzi di peering BGP o Google Cloud puoi selezionare automaticamente indirizzi locali rispetto al collegamento IPv4 non utilizzati.
- Per Partner Interconnect, Google Cloud seleziona automaticamente gli indirizzi IPv4 non utilizzati e locali rispetto al collegamento.
- Per la VPN ad alta disponibilità e la VPN classica di routing dinamico, puoi specificare gli indirizzi di peering BGP creano l'interfaccia BGP sul router Cloud.
Le appliance router utilizzano gli indirizzi IPv4 interni delle VM Google Cloud come BGP indirizzi IP esterni. Per maggiori dettagli, consulta Creazione dell'appliance router di Compute Engine.
Il router Cloud supporta anche gli indirizzi IPv6 per il peering BGP. Con dei peer IPv6 BGP, puoi creare sessioni BGP IPv6 Tunnel VPN ad alta disponibilità e VLAN Dedicated Interconnect allegati.
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 in bit inferiore, come /122.
Quando configuri una sessione BGP IPv6 nella VPN ad alta disponibilità, puoi
configurare manualmente gli indirizzi IPv6 di peering o fare in modo che Google Cloud assegni
automaticamente per te.
Per Dedicated Interconnect, gli indirizzi IPv6 di peering vengono automaticamente
e assegnati dall'intervallo di indirizzi unicast (GUA, Global unicast Address) 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 il peering BGP IPv6 su sessioni BGP IPv4 mediante BGP multiprotocollo (MP-BGP).
Il router Cloud annuncia prefissi IPv6 per Reti VPC che includono subnet a doppio stack. Per impostazione predefinita, gli intervalli di subnet IPv6 interne sono pubblicizzati automaticamente. Intervalli di subnet IPv6 esterne 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 utilizzando MP-BGP
- Sessioni BGP IPv6 che scambiano route IPv6 ma anche route IPv4 utilizzando MP-BGP
- Sia le sessioni BGP IPv4 sia le sessioni IPv6 eseguite in parallelo sulla stessa Tunnel VPN ad alta disponibilità o VLAN Dedicated Interconnect allegato; la sessione BGP IPv4 scambia solo route IPv4 e La sessione BGP scambia solo route IPv6
Per maggiori dettagli, consulta i seguenti documenti:
- Stabilisci sessioni BGP
- Crea una VPN ad alta disponibilità connesso a una VPN peer gateway
- Crea gateway VPN ad alta disponibilità per connettere il VPC reti
- Crea VLAN allegati (Dedicated Interconnect)
- Configura BGP multiprotocollo per BGP IPv4 e IPv6 sessioni
Per maggiori dettagli sugli annunci di route IPv6, consulta Modalità di pubblicità di routing:
Limitazioni IPv6
Il peering BGP IPv6 e lo scambio di route IPv6 non supportato 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 con uno, due o, in rari casi, tre attività software.
La selezione della lunghezza del percorso è pertinente solo all'interno di ogni individuo Attività software router Cloud. Software per singoli router Cloud le attività preferiscono in modo indipendente lunghezze del percorso dell'AS prima di prendere in considerazione del discriminatore di uscita (MED).
Ogni attività software invia i percorsi migliori per un determinato prefisso a un dal piano di controllo del router Cloud, che poi invia il suo meglio alla rete VPC.
Nei casi in cui viene eseguita più di un'attività software del router Cloud coinvolti, il percorso migliore di una determinata attività software per un prefisso potrebbe avere un lunghezza del percorso dell'AS diversa rispetto al percorso migliore per lo stesso prefisso su un altro un'attività software specifica.
Durante la configurazione sono necessarie più attività software del router Cloud Tunnel VPN ad alta disponibilità e VLAN Cloud Interconnect allegati con uno SLA. 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à della dinamica risultante route
La tabella seguente fornisce scenari di esempio e il numero di attività software usato da Google Cloud per implementare il router Cloud in ogni in questo scenario.
- Per le configurazioni ad alta disponibilità elencate nella tabella, vengono utilizzate due attività software per fornisce la ridondanza del software.
- Per i collegamenti VLAN, un'attività software separata gestisce ogni disponibilità perimetrale dominio con allegati.
| 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 una 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
tunnel, ciascuno connesso a interface 0 su diversi
gateway VPN ad alta disponibilità. |
Uno |
| Almeno due interfacce, di cui una connessa a un collegamento VLAN in un singolo dominio di disponibilità perimetrale e un'altra connessa un singolo tunnel VPN ad alta disponibilità, di dominio e di interfaccia del gateway VPN sono gli stessi, ad esempio il primo dominio di disponibilità perimetrale di 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. A
per creare un'interfaccia ridondante, usa 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 una VPN ad alta disponibilità
in cui ogni tunnel è collegato a diverse
Numeri di interfaccia del gateway VPN ad alta disponibilità, ad esempio uno
tunnel connesso a interface 0 di una VPN ad alta disponibilità
gateway VPN esterno e un altro tunnel connesso a interface 1 del
lo stesso gateway o uno 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à e per migliorare l'affidabilità. Durante la manutenzione, le nuove attività software di cui è stato eseguito il provisioning. I log del router on-premise indicano che le sessioni BGP sono state gestite da quelle attività software si sono arrestate e sono tornate (un lembo BGP).
La manutenzione del router Cloud è un processo automatico ed è progettata
in modo da non interrompere il routing. Gli eventi di manutenzione dovrebbero richiedere
non più di 60 secondi. Prima della manutenzione, il router Cloud invia
notifica di riavvio graceful (un pacchetto TCP FIN) al router on-premise.
Se il router on-premise può elaborare gli eventi di riavvio graceful, registra un evento di riavvio graceful durante la manutenzione del router Cloud. Per router on-premise che non supportano il riavvio graceful, assicurati che il timer di sospensione del router on-premise è impostato su 60 secondi. Per maggiori dettagli, vedi Gestisci i timer BGP.
Gli eventi di manutenzione del router Cloud non vengono annunciati in anticipo perché sulle route non vengono perse sui router on-premise configurati correttamente. Per ottenere i dettagli sugli eventi di manutenzione completati, consulta Identifica gli eventi di manutenzione del router.
Per informazioni su come funziona il riavvio graceful con il forwarding bidirezionale Rilevamento (BFD), consulta Riavvio controllato e BFD.
Modalità di pubblicità percorso
Usando BGP e un prodotto elencati nella sezione Risorse aggiuntive, Il router Cloud pubblicizza gli intervalli di indirizzi sulla tua rete on-premise. Ciò consente ai client nella tua rete on-premise di inviare e ricevere pacchetti e 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 BGP sessione per pubblicizzare i prefissi per i seguenti tipi di indirizzi di subnet intervalli di tempo. La modalità di routing dinamico del VPC controlla se gli intervalli di indirizzi di subnet pubblicizzati provengono solo dalla stessa regione o se provengono da tutte le regioni:
Modalità di routing dinamico a livello di regione: ogni router Cloud nella La rete VPC annuncia una subnet IPv4 principale e secondaria nella stessa regione del router Cloud. Se le condizioni per IPv6 route pubblicità, il router Cloud pubblicizza subnet IPv6 interna (
ipv6-access-type=INTERNAL) nella stessa regione router Cloud.Modalità di routing dinamico globale: ogni router Cloud nella La rete VPC annuncia una subnet IPv4 principale e secondaria da tutte le regioni in la rete VPC. Se le condizioni per IPv6 route pubblicità, il router Cloud pubblicizza subnet IPv6 interna (
ipv6-access-type=INTERNAL) da tutte le regioni del rete VPC.
Se pubblicizzi indirizzi IPv4 pubblici utilizzati privatamente, i sistemi on-premise potrebbero non sarà 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 la route della subnet pubblicità.
Modalità pubblicitaria personalizzata
La modalità pubblicità personalizzata ti consente di controllare i prefissi che un
Router Cloud fa pubblicità. 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
con un router Cloud o una sessione BGP. Esistono due metodi
categorie di route annunciate personalizzate:
Puoi pubblicizzare solo i prefissi IPv4 e IPv6 personalizzati. Questo tipo di configurazione la route annunciata omette le route di subnet che verrebbero annunciate utilizzando la route predefinita modalità pubblicitaria.
È possibile pubblicizzare prefissi IPv4 e IPv6 personalizzati oltre alle subnet route. Questo tipo di route annunciata personalizzata include le stesse route di subnet Sono pubblicizzati tramite la modalità pubblicitaria predefinita.
Se scegli di pubblicizzare route di subnet, i relativi annunci vengono aggiornati automaticamente come descritto in Aggiornamenti automatici per le route di subnet pubblicità.
Se le condizioni per la pubblicità di route IPv6 sono soddisfatte, Il router Cloud annuncia una subnet IPv6 interna ogni volta che scegli di pubblicizzare la subnet route. Devi aggiungere qualsiasi subnet IPv6 esterna al tuo elenco di route personalizzate in per pubblicizzarli.
Per il numero massimo di route annunciate personalizzate che possono essere annunciate su ciascuna sessione BGP consulta il numero massimo di route annunciate personalizzate per BGP sessione nella pagina dei limiti del router Cloud. Questo valore massimo si applica alle route annunciate personalizzate per l'intero 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 al router Cloud e alle singole sessioni BGP router Cloud. Nella tabella seguente vengono descritti i prefissi da pubblicizzato nella sessione BGP, in base alla modalità pubblicitaria selezionata il router Cloud e il BGP durante la sessione.
| 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 vengono annunciate come descritto in Modalità pubblicitaria predefinita. |
| personalizzata | predefinita | La sessione BGP eredita la configurazione del router Cloud. Vengono annunciate route personalizzate configurate sull'intero router Cloud come descritto in Impostazioni personalizzate modalità pubblicitaria. Le route annunciate potrebbero contenere alcune o tutte le route di subnet. |
| predefinita o personalizzata | personalizzata | La sessione BGP non eredita il router Cloud configurazione. Route annunciate personalizzate configurate nella sessione BGP stessa sono pubblicizzati come descritto nella sezione modalità pubblicitaria. Le route annunciate potrebbero contenere alcune o tutte le subnet route. |
Aggiornamenti automatici per gli annunci di route di subnet
Il router Cloud aggiorna automaticamente gli annunci di route di subnet le 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
Condizioni per annuncio di route IPv6
Il router Cloud può pubblicizzare le route IPv6 quando: sono soddisfatte:
Il prodotto utilizzato con il router Cloud, ad esempio il gateway VPN ad alta disponibilità è configurato in modo da utilizzare (doppio stack).
La sessione BGP IPv6 è configurata e abilitata oppure la sessione BGP IPv4 è appositamente configurato per abilitare lo scambio di route IPv6 .
Per saperne di più sulla configurazione delle sessioni BGP, consulta Stabilisci sessioni BGP.
Per pubblicizzare gli intervalli di subnet IPv6 interne, il VPC la rete deve avere un IPv6 interno assegnato (ULA) intervallo e devi aver creato almeno un doppio stack una subnet con un'interfaccia Intervallo di subnet IPv6.
Prefissi e priorità pubblicizzati
Quando un router Cloud annuncia prefissi a un peer BGP, include una la priorità di ogni prefisso nella pubblicità (messaggio BGP). L'inserzionista viene implementata come un MED.
Puoi controllare i prefissi annunciati dal router Cloud a tutte o alcune delle sue sessioni BGP. Sei tu a 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 pubblicizzi intervalli personalizzati, ogni router Cloud pubblicizza solo di subnet nella stessa regione del router Cloud. Ogni intervallo è pubblicizzato come prefisso in cui il MED rappresenta la priorità di base.
Se la tua rete VPC utilizza la modalità di routing dinamico globale, a meno che Pubblichi intervalli personalizzati, ciascun router Cloud pubblicizza intervalli di subnet dalla sua regione locale come prefissi il cui MED corrisponde alla priorità di base. Inoltre, i router Cloud pubblicizzano intervalli di subnet diversi regioni come prefissi i cui MED corrispondono alla priorità di base più un valore ad accesso meno frequente per ridurre i costi di archiviazione. Google Cloud calcola automaticamente un costo da regione a regione in base come le prestazioni della rete, la distanza e la larghezza di banda disponibile regioni. Ogni costo da regione a regione ha un valore specifico per una coppia di regioni: la regione della subnet e la regione del router Cloud.
Quando i router on-premise ricevono i prefissi annunciati e i relativi le priorità, creano route utilizzate per inviare pacchetti al tuo 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 il BGP durante la sessione. La priorità di base pubblicizzata si applica a tutti i prefissi (destinazioni) annunciate 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 ti consentono di specificare quali tunnel Cloud VPN I sistemi on-premise per i collegamenti VLAN utilizzano per inviare di pacchetti alla rete VPC. Puoi creare impostazioni per lo stato attivo-passivo o una combinazione personalizzata di queste topologie usando il modello la priorità. 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à in Cloud VPN documentazione.
Quando scegli le priorità di base, tieni presente quanto segue:
I costi da regione a regione sono compresi tra
201e9999inclusi. Il valore dipende dalla distanza, dalla latenza e da altri fattori tra le due regioni. Google genera i valori di costo da regione a regione e non puoi modificarli.Priorità di base tra i router Cloud in una regione il valore consigliato è compreso tra
0e200inclusi. Poiché i costi da regione a regione sono almeno201, se utilizzi le priorità di base di201o superiore, potresti assegnare accidentalmente un tunnel Cloud VPN o una VLAN per gli allegati una priorità inferiore rispetto a quella desiderata. Un'altra sessione BGP in regioni diverse potrebbero pubblicizzare lo stesso prefisso con un numero della priorità (MED, che equivale alla priorità di base più il costo da regione a regione). Se non imposti attentamente le priorità di base in altre regioni, potresti causare traffico on-premise da distribuire alla rete VPC di un collegamento VLAN o un tunnel Cloud VPN imprevisto.Le priorità di base pari o superiori a
10200assicurano che un prefisso venga pubblicizzato nel complesso della priorità (MED, priorità di base più costo regione per regione) è 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à di base delle route annunciate.
Esempi
Questa sezione fornisce esempi che mostrano come i costi da regione a regione influenzano 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, osserva il seguente diagramma, include valori di esempio per il costo per 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 proveniente dalla rete on-premise a ciascuna 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 presso 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 | 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 presso 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 | 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 presso 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 | 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 hanno modificato le priorità di base per ottenere un'esperienza Coppia di tunnel VPN ad alta disponibilità 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 proveniente dalla rete on-premise a ciascuna 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 presso 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 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 presso 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 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 presso 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 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. Specifica priorità di base più grandi
per i tunnel VPN ad alta disponibilità nella regione us-central1
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 proveniente dalla rete on-premise a ciascuna 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 presso us-central1.
Il traffico proveniente 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 | 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 presso europe-west1.
Il traffico proveniente 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 | 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 presso us-west1.
Il traffico proveniente 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 | 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 in ogni rete. L'altra rete potrebbe essere la tua rete on-premise, una in un altro cloud provider o in 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 che configuri manualmente per una singola sessione BGP (personalizzate route apprese)
Utilizzando entrambi i tipi di route apprese, il router Cloud crea route dinamiche per la tua rete VPC. Ogni route dinamica creata Il router Cloud deriva da una o più 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, Lunghezza del percorso AS per creare route dinamiche. Le seguenti sezioni descrivono maggiori informazioni su questo processo e sulle route apprese in generale.
Route apprese personalizzate
Come descritto nella sezione precedente, puoi configurare una sessione BGP mediante 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, route statiche non è in grado di rilevare una perdita di raggiungibilità nell'hop successivo di una route. Nel al contrario, le route apprese personalizzate possono rilevare una perdita di connettività reagire di conseguenza per evitare di perdere traffico senza notifica.
Per ulteriori informazioni, vedi Route apprese personalizzate.
Effetti della modalità di routing dinamico
La modalità di routing dinamico di un La 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 la route dinamica per la destinazione e l'hop successivo nella stessa regione dell' router Cloud. Il router Cloud imposta la priorità route dinamica alla priorità di base, che Il router Cloud deriva dal discriminatore di più uscite (MED) pubblicizzato dal router on-premise.
In modalità di routing dinamico globale, il router Cloud crea una per la destinazione e l'hop successivo in ogni regione di Google Cloud. Nella regione che contiene il router Cloud che ha appreso la route, Il router Cloud imposta la priorità della route dinamica su la priorità di base. In tutte le altre regioni, il router Cloud imposta la priorità sulla priorità di base più un'appropriata regione ad accesso meno frequente per ridurre i costi di archiviazione.
Puoi definire la priorità delle route a Google Cloud esportate in del router on-premise. Tuttavia, il router on-premise potrebbe sostituire questa impostazione la 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 dell'AS e i valori MED e calcola una come descritto nelle due sezioni successive.
Lunghezza del percorso AS in anteposizione e lunghezza del percorso AS
L'anticipo del percorso AS è un mezzo mediante il quale un hop successivo per una destinazione (prefisso) viene la priorità viene intenzionalmente ridotta, in modo che un diverso hop successivo viene selezionata la destinazione con una lunghezza del percorso AS più breve. Il MED è considerato solo quando la lunghezza del percorso AS degli hop successivi è la stessa.
Google Cloud può utilizzare il percorso AS per selezionare un hop successivo tra le sessioni BGP e implementato mediante la stessa attività software del router Cloud.
In che modo Google Cloud utilizza il percorso AS
Il percorso dell'AS in attesa non è pertinente al piano di controllo e al VPC in ogni rete. La lunghezza del percorso dell'AS viene considerata solo all'interno di ogni router Cloud un'attività software come descritto negli scenari seguenti.
Se una singola attività software del router Cloud apprende la stessa destinazione due o più sessioni BGP:
- L'attività software sceglie una sessione BGP dell'hop successivo con l'AS più breve della lunghezza del percorso.
- L'attività software invia le informazioni sulla destinazione, sull'hop successivo e sul MED dal piano di controllo del router Cloud.
- Il piano di controllo utilizza le informazioni per creare uno o più candidati route. 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 l'AS più breve della lunghezza del percorso.
- Ogni attività software invia le informazioni sulla destinazione, sull'hop successivo e sul MED alla dal 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ù più route nella rete VPC, in base modalità di routing dinamico della rete. In modalità di routing dinamico globale, la priorità ciascuna route dinamica regionale viene regolata in regioni diverse nella regione del router Cloud. Per maggiori dettagli su come Google Cloud seleziona una route, vedi Ordine di routing in documentazione di VPC.
Priorità di base, MED e origine
Il router Cloud utilizza il valore MED pubblicizzato dal tuo router peer per calcola una priorità di base:
- Se il valore MED per il prefisso di una destinazione è compreso tra
0e231 -1(incluso), il router Cloud imposta la base la priorità al 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 venga applicato durante la selezione del percorso migliore tra più apprese per la stessa destinazione, il valore dell'attributo di origine BGP le route ricevute devono essere le stesse. Altrimenti, la selezione avviene in base al valore dell'attributo origine, che precede il passaggio di confronto MED nel processo di selezione del percorso migliore (RFC 4271).
Il router Cloud annuncia le route BGP ai suoi peer con l'origine
valore dell'attributo impostato su Incomplete. Questo valore è l'origine meno preferita
digita nella selezione della route.
Il valore di priorità finale che il router Cloud imposta al momento della creazione le route dinamiche in una rete VPC dipendono modalità di routing. Per ulteriori informazioni, vedi Effetti della modalità di routing dinamico.
Route statiche
Quando un'istanza invia un pacchetto, Google Cloud tenta di selezionarne uno 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
Nei casi in cui hai una subnet VPC e una route on-premise un annuncio pubblicitario con intervalli di indirizzi sovrapposti, Google Cloud indirizza il traffico in uscita a seconda dei relativi intervalli di indirizzi.
Per ulteriori informazioni, vedi Percorsi applicabili nella documentazione del VPC.
Trasferimento dati site-to-site
Se devi trasferire dati tra due siti esterni all'account Google Cloud, utilizza Network Connectivity Center. Network Connectivity Center collabora con il router Cloud per annunciamo dinamicamente le route tra le sessioni BGP.
Il router Cloud da solo non supporta questa funzionalità (anche in modo dinamico o configurando route annunciate personalizzate che corrispondono prefissi appresi). Se aggiungi una route annunciata personalizzata a una sessione BGP, e quella route pubblicizzata si sovrappone a una route appresa da un'altra sessione BGP, la route appresa potrebbe essere abbandonata.
Quote di route apprese
Esistono diverse quote che possono influire sulle route apprese. Per ulteriori informazioni, consulta Quote.
Le route IPv4 e IPv6 vengono conteggiate ai fini dello stesso numero massimo e non hanno route quotas.
Per monitorare l'utilizzo rispetto alle quote, 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 queste quote, metriche utilizzabili per monitorarle e come risolvere i problemi, consulta Controlla 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 un
percorso predefinito, che è l'ultima risorsa quando non sono disponibili altre opzioni. Per
Ad esempio, le reti VPC di Google Cloud includono
route predefinita che invia traffico al gateway internet. La route predefinita
per IPv4 è 0.0.0.0/0 e per IPv6 è ::/0.
A volte potresti voler indirizzare il traffico alla tua rete on-premise
per impostazione predefinita. Per farlo, puoi pubblicizzare una route predefinita dalla tua rete on-premise.
al router Cloud. Con il router Cloud, non è necessario
e gestire route statiche. Se pubblicizzi un percorso predefinito
rete on-premise, verifica che abbia la priorità su altre
create route predefinite (ha un valore MED più basso). Vai alla sezione
Pagina Route
e visualizza la Priorità per i percorsi 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, viene un errore su entrambi i lati della sessione BGP provoca l'errore della sessione e è disturbato. Dopo il superamento del timeout BGP, che è pari a 60 secondi Le route vengono ritirate da entrambi i lati.
Senza il supporto riavvio graceful, il deployment di due gateway on-premise ognuno dei quali fornisce ridondanza e failover. Questa configurazione abilita una tunnel e i suoi dispositivi di andare offline per gli upgrade o la manutenzione del software senza bloccare il traffico. Inoltre, se un tunnel presenta errori, l'altro può mantenere il livello percorsi attivi e traffico.
Eventi di manutenzione
Il router Cloud viene sottoposto a manutenzione periodica, che 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 più basso dei due valori da entrambi i lati. Il router Cloud utilizza il valore 60 secondi (per impostazione predefinita) per il timer di blocco BGP. Ti consigliamo di impostare il blocco BGP a un timer di almeno 60 secondi sul router (peer) on-premise. Di conseguenza, entrambi i router mantengono la loro 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 è stata reimpostata e instrada devono essere imparate di nuovo. I tempi di recupero dei gateway Cloud VPN circa un minuto. Se sono presenti gateway Cloud VPN ridondanti, il traffico viene non è interessato perché viene rimosso 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 ogni router Cloud nel tuo Virtual Private Cloud come richiesto dalla specifica RFC 6286.
In genere, l'identificatore BGP viene assegnato automaticamente, ma puoi configurare il tuo router Cloud con un intervallo di identificatori BGP esplicito. Se scegli per assegnare il tuo intervallo di identificatori BGP, al tuo router Cloud viene assegnato un identificatore BGP stabile nell'intervallo selezionato. Un router Cloud non è configurato con un intervallo di identificatori BGP. Viene assegnato un identificatore BGP basato sul suo indirizzo di 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 un intervallo di identificatori BGP automaticamente.
Per ulteriori informazioni, vedi Configura l'intervallo di identificatori BGP per router Cloud.
Riavvii delle sessioni BGP
L'identificatore BGP di un router Cloud attivo può cambiare a causa di uno qualsiasi dei seguenti:
- Aggiorna o rimuovi manualmente l'intervallo di identificatori BGP configurato.
- Rimuovi un'interfaccia IPv4 dal router Cloud e non un intervallo di identificatori BGP è assegnato.
Quando l'identificatore BGP di un router Cloud attivo cambia, ogni sessione BGP su quel router Cloud.
L'intervallo di identificatori di un router Cloud può cambiare anche quando il router è stata riavviata per manutenzione periodica e non ha un BGP assegnato o un intervallo di identificatori.
Risorse aggiuntive
Per ulteriori informazioni sull'uso del routing statico e dinamico con un 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 in corso istanze appliance router |
| VPN ad alta disponibilità | Richiede il routing dinamico con il router Cloud |
Creazione in corso
da un gateway VPN ad alta disponibilità connesso a un gateway VPN peer Creazione in corso... una VPN ad alta disponibilità tra le reti Google Cloud |
| VPN classica | Il routing dinamico tramite router Cloud è facoltativo | Creazione in corso
su una VPN classica che usa 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, vedi 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.