VPC-Spokes – Übersicht

Diese Seite bietet eine Übersicht über die Unterstützung von Virtual Private Cloud (VPC) im Network Connectivity Center.

VPC-Spokes

Network Connectivity Center bietet Inter-VPC-Netzwerkkonnektivität im großen Maßstab mit Unterstützung für VPC-Spokes. VPC-Spokes reduzieren die operative Komplexität der Verwaltung der einzelnen paarweisen VPC-Netzwerk-Peering-Verbindungen durch die Verwendung von VPC-Spokes und einem zentralen Modell für die Konnektivitätsverwaltung. VPC-Spokes können alle Subnetzrouten aus anderen Spoke-VPCs in einem Network Connectivity Center-Hub exportieren und importieren. Dies gewährleistet eine vollständige Konnektivität zwischen allen Arbeitslasten, die sich in diesen VPC-Netzwerken befinden. Der Inter-VPC-Netzwerktraffic verbleibt im Google Cloud -Netzwerk und wird nicht über das Internet geleitet, wodurch Datenschutz und Sicherheit gewährleistet sind.

VPC-Spokes können sich im selben Projekt und in derselben Organisation oder in einem anderen Projekt und einer anderen Organisation als der Network Connectivity Center-Hub befinden. Ein VPC-Spoke kann jeweils nur mit einem Hub verbunden sein.

Informationen zum Erstellen eines VPC-Spoke finden Sie unter VPC-Spoke erstellen.

Vergleich mit VPC-Netzwerk-Peering

VPC-Spokes unterstützen die Anforderungen mittlerer bis großer Unternehmen, indem sie IPv4- und IPv6-Subnetz-Routenverbindungen und IPv4-dynamische Routenverbindungen mithilfe von Hybrid-Spokes bereitstellen.

Ein VPC-Netzwerk kann gleichzeitig ein VPC-Spoke im Network Connectivity Center sein und über VPC-Netzwerk-Peering mit einem anderen VPC-Netzwerk verbunden sein, sofern das VPC-Netzwerk, mit dem gepeert wird, selbst kein VPC-Spoke ist.

Beachten Sie bei der Verwendung von VPC-Spokes und VPC-Netzwerk-Peering in Network Connectivity Center Folgendes:

Funktion VPC-Netzwerk-Peering VPC-Spokes
VPC-Netzwerke

Peerings pro VPC-Netzwerk

Aktive VPC-Spokes pro Hub

Subnetzbereiche (Subnetzrouten)

Subnetzwerkbereiche pro Peering-Gruppe

Subnetzrouten pro Routentabelle

Statische und dynamische Routen

Statische Routen pro Peering-Gruppe

Dynamische Routen pro Region und Peering-Gruppe

Eindeutige Präfixe für dynamische Routen pro Hub-Routingtabelle und Region

Der Austausch von Static Routes wird nicht unterstützt.

Exportfilter

Bestimmte Filter werden nicht unterstützt. Siehe Optionen für den Routenaustausch in der Dokumentation zu VPC-Netzwerk-Peering.

Bis zu 16 CIDR-Bereiche werden pro VPC-Spoke unterstützt.

Inter-VPC NAT

Nicht unterstützt

Unterstützt

Private Service Connect-Verbindungsweitergabe

Nicht unterstützt

Unterstützt (Vorabversion)

Verbindung des Ersteller-VPC-Spokes von anderen VPC-Netzwerken

Nicht unterstützt

Unterstützt (Vorabversion)

IP-Adressierung

Interne IPv4-Adressen, einschließlich privater IPv4-Adressen und privat verwendeter öffentlicher IPv4-Adressen. Siehe Gültige IPv4-Bereiche.

Interne und externe IPv6-Adressen

Nur private interne IPv4-Adressen, ausgenommen privat verwendete öffentliche IPv4-Adressen. Siehe Gültige IPv4-Bereiche.

Interne und externe IPv6-Adressen (Vorabversion)
IP-Adressfamilien Unterstützte Konfigurationen:
  • Nur IPv4-Subnetzbereiche austauschen
  • Sowohl IPv4- als auch IPv6-Subnetzbereiche austauschen
 Unterstützte Konfigurationen:
  • Nur IPv4-Subnetzbereiche austauschen
  • Sowohl IPv4- als auch IPv6-Subnetzbereiche austauschen
  • Nur IPv6-Subnetzbereiche austauschen
Leistung und Durchsatz (im Vergleich zu anderen VPC-Konnektivitätsmechanismen)

Niedrigste Latenz, höchster Durchsatz (VM-VM-Entsprechung)

Niedrigste Latenz, höchster Durchsatz (VM-VM-Entsprechung)

VPC-Spokes in einem anderen Projekt als einem Hub

Mit dem Network Connectivity Center können Sie VPC-Netzwerke, die als VPC-Spokes dargestellt werden, an einen einzelnen Hub in einem anderen Projekt anhängen, einschließlich eines Projekts in einer anderen Organisation. So können Sie Ihre VPC-Netzwerke über mehrere Projekte und Organisationen hinweg in großem Maßstab miteinander verbinden.

Folgende Arten von Nutzern sind zulässig:

  • Ein Hub-Administrator, der Inhaber eines Hubs in einem Projekt ist
  • Ein VPC-Netzwerk-Spoke-Administrator oder Netzwerkadministrator, der sein VPC-Netzwerk in einem anderen Projekt als Spoke zum Hub hinzufügen möchte

Der Hub-Administrator steuert mithilfe von IAM-Berechtigungen (Identity and Access Management) den VPC-Spoke in einem anderen Projekt, das mit seinem Hub verknüpft ist. Der VPC-Netzwerk-Spoke-Administrator erstellt einen Spoke in einem anderen Projekt als dem Hub. Diese Spokes sind nach der Erstellung inaktiv. Der Hub-Administrator muss sie prüfen und den Spoke entweder akzeptieren oder ablehnen. Wenn der Hub-Administrator den Spoke akzeptiert, wird er aktiviert.

Network Connectivity Center akzeptiert immer automatisch Spokes, die im selben Projekt wie der Hub erstellt wurden.

Ausführliche Informationen zum Verwalten von Hubs, die VPC-Spokes in einem anderen Projekt als dem Hub haben, finden Sie unter Hub-Verwaltung – Übersicht. Ausführliche Informationen zu Spoke-Administratoren finden Sie unter Spoke-Verwaltung – Übersicht.

Spoke-Interaktion mit VPC Service Controls

Network Connectivity Center unterstützt VPC Service Controls für projekt- und organisationsübergreifende Spokes. Wenn für einen Spoke in einem anderen Projekt aus dem Hub ein neuer VPC Service Controls-Perimeter hinzugefügt wird, können Sie keine neuen Spokes verwenden, die gegen diesen Perimeter verstoßen. Vorhandene Spokes, die Sie vor dem Hinzufügen des VPC Service Controls-Perimeters hinzugefügt haben, funktionieren jedoch weiterhin.

VPC-Konnektivität mit Exportfiltern

Mit dem Network Connectivity Center können Sie die Konnektivität aller Spoke-VPC-Netzwerke auf einen Teil der Subnetzwerke in der Spoke-VPC beschränken. So können Sie die Konnektivität einschränken:

  • Für IPv4-Subnetzbereiche:
    • Sie können den Spoke so konfigurieren, dass er entweder alle oder keine seiner IPv4-Subnetzbereiche anbietet.
    • Sie können IPv4-Adressbereiche angeben, die nicht beworben werden sollen, und eine Liste mit CIDR-Bereichen erstellen, die vom VPC-Netzwerk aus beworben werden können. Sie können auch nur eine Liste zulässiger CIDR-Bereiche angeben, um alle Bereiche außer den zulässigen zu blockieren.
  • Für IPv6-Subnetzbereiche (Vorabversion):
    • Sie können den Spoke so konfigurieren, dass er entweder alle oder keine seiner IPv6-Subnetzbereiche anbietet.

Mit Exportfiltern können Sie VPC-Spokes so konfigurieren, dass nur IPv4-Subnetzbereiche, nur IPv6-Subnetzbereiche oder sowohl IPv4- als auch IPv6-Subnetzbereiche ausgetauscht werden. Angenommen, ein Spoke hat ein VPC-Netzwerk mit einer Mischung aus Subnetz-Stack-Typen. Wenn Sie den Spoke so konfigurieren, dass nur IPv6-Subnetzbereiche exportiert werden, werden IPv6-Bereiche aus Dual-Stack- und reinen IPv6-Subnetzen ausgetauscht, aber IPv4-Subnetzbereiche aus reinen IPv4- und Dual-Stack-Subnetzen werden nicht ausgetauscht.

Exportbereiche ausschließen

Wenn Sie verhindern möchten, dass ein IPv4-Adressbereich beworben wird, verwenden Sie das Flag --exclude-export-ranges in der Google Cloud CLI oder das Feld excludeExportRanges in der API. Alle IPv4-Adressbereiche, die dem angegebenen Bereich entsprechen, werden vom Export in den Hub ausgeschlossen. Diese Filterung ist nützlich, wenn Sie Subnetze haben, die im VPC-Netzwerk privat sein müssen oder sich mit anderen Subnetzen in der Hub-Routingtabelle überschneiden können.

Exportbereiche einschließen

Mit dem Flag --include-export-ranges oder dem Feld includeExportRanges in der API können Sie festlegen, welche IP-Adressbereiche von einem VPC-Spoke beworben werden dürfen. Sie können Folgendes angeben:

  • Wenn Sie alle IPv4-Subnetzbereiche angeben möchten, können Sie ALL_PRIVATE_IPV4_RANGES angeben.
  • Wenn Sie nur bestimmte IPv4-Subnetzbereiche angeben möchten, können Sie eine Liste von CIDR-Bereichen angeben.
  • Wenn Sie alle IPv6-Subnetzbereiche angeben möchten, können Sie ALL_IPV6_RANGES angeben.

Bei IPv4-Adressbereichen können Sie eine genauere Verbindung herstellen, wenn Sie neben dem Exportfilter „Ausschließen“ auch den Exportfilter „Einschließen“ verwenden. Durch diese Filterung wird festgelegt, ob ein bestimmter Subnetzbereich aus dem VPC-Netzwerk beworben werden kann.

Hinweise

Beachten Sie Folgendes, wenn Sie die Filter „Auszuschließende Exportbereiche“ und „Einzuschließende Exportbereiche“ verwenden:

  • Die Include-Bereiche dürfen sich nicht überschneiden. Angenommen, es gibt drei IP-Adressbereiche:

    Range 1: 10.100.64.0/18

    Range 2: 10.100.250.0/21

    Range 3: 10.100.100.0/22

    Range 1 und range 2 sind gültige Einschlussbereiche, da sie sich nicht überschneiden. range 3 liegt jedoch unter range 1, was zu Überschneidungen führen kann. Daher ist range 3 ungültig.

  • Da im Network Connectivity Center bereits Ausschlussexportfilter in der Netzwerkkonfigurationsrichtlinie verfügbar sind, wirken sich sowohl die Exportfilter für einzuschließende als auch für auszuschließende CIDR-Bereiche auf die gültigen CIDR-Bereiche der Netzwerkkonfiguration aus. Wenn sowohl Exportfilter für einzuschließende als auch für auszuschließende Daten verwendet werden, müssen die IP-Adressbereiche, die eingeschlossen werden sollen, eine Übermenge der IP-Adressbereiche sein, die ausgeschlossen werden sollen.

  • Standardmäßig haben alle VPC-Konnektivitätsrichtlinien einen CIDR-Bereich von 0.0.0.0/0. Wenn Sie also beim Erstellen des VPC-Spokes keinen Include-Filter angeben, setzt Network Connectivity Center den Standard-Include-Bereich auf alle gültigen privaten IPv4-Adressen, wie in Gültige IPv4-Bereiche definiert.

  • Sie können einen Einschlussbereich verfeinern, indem Sie mehrere Ausschlussbereiche hinzufügen. Wenn Sie beispielsweise 10.1.0.0/16 als Einschlussbereich und 10.1.100.0/24 und 10.1.200.0/24 als Ausschlussbereiche angeben, wird die Konnektivität durch die Kombination von Einschluss- und Ausschlussfiltern optimiert. Dazu gehören 10.1.0.0/24 bis 10.1.99.0/24, 10.1.101.0/24 bis 10.1.199.0/24 und 10.1.201.0/24 bis 10.1.255.0/24.

  • Vorhandene Subnetzbereiche funktionieren weiterhin wie erwartet. Überschneidungen mit Include- und Exclude-Bereichen beim Erstellen neuer Subnetzbereiche führen zu einem Fehler.

Beispiele für ungültige neue Subnetzbereiche

Die folgenden Beispiele zeigen ungültige Subnetzbereiche:

  • Überschneidung mit dem Ausschlussbereich: Angenommen, es gibt die folgenden IP-Adressbereiche.

    Zu berücksichtigender Bereich: 10.0.0.0/8

    Exclude range 4: 10.1.1.0/24

    Subnet range 4: 10.1.0.0/16

    In diesem Fall enthält der Include-Bereich subnet range 4. Es ist jedoch ein Obermenge von exclude range 4. Daher ist subnet range 4 ungültig.

  • Überschneidung mit dem Include-Bereich: Angenommen, es gibt die folgenden IP-Adressbereiche:

    Zu berücksichtigender Bereich: 10.1.1.0/24

    Subnet range 5: 10.1.0.0/16

    Subnet range 5 überschneidet sich mit dem Include-Bereich und ist daher ungültig.

Wenn Sie beim Erstellen eines Subnetzes einen ungültigen Subnetzbereich eingeben, erhalten Sie einen Invalid IPCidrRange-Fehler, der in etwa so aussieht:

Invalid IPCidrRange: CIDR_RANGE conflicts with existing subnetwork SUBNET_RANGE in region REGION

Voreingestellte Topologien

Mit dem Network Connectivity Center können Sie die gewünschte Konnektivitätskonfiguration für alle VPC-Spokes angeben. Sie können eine der folgenden beiden vordefinierten Topologien auswählen:

  • Mesh-Netzwerktopologie
  • Sterntopologie

Wenn Sie einen Hub mit dem Befehl gcloud network-connectivity hubs create erstellen, wählen Sie die vordefinierte Mesh- oder Sterntopologie aus. Wenn die Topologie nicht angegeben ist, wird standardmäßig „Mesh“ verwendet. Die beim Erstellen des Hubs festgelegte Topologie kann nicht mehr geändert werden.

Wenn Sie die Topologieeinstellungen eines Spokes ändern möchten, können Sie den Spoke löschen und einen neuen Spoke mit einem neuen Hub erstellen, der eine andere Topologie verwendet.

Mesh-Netzwerktopologie

Die Mesh-Topologie bietet eine Netzwerkkonnektivität im großen Maßstab zwischen VPC-Spokes. Mit dieser Topologie können alle Spokes miteinander verbunden werden und miteinander kommunizieren. Subnetze innerhalb dieser VPC-Speichen sind vollständig erreichbar, es sei denn, Sie geben Exportfilter ausschließen an. Wenn zwei oder mehr Arbeitslast-VPC-Netzwerke so konfiguriert sind, dass sie einem Network Connectivity Center-Hub als Spokes beitreten, erstellt Network Connectivity Center standardmäßig eine vollständige Mesh-Konnektivität zwischen den einzelnen Spokes.

Alle Speichen innerhalb der Mesh-Topologie gehören zu einer einzigen Standard-Gruppe. Die Mesh-Topologie wird für VPC- und Hybrid-Spoke-Typen unterstützt.

Das folgende Diagramm zeigt die Mesh-Topologie-Verbindung im Network Connectivity Center.

Mesh-Topologie-Verbindung des Network Connectivity Centers
Netzwerkkonnektivität des Network Connectivity Centers mit Mesh-Topologie (zum Vergrößern anklicken)

Sterntopologie

Wenn Sie für die Konnektivität eine Sterntopologie verwenden, erreichen die Edge-Spokes und ihre zugehörigen Subnetze nur die angegebenen Center-Spokes, während die Center-Spokes alle anderen Spokes erreichen können. So wird die Segmentierung und Verbindungstrennung über Edge-VPC-Netzwerke hinweg sichergestellt.

Da VPC-Spokes an einen Hub in einem anderen Projekt angehängt werden können, können sie aus verschiedenen Verwaltungsdomains stammen. Diese Spokes, die sich in einem anderen Projekt als dem Hub befinden, müssen möglicherweise nicht mit jedem anderen Spoke im Network Connectivity Center-Hub kommunizieren.

Sie können die Sterntopologie für die folgenden Anwendungsfälle auswählen:

  • Arbeitslasten, die in verschiedenen VPC-Netzwerken ausgeführt werden und keine Verbindung untereinander, sondern nur Zugriff auf die VPC-Netzwerke über das zentrale VPC-Netzwerk mit freigegebenen Diensten benötigen.

  • Sicherheitskontrolle der Kommunikation über mehrere VPC-Netzwerke, bei der der Traffic eine Reihe von zentralen Netzwerk-Virtuellen-Appliances (NVAs) durchlaufen muss.

Das folgende Diagramm zeigt eine Sterntopologie in Network Connectivity Center. center-vpc-a und center-vpc-b sind mit der Mittelgruppe und edge-vpc-c und edge-vpc-d mit der Randgruppe verknüpft. In diesem Fall können edge-vpc-c und edge-vpc-d über die Sterntopologie mit center-vpc-a und center-vpc-b verbunden werden und ihre Subnetze an die zentrale Gruppe weitergeben, aber nicht miteinander verbunden sein (keine direkte Erreichbarkeit zwischen edge-vpc-c und edge-vpc-d). center-vpc-a und center-vpc-b sind dagegen miteinander und mit edge-vpc-c und edge-vpc-d verbunden, sodass die VPCs der zentralen Gruppe von den VPCs der Edge-Gruppe vollständig erreichbar sind.

Sterntopologie-Verbindung des Network Connectivity Centers
Sterntopologie-Verbindung des Network Connectivity Centers (zum Vergrößern anklicken)

Spoke-Gruppen

Eine Spoke-Gruppe ist eine Teilmenge von Spokes, die mit einem Hub verbunden sind. Wenn Sie das Network Connectivity Center mit einer Sterntopologie konfigurieren möchten, müssen Sie alle VPC-Spokes in zwei verschiedene Gruppen unterteilen, die auch als Routingdomains bezeichnet werden:

  1. Eine zentrale Gruppe von Spokes, die mit allen anderen Spokes kommunizieren, die mit dem Hub verbunden sind
  2. Eine Randgruppe von Speichen, die nur mit Speichen kommunizieren, die zur Mittelgruppe gehören

Ein VPC-Spoke kann jeweils nur zu einer Gruppe gehören. Gruppen werden automatisch erstellt, wenn Sie einen Hub erstellen.

Ein Hub-Administrator kann eine Spoke-Gruppe mit dem Befehl gcloud network-connectivity hubs groups update aktualisieren. Der Hub-Administrator kann eine Liste mit Projekt-IDs oder Projektnummern hinzufügen, um die automatische Annahme für Spokes zu aktivieren. Wenn die automatische Annahme aktiviert ist, wird der Spoke aus dem Projekt mit automatischer Annahme automatisch mit dem Hub verbunden, ohne dass ein einzelner Spoke-Vorschlag überprüft werden muss.

Mit dem Befehl gcloud network-connectivity hubs groups list --hub können Sie die Gruppen center und edge als verschachtelte Ressourcen für einen bestimmten Hub auflisten. Bei Hubs, die mit einer Mesh-Topologie erstellt wurden, wird in der Ausgabe die Standardgruppe zurückgegeben. Für Hubs, die mit einer Sterntopologie erstellt wurden, werden in der Ausgabe die Gruppen center und edge zurückgegeben.

Ausführliche Informationen zum Konfigurieren der Mesh- oder Sterntopologie für Ihre VPC-Spokes finden Sie unter Hub konfigurieren.

Beschränkungen

In diesem Abschnitt werden die Einschränkungen von VPC-Spokes im Allgemeinen und ihre Verknüpfung mit einem Hub in einem anderen Projekt beschrieben. Diese Einschränkungen gelten auch für VPC-Spokes von Produzenten (Vorabversion).

Einschränkungen von VPC-Spokes

  • VPC-Netzwerke können auf exklusive Weise über den Network Connectivity Center-Hub oder über VPC-Netzwerk-Peering miteinander verbunden werden.
  • Sie können kein VPC-Netzwerk-Peering zwischen zwei VPC-Spokes verwenden, die mit demselben Network Connectivity Center-Hub verbunden sind. Beachten Sie jedoch Folgendes:
    • Für einen Ersteller-VPC-Spoke ist eine Peering-Verbindung zu einem VPC-Spoke im selben Hub erforderlich. Zwischen dem Ersteller-VPC-Spoke und dem zugehörigen VPC-Spoke wird keine Verbindung über das Network Connectivity Center hergestellt.
    • Sie können einen mit Network Connectivity Center verbundenen VPC-Spoke haben, der über VPC-Netzwerk-Peering mit einer separaten VPC verbunden ist, die nicht Teil von Network Connectivity Center ist.
  • VPCs, die über Network Connectivity Center und VPC-Netzwerk-Peering in einer beliebigen Kombination verbunden sind, sind nicht transitiv.
  • Der Austausch statischer Routen über VPC-Spokes wird nicht unterstützt.
  • Routen, die auf interne virtuelle Pass-Through IP-Adressen des Netzwerk-Load-Balancers in anderen VPC-Spokes verweisen, werden nicht unterstützt.
  • Die Aktualisierung von export range filters nach der Erstellung des VPC-Spoke wird nicht unterstützt.
  • IPv6-basierte interne Passthrough-Network Load Balancer sind zwischen VPC-Spokes nicht erreichbar.
  • Der dynamische IPv6-Routenaustausch wird nicht unterstützt.
  • VPC-Netzwerke im automatischen Modus werden nicht als VPC-Spokes unterstützt. Sie können vom automatischen Modus zu einem benutzerdefinierten VPC-Netzwerk wechseln, mit dem Sie Subnetzpräfixe für jede Region in Ihrem VPC-Netzwerk manuell definieren können. Diese Aktion kann nicht rückgängig gemacht werden.

Einschränkungen beim Austausch dynamischer Routen

  • Nur IPv4: Das Network Connectivity Center unterstützt nur den Austausch dynamischer IPv4-Routen. Der Austausch von dynamischen IPv6-Routen wird nicht unterstützt.

  • Kompatibilität von Hybrid-Spokes mit Sterntopologie: Für einen Hub, der für die Verwendung der Sterntopologie konfiguriert ist, gelten die folgenden Einschränkungen für seine Hybrid-Spokes:

    • Hybrid-Spokes mit aktivierter Site-to-Site-Datenübertragung werden nur in der zentralen Spoke-Gruppe unterstützt.
    • Hybrid-Speichen, für die die Site-to-Site-Datenübertragung nicht aktiviert ist, können entweder zur Gruppe der zentralen Speichen oder zur Gruppe der Edge-Speichen gehören.

  • Routing-VPC-Netzwerke, die auch VPC-Spokes sind: Network Connectivity Center unterstützt nur dann zwei oder mehr Routing-VPC-Netzwerke auf demselben Hub, wenn keines der Routing-VPC-Netzwerke auch VPC-Spokes sind. Wenn ein Network Connectivity Center-Hub ein einzelnes VPC-Routingnetzwerk hat, kann dieses VPC-Routingnetzwerk optional auch ein VPC-Spoke sein:

    • Wenn Sie weitergeleitete Private Service Connect-Verbindungen für lokale Netzwerke über die Hybrid-Spokes des Hubs verfügbar machen möchten, muss das VPC-Netzwerk mit dem einzelnen Routing des Hubs auch als VPC-Spoke verbunden sein.

    • Wenn Sie keine propagierten Private Service Connect-Verbindungen für lokale Netzwerke über die Hybrid-Spokes des Hubs verfügbar machen müssen, empfehlen wir, kein Routing-VPC-Netzwerk als VPC-Spoke zu konfigurieren, damit der Hub zwei oder mehr Routing-VPC-Netzwerke unterstützen kann.

  • Regeln für die Interaktion dynamischer Routen: Innerhalb eines VPC-Netzwerks für das Routing müssen Sie für jedes eindeutige Ziel einer dynamischen Route mit einem nächsten Hop in einem Hybrid-Spoke dafür sorgen, dass alle anderen dynamischen Routen, unabhängig von der Priorität, deren Ziele genau mit dem Ziel der eindeutigen dynamischen Route übereinstimmen oder in dieses Ziel passen, Cloud VPN-Tunnel oder VLAN-Anhänge als nächsten Hop ebenfalls in einem Hybrid-Spoke haben. Außerdem müssen Sie dafür sorgen, dass für diese Hybrid-Spokes dieselbe Einstellung für die Site-to-Site-Datenübertragung verwendet wird (entweder aktiviert oder deaktiviert).

    • Wenn sich nur einige Next Hops für dynamische Routen mit einem gemeinsamen Ziel in Hybrid-Spokes befinden, kann Network Connectivity Center keine zuverlässigen dynamischen Routen austauschen, die dieses Ziel verwenden, mit VPC-Spokes am Hub. Daher erhalten VPC-Spokes diese dynamischen Routen möglicherweise nicht.

    • Das Network Connectivity Center führt keine ECMP-Berechnung für alle nächsten Hops von dynamischen Routen des Hybrid-Spokes durch, wenn für einige Hybrid-Spokes die Site-to-Site-Datenübertragung aktiviert, für andere jedoch deaktiviert ist. Wenn sich dynamische Routen mit einem gemeinsamen Ziel in Hybrid-Spokes befinden, ohne dass die Einstellungen für die Standort-zu-Standort-Datenübertragung übereinstimmen, entsprechen die nächsten Hops für die Standort-zu-Standort-Datenübertragung oder für die Verbindung zwischen VPC-Spokes und lokalen Netzwerken möglicherweise nicht Ihren Erwartungen.

  • Regeln für die Interaktion von dynamischen und statischen Routen: Für jedes eindeutige Ziel einer dynamischen Route in einem Routing-VPC-Netzwerk, das einen nächsten Hop in einem Hybrid-Spoke hat, müssen Sie dafür sorgen, dass es unabhängig von der Priorität keine lokalen statischen Routen gibt, deren Ziele genau mit dem Ziel der dynamischen Route übereinstimmen oder in diese passen.

    • Wenn eine lokale statische Route im Routing-VPC-Netzwerk dasselbe Ziel wie eine dynamische Route eines Hybrid-Spokes hat, verlieren VPC-Spokes möglicherweise die Verbindung zum Ziel der dynamischen Route.

    • Wenn eine lokale statische Route in einem Routing-VPC-Netzwerk ein Ziel hat, das in das Ziel einer dynamischen Route eines Hybrid-Spokes passt, verlieren VPC-Spokes die Verbindung zum Ziel der statischen Route.

Wartezeit nach dem Löschen eines VPC-Spokes

Bei einem neuen Spoke für dasselbe VPC-Netzwerk, das mit einem anderen Hub verbunden ist, müssen Sie mindestens 10 Minuten warten. Wenn eine ausreichende Wartezeit nicht möglich ist, wird die neue Konfiguration möglicherweise nicht wirksam. Diese Wartezeit ist nicht erforderlich, wenn das VPC-Netzwerk demselben Hub als Spoke hinzugefügt wird.

Kontingente und Limits

Wenn Sie den dynamischen Routenaustausch verwenden, sollten Sie die Anzahl der dynamischen Routen pro Hub sorgfältig im Blick behalten. Bei diesem Kontingent wird die Nutzung nur nach Ziel (Prefix) gezählt, ohne Rücksicht auf die Priorität oder den nächsten Hop einer dynamischen Route. Wenn die Nutzung dieses Kontingents das Limit überschreitet, verwirft das Network Connectivity Center Routen nach Ziel. Wenn ein Ziel verworfen wird, werden alle dynamischen Routen mit diesem Ziel – unabhängig von Priorität oder nächstem Hop – nicht mehr an den Hub gesendet.

Ausführliche Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

Abrechnung

Spoke-Stunden

Spoke-Stunden werden dem Projekt in Rechnung gestellt, in dem sich die Spoke-Ressource befindet, und folgen den Standardpreisen für Spoke-Stunden. Spoke-Stunden werden nur in Rechnung gestellt, wenn sich der Spoke im Status ACTIVE befindet.

Ausgehender Traffic

Ausgehender Traffic wird dem Projekt der Spoke-Ressource in Rechnung gestellt, von der der Traffic stammt. Die Preise sind unabhängig davon, ob der Traffic Projektgrenzen überschreitet, gleich.

Service Level Agreement

Informationen zum Service Level Agreement (SLA) für Network Connectivity Center finden Sie unter Service Level Agreement (SLA) für Network Connectivity Center.

Preise

Informationen zu den Preisen finden Sie unter Preise für Network Connectivity Center.

Nächste Schritte