Our F5 load balancers run version 10.2.4. We migrated from Cisco load balancer cards on the Catalyst 6500 and used to be able to run xterm sessions to our solaris and linux servers without the sessions dying after 15 minutes.

Our boss is afraid of raising the 900 second number in our F5 tcp profile, because at another company he was at they did this and it exhausted all the resources in the F5 from hung connections.

Is there another way to keep the sessions from resetting without changing the timeout? This is our config

profile fastL4 fwd_fastL4_15m {
  defaults from fastL4
  idle timeout 900

virtual route_outbound {
  destination any:any
  mask none
  ip forward
  profile fwd_fastL4_15m
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Dec 20, 2020 at 2:33

2 Answers 2


Is there another way to keep the sessions from resetting without changing the timeout?

You already mentioned that keepalives were not used on your old Cisco load-balancer, so I will focus on what you can do with the F5.

There are two problems you need to solve...

  • The F5 sends a reset to the client when the TCP session expires from the state table
  • The F5 removes the TCP session after it expires

Those two issues seem related, but they have different solutions on the F5.

Solving TCP Resets:

F5 resets timed-out TCP sessions by default. You can disable that behavior with reset on timeout disable inside your TCP profile. However, all this does is keep the F5 from resetting the client connection, but the session will still be expired from the F5's state table the next time someone takes a break for a couple of hours, and then moves the mouse pointer again in the xterm.

Solving Session expiration inside the F5:

Use loose initiation enable in your TCP profile. loose initiation allows the F5 to create an entry in the TCP state table whenever it sees an unknown TCP packet. As long as these connections are trusted, and inside your company, there is no problem turning loose initiation on.

Essentially, loose initiation makes the F5 behave more like a router than a load-balancer, which is what you need in this situation. xterm sessions create a TCP socket sourced from TCP/6000 to the client. In this case, you aren't load-balancing the xterm sessions anyway.

Final solution:

Your final profile should look like this...

profile fastL4 fwd_fastL4_5m_loose {
  defaults from fastL4
  reset on timeout disable
  idle timeout 300
  loose initiation enable
virtual route_outbound {
  destination any:any
  mask none
  ip forward
  profile fwd_fastL4_5m_loose

Technically, you can change the timeout from 900 seconds to 300 seconds, since you're enabling loose session initiation on the route_outbound service. F5 Solution Document 7595 is a good reference for forwarding virtual server configurations like this... see the section titled, "Emulating stateless IP routing with BIG-IP LTM forwarding virtual servers".


For term sessions, I believe the best option is to use app or OS keepalives to maintain the connection through the SLB which allows you to keep your idle timeout where you want it.

This is app and OS dependent. See Keep Your Linux SSH Session From Disconnecting as one method that may work.

The concern of your manager in raising the idle timeout is highly subjective. The typical flow rate (conn/sec) and idle durations between your environment and his last could be vastly different. If your flow rate or idle durations are much lower, you could afford to increase the timeout. You'll need to zero into flow capacity, what you have free, and how quickly you cycle through them.

The CSM's default idle timeout is 3600. Same for the ACE for idle TCP connections.

  • I suggested that. The development team keeps asking me why they did not need to turn on Exceed keep alives when they used the Cisco load balancer. Do you know why? They say this is a problem with our F5.
    – user2561
    Sep 12, 2013 at 8:38
  • @user2561 were you using the CSM (or ACE Module)? [I just finished resolving an issue with the Cisco CSS whose default idle flow timeout is a mere 16 secs, so you're already better off than I was with 900!] Sep 12, 2013 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.