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:
Google Cloud does not allow overlapping BYOIP route announcements. This means that if an IP address range, such as 220.127.116.11/23, or a subset of it, such as 18.104.22.168/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.
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.
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.
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.
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
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:
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:
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 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 presents three scenarios to illustrate the outcomes of using live migration for public delegated prefixes within a public advertised prefix:
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.
When considering a live migration, it’s crucial to be aware of specific requirements and limitations:
Here are the recommended best practices for using live migration:
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.
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.
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.
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.
Client Support Teamleader
Having a clear understanding of the different types and purposes of IP addresses
the rights to manage blocks of IP addresses are constantly faced with a dilemma.
In 2011, RIPE announced the depletion of IPv4 addresses. IPv4 addresses continue
addresses are trite. The allocation from the Primary IPv4 Registry, begun by John
unique identifier that points to each device on the internet and allows them to communicate
One of the possible ways to support the development of the IT sector is the effective
Even if you don’t plan to sell your IPv4 network, there are still ways to make
InterLIR GmbH is a marketplace solution that aims to solve network availability problems
l IPv4, where is possible only 4,3 billion combination of the numbers.
The increasing demand for IP blocks has driven up prices and transformed overused