About live migration

Live migration lets you control BGP announcement of v1 regional public delegated prefixes. Live migration is not available by default. To request access, contact your Google Cloud customer engineer.

For new configurations, we recommend that you create a v2 public advertised prefix, which lets you create regional public delegated prefixes that provision more quickly, and give you better control over BGP announcement.

For more information about the difference between v1 and v2 public delegated prefixes, see Bring your own IP configurations.

Live migration

Live 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 customer engineer 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:

  • All public delegated prefixes within the public advertised prefix are configured with regional scope, not global scope. See live migration recommendations for more information.

  • No IP addresses in the range of the public advertised prefix are assigned to resources.

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. Public advertised prefix advertisement during live migration (click to enlarge).

Figure 2 illustrates the following scenarios:

  • In the first project example, all public delegated prefixes in the public advertised prefix are configured with live migration enabled. No VMs are configured with IP addresses from this prefix.

    Result: The public advertised prefix is not advertised.

  • In the second project example, all public delegated prefixes in the public advertised prefix are configured with live migration enabled. One VM is configured with an IP address from this prefix.

    Result: 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. No VMs are configured with IP addresses from this prefix.

    Result: The public advertised prefix is advertised.

You control when the advertisement starts by assigning IP addresses from your public delegated prefix to Google Cloud resources. For more information, see Use live migration.

After your live migration is complete, contact your Google Cloud customer engineer 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 customer engineer.

Live migration limitations

When planning a live migration, it is important that you understand the following requirements and limitations:

  • Creating a public delegated prefix with live migration enabled is not supported if the scope is set to global. See live migration recommendations for information about managing live migration for global resources.

  • The longest prefix that can be migrated is a /24 because /24 is the maximum routable prefix-length on the internet.

  • Don't assume that all Google's peers respect the longest prefix between two sites. Some peers might not have full routing tables. As a result, a shorter prefix advertised by Google to those peers is the only (and therefore also the longest) prefix that the peer sees. As a result, the existence of any prefix from Google takes precedence, even if you are advertising a more specific route from your on-premises location.

    For example:

    A customer has a /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:

    • Google peers who have full routing tables prefer the more specific /24 on-premises prefixes.

    • Google peers who don't have full routing tables prefer the public advertised prefix announced from Google, since their routing tables don't include the more specific prefixes.

  • Your traffic is not delivered if Google receives traffic for a valid public advertised prefix for which you have not provisioned services, even if there is an active on-premises advertisement for the prefix.

    For example:

    A customer has an on-premises network comprising two /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 /24 active 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.

Live migration recommendations

As a best practice, follow these recommendations when using live migration.

  • Disaggregate all live migration prefixes into the longest prefixes that reflect how you want to advertise these prefixes during migration. In the previous examples, the /23 should be disaggregated into two /24 prefixes and announced as such from their on-premises location before you create the public advertised prefix.

  • Create exact prefix length ROA requests, and don't rely on the maximum length parameter to be respected.

  • Make sure that RPKI ROA requests exist for both the on-premises origin ASN and Google's origin ASN. If there is no ROA for the on-premises prefix, the creation of a Google origin ROA might cause third-party ISPs to filter out those on-premises prefixes if they are using automatic RPKI filtering.

  • Create separate public advertised prefixes for global resources and regional resources if you need to use live migration. When you enable live migration on a public delegated prefix, you must specify a region for the scope. Specifying global scope for a public delegated prefix that has live migration enabled is not supported. If you create a public delegated prefix with global scope and live migration enabled, the prefix is advertised immediately.

    Having regional prefixes in one public advertised prefix and global prefixes in another public advertised prefix lets you manage them separately. You can manage the live migration of the regional resources and contact your Google Cloud customer engineer to manage live migration of the global resources.

What's next