Web Stack: Client → LB → Servers

The scenario

The Browser (10.0.1.10) reaches the Load Balancer through a Router. The Load Balancer's virtual IP (VIP) is its own front address, 10.0.2.10, and it balances TCP port 80 across App-1 (10.0.3.10) and App-2 (10.0.3.11), both running HTTP on port 80 behind a Server Switch. For each new connection to 10.0.2.10:80, the balancer rewrites the destination to a backend and rewrites the source to its own backend-side address, 10.0.3.1, so the app servers answer the balancer, which translates the reply back to the Browser. In a live lab the balancer sends each new connection to the next backend in turn (round-robin); the simulator always shows App-1. The balancer only serves port 80: nothing listens on any other port of 10.0.2.10. The Router also has a static route to the backend network, 10.0.3.0/24 via 10.0.2.10, and uses static routes only (OSPF is off).

What you will work out

See how a layer 4 load balancer turns connections to one virtual IP into connections to backend servers, what the backends see, and which ports it really serves.

Why this matters

Load balancers sit in front of most sites that run on more than one server, as hardware appliances, as software such as HAProxy, nginx or Linux IPVS, and as cloud services such as AWS Elastic Load Balancing. When 'some requests fail', the questions come from this lab: does the balancer serve that port, is the service running on every backend (a balancer without health checks keeps sending traffic to a dead one), and do the backends' logs show the balancer's address instead of the client's?

Running it

Web Stack: Client → LB → Servers opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.