How Much Bandwidth is Too Much?

In an age of unlimited bandwidth; how do we prevent a “greedy” user from consuming all of our bandwidth? “Bandwidth controllers” (BWC), a feature of BIG-IP, can help prevent an overflow of data and keep things fair.

Some examples of using BWC would be to limit the amount of data that can be downloaded from an AWS S3 bucket or prevent a user that is streaming a 4K video from saturating the network.

Bandwidth Controllers

On the BIG-IP we can control the amount of bandwidth that an application or user gets. This could control the amount of bandwidth that a user can get to access an application you provide (ingress) or the amount of bandwidth that you provide to the Internet (egress).

Bandwidth controllers can use either a static or dynamic policy to control bandwidth.

Static Policy

A static policy provides an aggregate bandwidth limit. Think of this like taking a garden hose and adding a nozzle. All requests are throttled evenly across the defined max. For example, you can limit a site that provides file downloads to 100 Mbps.  

A static policy is very simple and can be useful to apply an egress policy like “students share 100 Mpbs of internet and faculty share 1 Gbps of internet based on the originating subnet” or limit backups/games that go over port XXXX to 100 Mpbs.

Dynamic Policy

A static policy can be abused. In the previous egress scenario a savvy student could create multiple connections and “steal” bandwidth from other students.

A dynamic policy provides a fairer mechanism to apply both a global (similar to static) and “user” policy. A dynamic policy could refine the previous example to impose a 10 Mbps end-user limit based on source IP address as well as the overall max of 100 Mbps for students and 1 Gbps for faculty.

To use a dynamic policy you need to define what is the key or bucket that you want to sort your users by. This could be an IP address, session ID, or other criteria.

In Action

The following is an example of limiting access to an AWS S3 bucket. It does the following:

  • Limit overall download to 200 Mbps
  • Identify users by either IP address or X-Forwarded-For header
  • Limit individual user to 100 Mpbs


Here is an example of the dynamic policy that implements the 200 Mbps and 100 Mbps limits.

Identifying User

The method to identify a user can be done with the following iRule.

This iRule accepts either the client IP address or the X-Forwarded-For header. This could also key off a header that is sent by the server if you want to have a custom X-BWC-Policy header that is set by the application (i.e. authenticated users get 10 Mpbs of download and anonymous users 1 Mpbs).

Example Scenario

In this example you can see the first user gets the full 100 Mbps on their first connection (~12 MB/s).

When the first user opens a second connection the bandwidth gets split between the two connections (~6 MB/s each).

When a second user connects they also get the full 100 Mbps of bandwidth (~12 MB/s).

When a third user connects you can see the traffic gets split across the 3 users to keep the overall max under 200 Mbps (~8 MB/s per user).

Note that 100 Mbps is ~12 MB/s this is one of those fun there are 8 bits in a byte (100 megabytes / 8 = 12.5 megabits). Upper case B is bits and lowercase b is bytes.

Level Playing Field

A more sophisticated deployment could also make use of Service Provider features that can provide finer granularity. Please see, "PEM: Subscriber-Aware Policy and Why Every Large Network Needs One", for an example of using this feature to limit traffic based on URL classification.

Bandwidth controllers are useful to keep the peace and allocate resources fairly.

Published Jul 01, 2019
Version 1.0

Was this article helpful?


  •  This helped us move past the original error and we are now seeing the following. It is almost as if because the traffic is coming from the same IP it is throwing an attachment error.




  • Hi Eric, I was directed to your article to assist me with creation of bandwidth control environment. I need the solution to be broader than apply to HTTP traffic or even TCP traffic (it needs to cover both TCP and UDP). I want to apply the policy to ideally an IP forwarding VS or at least a Performance L4 VS. First of all can you confirm if this is possible i.e. can BIG-IP shape / limit all these traffic types? Second could you let us know how the iRule / Config would need to be modified to support all traffic types flowing through a VS. Lastly is BIG-IP able to perform the bandwidth control in both directions or just one? If both is possible what needs to be done again in that circumstance. Thanks

  • Re: can it be used with other protocols

    The short answer is yes it should be possible, but you'll need to test the flows to make sure it is working as expected. To test you should create a IP Forward VIP and attach an iRule and see if it works as expected.

    UDP I'm not 100% sure, so definitely something to test.  The direction of the flow matters so you should check that it is being limited in the expected direction of flow.

  •  In version the iRule is giving an error - Oct 26 00:53:33 lab-lb1 err tmm1[22643]: 01220001:3: TCL error: Dynamic-100Mbps-iRule <HTTP_REQUEST> - expected boolean value but got "" while executing "if { [HTTP::header exist X-Forwarded-For] } { set remote_ip [HTTP::header X-Forwarded-For] } else { set remote_ip [IP::remote_addr] }"


    Any thoughts? Seem to work fine testing internally on version 14.1.4..1.




  • Thanks Eric,

    With the assistance of another colleague we've now been able to generate a config that works for all traffic so I thought I'd come back and post the settings used. I've had it confirmed that for traffic shaping when not using a 'standard' VS type you need to use 'Rate Shaping' and not 'Bandwidth Controllers', so that was the major thing. We used a 'Performance(L4)' VS type. The Protocol Profile was left as the default 'fastL4'. In the environment is was doing testing I needed Source Address Translation (AutoMap), in a real environment this shouldn't be required so long as the return traffic routes via the BIG-IP.