Thanks Chris.
-----Original Message-----
From: crobertson_at_gci.net [mailto:crobertson_at_gci.net]
Sent: 16 December 2008 02:53
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] Class 4 Delay pools
Johnny Edge wrote:
> Hello folks,
>
> I have a NT Group based acl Squid setup. Everything is fine with it, except for I'd like to provide certain NT Security Groups with more bandwidth than others, i.e. allocate bw by username/groupname.
> Atm the traffic control is done on a iproute2/tc basis which is not sufficient for my needs.
>
> Is this possible and how?
Yes. Probably using delay_access.
> I can't find decent info on Class 4 dalay pools usage.
A Class 4 pool works on a per-authentication (username) basis. Any given username is given a bucket/pool (possibly further restricted by the individual, network and/or aggregate buckets), no matter how many IPs their traffic is going to. A class 5 pool, coupled with an external ACL that returns tags according to group membership would allow you to have per-group pools (again possibly further limited by the other buckets), not really what you seem to be looking for. Your best bet is to read a bit more about delay_access and use that to push specific group members in to specific Class 1, 2 or 3 pools (depending on if/how you want to further allocate bandwidth within the pool).
For documentation, recently I've been pointing people at http://www.squid-cache.org/Doc/config/, but the section in there on delay_class is not very comprehensive and the section dealing with delay_parameters makes no mention of the fact that Class 4 and Class 5 pools are only available in Squid 3. Upon further inspection, there are links to the version specific information, so it's still a good place to
start. See http://www.squid-cache.org/Doc/config/delay_access/,
http://www.squid-cache.org/Doc/config/delay_class/ and http://www.squid-cache.org/Doc/config/delay_parameters/ with a dash of http://www.squid-cache.org/Doc/config/external_acl_type/.
> Please advise.
>
Hope that's advice and not chaos... Here's a bonus section with pseudo ACLs to help illustrate what I'm referring to:
acl FastUsers NTLMGroup matches ServerAdmins acl RegularUsers NTLMGroup matches LoggedInUsers # Yes, the FastUsers would also be part of this group acl SlowUsers NTLMGroup matches Guests # Should match all other computers that are allowed access
# Now I'll give two examples using the above ACLs # First, the ServerAdmins are given limited bandwidth (but less limited than everyone else) # and guests are even more limited...
# Allocate three pools
delay_pools 3
# All of type 1
delay_class 1 1
delay_class 2 1
delay_class 3 1
# Set up the ServerAdmin's pool
delay_parameters 1 32000/32000
# Next the users' pool
delay_parameters 2 16000/16000
# Finally the guest pool
delay_parameters 3 8000/8000
# Now we assign users to their respective pools delay_access 1 allow FastUsers delay_access 1 deny all delay_access 2 allow RegularUsers # ServerAdmins have already matched pool 1 delay_access 2 deny all delay_access 3 allow all
# Example 2, ServerAdmins are not limited. Everyone else is put into a class 3 pool.
delay_pools 1
delay_class 1 3
# 256kbit/s pool limit, no "network" limit, 16kbit/s individual bucket # Fun fact: Class 2 pools allow an individual bucket to match only the last octet while # class 3 has a separate bucket for every combination of third and fourth octet # (according to the documentation from Squid 2.6*).
delay_parameters 1 32000/32000 -1/-1 2000/2000 delay_access 1 deny FastUsers delay_access allow all
> Thanks,
>
> -JE
>
Chris
* In other words, given a class 2 delay pool, 10.0.0.10 and 10.0.1.10 would share an individual bucket, but would each have their own individual bucket in a class 3 pool. I haven't read the source code (or tested my theory on a real install), so the documentation
(http://www.squid-cache.org/Versions/v2/2.6/cfgman/delay_class.html)
might be wrong. I also might be mis-interpreting what the documentation conveys. Then again, maybe this code has been significantly changed since 2.6.
Received on Tue Dec 16 2008 - 06:57:53 MST
This archive was generated by hypermail 2.2.0 : Tue Dec 16 2008 - 12:00:01 MST