You get a bonus - 1 coin for daily activity. Now you have 1 coin

Bandwidth Limiting via Squid (delay pools)

Practice



Limiting internet channel bandwidth for various users or computers is not a new topic and has been discussed quite a lot. One of the most common methods for solving this is to use the traffic "shaping" or speed-limiting capabilities built into the kernel firewalls IPFW or IPTABLES.

Although using firewalls for this task is probably one of the most popular approaches, other solutions exist as well. For example, if you have a caching proxy server Squid installed, you can use it.

Why bother with Squid? For example, you're not on very friendly terms with IPTABLES or IPFW (for Linux and FreeBSD respectively), you don't want to risk a gateway located remotely from you (mistakenly breaking the firewall config and, as a result, losing the ability to manage it), or you want to tie the channel width limit to the logged-in user (for example, when Squid works with authentication of connecting users and people with different speed-limiting rules can access the internet from the same machine).

Note. You should also keep in mind the flip side of the coin - Squid can only control traffic speed for HTTP/S. Everything else that isn't routed through the proxy server will pass at maximum speed or as set via the firewall.


A technology called Delay pools is used to limit channel speed in Squid. However, by default Squid is built without it, and you will probably need to reinstall the proxy server to enable this option.


Enabling delay-pools

For FreeBSD:

Here I'll assume you have Squid 3.1. For 3.0, use the path "../squid30"
$ cd /usr/ports/www/squid31
$ make config

If the "SQUID_DELAY_POOLS" checkbox is not checked - it means the proxy server was built without support for this option. In that case, do the following (having exited make config without saving):
$ sudo make deinstall
$ sudo make config
(enable SQUID_DELAY_POOLS)
$ sudo make reinstall


For Linux Debian/RHEL:

By default, Squid installed via apt-get (or yum for rhel) comes with delay pools support, so in this case there's nothing to do.

If you are building Squid from source - then don't forget to specify the "--enable-delay-pools" flag for ./configure.



Configuring delay-pools

To do this we need to open the Squid configuration file: squid.conf. For each OS it's located in its own place:
  • FreeBSD: /usr/local/etc/squid/squid.conf
  • Debian: /etc/squid/squid.conf
  • CentOS/RedHat: /etc/squid/squid.conf

So, open this file for editing.



Number of pools

First determine - how many pools you will be configuring. For example, one pool for restricted users, one for regular users, and one for management (3 total).

After that, add this option to the config file:
delay_pools 3
where instead of 3 you specify the number of pools.


Configuring each pool

Now let's define the parameters for each pool. Pools are defined by their number: 1, 2, 3...

First let's set the pool classes. The thing is, Squid provides us with several classes that differ in their properties.

For example:
delay_class 1 1
delay_class 2 2
delay_class 3 2
here the first digit in the parameter is the pool number, and the second is the pool class.


Now let's specify the ACL for which this pool will operate. We must first create the ACL using Squid's standard syntax, placing in it a set of subnets, computers or users.

For example:
# Management
delay_access 1 allow chiefs

# Regular users
delay_access 2 allow users

# Specially restricted users
delay_access 3 allow minusers

And specify the parameters for each pool. For example:
# Pool 1 - unlimited speed
delay_parameters 1 -1/-1

# Pool 2 - the total speed of all users is not limited, but each
# user cannot exceed 1024Kbit/s (128KByte/s). Class 2 allows
# splitting the speed limits (more on this below).
# In this case the first 128KByte for each connection will be downloaded without limitation
delay_parameters 2 -1/-1 128000/128000

# Pool 3 - the total speed of all users - no more than 2048Kbit/s (256KByte/s),
# but each user cannot exceed 512Kbit/s (64KByte/s). Class 2 allows
# splitting the speed limits (more on this below).
# In this case the first 128KByte for each connection will be downloaded without limitation
delay_parameters 3 256000/128000 64000/128000

As you can see, the parameters are split into pairs. The first number in the pair is the speed limit in Bytes/second (not Bits!), and the second is "the first XX bytes that will be transmitted to the user at maximum speed".

Instead of a specific number you can use -1, which means "don't take this parameter into account".

The number of parameters and their meaning depends on the pool class (about classes - below).

Let's go through 3 examples, from which, I hope, the effect of the parameters will become a bit clearer:
  • a) 256000/128000 : Here we limit the speed to 256000 bytes/s (256KByte/s), and the first 128000 bytes (128Kbyte) of each request will be downloaded at maximum speed - i.e. without limitation.
  • b) 256000/-1 : Here we limit the speed to 256000 bytes/s (256KByte/s), and this applies right from the first byte of traffic.
  • c) -1/-1 : Here we say that no restrictions exist for this traffic.


As a result of the example written above, we will have the following:
  • 1) Management browse without restrictions;
  • 2) Users are limited to a speed of 1Mbit/s each, while the first 128KByte will be downloaded at maximum speed;
  • 3) Restricted users: here each user is given a limit of 512Kbit/s, while all users combined are limited to a total speed of 2Mbit/s (i.e. together they cannot download faster than 2Mbit/s), and the first 128Kbyte for each connection will be downloaded without a speed limit.


Pool classes

Squid provides several pool classes that differ in their traffic-limiting capabilities. Let's look at them now.


Class 1

Limits the total speed for all hosts belonging to a specific ACL. That is, it doesn't distinguish between individual users - it simply sums up the total bandwidth of all users from the specified ACL and limits all users equally depending on the usage of the allocated bandwidth.

delay_class 1 1
delay_access allow myacl
delay_parameters 512000/-1
in this example we limit all users from myacl to a total of 4Mbit/s (512Kbyte/s).


Class 2

Limits the total speed for all hosts, but allows limiting individual users separately. That is, "the total from the ACL no faster than A, but each user - no faster than B".

delay_class 1 2
delay_access allow myacl
delay_parameters 512000/-1 128000/-1
in this example we limit all users of myacl to a total of 4Mbit/s (512Kbyte/s), but at the same time, even with a free channel, each user individually will not get a speed higher than 1Mbit/s (128Kbyte/s).

Second example:
acl myacl1 src 192.168.0.0/24
acl myacl2 src 192.168.1.0/24
delay_class 1 2
delay_access allow myacl1 myacl2
delay_parameters 512000/-1 128000/-1
here we limit the speed of myacl1 to a total of 4Mbit/s and myacl2 to a total of 4Mbit/s. That is, these two ACLs are not limited jointly, but the rules are applied separately for each of them. Otherwise - everything the same.



Class 3

Limits the total speed, the speed of each ACL, and each host. That is, it's class 2 + a total limit for all ACLs included in the pool.

acl myacl1 src 192.168.0.0/24
acl myacl2 src 192.168.1.0/24
delay_class 1 3
delay_access allow myacl1 myacl2
delay_parameters 768000/-1 512000/-1 128000/-1
here we limit myacl1 to a speed of 4Mbit/s, myacl2 to a speed of 4Mbit/s, while each computer cannot consume more than 1Mbit/s even with a free channel. But on top of everything, we limit myacl1 and myacl2 combined to a speed of 6Mbit/s (i.e. the speed of myacl1 + myacl2 cannot exceed 6Mbit/s in total).

Thus, although we allocated 4Mbit/s to each ACL (which totals 8Mbit/s), we showed that together they cannot exceed a speed of 6Mbit/s.


Class 4

In addition to class 3, allows splitting the speed for each logged-in user. That is, we can limit:
  • a) All ACLs
  • b) + Each ACL
  • c) + Each computer in each ACL
  • d) + Each authorized user

For example:
acl myacl src 192.168.0.0/24
acl authacl proxy_auth user1 user2 user3
delay_class 1 4
delay_access allow myacl authacl
delay_parameters -1/-1 512000/-1 -1/-1 128000/-1

Here:
  • The total speed is not limited (-1/-1)
  • The speed for myacl and authacl is limited to 4Mbit/s for each of them (total for all hosts within the ACL)
  • The speed for each individual computer is not limited
  • The speed for users user1, user2 and user3 (authacl) is limited to 1Mbit/s each. In this case, if the same login is used by a user on several computers, the speed is counted in total across all computers this user is logged in from.



Conclusion

So that's it, in a nutshell, as a reminder, I've described how to use delay pools in Squid. By the way, there is also a fifth class, which I haven't covered. Unfortunately, I don't have time to deal with it (it's even more complicated and is based on external_acl's and requests grouped by tags).

Once again I want to repeat the main drawback of this method - you can only limit users by HTTP/S traffic. Anything that bypasses Squid is not limited.

Applicable to: Linux Debian/CentOS/RedHat or FreeBSD; Squid 3+

Comments

To leave a comment

If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Lectures and tutorial on "Computer networks"

Terms: Computer networks