Statische Routen – Übersicht

In diesem Dokument wird beschrieben, wie das Network Connectivity Center statische Routen in VPC-Spokes unterstützt.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Ressourcen vertraut:

  • Routen für eine allgemeine Übersicht über Routen in Google Cloud
  • Statische Routen – Übersicht über statische Routen

Einführung

Im Gegensatz zu Subnetzrouten und dynamischen Routen werden statische Routen nicht über Network Connectivity Center-Hubs ausgetauscht. Stattdessen bietet ein Hub zusätzliche Konfigurationsflexibilität für statische Routen, die in jedem VPC-Spoke erstellt werden.

Eine statische Route in einem VPC-Spoke kann einen nächsten Hop in einem anderen VPC-Spoke verwenden, wenn alle folgenden Bedingungen erfüllt sind:

Die zusätzliche Konfigurationsflexibilität für statische Routen gilt nur für VPC-Spokes, nicht für VPC-Netzwerke, die reine Routing-VPC-Netzwerke sind (die nur Hybrid-Spokes enthalten).

Einen Vergleich mit anderen Typen von statischen Routen für nächste Hops finden Sie unter Projekt und Netzwerk für den nächsten Hop.

Internen Passthrough-Network Load Balancer für den nächsten Hop identifizieren

Google Cloud versucht, einen internen Passthrough Network Load Balancer für eine statische Route mit einer IP-Adresse des internen Passthrough Network Load Balancers als nächsten Hop zu finden. Dazu wird folgender Prozess verwendet:

  • Wenn sich die IP-Adresse des nächsten Hops im Zielbereich einer lokalen Subnetzroute befindet, wird ausschließlich nach einem internen Passthrough-Network Load Balancer gesucht, dessen IP-Adresse der Weiterleitungsregel sich im entsprechenden lokalen Subnetz befindet. Google Cloud Wenn ein interner Passthrough-Network-Load-Balancer als nächster Hop gefunden wird, befinden sich sowohl die statische Route als auch der nächste Hop im selben VPC-Netzwerk.

  • Wenn sich die IP-Adresse des nächsten Hops im Zielbereich einer Network Connectivity Center-Subnetzroute befindet (aus dem Hub importiert): Google Cloud wird ausschließlich nach einem internen Passthrough Network Load Balancer gesucht, dessen IP-Adresse der Weiterleitungsregel sich im entsprechenden Subnetz eines anderen VPC-Spoke befindet. Wenn ein interner Passthrough Network Load Balancer als nächster Hop gefunden wird, befindet sich die statische Route in einem VPC-Spoke und der nächste Hop in einem anderen VPC-Spoke.

    • Weitere Informationen dazu, wie ein interner Passthrough-Network Load Balancer in einem anderen VPC-Spoke gefunden werden kann, finden Sie unter Network Connectivity Center-Anforderungen für die Konnektivität.

    • Wenn Sie einen internen Next Hop Passthrough Network Load Balancer in einem VPC-Routingnetzwerk (mit Hybrid-Spokes) verwenden möchten, müssen Sie das VPC-Routingnetzwerk dem Hub als VPC-Spoke hinzufügen. Weitere Einschränkungen für die Verwendung eines Routing-VPC-Netzwerks als VPC-Spoke finden Sie unter Einschränkungen des dynamischen Routenaustauschs.

  • Wenn sich die IP-Adresse des nächsten Hops im Zielbereich einer Peering-Subnetzroute befindet, die aus einem anderen Netzwerk importiert wurde, das VPC Network Peering verwendet,Google Cloud wird ausschließlich nach einem internen Passthrough Network Load Balancer gesucht, dessen IP-Adresse der Weiterleitungsregel im entsprechenden Subnetz des verbundenen VPC-Netzwerks liegt. Wenn ein interner Passthrough Network Load Balancer als nächster Hop gefunden wird, befindet sich die statische Route in einem VPC-Netzwerk und der nächste Hop im Peering-VPC-Netzwerk.

Wenn kein interner Passthrough-Network Load Balancer für den nächsten Hop gefunden wird, werden Pakete, die an den Zielbereich der statischen Route gesendet werden, verworfen.

Aktualisierungen des internen Passthrough-Network-Load-Balancers für den nächsten Hop

Google Cloud versucht kontinuierlich, einen internen Passthrough-Network-Load-Balancer für den nächsten Hop zu identifizieren. In den folgenden Beispielsituationen wird der nächste Hop für eine statische Route automatisch aktualisiert.

  • Ersetzen des internen Passthrough-Network-Load-Balancers als nächster Hop: Wenn der nächste Hop für eine statische Route die IP-Adresse eines internen Passthrough-Network-Load-Balancers ist, können Sie den internen Passthrough-Network-Load-Balancer als nächster Hop löschen, ohne die statische Route zuerst löschen zu müssen. Wenn Google Cloud einen Ersatz-Passthrough-Network-Load-Balancer mit derselben IP-Adresse findet,wechselt Google Cloud zum Ersatz-Passthrough-Network-Load-Balancer als nächstem Hop.

  • Eine vorhandene statische Route ohne gültigen internen Passthrough-Network-Load-Balancer als nächsten Hop kann in Betrieb genommen werden: Wenn ein gültiger interner Passthrough-Network-Load-Balancer als nächster Hop gefunden wird, Google Cloudwird dieser interne Passthrough-Network-Load-Balancer als nächster Hop verwendet.

  • Anpassen der Network Connectivity Center-Konfiguration: Wenn Sie einen VPC-Spoke in eine andere Spoke-Gruppe verschieben oder Exportfilter anpassen, kann es sein, dass ein interner Passthrough-Network-Load-Balancer für den nächsten Hop nicht mehr gefunden wird oder ein anderer interner Passthrough-Network-Load-Balancer für den nächsten Hop gefunden und verwendet wird.

Anforderungen an die Verbindung für Network Connectivity Center

Damit ein interner Passthrough-Network-Load-Balancer als nächster Hop in einem anderen VPC-Spoke gefunden werden kann, muss das von der Weiterleitungsregel des internen Passthrough-Network-Load-Balancers verwendete Subnetz im VPC-Spoke, in dem die statische Route definiert ist, zugänglich sein. Beide der folgenden Bedingungen müssen erfüllt sein:

  1. Die Hub-Topologie muss den Austausch von Subnetzrouten ermöglichen, die den internen Passthrough-Network-Load-Balancer als nächsten Hop enthalten.

    • Wenn Sie die Mesh-Topologie verwenden, sind alle VPC-Spokes Teil derselben Spoke-Gruppe. Die statische Route kann in einem beliebigen VPC-Spoke vorhanden sein und der interne Passthrough-Network-Load-Balancer als nächster Hop kann in einem beliebigen VPC-Spoke vorhanden sein.

    • Wenn Sie die Sterntopologie verwenden, gelten die folgenden Anforderungen:

      • Wenn sich die statische Route in einem VPC-Spoke der Edge-Spoke-Gruppe befindet, kann sich der interne Passthrough Network Load Balancer als nächster Hop in diesem Edge-VPC-Spoke oder in einem beliebigen VPC-Spoke der Center-Spoke-Gruppe befinden. Der nächste Hop darf sich nicht in einem anderen VPC-Spoke der Edge-Spoke-Gruppe befinden.

      • Wenn sich die statische Route in einem VPC-Spoke der Center-Spoke-Gruppe befindet, kann sich der interne Passthrough Network Load Balancer als nächster Hop in einem beliebigen VPC-Spoke (entweder in der Edge-Spoke-Gruppe oder in der Center-Spoke-Gruppe) befinden.

  2. Der von der Weiterleitungsregel des internen Passthrough-Network Load Balancers verwendete Subnetzbereich muss in den Hub exportiert werden. Weitere Informationen finden Sie unter VPC-Verbindung mit Exportfiltern.

Auswirkungen des globalen Zugriffs

Interne Passthrough Network Load Balancer, für die der globale Zugriff nicht aktiviert ist, sind nicht aus Regionen außerhalb der Region des Load Balancers erreichbar. Wenn Google Cloud einen Load-Balancer als nächsten Hop an der angegebenen IP-Adresse für den nächsten Hop identifiziert hat und die Anforderungen an die Network Connectivity Center-Verbindung erfüllt sind, aber der globale Zugriff für den Load-Balancer nicht aktiviert ist, Google Cloud werden alle Pakete verworfen,die von VM-Instanzen, VLAN-Anhängen und Cloud VPN-Tunneln in Regionen gesendet werden, die sich von der Region des Load-Balancers unterscheiden.

Wenn Sie dieses Verhalten ändern und den Load-Balancer als nächsten Hop aus allen Regionen erreichbar machen möchten, aktivieren Sie den globalen Zugriff.

Nächste Schritte