Questa pagina è stata tradotta dall'API Cloud Translation.

Quote e limiti

Questo documento elenca le quotas e i quotas che si applicano al router Cloud. Per ulteriori informazioni sulle quote, consulta Quote di Virtual Private Cloud.

Una quota limita la quantità di una risorsa Google Cloud condivisa che può essere utilizzata dal progetto Google Cloud, inclusi hardware, software e componenti di rete. Pertanto, le quote fanno parte di un sistema che:

Monitora il tuo utilizzo o consumo di prodotti e servizi Google Cloud.
Limita il consumo di queste risorse, per motivi che includono la garanzia dell'equità e la riduzione dei picchi di utilizzo.
Mantiene configurazioni che applicano automaticamente le limitazioni prescritte.
Offre un mezzo per richiedere o modificare la quota.

Nella maggior parte dei casi, quando viene superata una quota, il sistema blocca immediatamente l'accesso alla risorsa Google pertinente e l'attività che stai tentando di eseguire ha esito negativo. Nella maggior parte dei casi, le quote si applicano a ogni progetto Google Cloud e sono condivise tra tutte le applicazioni e gli indirizzi IP che utilizzano il progetto Google Cloud.

Esistono anche dei limiti relativi alle risorse router Cloud. Questi limiti non sono correlati al sistema di quote. I limiti non possono essere modificati se non diversamente indicato.

Quote

Per modificare una quota, consulta Richiedere una quota aggiuntiva.

In questa tabella vengono illustrate le quote importanti per singolo progetto. Per altre quote, consulta la pagina Quote e limiti di sistema della console Google Cloud.

Elemento	Quota	Note
Router Cloud per progetto	Quota	Indipendentemente dalla quota, ogni rete è limitata a cinque router Cloud per area geografica. Vedi Limiti.

Limiti

I seguenti limiti per il router Cloud si applicano alle reti Virtual Private Cloud (VPC). Salvo diversa indicazione, questi limiti non possono essere aumentati.

Elemento	Limite	Note
Numero massimo di router Cloud per combinazione di rete VPC e area geografica	5	Se disponi di una quota di progetto sufficiente, puoi creare fino a cinque router Cloud in una determinata area geografica e rete VPC.
Numero massimo di peer BGP per ciascun router Cloud in una determinata rete VPC e area geografica	128	Il peer BGP può essere uno dei seguenti: Un tunnel Cloud VPN che utilizza il routing dinamico Un collegamento VLAN per uno dei seguenti elementi: Dedicated Interconnect Partner Interconnect Cross-Cloud Interconnect Un' appliance router all'interno di Network Connectivity Center
Numero massimo di prefissi che il router Cloud accetta da un singolo peer BGP	5000	Se un peer BGP annuncia più di 5000 prefissi, il router Cloud reimposta la sessione BGP.
Numero massimo di termini di tutti i criteri di route BGP applicati all'interno di un singolo peer o direzione BGP	1000	Questo limite non è suddiviso tra risorse, ma combinato. Non sono previsti limiti per le dimensioni di una singola espressione di corrispondenza o azione, il numero di azioni in un termine, il numero di termini in un singolo criterio o il numero di criteri.
Per un determinato router Cloud, numero massimo di annunci di route subnet per sessione BGP	Nessuna restrizione	I router Cloud non hanno un limite per il numero di route subnet che possono pubblicizzare. Il numero di route subnet è determinato dal numero di subnet, che sono controllate dai limiti e dalle quote di rete VPC.
Per un determinato router Cloud, numero massimo di route pubblicizzate personalizzate per sessione BGP	200	Se le route annunciate personalizzate sono identiche per tutte le sessioni BGP su un router Cloud, questo limite rappresenta il numero totale di route uniche pubblicizzate personalizzate per il router Cloud. In questo caso, ogni sessione riceve lo stesso insieme di route annunciate personalizzate.
Per un determinato router Cloud, la dimensione massima combinata di tutti i valori letterali di espressione di corrispondenza e azione utilizzati nei criteri di route BGP quando sono codificati come UTF-8.	Limite di 250 KiB	Per un determinato router Cloud, questo limite non è suddiviso tra risorse, ma combinato. Non esistono limiti per le dimensioni di una singola espressione di corrispondenza o azione, il numero di azioni in un termine, il numero di termini in un singolo criterio di route BGP o il numero di criteri di route BGP.
Numero massimo di query al minuto per chiamate `list-bgp-routes` su un singolo router Cloud	1500	Questa quota proviene dal giorno `compute.googleapis.com/list_requests_per_region`. Per maggiori informazioni, consulta la pagina Quote di frequenza.
Numero massimo di criteri di route BGP per router Cloud.	500
Numero massimo di destinazioni univoche garantite per route apprese che possono essere applicate alle subnet in una determinata regione da tutti i router Cloud nella stessa regione. Questo limite è definito limite di una singola regione dalla propria regione.	250	Entrambi i prefissi IPv4 e IPv6 vengono conteggiati ai fini di questo limite. Tutte le route apprese vengono conteggiate ai fini di questo limite, incluse le route apprese personalizzate e quelle apprese da un peer BGP. Le route vengono raggruppate per destinazioni univoche. Le route con destinazioni identiche ma hop successivi diversi vengono conteggiate come un'unica destinazione. Anche le route con destinazioni identiche e hop successivi identici vengono conteggiate come un'unica destinazione. Per le reti in modalità di routing dinamico globale, è possibile raggiungere uno dei limiti massimo di destinazioni univoche senza raggiungere l'altro. Quando è stato raggiunto uno dei limiti, si possono verificare problemi di connettività intermittente in caso di abbandono delle route. Per maggiori dettagli, vedi l'esempio di route appresa. Per ulteriori informazioni su questi limiti, incluse le metriche che puoi utilizzare per comprendere i limiti e l'utilizzo attuali, consulta Controllare quote e limiti in Risoluzione dei problemi. Se devi verificare o controllare di aver superato questo limite, invia una richiesta di assistenza. Se devi aumentare questo limite, invia una richiesta di assistenza. Un aumento del limite è soggetto ad approvazione. Se approvata, l'evasione richiede fino a 2 settimane.
Si applica solo alle reti VPC in modalità di routing dinamico globale. Numero massimo di destinazioni univoche garantite per route apprese che può essere applicato a subnet in una determinata regione dai router Cloud di diverse regioni. Questo limite è definito limite di da altre regioni per un'area geografica.	250	Entrambi i prefissi IPv4 e IPv6 vengono conteggiati ai fini di questo limite. Tutte le route apprese vengono conteggiate ai fini di questo limite, incluse le route apprese personalizzate e quelle apprese da un peer BGP. Le route vengono raggruppate per destinazioni univoche. Le route con destinazioni identiche ma hop successivi diversi vengono conteggiate come un'unica destinazione. Anche le route con destinazioni identiche e hop successivi identici vengono conteggiate come un'unica destinazione. Per le reti in modalità di routing dinamico globale, è possibile raggiungere uno dei limiti massimo di destinazioni univoche senza raggiungere l'altro. Quando è stato raggiunto uno dei limiti, si possono verificare problemi di connettività intermittente in caso di abbandono delle route. Per maggiori dettagli, vedi l'esempio di route appresa. Per ulteriori informazioni su questi limiti, incluse le metriche che puoi utilizzare per comprendere i limiti e l'utilizzo attuali, consulta Controllare quote e limiti in Risoluzione dei problemi. Se devi verificare o controllare di aver superato questo limite, invia una richiesta di assistenza. Se devi aumentare questo limite, invia una richiesta di assistenza. Un aumento del limite è soggetto ad approvazione. Se approvata, l'evasione richiede fino a 2 settimane.
Per una determinata sessione BGP, il numero massimo di route apprese personalizzate	10	Per maggiori informazioni su questa funzionalità, consulta Route apprese personalizzate.
Per una determinata regione in una rete VPC, il numero massimo di prefissi IP univoci che possono essere configurati come route apprese personalizzate; questo limite consente di utilizzare gli stessi intervalli in più peer	10	Per maggiori informazioni su questa funzionalità, consulta Route apprese personalizzate.

Esempio di route appresa

I seguenti esempi illustrano il comportamento di eliminazione delle route che puoi riscontrare quando il limite from-own-region o il limite from-other-regions viene superato.

Supponi di avere router Cloud nella regione us-east1 e router Cloud nella regione us-west1 nella stessa rete VPC e che sia abilitato il routing dinamico globale. Ogni router Cloud in ogni regione apprende 250 destinazioni uniche. A scopo illustrativo di questo esempio, ogni router Cloud in ogni regione non apprende nessuna delle stesse destinazioni.

Indipendentemente da quali i router Cloud apprendono le route all'interno di ogni regione, il limite della propria regione viene esaurito perché 250 su 250 destinazioni univoche vengono apprese dai router Cloud in ogni regione. Vengono esauriti anche i limiti di altre regioni per entrambe le regioni, perché ogni router Cloud importa 250 destinazioni univoche dall'altra regione. Se la rete VPC di esempio utilizzava il routing dinamico a livello di regione, i limiti da altre regioni in ogni regione non verranno applicati perché la modalità di routing dinamico a livello di regione indica alla rete VPC di creare solo route dinamiche nella regione che corrisponde all'hop successivo della route.

Superamento del limite di una regione dalla propria regione

Supponiamo che il tuo router on-premise connesso a un router Cloud in us-west1 pubblicizzi una 251a destinazione. I router Cloud nella regione us-west1 scelgono 250 delle 251 destinazioni univoche seguendo un ordine di route deterministico. Questi router inviano le 250 destinazioni univoche alla rete VPC, creando 250 route dinamiche nella regione us-west1.

Poiché la rete VPC utilizza la modalità di routing dinamico globale, crea anche non più di 250 route dinamiche in ogni altra regione, in base al limite di destinazione univoco di ciascuna regione da altre regioni. La prossima sezione descrive in modo più dettagliato cosa succede in altre regioni.

Superamento del limite di una regione da altre regioni

Quando i router Cloud rilevano 251 destinazioni univoche nella regione us-west1, 250 delle 251 destinazioni univoche da us-west1 vengono rese disponibili per le risorse nella regione us-east1, perché il limite della regione us-east1 da altre regioni può accettare solo 250 destinazioni univoche.

Supponiamo di creare un router Cloud in una terza regione, us-central1, nella stessa rete VPC. Supponiamo che il nuovo router Cloud apprenda 10 destinazioni univoche dal suo peer BGP. Anche se il limite di destinazioni dalla propria regione us-central1 non è stato superato, il limite di destinazioni uniche per la regione us-central1 da altre regioni è stato superato perché le altre due regioni forniscono un totale di 500 destinazioni uniche (250 per us-east1 e 250 diverse per us-west1).

A livello di regione per regione, l'ordine delle route deterministiche seleziona le route per un massimo di 250 destinazioni univoche in altre regioni, come indicato nella tabella seguente.

Regione Destinazioni uniche locali rispetto alla regione
(utilizzo del limite per regione dalla propria regione) Destinazioni uniche da altre regioni
(utilizzo del limite per regione da altre regioni)

Regione	Destinazioni uniche locali rispetto alla regione (utilizzo del limite per regione dalla propria regione)	Destinazioni uniche da altre regioni (utilizzo del limite per regione da altre regioni)
us-west1	251 ricevuti. 250 delle 251 vengono selezionate e una delle 251 viene eliminata dall'ordine delle route deterministiche. In `us-west1` vengono create 250 route dinamiche con hop successivi in `us-west1`. I 250 prefissi selezionati vengono condivisi con altre regioni.	260 ricevuti (250 da `us-east1`, 10 da `us-central1`). 250 su 260 vengono selezionate e 10 su 260 vengono eliminate dall'ordine di route deterministico. In `us-west1` vengono create 250 route dinamiche con hop successivi al di fuori di `us-west1`.
us-east1	250 ricevuti. Tutte le 250 vengono selezionate in base all'ordine delle route deterministiche. In `us-east1` vengono create 250 route dinamiche con hop successivi in `us-east1`. Tutti i 250 prefissi selezionati vengono condivisi con altre regioni.	260 ricevuti (250 da `us-west1`, 10 da `us-central1`). 250 su 260 vengono selezionate e 10 su 260 vengono eliminate dall'ordine di route deterministico. In `us-east1` vengono create 250 route dinamiche con hop successivi al di fuori di `us-east1`.
us-central1	10 ricevuti. Tutte e 10 vengono selezionate in base all'ordine delle route deterministiche. Vengono create 10 route dinamiche con hop successivi in `us-central1` in `us-central1`. Tutti e 10 i prefissi selezionati sono condivisi con altre regioni.	500 ricevuti (250 da `us-west1`, 250 da `us-east1`). 250 su 500 vengono selezionate e 250 su 500 vengono eliminate dall'ordine di route deterministico. In `us-central1` vengono create 250 route dinamiche con hop successivi al di fuori di `us-central1`.

us-west1

251 ricevuti. 250 delle 251 vengono selezionate e una delle 251 viene eliminata dall'ordine delle route deterministiche. In us-west1 vengono create 250 route dinamiche con hop successivi in us-west1.

I 250 prefissi selezionati vengono condivisi con altre regioni.

260 ricevuti (250 da us-east1, 10 da us-central1). 250 su 260 vengono selezionate e 10 su 260 vengono eliminate dall'ordine di route deterministico.

In us-west1 vengono create 250 route dinamiche con hop successivi al di fuori di us-west1.

us-east1

250 ricevuti. Tutte le 250 vengono selezionate in base all'ordine delle route deterministiche. In us-east1 vengono create 250 route dinamiche con hop successivi in us-east1.

Tutti i 250 prefissi selezionati vengono condivisi con altre regioni.

260 ricevuti (250 da us-west1, 10 da us-central1). 250 su 260 vengono selezionate e 10 su 260 vengono eliminate dall'ordine di route deterministico.

In us-east1 vengono create 250 route dinamiche con hop successivi al di fuori di us-east1.

us-central1

10 ricevuti. Tutte e 10 vengono selezionate in base all'ordine delle route deterministiche. Vengono create 10 route dinamiche con hop successivi in us-central1 in us-central1.

Tutti e 10 i prefissi selezionati sono condivisi con altre regioni.

500 ricevuti (250 da us-west1, 250 da us-east1). 250 su 500 vengono selezionate e 250 su 500 vengono eliminate dall'ordine di route deterministico.

In us-central1 vengono create 250 route dinamiche con hop successivi al di fuori di us-central1.

Anche se il limite della regione us-central1 è stato superato, il suo limite from-own-region può accettare destinazioni i cui hop successivi si trovano nella us-central1 regione.

Comportamento di eliminazione della route deterministica

Il router Cloud implementa un comportamento deterministico per l'eliminazione delle route in base alla lunghezza della subnet mask e alle caratteristiche lessicografiche di ogni prefisso ricevuto. All'interno di ogni regione, il seguente processo si applica in modo indipendente dall'elenco delle destinazioni dalla propria regione e dall'elenco delle destinazioni univoche per la regione da altre regioni:

L'elenco è ordinato prima in base alla lunghezza della subnet mask più breve a quella più lunga, quindi lessicograficamente. Ad esempio, 10.0.0.0/8 è precedente a 10.2.1.0/24, che precede a 10.99.1.0/24.
Le prime 250 voci dell'elenco vengono mantenute. Tutti gli altri vengono eliminati.

Come mostrato in corrispondenza del superamento del limite di from-other-regions di una regione, il comportamento di eliminazione deterministica viene applicato in modo indipendente al limite from-own-region di ogni regione e al limite di ogni regione from-other-regions.

Il comportamento di eliminazione delle route deterministiche ha le seguenti conseguenze:

Quando vengono ricevuti entrambi i prefissi IPv4 e IPv6, il router Cloud in genere elimina prima i prefissi IPv6 ogni volta che viene superato un limite di destinazione univoco. Questo accade perché la lunghezza della subnet mask più comune più breve per IPv6 (/48) è superiore alla lunghezza della subnet mask più lunga possibile per IPv4 (/32).
Se l'insieme di prefissi appresi in ogni regione rimane costante, Google Cloud programma un insieme coerente di route dinamiche locali in ogni regione, in base alla modalità di routing dinamico della rete VPC. Questa coerenza, incluse le route che vengono eliminate dal router Cloud, viene mantenuta al riavvio delle attività del router Cloud.

Percorso che evita di perdere

Durante l'eliminazione della route, perdi la connettività per i prefissi eliminati. Per evitare l'interruzione della route, monitora l'utilizzo dei prefissi dalla propria regione e da altre regioni utilizzando Cloud Monitoring o Cloud Logging e assicurati di non pubblicizzare più destinazioni univoche rispetto a ciascun limite.

Valuta la possibilità di riassumere le route per ridurre il numero di destinazioni univoche. Ad esempio, se hai le quattro subnet 10.10.10.0/24, 10.10.10.1/24, 10.10.10.2/24 e 10.10.10.3/24, puoi riassumerle come un unico prefisso, 10.10.0.0/22.

Se non è possibile riassumere, contatta il team di vendita di Google Cloud per parlare di opzioni alternative.

Manage quotas

Cloud Router enforces quotas on resource usage for various reasons. For example, quotas protect the community of Google Cloud users by preventing unforeseen spikes in usage. Quotas also help users who are exploring Google Cloud with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas might increase automatically based on your use of a product.

Permissions

To view quotas or request quota increases, Identity and Access Management (IAM) principals need one of the following roles.

Task	Required role
Check quotas for a project	One of the following: Project Owner (`roles/owner`) Project Editor (`roles/editor`) Quota Viewer (`roles/servicemanagement.quotaViewer`)
Modify quotas, request additional quota	One of the following: Project Owner (`roles/owner`) Project Editor (`roles/editor`) Quota Administrator (`roles/servicemanagement.quotaAdmin`) A custom role with the `serviceusage.quotas.update` permission

Check your quota

Console

In the Google Cloud console, go to the Quotas page.
Go to Quotas
To search for the quota that you want to update, use the Filter table. If you don't know the name of the quota, use the links on this page instead.

gcloud

Using the Google Cloud CLI, run the following command to check your quotas. Replace PROJECT_ID with your own project ID.

      gcloud compute project-info describe --project PROJECT_ID

To check your used quota in a region, run the following command:

    gcloud compute regions describe example-region

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Google Cloud returns the following HTTP status code: 413 Request Entity Too Large.

Request additional quota

To increase or decrease most quotas, use the Google Cloud console. For more information, see Request a higher quota.

Console

In the Google Cloud console, go to the Quotas page.
Go to Quotas
On the Quotas page, select the quotas that you want to change.
At the top of the page, click Edit quotas.
For Name, enter your name.
Optional: For Phone, enter a phone number.
Submit your request. Quota requests take 24 to 48 hours to process.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, if that resource is available. It's important to note that quotas don't guarantee resource availability. Even if you have available quota, you can't create a new resource if it is not available.

For example, you might have sufficient quota to create a new regional, external IP address in the us-central1 region. However, that is not possible if there are no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare. However, resources within a zone can be depleted from time to time, typically without impact to the service level agreement (SLA) for the type of resource. For more information, review the relevant SLA for the resource.