Internal TCP/UDP load balancers as next hops

Internal TCP/UDP Load Balancing is a regional load balancer that enables you to run and scale your services behind an internal IP address. You can use an internal TCP/UDP load balancer as the next hop to which packets are forwarded along the path to their final destination. To do this, you set the load balancer as the next hop in a custom static route.

Before reviewing the information on this page, you should already be familiar with concepts from the following:

• Routes overview
• Internal TCP/UDP Load Balancing overview

An internal TCP/UDP load balancer next hop is useful in the following cases:

• To load balance traffic across multiple VMs that are functioning as gateway or router VMs.

• To use gateway virtual appliances as your next hop for a default route. With this configuration, virtual machine (VM) instances in your Virtual Private Cloud (VPC) network send traffic to the internet through a set of load-balanced virtual gateway VMs.

• To send traffic through multiple load balancers in two or more directions by using the same set of multi-NIC gateway or router VMs as backends. To do this, you create a load balancer and use it as the next hop for a custom static route in each VPC network. Each internal TCP/UDP load balancer operates within a single VPC network, distributing traffic to the network interfaces of backend VMs in that network.

Note: This feature does not support IPv6 addresses.

Architecture

In the following diagram, a VM instance group of router VMs serves as the backend for two different load balancers. The first Internal TCP/UDP Load Balancing sends packets to nic0 of the backend VMs, and the second Internal TCP/UDP Load Balancing sends packets to nic1 on the same backends.

Load balancing to multiple NICs (click to enlarge)

Benefits of using your internal TCP/UDP load balancer as a next hop

When the load balancer is a next hop for a static route, no special configuration is needed within the guest operating systems of the client VMs in the VPC network where the route is defined. Client VMs send packets to the load balancer's backends through VPC network routing, in a bump-in-the-wire fashion.

Using an internal TCP/UDP load balancer as a next hop for a static route provides the same benefits as Internal TCP/UDP Load Balancing. The load balancer's health check ensures that new connections are routed to healthy backend VMs. By using a managed instance group as a backend, you can configure autoscaling to grow or shrink the set of VMs based on service demand.

Specifications

The following are specifications for using internal TCP/UDP load balancers as next hops.

Routes

You can create a custom static route to pass TCP, UDP, and other protocol traffic to an internal TCP/UDP load balancer where the load balancer is the next hop for the static route. The route can be an external (publicly-routable) CIDR prefix or an internal CIDR prefix, if the prefix doesn't conflict with a subnet route. For example, you can replace your default route (0.0.0.0/0) with a route that directs traffic to third-party backend VMs for packet processing.

Caution: When sending traffic to Google APIs and services, don't route the traffic through a next-hop VM or through a next-hop internal TCP/UDP load balancer. Instead, route such traffic through a next-hop default internet gateway. This includes traffic to Google APIs and services sent by means of Private Google Access.

Options for specifying the next hop

You have two options for how to specify the load balancer as the next hop.

Specification option	Next hop network	Can be exported to peered networks
Forwarding rule's name and the load balancer's region	Next hop load balancer and route must be in the same VPC network	Yes, by exporting custom routes (applicable to routes without instance tags)
Internal IP address of the forwarding rule	Next hop load balancer can be in the same VPC network as the route or in a peered VPC network	Yes, always exported (except for routes with instance tags)

Client IP session affinity

Internal TCP/UDP Load Balancing offers two similar "client IP address" session affinity options:

• Client IP (CLIENT_IP): A two-tuple hash of a packet's source IP address and destination IP address. When an internal TCP/UDP load balancer is not a route's next hop, packets sent to the load balancer's forwarding rule IP address share a common destination IP address—the forwarding rule IP address. In this situation, one of the addresses used by the two-tuple hash remains constant. Thus, if the number of configured and healthy backends doesn't change and packets have identical source IP addresses, this two-tuple session affinity option selects the same backend.
• Client IP, no destination (CLIENT_IP_NO_DESTINATION): A one-tuple hash of a packet's source IP address. When you are using an internal TCP/UDP load balancer as a next hop, the destination IP address often varies because destination IP addresses are those specified by the route's destination attribute. In this situation, the two-tuple hash Client IP (CLIENT_IP) session affinity cannot select the same backend even when the number of configured and healthy backends doesn't change and packets have identical source IP addresses. (An exception to this rule is when only one backend is configured.) If you require packets with identical source IP addresses to be routed to the same backend, you must use the Client IP, no destination (CLIENT_IP_NO_DESTINATION) session affinity option.

Destination range

The destination of a custom static route cannot be equal to or more specific than a subnet route. Note that more specific means that the subnet mask is longer. This rule applies to all custom static routes, including when the next hop is an internal TCP/UDP load balancer. For example, suppose that your subnet route is 10.140.0.0/20. The destination of a custom static route can't be the same (10.140.0.0/20), and it can't be more specific, as in 10.140.0.0/22.

Same VPC network and region

Custom static routes that use internal TCP/UDP load balancers as next hops are limited to the following:

• A single VPC network. The load balancer and the custom static route must be in the same VPC network.

• A single region or all regions. Unless you configure global access, the custom static route is only available to resources in the same region as the load balancer. This regional restriction is enforced even though the route itself is part of the routing table for the entire VPC network. If you enable global access, the custom static route is available to resources in any region.

Advertising the custom static route

To advertise the prefix (destination) for the custom static route, you can use a Cloud Router custom route advertisement. The scope of the route advertisement depends on the load balancer's global access setting, as follows:

• When global access is disabled, the internal TCP/UDP load balancer is only available to VMs, Cloud VPN tunnels, and Cloud Interconnect attachments (VLANs) that are in the same region as the load balancer. Consequently, a custom route advertisement for a custom static route's prefix only makes sense if the Cloud Router and load balancer are in the same region.

• When global access is enabled, the internal TCP/UDP load balancer is available to VMs, Cloud VPN tunnels, and Cloud Interconnect attachments (VLANs) that are in any region. With global dynamic routing, on-premises systems can use the custom static route from any connected region.

The following table summarizes the accessibility of the load balancer.

Global access	VPC network dynamic routing mode	Load balancer access
Disabled	Regional	Accessible by routers in the same region
Disabled	Global	Accessible by routers in the same region
Enabled	Regional	Accessible by all routers in any region
Enabled	Global	Accessible by all routers in any region

For more information, see Internal TCP/UDP Load Balancing and connected networks.

Order of operations

You must create an internal TCP/UDP load balancer before you can create a custom static route that uses it as a next hop. The load balancer must exist before you can create the route. If you try to create a route that refers to a nonexistent load balancer, Google Cloud returns an error.

You specify an internal TCP/UDP load balancer next hop by using the forwarding rule's name and the load balancer's region, or by using the internal IP address associated with the forwarding rule.

After you've created a route with a next hop that refers to an internal TCP/UDP load balancer, you cannot delete the load balancer unless you first delete the route. Specifically, you can't delete an internal forwarding rule until no custom static route uses that load balancer as a next hop.

Backend requirements

• You must configure all of the internal TCP/UDP load balancer's backend VMs to allow IP forwarding (--can-ip-forward = True). For more information, see Considerations for instance-based or load balancer-based routing.

• You cannot use an internal TCP/UDP load balancer whose backends are Google Kubernetes Engine (GKE) nodes as a next hop for a custom static route. Software on the nodes can only route traffic to Pods if the destination matches an IP address managed by the cluster, not an arbitrary destination.

Processing of TCP, UDP, and other protocol traffic

Important: The information in this section applies only to custom routes created before May 15, 2021.

If an internal TCP/UDP load balancer as next hop route was created before May 15, 2021, the load balancer forwards only TCP and UDP traffic on all ports to the backend VMs, regardless of the forwarding rule or backend service configuration. All other traffic, such as ICMP pings, will be handled by the next most specific route in your VPC network.

If a route created before May 15, 2021 was still in operation on August 16, 2021, it was automatically migrated to forward all protocol traffic starting August 16, 2021.

When an internal TCP/UDP load balancer is deployed as a next hop, Google Cloud forwards all traffic on all ports to the backend VMs, regardless of the following:

• The forwarding rule's protocol and port configuration
• The backend service's protocol configuration

The internal TCP/UDP load balancer which is the next hop of the route, seamlessly supports forwarding of all traffic for protocols supported by Google Cloud VPC networks (such as TCP, UDP, and ICMP).

Additional considerations

• Effect of global access. Custom static routes using internal TCP/UDP load balancer next hops are programmed in all regions. Whether the next hop is usable depends on the load balancer's global access setting. With global access enabled, the load balancer next hop is accessible in all regions of the VPC network. With global access disabled, the load balancer next hop is only accessible in the same region as the load balancer. With global access disabled, packets sent from another region to a route using an internal TCP/UDP load balancer next hop are dropped.

• When all backends are unhealthy. When all backends of an internal TCP/UDP load balancer fail health checks, the routes using that load balancer next hop are still in effect. Packets processed by the route are sent to one of the next hop load balancer's backends according to traffic distribution.

• Forwarding rules that use a common internal IP address (--purpose=SHARED_LOADBALANCER_VIP) are not supported. Next hop internal TCP/UDP load balancer and internal TCP/UDP load balancer forwarding rules with a common IP address are mutually exclusive features. A next hop internal TCP/UDP load balancer must use an IP address that is unique to the load balancer's forwarding rule so that only one backend service (one load balancer) is unambiguously referenced. It's possible for forwarding rules that use a common internal IP address to reference different backend services (different internal TCP/UDP load balancers).

• Same destination and multiple next hop internal TCP/UDP load balancers. If you create two or more custom static routes with the same destination, using different internal TCP/UDP load balancer next hops, Google Cloud never distributes traffic among the load balancer next hops using ECMP. If the routes have unique priorities, Google Cloud uses the next hop internal TCP/UDP load balancer from the route with the highest priority. If the routes have equal priorities, Google Cloud still selects just one next hop internal TCP/UDP load balancer. In this latter situation, as illustrated in the diagram below, Google Cloud uses a deterministic, internal algorithm to select a single next hop forwarding rule (forwarding-rule-a), ignoring other routes with the same priority.

  

  Google Cloud selects a single next hop when static routes with different internal TCP/UDP load balancer next hops have the same priority and destination.

• Multiple destinations and the same next hop internal TCP/UDP load balancer.

  With instance tags:

  If you use instance tags (also called network tags), you can use the same next hop internal TCP/UDP load balancer for multiple custom static routes with the same destination and priority.

  Without instance tags: Without instance tags, you cannot create multiple custom static routes having the same combination of destination, priority, and internal TCP/UDP load balancer next hop. For example, route-x, route-y, and route-z can all be created, but route-x-copy cannot be created.

  

  Static routes that don't have instance tags cannot be created with the same destination, priority, and internal TCP/UDP load balancer next hop.

• Instance tags.

  You can specify instance tags (also called network tags) so that the next-hop route only applies to client instances that have been configured with the tag. This lets you select which client instances get populated with which tagged next-hop route and which set of appliances to route your traffic to.

  You don't need to segregate the different client instances into separate VPC networks, each pointing to their preferred internal TCP/UDP load balancer front-ending a set of appliances.

  Note: Tagged routes are not exported or imported through peering.

• Multiple routes to the same destination prefix. With instance tags, you can specify multiple routes to the same destination with different internal load balancers as next-hops. You can use different instance tags or different priorities for these same destination routes.

Use cases

You can use an internal TCP/UDP load balancer as a next hop in multiple deployments and topologies.

For each example, note the following guidelines:

• Each VM interface must be in a separate VPC network.

• You cannot use backend VMs or load balancers to route traffic between subnets in the same VPC network because subnet routes cannot be overridden.

• The internal TCP/UDP load balancer is a software-defined pass-through load balancer. Packets are delivered to backend VMs without alterations to source or destination information (addresses or addresses and ports).

  Routing, packet filtering, proxying, and address translation are the responsibility of the virtual appliance VMs that serve as backends for the internal TCP/UDP load balancer.

Using an internal TCP/UDP load balancer as the next hop to a NAT gateway

This use case load balances traffic from internal VMs to multiple NAT gateway instances that route traffic to the internet.

NAT use case (click to enlarge)

Hub and spoke: Exchanging next-hop routes by using VPC Network Peering

In addition to exchanging subnet routes, you can configure VPC Network Peering to export and import custom static and dynamic routes. Custom static routes that have a next hop of the default internet gateway are excluded. Custom static routes that use next-hop internal TCP/UDP load balancers are included.

You can configure a hub-and-spoke topology with your next-hop firewall virtual appliances located in the hub VPC network by doing the following:

• In the hub VPC network, create an internal TCP/UDP load balancer with firewall virtual appliances as the backends.
• In the hub VPC network, create a custom static route, and set the next hop to be the internal TCP/UDP load balancer.
• Connect the hub VPC network to each of the spoke VPC networks by using VPC Network Peering.
• For each peering, configure the hub network to export its custom routes, and configure the corresponding spoke network to import custom routes. The route with the load balancer next hop is one of the routes that the hub network exports.

Subject to the routing order, the next hop firewall appliance load balancer in the hub VPC network is available in the spoke networks:

• to clients in the same region as the load balancer, if global access is disabled
• to clients in all regions, if global access is enabled, according to the routing order.

Hub and spoke (click to enlarge)

Load balancing to multiple NICs

In the following use case, the backend VMs are virtual appliance instances (for example, packet inspection, routing, or gateway VMs) with NICs in multiple VPC networks. These virtual appliance instances can be commercial solutions from third parties or solutions that you build yourself. The virtual appliances are Compute Engine VMs with multiple NICs.

This example shows a single set of backend virtual appliances in a managed VM instance group.

In the VPC network called testing, the internal TCP/UDP load balancer has a forwarding rule called fr-ilb1. In the example, this load balancer distributes traffic to the nic0 interface.

In the VPC network called production, a different internal TCP/UDP load balancer has a forwarding rule called fr-ilb2. This load balancer distributes traffic to a different interface, nic1 in this example.

Traffic with multi-NIC load balancing (click to enlarge)

For a detailed configuration setup, see Load balancing to multiple backend NICs.

Symmetric hashing

The preceding example doesn't use source network address translation (SNAT). SNAT isn't required because Google Cloud uses symmetric hashing. This means that when packets belong to the same flow, Google Cloud calculates the same hash. In other words, the hash doesn't change when the source IP address:port is swapped with the destination IP address:port.

Notes:

• Symmetric hashing is enabled automatically when you create the internal TCP/UDP load balancer forwarding rule on or after June 22, 2021.

• To enable symmetric hashing on existing internal TCP/UDP load balancers, you must re-create the forwarding rule and the next-hop route, as described in Enabling symmetric hashing.

• Symmetric hashing is only supported with Internal TCP/UDP Load Balancing.

• Symmetric hashing is supported with the following session affinity types for protocols TCP and UDP:

  • Client IP (2-tuple)
  • Client IP and protocol (3-tuple)
  • Client IP, protocol, and port (5-tuple)

• You can optionally use SNAT if your use case requires it for some reason.

What's next

• To configure an internal TCP/UDP load balancer to be a next hop, see Set up Internal TCP/UDP Load Balancing for third-party appliances or Deploy a hub-and-spoke network by using a load balancer as the next hop.
• To configure and test an internal TCP/UDP load balancer, see Set up Internal TCP/UDP Load Balancing with VM instance group backends.
• To troubleshoot next hop issues with your internal TCP/UDP load balancer, see Troubleshoot Internal TCP/UDP Load Balancing.