Search squid archive

Re: Clarification on delay_pool bandwidth restricting with external acls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/06/2012 2:20 p.m., Cameron Charles wrote:
Hi all, im just after some clarification on using delay pools with
external acls as triggers, i have a good understanding of the
components of delay pools and how they operate but most documentation
only mentions users aka ip addresses as the method of triggering the
restriction, i would like to use an external acl to decide whether a
request should be limited or not regardless of any other factors, so
any and all traffic coming through squid, if a match to this acl, is
restricted to say 128bps, is this possible and is the following the
correct way to achieve this???

acl bandwidth_UNIQUENAME_acl external bandwidth_check_ext_acl_type UNIQUENAME
http_reply_access allow bandwidth_UNIQUENAME_acl !all
delay_class 1 1
delay_parameters 1 128.0/128.0
delay_access 1 allow bandwidth_128.0_acl
delay_initial_bucket_level 1 100

additionally im a inexperienced when it comes to actually testing
bandwidth limits is it possible to simply download a file that is
known to be a match to the ext acl and observe that it doesn't
download at over the bandwidth restriction or is testing this more
complicated.

Yes that is pretty much it when testing. Max download should be no more than 128 bytes per second according to that config.

If that shows a problem the other thing is to set debug_options ALL,5 (or the specific delay pools, comm, external ACL and access control levels specifically) and watch for external ACL results and delay pool operations to see if the issue shows up.

Amos


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux