Cloud Router – Übersicht

Cloud Router ist ein vollständig verteilter und verwalteter Google Cloud-Dienst, der das Border Gateway Protocol (BGP) verwendet, um IP-Präfixe zu bewerben. Er programmiert 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 VPC-Subnetzrouten und benutzerdefinierte Präfixe (Virtual Private Cloud) in seinen BGP-Sitzungen (Border Gateway Protocol) anbieten. Sofern Sie keinen benutzerdefinierten Advertising-Modus konfigurieren, bewirbt ein Cloud Router nur VPC-Subnetzrouten. Mit dem benutzerdefinierten Advertising-Modus können Sie auch einen Cloud Router so konfigurieren, dass Advertising-VPC-Subnetzrouten weggelassen werden.

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

Der Modus für dynamisches Routing steuert auch, wie jeder Cloud Router gelernte Präfixe als 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.

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 Anleitungen für die einzelnen im Abschnitt Zusätzliche Ressourcen aufgeführten Produkte enthalten Details zur Verwendung der ASN pro Produkt.

BGP-Peering-Adressen

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

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

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

Cloud Router unterstützt auch IPv6-Adressen für BGP-Peering. Mit der Konfiguration von IPv6-BGP-Peers können Sie IPv6-BGP-Sitzungen über HA VPN-Tunnel und Dedicated Interconnect-VLAN-Anhänge erstellen.

Für HA VPN-Tunnel können Sie eindeutige IPv6-Adressen (ULA) im Bereich fdff:1::/64 als BGP-Peering-Adressen verwenden. Die Peering-Adressen für IPv6-BGP-Sitzungen müssen eine Maskenlänge von 126 oder einen niedrigeren Wert für die Bitzahl wie /122 verwenden. Wenn Sie eine IPv6-BGP-Sitzung in HA VPN konfigurieren, können Sie die Peering-IPv6-Adressen manuell konfigurieren oder sie von Google Cloud automatisch zuweisen lassen.

Bei Dedicated Interconnect werden die IPv6-Adressen automatisch aus dem globalen Unicast-Adressbereich (GUA) 2600:2d00:0:1::/64 von Google zugewiesen. Sie können für diese Peering-IPv6-Adressen keinen Kandidatenbereich angeben oder diese Peering-IPv6-Adressen manuell konfigurieren.

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 Passthrough-Network-Load Balancer und verbundene Netzwerke.

IPv6-Unterstützung

Cloud Router unterstützt den IPv6-Routenaustausch mit IPv6-BGP-Peering oder über IPv4-BGP-Sitzungen mithilfe von Multiprotokoll-BGP (MP-BGP).

Cloud Router bewirbt IPv6-Präfixe für VPC-Netzwerke, 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 benutzerdefinierte beworbene Routen anbieten.

Sie können die folgenden Arten von BGP-Sitzungen erstellen:

  • IPv4-BGP-Sitzungen, die nur IPv4-Routen austauschen
  • IPv6-BGP-Sitzungen, die nur IPv6-Routen austauschen
  • IPv4-BGP-Sitzungen, die IPv4-Routen, aber auch IPv6-Routen über MP-BGP austauschen
  • IPv6-BGP-Sitzungen, die IPv6-Routen, aber auch IPv4-Routen über MP-BGP austauschen
  • Sowohl IPv4-BGP-Sitzungen als auch IPv6-Sitzungen, die parallel über denselben HA VPN-Tunnel oder Dedicated Interconnect-VLAN-Anhang ausgeführt werden; die IPv4-BGP-Sitzung tauscht nur IPv4-Routen aus und die IPv6-BGP-Sitzung tauscht nur IPv6-Routen aus

Weitere Informationen finden Sie in folgenden Dokumenten:

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

IPv6-Einschränkungen

IPv6-BGP-Peering und IPv6-Routenaustausch werden für die folgenden Ressourcen nicht unterstützt:

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

Softwareaufgaben von Cloud Router

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

Die Auswahl der AS-Pfadlänge ist nur innerhalb jeder einzelnen Cloud Router-Softwareaufgabe relevant. Einzelne Cloud Router-Softwareaufgaben bevorzugen unabhängig voneinander kürzere AS-Pfadlängen, bevor der MED-Wert (Multi-Exit Diskriminator) berücksichtigt wird.

Jede Softwareaufgabe sendet ihre besten Pfade für ein bestimmtes Präfix an eine Cloud Router-Steuerungsebene. Anschließend sendet die Steuerungsebene ihre besten Pfade an das VPC-Netzwerk.

Wenn mehrere Cloud Router-Softwareaufgaben beteiligt sind, kann der beste Pfad einer bestimmten Softwareaufgabe für ein Präfix eine andere AS-Pfadlänge als der beste Pfad für dasselbe Präfix bei einer anderen Softwareaufgabe haben.

Beim Konfigurieren von HA VPN-Tunneln und Cloud Interconnect-VLAN-Anhängen mit einem SLA sind mehrere Cloud Router-Softwareaufgaben erforderlich. Um vorhersehbare Ergebnisse zu gewährleisten, empfiehlt Google daher Folgendes:

  • Lokale Präfixe mit derselben AS-Pfadlänge bewerben
  • Verwenden Sie MED-Werte nur, um die Priorität der resultierenden dynamischen Routen zu beeinflussen

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). Router-Appliance ist Teil von Network Connectivity Center. 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, das im Abschnitt Zusätzliche Ressourcen aufgeführt ist, bewirbt ein Cloud Router 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äßiger Advertisement-Modus und benutzerdefinierter Advertisement-Modus.

Standardmäßiger Advertising-Modus

Mit dem standardmäßigen Advertising-Modus wird ein Cloud Router oder eine BGP-Sitzung konfiguriert, um Präfixe für die folgenden Arten von Subnetz-Adressbereichen zu bewerben. Der dynamische Routingmodus des VPC-Netzwerks steuert, ob die beworbenen Subnetz-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.

Benutzerdefinierter Advertising-Modus

Mit dem benutzerdefinierten Advertising-Modus können Sie die Präfixe steuern, die ein Cloud Router anbietet. Sie können benutzerdefinierte beworbene Routen (einschließlich Standardroutenpräfixe, 0.0.0.0/0 für IPv4-Routen oder ::/0 für IPv6-Routen) für alle BGP-Sitzungen auf einem Cloud Router oder pro BGP-Sitzung angeben. Es gibt zwei Kategorien von benutzerdefinierten Routen:

  • Sie können nur benutzerdefinierte IPv4- und IPv6-Präfixe bewerben. Bei dieser Art von benutzerdefinierter Route werden die Subnetzrouten weggelassen, die im Standard-Advertising-Modus beworben werden.

  • Sie können zusätzlich zu Subnetzrouten benutzerdefinierte IPv4- und IPv6-Präfixe bewerben. Diese Art von benutzerdefinierter Route enthält dieselben Subnetzrouten, die im Standard-Advertising-Modus 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-Route-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 Routes hinzufügen, um sie zu bewerben.

Die maximale Anzahl benutzerdefinierter Routen, die in jeder BGP-Sitzung beworben werden können, finden Sie auf der Seite „Cloud Router-Limits“ unter Maximale Anzahl von benutzerdefinierten beworbenen Routen pro BGP-Sitzung. Dieser Höchstwert gilt für benutzerdefinierte beworbene Routen 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 Standard-Advertising-Modus 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 Benutzerdefinierter Advertising-Modus beschrieben, beworben. Beworbene Routen können einige oder alle Subnetzrouten enthalten.
Standard oder benutzerdefiniert Benutzerdefiniert Die BGP-Sitzung übernimmt nicht die Cloud Router-Konfiguration. Benutzerdefinierte beworbene Routen, die in der BGP-Sitzung selbst konfiguriert sind, werden wie unter Benutzerdefinierter Advertising-Modus 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-Route Advertisement

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

  • Das mit Cloud Router verwendete Produkt, wie das HA VPN-Gateway, ist so konfiguriert, dass der Stack-Typ IPv4 und IPv6 (Dual-Stack) verwendet wird.

  • Die IPv6-BGP-Sitzung ist konfiguriert und aktiviert oder die IPv4-BGP-Sitzung wurde speziell konfiguriert, um den IPv6-Routenaustausch zu aktivieren.

    Weitere Informationen zum Konfigurieren von BGP-Sitzungen finden Sie unter BGP-Sitzungen erstellen.

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 (Border Gateway Protocol) auf einem Cloud Router konfigurieren, können Sie eine beworbene 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 zwischen Cloud Routern in einer Region sollten 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 10200 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 IPv4-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 IPv4-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 IPv4-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 IPv4-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 IPv4-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 IPv4-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 IPv4-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 IPv4-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 IPv4-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 Routen

Erkannte Routen sind Routen, die Cloud Router zum Erreichen eines anderen Netzwerks verwendet. Das andere Netzwerk kann Ihr lokales Netzwerk, ein Netzwerk bei einem anderen Cloud-Dienstanbieter oder ein anderes VPC-Netzwerk sein. Erkannte Routen werden manchmal als empfangene Routen bezeichnet.

In Google Cloud gibt es zwei Arten von erkannten Routen:

  • Routen, die von externen Routern über BGP erkannt werden

  • Routen, die Sie für eine einzelne BGP-Sitzung manuell konfigurieren (benutzerdefinierte erkannte Routen)

Mit beiden Arten von erkannten Routen erstellt Cloud Router dynamische Routen in Ihrem VPC-Netzwerk. Jede von Cloud Router erstellte dynamische Route wird von einer oder mehreren dieser erkannten Routen abgeleitet.

Wenn Cloud Router mehrere erkannte Routen für dasselbe Zielpräfix hat, verwendet Cloud Router Routenmesswerte und in einigen Fällen die AS-Pfadlänge, um dynamische Routen zu erstellen. In den folgenden Abschnitten finden Sie weitere Informationen zu diesem Vorgang und zu erkannten Routen im Allgemeinen.

Benutzerdefinierte erkannte Routen

Wie im vorherigen Abschnitt beschrieben, können Sie eine BGP-Sitzung für benutzerdefinierte erkannte Routen konfigurieren. Wenn Sie benutzerdefinierte erkannte Routen konfigurieren, verhält sich Cloud Router so, als hätte er diese Routen von einem BGP-Peer Router erkannt.

Benutzerdefinierte erlernte Routen können nützlich sein, wenn Sie die Einschränkungen von statischen Routen vermeiden möchten. Beispielsweise können statische Routen keinen Verlust der Erreichbarkeit im nächsten Hop einer Route erkennen. Im Gegensatz dazu können benutzerdefinierte erkannte Routen einen Verlust der Erreichbarkeit erkennen und entsprechend reagieren, um Traffic ohne Benachrichtigung zu unterbrechen.

Weitere Informationen finden Sie unter Benutzerdefinierte erkannte Routen.

Auswirkungen des dynamischen Routingmodus

Der dynamische Routing-Modus eines VPC-Netzwerks bestimmt, wie erkannte Routen angewendet werden:

  • Im regionalen dynamischen Routingmodus erstellt Cloud Router eine dynamische Route für das Ziel und den nächsten Hop in derselben Region wie Cloud Router. Cloud Router legt als Priorität dieser 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 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 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.

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 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 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 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 IPv4- oder IPv6-Adressbereiche

In Fällen, in denen Sie ein VPC-Subnetz und ein lokales Route Advertisement mit sich überlappenden 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.

Site-to-Site-Datenübertragung

Wenn Sie Daten zwischen zwei Standorten außerhalb von Google Cloud übertragen müssen, verwenden Sie das Network Connectivity Center. Das Network Connectivity Center funktioniert mit Cloud Router, damit Sie Routen zwischen BGP-Sitzungen dynamisch bewerben können.

Cloud Router alleine unterstützt diese Funktion nicht (dynamisch oder durch Konfigurieren von benutzerdefinierten beworbenen Routen, das den erlernten Präfixen entspricht). Wenn Sie einer BGP-Sitzung eine benutzerdefinierte beworbene Route hinzufügen und die beworbene Route eine erkannte Route aus einer anderen BGP-Sitzung überschneidet, wird die erkannte Route möglicherweise gelöscht.

Limits für erkannte Routen

Es gibt mehrere Limits, die sich auf erkannte Routen auswirken. Weitere Informationen 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 IPv4- oder IPv6-Ziel keine Route angegeben ist, wird der Traffic an eine Standardroute gesendet. Dies ist das letzte Mittel, wenn keine anderen Optionen vorhanden sind. Beispielsweise enthalten Google Cloud VPC-Netzwerke automatisch eine Standardroute, die Traffic an das Internetgateway sendet. Die Standardroute für IPv4 ist 0.0.0.0/0 und für IPv6 ::/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.

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 (standardmäßig) einen Wert von 60 Sekunden für den BGP-Haltezeitgeber. Wir empfehlen, dass Sie den BGP-Hold-Timer auf Ihrem lokalen (Peer-)Router auf 60 Sekunden oder mehr festlegen. 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-Kennung (Router-ID)

Jeder Cloud Router hat eine BGP-ID, auch Router-ID genannt. Die BGP-Kennung ist für jeden Cloud Router in Ihrer Virtual Private Cloud eindeutig, wie von RFC 6286 erforderlich.

Im Allgemeinen wird die BGP-Kennung automatisch zugewiesen. Sie können Ihren Cloud Router jedoch mit einem expliziten BGP-Kennungsbereich konfigurieren. Wenn Sie einen eigenen BGP-Kennungsbereich zuweisen, wird Ihrem Cloud Router eine stabile BGP-Kennung innerhalb des ausgewählten Bereichs zugewiesen. Einem Cloud Router, der nicht mit einem BGP-Kennungsbereich konfiguriert ist, wird eine BGP-Kennung anhand der höchsten IPv4-Schnittstellenadresse zugewiesen.

Wenn Sie die erste IPv6-Schnittstelle einem Cloud Router hinzufügen, der nicht mit einem BGP-Kennungsbereich konfiguriert ist, wird automatisch ein BGP-Kennungsbereich zugewiesen.

Weitere Informationen finden Sie unter BGP-Kennungsbereich für Cloud Router konfigurieren.

BGP-Sitzung neu gestartet

Die BGP-ID eines aktiven Cloud Routers kann sich aus folgenden Gründen ändern:

  • Sie aktualisieren oder entfernen den konfigurierten BGP-Kennungsbereich.
  • Sie entfernen eine IPv4-Schnittstelle vom Cloud Router und ihr wird kein BGP-Kennungsbereich zugewiesen.

Wenn sich die BGP-ID eines aktiven Cloud Routers ändert, wird jede BGP-Sitzung auf diesem Cloud Router neu gestartet.

Der Kennungsbereich eines Cloud Routers kann sich auch ändern, wenn der Router aufgrund regelmäßiger Wartungsarbeiten neu gestartet wird und ihm kein BGP-Kennungsbereich zugewiesen wird.

Weitere Ressourcen

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

  • Informationen zum Erstellen Ihrer Netzwerktopologie mit Cloud Router finden Sie unter Best Practices.

  • Definitionen der Cloud Router-Terminologie erhalten Sie unter Wichtige Begriffe.

  • Informationen zur Behebung von Problemen bei der Verwendung von Cloud Router finden Sie unter Fehlerbehebung.