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

Eine Standardroute hat das breitestmögliche Ziel: 0.0.0.0/0 für IPv4 und ::/0 für IPv6. Google Cloud verwendet eine Standardroute nur, um ein Paket zuzustellen, wenn das Paket nicht mit einer spezifischeren Route in der Routingreihenfolge übereinstimmt.

Das Fehlen einer Standardroute führt nicht unbedingt dazu, dass Ihr Netzwerk vom Internet getrennt wird, da spezielle Routingpfade für externe Passthrough-Network Load Balancer und externe Protokollweiterleitung nicht von einer Standardroute abhängen.

Wenn Sie ein VPC-Netzwerk erstellen, fügt Google Cloud dem VPC-Netzwerk eine vom System generierte Standardroute (IPv4) hinzu. Die vom System generierte IPv4-Standardroute ist eine lokale statische Route mit dem Ziel 0.0.0.0/0 und dem nächsten Hop „Standard-Internetgateway“. Eine lokale statische Route mit dem Ziel 0.0.0.0/0 und dem nächsten Hop „Standard-Internetgateway“ bietet einen Pfad zu externen IPv4-Adressen, einschließlich IPv4-Adressen im Internet. In den folgenden Beispielressourcen wird dieser Pfad verwendet:

  • VMs mit externen IPv4-Adressen, die ihren Netzwerkschnittstellen zugewiesen sind, wenn die von ihnen gesendeten Pakete Quellen haben, die mit der primären internen IPv4-Adresse der Netzwerkschnittstelle übereinstimmen.
  • Ein öffentliches Cloud NAT-Gateway, das NAT-Dienste für Subnetze bereitstellt, die von VM-Netzwerkschnittstellen verwendet werden. Je nachdem, für welche IPv4-Adressbereiche des Subnetzes das Cloud NAT-Gateway konfiguriert ist, können Paketquellen mit einer der folgenden Optionen übereinstimmen:
    • Eine interne IPv4-Adresse aus einem Alias-IP-Adressbereich der Netzwerkschnittstelle der VM (unabhängig davon, ob der Netzwerkschnittstelle eine externe IPv4-Adresse zugewiesen ist) oder
    • Die primäre interne IPv4-Adresse der Netzwerkschnittstelle der VM, sofern der Netzwerkschnittstelle keine externe IPv4-Adresse zugewiesen ist.

Wenn Sie ein Subnetz mit einem externen IPv6-Adressbereich erstellen, fügt Google Cloud dem VPC-Netzwerk eine vom System generierte IPv6-Standardroute hinzu, falls noch keine vorhanden ist. Die vom System generierte IPv6-Standardroute ist eine lokale statische Route mit dem Ziel ::/0 und dem nächsten Hop „Standard-Internetgateway“. Eine lokale statische Route mit dem Ziel ::/0 und dem nächsten Hop „Standard-Internetgateway“ bietet einen Pfad zu externen IPv6-Adressen, einschließlich IPv6-Adressen im Internet. Dieser Pfad kann für Folgendes verwendet werden:

  • VMs mit /96 externen IPv6-Adressbereichen, die ihren Netzwerkschnittstellen zugewiesen sind, wenn die von ihnen gesendeten Pakete Quellen in diesem /96-Adressbereich haben.

Der Zugriff auf globale Google APIs hängt manchmal von einer lokalen IPv4- oder IPv6-Standardroute mit dem nächsten Hop des Standard-Internetgateways ab:

  • Wenn Sie über das Senden von Paketen an einen Private Service Connect-Endpunkt für globale Google APIs auf globale Google APIs und ‑Dienste zugreifen, ist für Ihr VPC-Netzwerk keine Standardroute mit dem Standard-Internetgateway als nächstem Hop erforderlich. Google Cloud fügt dem Endpunkt einen besonderen Routingpfad hinzu.

  • Wenn Sie über das Senden von Paketen an IPv4- oder IPv6-Adressen für die Standarddomains, die IPv4- oder IPv6-Adressen für private.googleapis.com oder die IPv4- oder IPv6-Adressen für restricted.googleapis.com auf globale Google APIs und ‑Dienste zugreifen, können Sie entweder Standard-IPv4- und ‑IPv6-Routen mit Standard-Internetgateway als nächster Hop verwenden oder IPv4- und IPv6-statische Routen mit spezifischeren Zielen und Standard-Internetgateway als nächster Hop erstellen und verwenden:

    • Wenn Ihre VMs nur interne IP-Adressen haben, lesen Sie den Hilfeartikel Routingoptionen für den privaten Google-Zugriff.
    • Wenn Ihre VMs externe IP-Adressen haben, lesen Sie den Hilfeartikel Routingoptionen.

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.

Ein VPC-Netzwerk kann die folgenden Arten von Subnetzrouten enthalten:

  • Subnetzrouten für Subnetze im selben VPC-Netzwerk, auch lokale Subnetzrouten genannt.
  • Peering-Subnetzrouten, die aus Netzwerken importiert werden, die über VPC-Netzwerk-Peering verbunden sind.
  • Network Connectivity Center-Subnetzrouten, die aus VPC-Spokes eines Network Connectivity Center-Hubs importiert werden.

Interaktionen mit statischen Routen

In Google Cloud gelten die folgenden Regeln für lokale Subnetzrouten, Peering-Subnetzrouten und Network Connectivity Center-Subnetzrouten, es sei denn, das entsprechende Subnetz wurde als Hybrid-Subnetz konfiguriert.

  • In Google Cloud können Sie keine neue statische Route erstellen, wenn das Ziel der neuen statischen Route genau mit dem Ziel einer vorhandenen lokalen, Peering- oder Network Connectivity Center-Subnetzroute übereinstimmt oder in diese passt. Beispiel:

    • Wenn eine lokale, Peering- oder Network Connectivity Center-Subnetzroute mit dem Ziel 10.70.1.0/24 vorhanden ist, können Sie keine neue statische Route für 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 oder ein anderes Ziel erstellen, das in 10.70.1.0/24 passt.

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

  • In Google Cloud können Sie keine Änderungen an Subnetzen vornehmen, die zu einem Subnetz-IP-Adressbereich führen, der genau mit dem Ziel einer vorhandenen lokalen oder Peering-statischen Route übereinstimmt oder diese enthält. Beispiel:

    • Wenn Ihr VPC-Netzwerk eine statische Route mit dem Ziel 10.70.1.128/25 hat, können Sie kein neues Subnetz mit einem primären oder sekundären IPv4-Adressbereich von 10.70.1.128/25, 10.70.1.0/24 oder einem anderen IP-Adressbereich erstellen, der alle IPv4-Adressen in 10.70.1.128/25 enthält.

    • Wenn Ihr VPC-Netzwerk eine statische Route mit dem Ziel 2001:db8:a0b:c0d:e0f:f0e::/96 hat, untersagt Google Cloud die Erstellung einer neuen lokalen oder Peering-Subnetzroute mit einem IPv6-Adressbereich von 2001:db8:a0b:c0d::/64 oder einem anderen Bereich, der alle IPv6-Adressen in 2001:db8:a0b:c0d:e0f:f0e::/96 enthält.

Interaktionen mit dynamischen Routen

Für Google Cloud gelten die folgenden Regeln, es sei denn, ein Subnetz wurde als Hybrid-Subnetz konfiguriert.

  • Google Cloud erstellt keine dynamische Route für ein Präfix, das von einer BGP-Sitzung eines Cloud Routers erlernt wurde, wenn das Präfix genau mit dem Ziel einer vorhandenen lokalen, Peering- oder Network Connectivity Center-Subnetzroute übereinstimmt oder in dieses Ziel passt. Beispiel:

    • Wenn eine lokale, Peering- oder Subnetzroute des Network Connectivity Centers mit dem Ziel 10.70.1.0/24 vorhanden ist und ein Cloud Router im VPC-Netzwerk oder in einem Peering-VPC-Netzwerk 10.70.1.128/25, 10.70.1.0/24 oder ein anderes Präfix empfängt, das in 10.70.1.0/24 passt, erstellt Google Cloud keine lokalen oder Peering-dynamischen Routen für die empfangenen in Konflikt stehenden Präfixe.

    • Wenn eine lokale, Peering- oder Subnetzroute des Network Connectivity Centers mit dem Ziel 2001:0db8:0a0b:0c0d::/64 vorhanden ist und ein Cloud Router im VPC-Netzwerk oder in einem Peering-VPC-Netzwerk 2001:0db8:0a0b:0c0d::/96, 2001:0db8:0a0b:0c0d::/64 oder ein anderes Präfix empfängt, das in 2001:0db8:0a0b:0c0d::/64 passt, erstellt Google Cloud keine lokalen oder Peering-dynamischen Routen für die empfangenen in Konflikt stehenden Präfixe.

  • Google Cloud entfernt alle vorhandenen lokalen oder Peering-dynamischen Routen, wenn eine Änderung an Subnetzen zur Erstellung einer neuen lokalen, Peering- oder Network Connectivity Center-Subnetzroute führt, deren Ziel genau mit dem Ziel der vorhandenen lokalen oder Peering-dynamischen Route übereinstimmt oder diese enthält. Beispiel:

    • Wenn Ihr VPC-Netzwerk eine lokale oder Peering-dynamische Route mit dem Ziel 10.70.1.128/25 hat, entfernt Google Cloud die dynamische Route, wenn eine neue lokale, Peering- oder Subnetzroute des Network Connectivity Centers für 10.70.1.128/25, 10.70.1.0/24 oder einen anderen IP-Adressbereich erstellt wird, der alle IPv4-Adressen in 10.70.1.128/25 enthält.

    • Wenn Ihr VPC-Netzwerk eine lokale oder Peering-dynamische Route mit dem Ziel 2001:db8:a0b:c0d::/96 hat, entfernt Google Cloud die dynamische Route, wenn eine neue lokale, Peering- oder Subnetzroute des Network Connectivity Centers für 2001:db8:a0b:c0d::/64 erstellt wird.

Lebenszyklus von Subnetzrouten

Alle IP-Adressbereiche, die zu einem Subnetz gehören – primäre IPv4-Adressbereiche, sekundäre IPv4-Adressbereiche und IPv6-Adressbereiche – haben eine entsprechende Subnetzroute. In den folgenden Fällen werden Subnetzrouten in Google Cloud erstellt und gelöscht:

  • Sie nehmen eine Änderung an der Subnetzkonfiguration vor, z. B.:

    • Fügen Sie ein Subnetz hinzu oder löschen Sie es.
    • Primären IPv4-Bereich erweitern
    • Fügen Sie einen sekundären IPv4-Bereich hinzu oder löschen Sie ihn.
    • Fügen Sie einen IPv6-Bereich hinzu oder löschen Sie ihn.

  • Google Cloud fügt eine neue Region hinzu, wodurch automatisch ein neues Subnetz zu VPC-Netzwerken im automatischen Modus hinzugefügt wird. Informationen zu den IPv4-Adressbereichen für jedes Subnetz nach Region finden Sie unter IPv4-Bereiche im automatischen Modus.

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, jeder Cloud VPN-Tunnel und jeder VLAN-Anhang hat eine Reihe von anwendbaren Routen, also Routen, die für diese bestimmte Ressource gelten. Anwendbare Routen sind eine Teilmenge aller Routen im VPC-Netzwerk.

Die folgenden Routentypen gelten immer für alle VM-Instanzen, Cloud Interconnect-VLAN-Anhänge und Cloud VPN-Tunnel:

Die folgenden Routentypen können so konfiguriert werden, dass sie nur auf bestimmte VM-Instanzen, VLAN-Anhänge oder Cloud VPN-Tunnel angewendet werden:

  • Richtlinienbasierte Routen können für Folgendes gelten:

    • Alle VM-Instanzen, VLAN-Anhänge und VPN-Tunnel
    • Nur VM-Instanzen, die durch ein Netzwerktag identifiziert werden
    • Nur VLAN-Anhänge in einer bestimmten Region

  • Statische Routen können für Folgendes gelten:

    • Alle VM-Instanzen, VLAN-Anhänge und Cloud VPN-Tunnel
    • Nur VM-Instanzen, die durch ein Netzwerk-Tag gekennzeichnet sind

  • Dynamische Routen können je nach dem Modus für dynamisches Routing des VPC-Netzwerks entweder für VM-Instanzen, VLAN-Anhänge und Cloud VPN-Tunnel in der Region mit dem nächsten Hop der dynamischen Route oder für alle Regionen gelten.

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, 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. Paketprotokoll und Quellport müssen nicht mit der Protokoll- und Portspezifikation der Weiterleitungsregel übereinstimmen.
  • Routingpfade von Weiterleitungsregeln sind nicht von einer Standardroute oder der Verwendung des nächsten Hops des Standard-Internetgateways abhängig.
  • 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)

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

Wenn Sie die IAP-TCP-Weiterleitung verwenden, werden Pakete von 35.235.240.0/20 über Routen im Google-Netzwerk an VMs in Ihrem VPC-Netzwerk weitergeleitet. 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 im Internet keine Routen zu 35.199.192.0/19.

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

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

Über Routen im Google-Netzwerk werden Pakete von 35.199.224.0/19 an Connector-Instanzen für den serverlosen VPC-Zugriff gesendet. 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 Subnetzrouten 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 Subnetzrouten 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 der höchsten Priorität enthält, die so konfiguriert ist, dass andere richtlinienbasierte Routen übersprungen werden, ignoriert Google Cloud alle richtlinienbasierten Routen und fährt mit dem Schritt Subnetzrouten fort.

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

  3. Subnetzrouten: Google Cloud bestimmt, ob das Ziel des Pakets in den Zielbereich einer lokalen, Peering- oder Network Connectivity Center-Subnetzroute im VPC-Netzwerk fällt.

    • Wenn das Ziel eines Pakets nicht mit dem Zielbereich einer lokalen, Peering- oder Subnetzroute des Network Connectivity Centers übereinstimmt, ignoriert Google Cloud alle Subnetzrouten und fährt mit dem Schritt Spezifischstes Ziel fort.

    • Wenn das Ziel eines Pakets mit dem Zielbereich einer lokalen, Peering- oder Network Connectivity Center-Subnetzroute im VPC-Netzwerk übereinstimmt, hängt das Verhalten davon ab, ob das Subnetz als Hybrid-Subnetz konfiguriert wurde:

      • Für die meisten Subnetze verwendet Google Cloud ausschließlich die Subnetz-Route und versucht, das Paket an eine Ressource im Subnetz zu senden, z. B. an eine VM-Netzwerkschnittstelle oder eine interne Weiterleitungsregel. Alle anderen Routen werden ignoriert und die Bewertung wird in diesem Schritt beendet. Wenn keine Ressource mit dem Ziel des Pakets vorhanden ist oder die Ressource eine angehaltene VM-Instanz ist, wird das Paket verworfen.

      • Wenn die übereinstimmende Subnetzroute jedoch aus einem Hybridsubnetz stammt, versucht Google Cloud, eine übereinstimmende Zielressource im Subnetz zu finden, z. B. eine VM-Netzwerkschnittstelle oder eine interne Weiterleitungsregel:

        • Wenn sich eine Ressource im Subnetz befindet, verwendet Google Cloud ausschließlich die Subnetzroute und versucht, das Paket an die Ressource zu senden. Alle anderen Routen werden ignoriert und die Bewertung wird in diesem Schritt beendet. Wenn am Ziel des Pakets keine Ressource vorhanden ist, wird das Paket verworfen. Wenn die Ressource eine VM ist, die nicht ausgeführt wird, wird das Paket ebenfalls verworfen.

        • Wenn eine Ressource nicht im Subnetz vorhanden ist, ignoriert Google Cloud alle Subnetzrouten, einschließlich der übereinstimmenden Subnetzroute, und fährt mit dem Schritt Spezifischstes Ziel fort.

  4. Spezifischstes Ziel: Zu Beginn dieses Schritts enthält Ihr Routenauswahlmodell keine speziellen Routingpfade, keine richtlinienbasierten Routen und keine lokalen, Peering- oder Network Connectivity Center-Subnetzrouten.

    Google Cloud ermittelt, welche der verbleibenden 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.

    Am Ende dieses Schritts enthält Ihr Routenauswahlmodell nur die spezifischsten benutzerdefinierten Routen.

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

  6. Statische und dynamische Routen mit nicht verwendbaren nächsten Hops ignorieren: Mit diesem Schritt werden Situationen modelliert, in denen Google Cloud nächste Hops ignoriert, die ausgefallen oder ungültig sind.

    • Ungültige Angabe der IP-Adresse der nächsten Hop-VM: IP-Adressen, die mit next-hop-address angegeben werden, müssen in einem VPC-Netzwerk wie die Route auf eine der folgenden Konfigurationen aufgelöst werden:

      • Eine primäre interne IPv4-Adresse der Netzwerkschnittstelle einer VM
      • Eine interne oder externe IPv6-Adresse der Netzwerkschnittstelle einer VM

    • Nächster Hop ist keine VM: Google Cloud ignoriert jede lokale oder Peering-statische Route, deren nächste Hop-VM-Instanz angehalten oder gelöscht wurde. Dieses Verhalten gilt für Routen, die mit next-hop-instance oder next-hop-address konfiguriert sind. Weitere Informationen finden Sie unter Verhalten beim Anhalten oder Löschen von Instanzen im Abschnitt Überlegungen zu als nächster Hop dienenden Instanzen.

    • Ungültige Angabe der IP-Adresse des nächsten Hops eines internen Passthrough-Network Load Balancers: Wenn eine lokale oder Peering-statische Route einen Load Balancer als nächsten Hop anhand der IP-Adresse hat, muss die IP-Adresse des nächsten Hops auf eine Weiterleitungsregel für einen internen Passthrough-Network Load Balancer im VPC-Netzwerk der Route oder in einem Peering-VPC-Netzwerk verweisen. Wenn die IP-Adresse des nächsten Hops in eine Weiterleitungsregel für einen anderen Load Balancer-Typ aufgelöst wird oder gar nicht in eine Weiterleitungsregel aufgelöst wird, wird die Route von Google Cloud ignoriert.

    • Nächster Hop: Interner Passthrough-Network Load Balancer nicht erreichbar: Wenn eine lokale oder Peering-statische Route einen Load Balancer als nächsten Hop hat und sich die Google Cloud-Ressource, die das Paket sendet, in einer anderen Region als die des Load Balancers befindet, wird die Route von Google Cloud ignoriert, wenn für die Weiterleitungsregel kein globaler Zugriff aktiviert ist. Die Route wird verworfen, unabhängig davon, ob der nächste Hop durch einen Namen oder eine IP-Adresse angegeben ist.

    • Nicht eingerichteter klassischer VPN-Tunnel als nächster Hop: Google Cloud ignoriert jede lokale oder Peering-statische Route, deren klassischer VPN-Tunnel als nächster Hop keine aktive IKE-Sicherheitsverknüpfung (SA) der Phase 1 hat. Weitere Informationen finden Sie in der Dokumentation zu klassischen VPNs unter Reihenfolge der Routen.

    • Dynamische Route mit nicht funktionsfähigem nächsten Hop: Noch bevor die BGP-Sitzung, die für die Programmierung einer lokalen oder Peering-dynamischen Route verantwortlich ist, ausfällt, ignoriert Google Cloud einen Cloud VPN-Tunnel, einen Cloud Interconnect-VLAN-Anhang oder eine Router-Appliance-VM als nächsten Hop, wenn der nächste Hop nicht funktioniert. Diese Situation tritt in der Regel nur für wenige Sekunden auf, bevor die dynamische Route entfernt wird, wenn die entsprechende BGP-Sitzung des Cloud Routers ausfällt.

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

  8. 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) Lokale oder Peering-statische Routen mit nächsten Hop-Instanzen (next-hop-instance oder next-hop-address) oder klassischen VPN-Tunneln als nächster Hop
    Zweite Wahl Lokale oder Peering-dynamische Routen
    Dritte Wahl

    Lokale oder Peering-statische Routen mit dem internen Passthrough-Network Load Balancer als nächstem Hop (unabhängig davon, wie der nächste Hop angegeben ist)

    In Google Cloud wird kein Load Balancing zwischen mehreren statischen Routen mit unterschiedlichen internen Passthrough Network Load Balancern als nächste Hops durchgeführt. Weitere Informationen finden Sie unter Überlegungen zu internen Passthrough Network Load Balancern, die als nächster Hop dienen.
    Vierte Wahl Lokale statische Routen mit dem nächsten Hop default-internet-gateway

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

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

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

Nächste Schritte