Forum Discussion

ieflores_38076's avatar
Icon for Nimbostratus rankNimbostratus
Mar 16, 2011

F5 maintains a SSL session opened until 16 seconds after it receives a FIN request

Hi, I´ve configured a basic https monitor with these parameters:



Send string: HEAD / HTTP/1.1\r\nHost: \r\nConnection: close


Receive string: HTTP/1.1



It is working fine, the server is marked up when it is accesible and down when it is not. However, I did a packet capture to analyse the performance of this monitor and I noticed the following: After the F5 receives a FIN request from the server, it (the f5) maintains the session opened for sixteen seconds more, after this time the F5 ack the fin request and closes the connection.



Why is this happening? I mean, Why even though the F5 receives a FIN it waits sixteen seconds to close the session? What I´d like to happen is that the F5 closes the connection once it receives the FIN request, not after sixteen seconds.



Note: the sixteen seconds are not related with the frecuency nor the timeout, I´ve changed these parameters and the issue is the same.

3 Replies

  • Hi,



    Can you open a case with F5 Support on this and report back on what they find?



    Thanks, Aaron
  • Wow, that's a good one. There could be a few things going on here. I'm betting that this is a typical half-close, TIME_WAIT thing but we can't confirm that until we track down the source of that 16 seconds. If I am right, I'd expect to see a MSL of 8 seconds somewhere on the host side of the BigIP, but that seems odd to me somehow. Just to make sure I understand: I would expect the client (BigIP) to send the first FIN here, so are you seeing something like this?



    (C) (S)


    FIN---> close_wait


    fin_wait <--- ACK


    time_wait <---- FIN


    ...16 seconds pass, you go get a beer, etc.


    ACK---> closed



    Is that diagram correct?



    Also, have you by chance tried this with a typical HTTP monitor? Is that monitor HEAD request correct? I'd expect \r\n\r\n at the end to complete it. If you're seeing the FIN come from the server first, I wonder if it's responding to a request that's incomplete (missing the two CRLF), then sending its FIN, at which point there's some timeout on the request side...but I suppose I'd expect a RST in that picture...hmm you got me churning on this one!



    One other note: there's been some debate on RFC 2616 and HTTP connection management regarding how much consideration was given to how TCP does its thing. If you're interested you may want to read through this - not that it's got a solution to this issue but it may be a factor:





    -- and and old but really interesting draft discussing connection management.




    Keep us posted, and more data would be appreciated :)


  • Thanks for the interest Matt.



    First of all I have to say that unfortunately I don´t have the server private key, so I just can see at tcp level in the packet capture, I can´t go deeper into HTML because it´s encrypted. Once cleared this point, I continue:



    Your diagram isn´t ok. The communication is going on some weird, I show you how is the flow:




    (C) (S)


    <------ FIN


    Encrypted Alert------>


    <------ ACK to Encrypted alert



    After 16 seconds



    ------> FIN


    Closed<------ ACK




    As you can see, the first FIN comes from the server side, and I´d expect it because I send a close session instruction into the head request to the server. About the CRLF, I don´t think those are necessary because my BIG IP is on the 10.1.0 version, however I did do some tests adding those character at the end of the request and the issue persists.



    Regarding to the HTTP typical monitor the answer is yes. I´ve tried doing the same request on other different servers and it works perfectly, the F5 closes the session once it receives the FIN request (it doesn´t wait). I can´t do this type of monitor (typical http) in the server that is presenting the issue because it only listens on the port 443.



    Please let me know what kind of information would help you to try to understand/clarify what´s happening.



    Also I´ve tried to do the request manually helped by the command: "openssl s_client -host X.X.X.X -port 443"; when I do this test the communication seems to flow ok. The server closes the connection and the same happens with the F5 without waiting 16 seconds.