FIN/ACK sent by server, after a TCP KEEP alive ACK in F5 LTM load balancer
No. Time Source Destination Protocol Info
280 2014-05-27 15:37:20 6.6.6.6 1.1.1.1 TCP [TCP Keep-Alive] 9041 > 57703 [ACK] Seq=2629992488 Ack=144158763 Win=65535 Len=0
No. Time Source Destination Protocol Info
281 2014-05-27 15:37:20 3.3.3.3 2.2.2.2 TCP [TCP Keep-Alive] 57703 > 9041 [ACK] Seq=380327577 Ack=1111550497 Win=65535 Len=0
No. Time Source Destination Protocol Info
282 2014-05-27 15:37:20 2.2.2.2 3.3.3.3 TCP [TCP Window Update] 9041 > 57703 [ACK] Seq=1111550497 Ack=380327578 Win=46 Len=0
No. Time Source Destination Protocol Info
283 2014-05-27 15:37:20 1.1.1.1 6.6.6.6 TCP [TCP Keep-Alive ACK] 57703 > 9041 [ACK] Seq=144158763 Ack=2629992489 Win=68 Len=0
No. Time Source Destination Protocol Info
284 2014-05-27 15:37:22 2.2.2.2 3.3.3.3 TCP 9041 > 57703 [FIN, ACK] Seq=1111550497 Ack=380327578 Win=46 Len=0
No. Time Source Destination Protocol Info
285 2014-05-27 15:37:22 3.3.3.3 2.2.2.2 TCP 57703 > 9041 [ACK] Seq=380327578 Ack=1111550498 Win=4380 Len=0
No. Time Source Destination Protocol Info
286 2014-05-27 15:37:22 6.6.6.6 1.1.1.1 TCP 9041 > 57703 [FIN, ACK] Seq=2629992489 Ack=144158763 Win=3780 Len=0
No. Time Source Destination Protocol Info
287 2014-05-27 15:37:22 1.1.1.1 6.6.6.6 TCP 57703 > 9041 [ACK] Seq=144158763 Ack=2629992490 Win=68 Len=0
No. Time Source Destination Protocol Info
288 2014-05-27 15:37:22 1.1.1.1 6.6.6.6 TCP 57703 > 9041 [FIN, ACK] Seq=144158763 Ack=2629992490 Win=68 Len=0
No. Time Source Destination Protocol Info
289 2014-05-27 15:37:22 6.6.6.6 1.1.1.1 TCP 9041 > 57703 [ACK] Seq=2629992490 Ack=144158764 Win=3780 Len=0
6.6.6.6---VIP
2.2.2.2---Pool member
3.3.3.3---snat
1.1.1.1---client
asked 29 May '14, 01:17
Aneshk
1●1●1●1
accept rate: 0%
edited 29 May '14, 02:34
Kurt Knochner ♦
24.8k●10●39●237
The Server that sends the FIN/ACK in response to the ACK is listening on a HTTPS port
what is your question?
I also manage F5 load-balancers, so I look at traces like this quite often. I don't see much of interest in the data you have chosen to include. There's no TCP data transmitted - basically the connection is idle. The Server sends an ACK with a larger window in #282 in response to a keepalive packet sent by the LTM in #281. Then both clientside and serverside connection sits idle for two seconds, until the Server begins closing the connection by sending a FIN packet to the LTM in #284. The rest of the packets are just artifacts of the connection being gracefully closed on both sides of the LTM.
So I'd agree with Kurt here - what exactly is your question?
If the question is why does the Server begin closing the connection in #284, my guess is that either the TCP stack is configured to close connections after two seconds of idle time, or that the application layer has finished processing all the TCP data and has triggered the TCP stack to close the connection.
i started seeing this behavior of the server closing the connection, right after i set the keep alive interval for 60 seonds, that is the connection is removed from the connection table after 60 seconds, My question is whether the server closing the connection in response to the keep-alive sent by the load balancer
No, I don't think so - at least not directly. It's difficult to tell what is happening since you've only included the final few segments of the TCP stream. And you didn't state what the original keepalive interval was (was it larger or smaller?). But my initial thought is that by adjusting the down, you are forcing the Server to process more or less keepalive packets. Perhaps you have caused the the Server to reach a limit imposed on its TCP stack to process a certain number of these packets.
If Keepalives are really at the heart of this issue, then I think we'd need to see all of the keepalive packets which means you'd need to provide the entire trace. You can upload one to cloudshark.org and provide a link if you want some additional insight from me.