Help with IP::idle_timeout

Hi Doug,

You'd want to update the client and serverside idle timeouts if you expect the server to take longer than the default idle timeout to respond. This should ensure that neither the client or server side connections are closed prematurely.

Here is an example which shows how to do both:

when HTTP_REQUEST {
   if {$some_condition == 1}{
      log local0. "original timeout: [IP::idle_timeout]"
   
      IP::idle_timeout 1801
      log local0. "updated timeout: [IP::idle_timeout]"
      set update_serverside_idle_timeout 1
   }
}
when SERVER_CONNECTED {
   log local0. "original timeout: [IP::idle_timeout]"
   if {$update_serverside_idle_timeout}{
      IP::idle_timeout 1802
      log local0. "updated timeout: [IP::idle_timeout]"
   }
}

You can check the ltm log for the log output to see that the rule triggered.

idle_timeout_rule : original timeout: 300

idle_timeout_rule : updated timeout: 1801

idle_timeout_rule : original timeout: 300

idle_timeout_rule : updated timeout: 1802

And you can check the b conn output for your client IP to see the idle timeout.

b conn client 10.0.0.10 show all

VIRTUAL 2.2.2.2:http <-> NODE any6:any

CLIENTSIDE 10.0.0.10:4161 <-> 2.2.2.2:http

(pkts,bits) in = (2, 960), out = (1, 528)

SERVERSIDE 2.2.2.3:4409 <-> 3.3.3.3:80

(pkts,bits) in = (3, 4952), out = (4, 2440)

PROTOCOL tcp UNIT 1 IDLE 58 (1802) LASTHOP 4093 00:00:00:e2:1a:2e

As a test, I set the client and serverside timeouts to different values. When checking the timeout listed in the 'b conn' output it looks like the timeout (listed after the idle count in parens) is set to the timeout of the current connection context. ie, once a clientside connection is established, the timeout listed in the 'b conn' output is the client side timeout. Once the serverside connection is established, the timeout listed is the serverside timeout. I wasn't able to figure out how to list both the client and serverside timeouts. The b conn help output indicates you can use 'b conn client x idle timeout show', but this didn't return the idle timeouts on 9.2.4. I guess that the shorter of the two timeouts is the one that is used, as the second connections would probably be closed if the first is timed out.

Aaron