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:
|
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:
Die Standardrouten von IPv4 und IPv6 definieren einen Pfad aus dem VPC-Netzwerk zu externen IP-Adressen im Internet.
Wenn Sie auf Google APIs und Google-Dienste zugreifen, ohne einen Private Service Connect-Endpunkt zu verwenden, kann die Standardroute als Pfad zu Google APIs und Google-Diensten dienen. Weitere Informationen finden Sie unter Privaten Google-Zugriff konfigurieren und Auf APIs von VMs mit externen IP-Adressen zugreifen.
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ür10.70.1.0/24
,10.70.1.0/25
,10.70.1.128/25
oder andere Ziele, die in10.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, der10.70.1.128/25
,10.70.1.0/24
oder einem anderen Bereich entspricht, der alle IP-Adressen in10.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äfix10.70.1.0/24
über BGP erhalten, verwendet Google Cloud das Subnetz oder Peering-Subnetzroute und erstellt keine benutzerdefinierte dynamische Route für10.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äfixe10.70.1.0/25
und10.70.1.128/25
über BGP erhalten, verwendet Google Cloud die Subnetz- oder die Peering-Subnetzroute und erstellt keine benutzerdefinierten dynamischen Routen für10.70.1.0/25
und10.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.
Wenn Sie den primären IP-Adressbereich eines Subnetzes erweitern, aktualisiert Google Cloud das Ziel der entsprechenden Subnetzroute.
Wenn Sie einem Subnetz einen sekundären IP-Adressbereich hinzufügen oder ihn daraus entfernen, erstellt oder löscht Google Cloud eine entsprechende Subnetzroute für den sekundären Bereich.
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:
Sie können statische Routen manuell erstellen: mit der Google Cloud Console,
gcloud compute routes create
oder derroutes.insert
API.Wenn Sie mit der Google Cloud Console einen klassischen VPN-Tunnel erstellt haben, der richtlinienbasiertes Routing verwendet oder der ein routenbasiertes VPN ist, wurden statische Routen für die Remote-Trafficauswahl für Sie erstellt. Weitere Informationen finden Sie unter Cloud VPN-Netzwerke und Tunnelrouting.
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:
Klassischen VPN-Tunneln, die dynamisches Routing verwenden
Virtuelle Appliances von Drittanbietern, die als Router-Appliance-Instanzen im Network Connectivity Center installiert wurden
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:
- Statische Routen, die das
next-hop-gateway
verwenden (den nächsten Hop des Standard-Internetgateways) - Statische Routen, die sich über Netzwerk-Tags auf Instanzen beziehen
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.
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.
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.
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 als10.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.
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.
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
odernext-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.
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
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
odernext-hop-address
) oder über IKE-SA eingerichteter klassischer VPN-Tunnel, der als nächster Hop dientZweite 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
verwendetAm Ende dieses Schritts können null Routen, eine Route oder zwei oder mehr Routen im Routenmodell vorhanden sein.
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 Ziel10.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 ist0.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 von200
. 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
.
Nächstes Hop-Gateway (
next-hop-gateway
): Sie können ein Standard-Internetgateway angeben, um einen Pfad zu externen IP-Adressen zu definieren.Nächste Hop-Instanz nach Name (
next-hop-instance
) oder Adresse (next-hop-address
): Sie können Traffic an eine vorhandene Instanz mit einer Netzwerkschnittstelle im selben VPC-Netzwerk wie die Route weiterleiten. Weitere Informationen finden Sie unter Überlegungen zu als nächster Hop dienenden Instanzen.Als nächster Hop dienender interner TCP/UDP-Load-Balancer (
next-hop-ilb
): Sie können Traffic an mehrere Back-End-Instanzen eines vorhandenen internen TCP/UDP-Load-Balancers weiterleiten. Informationen finden Sie unter Überlegungen zu internen TCP/UDP-Load-Balancern, die als nächster Hop dienen.Nächster Hop-VPN-Tunnel (
next-hop-vpn-tunnel
): Bei klassischen VPN-Tunneln, die richtlinienbasiertes Routing und routenbasierte VPNs verwenden, können Sie Traffic an den VPN-Tunnel weiterleiten. Dazu erstellen Sie Routen, deren nächste Hops auf den Tunnel anhand seines Namens und seiner Region verweisen. Weitere Informationen finden Sie unter Überlegungen zu klassischen VPN-Tunneln mit nächstem Hop.
Ü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 inus-west1
zugegriffen werden kann, auch wenn die ursprüngliche Paketquelle außerhalb vonus-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 mitnext-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
odernext-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
undroute-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
- Mehr zum Erstellen und Verwalten von Routen erfahren Sie unter Routen verwenden.
- Einen Überblick über Google Cloud VPC-Netzwerke erhalten Sie unter VPC-Netzwerke.
- Anleitungen zum Erstellen, Ändern oder Löschen von VPC-Netzwerken finden Sie unter VPC-Netzwerke erstellen und verwalten.