Forum Discussion

Peter_Lowdon's avatar
Peter_Lowdon
Icon for Altocumulus rankAltocumulus
Sep 07, 2020
Solved

So basically health monitors which actually monitor downstream virtual servers on another f5 LTM don't seem to work?

hi f5'ers,

 

I've got a weird situation here, wondered if anyone has come across it before.

 

We have an f5 LTM with some simple load balanced web services, we call this our Tier 2 f5 LTM. Traffic from this LTM is forwarded to another f5 LTM where we have more indepth request analysis going on, we call this the Tier 3 f5 LTM.

 

We have an in-band health monitor on the Tier 2 f5 LTM which checks requests being forwarded to the Tier 3 f5 LTM BUT we have noticed that even if we force the Tier 3 f5 LTM pool members offline so that the Tier 3 f5 LTM virtual servers are red the Tier 2 f5 LTM health monitor doesn't seem to notice and will continue to try and forward traffic even though every request fails and at no point does that pool member become red on the Tier 2 f5 LTM.

 

So basically health monitors which actually monitor downstream virtual servers on another f5 LTM don't seem to work?

 

Anyone come across this before?

 

Thanks,

Peter

application delivery
BIG-IP
LTM
monitor in-band
  • crodriguez's avatar
    crodriguez
    Sep 08, 2020

    I think what you are running up against is simply the way the inband monitor works. My understanding is that the inband monitor relies upon multiple attempts to connect to the pool member failing over some period of time, as defined in the inband monitor settings. In other words, it's looking for a RST in response to a SYN. Because your Tier 2 pool members are actually Tier 3 virtual servers, it would appear the 3WHS actually succeeds before a RST is sent by the Tier 3 virtual server, even though it has no available pool members. I was able to confirm this behavior with TCPDUMP.

     

    If this is all web traffic, have you considered switching to an HTTP-type monitor - even the default http monitor, rather than use the inband monitor? The HTTP monitor should mark the Tier 2 pool member down when the associated Tier 3 virtual server is also down, as there is no HTTP response.

2 Replies

Sort By
  • crodriguez's avatar
    crodriguez
    Ret. Employee
    Sep 08, 2020

    I think what you are running up against is simply the way the inband monitor works. My understanding is that the inband monitor relies upon multiple attempts to connect to the pool member failing over some period of time, as defined in the inband monitor settings. In other words, it's looking for a RST in response to a SYN. Because your Tier 2 pool members are actually Tier 3 virtual servers, it would appear the 3WHS actually succeeds before a RST is sent by the Tier 3 virtual server, even though it has no available pool members. I was able to confirm this behavior with TCPDUMP.

     

    If this is all web traffic, have you considered switching to an HTTP-type monitor - even the default http monitor, rather than use the inband monitor? The HTTP monitor should mark the Tier 2 pool member down when the associated Tier 3 virtual server is also down, as there is no HTTP response.

    • Peter_Lowdon's avatar
      Peter_Lowdon
      Icon for Altocumulus rankAltocumulus
      Sep 14, 2020

      hi, thanks for you reply. It was a combination of two things, a school boy error of not setting the Action On Service Down to "reject" and as you pointed out the custom inband health monitor settings we have combined with our application deployment meant we weren't sending enough requests to trigger the monitor to mark the pool members down. It was one of those head scratchers that makes no sense at the time but with hindsight makes perfect sense.