Forum Discussion

Chris_Lira_5487's avatar
Chris_Lira_5487
Icon for Nimbostratus rankNimbostratus
Oct 16, 2008

idle timeout

In our BIGIP-LTM, the idle timeout is set to 300 seconds. When we run a transaction which takes about 10 minutes, we see a second transaction enter our web/app server after about 5 minutes (so we end up with two transactions running at the same time).

 

 

We think we are seeing a "retry" or a "resubmit" of the HTTP POST from the BIGIP (when we remove the BIGIP, the 2nd POST does not happen). The documentation says the connection will be "reset" after the timeout. Some folks are assuming reset=resubmit. I'm not clear on it.

 

 

Is this true? reset=resubmit of an HTTP POST?

 

10 Replies

  • LTM shouldn't retry a request unless you have an iRule which explicitly resends a request. LTM should send a FIN (or maybe a RST?) when the TCP idle timeout expires. That would instruct the peer in the connection to close the TCP connection. It would not allow for resending the same request unless the client specifically retried the request with interaction from the user.

     

     

    If you capture a tcpdump of the client and server side traffic you should be able to see exactly what's happening. If you want info on capturing/inspecting a tcpdump, you can search for tcpdump on AskF5.com and/or open a case with F5 Support.

     

     

    On another note, does the server actually take 10 minutes or more from the time the last request packet is received to start sending any response packets? If that's true, you should extend the TCP idle timeout to a value higher than that time to ensure LTM doesn't prematurely close the TCP connections.

     

     

    Aaron
  • Yes, the server does actually take 10 minutes or more to start sending responses (long running search query). We have considered extending the TCP idle timeout to a higher value. But we were also exploring using shorter OS level tcp_keepalive(s). We are using AIX. Would that be a better approach?
  • The TCP keepalive option might be better as the server will explicitly send the keepalive when it intends to use the connection. Compare this with having the BIG-IP hold all idle connection table entries for that long.

     

     

    Aaron
  • we did this and it worked great. we set tcp_keepidle on AIX to 4.5 minutes and the BIGIP was happy to keep the connection open. We also found that the connection was kept open from the Windows PC to the BIGIP. That was a surprise. Is that because the BIGIP is sending the heartbeat ALL THE WAY back to the PC??

     

     

    So we have PC->BIGIP->WEB and we set the tcp_keepidle on the WEB AIX box ONLY and it seemed to work fine. So we assumed the BIGIP sent the heartbeat all the way back to the PC to keep that connection open.

     

     

    Make sense?
  • If the server sends a packet to LTM, LTM will proxy it back to the client. So what you're describing would be expected.

     

     

    Aaron
  • Hello, where can I configure the idle time out to increase it´s value in the BIGIP-LTM.
  • Hi Lalo,

     

     

    See SOL7606 for details on the various timeouts and how to modify them:

     

     

    sol7606: Overview of BIG-IP idle session timeouts

     

    http://support.f5.com/kb/en-us/solutions/public/7000/600/sol7606.html

     

     

    Aaron
  • Hi all,

     

     

    Few days ago the LB in my network had memory leak. refer to f5 documentations,to decrease the consume system memory, i must setting the idle timeouts as small as possible. so i set the idle timeouts from 300 sec (default) to 60 sec. after i set to 60 sec, memory doesn't leak again. My question, is there any impact on the system by changing the idle timeouts (long term impact) ? for information, the CPU before and after changing the idle timeouts doesn't give big difference.

     

     

     

    rgds,

     

    cindy
  • for applications that do not require long-lived connections, idle timeout should be kept low. For other things, like telnet, ssh, rdp, etc, it makes sense to give users time to look away from their screen without killing their sessions (assuming app keepalives are not configured, if they are, and you control them, you can set the idle timeout to just a few seconds greater than the configured keepalive interval)