Cloud Router – Übersicht

Cloud Router ist ein vollständig verteilter und verwalteter Google Cloud-Dienst, der benutzerdefinierte dynamische Routen programmiert und gemäß Ihrem Netzwerktraffic skaliert. Cloud Router arbeitet sowohl mit älteren Netzwerken als auch mit VPC-Netzwerken (Virtual Private Cloud) zusammen.

Cloud Router ist keine Verbindungsoption, sondern ein Dienst, der über Cloud VPN- oder Cloud Interconnect-Verbindungen dynamisches Routing mithilfe des Border Gateway Protocol (BGP) für Ihre VPC-Netzwerke ermöglicht. Cloud Router wird für Direct Peering- oder Carrier Peering-Verbindungen nicht unterstützt.

Cloud Router ist kein physisches Gerät, das einen Engpass verursachen kann, und kann nicht allein verwendet werden. In den folgenden Fällen ist dies jedoch erforderlich oder empfohlen:

  • Erforderlich für Cloud NAT
  • Erforderlich für Cloud Interconnect und HA VPN
  • Eine empfohlene Konfigurationsoption für Klassisches VPN

Wenn Sie Ihr lokales Netzwerk auf Google Cloud erweitern, verwenden Sie Cloud Router zum dynamischen Austausch von Routen zwischen Ihren Google Cloud-Netzwerken und Ihrem lokalen Netzwerk. Cloud Router verbindet sich mit Ihrem lokalen VPN-Gateway oder Router. Die Router tauschen Topologieinformationen über BGP aus.

Topologieänderungen werden automatisch zwischen Ihrem VPC-Netzwerk und Ihrem lokalen Netzwerk übernommen. Wenn Sie Cloud Router verwenden, müssen Sie keine statischen Routen konfigurieren.

Statisches und dynamisches Routing im Vergleich

Bei statischen Routen müssen Sie eine Routingtabelle erstellen oder pflegen. Bei beiden Netzwerken erfordert eine Topologieänderung, dass Sie statische Routen manuell aktualisieren. Außerdem können statische Routen den Datenverkehr nicht automatisch umleiten, wenn eine Verbindung fehlschlägt.

Das statische Routing eignet sich für kleine Netzwerke mit stabilen Topologien. Außerdem haben Sie eine genaue Kontrolle über die Routingtabellen. Router senden keine Advertisings zwischen Netzwerken.

Bei Cloud Router können Sie BGP verwenden, um zwischen den Netzwerken Informationen auszutauschen. Anstatt statische Routen manuell zu konfigurieren, erkennen Netzwerke Topologieänderungen automatisch und schnell über BGP. Änderungen werden nahtlos implementiert, ohne den Traffic zu unterbrechen. Diese Methode für den Austausch von Routen über BGP wird dynamisches Routing genannt.

Dynamisches Routing eignet sich für Netzwerke von beliebiger Größe. Es nimmt Ihnen die Pflege statischer Routen ab. Wenn eine Verbindung fehlschlägt, kann dynamisches Routing den Datenverkehr automatisch umleiten, wenn dies möglich ist. Erstellen Sie einen Cloud Router, um das dynamische Routing zu aktivieren. Anschließend konfigurieren Sie eine BGP-Sitzung zwischen dem Cloud Router und dem lokalen Gateway oder Router.

Statisches Routing für Cloud VPN-Tunnel

Ohne Cloud Router können Sie Ihr Cloud VPN nur mit statischen Routen konfigurieren. Statische Routen haben folgende Nachteile:

  • Bei einer Änderung der Netzwerkkonfiguration auf einer der beiden Seiten des Cloud VPN-Tunnels müssen statische Routen entsprechend dieser Änderung manuell erstellt und gelöscht werden. Außerdem bedeutet die Abstimmung von Änderungen statischer Routen einen hohen Zeitaufwand.
  • Wenn Sie einen Cloud VPN-Tunnel mit statischen Routen erstellen, müssen Sie vor der Erstellung des Tunnels die Liste der IP-Präfixe auf einer der beiden Seiten des Tunnels angeben. Daher muss bei jeder erforderlichen Routenänderung der Cloud VPN-Tunnel gelöscht, neu erstellt und neue Routen konfiguriert werden. Dadurch wird der laufende Traffic unterbrochen.
  • Für die Konfiguration statischer Routen gibt es keine Standardmethode. Die Befehle unterscheiden sich je nach Anbieter.

Im folgenden Beispiel besteht Ihr kombiniertes Netzwerk aus Ihrem Google Cloud-Netzwerk und 29 Subnetzen (eines je Rack) im lokalen Netzwerk auf der anderen Seite des Cloud VPN-Tunnels. Nehmen wir für dieses Beispiel an, dass Ihr Unternehmen wächst und Sie deshalb jede Woche ein neues Subnetz mit Geräten hinzufügen müssen. In dieser Woche fügen Sie das Subnetz 10.0.30.0/24 hinzu, wie im folgenden Diagramm dargestellt:

Cloud Router für Cloud VPNs mit VPC-Netzwerk (zum Vergrößern klicken)
Cloud VPN ohne Cloud Router (zum Vergrößern klicken)

In diesem Szenario erfordert ein Cloud VPN mit statischen Routen die folgenden Änderungen:

  1. Sie müssen statische Routen zu Google Cloud hinzufügen, um das neue lokale Subnetz zu erreichen.
  2. Sie müssen den Cloud VPN-Tunnel löschen und noch einmal erstellen, um das neue lokale Subnetz einzubeziehen.

Sie können Konfigurationsänderungen an statischen Routen und Cloud VPN-Tunneln durch die Verwendung eines Cloud Routers vermeiden. Cloud Router verbindet sich per BGP mit dem Cloud VPN-Gateway, um Topologieinformationen auszutauschen. In der Tat werden Änderungen der Netzwerktopologie in Ihrem Google Cloud-Netzwerk automatisch auf Ihr eigenes Netzwerk und umgekehrt über BGP übertragen, sodass Sie keine statischen Routen für die Cloud VPN-Tunnel konfigurieren müssen.

Anforderungen für dynamisches Routing für Cloud Interconnect und Cloud VPN

Bevor Sie Folgendes tun können, müssen Sie einen Cloud Router haben:

Wenn Sie einen Cloud Router erstellen, können Sie die Google-seitige ASN auswählen. Wenn Sie keine ASN angeben, wählt Google Cloud eine ASN für Sie aus. Sie müssen die ASN Ihres lokalen (Peer-)Routers jedoch manuell in den Konfigurationseinstellungen für Cloud Router angeben.

Sie können BGP-Adressen auf folgende Weise angeben:

Dynamisches Routing für Cloud VPN-Tunnel in VPC-Netzwerken

Mithilfe von VPC-Netzwerken können Sie den IP-Bereich des Netzwerks regional in Präfixe (Subnetze) gliedern und steuern, welches Präfix der internen IP-Adresse einer VM-Instanz zugeordnet wird. Verwenden Sie Cloud Router, um das dynamische Routing für Ihren Cloud VPN-Tunnel zu aktivieren, damit Sie diese Subnetze nicht statisch verwalten müssen, was vor allem durch das Hinzufügen und Entfernen entsprechender statischer Routen für Ihr Cloud VPN Zusatzaufwand bedeutet.

Ein Cloud Router gehört zu einem bestimmten VPC-Netzwerk und einer Region. Cloud Router bewirbt Subnetze aus seinem VPC-Netzwerk über BGP für das lokale Gateway. Es bewirbt die Subnetze in seiner lokalen Region oder alle Subnetze im Netzwerk basierend auf dem dynamischen Routingmodus des VPC-Netzwerks. Cloud Router erkennt außerdem die lokalen Routen über BGP und ermöglicht der Netzwerkinfrastruktur, die beste Route zum Erreichen der zugehörigen Präfixe auszuwählen.

Im folgenden Beispiel sehen Sie Cloud Router mit VPC-Netzwerken im benutzerdefinierten Modus. Für VPC-Netzwerke im automatischen Modus gibt Cloud Router automatisch das /20-Präfix der Region an. Weitere Informationen zum automatischen und benutzerdefinierten Modus finden Sie unter VPC-Netzwerk (Virtual Private Cloud).

Das folgende Diagramm zeigt zwei verschiedene regionale Subnetze in einem VPC-Netzwerk und 30 Subnetze im lokalen Netzwerk. Die beiden Netzwerke sind über einen Cloud VPN-Tunnel miteinander verbunden. In diesem Szenario werden in beiden Netzwerken neue Subnetze hinzugefügt:

  1. Ein neues 192.168.1.0/24-Subnetz in der Region us-east1 des Google Cloud-Netzwerks
  2. Ein neues lokales Subnetz 10.0.30.0/24 für die Verarbeitung des erhöhten Traffics in Ihrem Rechenzentrum
Cloud Router für Cloud VPNs mit VPC-Netzwerk (zum Vergrößern klicken)
Cloud Router für VPNs mit VPC-Netzwerk (zum Vergrößern klicken)

Um Änderungen an der Netzwerkkonfiguration automatisch weiterzuleiten, erstellt der Cloud VPN-Tunnel mithilfe von Cloud Router eine BGP-Sitzung zwischen dem lokalen VPN-Gateway, welches BGP unterstützen muss. Die neuen Subnetze werden nahtlos zwischen Netzwerken beworben. Instanzen in den neuen Subnetzen können sofort Traffic senden und empfangen.

Zum Einrichten von BGP müssen Sie jedem Ende des Cloud VPN-Tunnels eine zusätzliche IP-Adresse zuweisen. Diese beiden IP-Adressen müssen Link-Local-IP-Adressen sein, die zum IP-Adressbereich 169.254.0.0/16 gehören. Diese Adressen sind nicht Teil des IP-Adressbereichs eines der Netzwerke. Diese beiden Adressen dienen ausschließlich zum Erstellen einer BGP-Sitzung. Die Adressen sind nicht routingfähig. Daher funktionieren sie nicht gut mit gängigen Tools für Netzwerktests. Traceroute funktioniert beispielsweise gar nicht und ein Ping-Test funktioniert nur dann, wenn die Anfrage von der Link-Local-Adresse stammt, die für die Link-Local-Adresse des Peers bestimmt ist.

Dynamisches Routing für Cloud VPN-Tunnel in Legacy-Netzwerken

In Legacy-Netzwerken werden Änderungen an der Netzwerkkonfiguration automatisch weitergeleitet, ohne dass statische Routen neu konfiguriert werden müssen und der Cloud VPN-Tunnel, ähnlich wie im vorherigen Beispiel, neu gestartet werden muss.

Die BGP-Sitzung informiert jeden Router über lokale Änderungen. Zum Einrichten von BGP muss jedem Ende des Cloud VPN-Tunnels eine zusätzliche IP-Adresse zugewiesen werden. Diese beiden IP-Adressen müssen Link-Local-IP-Adressen sein, die zum IP-Adressbereich 169.254.0.0/16 gehören. Diese Adressen gehören nicht zum IP-Adressbereich auf einer der beiden Seiten des Tunnels und werden ausschließlich für die Konfiguration von BGP-Peers zum Erstellen einer BGP-Sitzung verwendet.

Sie müssen auf beiden Seiten des Tunnels zwei Link-Local-IP-Adressen, die beide aus demselben Subnetz stammen, sowie eine Netzmaske konfigurieren. Nachdem Sie diese Änderungen auf beiden Seiten des Tunnels konfiguriert haben, wird eine BGP-Sitzung erstellt.

Auch hier gilt: Wenn ein Netzwerk Cloud VPN-Tunnel in mehreren Regionen hat, müssen Sie in jeder Region, in der Sie dynamisches Routing wünschen, einen Cloud Router erstellen. Sie können einen einzelnen Cloud Router für mehrere Cloud VPN-Gateways und mehrere Tunnel in der Netzwerkregion verwenden, zu der der Router gehört.

Modus für dynamisches Routing

Der dynamische Routingmodus eines VPC-Netzwerks bestimmt, welche Subnetze für Cloud Router sichtbar sind. Sie können den dynamischen Routingmodus auf global oder regional festlegen:

  • Beim globalen dynamischen Routing bewirbt ein Cloud Router alle Subnetze im VPC-Netzwerk gegenüber dem lokalen Router. Cloud Router leitet alle erkannten Routen vom lokalen Router an alle Regionen weiter.
  • Beim regionalen dynamischen Routing bewirbt ein Cloud Router Routen in seiner lokalen Region und leitet sie weiter.

Der dynamische Routingmodus wird im VPC-Netzwerk konfiguriert. Wenn Sie ein VPC-Netzwerk erstellen oder bearbeiten, können Sie den dynamischen Routingmodus auf global oder regional festlegen. Alle Cloud Router-Instanzen im VPC-Netzwerk verwenden den dynamischen Routingmodus des Netzwerks. Standardmäßig ist der Modus regional.

Wenn Sie den dynamischen Routingmodus für ein VPC-Netzwerk ändern, berücksichtigen Sie die Auswirkungen, z. B. die Unterbrechung bestehender Verbindungen oder die Aktivierung unbeabsichtigter Routen. Wenn Sie beispielsweise zum regionalen dynamischen Routing wechseln, könnten die Verbindungen von VMs zu Cloud VPN-Tunneln und Cloud Interconnect-Verbindungen in eine andere Region verloren gehen. Wenn Sie zum globalen dynamischen Routing wechseln, bewirbt Cloud Router möglicherweise VMs aus Regionen, die Sie nicht möchten. Informationen zum Anzeigen oder Konfigurieren des dynamischen Routingmodus finden Sie unter Regionales oder globales dynamisches Routing festlegen.

Modus für dynamisches Routing und Load-Balancer

Lesen Sie den Abschnitt Internes TCP/UDP-Load-Balancing und verbundene Netzwerke sorgfältig durch, um zu verstehen, wie Ihre internen TCP/UDP-Load-Balancer über Cloud VPN-Tunnel und Cloud Interconnect-Anhänge (VLANs) zugänglich sind. Auf interne TCP/UDP-Load-Balancer mit deaktiviertem globalen Zugriff kann beispielsweise nur von Client-VMs, Cloud VPN-Tunneln und Cloud Interconnect-Anhängen (VLANs) zugegriffen werden, die sich in derselben Region wie der Load-Balancer befinden.

Beispiel für regionales dynamisches Routing

Beim regionalen dynamischen Routing haben Sie möglicherweise einen Cloud VPN-Tunnel und VMs in einer einzigen Google Cloud-Region. Der Tunnel erweitert Ihr lokales Netzwerk auf ein VPC-Netzwerk. VMs in anderen Regionen müssen möglicherweise eine Verbindung zum lokalen Netzwerk herstellen, können den Tunnel jedoch nicht erreichen. Um diese Einschränkung zu umgehen, können Sie statische Routen erstellen. Das Beibehalten statischer Routen kann jedoch fehleranfällig sein und den Traffic stören.

Im folgenden Beispiel sind nur Ressourcen in der Region us-west1 für Cloud Router sichtbar. VMs in anderen Regionen, z. B. us-central1, können den Cloud VPN-Tunnel nicht erreichen.

Cloud Router – regionales dynamisches Routing (zum Vergrößern klicken)
Cloud Router – regionales dynamisches Routing (zum Vergrößern klicken)

Beispiele für globales dynamisches Routing

Beim globalen dynamischen Routing sind Ressourcen in allen Regionen für den Cloud Router sichtbar. Wenn Sie beispielsweise VMs in einer Region haben, können diese automatisch einen Cloud VPN-Tunnel in einer anderen Region erreichen, ohne statische Routen beizubehalten.

Das folgende Beispiel zeigt ein VPC-Netzwerk mit globalem dynamischem Routing. Der Cloud Router in us-west1 bewirbt Subnetze in zwei verschiedenen Regionen: us-west1 und us-central1. VMs in beiden Regionen erkennen dynamisch lokale Hosts.

Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)
Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)

Für redundante Topologien stellt das dynamische Routing (BGP) der VPC und den lokalen Netzwerken genügend Informationen bereit, sodass bei einem Ausfall eines Pfads der Traffic umgeleitet wird. Wenn eine Verbindung in einer Region ein Problem hat, kann der Traffic durch einen Failover auf eine andere Region umgeleitet werden.

Das folgende Beispiel zeigt zwei Cloud VPN-Tunnel in zwei unterschiedlichen Regionen. Die VMs (10.128.0.0/20) verwenden den tunnel-us-west1 in der Region us-west1, um beide Subnetze im lokalen Netzwerk zu erreichen. Ähnlich verwenden die VMs (10.138.0.0/20) in us-central1 den tunnel-us-central1.

Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)
Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)

Die Routen sind so konfiguriert, dass VMs ihre lokalen Tunnel (die Tunnel in ihrer Region) bevorzugen. Cloud Router legt verschiedene Gewichtungen für lokale und entfernte Routen mit gleichem Ziel fest. Wenn ein Tunnel fehlerhaft ist, kann Cloud Router den Datenverkehr entsprechend umleiten.

Im folgenden Beispiel schlägt tunnel-us-west1 fehl. Traffic von und zu den VMs (10.128.0.0/20) wird durch tunnel-us-central1 umgeleitet, statt gelöscht zu werden.

Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)
Cloud Router – globales dynamisches Routing (zum Vergrößern klicken)

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 Ihr VPC-Netzwerk mit einer Ziel-IP-Adresse, die einem beworbenen IP-Bereich 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.

Standardeinstellung

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. Neue Subnetze werden automatisch von Cloud Router beworben. 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 sein Route Advertisement an alle BGP-Sitzungen weiter. Wenn Sie ein benutzerdefiniertes Route Advertisement auf einem Cloud Router konfigurieren, übernehmen die BGP-Sitzungen dieses benutzerdefinierte Advertising.

Sie müssen benutzerdefiniertes Route Advertisement in folgenden Fällen angeben:

  • Zum Bewerben von IP-Adressen außerhalb des primären IP-Bereichs eines Subnetzes oder eines seiner sekundären IP-Bereiche. Beispiel: Advertising für externe 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 Peer-Netzwerk nicht automatisch von einem Cloud Router in Ihrem VPC-Netzwerk beworben. Damit Sie sie bewerben können, müssen Sie benutzerdefiniertes Route Advertisement auf dem Cloud Router in Ihrem VPC-Netzwerk erstellen und prüfen, ob 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.

Benutzerdefiniert

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. Zu diesem Zweck bieten Sie nur diejenigen an, die Sie veröffentlichen möchten. Wenn Sie jedoch selektiv Subnetze anbieten, müssen neue Subnetze manuell dem benutzerdefinierten Route Advertisement hinzugefügt werden. Cloud Router bietet neue Subnetze nicht automatisch an.

Sie können benutzerdefiniertes Route Advertisement 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 jedoch ein benutzerdefiniertes Route Advertisement in einer BGP-Sitzung angeben, wird das Advertisement des Cloud Routers ignoriert und mit dem Advertisement der Sitzung überschrieben.

Für jeden Cloud Router können Sie maximal 200 CIDR-Bereiche angeben. Außerdem hat jede BGP-Sitzung ebenfalls das Limit 200.

Beispiele

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

Standardmäßiges Route Advertisement

Beim regionalen dynamischen Routing bewirbt Cloud Router Subnetze in der eigenen Region. Im folgenden Beispiel bewirbt Cloud Router alle 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.

Cloud Router Standard-Route Advertisement (zum Vergrößern klicken)
Cloud Router Standard-Routen-Advertising (zum Vergrößern klicken)

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 durchfü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 zu bewerben.

Im folgenden Beispiel bewirbt der 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 VMs nicht im Subnetz my-subnet. Lokale Clients kennen nur die externe IP-Adresse des Proxyservers.

Externes IP-Adressen-Advertising (zum Vergrößern klicken)
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 Beispiel 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.

Bestimmte Subnetze auf dem Cloud Router bewerben (zum Vergrößern klicken)
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 verfügen über Produktions- und Testressourcen in Ihrer VPC und in Ihren lokalen Netzwerken und haben diese Ressourcen 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 Beispiel zeigt zwei BGP-Sitzungen: prod-bgp, die nur das prod-subnet bewirbt, und test- bgp, die nur das test-subnet bewirbt.

Bestimmte Subnetze in einer BGP-Sitzung bewerben (zum Vergrößern klicken)
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. In diesem Abschnitt wird dieser Vorgang beschrieben.

Auswirkungen des dynamischen Routingmodus

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

  • Im regionalen dynamischen Routingmodus erstellt Cloud Router eine benutzerdefinierte dynamische Route für das Ziel und den nächsten Hop in derselben Region wie der Cloud Router. Cloud Router legt die Priorität für diese benutzerdefinierte dynamische Route auf die Basispriorität fest, die der 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 der Cloud Router befindet, der diese Route erkannt hat, legt Cloud Router die Priorität für die benutzerdefinierte dynamische Route auf die Basispriorität fest. In allen anderen Regionen legt Cloud Router die Priorität auf die Basispriorität plus die entsprechenden regionalen Kosten fest.

Sie können die Routenpriorität für Routen zu Google Cloud definieren, die an Ihren lokalen Router exportiert werden. Diese Routenpriorität kann jedoch je nach Konfiguration von Ihrem lokalen Router überschrieben werden. Dies kann beispielsweise der Fall sein, wenn Ihr lokaler Router die Routenpriorität ändert.

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

Wenn die AS-Pfadlänge berücksichtigt wird

Wenn ein einzelner Cloud Router ein Zielpräfix mit mehreren nächsten Hops erkennt, verwendet der Cloud Router den nächsten Hop mit der kürzesten ASN-Pfadlänge. In diesem Fall erstellt der Cloud Router eine benutzerdefinierte dynamische Route im VPC-Netzwerk für das Ziel und den nächsten Hop mit dem kürzesten AS-Pfad. Der Cloud Router wählt den nächsten Hop nicht von MED aus. Der Cloud Router verwendet weiterhin das MED, um die Basispriorität einer benutzerdefinierten dynamischen Route festzulegen, die aus dem MED-Wert abgeleitet wird. Weitere Informationen finden Sie unter Auswirkungen des dynamischen Routingmodus.

Der AS-Pfad wird nie berücksichtigt, wenn ein Zielpräfix von zwei oder mehr Cloud Routern in derselben Region oder in verschiedenen Regionen erkannt wird. Wenn mehr als ein Cloud Router vorhanden ist, verwenden diese Router die Prioritäten der benutzerdefinierten dynamischen Routen, um den nächsten Hop auszuwählen, anstatt die AS-Pfadlänge zu verwenden.

AS-Pfad wird vorangestellt

Das Voranstellen des AS-Pfads ist eine Methode, mit der einige Netzwerke BGP-Advertisings priorisieren. In Google Cloud werden die Vorteile der AS-Pfadvoranstellung reduziert, da VPC-Netzwerke standardmäßig global konfiguriert sind.

Wenn ein VPC-Netzwerk mehr als einen Cloud Router enthält – in einer Region oder mehreren Regionen –, verwendet es den folgenden Algorithmus, um die nächsten Hops für die Ziele (Präfixe) auszuwählen, die es erkennt:

  • Wenn ein Ziel (Präfix) von genau einer BGP-Sitzung empfangen wird, hat der vorangestellte AS-Pfad keine Auswirkungen. Der nächste Hop jeder im VPC-Netzwerk erstellten benutzerdefinierten dynamischen Route ist der nächste Hop, der der einen BGP-Sitzung zugeordnet ist.
  • Wenn ein Ziel (ein Präfix) von mehr als einer BGP-Sitzung empfangen wird, unabhängig davon, ob es sich auf demselben Cloud Router oder auf verschiedenen Cloud Routern befindet, ignoriert Google Cloud alle nächsten Hops mit einem vorangestellten AS-Pfad. Der nächste Hop jeder benutzerdefinierten dynamischen Route, die im VPC-Netzwerk erstellt wird, ist ein nächster Hop, dessen BGP-Sitzung nicht das AS-Pfadpräfix verwendet. Wenn mehrere Cloud Router beteiligt sind, spielt es keine Rolle, ob sich die Cloud Router in derselben oder in unterschiedlichen Regionen befinden.

Ob eine oder mehrere benutzerdefinierte dynamische Routen erstellt werden, hängt in jedem Fall vom dynamischen Routingmodus des VPC-Netzwerks ab.

Verwenden Sie für möglichst konsistente Ergebnisse nicht das AS-Pfad-Präfix. Konfigurieren Sie stattdessen den MED-Wert.

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 die Basispriorität auf 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

Weitere Informationen finden Sie in der VPC-Routingdokumentation im Abschnitt Routingreihenfolge.

Überlappende IP-Bereiche zwischen einem VPC-Subnetz und einem lokalen Route Advertisement

In Fällen, in denen Sie ein VPC-Subnetz und ein lokales Route Advertisement mit sich überlappenden IP-Bereichen 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. Dabei wird für statische Route Advertisements eine lokale Route verwendet, 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 dynamischer Routen mit mehreren VPC-Netzwerken finden Sie auf der Seite "Fehlerbehebung für Cloud Router" unter IP-Präfixe, die nicht weitergegeben oder nicht verfügbar sind.

Routenmesswerte

Wenn Cloud Router Routen bewirbt oder weiterleitet, verwendet er Routenmesswerte, um die Routenprioritäten anzugeben. Wenn Sie mehrere Pfade zwischen Ihrem VPC-Netzwerk und dem lokalen Netzwerk haben, wird durch die Routenmesswerte ein bevorzugter Pfad bestimmt. Dieser Wert entspricht dem MED-Wert. Ein niedrigerer Routenmesswert (MED) zeigt eine höhere Priorität an.

Ein Routenmesswert setzt sich aus der Basispriorität der beworbenen Route und den regionalen Kosten zusammen. Die Basispriorität der beworbenen Route ist ein benutzerdefinierter Wert, während die regionalen Kosten einen von Google generierten Wert darstellen, den Sie nicht ändern können. Die regionalen Kosten stellen die Kosten der Kommunikation zwischen zwei Regionen in einem VPC-Netzwerk dar. Cloud Router addiert diese beiden Werte, um einen Routenmesswert zu erhalten.

Beim regionalen dynamischen Routing werden die regionalen Kosten nicht zu den Routenmesswerten hinzugefügt, weil Cloud Router nur Routen in der eigenen Region behandelt. Cloud Router verwendet nur die Basispriorität der beworbenen Route.

Beim globalen dynamischen Routing bieten alle Cloud Router die gleichen Routen an und leiten sie weiter. Jeder Cloud Router verwendet jedoch aufgrund regionaler Kosten möglicherweise unterschiedliche Routenmesswerte.

Basispriorität der beworbenen Route

Cloud Router beginnt die Berechnung von Routenmesswerten mit dem Basiswert der beworbenen Route und fügt dann die entsprechenden regionalen Kosten hinzu. Dieser Basiswert ist der minimale Routenmesswert für beworbene Routen. Wenn Sie eine BGP-Sitzung auf einem Cloud Router konfigurieren, können Sie eine Basispriorität der angebotenen Route angeben, die für alle Routen für diese Sitzung gilt. Standardmäßig ist die Basispriorität auf den Wert 100 festgelegt und verwendet als Wert eine positive Ganzzahl. Cloud Router betrachtet eine beworbene Basispriorität mit einem numerischen Wert von 1 als Route mit der höchsten Priorität. Dieser Wert hat Vorrang vor niedrigeren Prioritäten, die einen Wert von 2 oder mehr haben.

Mit der Basispriorität der beworbenen Route können Sie Prioritäten für Routen festlegen. Sie verfügen zum Beispiel über einen Cloud VPN-Tunnel und eine Dedicated Interconnect-Verbindung, über die Ihre VPC und Ihre lokalen Netzwerke miteinander verbunden sind. Sie können die Basispriorität der beworbenen Route festlegen, sodass der Traffic Dedicated Interconnect bevorzugt. Wenn die Cloud Interconnect-Verbindung nicht verfügbar ist, durchquert der Traffic den Tunnel. Weitere Informationen finden Sie in den Beispieltopologien.

Regionale Kosten

Wenn ein Cloud Router Routen aus anderen als seiner eigenen Region (d. h. aus entfernten Google Cloud-Regionen) bewirbt oder Routen an entfernte Regionen weiterleitet, erhöht das die regionalen Kosten.

Die regionalen Kosten können von 201 bis (einschließlich) 9.999 reichen. Der Wert hängt von der Entfernung, der Latenz und anderen Faktoren zwischen zwei Regionen ab. Google generiert den Wert der regionalen Kosten – Sie können ihn nicht ändern. Weitere Informationen zu regionalen Kosten finden Sie unter Beispieltopologien.

Regionale Kosten helfen bei der Priorisierung von Pfaden basierend auf der Nähe der Regionen. Stellen Sie sich beispielsweise vor, dass Sie zwei Verbindungen zwischen Ihrem VPC- und dem lokalen Netzwerk haben, z. B. zwei Cloud VPN-Tunnel mit eigenen Cloud Routern. Eine Verbindung befindet sich in us-central1 und eine andere in europe-west1. Durch das Hinzufügen regionaler Kosten zu den Routenmesswerten wird beim Traffic zwischen Netzwerken in us-central1 der us-central1-Tunnel priorisiert. In ähnlicher Weise wird beim Traffic zwischen den Netzwerken in europe-west1 der europe-west1-Tunnel priorisiert. Ohne regionale Kosten wird der Traffic gleichmäßig über beide Verbindungen geleitet, was zu einer inkonsistenten Netzwerkleistung führt.

Bei erkannten Routen fügt Cloud Router regionale Kosten hinzu, wenn er die erkannten Routen an entfernte Google Cloud-Regionen weiterleitet. Dadurch wird die Symmetrie zwischen dem eingehenden und dem ausgehenden Traffic zwischen VPC- und lokalen Netzwerken gewahrt. Cloud Router fügt dem MED-Wert, der von Ihrem lokalen Router beworben wird, regionale Kosten hinzu.

Vorgeschlagene Basisprioritätswerte

Verwenden Sie Werte kleiner als 201, um Prioritäten zwischen Routen in einer einzelnen Region anzupassen. Dadurch wird gewährleistet, dass die regionalen Kosten keine Auswirkung auf die globalen Routenprioritäten haben. Eine Route aus einer anderen Region (einer entfernten Region) darf keine Priorität unter 201 haben. Wenn Sie höhere Werte verwenden, können sich die regionalen Kosten auf Ihre Routenprioritäten auswirken. Beispiel: Sie haben eine primäre Verbindung und eine Ersatzverbindung. Wenn Sie die Basispriorität der Ersatzverbindung zu hoch festlegen, könnten Sie unbeabsichtigt Routen aus anderen Regionen anstelle der Ersatzverbindung bevorzugen.

Verwenden Sie Werte größer als 10,200, um die Priorisierung einer Route in einem VPC-Netzwerk global aufzuheben. Dadurch wird gewährleistet, dass alle anderen Routen unter 201 unabhängig von den regionalen Kosten Priorität haben.

In Fällen, in denen alle Routen in einer Region gleichermaßen bevorzugt werden, können Sie den Standardwert 100 verwenden.

Beispieltopologien

In den folgenden Beispielen wird erläutert, wie sich regionale Kosten auf Routenmesswerte auswirken, wenn Sie das globale dynamische Routing verwenden.

Angenommen, Sie haben ein VPC-Netzwerk mit zwei Cloud VPN-Tunneln mit eigenen Cloud Routern. Ein Tunnel befindet sich in us-central1 und der andere in us-west1. Standardmäßig werden bei dem in diesen Regionen eingehenden Traffic die entsprechenden Tunnel in ihren jeweiligen Regionen verwendet. Was passiert aber, wenn Sie VMs erreichen möchten, die sich nicht in diesen Regionen befinden, z. B. VMs in europe-west1? Das folgende Diagramm zeigt, wie sich die regionalen Kosten auf die Routenmesswerte auswirken.

Cloud Router – Routenmesswerte für beworbene Routen (zum Vergrößern klicken)
Cloud Router – Routenmesswerte für beworbene Routen (zum Vergrößern klicken)

Beide Cloud Router bewerben Routen nach europe-west1, aber mit unterschiedlichen Routenmesswerten. Der Cloud Router in us-central1 bewirbt Routen nach europe-west1 aufgrund von Entfernung, Latenz und anderen Faktoren mit einem niedrigeren Routenmesswert als Routen nach us-west1. Im Beispiel wird davon ausgegangen, dass die regionalen Kosten nach europe-west1 über us-central1 den Wert 300 und über us-west1 den Wert 350 haben. Beim eingehenden Traffic wird der us-central1-Tunnel verwendet, der einen niedrigeren Routenmesswert hat. Er hat einen Routenmesswert von 350 im Vergleich zu 400 für den us-west1-Tunnel.

In ähnlicher Weise fügt Cloud Router dem MED-Wert der erkannten Routen (die von Ihrem lokalen Router angegeben werden) regionale Kosten hinzu. Standardmäßig wird beim ausgehenden Traffic aus der europe-west1-Region ebenfalls der us-central1-Tunnel verwendet, da er einen niedrigeren Routenmesswert hat. So wird die Symmetrie zwischen dem eingehenden und dem ausgehenden Datenverkehr gewahrt.

Cloud Router – Routenmesswerte für erkannte Routen (zum Vergrößern klicken)
Cloud Router – Routenmesswerte für erkannte Routen (zum Vergrößern klicken)

Routenprioritäten innerhalb einer Region

Angenommen, Sie erstellen aus Gründen der Redundanz in us-west1 einen Sicherungstunnel. Sie geben eine höhere Basispriorität für den Sicherungstunnel an, damit der in us-west1 eingehende Traffic den primären Tunnel bevorzugt, wie im folgenden Beispiel gezeigt.

Basisprioritäten für Routen innerhalb einer Region (zum Vergrößern klicken)
Basisprioritäten für Routen innerhalb einer Region (zum Vergrößern klicken)

Wenn der primäre Tunnel ausfällt, bevorzugt der in us-west1 eingehende Traffic den Sicherungstunnel mit einem Routenmesswert von 51 gegenüber dem us-central1-Tunnel, dessen Routenmesswert 400 ist.

Basisprioritäten für Routen innerhalb einer Region (zum Vergrößern klicken)
Basisprioritäten für Routen innerhalb einer Region (zum Vergrößern klicken)

Verwenden Sie in ähnlicher Weise für den ausgehenden Traffic vom VPC-Netzwerk zu Ihrem lokalen Netzwerk MED-Werte unter 201, um einen Pfad gegenüber einem anderen zu priorisieren. Andernfalls ist der ausgehende Traffic vom VPC-Netzwerk zu Ihrem lokalen Netzwerk möglicherweise nicht mit dem eingehenden Traffic symmetrisch.

Wenn alle Tunnel oder Cloud Interconnect-Verbindungen in einer Region die gleiche Priorität haben, können Sie die standardmäßige Basisroutenpriorität 100 verwenden.

Global bevorzugte Route

Angenommen, Sie haben Dedicated Interconnect und einen Cloud VPN-Tunnel in verschiedenen Regionen. Sie möchten Dedicated Interconnect priorisieren, da es für Ihre Arbeitslasten kostengünstiger als der Cloud VPN-Tunnel ist. Geben Sie eine Basispriorität von 10,051 für die Cloud VPN-Tunnelrouten an, um die Priorität aufzuheben. Dadurch wird für den gesamten eingehenden Traffic Dedicated Interconnect verwendet, unabhängig von den regionalen Kosten. Routenmesswerte für Dedicated Interconnect überschreiten nicht 10,051. Traffic verwendet den Cloud VPN-Tunnel nur, wenn die Verbindung fehlschlägt.

Basisprioritäten für globale Routen (zum Vergrößern klicken)
Basisprioritäten für globale Routen (zum Vergrößern klicken)

Sie müssen auch die gleichen Anpassungen an Ihrem lokalen Router vornehmen, damit der ausgehende Traffic vom VPC-Netzwerk zum lokalen Netzwerk immer Dedicated Interconnect verwendet.

Weitere Informationen zum Festlegen einer Basispriorität finden Sie unter BGP-Sitzungen erstellen oder Basispriorität der beworbenen Route aktualisieren.

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.

Sie können Traffic auch standardmäßig an Ihr lokales Netzwerk weiterleiten. 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 Priorität vor anderen automatisch erstellten Standardrouten hat. Dies ist am niedrigeren MED-Wert erkennbar. Auf der Seite "Routen" können Sie sich 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.

Ordnungsgemäßer Neustart

Cloud Router beachtet Nachrichten zu ordnungsgemäßem Neustart, die von Ihrem lokalen Router gesendet werden. Wenn Sie Ihren lokalen Router mit einem ordnungsgemäßen Neustart konfiguriert haben, kann er eine Benachrichtigung an Cloud Router senden, wenn Ihr Router Softwareupdates installieren oder regelmäßige Wartungen durchführen muss. Cloud Router speichert benutzerdefinierte dynamische Routen, die er von Ihrem lokalen Router ermittelt hat, für den Zeitraum, der durch die Timereinstellung für den ordnungsgemäßen Neustart Ihres lokalen Routers definiert wird.

Weitere Informationen zu Timern für den ordnungsgemäßen Neustart finden Sie unter BGP-Timereinstellungen.

Cloud VPN-Tunnel mit ordnungsgemäßem Neustart

Wenn Cloud Router im folgenden Beispiel ein Wartungsupdate benötigt, kann er aktualisiert werden, ohne den Datenverkehr zu unterbrechen, solange er innerhalb des Zeitraums für den ordnungsgemäßen Neustart wieder online ist.

Ordentlicher Neustart und Netzwerkverbindung (zum Vergrößern klicken)
Ordnungsgemäßer Neustart und Netzwerkverbindung (zum Vergrößern klicken)

BGP-Timereinstellungen

Cloud Router und Ihr lokaler Router steuern die Kommunikation mit den folgenden Timereinstellungen:

Keepalive-Timer
Dieser Timer legt das Intervall zwischen den periodischen BGP-Heartbeats fest, die zwischen Cloud Router und dem entsprechenden lokalen Peer-Router ausgetauscht werden. In Verbindung mit dem Hold-Timer gibt der Keepalive-Timer die Verfügbarkeit aller Router füreinander an. Setzen Sie den Keepalive-Timer auf Ihrem lokalen Router auf 20 Sekunden.
Hold-Timer
Dieser Timer gibt die Mindestzeit seit dem letzten erfolgreichen Keepalive-Heartbeat an. Diese Mindestzeit legt fest, wie lange Cloud Router oder der lokale Router warten muss, bevor er die vom anderen Router erkannten Routen entfernt. Stellen Sie den Hold-Timer auf dem lokalen Router auf 60 Sekunden ein.
Timer für ordnungsgemäßen Neustart

Dieser Timer legt den Zeitraum fest, den der lokale Router ohne periodische Keepalive-Heartbeats wartet, bis er neue Keepalive-Heartbeats erwartet, nachdem er eine Benachrichtigung über den ordnungsgemäßen Neustart des entsprechenden Cloud Routers erhalten hat. Wenn keine neuen Keepalive-Herzschläge empfangen werden, entfernt der lokale Router die von Cloud Router ermittelten Routen.

Wir empfehlen, den Timer für ordnungsgemäßen Neustart auf Ihrem lokalen Router auf 1 Sekunde zu stellen, wenn Sie möchten, dass sich Ihr Router genauso wie Cloud Router verhält.

Cloud Router entfernt die benutzerdefinierten dynamischen Routen, die er von lokalen Geräten ermittelt, wenn er feststellt, dass ein Cloud VPN-Tunnel für den nächsten Hop oder eine Cloud Interconnect-Verbindung ausgefallen ist. Wenn Sie die Zeit Ihres lokalen Routers für ordnungsgemäßen Neustart auf einen Wert größer als eine Sekunde festlegen, sendet Ihr lokaler Router möglicherweise Rücktraffic an einen nächsten Hop, der nicht mehr aktiv ist, anstatt zu einem konfigurierten sekundären nächsten aktiven Hop zu wechseln.

Stalepath-Timer

Dieser Timer legt fest, wie lange ein Router wartet, bevor er ermittelte Routen löscht, nachdem er eine EOR-Nachricht vom anderen Router empfangen hat. Er wird gestartet, wenn die BGP-Sitzung nach einem ordnungsgemäßen Neustart wieder initialisiert wird, das betreffende Präfix jedoch nicht durch eine UPDATE-Nachricht adressiert wurde. Wir empfehlen, den Stalepath-Timer auf Ihrem lokalen Router auf 300 Sekunden zu stellen, damit er der Einstellung für Cloud Router entspricht.

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. Dynamisch weitergeleiteter Cloud VPN-Traffic tritt nicht mehr in den Tunnel ein. Statische Routen für den Tunnel werden weiterhin bedient.

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.

Das folgende Beispiel zeigt ein einzelnes Feld als den Cloud Router, aber mit zwei IP-Adressen. Diese beiden Adressen sind separate Ethernet-Schnittstellen innerhalb derselben Cloud Router-Aufgabe. Jede Schnittstelle wird für eine separate BGP-Sitzung mit einem separaten lokalen Gateway verwendet. Da diese Cloud VPN-Tunnel zu Redundanzzwecken eingerichtet wurden, tauschen in diesem speziellen Anwendungsfall beide BGP-Sitzungen exakt denselben Satz von Routenpräfixen aus, jedoch mit unterschiedlichen nächsten Hops, die auf unterschiedliche Cloud VPN-Tunnel verweisen.

Redundanz ohne ordnungsgemäßen Neustart (zum Vergrößern klicken)
Redundanz ohne ordnungsgemäßen Neustart (zum Vergrößern klicken)

Upgrade-Zyklen

Cloud Router wird regelmäßig aktualisiert, was weniger als 60 Sekunden dauert. Cloud Router ist während des Upgrades 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 Peer-BGP-Haltezeitgeber auf mindestens 60 Sekunden festlegen (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.

Die BGP-Router-ID und die 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

Informationen zur Behebung häufiger Probleme mit Cloud Router finden Sie in der Dokumentation zur Fehlerbehebung.

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

Produkt Routing Dokumentation
Dedizierte Interconnect-Verbindung Statisch Nicht unterstützt
Dedizierte Interconnect-Verbindung Dynamisch VLAN-Anhänge erstellen
Klassisches VPN Richtlinienbasiert, statisch Klassischen VPN-Tunnel mit statischem Routing erstellen
Klassisches VPN oder HA VPN Dynamisch Klassisches VPN mit dynamischem Routing erstellen
Gateway zwischen HA VPN und Peer-VPN erstellen
Gateway zwischen Google Cloud und Google Cloud HA VPN erstellen