persistence cookie at BIG IP level too persistent?

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.

i ' m talkin about let say Authentication session to the web app. when a user is browsing the web app if the node fail and lets say an LB_FAILED event occurs and goes through a reselect rule and the traffic is redirected to another node, the user will have to authenticate again. is there a way for the big ip to prevent that?

The user shouldn't have to authenticate again, unless the server is forcing that. It should be no different than if the bigip load-balanced to another node in the first place. The client browser never knows that the back-end connection is changing because the client's connection is actually terminated at the bigip and then spliced to a back-end connection.

server is forcing it.

I'm not sure how you are going to handle this. It would likely be difficult for the Bigip to keep the authentication information so that it could re-insert it to the new server (though that probably could be done but it would require a deeper knowledge of how your back end app is authenticating). Many people move the authentication to the Bigip as it avoids this problem.

Thank you very much for your support unRuleY. Had to close the pre sale case today. This item was marked as 'not supported'..it kinda blew the customer away cause he had MScluster or some kind of IIS plug in who could do it.. but we will see...