Professional Cloud Network Engineer
An internal passthrough Network Load Balancer can serve as a next hop in a custom route, acting as a traffic distribution point within a Virtual Private Cloud (VPC) network. This architecture lets organizations insert scalable pools of virtual appliancesâsuch as firewalls, intrusion detection systems, and NAT gatewaysâdirectly into the communication path between workloads. The load balancer operates as a software-defined passthrough service built on Google's Andromeda virtualization stack, routing original client packets directly to backend instances without changing source or destination IP addresses or ports.
Virtual appliance chaining places a pool of third-party security or routing instances behind an internal passthrough Network Load Balancer to perform stateful inspection or protocol filtering. To process traffic destined for other networks, every backend virtual machine (VM) must have IP forwarding enabled in its configuration. In multi-network designs, each network interface of a backend VM must reside in a separate VPC network, allowing the appliance to bridge trusted and untrusted environments. Google Cloud uses symmetric hashing to ensure bidirectional traffic flows between two endpoints consistently reach the same backend appliance instance without requiring source network address translation. Google Kubernetes Engine nodes cannot serve as next-hop backends because the node routing software only processes traffic directed to cluster-managed Pod IP addresses.
Static routes and policy-based routes direct traffic to the forwarding rule of an internal passthrough Network Load Balancer to steer traffic through inspection appliances. When configured as a next hop, the load balancer forwards all supported IP protocolsâincluding TCP, UDP, and ICMPâacross all ports to healthy backend instances regardless of the specific protocols or ports configured on the forwarding rule or backend service. A static route destination range cannot match or be more specific than any existing subnet route in the VPC network because subnet routes always take precedence. Policy-based routes evaluate traffic based on source and destination IP ranges, protocols, and network interfaces to direct incoming traffic from Cloud Interconnect or Cloud VPN to the load balancer.
Route selection follows strict precedence rules when multiple paths to a destination exist. When multiple static routes share the same destination prefix and priority but point to different next hop internal passthrough Network Load Balancers, Google Cloud never distributes traffic across them using equal-cost multi-path routing. Instead, the control plane applies an internal deterministic algorithm to select a single next hop load balancer for that route. Administrators must apply distinct network tags to routes to steer specific VM traffic predictably and avoid next-hop ambiguity. Forwarding rules configured with shared IP addresses are unsupported as next hops, and packets directed to them are dropped. If all backend VMs fail health checks, the route remains active in the network, and packets continue flowing to one of the unhealthy backends according to the traffic distribution policy.
The operational scope of a next hop internal passthrough Network Load Balancer is determined by its regional configuration and connected network topologies. By default, global access is disabled, which restricts next-hop route accessibility exclusively to client VMs, VPN tunnels, and interconnect attachments residing in the same region as the load balancer. When global access is enabled, workloads and dynamic routing systems in any Google Cloud region can forward packets to the regional load balancer next hop. Cloud Router uses custom route advertisements to propagate the static route destination prefix to on-premises networks across hybrid interconnects or VPNs. Cross-network designs can exchange these custom static routes using VPC Network Peering or configure Network Connectivity Center to allow a static route in one VPC spoke to reference an IPv4 next-hop load balancer located in a peered spoke.
Integrating an internal load balancer as a next hop for hybrid connectivity means configuring your network so that traffic coming from on-premises or other VPCs, via services like Cloud VPN or Cloud Interconnect, is directed through an internal load balancer before reaching its final destination. To send hybrid traffic through an internal load balancer, you must create custom routes in your VPC network that specify the ILB's forwarding rule IP address as the next hop for traffic destined to specific backend services. When traffic arrives from an on-premises network via a Cloud VPN tunnel or Cloud Interconnect VLAN attachment, the VPC's routing table directs it to the ILB's IP, not directly to the backend instances. This requires the ILB's frontend IP to be reachable from the hybrid connection, which is managed through dynamic or static routing advertisements.
For the ILB next hop to work, its frontend IP address must be reachable from the hybrid network. This is typically achieved by using dynamic routing with Cloud Router, which automatically advertises the VPC subnets, including the ILB's subnet, to the on-premises BGP peer. If using static routing (only available with Classic VPN), you must manually add a route that points the specific destination prefix to the Cloud VPN tunnel's next hop, and ensure the ILB's subnet is included in the advertised networks. A major consideration is asymmetric routing, where traffic from on-premises goes to the ILB, but the return path from the backend might go directly out via the default internet gateway. To prevent this, firewall rules and policies on the backend VMs must be configured to route reply traffic back through the ILB, maintaining session state for stateful devices.
Using an ILB as a next hop integrates well with centralized network models like Shared VPC. In a Shared VPC setup, the ILB and its required routes can be provisioned in the host project, allowing service projects across the organization to leverage the same ILB for hybrid traffic without managing the network infrastructure. The ILB can distribute traffic to backends in different service projects, providing a centralized point for security policy enforcement, health checks, and traffic management. When integrating with hybrid connectivity, the Cloud Interconnect or Cloud VPN attachments are also configured in the host project's Shared VPC, simplifying the overall architecture and ensuring all hybrid traffic flows through the centralized ILB next hop.
Route priority in Google Cloud VPC networks determines which route is selected when multiple routes could apply to a packet's destination. Lower numerical values indicate higher priority, with 0 representing the highest possible priority and 65,535 representing the lowest. When evaluating routes, Google Cloud first considers the most specific destination that contains the packet's destination IP addressâfor example, a destination of 10.240.1.0/24 takes precedence over 10.240.0.0/16 because it is more specific. Custom static routes using internal passthrough Network Load Balancer next hops are included when exported through VPC Network Peering, while static routes with a default internet gateway next hop are excluded from such exports.
When a static route specifies an internal passthrough Network Load Balancer frontend IP as its next hop, Google Cloud determines which ILB to use based on the next hop IP address and its location within the VPC network topology. If the next hop IP address falls within the destination range of a local subnet route, Google Cloud searches exclusively for an ILB whose forwarding rule IP address is in the corresponding local subnet. If the next hop IP address falls within a Network Connectivity Center subnet route imported from a hub, Google Cloud searches for an ILB in a corresponding subnet of another VPC spoke. When the next hop IP address falls within a peering subnet route imported from another VPC network connected through VPC Network Peering, Google Cloud exclusively searches for an ILB in the corresponding subnet of the peered VPC network. If no matching ILB is found at the specified next hop IP address, packets sent to the destination range of the static route are dropped.
Google Cloud evaluates routes in a specific order that affects which next hop is selected. Policy-based routes are evaluated first by priority, then subnet routes are evaluated, followed by the most specific destination matching among static and dynamic routes. After determining the most specific destination, Google Cloud selects the most favorable custom route type according to a preference hierarchy: static routes with next hop instances or Classic VPN tunnels rank first, followed by dynamic routes of a single type, then a single static route with an ILB next hop, and finally static routes with the default internet gateway. When multiple static routes with ILB next hops have identical destinations and priorities, Google Cloud does not perform equal-cost multipath distribution among them; instead, Google Cloud selects a single ILB next hop using a deterministic internal algorithm.
You must create an internal passthrough Network Load Balancer before creating a static route that uses it as a next hopâthe load balancer must exist before you can create the route, and attempting to create a route referring to a nonexistent load balancer returns an error. After creating a route with an ILB next hop, you cannot delete the load balancer unless you first delete the route. All backend VMs for the ILB must have IP forwarding enabled to process routed traffic, and you cannot use an internal passthrough Network Load Balancer whose backends are Google Kubernetes Engine nodes as a next hop. Forwarding rules that use a common internal IP address are not supported for next hop ILBs because they would reference different backend services, creating ambiguity about which load balancer is intended.
When all backends of an internal passthrough Network Load Balancer fail health checks, the routes using that load balancer as a next hop remain in effect. Packets processed by the route are sent to one of the next hop load balancer's backends according to traffic distribution, meaning traffic continues to be forwarded even when all backends are unhealthy. The load balancer 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, supporting all protocols that Google Cloud VPC networks support, including TCP, UDP, and ICMP.
With global access enabled, the ILB next hop is accessible from any Google Cloud region. With global access disabled, the ILB next hop is accessible only from client VMs, VPN tunnels, and interconnect attachments in the same region as the load balancer.
No, you cannot use an internal passthrough Network Load Balancer whose backends are Google Kubernetes Engine nodes as a next hop because the node routing software only processes traffic directed to Pod IP addresses managed by the cluster.
Google Cloud does not use equal-cost multipath routing to distribute traffic across multiple ILB next hops with identical destinations and priorities. Instead, it applies an internal deterministic algorithm to select a single ILB next hop.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts