Forum Discussion
skriba_85538
Nimbostratus
NimbostratusBigIP 1500 sticky session management/AOL problems
Hello,
How do you handle sticky session management with BigIPs for cases like users from AOL whose source IP address will change per request?
We recently installed 2 BigIP 1500's in active/backup mode for our production sites. The web application layer is ColdFusion 7, and our web apps use CF's Session scope to store variables. CF writes a cookie to the client to manage the session, which is fine since we require cookies for all our sites. Since we use the Session scope in CF, we knew we would have to peg the users to a specific web server for the life of their session. (Rewriting our thousands of web pages to be Session-less was not an option because of time.) We set the BigIPs to stick session state based on the source IP. The timeouts for the CF sessions is 30 minutes, so we set the BipIPs to 2 hours just so we don't encounter any conflict between the two. During our testing phase, everything appeared fine with the session management, so we went live with the new config.
After two months, though, we've been getting many session timeout messages on our sites. Half of these session timeout messages happen for AOL users (found by looking at the HTTP headers in our Apache logs). Having half of all the errors revolve around AOL users made me start to investigate what's different about AOL and sticky session management. I started finding a bunch of articles like this:
http://www.thescripts.com/forum/thread54390.html
Basically, AOL and similar ISPs will not necessarily NAT a users' request through the same IP address, so the source IP can change per page request. Suffice it to say this means out current BigIP session management does not work for it.
So, for these configuration needs and stated problem, is there a Session management state (iRule?) we can use on the BigIPs that will properly route requests from AOL and similar users to the same web server even if their source IP changes between requests? I heard that we can put in blocks/subnet masks for ranges of IPs to treat as the same source. This, though, does not appear to be a good solution. We would have to find all the outbound IPs for all ISPs that do this, which is an improbable task. On top of that, if any ISP adds outbound IPs to these ranges, this solution would break, making maintenance a nightmare and a reactive, not proactive, problem. I see many different options for persistence for the BigIPs from articles like this:
http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=47
I don't know the details of the other session persistence options, so any guidance as to which one(s) could work for our scenario would be extremely helpful.
I will admit that I do not know anything about configuring BigIPs since our managed hosting provider deals with them. But, since I manage the ColdFusion/development side, I need to understand how the BigIPs will interact with its Session scope to resolve this problem.
Thank you,
Lou
johnsEmployee
I think you can easily overcome this issue by just using Cookie Persistence for your Persistence Profile. Create your own cookie persistence profile based on the templates. BIG-IP will insert its own cookie into the response and enforce stickiness with subsequent visits.
Lightspeed_VT_5We've had this exact problem, and we're using ColdFusion (8) as well. The timeout issue doesn't manifest itself for several weeks / months after bringing a freshly-formatted LTM 1500 into the mix. Once the problem starts, it is relentless and occurs frequently and consistently.
We've tried cookie persistence, universal persistence using a JSESSION-created iRule, setting monitor internal and timeout values ridiculously high to no avail.
Did the original poster find a solution to this problem?- The original poster most likely resolved the issue by following the cookie persistence recommendation -- it's pretty reliable if your clients use cookies.
One approach we've recommended in the past is to set Simple/Source Address persistence with a 16 bit mask, which will cause all connections from any AOL proxy to clump together on the same persistence record. The downside there is that clumping to a single server can be quite dramatic if you have a high percentage of AOL users, and other (non-AOL) connections will clump together separately in the same manner.
As of LTM 9.0, we've added special support for AOL persistence intended to avoid the unnecessary clumping of non-AOL clients. To implement that configuration, follow the simple guidance of AskF5 SOL7004: Using Source Address Affinity for AOL persistence connections (Click here) and be sure to set a performance LB method such as Fastest or Least Connections to divert other traffic away from servers to which many connections are clumped.
If you have had difficulty with application timeouts using all of the proven persistence methods you mention, I'd suspect something other than the load balancer ignoring persistence tokens. I see you've looked into the possibility that your monitors are marking pool members down, which is a good start. If you really suspect LTM is the culprit, you'll need to correlate what the server logs with what LTM logs and what is seen in a packet trace or clientside transaction trace to figure out what's really going on. I would open a case with F5 Support once you have some evidence about LTMs misbehaviour, and/or and they can help guide you through that process of collecting & analyzing the information to determine the cause of the session timeouts.
hth
/deb - Lightspeed_VT_5Thanks for your help, deb. We finally have this issue sorted.
cmiskell_16928Hi guys, ive been dealing with a similar issue for about 6 months. We have 2 redundant bigip 4.6 boxes. Basically, as soon as I turn on persistent cookies of any type (insert, rewrite, passive, active, whatever) it causes our page to randomly timeout. it could be every 30 refreshes, or every other, then it wont happen for an hour. The page will hang for 30 to 60 seconds, then finally display.
As soon as I go down to 1 web server with no persistence, or use simple persistence, which i not an option for us, the issue completely goes away. I have had the boxes wiped, we have tried different releases, tried different web server OS (currently debian). Any thoughts would be greatly appreciated. We run a java based app with apache and mysql. I have gone down to very old releases of our application with no luck. Currently, it only seems to be happening in IE7, but its so random that I may be mislead on that. Thanks!
