Health checks for multi-NIC virtual appliance backends monitor interface availability by periodically probing a designated port and protocol on each backend instance. An administrator associates a regional health check with the load balancer's backend service to track instance reachability across zones. In multi-NIC deployments, where each network interface connects to a separate VPC network, health check probes must reach the specific interface handling the ingress traffic. Custom ingress firewall rules must be created to allow Google Cloud health check IP ranges to communicate with the probed service or helper daemon on the backend appliance.
A failover policy on an internal passthrough Network Load Balancer defines how traffic switches automatically between primary and backup backend instance groups. Under normal operations, the load balancer directs new connections only to the healthy instances within the designated primary backend groups. When the proportion of healthy primary instances falls below the configured failover ratio, the load balancer triggers a failover and redirects traffic to the active failover backend pool. For example, setting a failover ratio of 0.2 initiates failover when fewer than 20 percent of primary VMs remain healthy, while a ratio of 0.0 triggers failover only when all primary instances fail. If all primary and failover backends simultaneously become unhealthy, the load balancer routes packets across all backends as a fallback to avoid dropping entire route destinations.
Session persistence and connection tracking maintain consistent routing for active network flows across state changes and appliance failures. The load balancer uses a connection tracking table and consistent hashing to ensure that packets belonging to an established connection consistently reach the same backend VM interface. Administrators can configure the connection tracking mode to PER_CONNECTION or PER_SESSION to determine how TCP SYN packets and session affinity rules govern backend selection. Enabling connection draining on the backend service failover policy ensures that existing connections continue to be served until closed, preventing unexpected session drops during failover and failback events.
When you create a static route with an internal passthrough Network Load Balancer as the next hop, packets matching the route's destination are forwarded to the load balancer's frontend IP address. The load balancer then distributes these packets among its backend VMs using equal-cost multi-path (ECMP) distribution. The backend VMs receive packets with their original source and destination IP addresses, protocol, and ports unchanged—a behavior known as direct server return (DSR). Responses from the backend VMs go directly back to the clients, not through the load balancer.
You can specify a next hop internal passthrough Network Load Balancer using three methods: by forwarding rule name and region, by forwarding rule resource link, or by the load balancer's internal IP address. When specifying by name and region or by resource link, the forwarding rule's VPC network must match the route's VPC network. When specifying by IP address, the forwarding rule's network can be either the same VPC network or a VPC network connected through VPC Network Peering or Network Connectivity Center.
The global access setting on the internal passthrough Network Load Balancer determines whether the next hop is reachable from all regions or only from the same region as the load balancer. With global access disabled, packets sent from another region to a route using an internal passthrough Network Load Balancer next hop are dropped. With global access enabled, the load balancer next hop is accessible from any region in the VPC network. Custom static routes using internal passthrough Network Load Balancer next hops are programmed in all regions, but their usability depends on this global access setting.
All backend VMs for a next hop internal passthrough Network Load Balancer must have IP forwarding enabled (--can-ip-forward=True) on their network interfaces. This allows the VMs to forward packets from any source IP address to any destination. Additionally, you must configure appropriate firewall rules: ingress rules must include the IP addresses of routed packet sources, and egress rules must include the IP addresses of routed packet destinations. Software running on the backend VMs must be configured to handle the routed traffic appropriately—third-party appliance VMs acting as routers or firewalls must follow the manufacturer's configuration instructions.
When multiple static routes have the same destination and priority but different internal passthrough Network Load Balancer next hops, Google Cloud does not distribute traffic among them using ECMP. Instead, Google Cloud selects a single next hop using a deterministic internal algorithm. To avoid this ambiguity, you should use unique network tags for each route or ensure routes have different priorities. Without a network tag, Google Cloud does not allow you to create multiple static routes that have the same combination of destination, priority, and internal passthrough Network Load Balancer next hop.
One common use case for this configuration is load balancing traffic from internal VMs to multiple NAT gateway instances that route traffic to the internet. The internal passthrough Network Load Balancer distributes traffic across the NAT gateway VMs, providing high availability—if one NAT gateway fails, the load balancer automatically routes traffic to the remaining healthy gateways. This approach scales horizontally by adding more NAT gateway VMs to the backend pool without changing the route configuration.
You can configure a hub-and-spoke topology with next-hop firewall virtual appliances located in the hub VPC network. Routes using the internal passthrough Network Load Balancer as a next hop in the hub VPC network can be exported and imported through VPC Network Peering, making them usable in each spoke network. Custom static routes that use next-hop internal passthrough Network Load Balancers are included in route exchanges, while static routes with next-hop default internet gateways are excluded.
You must create the internal passthrough Network Load Balancer before creating the static route that uses it as a next hop. The load balancer must exist before you can reference it in a route. If you try to create a route that refers to a nonexistent load balancer, Google Cloud returns an error. Conversely, after creating a route with a next hop internal passthrough Network Load Balancer, you cannot delete the load balancer unless you first delete the route—specifically, you cannot delete an internal forwarding rule until no static route uses that load balancer as a next hop.
When an internal passthrough Network Load Balancer is deployed as a next hop, Google Cloud forwards all traffic on all ports to the backend VMs, regardless of the forwarding rule's protocol and port configuration or the backend service's protocol configuration. The internal passthrough Network Load Balancer supports forwarding all protocols that Google Cloud VPC networks support, including TCP, UDP, and ICMP. Routes created before May 15, 2021 initially forwarded only TCP and UDP traffic but were automatically migrated to forward all protocol traffic starting August 16, 2021.
You can create static routes from VPC spokes to internal passthrough Network Load Balancers that are accessible through a Network Connectivity Center hub. The subnet used by the internal passthrough Network Load Balancer forwarding rule must be accessible in the VPC spoke where the static route is defined, and the hub topology must allow exchange of subnet routes containing the next hop internal passthrough Network Load Balancer. For the star topology, if the static route is in an edge spoke group, the next hop internal passthrough Network Load Balancer can be in that edge spoke or in any center spoke group. If the static route is in a center spoke group, the next hop can be in any VPC spoke.
Forwarding rules that use a common internal IP address (--purpose=SHARED_LOADBALANCER_VIP) are not supported for next hop internal passthrough Network Load Balancers. A next hop internal passthrough Network Load Balancer must use an IP address unique to its forwarding rule so that only one backend service is unambiguously referenced. Traffic sent to a next-hop internal passthrough Network Load Balancer configured with a shared IP address is silently dropped. You cannot use an internal passthrough Network Load Balancer whose backends are GKE nodes as a next hop for a static route because software on the nodes can only route traffic to Pods if the destination matches an IP address managed by the cluster.
An internal passthrough Network Load Balancer becomes a routing next hop when referenced by a custom static route. You create the load balancer first, specifying its internal IP address, backend service, and health check. Then, you create a static route where the next-hop-ilb is set to that load balancer's forwarding rule (by name, resource link, or IP address). This route instructs the VPC network to send all traffic for a specific destination prefix (e.g., 10.0.1.0/24) to the load balancer, which then distributes it among its healthy backend VMs. The load balancer and the static route must be in the same VPC network, and the backend VMs must have IP forwarding enabled (can-ip-forward=true).
For high availability with multi-NIC VMs, each VM network interface must reside in a separate VPC network. The internal passthrough Network Load Balancer can load balance traffic to specific network interfaces (nic0 through nic7) on these backend VMs, which is essential for segmenting management, data, or trust zones. You cannot use the load balancer to route traffic between subnets in the same VPC network because subnet routes cannot be overridden. The backend VMs (acting as firewalls, NAT gateways, or other appliances) are responsible for the actual routing, packet filtering, and address translation after receiving the unaltered traffic from the load balancer.
The operational scope of the next-hop load balancer is controlled by its global access setting. With global access disabled (the default), the static route and load balancer next hop are only usable by resources in the same region. Packets sent from another region are dropped. If you enable global access, the load balancer next hop becomes accessible from all regions in the VPC network, allowing for multi-region client access. This setting is crucial for designs where client VMs or services are distributed across multiple regions but need to reach a centralized pool of virtual appliances.
High availability is achieved by placing backend VMs in managed or unmanaged instance groups across multiple zones within the load balancer's region. The load balancer continuously performs health checks on these backends. You can configure a failover policy on the backend service, designating some instance groups as primary and others as failover. If the health of primary backends falls below a defined failover ratio, traffic automatically fails over to the healthy VMs in the failover backend groups. This provides active-passive redundancy. For active-active designs, all backends are configured as primary.
Several constraints govern this design. First, a next-hop internal passthrough Network Load Balancer cannot use a shared IP address (--purpose=SHARED_LOADBALANCER_VIP); its forwarding rule IP must be unique to avoid ambiguous routing and dropped traffic. Second, Google Cloud never uses Equal-Cost Multi-Path (ECMP) to distribute traffic among multiple next-hop load balancers. If multiple static routes have the same destination and priority but point to different internal passthrough Network Load Balancers, a deterministic internal algorithm selects only one. To avoid ambiguity, use unique network tags on each route. Finally, the order of operations is strict: you must create the internal passthrough Network Load Balancer before creating the static route that uses it as a next hop, and you cannot delete the load balancer until all dependent routes are deleted.
In active-active designs, all backend VMs are configured as primary and handle traffic simultaneously. In active-passive designs, some instance groups are designated as primary while others serve as failover backups; traffic only moves to failover backends when primary health falls below the configured failover ratio.
When multiple static routes have the same destination and priority but different internal passthrough Network Load Balancer next hops, Google Cloud selects a single next hop using a deterministic internal algorithm rather than distributing traffic. To avoid this ambiguity, use unique network tags on each route or ensure routes have different priorities.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts