Applies To:

Show Versions Show Versions

sol8170: Overview of BIG-IP GTM monitor timers
OverviewOverview

Original Publication Date: 12/19/2007
Updated Date: 04/24/2014

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 Solution 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:

  • At regular intervals, the bigd process sends a request to each monitored object and evaluates the response.
  • By default, BIG-IP LTM monitors use a 3:1 timeout:interval ratio.
  • If the bigd process receives at least one correct monitor response during the timeout interval, the object is considered Available.
  • If the bigd process does not receive at least one correct monitor response during the timeout interval, the object is considered Unavailable.

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:

  • At regular intervals, the gtmd process sends a probe request for the status of the monitored object to a dynamically selected available big3d process.
  • The big3d process performs the requested probe and broadcasts the result to all listening gtmd daemons in the sync group.
  • Default BIG-IP GTM monitors use either a 4:1 or a 3:1 timeout:interval ratio for probe requests, and a 5 second timeout for the probes themselves.
  • If the gtmd process receives no monitor response during the timeout interval, then the object is considered Unavailable.
  • If the gtmd process receives an incorrect monitor response or a TCP reset, the object is marked Unavailable immediately.

    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.

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.

Important: The gtmd process dynamically selects the big3d process to be used for each probe request based on the current workload in each big3d process Active Queue. As a result, the gtmd process may select different big3d processes to perform probe duties for the same object.

BIG-IP GTM monitor timers

The available BIG-IP GTM monitor timers are defined as follows:

  • Interval

    The Interval is a mandatory setting for all monitor types which controls how often a probe request is sent out from the gtmd process to the big3d process. For example, if the interval value is set to 10 seconds, the gtmd process sends out a monitor probe request every 10 seconds.
  • Timeout

    The Timeout value controls how long the gtmd process waits for a response from the big3d process performing the probe before timing out and marking the server Unavailable. For example, if the timeout is set to 30 seconds, the gtmd process marks a virtual server Unavailable if it does not receive any monitor response from the big3d process within 30 seconds.

    Note: You must configure a Timeout value for all BIG-IP GTM monitor types.

  • Probe Timeout

    The Probe Timeout value controls how long the local big3d process waits for a response from a probe target before timing out a probe attempt. The big3d process makes one or more probe attempts after receiving a probe request from a gtmd process. If no response is returned within the Probe Timeout, the probe attempt fails. If multiple probe attempts were requested, the big3d daemon waits for the configured Probe Interval before making a subsequent attempt. If the final probe attempt fails, an Unavailable status is returned to the gtmd processes.

    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.

  • Probe Attempts

    The Probe Attempts value indicates how many probe attempts the local big3d process has to retrieve the expected response before returning an Unavailable status to the gtmd processes.

    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.

  • Probe Interval

    The Probe Interval value controls how long the big3d process will wait before sending out a subsequent probe attempt when a probe fails and multiple probe attempts have been requested. For example, if the probe interval is set to 5, and a probe fails, the big3d process would send out a subsequent probe attempt after 5 seconds.

    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.

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)