cloud-foundation-fabric/blueprints/networking/ilb-next-hop

Internal Network Load Balancer as Next Hop

This blueprint bootstraps a minimal infrastructure for testing ILB as next hop, using simple Linux gateway VMS between two VPCs to emulate virtual appliances.

The following diagram shows the resources created by this blueprint

Two ILBs are configured on the primary and secondary interfaces of gateway VMs with active health checks, but only a single one is used as next hop by default to simplify testing. The second (right-side) VPC has default routes that point to the gateway VMs, to also use the right-side ILB as next hop set the ilb_right_enable variable to true.

Testing

This setup can be used to test and verify new Internal Network LB features like forwards all protocols on Internal Network LB as next hops and symmetric hashing, using simple curl and ping tests on clients. To make this practical, test VMs on both VPCs have nginx pre-installed and active on port 80.

On the gateways, iftop and tcpdump are installed by default to quickly monitor traffic passing forwarded across VPCs.

Session affinity on the Internal Network LB backend services can be changed using gcloud compute backend-services update on each of the Internal Network LBs, or by setting the ilb_session_affinity variable to update both Internal Network LBs.

Simple /root/start.sh and /root/stop.sh scripts are pre-installed on both gateways to configure iptables so that health check requests are rejected and re-enabled, to quickly simulate removing instances from the Internal Network LB backends.

Some scenarios to test:

• short-lived connections with session affinity set to the default of NONE, then to CLIENT_IP
• long-lived connections, failing health checks on the active gateway while the connection is active

Useful commands

Basic commands to SSH to VMs and monitor backend health are provided in the Terraform outputs, and they already match input variables so that names, zones, etc. are correct. Other testing commands are provided below, adjust names to match your setup.

Create a large file on a destination VM (eg ilb-test-vm-right-1) to test long-running connections.

dd if=/dev/zero of=/var/www/html/test.txt bs=10M count=100 status=progress

Run curl from a source VM (eg ilb-test-vm-left-1) to send requests to a destination VM artificially slowing traffic.

curl -0 --output /dev/null --limit-rate 10k 10.0.1.3/test.txt

Monitor traffic from a source VM (eg ilb-test-vm-left-1) on the gateways.

iftop -n -F 10.0.0.3/32

Poll summary health status for a backend.

watch '\
  gcloud compute backend-services get-health ilb-test-ilb-right \
    --region europe-west1 \
    --flatten status.healthStatus \
    --format "value(status.healthStatus.ipAddress, status.healthStatus.healthState)" \
'

A sample testing session using tmux:

Variables

name	description	type	required	default
prefix	Prefix used for resource names.	string	✓
project_id	Existing project id.	string	✓
ilb_right_enable	Route right to left traffic through ILB.	bool		false
ilb_session_affinity	Session affinity configuration for ILBs.	string		"CLIENT_IP"
ip_ranges	IP CIDR ranges used for VPC subnets.	map(string)		{…}
project_create	Create project instead of using an existing one.	bool		false
region	Region used for resources.	string		"europe-west1"
zones	Zone suffixes used for instances.	list(string)		["b", "c"]

Outputs

name	description	sensitive
addresses	IP addresses.
backend_health_left	Command-line health status for left ILB backends.
backend_health_right	Command-line health status for right ILB backends.
ssh_gw	Command-line login to gateway VMs.
ssh_vm_left	Command-line login to left VMs.
ssh_vm_right	Command-line login to right VMs.

Test

module "test" {
  source         = "./fabric/blueprints/networking/ilb-next-hop"
  prefix         = "test"
  project_create = true
  project_id     = "project-1"
}
# tftest modules=18 resources=46