Bring Your Own IP to Google Cloud: InterLIR Marketplace

With INTERLIR Marketplace, you have the flexibility to use the rented IPs as Bring Your Own IP (BYOIP) with Google Cloud. BYOIP allows you to provision and utilize your own public IPv4 addresses for your Google Cloud resources. This feature enables seamless integration of your existing IP addresses with the Google Cloud platform, providing you with more control and convenience in managing your network infrastructure.

Once the IP addresses are imported into Google Cloud through BYOIP, Google manages them in a manner similar to its own provided IP addresses, with a few exceptions:

The imported IP addresses are exclusively available to the customer who brought them, ensuring dedicated usage.
There are no charges for idle or in-use IP addresses, providing cost efficiency for the customer.

Google Cloud does not allow overlapping BYOIP route announcements. This means that if an IP address range, such as 203.0.112.0/23, or a subset of it, such as 203.0.112.0/24, is already being advertised outside of Google, importing the same range or a subset of it into Google Cloud is not supported. Having overlapping route announcements with matching or mismatched prefix lengths between Google and another network can lead to unexpected routing issues and packet loss.

For managing the route advertisement of your imported prefix, Google Cloud offers a feature called live migration. Live migration allows you to control the timing of when Google Cloud starts advertising routes for your imported IP address range. However, it’s important to note that live migration is not available by default and needs to be requested from Google Cloud. To request access to the live migration feature, you can reach out to your Google Cloud representative.

Overview

To bring your own IP to Google Cloud, you first create a public advertised prefix (PAP). Verification of ownership is performed for this PAP through the use of Route Origin Authorization (ROA) and reverse DNS validation. After successful verification, the announcement of this PAP to the internet is configured, but the prefix is not advertised until it undergoes provisioning. The provisioning process for the public advertised prefix typically takes up to four weeks.

During the waiting period for provisioning, you divide the prefix into public delegated prefixes (PDP). These PDPs can have either regional or global scope, and you have the option to further divide them or use them to create assignable IP addresses. The provisioning of the public delegated prefix also takes up to four weeks

Once the provisioning of the public delegated prefix is completed, the public advertised prefix is then advertised to the internet. If you are using live migration, there may be additional steps involved, so it is recommended to refer to the specific guidelines for using live migration provided by Google Cloud.

Public Advertised Prefixes

A public advertised prefix (PAP) is a resource within Google Cloud’s Compute Engine that allows you to bring your own IP prefix to the platform. This enables you to allocate IP addresses from your own prefix to Google Cloud resources. The PAP represents a single unit of route advertisement, and Google’s global backbone advertises it from all of its points of presence. IP addresses within the public advertised prefix always utilize the Premium Tier of Network Service Tiers.

When creating a new public advertised prefix, it must have an IPv4 IP range with a minimum CIDR range of /24. It is not possible to create a new public advertised prefix with a smaller CIDR range, such as /25. However, once a public advertised prefix is created, you have the flexibility to break it up into smaller public delegated prefixes, such as /24 or /23.

Public delegated prefixes

A public delegated prefix (PDP) is a specific IP block within your public advertised prefix that is configured to operate within a defined scope, which can be a particular region or global in Google Cloud. Before you can allocate IP addresses to your project or organization, these IP blocks must be delegated and assigned to a specific scope.

Google Cloud provides the flexibility to break up a public advertised prefix into multiple public delegated prefixes. Each of these public delegated prefixes can be configured with its own scope in your Google Cloud projects. Additionally, you have the option to further divide a single public delegated prefix into multiple smaller blocks, but it is important to note that these smaller blocks must have the same scope as the parent block. Within a given scope, you can also configure multiple non-contiguous public delegated prefixes, which are also referred to as sub-prefixes.

IP addresses

Once IP addresses are created from a public delegated prefix, they are restricted for use within the specific project and scope to which they are allocated. Any user with the appropriate IAM permissions in the project can utilize these IP addresses for their designated purposes:

compute.addresses.* for regional IP addresses
compute.globalAddresses.* for global IP addresses

Public IP Admin role

To appoint an administrator for your BYOIP prefixes and addresses, you can grant them the Compute Public IP Admin role (roles/compute.publicIpAdmin). With this role, they gain the ability to manage publicly routable IPs within your organization.

The Public IP Admin’s tasks include:

Configuring public advertised prefixes within their own project.
Setting up public delegated prefixes using the configured public advertised prefixes within their own project.
Delegating sub-prefixes from the public delegated prefixes to specific projects within the organization.
Revoking previously delegated sub-prefixes from the public delegated prefixes for specific projects within the organization.
Deleting public delegated prefixes.

Planning your deployment

Effective planning is crucial when deploying BYOIP addresses, as the provisioning and deletion processes can take several weeks to complete. To aid in the planning process, consider the following decisions:

Administration Responsibility: Determine who will be responsible for administering the BYOIP addresses. Usually, this is an admin or a specific group, distinct from those managing individual projects. Use IAM roles and permissions to differentiate privileges for public advertised and delegated prefixes.
Prefix Management: Consider how prefixes will be managed across different projects. It is recommended to centrally manage prefixes in a dedicated project, separate from the projects where IP addresses will be utilized. This isolation helps avoid confusion and unauthorized use of prefixes.
Naming Convention: Each BYOIP resource (public advertised prefix, public delegated prefix, sub-prefix) requires a name for management purposes. Select descriptive and easily manageable names during resource creation, as they cannot be changed without recreating the resource.
Provisioning Locations: Think of the provisioning process as “stocking” IPs into regions or the global scope. Plan and deploy public delegated prefixes well ahead of their actual need, as provisioning takes several weeks. If unsure about where IPs will be used, provision only the prefixes needed immediately. Moving a public delegated prefix requires deletion and recreation, which can take up to eight weeks. Once provisioning is complete, delegate sub-prefixes to projects and create addresses for use with resources.

To illustrate, let’s say you have a /24 public advertised prefix and require IPs in us-central1 and for global load balancers, with some reserved for future use. You could create the following plan:

Public Advertised Prefix: 203.0.113.0/24

Public Delegated Prefix: 203.0.113.0/28 (for us-central1)

Public Delegated Prefix: 203.0.113.16/28 (for global)

Remaining IP addresses reserved for future use.

By planning ahead and effectively managing prefixes, you can ensure smooth deployment of BYOIP addresses in your Google Cloud projects.

Live Migration

Live migration is a powerful feature that allows you to import a BYOIP prefix when any part of the prefix is already publicly advertised. It requires careful planning and execution to avoid unexpected routing and packet loss.

To use live migration, ensure that the prefix you are importing is not already being advertised. Live migration is not widely available, so contact your Google Cloud representative to request access before creating a public delegated prefix with live migration enabled.

To enable live migration, you must create a public delegated prefix and ensure that all public delegated prefixes within the public advertised prefix have regional scope, not global scope.

Additionally, ensure that no IP addresses within the range of the public advertised prefix are assigned to any resources. By following these recommendations and configurations, you can prevent Google from advertising the public advertised prefix to peers during the migration process.

Figure 2 illustrates the different configurations in a project, with one preventing the prefix from being advertised and two others causing the public advertised prefix to be advertised. Carefully managing the scope and IP address assignments will ensure a successful live migration of your BYOIP prefix.

Figure 2. Public advertised prefix advertisement during live migration (click to enlarge).

Figure 2 presents three scenarios to illustrate the outcomes of using live migration for public delegated prefixes within a public advertised prefix:

In the first project example, all public delegated prefixes in the public advertised prefix have live migration enabled, but no virtual machines (VMs) are configured with IP addresses from this prefix. As a result, the public advertised prefix is not advertised.
In the second project example, all public delegated prefixes in the public advertised prefix have live migration enabled, and one VM is configured with an IP address from this prefix. In this case, the public advertised prefix is advertised.
In the third project example, one public delegated prefix within the public advertised prefix is not configured with live migration enabled, but no VMs are configured with IP addresses from this prefix. Despite the other delegated prefixes having live migration enabled, the public advertised prefix is still advertised.

You have control over when the advertisement of the public advertised prefix starts by assigning IP addresses from your public delegated prefix to Google Cloud resources. For detailed information on using live migration, refer to the relevant documentation.

After completing the live migration process, it is advisable to contact your Google Cloud representative to disable live migration for your prefix. By default, live migration is disabled 30 days after the start of the advertisement of the public advertised prefix. If you need the live migration option available for a longer duration, make sure to communicate this to your Google Cloud representative.

Live migration limitations

When considering a live migration, it’s crucial to be aware of specific requirements and limitations:

Public delegated prefixes with live migration enabled cannot have a global scope; they must be configured with a regional scope. Refer to the live migration recommendations for managing live migration with global resources.
The longest prefix that can be migrated through live migration is a /24, as this is the maximum routable prefix length on the internet.
Keep in mind that not all of Google’s peers may respect the longest prefix between two sites. Some peers might not have complete routing tables, leading to a situation where a shorter prefix advertised by Google takes precedence for those peers. This means that the existence of any prefix from Google will have priority, even if you are advertising a more specific route from your on-premises location.

For example, suppose you have a /23 prefix actively routed from your on-premises location. You plan to disaggregate the /23 into two /24 prefixes and announce the more specific routes from your on-premises location. Simultaneously, you configure a /23 public advertised prefix for BYOIP. While you may assume that the more specific on-premises routes take precedence over the shorter BYOIP prefix, this may not always be the case:
- Google peers with complete routing tables will prefer the more specific /24 on-premises prefixes.
- Google peers with incomplete routing tables will prefer the public advertised prefix announced by Google since their routing tables lack the more specific prefixes.
It’s crucial to understand that if Google receives traffic for a valid public advertised prefix for which you haven’t provisioned services, even if there is an active on-premises advertisement for the prefix, the traffic will not be delivered to you. For instance, if you have an on-premises network with two /24 prefixes and a public advertised prefix is the aggregate /23, migrating a single /24 to Google and withdrawing the on-premises prefix while leaving the other /24 active in the on-premises location can lead to some traffic routing to Google for the whole /23 prefix. This can cause confusion since the traffic is delivered to different destinations based on the routing paths of various Autonomous Systems. As a result, it’s important to carefully plan and configure your live migration to avoid unexpected routing issues and ensure proper traffic delivery.

Live migration recommendations

Here are the recommended best practices for using live migration:

Disaggregate all prefixes intended for live migration into the longest prefixes that accurately reflect how you want to advertise them during migration. For example, if you have a /23 prefix, it should be disaggregated into two /24 prefixes and announced as such from your on-premises location before creating the public advertised prefix.
Create exact prefix length Route Origin Authorization (ROA) requests and avoid relying on the maximum length parameter to be respected. This ensures precise and reliable authorization for the prefixes.
Ensure that RPKI ROA requests exist for both the on-premises origin Autonomous System Number (ASN) and Google’s origin ASN. Having proper ROAs for both origins is important as lacking a ROA for the on-premises prefix while creating a Google origin ROA might cause third-party Internet Service Providers (ISPs) to filter out the on-premises prefixes if they are using automatic RPKI filtering.
If you need to use live migration, create separate public advertised prefixes for global resources and regional resources. Enabling live migration on a public delegated prefix requires specifying a region for the scope. It’s not supported to specify global scope for a public delegated prefix with live migration enabled. By having regional prefixes in one public advertised prefix and global prefixes in another public advertised prefix, you can manage them separately. You can then handle the live migration of regional resources while working with your Google Cloud representative to manage the live migration of global resources. This separation allows for better control and management of the live migration process.

Project architecture

We advise using organizations to take advantage of features like centralized IAM permissions and Shared VPC, providing improved resource management and security in your Google Cloud environment.

BYOIP address administration in an organization

In this scenario, within an organization, a separate project called “Public IP Project” is designated to manage BYOIP addresses. The Public IP Admin, who oversees IP address management for the organization, creates the public advertised prefix and public delegated prefixes within this project.

When a VPC Project requires public IP addresses, the Public IP Admin creates the necessary IP addresses within the VPC Project.

The organization has the flexibility to have multiple projects, and the Public IP Admin can delegate IP addresses to all of them from the central “Public IP Project.” This centralized approach streamlines IP address management across the organization’s projects.

Figure 3. You can use organizations and projects to manage BYOIP addresses.

BYOIP addresses administration with Shared VPC

In this organization with Shared VPC, a separate project called “Public IP Project” is designated to manage BYOIP addresses. The Public IP Admin, responsible for IP address management across the organization, has created the public advertised prefix and public delegated prefixes within this central project.

When the Shared VPC Host Project or related service projects require public IP addresses, the Public IP Admin creates the necessary IP addresses within the Shared VPC Host Project. Both the host project and service projects can access the BYOIP addresses from the host project.

It’s important to note that creating IP addresses directly in a Shared VPC service project is not supported; all IP address management occurs within the central “Public IP Project” and is shared across the relevant projects within the organization.

Figure 4. You can delegate BYOIP addresses to a Shared VPC host project, but not to a Shared VPC service project. However, a service project can use BYOIP addresses that were delegated to the host project.

BYOIP address administration without an organization

If your project is not part of an organization, you cannot create a separate project solely for BYOIP address administration. In such cases, you must create the public advertised prefix and public delegated prefixes directly within the same project that requires the use of BYOIP addresses.