This page explains concepts about how external passthrough Network Load Balancers distribute traffic.

Backend selection and connection tracking

Backend selection and connection tracking work together to balance multipleconnections across different backends and to route all packets for eachconnection to the same backend. This is accomplished with a two-part strategy.First, a backend is selected using consistent hashing. Then, this selection isrecorded in a connection tracking table.

The following steps capture the backend selection and connection trackingprocess.

1.Check for a connection tracking table entry to use a previously selected backend

For anexisting connection, the load balancer uses the connectiontracking table to identify the previously selected backend for that connection.

The load balancer attempts to match each load-balanced packet with an entry inits connection tracking table using the following process:

• If the packet is a TCP packet with theSYN flag:

  • If the load balancer's connection tracking mode isPER_CONNECTION,continue to theIdentify eligible backendsstep. InPER_CONNECTION tracking mode, a TCP packet with theSYN flagalways represents a new connection, regardless of the configuredsession affinity.

  • If the load balancer's connection tracking mode isPER_SESSIONand the session affinity is eitherNONE orCLIENT_IP_PORT_PROTO,continue to theIdentify eligible backendsstep. InPER_SESSIONtracking mode, a TCP packet with theSYN flag represents a newconnection only when using one of the 5-tuple session affinityoptions (NONE orCLIENT_IP_PORT_PROTO).

• If the configured session affinity doesn't support connection trackingfor the packet's protocol, continue to theIdentify eligible backendsstep. For information about which protocols are connection trackable,see thetablein theConnection tracking mode section.

• For all other packets, the load balancer checks if the packet matches anexisting connection tracking table entry. The connection tuple (a set ofpacket characteristics) used to compare the packet to existing connectiontracking table entries depends on the connection tracking mode and sessionaffinity you configured. For information about which connection tupleis used for connection tracking, see thetable in theConnection trackingmode section.

  • If the packet matches a connection tracking table entry, the loadbalancer sends the packet to the previously selected backend.

  • If the packet doesn't match a connection tracking table entry,continue to theIdentify eligible backendsstep.

  For information about how long a connection tracking table entrypersists and under what conditions it persists,see theCreate a connection tracking table entry step.

2.Select an eligible backend for a new connection

For anew connection, the load balancer uses theconsistent hashingalgorithm to select a backend from among the eligible backends.

The following steps outline the process to select an eligible backend for a newconnection and then record that connection in a connection tracking table.

2.1Identify eligible backends

This step models which backends are candidates to receive new connections,taking into consideration health,weighted load balancing,andfailover policyconfiguration.

The following table outlines how failover policy and weighted load balancinginfluence which backends are eligible backends.

No failover policy, weighted load balancing disabled

The set of eligible backends depends only on health checks:

• When at least one backend is healthy, the set of eligiblebackends consists of all healthy backends.

• When all backends are unhealthy, the set of eligiblebackends consists ofall backends.

No failover policy, weighted load balancing enabled

The set of eligible backends depends both on health checks and weights,and consists of the first of the following that isn't empty:

• All healthy, non-zero weight backends
• All unhealthy, non-zero weight backends
• All healthy, zero weight backends
• All unhealthy, zero weight backends

Failover policy configured, weighted load balancing disabled

The set of eligible backends depends on health checks and failoverpolicy configuration:

• When at least one backend is healthy, the set of eligible backends isdefined as follows, using the first condition that is true from thisordered list:

  • If there are no healthy primary backends, the eligible backends areall healthy failover backends.
  • If there are no healthy failover backends, the eligible backends areall healthy primary backends.
  • If the failover ratio is set to0.0 (the default value), theeligible backends areall healthy primary backends.
  • If the ratio of the number of healthy primary backends compared tothe total number of primary backends is greater than or equal to theconfigured failover ratio, the eligible backends consists ofallhealthy primary backends.
  • The eligible backends consist ofall healthy failover backends.

• When there are no healthy backends,the set of eligible backends is defined as follows:

  • If the load balancer's failover policy is configured to drop newconnections when no backends are healthy, the set of eligible backends isempty. The load balancer drops the packets for new connections.
  • If the load balancer's failover policy isnot configured to drop newconnections when no backends are healthy, health checks aren't relevant.Eligible backends consist ofall primary backends.

Failover policy configured, weighted load balancing enabled

The set of eligible backends depends on health checks, weights,and failover policy configuration:

• When at least one backend is healthy and has a non-zero weight, theset of eligible backends is defined as follows, using the first conditionthat is true from this ordered list:

  • If there are no healthy, non-zero weight primary backends, the eligiblebackends areall healthy, non-zero weight failover backends.
  • If there are no healthy, non-zero weight failover backends, the eligiblebackends areall healthy, non-zero weight primary backends.
  • If the failover ratio is set to0.0 (the default value), theeligible backends areall healthy, non-zero weight primary backends.
  • If the ratio of the number of healthy, non-zero weight primary backendscompared to the total number of primary backends is greater than or equalto the configured failover ratio, the eligible backends consists ofallhealthy, non-zero weight primary backends.
  • The eligible backends consist ofall healthy, non-zero weight failoverbackends.

• When there are no healthy, non-zero weight backends,the set of eligible backends is defined as follows:

  • If the load balancer's failover policy is configured to drop newconnections when no backends are healthy, the set of eligible backends isempty. The load balancer drops the packets for new connections.

  • If the load balancer's failover policy isnot configured to drop newconnections when no backends are healthy, the set ofeligible backends is the first of the following that isn't empty:

    • All unhealthy, non-zero weight primary backends
    • All unhealthy, non-zero weight failover backends
    • All healthy, zero weight primary backends
    • All healthy, zero weight failover backends
    • All unhealthy, zero weight primary backends
    • All unhealthy, zero weight failover backends

2.2Select an eligible backend

The load balancerusesconsistent hashingto select an eligible backend. The load balancermaintains hashes of eligible backends, mapped to a unit circle.Weightedload balancing alters how eligible backends are mapped to thecircle such that backends with higher weights are more likely to be selected,proportional to their weights.

When processing a packet for a connection that's not in the connectiontracking table, the load balancer computes a hash of the packetcharacteristics and maps that hash to the same unit circle, selectingan eligible backend on the circle's circumference. The set of packetcharacteristics used to calculate the packet hash is defined by thesessionaffinity setting.

• If a session affinity isn't explicitly configured, theNONE sessionaffinity is the default.

• The following two examples show how weighted load balancing affects the selection of an eligible backend:

  • If the backend service has two eligible backends—the first havingweight1 and the second having weight4—the first eligiblebackend has a 20% (1÷(1+4)) selection probability,and the second eligible backend has an 80% (4÷(1+4))selection probability.

  • If the backend service has three eligible backends—eligiblebackenda having weight0, eligible backendb having weight2,and eligible backendc having weight6—backenda has a 0%(0÷(0+2+6)) selection probability, backendb has a 25%(2÷(0+2+6)) selection probability, and backendc has a 75%(6÷(0+2+6)) selection probability.

• The load balancer assigns new connections to eligible backends in a way thatis as consistent as possible even if the number of eligible backends ortheir weights change. The following benefits of consistent hashing show howthe load balancer selects eligible backends for possible new connectionsthat donot have connection tracking table entries:

  • The load balancer selects the same backend for all possible newconnections that have identical packet characteristics, as defined bysession affinity, in the following situations:

    • If weighted load balancing isn't configured, when the set ofeligible backends doesnot change.

    • If weighted load balancing is configured, when the set of eligiblebackends doesnot change,and the weight of each eligiblebackend remains constant.

  • The load balancer distributes possible new connections among eligiblebackends as fairly as possible:

    • If weighted load balancing isn't configured, approximately1/Npossible new connections map to each eligible backend, whereNis the count of eligible backends.

    • If weighted load balancing is configured, the ratio of possiblenew connections that map to each eligible backend is approximately:the weight of an eligible backend divided by the sum of all eligiblebackend weights.

    • If an eligible backend is added, removed, or has its weight change,consistent hashing aims to minimize the disruption of mappingsto the other eligible backends—that is, most connections thatmap to other eligible backends continue to map to the same eligiblebackend.

2.3Create a connection tracking table entry

After selecting a backend, theload balancer creates a connection tracking table entry if the configuredsession affinity supports connection tracking for the packet's protocol.

• If the configured session affinity doesn't support connection trackingfor the packet's protocol, skip this step.

• If the configured session affinity supports connection tracking for thepacket's protocol, the connection tracking table entry that's createdmaps packet characteristics to the selected backend. The packet headerfields used for this mapping depend on the connection tracking mode andsession affinity you configured.

For information about which protocols are connection trackable based on yourconfiguration choices, and what packet characteristics are used for the hash,see theConnection tracking mode section.

The load balancer removes connection tracking table entriesaccording to the following rules:

• A connection tracking table entry is removed after the connection hasbeen idle for 60 seconds. For more information, seeIdletimeout.

• Connection tracking table entries arenot removed when a TCP connectionis closed with aFIN orRST packet. Anynew TCP connection alwayscarries theSYN flag and is processed as described in theCheck for aconnection tracking table entry step.

• If a failover policy is configured and the connection draining on failoverand failback setting is disabled, the load balancer removes all entries inthe connection tracking table when the eligible backends switch from primaryto failover backends (failover), or switch from failover to primary backends(failback). For more information, seeConnection draining on failover andfailback.

• Entries in the connection tracking table can be removed if a backendbecomes unhealthy. This behavior depends onthe connection tracking mode, the protocol, and the connectionpersistence on unhealthy backends setting. For more information, seeConnection persistence on unhealthy backends.

• Entries in the connection tracking table are removed after the connectiondraining timeout that occurs following an event like deleting abackend VM or removinga backend VM from an instance group or NEG. For more information, seeEnable connection draining.

Session affinity

Session affinity controls the distribution of new connections from clients tothe load balancer's backends.External passthrough Network Load Balancers use session affinity toselect a backend from a set of eligible backends as described in theIdentifyeligible backends andSelect an eligible backend steps in theBackend selection and connectiontracking section. You configure session affinity on thebackend service, not on each backend instance group or NEG.

External passthrough Network Load Balancers support the following session affinity settings. Eachsession affinity setting usesconsistent hashing to select an eligible backend.The session affinity setting determines which fields from the IP headerand TCP/UDP headers are used to calculate the hash.

For information about how the different session affinity settings affect thebackend selection and connection tracking methods, see thetable in theConnection trackingmode section.

Connection tracking policy

This section describes the settings that control the connection trackingbehavior of external passthrough Network Load Balancers. A connection tracking policy includes the followingsettings:

• Connection tracking mode
• Connection persistence on unhealthy backends
• Idle timeout

Connection tracking mode

When connection tracking is possible, the load balancer's connection trackingtable maps connection tuples to previously selected backends in a hash table.The set of packet characteristics that compose each connection tuple depends onthe connection tracking mode and session affinity.

External passthrough Network Load Balancers support connection tracking based on protocol and sessionaffinity options:

• TCP connections are always connection trackable, for all session affinityoptions.

• UDP, ESP, and GRE connections are connection trackable for all sessionaffinity optionsexcept forNONE.

• All other protocols, such as ICMP and ICMPv6, aren't connection trackable.

The connection tracking mode refers to the granularity of the each connectiontuple in the load balancer's connection tracking table. The connection tuplecan be 5-tuple or 3-tuple (PER_CONNECTION mode), or it can match the sessionaffinity setting (PER_SESSION mode).

• PER_CONNECTION. This is the default connectiontracking mode. This connection tracking mode uses a 5-tuplehash or a 3-tuple hash. Non-fragmented packets that include port informationsuch as TCP packets and non-fragmented UDP packets are tracked with 5-tuplehashes. All other packets are tracked with 3-tuple hashes.

• PER_SESSION. This connection tracking mode uses a hash consisting of thesame packet characteristics used by the session affinity hash. Depending on thechosen session affinity,PER_SESSION can result in connections that morefrequently match an existing connection tracking table entry, reducing thefrequency that a backend needs to be selected by the session affinity hash.

The following table summarizes how connection tracking mode and session affinitywork together to route all packets for each connection to the same backend.

To learn how to change the connection tracking mode, seeConfigure aconnection trackingpolicy.

Connection persistence on unhealthy backends

The connection persistence settings control whether an existing connectionpersists on a selected backend VM or endpoint after that backend becomesunhealthy, as long as the backend remains in the load balancer's configuredbackend group (in an instance group or a NEG).

The following connection persistence options are available:

• DEFAULT_FOR_PROTOCOL (default)
• NEVER_PERSIST
• ALWAYS_PERSIST

The following table summarizes connection persistence options and howconnections persist for different protocols, session affinity options, andtracking modes.

TCP connection persistence behavior on unhealthy backends

Whenever a TCP connection with 5-tuple tracking persists on an unhealthybackend:

• If the unhealthy backend continues to respond to packets, theconnection continues until it is reset or closed (by either the unhealthybackend or the client).
• If the unhealthy backend sends a TCP reset (RST) packet or does notrespond to packets, then the client might retry with a new connection,letting the load balancer select a different, healthy backend. TCP SYNpackets always select a new, healthy backend.

To learn how to change connection persistence behavior, seeConfigure aconnection trackingpolicy.

Idle timeout

Entries in connection tracking tables expire 60 seconds after the load balancerprocesses the last packet that matched the entry. This idle timeout value can'tbe modified.

Weighted load balancing

Weighted load balancing for external passthrough Network Load Balancers uses weight information reportedby anHTTP healthcheck.Weighted load balancing requires that you configure all of the following:

• The backend service's load balancer locality policy (localityLbPolicy)must beWEIGHTED_MAGLEV.
• The backend service must use an HTTP health check.
• Health check responses from each backend VM or backend endpoint must containa custom HTTP response header. The response header field name isX-Load-Balancing-Endpoint-Weight, and valid field values range from0 to1000.

If you need to use the same instance group or NEG as a backend for two ormore backend services, we recommend the following strategy so that each ofthe common backend instances or endpoints can provide unique weightinformation for each backend service:

• Use a unique HTTP health check for each backend service. For example,use a uniquerequest-path health check parameter.
• Configure backend instances or endpoints to respond with appropriateweight information for each health check.

When using weighted load balancing, the load balancer ranks backendVMs or endpoints, first based on having a weight that's greater thanzero or equal to zero, then based on health checks. Health check statusis determined by thesuccess criteria for HTTP, HTTPS, and HTTP/2health checks.

For more information about how weighted load balancing influences which backendsare eligible backends, see theIdentify eligible backendsandSelect and eligible backend steps in theBackendselection and connection tracking section.

Weighted load balancing can be used in the following scenarios:

• If some connections process more data than others, or some connectionslive longer than others, the backend load distribution might get uneven.By signaling a lower per-instance weight, an instance with high load canreduce its share of new connections, while itkeeps servicing existing connections.

• If a backend is overloaded and assigning more connections might break existingconnections, such backends assign zero weight to itself. Bysignaling zero weight, a backend instance stops servicing new connections,but continues to service existing ones.

• If a backend is draining existing connections before maintenance, it assignszero weight to itself. By signaling zero weight, the backendinstance stops servicing new connections, but continues to service existingones.

For more information, seeConfigure weighted load balancing.

Connection draining

Connection draining provides a configurable amount of additional time forestablished connections to persist in the load balancer's connectiontracking table when one of the following actions takes place:

• A virtual machine (VM) instance is removed from a backend instance group(this includes abandoning an instance in a backend managed instance group)
• A VM is stopped or deleted (this includes automatic actions like rollingupdates or scaling down a backend managed instance group)
• An endpoint is removed from a backend network endpoint group (NEG)

By default, connection draining for the aforementioned actions is disabled.For information about how connection draining is triggered and how toenable connection draining, seeEnabling connectiondraining.

UDP fragmentation

Backend service-based external passthrough Network Load Balancers can process both fragmented andunfragmented UDP packets. If your application uses fragmented UDP packets, keepthe following in mind:

• UDP packets might become fragmented before reaching a Google CloudVPC network.
• Google Cloud VPC networks forward UDP fragments as theyarrive (without waiting for all fragments to arrive).
• Non-Google Cloud networks and on-premises network equipment mightforward UDP fragments as they arrive, delay fragmented UDP packets untilall fragments have arrived, or discard fragmented UDP packets. For details,see the documentation for the network provider or network equipment.

If you expect fragmented UDP packets and need to route them to the same backends,use the following forwarding rule and backend service configuration parameters:

• Forwarding rule configuration: Use only oneUDPorL3_DEFAULTforwarding rule per load-balanced IP address, and configure the forwardingrule to accept traffic on all ports. This ensures that all fragments arrive atthe same forwarding rule. Even though the fragmented packets (other than thefirst fragment) lack a destination port, configuring the forwarding rule toprocess traffic for all ports also configures it to receive UDP fragments thathave no port information. To configure all ports, either use theGoogle Cloud CLI to set--ports=ALL or use the APIto setallPorts toTrue.

• Backend service configuration: Set the backend service'ssessionaffinity toCLIENT_IP (2-tuple hash) orCLIENT_IP_PROTO (3-tuple hash) so that the same backend is selected for UDPpackets that include port information and UDP fragments (other than the firstfragment) that lack port information. Set the backend service'sconnectiontracking mode toPER_SESSION so that the connectiontracking table entries are built by using the same 2-tuple or 3-tuple hashes.

Failover

You can configure an external passthrough Network Load Balancer to distribute connections among VM instancesor endpoints in primary backends (instance groups or NEGs), and then switch, ifneeded, to using failover backends. Failover provides yet another method ofincreasing availability, while also giving you greater control over how tomanage your workload when your primary backends aren't healthy.

By default, when you add a backend to an external passthrough Network Load Balancer's backend service,that backend is a primary backend. You can designate a backend to be a failoverbackend when you add it to the load balancer's backend service, or by editingthe backend service later.

For more information about how failover is used for backend selection andconnection tracking, see theIdentify eligible backendsandCreate a connection tracking table entry stepsin theBackend selection and connection tracking section.

For more more information about how failover works, seeFailover overview forexternal passthrough Network Load Balancers.

What's next

• To configure an external passthrough Network Load Balancer with a backend service for TCP or UDP trafficonly (supporting IPv4 and IPv6 traffic), seeSet up an external passthrough Network Load Balancer with abackendservice.
• To configure an external passthrough Network Load Balancer for multiple IP protocols (supporting IPv4 andIPv6 traffic), seeSet up an external passthrough Network Load Balancer for multiple IPprotocols.
• To configure an external passthrough Network Load Balancer with a zonal NEG backend, seeSet up anexternal passthrough Network Load Balancer with zonal NEGs
• To learn how to transition an external passthrough Network Load Balancer from a target pool backend to aregional backend service, seeTransitioning an external passthrough Network Load Balancer from a targetpool to a backendservice.