Statische Routen

Diese Seite bietet einen Überblick über die Funktionsweise von Routen in Google Cloud.

Eine allgemeine Übersicht über Routen in Google Cloud finden Sie in der Routenübersicht.

Überlegungen zum Erstellen statischer Routen

Sie können statische Routen auf zwei Weisen erstellen:

Sie können statische Routen mit einem Peering-VPC-Netzwerk austauschen, wie in der VPC-Netzwerk-Peering-Dokumentation unter Optionen für den Austausch benutzerdefinierter statischer Routen beschrieben.

Routenparameter

Statische Routen unterstützen folgende Attribute:

  • Name und Beschreibung. Diese Felder identifizieren die Route. Ein Name ist erforderlich, eine Beschreibung jedoch optional. Der Name jeder Route darf in Ihrem Projekt nur einmal vorkommen.

  • Netzwerk. Jede Route muss genau einem VPC-Netzwerk zugeordnet sein.

  • Next Hop. Der nächste Hop identifiziert die Netzwerkressource, an die Pakete gesendet werden. Alle Next-Hop-Typen unterstützen IPv4-Ziele, einige Next-Hop-Typen unterstützen IPv6-Ziele. Weitere Informationen finden Sie unter Next-Hops und Funktionen.

  • Zielbereich. Der Zielbereich ist eine einzelne IPv4- oder IPv6-CIDR-Notation.

    Ziele für statische Routen müssen den Regeln entsprechen, die unter Interaktionen mit statischen Routen und Interaktionen von Subnetzen und statischen Routen beschrieben werden. Das breitestmögliche Ziel für eine statische IPv4-Route ist 0.0.0.0/0. Das breitestmögliche Ziel für eine statische IPv6-Route ist ::/0.

  • Priorität. Niedrigere Zahlen bedeuten höhere Prioritäten. Die höchstmögliche Priorität ist 0, die niedrigste Priorität ist 65,535.

  • Netzwerk-Tags. Sie können eine statische Route nur für ausgewählte VM-Instanzen im VPC-Netzwerk festlegen, die durch ein Netzwerk-Tag identifiziert werden. Wenn Sie kein Netzwerk-Tag angeben, macht Google Cloud die statische Route für alle Instanzen im Netzwerk gültig. Statische Routen mit Tags werden bei Verwendung des VPC-Netzwerk-Peering nie ausgetauscht.

Next-Hops und Funktionen

In der folgenden Tabelle sind die unterstützten Funktionen für statische Routen nach Next-Hop-Typ zusammengefasst:

Nächster Hop-Typ IPv4 IPv6 ECMP1
Nächstes Hop-Gateway (next-hop-gateway)
Sie können ein Standard-Internetgateway angeben, um einen Pfad zu externen IP-Adressen zu definieren.
Nächste Hop-Instanz nach Name und Zone (next-hop-instance)
Pakete an eine nächste Hop-VM senden, die durch Name und Zone identifiziert wird und sich im selben Projekt befindet wie die Route. Weitere Informationen finden Sie unter Überlegungen zu Next-Hop-Instanzen.
Nächste Hop-Instanz nach Adresse (next-hop-address)
Pakete an eine nächste Hop-VM senden, die durch die primäre interne IPv4-Adresse oder eine interne oder externe IPv6-Adresse ihrer Netzwerkschnittstelle identifiziert wird. Weitere Informationen finden Sie unter Überlegungen zu Next-Hop-Instanzen.		 (Vorschau)
Nächster Hop: Interner Passthrough-Netzwerk-Load Balancer über Weiterleitungsregelnamen (next-hop-ilb) und Region (next-hop-ilb-region)
Pakete an Back-Ends eines internen Passthrough-Netzwerk-Load Balancers senden, die durch den Namen, die Region und optional das Projekt der Weiterleitungsregel identifiziert werden. Weitere Informationen finden Sie unter Überlegungen zu internen Passthrough Network Load Balancern, die als nächster Hop dienen.		 (Vorschau)
Nächster Hop: Interner Passthrough-Netzwerk-Load-Balancer nach Adresse (next-hop-ilb)
Pakete an Back-Ends eines internen Passthrough-Netzwerk-Load-Balancers senden, die durch die IP-Adresse der Weiterleitungsregel des Load-Balancers identifiziert werden. Weitere Informationen finden Sie unter Überlegungen zu internen Passthrough Network Load Balancern, die als nächster Hop dienen. 		(Vorschau)
Nächster Hop: Klassischer VPN-Tunnel (next-hop-vpn-tunnel )
Senden von Paketen an einen als nächster Hop dienenden klassischen VPN-Tunnel über richtlinienbasiertes Routing oder ein routenbasiertes VPN. Weitere Informationen finden Sie unter Überlegungen zu klassischen VPN-Tunneln als nächstem Hop.
1 ECMP (Equal-Cost Multipath) bedeutet, dass zwei oder mehr statische Routen denselben Zielbereich und dieselbe Priorität haben können. Obwohl Sie in einem VPC-Netzwerk zwei oder mehr statische Routen mit demselben Ziel, derselben Priorität und demselben Standard-Internetgateway als nächsten Hop erstellen können, entspricht dies effektiv einer einzelnen statischen Route, die das standardmäßige Internet-Gateway als nächsten Hop für dieses Ziel und diese Priorität nutzt.

Next-Hop-Projekt und ‑Netzwerk

Der nächste Hop einer statischen Route ist sowohl mit einem VPC-Netzwerk als auch mit einem Projekt verknüpft:

  • Netzwerk: Sofern nicht in der folgenden Tabelle anders angegeben, muss das VPC-Netzwerk des nächsten Hops mit dem VPC-Netzwerk der Route übereinstimmen.

  • Projekt: Sofern nicht in der folgenden Tabelle anders angegeben, muss sich der nächste Hop in dem Projekt befinden, das das VPC-Netzwerk des nächsten Hops enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt). Einige Next-Hops können sich in Dienstprojekten mit freigegebene VPC befinden.

Nächster Hop-Typ Kann sich in einem Peering-VPC-Netzwerk befinden Kann sich in einem Dienstprojekt mit freigegebene VPC befinden
Nächstes Hop-Gateway (next-hop-gateway)
Nächste Hop-Instanz nach Name (next-hop-instance)
Next Hop-Instanz nach Adresse (next-hop-address)
Nächster Hop: Interner Passthrough-Netzwerk-Load-Balancer des nach Name und Region der Weiterleitungsregel (next-hop-ilb)
Nächster Hop: Interner Passthrough-Netzwerk-Load-Balancer nach Adresse (next-hop-ilb)
Nächster Hop: Klassischer VPN-Tunnel (next-hop-vpn-tunnel)

Überlegungen zu Instanzen und internen Passthrough Network Load Balancern, die als nächster Hop dienen

Instanzbasiertes Routing bezieht sich auf eine statische Route mit einer VM-Instanz als nächsten Hop (next-hop-instance oder next-hop-address).

Der interne Passthrough Network Load Balancer als nächster Hop bezieht sich auf eine statische Route mit einem internen Passthrough Network Load Balancer (next-hop-ilb).

Wenn Sie das instanzbasierte Routing oder einen internen Passthrough Network Load Balancer als nächsten Hop konfigurieren, beachten Sie die folgenden Richtlinien:

  • Sie müssen die Backend-VMs oder die nächste Hop-Instanz so konfigurieren, dass sie Pakete von einer beliebigen Quell-IP-Adresse weiterleiten. Wenn Sie die Weiterleitung konfigurieren möchten, aktivieren Sie die IP-Weiterleitung (can-ip-forward) pro VM, wenn Sie die VM erstellen. Aktivieren Sie für VMs, die automatisch als Teil einer verwalteten Instanzgruppe erstellt werden, die IP-Weiterleitung in der von der Instanzgruppe verwendeten Instanzvorlage. Sie müssen diese Konfiguration zusätzlich zu jeder Betriebssystemkonfiguration vornehmen, die zum Weiterleiten von Paketen erforderlich ist.

  • Software, die auf der Backend-VM oder der nächsten Hop-Instanz ausgeführt wird, muss entsprechend konfiguriert werden. Beispielsweise müssen VM-Appliances von Drittanbietern, die als Router oder Firewalls dienen, gemäß den Anweisungen des Herstellers konfiguriert werden.

  • Back-End-VMs oder die nächste Hop-Instanz müssen die erforderlichen Firewallregeln haben. Sie müssen Firewallregeln konfigurieren, die für die Pakete gelten, die weitergeleitet werden. Beachten Sie Folgendes:

    • Firewallregeln für eingehenden Traffic, die auf Instanzen mit Routingfunktionen angewendet werden, müssen die IP-Adressen der Quellen von weitergeleiteten Paketen enthalten. Die implizierte Regel zum Ablehnen von eingehendem Traffic blockiert alle eingehenden Pakete. Sie müssen also mindestens benutzerdefinierte Firewall-Zulassungsregeln für eingehenden Traffic erstellen.
    • Firewallregeln für ausgehenden Traffic, die auf Instanzen mit Routingfunktionen angewendet werden, müssen die IP-Adressen der Ziele von weitergeleiteten Paketen enthalten. Die implizierte Regel zum Zulassen von ausgehendem Traffic erlaubt dies, sofern sie nicht durch eine bestimmte von Ihnen erstellte Regel zum Ablehnen von ausgehendem Traffic überschrieben wird.
    • Berücksichtigen Sie beim Erstellen Ihrer Firewallregeln, ob die Back-End-VM oder die nächste Hop-Instanz Network Address Translation (NAT) ausführt.

    Weitere Informationen finden Sie unter Implizierte Firewallregeln.

  • Die Quellregion eines Pakets, das von einer Backend-VM oder einer Next-Hop-Instanz gesendet wurde, ist die Region, in der sich die Backend-VM oder die Next-Hop-Instanz befindet. Beispiel: Pakete, die von Backend-VMs oder Next-Hop-Instanzen in us-west1 verarbeitet werden, können an Ziele gesendet werden, auf die nur in us-west1 zugegriffen werden kann, selbst wenn die Backend-VM oder die Next-Hop-Instanz das Paket ursprünglich von einer Ressource in einer anderen Region als us-west1 empfangen hat. Beispiele für Ressourcen, auf die nur in derselben Region wie eine VM, die ein Paket sendet, zugegriffen werden kann, sind die folgenden:

    • Interne Passthrough Network Load Balancer, interne Application Load Balancer und regionale interne Proxy Network Load Balancer mit deaktiviertem globalen Zugriff
    • Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge und Network Connectivity Router-Appliance-VMs, wenn das VPC-Netzwerk das regionale dynamische Routing nutzt

Überlegungen zu als nächster Hop dienenden Instanzen

  • Nächster Hop nach Instanzname und Zone (next-hop-instance): Wenn Sie eine statische Route mit einer nächsten Hop-Instanz erstellen, die durch Instanznamen und Zone angegeben ist, erfordert Google Cloud, dass eine Instanz mit diesem Namen in der angegebenen Zone vorhanden ist und folgende Bedingungen erfüllt:

    • Die Instanz befindet sich im selben Projekt wie die Route.
    • Die Instanz hat eine Netzwerkschnittstelle (NIC) im VPC-Netzwerk der Route (nicht in einem Peering-VPC-Netzwerk).

    Solange die statische Route vorhanden ist, gilt Folgendes:

    • Google Cloud aktualisiert die Programmierung für den nächsten Hop in folgenden Fällen automatisch:

      • sich die primäre interne IPv4-Adresse der nächsten Hop-Instanz ändert oder
      • Sie ersetzen die nächste Hop-Instanz. Die Ersatzinstanz hat dabei denselben Namen, befindet sich in derselben Zone und im selben Projekt und hat eine Netzwerkschnittstelle im VPC-Netzwerk der Route.

    • In den folgenden Fällen aktualisiert Google Cloud die Programmierung für den nächsten Hop nicht:

      • Wenn die Instanz gelöscht wird.
      • Der IPv6-Adressbereich, der der NIC der Instanz zugewiesen ist, ändert sich.
      • Wenn die IPv4- oder IPv6-Adresse der Instanz nicht zugewiesen ist.

  • IP-Adresse der Next-Hop-Instanz (next-hop-address): Gültige VM-IP-Adressen für den nächsten Hop:

    • Die primäre interne IPv4-Adresse einer VM-Netzwerkschnittstelle
    • Eine interne oder externe IPv6-Adresse im IPv6-Adressbereich /96, die einer VM-Netzwerkschnittstelle zugewiesen ist.

    Wenn Sie eine statische Route mit einer Next-Hop-Instanz erstellen, die durch eine IP-Adresse angegeben wird, akzeptiert Google Cloud jede VM-zugewiesene IP-Adresse, die in einen Subnetzbereich eines Subnetzes im selben VPC-Netzwerk wie die Route passt. Google Cloud programmiert die Route jedoch nur, wenn die Adresse des nächsten Hops eine gültige VM-IP-Adresse für den nächsten Hop ist. Wenn Sie beispielsweise eine Route erstellen und den nächsten Hop als IP-Adresse angeben, die aus einem Alias-IP-Bereich stammt, wird die Route erstellt. Da Alias-IP-Adressen jedoch keine gültigen Next-Hop-VM-IP-Adressen sind, wird die Route nicht programmiert.

    Google Cloud aktualisiert die Programmierung für den nächsten Hop automatisch, wenn die IP-Adresse des nächsten Hops in eine andere VM verschoben wird, sofern die IP-Adresse eine gültige VM-IP-Adresse des nächsten Hops bleibt.

    Wenn Sie eine nächste Hop-Instanz anhand der IP-Adresse angeben, werden Pakete an die Netzwerkschnittstelle der Instanz und nicht an die bestimmte IP-Adresse weitergeleitet.

  • Nächste Hop-Instanzen in freigegebenen VPC-Dienstprojekten: Wenn Sie eine Nex-Hop-VM über eine IP-Adresse angeben, kann sich die VM entweder im selben Projekt wie die Route (in einem eigenständigen Projekt oder einem freigegebenen VPC-Hostprojekt) oder in einem freigegebenen VPC-Dienstprojekt befinden. Wenn Sie eine Next-Hop-VM über Instanzname und Zone angeben, muss sich die Next-Hop-VM im selben Projekt wie die Route und das VPC-Netzwerk befinden (in einem eigenständigen Projekt oder einem freigegebenen VPC-Hostprojekt).

  • Kosten und Latenz von Region zu Region:: Wenn Sie eine VM als nächsten Hop verwenden, befindet sich der nächste Hop in einer Zone einer Region. Die Route, die den nächsten Hop verwendet, ist für alle Instanzen im selben VPC-Netzwerk oder für ausgewählte Instanzen mit einem übereinstimmenden Netzwerk-Tag verfügbar. Die regionale Entfernung für Routen, die eine Instanz als nächsten Hop verwenden, wird von Google Cloud nicht berücksichtigt. Daher kann auch eine Route erstellt werden, die Traffic an eine nächste Hop-VM in einer anderen Region sendet. Das Senden von Paketen von einer Region in eine andere erhöht die Kosten für die ausgehende Datenübertragung und führt zu Netzwerklatenz.

  • Keine Systemdiagnose, keine Konfigurationsvalidierung: Google Cloud prüft niemals, ob eine nächste Hop-Instanz alle unter Überlegungen zu Instanzen und internen Passthrough Network Load Balancern, die als nächste Hops dienen beschriebenen Anforderungen erfüllt. Das Deaktivieren der Netzwerkschnittstelle der VM durch Konfigurieren des Gastbetriebssystems der Instanz bewirkt nicht, dass Google Cloud die nächste Hop-Instanz ignoriert.

  • Kein symmetrisches Hashing beim Verbinden von zwei VPC-Netzwerken: Google Cloud bietet kein symmetrisches Hashing, wenn zwei oder mehr nächste Hop-VMs mit mehreren Netzwerkschnittstellen in einer Konfiguration verwendet werden, die alle folgenden Kriterien erfüllt:

    • Die VMs haben genau eine Netzwerkschnittstelle in genau einem VPC-Netzwerk und eine weitere Oberfläche in einem zweiten VPC-Netzwerk.
    • In jedem VPC-Netzwerk gibt es einen Satz von mindestens zwei benutzerdefinierten statischen Routen für dasselbe Ziel mit derselben Priorität, wobei jede Route im Satz auf eine eindeutige nächste Hop-VM verweist.

    Wenn Sie zwei oder mehr VMs mit mehreren Schnittstellen verwenden, um VPC-Netzwerke zu verbinden, und Sie erfordern, dass dieselbe VM Pakete für eine bestimmte Verbindung in beide Richtungen verarbeitet, benötigen Sie symmetrisches Hashing, das nur von internen Next Hop Passthrough Network Load Balancern unterstützt wird. Weitere Informationen finden Sie unter Symmetrisches Hashing.

  • Verhalten beim Anhalten oder Löschen von Instanzen: Google Cloud hindert Sie nicht daran, eine Next Hop-VM mit statischer Route (die entweder durch Name und Zone oder interne Adresse angegeben wird) anzuhalten oder zu löschen. Ist eine als nächster Hop dienende VM nicht aktiv, so hängt das Routing davon ab, ob andere Routen für genau dasselbe Ziel vorhanden sind und ob diese anderen Routen aktive nächste Hops haben. Die folgenden Beispiele veranschaulichen dieses Verhalten:

    • Sie haben die folgenden Routen und VM-Status:

      • route-a, Ziel 192.168.168.0/24, Priorität 10, VM des nächsten Hops vm-a ist angehalten
      • route-b, Ziel 192.168.168.0/24, Priorität 20, VM des nächsten Hops vm-b ist aktiv
      • route-c, Ziel 192.168.168.0/24, Priorität 30, VM des nächsten Hops vm-c ist aktiv

      In diesem Beispiel werden Pakete, deren Ziele in 192.168.168.0/24 passen, an den nächsten Hop von vm-b gesendet, da der nächste Hop vm-a der Route mit der höchsten Priorität route-a nicht aktiv ist. Das liegt daran, dass der Schritt Statische und dynamische Routen mit nicht verwendbaren nächsten Hops ignorieren in der Google Cloud-Routingreihenfolge vor dem Schritt Routen mit niedriger Priorität ignorieren kommt.

    • Sie haben die folgenden Routen und VM-Status:

      • route-x, Ziel 192.168.168.0/24, Priorität 10, VM des nächsten Hops vm-x ist angehalten
      • route-y, Ziel 192.168.168.0/24, Priorität 20, VM des nächsten Hops vm-y ist angehalten
      • route-z, Ziel 192.168.0.0/16, Priorität 0, VM des nächsten Hops vm-z ist aktiv

      In diesem Beispiel werden Pakete, deren Ziele in 192.168.168.0/24 passen, verworfen, da die nächsten Hop-VMs für die beiden 192.168.168.0/24-Routen (route-x und route-y) nicht ausgeführt werden, obwohl eine Route für das breitere 192.168.0.0/16-Ziel (route-z) mit einer ausgeführten nächsten Hop-VM vorhanden ist. Das liegt daran, dass der Schritt spezifischstes Ziel in der Google Cloud-Routingreihenfolge vor dem Schritt Statische und dynamische Routen mit nicht verwendbaren nächsten Hops ignorieren kommt.

Überlegungen zu internen Passthrough Network Load Balancern, die als nächster Hop dienen

  • Unterstützte Weiterleitungsregeln. Google Cloud unterstützt nur interne Weiterleitungsregeln für Network Load Balancer als nächsten Hop. Google Cloud unterstützt keine Weiterleitungsregeln für den nächsten Hop, die von anderen Load Balancern, Protokollweiterleitungen oder als Private Service Connect-Endpunkten verwendet werden.

  • Spezifikationsmethoden sowie das Netzwerk und Projekt für die Weiterleitungsregel. Sie können eine der folgenden Hop-Weiterleitungsregeln angeben. Die von Ihnen verwendete Spezifikationsmethode bestimmt, ob das Netzwerk der Weiterleitungsregel mit dem Netzwerk der Route übereinstimmen muss und in welchem Projekt sich die Weiterleitungsregel befinden kann.

    Wählen Sie eine der folgenden Methoden aus und achten Sie darauf, dass die IP-Version Ihrer Weiterleitungsregel mit der IP-Version der von Ihnen erstellten statischen Route übereinstimmt:

    • Nach Weiterleitungsregelname (--next-hop-ilb) und Region (--next-hop-ilb-region): Wenn Sie eine Weiterleitungsregel als nächsten Hop nach Name und Region angeben, muss das Netzwerk der Weiterleitungsregel mit dem VPC-Netzwerk der Route übereinstimmen. Die Weiterleitungsregel muss sich in demselben Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt).

    • Durch Weiterleitung des Links zur Weiterleitungsregelressource: Der Ressourcenlink einer Weiterleitungsregel verwendet das folgende Format: /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, wobei PROJECT_ID die Projekt-ID des Projekts ist, das die Weiterleitungsregel enthält. REGION ist die Region der Weiterleitungsregel und FORWARDING_RULE_NAME ist der Name der Weiterleitungsregel. Wenn Sie eine Weiterleitungsregel für den nächsten Hop über den Ressourcenlink angeben, muss das Netzwerk der Weiterleitungsregel mit dem VPC-Netzwerk der Route übereinstimmen. Die Weiterleitungsregel kann sich in dem Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt) oder in einem freigegebenen VPC-Dienstprojekt.

    • Durch die IP-Adresse einer Weiterleitungsregel: Wenn Sie eine Weiterleitungsregel für den nächsten Hop anhand seiner IPv4- oder IPv6-Adresse (Vorabversion) angeben, kann das Netzwerk der Weiterleitungsregel entweder das VPC-Netzwerk der Route oder ein Peering-VPC-Netzwerk sein. Die Weiterleitungsregel kann sich in dem Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebene VPC-Hostprojekt) oder in einem freigegebene VPC-Dienstprojekt.

  • Auswirkungen des globalen Zugriffs. Benutzerdefinierte statische Routen, die interne Network Load Balancer als nächste Hops verwenden, werden in allen Regionen programmiert. Ob der nächste Hop verwendet werden kann, hängt von der Einstellung für den globalen Zugriff des Load-Balancers ab. Wenn der globale Zugriff aktiviert ist, ist der Load-Balancer als nächster Hop in allen Regionen des VPC-Netzwerks zugänglich. Wenn der globale Zugriff deaktiviert ist, ist der Load-Balancer als nächster Hop nur in derselben Region wie der Load-Balancer zugänglich. Wenn der globale Zugriff deaktiviert ist, werden Pakete, die aus einer anderen Region an eine Route mit einem internen Passthrough Network Load Balancer gesendet werden, verworfen.

  • Wenn alle Back-Ends fehlerhaft sind. Wenn alle Back-Ends eines internen Passthrough Network Load Balancers bei Systemdiagnosen fehlschlagen, sind die Routen, die diesen nächsten Hop verwenden, noch aktiv. Von der Route verarbeitete Pakete werden gemäß der Trafficverteilung an eines der Back-Ends des nächsten Hop-Load-Balancers gesendet.

  • Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden (--purpose=SHARED_LOADBALANCER_VIP), werden nicht unterstützt. Die Network Load Balancer des nächsten Hops und die Weiterleitungsregeln für internen Passthrough Network Load Balancer mit einer gemeinsamen IP-Adresse schließen sich gegenseitig aus. Der interne Passthrough Network Load Balancer mit nächstem Hop muss eine IP-Adresse verwenden, die für die Weiterleitungsregel des Load-Balancers eindeutig ist, damit nur ein Backend-Dienst (ein Load-Balancer) eindeutig referenziert wird. Es ist möglich, dass Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden, auf verschiedene Backend-Dienste verweisen (verschiedene interne Passthrough Network Load Balancer).

  • Mehrere Routen mit denselben Zielen und Prioritäten, aber unterschiedlichen internen Passthrough Network Load Balancern als nächster Hop. Google Cloud verteilt Traffic nie auf zwei oder mehr interne Passthrough Network Load Balancer als nächsten Hop mit ECMP. Stattdessen wählt Google Cloud mithilfe eines deterministischen internen Algorithmus nur einen internen Passthrough-Network Load Balancer als nächsten Hop aus. Um diese Mehrdeutigkeit zu vermeiden, können Sie für jede Route eindeutige Netzwerk-Tags verwenden.

    Google Cloud wählt einen einzelnen nächsten Hop aus, wenn statische Routen mit unterschiedlichen internen Passthrough Network Load Balancern als nächste Hops dieselbe Priorität und dasselbe Ziel haben.

  • Mehrere Routen mit denselben Zielen, Prioritäten und internen Passthrough Network Load Balancern als nächster Hop. Ohne Netzwerk-Tag können Sie in Google Cloud nicht mehrere statische Routen mit derselben Kombination aus Ziel, Priorität und internem Passthrough Network Load Balancer als nächsten Hop erstellen. Mit Netzwerk-Tags können Sie mehrere statische Routen mit derselben Kombination aus Ziel, Priorität und internem Passthrough Network Load Balancer als nächsten Hop erstellen.

Überlegungen zu klassischen VPN-Tunneln mit nächstem Hop

  • Kosten und Latenz von Region zu Region: Google Cloud berücksichtigt keine regionalen Entfernungen für Routen, die einen als nächster Hop dienenden Klassisches VPN-Tunnel verwenden. Das Senden von Traffic an einen als nächster Hop dienenden klassischen VPN-Tunnel in einer anderen Region erhöht die Kosten für ausgehende Datenübertragung und führt zu Netzwerklatenz. Verwenden Sie als Best Practice stattdessen einen HA VPN-Tunnel mit dynamischem Routing, da diese Konfiguration regionale Entfernungen berücksichtigt.

  • Verhalten, wenn klassische VPN-Tunnel nicht ausgeführt werden: Benutzerdefinierte statische Routen, deren nächste Hops klassische VPN-Tunnel sind, werden nicht automatisch entfernt, wenn die klassischen VPN-Tunnel nicht aktiv sind. Weitere Informationen dazu, was geschieht, wenn Tunnel nicht aktiv sind, finden Sie in der Dokumentation zu klassischen VPNs unter Wenn Tunnel nicht erreichbar sind.

Nächste Schritte

  • Mehr zum Erstellen und Verwalten von Routen erfahren Sie unter Routen verwenden.
  • Eine allgemeine Übersicht über Routen in Google Cloud finden Sie unter Routen.