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:

Wir empfehlen Cloud Router für klassisches VPN auch dann, wenn Ihr lokales VPN-Gateway BGP unterstützt.

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 Routingmodus eines VPC-Netzwerks bestimmt, welches Subnetz die Cloud Router in diesem Netzwerk bewerben:

  • 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.

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.

Routen-Advertising

Cloud Router bewirbt über BGP die IP-Adressen, die die Clients in Ihrem lokalen Netzwerk erreichen können. Ihr lokales Netzwerk sendet Pakete an Ihre VPC-Netzwerke mit einer Ziel-IP-Adresse, die einem beworbenen IP-Adressbereich entspricht. Nach dem Erreichen von Google Cloud bestimmen die Firewallregeln und -routen Ihres VPC-Netzwerks, wie Google Cloud die Pakete verarbeitet.

Sie können das Standard-Advertising von Cloud Router verwenden oder explizit angeben, welche CIDR-Bereiche angeboten werden sollen. Wenn Sie kein Advertising angeben, verwendet der Cloud Router den Standardwert.

Standardmäßiges Route Advertisement

Standardmäßig bewirbt Cloud Router Subnetze in der eigenen Region für regionales dynamisches Routing oder alle Subnetze in einem VPC-Netzwerk für globales dynamisches Routing. Cloud Router bewirbt automatisch neue Subnetze. Wenn ein Subnetz über einen sekundären IP-Bereich zum Konfigurieren von Alias-IP-Adressen verfügt, werden von Cloud Router sowohl die primären als auch die sekundären IP-Adressen beworben.

Jede BGP-Sitzung für einen Cloud Router verfügt außerdem über ein Standard-Advertising. Standardmäßig leitet Cloud Router seine Route Advertisements an alle BGP-Sitzungen weiter. Wenn Sie ein benutzerdefiniertes Routen-Advertising auf einem Cloud Router konfigurieren, übernehmen die BGP-Sitzungen dieses benutzerdefinierte Advertising.

Legen Sie in den folgenden Fällen ein benutzerdefiniertes Route Advertisement fest:

  • Zum Bewerben von IP-Adressen außerhalb des primären IP-Bereichs eines Subnetzes oder eines seiner sekundären IP-Bereiche, beispielsweise zum Bewerben externer IP-Adressen.

  • Mit dem VPC-Netzwerk-Peering können Sie Routen aus einem anderen VPC-Netzwerk bewerben, das mit Ihrem VPC-Netzwerk verbunden ist. In diesem Fall werden Subnetzrouten und importierte benutzerdefinierte Routen in einem Peering-Netzwerk nicht automatisch von einem Cloud Router in Ihrem VPC-Netzwerk beworben. Damit Sie sie bewerben können, müssen Sie benutzerdefinierte Route Advertisements auf Cloud Router in Ihrem VPC-Netzwerk erstellen. Außerdem müssen Sie dafür sorgen, dass die VPC-Netzwerk-Peering-Verbindungen so konfiguriert sind, dass sie die benutzerdefinierten Routen austauschen.

Wenn Sie ein benutzerdefiniertes Advertising verwenden, können Sie selektiv Subnetze oder Teile eines Subnetzes bewerben. Auf diese Weise können Sie verhindern, dass bestimmte Subnetze beworben werden. Wenn Sie diese Funktionen nicht benötigen, verwenden Sie das Standard-Advertising.

Benutzerdefiniertes Route Advertisement

Wenn Sie benutzerdefiniertes Route Advertisement konfigurieren, geben Sie explizit die Routen an, die ein Cloud Router anbietet. In den meisten Fällen ist benutzerdefiniertes Advertising nützlich, um das Standard-Subnetz-Advertising durch benutzerdefinierte IP-Adressen zu ergänzen. Benutzerdefinierte IP-Adressen sind Adressen außerhalb des IP-Bereichs eines Subnetzes, z. B. reservierte externe IP-Adressen. Ohne benutzerdefiniertes Route Advertisement müssten Sie statische Routen für benutzerdefinierte IP-Adressen erstellen und verwalten.

Wenn Sie benutzerdefiniertes Route Advertisement konfigurieren, können Sie alle Subnetze anbieten, was dem Standardverhalten entspricht. Sie können festlegen, dass nicht alle Subnetze angeboten werden. Stattdessen werden nur bestimmte Subnetze oder bestimmte CIDR-Blöcke innerhalb eines Subnetzes angeboten. Beispielsweise möchten Sie möglicherweise verhindern, dass Cloud Router bestimmte Subnetze anbietet. Dazu bieten Sie nur die Subnetze an, die Sie freigeben möchten. Wenn Sie aber Subnetze selektiv anbieten, müssen Sie neue Subnetze dem benutzerdefinierten Route Advertisement manuell hinzufügen. Cloud Router bietet neue Subnetze nicht automatisch an.

Sie können benutzerdefiniertes Routen-Advertising auf einem Cloud Router oder in einer BGP-Sitzung angeben. Benutzerdefiniertes Route Advertisement auf dem Cloud Router gilt für alle BGP-Sitzungen. Wenn Sie aber ein benutzerdefiniertes Route Advertisement in einer BGP-Sitzung angeben, ignoriert und überschreibt das Route Advertisement der BGP-Sitzung das Route Advertisement von Cloud Router.

Für jeden Cloud Router können Sie maximal 200 CIDR-Bereiche angeben. Jede BGP-Sitzung ebenfalls das Limit 200.

Beispiele für Route Advertisement

Die folgenden Beispiele zeigen das Standardverhalten des Cloud Routers und Szenarien, in denen benutzerdefiniertes Route Advertisement nützlich sein kann. Für die Beispiele wird eine vorhandene Verbindung zwischen der VPC und lokalen Netzwerken wie ein IPsec-VPN-Tunnel oder eine Dedicated Interconnect-Verbindung vorausgesetzt.

Standardmäßiges Route Advertisement

Beim regionalen dynamischen Routing bietet Cloud Router Subnetze in seiner Region an. Im folgenden Diagramm bewirbt Cloud Router Subnetze in der Region us-central1. Außerdem wird der sekundäre IP-Bereich des alias-subnet beworben. Wenn Sie neue Subnetze in us-central1 erstellen, bewirbt Cloud Router diese automatisch. Cloud Router bewirbt keine IP-Adressen, die nicht im IP-Bereich eines Subnetzes enthalten sind, z. B. externe IP-Adressen.

Standardmäßiges Route Advertisement für Cloud Router
Cloud Router Standard-Routen-Advertising (zum Vergrößern klicken)

Externes IP-Adress-Advertising

Sie können eine externe statische IP-Adresse für eine Google Cloud-Anwendung verwenden, die Clients in Ihrem lokalen Netzwerk bedient. Wenn Sie Wartungsarbeiten an der Anwendung ausführen, können Sie die statische IP-Adresse einer anderen VM neu zuordnen, um Ausfallzeiten zu minimieren. Wenn Sie das Standard-Advertising von Cloud Router verwenden, müssen Sie eine statische Route konfigurieren und verwalten. Stattdessen können Sie benutzerdefiniertes Advertising verwenden, um die externe IP-Adresse über BGP anzubieten.

Im folgenden Diagramm bewirbt Cloud Router die externe IP-Adresse des Proxyservers 1.2.3.4. Die externe IP-Adresse wird der internen IP-Adresse 10.20.0.2 des Servers zugeordnet. Cloud Router bewirbt die interne IP-Adresse des Proxyservers oder von VMs nicht im Subnetz my-subnet. Lokale Clients kennen nur die externe IP-Adresse des Proxyservers.

Externes IP-Adress-Advertising
Externes IP-Adressen-Advertising (zum Vergrößern klicken)

Weitere Informationen finden Sie unter Benutzerdefinierte IP-Bereiche bewerben.

Subnetz-Advertising einschränken

Sie können verhindern, dass Instanzen beworben werden, damit sie verborgen bleiben. Im folgenden Diagramm bewirbt Cloud Router subnet-1 und subnet-2. Clients im lokalen Netzwerk können VMs in diesen Subnetzen erreichen, aber keine VMs im Subnetz unadvertised-subnet.

Advertising bestimmter Subnetze für Cloud Router
Bestimmte Subnetze auf dem Cloud Router bewerben (zum Vergrößern anklicken)

Weitere Informationen finden Sie unter Bestimmte VPC-Subnetze bewerben.

Route Advertisement nach BGP-Sitzung

Angenommen, Sie haben Produktions- und Testressourcen in Ihrem VPC- und in Ihrem lokalen Netzwerk und diese Ressourcen sind in verschiedenen Subnetzen organisiert. Dementsprechend richten Sie zwei BGP-Sitzungen ein, die unterschiedliche IP-Adressbereiche bewerben. Wenn zwei verschiedene BGP-Sitzungen verwendet werden, wird der Traffic für ein Subnetz nicht versehentlich in ein anderes Subnetz geleitet. Das folgende Diagramm zeigt zwei BGP-Sitzungen: prod-bgp, die nur das prod-subnet bewirbt, und test-bgp, die nur das test-subnet bewirbt.

Advertising bestimmter Subnetze in einer BGP-Sitzung
Bestimmte Subnetze in einer BGP-Sitzung bewerben (zum Vergrößern klicken)

Weitere Informationen finden Sie unter Benutzerdefinierte IP-Bereiche bewerben und Bestimmte VPC-Subnetze bewerben.

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.

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

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" können 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 ansehen.

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