2012/10/5 Amos Jeffries <squid3@xxxxxxxxxxxxx>: > On 5/10/2012 4:36 a.m., E.S. Rosenberg wrote: >> >> 2012/10/1 Amos Jeffries: >>> >>> On 01.10.2012 03:39, E.S. Rosenberg wrote: >>>> >>>> 2012/9/30 Amos Jeffries: >>>> >>>>> 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? > > > "questionable". IPv4s are running out, and how many does this one server > consume? Internally I have a /16 ("Class B") to work with and towards the ISP we currently have a /29. So far that is enough. > > It also limits the connection count since each IP is locked to one user who > woudl be using not many ports out of the 64k that IP would otherwise make > available. I am not sure I follow.... I'd be using IP addresses to convey a plan/ISP but lots of users would be "using" the same IP. > > >> 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... > > > That is a probem. I was of the understanding this was a single proxy layer > with upstream routes. The OS routing systems should be fully capable of > receiving TOS values from Squid and routing traffic based on them. Ah, no there are 2 layers of proxies, 1 layer facing the user that is supposed to do authentication etc. and basic caching and a second layer facing the ISPs that is supposed to be specialized in caching, connected to AV server, do delay pools and route users to different ISPs/plans@ISPs based on username or on the IP presented by the child caches. Regards, Eli > > Amos