Cloud Router – Übersicht

Cloud Router ist ein vollständig verteilter und verwalteter Google Cloud-Dienst, der das Border Gateway Protocol (BGP) verwendet, um IP-Adressbereiche zu bewerben. Er programmiert benutzerdefinierte dynamische Routen auf der Grundlage von BGP-Advertisements, die von einem Peer empfangen werden. Anstelle eines physischen Geräts oder einer Appliance wird jeder Cloud Router durch Softwareaufgaben implementiert, die als BGP-Speaker und -Responder fungieren. Ein Cloud Router dient auch als Steuerungsebene für Cloud NAT. Cloud Router bietet BGP-Dienste für die folgenden Google Cloud-Produkte:

Sie können Cloud Router auch für ein klassisches VPN verwenden, wenn Ihr lokales VPN-Gateway BGP unterstützt. Diese Funktion wird jedoch am 31. März 2022 verworfen. Weitere Informationen finden Sie unter Teilweise Einstellung des klassischen VPN.

Wenn Sie Ihr lokales Netzwerk mit Google Cloud verbinden, verwendet Cloud Router BGP, um Routen zwischen Ihrem Google Cloud-VPC-Netzwerk und Ihrem lokalen Netzwerk dynamisch auszutauschen. Präfixänderungen und Änderungen des nächsten Hop werden automatisch zwischen Ihrem VPC-Netzwerk und Ihrem lokalen Netzwerk weitergegeben, ohne dass statische Routen erforderlich sind.

Jeder Cloud Router arbeitet mit einem der zuvor aufgeführten Produkte für Netzwerkverbindungen. Direct Peering und Carrier Peering verwenden keine Cloud Router.

Spezifikationen

Ein Cloud Router kann Subnetzrouten und benutzerdefinierte Präfixe in seinen BGP-Sitzungen bewerben. Sofern Sie keine benutzerdefinierten Route Advertisements verwenden, bewirbt ein Cloud Router nur Subnetzrouten. Mit benutzerdefinierten Route Advertisements können Sie auch einen Cloud Router so konfigurieren, dass Advertising-Subnetzrouten weggelassen werden.

Der dynamische Routing-Modus eines VPC-Netzwerks, entweder regional oder global, bestimmt, welches Subnetz die Cloud Router in diesem Netzwerk weiterleitet. Weitere Informationen finden Sie unter Standardmäßiges Route Advertisement.

Der Modus für dynamisches Routing steuert auch, wie jeder Cloud Router gelernte Präfixe als benutzerdefinierte dynamische Routen in einem VPC-Netzwerk anwendet. Weitere Informationen zu diesem Verhalten finden Sie unter Auswirkungen des dynamischen Routingmodus.

Autonome Systemnummer (ASN)

Wenn Sie einen Cloud Router erstellen, wählen Sie die Google-seitige ASN für alle vom Cloud Router verwendeten BGP-Sitzungen aus. Die Anleitung für jedes im Abschnitt Cloud Router verwenden aufgeführte Netzwerkverbindungsprodukt enthält Details zur Verwendung der ASN für jedes Produkt.

BGP-IP-Adressen

BGP-Sitzungen für die folgenden Produkte für Netzwerkverbindungen verwenden Link-Local-IP-Adressen im Bereich 169.254.0.0/16 als BGP-IP-Adressen:

  • Für Dedicated Interconnect können Sie entweder Kandidaten für Link-Local-BGP-IP-Adressen angeben oder Google Cloud kann nicht verwendete Link-Local-Adressen automatisch auswählen.
  • Bei Partner Interconnect wählt Google Cloud automatisch nicht verwendete Link-Local-Adressen aus.
  • Für HA VPN und klassisches VPN mit dynamischem Routing können Sie die BGP-IP-Adressen angeben, wenn Sie die BGP-Schnittstelle auf dem Cloud Router erstellen.

Router-Appliances verwenden interne IP-Adressen von Google Cloud-VMs als BGP-IP-Adressen. Weitere Informationen finden Sie unter Router-Appliance-Instanzen erstellen.

Zugriff auf interne Load-Balancer

Weitere Informationen zum Zugriff auf interne Load-Balancer aus einem verbundenen lokalen Netzwerk finden Sie in der Cloud Load Balancing-Dokumentation unter Interne Load-Balancer und verbundene Netzwerke.

Softwareaufgaben von Cloud Router

Cloud Router-Instanzen werden durch eine, zwei oder in seltenen Fällen auch durch drei Softwareaufgaben implementiert.

Die folgende Tabelle enthält Beispielszenarien sowie die Anzahl der Softwareaufgaben, die von Google Cloud zur Implementierung der Cloud Router-Instanz in jedem Szenario verwendet werden.

  • Für die in der Tabelle aufgeführten Hochverfügbarkeitskonfigurationen (HA) werden zwei Softwareaufgaben verwendet, um Softwareredundanz bereitzustellen.
  • Bei VLAN-Anhängen verarbeitet eine separate Softwareaufgabe jeweils eine Edge-Verfügbarkeitsdomain mit Anhängen.
Beispielszenario Anzahl der Softwareaufgaben, die zur Implementierung der Cloud Router-Instanz verwendet werden
Eine oder mehrere Schnittstellen, die jeweils mit einem klassischen VPN-Tunnel verbunden sind. Eins
Eine oder mehrere Schnittstellen, die jeweils mit einem VLAN-Anhang verbunden sind, wobei die VLAN-Anhänge sich in derselben Edge-Verfügbarkeitsdomain befinden. Eins
Eine beliebige Anzahl an Schnittstellen, die jeweils mit einem HA VPN-Tunnel verbunden sind, wobei alle Tunnel über ein oder mehrere HA VPN-Gateways mit derselben Schnittstellennummer verbunden sind, z. B. zwei Tunnel, die jeweils mit interface 0 auf verschiedenen HA VPN-Gateways verbunden sind. Eins
Mindestens zwei Schnittstellen und zwar eine verbunden mit einem VLAN-Anhang in einer einzelnen Edge-Verfügbarkeitsdomain und die andere verbunden mit einem einzelnen HA VPN-Tunnel, wobei die Edge-Verfügbarkeitsdomain und die VPN-Gateway-Schnittstellennummern identisch sind. Ein Beispiel sind die erste Edge-Verfügbarkeitsdomain in einem Paar von Edge-Verfügbarkeitsdomains und die erste VPN-Gateway-Schnittstelle. Eins
Mindestens zwei Schnittstellen, die jeweils mit einer Router-Appliance-Instanz verbunden sind, wobei eine der Schnittstellen als redundante Schnittstelle konfiguriert ist. Verwenden Sie zum Erstellen einer redundanten Schnittstelle das Flag redundant-interface (gcloud-Befehlszeilentool) oder das Feld redundantInterface (Compute Engine API). Die Router-Appliance ist Teil von Network Connectivity Center, das sich in der Vorschau befindet. Zwei
Mindestens zwei Schnittstellen, die jeweils mit einem VLAN-Anhang verbunden sind, wobei die VLAN-Anhänge sich in verschiedenen Edge-Verfügbarkeitsdomains befinden. Zwei
Mindestens zwei Schnittstellen, die jeweils mit einem HA VPN-Tunnel verbunden sind, wobei jeder Tunnel mit verschiedenen HA VPN-Gateway-Nummern verbunden ist. Ein Beispiel sind ein Tunnel, der mit interface 0 eines HA VPN-Gateways verbunden ist, und ein anderer Tunnel, der mit interface 1 desselben Gateways oder eines anderen Gateways verbunden ist. Zwei
Ein Cloud Router mit mindestens den folgenden Elementen:
  • Eine Schnittstelle, die mit einem VLAN-Anhang in edge availability domain 0 und/oder einer Schnittstelle verbunden ist, die mit einem HA VPN-Tunnel verbunden sind, der wiederum mit interface 0 eines HA VPN-Gateways verbunden ist.
  • Eine Schnittstelle, die mit einem VLAN-Anhang in edge availability domain 1 und/oder mit einer Schnittstelle verbunden ist, die mit einem HA VPN-Tunnel verbunden ist, der wiederum mit interface 1 eines HA VPN-Gateways verbunden ist.
  • Eine Schnittstelle, die mit einem klassischen VPN-Tunnel verbunden ist.
Drei

Softwarewartung und automatisierte Neustarts von Aufgaben

Google Cloud führt regelmäßig Wartungsereignisse durch, um neue Features einzuführen und die Zuverlässigkeit zu verbessern. Während der Wartung werden neue Softwareaufgaben bereitgestellt. Die Logs des lokalen Routers weisen darauf hin, dass die von diesen Softwareaufgaben verwalteten BGP-Sitzungen beendet und wieder aktiviert wurden (BGP-Flap).

Die Wartung des Cloud Routers ist ein automatischer Prozess und ist darauf ausgelegt, das Routing nicht zu unterbrechen. Wartungsereignisse sollten nicht länger als 60 Sekunden dauern. Vor der Wartung sendet Cloud Router eine Benachrichtigung über den ordnungsgemäßen Neustart (ein TCP-FIN-Paket) an den lokalen Router.

Wenn Ihr lokaler Router Ereignisse für ordnungsgemäße Neustarts verarbeiten kann, wird während der Wartung des Cloud Routers ein Ereignis für einen ordnungsgemäßen Neustart protokolliert. Achten Sie bei lokalen Routern, die keinen ordnungsgemäßen Neustart unterstützen, darauf, dass der Hold-Timer des lokalen Routers auf 60 Sekunden eingestellt ist. Weitere Informationen finden Sie unter BGP-Timer verwalten.

Cloud Router-Wartungsereignisse werden nicht im Voraus angekündigt, da Routen auf ordnungsgemäß konfigurierten lokalen Routern nicht verloren gehen. Weitere Informationen zu abgeschlossenen Wartungsereignissen finden Sie unter Routerwartungsereignisse identifizieren.

Automatisierte Aufgaben werden neu gestartet, wenn sich Routerkennungen ändern

Softwareaufgaben von Cloud Router verwenden eine interne Kennung, die auf der letzten Schnittstelle in der Schnittstellenliste des Cloud Routers basiert. Wenn Sie diese Schnittstelle löschen, startet Google Cloud die Cloud Router-Softwareaufgaben neu, um ihnen neue Kennungen zuzuweisen. Folglich kann das Löschen einer BGP-Sitzung dazu führen, dass alle anderen BGP-Sitzungen wie bei einer Softwarewartung neu gestartet werden. In diesem Fall werden Routen auf ordnungsgemäß konfigurierten lokalen Routern beibehalten.

Die interne Kennung ist für Sie nicht sichtbar und ändert sich manchmal während Softwarewartungen und automatischen Aufgabenneustarts.

Route Advertisement-Modi

Mithilfe von BGP und einem Produkt für die Netzwerkverbindung bewirbt ein Cloud Router IP-Adressbereiche für Ihr lokales Netzwerk. Dadurch können Clients in Ihrem lokalen Netzwerk Pakete an Ressourcen in Ihrem VPC-Netzwerk senden und von diesen empfangen.

Cloud Router bietet zwei Route Advertisement-Modi: Standardmäßiges Route Advertisement und benutzerdefiniertes Route Advertisement.

Standardmäßiges Route Advertisement

Wenn Sie den standardmäßigen Route Advertisement-Modus verwenden, bewirbt ein Cloud Router Präfixe für Subnetz-Routen gemäß dem dynamischen Routing-Modus des VPC-Netzwerks:

  • Wenn Sie den regionalen dynamischen Routingmodus verwenden, bewirbt jeder Cloud Router im VPC-Netzwerk nur Subnetzrouten in derselben Region wie der Cloud Router.

  • Wenn Sie den globalen dynamischen Routingmodus verwenden, bewirbt jeder Cloud Router im VPC-Netzwerk alle Subnetzrouten aus allen Regionen des VPC-Netzwerks.

Die primäre interne IP-Adresse einer VM muss aus dem primären IPv4-Bereich eines Subnetzes stammen. VMs können auch Adressen aus Alias-IP-Bereichen verwenden. Alias-IP-Bereiche können entweder aus dem primären oder sekundären IPv4-Bereich eines Subnetzes stammen. Cloud Router aktualisieren ihre standardmäßigen Route Advertisements in folgenden Fällen automatisch:

Benutzerdefiniertes Route Advertisement

Mit dem benutzerdefinierten Route Advertisement-Modus können Sie die Routen steuern, die ein Cloud Router anbietet. Sie können benutzerdefiniertes Route Advertisement für alle BGP-Sitzungen auf einem Cloud Router oder für einzelne BGP-Sitzungen angeben. Wenn Sie benutzerdefiniertes Route Advertisement konfigurieren, können Sie Folgendes tun:

  • Zusätzlich zu den benutzerdefinierten Bereichen können Sie den Cloud Router so konfigurieren, dass IPv4-Bereiche des Subnetzes genauso wie der standardmäßige Route Advertisement-Modus beworben werden. Das Advertisement von Subnetzbereichen kann nützlich sein, da Cloud Router das Route Advertisement im Subnetz weiterhin automatisch aktualisiert, wenn Sie ein Subnetz hinzufügen, ein Subnetz löschen, den primären IPv4-Bereich eines Subnetzes erweitern oder den sekundären IPv4-Bereich eines Subnetzes bearbeiten.

  • Sie können das automatische Route Advertisement von Subnetzen deaktivieren. So können Sie selektiv Subnetzbereiche, Teile von Subnetzbereichen, aggregierte Subnetzbereiche oder gar keine Subnetzbereiche bewerben. Informationen zum Advertising bestimmter Subnetzbereiche finden Sie unter Bestimmte VPC-Subnetze bewerben.

Weitere Informationen finden Sie unter Benutzerdefinierte IP-Bereiche bewerben.

Umfang des Route Advertisement-Modus

Wenn Sie einen Cloud Router erstellen, wählen Sie den Route Advertisement-Modus für den gesamten Cloud Router aus. Wenn Sie für eine BGP-Sitzung keinen anderen Route Advertisement-Modus angeben, gilt der Cloud Advertisement-Modus des Cloud Routers für jede BGP-Sitzung auf dem Cloud Router.

Wenn ein Cloud Router den standardmäßigen Route Advertisement-Modus verwendet, verwendet jede seiner BGP-Sitzungen den standardmäßigen Route Advertisement-Modus, es sei denn, Sie haben eine BGP-Sitzung für die Verwendung von benutzerdefiniertem Route Advertisement konfiguriert.

Wenn ein Cloud Router den benutzerdefinierten Route Advertisement-Modus verwendet, verwendet jede seiner BGP-Sitzungen den benutzerdefinierten Route Advertisement-Modus mit den benutzerdefinierten Route Advertisements, die für den gesamten Cloud Router konfiguriert sind, es sei denn, Sie haben eine BGP-Sitzung so konfiguriert, dass sie einen anderen Satz von benutzerdefinierten Route Advertisements verwendet.

Die maximale Anzahl von Präfixen, die in jeder BGP-Sitzung beworben werden können, finden Sie auf der Seite "Cloud Router-Limits" unter Maximale Anzahl von benutzerdefinierten Route Advertisements pro BGP-Sitzung. Dieser Höchstwert gilt unabhängig davon, wie die benutzerdefinierten Routenanzeigen der BGP-Sitzung definiert sind – für den gesamten Cloud Router oder einzeln pro BGP-Sitzung.

Beworbene Präfixe und Prioritäten

Wenn ein Cloud Router Präfixe für einen BGP-Peer bewirbt, enthält er für jedes Präfix im Advertising (BGP-Nachricht) eine Priorität. Die beworbene Priorität wird als MED-Datei implementiert.

Sie können steuern, welche Präfixe Cloud Router für alle oder einige seiner BGP-Sitzungen bewirbt. Sie steuern die beworbene Priorität (MED) durch Festlegen einer Basispriorität für die Präfixe.

  • Wenn Ihr VPC-Netzwerk den Modus für regionales dynamisches Routing verwendet und Sie keine benutzerdefinierten Bereiche anbieten, bewirbt jeder Cloud Router nur die Subnetzbereiche in derselben Region wie der Cloud Router. Jeder Bereich wird als Präfix angeboten, wobei MED die Basispriorität ist.

  • Wenn Ihr VPC-Netzwerk den Modus für globales dynamisches Routing verwendet, bewirbt jeder Cloud Router Subnetzbereiche aus seiner lokalen Region als Präfixe, deren MED der Basispriorität entspricht, sofern Sie keine benutzerdefinierten Bereiche anbieten. Darüber hinaus bieten Cloud Router-Instanzen Subnetzbereiche aus verschiedenen Regionen als Präfixe an, deren MEDs der Basispriorität plus den Region-zu-Region-Kosten entsprechen. Google Cloud berechnet die Region-zu-Region-Kosten automatisch auf der Grundlage von Faktoren wie Netzwerkleistung, Entfernung und verfügbarer Bandbreite zwischen Regionen. Alle Region-zu-Region-Kosten haben einen bestimmten Wert, der für ein Paar aus zwei Regionen gilt: die Region des Subnetzes und die Region der Advertising-Cloud Router-Instanz.

Wenn Ihre lokalen Router die beworbenen Präfixe und ihre Prioritäten erhalten haben, erstellen sie Routen zum Senden von Paketen an Ihr VPC-Netzwerk.

Anleitung für Basisprioritäten

Wenn Sie eine BGP-Sitzung auf einem Cloud Router konfigurieren, können Sie eine Basispriorität für die BGP-Sitzung angeben. Die beworbene Basispriorität gilt für alle Präfixe (Ziele), die von dieser BGP-Sitzung beworben werden.

Basisprioritäten sind ganze Zahlen von 0 bis 65535. Die höchstmögliche Basispriorität ist 0. Die Standardbasispriorität ist 100. Wenn Sie keine Basispriorität angeben, wird die Standardpriorität verwendet.

Mit Basisprioritäten können Sie festlegen, welche Cloud VPN-Tunnel oder VLAN-Anhänge lokale Systeme verwenden, um Pakete an Ihr VPC-Netzwerk zu senden. Sie können Aktiv/Aktiv-, Aktiv/Passiv- oder benutzerdefinierte Kombinationen dieser Topologien mit der Basispriorität erstellen. Ein Beispiel mit HA VPN-Tunnel finden Sie unter Aktiv/Aktiv- und Aktiv/Passiv-Routingoptionen für HA VPN in der Cloud VPN-Dokumentation.

Beachten Sie bei der Auswahl der Basisprioritäten Folgendes:

  • Die Region-zu-Region-Kosten liegen zwischen 201 und 9999. Der Wert hängt von der Entfernung, der Latenz und anderen Faktoren zwischen zwei Regionen ab. Google generiert die Region-zu-Region-Kosten, die Sie nicht ändern können.

  • Die Basisprioritäten für BGP-Sitzungen zwischen Cloud Routern in einer Region müssen zwischen 0 und 200 liegen. Die Region-zu-Region-Kosten betragen mindestens 201. Wenn Sie also eine Basispriorität von 201 oder höher verwenden, kann es sein, dass Sie einem Cloud VPN-Tunnel oder einem VLAN-Anhang eine niedrigere Priorität zuweisen als beabsichtigt. Eine andere BGP-Sitzung in einer anderen Region bewirbt möglicherweise dasselbe Präfix mit einer höheren Priorität (MED = Basispriorität plus Region-zu-Region-Kosten). Wenn Sie die Basisprioritäten in anderen Regionen nicht sorgfältig festlegen, kann dies dazu führen, dass lokaler Traffic über einen nicht vorgesehenen Cloud VPN-Tunnel oder -VLAN-Anhang an Ihr VPC-Netzwerk gesendet wird.

  • Basisprioritäten von mindestens 10,200 können dafür sorgen, dass die Gesamtpriorität des beworbenen Präfixes (MED, Basispriorität plus Region-zu-Region-Kosten) immer niedriger ist als alle anderen beworbenen Präfixe mit einer maximalen Basispriorität von 200.

Weitere Informationen zum Festlegen einer Basispriorität finden Sie unter Basispriorität der beworbenen Route aktualisieren.

Beispiele

Dieser Abschnitt enthält Beispiele, die zeigen, wie sich die Region-zu-Region-Kosten auf beworbene MEDs auswirken, wenn Sie globales dynamisches Routing verwenden.

HA VPNs mit Aktiv/Aktiv-Tunneln

In diesem Beispiel verfügen Sie über ein VPC-Netzwerk mit Folgendem:

  • Ein Subnetz in jeder der folgenden Regionen: us-central1, europe-west1 und us-west-1
  • Einen Cloud Router, der zwei BGP-Sitzungen für zwei HA VPN-Tunnel in us-central1 verwaltet
  • Einen Cloud Router, der zwei BGP-Sitzungen für zwei HA VPN-Tunnel in us-west1 verwaltet

Eine Veranschaulichung dieses Beispiels finden Sie im folgenden Diagramm, das Beispielwerte für die Region-zu-Region-Kosten enthält.

HA VPNs mit Aktiv/Aktiv-Tunneln
HA VPNs mit Aktiv/Aktiv-Tunnel (zum Vergrößern klicken)

Angenommen, jede BGP-Sitzung hat die Standardbasispriorität 100.

In den folgenden Tabellen wird gezeigt, wie mit der Basispriorität und mit den Region-zu-Region-Kosten die beworbenen MED-Werte für den Traffic von Ihrem lokalen Netzwerk zu jedem Subnetz berechnet werden.

10.0.1.0/24 (us-central1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.1.0/24 des Subnetzes bewerben, der sich in us-central1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den HA VPN-Tunnel in us-central1, da die BGP-Sitzungen das niedrigste beworbene MED haben.

VPN-Tunnel Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0,
central-tunnel-1
100 0 100 1. Auswahl
west-tunnel-0,
west-tunnel-1
100 250 350 2. Auswahl

10.0.2.0/24 (europe-west1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.2.0/24 des Subnetzes bewerben, der sich in europe-west1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den HA VPN-Tunnel in us-central1, da die BGP-Sitzungen das niedrigste beworbene MED haben.

VPN-Tunnel Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0,
central-tunnel-1
100 300 400 1. Auswahl
west-tunnel-0,
west-tunnel-1
100 350 450 2. Auswahl

10.0.3.0/24 (us-west1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.3.0/24 des Subnetzes bewerben, der sich in us-west1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den HA VPN-Tunnel in us-west1, da die BGP-Sitzungen das niedrigste beworbene MED haben.

VPN-Tunnel Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0,
central-tunnel-1
100 250 350 2. Auswahl
west-tunnel-0,
west-tunnel-1
100 0 100 1. Auswahl

HA VPNs mit Aktiv/Passiv-Tunnel

In diesem Beispiel wird die gleiche Topologie wie im vorherigen Beispiel verwendet. Allerdings sind die Basisprioritäten geändert, um in jeder Region ein aktives/passives HA VPN-Tunnelpaar zu ermöglichen:

  • Ein primärer Tunnel, dessen BGP-Sitzung die Standardbasispriorität 100 hat
  • Ein sekundärer Tunnel, dessen BGP-Sitzung eine niedrigere Priorität von 351 hat

In den folgenden Tabellen wird gezeigt, wie mit der Basispriorität und mit den Region-zu-Region-Kosten die beworbenen MED-Werte für den Traffic von Ihrem lokalen Netzwerk zu jedem Subnetz berechnet werden.

10.0.1.0/24 (us-central1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.1.0/24 des Subnetzes bewerben, der sich in us-central1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den primären VPN-Tunnel in us-central1, da die BGP-Sitzung das niedrigste beworbene MED hat. Wenn dieser Tunnel nicht verfügbar ist, verwendet der Traffic den primären Tunnel in us-west1.

VPN-Tunnel Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0 100 0 100 1. Auswahl
central-tunnel-1 351 0 351 3. Auswahl
west-tunnel-0 100 250 350 2. Auswahl
west-tunnel-1 351 250 601 4. Auswahl

10.0.2.0/24 (europe-west1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.2.0/24 des Subnetzes bewerben, der sich in europe-west1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den primären VPN-Tunnel in us-central1, da die BGP-Sitzung das niedrigste beworbene MED hat. Wenn dieser Tunnel nicht verfügbar ist, verwendet der Traffic den primären Tunnel in us-west1.

VPN-Tunnel Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0 100 300 400 1. Auswahl
central-tunnel-1 351 300 651 3. Auswahl
west-tunnel-0 100 350 450 2. Auswahl
west-tunnel-1 351 350 701 4. Auswahl

10.0.3.0/24 (us-west1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.3.0/24 des Subnetzes bewerben, der sich in us-west1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den primären VPN-Tunnel in us-west1, da die BGP-Sitzung das niedrigste beworbene MED hat. Wenn dieser Tunnel nicht verfügbar ist, verwendet der Traffic den primären Tunnel in us-central1.

VPN-Tunnel Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0 100 250 350 2. Auswahl
central-tunnel-1 351 250 601 4. Auswahl
west-tunnel-0 100 0 100 1. Auswahl
west-tunnel-1 351 0 351 3. Auswahl

Global bevorzugte Dedicated Interconnect-Verbindung

Dieses Beispiel ist den vorherigen Beispielen ähnlich. Es wurden lediglich die beiden Cloud VPN-Tunnel in der Region us-west1 durch zwei VLAN-Anhänge ersetzt.

Eine Veranschaulichung dieses Beispiels finden Sie im folgenden Diagramm.

Global bevorzugte Dedicated Interconnect-Verbindung
Global bevorzugte Dedicated Interconnect-Verbindung (zum Vergrößern klicken)

Sie möchten die VLAN-Anhänge priorisieren. Dazu geben Sie größere Basisprioritäten für die HA VPN-Tunnel in der Region us-central1 an, um deren Priorität aufzuheben.

In den folgenden Tabellen wird gezeigt, wie mit der Basispriorität und mit den Region-zu-Region-Kosten die beworbenen MED-Werte für den Traffic von Ihrem lokalen Netzwerk zu jedem Subnetz berechnet werden.

10.0.1.0/24 (us-central1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.1.0/24 des Subnetzes bewerben, der sich in us-central1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den VLAN-Anhang in us-west1, da die BGP-Sitzungen das niedrigste beworbene MED haben.

VPN-Tunnel oder VLAN-Anhang Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0,
central-tunnel-1
351 0 351 2. Auswahl
west-attachment-0,
west-attachment-1
100 250 350 1. Auswahl

10.0.2.0/24 (europe-west1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.2.0/24 des Subnetzes bewerben, der sich in europe-west1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den VLAN-Anhang in us-west1, da die BGP-Sitzungen das niedrigste beworbene MED haben.

VPN-Tunnel oder VLAN-Anhang Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0,
central-tunnel-1
351 300 651 2. Auswahl
west-attachment-0,
west-attachment-1
100 350 450 1. Auswahl

10.0.3.0/24 (us-west1)

Diese Tabelle enthält die BGP-Sitzungen, die den IP-Adressbereich 10.0.3.0/24 des Subnetzes bewerben, der sich in us-west1 befindet.

Traffic von Ihrem lokalen Netzwerk verwendet den VLAN-Anhang in us-west1, da die BGP-Sitzungen das niedrigste beworbene MED haben.

VPN-Tunnel oder VLAN-Anhang Basispriorität Region-zu-Region-Kosten Beworbenes MED Pfadranking
central-tunnel-0,
central-tunnel-1
351 250 601 2. Auswahl
west-attachment-0,
west-attachment-1
100 0 100 1. Auswahl

Erkannte benutzerdefinierte dynamische Routen

Wenn ein Cloud Router mehrere nächste Hops für dasselbe Zielpräfix empfängt, verwendet Google Cloud Routenmesswerte und in einigen Fällen die AS-Pfadlänge, um benutzerdefinierte dynamische Routen in Ihrem VPC-Netzwerk zu erstellen. Dieser Vorgang wird in den folgenden Abschnitten erläutert.

Auswirkungen des dynamischen Routingmodus

Der dynamische Routingmodus eines VPC-Netzwerks bestimmt, wie benutzerdefinierte dynamische Routen angewendet werden, die von Cloud Routern erkannt werden:

  • Im regionalen dynamischen Routingmodus erstellt Cloud Router eine benutzerdefinierte dynamische Route für das Ziel und den nächsten Hop in derselben Region wie Cloud Router. Cloud Router legt als Priorität dieser benutzerdefinierten dynamischen Route die Basispriorität fest, die Cloud Router aus dem von Ihrem lokalen Router beworbenen MED ableitet.

  • Im globalen dynamischen Routingmodus erstellt Cloud Router eine benutzerdefinierte dynamische Route für das Ziel und den nächsten Hop in jeder Google Cloud-Region. In der Region, in der sich die Cloud Router-Instanz befindet, die diese Route erkannt hat, legt Cloud Router die Basispriorität als Priorität der benutzerdefinierten dynamischen Route fest. In allen anderen Regionen legt Cloud Router als Priorität die Basispriorität sowie die entsprechenden Region-zu-Region-Kosten fest.

Sie können die Routenpriorität für Routen zu Google Cloud definieren, die an Ihren lokalen Router exportiert werden. Der lokale Router kann diese Routenpriorität jedoch je nach Konfiguration überschreiben, z. B. wenn der lokale Router die Routenpriorität ändert.

Für Routen zu lokalen Routern, die von Cloud Router erkannt wurden, ruft Cloud Router die AS-Pfadlänge sowie die MED-Werte ab und berechnet eine Basispriorität, wie in den nächsten beiden Abschnitten beschrieben.

AS-Pfadvoranstellung und AS-Pfadlänge

Das Voranstellen von AS-Pfaden ist ein Mittel, mit dem die Priorität eines nächsten Hops für ein Ziel (Präfix) absichtlich herabgestuft wird, sodass ein anderer nächster Hop für dasselbe Ziel (Präfix) mit einer kürzeren AS-Pfadlänge ausgewählt wird. Der MED-Wert wird nur berücksichtigt, wenn die AS-Pfadlängen der nächsten Hops identisch sind.

Google Cloud kann mithilfe des AS-Pfads einen nächsten Hop unter BGP-Sitzungen auswählen, die von derselben Cloud Router-Softwareaufgabe implementiert wurden.

So verwendet Google den AS-Pfad

Das Voranstellen eines AS-Pfads ist für die Steuerungsebene und das VPC-Netzwerk irrelevant. Die Länge des AS-Pfads wird nur innerhalb der einzelnen Cloud Router-Softwareaufgaben berücksichtigt, wie in den folgenden Szenarien beschrieben.

Folgendes geschieht, wenn eine einzelne Cloud Router-Softwareaufgabe dasselbe Ziel aus zwei oder mehr BGP-Sitzungen erkennt:

  • Die Softwareaufgabe wählt die BGP-Sitzung für den nächsten Hop mit der kürzesten AS-Pfadlänge aus.
  • Die Softwareaufgabe sendet Informationen zum Ziel, zum nächsten Hop und zum MED-Wert an die Steuerungsebene des Cloud Routers.
  • Die Steuerungsebene verwendet die Informationen zum Erstellen einer oder mehrerer Kandidatenrouten. Die Basispriorität jedes Kandidaten wird auf den erhaltenen MED-Wert eingestellt.

Folgendes geschieht, wenn zwei oder mehr Cloud Router-Softwareaufgaben dasselbe Ziel aus zwei oder mehr BGP-Sitzungen erkennen:

  • Jede Softwareaufgabe wählt die BGP-Sitzung für den nächsten Hop mit der kürzesten AS-Pfadlänge aus.
  • Jede Softwareaufgabe sendet Informationen zum Ziel, zum nächsten Hop und zum MED-Wert an die Steuerungsebene des Cloud Routers.
  • Die Steuerungsebene verwendet die Informationen zum Erstellen von zwei oder mehr Kandidatenrouten. Die Basispriorität jedes Kandidaten wird auf den erhaltenen MED-Wert eingestellt.

Die Cloud Router-Steuerungsebene installiert dann eine oder mehrere benutzerdefinierte dynamische Routen im VPC-Netzwerk, wobei dies entsprechend dem Modus für dynamisches Routing des VPC-Netzwerks erfolgt. Im Modus für globales dynamisches Routing wird die Priorität jeder regionalen benutzerdefinierten dynamischen Route in anderen Regionen als der Cloud Router-Region angepasst. Ausführliche Informationen zum Auswählen einer Route durch Google Cloud finden Sie unter Routingreihenfolge in der VPC-Dokumentation.

Basispriorität und MED

Cloud Router verwendet den von Ihrem Peer-Router beworbenen MED-Wert, um eine Basispriorität zu berechnen:

  • Wenn der MED-Wert für das Präfix eines Ziels zwischen 0 und 231 -1 (einschließlich) liegt, legt Cloud Router die Basispriorität auf den MED-Wert fest.
  • Wenn der MED-Wert für das Präfix eines Ziels zwischen 231 und 232 -1 (einschließlich) liegt, legt Cloud Router für die Basispriorität den Wert 231 -1 fest.

Die endgültige Priorität, die Cloud Router beim Erstellen benutzerdefinierter dynamischer Routen in einem VPC-Netzwerk festlegt, hängt vom dynamischen Routingmodus des Netzwerks ab. Weitere Informationen finden Sie unter Auswirkungen des dynamischen Routingmodus.

Statische Routen

Wenn eine Instanz ein Paket sendet, versucht Google Cloud, aus der Menge der anwendbaren Routen eine Route gemäß der Routingreihenfolge auszuwählen. Weitere Informationen finden Sie im Abschnitt Routingreihenfolge der VPC-Dokumentation.

Überlappende IP-Bereiche

In Fällen, in denen Sie ein VPC-Subnetz und ein lokales Route Advertisement mit sich überlappenden IP-Adressbereichen haben, leitet Google Cloud den ausgehenden Traffic abhängig von deren IP-Bereichen weiter.

Weitere Informationen finden Sie in der VPC-Dokumentation unter Anwendbare Routen.

Advertising für eine Route, die von einer BGP-Sitzung erkannt wurde, gegenüber einer anderen BGP-Sitzung

Cloud Router unterstützt derzeit kein Advertising über statische Route Advertisements für eine lokale Route, die von einer BGP-Sitzung zu einer anderen BGP-Sitzung erkannt wird. Dies kann dazu führen, dass die Route gelöscht wird.

Weitere Informationen zum ordnungsgemäßen Austausch von dynamischen Routen mit mehreren VPC-Netzwerken finden Sie auf der Seite "Fehlerbehebung für Cloud Router" unter Einige lokale IP-Präfixe sind nicht verfügbar.

Limits für erkannte Routen

Für erkannte Routen gibt es zwei Beschränkungen. Diese Limits definieren nicht die maximale Anzahl erkannter Routen. Sie definieren stattdessen die maximale Anzahl eindeutiger Zielpräfixe. Informationen zu diesen Limits finden Sie unter Beschränkungen.

Wenn Sie Ihre Nutzung anhand dieser Limits überwachen möchten, verwenden Sie die folgenden Messwerte:

  • 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

Informationen zu Logmeldungen in Bezug auf diese Limits, zu den Messwerten, mit denen Sie diese überwachen können, und zum Beheben von Problemen finden Sie auf der Seite "Fehlerbehebung" unter Kontingente und Limits prüfen.

Standardroute

Wenn für ein bestimmtes IP-Ziel keine Route angegeben ist, wird der Traffic an eine Standardroute gesendet, die als letzte Möglichkeit dient, wenn keine anderen Optionen vorhanden sind. Beispielsweise enthalten Google Cloud VPC-Netzwerke automatisch eine Standardroute (0.0.0.0/0), die Traffic an das Internetgateway sendet.

Es kann vorkommen, dass Traffic standardmäßig an Ihr lokales Netzwerk weitergeleitet werden soll. Dafür bieten Sie eine Standardroute von Ihrem lokalen Router zu Cloud Router an. Mit Cloud Router müssen Sie keine statischen Routen erstellen und verwalten. Wenn Sie eine Standardroute von Ihrem lokalen Netzwerk bewerben, achten Sie darauf, dass diese Vorrang vor anderen automatisch erstellten Standardrouten hat. Dies ist am niedrigeren MED-Wert erkennbar. Auf der Seite "Routen" finden Sie die Priorität von Routen mit dem Wert 0.0.0.0/0 als Ziel-IP-Bereich und Default internet gateway als Nächsten Hop.

Cloud Router verwenden

Informationen zur Verwendung von Cloud Router mit einem Netzwerkverbindungsprodukt finden Sie in der Dokumentation des Produkts. Die Schritte zum Erstellen eines Cloud Routers oder zum Verwenden eines vorhandenen Cloud Routers sind in den folgenden Schritten enthalten.

Produkt Routing Dokumentation
Dedicated Interconnect Dynamisches Routing mit Cloud Router erforderlich VLAN-Anhänge erstellen
Partner Interconnect Dynamisches Routing mit Cloud Router erforderlich VLAN-Anhänge erstellen
Router-Appliances Dynamisches Routing mit Cloud Router erforderlich Router-Appliance-Instanzen erstellen
HA VPN Dynamisches Routing mit Cloud Router erforderlich HA VPN-Gateway zu einem und Peer-VPN--Gateway erstellen
HA VPN zwischen Google Cloud-Netzwerken erstellen
Klassisches VPN Dynamisches Routing mit Cloud Router ist optional Klassisches VPN mit dynamischem Routing erstellen
Klassisches VPN mit statischem Routing erstellen

Nächste Schritte