Invalid or inconsistent configurations encountered when running Connectivity Tests

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 a description of testing to and from common network source and destination types, see Common use cases.

Detecting 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, VM1 in Network 1 should be able to access data on VM2, VM3, and VM4 in Network 2 through a VM instance named nat_vm_1. However, nat_vm_1 no longer exists because it has migrated to a new VM, nat_vm_2.

The configured route from VM1 to the other three VM instances still points to nat_vm_1 as the next hop. However, because nat_vm_1 no longer exists and there is no route to nat_vm_2, VM1 can't communicate with the other VM instances.

A Connectivity Test run fromVM1 to VM2 reveals that the traffic between VM1 and the other VM instances has been dropped due to an invalid next hop for the route to the other VMs.

An invalid route configuration for Cloud NAT.
An invalid route configuration for Cloud NAT

In contrast, in the use case for an inconsistent configuration, VM3 is missing a network tag, making the load balancer configuration inconsistent across the load balancer backends. However, the configuration for VM3 itself is valid, because configuring a VM instance doesn't require a tag.

Detecting 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 35.184.176.28. The traffic to that address is distributed across three backends: VM1, VM2, and VM3. However, because of a missing network tag on VM3, the Virtual Private Cloud (VPC) firewall allows traffic from external IP ranges to VM1 and VM2, but denies that traffic to VM3.

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. VM1 and VM2 are reachable, but VM3 is unreachable. Only the two backends are reachable because VM3 has failed the health check.

An external HTTP(S) load balancer with an inconsistent backend configuration.
An external HTTP(S) load balancer with an inconsistent backend configuration

What's next