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.
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.
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.
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 Google Cloud console, including successful results. However, the card
for each resource tested reads "No permission to view resource in
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
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.
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.
|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.|