Forum Discussion
AltocumulusTCP-timeout question
Hey guys, Got an interesting (to me anyway) question. I have a user with an application that does long queries that run in the background. It was timing out and so I created a new TCP profile for it and lowered the keep alive value to just below the idle timeout and that fixed it. However, now he is complaining about an application timer which is based on the idle timeout built into the application of an hour. This no longer works because the keep alive never lets the connection age. I guess my question is sort of a several part thing. First I made an assumption in my head that making the TCP timeout long like 15-20 minutes to allow the job to finish is bad from a security point of view. Thinking someone could use up all the connections in a DOS type of attack and those connections would never timeout. First, is that right and second is a keep alive pretty much the same? I guess third, is there a way to write an Irule that does like 3 keep alives and then lets it die or some other best way to handle it. As always, Thanks for the help! Joe
Simon_BlakelyEmployee
First I made an assumption in my head that making the TCP timeout long like 15-20 minutes to allow the job to finish is bad from a security point of view. Thinking someone could use up all the connections in a DOS type of attack and those connections would never timeout. First, is that right and second is a keep alive pretty much the same?
It depends on the application. Long TCP timeouts do create entries in the connection table that sit for a long time. And yes - this can be abused to DoS a service. However, the LTM has an idle reaper - if the connection table memory reaches over 80%, the connection reaper kicks in and starts deleting the connections that have been idle the longest.
Keepalives keep resetting the idle timer, so the reaper has a harder job finding the oldest idle connection and is more likely to delete an active connection.I guess third, is there a way to write an Irule that does like 3 keep alives and then lets it die or some other best way to handle it.
There is no irule command to send a TCP keepalive. I'd recommend removing the keepalive (as it interferes with the application) and shift to a longer TCP idle timeout. I suspect that will address the application issues. As long as the tcp profile is limited to the specific application, you will probably be not have any issues.
- Hannes_Rapp
Nimbostratus
Indeed, long idle timeouts aren't a good idea.
What BigIP features you use for this application? If it's just routing/balancing, maybe you could apply a FastL4 profile instead of TCP profile to your Virtual Server? If that's an option, I could recommend some custom settings to make F5 behave similar to a stateless router. This would be ideal, but will not work if you use HTTP-aware iRules or AFM module to deliver this application via BigIP.
sundogbrewThank you guys for the responses. I think there is an interest in more Irule use, so I may go with the longer timeout. Thanks for the info about the connection reaper. I knew it did this to some extent but it is good to know I am actually keeping it from working by changing the keep alive. I will change my timeout and keep an eye on it. Thank you guys as always!
Stanislas_Piro2Cumulonimbus
You can try to detect if the request requires long timeout (filter by a HTTP header, URI, ...) and change the timeout.
when HTTP_REQUEST { if {[HTTP::host] equals "www.company.com" && [HTTP::path] equals "/long_time_request"} { TCP::idletime 1800 } } when HTTP_RESPONSE { set the timeout to 30 seconds after server response to prevent DOS abuse. TCP::idletime 30 }In 16.1 there will be an iRule
