In diesem Dokument wird beschrieben, wie Network Connectivity Center (NCC) statische Routen in VPC-Spokes unterstützt.
Bevor Sie diese Seite lesen, sollten Sie mit den folgenden Ressourcen vertraut sein:
- Routen für eine allgemeine Übersicht über Routen in Google Cloud
- Statische Routen für eine Übersicht über statische Routen
Einführung
Im Gegensatz zu Subnetzrouten und dynamischen Routen werden statische Routen nicht von NCC-Hubs ausgetauscht. Stattdessen bietet ein Hub zusätzliche Konfigurationsflexibilität für statische Routen, die in jedem VPC-Spoke erstellt wurden.
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 statische Route verwendet kein Netzwerk-Tag.
- Der Zielbereich der statischen Route ist ein IPv4-Bereich.
- Der angegebene nächste Hop der statischen Route ist eine IPv4-Adresse eines internen Passthrough-Network-Load-Balancers.
- Google Cloud kann einen internen Passthrough-Network-Load-Balancer für den nächsten Hop an der angegebenen IP-Adresse des nächsten Hops identifizieren.
- Die NCC-Verbindungsanforderungen wurden erfüllt.
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 Arten von nächsten Hops für statische Routen finden Sie unter Projekt und Netzwerk des nächsten Hops.
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 zu finden, die eine IP-Adresse für den nächsten Hop des internen Passthrough-Network-Load-Balancers hat. Dazu wird folgender Prozess verwendet:
Wenn sich die IP-Adresse des nächsten Hops im Zielbereich einer lokalen Subnetz route befindet, Google Cloud sucht ausschließlich nach einem internen Passthrough-Network-Load-Balancer, dessen IP-Adresse der Weiterleitungsregel sich im entsprechenden lokalen Subnetz befindet. Wenn ein interner Passthrough-Network-Load-Balancer für den nächsten 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 NCC Subnetzroute befindet (die vom Hub importiert wurde), sucht Google Cloud ausschließlich nach einem internen Passthrough-Network-Load-Balancer, dessen IP-Adresse der Weiterleitungsregel sich im entsprechenden Subnetz eines anderen VPC-Spokes befindet. Wenn ein interner Passthrough-Network-Load-Balancer für den nächsten 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 NCC-Anforderungen für die Konnektivität.
Wenn Sie einen internen Passthrough-Network-Load-Balancer für den nächsten Hop in einem Routing-VPC-Netzwerk (mit Hybrid-Spokes) verwenden möchten, müssen Sie das Routing-VPC-Netzwerk dem Hub als VPC-Spoke hinzufügen. Weitere Einschränkungen im Zusammenhang mit der Verwendung eines Routing-VPC Netzwerks als VPC-Spoke finden Sie unter Überlegungen zum Austausch dynamischer Routen mit VPC-Spokes.
Wenn sich die IP-Adresse des nächsten Hops im Zielbereich einer Peering-Subnetz route befindet (die aus einem anderen Netzwerk importiert wurde, das VPC-Netzwerk-Peering verwendet), Google Cloud sucht ausschließlich nach einem internen Passthrough-Network-Load-Balancer, dessen IP-Adresse der Weiterleitungs regel sich im entsprechenden Subnetz des Peering-VPC Netzwerks befindet. Wenn ein interner Passthrough-Network-Load-Balancer für den nächsten 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.
Updates für den internen Passthrough-Network-Load-Balancer 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.
Internen Passthrough-Network-Load-Balancer für den nächsten Hop ersetzen: 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 für den nächsten Hop löschen, ohne zuerst die statische Route löschen zu müssen. Wenn Google Cloud einen Ersatz-Passthrough-Network-Load-Balancer mit derselben IP-Adresse findet, Google Cloud wechselt zu diesem Ersatz-Passthrough-Network-Load-Balancer als nächsten Hop.
Eine vorhandene statische Route ohne gültigen internen Passthrough-Network-Load-Balancer für den nächsten Hop kann betriebsbereit werden: Wenn ein gültiger interner Passthrough-Network-Load-Balancer für den nächsten Hop gefunden wird, Google Cloud verwendet diesen internen Passthrough-Network-Load-Balancer als nächsten Hop.
NCC-Konfiguration anpassen: Wenn Sie einen VPC-Spoke in eine andere Spoke-Gruppe verschieben oder Exportfilter anpassen, kann es passieren, dass kein interner Passthrough-Network-Load-Balancer für den nächsten Hop mehr gefunden wird oder ein anderer interner Passthrough-Network-Load-Balancer für den nächsten Hop gefunden und verwendet wird.
NCC-Anforderungen für die Konnektivität
Damit ein interner Passthrough-Network-Load-Balancer für den nächsten Hop in einem anderen VPC-Spoke gefunden werden kann, muss das Subnetz, das von der Weiterleitungsregel des internen Passthrough-Network-Load-Balancers verwendet wird, im VPC-Spoke zugänglich sein, in dem die statische Route definiert ist. Beide folgenden Bedingungen müssen erfüllt sein:
Die Hub Topologie muss den Austausch von Subnetzrouten ermöglichen, die den internen Passthrough-Network-Load-Balancer für den nächsten Hop enthalten.
Wenn Sie die Mesh-Topologie verwenden, gehören alle VPC-Spokes zur selben Spoke-Gruppe. Die statische Route kann in jedem VPC-Spoke vorhanden sein und der zugehörige interne Passthrough-Network-Load-Balancer für den nächsten Hop kann in jedem VPC-Spoke vorhanden sein.
Wenn Sie die Stern-Topologie 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 für den nächsten Hop in diesem Edge-VPC-Spoke oder in einem beliebigen VPC-Spoke der Center-Spoke-Gruppe befinden. Der nächste Hop kann 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 zugehörige interne Passthrough-Network-Load-Balancer für den nächsten Hop in jedem VPC-Spoke befinden (entweder in der Edge-Spoke-Gruppe oder in der Center-Spoke-Gruppe).
Der von der Weiterleitungsregel des internen Passthrough-Network-Load-Balancers verwendete Subnetzbereich muss zum Hub exportiert werden. Weitere Informationen finden Sie unter VPC-Konnektivität mit Export filtern.
Auswirkungen des globalen Zugriffs
Interne Passthrough-Network-Load-Balancer für den nächsten Hop, für die der globale Zugriff nicht aktiviert ist, sind nicht aus Regionen außerhalb der Region des Load-Balancers erreichbar. Wenn Google Cloud an der angegebenen IP-Adresse des nächsten Hops einen Load-Balancer für den nächsten Hop identifiziert hat und die NCC-Verbindungsanforderungen erfüllt sind, aber der globale Zugriff für den Load-Balancer nicht aktiviert ist, Google Cloud verwirft alle Pakete, die von VM-Instanzen, VLAN-Anhängen und Cloud VPN-Tunneln in anderen Regionen als der Region des Load-Balancers gesendet werden.
Wenn Sie dieses Verhalten ändern und den Load-Balancer für den nächsten Hop aus allen Regionen erreichbar machen möchten, aktivieren Sie den globalen Zugriff.