As your network topology grows and becomes more complex, so does the complexity of managing your IP address space. This task becomes even more daunting when deployments are complicated by hybrid infrastructure, cross-cloud networks, VPC peering and shared VPC. To help you simplify private IP management, we are happy to announce the new internal range API, which helps to simplify management of private IP addresses. With the internal range API, you can now:

• Automatically allocate subnets from a free address range within your VPC
• Reserve / protect an internal range for use with a specific Google Cloud network
• Reserve / protect on-premises, or cross-cloud ranges such that they won’t be used in your Google Cloud VPC

In this blog, we’ll show you how to use the interna range API with an overview, and then by creating internal range resources through some common use cases.

The internal range resource

The internal range resource allows you to reserve and protect an IP net block for a VPC network. Once an internal range resource has been created, the range is reserved and protected. Subsequent resource creation (e.g., subnet creation) must refer to the internal range resource directly at time of creation. Any other attempt to use the range will be blocked. By default, Google Cloud enforces that no other resource uses this range within the VPC. Below we demonstrate how this new resource can be used within your VPC.

Note: The Internal range resource is aware of all existing allocations of subnetworks and static routes in the VPC and its peers and does overlap checks at the time of allocation. This allows the internal range to be adopted incrementally in existing networks, to ease ongoing IP address management challenges.

Associate Google Cloud resource to an Internal range

The association between a Google Cloud resource and internal range can be done during resource creation. The internal range enforces intent via usage properties. VPC network peering intent can also be defined by the peering property of the internal range as described in the next section:

Usage types

• FOR_VPC - A VPC resource can use the reserved IP net block by associating it with the internal range resource if usage is set to FOR_VPC. This is the default setting.
• EXTERNAL_TO_VPC -
• Ranges created with the EXTERNAL_TO_VPC usage property cannot be associated with Google Cloud resources within the current VPC and are meant to reserve and protect address ranges for various use cases. For example, if you want to protect an IP range which is already in use on-premises, cross-cloud networks, another VPC, or if you plan to reserve the range for future use.

Peering types

Peering types are utilized if usage is FOR_VPC.

• FOR_SELF - This is the default behavior and dictates that 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. Only resources belonging to the network that is associated with the internal range can refer to it and peers are prevented from exchanging this range.
• FOR_PEER - This behavior can be set when the internal range is being reserved for usage by the peers. This means that no resource within the VPC in which it is being created can use this to associate with a local VPC resource, but one of the peers can. This effectively reserves and “donates” a range for peer networks to use.
• NOT_SHARED (for future use cases) - This behavior can be set when the internal range is being reserved for usage by the VPC on which it is created but not shared with the peers. This effectively reserves the range to be used exclusively by the local VPC.
  
  Note: This flag is intended for future use cases and currently no resources can refer to the internal range associated with this property. This does have the side effect though, that no new static routes can be created that are covered by a protected range.

Use cases

Use case 1: Create subnetworks with internal ranges

Suppose you have a VPC, my-vpc-name. You can create a subnetwork by referring to an internal range to specify the subnet's usable private IP address space. The subnetwork can be associated with an entire internal range or a subset of the range. Secondary ranges for subnetworks can also be associated with internal ranges.

Step 1: Make sure you already have the correct IAM permissions and have created a VPC network.

Step 2: Create an internal range to allocate free address space of the required size. Say we want to create a subnet of size /24

Step 3: Create a subnetwork that uses an entire internal range.

Step 4: Create a subnetwork that uses part of an internal range.

Use case 2: Reserve and protect an on-premises range

When the on-premises network is connected to a VPC network, you can indicate that the range is reserved for on-premises networks by using the “EXTERNAL_TO_VPC” usage attribute. Thus, Google Cloud rejects any attempt to create a subnetwork or route within the VPC that conflicts with the reserved range:

Use case 3: Create GKE clusters with internal ranges

The API provides a way for Google Kubernetes Engine (GKE) to automatically allocate available ranges, while ensuring no conflicts exist.

Step 1: Make sure that you already have correct IAM permissions and have created a VPC accordingly.

Step 2: We will now reserve GKE Nodes, GKE Pods and GKE services IP ranges as shown below:

a)

b)

c)

Step 3: Create a subnet with the above internal ranges:

Step 4: Create a VPC native cluster: