配額

配額與限制

以下各節說明 Cloud Router 的配額與限制。如要變更配額,請透過 Google Cloud Console 申請更多配額

配額

項目 限制 注意事項
每項專案的 Cloud Router 雲端路由器數量 配額 無論配額多寡,每個地區每個網路最多只能使用五個 Cloud Router 雲端路由器。詳情請參閱相關限制

限制

下列 Cloud Router 限制適用於虛擬私人雲端 (VPC) 網路。除非另行公告,否則這些配額限制均不得提高。

項目 限制 注意事項
單一地區中的 Cloud Router 雲端路由器數量上限 5 如果專案配額充足,您最多可以在一個虛擬私人雲端網路和地區中建立五個 Cloud Router 雲端路由器。
單一地區中各個 Cloud Router 雲端路由器的 BGP 對等點數量上限 128 BGP 對等點可以是採用動態轉送模式的 Cloud VPN 通道,或是專屬互連網路合作夥伴互連網路的互連網路連結 (VLAN)。
單一 Cloud Router 雲端路由器中各個 BGP 工作階段的子網路路徑通告數量上限 沒有限制 Cloud Router 雲端路由器沒有子網路路徑通告數量上限。子網路路徑的數量取決於子網路數量,而子網路數量不得超過VPC 網路配額與限制的規定。
單一 Cloud Router 雲端路由器中每個 BGP 工作階段的自訂路徑通告數量上限 200 在某個 Cloud Router 雲端路由器中,如果所有 BGP 工作階段的自訂路徑通告完全相同,這項上限即代表該雲端路由器的「不重複」自訂路徑通告總數。在這種情況下,每個工作階段都會收到相同的自訂路徑通告。
已知路徑的不重複目的地數量上限 (可透過某個地區中的任何 Cloud Router 雲端路由器套用至位於相同地區的子網路) 100 適用於已知路徑不重複目的地數量的兩項上限:路徑是依據不重複目的地進行分組。目的地相同,但後續躍點不同的路徑只會計為一個目的地;目的地相同,後續躍點也相同的路徑同樣只會計為一個目的地。

處於「全域動態轉送模式」的網路:可能只會達到兩項已知路徑不重複目的地數量上限中的一項。如果已知路徑僅達到一項上限,系統可能會出現無法預測的轉送行為。詳情請參閱已知路徑示例一節。

如需提高已知路徑的任一數量上限,請與 Google Cloud 銷售團隊聯絡。
「僅適用於
採用全域動態轉送模式的 VPC 網路:」
已知路徑的不重複目的地數量上限 (可透過「不同」地區中的 Cloud Router 雲端路由器套用至某個地區的子網路)
100

已知路徑示例

以下示例說明當已知路徑僅達到其中一項數量上限時,系統可能會發生哪些無法預測的行為。

假設您在 us-east1 和 us-west1 地區中各有一個 Cloud Router 雲端路由器,這兩個 Cloud Router 雲端路由器都收到了同一組路徑 (當中包含 100 個不重複的目的地,均連至您的內部部署網路)。對兩個 Cloud Router 雲端路由器而言,這些路徑的後續躍點都不相同,因為每個躍點皆連結至內部部署網路中的不同路由器。假設您連結至 us-west1 地區 Cloud Router 雲端路由器的內部部署路由器分享了第 101 條路徑,而且這條路徑的目的地與前 100 條均不相同:

  • Cloud Router 雲端路由器會挑選 101 條共用路徑中的「任意」100 條。此時,「不同」地區的 Cloud Router 雲端路由器收到的不重複目的地會在 us-east1 地區中達到數量上限,因此系統會將 101 條路徑中的「任意」100 條套用至 us-east1 地區中的子網路。在這種情況下,我們無法保證兩個地區收到的 100 條路徑會完全相同。

  • 其中一個地區中的 VM 可能會遺失其他路徑。假設某條路徑的目的地為 10.1.2.0/24,而且這條路徑是從內部部署系統分享至這兩個地區中的 Cloud Router 雲端路由器。如果 us-east1 達到已知路徑不重複目的地的數量上限,us-east1 中的子網路就「無法」收到「另一條」目的地為 10.1.2.0/24 且下一個躍點位於 us-west1 的路徑。在這種情況下,us-east1 中的子網路就不會有連結至 10.1.2.0/24 的路徑。

  • 更常見的情況是,某個地區中的 Cloud Router 雲端路由器和位於其他地區的 Cloud Router 雲端路由器都收到了目的地相同,但下一個躍點不同的路徑,則該地區達到已知路徑不重複目的地的數量上限時,Google Cloud 會「忽略」應連至前述目的地,但下一個躍點位於其他地區 Cloud Router 雲端路由器的路徑。

Overview

Cloud Router enforces quotas on resource usage for a variety of 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 may increase automatically based on your use of a product.

Permissions

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

Task Required role
Check quotas for a project Project owner or editor or Quota Viewer
Modify quotas, request additional quota Project owner or editor, Quota Admin, or custom role with the serviceusage.quotas.update permission

Checking your quota

In the Cloud Console, go to the Quotas page.

Using the gcloud command-line tool, 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:

    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: HTTP 413 Request Entity Too Large.

Requesting additional quota

Request additional quota from the Quotas page in the Cloud Console. Quota requests take 24 to 48 hours to process.

  1. Go to the Quotas page.

    Go to the Quotas page

  2. On the Quotas page, select the quotas that you want to change.
  3. Click the Edit Quotas button at the top of the page.
  4. Fill out your name, email, and phone number, and then click Next.
  5. Fill in your quota request, and then click Next.
  6. Submit your request.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, provided that resource is available. It's important to note that quotas do not guarantee resource availability. Even if you have available quota, you won't be able to 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, but that would not be possible if there were 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.