Forum Discussion

1 Reply

  • Martin_Machacek's avatar
    Martin_Machacek
    Historic F5 Account
    Well, iRules can be used as a part of solution implementing this feature. What you actually want to do (in majority of cases) is rate limit *responses* to requests for particular URI because requests are usually much smaller than responses. This can be done on BIG-IP 4.x by combining:

    - iRules (for matching the URI),

    - snatpools (for "marking the flow"),

    - ipfw rate filter (for the actual rate limiting).

    A skeleton solution may look like this:

    The goal:

    Rate limit responses to requests for URIs starting with "/low_priority" to 5Mbps.

    /config/bigip.conf:

    
    pool servers {
       member 10.1.21.2:80
       member 10.1.21.3:80
    }
    snatpool lowprio {
       member 10.1.21.169
    }
    rule rate_limit {
       if(http_uri start_with "/low_priority") {
          use pool servers
          use snatpool lowprio
       } else {
          use pool servers
       }
    }
    virtual 10.66.66.166:80 {
       use rule rate_limit
    }

    /config/ipfwrate.conf:

    
    // Filter "lowpriohttp"
    dstaddr(10.1.21.169) && tcp && srcport(80)
    {
            return [1];
    }
    return [0];

    /config/rateclass.conf:

    
     ClassName:  lowpriority
    ipfwrate -q 24288 -Q 16 1 5000000

    Please refer to BIG-IP Reference guide for details on how to configure rate filters.

    This is how it works:

    Source address of TCP connections to servers for URIs starting with "/low_priority" is set to 10.1.21.169. That allows the input ipfw rate filter to match TCP packets carrying the server response and send them to the rate limit queue with 5Mbps maximum rate. The solution is little bit arcane but it should work. Note that servers won't see the real client address for requests that are subject to the rate limit.