Forum Discussion

What_Lies_Bene1's avatar
What_Lies_Bene1
Icon for Cirrostratus rankCirrostratus
Aug 08, 2014

Monitor Timeouts

Hi all, I have more monitor questions. I promise not to mention Administrative Partitions ;-)

 

1) Lets say my timeout is 16s. Probe 1 is sent at 0s, probe 2 at 5s. Before probe 3 is sent at 10s a response is received for probe 1 at 9s. The Timeout is reset to zero right? So, with default values one response can keep a Node up for 31s?

 

2) What if a response is sent to probe 1 again at 9s, the Timeout is reset to zero. Then probe 2 at 5s response at 10s, will this also set the Timeout back to zero or, because it was sent during a different Timeout period, is the response ignored?

 

See the attached diagram for a visual representation which makes it all pretty clear (I hope) - red is a probe with no response, green is a probe that is responded to.

 

 

Thanks

 

application delivery
availability
LTM
management

3 Replies

Sort By
  • Mike_Kahler_488's avatar
    Mike_Kahler_488
    Historic F5 Account
    Aug 08, 2014

    I am assuming you are discussing HTTP type monitors. I haven't tested this since 10.x. But I will assume 11.x is the same. For interval/timeout, it appears the LTM does something every interval no matter if the health check passes or fails. Here are some notes I took when testing. For failure testing, I just ran netcat on my server to listen but not respond to any HTTP queries.

     

    The interval takes effect whenever an HTTP health monitor connects to the pool member. This behavior is different if the health monitor passes or fails. For a passing monitor, the successful GET will close the connection and mark the pool member up. The LTM will then use the interval timer to establish a new connection. For the default interval/timeout 5/16, the health monitor may invoke a new connection and GET around every 5 seconds.

     

    For a failed monitor, the LTM will establish a connection to the pool member and send up to 4 GET's, per the interval set, before closing the connection. If, after 4 GET's, the timeout has not been met, the LTM will establish a new connection and will continue this behavior until the timeout has been exceeded. At that time the LTM will mark a pool member down.

     

    Hope this helps

     

    • What_Lies_Bene1's avatar
      What_Lies_Bene1
      Icon for Cirrostratus rankCirrostratus
      Aug 11, 2014
      Hey Mike, thanks for your response, yes, HTTP in this instance. I'm sure I'd come across this very same text in response to a similar question answered by you and the detail is appreciated. However, it does not answer either of my questions. Do you have a view please?
  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus
    Aug 09, 2014

    As I understand it, the timeout period starts as the first probe is sent out. If the probe succeeds right away, the timeout period is over, the pool member is marked as up, and a new generic "interval" period, or an "up" interval if defined, starts.

     

    If the first probe fails right away, a second probe is sent after the defined generic interval; if the first probe hangs, a second probe is also sent after the defined interval period. More probes are sent in this way until the defined timeout period is over, at which time the system will kill all existing connections used by the probes and mark the pool member down.

     

    It would be good if somebody from F5 can confirm / deny this is how it works, and in the latter case, provide a detailed description.