Forum Discussion
mikeshimkus_111
Historic F5 Account
Hi jbs, which timeout is set to 4 hours? Is it the TCP idle timeout, or the source persistence timeout? By default, the iApp sets both to 20 minutes.
It sounds like the persistence timeout may be too short, causing your client to reconnect to AB or EWS to a different pool member.
We'll do some testing here and let you know what we find out.
thanks
Mike
jbs_132130
Oct 01, 2013Nimbostratus
Mike - thanks for the responses and sorry for the delayed response - never enough time/staff especially at the beginning of a higher ed semester - so the resolution involved: upgrading iApp, changing persistence values (syncing), removing SNAT (so we could actually capture individual sessions that were experiencing the issue on both interfaces of the F5, the client, and the CAS server)
Once things calm down we will open a new case since part of our resolution (to follow) required disabling strictness:
From our Network Engineer (9/3):
"there have been a number of problems related to the Citrix to F5 move for Exchange. Some issues were resolved by upgrading to the latest iApp a few weeks ago. Some other issues were resolved by increasing the persistence and idle-connection timer on the respective profiles and keeping them in-sync with one another (4 hours).
However, there is some configuration mystery on the F5. When you go to
change the idle-connection timer, either (1) it does not really get changed, or (2) there is some other timer that uses TCP Keepalive misses as the actual trigger for killing off idle sessions.
On the wire, it appears that the F5 will send a TCP Keepalive once every
30 minutes for these types of services, both to the client as well as the
server. If a Keepalive test does not receive a response after 3
iterations (2 hours), the F5 will timeout the connection and send TCP
RSTs to both the client and server. Since the Address Book application
is NOT chatty, it is clearly evident that a user will experience a timeout under such conditions when the client is not routinely used.
The problem is that the Juniper SRX has a default idle TCP connection timer of 30
minutes as well. Packet traces indicate that the SRX would time out the
TCP connection first, thereby preventing the TCP Keeaplive from the F5
from reaching the client. This set in motion the basic problem.
Increasing the SRX idle connection timer to 2 hours eliminates this problem for SecureNet users, which appears to be the last set of users that were having repetitive problems with the Exchange Address Book.
Further discussion with F5 is needed to figure out if this timer mechanism is either a different animal from the "idle" timeout configuration parameter in the configuration, or if the "idle" timeout config parameter is being somehow ignored or overwritten by something else."
Thanks again - as always tcpdump saves the day and networks with many network devices always need all of the devices considered as a source/part of an issue - the perfect storm? ....
J