Internal ranges overview

Internal ranges let you allocate blocks of internal IP addresses and specify how those addresses can be used. You can use internal ranges to help you manage Virtual Private Cloud (VPC) network topology as networks grow more complex with features like VPC Network Peering and Shared VPC.

Specifications

  • An internal range resource represents an internal CIDR block that is allocated from within a VPC network.
  • When you create an internal range, you configure the following:
    • If the range can be used by Google Cloud resources in its parent VPC network.
    • If the range is reserved for external usage.
    • How the range can be used if VPC Network Peering is configured.
  • You can't create an internal range that overlaps with IP addresses that are used by Google Cloud resources in the range's VPC network.

  • You can't create Google Cloud resources that use IP addresses from an existing internal range unless you explicitly associate the resource with the internal range.

    For example, consider an internal range for 10.0.0.0/24. If you try to create a subnet in the internal range's VPC network that uses the range 10.0.0.0/25, the subnet creation will fail, unless you associate the subnet with the internal range.

Peering types

The peering type of an internal range specifies the range's behavior with respect to VPC Network Peering. The peering type can be one of the following:

  • FOR_SELF: the internal range can only be used in the VPC network where it was created. The range is accessible from its associated VPC network and peers of that VPC network. Peers of peer networks, however, cannot use this range. This is the default setting.

  • FOR_PEER: the internal range can only be associated with resources in peer networks. No resource within the range's parent VPC network can be associated with the range, but resources in peer networks can.

  • NOT_SHARED: the internal range can only be associated with resources in the network where the range was created, without sharing the range with its peers. A peered network can't use the internal range in a way that is visible to the parent VPC network. A peered network can use the same range if the peering type is NOT_SHARED in both networks.

Usage types

The usage type of an internal range resource specifies whether the allocated CIDR block can be associated with other Google Cloud resources in its parent VPC network. The usage type for an internal range can be one of the following:

  • FOR_VPC: the range can be associated with other Google Cloud resources in its parent VPC network. This is the default setting.

  • EXTERNAL_TO_VPC: the range cannot be associated with other Google Cloud resources in its parent VPC network.

  • FOR_MIGRATION: the range can be used to migrate a subnet range, including from one peered VPC network to another.

Migrating subnet ranges

To migrate a CIDR range from one subnet to another, you must delete the subnet and then recreate it. Normally, when you delete a subnet, its CIDR range is released and can be used by any other resource. To reserve the CIDR range during a migration—after the original subnet is deleted but before the new subnet is created—you can create an internal range that has the FOR_MIGRATION usage type.

An internal range for migration specifies a CIDR range, a source subnet, and a target subnet.

  • The CIDR range must match or contain the source subnet range.
  • The source and target subnets can be in the same project or in different projects.
  • The source subnet must be in the same project as the internal range resource.
  • The target subnet doesn't need to exist at the time that you create the internal range.

When you delete the source subnet, the CIDR range can only be assigned to a subnet that matches the target subnet.

After you've migrated the subnet, you can delete the internal range.

Internal ranges with usage type FOR_MIGRATION must have the peering type FOR_SELF.

Quota

There is a limit to how many internal range resources you can create in a single project. For more information, see the per-project quotas in the VPC documentation.

What's next