Forum Discussion
Peter_Lowdon
Altocumulus
AltocumulusSo 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
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.
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
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.
