You can use IPs rented with INTERLIR Marketplace as BYOIPs with Google Cloud. Bring your own IP (BYOIP) lets you provision and use your own public IPv4 addresses for Google Cloud resources.
After the IP addresses are imported, Google Cloud manages them in the same way as Google-provided IP addresses, with these exceptions:
Warning: Google does not support overlapping BYOIP route announcements. For example, importing 203.0.112.0/23 is not supported if 203.0.112.0/23 or a subset of this prefix, such as 203.0.112.0/24, is advertised outside Google. If Google and another network advertise the same route with matching or mismatched prefix lengths, you might experience unexpected routing and packet loss.
Live migration lets you control when Google starts advertising routes for your prefix. Live migration is not available by default. To request access, contact your Google Cloud representative.
To bring your own IP to Google, you create a public advertised prefix (PAP). Verification of ownership is done for this public advertised prefix using ROA and reverse DNS validation. After verification is complete, we configure the announcement of this prefix to the internet, but the prefix is not advertised until it is provisioned. It takes up to four weeks for the public advertised prefix to be provisioned.
While you wait for the public advertised prefix to provision, you split the prefix into public delegated prefixes (PDP), which you configure to have regional or global scope. You can then either divide the public delegated prefix further, or use it to create assignable IP addresses. It takes up to four weeks for the public delegated prefix to be provisioned.
Once provisioning of the public delegated prefix is complete, the public advertised prefix is advertised to the internet. If you’re using live migration, see using live migration for additional steps.
A public advertised prefix (PAP) is a resource in Compute Engine that represents an IP prefix that you bring to Google Cloud. This lets you allocate IP addresses from your own prefix to Google Cloud resources. The public advertised prefix is a single unit of route advertisement. Google’s global backbone advertises the public advertised prefix from all of its points of presence. IP addresses in the public advertised prefix always use 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 size /24. A smaller CIDR range, for example /25, cannot be created as a new public advertised prefix. However, once created, you can break up a public advertised prefix, say a /24 or /23, into smaller public delegated prefixes.
A public delegated prefix (PDP) is an IP block within your public advertised prefix that is configured within a single scope (a specific region or global). The IP blocks must be delegated and assigned to a scope before you can allocate IP addresses to your project or organization.
You can break up a public advertised prefix into multiple public delegated prefixes and configure each of them with whatever scope you want in your Google Cloud projects. You can break up a single public delegated prefix into multiple smaller blocks, but these blocks must have the same scope as the parent block. You can configure multiple non-contiguous public delegated prefixes in a given scope. These smaller blocks are public delegated prefixes, but are also referred to as sub-prefixes.
When you create IP addresses from a public delegated prefix, the IP addresses can be used only within the project and scope that they are allocated to. Anyone who has the appropriate IAM permissions in the project can use the IP addresses:
compute.addresses.* for regional IP addressescompute.globalAddresses.* for global IP addressesYou can designate an administrator for your BYOIP prefixes and addresses by assigning them the Compute Public IP Admin role (roles/compute.publicIpAdmin). This role lets them manage publicly routable IPs in your organization.
The Public IP Admin can do the following tasks:
It’s important to plan your deployment, because provisioning and deletion processes require several weeks to complete. For more information about the provisioning timeline and allowed prefix sizes, see Limitations.
Here are some decisions that should be considered when you plan your deployment:
pap-203-0-113-0-24, pdp-203-0-113-0-25, sub-203-0-113-0-28, where the letters denote the resource type, and the numbers denote the specific prefix and prefix length./24 public advertised prefix. You know you need some IP addresses in us-central1, some IP addresses for global load balancers, and you want to reserve some for future use. You could create the following plan:Prefix typePrefixScopePublic advertised prefix203.0.113.0/24Public delegated prefix203.0.113.0/28us-central1Public delegated prefix203.0.113.16/28globalRemaining IP addresses reserved for future useLive migration is a powerful feature that requires detailed planning and execution.
Use live migration to import a BYOIP prefix when any part of the prefix is already publicly advertised. Importing an advertised prefix without using live migration might cause unexpected routing and packet loss.
Live migration has limited availability. Contact your Google Cloud representative to get access before you create a public delegated prefix with live migration enabled.
You enable live migration when you create a public delegated prefix. To prevent Google from advertising the public advertised prefix to peers, you must ensure the following:
Figure 2 displays the same project with different configurations, one of which prevents the prefix from being advertised, and two which cause the public advertised prefix to be advertised.
Figure 2 illustrates the following scenarios:
You control when the advertisement starts by assigning IP addresses from your public delegated prefix to Google Cloud resources. For more information, see Using live migration.
After your live migration is complete, contact your Google Cloud representative so that they can disable live migration for your prefix. By default, live migration is disabled 30 days after you start advertisement of the public advertised prefix. If you need to have the live migration option available for longer than 30 days, contact your Google Cloud representative.
When planning a live migration, it is important that you understand the following requirements and limitations:
/24 because /24 is the maximum routable prefix-length on the internet./23 which is actively routed from their on-premises location. The customer plans to disaggregate the /23 into two /24 prefixes, and announce the more specific routes from their on-premises location. Following the disaggregation, they plan to configure a /23 public advertised prefix for BYOIP. They assume that the more specific routes from their on-premises location take precedence over the shorter BYOIP prefix, and that traffic continues to route to the more specific on-premises prefixes.Unfortunately, this plan works only partially:/24 on-premises prefixes./24 prefixes. Their public advertised prefix is the aggregate /23.The customer migrates a single /24 to Google and withdraws the on-premises prefix, but leaves the other /24active in the on-premises location.This configuration results in some of the traffic routing to Google for the whole /23 prefix, even though there is still a more specific /24 prefix announced from the on-premises location. This scenario is difficult to diagnose, since various Autonomous Systems deliver traffic to your on-premises location, but others deliver to Google, in which case the traffic is dropped.As a best practice, follow these recommendations when using live migration.
/23 should be disaggregated into two /24 prefixes and announced as such from their on-premises location before you create the public advertised prefix.We recommend that you use organizations to benefit from features such as IAM permissions at the organization level and Shared VPC. See creating and managing organizations for more information about using an organization.
In this example of a project belonging to an organization, there is a dedicated project, Public IP Project, used to manage BYOIP addresses. The Public IP Admin for the organization has created the public advertised prefix and public delegated prefixes in the Public IP Project.
When the VPC Project needs public IP addresses, the Public IP Admin for the organization creates the IP addresses in the VPC Project.
The organization can contain multiple projects, and the Public IP Admin can delegate IP addresses to them all from the Public IP Project.
In this example of an organization that contains Shared VPC, there is a dedicated project, Public IP Project, used to manage BYOIP addresses. The Public IP Admin for the organization has created the public advertised prefix and public delegated prefixes in the Public IP Project
When the Shared VPC Host Project or the related service projects need public IP addresses, the Public IP Admin for the organization creates the IP addresses in the Shared VPC Host Project. The host project and the service projects can access the BYOIP addresses from the host project.
Creating IP addresses in a Shared VPC service project is not supported.
If you use a project that does not belong to an organization, you can’t create a separate project for BYOIP address administration. Create the public advertised prefix and public delegated prefixes in the same project that needs the BYOIP addresses.