Test connectivity to Google Cloud load balancers

This page describes common scenarios for testing connectivity to Google Cloud load balancers.

Connectivity Tests configuration analysis supports tracing simulated packets to all types of Google Cloud load balancers. The trace path for an external HTTP(S) load balancer also applies to a TCP proxy load balancer and an SSL proxy load balancer. For more information, see the Cloud Load Balancing overview.

In the following example, Connectivity Tests traces a simulated packet from an external host to a virtual IP address (VIP) for an external HTTP(S) load balancer. The TCP connection from the external host terminates at the proxy for the external HTTP(S) load balancer. The external HTTP(S) load balancer then initiates a new TCP connection to a VM acting as a load balancer backend.

A typical trace path to an external HTTP(S) load balancer.
A typical trace path to an external HTTP(S) load balancer

Trace diagrams on this page use the symbols described in the following legend.
Symbol Name Meaning
Gray diamond
Legend for packet trace diagram: gray diamond.
Checkpoint A decision point where Connectivity Tests checks a configuration and decides if a trace packet should be forwarded, delivered, or dropped.
Blue rectangle
Legend for packet trace diagram: blue rectangle.
Hop A step in the forwarding path for a trace packet, representing a Google Cloud resource that forwards a packet to the next hop in a VPC network (for example, to a Cloud Load Balancing proxy or to a Cloud VPN tunnel).
Orange hexagon
Legend for packet trace diagram: orange hexagon.
Endpoint The source or destination of a trace packet.

In the following trace path, the Connectivity Tests configuration analysis provides three traces, one for each possible path to the three load balancer backends. Connectivity Tests does this because it validates only configurations, not the live data plane.

Packet trace to an external HTTP(S) load balancer.
Packet trace to an external HTTP(S) load balancer

A successful test to a load balancer

This section describes an example of a successful test to the external HTTP(S) load balancer described previously.

In the actual data plane, the load-balancing algorithm chooses a VM instance for each backend connection. Because there are three load balancer backends in this example, the Trace selection menu on the Results screen enables you to select the trace that you want to view.

The following successful test result validates that all of the following Google Cloud resources for the external HTTP(S) load balancer are configured correctly:

  • The forwarding rule
  • The load balancer backends, including the ability for the load balancer to successfully send health checks to those backends
  • The proxy connection
  • VPC firewall rules

This result shows that a simulated packet from an external IP address could successfully reach the backend VM instances.

For a detailed example of a trace to all three backends, see Detect invalid or inconsistent configurations.

Example output for a successful test to an external HTTP(S) load balancer.
Example output for a successful test to an external HTTP(S) load balancer

If you don't have permissions to review the Google Cloud resources in the network path for the external HTTP(S) load balancer, you still see results in the Cloud Console, including successful results. However, the card for each resource tested reads "No permission to view resource in PROJECT_NAME."

A test showing a missing firewall rule for a health check

A load balancer trace verifies many of the same Google Cloud resource configurations described previously. However, if the following load balancer resources are misconfigured, the analysis shows Packet could be dropped (a final state of the trace is Drop).

The following test result shows that the VPC network's ingress firewall rules do not allow a health check to the load balancer backends, making the backends unavailable to the load balancer.

Example output for a missing firewall rule.
Example output for a missing firewall rule

In addition to invalid VPC firewall rules, the problems in the following table are common configuration issues that Connectivity Tests detects for Google Cloud load balancers. To correct these issues, use the solutions described in the table.

Configuration issue Solution
The input parameters don't match the protocol or port that you defined in the forwarding rule for the load balancer. Before you run a test, change the input parameter to match the protocol or port that you defined in the forwarding rule.
The forwarding rule for the load balancer does not have backends configured. Before you run a test, configure the backends for the load balancer.
The load balancer has invalid or inconsistent configurations. Before you run a test, correct the invalid or inconsistent configurations.
Traffic can't reach an internal TCP/UDP load balancer that has a mismatched region because the internal TCP/UDP load balancer is a regional service. Before you run a test, configure load balancer components so that they are located in the same region.

What's next