10 iRules and Local Traffic Policies

When the built-in settings aren’t enough, BIG-IP lets you program traffic decisions. Local Traffic Policies do it with forms (conditions → actions); iRules do it with code. This note explains both, when to choose each, and their dependencies.

iRules

iRule in one line

An event-driven script (TCL with F5 extensions) attached to a virtual server that runs custom logic whenever a traffic event happens.

• An iRule does nothing until it’s attached to a VS; then it runs on every connection or request that triggers its events.
• It’s code, not a firewall-style rule list.

Structure

when HTTP_REQUEST {
    if { [string tolower [HTTP::host]] contains "company.com" } {
        pool HTTP_APP1_Pool
    }
}

• when <EVENT> — when to run.
• Commands — what to do.
• Data groups — lists (IPs, strings, integers) checked with class match.

Common events and commands

Event	Fires when
CLIENT_ACCEPTED	A client connection is accepted (L4)
CLIENTSSL_HANDSHAKE	The client-side TLS handshake completes
HTTP_REQUEST	BIG-IP has parsed the client’s HTTP request headers
LB_SELECTED / LB_FAILED	A pool member was chosen / couldn’t be chosen
SERVER_CONNECTED	The server-side connection is established
HTTP_RESPONSE	BIG-IP has parsed the server’s response headers

Command	Does
pool, node	Choose the destination
snat	Apply a specific SNAT IP or pool
persist	Set persistence (source_addr, cookie, uie…)
HTTP::redirect, HTTP::respond	Redirect or answer directly from BIG-IP
HTTP::header insert/remove/replace	Manipulate headers
reject, drop	Refuse the connection
log local0. "msg"	Write to /var/log/ltm

Dependencies

• Events and commands of a protocol require that profile on the VS: HTTP_*, HTTP::header, HTTP::uri, HTTP::host → HTTP profile; CLIENTSSL_* → Client SSL profile.
• CLIENT_ACCEPTED + IP::client_addr is Layer 4 → works with only TCP.
• Persistence from an iRule: persist cookie needs the HTTP profile (and a cookie persistence profile), and persist uie (universal) needs a universal persistence profile on the VS. Best practice for any method is to attach a matching persistence profile so you control the timeout and options.
• HTTP::uri = path and query (/index.php?id=123); HTTP::host = the domain (FQDN). To match company.com use host, not uri.

Operating iRules

• Several iRules on one VS run in order; priority changes the order per event.
• log local0. writes to /var/log/ltm. Use it for debugging and remove or limit it in production (logging costs CPU).
• TCL runtime errors (e.g. an HTTP command on a VS without HTTP profile) are logged in /var/log/ltm and usually reset the connection.
• Per-iRule Statistics: executions, failures, aborts, CPU cycles.
• To see if an iRule is in use, check where it’s assigned (virtual servers) and its statistics.
• Community examples: DevCentral. Reference: clouddocs.f5.com/api/irules.

Examples

# Insert the real client IP when SNAT is used
when HTTP_REQUEST {
    HTTP::header insert X-Forwarded-For [IP::remote_addr]
}

# Send one client to a specific pool (Layer 4, no HTTP profile needed)
when CLIENT_ACCEPTED {
    if { [IP::client_addr] equals "172.16.101.5" } {
        pool HTTP_APP1_Pool
    }
}

# Redirect HTTP to HTTPS (BIG-IP also ships _sys_https_redirect)
when HTTP_REQUEST {
    HTTP::redirect "https://[HTTP::host][HTTP::uri]"
}

# Send /api requests to another pool
when HTTP_REQUEST {
    if { [HTTP::uri] starts_with "/api" } {
        pool pool_api
    }
}

Local Traffic Policies (LTM policies)

• Rule-based decisions without code: conditions (host, URI, header, client IP, TCP address…) → actions (forward to pool/node, redirect, insert header, enable/disable ASM, reset…).
• Strategy: first-match, best-match or all-match.
• Lifecycle: Draft → Publish → assign to the VS. A policy must be published before it can be selected on a virtual server. A policy with no rules can still be published, but not without a strategy.
• Reference: BIG-IP Local Traffic Policies: Getting Started.

Policies vs iRules

	LTM policy	iRule
Configured with	GUI forms / tmsh	TCL code
Ease	Easier to build and maintain	Requires coding
Performance	Faster (compiled)	Slower if complex
Flexibility	Predefined conditions and actions — not everything an iRule can do	Almost anything

Rule of thumb

If a policy can do it (pool selection by host/URI, redirects, header insertion), use a policy. Use iRules for custom logic: complex conditions, data manipulation, logging, iSNAT, custom persistence, protocols without policy support.

Configuration objects: keep it minimal

• Configure only the objects a goal needs. Extra iRules, profiles and pools consume resources and add complexity.
• iRules are not dependency-free: they can depend on profiles, persistence profiles, pools and data groups.
• Orphaned objects (left after changes) can be found with iHealth → Config Explorer → Unused Objects.

Self-check

Q1 — Where are iRules assigned, and where do you see their activity?

Respuesta

Assigned to virtual servers; activity in Statistics.

Q2 — Both iRule examples need Layer 7 data. Which profile must the VS have?

Respuesta

The HTTP profile.

Q3 — Can iRules depend on profiles?

Respuesta

Yes.

Q4 — A new LTM policy isn't available to choose on the virtual server. The rules are correct. Why?

Respuesta

The policy must be published.

Q5 — Can a policy with no rules be published?

Respuesta

Yes (it needs a strategy, though).

Q6 — An iRule should match the domain company.com. HTTP::uri or HTTP::host?

Respuesta

HTTP::host — uri is the path and query.