Kontingente und Limits

Auf dieser Seite werden Kontingente und Limits für Network Connectivity-Produkte beschrieben. Informationen zum Ändern eines Kontingents finden Sie unter Weitere Kontingente anfordern. Limits können normalerweise nicht erhöht werden, sofern nicht ausdrücklich angegeben.

Cloud VPN

Kontingente

In dieser Tabelle sind wichtige Kontingente pro Projekt aufgeführt. Weitere Kontingente finden Sie auf der Seite Kontingente der Google Cloud Console.

Element Kontingent Hinweise
VPN-Gateways Kontingent Nur für HA VPN
Externe VPN-Gateways Kontingent Nur für HA VPN
VPN-Tunnel Kontingent Dieses Kontingent entspricht der Gesamtzahl von Tunneln des klassischen VPN und HA VPN.
Router Kontingent

Dieses Kontingent entspricht der Anzahl der Cloud Router, die Sie in Ihrem Projekt in jedem beliebigen Netzwerk und in jeder beliebigen Region erstellen können. Netzwerke haben auch ein Limit bezüglich der Anzahl der Cloud Router in einer bestimmten Region. Weitere Informationen finden Sie unter Kontingente und Limits für Cloud Router.

Die Anzahl der Cloud Router unterliegt dem Kontingent und den Limits für Cloud Router und ist unabhängig vom Typ des Cloud-VPN-Gateways (klassisches VPN oder HA VPN), dem ein Tunnel zugeordnet ist. Allerdings wird das Kontingent auf beide Gateway-Typen gleichermaßen angewendet.

Ziel-VPN-Gateways Kontingent Nur für klassisches VPN
Weiterleitungsregeln Kontingent Nur für klassisches VPN

Limits

Für Cloud VPN gelten die folgenden Limits. In dieser Tabelle steht VPN-Tunnel entweder für den Tunnel eines klassischen VPN oder eines HA VPN. Wenn nichts anderes angegeben ist, können diese Limits nicht erhöht werden.

Element Limit Hinweise
Bandbreite pro VPN-Tunnel 250.000 Pakete pro Sekunde für die Summe von Ein- und Ausgang

250.000 Pakete pro Sekunde entsprechen ungefähr 1 Gbit/s bis 3 Gbit/s, je nach durchschnittlicher Paketgröße im Tunnel.

Cloud VPN drosselt lediglich den ausgehenden IPsec-Traffic. Der eingehende Traffic wird nicht gedrosselt.

Weitere Informationen finden Sie unter Netzwerkbandbreite.

Bekannte Probleme

Sie sollten Folgendes beachten:

Cloud Interconnect

Kontingente

In dieser Tabelle sind wichtige Kontingente aufgeführt, die pro Projekt gelten. Weitere Kontingente finden Sie auf der Seite Kontingente der Google Cloud Console.

Element Kontingent Hinweise
Interconnect-Verbindungen Kontingent

Die Anzahl der Dedicated Interconnect-Verbindungen pro Projekt.

Interconnect-Verbindungen sind nicht mit Regionen oder VPC-Netzwerken verknüpft.

VLAN-Anhänge Kontingent

Die Anzahl der VLAN-Anhänge, die Sie in den einzelnen Regionen für Ihr Projekt konfigurieren können. Dazu gehören VLAN-Anhänge für Dedicated Interconnect und Partner Interconnect.

Zusätzlich zu diesem Kontingent gilt die Beschränkung für VLAN-Anhänge pro Interconnect.

VLAN-Anhänge pro Interconnect Kontingent Die Anzahl der VLAN-Anhänge, die Sie für eine einzelne Interconnect-Verbindung konfigurieren können.
Gesamtbandbreite für VLAN-Anhänge in Mbit/s Kontingent

Die Bandbreitenkapazität aller VLAN-Anhänge in einer Region für ein bestimmtes Projekt, unabhängig von Interconnect-Verbindungen.

Zusätzlich gelten die in der Tabelle Limits aufgeführten Limits.

Cloud Router Kontingent

Die Anzahl der Cloud Router, die Sie in Ihrem Projekt in jedem beliebigen Netzwerk und in jeder beliebigen Region erstellen können.

Netzwerke haben auch ein Limit bezüglich der Anzahl der Cloud Router in einer bestimmten Region.

Weitere Informationen finden Sie unter Kontingente und Limits für Cloud Router.

Limits

Für Interconnect-Verbindungen und VLAN-Anhänge gelten die folgenden Limits. Wenn nichts anderes angegeben ist, können diese Limits nicht erhöht werden.

Element Limit Hinweise
Maximale Anzahl physischer Netzwerkverbindungen pro Interconnect-Verbindung 8 x 10 Gbit/s-Netzwerkverbindungen (80-Gbit/s) oder
2 x 100 Gbit/s-Netzwerkverbindungen (200 Gbit/s)

Eine Interconnect-Verbindung ist eine logische Verbindung zu Google. Sie besteht aus einer oder mehreren physischen Netzwerkverbindungen. Die Netzwerkverbindungen sind als folgende Optionen verfügbar:

  • Netzwerkverbindungen von bis zu 2 x 100 Gbit/s (200 Gbit/s).
  • Bei 10 Gbit/s können Sie auf bis zu acht Netzwerkverbindungen inkrementieren, um die maximale Bandbreite aller VLAN-Anhänge, die die Interconnect-Verbindung nutzen, auf 80 Gbit/s zu erhöhen.

    Multiplizieren Sie die Zahl der physischen Netzwerkverbindungen mit der Bandbreite pro Netzwerkverbindung (10 Gbit/s), um die Bandbreite zu ermitteln.

Maximale Bandbreite pro VLAN-Anhang Kapazitäten von 50 Mbit/s bis 50 Gbit/s

Die maximal mögliche Bandbreite pro VLAN-Anhang hängt von der angeforderten Bandbreitenkapazität ab. Informationen zu Kapazitäten finden Sie auf der Seite „Preise“. Bei Partner Interconnect bieten nicht alle Dienstanbieter alle Kapazitäten.

Der Durchsatz einzelner Trafficflüsse in einem VLAN-Anhang ist begrenzt. Für einen maximalen Durchsatz müssen Sie mehrere 5-Tupel-Flüsse (z. B.: 10+) mit Paketgrößen innerhalb der MTU des VLAN-Anhangs verwenden.

Maximale Gesamtpaketrate pro VLAN-Anhang

Datenplane v1: Diese Rate variiert je nach Kapazität des Anhangs:

  • Die maximale Rate für einen VLAN-Anhang mit einer Geschwindigkeit von 50 Gbit/s beträgt 6,25 Mio. Pakete pro Sekunde (pps).
  • Die maximale Rate für einen VLAN-Anhang mit einer Geschwindigkeit von 10 Gbit/s beträgt 1,25 Mio. Pakete pro Sekunde (pps).
Die maximale Paketrate für den gesamten VLAN-Anhang.
Maximale Bandbreite pro Trafficfluss in einem VLAN-Anhang
  • Dataplane v2: 10 Gbit/s
  • Dataplane v1: 3 Gbit/s
  • Selbst wenn Sie Ihren Anhang mit einer höheren Bandbreite konfigurieren, ist ein einzelner Trafficfluss möglicherweise auf den Höchstwert begrenzt, der für die Dataplane-Version definiert ist.

Ein Trafficabflauf zu einem Ziel in einem VPC-Netzwerk wird entweder durch einen 5-Tupel-Hash für nicht fragmentierte Pakete oder einen 3-Tupel-Hash für fragmentierte Pakete angegeben. Außerdem werden Trafficabläufe, die privaten Google-Zugriff für lokale Hosts verwenden, durch einen 3-Tupel-Hash identifiziert.

  • Ein 5-Tupel-Hash besteht aus einem Protokoll, der Quell-IP-Adresse, dem Quellport, der Ziel-IP-Adresse und dem Zielport.
  • Ein 3-Tupel-Hash besteht aus einem Protokoll, der Quell-IP-Adresse und der Ziel-IP-Adresse.

In den folgenden Fällen ist die maximale Bandbreite niedriger als 3 Gbit/s oder 10 Gbit/s:

  • Falls die Bandbreitenkapazität des VLAN-Anhangs unter dem Maximum für die Dataplane-Version liegt (3 Gbit/s oder 10 Gbit/s), wird die Bandbreite pro Trafficfluss durch die Bandbreite des VLAN-Anhangs begrenzt.
  • Falls die maximale Paketrate pro Trafficfluss erreichen (siehe nächsten Abschnitt).
Maximale Paketrate pro Trafficfluss über einen VLAN-Anhang
  • Dataplane v2: 10.000.000 Pakete pro Sekunde (pps)
  • Dataplane v1: 250.000 Pakete pro Sekunde
Die maximale Rate von Paketen pro Trafficfluss. Sie wird durch einen 5-Tupel-Hash für nicht fragmentierte Pakete und durch einen 3-Tupel-Hash für fragmentierte Pakete angegeben (siehe vorheriger Abschnitt).
Maximale Übertragungseinheit (MTU)
  • 1.440 Byte
  • 1.460 Byte
  • 1.500 Byte
  • 8.896 Byte
Abhängig von der MTU-Einstellung des VLAN-Anhangs ist die Größe des größten IP-Adresspakets erforderlich, das über einen VLAN-Anhang übertragen werden kann. Weitere Informationen finden Sie im Abschnitt Cloud Interconnect-MTU.
Maximale Lebensdauer des Kopplungsschlüssels für den (Partner Interconnect) VLAN-Anhang 28 Tage

Die maximale Zeitspanne, die zwischen der Erstellung eines Kopplungsschlüssels für einen (Partner Interconnect) VLAN-Anhang und der erfolgreichen Bereitstellung des Anhangs durch den Dienstleister verstreichen darf.

Sollte ein Kopplungsschlüssel nicht mehr gültig sein, löschen Sie ihn einfach und erstellen Sie einen neuen Kopplungsschlüssel, den der Partner Interconnect-Dienstleister nutzen kann.

Limits für Cloud Router

Da Cloud Router für Dedicated Interconnect und Partner Interconnect erforderlich ist, gelten alle Kontingente und Limits für Cloud Router.

Die maximale Anzahl an erkannten Routen und die Anzahl der beworbenen Routen ist begrenzt. Weitere Informationen finden Sie auf der Seite Kontingente und Limits für Cloud Router.

Cloud Router

Kontingente

In dieser Tabelle sind wichtige Kontingente pro Projekt aufgeführt. Weitere Kontingente finden Sie auf der Seite Kontingente und Systemlimits der Google Cloud Console.

Element Kontingent Hinweise
Cloud Router pro Projekt Kontingent Unabhängig vom Kontingent ist jedes Netzwerk auf fünf Cloud Router pro Region beschränkt. Siehe Limits

Einzigartige Präfixe für dynamische Cloud Router-Routen aus der eigenen Region pro Region und VPC-Netzwerk

Die maximale Anzahl eindeutiger Zielpräfixe für erkannte Routen, die von allen Cloud Routern in derselben Region auf Subnetze in einer Region angewendet werden können. Das wird als from-own-region-Kontingent einer Region bezeichnet.

Kontingent

Auf dieses Kontingent werden sowohl IPv4- als auch IPv6-Präfixe angerechnet.

Alle erkannten Routen werden auf dieses Kontingent angerechnet, einschließlich benutzerdefinierter erkannter Routen und von BGP empfangener Routen.

Routen werden nach eindeutigen Zielen gruppiert. Routen mit identischen Zielen, aber unterschiedlichen nächsten Hops zählen als ein Ziel. Routen mit identischen Zielen und identischen nächsten Hops gelten ebenfalls als ein Ziel.

Für Netzwerke im globalen Modus für dynamisches Routing ist es möglich, eines der Kontingente für eindeutige Präfixe für dynamische Routen zu erreichen, ohne das andere zu erreichen. Wenn eines der Kontingente überschritten wurde, können vorübergehende Verbindungsprobleme auftreten, wenn Routen verloren gehen./ Weitere Informationen finden Sie im Beispiel zu erkannten Routen.

Weitere Informationen zu diesen Kontingenten sowie zu Messwerten, mit denen Sie Ihre aktuelle Nutzung ermitteln können, finden Sie unter Fehlerbehebung bei BGP-Routen und Routenauswahl.

Nur anwendbar auf VPC-Netzwerke im globalen Modus für dynamisches Routing:

Einzigartige dynamische Cloud Router-Routenpräfixe aus anderen Regionen pro Region und VPC-Netzwerk

Die maximale Anzahl eindeutiger Ziele für erkannte Routen, die von Cloud Routern aus verschiedenen Regionen auf Subnetze in einer Region angewendet werden können Dies wird als from-other-regions-Kontingent einer Region bezeichnet.

Kontingent

Auf dieses Kontingent werden sowohl IPv4- als auch IPv6-Präfixe angerechnet.

Alle erkannten Routen werden auf dieses Kontingent angerechnet, einschließlich benutzerdefinierter erkannter Routen und von BGP empfangener Routen.

Routen werden nach eindeutigen Zielen gruppiert. Routen mit identischen Zielen, aber unterschiedlichen nächsten Hops zählen als ein Ziel. Routen mit identischen Zielen und identischen nächsten Hops gelten ebenfalls als ein Ziel.

Für Netzwerke im globalen Modus für dynamisches Routing ist es möglich, eines der Kontingente für eindeutige Präfixe für dynamische Routen zu erreichen, ohne das andere zu erreichen. Wenn eines dieser Limits erreicht wurde, können vorübergehende Verbindungsprobleme auftreten, wenn die Routen verloren gehen. Weitere Informationen finden Sie im Beispiel zu erkannten Routen.

Weitere Informationen zu diesen Kontingenten sowie zu Messwerten, mit denen Sie Ihre aktuelle Nutzung ermitteln können, finden Sie unter Fehlerbehebung bei BGP-Routen und Routenauswahl.

Limits

Für Virtual Private Cloud-Netzwerke (VPC) gelten die folgenden Limits für Cloud Router. Wenn nichts anderes angegeben ist, können diese Limits nicht erhöht werden.

Element Limit Hinweise
Maximale Anzahl der Cloud Router je Kombination von VPC-Netzwerk und Region 5 Wenn Sie für Ihr Projekt ein ausreichend hohes Kontingent haben, können Sie in einem VPC-Netzwerk und einer Region bis zu fünf Cloud Router erstellen.
Maximale Anzahl der BGP-Peers für jeden Cloud Router in einem gegebenen VPC-Netzwerk und einer Region 128 Ein BGP-Peer kann folgendes sein:
Maximale Anzahl von Präfixen, die Cloud Router von einer einzelner BGP-Peer akzeptiert 5.000 Wenn ein BGP-Peer mehr als 5.000 Präfixe anbietet, setzt Cloud Router die BGP-Sitzung zurück.
Maximale Anzahl von Begriffen aller angewendeten BGP-Routenrichtlinien innerhalb eines einzelnen BGP-Peers oder einer einzelnen Richtung 1.000 Dieses Limit wird nicht auf Ressourcen aufgeteilt, sondern zusammengefasst. Es gibt keine Begrenzung für die Größe eines einzelnen Übereinstimmungs- oder Aktionsausdrucks, die Anzahl der Aktionen in einem Begriff, die Anzahl der Begriffe in einer einzelnen Richtlinie oder die Anzahl der Richtlinien.
Maximale Anzahl von Route Advertisements im Subnetz pro BGP-Sitzung für einen Cloud Router Keine Beschränkung Bei Cloud Routern besteht kein Limit für die Anzahl der Route Advertisements im Subnetz. Die Anzahl der Subnetzrouten hängt von der Anzahl der Subnetze ab, die durch die VPC-Netzwerkkontingente und -limits bestimmt wird.
Maximale Anzahl von benutzerdefinierten beworbenen Routen pro BGP-Sitzung für einen Cloud Router 200 Wenn die benutzerdefinierten Routen für alle BGP-Sitzungen auf einem Cloud Router identisch sind, stellt dieses Limit die Gesamtzahl für eindeutige IPv4- und IPv6-Routen für den Cloud Router dar. In diesem Fall erhält jede Sitzung den gleichen Satz an benutzerdefinierten beworbenen Routen.
Die maximale Gesamtgröße aller Übereinstimmungs- und Aktionsausdrucksliterale, die in BGP-Routenrichtlinien für einen Cloud Router verwendet werden und als UTF-8 codiert sind. 250 KiB Für einen bestimmten Cloud Router wird dieses Limit nicht auf mehrere Ressourcen aufgeteilt, sondern zusammengefasst. Es gibt keine Begrenzung für die Größe eines einzelnen Übereinstimmungs- oder Aktionsausdrucks, die Anzahl der Aktionen in einem Begriff, die Anzahl der Begriffe in einer einzelnen BGP-Routenrichtlinie oder die Anzahl der BGP-Routenrichtlinien.
Maximale Anzahl von Abfragen pro Minute für list-bgp-routes Anrufe auf einem einzelnen Cloud Router 1500 Dieses Kontingent stammt von compute.googleapis.com/list_requests_per_region. Weitere Informationen finden Sie unter Ratenkontingente.
Maximale Anzahl von BGP-Routenrichtlinien pro Cloud Router. 500
Maximale Anzahl benutzerdefinierter erkannter Routen für eine BGP-Sitzung 10

Weitere Informationen zu diesem Feature finden Sie unter Benutzerdefinierte erkannte Routen.

Die maximale Anzahl eindeutiger IP-Präfixe, die für eine bestimmte Region in einem VPC-Netzwerk als benutzerdefinierte erkannte Routen konfiguriert werden können. Mit diesem Limit können dieselben Bereiche auf mehreren Peers verwendet werden.

10

Weitere Informationen zu diesem Feature finden Sie unter Benutzerdefinierte erkannte Routen.

Beispiel zu erkannten Routen

Die folgenden Beispiele veranschaulichen das Verhalten beim Routenverlust, das Sie erreichen können, wenn das Kontingent für „from-own-region“ oder „from-other-regions“ überschritten wird.

Angenommen, Sie haben Cloud Router in der Region us-east1 und Cloud Router in der Region us-west1 im selben VPC-Netzwerk und globales dynamisches Routing ist aktiviert. Jeder Cloud Router in jeder Region lernt 250 eindeutige Ziele. Zur Veranschaulichung dieses Beispiels lernt jeder Cloud Router in jeder Region keine der gleichen Ziele.

Unabhängig davon, welche Cloud Router die Routen in den einzelnen Regionen lernen, ist das Kontingent für „from-own-region“ jeder Region ausgeschöpft, da 250 von 250 eindeutigen Zielen von den Cloud Routern in jeder Region erlernt werden. Die from-other-regions-Kontingente für beide Regionen sind ebenfalls aufgebraucht, da jeder Cloud Router 250 eindeutige Ziele aus der anderen Region importiert. Wenn im Beispiel-VPC-Netzwerk regionales dynamisches Routing verwendet wird, gelten die Kontingente für „Aus anderen Regionen“ nicht in jeder Region, da der regionale Modus für dynamisches Routing die VPC anweist, nur dynamische Routen in der Region zu erstellen, die dem nächsten Hop der Route entspricht.

Kontingent für „from-own-region“ einer Region überschreiten

Angenommen, Ihr lokaler Router, der mit einem Cloud Router in us-west1 verbunden ist, bewirbt ein 251. Ziel. Cloud Router in der Region us-west1 wählen 250 der 251 eindeutigen Ziele nach einer deterministischen Routenreihenfolge aus. Diese Router senden diese 250 eindeutigen Ziele an das VPC-Netzwerk und erstellen 250 dynamische Routen in der Region us-west1.

Da das VPC-Netzwerk den Modus für globales dynamisches Routing verwendet, werden auch maximal 250 dynamische Routen in jeder anderen Region erstellt, wobei das Kontingent für eindeutige Ziele von anderen Regionen gilt. Im nächsten Abschnitt wird dies in anderen Regionen ausführlicher beschrieben.

Kontingent für „from-other-regions“ einer Region überschreiten

Wenn Cloud Router in der Region us-west1 251 eindeutige Ziele erkannt haben, werden 250 der 251 eindeutigen Ziele aus us-west1 Ressourcen in der Region us-east1 zur Verfügung gestellt, da das Kontingent für from-other-regions der Region us-east1 nur 250 eindeutige Ziele akzeptieren kann.

Angenommen, Sie erstellen einen Cloud Router in einer dritten Region (us-central1) im selben VPC-Netzwerk. Angenommen, der neue Cloud Router lernt von seinem BGP-Peer zehn eindeutige Ziele. Obwohl das Kontingent für „from-own-region“ der Region us-central1 nicht überschritten wurde, wurde das Kontingent für „from-other-regions“ der Region us-central1 überschritten, da insgesamt 500 eindeutige Ziele von den beiden anderen Regionen (250 von us-east1 und andere 250 von us-west1) bereitgestellt werden.

Regionsweise legt die deterministische Routenreihenfolge Routen für maximal 250 eindeutige Ziele in anderen Regionen fest, wie in der folgenden Tabelle angegeben.

Region Eindeutige Ziele lokal in der Region
(Nutzung des Kontingents für „from-own-region“)
Eindeutige Ziele aus anderen Regionen
(Nutzung des Kontingents für „from-other-regions“ der Region)
us-west1

251 empfangen. 250 der 251 sind ausgewählt und einer der 251 wird aufgrund der deterministischen Routenreihenfolge verworfen. 250 dynamische Routen mit den nächsten Hops in us-west1 werden in us-west1 erstellt.

Die 250 ausgewählten Präfixe werden für andere Regionen freigegeben.

260 erhalten (250 von us-east1, 10 ab us-central1). 250 der 260 werden ausgewählt und 10 von den 260 werden nach der deterministischen Routenreihenfolge verworfen.

250 dynamische Routen mit den nächsten Hops außerhalb von us-west1 werden in us-west1 erstellt.

us-east1

250 empfangen. Alle 250 werden nach der deterministischen Routenreihenfolge ausgewählt. 250 dynamische Routen mit den nächsten Hops in us-east1 werden in us-east1 erstellt.

Alle 250 ausgewählten Präfixe werden für andere Regionen freigegeben.

260 erhalten (250 von us-west1, 10 ab us-central1). 250 der 260 werden ausgewählt und 10 von den 260 werden nach der deterministischen Routenreihenfolge verworfen.

250 dynamische Routen mit den nächsten Hops außerhalb von us-east1 werden in us-east1 erstellt.

us-central1

10 erhalten. Alle zehn werden nach der deterministischen Routenreihenfolge ausgewählt. Zehn dynamische Routen mit den nächsten Hops in us-central1 werden in us-central1 erstellt.

Alle zehn ausgewählten Präfixe werden für andere Regionen freigegeben.

500 erhalten (250 von us-west1, 250 von us-east1). 250 der 500 werden ausgewählt und 250 der 500 werden durch die deterministische Routenreihenfolge verworfen.

250 dynamische Routen mit den nächsten Hops außerhalb von us-central1 werden in us-central1 erstellt.

Obwohl das Kontingent für „from-other-regions“ der Region us-central1 überschritten wird, kann das Kontingent für „from-own-region“ Ziele akzeptieren, deren nächste Hops in der Region us-central1 liegen.

Verhalten bei deterministischem Routenverlust

Cloud Router implementiert ein deterministisches Routenverlustverhalten basierend auf der Länge der Subnetzmaske und den lexikografischen Eigenschaften jedes empfangenen Präfixes. Innerhalb jeder Region gilt der folgende Prozess unabhängig für die Liste der from-own-region-Ziele und der Liste der eindeutigen from-other-regions-Ziele:

  • Die Liste wird zuerst von der kürzesten zur längsten Länge der Subnetzmaske sortiert, dann lexikografisch. Beispiel: 10.0.0.0/8 steht vor 10.2.1.0/24, also vor 10.99.1.0/24.

  • Die ersten 250 Einträge in der Liste werden beibehalten. Alle anderen werden verworfen.

Wie unter from-other-regions-Kontingent einer Region überschreiten gezeigt, wird das deterministische Verlustverhalten unabhängig auf das from-own-region-Kontingent und das from-other-regions-Kontingent der einzelnen Regionen angewendet.

Das deterministische Routenverlust hat folgende Konsequenzen:

  • Wenn beide IPv4- und IPv6-Präfixe empfangen werden, verwirft Cloud Router in der Regel zuerst IPv6-Präfixe, wenn ein eindeutiges Zielkontingent überschritten wird. Dies liegt daran, dass die kürzeste Subnetzmaskenlänge für IPv6 (/48) länger als die längste mögliche Subnetzmaskenlänge für IPv4 (/32) ist.

  • Wenn die in jeder Region erlernten Präfixe konstant bleiben, programmiert Google Cloud gemäß dem dynamischen Routingmodus des VPC-Netzwerks eine konsistente Gruppe lokaler dynamischer Routen in jeder Region. Diese Konsistenz wird beibehalten, einschließlich der Routen, die von Cloud Router gelöscht werden, wenn Cloud Router-Aufgaben neu gestartet werden.

Routenverlust wird vermieden

Während dem Routenverlust geht die Verbindung für die Präfixe, die verworfen werden, verloren. Um den Routenverlust zu vermeiden, überwachen Sie die from-own-region- und from-other-regions-Präfixnutzung mit Cloud Monitoring oder Cloud Logging und stellen Sie sicher, dass nicht mehr eindeutige Ziele als das jeweilige Kontingent beworben werden.

Sie können Routen zusammenfassen, um die Anzahl der eindeutigen Ziele zu reduzieren. Wenn Sie beispielsweise die vier Subnetze 10.10.10.0/24, 10.10.10.1/24, 10.10.10.2/24 und 10.10.10.3/24 haben, können Sie sie in einem Präfix zusammenfassen, z. B. 10.10.0.0/22.

Wenn keine Zusammenfassung möglich ist, wenden Sie sich an Ihr Google Cloud-Vertriebsteam, um alternative Optionen zu besprechen.

Router-Appliance

Kontingente

Kontingente für Netzwerkrouten für Cloud Router gelten auch für Routen von Router-Appliance-Spokes, die mit Hubs des Network Connectivity Centers verbunden sind.

Weitere Informationen finden Sie unter Cloud Router-Kontingente.

Limits

Darüber hinaus gelten die folgenden Limits für Cloud Router auch für die Router-Appliance:

  • Die maximale Anzahl der Cloud Router je Kombination von VPC-Netzwerk und Region
  • Die maximale Anzahl der BGP-Peers für jeden Cloud Router in einem gegebenen VPC-Netzwerk und einer Region

Weitere Informationen finden Sie unter Cloud Router-Limits.

Network Connectivity Center

Kontingente

Kontingente für Netzwerkrouten für Cloud Router gelten auch für Routen für Hub-Hubs und Spokes für Network Connectivity Center. Weitere Informationen finden Sie unter Kontingente und Limits für Cloud Router.

Element Kontingent Hinweise
Anzahl der Hubs pro Projekt Kontingent Pro Projekt, global
Anzahl der Cloud VPN-Tunnel-Spokes pro Projekt und Region Kontingent Pro Projekt und Region; nur HA VPN-Tunnel werden unterstützt
Anzahl der Cloud Interconnect-VLAN-Anhang-Spokes pro Projekt und Region Kontingent Pro Projekt und Region
Anzahl der Router-Appliance-Spokes pro Router und Projekt Kontingent Pro Projekt und Region
Anzahl der VPC-Spokes pro Projekt Kontingent Umfasst VPC-Spokes (Edge- und Center-Spokes kombiniert), auch wenn sie nicht mit einem Hub verbunden sind.

Anzahl der aktiven VPC-Spokes pro Hub

Kontingent

Gilt nur für VPC-Spokes, die in einen Hub akzeptiert wurden; gilt nicht für VPC-Spokes, die noch überprüft werden müssen oder abgelehnt wurden.

Anzahl der Subnetz-Routen pro Hub-Routingtabelle

Kontingent Gilt nur für Hubs mit VPC-Spokes

Limits

Für Network Connectivity Center gelten die folgenden Nutzungsbeschränkungen.

Element Wert
Anzahl der VPN-Tunnel, die mit einem Spoke verknüpft werden können 8
Anzahl der VLAN-Anhänge, die mit einem Spoke verknüpft werden können 6
Anzahl der Router-Appliance-Instanzen, die mit einem Spoke verknüpft werden können 8
Anzahl der aktiven VPC-Spokes pro Hub 250
Maximalanzahl der VPC-Spokes (aktiv und inaktiv) pro Hub 1.000
Anzahl der Exportfilter pro Spoke 16
Maximale Anzahl von unterstützten Routing-VPCs pro Network Connectivity Center-Hub 40
Anzahl der Routen pro Hub-Routingtabelle 500

Kontingente verwalten

MitGoogle Cloud werden Kontingente für die Ressourcennutzung aus verschiedenen Gründen festgelegt. Kontingente schützen unter anderem die gesamte Google Cloud -Community vor unerwarteten Nutzungsspitzen. Außerdem unterstützen Kontingente Nutzer, die Google Cloud mit der kostenlosen Stufe prüfen, dabei, im Rahmen der Testversion zu verbleiben.

Alle Projekte beginnen mit den gleichen Kontingenten, die Sie ändern können, indem Sie zusätzliche Kontingente anfordern. Einige Kontingente könnten entsprechend Ihrer Nutzung eines Produkts automatisch erhöht werden.

Berechtigungen

Zur Anzeige von Kontingenten oder zur Anforderung von Kontingenterhöhungen benötigen IAM-Hauptkonten (Identity and Access Management) eine der folgenden Rollen:

Aufgabe Erforderliche Rolle
Kontingente für ein Projekt prüfen Beispiele:
Kontingente ändern, zusätzliche Kontingente anfordern Beispiele:
  • Project Owner (roles/owner)
  • Project Editor (roles/editor)
  • Quota Administrator (roles/servicemanagement.quotaAdmin)
  • Eine benutzerdefinierte Rolle mit der Berechtigung serviceusage.quotas.update

Kontingent prüfen

Console

  1. Öffnen Sie in der Google Cloud Console die Seite Kontingente.

    Kontingente aufrufen

  2. Mit dem Feld Tabelle filtern können Sie nach den zu aktualisierenden Kontingenten suchen. Wenn Sie den Namen des Kontingents nicht kennen, verwenden Sie stattdessen die Links auf dieser Seite.

gcloud

Führen Sie mit der Google Cloud CLI den folgenden Befehl aus, um Ihre Kontingente zu prüfen. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID:

    gcloud compute project-info describe --project PROJECT_ID

Mit dem folgenden Befehl prüfen Sie das genutzte Kontingent in einer Region:

    gcloud compute regions describe example-region
    

Fehler beim Überschreiten Ihres Kontingents

Wenn Sie ein Kontingent mit einem gcloud-Befehl überschreiten, gibt gcloud eine quota exceeded-Fehlermeldung aus und liefert den Exit-Code 1.

Wenn Sie ein Kontingent mit einer API-Anfrage überschreiten, liefert Google Cloud folgenden HTTP-Statuscode: 413 Request Entity Too Large.

Weitere Kontingente anfordern

Verwenden Sie die Google Cloud Console, um die meisten Kontingente anzupassen. Weitere Informationen finden Sie unter Kontingentanpassung beantragen.

Console

  1. Öffnen Sie in der Google Cloud Console die Seite Kontingente.

    Kontingente aufrufen

  2. Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten.
  3. Klicken Sie oben auf der Seite auf Kontingente bearbeiten.
  4. Geben Sie unter Name Ihren Namen ein.
  5. Optional: Geben Sie unter Telefon eine Telefonnummer ein.
  6. Senden Sie die Anfrage. Die Bearbeitung von Kontingentanforderungen dauert 24 bis 48 Stunden.

Ressourcenverfügbarkeit

Jedes Kontingent stellt die maximale Anzahl an Ressourcen eines bestimmten Typs dar, die Sie erstellen können, sofern der Ressourcentyp verfügbar ist. Beachten Sie, dass Kontingente die Verfügbarkeit von Ressourcen nicht garantieren. Selbst wenn Sie ein verfügbares Kontingent haben, können Sie keine neue Ressource erstellen, wenn keine verfügbar ist.

Beispiel: Sie haben noch ein ausreichendes Kontingent zum Erstellen einer neuen regionalen, externen IP-Adresse in der Region us-central1. Dies ist jedoch nicht möglich, wenn in dieser Region keine externen IP-Adressen verfügbar sind. Die Verfügbarkeit von zonalen Ressourcen kann sich auch auf Ihre Fähigkeit auswirken, eine neue Ressource zu erstellen.

Es kommt nur selten vor, dass Ressourcen in einer kompletten Region nicht verfügbar sind. Ressourcen innerhalb einer Zone können aber manchmal vorübergehend ausgeschöpft sein, ohne dass sich das auf das Service Level Agreement (SLA) für den Ressourcentyp auswirkt. Weitere Informationen finden Sie im entsprechenden SLA für die Ressource.