Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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		 Gilt für das gesamte VPC-Netzwerk

Wird von Google Cloud automatisch erstellt, aktualisiert und entfernt, wenn Sie ein Subnetz oder einen sekundären IP-Adressbereich eines Subnetzes erstellen, ändern oder löschen.
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 von Cloud Routern in Ihrem VPC-Netzwerk automatisch hinzugefügt und entfernt.

Routen gelten für VMs entsprechend dem dynamischen Routingmodus des VPC-Netzwerks.
Peering-Routen
Peering-Subnetzroute
Steht für den Subnetz-IP-Adressbereich in einem Netzwerk, das über VPC-Netzwerk-Peering verbunden ist		 Peer-VPC-Netzwerk
Leitet Pakete an VMs und interne Load-Balancer im Peer-Netzwerk weiter		 Gilt für das gesamte VPC-Netzwerk

Wird von Google Cloud automatisch erstellt, aktualisiert und entfernt, wenn Sie Subnetze im Peer-Netzwerk erstellt, geändert oder gelöscht werden
Benutzerdefinierte Peering-Route
Benutzerdefinierte statische oder benutzerdefinierte dynamische Route in einem Netzwerk, das über VPC-Netzwerk-Peering verbunden ist		 Nächster Hop im Peer-VPC-Netzwerk Benutzerdefinierte Peering-Routen, die von statischen Routen im Peer-Netzwerk unterstützt werden, gelten so:
  • Statische Routen in einem Peer-Netzwerk, die Netzwerk-Tags verwenden, werden niemals als benutzerdefinierte Peering-Routen importiert.
  • Statische Routen in einem Peer-Netzwerk, die das als nächster Hop dienende Standard-Internetgateways verwenden, werden nie als benutzerdefinierte Peering-Routen importiert.
  • Statische Routen in einem Peer-Netzwerk, die als nächster Hop dienende interne TCP/UDP-Load-Balancer verwenden, können auf nur eine Region oder auf alle Regionen angewendet werden, je nachdem, ob der globale Zugriff aktiviert ist. Weitere Informationen finden Sie unter Überlegungen zu internen TCP/UDP-Load-Balancern, die als nächster Hop dienen.
Die benutzerdefinierten Peering-Routen, die von dynamischen Routen im Peer-Netzwerk unterstützt werden, gelten entsprechend dem Modus für dynamisches Routing des VPC-Netzwerks, in dem die Routen importiert werden.
Richtlinienbasierte Routen
Richtlinienbasierte Route
Ordnet Traffic anhand einer Kombination aus Protokoll, Quell-IP-Bereich und Ziel-IP-Bereich zu. 		Interner TCP/UDP-Load-Balancer

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

Richtlinienbasierte Routen werden nicht ü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 eine entsprechende Subnetzroute für den IPv6-Adressbereich. 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 benutzerdefinierten 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. Wenn beispielsweise 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.

  • 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). Wenn Ihr VPC-Netzwerk beispielsweise eine benutzerdefinierte statische Route für das Ziel 10.70.1.128/25 hat, verhindert Google Cloud das Erstellen einer beliebigen Subnetz- oder Peering-Subnetzroute mit einem primären oder sekundären Subnetz-IP-Adressbereich, der 10.70.1.128/25, 10.70.1.0/24 oder einem anderen Bereich entspricht, der alle IP-Adressen in 10.70.1.128/25 enthält.

Interaktionen mit benutzerdefinierten dynamischen Routen

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

  • Wenn Cloud Router ein Präfix lernen, das genau mit dem Ziel einer vorhandenen Subnetz- oder Peering-Subnetzroute übereinstimmt, erstellt Google Cloud keine benutzerdefinierte dynamische Route für das in Konflikt stehende 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 Präfix 10.70.1.0/24 über BGP erhalten, verwendet Google Cloud das Subnetz oder Peering-Subnetzroute und erstellt keine benutzerdefinierte dynamische Route 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.

Statische Routen

Statische Routen werden mit Parametern für statische Routen definiert und unterstützen statische Routen mit nächstem Hop. Sie können statische Routen auf zwei Weisen erstellen:

Dynamische Routen

Dynamische Routen werden von Cloud Routern im VPC-Netzwerk verwaltet. Die Ziele stellen immer IP-Adressbereiche außerhalb Ihres VPC-Netzwerks dar, die von einem BGP-Peer empfangen wurden. Dynamische Routen werden verwendet von:

VPC-Netzwerke ignorieren alle Ziele, die Cloud Router erhalten, wenn die Ziele eines der folgenden Kriterien erfüllen:

  • Das Ziel stimmt genau mit einem Subnetz-IP-Adressbereich überein.

  • Das Ziel passt in einen Subnetz-IP-Adressbereich (hat also eine längere Subnetzmaske als dieser).

Das Ziel einer dynamischen Route kann jedoch den IP-Bereich eines Subnetzes enthalten (und eine kleinere Subnetzmaske als dieses haben). Wenn Sie beispielsweise einen Subnetz-IP-Bereich von 10.10.10.0/24 haben, können Sie eine dynamische Route mit dem Ziel 10.10.10.0/23 haben. Wenn die Ziel-IP-Adresse eines Pakets nicht im Ziel der Subnetzroute enthalten ist, wird das Paket an den nächsten Hop der dynamischen Route gesendet. Das breitestmögliche Ziel ist 0.0.0.0/0.

Peering-Subnetzrouten

Mit Peering-Subnetzrouten werden Pfade zu Ressourcen definiert. Dabei werden Subnetze in einem anderen VPC-Netzwerk verwendet, dessen Verbindung per VPC-Netzwerk-Peering hergestellt wurde. Das andere Netzwerk wird als Peer-VPC-Netzwerk bezeichnet.

Peer-Netzwerke teilen Subnetzrouten so:

  • Peer-Netzwerke exportieren ihre Subnetzrouten immer für alle primären und sekundären IP-Adressbereiche.

  • Peer-Netzwerke importieren Subnetzrouten automatisch, solange das Ziel der Route (Subnetz-IP-Adressbereich) keine privat verwendete öffentliche IP-Adresse ist. Sie können einen Peer konfigurieren, um die Subnetzrouten zu importieren, die privat verwendete öffentliche IP-Adressen verwenden.

  • Importierte Peering-Subnetzrouten können nur entfernt werden, wenn Sie das Peering deaktivieren. Dann werden alle importierten Peering-Subnetzrouten automatisch entfernt.

  • Google Cloud verhindert Konflikte in Subnetz-IP-Adressbereichen zwischen Peer-Netzwerken.

Die Gesamtzahl von Subnetzrouten in einem VPC-Netzwerk und Peering-Subnetzrouten, die aus allen Peer-Netzwerken importiert wurden, ist beschränkt durch die maximale Anzahl von (primären und sekundären) Subnetz-IP-Bereichen.

Benutzerdefinierte Peering-Routen

Sie können Peer-Netzwerke so konfigurieren, dass benutzerdefinierte Routen exportiert oder importiert werden. In diesem Kontext sind benutzerdefinierte Routen sowohl statische als auch dynamische Routen in einem VPC-Netzwerk.

Auch wenn ein VPC-Netzwerk für den Export seiner benutzerdefinierten Routen konfiguriert ist, werden folgende Routentypen ausgeschlossen:

Die Gesamtzahl von statischen und dynamischen Routen in einem VPC-Netzwerk sowie von benutzerdefinierten Peering-Routen, die aus allen Peer-Netzwerken importiert wurden, ist beschränkt durch:

  • Maximale Anzahl der statischen Routen in einer Peering-Gruppe
  • Maximale Anzahl der dynamischen Routen in einer Peering-Gruppe

Richtlinienbasierte Routen

Mit richtlinienbasierten Routen können Sie Pakete an einen internen TCP/UDP-Load-Balancer als nächsten Hop weiterleiten. Sie können den Traffic, auf den die Route angewendet wird, anhand von Kriterien wie der Quell-IP-Adresse, der Ziel-IP-Adresse oder dem Protokoll eines Pakets auswählen. Weitere Informationen finden Sie unter Richtlinienbasierte Routen.

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.

  • Richtlinienbasierte Routen können für Instanzen, VLAN-Anhänge für Cloud Interconnect und Cloud VPN-Gateways in einem VPC-Netzwerk gelten. Richtlinienbasierte Routen gelten nur, wenn ein Paket die Kriterien der richtlinienbasierten Route erfüllt.

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

  • Subnetz- und Peering-Subnetzrouten gelten für alle Instanzen. Subnetzrouten und Peering-Subnetzrouten entsprechen Subnetzen in Ihrem VPC-Netzwerk sowie denen, die aus Peer-Netzwerken importiert wurden.

  • Die vom System generierte Standardroute gilt für alle Instanzen. Sie können die vom System generierte Standardroute nach Wunsch durch eine benutzerdefinierte statische Route ersetzen.

  • 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. Wenn ein VPC-Netzwerk den regionalen dynamischen Routingmodus verwendet, erstellen alle seine Cloud Router nur dynamische Routen für gelernte Präfixe in seiner lokalen Region. Wenn ein VPC-Netzwerk den globalen dynamischen Routingmodus verwendet, erstellen alle seine Cloud Router dynamische Routen für gelernte Präfixe in allen Regionen.

    Cloud Router verwerfen automatisch gelernte Präfixe, die nicht zugänglichen nächsten Hops entsprechen (Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge). Je nach Netzwerk kann das Entfernen einer dynamischen Route, deren nächster Hop nicht erreichbar ist, durch Cloud Router bis zu 40 Sekunden dauern.

Routingreihenfolge

Im folgenden Prozess wird das Verhalten der Auswahl von VPC-Netzwerkrouten modelliert. Beginnend mit dem Satz anwendbarer Routen (wie im vorherigen Abschnitt beschrieben) können Sie die Routenauswahlentscheidungen modellieren, die Google Cloud für ein Paket trifft, indem Sie diesem Prozess folgen.

  1. Richtlinienbasierte Routen: Richtlinienbasierte Routen werden vor allen anderen Routentypen ausgewertet. Wenn ein Paket die Kriterien für mindestens eine richtlinienbasierte Route erfüllt, schränkt Google Cloud Ihr Routenauswahlmodell ein, sodass das Modell nur die richtlinienbasierten Routen enthält, die mit der größten Anzahl von Paketeigenschaften übereinstimmen – die am spezifischsten für das Paket sind. Beispielsweise wird eine richtlinienbasierte Route ausgewählt, die mit der Quelle und dem Ziel eines Pakets übereinstimmt, anstelle einer richtlinienbasierten Route, die nur mit dem Ziel eines Pakets übereinstimmt.

    Google Cloud stellt Pakete gemäß den Routenauswahlmodellen auf folgende Arten bereit:

    • Wenn ein Routenauswahlmodell auf eine einzelne richtlinienbasierte Route beschränkt ist, liefert Google Cloud das Paket an den nächsten Hop dieser richtlinienbasierten Route.
    • Wenn ein Routenauswahlmodell zwei oder mehr richtlinienbasierte Routen enthält, verteilt Google Cloud den Traffic so:
      • Wenn die richtlinienbasierten Routen eindeutige Prioritäten haben, verwendet Google Cloud den internen TCP/UDP-Load-Balancer als nächsten Hop der richtlinienbasierten Route mit der höchsten Priorität.
      • Wenn die richtlinienbasierten Routen dieselben Prioritäten haben, wählt Google Cloud trotzdem nur einen internen TCP/UDP-Load-Balancer als nächsten Hop aus. Google Cloud verwendet einen deterministischen internen Algorithmus, um einen einzelnen Load-Balancer als nächsten Hop auszuwählen, und ignoriert andere richtlinienbasierte Routen mit derselben Priorität.

  2. Spezielle Rückgabepfade: Spezielle Rückgabepfade ähneln richtlinienbasierten Routen, mit dem Unterschied, dass in der Routentabelle Ihres VPC-Netzwerks keine speziellen Rückgabepfade angezeigt werden. Routen, die Sie in einem VPC-Netzwerk konfigurieren, gelten nicht für Antwortpakete für bestimmte Google Cloud-Load-Balancer, Systemdiagnosesysteme, Identity-Aware Proxy (IAP) und Cloud DNS-Proxys. Weitere Informationen finden Sie unter Spezielle Rückgabepfade.

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

  3. 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 Rückgabepfade am spezifischsten.

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

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

  5. Benutzerdefinierte statische Routen ignorieren, deren nächste Hops ausgefallen sind: Mit diesem Schritt werden zwei Situationen modelliert, in denen Google Cloud nächste Hops ignoriert, die als ausgefallen 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.

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

  7. 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 TCP/UDP-Load-Balancer
    Google Cloud verwendet einen internen Algorithmus, um einen einzelnen als nächster Hop dienenden internen TCP/UDP-Load-Balancer auszuwählen, wobei die anderen als nächster Hop dienenden internen TCP/UDP-Load-Balancer mit derselben Priorität ignoriert werden. Weitere Informationen finden Sie unter "Gleiches Ziel und mehrere interne TCP/UDP-Load-Balancer als nächsten Hop" im Abschnitt Überlegungen zu internen TCP/UDP-Load-Balancern, die als nächster Hop dienen.
    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.

  8. 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 TCP/UDP-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 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.

Spezielle Rückgabepfade

VPC-Netzwerke haben spezielle Routen für bestimmte Dienste. Diese Routen werden außerhalb Ihres VPC-Netzwerks im Produktionsnetzwerk von Google definiert. Sie tauchen nicht in der Routingtabelle Ihres VPC-Netzwerks auf. Sie können sie nicht entfernen oder überschreiben, auch wenn Sie eine Standardroute in Ihrem VPC-Netzwerk löschen oder ersetzen. Sie können jedoch den Traffic zu und von diesen Diensten mithilfe von Firewallregeln steuern.

Load-Balancer-Rückgabepfade

Wenn Sie einen der folgenden Google Cloud-Load-Balancer verwenden, setzt Google Cloud spezielle Routen für die Load-Balancer und die dazugehörigen Systemdiagnosen ein. Diese werden in den folgenden Abschnitten ausführlicher beschrieben.

  • Rückgabepfade für HTTP(S)-, SSL-Proxy- und TCP-Proxy-Load-Balancer

    Bei diesen Load-Balancer-Typen dienen Google Front End-Systeme (GFE) als Proxys. Wenn ein Client eine Anfrage an den Load-Balancer sendet, beendet ein Proxy die TCP-Sitzung und öffnet eine neue TCP-Sitzung mit Ihrer Back-End-VM. Außerhalb Ihres VPC-Netzwerks definierte Routen erleichtern die Kommunikation von GFE-Proxys zu Ihren Back-End-VMs und von Ihren Back-End-VMs zu GFE-Proxys.

    Weitere Informationen finden Sie auf den folgenden Seiten:

  • Rückgabepfade für Netzwerk-Load-Balancer

    Wenn ein Client im Internet eine TCP- oder UDP-Anfrage über einen Netzwerk-Load-Balancer an eine Back-End-VM sendet, verwendet Google Cloud Routen außerhalb Ihres VPC-Netzwerks, um die Kommunikation vom Client zur Back-End-VM und von Ihrer Back-End-VM zum Client zu erleichtern.

    Weitere Informationen finden Sie unter Netzwerk-Load-Balancing.

  • Systemdiagnosen für alle Load-Balancer-Typen

    Pakete, die von Prüfsystemen der Google Cloud-Systemdiagnose gesendet werden, verfügen über Quellen gemäß den Prüfungs-IP-Bereichen und Firewallregeln. Routen, die die Kommunikation zwischen den Prüfsystemen der Google Cloud-Systemdiagnose und Ihren Back-End-VMs erleichtern, befinden sich außerhalb Ihres VPC-Netzwerks und können nicht entfernt werden. Ihr VPC-Netzwerk muss jedoch Firewall-Zulassungsregeln für eingehenden Traffic haben, um Traffic von diesen Systemen freizugeben.

IAP

Eine Route für 35.235.240.0/20 ist enthalten, um die TCP-Weiterleitung mit IAP zu unterstützen. Das Produktionsnetzwerk von Google akzeptiert keine Routen für 35.235.240.0/20 aus anderen Quellen im Internet.

Cloud DNS

Eine Route nach 35.199.192.0/19 unterstützt Verbindungen zu Weiterleitungszielen mit privatem Routing oder alternativen Nameservern mit privatem Routing. Das Produktionsnetzwerk von Google akzeptiert keine Routen für 35.199.192.0/19 aus anderen Quellen im Internet.

Serverloser VPC-Zugriff

Eine Route für 35.199.224.0/19 unterstützt den serverlosen VPC-Zugriff. Das Produktionsnetzwerk von Google akzeptiert keine Routen für 35.199.224.0/19 aus anderen Quellen im Internet.

Parameter für statische Routen

Jede statische Route besteht aus folgenden Komponenten:

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

  • Zielbereich: Der Zielbereich ist ein einzelner IPv4-CIDR-Block, der die IP-Adressen von Systemen enthält, die eingehende Pakete empfangen. Ziele müssen in CIDR-Notation angegeben werden. Sie können weder genau mit einem Subnetz-IP-Adressbereich übereinstimmen noch in einem Subnetz-IP-Adressbereich enthalten sein (also eine längere Subnetzmaske haben). Das Ziel einer statischen Route kann jedoch den IP-Bereich eines Subnetzes enthalten (und eine kleinere Subnetzmaske als dieses haben). Wenn Sie beispielsweise einen Subnetz-IP-Bereich von 10.10.10.0/24 haben, können Sie eine statische Route mit dem Ziel 10.10.10.0/23 haben. Wenn die Ziel-IP-Adresse eines Pakets nicht im Ziel der Subnetzroute enthalten ist, wird das Paket an den nächsten Hop der statischen Route gesendet. Das breitestmögliche Ziel ist 0.0.0.0/0.

  • Priorität: Mit der Priorität wird festgelegt, welche Route verwendet werden soll, wenn mehrere Routen identische Ziele haben. Niedrigere Zahlen zeigen höhere Prioritäten an. Beispielsweise hat eine Route mit einem Prioritätswert von 100 eine höhere Priorität als eine Route mit einem Prioritätswert von 200. Höchste Routenpriorität hat die kleinste mögliche nichtnegative Ganzzahl. Da Null die kleinste mögliche nichtnegative Ganzzahl ist, hat sie die höchste Priorität.

  • Nächster Hop: Statische Routen können nächste Hops haben, die auf das Standard-Internetgateway, eine Google Cloud-Instanz oder einen Cloud VPN-Tunnel verweisen. Weitere Informationen finden Sie unter Nächste Hops für statische Routen.

  • Tags: Sie können eine Liste von Netzwerk-Tags angeben, sodass die Route nur für Instanzen gilt, die mindestens eines der aufgelisteten Tags haben. Wenn Sie keine Tags angeben, wendet Google Cloud die Route auf alle Instanzen im Netzwerk an.

Nächste Hops für statische Routen

Im Folgenden sind die gültigen nächsten Hops für statische Routen aufgeführt. Weitere Informationen zu den einzelnen Typen finden Sie in der Referenzdokumentation zu gcloud.

Überlegungen zu Instanzen und internen TCP/UDP-Load-Balancern, die als nächste Hops dienen

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

Interner TCP/UDP-Load-Balancer als nächster Hop bezieht sich auf eine statische Route mit einem internen TCP/UDP-Load-Balancer als nächsten Hop (next-hop-ilb).

Wenn Sie das instanzbasierte Routing oder einen internen TCP/UDP-Load-Balancer als nächsten Hop konfigurieren, beachten Sie die folgenden Richtlinien:

  • Sie müssen die Back-End-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 Back-End-VM oder der nächsten Hop-Instanz ausgeführt wird, muss entsprechend konfiguriert werden. Beispielsweise müssen VM-Appliances von Drittanbietern, die als Router oder Firewalls dienen, gemäß den Anweisungen des Herstellers konfiguriert werden.

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

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

    Weitere Informationen finden Sie unter Implizierte Firewallregeln.

  • Aus Sicht des Ziels eines Pakets ist die Quellregion des Pakets die Region, die die Back-End-VM oder die nächste Hop-Instanz enthält. Beispielsweise können Pakete, die von Back-End-VMs oder nächsten Hop-Instanzen in us-west1 verarbeitet werden, an Ziele gesendet werden, auf die nur in us-west1 zugegriffen werden kann, auch wenn die ursprüngliche Paketquelle außerhalb von us-west1 liegt. Beispiele für Zielressourcen, die nur zugänglich sind, wenn sich Quell- und Zielressourcen in derselben Region befinden:

    • Interne TCP/UDP-Load-Balancer mit deaktiviertem globalen Zugriff
    • Regionale interne HTTP(S)-Load-Balancer
    • Interne regionale TCP-Proxy-Load-Balancer

Überlegungen zu als nächster Hop dienenden Instanzen

  • Nächster Hop nach Instanzname (next-hop-instance): Wenn sich sowohl die Route als auch die nächste Hop-Instanz im selben Projekt befinden, können Sie eine nächste Hop-Instanz anhand ihres Namens und ihrer Zone angeben. Bevor Sie die Route in Google Cloud erstellen können, muss eine nächste Hop-Instanz vorhanden sein und alle folgenden Kriterien erfüllen:

    • Der Instanzname muss dem VM-Namen des nächsten Hops der Route entsprechen.
    • Die Zone der Instanz muss mit der Zone des nächsten Hops der Route übereinstimmen.
    • Die Instanz muss eine Netzwerkschnittstelle im VPC-Netzwerk der Route haben.

    Google Cloud aktualisiert eine Route, deren nächster Hop durch next-hop-instance angegeben ist, in folgenden Fällen automatisch:

    • Wenn sich die IPv4-Adresse der nächsten Hop-Instanz ändert
    • Wenn Sie die nächste Hop-Instanz ersetzen, solange die Ersatzinstanz dieselben Kriterien wie die ersetzte Instanz erfüllt

  • Interne IP-Adresse der nächsten Hop-Instanz (next-hop-address): Sie können eine nächste Hop-Instanz mithilfe einer internen IPv4-Adresse angeben, die einer Netzwerkschnittstelle im VPC-Netzwerk der Route zugeordnet ist. Bevor Sie die Route in Google Cloud erstellen können, muss eine nächste Hop-Instanz vorhanden sein und alle folgenden Kriterien erfüllen:

    • Die Instanz muss mindestens eine Netzwerkschnittstelle im VPC-Netzwerk der Route haben.
    • Die Netzwerkschnittstelle der Instanz muss eine interne IPv4-Adresse haben, die der Adresse des nächsten Hops der Route entspricht. Die interne IPv4-Adresse kann entweder die primäre IPv4-Adresse der Netzwerkschnittstelle oder eine IPv4-Adresse aus einem Alias-IP-Bereich der Netzwerkschnittstelle sein.

    Google Cloud aktualisiert eine Route, deren nächster Hop durch next-hop-address angegeben wird, automatisch, wenn die IPv4-Adresse zu einer anderen VM verschoben wird, vorausgesetzt, die Ersatz-VM erfüllt die oben genannten Kriterien.

  • Nächste Hops in einem freigegebenen VPC-Dienstprojekt: Wenn Sie eine Route in einem freigegebenen VPC-Netzwerk erstellen müssen, dessen nächste Hop-Instanz sich in einem Dienstprojekt befindet, müssen Sie den nächsten Hop mit next-hop-address angeben. Sie können den nächsten Hop nicht mit next-hop-instance angeben.

  • 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 ausgehenden Traffic 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 TCP/UDP-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. Verwenden Sie zur Verbesserung der Zuverlässigkeit stattdessen einen internen TCP/UDP-Load-Balancer als nächsten Hop.

  • 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, müssen Sie einen als nächster Hop dienenden internen TCP/UDP-Load-Balancer verwenden. Der als nächster Hop dienende TCP/UDP-Load-Balancer ist erforderlich, da er symmetrisches Hashing bietet. Weitere Informationen zum symmetrischen Hashing finden Sie in der Dokumentation zum symmetrischen Hashing in den internen TCP/UDP-Load-Balancern als nächste Hops.

  • Verhalten, wenn Instanzen angehalten oder gelöscht werden: Google Cloud verhindert nicht, dass Sie eine nächste Hop-Instanz anhalten oder löschen, unabhängig davon, wie Sie sie angegeben haben (mit next-hop-instance oder next-hop-address). Google Cloud verwirft alle angehaltenen oder gelöschten Instanzen im Schritt zur Präferenzkategorisierung in der Routingreihenfolge. Die folgenden Beispiele verdeutlichen dieses Verhalten:

    • Angenommen, Sie haben drei benutzerdefinierte statische Routen für das Ziel 192.168.168.0/24: eine mit Priorität 10, deren nächste Hop-VM angehalten wurde, eine zweite mit Priorität 20, deren nächste Hop-VM ausgeführt wird, und eine dritte mit Priorität 30, deren nächste Hop-VM ausgeführt wird. Google Cloud sendet Pakete an die zweite VM, obwohl ihre Route eine niedrigere Priorität hat als die Route, deren nächste Hop-VM angehalten wurde. Wenn die VM mit der Priorität 10 neu gestartet wird, verwendet Google Cloud diese VM stattdessen als nächsten Hop.

    • Angenommen, Sie haben drei benutzerdefinierte statische Routen, wie oben beschrieben, aber alle nächste Hop-VMs wurden entweder angehalten oder gelöscht. Pakete werden auch dann verworfen, wenn weniger spezifische Routen mit funktionierenden nächsten Hops vorhanden sind, da Google Cloud die Zielspezifität berücksichtigt, bevor bestimmt wird, ob eine nächste Hop-VM ausgeführt wird.

Überlegungen zu internen TCP/UDP-Load-Balancern, die als nächster Hop dienen

  • Auswirkungen des globalen Zugriffs. Benutzerdefinierte statische Routen, die interne TCP/UDP-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 TCP/UDP-Load-Balancer gesendet werden, verworfen.

  • Wenn alle Back-Ends fehlerhaft sind. Wenn alle Back-Ends eines internen TCP/UDP-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. Ein interner TCP/UDP-Load-Balancer mit nächstem Hop und interne Weiterleitungsregeln des TCP/UDP-Load-Balancers mit einer gemeinsamen IP-Adresse schließen sich gegenseitig aus. Der interne TCP/UDP-Load-Balancer mit nächstem Hop muss eine IP-Adresse verwenden, die für die Weiterleitungsregel des Load-Balancers eindeutig ist, damit nur ein Back-End-Dienst (ein Load-Balancer) eindeutig referenziert wird. Es ist möglich, dass Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden, auf verschiedene Back-End-Dienste verweisen (verschiedene interne TCP/UDP-Load-Balancer).

  • Gleiches Ziel und mehrere interne TCP/UDP-Load-Balancer als nächsten Hop Wenn Sie zwei oder mehr benutzerdefinierte statische Routen mit demselben Ziel und unterschiedlichen internen TCP/UDP-Load-Balancern als nächste Hops erstellen, verteilt Google Cloud den Traffic nie unter den Load-Balancern als nächste Hops mit ECMP. Wenn die Routen eindeutige Prioritäten haben, verwendet Google Cloud den internen TCP/UDP-Load-Balancer als nächsten Hop aus der Route mit der höchsten Priorität. Wenn die Routen dieselben Prioritäten haben, wählt Google Cloud trotzdem nur einen internen TCP/UDP-Load-Balancer als nächsten Hop aus. Wie in der folgenden Abbildung dargestellt, verwendet Google Cloud einen deterministischen internen Algorithmus, um eine Weiterleitungsregel als nächsten Hop (forwarding-rule-a) auszuwählen und andere Routen mit derselben Priorität zu ignorieren.

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

  • Mehrere Ziele und derselbe TCP-UDP-Load-Balancer für den nächsten Hop:

    Mit Instanz-Tags:

    Wenn Sie Instanz-Tags (auch Netzwerk-Tags genannt) verwenden, können Sie denselben internen TCP/UDP-Load-Balancer als nächsten Hop für mehrere benutzerdefinierte statische Routen mit demselben Ziel und derselben Priorität verwenden.

    Ohne Instanz-Tags: Ohne Instanz-Tags können Sie nicht mehrere benutzerdefinierte statische Routen mit derselben Kombination aus Ziel, Priorität und internem TCP/UDP-Load-Balancer als nächsten Hop erstellen. Beispielsweise können route-x, route-y und route-z erstellt werden, route-x-copy jedoch nicht.

    Statische Routen, die keine Instanz-Tags enthalten, können nicht mit demselben Ziel, derselben Priorität und demselben internen TCP/UDP-Load-Balancer als nächster Hop erstellt werden.

  • Instanz-Tags.

    Sie können Instanz-Tags angeben (auch als Netzwerk-Tags bezeichnet), sodass die Route für den nächsten Hop nur für Clientinstanzen gilt, die mit dem Tag konfiguriert wurden. Dadurch können Sie auswählen, welche Clientinstanzen mit welcher getaggten Route für den nächsten Hop gefüllt werden und an welche Gruppe von Appliances der Traffic weitergeleitet werden soll.

    Sie müssen die verschiedenen Clientinstanzen nicht in separate VPC-Netzwerke unterteilen, die jeweils auf ihre bevorzugten internen TCP/UDP-Load-Balancer mit dem Front-End einer Reihe von Appliances verweisen.

  • Mehrere Routen für dasselbe Zielpräfix: Mit Instanz-Tags können Sie mehrere Routen zum selben Ziel mit unterschiedlichen internen Load-Balancern als nächste Hops angeben. Sie können für diese Zielrouten unterschiedliche Instanz-Tags oder unterschiedliche Prioritäten verwenden.

Ü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 ausgehenden Traffic 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 ausgefallen sind: Benutzerdefinierte statische Routen, deren nächste Hops klassische VPN-Tunnel sind, werden nicht automatisch entfernt, wenn die klassischen VPN-Tunnel ausfallen. Weitere Informationen dazu, was geschieht, wenn Tunnel ausfallen, finden Sie in der Dokumentation zu klassischen VPNs Wenn Tunnel nicht erreichbar sind.

Nächste Schritte