on 01-Jul-2019 09:55
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.
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.
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.
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.
The following is an example of limiting access to an AWS S3 bucket. It does the following:
Here is an example of the dynamic policy that implements the 200 Mbps and 100 Mbps limits.
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).
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.
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.
In version 15.1.3.1 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.
/jeff
do you have a typo in your iRule? I believe the command should be "HTTP::header exists" https://clouddocs.f5.com/api/irules/HTTP__header.html
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 0.0.0.0/0 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.
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.