Expire Persistence Cookie

Pete,

the only way (I can think of) how to "expire" a persistence cookie via iRule is to send the client to a different (secondary) pool (based on URI and/or cookie). The secondary pool should have the same members (nodes) as the primary pool but should use different cookie for persistence. The rule needs to detect presense of the secondary cookie and send all subsequent requests to the secondary pool. The client will keep returning the primary cookie till it expires but it will be ignored at the secondary pool. Example:

pool primary {
   persist cookie
   cookie_mode insert
   cookie_name primaryCookie
   cookie_expiration 00:30:00
   member 10.1.21.2:http
   member 10.1.21.3:http
   member 10.1.21.4:http
}
pool secondary {
   persist cookie
   cookie_mode insert
   cookie_name secondaryCookie
   cookie_expiration 00:30:00
   member 10.1.21.2:http
   member 10.1.21.3:http
   member 10.1.21.4:http
}
rule cookie_selector {
   if((http_uri contains "/good_time_to_lb_again/" and exists http_cookie("primaryCookie")) or exists http_cookie("secondaryCookie")) {
        use pool secondary
   } else {
        use pool primary
   }
}

The solution does not scale too far, because it allows only one "re-loadbalancing" event. The best way how to implement application triggered re-loadbalancing is using cookie persistence in passive or rewite mode and control the cookie from within your application. That way you can expire the cookie at will.

BTW, You should always configure expiration time for your persistence cookies unless you want your clients to persist infinitely. In general the expiration time should be equal to or shorter than a session inactivity timeout in your application (if it has any).

You don't need to do anything special in order to deal with removed and/or disabled nodes. BIG-IP automatically falls-back to loadbalancing if the node recorded in persistence cookie received from client no longer exists or is down.

I thought of doing something with the application that would expire the cookie. We may have to try that route. The reason we we don't have an expiration time for the cookie is that we didn't want it to expire in the middle of them using the application since it could cause major issues. We do have an session cookie that times out after 60 minutes and logs the user out. The way I understood the timeout for the BigIP cookie is that it doesn't reset when used, so if we set the timeout for 30 minutes and someone is constantly using the app for 30 minutes they would be re-loadbalanced and possibly moved to the other server. We're really just looking for a graceful way to get people to a different server. I appreciate your input and thanks for the quick response.

 

 

-Pete

 

Pete,

 

 

BIG-IP sets persistence cookie on every response. So, if you set expiration time of X minutes on it, it will expire after X minutes of inactivity. Persistence cookies get new lifetime equal to the expiration time on every response.

 

 

Moreover, the cookie "expiration" is actually done by the client. Clients must not send a cookie past it's expiration back to the server/BIG-IP. If a client sends expired peristence cookie, BIG-IP will use it because it does not store cookies and so it has no way to detect a stale one.