2012/10/1 Amos Jeffries <squid3@xxxxxxxxxxxxx>: > On 01.10.2012 03:39, E.S. Rosenberg wrote: >> >> 2012/9/30 Amos Jeffries <squid3@xxxxxxxxxxxxx>: >>> >>> On 30/09/2012 12:43 p.m., Eliezer Croitoru wrote: >>>> >>>> >>>> On 9/29/2012 9:38 PM, E.S. Rosenberg wrote: >>>>> >>>>> >>>>> I have A, B and C with a potential for quite a few more (not >>>>> necisarily ISPs but also browsing restrictions or lack thereof). >>>>> I guess I over-simplified things a bit, but we have lots of user based >>>>> stuff going on, in addition we also want to start capping bandwidth >>>>> usage on a per user basis so that resources are shared more fairly >>>>> etc. >>>>> Regards, >>>>> Eli >>>> >>>> >>>> >>>> Well still the only difference is that you will need to design the acls >>>> you are going to use. >>>> are you using tproxy or intercept? >>>> you can try by listing a of the things you want to implement and then >>>> plan >>>> the network design by that. >>>> >>>> if you have 6 ISP's for example you can put one proxy not cache at all >>>> for >>>> the interception and accounting stuff which is basically acls and other >>>> stuff. >>>> then use cache_peers with 6 incoming ports that will decide the outgoing >>>> port by the incoming port.(just something in my mind). >>> >>> >>> >>> or a "OK tag=ISP-1" from the external ACL helper and a tag type ACL in >>> tcp_outgoing_* to determine either outgoing IP or TOS marking. >>> >>> I recommend 3.2.1 or later for this type of thing though we did a lot of >>> bug >>> fixing and performance polishing of this type of config in 3.2. >>> >>> >>> >>>> >>>> if you have some ICAP service then put it somewhere in the >>>> infrastructure >>>> in a place that wont effect you delay pools etc. >>>> >>>> I dont remember about resources consumption by a no cache at all squid >>>> but >>>> it should be low. >>> >>> >>> >>> Squid uses a few MB base footprint and up to (usually under) 256KB per >>> concurrent transaction. The rest is cached data. >>> >>> >>>> I do remember you wanted somewhere to cache youtube etc.. >>>> I have a working solution for that and I'm working on store_url_rewrite >>>> which can benefit from this two. >>>> >>>> you can also add some captive portal that has user validation in it for >>>> wireless places ( I was working on a way to do it for transparent proxy >>>> like >>>> in wifi-coffe shops that has agreement and other stuff like "prepaid >>>> cap" >>>> that is being used in cellular providers. >>>> >>>> just make a list of things you need\want to get from the network and >>>> from >>>> there the only question is how to put the whole puzzle together. >>>> >>>> Regards, >>>> Elizer >>>> >>> >>> Amos >> >> >> Great. >> So just to summarize: >> - Reloading often is bad, use smartly structured ext_acls instead. >> >> As far as how we do it, we don't use tproxy, we have a class B for >> ourselves so internally, so the user facing proxy that needs to handof >> information about a forced plan because of some location does that >> through the IP it presents to the parent. > > > This is questionable practice. Does the information have to be passed as an > IP or would using TOS values to mark the service type for particular > handling work with your other infrastructure? Well this is what we need to do for one of our ISPs and I saw no reason not to use the same technique internally, what's bad about conveying that info like that? Also I don't see any ACL that in turn allows me to do stuff on the parent based on the TOS set by the child cache... Thanks, Eli > Squid can set outgoing for either of them just as easily and based on the > same ACLs. You can even migrate by setting both on Squid outgoing packets > while you upgrade other things. > > Amos > > >> The parent in turn is connected to all ISPs/plans so that it can get >> better caching results and limit the total traffic of a user (ie. >> wireless and lab stations). >> >> Youtube is something I hope to optimize for in the future but fist >> this general architecture needs to become active and then we'll start >> caching optimizations. >> >> Thanks, >> Eli > >
