How to Implement a keepAlive Client-Side Connection

The issue most likely is that the LTM has a 5 min TCP timeout. Once this has been reached the unit sends a reset packet too both sides of the connection. You can increase this time out though I would not set it to infinite. You can also set up TCP-keep alive to keep traffic flowing over the session and the LTM will not kill the session.

 

 

The main question is how long does the server need to respond to the clients request? If it is a set amount the best way would be to increase the TCP timeout to be a little above that amount.

just wondering if keep-alive setting in tcp profile does not help.

 

 

sol8049: Implementing TCP Keep-Alives for server-client communication using TCP profiles

 

http://support.f5.com/kb/en-us/solutions/public/8000/000/sol8049.html

it might, but why send the extra traffic? just increase the tcp timeout as richard suggests seems more logical.

In that case the server has to send the TCP Keep alive, the LTM will not send a TCP keep-alive. With the profile setting set the LTM will not just ACK the Keep-Alive it will also send the keep-alive to the client keeping the client connection open. So the server will have to send the Keep-alive then set the profile setting and the LTM will proxy the keep-alive to the client.

 

it might, but why send the extra traffic? just increase the tcp timeout as richard suggests seems more logical.i think it holds memory and how we know if timeout value is long enough.

In that case the server has to send the TCP Keep alive, the LTM will not send a TCP keep-alive.i do not think so.

sol7559: Overview of the TCP profile

http://support.f5.com/kb/en-us/solutions/public/7000/500/sol7559.html

[root@ve10:Active] config  b virtual bar list
virtual bar {
   pool foo
   destination 172.28.19.79:22
   ip protocol 6
   profiles {
      tcp3s {
         serverside
      }
      tcp5s {
         clientside
      }
   }
}
[root@ve10:Active] config  b pool foo list
pool foo {
   members 200.200.200.101:22 {}
}
[root@ve10:Active] config  b profile tcp3s list
profile tcp tcp3s {
   defaults from tcp
   keep alive interval 3
}
[root@ve10:Active] config  b profile tcp5s list
profile tcp tcp5s {
   defaults from tcp
   keep alive interval 5
}

 clientside
[root@ve10:Active] config  tcpdump -nni external not host 172.28.19.80 and port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on external, link-type EN10MB (Ethernet), capture size 108 bytes
23:34:23.165953 IP 172.28.19.79.22 > 172.18.205.120.21508: . ack 3549108548 win 32768
23:34:23.209586 IP 172.18.205.120.21508 > 172.28.19.79.22: . ack 1 win 254
23:34:28.209680 IP 172.28.19.79.22 > 172.18.205.120.21508: . ack 1 win 32768
23:34:28.254657 IP 172.18.205.120.21508 > 172.28.19.79.22: . ack 1 win 254
23:34:33.254961 IP 172.28.19.79.22 > 172.18.205.120.21508: . ack 1 win 32768
23:34:33.297428 IP 172.18.205.120.21508 > 172.28.19.79.22: . ack 1 win 254

 serverside
[root@ve10:Active] config  tcpdump -nni internal not host 172.28.19.80 and port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on internal, link-type EN10MB (Ethernet), capture size 108 bytes
23:35:01.613940 IP 172.18.205.120.21508 > 200.200.200.101.22: . ack 4072446330 win 32768
23:35:01.615544 IP 200.200.200.101.22 > 172.18.205.120.21508: . ack 1 win 80
23:35:04.615892 IP 172.18.205.120.21508 > 200.200.200.101.22: . ack 1 win 32768
23:35:04.617456 IP 200.200.200.101.22 > 172.18.205.120.21508: . ack 1 win 80
23:35:07.617801 IP 172.18.205.120.21508 > 200.200.200.101.22: . ack 1 win 32768
23:35:07.619647 IP 200.200.200.101.22 > 172.18.205.120.21508: . ack 1 win 80

As Nitass said, keep-alives do make sense in this scenario so that the connection is kept open via the server's keep-alives for as long as it takes to send the response. If you only extend the TCP idle timeout on LTM, you'd eat up more memory for all connections that aren't closed cleanly.

 

 

Aaron

In the long run as long as you set your TCP time out not to infinite you will reclaim the memory. With TCP timeout there are cases where it is possible that you will not close the connection. The Acking of data is a TCP function not a Application function. There are many cases were the Application will go off into space but the TCP stack will still open connection and ack data. So the memory question can be a wash. The only connection that are left in memory are the one that drop off the network and do not close the connection down and they are cleaned up when the timeout run. With keep-alives you have the chance of a connection not shunting down as long at the client and server respond.

 

 

You will also find that if tcp keep-alives are two aggressive you will lose valid connections. If you think from a cell perspective if the client loses connectivity then regains it it can keep the TCP session open. But with aggressive keep alive the LTM can reset the connection causing the provider to request the again. After 8 missed Ack packets the LTM will drop the connection. With flaky coverage and dropped packets on the internet it would not be hard to lose 8 packets if you say update a route between the user and the server due to a outage.

 

 

From a DDos prospective you are opening up more from increasing from 5 min to 10 min. But with Deferred Accept you can help mitigate a SYN-flood and force the client to complete the three way handshake.

 

 

My rule of thumb for the most part is the Firewall idle timeout +1. Or if the LTM is the firewall then what ever the firewall timeout would be. Again that is just how I roll. Over all I am just saying there is no one size fits all solution just one that works best in you network.

 

 

Sorry Natass, it looks like I was wrong with reading the docs.