Target pool-based external passthrough Network Load Balancer overview

An external passthrough Network Load Balancer is a regional, Layer 4 load balancer. External passthrough Network Load Balancers distribute TCP and UDP traffic among backend virtual machine (VM) instances in the same region in a Virtual Private Cloud (VPC) network. An external passthrough Network Load Balancer can receive traffic from any of the following:

  • Any client on the internet
  • Google Cloud VMs with external IPs
  • Google Cloud VMs that have internet access through Cloud NAT or instance-based NAT

Depending on the forwarding rule configuration, each target-pool based load balancer supports one of the following types of protocol traffic:

  • TCP
  • UDP
  • TCP and UDP

The scope of the load balancer is regional, not global. This means that all backend instances for an external passthrough Network Load Balancer must be located in the same region. You can place backends in any zone of the region.

External passthrough Network Load Balancers support any and all ports. You can use an external passthrough Network Load Balancer to load balance either TCP or UDP traffic. Because the load balancer is a pass-through load balancer, your backends terminate the load-balanced TCP connection or UDP packets themselves. For example, you might run an HTTPS web server on your backends and use an external passthrough Network Load Balancer to route requests to it, terminating TLS on your backends themselves.

If you are building applications in GKE, we recommend that you use the built-in GKE Service controller, which deploys Google Cloud load balancers on behalf of GKE users. This is the same as the standalone load balancing architecture, except that its lifecycle is fully automated and controlled by GKE. For details, see Expose apps using services.

Architecture

The load balancer is made up of several configuration components. A single load balancer can have the following:

An external passthrough Network Load Balancer always has one target pool. Multiple forwarding rules can reference the target pool.

The target pool is a backend for the load balancer. It specifies the backend instances among which traffic is load balanced. Each forwarding rule is a frontend for the load balancer. Keep in mind that there are limits to the number of forwarding rules and target pools per project.

The external passthrough Network Load Balancers balance the load on your systems based on incoming IP protocol data, such as address, port, and protocol type.

The external passthrough Network Load Balancer is a pass-through load balancer, so your backends receive the original client request. The external passthrough Network Load Balancer doesn't do any Transport Layer Security (TLS) offloading or proxying. Traffic is directly routed to your VMs.

When you create a forwarding rule for the load balancer, you receive an ephemeral virtual IP address (VIP) or reserve a VIP that originates from a regional network block.

You then associate that forwarding rule with your target pools. The VIP is anycasted from Google's global points of presence, but the backends are regional. The load balancer cannot have backends that span multiple regions.

You can use Google Cloud firewalls to control or filter access to the backend VMs.

The external passthrough Network Load Balancer examines the source and destination ports, IP address, and protocol to determine how to forward packets. For TCP traffic, you can modify the forwarding behavior of the load balancer by configuring session affinity. The external passthrough Network Load Balancer forwards packets to the first network interface (nic0) of the instances in the target pool.

The load balancer preserves the source IP addresses of incoming packets. The destination IP address for incoming packets is the regional external IP address associated with the load balancer's forwarding rule.

Load distribution algorithm

By default, to distribute traffic to instances, the session affinity value is set to NONE. Cloud Load Balancing picks an instance based on a hash of the source IP and port, destination IP and port, and protocol. This means that incoming TCP connections are spread across instances, and each new connection might go to a different instance. All packets for a connection are directed to the same instance until the connection is closed. Established connections are not taken into account in the load balancing process.

Regardless of the session affinity setting, all packets for a connection are directed to the chosen instance until the connection is closed. An existing connection has no impact on load balancing decisions for new incoming connections. This can result in an imbalance among backends if long-lived TCP connections are in use.

You can choose a different session affinity setting if you need multiple connections from a client to go to the same instance.

Target pools

A target pool resource defines a group of instances that should receive incoming traffic from forwarding rules. When a forwarding rule directs traffic to a target pool, Cloud Load Balancing picks an instance from these target pools based on a hash of the source IP and port and the destination IP and port. Each target pool operates in a single region and distributes traffic to the first network interface (nic0) of the backend instance. For more information about how traffic is distributed to instances, see the Load distribution algorithm section.

The external passthrough Network Load Balancers are not proxies. Responses from the backend VMs go directly to the clients, not back through the load balancer. The load balancer preserves the source IP addresses of packets. The destination IP address for incoming packets is the regional external IP address associated with the load balancer's forwarding rule. Consequently:

  • Instances that participate as backend VMs for external passthrough Network Load Balancers must be running the appropriate Linux guest environment, Windows guest environment, or other processes that provide equivalent capability.

    The guest OS environment (or an equivalent process) is responsible for configuring local routes on each backend VM. These routes allow the VM to accept packets that have a destination that matches the IP address of the load balancer's forwarding rule.

  • On the backend instances that accept load-balanced traffic, you must configure the software to bind to the IP address associated with the load balancer's forwarding rule (or to any IP address, 0.0.0.0/0).

External passthrough Network Load Balancers support Compute Engine autoscaler, which allows users to perform autoscaling on the instance groups in a target pool based on backend utilization. For more information, see Scaling based on CPU utilization.

If you intend for your target pool to contain a single VM instance, you should consider using the protocol forwarding feature instead.

Target pools can only be used with forwarding rules that handle TCP and UDP traffic. For all other protocols, you must create a target instance. You must create a target pool before you can use it with a forwarding rule. Each project can have up to 50 target pools.

Forwarding rules

Forwarding rules work in conjunction with target pools to support load balancing. To use load balancing, you must create a forwarding rule that directs traffic to specific target pools. It is not possible to load balance your traffic without a forwarding rule.

Each forwarding rule matches a particular IP address, protocol, and optionally, port range to a single target pool. When traffic is sent to an external IP address that is served by a forwarding rule, the forwarding rule directs that traffic to the corresponding target pool.

If you are load balancing UDP packets that are likely to be fragmented before arriving at your Google Cloud VPC network, see Load balancing and fragmented UDP packets.

Target pool-based external passthrough Network Load Balancers support the following protocols for each forwarding rule: TCP or UDP. If you want the load balancer to forward all IP protocol traffic, you must use a Backend service-based external passthrough Network Load Balancer.

Multiple forwarding rules

You can configure multiple regional external forwarding rules for the same external passthrough Network Load Balancer. Optionally, each forwarding rule can have a different regional external IP address, or multiple forwarding rules can have the same regional external IP address.

Configuring multiple regional external forwarding rules can be useful for these use cases:

  • You need to configure more than one external IP address for the same target pool.
  • You need to configure different port ranges or different protocols by using the same external IP address for the same target pool.

When using multiple forwarding rules, make sure that you configure the software running on your backend VMs so that it binds to all necessary IP addresses. This is required because the destination IP address for packets delivered through the load balancer is the regional external IP address associated with the respective regional external forwarding rule.

Health checks

Health checks ensure that Compute Engine forwards new connections only to instances that are up and ready to receive them. Compute Engine sends health check requests to each instance at the specified frequency. After an instance exceeds its allowed number of health check failures, it is no longer considered an eligible instance for receiving new traffic.

To allow for graceful shutdown and closure of TCP connections, existing connections are not actively terminated. However, existing connections to an unhealthy backend are not guaranteed to remain viable for long periods of time. If possible, you should begin a graceful shutdown process as soon as possible for your unhealthy backend.

The health checker continues to query unhealthy instances, and returns an instance to the pool when the specified number of successful checks occur. If all instances are marked as UNHEALTHY, the load balancer directs new traffic to all existing instances.

External passthrough Network Load Balancers rely on legacy HTTP health checks to determine instance health. Even if your service does not use HTTP, you must run a basic web server on each instance that the health check system can query.

Legacy HTTPS health checks aren't supported for external passthrough Network Load Balancers and cannot be used with most other types of load balancers.

Firewall rules

Health checks for external passthrough Network Load Balancers are sent from these IP ranges. You'll need to create ingress allow firewall rules that permit traffic from those ranges.

External passthrough Network Load Balancers are passthrough load balancers, which means that your firewall rules must allow traffic from the client source IP addresses. If your service is open to the internet, it is easiest to allow traffic from all IP ranges. If you want to restrict access so that only certain source IP addresses are allowed, you can set up firewall rules to enforce that restriction, but you must allow access from the health check IP ranges.

For a firewall rule example and a configuration example, see Firewall rules for external passthrough Network Load Balancers.

IP addresses for request and return packets

When a backend VM receives a load-balanced packet from a client, the packet's source and destination are:

  • Source: the external IP address associated with a Google Cloud VM or internet-routable IP address of a system connecting to the load balancer.
  • Destination: the IP address of the load balancer's forwarding rule.

Because the load balancer is a pass-through load balancer (not a proxy), packets arrive bearing the destination IP address of the load balancer's forwarding rule. Software running on backend VMs should be configured to do the following:

  • Listen on (bind to) the load balancer's forwarding rule IP address or any IP address (0.0.0.0 or ::)
  • If the load balancer forwarding rule's protocol supports ports: Listen on (bind to) a port that's included in the load balancer's forwarding rule

Return packets are sent directly from the load balancer's backend VMs to the client. The return packet's source and destination IP addresses depend on the protocol:

  • TCP is connection-oriented so backend VMs must reply with packets whose source IP addresses match the forwarding rule's IP address so that the client can associate the response packets with the appropriate TCP connection.
  • UDP is connectionless so backend VMs can send response packets whose source IP addresses either match the forwarding rule's IP address or match any assigned IP address for the VM. Practically speaking, most clients expect the response to come from the same IP address to which they sent packets.

The following table summarizes sources and destinations for response packets:

Traffic type Source Destination
TCP The IP address of the load balancer's forwarding rule The requesting packet's source
UDP For most use cases, the IP address of the load balancer's forwarding rule † The requesting packet's source

† When a VM has an external IP address or when you are using Cloud NAT, it is also possible to set the response packet's source IP address to the VM NIC's primary internal IPv4 address. Google Cloud or Cloud NAT changes the response packet's source IP address to either the NIC's external IPv4 address or a Cloud NAT external IPv4 address in order to send the response packet to the client's external IP address. Not using the forwarding rule's IP address as a source is an advanced scenario because the client receives a response packet from an external IP address that does not match the IP address to which it sent a request packet.

Special routing paths

Google Cloud uses special routes not defined in your VPC network for health checks. For more information, see Paths for health checks.

Shared VPC architecture

The following table summarizes Shared VPC components for external passthrough Network Load Balancers:

IP address Forwarding rule Backend components
A regional external IP address must be defined in the same project as the instances being load balanced. A regional external forwarding rule must be defined in the same project as the instances in the target pool (the service project). The target pool must be defined in the same project and same region where the instances in the target pool exist. Health checks associated with the target pool must be defined in the same project as well.

Traffic distribution

The way a target pool-based external passthrough Network Load Balancer distributes new connections depends on how session affinity has been configured.

Session affinity

Session affinity controls the hashing method used to distribute new connections from clients to the load balancer's backend VMs. Target pool-based load balancers use the sessionAffinity parameter to configure session affinity.

For more information, see Using target pools.

Load balancing and fragmented UDP packets

If you are load balancing UDP packets, be aware of the following:

  1. Unfragmented packets are handled normally in all configurations.
  2. UDP packets might become fragmented before reaching Google Cloud. Intervening networks might wait for all fragments to arrive before forwarding them, causing delay, or might drop fragments. Google Cloud does not wait for all fragments; it forwards each fragment as soon as it arrives.

  3. Because subsequent UDP fragments don't contain the destination port, problems can occur in these situations:

    • If the target pools session affinity is set to NONE (5-tuple affinity), the subsequent fragments might be dropped because the load balancer cannot calculate the 5-tuple hash.
    • If there is more than one UDP forwarding rule for the same load-balanced IP address, subsequent fragments might arrive at the wrong forwarding rule.

If you expect fragmented UDP packets, do the following:

  • Set session affinity to NONE, CLIENT_IP_PROTO or CLIENT_IP.
    • Setting session affinity to NONE indicates that maintaining affinity is not required. Hence the load balancer uses a 5-tuple hash to select a backend for unfragmented packets, but 3-tuple hash for fragmented packets.
    • Setting session affinity to CLIENT_IP_PROTO or CLIENT_IP means that the source and destination ports are not used for hashing, and therefore the same hash is calculated for both fragmented and unfragmented packets.
  • Use only one UDP forwarding rule per load-balanced IP address. This ensures that all fragments arrive at the same forwarding rule.

With these settings, UDP fragments from the same packet are forwarded to the same instance for reassembly.

Using target instances as backends

If you're using target instances as backends for the external passthrough Network Load Balancer and you expect fragmented UDP packets, use only one UDP forwarding rule per load-balanced IP address, and configure the forwarding rule to accept traffic on all ports 0-65535. This ensures that all fragments arrive at the same forwarding rule even if they don't have the same destination port.

Limitations

  • You can't use the Google Cloud console to create target pool-based external passthrough Network Load Balancers. Instead, use either gcloud or the REST API.
  • External passthrough Network Load Balancers don't support VPC Network Peering.

What's next