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

VPC-Netzwerk-Peering

Das Google Cloud VPC-Netzwerk-Peering verbindet zwei Virtual Private Cloud-Netzwerke (VPC), sodass Ressourcen in jedem Netzwerk miteinander kommunizieren können:

  • Alle Subnetze können über interne IPv4-Adressen kommunizieren.
  • Dual-Stack-Subnetze können auch über interne oder externe IPv6-Adressen kommunizieren.

Peering-VPC-Netzwerke können sich im selben Projekt, in verschiedenen Projekten derselben Organisation oder in verschiedenen Projekten verschiedener Organisationen befinden.

VPC-Netzwerk-Peering bietet folgende Vorteile:

Vorteile von VPC-Netzwerk-Peering

VPC-Netzwerk-Peering bietet folgende Vorteile:

  • Netzwerklatenz: Verbindungen, die nur interne Adressen verwenden, bieten eine geringere Latenz als Verbindungen, die externe Adressen nutzen.
  • Netzwerksicherheit: Dienstinhaber müssen ihre Dienste nicht über das öffentliche Internet anbieten und den zugehörigen Risiken aussetzen.
  • Netzwerkkosten: In Google Cloud werden Gebühren für die Bandbreitennutzung ausgehenden Traffics aus Netzwerken berechnet, die über externe IP-Adressen kommunizieren. Dies gilt auch für Traffic innerhalb derselben Zone. Wenn die Netzwerke jedoch über Peering miteinander verbunden sind, können für die Kommunikation interne IP-Adressen verwendet und die Kosten für ausgehenden Traffic eingespart werden. Für den gesamten Traffic gelten aber weiterhin die normalen Netzwerkpreise.

Informationen zum Erstellen von Peering-Verbindungen finden Sie unter VPC-Netzwerk-Peering verwenden.

Spezifikationen

Für VPC-Netzwerk-Peering gelten die folgenden Spezifikationen.

Allgemeine Spezifikationen:

  • VPC-Netzwerk-Peering kann mit Compute Engine, GKE und der flexiblen App Engine-Umgebung verwendet werden.
    • Standardmäßig wird VPC-Netzwerk-Peering mit GKE bei einer Verwendung mit IP-Aliassen unterstützt. Wenn Sie keine IP-Aliasse verwenden, können Sie benutzerdefinierte Routen exportieren, sodass GKE-Container über Peering-Netzwerke erreichbar sind.
  • VPC-Netzwerk-Peering ist nur zwischen VPC-Netzwerken möglich. Für Legacy-Netzwerke wird das Peering nicht unterstützt.
  • VPC-Netzwerk-Peering unterstützt sowohl IPv4- als auch IPv6-Verbindungen. Sie können VPC-Netzwerk-Peering in einem VPC-Netzwerk konfigurieren, das Dual-Stack-Subnetze enthält. Bei IPv6 werden jedoch nur dynamische Routen ausgetauscht.
  • Für ein VPC-Netzwerk kann Peering mit mehreren anderen VPC-Netzwerken eingerichtet werden, allerdings gibt es hierfür ein Limit.

Administrative Trennung:

  • Peering-VPC-Netzwerke bleiben administrativ getrennt. Die Routen, Firewalls, VPNs und anderen Trafficmanagementtools werden in jedem VPC-Netzwerk separat verwaltet und angewendet.
  • Zum Herstellen einer Peering-Verbindung muss ein Netzwerkadministrator für jedes VPC-Netzwerk eine Peering-Verbindung zum anderen VPC-Netzwerk herstellen. Ein Netzwerkadministrator für eines der VPC-Netzwerke kann eine Peering-Verbindung trennen.
  • Alle Komponenten der Peering-Verknüpfung werden unabhängig voneinander eingerichtet. Das Peering ist nur aktiv, wenn beide Seiten übereinstimmend konfiguriert sind. Die Peering-Verknüpfung kann von beiden Seiten jederzeit getrennt werden.
  • Durch das Erstellen einer Peering-Verbindung werden Ihnen keine IAM-Rollen (Identity and Access Management) im anderen VPC-Netzwerk zugewiesen. Wenn Sie beispielsweise die Rolle „Compute-Netzwerkadministrator“ oder die Rolle „Compute-Sicherheitsadministrator“ für ein Netzwerk haben, werden Sie kein Netzwerkadministrator oder Sicherheitsadministrator für das andere Netzwerk.

IAM:

  • IAM-Berechtigungen zum Erstellen und Löschen von VPC-Netzwerk-Peering sind Bestandteil der Rolle Compute-Netzwerkadministrator (roles/compute.networkAdmin).
  • Sie können eine benutzerdefinierte Rolle verwenden, wenn sie die folgenden Berechtigungen enthält:
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

Routenaustausch:

  • Peering und die Option zum Importieren und Exportieren benutzerdefinierter Routen können für ein VPC-Netzwerk konfiguriert werden, auch wenn das andere VPC-Netzwerk noch gar nicht erstellt wurde. Der Routentausch erfolgt jedoch erst, wenn beide Seiten konfiguriert wurden.
  • VPC-Peers exportieren immer Subnetzrouten.
  • VPC-Peers importieren Subnetzrouten immer, wenn das Subnetz private IP-Adressen verwendet. Wenn das Subnetz privat genutzte öffentliche IP-Adressen verwendet, müssen Peering-Netzwerke privat genutzte öffentliche IP-Subnetzrouten importieren, um sie von anderen Netzwerken zu empfangen. Weitere Informationen zu privaten und privat verwendeten öffentlichen IP-Adressen finden Sie unter Gültige Bereiche.
  • Sie können den Austausch von Subnetzrouten nicht deaktivieren oder auswählen, welche Subnetzrouten ausgetauscht werden. Nach dem Einrichten des Peerings sind alle Ressourcen, die im Subnetz-IP-Adressbereich liegen, über direkt verbundene Peering-Netzwerke zugänglich. VPC-Netzwerk-Peering bietet keine detaillierte Routensteuerung, um herauszufiltern, welche Subnetz-CIDR-Bereiche innerhalb der Peering-Netzwerke erreichbar sind. Sie müssen bei Bedarf Firewallregeln verwenden, um den Traffic zu filtern. In direkt verbundenen Peering-Netzwerken sind folgende Arten von Endpunkten und Ressourcen erreichbar:
    • Interne IP-Adressen virtueller Maschinen (VMs) in allen Subnetzen
    • Interne IP-Adressen mit Load-Balancing in allen Subnetzen
  • Sie können benutzerdefinierte Routen (statische und dynamische Routen) austauschen, je nachdem, ob die Peering-Konfigurationen für den Import oder Export konfiguriert wurden. Weitere Informationen finden Sie unter Benutzerdefinierte Routen importieren und exportieren.
  • Subnetz- und statische Routen sind global. Dynamische Routen können abhängig vom Modus für dynamisches Routing des VPC-Netzwerks regional oder global sein.
  • Der CIDR-Bereich eines Subnetzes in einem Peering-VPC-Netzwerk darf sich nicht mit einer statischen Route in einem anderen Peering-Netzwerk überschneiden. Diese Regel gilt sowohl für Subnetzrouten als auch statische Routen. In folgenden Fällen wird in Google Cloud geprüft, ob eine Überschneidung vorliegt, und gegebenenfalls ein Fehler ausgegeben.
    • Wenn VPC-Netzwerke erstmals verbunden werden (Peering)
    • Wenn Sie in einem Peering-VPC-Netzwerk eine Route erstellen
    • Wenn Sie in einem Peering-VPC-Netzwerk ein neues Subnetz erstellen
  • Eine dynamische Route kann sich mit einer Subnetzroute in einem Peering-Netzwerk überschneiden. Bei dynamischen Routen werden die Zielbereiche, die sich mit einer Subnetzroute aus dem Peering-Netzwerk überschneiden, ohne Rückmeldung verworfen. Google Cloud verwendet die Subnetzroute.

Einschränkungen:

  • Nur direkt verbundene Peering-Netzwerke können miteinander kommunizieren. Transitives Peering wird nicht unterstützt. Wenn also das VPC-Netzwerk N1 mit N2 und N3 verbunden ist, aber N2 und N3 nicht direkt miteinander verbunden sind, kann das VPC-Netzwerk N2 nicht per VPC-Netzwerk-Peering mit dem VPC-Netzwerk N3 kommunizieren.
  • VPC-Firewallregeln können kein Netzwerktag oder Dienstkonto aus einem Peering-Netzwerk verwenden. Weitere Informationen finden Sie unter Netzwerksicherheit.
  • Die in einem Netzwerk erstellten internen DNS-Namen von Compute Engine sind für Peering-Netzwerke nicht erreichbar. Verwenden Sie die IP-Adresse, um die VM-Instanzen in einem Peering-Netzwerk zu erreichen.
  • Richtlinienbasierte Routen werden nie über Peering ausgetauscht.

Benutzerdefinierte Routen importieren und exportieren

Netzwerksicherheit

VPC-Netzwerk-Peering tauscht keine VPC-Firewallregeln oder hierarchische Firewallrichtlinien aus. VPC-Firewallregeln in einem VPC-Netzwerk können keine Ziele oder Quellen mithilfe von Netzwerktags oder Dienstkonten aus dem anderen VPC-Netzwerk angeben. Allerdings kann dasselbe Zielnetzwerk-Tag in beiden Netzwerken verwendet werden.

Jedes VPC-Netzwerk enthält implizierte Firewallregeln. Aufgrund der implizierte Firewallregeln zum Ablehnen von eingehendem Traffic müssen Sicherheitsadministratoren für ein lokales VPC-Netzwerk geeignete Firewallregeln zum Zulassen von eingehendem Traffic oder hierarchische Firewallrichtlinien erstellen. Diese Regeln oder Richtlinien lassen Pakete aus den erforderlichen Quell-IP-Adressbereichen im Peering-VPC-Netzwerk zu.

Aufgrund der implizierten Firewallregeln zum Zulassen von ausgehendem Traffic müssen Sie keine Firewallregeln für ausgehenden Traffic oder hierarchische Firewallrichtlinien erstellen, um Pakete an die Ziele im Peering-VPC-Netzwerk zuzulassen. Wenn jedoch Sicherheitsadministratoren für das lokale VPC-Netzwerk explizite Ablehnungsregeln für ausgehenden Traffic erstellt haben, müssen Sie Zulassungsregeln oder -richtlinien erstellen.

DNS-Unterstützung

Ressourcen in einem Peering-VPC-Netzwerk können keine internen Compute Engine-DNS-Namen verwenden, die von einem lokalen VPC-Netzwerk erstellt werden.

Ein Peering-VPC-Netzwerk kann keine von Cloud DNS verwalteten privaten Zonen verwenden, die nur für ein lokales VPC-Netzwerk autorisiert sind. Verwenden Sie eine der folgenden Methoden, um die DNS-Namen für Ressourcen in einem Peering-VPC-Netzwerk verfügbar zu machen:

Support für internen Load-Balancer

Clients in einem lokalen VPC-Netzwerk können auf interne TCP/UDP-Load-Balancer in einem Peering-VPC-Netzwerk zugreifen. Weitere Informationen finden Sie unter VPC-Netzwerk-Peering für den internen TCP/UDP-Load-Balancer verwenden. Peering-Netzwerke können benutzerdefinierte statische Routen mithilfe interner TCP/UDP-Load-Balancer als nächste Hops austauschen. Weitere Informationen finden Sie unter Optionen für den Routenaustausch.

Clients in einem lokalen VPC-Netzwerk können auf interne HTTP(S)-Load-Balancer in einem Peer-VPC-Netzwerk zugreifen. Weitere Informationen finden Sie unter VPC-Netzwerk-Peering für das interne HTTP(S)-Load-Balancing verwenden.

Limits für VPC-Netzwerk-Peering

Mit VPC-Netzwerk-Peering-Limits wird Folgendes gesteuert:

  • Die Anzahl der Ressourcen wie VM-Instanzen oder interne Weiterleitungsregeln, die in einer Peering-Gruppe vorhanden sein können.
  • Die Anzahl der Netzwerke, mit denen ein bestimmtes VPC-Netzwerk eine Verbindung herstellen kann.

Die Limits für das VPC-Peering hängen vom Konzept ab, das als Peering-Gruppe bezeichnet wird. Jedes VPC-Netzwerk hat eine eigene Peering-Gruppe, die aus sich selbst und allen anderen VPC-Netzwerken besteht, die über VPC-Netzwerk-Peering verbunden sind. Im einfachsten Szenario gibt es zwei Peering-Gruppen, wenn zwei VPC-Netzwerke, net-a und net-b, verbunden sind, eine aus der Perspektive von net-a und die andere aus der Perspektive von net-b.

Weitere Informationen finden Sie unter Einschränkungen für VPC-Netzwerk-Peering.

Optionen für den Routenaustausch

Wenn ein VPC-Netzwerk lokale Routen für ein Peering-VPC-Netzwerk freigibt, werden die Routen exportiert. Das Peering-VPC-Netzwerk kann dann die Routen importieren. Subnetzrouten, mit Ausnahme von IPv4-Subnetzrouten, die privat verwendete öffentliche IPv4-Adressen verwenden, werden immer ausgetauscht.

Mit der Konfiguration von VPC-Netzwerk-Peering können Sie Folgendes steuern:

  • Wenn IPv6-Routen ausgetauscht werden
  • Wenn Routen für Subnetze, die privat verwendete öffentliche IPv4-Adressen verwenden, exportiert oder importiert werden
  • Ob benutzerdefinierte statische und dynamische Routen exportiert oder importiert werden

Sie können die Konfiguration aktualisieren, bevor das Peering eingerichtet wurde oder während die Peering-Verbindung aktiv ist.

Optionen für den Austausch von Subnetzrouten

In der folgenden Tabelle werden die Routenaustauschoptionen für Subnetzrouten beschrieben:

Routentyp Bedingungen für den Routenexport Routenimportbedingungen
IPv4-Subnetzrouten (primäre und sekundäre IPv4-Subnetzbereiche) unter Verwendung von privaten IPv4-Adressbereichen Immer exportiert

Kann nicht deaktiviert werden		 Immer importiert

Kann nicht deaktiviert werden
IPv4-Subnetzrouten (primäre und sekundäre IPv4-Subnetzbereiche) unter Verwendung privat verwendeter öffentlicher IPv4-Adressbereiche Standardmäßig exportiert

Der Export wird mit dem Flag --export-subnet-routes-with-public-ip gesteuert. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-subnet-routes-with-public-ip gesteuert.
Interne IPv6-Subnetzbereiche
(ipv6-access-type=INTERNAL) 		Standardmäßig nicht exportiert

Der Export ist durch Festlegen von --stack-type=IPV4_IPV6 aktiviert 		Standardmäßig nicht importiert

Der Import ist durch Festlegen von --stack-type=IPV4_IPV6 aktiviert.
Externe IPv6-Subnetzbereiche
(ipv6-access-type=EXTERNAL) 		Standardmäßig nicht exportiert

Der Export ist durch Festlegen von --stack-type=IPV4_IPV6 aktiviert 		Standardmäßig nicht importiert

Der Import ist durch Festlegen von --stack-type=IPV4_IPV6 aktiviert.

Optionen für den Austausch benutzerdefinierter statischer Routen

In der folgenden Tabelle werden die Optionen für den Routenaustausch für benutzerdefinierte statische Routen beschrieben:

Routentyp Bedingungen für den Routenexport Routenimportbedingungen
Benutzerdefinierte statische Routen mit Netzwerktags (alle Typen des nächsten Hops) Kann nicht exportiert werden Kann nicht importiert werden
Benutzerdefinierte statische Routen mit Standard-Internetgateway als nächsten Hop Kann nicht exportiert werden Kann nicht importiert werden
Benutzerdefinierte statische IPv4-Routen ohne Netzwerk-Tags, die die private IPv4-Adresse eines internen TCP/UDP-Load-Balancers als nächsten Hop verwenden Immer exportiert (wie Subnetz-IPv4-Routen)

Kann nicht deaktiviert werden 		Immer importiert (wie Subnetz-IPv4-Routen)

Kann nicht deaktiviert werden
Benutzerdefinierte statische IPv4-Routen ohne Netzwerk-Tags, die den Namen der Weiterleitungsregel eines internen TCP/UDP-Load-Balancers als nächsten Hop verwenden Standardmäßig nicht exportiert

Der Export wird mit dem Flag --export-custom-routes gesteuert. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-custom-routes gesteuert.
Benutzerdefinierte statische IPv4-Routen ohne Netzwerk-Tags, die andere nächste Hop-Typen verwenden Standardmäßig nicht exportiert

Der Export wird mit dem Flag --export-custom-routes gesteuert. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-custom-routes gesteuert.

Optionen für den Austausch dynamischer Routen

In der folgenden Tabelle werden die Routenaustauschoptionen für dynamische Routen beschrieben:

Routentyp Bedingungen für den Routenexport Routenimportbedingungen
Dynamische IPv4-Routen Standardmäßig nicht exportiert

Der Export wird mit dem Flag --export-custom-routes gesteuert. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-custom-routes gesteuert.
Dynamische IPv6-Routen Standardmäßig nicht exportiert

Der Export wird mit dem Flag --export-custom-routes gesteuert, wenn der Stacktyp des Peerings auf --stack-type=IPV4_IPV6 gesetzt ist. 		Standardmäßig nicht importiert

Der Import wird mit dem Flag --import-custom-routes gesteuert, wenn der Stacktyp des Peerings auf --stack-type=IPV4_IPV6 gesetzt ist.

Benutzerdefinierter Routenaustausch

Wenn ein VPC-Netzwerk benutzerdefinierte Routen exportiert und das andere VPC-Netzwerk benutzerdefinierte Routen importiert, kann das Importnetzwerk Pakete für jede importierte benutzerdefinierte Route direkt im Peering-VPC-Netzwerk senden. Benutzerdefinierte statische und benutzerdefinierte dynamische Routen werden zusammen erlernt und können nicht unabhängig konfiguriert werden. Änderungen in einem Netzwerk werden im anderen Netzwerk unter bestimmten Bedingungen übernommen. Weitere Informationen finden Sie in diesem Dokument unter Ignorierte Routen, Interaktionen mit Subnetz- und Peering-Subnetzrouten und Interaktionen mit Subnetzen und statischen Routen.

Das Importieren benutzerdefinierter Routen aus einem Peering-VPC-Netzwerk kann in den folgenden Szenarien hilfreich sein:

  • Wenn das Peering-VPC-Netzwerk routenbasierte GKE-Cluster enthält und Sie Pakete an die Pods in diesen Clustern senden müssen: Pod-IP-Adressen werden als Zielbereiche für benutzerdefinierte statische Routen implementiert, die sich im Peering-VPC-Netzwerk befinden.
  • Wenn das Peering-VPC-Netzwerk Routen zu lokalen Ressourcen enthält und Sie auf diese Ressourcen im lokalen VPC-Netzwerk zugreifen müssen, müssen Sie auch Routen für die Subnetz-IP-Adressbereiche des lokalen VPC-Netzwerks im lokalen Netzwerk erstellen. Sie können Peering-Routen für benutzerdefinierte Cloud Router im Peering-VPC-Netzwerk verwenden, um diese zusätzliche Anforderung zu erfüllen.

Wichtig: Cloud Router bieten keine Peering-Subnetzrouten an, wenn der Standard-Advertising-Modus verwendet wird. Sie müssen also benutzerdefiniertes Route Advertisement verwenden, um Peering-Subnetzrouten (oder aggregierte Bereiche von Peering-Subnetzrouten) zu bewerben.

Ignorierte Routen

Selbst wenn ein VPC-Netzwerk eine Route importiert, kann sie die importierte Route in folgenden Situationen ignorieren:

  • Wenn das lokale VPC-Netzwerk eine Route mit einem identischen oder spezifischeren Ziel (längere Subnetzmaske) hat, verwendet das lokale VPC-Netzwerk immer seine lokale Route.

  • Wenn das lokale VPC-Netzwerk nicht die spezifischste Route für das Ziel eines Pakets enthält, aber zwei oder mehr Peering-VPC-Netzwerke dasselbe, spezifischste Ziel für das Paket enthalten, verwendet Google Cloud einen internen Algorithmus, um einen nächsten Hop aus nur einem der Peering-VPC-Netzwerke auszuwählen. Diese Auswahl erfolgt, bevor die Routenpriorität berücksichtigt wird, und Sie können das Verhalten nicht konfigurieren. Als Best Practice sollten Sie diese Konfiguration vermeiden, da das Hinzufügen oder Entfernen von Peering-VPC-Netzwerken zu unbeabsichtigten Änderungen an der Routingreihenfolge führen kann.

Weitere Informationen zu den oben genannten Situationen finden Sie unter Routingreihenfolge.

Wenn ein lokales VPC-Netzwerk, das IPv6-Routen importiert, keine Dual-Stack-Subnetze hat, kann bei Dual-Stack-Peerings keine der IPv6-Routen verwendet werden, die es von Peering-VPC-Netzwerken empfängt. Wenn die Organisationsrichtlinieneinschränkung für constraints/compute.disableAllIpv6 festgelegt wurde, kann ein Netzwerkadministrator möglicherweise keine Dual-Stack-Subnetze erstellen.

Interaktionen mit Subnetz- und Peering-Subnetzrouten

IPv4-Subnetzrouten in Peering-VPC-Netzwerken dürfen sich nicht überschneiden:

  • Peering erlaubt identische IPv4-Subnetzrouten. Beispielsweise können zwei Peering-VPC-Netzwerke nicht beide eine IPv4-Subnetzroute haben, deren Ziel 100.64.0.0/10 ist.
  • Das Peering verhindert, dass eine Subnetzroute in einer Peering-Subnetzroute enthalten ist. Wenn das lokale VPC-Netzwerk beispielsweise eine Subnetzroute mit dem Ziel 100.64.0.0/24 hat, kann keines der Peering-VPC-Netzwerke eine Subnetzroute mit dem Ziel 100.64.0.0/10 haben.

In Google Cloud werden in den folgenden Fällen die vorherigen Bedingungen für IPv4-Subnetzrouten erzwungen:

  • Wenn Sie VPC-Netzwerke zum ersten Mal über VPC-Netzwerk-Peering verbinden
  • Während die Netzwerke über Peering verbunden sind
  • Wenn Sie eine Peering-Konfigurationsänderung vornehmen, z. B. das Importieren von IPv4-Routen von Subnetzen mit privat verwendeten öffentlichen IP-Adressen aktivieren.

Während Sie Peering-Netzwerke herstellen, gibt Google Cloud einen Fehler zurück, wenn einer der folgenden Vorgänge eine Überschneidung verursacht:

IPv6-Subnetzrouten (intern und extern) sind Definitionsgemäß. Zwei VPC-Netzwerke können nicht dieselben internen oder externen IPv6-Subnetzbereiche verwenden.

Interaktionen mit Subnetzen und statischen Routen

Für Google Cloud ist es erforderlich, dass Subnetzrouten und Peering-Subnetzrouten die spezifischsten IPv4- oder IPv6-Zielbereiche haben. In jedem VPC-Netzwerk kann eine lokale statische Route kein Ziel haben, das genau mit einer lokalen Subnetzroute übereinstimmt oder in diese passt. Weitere Informationen zu diesem Szenario finden Sie unter Interaktionen mit benutzerdefinierten statischen Routen.

Dieses Konzept wird auf VPC-Netzwerk-Peering durch die folgenden beiden Regeln erweitert:

  • Eine lokale statische Route darf kein Ziel haben, das genau mit einer Peering-Subnetzroute übereinstimmt oder in diese passt. Wenn eine lokale statische Route vorhanden ist, erzwingt Google Cloud Folgendes:

    • Sie können keine neue Peering-Verbindung zu einem VPC-Netzwerk herstellen, das bereits eine Subnetzroute enthält, die genau mit dem Ziel der lokalen statischen Route übereinstimmt oder diese enthält, wenn die Peering-Konfiguration zum Import der in Konflikt stehenden Subnetzroute führt.

      Beispiel: Wenn eine lokale statische Route mit den Ziel 10.0.0.0/24 vorhanden ist, können Sie keine neue Peering-Verbindung zu einem VPC-Netzwerk mit einer Subnetzroute herstellen, deren Ziel genau mit 10.0.0.0/24 übereinstimmt oder 10.0.0.0/24 enthält (Beispiel: 10.0.0.0/8).

    • Sie können eine vorhandene Peering-Verbindung nicht aktualisieren, wenn die aktualisierte Peering-Konfiguration zum Import der in Konflikt stehenden Subnetzroute führt.

      Wenn beispielsweise eine lokale statische Route mit dem Ziel 11.0.0.0/24 und eine Subnetzroute mit dem Ziel 11.0.0.0/8 im Peering-VPC-Netzwerk vorhanden ist, können Sie das Peering-Netzwerk nicht so konfigurieren, dass es Subnetzrouten mit privat verwendeten öffentlichen IPv4-Adressen exportiert und das lokale VPc-Netzwerk so konfigurieren, dass es Subnetzrouten mithilfe privat verwendeter öffentlicher IPv4-Adressen importiert.

    • Wenn VPC-Netzwerke jedoch bereits über VPC-Netzwerk-Peering verbunden sind, können Sie die folgenden Vorgänge nicht ausführen:

      • Erstellen Sie eine neue lokale statische Route, deren Ziel genau mit einer importierten Peering-Subnetzroute übereinstimmen oder an diese angepasst werden würde.
      • Erstellen Sie im Peering-VPC-Netzwerk einen neuen Subnetzadressbereich, wenn dieser Bereich genau übereinstimmen oder eine vorhandene lokale statische Route enthalten würde.

  • Eine statische Peering-Route darf kein Ziel haben, das genau mit einer lokalen Subnetzroute übereinstimmt oder in diese passt. Wenn eine lokale Subnetzroute vorhanden ist, verhindert Google Cloud Folgendes:

    • Sie können keine neue Peering-Verbindung zu einem VPC-Netzwerk herstellen, das bereits eine statische Route enthält, die genau mit dem Ziel der Subnetzroute des lokalen VPC-Netzwerks übereinstimmt, wenn die Peering-Konfiguration die benutzerdefinierte Route aus dem Peering importieren.

      Wenn zum Beispiel eine lokale Subnetzroute für 10.0.0.0/8 vorhanden ist, können Sie keine Peering-Verbindung zu einem VPC-Netzwerk mit einer statischen Route herstellen, deren Ziel genau mit 10.0.0.0/8 übereinstimmt oder in 10.0.0.0/8 passt. Beispiel: 10.0.0.0/24

    • Sie können eine vorhandene Peering-Verbindung nicht aktualisieren, wenn die aktualisierte Peering-Konfiguration zum Importieren der in Konflikt stehenden statischen Route führt.

    • Wenn VPC-Netzwerke jedoch bereits über VPC-Netzwerk-Peering verbunden sind, können Sie die folgenden Vorgänge nicht ausführen:

      • Erstellen Sie eine neue lokale Subnetzroute, deren Ziel genau mit einer importierten statischen Peering-Route übereinstimmen oder diese enthalten würde.
      • Erstellen Sie im Peering-VPC-Netzwerk eine neue statische Route, deren Ziel genau mit einer vorhandenen lokalen Subnetzroute übereinstimmen würde.

Auswirkungen des dynamischen Routingmodus

Der dynamische Routingmodus eines VPC-Netzwerks bestimmt die Regionen, in denen Präfixe, die von Cloud Routern in diesem Netzwerk erlernt werden, als lokale benutzerdefinierte dynamische Routen angewendet werden. Weitere Informationen zu diesem Verhalten finden Sie unter Auswirkungen des dynamischen Routingmodus.

Dieses Konzept wird auf VPC-Netzwerk-Peering erweitert. Der dynamische Routingmodus des Exporting-VPC-Netzwerks, also das Netzwerk mit den Cloud Routern, die die Präfixe für diese dynamischen Routen erkannt haben, bestimmt die Regionen, in denen die dynamischen Peering-Routen in Peer-Netzwerken programmiert werden können:

  • Wenn der dynamische Routingmodus des VPC-Netzwerks regional ist, exportiert dieses Netzwerk dynamische Routen nur in derselben Region wie die Cloud Router, die die Präfixe gelernt haben.

  • Wenn der dynamische Routingmodus des VPC-Netzwerks global ist, exportiert dieses Netzwerk dynamische Routen in allen Regionen.

In beiden Fällen ist der dynamische Routingmodus des importierenden VPC-Netzwerks nicht relevant.

Ein Beispiel zur Veranschaulichung dieses Verhaltens finden Sie unter Lokales VPC-Netzwerk und Peer-VPC-Netzwerk mit lokaler Konnektivität.

Interaktionen mit Subnetz und dynamischen Routen

Konflikte zwischen lokalen oder Peering-Subnetzrouten und dynamischen Routen werden behoben, wie unter Interaktionen mit benutzerdefinierten dynamischen Routen beschrieben.

Beispiele für VPC-Netzwerk-Peering

In den folgenden Beispielen werden zwei gängige VPC-Netzwerk-Peering-Szenarien veranschaulicht.

Lokales VPC-Netzwerk und Peering-VPC-Netzwerk mit lokaler Verbindung

In diesem Beispiel ist das folgende Netzwerk-Peering eingerichtet:

  • network-a ist mit network-b verbunden und network-b mit network-a.
    • network-a enthält ein Subnetz mit dem primären IPv4-Adressbereich 10.0.0.0/24 in us-west1.
    • network-a enthält ein Subnetz mit dem primären IPv4-Adressbereich 10.0.1.0/24 in europe-north1.
    • network-b enthält ein Subnetz mit dem primären IPv4-Adressbereich 10.0.2.0/23 in us-west1.
  • network-b ist über dynamisches VPN mit dynamischem Routing mit einem lokalen Netzwerk verbunden. (Dieselben Prinzipien gelten auch, wenn die Tunnel durch Cloud Interconnect-VLAN-Anhänge ersetzt werden.)
    • Für eine Verbindung von lokalen Umgebungen zu Subnetzen in network-a und network-b, muss der Cloud Router in network-b für die Verwendung von Benutzerdefiniertem Route Advertisement konfiguriert sein. Der Cloud Router bewirbt beispielsweise nur das benutzerdefinierte Präfix 10.0.0.0/22, das den Subnetzbereich 10.0.2.0/23 aus network-b und die Subnetzbereiche 10.0.0.0/24 und 10.0.1.0/24 aus network-a enthält.
    • Der Cloud Router in us-west1 lernt das Präfix 10.0.0.0/8 von einem lokalen Router. 10.0.0.0/8 verursacht keinen Konflikt, da es breiter als die Subnetz- und Peering-Subnetzrouten ist. Mit anderen Worten: 10.0.0.0/8 stimmt nicht genau überein und passt nicht in eine Subnetz- oder Peering-Subnetzroute.
  • Die Peering-Verbindung für network-b ist so konfiguriert, dass die benutzerdefinierten Routen exportiert werden. Die Peering-Verbindung für network-a ist so konfiguriert, dass die benutzerdefinierten Routen importiert werden.

Unabhängig vom Modus für dynamisches Routing von network-a gelten die folgenden Routingeigenschaften:

  • Wenn der dynamische Routingmodus von network-b globale, lokale Präfixe sind (10.0.0.0/8), die vom Cloud Router in network-b gelernt wurden, als dynamische Routen in allen Regionen der network-b und als dynamische Peering-Routen in allen Regionen der network-a hinzugefügt werden. Wenn Firewallregeln korrekt konfiguriert sind, können vm-a1, vm-a2 und vm-b mit einer lokalen Ressource mit der IP-Adresse 10.5.6.7 kommunizieren.

  • Wenn der dynamische Routingmodus von network-b in regional geändert wird, werden lokale Präfixe (10.0.0.0/8), die vom Cloud Router in network-b erkannt wurden, nur als dynamische Routen in der us-west1-Region von network-b und als Peering dynamische Routen in der Region us-west1 von network-a hinzugefügt. Wenn die Firewallregeln richtig konfiguriert sind, können nur vm-a1 und vm-b mit einer lokalen Ressource mit der IP-Adresse 10.5.6.7 kommunizieren, da dies die einzige VM in der dieselbe Region wie der Cloud Router ist.

Transitnetzwerk

Im folgenden Beispiel fungiert network-b als Transit-Netzwerk.

  • network-a ist mit network-b verbunden und network-b mit network-a.
  • network-c ist mit network-b verbunden und network-b mit network-c.
  • network-b ist über dynamisches VPN mit dynamischem Routing mit einem lokalen Netzwerk verbunden. Dieselben Prinzipien gelten auch, wenn die Tunnel durch Cloud Interconnect-VLAN-Anhänge ersetzt wurden.
    • Für eine Verbindung von lokalen Umgebungen zu Subnetzen in network-a, network-b und network-c, muss der Cloud Router in network-b für die Verwendung von Benutzerdefiniertem Route Advertisement konfiguriert sein. Beispielsweise bewirbt der Cloud Router Subnetzrouten von network-b sowie benutzerdefinierte Präfixe, die Subnetzrouten in network-a und network-c abdecken.
    • Je nach Subnetz- und dynamischen Routeninteraktionen erlernt der Cloud Router in network-b lokale Präfixe und erstellt dynamische Routen in network-b.
  • Die Peering-Verbindungen von network-b zu network-a und von network-b zu network-c wurden für den Export benutzerdefinierter Routen konfiguriert. Die Peering-Verbindungen von network-a zu network-b und von network-c bis network-b wurden für den Import benutzerdefinierter Routen konfiguriert.

Wenn Firewalls korrekt konfiguriert sind, sind folgende Szenarien möglich:

  • VM-Instanzen in network-a können andere VMs in network-b und lokalen Systemen erreichen.
  • VM-Instanzen in network-c können andere VMs in network-b und lokalen Systemen erreichen.
  • VM-Instanzen in network-b können andere VMs in network-a und network-c sowie Systeme im lokalen Netzwerk erreichen.

Da das VPC-Netzwerk-Peering nicht transitiv ist, können VM-Instanzen in network-a und network-c nicht miteinander kommunizieren, es sei denn, Sie verbinden auch die Netzwerke network-a und network-c über VPC Netzwerk-Peering.

Nächste Schritte