F5 LTM - Rate-limiting via iRules

Within this article we look at how to rate-limit traffic via the use of an iRule.


The Table Command

So that we can rate-limit traffic the iRule command 'table' is used. The table command (as the name suggests) provides the ability to create, delete, and append tables, along with being able to define timeouts for each table entry.

Each table that's created contains the following columns. 

  • Key - This is a key that is assigned to the table entry and reference during table look up.
  • Value - This is a value that is assigned to the key. 
  • Timeout - This is the timeout for the key.
  • Lifetime - This is the lifetime for the key. The difference between the timeout and the lifetime value is that at the point of table look up the timeout value is reset. 
  • Touch Time - This value indicates when the key entry was last touched. This value is mainly used internally.
  • Create Time - This value indicates when the key entry was created. This value is mainly used internally.

Table Example

Below shows an example of the table that is created.

 Table :

1 indefinite  1 1223830112 1223830112
2 indefinite  1 1223830110 1223830110
3 indefinite  1 1223830107 1223830107



Within our example we will rate-limit on a per IP, per URI basis.

Below is the iRule:

# Function : RateLimit HTTP GET requests per IP, per URI
# Created : 29/10/12
when RULE_INIT {
    set static::maxRate 3
    set static::windowSecs 1 
    if { ([HTTP::method] eq "GET") and ([class match [string tolower [HTTP::uri]] starts_with DATAGROUP-RATELIMIT-URI] ) } {
        # whitelist
        if { [class match [IP::client_addr] equals DATAGROUP-RATELIMIT-WHITELIST] }{
        # set variables
        set limiter [string tolower [HTTP::uri]]
        set clientip_limitervar [IP::client_addr]:$limiter
        set get_count [table key -count -subtable $clientip_limitervar]
        # main condition
        if { $get_count < $static::maxRate } {
            incr get_count 1
             table set -subtable $clientip_limitervar $get_count $clientip_limitervar indefinite $static::windowSecs
        } else {
            log local0. "$clientip_limitervar has exceeded the number of requests allowed."

How It Works

The way in which this iRule works is by creating a new table, named IP + URI and appending subsequent requests to the same table.
Each entry has a lifetime value and is removed once reached.

Finally the table is then counted to ensure that the total amount of requests for a given IP and URI has not exceeded the configured threshold.


Within this iRule 2 datagroups are used.

DATAGROUP-RATELIMIT-WHITELIST - (Type:Address) - Contains addresses that are not to be rate-limited.
DATAGROUP-RATELIMIT-URI - (Type:String) - Contains URIs that are to be rate-limited. If all URIs should be rate-limited then just add an / to this datagroup. 


In order to customize this iRule review the following 2 variables:

set limiter [string tolower [HTTP::uri]]
set clientip_limitervar [IP::client_addr]:$limiter

Ratelimit using different Attributes

If you wanted to ratelimit on a per IP, per hostname basis then then the line would be:

set limiter [string tolower [HTTP::host]]

Ratelimit using a single Attribute

Likewise if you wanted to only rate-limit of a per IP basis then the ':$limiter' would be removed from the '$clientip_limitvar' variable. 

Ratelimit Connections

If you want to rate limit traffic that is not HTTP based or the traffic is encrypted (SSL) then the following iRule can be used (click here).

Good to Know


It is worth nothing that the F5 places NO limits on the amount of memory that can be consumed when using the table command. Because of this it is recommended that once you have implemented this iRule that the memory of the device is monitored via the use of the command "show sys mem" within TMSH.


There are a number of bugs that can cause excessive memory usage or TMM instability when using the table/session command.
Below are the main F5 bug IDs, ref : BIG-IP cumulative hotfix version 10.2.4

ID381096 - Fixed a TMM connflow memory leak caused by iRule commands that temporarily suspend execution
ID363612 - Memory utilization for TCL string cache has been optimized. Ref : sol13889
ID374923 - Fixed a defect which could cause TMM to restart and leave a core when using the table command in an iRule on an SSL-enabled virtual server.

All of the above are fixed within HF5. However it is recommended to upgrade to the latest hotfix, which at time of writing this is HF7.


When session or tables are used within iRules Session DB mirroring is still performed, even if mirroring is not enabled on the virtual server.

Tags: TCL, iRule, BIG-IP F5