Test shared how-to NetLB test modules

Test internal TCP LB

Create client VM

This example creates a client VM in the same region as the backends. You then send traffic from the client to the load balancer.

The client VM can be in any zone in the same region as the load balancer, and it can use any subnet in that region.

Console

  1. In the Google Cloud console, go to the VM instances page.

    Go to VM instances

  2. Click Create instance.

  3. In the Name field, enter a name.

  4. For Region, select the same region as the load balancer.

  5. For Zone, select a zone.

  6. Click Networking.

  7. Configure the following fields and click Done:

    • For Network tags, enter allow-ssh.
    • For Network interfaces, select a network and a subnet. You can use the same network and subnet as the backends.
    • For IP stack type, choose IPv6 (single-stack).
  8. Click Create.

gcloud

gcloud compute instances create CLIENT_VM_NAME \
    --zone=ZONE \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --stack-type=IPV6_ONLY \
    --tags=allow-ssh \
    --subnet=SUBNET

Replace the following:

  • CLIENT_VM_NAME: the name of the client VM.
  • ZONE: the zone for the client VM. This zone must be in the same region as the load balancer.
  • SUBNET: the subnet for the client VM.

Send IPv6 traffic to the load balancer

Now that you have configured your load balancer, you can test your deployment by sending traffic to the load balancer's IP address. It might take a few minutes for the load balancer configuration to propagate after you first deploy it.

  1. Connect to the client VM instance.

    gcloud compute ssh CLIENT_VM_NAME \
        --zone=ZONE
    

    Replace the following:

    • CLIENT_VM_NAME: the name of the client VM.
    • ZONE: the zone of the client VM.
  2. Get the IP address of the load balancer.

    To get the IPv6 address, use the following command.

    gcloud compute forwarding-rules describe IPV6_FORWARDING_RULE_NAME \
        --region=REGION
    

    Replace IPV6_FORWARDING_RULE_NAME with the name of the IPv6 forwarding rule.

  3. Send traffic to the load balancer.

    From clients with IPv6 connectivity, run the following command:

    curl -m 10 -s http://LB_IPV6_ADDRESS:80
    

    Replace LB_IPV6_ADDRESS with the IPv6 address of the load balancer.

    For example, if the assigned IPv6 address is [fd20:1db0:b882:802:0:46:0:0/96]:80, the command should look like:

    curl -m 10 -s http://[fd20:1db0:b882:802:0:46:0:0]:80
    

Send IPv4 traffic to the load balancer

Now that you have configured your load balancer, you can test your deployment by sending traffic to the load balancer's IP address. It might take a few minutes for the load balancer configuration to propagate after you first deploy it.

  1. Connect to the client VM instance.

    gcloud compute ssh CLIENT_VM_NAME \
        --zone=ZONE
    

    Replace the following:

    • CLIENT_VM_NAME: the name of the client VM.
    • ZONE: the zone of the client VM.
  2. Get the IP address of the load balancer.

    To get the IPv4 address, use the following command.

    gcloud compute forwarding-rules describe IPV4_FORWARDING_RULE_NAME \
        --region=REGION
    

    Replace IPV4_FORWARDING_RULE_NAME with the name of the IPv4 forwarding rule.

  3. Send traffic to the load balancer.

    From clients with IPv4 connectivity, run the following command:

    curl -m 10 -s http://LB_IPV4_ADDRESS:80
    

    Replace LB_IPV4_ADDRESS with the IPv4 address of the load balancer.

Test external TCP LB

Send IPv6 traffic to the load balancer

Now that you have configured your load balancer, you can test your deployment by sending traffic to the load balancer's IP address. It might take a few minutes for the load balancer configuration to propagate after you first deploy it.

  1. Get the load balancer's IP address.

    To get the IPv6 address, use the following command.

    gcloud compute forwarding-rules describe IPV6_FORWARDING_RULE_NAME \
        --region=REGION
    

    Replace IPV6_FORWARDING_RULE_NAME with the name of the IPv6 forwarding rule.

  2. Send traffic to your load balancer by using curl to contact its IP address.

    From clients with IPv6 connectivity, run the following command:

    while true; do curl -m1 http://LB_IPV6_ADDRESS; done
    

    Replace LB_IPV6_ADDRESS with the IPv6 address of the load balancer.

    For example, if the assigned IPv6 address is [2001:db8:1:1:1:1:1:1/96]:80, the command is similar to the following:

    while true; do curl -m1 http://[2001:db8:1:1:1:1:1:1]:80; done
    

    Note the text returned by the curl command. The name of the backend VM generating the response is displayed in that text; for example: Page served from: VM_NAME.

    The response from the curl command alternates randomly among the backend instances. If your response is initially unsuccessful, you might need to wait approximately 30 seconds for the configuration to be fully loaded and for your instances to be marked healthy before trying again.

Send IPv4 traffic to the load balancer

Now that you have configured your load balancer, you can test your deployment by sending traffic to the load balancer's IP address. It might take a few minutes for the load balancer configuration to propagate after you first deploy it.

  1. Get the load balancer's IP address.

    To get the IPv4 address, use the following command.

    gcloud compute forwarding-rules describe IPV4_FORWARDING_RULE_NAME \
        --region=REGION
    

    Replace IPV4_FORWARDING_RULE_NAME with the name of the IPv4 forwarding rule.

  2. Send traffic to your load balancer by using curl to contact its IP address.

    From clients with IPv4 connectivity, run the following command:

    while true; do curl -m1 LB_IPV4_ADDRESS; done
    

    Replace LB_IPV4_ADDRESS with the IPv4 address of the load balancer.

    Note the text returned by the curl command. The name of the backend VM generating the response is displayed in that text; for example: Page served from: VM_NAME.

    The response from the curl command alternates randomly among the backend instances. If your response is initially unsuccessful, you might need to wait approximately 30 seconds for the configuration to be fully loaded and for your instances to be marked healthy before trying again.