About Hybrid Subnets

Hybrid Subnets helps you migrate workloads from another network—the source network—to a Virtual Private Cloud (VPC) subnet without needing to change any IP addresses. This migration process is called Migrate Motion. By combining a subnet in the source network with a VPC subnet, you create a single logical subnet that lets you migrate individual workloads and virtual machine (VM) instances over time. After all workloads and VMs have been migrated, you can decommission the source subnet.

In a hybrid subnet, a router in a source network and a Cloud Router in a VPC network advertise routes by using Border Gateway Protocol (BGP) (click to enlarge).

Migration options

We recommend using Migrate to Virtual Machines with Hybrid Subnets to automate the process of migrating VMs from a VMware source or from a Google Cloud VMware Engine source.

Hybrid Subnets doesn't support Google Cloud VMware Engine as the migration target. If VMware Engine is your migration target, we recommend migrating VMware VMs using VMware HCX. You don't need to configure Hybrid Subnets when using VMware HCX to migrate to Google Cloud VMware Engine.

Alternatively, you can use third-party migration tools with Hybrid Subnets, as long as the requirements of Hybrid Subnets that are described in this document are fulfilled.

For more information about migration options, see Migration resources.

For information about planning a migration with Migrate to VMs, see Migration journey with Migrate to VMs.

For support with planning a migration to Google Cloud by using Hybrid Subnets, file a support case.

Specifications

  • Hybrid Subnets requires a network connectivity product such as Cloud VPN or Cloud Interconnect.
  • Proxy ARP must be configured in the source network.
  • The source network must be configured to advertise the IP address range of the hybrid subnet.
  • The primary IPv4 address range of the VPC subnet must match the IP address range of the source subnet.
  • You must enable the allow-cidr-routes-overlap flag of a VPC subnet in order to configure the subnet as a hybrid subnet. When allow-cidr-routes-overlap is enabled, Google Cloud allows custom routes to overlap with subnet IP address ranges.
  • The allow-cidr-routes-overlap flag applies to primary and secondary IPv4 subnet ranges.
  • Internal connectivity is maintained between all VMs and workloads in a hybrid subnet.
  • You use Cloud Router custom advertised routes to selectively advertise the IP addresses of VMs as you migrate them to the VPC subnet.
  • As you migrate workloads from a source network to Google Cloud, you update the Cloud Router custom advertised routes to include the IP addresses of the migrated VMs.
  • You can connect a hybrid subnet to a peer VPC network by using VPC Network Peering. The peering configuration for the VPC network that contains the hybrid subnet must be configured to export custom routes. The peering configuration for the other VPC network must be configured to import custom routes.

Limitations

  • VPC networks that use Hybrid Subnets have the following resource limitations:

    These resource limitations are not enforced by Google Cloud limits or quotas. Exceeding them might cause connectivity and stability issues.

  • A hybrid subnet's Cloud Router can't exceed the maximum number of custom advertised routes per BGP session.

  • Broadcast and multicast traffic within a hybrid subnet are not supported.

  • You can't use Layer 3 Partner Interconnect connections that don't support announcing /32 routes with Hybrid Subnets.

  • Hybrid Subnets doesn't support IPv6.

  • Hybrid Subnets can't host workloads at the reserved IP addresses in IPv4 subnets.

  • Cloud DNS inbound forwarding doesn't respond to DNS requests from workloads in the source network.

  • Workloads in the source network can't reach Google APIs and services by using Private Google Access.

  • Workloads in the source network can't reach Private Service Connect endpoints for Google APIs.

  • Workloads in the source network can't be endpoints for hybrid connectivity network endpoint groups that use centralized health checks.

  • Hybrid Subnets doesn't support site-to-site data transfer.

  • You can't connect one hybrid subnet to another hybrid subnet.

  • Hybrid Subnets doesn't detect IP address conflicts between the source network and VPC parts of a hybrid subnet. Ensure that each IP address (except the default gateway) is used only once.

  • Hybrid Subnets doesn't support Google Cloud VMware Engine as the migration target.

  • Hybrid Subnets doesn't support migrating VMs from an Azure or AWS source.

  • Hybrid Subnets doesn't support migrating workloads from other cloud service providers.

  • Hybrid Subnets doesn't support Network Connectivity Center.

Considerations for using Hybrid Subnets

The following sections describe considerations for using Hybrid Subnets.

Proxy ARP and Hybrid Subnets

Hybrid Subnets requires proxy ARP to be configured on the source network's first-hop device. A first-hop device is the point where a host first sends traffic that has a destination outside of its local network. Proxy ARP lets the device respond with its own MAC address when it receives ARP requests for VMs that are in the VPC part of a hybrid subnet. The device can then forward packets to VMs in the VPC subnet by using the CIDR blocks that it has learned from the custom advertised routes of the Border Gateway Protocol (BGP) session on the Cloud Router.

The first-hop device can be a router, virtual appliance, firewall, or a VM running a software solution such as choparp.

We recommend the following for using proxy ARP in your source network:

  • Consult the vendor of your source network fabric for best practices related to enabling proxy ARP and securing your network environment.
  • Disable proxy ARP after you have completed your migration to Google Cloud.

Network performance

Hybrid Subnets uses Layer 3 of the OSI model to route packets between the source network and VPC parts of a hybrid subnet. This approach helps Hybrid Subnets avoid challenges with latency, jitters, and throughput that can happen during migrations when some workloads exist on a source network but other workloads have migrated to the cloud.

In particular, avoiding Layer 2 tunneling helps prevent the performance degradation that's associated with the encapsulation and encryption of an additional Layer 2 overlay. Additionally, Layer 3 routing lets Hybrid Subnets avoid a common issue with Layer 2 tunneling, where traffic is sent to a central node before reaching destinations that can be close to the traffic's point of origin. This issue is sometimes called network tromboning.

Hybrid Subnets' approach to routing means that you can expect performance from a hybrid subnet that's similar to, or the same as, a network that doesn't use Hybrid Subnets.

Firewalls and Hybrid Subnets

Hybrid Subnets avoids challenges related to using firewalls with traffic that's encapsulated in Layer 2 overlays. For Layer 2 traffic, firewalls can only inspect packets at or beyond the overlay endpoints, unless you take specific measures such as transparent decryption or deep inspections of overlay traffic.

No special considerations are needed to use existing firewalls and firewall rules with Hybrid Subnets. However, you might need to Configure firewall rules to ensure that Google Cloud VMs can communicate with workloads in the source network.

Pricing

There is no additional charge for using Hybrid Subnets. However, you are charged for resources and network traffic in the VPC part of a hybrid subnet.

For more information, see Virtual Private Cloud pricing.

What's next