Server Load Balancing

Server Load Balancing distributes application traffic between network servers, so that all requests can be fulfilled in a timely manner. For example, if a client wants to connect to a website and his browser does not load within seconds he won't complain about "overloaded routers" in transit. He won't blame, that the web server, he is connecting to, has to serve 1000 other users at the same time. He problably would only complain about time and may chose to go somewhere else, where he will find similar information. By using Load Balancing options, the provider can make sure that content gets loaded as quick as possible and no bottleneck prevents that user for coming back. Additional features to protect and unload CPU / Memory Resources will help to speed up the process as well.

 DNS entry of is tight to VIP of Load Balancer

Load Balancing improves network performance by distributing traffic efficiently so that individual servers are not overloaded by high impact of activities. There are many options how to provide Server Load Balancing and different vendors are using different algorithms and features to help customers.

The most common topologies are one-armed, .routed and transparent.

Typical Traffic Flow

Client sends a request to The DNS Entry of points to the load balancer public IP, which is the Red Side of the Load Balancer. The source of the packet is with the destination of When the Load Balancer gets the packet, it needs to choose the server and rewrites the packet to be destined for IP The Source IP is still, so the server logs are accurate with the Client IP. Server 1 replies to the request with Source IP destined to Since the servers default Gateway is the Green Side of the Load Balancer, the packet will be handed over to Now, the Load Balancer has to rewrite the source address from to the Red Side IP Address of and forwards the packet to the client. All the client knows, is the fact that it has sent a request to at and has no idea what backend server did fulfill the request.

If the client would have received the response from a backend server with corresponding source address, it would not have any idea what to do with it and will discard the packet

One-Armed Mode

For a one-armed configuration, all traffic passes over a single network interface. The Load Balancer accepts connections on a listening socket and holds this. It then creates a connection of its own to a backend server based on the load balancing policy. When it get the required data from the server, the Load Balancer sends it back to the client.


A One-Armed Mode is easy to deploy and perfect for evaluation, as I did with a jetNexus Virtual Appliance in my lab.


The server sees every request as a request from the load balancer and not the real client on the internet. If the traffic is HTTP based, the client's IP can be embedded in to a custom header for the server to collect stats. (x-forwarded-for)

Two-Armed Routed Mode

In a two-armed routed configuration all traffic between the client and the Load Balancer goes over the Red Side ( All traffic between the Load Balancer and the Backend Server goes over the Green Side ( Virtual server ( has to sit on a different subnet than the real server. Load Balancer is configured as the default gateway for the Server 1, Server 2 and Server 3


Backend Servers can be masked from the clients. Also additional filtering can be done on the Load Balancer


Server have to point their default route to the Load Balancer. Virtual IP Address has to be on a different subnet than the servers


Two-Armed Transparent Mode

In a two-armed transparent configuration, the load balancer serves as a bridge. Virtual Server sits on the same subnet as the real servers, but physically separated by the load balancer.


Low design impact, as no new subnets need to be created.


The risk of creating a loop is high, so smart Spanning Tree configurations or only one link between servers and clients to avoid that risk.