Subnets and IP addresses in GDC

This overview page explains the operating model for IP addresses in a Google Distributed Cloud (GDC) air-gapped universe. IP addresses are divided into subnetworks, or subnets, to provide manageable segments that you can allocate to your services. You can define subnets with specific IP address ranges, or configure them for dynamic allocation.

This page is for network administrators within the platform administrator group and application developers within the application operator group, who are responsible for managing network traffic for their services in a GDC universe. For more information, see Audiences for GDC air-gapped documentation.

Networks in GDC

There are two distinct network types available in a GDC organization for which you can allocate IP addresses:

  • Virtual Private Cloud (VPC): A network that is allocated internal IP addresses that are only accessible by workloads inside your organization.
  • External network segment: A network that is allocated external IP addresses that are accessible by external networks connected to your organization.

You can allocate subnets within each network type to accomplish specific goals. A subnet is a logical subdivision of an IP address network, defined by classless inter-domain routing (CIDR) ranges. CIDR ranges let you represent IP addresses and their corresponding networks for a service to use. Each network within these network types has an independent subnet tree.

Subnets within a VPC are accessible from within the GDC network and cannot be reached outside GDC. VPC subnets are available to allocate internal IP addresses within your organization. Network segment subnets are exposed to external networks connected to an organization, and let you provide external IP addresses available to networks outside of your organization.

VPC network

A VPC network uses internal IP addresses that are only accessible within your organization that cannot be reached by networks outside your organization.

There are two VPC networks available within your GDC universe:

  • Default VPC: A VPC that is allocated IP addresses for internal workloads, such as containers and virtual machines (VM), within and across multiple zones.
  • Infra VPC: A system-managed VPC that hosts first-party GDC air-gapped services, such as Vertex AI, Observability APIs, and the GDC console. You only define IP addresses within this VPC when planning your organization's IP address architecture.

IP addresses within the Default VPC and Infra VPC cannot overlap with each other within the same organization. For more information, see IPv4 usage and limitations.

Create a subnet in a VPC network to allocate additional IP addresses for internal workloads.

External network segment

An external network segment is allocated external IP addresses that are accessible by external networks connected to your organization. Network segments in GDC are only allocated external IP addresses.

GDC provides the following logically isolated network segments:

You can use distinct interconnects to connect network segments to other external networks. IP addresses within the network segments cannot overlap with each other. For more information, see IPv4 usage and limitations.

Create a subnet in a network segment to allocate additional external IP addresses for services that must connect to networks outside your GDC organization.

Subnet hierarchy

Subnets are categorized by their type:

  • Root: Top-level subnets from which other subnets can be derived. A global root subnet is created in each network during the provisioning of your organization.
  • Branch: Subnets derived from a root or another branch subnet, used to further subdivide IP address space.
  • Leaf: The smallest subdivision, typically used to allocate IP addresses for a specific service or resource.

You can subdivide your subnets to allocate IP addresses to your networks.

This example diagram illustrates how the different subnet types connect to each other:

  • A root subnet of 10.0.0.0/16 that serves as the top-level block for major IP address allocations.
  • From the root subnet, two branch subnets with values of 10.0.1.0/24 and 10.0.2.0/24 are derived. These branch subnets represent subdivisions of the root's address space, intended for more specific purposes.
  • The branch subnets are further subdivided into leaf subnets with values like 10.0.1.10/32, 10.0.1.11/32, and 10.0.2.12/24. These leaf subnets are typically the smallest subdivisions, often allocating single IP addresses for specific services or resources.

This subnet hierarchical structure lets you delegate and organize your network efficiently across the workloads and services that rely on the IP addresses within your network.

Global and zonal subnets

In GDC, you can provision subnets within two different scopes: zonal and global. Zonal and global subnets are defined and operate within distinct API servers and offer different capabilities.

After your organization is provisioned, each network has a global root subnet that is hosted in the global API server of your organization. To provision IP addresses from the global root subnet, you must create a global Subnet resource in the global API server that provisions a CIDR block to a zone or across multiple zones. Within the global subnet, you define the propagationStrategy field to indicate how you want to allocate your CIDR block across zones. This IP address range is provisioned to a zone as a zonal root subnet.

After a zone has its own zonal root subnet, you can create zonal Subnet resources in the zone's management API server to further divide the IP address range of the subnet into additional branch subnets within the zone, or leaf subnets that are available for individual workloads and services within the zone.

Global subnets

You must create a global subnet to allocate IP addresses from the root subnet hosted in the global API server to a zone or multiple zones in your GDC universe.

Global subnets are created in the global API server using the ipam.global.gdc.goog/v1 API group, and include optional fields like zone and propagationStrategy to define their interaction with specific zones.

Global subnets host a CIDR block as a branch subnet range that is consumed by zones across a GDC universe. For more information on where to create your global subnets, see Networks in GDC.

Zonal subnets

A zonal subnet is linked to a specific operational zone, often including direct network configurations. Zonal subnets operate strictly within a single zone, and are mainly provided for virtual machine and container workloads within that zone. A zonal subnet further allocates IP addresses that have already been provisioned for the zone to use by a global subnet.

For VPC-to-VPC communication across zones to function properly, non-overlapping subnets must be used in each zone.

Zonal subnets are created in the management API server using the ipam.gdc.goog/v1 API group, and include an optional networkSpec field in their specification, so you can define zone-specific network elements like gateways and VLAN IDs.

Subnet grouping rules

Subnets are grouped into different categories by labels in the Subnet custom resource:

Network Label
Default VPC ipam.gdc.goog/vpc: default-vpc
Infra VPC ipam.gdc.goog/vpc: infra-vpc
Admin Network Segment ipam.gdc.goog/network-segment: admin
Data Network Segment ipam.gdc.goog/network-segment: data

The four CIDR ranges were set in your organization as part of the bootstrap process. The four corresponding global subnets reside in the global API server. Those global subnets are the root-level CIDR range for each network across all the zones in an organization. All the root-level global subnets have the label ipam.gdc.goog/usage: network-root-range.

For each zone, a zonal network root subnet is initially available in the global API server that originates from the organization provisioning. You can create additional root subnets to expand your IP address space. Each root subnet hosts a CIDR range for a network in the specific zone, and logically serves as the zonally-scoped root subnet with the label ipam.gdc.goog/usage: zone-network-root-range. This root subnet must be initially created in the global API server and is automatically propagated to a specified zone. For more information on subnet scopes, see Global and zonal subnets.

You must use the defined labels when creating a Subnet custom resource to apply it to the appropriate GDC network. The following diagram illustrates global and zonal networks within a GDC universe:

Subnets reside within a zone and in the global API server.

In this diagram, there are two organizations that span a multi-zone universe. Each organization defines the VPC networks and external network segments. In this example, anycast IP addresses are used to route traffic between the zonal external network segments so the closest or best-performing zone services the networking request. For more information on anycast IP addresses, see IP addresses in GDC.

Static and dynamic CIDR configuration

When defining subnets, you can use a static or dynamic configuration for assigning the CIDR blocks.

Static CIDR configuration lets you explicitly specify the exact CIDR block for your subnet. Statically allocate your CIDR block when you require precise control over your IP address space. Use the spec.ipv4Request.cidr field in the Subnet custom resource to specify the exact, predefined IP address range.

Dynamic CIDR configuration offers greater flexibility by allowing the system to automatically allocate a CIDR block for your subnet. Instead of providing a full CIDR, you specify the required prefix length in the spec.ipv4Request.prefixLength field. Dynamically allocate your CIDR block if you prefer the system to automatically delegate IP addresses to your subnets, simplifying network planning and reducing the risk of IP address conflicts. The system selects an available CIDR block of the specified size from the parent network.

For more information, see the SubnetRequest API.

IP addresses in GDC

Resources such as VMs and load balancers have IP addresses in GDC. These IP addresses let GDC resources communicate with other resources within an organization or to external networks connected to your organization. The following IP address types are available in a GDC universe:

External IP address

External IP addresses are advertised to external networks connected to an organization. Resources with external IP addresses, such as load balancers and NAT, can communicate with external networks. With GDC, you can use private or public IP addresses as external addresses. Provide external IPv4 addresses for resources in the following ways:

  • Bring your own external IP addresses (BYOIP): You provide these external IP addresses for your organization. BYOIP external IP addresses can overlap with other organizations as long as they don't connect to the same external network.
  • IO-provided external IP addresses: Organizations can use the external IP addresses provided by the infrastructure operator group when connecting to an external network. The infrastructure operator group is the provider of the connectivity to that network.
Internal IP address

Internal IP addresses cannot be reached from outside GDC directly and are not publicly routable. Internal IP addresses are local to a VPC network, a VPC network connected by using VPC network peering, or an on-premises network connected to a VPC network by using Cloud VPN. Resources with internal IP addresses communicate with other resources as if they're all on the same private network.

Anycast IP address

Anycast IP addresses are a special type of external address which are always scoped to the entire GDC universe. GDC leverages anycast IP addresses along with Border Gateway Protocol (BGP) to route traffic to the closest or best-performing zone. Each global Layer 4 service running across two or more zones receives an anycast IP address from the anycast subnet, an external subnet. Each zone advertises the same anycast IP address, but your network picks the best one based on its routing rules. If a zone fails, it withdraws its IP address, and your network automatically reroutes traffic to another zone. This automatic routing provides seamless connectivity even during outages.

Private IP address

Private IP addresses are addresses that cannot be routed on the internet. For a list of private IPv4 ranges, see the entries for private IP address ranges in the Valid IPv4 ranges table.

Public IP address

Public IP addresses are internet routable addresses. In GDC, external IP addresses can be public or private. You can also use public IPv4 addresses as internal addresses when you configure the primary IPv4 address range of a subnet in your VPC network. These addresses are referred to as privately used public IP addresses.

IPv4 usage and limitations

Each network in your GDC universe has some IPv4 address range usage limitations you must consider when allocating IP addresses. IPv6 address ranges are not supported in the Default VPC and Data Network Segment. Reach out to your infrastructure operator group for IPv6 range possibilities in other networks.

Limitations for all IPv4 subnets

These limitations apply to VPC network subnets and external network segment subnets.

  • All subnets must be a unique valid CIDR block.
  • After you create a subnet, it cannot be upscaled, replaced, or shrunk.
  • GDC does not enforce a limit on how large of a CIDR can be created. However, for most IP address ranges larger than /8, additional validations prevent you from creating a subnet that is this large. For example, a subnet cannot overlap with a prohibited subnet. To minimize the chance of choosing an invalid subnet, we recommend that you limit your maximum subnet size to /8.
  • You can't create subnets that overlap with any prohibited subnets, any other subnet in the same VPC network, any subnet in an attached external network segment, or any subnet in a peered network. You must work with your infrastructure operator group to make sure that you don't create overlapping subnets in these scenarios.

  • GDC creates corresponding routes for subnets. VPC network subnets have routes created in your organization's virtual network stack, and external network segment subnets have routes created in your external peered network's routing table.

  • Verify that subnets don't conflict with on-premises IP addressing if you have connected your VPC network to another network using managed VPN, or a shared or dedicated interconnect.

  • Subnets must not match, be narrower, or be broader than a prohibited range. For example, 169.0.0.0/8 is not a valid subnet because it overlaps with the link-local range 169.254.0.0/16 (RFC 3927), which is restricted.

  • Subnets must not span an RFC range, as described in Valid IPv4 ranges, and a privately used public IP address range. For example, 172.0.0.0/10 is not a valid subnet because it includes both the 172.16.0.0/12 private IP address range and public IP addresses.

  • Subnets must not span multiple RFC ranges. For example, 192.0.0.0/8 isn't a valid subnet because it includes both 192.168.0.0/16 (RFC 1918) and 192.0.0.0/24 (RFC 6890). However, you can create two subnets, one with 192.168.0.0/16 and one with 192.0.0.0/24.

Valid IPv4 ranges

The following table describes valid ranges.

Range Description
Private IPv4 address ranges
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Private IP addresses RFC 1918

For information about using 172.17.0.0/16, see Additional considerations.

100.64.0.0/10 Shared address space RFC 6598
192.0.0.0/24 IETF protocol assignments RFC 6890
192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)
Documentation RFC 5737
192.88.99.0/24 IPv6 to IPv4 relay (deprecated) RFC 7526
198.18.0.0/15 Benchmark testing RFC 2544
240.0.0.0/4

Reserved for future use (Class E) as noted in RFC 5735 and RFC 1112.

Some operating systems don't support the use of this range, so verify that your OS supports it before creating subnets that use this range.

Privately used public IP address ranges
Privately used public IPv4 addresses Privately used public IPv4 addresses:
  • Are IPv4 addresses that are normally routable on the internet, but are used privately in a VPC network.
  • Must not belong to a prohibited subnet range.

GDC air-gapped does not assume connectivity to the internet. As a result, GDC air-gapped advertises any public IP address ranges as if they are private to your organization.

If your imported bring your own IP (BYOIP) addresses are public IP address ranges, you must verify that they don't cause network issues in any external networks. Your BYOIP addresses must not overlap with other subnets in your organization.

Prohibited IPv4 subnets

Prohibited subnet ranges include commonly reserved RFC ranges and any globally reserved subnets in your specific GDC universe, as described in the following table. These ranges cannot be used for subnets.

Range Description
GDC infrastructure range A globally reserved CIDR used by the GDC system. If this range is not specified for the zone-infra-cidr field of the customer intake questionnaire (CIQ), GDC uses 172.16.0.0/12 as the GDC infrastructure range by default.
Universe-specific ranges Additional ranges reserved by the infrastructure operator group.
0.0.0.0/8 Current (local) network RFC 1122
127.0.0.0/8 Local host RFC 1122
169.254.0.0/16 Link-local RFC 3927
224.0.0.0/4 Multicast (Class D) RFC 5771
255.255.255.255/32 Limited broadcast destination address RFC 8190 and RFC 919

Unusable addresses in IPv4 subnets

GDC uses the first two and last two IPv4 addresses in each subnet to host the subnet.

Unusable IPv4 address Description Example
Network address First address in the primary IPv4 range. 10.1.2.0 from range 10.1.2.0/24
Default gateway address Second address in the primary IPv4 range. 10.1.2.1 from range 10.1.2.0/24
Second-to-last address Second-to-last address in the primary IPv4 range.

This range is reserved by Google Cloud for potential future use.

10.1.2.254 from range 10.1.2.0/24
Broadcast address Last address in the primary IPv4 range. 10.1.2.255 from range 10.1.2.0/24

Additional considerations

Some Google and third-party products use 172.17.0.0/16 for routing within the guest operating system. For example, the default Docker bridge network uses this range. If you depend on a product that uses 172.17.0.0/16, don't use it as any subnet IPv4 address range.

What's next