2012/10/10 E.S. Rosenberg <esr@xxxxxxxxxxx>:
> 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
I forgot to ask:
Is it possible to have an ext_acl return multiple tags (to 'stack' tags)?
Thanks,
Eli
