When a cookie is created at the bIG IP level it seems that the user is stuck on the same server for his session (which is a requirement of our solution) but should that server fail during the session, user gets Pages cannot be display..(probably because of the cookie) Is there a way (like health monitor) to determine that the node is down AND the session would be clenaly failed over the other server?

If you set "Action On Service Down" to "Reselect" it works. I think you will have to be on 9.1 for that to work.

When a member is detected down, persistence records to it should be invalidated. Since I can't see the traffic flow to your servers, my best guess is that since service checking occurs out-of-band, the next request may be hitting the server before service checks detect it as down. You can work around this in a combination of 2 ways: a) Invalidate the persistence record from an LB_FAILED event, and reselect or redirect back again. and b) Use bl0ndie's request-reissuing rule to resend the same request to a different server if the error occurs after the request has already been sent to the server. (e.g. a 503 error.)

To provide an example of rappy's solution a) above, simply try adding this to a rule on your virtual:when LB_FAILED { if { not [info exists retry_count] } { set retry_count 0 } if { $retry_count < 3 } { LB::reselect incr retry_count } } For solution b) you'll have to wait until 9.2 ships as it requires some new commands that are only available in 9.2.

question: in the event of the reslection of another node can session information be kept on the session failing over or is the user doom to restart anther session on the failed over node.?

If by "session" you mean the SSL session, then that is going to depend on the browser. In most cases, the browser isn't even going to know the old node is down as it's talking to the vip. So, it will continue to use the existing session. This is also true for session cookies.