Trigger action on source IP load balancing event?

Hi dubdub,

 

 

You should be able to locate the source_addr timeout by using the "persist lookup" command (http://devcentral.f5.com/wiki/iRules.persist.ashx), but I do not believe that you are going to be able to trigger an iRule based action because the persistence table just drops the record when the timeout is reached and you would need an iRule event to be called in order to process your cookie removal.

 

 

You might be able to do something like this with a script on the BIG-IP, but I do not think you can do it with an iRule.

 

 

 

Can you describe why you need to remove the app cookies when the LTM persistence expires? Ideally you want the LTM persistence timeout to be slightly longer than the app timeout so the client always gets back to the same pool member during their session. Are you trying to force a shorter application timeout than what the app uses?

 

 

Maybe you could remove the app cookie from the requests if there isn't an LTM source address persistence record for that client? The app should then set new cookies which overwrite the existing ones on the client.

 

 

Aaron

Hi Aaron,

Here's a paragraph from the application owner, which undoubtedly explains it better than I can:

"This happens (users getting a 500 error on occasion) because the application server issues a session cookie that is stored on the user's computer and is associated with the open browser. As long as that session information is current, the application will work as expected. Should it expire due to inactivity (in the application server, not the browser or computer), the session information stored on the application server is invalidated, but it remains on the user's computer. When the application is interacted with, the application server is supposed to detect the invalid session information and transparently log the user back in via single signon. However, for certain scenarios this does not occur. The application server does not invalidate the session information stored on the user's computer and instead attempts to use it. Since it is no longer valid, it errors out and the end result is the HTTP 500 message."

This is a known bug in the application server and has been fixed in a recent service pack. Unfortunately, due to other constraints, we're not able to upgrade the application server at this time.

I like the idea of removing the cookies when a persistence record doesn't exist. Something along the lines of this?

when HTTP_REQUEST {
  if { [session lookup uie "[IP::client_addr]"] eq "" } { 
    HTTP::cookie remove "first_cookie_name" 
    HTTP::cookie remove "second_cookie_name" 
  } 
} 

I am on 10.2.2 HF1, by the way.

Thanks,

Jen

Hi Jen,

 

 

Yes that idea should work well based on the description of the application bug. If you're using source address persistence, you could modify it slightly:

 

 

if { [persist lookup source_addr [IP::client_addr]] eq "" }{

 

 

Aaron

The rule is going through acceptance testing today, but it looks like it's working well so far. Thanks for all the help!

 

 

Thanks,

 

Jen