Wiki: iRules API




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).


  pool errorPool

  HTTP::respond 501

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.

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.