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:
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.
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
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.
The following are specifications for using internal TCP/UDP load balancers as next hops.
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.
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.
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
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.
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
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).
- 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.
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-zcan all be created, but
route-x-copycannot be created.
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.
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.
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.
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
- In the
hubVPC network, create an internal TCP/UDP load balancer with firewall virtual appliances as the backends.
- In the
hubVPC network, create a custom static route, and set the next hop to be the internal TCP/UDP load balancer.
- Connect the
hubVPC network to each of the
spokeVPC networks by using VPC Network Peering.
- For each peering, configure the
hubnetwork to export its custom routes, and configure the corresponding
spokenetwork to import custom routes. The route with the load balancer next hop is one of the routes that the
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.
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
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.
For a detailed configuration setup, see Load balancing to multiple backend NICs.
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.
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.
- To configure an internal TCP/UDP load balancer to be a next hop, see Setting up Internal TCP/UDP Load Balancing for third-party appliances or Deploying centralized VM-based appliances using internal TCP/UDP load balancer as the next hop.
- To configure and test an internal TCP/UDP load balancer, see Setting up Internal TCP/UDP Load Balancing.
- To troubleshoot next hop issues with your internal TCP/UDP load balancer, see Troubleshooting Internal TCP/UDP Load Balancing.