Kontingente und Limits

In diesem Dokument sind die Kontingente und Limits für Cloud Router aufgeführt.

Informationen zum Ändern eines Kontingents finden Sie unter Weitere Kontingente anfordern.

Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten. Daher sind Kontingente Teil eines Systems, das Folgendes tut:

Ihre Nutzung oder Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen.
Ihren Verbrauch dieser Ressourcen einschränken, um u. a. für Fairness zu sorgen und Nutzungsspitzen zu reduzieren.
Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen.
Möglichkeit, das Kontingent anzufordern oder zu ändern.

Wenn ein Kontingentlimit überschritten wird, blockiert das System in den meisten Fällen den Zugriff auf die entsprechende Google-Ressource und die Aufgabe, die Sie ausführen möchten, schlägt fehl. In den meisten Fällen gelten Kontingente für jedes Google Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses Google Cloud-Projekt verwenden.

Für Cloud Router-Ressourcen gelten außerdem Limits. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn etwas anderes angegeben ist.

Kontingente

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

Posten	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

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 ein Cloud-VPN-Tunnel sein, der dynamisches Routing verwendet, oder ein VLAN-Anhang für Dedicated Interconnect oder Partner Interconnect(beide nur auf Englisch verfügbar).
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 von benutzerdefinierten Routen.
Maximale Anzahl eindeutiger Ziele für erkannte Routen, die von allen Cloud Routern in derselben Region auf Subnetze in einer Region angewendet werden können. Dieses Limit wird als from-own-region-Limit einer Region bezeichnet.	250	Für beide Limits der maximalen Anzahl eindeutiger Ziele für erkannte Routen gilt: Auf Limits werden sowohl IPv4- als auch IPv6-Präfixe angerechnet. Alle erkannten Routen werden auf dieses Limit angerechnet, einschließlich benutzerdefinierter erkannter Routen und Routen, die von einem BGP-Peer erkannt wurden. 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, eine der maximalen Anzahl von eindeutigen Ziellimits zu erreichen, ohne die 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 Limits sowie zu Messwerten, mit denen Sie Ihre aktuellen Limits und Nutzungsmöglichkeiten ermitteln können, finden Sie unter Kontingente und Limits prüfen im Abschnitt Fehlerbehebung. Wenn Sie eines dieser Limits erhöhen möchten, reichen Sie eine Supportanfrage ein.
Nur anwendbar auf VPC-Netzwerke im globalen Modus für dynamisches Routing: Maximale Anzahl eindeutiger Ziele für erkannte Routen, die von Cloud Routern aus verschiedenen Regionen auf Subnetze in einer Region angewendet werden können Dieses Limit wird als from-other-regions einer Region bezeichnet.	250
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

Beispiel zu erkannten Routen

Die folgenden Beispiele veranschaulichen das Verhalten beim Routenverlust, das Sie erreichen können, wenn das from-own-region-Limit oder das from-other-region-Limit ü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 from-own-region-Limit jeder Region ausgeschöpft, da 250 von 250 eindeutigen Zielen von den Cloud Routern in jeder Region erlernt werden. Die from-other-regions-Limits für beide Regionen sind auch 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 from-other-region-Limits in jeder Region nicht, da der regionale dynamische Routingmodus das VPC-Netzwerk anweist, nur dynamische Routen zu erstellen, die dem next Hop der Route entspricht.

from-own-region-Limit 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 from-other-regions-Limit gilt. Im nächsten Abschnitt wird dies in anderen Regionen ausführlicher beschrieben.

from-other-region-Limit 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 from-other-regions-Limit der us-east1 Region 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 from-own-Limit der us-central1-Region nicht überschritten wurde, wurde das from-other-regions-Limit des eindeutigen Ziels der us-central1-Region ü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 from-own-region-Limits) Eindeutige Ziele aus anderen Regionen
(Nutzung des from-other-regions-Limits)

Region	Eindeutige Ziele lokal in der Region (Nutzung des from-own-region-Limits)	Eindeutige Ziele aus anderen Regionen (Nutzung des from-other-regions-Limits)
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.

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 Limit der from-other-regions-Limit für die us-central1-Region überschritten wird, kann das from-own-region-Limit Ziele akzeptieren, deren next Hops in der us-central1-Region 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-Limit einer Region überschreiten gezeigt, wird das deterministische Verlustverhalten unabhängig auf das from-own-region-Limit und das from-other-regions-Limit 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 Ziellimit ü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 Limit beworben werden.

Sie können Präfixe aggregieren (z. B. Zusammenfassen von Präfixen in einem Präfix mit geringerer Länge), um die Anzahl der eindeutigen Ziele zu reduzieren. Wenn keine Zusammenfassung von Präfixen möglich ist, wenden Sie sich an Ihr Google Cloud-Vertriebsteam, um alternative Optionen zu besprechen.

Verwalten von Kontingenten

Mit Cloud Router 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önnen 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: Project Owner (`roles/owner`) Project Editor (`roles/editor`) Quota Viewer (`roles/servicemanagement.quotaViewer`)
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

Öffnen Sie in der Google Cloud Console die Seite Kontingente.
Kontingente aufrufen
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: HTTP 413 Request Entity Too Large.

Weitere Kontingente anfordern

Verwenden Sie zur Erhöhung/Verringerung der meisten Kontingenten die Google Cloud Console. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.

Console

Öffnen Sie in der Google Cloud Console die Seite Kontingente.
Kontingente aufrufen
Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten.
Klicken Sie oben auf der Seite auf Kontingente bearbeiten.
Geben Sie Ihren Namen, Ihre E-Mail-Adresse und Ihre Telefonnummer ein und klicken Sie auf Weiter.
Geben Sie Ihre Kontingentanforderung ein und klicken Sie auf Fertig.
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.