An iRule is a set of event handlers. You write blocks like when HTTP_REQUEST { ... }, and the BIG-IP runs each block when its event fires. The events are not arbitrary: they fire in a specific sequence that mirrors how a connection is actually processed, and which events appear depends on which profiles are attached to the virtual server.

The happy path, end to end

For a full HTTPS virtual server that re-encrypts to the pool (a client-SSL profile, an HTTP profile, a server-SSL profile, and a pool), the common events fire in this order:

CLIENT_ACCEPTED        client TCP connection established
CLIENTSSL_CLIENTHELLO  client's TLS ClientHello received
CLIENTSSL_HANDSHAKE    client-side TLS handshake complete
HTTP_REQUEST           full client request headers parsed
LB_SELECTED            pool member chosen
SERVER_CONNECTED       connection to the member established
SERVERSSL_HANDSHAKE    server-side TLS handshake complete
HTTP_REQUEST_SEND      about to send the request to the server
HTTP_RESPONSE          response status and headers parsed
SERVER_CLOSED          server-side connection closed
CLIENT_CLOSED          client-side connection closed

Remove a profile and the related events simply drop out. Take away the HTTP profile and you are left with a raw TCP flow: CLIENT_ACCEPTED, LB_SELECTED, SERVER_CONNECTED, SERVER_CLOSED, CLIENT_CLOSED. Take away the pool and there is nothing to load balance to, so LB_SELECTED and every server-side event disappear.

Why the order matters

The order is not trivia: it dictates what data is available when. HTTP::header works in HTTP_REQUEST because the headers have been parsed by then; calling it in CLIENT_ACCEPTED errors, because at that point the BIG-IP has a TCP connection and nothing more. Pool selection commands belong before LB_SELECTED; response commands only make sense from HTTP_RESPONSE onward. A large share of iRule runtime errors are really an event-order mistake: touching something that does not exist yet.

A map, not the territory

iRules event-order explainer models the documented order for a Standard (full-proxy) virtual server, which covers the vast majority of BIG-IP LTM - Local Traffic Manager use cases. The exact set also depends on modules: BIG-IP Zero Trust Access (formerly BIG-IP APM - Access Policy Manager), F5 AWAF - Advanced (formerly BIG-IP ASM - Application Security Manager), and others add their own events. It also depends on whether your iRule explicitly collects data. Use it to reason about where in the flow your logic should live, then confirm against a real configuration for anything unusual.

This series, in order

This article opens the series iRules events and the connection lifecycle. It walks the events in the order a connection fires them; the parts answer the questions that order raises: which side of the proxy an event sees, why an event may not exist on a given virtual server, what the handshake adds, which of several rules runs first, and how to choose the event before choosing the commands.

  1. Client Side vs Server Side in iRules. A full proxy holds two connections, and the same command returns different things on each side.
  2. What Makes an Event Fire: Provisioning and Profiles. An event exists only when its module is provisioned and its profile is attached, and some need a third ingredient.
  3. FastL4 vs Standard: Which iRule Events You Get. The full TCP proxy's rich events against the fast path that deliberately gives most of them up.
  4. iRule SSL Handshake Events. The events around the TLS handshake, and the ClientHello event that makes selection by possible.
  5. iRule Priority and Multiple Rules. When several iRules listen for the same event, priority decides which runs first.
  6. Writing an iRule: The Order the Questions Come In. Event first, commands second, cost third: why performance is the last question and not the first.