Routen

Google Cloud-Routen definieren die Pfade, die der Netzwerktraffic von einer VM-Instanz zu anderen Zielen zurücklegt. Diese Ziele können sich innerhalb Ihres Virtual Private Cloud-Netzwerks (VPC) von Google Cloud befinden, beispielsweise in einer anderen VM oder außerhalb davon.

In einem VPC-Netzwerk besteht eine Route aus einem einzelnen Zielpräfix im CIDR-Format und einem einzelnen nächsten Hop. Wenn eine Instanz in einem VPC-Netzwerk ein Paket sendet, liefert Google Cloud das Paket an den nächsten Hop der Route, wenn die Zieladresse des Pakets im Zielbereich der Route liegt.

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

Routing in Google Cloud

Jedes VPC-Netzwerk verwendet einen skalierbaren, verteilten virtuellen Routingmechanismus. Dem Netzwerk ist kein physisches Gerät zugewiesen. Einige Routen können selektiv angewendet werden, aber die Routingtabelle für ein VPC-Netzwerk wird auf VPC-Netzwerkebene definiert.

Jede VM-Instanz hat einen Controller, der über alle anwendbaren Routen aus der Routingtabelle des Netzwerks informiert wird. Jedes Paket, das eine VM verlässt, wird auf Basis einer Routingreihenfolge an den entsprechenden nächsten Hop einer anwendbaren Route zugestellt. Wenn Sie eine Route hinzufügen oder löschen, wird der Satz von Änderungen nach dem Eventual Consistency-Modell an die VM-Controller weitergegeben.

Routentypen

In den folgenden Tabellen wird zusammengefasst, wie Google Cloud Routen in VPC-Netzwerken kategorisiert.

Typ und Ziel Nächster Hop Hinweise
Vom System generierte Routen
Vom System generierte Standardrouten
0.0.0.0/0 für IPv4
::/0 für IPv6		 default-internet-gateway Gilt für das gesamte VPC-Netzwerk

Kann entfernt oder ersetzt werden
Subnetzroute
Wird automatisch für jeden Subnetz-IP-Adressbereich erstellt		 VPC-Netzwerk
Leitet Pakete an VMs und interne Load-Balancer weiter

Wird von Google Cloud während Subnetzlebenszyklus-Ereignissen automatisch erstellt, aktualisiert und entfernt.

Lokale Subnetzrouten gelten für das gesamte VPC-Netzwerk.
Benutzerdefinierte Routen
Statische Route
Unterstützt verschiedene Ziele		 Leitet Pakete an eine als nächster Hop dienende statische Route weiter Weitere Informationen zu jeder als nächster Hop dienenden statischen Route finden Sie unter:
Dynamische Route
Ziele, die nicht mit Subnetzrouten oder statischen Routen in Konflikt stehen		 Peer einer BGP-Sitzung auf einem Cloud Router Routen werden automatisch anhand der erkannten Routen von Cloud Routern in Ihrem VPC-Netzwerk hinzugefügt und entfernt.

Routen gelten für VMs entsprechend dem dynamischen Routingmodus des VPC-Netzwerks.
VPC-Netzwerk-Peering-Routen
Peering-Subnetzroute
Steht für den Subnetz-IP-Adressbereich in einem anderen VPC-Netzwerk, das über VPC-Netzwerk-Peering verbunden ist 		Nächster Hop im Peer-VPC-Netzwerk

VPC-Netzwerk-Peering bietet Optionen für den Austausch von Subnetzrouten.

Wird von Google Cloud während Subnetzlebenszyklus-Ereignissen automatisch erstellt, aktualisiert und entfernt.

Importierte Peering-Subnetzrouten gelten für das gesamte VPC-Netzwerk.
Statische und dynamische Peering-Routen
Statische oder dynamische Routen in einem anderen VPC-Netzwerk, das über VPC-Netzwerk-Peering verbunden ist 		Nächster Hop im Peer-VPC-Netzwerk

VPC-Netzwerk-Peering bietet Optionen für den Austausch statischer Routen.

Importierte statische Peering-Routen gelten für das gesamte VPC-Netzwerk.

VPC-Netzwerk-Peering bietet Optionen für den Austausch dynamischer Routen.

Importierte dynamische Peering-Routen gelten für eine oder alle Regionen des VPC-Netzwerks, je nach dem Modus für dynamisches Routing des VPC-Netzwerks, das die Routen exportiert.
Network Connectivity Center-Routen
Network Connectivity Center-Subnetzroute
Stellt einen IP-Adressbereich des Subnetzes in einem VPC-Spoke dar (ein anderes VPC-Netzwerk, das mit dem Network Connectivity Center-Hub verbunden ist) 		Network Connectivity Center-Hub

Spoke-Administratoren von Network Connectivity Center können den Export von Subnetzrouten ausschließen.

Wird von Google Cloud während Subnetzlebenszyklus-Ereignissen automatisch erstellt, aktualisiert und entfernt.

Importierte Network Connectivity Center-Subnetzrouten gelten für das gesamte VPC-Netzwerk.
Richtlinienbasierte Routen
Richtlinienbasierte Route
Richtlinienbasierte Routen können für Pakete basierend auf Quell-IP-Adresse, Ziel-IP-Adresse, Protokoll oder einer Kombination davon gelten.

Richtlinienbasierte Routen werden vor anderen Routen ausgewertet. Richtlinienbasierte Routen können für alle VMs im Netzwerk, für bestimmte durch ein Netzwerk-Tag ausgewählte VMs oder für Traffic gelten, der über von Ihnen identifizierte Cloud Interconnect-VLAN-Anhänge in das VPC-Netzwerk eintritt.

Richtlinienbasierte Routen werden nie über VPC-Netzwerk-Peering ausgetauscht.

Vom System generierte Standardrouten

Wenn Sie ein VPC-Netzwerk erstellen, enthält es eine vom System generierte Standardroute (IPv4) (0.0.0.0/0). Wenn Sie ein Dual-Stack-Subnetz mit einem externen IPv6-Adressbereich in einem VPC-Netzwerk erstellen, wird eine vom System generierte IPv6-Standardroute (::/0) zu diesem Netzwerk hinzugefügt, wenn die Route noch nicht vorhanden ist. Standardrouten dienen folgenden Zwecken:

Google Cloud verwendet eine Standardroute nur, wenn für ein Paket keine Route mit einem spezifischeren Ziel gilt. Weitere Informationen dazu, wie mithilfe von Zielspezifität und Routenpriorität eine Route ausgewählt wird, finden Sie unter Routingreihenfolge.

Sie können die Standardroute löschen, wenn Sie Ihr Netzwerk vollständig vom Internet isolieren möchten oder wenn Sie die Standardroute durch eine benutzerdefinierte Route ersetzen müssen:

  • Nur IPv4: Sie können die Standardroute durch eine benutzerdefinierte statische oder dynamische Route ersetzen, wenn Sie Internettraffic an einen anderen nächsten Hop weiterleiten möchten. Sie lässt sich beispielsweise durch eine benutzerdefinierte statische Route ersetzen, deren nächster Hop eine Proxy-VM ist.

  • IPv4 und IPv6: Wenn Sie die Standardroute löschen und nicht ersetzen, werden Pakete gelöscht, deren Ziel-IP-Bereiche nicht von anderen Routen abgedeckt werden.

Subnetzrouten

Subnetzrouten definieren Pfade zu Ressourcen wie VMs und internen Load-Balancern in einem VPC-Netzwerk.

Jedes Subnetz hat mindestens eine Subnetzroute, deren Ziel dem primären IPv4-Bereich des Subnetzes entspricht. Wenn das Subnetz sekundäre IP-Bereiche hat, gibt es für jeden sekundären IP-Adressbereich eine entsprechende Subnetzroute. Wenn das Subnetz einen IPv6-Bereich hat, gibt es für den IPv6-Adressbereich eine entsprechende Subnetzroute. Weitere Informationen zu Subnetz-IP-Bereichen finden Sie unter Subnetze.

Subnetzrouten haben immer die spezifischsten Ziele. Sie können selbst dann nicht durch andere Routen überschrieben werden, wenn eine andere Route eine höhere Priorität hat. Das liegt daran, dass Google Cloud bei der Auswahl einer Route die Zielspezifität berücksichtigt. Google Cloud verwendet 0 als Priorität für alle Subnetzrouten.

Interaktionen mit statischen Routen

Lokale Subnetzrouten und importierte Peering-Subnetzrouten interagieren auf folgende Weise mit benutzerdefinierten statischen Routen:

  • Mit Google Cloud können Sie keine benutzerdefinierte statische Route erstellen, deren Ziel gleich oder kleiner als eine beliebige Subnetzroute oder Peering-Subnetzroute ist. Beispiel:

    • Wenn eine lokale Subnetzroute oder eine Peering-Subnetzroute für das Ziel 10.70.1.0/24 vorhanden ist, können Sie keine neue benutzerdefinierte statische Route für 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 oder andere Ziele, die in 10.70.1.0/24 passen, erstellen.

    • Wenn eine lokale Subnetzroute oder eine Peering-Subnetzroute für das 2001:0db8:0a0b:0c0d::/64 Ziel existiert, können Sie keine neue benutzerdefinierte statische Route für 2001:0db8:0a0b:0c0d::/64 erstellen oder ein beliebiges anderes Ziel, das in 2001:0db8:0a0b:0c0d::/64 passt, wie 2001:0db8:0a0b:0c0d::/96.

  • Umgekehrt können Sie in Google Cloud keine neue Subnetz- oder Peering-Subnetzroute erstellen, deren Ziel genau mit einer vorhandenen benutzerdefinierten statischen Route übereinstimmt bzw. breiter als diese ist (Ziel enthält die Route). Beispiel:

    • Wenn Ihr VPC-Netzwerk eine benutzerdefinierte statische Route für das Ziel 10.70.1.128/25 hat, verhindert Google Cloud die Erstellung einer beliebigen Subnetzroute oder einer Peering-Subnetzroute, die einen primären oder sekundären IPv4-Subnetz-Adressbereich von 10.70.1.128/25, 10.70.1.0/24 oder einen anderen Bereich hat, der alle IPv4-Adressen in 10.70.1.128/25 enthält.

    • Wenn Ihr VPC-Netzwerk eine benutzerdefinierte statische Route für das Ziel 2001:0db8:0a0b:0c0d::/96 hat, untersagt Google Cloud die Erstellung einer Dual-Stack-Subnetzroute oder einer Peering-Subnetzroute mit einem IPv6-Adressbereich von 2001:0db8:0a0b:0c0d::/64 oder einem anderen Bereich, der alle IPv6-Adressen in 2001:0db8:0a0b:0c0d::/96 enthält.

Interaktionen mit dynamischen Routen

Lokale Subnetzrouten und importierte Peering-Subnetzrouten interagieren so mit Cloud Routern:

  • Wenn Cloud Router ein Präfix findet, das genau mit dem Ziel einer vorhandenen Subnetz- oder Peering-Subnetzroute übereinstimmt, erstellt Google Cloud keine benutzerdefinierte dynamische Route für den in Konflikt stehenden Präfix. Wenn beispielsweise eine Subnetz- oder Peering-Subnetzroute mit dem Ziel 10.70.1.0/24 vorhanden ist und Cloud Router im VPC-Netzwerk das 10.70.1.0/24-Präfix über BGP erhalten, verwendet Google Cloud die Subnetz- oder die Peering-Subnetzroute und erstellt keine benutzerdefinierten dynamischen Routen für 10.70.1.0/24.

    • Wenn eine Subnetz- oder Peering-Subnetzroute erstellt wird, deren Ziel genau mit einem Präfix übereinstimmt, das von Cloud Routern im VPC-Netzwerk ermittelt wurde, entfernt Google Cloud die benutzerdefinierte dynamische Route für den in Konflikt stehenden Präfix, um Platz für die Subnetz- oder Peering-Subnetzroute zu schaffen.

  • Wenn Cloud Router Präfixe lernen, die in das Ziel einer vorhandenen Subnetz- oder Peering-Subnetzroute passen, erstellt Google Cloud keine benutzerdefinierten dynamischen Routen für die in Konflikt stehenden Präfixe. Wenn beispielsweise eine Subnetz- oder Peering-Subnetzroute mit dem Ziel 10.70.1.0/24 vorhanden ist und Cloud Router im VPC-Netzwerk die Präfixe 10.70.1.0/25 und 10.70.1.128/25 über BGP erhalten, verwendet Google Cloud die Subnetz- oder die Peering-Subnetzroute und erstellt keine benutzerdefinierten dynamischen Routen für 10.70.1.0/25 und 10.70.1.128/25.

    • Wenn eine Subnetz- oder Peering-Subnetzroute erstellt wird, deren Zielpräfixe von Cloud Routern im VPC-Netzwerk erkannt wurden, entfernt Google Cloud die benutzerdefinierten dynamischen Routen für die in Konflikt stehenden Präfixe, um Platz für die Subnetz- oder Peering-Subnetzroute zu schaffen.

Lebenszyklus von Subnetzrouten

Subnetzrouten werden erstellt, aktualisiert und gelöscht, wenn Sie Subnetze oder deren Subnetz-IP-Adressbereiche erstellen, ändern oder löschen:

  • Wenn Sie ein Subnetz hinzufügen, erstellt Google Cloud eine entsprechende Subnetzroute für den primären IP-Adressbereich des Subnetzes.

  • VPC-Netzwerke im automatischen Modus erstellen eine Subnetzroute für die primären IP-Bereiche von jedem automatisch erstellten Subnetz. Sie können diese Subnetze nur dann löschen, wenn Sie den Modus des VPC-Netzwerks von automatisch in benutzerdefiniert ändern.

  • Sie können eine Subnetzroute nur löschen, wenn Sie das Subnetz ändern oder löschen:

    • Wenn Sie einen sekundären Bereich aus einem Subnetz entfernen, wird die Subnetzroute für diesen sekundären Bereich automatisch gelöscht.

    • Wenn Sie ein Subnetz löschen, werden alle Subnetzrouten für primäre und sekundäre Bereiche automatisch gelöscht. Sie können die Subnetzroute für den primären Bereich des Subnetzes nicht auf andere Weise löschen.

Die Anzahl von Subnetzrouten in einem VPC-Netzwerk ist beschränkt durch die maximale Anzahl von (primären und sekundären) Subnetz-IP-Bereichen.

Dynamische Routen

Cloud Router weisen das VPC-Netzwerk an, anhand der empfangenen BGP-Nachrichten (Border Gateway Protocol), der anwendbaren BGP-Routenrichtlinien (Vorschau) und der von Ihnen konfigurierten benutzerdefinierten erkannten Cloud Router-Routen dynamische Routen zu erstellen, zu aktualisieren und zu entfernen. Die Cloud Router-Steuerungsebene installiert dynamische Routen regional, basierend auf dem Modus für dynamisches Routing des VPC-Netzwerks:

  • Wenn ein VPC-Netzwerk den regionalen dynamischen Routingmodus verwendet, erstellen die Cloud Router der verschiedenen Regionen nur in der Region, in der auch der Cloud Router ist, dynamische Routen.

  • Wenn ein VPC-Netzwerk den globalen dynamischen Routingmodus verwendet, erstellen die Cloud Router der verschiedenen Regionen dynamische Routen in allen Regionen des VPC-Netzwerks.

Der nächste Hop einer dynamischen Route kann eines der folgenden Elemente sein:

Wenn ein nächster Hop für eine dynamische Route nicht mehr zugänglich ist, weist der Cloud Router, der dessen BGP-Sitzung verwaltet, das VPC-Netzwerk an, die dynamische Route zu entfernen, sobald eine der folgenden Bedingungen erfüllt ist:

  • Der Timer für den ordnungsgemäßen Neustart des Peer-Routers ist abgelaufen (falls der BGP-Peer den ordnungsgemäßen Neustart unterstützt).

  • Der Hold-Timer des Cloud Routers ist abgelaufen. Der Hold-Timer des Cloud Routers ist proportional zum konfigurierbaren Cloud Router-Keepalive-Timer.

Google Cloud löst Konflikte zwischen dynamischen Routen und lokalen und Peering-Subnetzrouten, wie unter Interaktionen mit dynamischen Routen beschrieben.

Peering-Subnetzrouten

Mit Peering-Subnetzrouten werden Pfade zu Ressourcen in Subnetzen in einem anderen VPC-Netzwerk definiert, die über VPC-Netzwerk-Peering verbunden sind. Weitere Informationen finden Sie unter Optionen für den Austausch von Subnetzrouten.

Lokale Subnetz- und Peering-Subnetzrouten dürfen sich nicht überschneiden. Weitere Informationen finden Sie unter Interaktionen mit Subnetz- und Peering-Subnetzrouten.

Die Anzahl der Subnetzrouten pro Peering-Gruppe wird durch das Kontingent der Subnetzwerkbereiche pro Netzwerk pro Peering-Gruppe gesteuert.

Peering von statischen und dynamischen Routen

Wenn Sie zwei VPC-Netzwerke über VPC-Netzwerk-Peering verbinden, können Sie statische und dynamische Routen aus einem Netzwerk exportieren und in das andere Netzwerk importieren. Weitere Informationen finden Sie unter:

Die Anzahl der statischen Routen pro Peering-Gruppe und der dynamischen Routen pro Region per Peering-Gruppe wird durch die Kontingente für statische und dynamische Routen pro Netzwerk begrenzt.

Anwendbarkeit und Reihenfolge

Anwendbare Routen

Jede Instanz hat eine Reihe von anwendbaren Routen, bei denen es sich um eine Teilmenge aller Routen im VPC-Netzwerk handelt. Anwendbare Routen sind die möglichen Pfade für ausgehenden Traffic, die ein Paket verwenden kann, wenn es von der Instanz weitergeleitet wird.

  • Spezielle Routingpfade gelten beim Routing zu Proxy-Load-Balancern, Systemdiagnosen und anderen Google-Diensten. Weitere Informationen finden Sie unter Spezielle Routingpfade. Diese Routen werden in keiner Routentabelle angezeigt.

  • Richtlinienbasierte Routen können für Pakete gelten, die von Compute Engine-VM-Instanzen oder auf von Cloud Interconnect-VLAN-Anhängen empfangenen Paketen gesendet werden. Richtlinienbasierte Routen gelten nur, wenn ein Paket die Kriterien der richtlinienbasierten Route erfüllt.

  • Lokale und Peering-Subnetzrouten gelten für alle Instanzen. Mit Ausnahme von richtlinienbasierten Routen kann kein anderer Routentyp ein Ziel haben, das mit dem Ziel einer lokalen Route oder einer Peering-Subnetzroute übereinstimmt oder in diese passt. Weitere Informationen zur Konfliktlösung zwischen Subnetz-, statischen und dynamischen Routen finden Sie unter Interaktionen zwischen Subnetz- und statischen Routen sowie Interaktionen zwischen Subnetz- und dynamischen Routen.

  • Benutzerdefinierte statische Routen gelten für alle Instanzen oder bestimmte Instanzen. Statische Routen mit einem Tag-Attribut gelten für Instanzen mit demselben Netzwerk-Tag. Wenn die Route kein Netzwerk-Tag hat, gilt sie für alle Instanzen im Netzwerk.

  • Dynamische Routen gelten für Instanzen, die auf dem Modus für dynamisches Routing des VPC-Netzwerks basieren.

Spezielle Routingpfade

VPC-Netzwerke haben spezielle Routen für bestimmte Dienste. Diese speziellen Routingpfade werden nicht in Ihrer VPC-Netzwerkroutentabelle angezeigt. Sie können keine speziellen Routingpfade entfernen. Sie können Pakete jedoch mithilfe von VPC-Firewallregeln oder Firewallrichtlinien zulassen oder ablehnen.

Pfade für externe Passthrough-Network Load Balancer und externe Protokollweiterleitung

Externe Passthrough-Network Load Balancer und externe Protokollweiterleitung verwenden Maglev-Systeme, um Pakete von Clients im Internet zu Backend-VMs und Zielinstanzen in Ihrem VPC-Netzwerk weiterzuleiten. Diese Maglev-Systeme leiten Pakete mit Zielen weiter, die mit dem Ziel der externen Weiterleitungsregel übereinstimmen.

Jede Weiterleitungsregel für einen externen Passthrough-Network-Load-Balancer oder für die externe Protokollweiterleitung stellt auch einen Routingpfad für ihre Backend-VMs oder Zielinstanzen bereit, um Pakete an Ziele außerhalb des VPC-Netzwerks zu senden:

  • Von Back-End-VMs oder Zielinstanzen gesendete Pakete können entweder ausgehende Antwortpakete (an den Client zurückgesendet) oder ausgehende Pakete sein, die eine neue Verbindung initiieren.
  • Die Paketquellen müssen mit der IP-Adresse der Weiterleitungsregel übereinstimmen. Das Paketprotokoll und der Quellport müssen nicht mit der Protokoll- und Portspezifikation der Weiterleitungsregel übereinstimmen.
  • Routingpfade von Weiterleitungsregeln hängen nicht von einer Standardroute oder der Verwendung des nächsten Hops des Standard-Internetgateways ab.
  • Für Back-End-VMs und Zielinstanzen muss die IP-Weiterleitung nicht aktiviert sein.

Pfade zwischen Google Front Ends und Back-Ends

Externe Application Load Balancer und externe Proxy-Network-Load-Balancer verwenden Google Front Ends (GFEs). GFEs der zweiten Ebene öffnen TCP-Verbindungen zu Ihren Backend-VMs und senden Pakete aus den folgenden Quellen:

  • 35.191.0.0/16
  • 130.211.0.0/22

Google Cloud verwendet Routen im Google-Netzwerk, um Pakete aus diesen Quellbereichen an Backend-VMs in Ihrem VPC-Netzwerk bereitzustellen. Jedes VPC-Netzwerk enthält Routingpfade, über die VMs Antwortpakete an 35.191.0.0/16 und 130.211.0.0/22 senden können.

Pfade für Systemdiagnosen

Systemdiagnosen für alle Load-Balancer und für die automatische Reparatur von verwalteten Instanzgruppen senden Pakete aus IP-Adressbereichen für Systemdiagnoseprüfungen an Ihre Backend-VMs.

Google Cloud verwendet Routen im Google-Netzwerk, um Pakete von Prüfsystemen der Systemdiagnose an VMs in Ihrem VPC-Netzwerk zu senden. Jedes VPC-Netzwerk enthält Routingpfade, mit denen VMs Antwortpakete an die Prüfsysteme der Systemdiagnose senden können.

Pfade für Identity-Aware Proxy (IAP)

TCP-Weiterleitung mit IAP verwendet 35.235.240.0/20 als internen Bereich mit den nächsten Hops, die sich vollständig im Google-Netzwerk befinden. Google veröffentlicht keine Routen zu 35.235.240.0/20 im Internet.

Routen im Google-Netzwerk liefern Pakete von 35.235.240.0/20 an VMs in Ihrem VPC-Netzwerk, wenn Sie die IAP-TCP-Weiterleitung verwenden. Jedes VPC-Netzwerk enthält Routingpfade, über die VMs Antwortpakete an 35.235.240.0/20 senden können.

Pfade für Cloud DNS und Service Directory

Die folgenden Cloud DNS- und Service Directory-Features verwenden 35.199.192.0/19 als rein internen Bereich mit nächsten Hops, die sich vollständig im Google-Netzwerk befinden. Google veröffentlicht keine Routen zu 35.199.192.0/19 im Internet.

Routen im Google-Netzwerk liefern Pakete von 35.199.192.0/19 an VMs in Ihrem VPC-Netzwerk, wenn Sie diese Cloud DNS- und Service Directory-Features verwenden. Jedes VPC-Netzwerk enthält Routingpfade, über die VMs Antwortpakete an 35.199.192.0/19 senden können.

Pfade für serverlosen VPC-Zugriff

Serverloser VPC-Zugriff verwendet 35.199.224.0/19 als internen Bereich mit den nächsten Hops, die sich vollständig im Google-Netzwerk befinden. Google veröffentlicht keine Routen zu 35.199.224.0/19 im Internet.

Routen im Google-Netzwerk liefern Pakete von 35.199.224.0/19 an Connector-Instanzen für serverlosen VPC-Zugriff. Jedes VPC-Netzwerk enthält Routingpfade, über die Connector-Instanzen Antwortpakete an 35.199.224.0/19 senden können.

Pfade für Private Service Connect-Endpunkte für globale Google APIs

Wenn Sie einen Private Service Connect-Endpunkt für globale Google APIs erstellen, fügt Google Cloud Ihrem VPC-Netzwerk eine Route für den Endpunkt hinzu. Das Ziel dieser Route ist die globale interne IP-Adresse des Endpunkts.

Routingreihenfolge

Im folgenden Prozess wird das Routenauswahlverhalten der VPC-Netzwerke modelliert, beginnend mit der Reihe der anwendbaren Routen, die im vorherigen Abschnitt beschrieben wurden.

  1. Spezielle Routingpfade: Einige spezielle Google Cloud-Routingpfade, die in Ihrer VPC-Netzwerkroutentabelle nicht angezeigt werden. Weitere Informationen finden Sie unter Spezielle Routingpfade.

    Wenn ein spezieller Routingpfad gilt, enthält das Routenauswahlmodell nur den speziellen Pfad. Alle anderen Routen werden ignoriert und die Bewertung wird in diesem Schritt beendet.

  2. Richtlinienbasierte Routen: Richtlinienbasierte Routen werden nach speziellen Routingpfaden aber vor anderen Routentypen ausgewertet. Wenn im VPC-Netzwerk keine richtlinienbasierten Routen vorhanden sind, überspringt Google Cloud diesen Schritt und fährt mit dem Schritt Spezifischstes Ziel fort.

  • Google Cloud wertet richtlinienbasierte Routen ausschließlich nach ihrer Priorität aus. Google Cloud wertet die Quelle und das Ziel eines Pakets für jede richtlinienbasierte Route aus, beginnend mit der richtlinienbasierten Route mit der höchsten Priorität. Wenn die Eigenschaften eines Pakets nicht mit einer richtlinienbasierten Route übereinstimmen, ignoriert Google Cloud diese richtlinienbasierte Route und wertet die nächste richtlinienbasierte Route in der sortierten Liste aus. Die nächste auszuwertende richtlinienbasierte Route hat möglicherweise dieselbe oder eine niedrigere Priorität wie die ignorierte richtlinienbasierte Route.

    • Wenn die Eigenschaften eines Pakets keiner richtlinienbasierten Route entsprechen, nachdem alle richtlinienbasierten Routen in Ihrem Routenauswahlmodell ausgewertet wurden, ignoriert Google Cloud alle richtlinienbasierten Routen und fährt mit dem Schritt Spezifischstes Ziel fort.

    • Wenn die Eigenschaften eines Pakets mit einer richtlinienbasierten Route mit der höchsten Priorität übereinstimmen, ignoriert Google Cloud zuerst alle Routen mit niedrigerer Priorität. Wenn noch zwei oder mehr richtlinienbasierte Routen in der Liste verbleiben, wertet Google Cloud jede der verbleibenden richtlinienbasierten Routen mit identischen Prioritäten aus. Alle verbleibenden richtlinienbasierten Routen werden von Google Cloud ignoriert, wenn die Eigenschaften eines Pakets nicht mit ihnen übereinstimmen. Nach diesem Schritt kann Ihr Routenauswahlmodell eine oder mehrere richtlinienbasierte Routen enthalten.

    • Wenn Ihr Routenauswahlmodell zwei oder mehr übereinstimmende Routen mit der höchsten Priorität enthält, wählt Google Cloud mithilfe eines internen Algorithmus eine einzelne richtlinienbasierte Route aus. Die ausgewählte richtlinienbasierte Route ist möglicherweise nicht die spezifischste Übereinstimmung für die Quelle oder das Ziel des Pakets. Zur Vermeidung dieser Mehrdeutigkeit empfehlen wir Ihnen, richtlinienbasierte Routen mit eindeutigen Prioritäten zu erstellen.

    • Wenn Ihr Routenauswahlmodell nur eine einzige richtlinienbasierte Route mit höchster Priorität enthält, die so konfiguriert ist, dass andere richtlinienbasierte Routen übersprungen werden, bewertet Google Cloud nicht-richtlinienbasierte Routen im Schritt Spezifischstes Ziel und ignoriert alle richtlinienbasierten Routen.

    • Wenn Ihr Routenauswahlmodell nur eine einzige richtlinienbasierte Route mit der höchsten Priorität enthält, die nicht so konfiguriert ist, dass andere richtlinienbasierte Routen übersprungen werden, übergibt Google Cloud das Paket an den internen Passthrough-Network Load Balancer des nächsten Hops und ignoriert alle nicht-richtlinienbasierten Routen.

  1. Spezifischstes Ziel: Google Cloud ermittelt, welche der anwendbaren Routen das spezifischste Ziel hat, das die Ziel-IP-Adresse des Pakets enthält. Alle anderen Routen mit weniger spezifischen Zielen werden von Google Cloud ignoriert. Beispielsweise ist 10.240.1.0/24 ein spezifischeres Ziel als 10.240.0.0/16. Das spezifischste Ziel könnte ein beliebiger Routentyp sein. Per Definition sind jedoch Subnetzrouten, Peering-Subnetzrouten und spezielle Routingpfade am spezifischsten.

    Nach diesem Schritt enthält Ihr Routenauswahlmodell keine speziellen Routingpfade oder richtlinienbasierten Routen. Sie enthält nur die Routen mit den spezifischsten Zielen.

  2. Nächste Hops in einem einzelnen VPC-Netzwerk: Dieser Schritt ist nur anwendbar, wenn das VPC-Netzwerk, dessen Routenverhalten Sie modellieren, über VPC-Netzwerk-Peering mit einem oder mehreren VPC-Netzwerken verbunden ist. Beim VPC-Netzwerk-Peering können benutzerdefinierte Routen mit identischen Zielen in mehr als einem der Netzwerke in der Peering-Gruppe vorhanden sein. Die in diesem Schritt modellierte Anforderung ist, dass Google Cloud nächste Hops auswählt, die sich alle in einem einzelnen VPC-Netzwerk befinden.

    • Wenn eine oder mehrere Routen im Routenmodell nächste Hops innerhalb des VPC-Netzwerks haben, das Sie modellieren, ignorieren Sie alle Routen, die nächste Hops in Peer-Netzwerken haben. In dieser Situation verwendet Google Cloud nur nächste Hops im lokalen VPC-Netzwerk, auch wenn nächste Hops für dasselbe Ziel in einem oder mehreren Peer-VPC-Netzwerken vorhanden sind.

    • Wenn keine der Routen in Ihrem Routenmodell nächste Hops innerhalb des VPC-Netzwerks haben, das Sie modellieren, und alle nächsten Hops in mehreren Peer-Netzwerken vorhanden sind, verwendet Google Cloud einen internen Algorithmus, um ein einzelnes Peer-Netzwerk mit den nächsten Hops für die spezifischsten Ziele auszuwählen. Die Routenpriorität wird an diesem Punkt nicht berücksichtigt. Wenn Ihr VPC-Netzwerk mit einem neuen VPC-Netzwerk verbunden wird oder die Verbindung zu einem vorhandenen Peer-VPC-Netzwerk getrennt wird, kann sich das für die nächsten Hops ausgewählte VPC-Netzwerk ändern.

    Nach diesem Schritt enthält Ihr Routenauswahlmodell nur die Routen mit den spezifischsten Zielen und die nächsten Hops für diese Routen befinden sich alle in einem einzelnen VPC-Netzwerk.

  3. Benutzerdefinierte statische Routen ignorieren, deren nächste Hops nicht aktiv sind: Mit diesem Schritt werden zwei Situationen modelliert, in denen Google Cloud nächste Hops ignoriert, die als nicht ausgeführt betrachtet werden. Dieser Schritt gilt nur für benutzerdefinierte statische Routen. Benutzerdefinierte dynamische Routen werden automatisch mit BGP-Advertising hinzugefügt und entfernt.

    • Google Cloud ignoriert jede nächste Hop-VM-Instanz (next-hop-instance oder next-hop-address), wenn die nächste Hop-VM angehalten oder gelöscht wurde. Weitere Informationen finden Sie unter Verhalten beim Anhalten oder Löschen von Instanzen im Abschnitt Überlegungen zu als nächster Hop dienenden Instanzen. Wenn Ihr Routenmodell statische Routen enthält, deren nächste Hop-VMs angehalten oder gelöscht wurden, entfernen Sie diese Routen aus Ihrem Modell.

    • Google Cloud ignoriert jede benutzerdefinierte statische Route, die einen als nächster Hop dienenden klassischen VPN-Tunnel verwendet, wenn der Tunnel keine IKE-Sicherheitsverknüpfung (SA) der Phase 1 hat. Weitere Informationen finden Sie in der Dokumentation zu klassischen VPNs unter Reihenfolge der Routen. Wenn Ihr Routenmodell statische Routen enthält, deren nächste Hops klassische VPN-Tunnel ohne eingerichtete IKE-SAs sind, entfernen Sie diese Routen aus Ihrem Modell.

  4. Routen mit niedriger Priorität ignorieren: In diesem Schritt wird modelliert, wie Google Cloud alle Routen mit Ausnahme der Routen mit der höchsten Priorität verwirft.

    Nach diesem Schritt ist Ihr Routenauswahlmodell möglicherweise leer oder enthält eine oder mehrere Routen. Wenn Ihr Modell Routen enthält, haben alle Routen alle diese Merkmale:

    • Identische, spezifischste Ziele
    • Nächste Hops in einem einzigen VPC-Netzwerk – dem lokalen VPC-Netzwerk oder einem einzelnen Peer-VPC-Netzwerk
    • Nächste Hops, die nicht bekanntermaßen ausgefallen sind
    • Identische, höchste Prioritäten

  5. Nur die bevorzugte Präferenzkategorie auswählen: Google Cloud vermeidet ECMP-Routing bei verschiedenen Typen von nächsten Hops. Sie können dieses Verhalten modellieren, indem Sie das in der folgenden Tabelle beschriebene Präferenzkategoriesystem berücksichtigen. In diesem Schritt wird Ihr Routenmodell so optimiert, dass es nur Routen enthält, die denselben Routentyp oder dieselbe Kombination von Routentyp und Typ des nächsten Hops aufweisen.

    Präferenzkategorie Kombination von Kategorie und nächstem Hop
    Erste Wahl (höchste Präferenz) Benutzerdefinierte statische Routen mit ausgeführter nächster Hop-Instanz (next-hop-instance oder next-hop-address) oder über IKE-SA eingerichteter klassischer VPN-Tunnel, der als nächster Hop dient
    Zweite Wahl Benutzerdefinierte dynamische Routen, die aus einer beliebigen BGP-Sitzung eines beliebigen Cloud Routers gelernt wurden
    Dritte Wahl Eine einzelne benutzerdefinierte statische Route mit einem als nächster Hop dienenden internen Passthrough Network Load Balancer
    Google Cloud verwendet einen internen Algorithmus, um einen einzelnen als nächster Hop dienenden internen Passthrough Network Load Balancer auszuwählen, wobei der andere als nächster Hop dienende interne Passthrough Network Load Balancer mit derselben Priorität ignoriert wird. Weitere Informationen finden Sie unter "Gleiches Ziel und mehrere als nächster Hop dienende interne Passthrough Network Load Balancer" im Abschnitt Überlegungen zu internen Network Load Balancern als nächste Hops.
    Vierte Wahl Eine benutzerdefinierte statische Route, die als nächsten Hop default-internet-gateway verwendet

    Am Ende dieses Schritts können null Routen, eine Route oder zwei oder mehr Routen im Routenmodell vorhanden sein.

  6. Paket senden oder verwerfen: Was geschieht, hängt von der Anzahl der verbleibenden Routen im Routenmodell ab:

    • Wenn das Routenmodell leer ist, wird das Paket mit einem Fehler verworfen, der durch das ICMP-Ziel oder ein nicht erreichbares Netzwerk verursacht wird. Google Cloud greift nie auf eine weniger spezifische Route zurück, die möglicherweise einen funktionierenden nächsten Hop hat.

    • Wenn das Routenmodell eine einzelne Route enthält, sendet Google Cloud das Paket an den nächsten Hop. Bei als nächster Hop dienenden VMs prüft Google Cloud nicht, ob die nächste Hop-VM Pakete verarbeiten kann. Weitere Informationen finden Sie unter Überlegungen zu Instanzen und internen Passthrough Network Load Balancern, die als nächste Hops dienen. Wenn die einzelne Route eine Subnetzroute oder eine Peering-Subnetzroute ist und keine Google Cloud-Ressource an der Ziel-IP-Adresse des Pakets vorhanden ist, wird das Paket verworfen.

    • Wenn das Routenmodell zwei oder mehr Routen enthält, haben die Routen dasselbe, spezifischste Ziel, befinden sich in einem einzelnen VPC-Netzwerk, haben nächste Hops, die nicht bekanntermaßen ausgefallen sind, haben dieselbe höchste Priorität und gehören zur selben Kombination aus Routentyp und nächstem Hop (Präferenzkategorie). Google Cloud verteilt Pakete auf die nächsten Hops, wobei mithilfe eines Hash-Algorithmus Equal Cost Multipath (ECMP) implementiert wird. Hash-Berechnungen werden für jedes Paket zur Zeit der Übertragung durchgeführt, basierend auf der aktuellen Anzahl der nächsten Hops. Google Cloud verwendet einen 5-Tupel-Hash, wenn das Paket Portinformationen enthält. Andernfalls wird ein 3-Tupel-Hash verwendet. Wenn sich das Routenmodell beim Senden nachfolgender Pakete ändert, leitet Google Cloud diese Pakete möglicherweise an einen anderen nächsten Hop weiter, auch wenn der Hash identisch ist.

Statische Routen

Sie können statische Routen auf zwei Weisen erstellen:

Sie können statische Routen mit einem Peering-VPC-Netzwerk austauschen, wie in der Dokumentation zum VPC-Netzwerk-Peering 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.

  • Nächster 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 Nächste Hops und Features.

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

Nächste Hops und Features

In der folgenden Tabelle wird die Unterstützung statischer Routenfeatures nach Typ des nächsten Hops zusammengefasst:

Nächster Hop-Typ IPv4 IPv6 ECMP1
Nächstes Hop-Gateway (next-hop-gateway)
Geben Sie ein Standard-Internetgateway an, 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 und Region (next-hop-ilb)
Pakete an Back-Ends eines internen Passthrough-Netzwerk-Load-Balancers senden, die durch Name und Region der Weiterleitungsregel identifiziert werden. Weitere Informationen finden Sie unter Überlegungen zu internen Passthrough Network Load Balancern, die als nächster Hop dienen.
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.
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.

Projekt und Netzwerk für den nächsten Hop

Eine statische Route als nächster Hop ist sowohl einem VPC-Netzwerk als auch einem Projekt zugeordnet:

  • 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 nächste Hops können sich in freigegebenen VPC-Dienstprojekten befinden.

Nächster Hop-Typ Kann sich in einem Peering-VPC-Netzwerk befinden Kann sich in einem freigegebenen VPC-Dienstprojekt befinden
Nächstes Hop-Gateway (next-hop-gateway)
Nächste Hop-Instanz nach Name (next-hop-instance)
Nächste 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.

  • Backend-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 der Region zugegriffen werden kann, in der sich die das Paket sendende VM befindet:

    • 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 (kein Peering-VPC-Netzwerk).

    Solange eine statische Route vorhanden ist, deren nächster Hop durch Instanznamen und Zone angegeben ist, gilt Folgendes:

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

    • Die primäre interne IPv4-Adresse der nächsten Hop-Instanz ändert sich 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 Zuweisung der IPv4- oder IPv6-Adresse der Instanz aufgehoben wird

  • IP-Adresse der nächsten Hop-Instanz (next-hop-address): Wenn Sie eine statische Route erstellen, deren nächste Hop-Instanz durch eine IP-Adresse angegeben ist, können Sie eine der folgenden Optionen eingeben:

    • Die primäre interne IPv4-Adresse der Instanz.
    • Eine interne oder externe IPv6-Adresse aus dem IPv6-Adressbereich /96, der der Netzwerkschnittstelle einer Dual-Stack-VM-Instanz zugewiesen ist (Vorschau). Wenn Sie eine interne IPv6-Adresse eingeben, empfiehlt Google, die erste Adresse (/128) aus dem internen IPv6-Adressbereich der NIC /96 zu verwenden.

    Google Cloud prüft, ob die IP-Adresse der nächsten Hop-VM in einen Subnetzbereich eines Subnetzes im VPC-Netzwerk der Route passt. Google Cloud programmiert die Route jedoch nur, wenn die Adresse des nächsten Hops eine der folgenden ist:

    • Eine primäre interne IPv4-Adresse, die der NIC einer VM im selben VPC-Netzwerk wie die Route zugewiesen ist (kein Peering-VPC-Netzwerk)
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96, die der NIC einer Dual-Stack-VM im selben VPC-Netzwerk wie die Route zugewiesen ist (kein Peering-VPC-Netzwerk)

    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 Ersatz-VM dieselben Anforderungen erfüllt.

  • 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 möchten, dass dieselbe VM Pakete für eine bestimmte Verbindung in beide Richtungen verarbeitet, benötigen Sie symmetrisches Hashing. Dieses wird nur durch interne, als nächste Hops dienende Passthrough Load Balancer unterstützt. Weitere Informationen zum symmetrischen Hashing finden Sie in der Dokumentation zum symmetrischen Hashing in den als nächste Hops dienenden internen Passthrough Network Load Balancern.

  • Verhalten beim Anhalten oder Löschen von Instanzen: Google Cloud verhindert nicht, dass Sie eine statische Route als nächsten Hop dienende VM anhalten oder löschen (angegeben durch Name und Zone oder interne Adresse). Ist eine als nächster Hop dienende VM nicht aktiv, so hängt das Routing für das Ziel 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 zur Veranschaulichung dieses Verhaltens:

    • Pakete, deren Ziele in 192.168.168.0/24 passen, werden in folgender Situation an den nächsten Hop von route-vm-b gesendet, wenn der nächste Hop für die Route mit der höchsten Priorität nicht aktiv ist. Dieses Routing tritt auf, weil Google Cloud nächste Hops ignoriert, die nicht aktiv sind, bevor der Schritt Routen mit niedriger Priorität ignoriert der Routingreihenfolge berücksichtigt wird:
    • route-vm-a, Ziel 192.168.168.0/24, Priorität 10, VM des nächsten Hops ist angehalten
    • route-vm-b, Ziel 192.168.168.0/24, Priorität 20, VM des nächsten Hops ist aktiv

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

    • Pakete, deren Ziele in 192.168.168.0/24 passen, werden in diesem nächsten Beispiel gelöscht, in dem keine als nächsten Hops dienenden VMs für die 192.168.168.0/24-Routen aktiv sind, obwohl eine Route für den breiteren 192.168.0.0/16 einen als nächster Hop dienende VM aufweist, die ausgeführt wird. Die Pakete werden verworfen, da Google Cloud Routen mit breiteren Zielbereichen (kürzerer Subnetzmaskenlänge) im Schritt spezifischstes Ziel ignoriert, der vor dem Schritt Benutzerdefinierte statische Routen ignorieren, deren nächste Hops nicht aktiv sind der Routingreihenfolge erfolgt:

    • route-vm-x, Ziel 192.168.168.0/24, Priorität 10, VM des nächsten Hops ist angehalten

    • route-vm-y, Ziel 192.168.168.0/24, Priorität 20, VM des nächsten Hops ist angehalten

    • route-vm-z, Ziel 192.168.0.0/16, Priorität 0, VM des nächsten Hops ist aktiv

Ü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:

    • 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 eine die IPv4-Adresse einer Weiterleitungsregel: Wenn Sie eine Weiterleitungsregel für den nächsten Hop anhand seiner IPv4-Adresse 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 freigegebenes VPC-Hostprojekt) oder in einem freigegebenen 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 für den nächsten 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. Zur Vermeidung dieser Mehrdeutigkeit 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 für den nächsten 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 klassischen 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