Archive

Archive for March 6th, 2015

Case Study: F5 Load Balancer and TCP Idle Timer / fastL4 Profile

March 6th, 2015 No comments

This describes a problem whereby a client connects to a server then waits for a report to complete before retrieving it.  The report took longer than 5 minutes to complete and the TCP session remained idle whilst the client waited.  After a while the TCP connection dropped.

Packet traces were taken at the client, server and intermediate points, which included an F5 load balancer which simply acted as a router. The analysis of the packet traces revealed some interesting things..

What was happening was that the TCP 3-way handshake completed to setup the TCP session.  Then the client sends an HTTP GET requestor method (of TCP segment length 734 bytes) to submit the data, which is then received by a client-side firewall.  The firewall then forwards it onwards towards the server in the direction of an F5 load balancer …

BUT: The HTTP GET doesn’t seem to arrive at the F5.  The server-side firewall however, DID receive the GET and forwards it onto the application server, which then sends back an ACK to the client – which DOES go via the F5. Huh?

It was initially thought that the The F5 therefore saw an ACK packet for a TCP segment that it hasn’t seen, so it sends a RST packet in both directions to tear down the TCP session. This is a little confusing because the TCP session goes through the F5 but the HTTP GET request seemingly bypasses the F5 but does arrive at the server. After a bit of head-scratching and furrowed brows because it made no sense.  The delay. The fact that there clearly wasn’t any asymmetry anyway because the ACK came back via the same path. So why the reset? Read more…

Categories: linux Tags: