About Hybrid Subnets

Hybrid Subnets lets you combine an on-premises subnet with a Virtual Private Cloud (VPC) subnet to create a single logical subnet. You can migrate individual workloads and virtual machine (VM) instances from the on-premises subnet to the VPC subnet over time without needing to change IP addresses. After all workloads and VMs have been migrated, you can decommission the on-premises subnet.

In a hybrid subnet, on-premises routers and Cloud Routers advertise routes by using Border Gateway Protocol (BGP) (click to enlarge).

Hybrid Subnets and Migrate to Virtual Machines

We recommend using Migrate to Virtual Machines with Hybrid Subnets to automate the process of migrating VMs from a VMware source. Migrate to Virtual Machines is supported by Google.

For more information about migration options, see Migration resources.

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 support with planning a migration to Google Cloud by using Hybrid Subnets, file a support case.

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

Specifications

  • Hybrid Subnets requires a network connectivity product such as Cloud VPN or Cloud Interconnect.
  • An on-premises router uses proxy ARP to route traffic from on-premises machines to Google Cloud VMs by using routes learned from Cloud Router custom advertised routes.
  • The primary IPv4 address range of the Google Cloud subnet must match the IP address range of the on-premises 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 IPv4 subnet ranges and secondary IPv4 subnet ranges, and IPv6 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 an on-premises 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

  • The maximum number of VMs in a VPC network that uses Hybrid Subnets is 130. Exceeding this limit can 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 doesn't support Google Cloud VMware Engine. We recommend Migrating VMware VMs using VMware HCX.
  • If an on-premises workload has the same IP address as the Cloud Router, workloads in the VPC part of a hybrid subnet can't send packets to that IP address. For example, if the hybrid subnet's IP address range is 192.168.1.0/24, workloads in the VPC subnet can't reach 192.168.1.1.
  • 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 on-premises part of a hybrid subnet.
  • Workloads in the on-premises part of a hybrid subnet can't reach Google APIs and services by using Private Google Access.
  • Workloads in the on-premises part of a hybrid subnet can't reach Private Service Connect endpoints for Google APIs.
  • Hybrid Subnets doesn't support site-to-site data transfer.
  • Hybrid Subnets doesn't support migrating workloads from other cloud service providers or migrating workloads within Google Cloud because those environments don't support proxy ARP.
  • A hybrid subnets can't connect to peer networks by using Network Connectivity Center.

Considerations for using Hybrid Subnets

The following sections describe considerations for using Hybrid Subnets.

Network performance

Hybrid Subnets uses Layer 3 of the OSI model to route packets between the on-premises 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 an on-premises 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.

Proxy ARP and Hybrid Subnets

Proxy ARP is required for Hybrid Subnets. We recommend the following for using proxy ARP in the on-premises part of a hybrid subnet:

  • Consult the vendor of your on-premises 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.

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 on-premises workloads.

Pricing

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

For more information, see Virtual Private Cloud pricing.

What's next