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.
[Linux Audio Users] [Photo] [Yosemite News] [Samba] [Video Projectors] [Video Devices] [Big List of Linux Books] [LCD TVs] [Webcams] [Linux USB]