GTM health monitor fails on pool, but not on member.

Shaggy is correct. GTM will not be able to automatically associate a GTM VS with a LTM VS if both the name and IP:port are different. However you can manually assign a LTM VS to a GTM VS if required using tmsh.

modify gtm server  virtual-servers modify {  { ltm-name /Common/ }}

my apologies if the following is overkill - just want to lay out some iquery functionality that is often vague in documentation and misunderstood until you have to dig in:

regarding the earlier comment "This GTM does communicate with LTMs using iquery, however the GTM does not use that data. All server/member/node objects in the GTM are added manually."

iquery is used between GTM/LTM not only to autodiscover LTM virtual servers and monitor health of the F5 devices, but also to pass on health status of virtual servers from the LTM on which a vs is configured to a GTM that is configured with that vs as a GTM vs object, regardless of whether the server object was manually added or autodiscovered - if a GTM vs was manually added to the LTM server object and a bigip monitor is assigned to that server object, the GTM will ascertain the vs status via its iquery connection from that LTM.

when a specific non-bigip monitor is assigned to a GTM pool/member/server, the GTM may delegate that monitoring activity to a different iquery-connected F5-device. it doesn't necessarily handle the monitoring itself. from my experience, it will choose a live F5 device (GTM or LTM) in the same GTM data center as the monitored virtual-server object. for example, if an http monitor is assigned to a GTM pool/member in DC1, the GTM may tell another LTM in DC1 to monitor that object and relay the status back via iquery. this can cause issues if there's a firewall that prevents the selected F5 device from hitting that server object via port 80, 443, etc. required by the non-bigip monitor

my apologies if the following is overkill - just want to lay out some iquery functionality that is often vague in documentation and misunderstood until you have to dig in:

regarding the earlier comment "This GTM does communicate with LTMs using iquery, however the GTM does not use that data. All server/member/node objects in the GTM are added manually."

iquery is used between GTM/LTM not only to autodiscover LTM virtual servers and monitor health of the F5 devices, but also to pass on health status of virtual servers from the LTM on which a vs is configured to a GTM that is configured with that vs as a GTM vs object, regardless of whether the server object was manually added or autodiscovered - if a GTM vs was manually added to the LTM server object and a bigip monitor is assigned to that server object, the GTM will ascertain the vs status via its iquery connection from that LTM.

when a specific non-bigip monitor is assigned to a GTM pool/member/server, the GTM may delegate that monitoring activity to a different iquery-connected F5-device. it doesn't necessarily handle the monitoring itself. from my experience, it will choose a live F5 device (GTM or LTM) in the same GTM data center as the monitored virtual-server object. for example, if an http monitor is assigned to a GTM pool/member in DC1, the GTM may tell another LTM in DC1 to monitor that object and relay the status back via iquery. this can cause issues if there's a firewall that prevents the selected F5 device from hitting that server object via port 80, 443, etc. required by the non-bigip monitor

1. Yes, we have 2 data center objects.
2. Yes.
3. Unfortunately I have not been able to reproduce the problem with the non-production objects I have to work with.

@ken b and @matthiasritter - i doubt this solves the pool-level monitor vs. pool-member-level monitor discrepancy, but it's worth examining when troubleshooting GTM monitors

1. do you have multiple GTM data center objects configured?
2. in your GTM/LTM iquery mesh, regardless of having the correct rules allowing iquery communication, do you have firewalls/ACLs separating GTM/LTM devices that are in the same data center?
3. what does /var/log/gtm say about the pool-level and member-level monitors when they fail/pass?

I have not resolved this. I have not opened a support case yet. I have seen one other GTM problem with a health check not working correctly for a pool, however I think it might be resolved by HF5 for 11.4.1. So I am planning to install that as soon as management approves it. I need this patch for other bug fixes as well.

If HF5 does not resolve the issue, then I will pursue it with F5 support.

Hi,

I'm experienced the same problem. Did you solve this?

GTM marks down the Pool because the member (VIP) seems to be down, but the VIP in the menu: GSLB -> Servers -> "PoolServer1" -> Virtual Servers .. is still up. Seems to be a problem with the "http"-health-check??!?

Short answer is no, this is not expected behavior. A support case is your best bet.

I suppose it's good to know that this behavior is not expected. This might motivate me to open a case with F5 support to inquire about the issue. At least I know it's not working how it is supposed to. Much of the config in the GTM is not intuitive to me, so sometimes I'm never really sure how things are supposed to work.

1) I have not make any packet captures yet, as this hasn't been a critical issue.

2) This GTM does communicate with LTMs using iquery, however the GTM does not use that data. All server/member/node objects in the GTM are added manually.