CirrusDo Keep Alives renew Source Persistence table entry
I have found a few articles stating that any packet coming into the F5 on a socket connection will renew the source timeout. A customer has a 3600 tcp timeout and a 4800 source persistence timeout. In the capture i can the tcp keep alives being sent and the return ACK. I would expect the F5 to renew at this point but that doesnt appear to happen. It looks like the source timeout count down begins after the last data packet is passed onto the server. Is this the expected behavior? Because data is not really passing to the server because of the full proxy nature, does the persistence table not refresh?
Ok, I labbed this up today and thought I would share my results. In summary, source persistence is not renewed when using a standard virtual with long live connections and keep alives.
My scenario: I used SSH as the protocol. Standard virtual server with a modified tcp-lan-optimization profile. Modified settings to 300 tcp timeout and changed the keep alive interval to 150. I then created a source persistence profile and set the timeout at 400 seconds. I created the pool and attached all profiles and kicked off a tcp dump and viewed the VS and Source persistence connections from the CLI.
What I found was that the tcp timeout would renew every 150 seconds. This was expected as the timeout interval probe is set to 150 seconds. However, the source persistence for the connection never changed and it eventually timed out after 400 seconds. I suspect this is because of the full proxy nature of the standard virtual server. Each connection on the proxy is simply probing and not really passing traffic through the F5 thus not resetting the source persistence record. This is the confusing piece I was finding on the internet and on Dev Central, there wasnt any clear documentation on how this worked. All docs I found said "any" packet would reset persistence but didnt specify what type of virtuals and configurations might not reset source persistence.
I also tested this with fastl4, this was completely different. The probes actually traversed the F5 and reset source persistence.
In the end, I was able to confirm that this was not a F5 bug and instructed the customer to adjust keep alive intervals on the tcp profile. FYI, fastl4 was not an option because they were offloading ssl.
