Same Sunbet Problem

One of the most common problems that afflict load balancing situations is the “same subnet” problem. This is when a client tries to browse a Virtual Service/VIP from the same subnet as the real servers. Lately, I’ve seen this come up on the mailing list. See here (and my response) and here.

If the virtual server is setup as “transparent”, where the client IP address is preserved (i.e., the load balancer doesn’t act like proxy), then the clients cannot respond correctly.

The load balancer performs network address translation on the way in, and on the way out. This is necessary for the connection to work correctly. However, if the client is on the same subnet as the real server, the server will respond to the client directly, without hitting the load balancer on the way out. The source IP address will appear to be the server, and not the virtual service. Because the client sent the connection to the virtual service, it will drop all incoming packets from the server.

The client can be on the same subnet as the virtual service and browsing will work, provided that the virtual service is on a separate subnet from the real servers.

There are a few solutions for this:

The first is to disable transparency, and have the load balancer act like a proxy. The downside to this is that you lose the source IP address for your server logs (all connections appear to be coming from the load balancer).

Another solution is to use DSR (Direct Server Return). The downside to this is that you cannot do cookie persistence, or any other fancy Layer 7 features.

Depending on your situation, a compromise might be to setup two virtual IPs, each with identical real servers sitting behind them.  One would be for the public, which would preserve the IP address, and the other would be for client systems that sit on the same subnet, and that one would be set for non-transparent/proxy mode.

About the Author