This page shows examples of invalid or inconsistent configurations of Google Cloud resources that you might encounter when troubleshooting your network with Connectivity Tests.
For instructions about how to run tests, see Create and run Connectivity Tests.
For a description of testing to and from common network source and destination types, see Common use cases.
Detect an invalid configuration
There are many different types of invalid configurations; that is, configurations that are not correct or that have been updated and are no longer valid.
One example is a virtual machine (VM) instance that has been configured as a NAT gateway, but which has been deleted or migrated. In this case, the route to the VM instance still exists.
In the following diagram,
Network 1 should be able to access data on
Network 2 through a VM instance named
nat_vm_1 no longer exists because it has migrated to a new VM,
The configured route from
VM1 to the other three VM instances still
nat_vm_1 as the next hop. However, because
nat_vm_1 no longer
exists and there is no route to
VM1 can't communicate with the
other VM instances.
A Connectivity Test run from
VM2 reveals that the
VM1 and the other VM instances has been dropped due to an
invalid next hop for the route to the other VMs.
In contrast, in the use case for an
VM3 is missing a network tag, making the load balancer configuration
across the load balancer backends. However, the configuration for
is valid because configuring a VM instance doesn't require a tag.
Detect an inconsistent configuration
You can also use Connectivity Tests to routinely validate inconsistent configurations. These configurations might not be causing any current connectivity issues, but might unintentionally reduce network redundancy or cause performance issues in the future.
The load balancer is configured to send traffic to an external IP address of
126.96.36.199. The traffic to that address is distributed across three
VM3. However, because of a missing network tag
VM3, the Virtual Private Cloud (VPC) firewall rule allows traffic from
external IP ranges to
VM2, but denies that traffic to
The following trace from the allowed source ranges configured for the load
balancer to the destination external IP address of the load balancer shows the
intended configuration and the inconsistency.
VM2 are reachable,
VM3 is unreachable. Only the two backends are reachable because
failed the health check.