HTTP timeouts help

Hi,

 

This post has details:

 

 

 

http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=19455&ptarget=19509

 

 

interval: how often in seconds to send a request

 

 

timeout: how long to wait for a successful response before marking the member down

 

 

By default, these values are set to interval and timeout of 5 sec and 16 seconds (timeout = 3 x interval + 1). So the monitoring daemon starts a timer equal to the value of the timeout. It will send a request every five seconds--the length of the interval. When it receives a successful response, the countdown is reset to the timeout value. In this scenario, the node basically has three chances to respond before being marked down. Requests are still sent every interval even when the node is marked down. This allows for automatic resumption of use of the node when it responds correctly to a request. If you want to keep the node marked down even after it responds again, you can enable 'manual resume'.

 

 

If you want to give the node more chances to respond before marking it down, you could extend the timeout length. Setting the interval and timeout to 5 and 31 would mean the node would get sent six requests before being marked down.

 

 

 

 

The default monitors can be viewed/modified under Local Traffic >> Monitors. The default HTTP monitor sends an HTTP v0.9 request and does not check the response. Any data that the member sends will be considered a successful response.

 

 

You can send an HTTP 1.1 formatted request and check the response for a string using a send string like:

 

 

GET /monitor.html HTTP/1.1\r\nHost: \r\nConnection: Close\r\n

 

 

And a receive string of:

 

 

HTTP 200

 

 

The advantage of this is that you're telling the server it can close the TCP connection immediately after sending the response. And with a receive string, you're verifying the pool member sends an HTTP 200 in response.

 

 

You can get a lot more detail in the LTM Config Guide for your version on AskF5.com.

 

 

Aaron

Hi Aaron,

 

 

Thanks for the super quick reply. I did check out the post above but what I'd like to understand is if the BigIp is waiting the full 5-16 seconds for the response to come back and then restart the timer. Or, is the BigIP marking the first check as failed after 1 second and they trying again in 4 seconds time.

 

 

Does this makes sense?

Ah, I missed that. For a standard monitor, I believe that bigd will accept any response within the timeout period. For external monitors, I think each new request invalidates any previous request. Can anyone else confirm this?

 

 

Aaron

There are various caveats depending on version and monitor type, but what you have is basically true: a single success in the timeout period is enough to keep the node up.

Hi,

 

 

I seem to be having issues with the HTTP timeouts also. Basically, I have a custom Monitor setup on my GTM with the following parameters:

 

 

Interval: 15

 

Timeout: 81

 

Probe Timeout: 5

 

 

So I would expect that the probe would run every 15 seconds, and that 5 consecutive probes would need to be missed before the Server was marked as down (5 x 15 = 75 + 5 for the probe timeout).

 

 

However, when I tested this, the GTM was correctly sending Probes every 15 seconds, but the Server was marked as down after the first missed probe.

 

 

Am I missing something? GTM version is 9.4.7.

I'm seeing the same with GTM 10.1.

 

 

Timeouts for custom monitor are default: 30 sec interval, 120 sec timeout, 5 sec probe-interval.

 

 

This monitor is configured to probe a host that is not reachable at all.

 

 

T0 = when I enable the host, which is a virtual server.

 

 

tcpdump shows a syn go out at T0, then at T0+5sec, /var/log/gtm shows the virtual server go from blue to red.

 

 

So what gives? Seems like only the Interval and Probe-Timout values are actually referenced.

 

 

"timeout" is never used at all, from what I'm seeing.

 

 

 

Another bit of info:

 

I adjusted both up and downward the interval and probe-timeout values in my custom http monitor. Neither change actually has an impact on the probing of this test virtual server. Tcpdump shows that probes always occur at 30 seconds, and /var/log/gtm continues to show the VS turns red at T0+5sec.

 

 

Any thoughts?

 

 

thanks much!