balance with 302 to a pool

Why would you send the client a 302? I'm a bit confused about the relationship between the 302, least connections algorithm and NAT problems.

Least connections can be selected as your default pool's algorithm.

As for NAT problems and X-Forwarded-For, you need to apply source NAT to your Virtual Server and use X-Forwarded-For to send the true client IP to your pool members if said pool members do not use the Big IP as default gateway. Otherwise you will end up with assymetrical routing and it will most likely break your application.

Hej, thanks for your reply. No, the destination will not understand the x-forward header.

So what happens in an ACE module is, you call 1.1.1.1 behind 1.1.1.1 you have a pool with server 2.2.2.2, 3.3.3.3 and 4.4.4.4

when client connects to 1.1.1.1, the LB checks this pool for the server with the least connections and sends a 302 with that server IP back to the client. the client understands the 302 and directly connects to the server - not through the LB. (and this way it is NOT asymetric) This is a very efficient way to provide a) the original client-IP and b) do not sent heavy traffic-load through the LB. and still you have redundancy and load-sharing.

this must be possible with F5 as well?

I see... can you try configuring your pool with least-connections algorithm, add it as default pool to your Virtual Server and then try this iRule on your Virtual Server :

when HTTP_REQUEST {

eval [LB::select]

HTTP::respond 302 Location http://[LB::server addr]:[LB::server port]

}

What this iRule should do is trigger the load balancing algorithm (set to least-connections on your pool) to select a server and then dynamically add the pool member's IP address and port to the 302 redirect sent to the client. Can't say I've seen this done before but I think it should work. You can replace http:// by https:// in the 302 response of course if your servers expect an encrypted connection.

least connection requires the connection is going through the bigIP.

if the connection is direct from the client to the server, least connection will never work.

this kind of method can provide load sharing but never redundancy, as if the server is not available, the client will continue to request the same server.

That's a good point... the iRule should still work but the least-connections load balancing algorithm is pointless if the Big IP cannot track the active connections. Good catch :)

So what happens in an ACE module is, you call 1.1.1.1 behind 1.1.1.1 you have a pool with server 2.2.2.2, 3.3.3.3 and 4.4.4.4

...

this must be possible with F5 as well?

Not really.

How do you determine the number of connections to a pool member when the clients can directly connect to the pool members.

Your F5 Load balancer is the heavy network lifter and is expected to manage all the traffic to and from the pool members. It also isolates the pool members from the internet by providing the single IP (vip) for clients to connect to. This hides the internal details of your network implementation, and prevents attackers from identifying and targeting specific pool members.

You do not need to SNAT traffic to your pool members - if you can configure your pool members to route back out through the load balancer, then you can use a Standard virtual. If not, then you need to use n-Path (asymmetric) routing with a Performance Layer-4 virtual.

Implementing an irule to mimic the ACE behaviour would be possible, but isn't really the way to do things - work out how to implement the desired solution with the tools the LTM provides, as it will be more efficient and faster.

thanks a lot for the iRule - I will give this a try.

Stanislas, it will provide redundancy as long as you don't need persistence

Does it mean for every requests, the client first request the virtual address before redirecting to the selected server?

This behavior may consume more CPU on load balancer and increase latency.

well it's flow-based, not packet-based. actually it is in this case the access to exchange on tcp 443 and these are actually long-lasting flows. you are right if it comes to many, short sessions.