5

We have a marvellous squid proxy with dansguardian for filetering and they both work just great. Is there any easy way to limit the total bandwidth usage? I'd like to set the max amount of squid users internet use to 1200 since our total band is 2000 and I need the rest to ensure other services such as voip to work without hiccups related to huge downloads on the "internet side" of our connection and similar issues. I mean a total squid bandwidth limitation and not a user-based.

Fair thanks to everybody.

Pitto
  • 2,009
  • 10
  • 33
  • 49

2 Answers2

9

Yes yoy can limit Squid's total bandwidth. For exapmle say, 512 Kbps?
Add following to /etc/squid3/squid.conf

delay_pools 1  
delay_class 1 1  
delay_access 1 allow all  
delay_parameters 1 64000/64000          # 512 kbits == 64 kbytes per second  

To change a running instance of squid run following after changing the config file
sudo squid3 -k reconfigure

Reference
DelayPools
Bandwidth-Limiting-HOWTO

totti
  • 191
  • 1
  • 3
4

You could set up shaping with rules something like this:

tc qdisc del dev eth0 root

tc qdisc add dev eth0 root handle 1: htb default 1 r2q 160

tc class add dev eth0 parent 1: classid 1:1 htb rate 2000kbit burst 1k
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 2000kbit ceil 2000kbit burst 1k
tc class add dev eth0 parent 1:1 classid 1:3 htb rate 1200kbit ceil 1200kbit burst 1k

tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10
tc qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 10

Then you could use iptables to classify packets into these classes:

iptables -t mangle -A POSTROUTING -o eth0 --set-class 1:2
iptables -t mangle -A POSTROUTING -o eth0 -m tcp -p tcp --dport 80 -j CLASSIFY --set-class 1:3

Note that it's the last matching rule that sets the class, it doesn't short-circuit when one rule matches. It took me a while to grok that.

Sean Reifschneider
  • 10,370
  • 3
  • 24
  • 28
  • :O God bless you! So this are all bash commands, right? Can I do a backup of my current configuration so I can test this solution with safe conditions of not interrupting for too long production? – Pitto Dec 05 '10 at 11:45
  • Yes, these are all bash commands. They don't permanently change the system, so if they don't work out you can just reboot to get back to where it is now, or possibly do "service iptables restart" (depending on the firewall and how it's started). If you want to make it permanent, after testing, you will need to put it into the firewall script (/etc/init.d/iptables, or elsewhere depending on the distro and firewall packages), interface configs, or rc.local. – Sean Reifschneider Dec 05 '10 at 12:32
  • Is this sufficient to allow my voip phones to use the remaining bandwidth? The Voip guy told me that with the modification you suggest me the packet request is "made" so we could fill the bandwidth anyway and all we could get is a drop of incoming packets... Is he right? I just want to do this kind of modification to separate the normal internet usage from the voip needed bandwidth to communicate fluently... – Pitto Dec 09 '10 at 10:48
  • 1
    Shaping has to be done before the packet reaches the buffer in the router on the line that suffers congestion. However, often you don't have control of the router on the far end (your ISP). So, the VoIP guy is right, for incoming packets. Unless you can implement shaping at the remote end of the line, incoming traffic is already going to be in the router buffers before your shaping has time to help. Because of the way TCP works, connections try to run a little faster than the line, so you can't shape after they've hit the line. But for outgoing traffic, this should work. – Sean Reifschneider Dec 09 '10 at 17:58
  • Even if probably not useful I've decided to implement your solution but when I enter: iptables -t mangle -A -o eth0 --set-class 1:2 I get: Bad argument `eth0' Try `iptables -h' or 'iptables --help' for more information. Any hint? – Pitto Jan 14 '11 at 09:43
  • Try adding "POSTROUTING", I've updated the example above. Sorry about that. – Sean Reifschneider Jan 16 '11 at 02:19