PERSIST_DOWN¶

Description¶

PERSIST_DOWN is triggered when LTM is ready to send the request to a particular node or pool member via persistence and it has been marked down. This is usually because the server has been detected as unreachable (when no route to the target exists) or non-responsive (failed to respond to a connection request).

Examples¶

when PERSIST_DOWN {
  pool errorPool
}

when PERSIST_DOWN {
  HTTP::respond 501
  reject
}

Related Information¶

Available Commands:

clone - Causes the system to clone traffic to the specified pool or pool member regardless of monitor status.
forward - Sets the connection to forward IP packets.
IP::idle_timeout - Returns or sets the idle timeout value.
ip_ttl - Returns the TTL of the latest IP packet received.
lasthop - Sets the lasthop of an IP connection.
listen - Sets up a related ephemeral listener to allow an incoming related connection to be established.
nexthop - Sets the nexthop of an IP connection.
node - Sends the packet directly to the identified server node.
peer - Causes the specified iRule commands to be evaluated under the peer’s (opposite) context.
persist - Causes the system to use the named persistence type to persist the connection.
session - Utilizes the persistence table to store arbitrary information based on the same keys as persistence.

Warning

The links to the sample code below are remnants of the old DevCentral wiki and will result in a 404 error. For best results, please copy the link text and search the codeshare directly on DevCentral.

Sample Code:

Introduced: BIGIP-9.4.2

Release Notes:

LTM 9.4.2 - 10.x

PERSIST_DOWN is not triggered on failed persistence when cookie persistence, MSRDP persistence, or CARP persistence is the configured persistence method. F5 Product development is tracking this issue under CR104960/BZ325230 ( SOL9115 ).

LTM 10.x

PERSIST_DOWN was not triggered in most cases unless no new pool member was available for load balancing. It is intended to fire even if the request was able to be load-balanced to a new pool member. This issue was tracked as CR139374/BZ225436 and fixed in 11.0. Contact F5 Support for a possible 10.2.x hotfix.

The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.