Introducing internal range API: simplify IP address management in Google Cloud

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:

Infoblox internal range integration 

In collaboration with network security vendor Infoblox, internal range is incorporated into Infoblox’s integrated DNS, DHCP, and IPAM solution (DDI), helping to enhance the visibility and control for VPC networks, cross-cloud networks, and hybrid workload deployments. 

“Managing network resources in a hybrid cloud environment, combining on-prem with private/public clouds, is challenging due to the complexity of IP address management (IPAM). Every environment has unique IPAM needs, requiring careful coordination to ensure consistency and prevent conflicts.” - Jeevan Sharma, Product Manager at Infoblox

The integration between Infoblox and Google internal ranges is as follows: 

Infoblox BloxOne DDI with Google internal ranges enables the enforcement of enterprise IPAM policies on GCP and GKE resources, and cross-cloud networks. BloxOne DDI simplifies IPAM for hybrid cloud environments, providing a centralized view of assigned IP addresses and fully integrates with Google internal range APIs for Google Cloud. BloxOne DDI provides a single workflow using APIs or the Cloud Services Portal (CSP) to create internal range resources in Google Cloud, associate them with VPCs and Subnets, manage usage properties, and define peering intent.

Learn more about the internal range API

Managing private IP addresses is complex, but the internal range API should make it easier. With the internal range API, automatically allocate subnets, reserve and protect an internal range for use with a specific Google Cloud network, as well as cross-cloud ranges such that they won’t be used in your Google Cloud VPC. To learn more about creating and reserving internal IP ranges, start here.

Note: This feature is covered by the Pre-GA Offerings Terms of the Google Cloud Terms of Service. Pre-GA features might have limited support, and changes to pre-GA features might not be compatible with other pre-GA versions. For more information, see the launch stage descriptions.