Backend service-based regional external passthrough Network Load Balancer overview (original) (raw)

Regional external passthrough Network Load Balancers are regional, Layer 4 load balancers that distribute external traffic among backends (instance groups or network endpoint groups (NEGs)) in the same region as the load balancer. These backends must be in the same region and project but can be in different VPC networks. These load balancers are built onMaglevand the Andromeda network virtualization stack.

Regional external passthrough Network Load Balancers can receive traffic from:

Regional external passthrough Network Load Balancers are not proxies. The load balancer itself doesn't terminate user connections. Load-balanced packets are sent to the backend VMs with their source and destination IP addresses, protocol, and, if applicable, ports, unchanged. The backend VMs then terminate user connections. Responses from the backend VMs go directly to the clients, not back through the load balancer. This process is known as direct server return (DSR).

Backend service-based regional external passthrough Network Load Balancers support the following features:

Architecture

The following diagram illustrates the components of a regional external passthrough Network Load Balancer:

Regional external passthrough Network Load Balancer with a regional backend service

Regional external passthrough Network Load Balancer with a regional backend service

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

Additionally, you must create firewall rules that allow your load balancing traffic and health check probes to reach the backend VMs.

IP address

A regional external passthrough Network Load Balancer requires at least one forwarding rule. The forwarding rule references a regional external IP address that is accessible anywhere on the internet.

Use a reserved IP address for the forwarding rule if you need to keep the address associated with your project for reuse after you delete a forwarding rule or if you need multiple forwarding rules to reference the same IP address.

Regional external passthrough Network Load Balancers support both Standard Tier and Premium Tier for regional external IPv4 addresses. Both the IP address and the forwarding rule must use the same network tier. Regional external IPv6 addresses are only available in the Premium Tier.

Forwarding rule

A regional external forwarding rule specifies the protocol and ports on which the load balancer accepts traffic. Because regional external passthrough Network Load Balancers are not proxies, they pass traffic to backends on the same protocol and ports, if the packet carries port information. The forwarding rule in combination with the IP address forms the frontend of the load balancer.

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

Incoming traffic is matched to a forwarding rule, which is a combination of a particular IP address (either an IPv4 address or an IPv6 address range), protocol, and if the protocol is port-based, one of port(s), a range of ports, or all ports. The forwarding rule then directs traffic to the load balancer's backend service.

A regional external passthrough Network Load Balancer requires at least one forwarding rule. Forwarding rules can be configured to direct traffic coming from a specific range of source IP addresses to a specific backend service (or target instance). For details, see traffic steering. You can define multiple forwarding rules for the same load balancer as described in Multiple forwarding rules.

If you want the load balancer to handle both IPv4 and IPv6 traffic, create two forwarding rules: one rule for IPv4 traffic that points to IPv4 (or dual-stack) backends, and one rule for IPv6 traffic that points only to dual-stack backends. It's possible to have an IPv4 and an IPv6 forwarding rule reference the same backend service, but the backend service must reference dual-stack backends.

Forwarding rule protocols

Regional external passthrough Network Load Balancers support the following protocol options for each forwarding rule: TCP, UDP, and L3_DEFAULT.

Use the TCP and UDP options to configure TCP or UDP load balancing. The L3_DEFAULT protocol option enables a regional external passthrough Network Load Balancer to load balance TCP, UDP, ESP, GRE, ICMP, and ICMPv6 traffic.

In addition to supporting protocols other than TCP and UDP, L3_DEFAULT makes it possible for a single forwarding rule to serve multiple protocols. For example, IPsec services typically handle some combination of ESP and UDP-based IKE and NAT-T traffic. The L3_DEFAULT option allows a single forwarding rule to be configured to process all of those protocols.

Forwarding rules using the TCP or UDP protocols can reference a backend service using either the same protocol as the forwarding rule or a backend service whose protocol is UNSPECIFIED.L3_DEFAULT forwarding rules can only reference a backend service with protocol UNSPECIFIED.

If you're using the L3_DEFAULT protocol, you must configure the forwarding rule to accept traffic on all ports. To configure all ports, either set--ports=ALL by using the Google Cloud CLI, or set allPorts toTrue by using the API.

The following table summarizes how to use these settings for different protocols.

Traffic to be load balanced Forwarding rule protocol Backend service protocol
TCP TCP TCP or UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP or UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE, ICMP/ICMPv6 (echo request only) L3_DEFAULT UNSPECIFIED

Multiple forwarding rules

You can configure multiple regional external forwarding rules for the same regional external passthrough Network Load Balancer. 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:

Google Cloud requires that incoming packets match no more than one forwarding rule. Except for steering forwarding rules, which are discussed in the next section, two or more forwarding rules that use the same regional external IP address must have unique protocol and port combinations according to these constraints:

Forwarding rule selection

Google Cloud selects one or zero forwarding rules to process an incoming packet by using this elimination process, starting with the set of forwarding rule candidates which match the destination IP address of the packet:

When using multiple forwarding rules, make sure that you configure the software running on your backend VMs so that it binds to all the external IP address(es) of the load balancer's forwarding rule(s).

Traffic steering

Forwarding rules for regional external passthrough Network Load Balancers can be configured to direct traffic coming from a specific source IP address or a range of IP addresses to a specific backend service (or target instance).

Traffic steering is useful for troubleshooting and for advanced configurations. With traffic steering, you can direct certain clients to a different set of backends, a different backend service configuration, or both. For example:

Traffic steering is configured with a forwarding rule API parameter calledsourceIPRanges. Forwarding rules that have at least one source IP range configured are called steering forwarding rules.

A steering forwarding rule can use the sourceIPRanges parameter to specify a comma-separated list of up to 64 source IP addresses or IP address ranges. You can update this list of source IP address ranges at any time.

Each steering forwarding rule requires that you first create a parent forwarding rule. The parent and steering forwarding rules share the same regional external IP address, IP protocol, and port information; however, the parent forwarding rule does not have any source IP address information. For example:

A parent forwarding rule that points to a backend service can be associated with a steering forwarding rule that points to a backend service or a target instance.

For a given parent forwarding rule, two or more steering forwarding rules can have overlapping, but not identical, source IP address ranges and IP addresses. As an example, one steering forwarding rule can have the source IP range 203.0.113.0/24 and another steering forwarding rule for the same parent can have the source IP address 203.0.113.0.

You must delete all steering forwarding rules before you can delete the parent forwarding rule upon which they depend.

To learn how incoming packets are processed when steering forwarding rules are used, see Forwarding rule selection.

Session affinity behavior across steering changes

This section describes the conditions under which session affinity might break when the source IP address ranges configured for a steering forwarding rule are updated:

Preserving session affinity across steering changes

This section describes how to avoid breaking session affinity when the source IP ranges for steering forwarding rules are updated:

For instructions on how to configure traffic steering, see Configure traffic steering.

Regional backend service

Each regional external passthrough Network Load Balancer has one regional backend service that defines the behavior of the load balancer and how traffic is distributed to its backends. The name of the backend service is the name of the regional external passthrough Network Load Balancer shown in the Google Cloud console.

Each backend service defines the following backend parameters:

Instance groups

A regional external passthrough Network Load Balancer distributes connections among backend VMs contained within managed or unmanaged instance groups. Instance groups can be regional or zonal in scope.

Each instance group has an associated VPC network, even if that instance group hasn't been connected to a backend service yet. For more information about how a network is associated with instance groups, seeInstance group backends and network interfaces.

The regional external passthrough Network Load Balancer is highly available by design. There are no special steps needed to make the load balancer highly available because the mechanism doesn't rely on a single device or VM instance. You only need to make sure that your backend VM instances are deployed to multiple zones so that the load balancer can work around potential issues in any given zone.

Zonal NEGs

A regional external passthrough Network Load Balancer distributes connections among GCE_VM_IP endpoints contained within zonal network endpoint groups. These endpoints must be located in the same region as the load balancer. For some recommended zonal NEG use cases, see Zonal network endpoint groups overview.

Zonal NEGs support both IPv4 and dual-stack (IPv4 and IPv6) VMs. For both IPv4 and dual-stack VMs, it is sufficient to specify only the VM instance when attaching an endpoint to a NEG. You don't need to specify the endpoint's IP address. The VM instance must always be in the same zone as the NEG.

Each zonal NEG has an associated VPC network and a subnet, even if that zonal NEG hasn't been connected to a backend service yet. For more information about how a network is associated with zonal NEGs, see Zonal NEG backends and network interfaces.

Instance group backends and network interfaces

Within a given (managed or unmanaged) instance group, the nic0 network interface of each member VM is always in the same VPC network:

Member VMs can have additional network interfaces (vNICs or Dynamic Network Interfaces). Each non-nic0 interface can be in either the instance group's VPC network (the network used by the nic0 interface) or a different VPC network.

To distribute load-balanced traffic to a non-nic0 network interface, you can't use instance group backends. Use zonal NEGs with GCE_VM_IPendpoints instead. For more information, see Backend services and VPC networks.

Zonal NEG backends and network interfaces

When you create a new zonal NEG with GCE_VM_IP endpoints, you must explicitly associate the NEG with a subnetwork of a VPC network before you can add any endpoints to the NEG. Neither the subnet nor the VPC network can be changed after the NEG is created.

Within a given NEG, each GCE_VM_IP endpoint actually represents a network interface. The network interface must be in the subnetwork associated with the NEG. From the perspective of a Compute Engine instance, the network interface can use anyidentifier. From the perspective of being an endpoint in a NEG, the network interface is identified by using its primary internal IPv4 address. For more information, see NEGs with GCE_VM_IP endpoints.

There are two ways to add a GCE_VM_IP endpoint to a NEG:

Backend services and VPC networks

The backend service isn't associated with any VPC network; however, each backend instance group or zonal NEG is associated with a VPC network, as noted previously. As long as all backends are located in the same region and project, and as long as all backends are of the same type (instance groups or zonal NEGs), you can add backends that use either the same or different VPC networks.

To distribute packets to non-nic0 interfaces, you must meet both of the following requirements:

Dual-stack backends (IPv4 and IPv6)

If you want the load balancer to use dual-stack backends that handle both IPv4 and IPv6 traffic, note the following requirements:

IPv6-only backends

If you want the load balancer to use IPv6-only backends, note the following requirements:

Note that IPv6-only VMs can be created under both dual-stack and IPv6-only subnets, but dual-stack VMs can't be created under IPv6-only subnets.

Health checks

Health check information is used to determine eligible backends for new connections, and you can control whether existing connections persist on unhealthy backends. For more information about eligible backends, see Traffic distribution for regional external passthrough Network Load Balancers.

Health check type, protocol, and port

The load balancer's backend service must reference a regional health check, using any supported health check protocol and port. The health check protocol and port details don't have to match the load balancer backend service protocol and forwarding rule IP port information.

Because all supported health check protocols rely on TCP, when you use a regional external passthrough Network Load Balancer to balance connections and traffic for other protocols, backend VMs must run a TCP-based server to answer health check probers. For example, you can use an HTTP health check combined with running an HTTP server on each backend VM. In this example, your scripts or software are responsible for configuring the HTTP server so that it returns status 200 only when the software listening to load-balanced connections is operational.

For more information about supported health check protocols and ports, seeHealth check categories, protocols, and portsand How health checks work.

Health check packets

For instance group backends, health check probers send packets to the nic0network interface of each backend VM. For GCE_VM_IP zonal NEG backends, health check probers send packets to the network interface in the VPC network of the NEG. Health check packets have the following characteristics:

Software running on the backend VMs must bind to and listen on relevant IP address and port combinations. The simplest way to accomplish this is to configure software to bind to and listen on the relevant ports of any of the VM's IP addresses (0.0.0.0). For more information, see Destination for probe packets.

Firewall rules

Because regional external passthrough Network Load Balancers are passthrough load balancers, you control access to the load balancer's backends using Google Cloud firewall rules. You must create ingress allow firewall rules or an ingress allow hierarchical firewall policy to permit health checks and the traffic that you're load balancing.

Forwarding rules and ingress allow firewall rules or Hierarchical firewall policies work together in the following way: a forwarding rule specifies the protocol and, if defined, port requirements that a packet must meet to be forwarded to a backend VM. Ingress allow firewall rules control whether the forwarded packets are delivered to the VM or dropped. All VPC networks have an implied deny ingress firewall rule that blocks incoming packets from any source. The Google Cloud default VPC network includes a limited set of pre-populated ingress allow firewall rules.

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 as follows:

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. Configure software running on backend VMs to do the following:

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:

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, ESP, GRE, ICMP For most use cases, the IP address of the load balancer's forwarding rule 1 The requesting packet's source.

1 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 doesn't match the IP address to which it sent a request packet.

Return path

Regional external passthrough Network Load Balancers use special routes outside of your VPC network to direct incoming requests and health check probes to each backend VM.

The load balancer preserves the source IP addresses of packets. Responses from the backend VMs go directly to the clients, not back through the load balancer. The industry term for this is direct server return.

Outbound internet connectivity from backends

VM instances configured as a regional external passthrough Network Load Balancer's backend endpoints can initiate connections to the internet using the load balancer's forwarding rule IP address as the source IP address of the outbound connection.

Generally, a VM instance always uses its own external IP address or Cloud NAT to initiate connections. You use the forwarding rule IP address to initiate connections from backend endpoints only in special scenarios such as when you need VM instances to originate and receive connections at the same external IP address, and you also need the backend redundancy provided by the regional external passthrough Network Load Balancer for inbound connections.

Outbound packets sent from backend VMs directly to the internet have no restrictions on traffic protocols and ports. Even if an outbound packet is using the forwarding rule's IP address as the source, the packet's protocol and source port don't have to match the forwarding rule's protocol and port specification. However, inbound response packets must match the forwarding rule IP address, protocol, and destination port of the forwarding rule. For more information, see Paths for regional external passthrough Network Load Balancers and external protocol forwarding.

Additionally, any responses to the VM's outbound connections are subject to load balancing, just like all the other incoming packets meant for the load balancer. This means that responses might not arrive on the same backend VM that initiated the connection to the internet. If the outbound connections and load balanced inbound connections share common protocols and ports, then you can try one of the following suggestions:

This path to internet connectivity from a regional external passthrough Network Load Balancer's backends is the default intended behavior according to Google Cloud's implied firewall rules. However, if you have security concerns about leaving this path open, you can use targeted egress firewall rules to block unsolicited outbound traffic to the internet.

Shared VPC architecture

Note the following points in relation to a Shared VPC architecture for a regional external passthrough Network Load Balancer:

The following table outlines where the different components of a regional external passthrough Network Load Balancer exist in a Shared VPC architecture.

Location of load balancing resources1 Required location of IP address resource
Host project Host project
Service project Service project or host project

1 Includes the forwarding rule, backend service, health check, and backends (NEGs and managed or unmanaged instance groups)

Traffic distribution

Regional external passthrough Network Load Balancers support a variety of traffic distribution customization options, including session affinity, connection tracking, weighted load balancing, and failover. For details about how regional external passthrough Network Load Balancers distribute traffic, and how these options interact with each other, see Traffic distribution for regional external passthrough Network Load Balancers.

Limitations

Pricing

For pricing information, see Network pricing: Cloud Load Balancing.

What's next