配额和限制

本文档列出了适用于 Cloud Router 的配额和系统限制。

  • 配额用于指定您可以使用的可计数共享资源的数量。配额由 Cloud Router 等服务定义。 Google Cloud
  • 系统限制是无法更改的固定值。

Google Cloud 使用配额来帮助确保公平性并减少资源使用和可用性的激增。配额用于限制您的Google Cloud 项目可使用的 Google Cloud 资源的数量。配额适用于一系列资源类型,包括硬件、软件和网络组件。例如,配额可以限制对某项服务的 API 调用次数、您的项目并发使用的负载均衡器数量或者您可以创建的项目数量。配额可以防止服务过载,从而保护Google Cloud 用户社区。配额还可帮助您管理自己的 Google Cloud 资源。

Cloud 配额系统执行以下操作:

  • 监控您对 Google Cloud 产品和服务的消耗情况
  • 限制这些资源的消耗量
  • 提供请求更改配额值的方法

在大多数情况下,当您尝试消耗的资源超出其配额允许的范围时,系统会阻止对资源的访问,并且您尝试执行的任务会失败。

配额通常在 Google Cloud 项目级层应用。您在一个项目中使用资源不会影响您在另一个项目中的可用配额。在 Google Cloud 项目中,配额在所有应用和 IP 地址间共享。

Cloud Router 资源也有系统限制。系统限制不能更改。

配额

如需更改配额,请参阅申请更多配额

下表涵盖了每个项目的重要配额。如需了解其他配额,请参阅 Google Cloud 控制台的配额和系统限制页面

内容项 配额 备注
每个项目的 Cloud Router 路由器数 配额 无论配额是多少,每个网络在每个区域仅限使用 5 个 Cloud Router 路由器。请参阅限制

每个 VPC 网络中每个区域来自自有区域的唯一 Cloud Router 路由器动态路由前缀

由给定区域中所有 Cloud Router 路由器应用于该区域内子网的已知路由的保证唯一目的地前缀数量上限。这称为某区域的“来自自有区域”配额。

配额

IPv4 和 IPv6 前缀都会计入此配额。

所有已知路由均计入此配额,包括自定义已知路由和 BGP 收到的路由。

路由按唯一目的地进行分组。目的地相同但下一个跃点不同的路由仅计为一个目的地。目的地相同且下一个跃点也相同的路由也仅计为一个目的地。

对于处于全球动态路由模式的网络,可能会达到其中一个唯一动态路由前缀配额,而不会达到另一个配额。如果超出任一配额,在路由丢失时,您可能会遇到间歇性连接问题。如需了解详情,请参阅已知路由示例

如需详细了解这些配额(包括可用于了解当前用量的指标),请参阅排查 BGP 路由和路由选择问题

仅适用于处于全球动态路由模式的 VPC 网络

每个 VPC 网络中每个区域来自其他区域的唯一 Cloud Router 路由器动态路由前缀

可由不同区域中 Cloud Router 路由器应用于给定区域内子网的已知路由的保证唯一目的地数量上限。这称为某区域的“来自其他区域”配额。

配额

IPv4 和 IPv6 前缀都会计入此配额。

所有已知路由均计入此配额,包括自定义已知路由和 BGP 收到的路由。

路由按唯一目的地进行分组。目的地相同但下一个跃点不同的路由仅计为一个目的地。目的地相同且下一个跃点也相同的路由也仅计为一个目的地。

对于处于全球动态路由模式的网络,可能会达到其中一个唯一动态路由前缀配额,而不会达到另一个配额。如果达到任一配额,则在路由丢失时,您可能会遇到间歇性连接问题。如需了解详情,请参阅已知路由示例

如需详细了解这些配额(包括可用于了解当前用量的指标),请参阅排查 BGP 路由和路由选择问题

限制

如下 Cloud Router 限制适用于 Virtual Private Cloud (VPC) 网络。除非另有说明,否则无法提高这些限制。

设限项 限额 备注
每个 VPC 网络和区域组合的 Cloud Router 路由器数上限 5 如果您有足够的项目配额,那么您在给定的 VPC 网络和区域中最多可以创建 5 个 Cloud Router 路由器。
给定 VPC 网络和区域内每个 Cloud Router 路由器的 BGP 对等体数量上限 128 BGP 对等端可以是以下任何一项:
Cloud Router 路由器从单个 BGP 对等端接受的前缀数上限 5000 如果 BGP 对等端通告的前缀超过 5,000 个,则 Cloud Router 路由器会重置 BGP 会话。
单个 BGP 对等方或方向中所有应用的 BGP 路由政策的术语数上限 1000 此限制不会拆分到多个资源中,而是会合并。单个匹配项或操作表达式的大小、一个术语中的操作数量、单个政策中的术语数量或者政策数量均无限制。
给定 Cloud Router 路由器每个 BGP 会话的子网路由通告数量上限 无限制 Cloud Router 路由器可以通告的子网路由无数量限制。子网路由数量由子网数量决定,而子网数量由 VPC 网络配额和限制控制。
给定 Cloud Router 路由器的每个 BGP 会话的自定义通告路由数量上限 200 如果 Cloud Router 路由器上的所有 BGP 会话的自定义通告路由相同,则此限制即为该 Cloud Router 路由器的唯一 IPv4 和 IPv6 自定义通告路由的总数。在这种情况下,每个会话收到的都是同一组自定义通告路由。
对于给定的 Cloud Router 路由器,编码为 UTF-8 时,此限制是 BGP 路由政策中使用的所有匹配项和操作表达式字面量的总大小上限。 上限为 250 KiB 对于给定的 Cloud Router 路由器,此限制不会拆分到多个资源中,而是会合并。单个匹配项或操作表达式的大小、一个术语中的操作数量、单个 BGP 路由政策中的术语数量或者 BGP 路由政策数量均无限制。
单个 Cloud Router 路由器上每分钟对 list-bgp-routes 调用的查询数上限 1500 此配额来自 compute.googleapis.com/list_requests_per_region。如需了解详情,请参阅速率配额
每个 Cloud Router 路由器的 BGP 路由政策数量上限。 500
给定 BGP 会话的自定义已知路由数上限 10

如需详细了解此功能,请参阅自定义已知路由

VPC 网络中给定区域的可配置为自定义已知路由的唯一 IP 前缀的数量上限。此限制允许在多个对等方上使用相同的范围。

10

如需详细了解此功能,请参阅自定义已知路由

已知路由示例

以下示例展示了在超出“来自自有区域”配额或“来自其他区域”配额时可能会遇到的路由丢弃行为。

假设您在同一 VPC 网络中的 us-east1 区域和 us-west1 区域有 Cloud Router 路由器,并且启用了全局动态路由。每个区域中的每个 Cloud Router 路由器会学习 250 个唯一目的地。为方便对此示例进行说明,每个区域中的每个 Cloud Router 路由器不会学习任何相同的目的地。

无论哪个 Cloud Router 路由器获知每个区域内的路由,每个区域的“来自自有区域”配额都会用尽,因为每个区域中的 Cloud Router 路由器会获知 250 个唯一目的地(总共 250 个)。两个区域的“来自其他区域”配额也会用尽,因为每个 Cloud Router 路由器会从其他区域导入 250 个唯一目的地。如果示例 VPC 网络使用区域动态路由,则每个区域中的“来自其他区域”配额将不适用,因为区域动态路由模式指示 VPC 网络仅在与路由的下一个跃点匹配的区域中创建动态路由。

超出某个区域的“来自自有区域”配额

假设连接到 us-west1 中的 Cloud Router 路由器的本地路由器通告了第 251 个目的地。us-west1 区域中的 Cloud Router 路由器会按照确定性路由顺序选择 251 个唯一目的地中的 250 个。这些路由器会将这 250 个唯一目的地发送到 VPC 网络,从而在 us-west1 区域中创建 250 个动态路由。

由于 VPC 网络使用全球动态路由模式,因此它还会根据每个其他区域的“来自其他区域”唯一目的地配额,在每个其他区域中最多创建 250 个动态路由。下一部分将更详细地介绍其他区域中发生的情况。

超出某个区域的“来自其他区域”配额

us-west1 区域中的 Cloud Router 路由器获知 251 个唯一目的地时,us-west1 的 251 个唯一目的地中有 250 个可供 us-east1 区域中的资源使用,因为 us-east1 区域的“来自其他区域”配额只能接受 250 个唯一目的地。

假设您在同一 VPC 网络的第三个区域 (us-central1) 中创建一个 Cloud Router 路由器。假设新的 Cloud Router 路由器从其 BGP 对等端学习了 10 个唯一目的地。尽管未超出 us-central1 区域的“来自自有区域”配额,但由于其他两个区域总共提供了 500 个唯一目的地(us-east1 提供了 250 个,us-west1 提供了另外 250 个),因此超出了 us-central1 区域的“来自其他区域”配额。

确定性路由顺序会按照区域,为其他区域中不超过 250 个唯一目的地选择路由,如下表所示。

区域 区域内的本地唯一目的地
(使用区域的“来自自有区域”配额)
其他区域的唯一目的地
(使用区域的“来自其他区域”配额)
us-west1

收到 251 个。确定性路由顺序选择了 251 个中的 250 个,并丢弃一个。在 us-west1 中创建了 250 个下一个跃点在 us-west1 中的动态路由。

选择的 250 个前缀与其他区域共享。

收到 260 个(us-east1 中 250 个,us-central1 中 10 个)。确定性路由顺序选择了 260 个中的 250 个,并丢弃 10 个。

us-west1 中创建了 250 个下一个跃点在 us-west1 之外的动态路由。

us-east1

收到 250 个。确定性路由顺序选择所有 250 个。在 us-east1 中创建了 250 个下一个跃点在 us-east1 中的动态路由。

选择的所有 250 个前缀与其他区域共享。

收到 260 个(us-west1 中 250 个,us-central1 中 10 个)。确定性路由顺序选择了 260 个中的 250 个,并丢弃 10 个。

us-east1 中创建了 250 个下一个跃点在 us-east1 之外的动态路由。

us-central1

已收到 10 个。确定性路由顺序选择所有 10 个。在 us-central1 中创建了 10 个下一个跃点在 us-central1 中的动态路由。

选择的所有 10 个前缀与其他区域共享。

收到 500 个(us-west1 中 250 个,us-east1 中 250 个)。确定性路由顺序选择了 500 个中的 250 个,并丢弃 250 个。

us-central1 中创建了 250 个下一个跃点在 us-central1 之外的动态路由。

虽然超出了 us-central1 区域的“来自其他区域”配额,但其“来自自有区域”配额可以接受下一个跃点位于 us-central1 区域中的目的地。

确定性路由丢弃行为

Cloud Router 路由器根据收到的每个前缀的子网掩码长度和字典特征来实施确定性路由丢弃行为。在每个区域内,以下过程独立应用于该区域的“来自自有区域”目的地列表和该区域的“来自其他区域”唯一目的地列表:

  • 列表首先按子网掩码长度由短到长排序,然后按字典顺序排列。例如,10.0.0.0/8 排在 10.2.1.0/24 之前,后者排在 10.99.1.0/24 之前。

  • 列表中的前 250 个条目会被保留。所有其他条目则被舍弃。

超出某个区域的“来自其他区域”配额中所述,确定性丢弃行为会独立应用于每个区域的“来自自有区域”配额和每个区域的“来自其他区域”配额。

确定性路由丢弃行为会产生以下后果:

  • 如果同时收到 IPv4 和 IPv6 前缀,则在超出唯一目的地配额时,Cloud Router 路由器通常会先舍弃 IPv6 前缀。这是因为 IPv6 最常见的最短子网掩码长度 (/48) 超过 IPv4 的最长子网掩码长度 (/32)。

  • 如果在每个区域中学习的前缀集保持不变,Google Cloud 会基于 VPC 网络的动态路由模式,在每个区域中设置一组一致的本地动态路由。Cloud Router 任务重启时,这种一致性(包括 Cloud Router 路由器丢弃的路由)会得到保留。

避免丢弃路由

在路由丢失期间,丢弃前缀的连接中断。为避免路由丢弃,请使用 Cloud Monitoring 或 Cloud Logging 监控每个区域的“来自自有区域”和“来自其他区域”的前缀使用情况,并确保其通告的唯一目的地数量不会超出每个配额。

请考虑汇总路由,以减少唯一目的地的数量。例如,如果您有四个子网 10.10.10.0/2410.10.10.1/2410.10.10.2/2410.10.10.3/24,则可以将它们汇总为一个前缀 10.10.0.0/22

如果无法进行汇总,请与您的 Google Cloud 销售团队联系以讨论替代方案。

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:
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

  1. In the Google Cloud console, go to the Quotas page.

    Go to Quotas

  2. 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 adjust most quotas, use the Google Cloud console. For more information, see Request a quota adjustment.

Console

  1. In the Google Cloud console, go to the Quotas page.

    Go to Quotas

  2. On the Quotas page, select the quotas that you want to change.
  3. At the top of the page, click Edit quotas.
  4. For Name, enter your name.
  5. Optional: For Phone, enter a phone number.
  6. 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 a given 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.