This page provides the planning process and considerations you must take when allocating IP addresses for your Google Distributed Cloud (GDC) air-gapped universe.
Planning the architecture of your IP addresses effectively can mitigate any future networking disruptions for your workloads and services as they scale to changing requirements. For a conceptual overview of subnets and IP addresses in GDC, see Subnets and IP addresses.
This page is for network administrators within the platform administrator group, who are responsible for managing network traffic for their services within an organization. For more information, see Audiences for GDC air-gapped documentation.
Benefits for careful IP address planning
Careful IP address planning provides the following benefits:
- Isolation: Proper network segmentation between different organizations and between management and data planes.
- Scalability: Sufficient IP address space for current and future workloads and services, including administrative services that cannot be allocated additional IP address space after an organization is provisioned.
- Connectivity: Correct routing and reachability for all components within the GDC air-gapped universe, and to external networks as required.
- Compliance: Adherence to specific network addressing schemes or restrictions mandated by your environment.
The GDC architecture uses Virtual Routing and Forwarding (VRF) instances to achieve network isolation and segmentation. Understanding which IP address spaces you manage and the ones exclusively owned by your IO is key to successful planning.
Best practices for IP address architecture
You must factor in the following recommendations to effectively provision a durable IP address architecture that can adapt when your organization's networking requirements change:
- Overlapping and non-overlapping IP addresses:
- Virtual Private Cloud (VPC) networks can overlap between different organizations but must be unique within an organization across all its zones and unique from any networks they peer with.
- External network segments can overlap between different organizations if those organizations use separate interconnects. If they share an interconnect, IP addresses must be unique within the same organization across all its zones and unique from any networks they peer with.
- Minimum CIDR sizes: Adhere to the minimum CIDR prefix lengths specified for each network segment to allocate sufficient address space for system components and future growth.
- RFC 1918 preference: While public IP addresses can be used in most of your managed networks, if the zone does not connect to the internet, RFC 1918 private addresses are generally recommended for internal GDC air-gapped networks.
- OIQ accuracy: The information you provide to your IO in the organization intake questionnaire (OIQ) is critical. Inaccurate or poorly planned IP address ranges can lead to significant deployment challenges.
- Multi-zone: Organization VPCs and external network segments span across a global organization, but require unique IP address allocations per zone that don't overlap within that global organization. Use global subnets to allocate unique IP address ranges per zone for a given organization.
As an example IP address architecture, see the following diagram:
In this diagram, there are two different interconnects that span a multi-zone universe: dedicated interconnect and shared interconnect. Multiple organizations are defined in this universe. Organization 1 is within a dedicated interconnect, so its externally-scoped subnets can overlap with other organizations in the universe. However, the organizations in the shared interconnect cannot have overlapping externally-scoped subnets with each other since they all reside within the same interconnect.
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.
Planning process
Before your organization is provisioned by the IO, you must determine the IP address architecture for your organization. The IO will walk you through these steps.
The high-level process for planning and provisioning an organization's network IP addresses is the following:
Define CIDR ranges: Work with your network team to determine appropriate non-overlapping CIDR blocks for your Default VPC, Infra VPC, Admin Network Segment, and Data Network Segment.
Provide CIDR ranges to the IO: Supply these CIDRs to the IO as part of the OIQ when requesting a new organization. The IO uses the CIDRs to configure the necessary global subnets in the appropriate API servers.
After your organization is provisioned by your IO, you are responsible for managing certain IP address spaces within the organization, primarily for workload deployment and external service exposure.
For more information on each network and how to select the CIDR ranges per network, see IP address considerations for an organization.
IP address considerations for an organization
Review each network and the best practices for setting them up before completing the OIQ for defining CIDR ranges:
- Default VPC: Hosts internal IP addresses for internal workloads. You can allocate additional IP addresses to this network after your organization is provisioned.
- Infra VPC: Hosts internal IP addresses for first-party GDC air-gapped services. You cannot allocate additional IP addresses to this network after your organization is provisioned.
- Admin Network Segment: Hosts external IP addresses for administrative services. You cannot allocate additional IP addresses to this network after your organization is provisioned.
- Data Network Segment: Hosts external IP addresses for external services. You can allocate additional IP addresses to this network after your organization is provisioned.
For more information on network descriptions and the IP addresses they use, see Networks in GDC.
VPC networks
Prepare the following information for each VPC network type to deliver to your IO for the provisioning of your IP address spaces within your organization's VPC networks.
Default VPC
You deploy and manage your internal workloads, such as virtual machines (VM) and containers, from the Default VPC.
IP addresses in the Default VPC must be unique from other VPCs in all zones of your universe and any peered network IP addresses. IP addresses in this VPC can overlap between different organizations, and can be RFC 1918 private IP addresses or public IP addresses. You can create additional Default VPC subnets after the organization is provisioned.
Consider the following information when collaborating with your IO on the Default VPC root IP address range. Note that the corresponding OIQ field and global root subnet name are fixed values and cannot change.
- OIQ Field:
defaultVPCCIDR - Global Root Subnet Name:
default-vpc-root-cidr - Global API Server: Global organization
- Subnet minimum size:
/16per zone - Subnet recommended size:
/16per zone
Infra VPC
You don't directly deploy workloads to the Infra VPC, but you must provide the IP address range for consumption by the system-managed GDC air-gapped services.
IP addresses in the Infra VPC must be unique from other VPCs in all zones of your universe and any peered network IP addresses. IP addresses in this VPC can overlap between different organizations, and can be RFC 1918 private IP addresses or public IP addresses. You cannot create additional Infra VPC subnets after the organization is provisioned.
Consider the following information when collaborating with your IO on the Infra VPC root IP address range. Note that the corresponding OIQ field and global root subnet name are fixed values and cannot change.
- OIQ field:
infraVPCCIDR - Global root subnet name:
infra-vpc-root-cidr - Global API server: Global root
- Subnet minimum size:
/16per zone - Subnet recommended size:
/16per zone
External network segments
Prepare the following information for each external network segment type to deliver to your IO for the provisioning of your IP address spaces within your organization's external networks.
Admin Network Segment
You don't directly deploy external services to the Admin Network Segment, but you must provide the IP address range for consumption by the administrative services that will run in your organization, such as the GDC console and management APIs. You cannot allocate additional IP addresses to this network after your organization is provisioned.
IP addresses in the Admin Network Segment can overlap between different organizations if those organizations use separate interconnect attachment groups. If they share an attachment group, the IP addresses must be unique within the same organization across all its zones and unique from any networks they peer with. You cannot create additional Admin Network Segment subnets after the organization is provisioned.
Consider the following information when collaborating with your IO on the Admin Network Segment root IP address range. Note that the corresponding OIQ field and global root subnet name are fixed values and cannot change.
- OIQ field:
orgAdminExternalCIDR - Global root subnet name:
admin-external-root-cidr - Global API server: Global root
- Subnet minimum size:
/26per zone - Subnet recommended size:
/26per zone
Data Network Segment
You deploy and manage your external services that operate outside of your organization, such as egress Network Address Translation (NAT) and external load balancers, within the Data Network Segment. You can allocate additional IP addresses to this network after your organization is provisioned.
IP addresses in the Data Network Segment can overlap between different organizations if those organizations use separate interconnect attachment groups. If they share an attachment group, the IP addresses must be unique within the same organization across all its zones and unique from any networks they peer with. You can create additional Data Network Segment subnets after the organization is provisioned.
Consider the following information when collaborating with your IO on the Data Network Segment root IP address range. Note that the corresponding OIQ field and global root subnet name are fixed values and cannot change.
- OIQ field:
orgDataExternalCIDR - Global root subnet name:
data-external-root-cidr - Global API server: Global root
- Subnet minimum size:
/26per zone - Subnet recommended size:
/23per zone
What's next
- Interconnect overview
- Create an attachment group
- Provision IP addresses for workloads
- Bring your own external IP addresses