F5 session timeouts

Question

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
}

Answer 1

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".

Answer 2

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.