Forum Discussion
Deb_Allen_18
Apr 17, 2008Historic F5 Account
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