Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology

Wrong monitor interval, but not failing

I was upgrading software on a box I was unfamiliar with. When rebooting, I discovered what I consider a misconfiguration in one of the monitors. I has interval 1200 and timeout 16.

The behaviour I expected here was that the monitor would take 1200 seconds to come up, then go down after 16 seconds, and stay down until the next 1200 seconds came around.

The behaviour I am seeing is it takes 1200 seconds to come up, but then stays up.

Can anyone explain this?

ltm monitor https Monitor_xxx-HTTPS {
    adaptive disabled
    cipherlist DEFAULT:+SHA:+3DES:+kEDH
    compatibility enabled
    defaults-from https
    destination *:*
    interval 1200
    ip-dscp 0
    password $M$xxxxxxxxxxxxxxxxxxxx==
    recv active
    recv-disable none
    send "GET /testpage HTTP/1.1\r\nUser-agent: F5Monitor\r\nHost: xxx.yyy.com"
    time-until-up 0
    timeout 16
    username f5monitor@yyy.com
Rate this Question
Comments on this Question
Comment made 08-Mar-2018 by uni 1155

Oh, and it is v12.1.3

Comment made 08-Mar-2018 by S Blakely

The monitor issues a status check every 1200 seconds. If a status check does not get an OK response within 16 seconds, it will be marked down.

If the first check attempt fails to get a response before the timeout period (16 seconds), the member is marked down.

The next check will be 1184 (1200-16) seconds after the pool is marked down. If the pool member responds within 16 seconds, then the member will be marked up and will stay marked up until the next check 1200 seconds later.

Is that clear?


Answers to this Question


The monitor times out after 16 seconds if unsuccessful, and will not try again until after 1200 seconds, making it, effectively, ineffective in catching a service status change soon enough.

The settings should probably be returned to the default:

  • Interval: 5 seconds;

  • Timeout: 16 seconds.

as it is hardly normal for the monitor to take 1200 seconds to receive a response, and the timeout value should be 3 times the interval as recommended by F5.


Comments on this Answer
Comment made 08-Mar-2018 by rob_carr 1607

I don't think this explanation really works in this situation. The 16 second value doesn't refer to the allowed time for a specific monitor attempt, it refers to needing any monitor attempt to succeed within 16 seconds.

This sounds like a bug to me, where the monitor configuration should not have allowed setting the interval to something greater than the interval.

Comment made 08-Mar-2018 by Jie 2732

The monitor will be terminated at the end of 16th second, during which attempts will be made at the defined interval. In this case, the monitor will be no second attempt if the first one fails.

Comment made 08-Mar-2018 by uni 1155

My understanding has always been that the requests are sent every interval seconds, and there must be a response every timeout seconds - like they're two independent processes. I agree with rob_carr, interval should not be allowed to be greater than timeout

Comment made 08-Mar-2018 by Jie 2732

There are both success/failure situations where this "interval" configuration is involved. See https://devcentral.f5.com/questions/monitor-settings-interval-timeout-etc.

I can see a case in which the interval period could be greater than the timeout period,i.e. when you want the monitor to close the connection and mark the service down upon the failure of the very first attempt.

Comment made 08-Mar-2018 by uni 1155

hoolio's explanation in Jie's link matches my understanding, and fails to explain the behaviour I'm seeing.

Comment made 08-Mar-2018 by Jie 2732

The behaviour I am seeing is it takes 1200 seconds to come up, but then stays up.

Even when the pool member is down?

Could it be that it took 1200 seconds before the monitor starts to probe again?