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 besteht jeder Cloud Router aus Softwareaufgaben, die als BGP-Speaker und -Responder dienen. Ein Cloud Router dient auch als Steuerungsebene für Cloud NAT. Cloud Router bietet BGP-Dienste für die folgenden Google Cloud-Produkte:

Jeder Cloud Router funktioniert mit mindestens einem der zuvor aufgeführten Produkte zur Netzwerkverbindung.

Wenn Sie ein lokales oder Multi-Cloud-Netzwerk mit Google Cloud verbinden, nutzt Cloud Router das BGP, um Routen zwischen Ihrem Google Cloud-VPC-Netzwerk und dem Remote-Netzwerk dynamisch auszutauschen. Änderungen an Präfixen und nächsten Hops werden automatisch zwischen Ihrem VPC-Netzwerk und dem anderen Netzwerk übertragen, ohne dass statische Routen erforderlich sind.

Sie können Cloud Router auch verwenden, um zwei VPC-Netzwerke in Google Cloud zu verbinden. In diesem Szenario verbinden Sie die VPC-Netzwerke mithilfe von zwei HA VPNs und zwei Cloud Routern, einem HA VPN und dem zugehörigen Cloud Router in jedem Netzwerk.

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, bietet ein Cloud Router nur Subnetzrouten an. 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.

Wenn Sie BGP für Cloud Interconnect, HA VPN und Router-Appliance konfigurieren, können Sie optional die Peering-Sitzungen des Routers für die Verwendung der MD5-Authentifizierung konfigurieren. Diese Feature befindet sich im Vorschaumodus.

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-IPv4-Adressen im Bereich 169.254.0.0/16 als BGP-IP-Adressen:

  • Für Dedicated Interconnect können Sie entweder Link-Local-Adressen für BGP-Adressen angeben oder Google Cloud kann Link-Local-Adressen automatisch auswählen, die nicht verwendet werden.
  • 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-Adressen angeben, wenn Sie die BGP-Schnittstelle auf dem Cloud Router erstellen.

Router-Appliances verwenden interne IPv4-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.

IPv6-Unterstützung

Cloud Router unterstützt Multiprotokoll-BGP (MP-BGP) und kann IPv6-Präfixe über BGP-IPv4-Sitzungen austauschen. Reine IPv6-Sitzungen werden nicht unterstützt.

Cloud Router bewirbt IPv6-Präfixe für VPC-Netzwerke, die Dual-Stack-Subnetze enthalten.

Cloud Router kann IPv6-Subnetzbereiche für VPC-Netzwerke bewerben, die Dual-Stack-Subnetze enthalten. Standardmäßig werden interne IPv6-Subnetzbereiche automatisch beworben. Externe IPv6-Subnetzbereiche werden nicht automatisch beworben. Sie können sie aber manuell über benutzerdefiniertes Route Advertisement anbieten.

Sie können den IPv6-Präfixaustausch in für HA VPN-Tunnel erstellten BGP-Sitzungen aktivieren. Weitere Informationen finden Sie in folgenden Dokumenten:

Weitere Informationen zu IPv6-Route Advertisements finden Sie unter Route Advertisement-Modi.

IPv6-Einschränkungen

Cloud Router unterstützt nur das regionale Routing von IPv6-Traffic in HA VPN-Tunneln. IPv6-Traffic wird innerhalb der Region weitergeleitet, die dem HA  VPN-Gateway zugewiesen ist. Globales Routing für IPv6-Traffic in HA VPN-Tunneln wird nicht unterstützt.

IPv6-Präfixaustausch wird in BGP-Sitzungen für die folgenden Ressourcen nicht unterstützt:

  • Dedicated Interconnect-VLAN-Anhänge
  • Partner Interconnect-VLAN-Anhänge
  • Klassische VPN-Tunnel
  • Router-Appliance (Teil von Network Connectivity Center)

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. Zum Erstellen einer redundanten Schnittstelle verwenden Sie das Flag redundant-interface (Google Cloud CLI) oder das Feld redundantInterface (Compute Engine API). Die Router-Appliance ist Teil von Network Connectivity Center, das sich im Vorschaumodus 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 der 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.

Informationen zur Funktionsweise von ordnungsgemäßem Neustart mit Bidirectional Forwarding Detection (BFD) finden Sie unter Ordnungsgemäßer Neustart und BFD.

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

Mit dem standardmäßigen Route Advertisement wird ein Cloud Router oder eine BGP-Sitzung konfiguriert, um Präfixe für die folgenden Arten von Subnetz-IP-Adressbereichen zu bewerben. Der dynamische Routingmodus des VPC-Netzwerks steuert, ob die beworbenen Subnetz-IP-Adressbereiche nur aus derselben Region wie der Cloud Router stammen oder aus allen Regionen:

Wenn Sie privat genutzte öffentliche IPv4-Adressen bewerben, können lokale Systeme möglicherweise nicht auf Internetressourcen zugreifen, die diese öffentlichen IPv4-Adressen verwenden.

Subnetz-Route-Advertisements werden automatisch aktualisiert, wie unter Automatische Aktualisierungen für Subnetz-Route-Advertisements beschrieben.

Das IPv6-Subnetz-Route-Advertisement befindet sich in der Vorschau.

Benutzerdefiniertes Route Advertisement

Mit dem benutzerdefinierten Route Advertisement haben Sie die Kontrolle über die Präfixe, die ein Cloud Router anbietet. Sie können benutzerdefinierte Route Advertisements (einschließlich Standardroutenpräfixe, 0.0.0.0/0 oder ::/0) für alle BGP-Sitzungen auf einem Cloud Router oder pro BGP-Sitzung angeben. Es gibt zwei Kategorien von benutzerdefinierten Route Advertisements:

  • Sie können nur benutzerdefinierte IPv4- und IPv6-Präfixe bewerben. Bei diesem benutzerdefinierten Advertisement-Typ werden die Subnetzrouten weggelassen, die mit dem standarmäßigen Route Advertisement beworben werden.

  • Sie können zusätzlich zu Subnetzrouten benutzerdefinierte IPv4- und IPv6-Präfixe bewerben. Diese Art von benutzerdefiniertem Advertisement enthält die gleichen Subnetzrouten, die mit dem standardmäßigen Route Advertisement beworben werden.

Wenn Sie Subnetzrouten bewerben, werden deren Advertisements automatisch aktualisiert, wie unter Automatische Aktualisierungen für Subnetz-Route-Advertisements beschrieben.

Wenn Bedingungen für IPv6-Advertisement erfüllt sind, bewirbt Cloud Router interne IPv6-Subnetzbereiche, wenn Sie Subnetzrouten bewerben. Sie müssen alle externen IPv6-Subnetzbereiche in die Liste der benutzerdefinierten Präfixe hinzufügen, um sie zu bewerben.

Die maximale Anzahl benutzerdefinierter Präfixe, 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 für benutzerdefiniertes Advertisement für den gesamten Cloud Router und einzeln pro BGP-Sitzung.

Weitere Informationen finden Sie in folgenden Dokumenten:

Gültige beworbene Präfixe

Der Route Advertisement-Modus kann sowohl auf dem gesamten Cloud Router als auch auf einzelnen BGP-Sitzungen des Cloud Routers konfiguriert werden. In der folgenden Tabelle wird anhand des ausgewählten Advertisement-Modus des Cloud Routers und der BGP-Sitzung beschrieben, welche Präfixe in der BGP-Sitzung beworben werden.

Modus für Cloud Router Modus für BGP-Sitzung Effektive beworbene Präfixe in der BGP-Sitzung
Standard Standard Die BGP-Sitzung übernimmt die Cloud Router-Konfiguration. Subnetzrouten werden wie unter Standardmäßiges Route Advertisement beschrieben beworben.
Benutzerdefiniert Standard Die BGP-Sitzung übernimmt die Cloud Router-Konfiguration. Benutzerdefinierte Routen, die für den gesamten Cloud Router konfiguriert sind, werden wie unter Benutzerdefiniertes Route Advertisement beschrieben, beworben. Benutzerdefinierte Routen können einige oder alle Subnetzrouten enthalten.
Standard oder benutzerdefiniert Benutzerdefiniert Die BGP-Sitzung übernimmt nicht die Cloud Router-Konfiguration. Benutzerdefinierte Routen, die in der BGP-Sitzung selbst konfiguriert sind, werden wie unter Benutzerdefiniertes Route Advertisement beschrieben beworben. Benutzerdefinierte Routen können einige oder alle Subnetzrouten enthalten.

Automatische Aktualisierungen für Subnetz-Route-Advertisements

Cloud Router aktualisiert das Subnetz-Route-Advertisement in den folgenden Situationen automatisch:

Bedingungen für IPv6-Advertisement

Cloud Router kann IPv6-Routen (Vorschau) anbieten, wenn alle der folgenden Bedingungen erfüllt sind:

  • Das mit Cloud Router verwendete Produkt für die Netzwerkverbindung, wie das HA VPN-Gateway, ist so konfiguriert, dass der Dual-Stack-Typ IPv4 und IPv6 verwendet wird.
  • Die BGP-Sitzung ist speziell zur Aktivierung des IPv6-Präfixaustauschs konfiguriert. Weitere Informationen finden Sie unter IPv6-Präfixaustausch aktivieren oder deaktivieren.

Damit Sie interne IPv6-Subnetzbereiche anbieten können, muss Ihrem VPC-Netzwerk ein zugewiesener interner (ULA) IPv6-Bereich zugewiesen sein und Sie müssen mindestens ein Dual-Stack-Subnetz mit einem internen IPv6-Subnetzbereich erstellt haben.

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, MED und Ursprung

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.

Damit MED während der besten Pfadauswahl zwischen mehreren erkannten Routen für dasselbe Ziel wirksam wird, muss der BGP-Ursprungswertwert für die empfangenen Routen identisch sein. Andernfalls erfolgt die Auswahl auf der Grundlage des Wertes des Ursprungsattributs, das dem MED-Vergleichsschritt bei der Auswahl des besten Pfads vorausgeht (RFC 4271).

Cloud Router bietet BGP-Routen zu seinen Peers an, deren Ursprungsattributwert auf Incomplete gesetzt ist. Dieser Wert ist der am wenigsten bevorzugte Ursprungstyp bei der Routenauswahl.

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 der gesicherten eindeutigen Zielpräfixe. Informationen zu diesen Limits finden Sie unter Beschränkungen.

IPv4- und IPv6-Routen werden auf den gleichen Maximumwert angerechnet und haben keine separaten Limits.

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, die Traffic an das Internetgateway sendet. Die Standardroute nur für IPv4 ist 0.0.0.0/0, für Dual-Stack-IPv4 und IPv6 ist sie 0.0.0.0/0, ::/0.

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.

Redundante Cloud VPN-Tunnel

Wenn das lokale Gateway keinen ordnungsgemäßen Neustart unterstützt, führt ein Fehler auf einer der beiden Seiten der BGP-Sitzung dazu, dass die Sitzung fehlschlägt und der Traffic unterbrochen wird. Bei Überschreiten des BGP-Zeitlimits, das bei Cloud Router 60 Sekunden beträgt, werden die Routen auf beiden Seiten abgebaut. Peers auf beiden Seiten des Tunnels tauschen statische Routen, aber keine dynamischen Routen aus.

Wenn ein ordnungsgemäßer Neustart nicht unterstützt wird, bietet die Bereitstellung von zwei lokalen Gateways mit je einem Tunnel Redundanz und Failover-Funktionalität. Mit dieser Konfiguration können ein Tunnel und seine Geräte für Software-Upgrades oder Wartungen offline geschaltet werden, ohne den Traffic zu unterbrechen. Wenn ein Tunnel ausfällt, kann der andere Tunnel die Aktivität der Routen beibehalten und den Datenverkehr weiterleiten.

Wartungsereignisse

Cloud Router wird regelmäßig gewartet, was weniger als 60 Sekunden dauert. Cloud Router ist während einer Wartung nicht verfügbar. Der BGP-Haltezeitgeber legt fest, wie lange erkannte Routen erhalten bleiben sollen, wenn der Peering-BGP-Router nicht verfügbar ist. Der BGP-Haltezeitgeber wird auf den kleineren Wert der beiden Seiten eingestellt. Cloud Router verwendet einen Wert von 60 Sekunden für den BGP-Haltezeitgeber. Wir empfehlen, dass Sie den BGP-Haltezeitgeber auf Ihrem lokalen (Peer-)Router auf mindestens 60 Sekunden einstellen (der Standardwert ist 3 Minuten). Dadurch erhalten beide Router ihre Routen während dieser Upgrades aufrecht und der Traffic fließt weiter.

Während der Cloud VPN-Gateway-Wartungszyklen bei einem einzelnen Cloud VPN-Gateway wird durch die Verwendung von Cloud Router die Dauer der Tunnelwiederherstellung um ca. 20 Sekunden verlängert, da die BGP-Sitzung zurückgesetzt wird und die Routen neu erkannt werden müssen. Die Wiederherstellung eines Cloud VPN-Gateways dauert in der Regel ca. eine Minute. Wenn redundante Cloud VPN-Gateways vorhanden sind, ist der Traffic nicht beeinträchtigt, da jeweils nur ein Cloud VPN-Gateway heruntergefahren wird.

BGP-Router-ID und BGP-Sitzung werden neu gestartet

Cloud Router wählt für die BGP-Router-ID die höchste Schnittstellen-IP-Adresse aus und behält diese ID, solange die Adresse verfügbar ist. Wenn Sie die Cloud Router-Schnittstelle löschen, die für die BGP-Router-ID verwendet wird, muss Cloud Router eine neue Router-ID auswählen. Durch diese Auswahl werden alle Ihre BGP-Sitzungen neu gestartet. Die Router-ID kann sich auch ändern, wenn Cloud Router aufgrund regelmäßiger Wartungsarbeiten neu gestartet wird.

Weitere Informationen

Weitere Informationen zur Verwendung von statischem und dynamischem Routing mit einem unterstützten Dienst finden Sie in der folgenden Dokumentation.

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