Original Publication Date: 12/19/2007
Updated Date: 08/20/2015
BIG-IP LTM and BIG-IP GTM monitor mechanics
On the surface, the BIG-IP LTM and GTM monitors appear to provide roughly the same functionality. However, the operation and configuration of monitors differs significantly between BIG-IP LTM and GTM systems, particularly in the area of monitor timing. This article compares and contrasts the basic operations of BIG-IP LTM and GTM monitors, and describes the BIG-IP GTM monitor timer settings and their interactions in detail.
BIG-IP LTM monitors
The BIG-IP LTM health monitors are designed to check the status of pool members at a set interval. If a monitor target does not respond with the expected response within the configured timeout, the BIG-IP GTM system marks the object Unavailable and does not send traffic to the object until it is again Available. Since the BIG-IP LTM normally monitors devices in the network in which it resides, BIG-IP LTM monitors can afford to be somewhat verbose in terms of generating network traffic, including the overhead of multiple requests before marking an object Unavailable.
Generally, the BIG-IP LTM monitors operate in the following manner:
BIG-IP GTM monitors
The BIG-IP GTM health monitors are designed to check the status of a pool or virtual server at a set interval. If the monitor target returns an incorrect response, or does not respond within a specified timeout period, the BIG-IP GTM system marks the object Unavailable and does not send traffic to it until it is again Available. Since monitored objects may reside in multiple data centers over long geographical distances, the BIG-IP GTM monitors typically must be conservative in their use of shared WAN bandwidth, and must take into account the potential for increased latency. To minimize monitor related network traffic, the default interval for BIG-IP GTM monitors is typically longer than for BIG-IP LTM monitors, and by default the BIG-IP GTM system marks objects Unavailable more aggressively than the BIG-IP LTM system.
Generally, the BIG-IP GTM monitors operate in the following manner:
Note: In BIG-IP GTM 10.0.0 and later, you can mimic the less aggressive BIG-IP LTM behavior by setting the Ignore Down Response setting to Yes in the monitor configuration Advanced settings. Setting Ignore Down Response to Yes forces a BIG-IP GTM system which receives an incorrect monitor response or a TCP reset to wait until the monitor timeout has expired before marking the object Unavailable, rather than marking the object Unavailable immediately.
Interaction between BIG-IP LTM and BIG-IP GTM monitors
In general, F5 recommends that you monitor objects as closely as possible to the servers that are providing the content. For example, if you are using BIG-IP LTM to provide local load balancing for names resolved by GTM, F5 recommends configuring only the BIG-IP LTM to monitor the LTM pool members, allowing the BIG-IP GTM to collect object status information from the BIG-IP LTM system without configuring additional GTM monitors for the same objects. This results in the desired conservation of shared WAN bandwidth, and eliminates cross-data center latency.
The BIG-IP LTM and BIG-IP GTM work in concert to maintain the status of objects managed by BIG-IP GTM that are locally load balanced by BIG-IP LTM, exchanging information about system and object status using F5's iQuery protocol. To support this constant exchange of status information, a mesh of iQuery connections is established between the gtmd processes on the BIG-IP GTM systems and the big3d processes running on the BIG-IP LTM systems. To establish this communication mesh, the gtmd daemon on each BIG-IP GTM system in the sync group will attempt to establish an iQuery connection to each self IP address listed for each server configured as type BIG-IP. In addition, if Link Discovery is enabled and a BIG-IP server uses a default gateway pool, the gtmd process will also attempt to connect to any self IP address that resides on a default gateway's subnet.
Note: An iQuery connection is an SSL connection originated by the gtmd daemon to the big3d daemon running on port 4353 of the BIG-IP server. When the big3d daemon starts, it listens for port 4353 on all configured self IP addresses and the management IP address.
The information exchange between BIG-IP GTM and BIG-IP LTM begins with a request (referred to as a probe request) that is sent by the gtmd process to a big3d process to retrieve the status of a specific object. The probe request instructs the big3d process regarding performance of the probe, including the timeout, and for some monitors, the timing of multiple probes. The big3d process uses iQuery to broadcast its response to the requester and to any of its sync group members that have an established iQuery connection. The BIG-IP GTM system dynamically selects the big3d process for each probe request. The BIG-IP GTM system will choose big3d processes that only exist within the same datacenter as the monitored device. However, selection is dynamic among the available big3d processes in the datacenter. If this behavior is undesirable, the BIG-IP GTM Prober Pools feature (10.2.0 and later) allows you to configure specific group(s) of BIG-IP devices to use as the designated big3d monitoring points. You can then assign the Prober Pools feature to specific GTM servers.
Important: A probe request does not precipitate a continuous status update of that object by the big3d process. The big3d process will only broadcast the current probe status once in response to each gtmd-initiated probe request. Configuring multiple Probe Attempts for monitors that support it does not change this behavior: A single response to the probe request is derived from the results of the probe. Once the big3d process has broadcast its response to the probe request, the big3d process will delete all information related to that probe request. In order to receive an updated status from the big3d process, the gtmd process must issue a new probe request regarding the object.
BIG-IP GTM monitor timers
The available BIG-IP GTM monitor timers are defined as follows:
Note: You must configure a Timeout value for all BIG-IP GTM monitor types.
Note: You must configure a Probe Timeout value for all BIG-IP GTM monitor types except for the BIG-IP and BIG-IP Link monitor types.
Note: You can configure a Probe Attempts value only for the following monitor types: Gateway ICMP, SNMP, SNMP Link, TCP Half Open, and UDP. All other monitor types are hardcoded to one probe attempt. However, in BIG-IP GTM 10.0.0 and later, if you set the Ignore Down Response setting to Yes (in the Advanced monitor settings), BIG-IP GTM system will wait until the monitor timeout has expired before marking the object Unavailable, rather than marking the object Unavailable immediately.
Note: You can configure a Probe Interval value only for monitor types which allow configuration of the Probe Attempts value: Gateway ICMP, SNMP, SNMP Link, TCP Half Open, and UDP.